Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

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

 



On Thu, May 25, 2017 at 12:11:53PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 25, 2017 at 11:04:19AM +0300, Heikki Krogerus wrote:
> > On Wed, May 24, 2017 at 08:22:35AM -0700, Guenter Roeck wrote:
> > > On Wed, May 24, 2017 at 05:08:10PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, May 24, 2017 at 03:54:23PM +0300, Heikki Krogerus wrote:
> > > > > Driver for USB Type-C PHY on Intel WhiskeyCove PMIC that
> > > > > works with Type-C Port Controller Manager to provide USB
> > > > > Power Delivery and USB Type-C functionalities
> > > > > 
> > > > > Signed-off-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> > > > > ---
> > > > >  drivers/staging/typec/Kconfig       |  11 +
> > > > >  drivers/staging/typec/Makefile      |   1 +
> > > > >  drivers/staging/typec/typec_wcove.c | 684 ++++++++++++++++++++++++++++++++++++
> > > > >  drivers/usb/typec/Makefile          |   1 -
> > > > >  drivers/usb/typec/typec_wcove.c     | 377 --------------------
> > > > >  5 files changed, 696 insertions(+), 378 deletions(-)
> > > > >  create mode 100644 drivers/staging/typec/typec_wcove.c
> > > > >  delete mode 100644 drivers/usb/typec/typec_wcove.c
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I would like to register also this driver with tcpm, but since tcpm is
> > > > > in staging, can we move the driver to staging like in this patch?
> > > > 
> > > > How about spending the time to get the code out of staging instead?  I
> > > > don't like adding new features to staging drivers, instead, I want to
> > > > see people working to fix what we have before adding new stuff...
> > > > 
> > > Either case I think it should possibly be a different driver: One without
> > > PD support, the other one with PD support.
> > 
> > That works for me. Greg, is that acceptable?
> 
> I don't know, will that just confuse people as we now have two different
> drivers for the same hardware?

Depends. They would be mutually exclusive.

> 
> What is keeping this code in staging at the moment?  Who isn't agreeing
> on the existing apis we have there?
> 

I don't think the APIs are at issue; I would not expect any substantial
(if any) changes going forward. We may have additions such as the pending
port type change support, but will always happen.

>From TODO:
- Add documentation (at the very least for the API to low level drivers)
- Split PD code into separate file
- Check if it makes sense to use tracepoints instead of debugfs for debug logs
- Implement Alternate Mode handling
- Address "#if 0" code if not addressed with the above
- Validate all comments marked with "XXX"; either address or remove comments
- Add support for USB PD 3.0. While not mandatory, at least fast role swap
  as well as authentication support would be very desirable.

Not all of it has to be handled. I would see USB PD 3.0 as optional, for
example. For the rest, we would need an agreement about what is mandatory.
Presumably API documentation, but what else ?

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux