Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
Hi Artem, On Tuesday 29 October 2013 15:06:20 Artem Bityutskiy wrote: On Tue, 2013-10-29 at 10:12 +0100, Guennadi Liakhovetski wrote: On Tue, 29 Oct 2013, Laurent Pinchart wrote: Hello, This patch series, based on v3.12-rc7, prepares various Renesas drivers for migration to multiplatform kernels by enabling their compilation or otherwise fixing them on all ARM platforms. The patches are pretty straightforward and are described in their commit message. I'd like to get all these patches merged in v3.14. As they will need to go through their respective subsystems' trees, I would appreciate if all maintainers involved could notify me when they merge patches from this series in their tree to help me tracking the merge status. I don't plan to send pull requests individually for these patches, and I will repost patches individually if changes are requested during review. If you believe the issue should be solved in a different way (for instance by removing the architecture dependency completely) please reply to the cover letter to let other maintainers chime in. Exactly this was my doubt. If we let these drivers build on all ARM platforms... Maybe we should just let them build everywhere? Unless there are real ARM dependencies. Maybe you could try to remove the restriction and try to build them all on x86? If they have never been used on anything but ARM, why would you remove ARM dependencies? Just for the sake of compile-checking? Also, if ARM dependency is ever removed, all these should become 'n' by default in the Kconfig, in order to make sure they do not slip into defconfigs of different architectures. The idea is that, if ARM is neither a compile-time nor runtime dependency, it should not be specified in Kconfig. However, if the IP core has never been used on anything but SuperH and ARM, I don't think clobbering the config process with drivers that can't be used on the target architecture would be a really good idea, especially now that we have a COMPILE_TEST Kconfig option. My preference does goes to SUPERH || ARM || COMPILE_TEST over no dependency at all. -- Regards, Laurent Pinchart ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Tue, 2013-10-29 at 14:22 +0100, Laurent Pinchart wrote: Also, if ARM dependency is ever removed, all these should become 'n' by default in the Kconfig, in order to make sure they do not slip into defconfigs of different architectures. The idea is that, if ARM is neither a compile-time nor runtime dependency, it should not be specified in Kconfig. However, if the IP core has never been used on anything but SuperH and ARM, I don't think clobbering the config process with drivers that can't be used on the target architecture would be a really good idea, especially now that we have a COMPILE_TEST Kconfig option. My preference does goes to SUPERH || ARM || COMPILE_TEST over no dependency at all. Ah, OK, I missed the entire COMPILE_TEST story. -- Best Regards, Artem Bityutskiy ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Mon, Oct 28, 2013 at 4:46 PM, Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com wrote: If you believe the issue should be solved in a different way (for instance by removing the architecture dependency completely) please reply to the cover letter to let other maintainers chime in. I have no real opinions on whether this is a good itermediate step towards complete arch-independence or not, but I just noticed that you still have the mach/* hierarchy in mach-shmobile/include/mach/*, and grep:ing around this seems totally unnecessary, I think it would be easy to produce a patch set eliminating mach/* from shmobile. (Usually we will just move all the headers down into the mach-shmobile folder.) Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
Hi Mark, On Tuesday 29 October 2013 09:04:49 Mark Brown wrote: On Tue, Oct 29, 2013 at 03:04:27PM +0900, Simon Horman wrote: I think this is a step in a good direction. However, I think it would be even better if the architecture dependency was removed completely. Yes, please. I've kept it for two reasons. The first one is that I can't compile-test all those drivers on all architectures. The spi-sh-msiof driver, for instance, uses io(read|write)(16| 32) which are not available on all architectures. There might be other similar problems that I can't catch, and I don't want to introduce build breakages in the kernel. The second reason is that, as the IP cores have never been used on anything but SuperH and ARM, I don't like the idea of clobbering the config process with drivers that are useless on the target architecture. Now that we have a COMPILE_TEST Kconfig option, my preference would thus go to SUPERH || ARM || COMPILE_TEST over no dependency at all. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
Hi Mark, On Tuesday 29 October 2013 10:23:31 Mark Brown wrote: On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote: The first one is that I can't compile-test all those drivers on all architectures. The spi-sh-msiof driver, for instance, uses io(read|write)(16| Which architectures are these and is there not a symbol we can depend on for them? arch/cris for instance. We can use readl/writel instead (maybe it would be time to rationalize and document the I/O accessors across all architectures, but that's another topic). My point is that there might be other issues that I won't be able to easily catch. This would break compilation for everybody for no reason, as the drivers are useless on non-SuperH, non-ARM platforms. That's why I believe COMPILE_TEST would be a better option as a first step. 32) which are not available on all architectures. There might be other similar problems that I can't catch, and I don't want to introduce build breakages in the kernel. This is easy enough to handle if we do run into issues, it seems better to get things available than try to step through architecture by architecture. The second reason is that, as the IP cores have never been used on anything but SuperH and ARM, I don't like the idea of clobbering the config process with drivers that are useless on the target architecture. Now that we have a COMPILE_TEST Kconfig option, my preference would thus go to SUPERH || ARM || COMPILE_TEST over no dependency at all. That's not what you did, though - you're not adding COMPILE_TEST. No, but I can add it :-) If this gets agreed upon, I'll respin the series with || COMPILE_TEST. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Tue, Oct 29, 2013 at 06:29:59PM +0100, Laurent Pinchart wrote: On Tuesday 29 October 2013 10:23:31 Mark Brown wrote: On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote: The first one is that I can't compile-test all those drivers on all architectures. The spi-sh-msiof driver, for instance, uses io(read|write)(16| Which architectures are these and is there not a symbol we can depend on for them? arch/cris for instance. We can use readl/writel instead (maybe it would be time to rationalize and document the I/O accessors across all architectures, but that's another topic). It'd certainly be sensible, or adding a config option to depend on if you rely on these functions. My point is that there might be other issues that I won't be able to easily catch. This would break compilation for everybody for no reason, as the drivers are useless on non-SuperH, non-ARM platforms. That's why I believe COMPILE_TEST would be a better option as a first step. Yes, it would - please do that. Note that it won't stop anyone running into build issues on other architectures though, it's just about stopping Kconfig noise. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
