RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

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

 



Hi
> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@xxxxxxxxxxxxxxx]
> Sent: 2018年5月16日 20:25
> To: Jun Li <jun.li@xxxxxxx>; Mats Karrman <mats.dev.list@xxxxxxxxx>
> Cc: robh+dt@xxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux@xxxxxxxxxxxx;
> a.hajda@xxxxxxxxxxx; cw00.choi@xxxxxxxxxxx; shufan_lee@xxxxxxxxxxx;
> Peter Chen <peter.chen@xxxxxxx>; gsomlo@xxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; dl-linux-imx
> <linux-imx@xxxxxxx>
> Subject: Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power
> and data config
> 
> Hi guys,
> 
> On Tue, May 15, 2018 at 10:52:57PM +0200, Mats Karrman wrote:
> > Hi,
> >
> > On 05/14/2018 11:36 AM, Jun Li wrote:
> >
> > > Hi
> > >> -----Original Message-----
> > >> From: Mats Karrman [mailto:mats.dev.list@xxxxxxxxx]
> > >> Sent: 2018???5???12??? 3:56
> > >> To: Jun Li <jun.li@xxxxxxx>; robh+dt@xxxxxxxxxx;
> > >> gregkh@xxxxxxxxxxxxxxxxxxx; heikki.krogerus@xxxxxxxxxxxxxxx;
> > >> linux@xxxxxxxxxxxx
> > >> Cc: a.hajda@xxxxxxxxxxx; cw00.choi@xxxxxxxxxxx;
> > >> shufan_lee@xxxxxxxxxxx; Peter Chen <peter.chen@xxxxxxx>;
> > >> gsomlo@xxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> > >> linux-usb@xxxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>
> > >> Subject: Re: [PATCH v5 05/14] usb: typec: add API to get typec
> > >> basic port power and data config
> > >>
> > >> Hi Li Jun,
> > >>
> > >> On 2018-05-03 02:24, Li Jun wrote:
> > >>
> > >>> This patch adds 3 APIs to get the typec port power and data type,
> > >>> and preferred power role by its name string.
> > >>>
> > >>> Signed-off-by: Li Jun <jun.li@xxxxxxx>
> > >>> ---
> > >>>   drivers/usb/typec/class.c | 52
> > >> +++++++++++++++++++++++++++++++++++++++++++++++
> > >>>   include/linux/usb/typec.h |  3 +++
> > >>>   2 files changed, 55 insertions(+)
> > >>>
> > >>> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> > >>> index 53df10d..5981e18 100644
> > >>> --- a/drivers/usb/typec/class.c
> > >>> +++ b/drivers/usb/typec/class.c
> > >>> @@ -9,6 +9,7 @@
> > >>>   #include <linux/device.h>
> > >>>   #include <linux/module.h>
> > >>>   #include <linux/mutex.h>
> > >>> +#include <linux/property.h>
> 
> I don't think you need that anymore.

I will remove it.

> 
> > >>>   #include <linux/slab.h>
> > >>>   #include <linux/usb/typec.h>
> > >>>   #include <linux/usb/typec_mux.h> @@ -802,6 +803,12 @@ static
> > >>> const char * const typec_port_types[] = {
> > >>>   	[TYPEC_PORT_DRP] = "dual",
> > >>>   };
> > >>>
> > >>> +static const char * const typec_data_types[] = {
> > >>> +	[TYPEC_PORT_DFP] = "host",
> > >>> +	[TYPEC_PORT_UFP] = "device",
> > >>> +	[TYPEC_PORT_DRD] = "dual",
> > >>> +};
> > >>> +
> > >>>   static const char * const typec_port_types_drp[] = {
> > >>>   	[TYPEC_PORT_SRC] = "dual [source] sink",
> > >>>   	[TYPEC_PORT_SNK] = "dual source [sink]", @@ -1252,6 +1259,51
> > >> @@
> > >>> void typec_set_pwr_opmode(struct typec_port *port,
> > >>>   }
> > >>>   EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
> > >>>
> > >>> +/**
> > >>> + * typec_find_power_type - Get the typec port power type
> > >> Why is this function called typec_find_power_type() and not
> > >> typec_find_port_type()?
> > >> It's called port_type in sysfs, having different names just adds confusion.
> > >> (Otherwise I agree power_type is a better name but...)
> > > We have "port type" before the power and data role separation, this
> > > API name's intention is to reflect the power cap, anyway I leave
> > > this to be decided by Heikki then.
> 
> I really hate the "*_type" naming. It was understandable when there was no
> separate power and data roles defined in the specification, but now that there
> are, it's just confusing. IMO we should not use it anywhere.

OK, know your preference now.

> 
> So to me typec_find_type() is just as bad as typec_find_power_type() because it
> has the "type" in it. I wonder if this function is necessary at all? If it is, then
> perhaps we can think of some better name for it, name that gives a better hint
> what it is used for.

We need a way to match a string to a value which has to be done via typec
class.
 
> 
> > >>> + * @name: port type string
> > >>> + *
> > >>> + * This routine is used to find the typec_port_type by its string name.
> > >>> + *
> > >>> + * Returns typec_port_type if success, otherwise negative error code.
> > >>> + */
> > >>> +int typec_find_power_type(const char *name) {
> > >>> +	return match_string(typec_port_types,
> ARRAY_SIZE(typec_port_types),
> > >>> +			    name);
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(typec_find_power_type);
> > >>> +
> > >>> +/**
> > >>> + * typec_find_preferred_role - Find the typec drp port preferred
> > >>> +power role
> > >> Why typec_find_preferred_role()? Could be used for any power_role
> > >> so why not typec_find_power_role()?
> > > I am not sure if I catch your point of this comment.
> > > For preferred role(if support try.sink or try.src) the only allowed
> > > power roles are "sink"
> > > "source"
> > > But for power role, the allowed type are "sink"
> > > "source"
> > > "dual"
> >
> > Uhm, typing too fast again, I am. A better name would be just
> typec_find_role().
> > What I mean is that the function could be used for any situation when
> > someone wants to map a string to a TYPEC_{SOURCE,SINK} constant so it
> > is unnecessary to limit its usage to just preferred role.
> 
> That sounds reasonable to me.

Agreed

thanks
Li Jun
> 
> 
> Thanks,
> 
> --
> heikki
?韬{.n?????%??檩??w?{.n???{炳???骅w*jg????????G??⒏⒎?:+v????????????"??????



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

  Powered by Linux