Message ID | 20250105160346.418829-1-ivo.ivanov.ivanov1@gmail.com |
---|---|
Headers | show |
Series | soc: samsung: usi: implement support for USIv1 | expand |
On Sun, Jan 05, 2025 at 06:03:43PM +0200, Ivaylo Ivanov wrote: > diff --git a/include/dt-bindings/soc/samsung,exynos-usi.h b/include/dt-bindings/soc/samsung,exynos-usi.h > index a01af169d..b7c1406f3 100644 > --- a/include/dt-bindings/soc/samsung,exynos-usi.h > +++ b/include/dt-bindings/soc/samsung,exynos-usi.h > @@ -9,9 +9,9 @@ > #ifndef __DT_BINDINGS_SAMSUNG_EXYNOS_USI_H > #define __DT_BINDINGS_SAMSUNG_EXYNOS_USI_H > > -#define USI_V2_NONE 0 > -#define USI_V2_UART 1 > -#define USI_V2_SPI 2 > -#define USI_V2_I2C 3 > +#define USI_MODE_NONE 0 > +#define USI_MODE_UART 1 > +#define USI_MODE_SPI 2 > +#define USI_MODE_I2C 3 This breaks ABI and does not build. You still need also: #define USI_V2_NONE USI_MODE_NONE and same for the rest. Best regards, Krzysztof
On Sun, Jan 05, 2025 at 06:03:45PM +0200, Ivaylo Ivanov wrote: > @@ -169,9 +207,12 @@ static int exynos_usi_configure(struct exynos_usi *usi) > return ret; > > if (usi->data->ver == USI_VER2) > - return exynos_usi_enable(usi); > + ret = exynos_usi_enable(usi); > + else > + ret = clk_bulk_prepare_enable(usi->data->num_clks, > + usi->clks); You need now exynos_usi_remove() callback and also error path after populate at end of probe. Best regards, Krzysztof
Hiya, On 1/5/25 4:03 PM, Ivaylo Ivanov wrote: > +#define USI_MODE_NONE 0 > +#define USI_MODE_UART 1 > +#define USI_MODE_SPI 2 > +#define USI_MODE_I2C 3 USI_CONFIG register refers to the protocol selection with USI_I2C, USI_SPI, USI_UART. How about getting rid of the MODE from the name? Cheers, ta
On 06/01/2025 08:41, Ivaylo Ivanov wrote: > On 1/6/25 09:36, Tudor Ambarus wrote: >> Hiya, >> >> On 1/5/25 4:03 PM, Ivaylo Ivanov wrote: >>> +#define USI_MODE_NONE 0 >>> +#define USI_MODE_UART 1 >>> +#define USI_MODE_SPI 2 >>> +#define USI_MODE_I2C 3 >> USI_CONFIG register refers to the protocol selection with USI_I2C, >> USI_SPI, USI_UART. How about getting rid of the MODE from the name? > > I thought about that too but I believe that mentioning that these constants > are for mode selection in their name is generally a good practice. Let me know > if dropping _MODE is really needed. I am fine with both, MODE feels a bit more descriptive indicating how the USI should be configured. Best regards, Krzysztof