Re: R-CAR's arch

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Jean,

On Thursday 22 May 2014 10:19:38 Jean Delvare wrote:
> Hi Simon and all,
> 
> I am in the process of cleaning up dependencies for hardware-specific
> linux drivers. I'm looking into R-CAR drivers now and I have to admit I
> am confused. Some drivers (drm, gpio) depend on ARM, some (i2c, gen2
> pci, thermal, sata) depend on ARCH_SHMOBILE, sound depends on SUPERH ||
> ARCH_SHMOBILE, gen2 usb depends on ARCH_R8A7790 || ARCH_R8A7791, while
> gen1 usb and video-in have no architecture/platform dependency at all.
> 
> Shouldn't all these drivers have the same architecture/platform
> dependency? If so, what would the correct one be?
> 
> I admit I don't really understand how SHMOBILE relates to ARM and
> SUPERH (which so far I thought were two different and totally
> independent architectures, but apparently I was wrong?)

CONFIG_SUPERH is defined for arch/sh only, and CONFIG_ARCH_SHMOBILE for 
arch/arm/mach-shmobile.

The Kconfig dependencies for Renesas drivers currently model two different 
things, which are what the driver requires in order to compile and which 
architecture(s) the driver can run on.

There's no question regarding the former. If a driver can only be compiled on 
arch/sh it must list CONFIG_SUPERH as a dependency. Ditto for CONFIG_ARM or 
CONFIG_ARCH_SHMOBILE. However, this should be a pretty uncommon case, as most 
drivers should have no compile dependency on a specific architecture (the 
exception here is when a driver uses an API not available on all architectures 
for which no specific Kconfig symbol exists).

The latter is more debatable. We've started by listing platforms on which the 
hardware is known to exist as dependencies to avoid cluttering the kernel 
configuration with useless options. However, this excludes drivers for 
automated builds that can be very useful to report compilation bugs early. 
We've thus started moving to adding a || COMPILE_TEST dependency to enable 
driver compilation even on architectures where the device isn't available 
(only when the driver is expected to compile properly of course).

We've decided to split dependencies on two (or more) lines, one for the 
runtime dependencies and one or more for the compile time dependencies. A good 
example of that is the SPI MSIOF driver.

config SPI_SH_MSIOF
        tristate "SuperH MSIOF SPI controller"
        depends on HAVE_CLK
        depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
        help
          SPI driver for SuperH and SH Mobile MSIOF blocks.

The first "depends on" line states that the driver requires the clock API to 
compile, and the second line states that the device is available on SUPERH and 
ARCH_SHMOBILE only, but can be compiled on other architectures when 
COMPILE_TEST is enabled.

I'd like to generalize this pattern, please feel free to help :-)

-- 
Regards,

Laurent Pinchart