mbox series

[RFC,v2,0/2] usb: typec: Add driver for Microchip sama7g5 tcpc

Message ID 20210330205442.981649-1-cristian.birsan@microchip.com (mailing list archive)
Headers show
Series usb: typec: Add driver for Microchip sama7g5 tcpc | expand

Message

Cristian Birsan March 30, 2021, 8:54 p.m. UTC
From: Cristian Birsan <cristian.birsan@microchip.com>

This patch set adds initial driver support for Microchip USB Type-C Port
Controller (TCPC) embedded in sama7g5 SoC.

The controller does not implement power delivery and the driver uses dummy
functions to register the port with TCPM. The current silicon version is
not able to trigger interrupts so the driver will poll for changes on
CC1/CC2 lines.

Support for sink is implemented and tested with an USB device. The plan is
to extend the driver and add source support.

Changes in v2:
- fix DT bindings yamllint warnings/errors
- fix compilation error reported by: kernel test robot <lkp@intel.com>

Cristian Birsan (2):
  dt-bindings: usb: Add DT bindings for Microchip sama7g5 tcpc
  usb: typec: sama7g5_tcpc: add driver for Microchip sama7g5 tcpc

 .../bindings/usb/microchip,sama7g5-tcpc.yaml  |  90 +++
 drivers/usb/typec/tcpm/Kconfig                |   8 +
 drivers/usb/typec/tcpm/Makefile               |   1 +
 drivers/usb/typec/tcpm/sama7g5_tcpc.c         | 610 ++++++++++++++++++
 4 files changed, 709 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/microchip,sama7g5-tcpc.yaml
 create mode 100644 drivers/usb/typec/tcpm/sama7g5_tcpc.c

Comments

Greg Kroah-Hartman March 31, 2021, 6:21 a.m. UTC | #1
On Tue, Mar 30, 2021 at 11:54:40PM +0300, cristian.birsan@microchip.com wrote:
> From: Cristian Birsan <cristian.birsan@microchip.com>
> 
> This patch set adds initial driver support for Microchip USB Type-C Port
> Controller (TCPC) embedded in sama7g5 SoC.
> 
> The controller does not implement power delivery and the driver uses dummy
> functions to register the port with TCPM. The current silicon version is
> not able to trigger interrupts so the driver will poll for changes on
> CC1/CC2 lines.
> 
> Support for sink is implemented and tested with an USB device. The plan is
> to extend the driver and add source support.

Why are these marked "RFC"?

Do you really not think they should be accepted?  Why not, what is left
to do with them?

I do not normally review "RFC" patches as the authors do not think they
should be merged, and we have plenty of patches that are being asked to
be merged already :)

thanks,

greg k-h
Cristian Birsan March 31, 2021, 7:41 p.m. UTC | #2
On 3/31/21 9:21 AM, Greg KH wrote:
> 
> On Tue, Mar 30, 2021 at 11:54:40PM +0300, cristian.birsan@microchip.com wrote:
>> From: Cristian Birsan <cristian.birsan@microchip.com>
>>
>> This patch set adds initial driver support for Microchip USB Type-C Port
>> Controller (TCPC) embedded in sama7g5 SoC.
>>
>> The controller does not implement power delivery and the driver uses dummy
>> functions to register the port with TCPM. The current silicon version is
>> not able to trigger interrupts so the driver will poll for changes on
>> CC1/CC2 lines.
>>
>> Support for sink is implemented and tested with an USB device. The plan is
>> to extend the driver and add source support.
> 
> Why are these marked "RFC"?

I sent the patch as RFC because I wanted to gather feedback on it and on how
it fits under Type-C/TCPM subsystem.

> 
> Do you really not think they should be accepted?  Why not, what is left
> to do with them?
> 

I think the driver can be merged after I address the review received on the
mailing list. At the same time, I plan to enhance it with the following:

- add sink detection at power source and check it with USB Host.

- add a way to notify VBUS presence back to USB gadget.  As TCPC needs to
detect VBUS and report it to TCPM, I moved the VBUS detection gpio from the
USB gadget device tree node to TCPC. For now, the gadget always assumes that
VBUS is on. I saw that some USB PHY drivers use a notifier chain. I can
implement something similar.
  
> I do not normally review "RFC" patches as the authors do not think they
> should be merged, and we have plenty of patches that are being asked to
> be merged already :)

Until now I received a review from Heikki Krogerus. I will let this version
of the patch on the mailing list for some time in case there is additional
feedback.

> 
> thanks,
> 
> greg k-h
> 

Regards,
Cristian