On Thu, Feb 18, 2016 at 4:17 PM, Heikki Krogerus
wrote:
> On Thu, Feb 18, 2016 at 04:07:54PM +0530, Rajaram R wrote:
>> On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
>> wrote:
>> > On Wed, Feb 17, 2016 at 03:36:46PM +0200,
On Thu, Feb 18, 2016 at 4:17 PM, Heikki Krogerus
wrote:
> On Thu, Feb 18, 2016 at 04:07:54PM +0530, Rajaram R wrote:
>> On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
>> wrote:
>> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
>> >>
>> >> Hi,
>> >>
>> >> Heikki Krogerus
On Thu, Feb 18, 2016 at 04:07:54PM +0530, Rajaram R wrote:
> On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
> wrote:
> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Heikki Krogerus
On Thu, Feb 18, 2016 at 04:07:54PM +0530, Rajaram R wrote:
> On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
> wrote:
> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Heikki Krogerus writes:
> >> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum
Hi Peter,
On Thu, Feb 18, 2016 at 05:07:04PM +0800, Peter Chen wrote:
> On Wed, Feb 17, 2016 at 04:28:16PM +0200, Heikki Krogerus wrote:
> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> > > IIRC mode and role negotiation goes via CC pins using the power delivery
> > > protocol.
Hi Peter,
On Thu, Feb 18, 2016 at 05:07:04PM +0800, Peter Chen wrote:
> On Wed, Feb 17, 2016 at 04:28:16PM +0200, Heikki Krogerus wrote:
> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> > > IIRC mode and role negotiation goes via CC pins using the power delivery
> > > protocol.
On Thu, 2016-02-18 at 12:30 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum writes:
> >> > What exactly are you sure about about?
> >>
> >> heh, missed a NOT there :-)
> >
> > I am still confused :-)
> > Do you think a sysfs interface is good, bad or good
> > but
On Thu, 2016-02-18 at 12:30 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum writes:
> >> > What exactly are you sure about about?
> >>
> >> heh, missed a NOT there :-)
> >
> > I am still confused :-)
> > Do you think a sysfs interface is good, bad or good
> > but insufficient?
>
> I'm not
On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
wrote:
> On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Heikki Krogerus writes:
>> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
>>
On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
wrote:
> On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Heikki Krogerus writes:
>> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
>> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
>> >> >
Hi,
Oliver Neukum writes:
>> > What exactly are you sure about about?
>>
>> heh, missed a NOT there :-)
>
> I am still confused :-)
> Do you think a sysfs interface is good, bad or good
> but insufficient?
I'm not sure it's the best interface. My fear is that as new
Hi,
Oliver Neukum writes:
>> > What exactly are you sure about about?
>>
>> heh, missed a NOT there :-)
>
> I am still confused :-)
> Do you think a sysfs interface is good, bad or good
> but insufficient?
I'm not sure it's the best interface. My fear is that as new
requirements/features come
On Thu, 2016-02-18 at 09:08 +0200, Felipe Balbi wrote:
> Oliver Neukum writes:
> >> Oliver Neukum writes:
Hi,
> > What exactly are you sure about about?
>
> heh, missed a NOT there :-)
I am still confused :-)
Do you think a sysfs interface is good, bad or
On Thu, 2016-02-18 at 09:08 +0200, Felipe Balbi wrote:
> Oliver Neukum writes:
> >> Oliver Neukum writes:
Hi,
> > What exactly are you sure about about?
>
> heh, missed a NOT there :-)
I am still confused :-)
Do you think a sysfs interface is good, bad or good
but insufficient?
> >> that,
On Thu, 2016-02-18 at 17:29 +0800, Peter Chen wrote:
> Does this UCSI spec has some similar things with USB Type-C Port
> Controller Interface Spec at usb.org? If not, how to co-work
> together in future?
USB Type-C Port Controller Interface Spec:
What can a type C connector do?
UCSI spec:
On Thu, 2016-02-18 at 17:29 +0800, Peter Chen wrote:
> Does this UCSI spec has some similar things with USB Type-C Port
> Controller Interface Spec at usb.org? If not, how to co-work
> together in future?
USB Type-C Port Controller Interface Spec:
What can a type C connector do?
UCSI spec:
On Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> > On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > > USB Type-C Connector System Software Interface (UCSI) is a
> > > specification that defines
On Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> > On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > > USB Type-C Connector System Software Interface (UCSI) is a
> > > specification that defines
On Wed, Feb 17, 2016 at 04:28:16PM +0200, Heikki Krogerus wrote:
> On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> >
> > Hi,
> >
>
> > IIRC mode and role negotiation goes via CC pins using the power delivery
> > protocol. If I misunderstand anything, let me know.
>
> The data
On Wed, Feb 17, 2016 at 04:28:16PM +0200, Heikki Krogerus wrote:
> On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> >
> > Hi,
> >
>
> > IIRC mode and role negotiation goes via CC pins using the power delivery
> > protocol. If I misunderstand anything, let me know.
>
> The data
Hi,
Oliver Neukum writes:
>> Oliver Neukum writes:
>> >> > The API to user space. That is the point. We cannot break user space.
>> >> > Once this sysfs API is upstream we are stuck with it.
>> >>
>> >> yeah, in fact I have been wondering if sysfs is the
Hi,
Oliver Neukum writes:
>> Oliver Neukum writes:
>> >> > The API to user space. That is the point. We cannot break user space.
>> >> > Once this sysfs API is upstream we are stuck with it.
>> >>
>> >> yeah, in fact I have been wondering if sysfs is the best interface to
>> >
>> > That is
On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Heikki Krogerus writes:
> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> >> > Hi,
> >> >
> >> > Oliver
On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Heikki Krogerus writes:
> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> >> > Hi,
> >> >
> >> > Oliver Neukum writes:
> >> > > On Wed,
On Wed, 2016-02-17 at 15:34 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum writes:
> >> > The API to user space. That is the point. We cannot break user space.
> >> > Once this sysfs API is upstream we are stuck with it.
> >>
> >> yeah, in fact I have been wondering if
On Wed, 2016-02-17 at 15:34 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum writes:
> >> > The API to user space. That is the point. We cannot break user space.
> >> > Once this sysfs API is upstream we are stuck with it.
> >>
> >> yeah, in fact I have been wondering if sysfs is the best
Hi,
Heikki Krogerus writes:
> On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
>> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
>> > Hi,
>> >
>> > Oliver Neukum writes:
>> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki
Hi,
Heikki Krogerus writes:
> On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
>> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
>> > Hi,
>> >
>> > Oliver Neukum writes:
>> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
>> > >> On Tue, Feb 16, 2016 at
Hi,
Oliver Neukum writes:
>> > The API to user space. That is the point. We cannot break user space.
>> > Once this sysfs API is upstream we are stuck with it.
>>
>> yeah, in fact I have been wondering if sysfs is the best interface to
>
> That is the discussion we must have.
Hi,
Oliver Neukum writes:
>> > The API to user space. That is the point. We cannot break user space.
>> > Once this sysfs API is upstream we are stuck with it.
>>
>> yeah, in fact I have been wondering if sysfs is the best interface to
>
> That is the discussion we must have.
>
>> userspace. I
On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> > Hi,
> >
> > Oliver Neukum writes:
> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver
On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> > Hi,
> >
> > Oliver Neukum writes:
> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
>
>
On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum writes:
> > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> >> > Yes, but we need an API. We can't keep adding to it.
On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum writes:
> > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> >> > Yes, but we need an API. We can't keep adding to it. So if that
> >> >
Hi,
Oliver Neukum writes:
> On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
>> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
>> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
>> > > > That question has not been answered. It would be
Hi,
Oliver Neukum writes:
> On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
>> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
>> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
>> > > > That question has not been answered. It would be awkward for the OS
>>
On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > > That question has not been answered. It would be awkward for the OS
> > > > to find itself in the slave
On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > > That question has not been answered. It would be awkward for the OS
> > > > to find itself in the slave
On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > That question has not been answered. It would be awkward for the OS
> > > to find itself in the slave role, which it is ill equipped for. So
> > > the data role should
On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > That question has not been answered. It would be awkward for the OS
> > > to find itself in the slave role, which it is ill equipped for. So
> > > the data role should
On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > That question has not been answered. It would be awkward for the OS
> > to find itself in the slave role, which it is ill equipped for. So
> > the data role should be switched before the new device is announced
> > to user space. How is
On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > That question has not been answered. It would be awkward for the OS
> > to find itself in the slave role, which it is ill equipped for. So
> > the data role should be switched before the new device is announced
> > to user space. How is
Hi,
On Mon, Feb 15, 2016 at 04:30:18PM +0100, Oliver Neukum wrote:
> On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> > Because USB Type-C ports (DRP ones) will select the data role randomly
> > when you connect (to an other DRP port). USB Type-C spec defines that
> > you can "prefer"
Hi,
On Mon, Feb 15, 2016 at 04:30:18PM +0100, Oliver Neukum wrote:
> On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> > Because USB Type-C ports (DRP ones) will select the data role randomly
> > when you connect (to an other DRP port). USB Type-C spec defines that
> > you can "prefer"
On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> Because USB Type-C ports (DRP ones) will select the data role randomly
> when you connect (to an other DRP port). USB Type-C spec defines that
> you can "prefer" host mode, but when both ends prefer host mode, it's
> +-0.
That question
On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> Because USB Type-C ports (DRP ones) will select the data role randomly
> when you connect (to an other DRP port). USB Type-C spec defines that
> you can "prefer" host mode, but when both ends prefer host mode, it's
> +-0.
That question
On Thu, Feb 11, 2016 at 10:13:11AM +0200, Andy Shevchenko wrote:
> -- Forwarded message --
> From: Andy Shevchenko
> Date: Thu, Feb 11, 2016 at 10:10 AM
> Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System
> Software Interface
> To: Oliver Neuk
On Wed, Feb 10, 2016 at 02:04:07PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> > +#define UCSI_CONSTAT_BC_NOT_CHARGING 0
> > +#define UCSI_CONSTAT_BC_NOMINAL_CHARGING 1
> > +#define UCSI_CONSTAT_BC_SLOW_CHARGING 2
> > +#define
Hi Greg,
> > But surely everybody agrees that decision about the policies regarding
> > USB Type-C ports, like which data role to use, do we charge or are we
> > letting the other end charge, etc., belongs to the user?
>
> No, I don't agree. It's still unknown if userspace can react fast
>
Andy Shevchenko writes:
> To me out: sounds out, like printing error and return code, or
> something like that. Here the case is different.
>
> And since we have two full switches it might be hard to have on one
> screen out code and exact goto. See my point now?
No, sorry. Not really.
The
On Wed, Feb 10, 2016 at 5:11 PM, Bjørn Mork wrote:
> Andy Shevchenko writes:
>> On Wed, Feb 10, 2016 at 3:21 PM, Oliver Neukum wrote:
>>> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> +out:
CodingStyle suggests to do a better label naming.
[...]
> Exactly what is
-- Forwarded message --
From: Andy Shevchenko
Date: Thu, Feb 11, 2016 at 10:10 AM
Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System
Software Interface
To: Oliver Neukum
On Wed, Feb 10, 2016 at 5:08 PM, Oliver Neukum wrote:
> On Wed, 2016-02-10 at 16:24 +0
-- Forwarded message --
From: Andy Shevchenko <andy.shevche...@gmail.com>
Date: Thu, Feb 11, 2016 at 10:10 AM
Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System
Software Interface
To: Oliver Neukum <oneu...@suse.de>
On Wed, Feb 10, 2016 at 5:08 PM, O
On Wed, Feb 10, 2016 at 5:11 PM, Bjørn Mork wrote:
> Andy Shevchenko writes:
>> On Wed, Feb 10, 2016 at 3:21 PM, Oliver Neukum wrote:
>>> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> +out:
CodingStyle
Andy Shevchenko writes:
> To me out: sounds out, like printing error and return code, or
> something like that. Here the case is different.
>
> And since we have two full switches it might be hard to have on one
> screen out code and exact goto. See my point now?
No,
On Thu, Feb 11, 2016 at 10:13:11AM +0200, Andy Shevchenko wrote:
> -- Forwarded message --
> From: Andy Shevchenko <andy.shevche...@gmail.com>
> Date: Thu, Feb 11, 2016 at 10:10 AM
> Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System
> Software I
Hi Greg,
> > But surely everybody agrees that decision about the policies regarding
> > USB Type-C ports, like which data role to use, do we charge or are we
> > letting the other end charge, etc., belongs to the user?
>
> No, I don't agree. It's still unknown if userspace can react fast
>
On Wed, Feb 10, 2016 at 02:04:07PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> > +#define UCSI_CONSTAT_BC_NOT_CHARGING 0
> > +#define UCSI_CONSTAT_BC_NOMINAL_CHARGING 1
> > +#define UCSI_CONSTAT_BC_SLOW_CHARGING 2
> > +#define
On Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> > On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > > USB Type-C Connector System Software Interface (UCSI) is a
> > > specification that defines
Andy Shevchenko writes:
> On Wed, Feb 10, 2016 at 3:21 PM, Oliver Neukum wrote:
>> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>>> > +out:
>>>
>>> CodingStyle suggests to do a better label naming.
>>
>> Names coming from specs are what they are. There is
>> no place for coding
On Wed, 2016-02-10 at 16:24 +0200, Andy Shevchenko wrote:
> On Wed, Feb 10, 2016 at 4:15 PM, Oliver Neukum wrote:
> > On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> >> > +err:
> >> > + if (i > 0)
> >> > + for (; i >= 0; i--, con--)
> >> > +
On Wed, Feb 10, 2016 at 4:15 PM, Oliver Neukum wrote:
> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>> > +err:
>> > + if (i > 0)
>> > + for (; i >= 0; i--, con--)
>> > + typec_unregister_port(con->port);
>>
>> Perhaps
>>
>> while (--i >= 0)
On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> > +err:
> > + if (i > 0)
> > + for (; i >= 0; i--, con--)
> > + typec_unregister_port(con->port);
>
> Perhaps
>
> while (--i >= 0) {
> ...
> }
While we are at it. No we should not change the
On Wed, Feb 10, 2016 at 3:21 PM, Oliver Neukum wrote:
> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>> > +out:
>>
>> CodingStyle suggests to do a better label naming.
>
> Names coming from specs are what they are. There is
> no place for coding style here.
Yes, and how is it
On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> > +out:
>
> CodingStyle suggests to do a better label naming.
Names coming from specs are what they are. There is
no place for coding style here.
Regards
Oliver
On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> +#define UCSI_CONSTAT_BC_NOT_CHARGING 0
> +#define UCSI_CONSTAT_BC_NOMINAL_CHARGING 1
> +#define UCSI_CONSTAT_BC_SLOW_CHARGING 2
> +#define UCSI_CONSTAT_BC_TRICLE_CHARGING3
typo. It is spelled
On Wed, Feb 10, 2016 at 12:19:53PM +0100, Oliver Neukum wrote:
>
> > +static int ucsi_run_cmd(struct ucsi *ucsi, void *data, size_t size)
> > +{
> > + int status;
> > + int ret;
> > +
> > + dev_vdbg(ucsi->dev, "%s control 0x%llx\n", __func__,
> > +ucsi->ppm->data->control);
> >
On Tue, Feb 9, 2016 at 7:01 PM, Heikki Krogerus
wrote:
> USB Type-C Connector System Software Interface (UCSI) is a
> specification that defines registers and data structures
> used to interface with the USB Type-C connectors on a system.
>
> The specification is public and available at:
>
> +static int ucsi_run_cmd(struct ucsi *ucsi, void *data, size_t size)
> +{
> + int status;
> + int ret;
> +
> + dev_vdbg(ucsi->dev, "%s control 0x%llx\n", __func__,
> + ucsi->ppm->data->control);
> +
> + ret = ucsi->ppm->cmd(ucsi->ppm);
> + if (ret)
> +
On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > USB Type-C Connector System Software Interface (UCSI) is a
> > specification that defines registers and data structures
> > used to interface with the USB Type-C
On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> > +err:
> > + if (i > 0)
> > + for (; i >= 0; i--, con--)
> > + typec_unregister_port(con->port);
>
> Perhaps
>
> while (--i >= 0) {
> ...
> }
While we are at it. No we should not change the
On Wed, Feb 10, 2016 at 4:15 PM, Oliver Neukum wrote:
> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>> > +err:
>> > + if (i > 0)
>> > + for (; i >= 0; i--, con--)
>> > + typec_unregister_port(con->port);
>>
>> Perhaps
>>
>>
On Wed, Feb 10, 2016 at 3:21 PM, Oliver Neukum wrote:
> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>> > +out:
>>
>> CodingStyle suggests to do a better label naming.
>
> Names coming from specs are what they are. There is
> no place for coding style here.
Yes,
On Wed, 2016-02-10 at 16:24 +0200, Andy Shevchenko wrote:
> On Wed, Feb 10, 2016 at 4:15 PM, Oliver Neukum wrote:
> > On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> >> > +err:
> >> > + if (i > 0)
> >> > + for (; i >= 0; i--, con--)
> >> > +
Andy Shevchenko writes:
> On Wed, Feb 10, 2016 at 3:21 PM, Oliver Neukum wrote:
>> On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>>> > +out:
>>>
>>> CodingStyle suggests to do a better label naming.
>>
>> Names coming from specs are what
On Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> > On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > > USB Type-C Connector System Software Interface (UCSI) is a
> > > specification that defines
> +static int ucsi_run_cmd(struct ucsi *ucsi, void *data, size_t size)
> +{
> + int status;
> + int ret;
> +
> + dev_vdbg(ucsi->dev, "%s control 0x%llx\n", __func__,
> + ucsi->ppm->data->control);
> +
> + ret = ucsi->ppm->cmd(ucsi->ppm);
> + if (ret)
> +
On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > USB Type-C Connector System Software Interface (UCSI) is a
> > specification that defines registers and data structures
> > used to interface with the USB Type-C
On Tue, Feb 9, 2016 at 7:01 PM, Heikki Krogerus
wrote:
> USB Type-C Connector System Software Interface (UCSI) is a
> specification that defines registers and data structures
> used to interface with the USB Type-C connectors on a system.
>
> The specification is
On Wed, Feb 10, 2016 at 12:19:53PM +0100, Oliver Neukum wrote:
>
> > +static int ucsi_run_cmd(struct ucsi *ucsi, void *data, size_t size)
> > +{
> > + int status;
> > + int ret;
> > +
> > + dev_vdbg(ucsi->dev, "%s control 0x%llx\n", __func__,
> > +ucsi->ppm->data->control);
> >
On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> +#define UCSI_CONSTAT_BC_NOT_CHARGING 0
> +#define UCSI_CONSTAT_BC_NOMINAL_CHARGING 1
> +#define UCSI_CONSTAT_BC_SLOW_CHARGING 2
> +#define UCSI_CONSTAT_BC_TRICLE_CHARGING3
typo. It is spelled
On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> > +out:
>
> CodingStyle suggests to do a better label naming.
Names coming from specs are what they are. There is
no place for coding style here.
Regards
Oliver
On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> USB Type-C Connector System Software Interface (UCSI) is a
> specification that defines registers and data structures
> used to interface with the USB Type-C connectors on a system.
>
> The specification is public and available
USB Type-C Connector System Software Interface (UCSI) is a
specification that defines registers and data structures
used to interface with the USB Type-C connectors on a system.
The specification is public and available at:
USB Type-C Connector System Software Interface (UCSI) is a
specification that defines registers and data structures
used to interface with the USB Type-C connectors on a system.
The specification is public and available at:
On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> USB Type-C Connector System Software Interface (UCSI) is a
> specification that defines registers and data structures
> used to interface with the USB Type-C connectors on a system.
>
> The specification is public and available
86 matches
Mail list logo