All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Yash Shah <yash.shah@sifive.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	linux-pwm@vger.kernel.org, linux-riscv@lists.infradead.org,
	Thierry Reding <thierry.reding@gmail.com>,
	robh+dt@kernel.org, mark.rutland@arm.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sachin Ghadi <sachin.ghadi@sifive.com>
Subject: Re: [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
Date: Wed, 16 Jan 2019 18:28:49 +0100	[thread overview]
Message-ID: <20190116172849.h5qdfa5wc3vaprbn@pengutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1901160909540.19681@viisi.sifive.com>

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/  |

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: mark.rutland@arm.com, linux-pwm@vger.kernel.org,
	devicetree@vger.kernel.org, Palmer Dabbelt <palmer@sifive.com>,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	Sachin Ghadi <sachin.ghadi@sifive.com>,
	Yash Shah <yash.shah@sifive.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
Date: Wed, 16 Jan 2019 18:28:49 +0100	[thread overview]
Message-ID: <20190116172849.h5qdfa5wc3vaprbn@pengutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1901160909540.19681@viisi.sifive.com>

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/  |

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: mark.rutland@arm.com, linux-pwm@vger.kernel.org,
	devicetree@vger.kernel.org, Palmer Dabbelt <palmer@sifive.com>,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	Sachin Ghadi <sachin.ghadi@sifive.com>,
	Yash Shah <yash.shah@sifive.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
Date: Wed, 16 Jan 2019 18:28:49 +0100	[thread overview]
Message-ID: <20190116172849.h5qdfa5wc3vaprbn@pengutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1901160909540.19681@viisi.sifive.com>

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/  |

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-01-16 17:28 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11  8:22 [PATCH 0/2] PWM support for HiFive Unleashed Yash Shah
2019-01-11  8:22 ` Yash Shah
2019-01-11  8:22 ` [PATCH 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller Yash Shah
2019-01-11  8:22   ` Yash Shah
2019-01-15 20:11   ` Uwe Kleine-König
2019-01-15 20:11     ` Uwe Kleine-König
2019-01-16  9:21     ` Yash Shah
2019-01-16  9:21       ` Yash Shah
2019-01-21 11:20       ` Thierry Reding
2019-01-21 11:20         ` Thierry Reding
2019-01-11  8:22 ` [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM Yash Shah
2019-01-11  8:22   ` Yash Shah
2019-01-15 15:27   ` Christoph Hellwig
2019-01-15 15:27     ` Christoph Hellwig
2019-01-15 15:27     ` Christoph Hellwig
2019-01-15 22:00   ` Uwe Kleine-König
2019-01-15 22:00     ` Uwe Kleine-König
2019-01-16 11:10     ` Yash Shah
2019-01-16 11:10       ` Yash Shah
2019-01-16 16:46       ` Uwe Kleine-König
2019-01-16 16:46         ` Uwe Kleine-König
2019-01-16 16:46         ` Uwe Kleine-König
2019-01-16 17:18         ` Paul Walmsley
2019-01-16 17:18           ` Paul Walmsley
2019-01-16 17:28           ` Uwe Kleine-König [this message]
2019-01-16 17:28             ` Uwe Kleine-König
2019-01-16 17:28             ` Uwe Kleine-König
2019-01-16 19:29             ` Paul Walmsley
2019-01-16 19:29               ` Paul Walmsley
2019-01-17  8:19               ` Uwe Kleine-König
2019-01-17  8:19                 ` Uwe Kleine-König
2019-01-21 11:54                 ` Thierry Reding
2019-01-21 11:54                   ` Thierry Reding
2019-01-21 15:11                   ` Uwe Kleine-König
2019-01-21 15:11                     ` Uwe Kleine-König
2019-01-17  6:45         ` Yash Shah
2019-01-17  6:45           ` Yash Shah
2019-01-17  7:28           ` Uwe Kleine-König
2019-01-17  7:28             ` Uwe Kleine-König
2019-01-21 11:30     ` Thierry Reding
2019-01-21 11:30       ` Thierry Reding
2019-01-21 13:23       ` Uwe Kleine-König
2019-01-21 13:23         ` Uwe Kleine-König
2019-01-21 13:23         ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190116172849.h5qdfa5wc3vaprbn@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=sachin.ghadi@sifive.com \
    --cc=thierry.reding@gmail.com \
    --cc=yash.shah@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.