Re: [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM

Uwe Kleine-König
2019-01-16T17:28:49Z

On Wed, Jan 16, 2019 at 09:18:45AM -0800, Paul Walmsley wrote:
> On Wed, 16 Jan 2019, Uwe Kleine-König wrote:
>
> > On Wed, Jan 16, 2019 at 04:40:42PM +0530, Yash Shah wrote:
> > > On Wed, Jan 16, 2019 at 3:30 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > On Fri, Jan 11, 2019 at 01:52:44PM +0530, Yash Shah wrote:
> > > > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > > > > index a8f47df..3bcaf6a 100644
> > > > > --- a/drivers/pwm/Kconfig
> > > > > +++ b/drivers/pwm/Kconfig
> > > > > @@ -380,6 +380,16 @@ config PWM_SAMSUNG
> > > > > To compile this driver as a module, choose M here: the module
> > > > > will be called pwm-samsung.
> > > > >
> > > > > +config PWM_SIFIVE
> > > > > + tristate "SiFive PWM support"
> > > > > + depends on OF
> > > > > + depends on COMMON_CLK
> > > >
> > > > I'd say add:
> > > >
> > > > depends on MACH_SIFIVE || COMPILE_TEST
> > > >
> > > > (I guess "MACH_SIFIVE" is wrong, but I assume you get what I mean.)
> > >
> > > As of now, MACH_SIFIVE/ARCH_SIFIVE isn't available.
> > > @Paul, Do you have any comments on this?
> >
> > If this is not going to be available at least protect it by
> >
> > depends RISCV || COMPILE_TEST
>
> There's nothing RISC-V or SiFive SoC-specific about this driver or IP
> block. The HDL for this IP block is open-source and posted on Github.
> The IP block and driver would work unchanged on an ARM or MIPS SoC, and in
> fact, SiFive does design ARM-based SoCs as well. Likewise, any other SoC
> vendor could take the HDL for this IP block from the git tree and
> implement it on their own SoC.
>
> More generally: it's a basic principle of Linux device drivers that they
> should be buildable for any architecture. The idea here is to prevent
> developers from burying architecture or SoC-specific hacks into the
> driver. So there shouldn't be any architecture or SoC-specific code in
> any device driver, unless it's abstracted in some way - ideally through a
> common framework.
>
> So from this point of view, neither "depends MACH_SIFIVE" nor "depends
> RISCV" would be appropriate. Similarly, the equivalents for other
> architectures (e.g. "ARCH_ARM") or SoC manufacturers (e.g.,
> "MACH_SAMSUNG") wouldn't be appropriate for any generic IP block device
> driver like this one.

The dependency serves two purposes:

a) ensure that the build requirements are fulfilled.
b) restrict configuration to actually existing machines

When considering b) it doesn't make sense to enable the driver for (say)
a machine that is powered by an ARM SoC by TI. If you still want to
compile test the sifive driver for ARM, enable COMPILE_TEST. That's what
this symbol is there for.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |