On Fri, 29 Mar 2024 at 17:09, Pavan Holla <pholla@xxxxxxxxxxxx> wrote: > > Hi Dmitry, > > Thanks for the review. > > On Thu, Mar 28, 2024 at 8:32 AM Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > While it's fine to use platform/chrome for platform drivers, please > > place drivers which have a subsystem into the subsystem dir. I think we > > don't want to hunt UCSI implementations all over the codebase. Please > > use drivers/usb/typec/ucsi/ location for your driver. This also removes > > a need for a global header. > > I agree with your assessment that drivers/usb/typec/ucsi/ is a good > location for the driver currently. However, the driver is still in > early stages of development. We may have to account for PDC/ EC quirks > (we have multiple vendors), add FW update functionality outside the > UCSI spec, or add PDC logging functionality. While I'd like to write > separate drivers for those, some of this functionality will need to > acquire a lock over communication to the PDC. Even if I were to write > separate drivers for new functionality related to the PDC, maybe it's > better for all ChromeOS PDC related drivers to reside in the same > location. I am not sure what form this driver will take in the near > future, thus I would prefer to keep it in platform/chrome. Maybe > cros_ec_ucsi isn't the best name here, cros_ec_pdc probably conveys > the intention better. In such a case please consider using auxilliary device bus or MFD cells to describe pdc / ucsi relationship. See how this is handled for pmic-glink / ucsi_glink. The drivers/platform should really be limited to simple drivers, which don't have a better place. Otherwise it becomes a nightmare to handle driver changes (this applies not only to the UCSI but also to other drivers which have their own subsystem tree). -- With best wishes Dmitry
