struct usb_device * (*usb_hub_find_child)(struct usb_device *hdev,
> + int port1);
> +};
> +
> static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
> {
> return hcd->driver->flags & HCD_BH;
> --
> 2.5.0
>
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
+#ifdef CONFIG_USB_OTG
> + /* notify OTG fsm about a_set_b_hnp_enable change */
> + usb_otg_kick_fsm(hcd->otg_dev);
> +#endif
> + }
> }
>
> /* Some low speed devices have problems with the quick delay, so */
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
no otg-controller property
> in DT\n");
> + return -EINVAL;
> + }
> +
> + pdev = of_find_device_by_node(np);
> + of_node_put(np);
> + if (!pdev) {
> + dev_err(parent, "couldn't get otg-controller device\n");
> + return -ENODEV;
> + }
> +
> + gadget->otg_dev = &pdev->dev;
> + } else {
> + gadget->otg_dev = otg_dev;
> + }
The above the code is duplicated with hcd's. Can we do something common
at usb-otg.c, eg define an API get_usb_otg_dev(struct usb_gadget *gadget, struct
usb_hcd *hcd), in this API we can try to get otg_dev for both gadget and
hcd, and we can call it at controller driver during register otg.
--
Best Regards,
Peter Chen
"couldn't get otg-controller device\n");
> + return -ENODEV;
> + }
> +
> + hcd->otg_dev = &pdev->dev;
> + } else {
> + hcd->otg_dev = otg_dev;
> + }
> +
> + return usb_otg_register_hcd(hcd, irqnum, irqflags, &otg_hcd_intf);
> +}
> +EXPORT_SYMBOL_GPL(usb_otg_add_hcd);
> +
--
Best Regards,
Peter Chen
seems like this would make more sense in usb_del_hcd() instead.
> >
>
> OK, I'll move it there.
>
It depends on Alan's comments, whether only usb_add_hcd/usb_del_hcd
pair can be called repeat. If Alan acks it, I have no idea for it.
--
Best Regards,
Peter Chen
On Fri, Apr 15, 2016 at 02:00:46PM +0300, Roger Quadros wrote:
> On 15/04/16 12:25, Peter Chen wrote:
> > On Tue, Apr 05, 2016 at 05:05:12PM +0300, Roger Quadros wrote:
> >> + * usb_otg_register() - Register the OTG/dual-role device to OTG core
> >> + * @dev: OTG/
+ */
> +struct usb_otg_config {
> + struct usb_otg_caps *otg_caps;
> + struct otg_fsm_ops *fsm_ops;
> + void (*otg_work)(struct work_struct *work);
> +};
> +
> extern const char *usb_otg_state_string(enum usb_otg_state state);
>
> +#if IS_ENABLED(CONFIG_USB_OTG)
> +struct usb_otg *usb_otg_register(struct device *dev,
> + struct usb_otg_config *config);
> +int usb_otg_unregister(struct device *dev);
> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
> + unsigned long irqflags, struct otg_hcd_ops *ops);
> +int usb_otg_unregister_hcd(struct usb_hcd *hcd);
> +int usb_otg_register_gadget(struct usb_gadget *gadget,
> + struct otg_gadget_ops *ops);
> +int usb_otg_unregister_gadget(struct usb_gadget *gadget);
> +void usb_otg_sync_inputs(struct usb_otg *otg);
> +int usb_otg_kick_fsm(struct device *otg_dev);
> +int usb_otg_start_host(struct usb_otg *otg, int on);
> +int usb_otg_start_gadget(struct usb_otg *otg, int on);
> +
> +#else /* CONFIG_USB_OTG */
> +
> +static inline struct usb_otg *usb_otg_register(struct device *dev,
> +struct usb_otg_config *config)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> +static inline int usb_otg_unregister(struct device *dev)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int
> irqnum,
> +unsigned long irqflags,
> +struct otg_hcd_ops *ops)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_unregister_hcd(struct usb_hcd *hcd)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_register_gadget(struct usb_gadget *gadget,
> + struct otg_gadget_ops *ops)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_unregister_gadget(struct usb_gadget *gadget)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline void usb_otg_sync_inputs(struct usb_otg *otg)
> +{
> +}
> +
> +static inline int usb_otg_kick_fsm(struct device *otg_dev)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_start_gadget(struct usb_otg *otg, int on)
> +{
> + return -ENOTSUPP;
> +}
> +#endif /* CONFIG_USB_OTG */
> +
> +/*- deprecated interface -*/
> /* Context: can sleep */
> static inline int
> otg_start_hnp(struct usb_otg *otg)
> @@ -113,6 +257,8 @@ otg_start_srp(struct usb_otg *otg)
> return -ENOTSUPP;
> }
>
> +/*---*/
> +
> /* for OTG controller drivers (and maybe other stuff) */
> extern int usb_bus_start_enum(struct usb_bus *bus, unsigned port_num);
>
> @@ -237,4 +383,6 @@ static inline int otg_start_gadget(struct usb_otg *otg,
> int on)
> return otg->fsm.ops->start_gadget(otg, on);
> }
>
> +int drd_statemachine(struct usb_otg *otg);
> +
> #endif /* __LINUX_USB_OTG_H */
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
On Fri, Apr 08, 2016 at 10:16:30AM +0300, Roger Quadros wrote:
> On 08/04/16 04:01, Peter Chen wrote:
> > On Thu, Apr 07, 2016 at 01:40:21PM +0300, Roger Quadros wrote:
> >> On 07/04/16 12:42, Peter Chen wrote:
> >>> On Wed, Apr 06, 2016 at 09:32:22AM +0300, Roger Qua
On Thu, Apr 07, 2016 at 01:40:21PM +0300, Roger Quadros wrote:
> On 07/04/16 12:42, Peter Chen wrote:
> > On Wed, Apr 06, 2016 at 09:32:22AM +0300, Roger Quadros wrote:
> >> On 06/04/16 09:09, Felipe Balbi wrote:
> >>>
> >>> Hi,
> >>>
> &
are at gadget mode, we may not hope the vbus regulator
is still on which is for host only. So, this part may need to implement
by each user.
--
Best Regards,
Peter Chen
struct usb_ep *(*match_ep)(struct usb_gadget *,
+ /* get the charger type */
+ enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
};
struct usb_charger {
...
+ /* user can get charger type by implementing this callback */
+ enum usb_charger_type (*get_charger_type)(struct usb_charger
*);
}
>
> $subject has a fragility, however: It's assuming that we should always
> call ->get_charger_type() before ->vbus_draw(), but that's a good
> default, I'd say.
>
--
Best Regards,
Peter Chen
On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
> >> Peter Chen writes:
> >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
&
On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
> Peter Chen writes:
> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
> >> Peter Chen writes:
> >> > On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote:
> >>
On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
> Peter Chen writes:
> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
> >> Peter Chen writes:
> >> > On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote:
> >>
On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
> Peter Chen writes:
> > On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote:
> > +
> >> +static struct attribute *usb_charger_attrs[] = {
> >> + &dev_attr_sdp_current.att
chger)
> +{
> +}
> +
> +static inline int
> +usb_charger_register_notify(struct usb_charger *uchger,
> + struct notifier_block *nb)
> +{
> + return 0;
> +}
> +
> +static inline int
> +usb_charger_unregister_notify(struct usb_charger *uchger,
> + struct notifier_block *nb)
> +{
> + return 0;
> +}
> +
> +static inline int
> +usb_charger_set_cur_limit(struct usb_charger *uchger,
> + struct usb_charger_cur_limit *cur_limit_set)
> +{
> + return 0;
> +}
> +
> +static inline int
> +usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
> + enum usb_charger_type type,
> + unsigned int cur_limit)
> +{
> + return 0;
> +}
> +
> +static inline unsigned int
> +usb_charger_get_current(struct usb_charger *uchger)
> +{
> + return 0;
> +}
> +
> +static inline enum usb_charger_type
> +usb_charger_get_type(struct usb_charger *uchger)
> +{
> + return UNKNOWN_TYPE;
> +}
> +
> +static inline int usb_charger_detect_type(struct usb_charger *uchger)
> +{
> + return 0;
> +}
> +
> +static inline int
> +usb_charger_plug_by_gadget(struct usb_gadget *gadget, unsigned long state)
> +{
> + return 0;
> +}
> +
> +static inline void devm_usb_charger_unregister(struct device *dev,
> +struct usb_charger *uchger)
> +{
> +}
> +
> +static inline int devm_usb_charger_register(struct device *dev,
> + struct usb_charger *uchger)
> +{
> + return 0;
> +}
> +
> +static inline int usb_charger_init(struct usb_gadget *ugadget)
> +{
> + return 0;
> +}
> +
> +static inline int usb_charger_exit(struct usb_gadget *ugadget)
> +{
> + return 0;
> +}
> +#endif
> +
> +#endif /* __LINUX_USB_CHARGER_H__ */
> diff --git a/include/uapi/linux/usb/charger.h
> b/include/uapi/linux/usb/charger.h
> new file mode 100644
> index 000..3c56ec4
> --- /dev/null
> +++ b/include/uapi/linux/usb/charger.h
> @@ -0,0 +1,31 @@
> +/*
> + * This file defines the USB charger type and state that are needed for
> + * USB device APIs.
> + */
> +
> +#ifndef _UAPI__LINUX_USB_CHARGER_H
> +#define _UAPI__LINUX_USB_CHARGER_H
> +
> +/*
> + * USB charger type:
> + * SDP (Standard Downstream Port)
> + * DCP (Dedicated Charging Port)
> + * CDP (Charging Downstream Port)
> + * ACA (Accessory Charger Adapters)
> + */
> +enum usb_charger_type {
> + UNKNOWN_TYPE,
> + SDP_TYPE,
> + DCP_TYPE,
> + CDP_TYPE,
> + ACA_TYPE,
> +};
> +
> +/* USB charger state */
> +enum usb_charger_state {
> + USB_CHARGER_DEFAULT,
> + USB_CHARGER_PRESENT,
> + USB_CHARGER_REMOVE,
> +};
> +
> +#endif /* _UAPI__LINUX_USB_CHARGER_H */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
design is notify charger IC too,
so you can do set current limit and notify charger IC together at this
API together, it has already covered all situations. We don't need to
notify charger IC again when the gadget status has changed again.
> if (!gadget->ops->vbus_draw)
> return -EOPNOTSUPP;
> return gadget->ops->vbus_draw(gadget, mA);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
On Tue, Apr 05, 2016 at 04:48:19PM +0300, Roger Quadros wrote:
> Peter,
>
> On 05/04/16 15:52, Roger Quadros wrote:
> > Peter,
> >
> > On 05/04/16 11:52, Peter Chen wrote:
> >> On Thu, Mar 31, 2016 at 12:41:19PM +0300, Roger Quadros wrote:
> >>> I
USB device (not only USB controller, it is the whole system), it can
supply more power after set configuration. See 1.4.13 from BC 1.2.
An SDP expects a downstream device with a good battery to draw less than
2.5mA average when unconnected or suspended, up to 100mA maximum when
connected and not configured and not suspended, and up to 500mA maximum
if so configured and not suspended.
--
Best Regards,
Peter Chen
On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote:
> On 5 April 2016 at 16:12, Peter Chen wrote:
> > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> >> Hi Peter,
> >>
> >> On 5 April 2016 at 14:46, Peter Chen wrote:
> >> >
ine VDBG(stuff...) do {} while (0)
> -#endif
> -
> -#ifdef VERBOSE
> -#define MPC_LOC printk("Current Location [%s]:[%d]\n", __FILE__, __LINE__)
> -#else
> -#define MPC_LOC do {} while (0)
> -#endif
> -
> #define PROTO_UNDEF (0)
> #define PROTO_HOST (1)
> #define PROTO_GADGET (2)
> @@ -211,6 +197,9 @@ struct otg_fsm {
> u8 *host_req_flag;
> struct delayed_work hnp_polling_work;
> bool state_changed;
> +
> + /* for debug prints */
> + struct device *dev;
> };
>
> struct otg_fsm_ops {
> --
> 2.5.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> Hi Peter,
>
> On 5 April 2016 at 14:46, Peter Chen wrote:
> >
> > We are thinking USB charger framework for Freescale i.mx SoC series,
> > since our internal framework is not good enough.
> >
api/linux/usb/charger.h
> new file mode 100644
> index 000..3c56ec4
> --- /dev/null
> +++ b/include/uapi/linux/usb/charger.h
> @@ -0,0 +1,31 @@
> +/*
> + * This file defines the USB charger type and state that are needed for
> + * USB device APIs.
> + */
> +
> +#ifndef _UAPI__LINUX_USB_CHARGER_H
> +#define _UAPI__LINUX_USB_CHARGER_H
> +
> +/*
> + * USB charger type:
> + * SDP (Standard Downstream Port)
> + * DCP (Dedicated Charging Port)
> + * CDP (Charging Downstream Port)
> + * ACA (Accessory Charger Adapters)
> + */
> +enum usb_charger_type {
> + UNKNOWN_TYPE,
> + SDP_TYPE,
> + DCP_TYPE,
> + CDP_TYPE,
> + ACA_TYPE,
> +};
> +
> +/* USB charger state */
> +enum usb_charger_state {
> + USB_CHARGER_DEFAULT,
> + USB_CHARGER_PRESENT,
> + USB_CHARGER_REMOVE,
> +};
> +
> +#endif /* _UAPI__LINUX_USB_CHARGER_H */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
the charger type. But for CDP/SDP, you need to
notify charger IC after set configuration has finished, since
the host may still not be ready to give high current.
--
Best Regards,
Peter Chen
On Wed, Mar 30, 2016 at 12:56:27PM +0300, Roger Quadros wrote:
> Hi,
>
> Add documentation for struct otg_fsm with some trivial cleanups.
> All patches have been Acked by otg-fsm maintainer (Peter Chen).
>
I will queue them, thanks.
--
Best Regards,
Peter Chen
e need notify
> gadget state to usb charger.
>
Ok, I see, it only changes current limit at function usb_gadget_vbus_draw
in your patch 2/4. Then, we need to make sure usb_charger_set_cur_limit_by_type
is called before calling usb_gadget_set_state(gadget, USB_STATE_CONFIGURED).
It seems you have not implemented usb_charger_plug_by_gadget in your patch set.
--
Best Regards,
Peter Chen
>
> On 16-03-29 00:24:46, Peter Chen wrote:
> >
> > >
> > > On 2016-03-25 00:40, Peter Chen wrote:
> > > > On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> > > >> Hello Peter,
> > > >>
> > > &g
On Wed, Mar 30, 2016 at 03:07:49PM +0800, Baolin Wang wrote:
> On 30 March 2016 at 10:05, Peter Chen wrote:
> > On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote:
> >> On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> >> > On Mon, Mar 28, 2016 at
On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote:
> On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
>
> > > > I am afraid I still not find the user (udc driver) for this framework,
>
>
> On 28 March 2016 at 15:13, Peter Chen wrote:
> > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
> >> On 25 March 2016 at 15:09, Peter Chen wrote:
> >> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> >>
>
> On 2016-03-25 00:40, Peter Chen wrote:
> > On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> >> Hello Peter,
> >>
> >> The existing usage of extcon in Chipidea driver relies on OTG
> >> registers. In case of SoC with dual role
On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
> On 25 March 2016 at 15:09, Peter Chen wrote:
> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> Currently the Linux kernel does not provide any standard integration of
> >> this
> >
you sure Vybrid is NOT OTG core? Afaik, it is uses the same
IP base with other Freescale SoCs, just the IP core is 2.40a.
When working at device mode, can you read vbus status through
OTGSC? And if there is an ID pin (input pin) for Vybrid? I mean
SoC, not the board.
--
Best Regards,
Peter Chen
eover there may be other potential users will use
> it in future.
>
I am afraid I still not find the user (udc driver) for this framework, I would
like to see how udc driver block the enumeration until the charger detection
has finished, or am I missing something?
--
Best Regards,
Peter Chen
tform layer.
>
> My suggestion is that we turn the chipidea core into a set of APIs
> that can called by the platform specific pieces. That way we will have
> the chipidea core be the device described in the DT.
>
Hi Bjorn,
After reading the DMA documentation Russell supplied and se
using dev_of_node for all devices in
case the struct device is not zero-initialized.
--
Best Regards,
Peter Chen
t; ---
> > Applicable to linux-next-20160317
> >
> > Changes to v1:
> > - Initialize raw_port with port1
>
> Acked-by: Alan Stern
>
Thanks for fixing it in time, you are right. My patch would let the
device logical port number equals to device raw port number, but it
is wrong for xhci.
--
Best Regards,
Peter Chen
On Thu, Mar 17, 2016 at 04:52:55PM +0100, Arnd Bergmann wrote:
> On Monday 14 March 2016 18:51:08 Peter Chen wrote:
> > On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote:
> > > On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson
> > > wrote:
> > > > O
e described in the DT.
>
> But like I said, this problem is not just existing for chipidea
> driver. We already found that the dwc3 driver is also suffering from
> the same issue. I don't know how many other drivers are impacted by
> this change, but I suspect there will be some. A grep of
> platform_device_add() in driver/ directory returns many possible
> drivers to be impacted. As far as I know, the
> drivers/net/ethernet/freescale/fman/mac.c is registering child
> ethernet devices that definitely will do dma. If you want to do this
> kind of rework to all these drivers, it will be a really big effort.
>
+1
Yes, I think this DMA things should be covered by driver core too.
--
Best Regards,
Peter Chen
On Thu, Feb 25, 2016 at 05:01:12PM -0500, Tejun Heo wrote:
> Hello, Peter.
>
> On Wed, Feb 24, 2016 at 03:24:30PM +0800, Peter Chen wrote:
> > > You might want to complain to the block-layer people about this. I
> > > don't know if anything can be done
blem is that such solution does not exist today.
>
> Peter Chen has been working on it lately.
Yes, I will cc you when I send new patch.
Peter
On Tue, Feb 23, 2016 at 10:34:09AM -0500, Alan Stern wrote:
> On Tue, 23 Feb 2016, Peter Chen wrote:
>
> > Hi Tejun Heo and Florian Mickler,
> >
> > I have a question that during the system resume process, the freezable
> > workqueue can be thawed if there i
On Tue, Feb 23, 2016 at 11:20:56AM +0800, Peter Chen wrote:
> Hi Tejun Heo and Florian Mickler,
>
> I have a question that during the system resume process, the freezable
> workqueue can be thawed if there is a non-freezable workqueue is
> blocked (At uninterruptable state)?
&g
wq 2: cpus=0 flags=0x4 nice=0 active=1/1
[ 555.844623] in-flight: 826:ci_otg_work
[ 555.848810] pool 2: cpus=0 flags=0x4 nice=0 hung=0s workers=15 idle: 814 733
700 824 6 822 820 819 816 817 815 813 827 825
Thanks you!
--
Best Regards,
Peter Chen
gt; needs to be figured out.
>
Chipidea is core driver; msm driver is glue layer, it has something
platform related.
--
Best Regards,
Peter Chen
ev, res, nres);
> if (ret)
> goto err;
Just would like to confirm, it will not affect the default behavior
which the "dma-ranges" is not set at those platforms?
--
Best Regards,
Peter Chen
unplug/replug
> your phone from the desktop until you achieve device role, right?
>
> > You need to describe this a lot better than you did...
>
> Sure thing. I'm sorry about the poor description. I send these out too
> hastily.
>
>
> Thanks,
>
> --
> heikki
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
I am interested in how you design role swap on the fly without USB PD.
Do you follow the spec like USB OTG 3.0 RSP (Role Swap Protocol) or
just echo the /sys to give up current role, and swap to another?
--
Best Regards,
Peter Chen
>
> The hub and the ethernet in its port 1 are hardwired on the board.
>
> Compared to the adapters that can be plugged into the USB ports, this one has
> no serial EEPROM to store its MAC. Nevertheless, the Raspberry Pi has the
> MAC address for this adapter in its ROM, accessible from its fir
> Lubomir Rintel writes:
>
> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > index ef54050..32bbd2a 100644
> > --- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > +++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
>
> Hi,
>
> Shouldn't thi
/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -15,6 +15,7 @@
>
> menuconfig USB_GADGET
> tristate "USB Gadget Support"
> + select USB_COMMON
> select NLS
> help
> USB is a master/slave protocol, organized with one master
>
Reviewed-by: Peter Chen
--
Best Regards,
Peter Chen
r get lock but the request has already been given back.
> > >
> >
> > get unlock?
> >
> > During the interrupt handler, it should only handle the "data complete"
> > interrupt on queued request; if the "data complete" interrupt occurs,
> }
> kfree(data);
> }
> @@ -859,6 +869,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
> ffs_io_data *io_data)
>
> error_lock:
> spin_unlock_irq(&epfile->ffs->eps_lock);
> +error_mutex:
&
} while (active);
>
> + spin_unlock_irqrestore(&midi->transmit_lock, flags);
> +
> return;
>
> drop_out:
> @@ -1255,6 +1265,8 @@ static struct usb_function *f_midi_alloc(struct
> usb_function_instance *fi)
> if (status)
> goto setu
i % (ci->hw_ep_max / 2),
> --
> 2.5.0
>
It is ok for chipidea part, I will queue it, you don't need to
re-send it again
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
load anything to dwc3 ;-)
>
> In all fairness, none of these are regressions. Can we agree to look at
> these during v4.5-rc so maybe v4.6 has a final solution ?
>
> cheers
>
Hi Felipe,
To support all of these, it will let legacy gadget driver usage as same
as configfs. If t
b/core/Kconfig | 11 +-
> drivers/usb/core/hcd.c| 55 +-
> drivers/usb/core/hub.c| 10 +-
> drivers/usb/gadget/udc/udc-core.c | 124 ++-
> drivers/usb/phy/Kconfig
include/uapi/linux/usbdevice_fs.h
> +++ b/include/uapi/linux/usbdevice_fs.h
> @@ -187,5 +187,6 @@ struct usbdevfs_streams {
> #define USBDEVFS_DISCONNECT_CLAIM _IOR('U', 27, struct
> usbdevfs_disconnect_claim)
> #define USBDEVFS_ALLOC_STREAMS _IOR('U', 28, s
due to no any UDC added.
> >
> > Also it is useful for modules case - now there is no
> > difference what module to insert first: gadget module
> > or gadget driver one.
> >
> > Tested-by: Maxime Ripard
> > Signed-off-by: Ruslan Bilovol
> > [simplif
urrent chipidea framework (find this
problem after testing), the chipidea core manages its host and device
function using its own API start/stop, it does not define struct usb_otg
APIs. In fact, it is not reasonable control host and device function
at PHY driver.
--
Best Regards,
Peter Chen
--
h_entry(udc, &udc_list, list) {
> @@ -549,9 +569,12 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
> *driver)
> }
> }
>
> - pr_debug("couldn't find an available UDC\n");
> + list_add_tail(&driver->pending, &g
river->pending, &gadget_driver_pending_list);
> > + mutex_unlock(&udc_lock);
> > + }
>
> It looks like there is a race here with usb_gadget_unregister_driver().
> Would it be okay to hold the udc_lock mutex throughout the whole "if"
>
On Fri, Nov 20, 2015 at 06:58:59PM -0600, Felipe Balbi wrote:
>
> Hi,
>
> Tim Bird writes:
> > On 11/16/2015 09:21 AM, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Peter Chen writes:
> >>> On Wed, Nov 11, 2015 at 09:48:00AM
> >>
> > And it seems can't apply for felipe's testing/next which I just
> > rebased on it.
>
> I really have no idea why it fails for You. The patchset applies correctly on
> both
> Felipe's 'next' and 'testing/next' branches from today.
>
I may know the reason, it may be because I changed
include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -1014,6 +1014,7 @@ static inline int usb_gadget_activate(struct usb_gadget
> *gadget)
> * @driver: Driver model state for this driver.
> * @udc_name: A name of UDC this driver should be bound to. If udc_name is
> NU
truct usb_composite_dev *cdev = &gi->cdev;
>
> mutex_lock(&gi->lock);
> - if (gi->udc_name)
> + if (gi->composite.gadget_driver.udc_name)
> unregister_gadget(gi);
> cdev->os_desc_config = NULL;
> - WARN_ON(gi->udc
sb: gadget: bind UDC by name passed via usb_gadget_driver
structure
WARNING: please, no space before tabs
#55: FILE: include/linux/usb/gadget.h:1016:
+ * ^Ithis driver will be bound to any available UDC.$
>
> --
> 1.9.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe
On Wed, Nov 18, 2015 at 10:38:18AM +0100, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 11:17:50 Peter Chen wrote:
> > From 3a6918dae038aadc200dcf0263f4440acc2353d4 Mon Sep 17 00:00:00 2001
> > From: Peter Chen
> > Date: Wed, 18 Nov 2015 11:06:34 +0800
> > Subjec
On Wed, Nov 18, 2015 at 11:48:36AM +0530, Saurabh Sengar wrote:
> On 18 November 2015 at 11:35, Peter Chen wrote:
> > On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
> >> call to of_find_property() before of_property_read_u32() is unnecessary.
> >> of
erty_read_u32(dev->of_node, "rx-burst-size-dword",
> - &platdata->rx_burst_size);
> - if (ret) {
> - dev_err(dev,
> - "failed to get rx-burst-size-dword\n");
> -
(-ENODATA) or
> 'overflow'(-ENODATA) error for this property.
If there is an error, the variable pass to of_property_read_u32 will
not be changed.
Peter
> In case this is not OK, I will send a another patch(v4) as you have suggested.
>
> Regards,
> Saurabh
>
> On
ze-dword",
> - &platdata->rx_burst_size);
> - if (ret) {
> - dev_err(dev,
> - "failed to get rx-burst-size-dword\n");
> - return ret;
> - }
> +
ng
> anything that contradicted this. It seems I missed the important part
> as you say, so we should instead add 'depends on PM' for the other
> symbols.
>
> Arnd
Hi Arnd, would you kindly try if below patch can fix your problem
>From 3a6918dae038aadc200dcf0263f4440acc2353d4 Mon Sep 17 00:00:00 2
On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
>
>
> On 11/10/2015 07:14 PM, Peter Chen wrote:
> > On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
> >> This fixes a bug where if you disconnect and re-connect the USB cable,
> >> the gadget dr
m_hsusb.h
> index 8c8f685..08c67a3 100644
> --- a/include/linux/usb/msm_hsusb.h
> +++ b/include/linux/usb/msm_hsusb.h
> @@ -164,6 +164,7 @@ struct msm_otg {
> struct usb_phy phy;
> struct msm_otg_platform_data *pdata;
> int irq;
> + int async_irq;
> struct clk *clk;
> struct clk *pclk;
> struct clk *core_clk;
> --
> 1.8.2.2
>
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, Nov 06, 2015 at 10:58:39AM +0100, Krzysztof Opasiak wrote:
>
>
> On 11/06/2015 10:48 AM, Peter Chen wrote:
> >On Fri, Nov 06, 2015 at 09:50:11AM +0100, Robert Baldyga wrote:
> >>On 11/06/2015 09:15 AM, Peter Chen wrote:
> >>>On Tue, Nov 03, 2015 at 01
On Fri, Nov 06, 2015 at 09:50:11AM +0100, Robert Baldyga wrote:
> On 11/06/2015 09:15 AM, Peter Chen wrote:
> > On Tue, Nov 03, 2015 at 01:53:42PM +0100, Robert Baldyga wrote:
> >> USB requests in SourceSink function are allocated in sourcesink_get_alt()
> >> function
Forum,
> hosted by The Linux Foundation
>
Greg, another related changes is at host driver, pick it up
directly please, thanks.
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
free_ep_req(ss->iso_in_ep, ss->iso_in_req[i]);
> + free_ep_req(ss->iso_out_ep, ss->iso_out_req[i]);
> + }
> + }
> }
>
> /*-*/
> --
> 1.9.1
1023 : ss->isoc_maxpacket;
> + break;
> }
> + ep = is_in ? ss->iso_in_ep : ss->iso_out_ep;
> + } else {
> + ep = is_in ? ss->in_ep : ss->out_ep;
> + }
>
> + for (i = 0; i < 8; i
> gzero_options.isoc_maxburst, uint,
> S_IRUGO|S_IWUSR);
> MODULE_PARM_DESC(isoc_maxburst, "0 - 15 (ss only)");
>
> +module_param_named(isoc_enabled, gzero_options.isoc_enabled, uint,
> + S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(isoc_enabled, "0 - disabled, 1 - enabled");
> +
> static struct usb_function *func_lb;
> static struct usb_function_instance *func_inst_lb;
>
> @@ -284,6 +289,7 @@ static int zero_bind(struct usb_composite_dev *cdev)
> ss_opts->isoc_maxpacket = gzero_options.isoc_maxpacket;
> ss_opts->isoc_mult = gzero_options.isoc_mult;
> ss_opts->isoc_maxburst = gzero_options.isoc_maxburst;
> + ss_opts->isoc_enabled = gzero_options.isoc_enabled;
> ss_opts->bulk_buflen = gzero_options.bulk_buflen;
>
> func_ss = usb_get_function(func_inst_ss);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Nov 03, 2015 at 09:51:11PM -0600, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> > On Tue, Nov 03, 2015 at 07:56:55AM -0600, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Nathan Sullivan writes:
> >> > The USB O
if the software
implements OTG FSM, it is the user option whether do HNP, and bus
suspend is controlled by OTG FSM software (stop SOF), but not by host
stack (eg, ehci).
I am sorry I did not consider the legacy OTG design, this patch should
be dropped.
--
Best Regards,
Peter Chen
--
To unsubsc
> @@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS
>
> config USB_OTG
> bool "OTG support"
> - depends on PM
> default n
> help
> The most notable feature of USB OTG is support for a
> --
> 1.7.10.4
>
Acked-by: Peter Chen
--
t; I'm just pointing to those references, since I don't know if you want to
> keep them in the code or not. I found the issue and your commit with
> scipts/checkkconfigsymbols.py.
Thanks, Valentin. I will change them.
>
> Kind regards,
> Valentin
--
Best Regards,
Peter
--- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -43,8 +43,6 @@ config USB_DYNAMIC_MINORS
>
> config USB_OTG
> bool "OTG support"
> - depends on PM
> - default n
> help
> The most notable feature of USB OTG is s
On Thu, Oct 29, 2015 at 09:05:55AM +0100, Michal Marek wrote:
> Dne 29.10.2015 v 07:34 Peter Chen napsal(a):
> > On Wed, Oct 28, 2015 at 02:25:41PM +0100, Michal Marek wrote:
> >> From: Michal Marek
> >>
> >> This allows to write
> >>
> >> d
e depending on something
> modular cannot work and init/Makefile actually relies on the current
> semantics. There are a few drivers which adapted to the current
> semantics out of necessity; these are fixed to also work when the
> respective subsystem is modular.
>
> Cc: Peter
On Wed, Oct 28, 2015 at 10:17:59AM -0400, Jason Baron wrote:
> On 10/27/2015 03:40 AM, Peter Chen wrote:
> > The parse_args will delete space between boot parameters, so
> > if we add dyndbg="file drivers/usb/* +p" at bootargs, the parse_args
> > will split it as t
*/
> if (cycle_state == 0) {
> for (i = 0; i < TRBS_PER_SEGMENT; i++)
> @@ -517,12 +516,11 @@ static struct xhci_container_ctx
> *xhci_alloc_container_ctx(struct xhci_hcd *xhci
> if (type == XHCI_CTX_TYPE_INPUT)
> ctx->size += CTX_SIZE(xhc
f USB OTG is support for a
> "Dual-Role" device, which can act as either a device
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordo
> Hi Peter,
>
> Have you seen this patch? I saw that you didn't apply it to your tree, so I
> wonder if it is good or do I have to change anything.
>
> This patch is a bug fix for a memory leak, so it is quite important.
>
Would you please create it based on my tree, branch ci-for-usb-next?
I
Current non-module ddebug during boot process will fail due to
parse_args will delete space and give ddebug only the first
parameter, the code changes using comma to split ddebug parameters
for boot process, and we change documentation accordingly.
Signed-off-by: Peter Chen
Cc
to split parameters for ddebug booting
parameter, and replace comma with space at code, in that case, the ddebug
core can handle it with the same way we do it for /sys.
Signed-off-by: Peter Chen
Cc:
---
lib/dynamic_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/d
t for a
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
amp;hwreq->tds, struct td_node, td);
>
> --
> 2.1.4
>
Hi Felipe,
I can't apply it in my tree, would you please create it based on chipdea
tree?
https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
branch: ci-for-usb-next
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 20, 2015 at 03:33:52PM +0900, Jiada Wang wrote:
> Hi
>
> On 10/20/2015 03:28 PM, Peter Chen wrote:
> >On Tue, Oct 20, 2015 at 03:09:02PM +0900, Jiada Wang wrote:
> >>Hi
> >>
> >>On 10/20/2015 03:01 PM, Peter Chen wrote:
> >>>On T
On Tue, Oct 20, 2015 at 03:09:02PM +0900, Jiada Wang wrote:
> Hi
>
> On 10/20/2015 03:01 PM, Peter Chen wrote:
> >On Tue, Oct 20, 2015 at 11:29:18AM +0900, Jiada Wang wrote:
> >>Currently in udc_stop, if vbus_active flag is true, all USB activities
> >>will be
t;
> if (ci->vbus_active) {
> + ci->vbus_active = 0;
> hw_device_state(ci, 0);
> if (ci->platdata->notify_event)
> ci->platdata->notify_event(ci,
> --
> 2.4.5
>
This flag will be handl
On Fri, Sep 25, 2015 at 09:27:49AM +0100, Felipe Tonello wrote:
> On Thu, Sep 24, 2015 at 2:20 AM, Peter Chen wrote:
> > On Wed, Sep 23, 2015 at 12:40:46PM +0100, Felipe Tonello wrote:
> >> Hi Peter,
> >>
> >> On Wed, Sep 23, 2015 at 8:09 AM, Peter Chen
>
801 - 900 of 1229 matches
Mail list logo
