ca027ae5 | 26-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
ARM: s3c: Switch i2c drivers back to use .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c8
ARM: s3c: Switch i2c drivers back to use .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230526214003.2134595-1-u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
6bac4f78 | 29-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: s3c: remove s3c6400 support
No board file and no dts file references the s3c6400 now, it's only s3c6410, so remove the final bits as well.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski
ARM: s3c: remove s3c6400 support
No board file and no dts file references the s3c6400 now, it's only s3c6410, so remove the final bits as well.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
cc146410 | 29-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: s3c: remove adc.c
This driver could not be enabled on s3c64xx for a long time because of the ARCH_MULTIPLATFORM dependency, so remove it.
Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by:
ARM: s3c: remove adc.c
This driver could not be enabled on s3c64xx for a long time because of the ARCH_MULTIPLATFORM dependency, so remove it.
Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
743c8fbb | 29-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: s3c: remove most s3c64xx board support
All traditional board files except for MACH_WLF_CRAGG_6410 were marked as unused, so remove them now.
Cc: Kwangwoo Lee <kwangwoo.lee@gmail.com> Cc: Peter
ARM: s3c: remove most s3c64xx board support
All traditional board files except for MACH_WLF_CRAGG_6410 were marked as unused, so remove them now.
Cc: Kwangwoo Lee <kwangwoo.lee@gmail.com> Cc: Peter Korsgaard <jacmet@sunsite.dk> Cc: Darius Augulis <augulis.darius@gmail.com> Cc: Maurus Cuelenaere <mcuelenaere@gmail.com> Cc: Ben Dooks <ben-linux@fluff.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
d1065293 | 09-Jun-2022 |
Juerg Haefliger <juerg.haefliger@canonical.com> |
ARM: s3c: Kconfig.s3c64xx: Fix indentation
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these r
ARM: s3c: Kconfig.s3c64xx: Fix indentation
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Link: https://lore.kernel.org/r/20220609082154.115301-4-juerg.haefliger@canonical.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
48bf4b84 | 09-Jun-2022 |
Juerg Haefliger <juerg.haefliger@canonical.com> |
ARM: s3c: Kconfig.s3c24xx: Fix indentation and replace some tabs
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the line
ARM: s3c: Kconfig.s3c24xx: Fix indentation and replace some tabs
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules.
While add it, replace tabs before comments with whitespaces (which seems to be more common), add a missing trailing endif comment and squeeze multiple empty lines.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Link: https://lore.kernel.org/r/20220609082154.115301-3-juerg.haefliger@canonical.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
1afde294 | 09-Jun-2022 |
Juerg Haefliger <juerg.haefliger@canonical.com> |
ARM: s3c: Kconfig: Fix indentation
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules.
S
ARM: s3c: Kconfig: Fix indentation
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Link: https://lore.kernel.org/r/20220609082154.115301-2-juerg.haefliger@canonical.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
6a5e69c7 | 20-Apr-2022 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
ARM: s3c: mark as deprecated and schedule removal
The Samsung S3C24xx and S3C64xx platforms are very old designs. S3C2416 was introduced in 2008 and S3C6410 in 2009/2010. They are not widely availa
ARM: s3c: mark as deprecated and schedule removal
The Samsung S3C24xx and S3C64xx platforms are very old designs. S3C2416 was introduced in 2008 and S3C6410 in 2009/2010. They are not widely available anymore - out-of-stock on FriendlyArm (one of manufacturers of boards) and only few specialist stores still offer them for quite a high price.
The community around these platforms was not very active, so I suspect no one really uses them anymore. Maintenance takes precious time so there is little sense in keeping them alive if there are no real users.
Let's mark all S3C24xx and S3C64xx platforms as deprecated and mention possible removal in after 2022 for the first and 2024 for the lattere. The deprecation message will be as text in Kconfig, build message (not a warning though) and runtime print error.
If there are any users, they might respond and postpone the removal.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220407072319.75614-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
5d6f5267 | 04-Apr-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: rework endianess selection
Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago.
The problems is
ARM: rework endianess selection
Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago.
The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them.
This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx.
As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment.
For the ARMv6/v7 platforms, there are two ways this could be handled
a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point.
b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work.
Out of these, I picked b) because it seemed slighly more logical to me.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|