Re: [PATCH v2 2/2] Embedded USB Debugger (EUD) driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 11, 2018 at 01:40:19PM -0700, pheragu@xxxxxxxxxxxxxx wrote:
> On 2018-09-05 04:18, Greg KH wrote:
> > On Wed, Sep 05, 2018 at 03:01:26PM +0530, Manu Gautam wrote:
> > > Hi,
> > > 
> > > 
> > > On 9/5/2018 3:04 AM, Prakruthi Deepak Heragu wrote:
> > > > Add support for control peripheral of EUD (Embedded USB Debugger) to
> > > > listen to events such as USB attach/detach, charger enable/disable, pet
> > > > EUD to indicate software is functional.
> > > >
> > > > Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@xxxxxxxxxxxxxx>
> > > > Signed-off-by: Prakruthi Deepak Heragu <pheragu@xxxxxxxxxxxxxx>
> > > > ---
> > > >  drivers/soc/qcom/Kconfig  |  12 ++
> > > >  drivers/soc/qcom/Makefile |   1 +
> > > >  drivers/soc/qcom/eud.c    | 338 ++++++++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 351 insertions(+)
> > > >  create mode 100644 drivers/soc/qcom/eud.c
> > > >
> > > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> > > [snip]
> > > > +
> > > > +#define EUD_ENABLE_CMD 1
> > > > +#define EUD_DISABLE_CMD 0
> > > 
> > > Why not use module param as boolean? I mean zero to disable and
> > > non-zero to enable?
> > 
> > Never use module parameters on new code, as it's really hard to ever
> > change them.  It also doesn't work for multiple devices of the same
> > type.
> > 
> If not for module_param, do you suggest we use sysfs?

It depends on what you want to control.

> module_param also provides a facility to control these parameters
> through command line too. If we can't use module_param, do you expect
> us to use __setup(..) API?

Again, it depends on what you are wanting to handle here.  module
parameters and setup variables are all "global" in that they affect all
devices of the same type.  sysfs can be "per device" which is almost
always what you want to have happen.

But don't use any of those for things that should be "automatic" in that
the driver should figure out what needs to be done here and not need any
external configuration.  That's the best way of all to handle this.

thanks,

greg k-h



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux