Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Sun, 2016-08-07 at 23:37 +0200, Pavel Machek wrote: > Hi! > > > > With these boards, you will not see anything on the screen that is > > > attached to a Type-C connector until the OS has booted to the point > > > where it has negotiated the power contract and entered a mode. > > > > > > If

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Thu, 2016-08-04 at 13:44 -0400, Robert Foss wrote: > > On 2016-08-03 06:39 AM, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 10:37 -0400, Robert Foss wrote: > > How can that depend on what we return to user space? > > In the driver we can continue just ignoring errors

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Thu, 2016-08-04 at 13:44 -0400, Robert Foss wrote: > > On 2016-08-03 06:39 AM, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 10:37 -0400, Robert Foss wrote: > > How can that depend on what we return to user space? > > In the driver we can continue just ignoring errors

Re: [PATCH 0984/1285] Replace numeric parameter like 0444 with macro

On Tue, 2016-08-02 at 16:54 +0300, Felipe Balbi wrote: > Baole Ni writes: > > > I find that the developers often just specified the numeric value > > when calling a macro which is defined with a parameter for access > > permission. > > As we know, these numeric value for

Re: [PATCH 0984/1285] Replace numeric parameter like 0444 with macro

On Tue, 2016-08-02 at 16:54 +0300, Felipe Balbi wrote: > Baole Ni writes: > > > I find that the developers often just specified the numeric value > > when calling a macro which is defined with a parameter for access > > permission. > > As we know, these numeric value for access permission have

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Tue, 2016-08-02 at 10:37 -0400, Robert Foss wrote: > > On 2016-08-02 09:59 AM, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 09:54 -0400, Robert Foss wrote: > >> > >> On 2016-08-02 08:23 AM, Oliver Neukum wrote: > >>> On Thu, 2016-07-28 at 14

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Tue, 2016-08-02 at 10:37 -0400, Robert Foss wrote: > > On 2016-08-02 09:59 AM, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 09:54 -0400, Robert Foss wrote: > >> > >> On 2016-08-02 08:23 AM, Oliver Neukum wrote: > >>> On Thu, 2016-07-28 at 14

Re: [RFC PATCH 3/4] usb: typec: USB Type-C Port Manager (tcpm)

On Tue, 2016-08-02 at 13:32 -0700, Guenter Roeck wrote: > +static bool svdm_consume_svids(struct tcpm_port *port, const u32 > *payload, > + int cnt) > +{ > + struct pd_mode_data *pmdata = >mode_data; > + int i; > + > + for (i = 1; i < cnt; i++) { > +

Re: [RFC PATCH 3/4] usb: typec: USB Type-C Port Manager (tcpm)

On Tue, 2016-08-02 at 13:32 -0700, Guenter Roeck wrote: > +static bool svdm_consume_svids(struct tcpm_port *port, const u32 > *payload, > + int cnt) > +{ > + struct pd_mode_data *pmdata = >mode_data; > + int i; > + > + for (i = 1; i < cnt; i++) { > +

Re: [RFC PATCH 3/4] usb: typec: USB Type-C Port Manager (tcpm)

On Tue, 2016-08-02 at 13:32 -0700, Guenter Roeck wrote: > +static int tcpm_set_polarity(struct tcpm_port *port, > +enum typec_cc_polarity polarity) > +{ > + tcpm_log(port, "polarity %d", polarity); > + > + port->polarity = polarity; > + > + return

Re: [RFC PATCH 3/4] usb: typec: USB Type-C Port Manager (tcpm)

On Tue, 2016-08-02 at 13:32 -0700, Guenter Roeck wrote: > +static int tcpm_set_polarity(struct tcpm_port *port, > +enum typec_cc_polarity polarity) > +{ > + tcpm_log(port, "polarity %d", polarity); > + > + port->polarity = polarity; > + > + return

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Tue, 2016-08-02 at 13:34 +0200, Michal Hocko wrote: > On Tue 02-08-16 12:03:23, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote: > > > On Tue 02-08-16 10:06:12, Oliver Neukum wrote: > > > > On Mon, 2016-08-01 at 10:20 -0400, Te

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Tue, 2016-08-02 at 13:34 +0200, Michal Hocko wrote: > On Tue 02-08-16 12:03:23, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote: > > > On Tue 02-08-16 10:06:12, Oliver Neukum wrote: > > > > On Mon, 2016-08-01 at 10:20 -0400, Te

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Thu, 2016-07-28 at 14:19 -0400, robert.f...@collabora.com wrote: > From: Prathmesh Prabhu > > Implemented queued response handling. This queue is processed every > time the > WDM_READ flag is cleared. > > In case of a read error, userspace may not actually read the

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Thu, 2016-07-28 at 14:19 -0400, robert.f...@collabora.com wrote: > From: Prathmesh Prabhu > > Implemented queued response handling. This queue is processed every > time the > WDM_READ flag is cleared. > > In case of a read error, userspace may not actually read the data, > since the > driver

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Tue, 2016-08-02 at 09:54 -0400, Robert Foss wrote: > > On 2016-08-02 08:23 AM, Oliver Neukum wrote: > > On Thu, 2016-07-28 at 14:19 -0400, robert.f...@collabora.com wrote: > >> From: Prathmesh Prabhu <ppra...@chromium.org> > >> > >> Implemented queu

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On Tue, 2016-08-02 at 09:54 -0400, Robert Foss wrote: > > On 2016-08-02 08:23 AM, Oliver Neukum wrote: > > On Thu, 2016-07-28 at 14:19 -0400, robert.f...@collabora.com wrote: > >> From: Prathmesh Prabhu > >> > >> Implemented queued response handling.

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Tue, 2016-08-02 at 14:48 +0200, Michal Hocko wrote: > On Tue 02-08-16 13:44:48, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 13:34 +0200, Michal Hocko wrote: > > > On Tue 02-08-16 12:03:23, Oliver Neukum wrote: > > > > On Tue, 2016-08-02 at 10:18 +0200, Michal Ho

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Tue, 2016-08-02 at 14:48 +0200, Michal Hocko wrote: > On Tue 02-08-16 13:44:48, Oliver Neukum wrote: > > On Tue, 2016-08-02 at 13:34 +0200, Michal Hocko wrote: > > > On Tue 02-08-16 12:03:23, Oliver Neukum wrote: > > > > On Tue, 2016-08-02 at 10:18 +0200, Michal Ho

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote: > On Tue 02-08-16 10:06:12, Oliver Neukum wrote: > > On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote: > > > Hello, > > > > > > If any real IO depends on those devices then this is not sufficient and >

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote: > On Tue 02-08-16 10:06:12, Oliver Neukum wrote: > > On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote: > > > Hello, > > > > > > If any real IO depends on those devices then this is not sufficient and >

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote: > Hello, > > If any real IO depends on those devices then this is not sufficient and > > they need some form of guarantee for progress (aka mempool). > > Oliver, Alan, what do you think? If USB itself can't operate without > allocating memory

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote: > Hello, > > If any real IO depends on those devices then this is not sufficient and > > they need some form of guarantee for progress (aka mempool). > > Oliver, Alan, what do you think? If USB itself can't operate without > allocating memory

Re: [PATCH v2 10/22] usb: serial: ti_usb_3410_5052: Change ti_write_byte function arguments

On Wed, 2016-07-27 at 18:08 +0200, Mathieu OTHACEHE wrote: > Hi, > > > this makes me think something is wrong with the data structure. > > We should have a be32 there, it seems to me. > > You mean something like : > > struct ti_write_data_bytes { > u8 bAddrType; > u8

Re: [PATCH v2 10/22] usb: serial: ti_usb_3410_5052: Change ti_write_byte function arguments

On Wed, 2016-07-27 at 18:08 +0200, Mathieu OTHACEHE wrote: > Hi, > > > this makes me think something is wrong with the data structure. > > We should have a be32 there, it seems to me. > > You mean something like : > > struct ti_write_data_bytes { > u8 bAddrType; > u8

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Wed, 2016-07-27 at 14:50 +0530, Bhaktipriya Shridhar wrote: > The workqueue "workqueue" has multiple workitems which may require > ordering. Hence, a dedicated ordered workqueue has been used. > Since the workqueue is not being used on a memory reclaim path, > WQ_MEM_RECLAIM has not been set.

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Wed, 2016-07-27 at 14:50 +0530, Bhaktipriya Shridhar wrote: > The workqueue "workqueue" has multiple workitems which may require > ordering. Hence, a dedicated ordered workqueue has been used. > Since the workqueue is not being used on a memory reclaim path, > WQ_MEM_RECLAIM has not been set.

Re: [PATCH v2 1/2] usb: typec: Add USB Power Delivery sink port support

On Tue, 2016-07-26 at 11:37 -0700, Bin Gao wrote: > +#define MAKE_HEADER(port, header, msg, objs) \ > +do { \ > + header->type = msg; \ > + header->data_role = PD_DATA_ROLE_UFP; \ > + header->revision = port->pd_rev; \ > + header->power_role = PD_POWER_ROLE_SINK; \ > +

Re: [PATCH v2 1/2] usb: typec: Add USB Power Delivery sink port support

On Tue, 2016-07-26 at 11:37 -0700, Bin Gao wrote: > +#define MAKE_HEADER(port, header, msg, objs) \ > +do { \ > + header->type = msg; \ > + header->data_role = PD_DATA_ROLE_UFP; \ > + header->revision = port->pd_rev; \ > + header->power_role = PD_POWER_ROLE_SINK; \ > +

Re: [PATCH v2 10/22] usb: serial: ti_usb_3410_5052: Change ti_write_byte function arguments

On Tue, 2016-07-26 at 19:59 +0200, Mathieu OTHACEHE wrote: > @@ -1626,7 +1624,7 @@ static int ti_write_byte(struct usb_serial_port > *port, > data->bAddrType = TI_RW_DATA_ADDR_XDATA; > data->bDataType = TI_RW_DATA_BYTE; > data->bDataCounter = 1; > - data->wBaseAddrHi

Re: [PATCH v2 10/22] usb: serial: ti_usb_3410_5052: Change ti_write_byte function arguments

On Tue, 2016-07-26 at 19:59 +0200, Mathieu OTHACEHE wrote: > @@ -1626,7 +1624,7 @@ static int ti_write_byte(struct usb_serial_port > *port, > data->bAddrType = TI_RW_DATA_ADDR_XDATA; > data->bDataType = TI_RW_DATA_BYTE; > data->bDataCounter = 1; > - data->wBaseAddrHi

Re: [PATCH v2 03/22] usb: serial: ti_usb_3410_5052: Use kzalloc instead of kmalloc

On Tue, 2016-07-26 at 19:59 +0200, Mathieu OTHACEHE wrote: > Use kzalloc instead of kmalloc to avoid field initialisation to 0. > > Signed-off-by: Mathieu OTHACEHE > --- > drivers/usb/serial/ti_usb_3410_5052.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [PATCH v2 03/22] usb: serial: ti_usb_3410_5052: Use kzalloc instead of kmalloc

On Tue, 2016-07-26 at 19:59 +0200, Mathieu OTHACEHE wrote: > Use kzalloc instead of kmalloc to avoid field initialisation to 0. > > Signed-off-by: Mathieu OTHACEHE > --- > drivers/usb/serial/ti_usb_3410_5052.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

> MAC, > the correct operational state and I can receive/sent traffic without > problems. I also tested with some other cdc_ether devices I have and > did > not find any problems/regressions caused by the two general changes. > > v2->v3: > * I had forgot to remove the

Re: [PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

> MAC, > the correct operational state and I can receive/sent traffic without > problems. I also tested with some other cdc_ether devices I have and > did > not find any problems/regressions caused by the two general changes. > > v2->v3: > * I had forgot to remove the

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Tue, 2016-07-19 at 08:40 +0200, Kristian Evensen wrote: > On Tue, Jul 19, 2016 at 8:20 AM, Oliver Neukum <oneu...@suse.com> wrote: > >> I had a look at some other drivers, and I think we need to be very > >> careful about making setting a random MAC too generic.

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Tue, 2016-07-19 at 08:40 +0200, Kristian Evensen wrote: > On Tue, Jul 19, 2016 at 8:20 AM, Oliver Neukum wrote: > >> I had a look at some other drivers, and I think we need to be very > >> careful about making setting a random MAC too generic. For example, we > >&

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 17:04 +0200, Kristian Evensen wrote: > On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum <oneu...@suse.com> wrote: > >> Ok, sounds good. So far, I have only seen the random MAC issue with > >> the three previously mentioned devices, but who know

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 17:04 +0200, Kristian Evensen wrote: > On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum wrote: > >> Ok, sounds good. So far, I have only seen the random MAC issue with > >> the three previously mentioned devices, but who knows how many else is > &g

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote: > On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum <oneu...@suse.com> wrote: > > No, you misunderstand me. I don't want quirks if we can avoid it. > > But if you need to do this for rndis_host and cdc_ether and maybe

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote: > On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote: > > No, you misunderstand me. I don't want quirks if we can avoid it. > > But if you need to do this for rndis_host and cdc_ether and maybe other > &g

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 15:23 +0200, Kristian Evensen wrote: > Hi, > > On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum <oneu...@suse.com> wrote: > > On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote: > >> The firmware in the ZTE MF823/831/910 mode

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 15:23 +0200, Kristian Evensen wrote: > Hi, > > On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum wrote: > > On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote: > >> The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to &

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote: > The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to > determine which type of device to export. In addition, these devices export > a REST API which can also be used to control the type of device. So far, on >

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote: > The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to > determine which type of device to export. In addition, these devices export > a REST API which can also be used to control the type of device. So far, on >

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Fri, 2016-07-15 at 10:25 +0300, Felipe Balbi wrote: > > +int pd_sink_queue_msg(struct pd_sink_msg *msg) > > +{ > > + unsigned long flags; > > + struct pd_sink_port *port; > > + > > + if (msg->port < 0 || msg->port >= MAX_NR_SINK_PORTS) { > > + pr_err("Invalid port

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Fri, 2016-07-15 at 10:25 +0300, Felipe Balbi wrote: > > +int pd_sink_queue_msg(struct pd_sink_msg *msg) > > +{ > > + unsigned long flags; > > + struct pd_sink_port *port; > > + > > + if (msg->port < 0 || msg->port >= MAX_NR_SINK_PORTS) { > > + pr_err("Invalid port

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Thu, 2016-07-14 at 19:14 -0700, Bin Gao wrote: > This patch implements a simple USB Power Delivery sink port state machine. > It assumes the hardware only handles PD packet transmitting and receiving > over the CC line of the USB Type-C connector. The state transition is > completely controlled

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Thu, 2016-07-14 at 19:14 -0700, Bin Gao wrote: > This patch implements a simple USB Power Delivery sink port state machine. > It assumes the hardware only handles PD packet transmitting and receiving > over the CC line of the USB Type-C connector. The state transition is > completely controlled

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-29 at 14:27 +0300, Heikki Krogerus wrote: > About the end user of the interface, I think Oliver knows more about > that. But I would imagine that the use cases will be something like, > for example, on systems that need prefer sertain roles, perhaps Host > for example on some

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-29 at 14:27 +0300, Heikki Krogerus wrote: > About the end user of the interface, I think Oliver knows more about > that. But I would imagine that the use cases will be something like, > for example, on systems that need prefer sertain roles, perhaps Host > for example on some

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote: > No it's not. DRP means a port that can operate as _either_ Source > (host) or Sink (device), but not at the same time.. Yes, but it is unclear what you will

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote: > No it's not. DRP means a port that can operate as _either_ Source > (host) or Sink (device), but not at the same time.. Yes, but it is unclear what you will

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 17:38 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 03:47:03PM +0200, Oliver Neukum wrote: > > On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote: > > > If our port is DRD (which would be DRP in the port controller spec), > > >

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 17:38 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 03:47:03PM +0200, Oliver Neukum wrote: > > On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote: > > > If our port is DRD (which would be DRP in the port controller spec), > > >

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote: > If our port is DRD (which would be DRP in the port controller spec), > the supported_power_roles will list: > > device, host > > And the power role, if the port is Source only, the > supported_power_roles will list: > >

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote: > If our port is DRD (which would be DRP in the port controller spec), > the supported_power_roles will list: > > device, host > > And the power role, if the port is Source only, the > supported_power_roles will list: > >

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 13:03 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 12:50:16PM +0300, Heikki Krogerus wrote: > > > But if the port is DRP, we will always be able to swap the data role > > between DFP and UFP. > > Just to clarify: DRP as it's defined in Type-C spec < 1.2 means

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 13:03 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 12:50:16PM +0300, Heikki Krogerus wrote: > > > But if the port is DRP, we will always be able to swap the data role > > between DFP and UFP. > > Just to clarify: DRP as it's defined in Type-C spec < 1.2 means

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 12:50 +0300, Heikki Krogerus wrote: > On Tue, Jun 21, 2016 at 10:25:05PM +0200, Oliver Neukum wrote: > > On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote: > > > +What: /sys/class/typec//supported_data_roles > > > +Data:

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 12:50 +0300, Heikki Krogerus wrote: > On Tue, Jun 21, 2016 at 10:25:05PM +0200, Oliver Neukum wrote: > > On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote: > > > +What: /sys/class/typec//supported_data_roles > > > +Data:

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-22 at 12:31 +0300, Heikki Krogerus wrote: Hi, > > Now correct me, if I am misreading the spec. I am sure the system > > will boot unless it needs ridiculous amounts of power, but > > will we see anything on the screen? As far as I can tell the spec > > actually says that you

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-22 at 12:31 +0300, Heikki Krogerus wrote: Hi, > > Now correct me, if I am misreading the spec. I am sure the system > > will boot unless it needs ridiculous amounts of power, but > > will we see anything on the screen? As far as I can tell the spec > > actually says that you

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote: > On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote: > > > The firmware will surely want to display something. So it is possible > > that we start the OS will a valid power contract. How do we deal > >

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote: > On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote: > > > The firmware will surely want to display something. So it is possible > > that we start the OS will a valid power contract. How do we deal > >

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote: > +What: /sys/class/typec//supported_data_roles > +Data: June 2016 > +Contact: Heikki Krogerus > +Description: > + Lists the USB data roles, host or device, the port is

Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote: > +What: /sys/class/typec//supported_data_roles > +Data: June 2016 > +Contact: Heikki Krogerus > +Description: > + Lists the USB data roles, host or device, the port is > capable > + of

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-06-21 at 06:24 -0700, Guenter Roeck wrote: > On 06/21/2016 06:08 AM, Oliver Neukum wrote: > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > >> The purpose of this class is to provide unified interface for user > >> space to get the status and

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-06-21 at 06:24 -0700, Guenter Roeck wrote: > On 06/21/2016 06:08 AM, Oliver Neukum wrote: > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > >> The purpose of this class is to provide unified interface for user > >> space to get the status and

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > The purpose of this class is to provide unified interface for user > space to get the status and basic information about USB Type-C > Connectors in the system, control data role swapping, and when USB PD > is available, also power role

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > The purpose of this class is to provide unified interface for user > space to get the status and basic information about USB Type-C > Connectors in the system, control data role swapping, and when USB PD > is available, also power role

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

On Tue, 2016-06-14 at 13:20 +0200, Martin Kepplinger wrote: > * Fix usb_autopm calls to be balanced > * In reset_resume() we need to set the device mode > * In suspend() we must cancel the workqueue's work > > Signed-off-by: Martin Kepplinger Looks good to me.

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

On Tue, 2016-06-14 at 13:20 +0200, Martin Kepplinger wrote: > * Fix usb_autopm calls to be balanced > * In reset_resume() we need to set the device mode > * In suspend() we must cancel the workqueue's work > > Signed-off-by: Martin Kepplinger Looks good to me. Regards

Re: [PATCH] input: tablet: pegasus_notetaker: USB PM fixes

On Mon, 2016-06-13 at 15:31 +0200, Martin Kepplinger wrote: > In close() we only need usb_autopm_put_interface(), in reset_resume() Sorry, that is a misunderstanding. You need not carry about power management in close() at all. But it must be balanced of course. Regards

Re: [PATCH] input: tablet: pegasus_notetaker: USB PM fixes

On Mon, 2016-06-13 at 15:31 +0200, Martin Kepplinger wrote: > In close() we only need usb_autopm_put_interface(), in reset_resume() Sorry, that is a misunderstanding. You need not carry about power management in close() at all. But it must be balanced of course. Regards

Re: [RFC PATCHv3] usb: USB Type-C Connector Class

On Fri, 2016-06-10 at 17:34 +0300, Heikki Krogerus wrote: > +static ssize_t > +preferred_role_store(struct device *dev, struct device_attribute > *attr, > +const char *buf, size_t size) > +{ > + struct typec_port *port = to_typec_port(dev); > + enum typec_role role;

Re: [RFC PATCHv3] usb: USB Type-C Connector Class

On Fri, 2016-06-10 at 17:34 +0300, Heikki Krogerus wrote: > +static ssize_t > +preferred_role_store(struct device *dev, struct device_attribute > *attr, > +const char *buf, size_t size) > +{ > + struct typec_port *port = to_typec_port(dev); > + enum typec_role role;

Re: [PATCH v7] input: tablet: add Pegasus Notetaker tablet driver

On Fri, 2016-06-10 at 15:27 +0200, Martin Kepplinger wrote: > >> +input_set_abs_params(input_dev, ABS_X, -1500, 1500, 8, 0); > >> +input_set_abs_params(input_dev, ABS_Y, 1600, 3000, 8, 0); > >> + > >> +pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE); > > > > If you need to

Re: [PATCH v7] input: tablet: add Pegasus Notetaker tablet driver

On Fri, 2016-06-10 at 15:27 +0200, Martin Kepplinger wrote: > >> +input_set_abs_params(input_dev, ABS_X, -1500, 1500, 8, 0); > >> +input_set_abs_params(input_dev, ABS_Y, 1600, 3000, 8, 0); > >> + > >> +pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE); > > > > If you need to

Re: [PATCH v7] input: tablet: add Pegasus Notetaker tablet driver

On Wed, 2016-06-01 at 14:55 +0200, Martin Kepplinger wrote: > It's *really* fun to use as an input tablet though! So let's support this > for everybody. Nice job, but a few issues are left. I'll comment in the code. > +static void pegasus_close(struct input_dev *dev) > +{ > + struct

Re: [PATCH v7] input: tablet: add Pegasus Notetaker tablet driver

On Wed, 2016-06-01 at 14:55 +0200, Martin Kepplinger wrote: > It's *really* fun to use as an input tablet though! So let's support this > for everybody. Nice job, but a few issues are left. I'll comment in the code. > +static void pegasus_close(struct input_dev *dev) > +{ > + struct

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote: > I would prefer lower case letters. I don't know the SIDs there are at > them moment, other then Display Port. Do you know them? > > I don't think we can ever guarantee that in every case we will be able > to provide a human readable

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote: > I would prefer lower case letters. I don't know the SIDs there are at > them moment, other then Display Port. Do you know them? > > I don't think we can ever guarantee that in every case we will be able > to provide a human readable

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote: > On 06/01/2016 11:24 PM, Oliver Neukum wrote: > > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote: > >> The class code would not explicitly learn about the reset, > >> but it would be informed about the exi

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote: > On 06/01/2016 11:24 PM, Oliver Neukum wrote: > > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote: > >> The class code would not explicitly learn about the reset, > >> but it would be informed about the exi

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote: > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote: > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > > Just noticed that the "active" file is for now read only, but it needs >

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote: > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote: > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > > Just noticed that the "active" file is for now read only, but it needs >

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote: > The class code would not explicitly learn about the reset, > but it would be informed about the exited modes. That has drawbacks - it doesn't tell you what caused the mode to be left (if you UFP, it may be the regular command) - it is a

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote: > The class code would not explicitly learn about the reset, > but it would be informed about the exited modes. That has drawbacks - it doesn't tell you what caused the mode to be left (if you UFP, it may be the regular command) - it is a

Re: [PATCH] usb: microtek: Use "foo *bar" instead of "foo * bar".

On Wed, 2016-06-01 at 08:48 -0400, Sandhya Bankar wrote: > Use "foo *bar" instead of "foo * bar". > > Signed-off-by: Sandhya Bankar <bankarsandhya...@gmail.com> Acked-by: Oliver Neukum <oneu...@suse.com> > --- > drivers/usb/image/microtek.h |

Re: [PATCH] usb: microtek: Use "foo *bar" instead of "foo * bar".

On Wed, 2016-06-01 at 08:48 -0400, Sandhya Bankar wrote: > Use "foo *bar" instead of "foo * bar". > > Signed-off-by: Sandhya Bankar Acked-by: Oliver Neukum > --- > drivers/usb/image/microtek.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > Just noticed that the "active" file is for now read only, but it needs > to be changed to writable. That file will of course provide means for > the userspace to Exit and Enter modes. But please note that the > responsibility of the

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > Just noticed that the "active" file is for now read only, but it needs > to be changed to writable. That file will of course provide means for > the userspace to Exit and Enter modes. But please note that the > responsibility of the

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote: > I think we can still add them later if they are still seen as > necessity later on, tough I seriously doubt it. It would not be > ideal, but adding an attribute should not really break anything, > right? Removing would. However, how do

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote: > I think we can still add them later if they are still seen as > necessity later on, tough I seriously doubt it. It would not be > ideal, but adding an attribute should not really break anything, > right? Removing would. However, how do

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

gt; On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote: > > > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote: > > > > > > Hi Oliver, > > > > > > > > > > > > On Mon, May 30, 2016 at 03:59:27PM

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

gt; On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote: > > > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote: > > > > > > Hi Oliver, > > > > > > > > > > > > On Mon, May 30, 2016 at 03:59:27PM

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote: > Hi Oliver, > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote: > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote: > > > Hi guys, > > > > > > I'm attaching a d

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote: > Hi Oliver, > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote: > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote: > > > Hi guys, > > > > > > I'm attaching a d

Re: PROBLEM: Kernel Bug on USB unplugging (Elo TouchSystems CarrollTouch 4500U)

93673bd350 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneu...@suse.com> Date: Tue, 31 May 2016 10:08:47 +0200 Subject: [PATCH] hid-elo: kill not flush the work Flushing a work that reschedules itself is not a sensible operation. It needs to be killed. Signed-off-by: Oliver Neukum <oneu.

<    1   2   3   4   5   6   7   8   9   10   >