Re: [PATCH net] net: usbnet: prevent buggy devices from killing us
Joe Perches j...@perches.com writes:
On Thu, 2013-01-24 at 20:16 +0100, Bjørn Mork wrote:
A device sending 0 length frames as fast as it can has been
observed killing the host system due to the resulting memory
pressure.
[]
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
[]
@@ -539,6 +545,22 @@ block:
break;
}
+/* stop rx if packet error rate is high */
+if (++dev-pkt_cnt 30) {
+dev-pkt_cnt = 0;
+dev-pkt_err = 0;
+} else {
+if (state == rx_cleanup)
+dev-pkt_err++;
+if (dev-pkt_err 20) {
+set_bit(EVENT_RX_KILL, dev-flags);
+if (net_ratelimit())
+netif_dbg(dev, rx_err, dev-net,
+ rx kill: high error rate\n);
+dev-pkt_err = 0;
+}
+}
Maybe use ratelimit() here?
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
[]
@@ -33,6 +33,7 @@ struct usbnet {
wait_queue_head_t *wait;
struct mutexphy_mutex;
unsigned char suspend_count;
+unsigned char pkt_cnt, pkt_err;
and instead:
struct ratelimit_state errors;
Thanks. I took a look at this, but it seems to be more complex than I
really wanted for keeping the debug noise down here. The rest of usbnet
does not care much about rate limiting debug messages at all. I'll get
a message for every 0 length packet for example.
Maybe usbnet should get a private debug ratelimiter all over?
Is the problem that these instances will hide more important net
messages? Would it help to make the ratelimit call depend on whether
debugging is enabled like ath5k and brcm80211 seems to do?
Bjørn
--
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
[balbi-usb:xceiv 11/13] include/linux/usb/phy.h:194:2: warning: return makes integer from pointer without a cast
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
head: a342da25a9a7f5a2f34030e5017043780a673cd1
commit: 84c5bc80a75b8db64e890d035ee1469822b85438 [11/13] usb: otg: add an api
to bind the usb controller and phy
config: i386-randconfig-x425 (attached as .config)
All warnings:
In file included from include/linux/usb/otg.h:12:0,
from drivers/usb/gadget/mv_udc_core.c:31:
include/linux/usb/phy.h: In function 'usb_bind_phy':
include/linux/usb/phy.h:194:2: warning: return makes integer from pointer
without a cast [enabled by default]
vim +194 include/linux/usb/phy.h
178 enum usb_phy_type type)
179 {
180 return NULL;
181 }
182
183 static inline void usb_put_phy(struct usb_phy *x)
184 {
185 }
186
187 static inline void devm_usb_put_phy(struct device *dev, struct usb_phy
*x)
188 {
189 }
190
191 static inline int usb_bind_phy(const char *dev_name, u8 index,
192 const char *phy_dev_name)
193 {
194 return NULL;
195 }
196 #endif
197
198 static inline int
199 usb_phy_set_power(struct usb_phy *x, unsigned mA)
200 {
201 if (x x-set_power)
202 return x-set_power(x, mA);
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.8.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT=elf32-i386
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME=(none)
# CONFIG_SYSVIPC is not set
CONFIG_FHANDLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FANOUT_EXACT=y
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=1
CONFIG_RCU_BOOST_DELAY=500
CONFIG_RCU_NOCB_CPU=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY
Re: [balbi-usb:xceiv 11/13] include/linux/usb/phy.h:194:2: warning: return makes integer from pointer without a cast
Hi,
On Fri, Jan 25, 2013 at 04:15:13PM +0800, kbuild test robot wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
head: a342da25a9a7f5a2f34030e5017043780a673cd1
commit: 84c5bc80a75b8db64e890d035ee1469822b85438 [11/13] usb: otg: add an api
to bind the usb controller and phy
config: i386-randconfig-x425 (attached as .config)
All warnings:
In file included from include/linux/usb/otg.h:12:0,
from drivers/usb/gadget/mv_udc_core.c:31:
include/linux/usb/phy.h: In function 'usb_bind_phy':
include/linux/usb/phy.h:194:2: warning: return makes integer from pointer
without a cast [enabled by default]
vim +194 include/linux/usb/phy.h
178enum usb_phy_type type)
179{
180return NULL;
181}
182
183static inline void usb_put_phy(struct usb_phy *x)
184{
185}
186
187static inline void devm_usb_put_phy(struct device *dev, struct
usb_phy *x)
188{
189}
190
191static inline int usb_bind_phy(const char *dev_name, u8 index,
192const char *phy_dev_name)
193{
194return NULL;
195}
196#endif
197
198static inline int
199usb_phy_set_power(struct usb_phy *x, unsigned mA)
200{
201if (x x-set_power)
202return x-set_power(x, mA);
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
fixed and updated branch. Thank you
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Friday 25 January 2013 01:18 PM, Felipe Balbi wrote: On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote: On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy will be removed. diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt This file seems to be specific to the TI USB PHYs, not all USB PHYs; shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match the compatible value it documents, giving ti,omap-usb2.txt? could be, but that can be done as a separate patch. It's not part of $SUBJECT. add the address of control module dev conf register until a driver for control module is added +Optional properties: + - ctrl_module : phandle of the control module used by PHY driver to power on + the PHY. DT property names generally use - not _ as the word separator. fair enough, Kishon, can you fix this up ? Sure. Will post a patch.. Thanks Kishon -- 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
Re: [PATCH v1 1/8] usb: otg: palmas-usb: make palmas-usb as a comparator driver
On Friday 25 January 2013 01:13 PM, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 08:42:24AM +0530, Kishon Vijay Abraham I wrote: palmas-usb is made as a comparator driver to omap usb2 phy, so that omap usb can make use of palmas for srp and also to set vbus. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com doesn't apply. palmas-usb isn't in mainline Yes. We'll ask Rajendra Nayak to pick this up in his tree? Thanks Kishon -- 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
Re: [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
hi, On Fri, Jan 25, 2013 at 02:12:41PM +0530, kishon wrote: On Friday 25 January 2013 01:18 PM, Felipe Balbi wrote: On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote: On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy will be removed. diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt This file seems to be specific to the TI USB PHYs, not all USB PHYs; shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match the compatible value it documents, giving ti,omap-usb2.txt? could be, but that can be done as a separate patch. It's not part of $SUBJECT. add the address of control module dev conf register until a driver for control module is added +Optional properties: + - ctrl_module : phandle of the control module used by PHY driver to power on + the PHY. DT property names generally use - not _ as the word separator. fair enough, Kishon, can you fix this up ? Sure. Will post a patch.. Great, notice that I've already applied some of your patches to my tree. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Friday 25 January 2013 02:15 PM, Felipe Balbi wrote: hi, On Fri, Jan 25, 2013 at 02:12:41PM +0530, kishon wrote: On Friday 25 January 2013 01:18 PM, Felipe Balbi wrote: On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote: On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy will be removed. diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt This file seems to be specific to the TI USB PHYs, not all USB PHYs; shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match the compatible value it documents, giving ti,omap-usb2.txt? could be, but that can be done as a separate patch. It's not part of $SUBJECT. add the address of control module dev conf register until a driver for control module is added +Optional properties: + - ctrl_module : phandle of the control module used by PHY driver to power on + the PHY. DT property names generally use - not _ as the word separator. fair enough, Kishon, can you fix this up ? Sure. Will post a patch.. Great, notice that I've already applied some of your patches to my tree. Cool. Thanks :-) Regards Kishon -- 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
Re: [PATCH v1 1/8] usb: otg: palmas-usb: make palmas-usb as a comparator driver
On Fri, Jan 25, 2013 at 02:14:07PM +0530, kishon wrote: On Friday 25 January 2013 01:13 PM, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 08:42:24AM +0530, Kishon Vijay Abraham I wrote: palmas-usb is made as a comparator driver to omap usb2 phy, so that omap usb can make use of palmas for srp and also to set vbus. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com doesn't apply. palmas-usb isn't in mainline Yes. We'll ask Rajendra Nayak to pick this up in his tree? Eventually the final version needs to go upstream, though. -- balbi signature.asc Description: Digital signature
[PATCH v4 2/3] usb: gadget: introduce gadget state tracking
that's useful information to expose to userland.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/udc-core.c | 23 +++
include/linux/usb/gadget.h| 9 +
2 files changed, 32 insertions(+)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 40b1d88..8a1eeb2 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -101,6 +101,16 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
/* - */
+void usb_gadget_set_state(struct usb_gadget *gadget,
+ enum usb_device_state state)
+{
+ gadget-state = state;
+ sysfs_notify(gadget-dev.kobj, NULL, status);
+}
+EXPORT_SYMBOL_GPL(usb_gadget_set_state);
+
+/* - */
+
/**
* usb_gadget_udc_start - tells usb device controller to start up
* @gadget: The gadget we want to get started
@@ -197,6 +207,8 @@ int usb_add_gadget_udc(struct device *parent, struct
usb_gadget *gadget)
if (ret)
goto err4;
+ usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
+
mutex_unlock(udc_lock);
return 0;
@@ -406,6 +418,16 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
}
static DEVICE_ATTR(soft_connect, S_IWUSR, NULL, usb_udc_softconn_store);
+static ssize_t usb_gadget_state_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct usb_udc *udc = container_of(dev, struct usb_udc, dev);
+ struct usb_gadget *gadget = udc-gadget;
+
+ return sprintf(buf, %s\n, usb_state_string(gadget-state));
+}
+static DEVICE_ATTR(state, S_IRUGO, usb_gadget_state_show, NULL);
+
#define USB_UDC_SPEED_ATTR(name, param)
\
ssize_t usb_udc_##param##_show(struct device *dev, \
struct device_attribute *attr, char *buf) \
@@ -439,6 +461,7 @@ static USB_UDC_ATTR(a_alt_hnp_support);
static struct attribute *usb_udc_attrs[] = {
dev_attr_srp.attr,
dev_attr_soft_connect.attr,
+ dev_attr_state.attr,
dev_attr_current_speed.attr,
dev_attr_maximum_speed.attr,
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 2e297e8..dcf8b7c 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -482,6 +482,7 @@ struct usb_gadget_ops {
* @speed: Speed of current connection to USB host.
* @max_speed: Maximal speed the UDC can handle. UDC must support this
* and all slower speeds.
+ * @state: the state we are now (attached, suspended, configured, etc)
* @sg_supported: true if we can handle scatter-gather
* @is_otg: True if the USB device port uses a Mini-AB jack, so that the
* gadget driver must provide a USB OTG descriptor.
@@ -525,6 +526,7 @@ struct usb_gadget {
struct list_headep_list;/* of usb_ep */
enum usb_device_speed speed;
enum usb_device_speed max_speed;
+ enum usb_device_state state;
unsignedsg_supported:1;
unsignedis_otg:1;
unsignedis_a_peripheral:1;
@@ -959,6 +961,13 @@ extern void usb_gadget_unmap_request(struct usb_gadget
*gadget,
/*-*/
+/* utility to set gadget status properly */
+
+extern void usb_gadget_set_state(struct usb_gadget *gadget,
+ enum usb_device_state state);
+
+/*-*/
+
/* utility wrapping a simple endpoint selection policy */
extern struct usb_ep *usb_ep_autoconfig(struct usb_gadget *,
--
1.8.1.rc1.5.g7e0651a
--
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
[PATCH v4 1/3] usb: common: introduce usb_state_string()
this function will receive enum usb_device_state
and return a human-readable string from it or,
case an unknown value is passed as argument,
the string UNKNOWN.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/usb-common.c | 21 +
include/linux/usb/ch9.h | 9 +
2 files changed, 30 insertions(+)
diff --git a/drivers/usb/usb-common.c b/drivers/usb/usb-common.c
index d29503e..070b681 100644
--- a/drivers/usb/usb-common.c
+++ b/drivers/usb/usb-common.c
@@ -32,4 +32,25 @@ const char *usb_speed_string(enum usb_device_speed speed)
}
EXPORT_SYMBOL_GPL(usb_speed_string);
+const char *usb_state_string(enum usb_device_state state)
+{
+ static const char *const names[] = {
+ [USB_STATE_NOTATTACHED] = not attached,
+ [USB_STATE_ATTACHED] = attached,
+ [USB_STATE_POWERED] = powered,
+ [USB_STATE_RECONNECTING] = reconnecting,
+ [USB_STATE_UNAUTHENTICATED] = unauthenticated,
+ [USB_STATE_DEFAULT] = default,
+ [USB_STATE_ADDRESS] = addresssed,
+ [USB_STATE_CONFIGURED] = configured,
+ [USB_STATE_SUSPENDED] = suspended,
+ };
+
+ if (state 0 || state = ARRAY_SIZE(names))
+ return UNKNOWN;
+
+ return names[state];
+}
+EXPORT_SYMBOL_GPL(usb_state_string);
+
MODULE_LICENSE(GPL);
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 9c210f2..27603bc 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -43,4 +43,13 @@
*/
extern const char *usb_speed_string(enum usb_device_speed speed);
+
+/**
+ * usb_state_string - Returns human readable name for the state.
+ * @state: The state to return a human-readable name for. If it's not
+ * any of the states devices in usb_device_state_string enum,
+ * the string UNKNOWN will be returned.
+ */
+extern const char *usb_state_string(enum usb_device_state state);
+
#endif /* __LINUX_USB_CH9_H */
--
1.8.1.rc1.5.g7e0651a
--
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
[PATCH v4 0/3] usb: gadget: state tracking
here's v4 Changes since v3: - Remove direct inclusion of uapi/linux/usb/ch9.h Chances since v2: - split usb_state_string() to a separate patch, placed it on usb-common.c and renamed from usb_device_state_string() - moved NOTATTACHED to udc-core.c::usb_add_gadget_udc(). Felipe Balbi (3): usb: common: introduce usb_state_string() usb: gadget: introduce gadget state tracking usb: dwc3: gadget: implement gadget status tracking drivers/usb/dwc3/ep0.c| 15 --- drivers/usb/gadget/udc-core.c | 23 +++ drivers/usb/usb-common.c | 21 + include/linux/usb/ch9.h | 9 + include/linux/usb/gadget.h| 9 + 5 files changed, 74 insertions(+), 3 deletions(-) -- 1.8.1.rc1.5.g7e0651a -- 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
[PATCH v4 3/3] usb: dwc3: gadget: implement gadget state tracking
make use of the previously introduced gadget-state
field.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/ep0.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index d7da073..ec4b563 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -512,10 +512,13 @@ static int dwc3_ep0_set_address(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
reg |= DWC3_DCFG_DEVADDR(addr);
dwc3_writel(dwc-regs, DWC3_DCFG, reg);
- if (addr)
+ if (addr) {
dwc-dev_state = DWC3_ADDRESS_STATE;
- else
+ usb_gadget_set_state(dwc-gadget, USB_STATE_ADDRESS);
+ } else {
dwc-dev_state = DWC3_DEFAULT_STATE;
+ usb_gadget_set_state(dwc-gadget, USB_STATE_DEFAULT);
+ }
return 0;
}
@@ -549,6 +552,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
/* if the cfg matches and the cfg is non zero */
if (cfg (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
dwc-dev_state = DWC3_CONFIGURED_STATE;
+ usb_gadget_set_state(dwc-gadget,
+ USB_STATE_CONFIGURED);
+
/*
* Enable transition to U1/U2 state when
* nothing is pending from application.
@@ -564,8 +570,11 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
case DWC3_CONFIGURED_STATE:
ret = dwc3_ep0_delegate_req(dwc, ctrl);
- if (!cfg)
+ if (!cfg) {
dwc-dev_state = DWC3_ADDRESS_STATE;
+ usb_gadget_set_state(dwc-gadget,
+ USB_STATE_ADDRESS);
+ }
break;
default:
ret = -EINVAL;
--
1.8.1.rc1.5.g7e0651a
--
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
Re: [PATCH v4 2/3] usb: gadget: introduce gadget state tracking
Hi,
On Fri, Jan 25, 2013 at 11:12:41AM +0200, Felipe Balbi wrote:
that's useful information to expose to userland.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/udc-core.c | 23 +++
include/linux/usb/gadget.h| 9 +
2 files changed, 32 insertions(+)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 40b1d88..8a1eeb2 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -101,6 +101,16 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
/* -
*/
+void usb_gadget_set_state(struct usb_gadget *gadget,
+ enum usb_device_state state)
+{
+ gadget-state = state;
+ sysfs_notify(gadget-dev.kobj, NULL, status);
+}
+EXPORT_SYMBOL_GPL(usb_gadget_set_state);
I guess it would be good to have a:
enum usb_gadget_state usb_gadget_get_state(struct usb_gadget *gadget)
{
return gadget-state;
}
right ?? At least dwc3 can make use of it.
--
balbi
signature.asc
Description: Digital signature
Re: Hibernate fails to freeze fuse write
On Fri, Jan 25, 2013 at 1:03 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Hi Miklos, I'm running some tests with an NTFS formated USB 3.0 device. First, I flush any caches by running `echo 3 /proc/sys/vm/drop_caches`. Next, I begin a copy of a 1.1 GB file to the device. I immediately attempt to hibernate the system, but the hibernate almost always fails. dmesg says: Yes, this is a known problem. And proper solution is hard. Thanks, Miklos -- 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
Re: [PATCH v4 2/3] usb: gadget: introduce gadget state tracking
Hi,
On Fri, Jan 25, 2013 at 11:29:57AM +0200, Felipe Balbi wrote:
Hi,
On Fri, Jan 25, 2013 at 11:12:41AM +0200, Felipe Balbi wrote:
that's useful information to expose to userland.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/udc-core.c | 23 +++
include/linux/usb/gadget.h| 9 +
2 files changed, 32 insertions(+)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 40b1d88..8a1eeb2 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -101,6 +101,16 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
/*
- */
+void usb_gadget_set_state(struct usb_gadget *gadget,
+ enum usb_device_state state)
+{
+ gadget-state = state;
+ sysfs_notify(gadget-dev.kobj, NULL, status);
+}
+EXPORT_SYMBOL_GPL(usb_gadget_set_state);
I guess it would be good to have a:
enum usb_gadget_state usb_gadget_get_state(struct usb_gadget *gadget)
{
return gadget-state;
}
right ?? At least dwc3 can make use of it.
We could use it like this:
From c6c90377581bfcd55fc8a4bf724e0c9d5872944a Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Fri, 25 Jan 2013 11:28:19 +0200
Subject: [PATCH] usb: dwc3: remove our homebrew state mechanism
We can reuse the generic implementation via
our struct usb_gadget.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.h | 7 ---
drivers/usb/dwc3/ep0.c | 34 +-
2 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4999563..11a77f0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -487,12 +487,6 @@ enum dwc3_link_state {
DWC3_LINK_STATE_MASK= 0x0f,
};
-enum dwc3_device_state {
- DWC3_DEFAULT_STATE,
- DWC3_ADDRESS_STATE,
- DWC3_CONFIGURED_STATE,
-};
-
/* TRB Length, PCM and Status */
#define DWC3_TRB_SIZE_MASK (0x00ff)
#define DWC3_TRB_SIZE_LENGTH(n)((n) DWC3_TRB_SIZE_MASK)
@@ -707,7 +701,6 @@ struct dwc3 {
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
enum dwc3_link_statelink_state;
- enum dwc3_device_state dev_state;
u16 isoch_delay;
u16 u2sel;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index ec4b563..45847ce 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -394,10 +394,13 @@ static int dwc3_ep0_handle_feature(struct dwc3 *dwc,
u32 wIndex;
u32 reg;
int ret;
+ enum usb_device_state state;
wValue = le16_to_cpu(ctrl-wValue);
wIndex = le16_to_cpu(ctrl-wIndex);
recip = ctrl-bRequestType USB_RECIP_MASK;
+ state = usb_gadget_get_state(dwc-gadget);
+
switch (recip) {
case USB_RECIP_DEVICE:
@@ -409,7 +412,7 @@ static int dwc3_ep0_handle_feature(struct dwc3 *dwc,
* default control pipe
*/
case USB_DEVICE_U1_ENABLE:
- if (dwc-dev_state != DWC3_CONFIGURED_STATE)
+ if (state != USB_STATE_CONFIGURED)
return -EINVAL;
if (dwc-speed != DWC3_DSTS_SUPERSPEED)
return -EINVAL;
@@ -423,7 +426,7 @@ static int dwc3_ep0_handle_feature(struct dwc3 *dwc,
break;
case USB_DEVICE_U2_ENABLE:
- if (dwc-dev_state != DWC3_CONFIGURED_STATE)
+ if (state != USB_STATE_CONFIGURED)
return -EINVAL;
if (dwc-speed != DWC3_DSTS_SUPERSPEED)
return -EINVAL;
@@ -493,6 +496,7 @@ static int dwc3_ep0_handle_feature(struct dwc3 *dwc,
static int dwc3_ep0_set_address(struct dwc3 *dwc, struct usb_ctrlrequest *ctrl)
{
+ enum usb_device_state state = usb_gadget_get_state(dwc-gadget);
u32 addr;
u32 reg;
@@ -502,7 +506,7 @@ static int dwc3_ep0_set_address(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
return -EINVAL;
}
- if (dwc-dev_state == DWC3_CONFIGURED_STATE) {
+ if (state == USB_STATE_CONFIGURED) {
dev_dbg(dwc-dev, trying to set address when configured\n);
return -EINVAL;
}
@@ -512,13 +516,10 @@ static int dwc3_ep0_set_address(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
reg |= DWC3_DCFG_DEVADDR(addr);
dwc3_writel(dwc-regs, DWC3_DCFG, reg);
- if (addr) {
- dwc-dev_state = DWC3_ADDRESS_STATE;
+ if (addr)
usb_gadget_set_state(dwc-gadget, USB_STATE_ADDRESS);
- } else {
-
Re: [RESEND PATCH v5 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
Peter Chen peter.c...@freescale.com writes:
On Thu, Jan 24, 2013 at 05:25:17PM +0200, Alexander Shishkin wrote:
Peter Chen peter.c...@freescale.com writes:
The main design flow is the same with msm otg driver, that is the id and
vbus interrupt are handled at core driver, others are handled by
individual drivers.
- At former design, when switch usb role from device-host, it will call
udc_stop, it will remove the gadget driver, so when switch role
from host-device, it can't add gadget driver any more.
At new design, when role switch occurs, the gadget just calls
usb_gadget_vbus_disconnect/usb_gadget_vbus_connect as well as
reset controller, it will not free any device/gadget structure
- Add vbus connect and disconnect to core interrupt handler, it can
notify udc driver by calling usb_gadget_vbus_disconnect
/usb_gadget_vbus_connect.
Signed-off-by: Peter Chen peter.c...@freescale.com
[snip]
@@ -483,6 +614,17 @@ static int ci_hdrc_probe(struct platform_device *pdev)
goto rm_wq;
}
+ otgsc = hw_read(ci, OP_OTGSC, ~0);
+ /*
+ * if it is device mode:
+ * - Enable vbus detect
+ * - If it has already connected to host, notify udc
+ */
+ if (ci-role == CI_ROLE_GADGET) {
+ ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
+ ci_handle_vbus_change(ci);
+ }
+
Actually, this doesn't work, neither here, nor in udc_start(), where the
next patch moves it. If you start in host role with A plug, unplug it,
plug B and load a gadget module,
When we unplug A, device's role start will be called, that is
udc_id_switch_for_device in my patch, it will enable vbus interrupt.
Then, when we plug B, there will be an vbus interrupt, then the
ci-vbus_active will be set, then when we load a gadget module,
the enumeration will begin like I said at last email.
What doesn't happen is the reset into device mode (unless you have
_REGS_SHARED set, which by the way seems a bit misleading) and we're
still doing nothing till the vbus interrupt comes. So the REGS_SHARED is
the real problem in this case.
Now, looking at ci13xxx_{start,stop}(), I'm seeing some more code
duplication. What do think about something like this (untested):
---cut---
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index dcac77c..38446de 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1351,6 +1351,28 @@ static const struct usb_ep_ops usb_ep_ops = {
.fifo_flush= ep_fifo_flush,
};
+static int hw_device_connect(struct ci13xxx *ci, int connect)
+{
+ int ret;
+
+ if (connect) {
+ pm_runtime_get_sync(ci-gadget.dev);
+ ret = hw_device_reset(ci, USBMODE_CM_DC);
+ hw_device_state(ci, ci-ep0out-qh.dma);
+ dev_dbg(ci-dev, Connected to host\n);
+ } else {
+ hw_device_state(ci, 0);
+ if (ci-platdata-notify_event)
+ ci-platdata-notify_event(ci,
+ CI13XXX_CONTROLLER_STOPPED_EVENT);
+ ret = _gadget_stop_activity(ci-gadget);
+ pm_runtime_put_sync(ci-gadget.dev);
+ dev_dbg(ci-dev, Disconnected from host\n);
+ }
+
+ return ret;
+}
+
/**
* GADGET block
*/
@@ -1358,7 +1380,7 @@ static int ci13xxx_vbus_session(struct usb_gadget
*_gadget, int is_active)
{
struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
unsigned long flags;
- int gadget_ready = 0;
+ int gadget_ready = 0, ret = 0;
spin_lock_irqsave(ci-lock, flags);
ci-vbus_active = is_active;
@@ -1366,24 +1388,10 @@ static int ci13xxx_vbus_session(struct usb_gadget
*_gadget, int is_active)
gadget_ready = 1;
spin_unlock_irqrestore(ci-lock, flags);
- if (gadget_ready) {
- if (is_active) {
- pm_runtime_get_sync(_gadget-dev);
- hw_device_reset(ci, USBMODE_CM_DC);
- hw_device_state(ci, ci-ep0out-qh.dma);
- dev_dbg(ci-dev, Connected to host\n);
- } else {
- hw_device_state(ci, 0);
- if (ci-platdata-notify_event)
- ci-platdata-notify_event(ci,
- CI13XXX_CONTROLLER_STOPPED_EVENT);
- _gadget_stop_activity(ci-gadget);
- pm_runtime_put_sync(_gadget-dev);
- dev_dbg(ci-dev, Disconnected from host\n);
- }
- }
+ if (gadget_ready)
+ ret = hw_device_connect(ci, is_active);
- return 0;
+ return ret;
}
static int ci13xxx_wakeup(struct usb_gadget *_gadget)
@@ -1546,20 +1554,9 @@
Re: [V5 PATCH 24/26] usb: gadget: mv_udc: add device tree support
On Fri, Jan 25, 2013 at 02:13:54AM +, chao xie wrote:
2013/1/24 Mark Rutland mark.rutl...@arm.com:
Hello,
On Thu, Jan 24, 2013 at 06:38:48AM +, Chao Xie wrote:
In original driver, we have callbacks in platform data, and some
dynamically allocations variables in platform data.
Now, these blocks are removed, the device tree support is easier
now.
Please could you also add a binding document? See
Documentation/devicetree/bindings/usb for examples of existing bindings.
Also, please Cc devicetree-discuss when introducing a new binding as you are
doing here.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/gadget/mv_udc.h |5 +-
drivers/usb/gadget/mv_udc_core.c | 106
++
2 files changed, 86 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index 50ae7c7..de84722 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -179,6 +179,7 @@ struct mv_udc {
int irq;
unsigned intextern_attr;
+ unsigned intmode;
struct notifier_block notifier;
struct mv_cap_regs __iomem *cap_regs;
@@ -222,11 +223,9 @@ struct mv_udc {
struct mv_usb2_phy *phy;
struct usb_phy *transceiver;
- struct mv_usb_platform_data *pdata;
-
/* some SOC has mutiple clock sources for USB*/
unsigned intclknum;
- struct clk *clk[0];
+ struct clk **clk;
};
/* endpoint data structure */
diff --git a/drivers/usb/gadget/mv_udc_core.c
b/drivers/usb/gadget/mv_udc_core.c
index 2e5907f..a4ee9a1 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -34,6 +34,7 @@
#include linux/irq.h
#include linux/platform_device.h
#include linux/clk.h
+#include linux/of.h
#include linux/platform_data/mv_usb.h
#include linux/usb/mv_usb2.h
#include asm/unaligned.h
@@ -2153,21 +2154,57 @@ static int mv_udc_remove(struct platform_device
*pdev)
return 0;
}
+static int mv_udc_parse_dt(struct platform_device *pdev,
+ struct mv_udc *udc)
+{
+ struct device_node *np = pdev-dev.of_node;
+ unsigned int clks_num;
+ int i, ret;
+ const char *clk_name;
+
+ if (!np)
+ return 1;
+
+ clks_num = of_property_count_strings(np, clocks);
+ if (clks_num 0)
+ return clks_num;
+
+ udc-clk = devm_kzalloc(pdev-dev,
+ sizeof(struct clk *) * clks_num, GFP_KERNEL);
+ if (udc-clk == NULL)
+ return -ENOMEM;
+
+ for (i = 0; i clks_num; i++) {
+ ret = of_property_read_string_index(np, clocks, i,
+ clk_name);
+ if (ret)
+ return ret;
+ udc-clk[i] = devm_clk_get(pdev-dev, clk_name);
+ if (IS_ERR(udc-clk[i]))
+ return PTR_ERR(udc-clk[i]);
I was going to ask if you couldn't use of_clk_get, but I see you want to use
the devm_* functions to handle cleanup. It seems a shame there's not a
standard
devm_of_clk_get.
It is nice to have someone to review the device tree part patches.
In fact main target of the modification is to remove the
pointers/callbacks in the platform_data, so
i can easly to add device tree support.
of_clk_get is is based on CONFIG_COMMON_CLK. of_clk_get is not simple.
The orginal way we use to
get a clock used two arguments: dev_id and con_id. The dev_id is the
name of the device.
of_clk_get need clock framework changes. It means that clock driver
need add device tree support. Now
we are doing the clock tree support for Marvell MMP SOCes, but it will
not be done in a short time.
As i think, of_clk_get still have some problems. It parses the
property's name as clocks, but it does not support
mutipile clocks. If the device driver original has two clocks, the old
way can do it as
clk_get(dev, clock 1);
clk_get(dev, clock 2);
of_clk_get can not do it. I have not asked this question in the
mailist, and i will do it soon.
I may have misunderstood here, but as far as I can see, of_clk_get supports
multiple clocks -- it even takes an index parameter:
struct clk *of_clk_get(struct device_node *np, int index)
I can see several dts files which have a clocks property with multiple clocks.
In arch/arm/boot/dts/vexpress-v2m.dtsi there's a arm,sp810 node with
multiple clocks, which I believe is dealt with by vexpress_clk_of_init in
drivers/clk/versatile/clk-vexpress.c (though this uses of_clk_get_by_name).
This also raises the issue that you expect the clocks property to be a list of
strings, while other bindings expect the clocks property to be list of
phandle/clock-specifier pairs.
It's worth taking a
Re: [V5 PATCH 26/26] usb: ehci: ehci-mv: add device tree support
[...]
@@ -170,19 +202,36 @@ static int mv_ehci_probe(struct platform_device
*pdev)
}
platform_set_drvdata(pdev, ehci_mv);
- ehci_mv-pdata = pdata;
ehci_mv-hcd = hcd;
- ehci_mv-clknum = pdata-clknum;
- for (clk_i = 0; clk_i ehci_mv-clknum; clk_i++) {
- ehci_mv-clk[clk_i] =
- devm_clk_get(pdev-dev, pdata-clkname[clk_i]);
- if (IS_ERR(ehci_mv-clk[clk_i])) {
- dev_err(pdev-dev, error get clck \%s\\n,
- pdata-clkname[clk_i]);
- retval = PTR_ERR(ehci_mv-clk[clk_i]);
- goto err_clear_drvdata;
+ retval = mv_ehci_parse_dt(pdev, ehci_mv);
+ if (retval 0) {
Is this why you returned 1 from mv_ehci_parse_dt? So you only do this if you
don't have a dt node?
If so, why not rip the check (and positive error code) out of
mv_ehci_parse_dt,
and then here:
if (pdev-dev.of_node) {
retval = mv_ehci_parse_dt(pdev, ehci_mv);
} else
fall back to mv_usb_platform_data ...
}
That makes it obvious that one side depends on dt and the other's a
fallback,
and doesn't rely on nonstandard return code behaviour.
I will change it.
Also, why not return immediately if mv_ehci_parse_dt fails?
I do not understand. if mv_ehci_parse_dt returns negative value, the
probe will be finished immediately.
Yes, you're right. I got myself confused about the logic.
Thanks,
Mark.
--
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
[PATCH v4 2/4] ARM: OMAP: devices: create device for usb part of control module
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5e304d0..6a450a3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include linux/platform_data/omap_ocp2scp.h
+#include linux/usb/omap_control_usb.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)
#endif
}
+#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+ .type = 1,
+};
+
+struct resource omap4_control_usb_res[] = {
+ {
+ .name = control_dev_conf,
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = otghs_control,
+ .start = 0x4a00233c,
+ .end= 0x4a00233f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap4_control_usb = {
+ .name = omap-control-usb,
+ .id = -1,
+ .dev = {
+ .platform_data = omap4_control_usb_pdata,
+ },
+ .num_resources = 2,
+ .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+ if (!cpu_is_omap44xx())
+ return;
+
+ if (platform_device_register(omap4_control_usb))
+ pr_err(Error registering omap_control_usb device\n);
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
{
@@ -721,6 +765,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+ omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
--
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
[PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy will be removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 30 +-
Documentation/devicetree/bindings/usb/usb-phy.txt |5 +
drivers/usb/phy/Kconfig| 10 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-control-usb.c | 295
include/linux/usb/omap_control_usb.h | 92 ++
6 files changed, 432 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/phy/omap-control-usb.c
create mode 100644 include/linux/usb/omap_control_usb.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..2d8c6c4 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
@@ -16,6 +16,10 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+Optional properties:
+ - ctrl-module : phandle of the control module this glue uses to write to
+ mailbox
+
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
@@ -23,6 +27,7 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
multipoint = 1;
num_eps = 16;
ram_bits = 12;
+ ctrl-module = omap_control_usb;
};
Board specific device node entry
@@ -31,3 +36,26 @@ Board specific device node entry
mode = 3;
power = 50;
};
+
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be ti,omap-control-usb
+ - reg : Address and length of the register set for the device. It contains
+ the address of control_dev_conf and otghs_control or phy_power_usb
+ depending upon omap4 or omap5.
+ - reg-names: The names of the register addresses corresponding to the
registers
+ filled in reg.
+ - ti,type: This is used to differentiate whether the control module has
+ usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
+ notify events to the musb core and omap5 has usb3 phy power register to
+ power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
+ phy power.
+
+omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,type = 1;
+};
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..2466b6f 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -8,10 +8,15 @@ Required properties:
add the address of control module dev conf register until a driver for
control module is added
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+ the PHY.
+
This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
+ ctrl-module = omap_control_usb;
};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 36a85b6..65b6a80 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -14,6 +14,16 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_CONTROL_USB
+ tristate OMAP CONTROL USB Driver
+ depends on ARCH_OMAP2PLUS
+ help
+ Enable this to add support for the USB part present in the control
+ module. This driver has API to power on the USB2 PHY and to write to
+ the mailbox. The mailbox is present only in omap4 and the register to
+ power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
+ additional register to power on USB3 PHY.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index ec304f6..ee97767 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_CONTROL_USB) += omap-control-usb.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) +=
[PATCH v4 4/4] drivers: usb: start using the control module driver
Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++
Documentation/devicetree/bindings/usb/usb-phy.txt |7 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13
drivers/usb/musb/Kconfig |1 +
drivers/usb/musb/omap2430.c| 68 +++-
drivers/usb/musb/omap2430.h|9 ---
drivers/usb/phy/Kconfig|1 +
drivers/usb/phy/omap-usb2.c| 41 +++-
include/linux/usb/omap_usb.h |4 +-
9 files changed, 40 insertions(+), 108 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 2d8c6c4..704b684 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,6 +3,9 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
- ti,hwmods : must be usb_otg_hs
+ - ti,has-mailbox : to specify that omap uses an external mailbox
+ (in control module) to communicate with the musb core during device connect
+ and disconnect.
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num_eps : Specifies the number of endpoints. This is also a
@@ -24,6 +27,7 @@ SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
ti,hwmods = usb_otg_hs;
+ ti,has-mailbox;
multipoint = 1;
num_eps = 16;
ram_bits = 12;
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 2466b6f..48761a2 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -4,9 +4,7 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be ti,omap-usb2
- - reg : Address and length of the register set for the device. Also
-add the address of control module dev conf register until a driver for
-control module is added
+ - reg : Address and length of the register set for the device.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,7 +14,6 @@ This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
- reg = 0x4a0ad080 0x58,
- 0x4a002300 0x4;
+ reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 129d508..103f4ba 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2698,13 +2698,6 @@ static struct resource omap44xx_usb_phy_and_pll_addrs[]
= {
.end= 0x4a0ae000,
.flags = IORESOURCE_MEM,
},
- {
- /* XXX: Remove this once control module driver is in place */
- .name = ctrl_dev,
- .start = 0x4a002300,
- .end= 0x4a002303,
- .flags = IORESOURCE_MEM,
- },
{ }
};
@@ -6152,12 +6145,6 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
- {
- /* XXX: Remove this once control module driver is in place */
- .pa_start = 0x4a00233c,
- .pa_end = 0x4a00233f,
- .flags = ADDR_TYPE_RT
- },
{ }
};
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 23a0b7f..de6e5ce 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -11,6 +11,7 @@ config USB_MUSB_HDRC
select NOP_USB_XCEIV if (SOC_TI81XX || SOC_AM33XX)
select TWL4030_USB if MACH_OMAP_3430SDP
select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
+ select OMAP_CONTROL_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
select USB_OTG_UTILS
help
Say Y here if your system has a dual role high speed USB
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index da00af4..88a601b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -37,6 +37,7 @@
#include linux/err.h
#include linux/delay.h
#include linux/usb/musb-omap.h
+#include linux/usb/omap_control_usb.h
#include musb_core.h
#include omap2430.h
@@ -46,7 +47,7 @@ struct omap2430_glue {
struct
[PATCH v4 0/4] usb: musb/dwc3: add driver for control module
Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Also added an API to power on usb3 phy (omap5). Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Changes from v3: * Changed property names from ti,has_mailbox to ti,has-mailbox and ctrl_module to ctrl-module * Fixed a compiler warning. Changes from v2: * removed ti,has_mailbox and added ti,type to differentiate whether the control module has usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to notify events to the musb core and omap5 has usb3 phy power register to power on usb3 phy. * Added an API to power on USB3 PHY needed for OMAP5. Changes from v1: * renamed get_omap_control_dev to omap_get_control_dev * created and exported a single API (omap_control_usb_set_mode) to change the usb mode * Before writing to the otghs_control regster, the value from otghs_control regster is read and only the appropriate bits are set. * In omap_init_control_usb, the indentation is now reduced as per Felipe's suggestion. Changes from RFC: * Used #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB) instead of #if (defined(CONFIG_OMAP_CONTROL_USB) || \ defined(CONFIG_OMAP_CONTROL_USB_MODULE)) * return -EADDRNOTAVAIL if devm_request_and_ioremap fails. * Removed the dt data from this patch series (I'll send that as a separate series). * added ctrl_module binding to usb otg glue and usb phy in the Documentaion. This binding is not planned to be used until an actual requirement for it arises. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv I've kept this patch series and all the patch series to follow in a single branch git://gitorious.org/linux-usb/linux-usb.git omap5-with-palmas (changes up to 23b4dfa2ab7052569cd88acc6383c4b1a8e8a482) Did basic enumeration testing in omap4 panda, omap3 beagle and omap5 evm. Kishon Vijay Abraham I (4): drivers: usb: phy: add a new driver for usb part of control module ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox drivers: usb: start using the control module driver Documentation/devicetree/bindings/usb/omap-usb.txt | 34 ++- Documentation/devicetree/bindings/usb/usb-phy.txt | 12 +- arch/arm/mach-omap2/devices.c | 45 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 - arch/arm/mach-omap2/usb-musb.c |3 + drivers/usb/musb/Kconfig |1 + drivers/usb/musb/omap2430.c| 68 ++--- drivers/usb/musb/omap2430.h|9 - drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-control-usb.c | 295 drivers/usb/phy/omap-usb2.c| 41 +-- include/linux/usb/musb.h |2 + include/linux/usb/omap_control_usb.h | 92 ++ include/linux/usb/omap_usb.h |4 +- 15 files changed, 522 insertions(+), 109 deletions(-) create mode 100644 drivers/usb/phy/omap-control-usb.c create mode 100644 include/linux/usb/omap_control_usb.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
[PATCH v3 1/3] ARM: dts: omap: Add omap control usb data
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..ffc7352 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,13 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,type = 1;
+ };
};
};
--
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
[PATCH v3 3/3] ARM: dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
The information about usb otg node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |2 ++
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3-overo.dtsi |6 ++
arch/arm/boot/dts/omap3.dtsi | 12
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi | 13 +
arch/arm/boot/dts/twl4030.dtsi |2 +-
9 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index b36df59..b892f58 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -18,6 +18,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -32,6 +33,7 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num_eps = 16;
ram_bits = 12;
ctrl-module = omap_control_usb;
+ usb-phy = usb2_phy;
};
Board specific device node entry
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
*/
ti,pulldowns = 0x03a1c4;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..176561b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usb_otg_hs: usb_otg_hs@480ab000 {
+ compatible = ti,omap3-musb;
+ reg = 0x480ab000 0x1000;
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ usb-phy = usb2_phy;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c829d7e..ab817a2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = control_dev_conf, otghs_control;
ti,type = 1;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ reg = 0x4a0ab000 0x7ff;
+ interrupts = 0 92 0x4, 0 93 0x4;
+
Re: [PATCH v4 4/4] drivers: usb: start using the control module driver
Hi, On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote: Start using the control module driver for powering on the PHY and for writing to the mailbox instead of writing to the control module registers on their own. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++ Documentation/devicetree/bindings/usb/usb-phy.txt |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c change just to kill dependency. Can you send that single change as a separate patch which Tony can queue ? -- balbi signature.asc Description: Digital signature
[PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
This patch series adds dt data to get MUSB working in omap4 and omap3. Long time back a patch series with the same title was sent but only a part of it got merged. The rest of it wasn't merged because of adding omap control usb data to glue and usb phy. Now there exists a separate driver for control usb and hence added a separate dt node for control usb. Changes from v2: * Changed property names from ti,has_mailbox to ti,has-mailbox, ctrl_module to ctrl-module, usb_phy to usb-phy Changes from v1: * ti,has_mailbox property is removed and ti,type property is added and filled with value 1 to specify it has a mailbox This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv + usb: musb: add driver for control module patch series Did basic enumeration testing in omap4 panda, omap4 sdp and omap3 beagle. Kishon Vijay Abraham I (3): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data Documentation/devicetree/bindings/usb/omap-usb.txt |2 ++ arch/arm/boot/dts/omap3-beagle-xm.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3-overo.dtsi |6 + arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 + arch/arm/boot/dts/omap4-sdp.dts|6 + arch/arm/boot/dts/omap4.dtsi | 26 arch/arm/boot/dts/twl4030.dtsi |2 +- 9 files changed, 71 insertions(+), 1 deletion(-) -- 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
[PATCH v3 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
There were some comments w.r.t this patch for returning EPROBE_DEFER if
not able to get the phy, in my previous version.
Currently we can't have that because the gadget driver doesn't do a
EPROBE_DEFER. We have a separate activity planned for making gadget driver
also do EPROBE_DEFER for 3.10.
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index be6d259..08814d2 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ if (dev-parent-of_node)
+ musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+ usb-phy, 0);
+ else
+ musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
--
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
[PATCH v4 2/2] usb: phy: omap-usb2: enable 960Mhz clock for omap5
usb_otg_ss_refclk960m is needed for usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/phy/omap-usb2.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 0cd88ac..844ab68 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -166,6 +166,12 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk))
+ dev_vdbg(pdev-dev, unable to get refclk960m\n);
+ else
+ clk_prepare(phy-optclk);
+
usb_add_phy_dev(phy-phy);
platform_set_drvdata(pdev, phy);
@@ -180,6 +186,8 @@ static int omap_usb2_remove(struct platform_device *pdev)
struct omap_usb *phy = platform_get_drvdata(pdev);
clk_unprepare(phy-wkupclk);
+ if (!IS_ERR(phy-optclk))
+ clk_unprepare(phy-optclk);
usb_remove_phy(phy-phy);
return 0;
@@ -193,6 +201,8 @@ static int omap_usb2_runtime_suspend(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
clk_disable(phy-wkupclk);
+ if (!IS_ERR(phy-optclk))
+ clk_disable(phy-optclk);
return 0;
}
@@ -204,9 +214,25 @@ static int omap_usb2_runtime_resume(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
ret = clk_enable(phy-wkupclk);
- if (ret 0)
+ if (ret 0) {
dev_err(phy-dev, Failed to enable wkupclk %d\n, ret);
+ goto err0;
+ }
+
+ if (!IS_ERR(phy-optclk)) {
+ ret = clk_enable(phy-optclk);
+ if (ret 0) {
+ dev_err(phy-dev, Failed to enable optclk %d\n, ret);
+ goto err1;
+ }
+ }
+
+ return 0;
+
+err1:
+ clk_disable(phy-wkupclk);
+err0:
return ret;
}
--
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
[PATCH v4 0/2] usb: phy: add usb3 phy driver
Apologies for the delay in sending this version. Added a driver for usb3 phy that handles the interaction between usb phy device and dwc3 controller. Changes from v3: * Changed the property name from ctrl_module to ctrl-module Changes from v2: * used control module driver APIs to write to control module register. * Added pm_runtime_put and pm_runtime_disable in the usb3 phy driver. * Added checks for enabling and disabling usb_otg_ss_refclk960m so that it doesn't break omap4. Changes from v1: * Added missing clk_put() * Remove the patches usb: dwc3: Fix gadget pullup in SS mode and usb: phy: omap-usb3: Decrease the number of transitions to recovery. Those are actually WA for hw issues which will be fixed in ES2. * Removed the *has960mhzclk* property This patch series is developed on git://github.com/rrnayak/linux.git omap5-3.8-rc4-base-palmas I've kept this patch series and the patch series to follow in a single branch git://gitorious.org/linux-usb/linux-usb.git omap5-with-palmas (changes up to 23b4dfa2ab7052569cd88acc6383c4b1a8e8a482) Did enumeration testing on omap4 panda and omap5 evm. Kishon Vijay Abraham I (2): usb: phy: add a new driver for usb3 phy usb: phy: omap-usb2: enable 960Mhz clock for omap5 Documentation/devicetree/bindings/usb/usb-phy.txt | 23 ++ drivers/usb/phy/Kconfig | 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 28 +- drivers/usb/phy/omap-usb3.c | 355 + include/linux/usb/omap_usb.h | 23 ++ 6 files changed, 439 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/phy/omap-usb3.c -- 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
[PATCH v4 1/2] usb: phy: add a new driver for usb3 phy
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 23 ++
drivers/usb/phy/Kconfig | 10 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb3.c | 355 +
include/linux/usb/omap_usb.h | 23 ++
5 files changed, 412 insertions(+)
create mode 100644 drivers/usb/phy/omap-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 48761a2..2229eab 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -17,3 +17,26 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
};
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb3
+ - reg : Address and length of the register set for the device.
+ - reg-names: The names of the register addresses corresponding to the
registers
+ filled in reg.
+
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+ the PHY.
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_usb;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2122030..6566eae 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -15,6 +15,16 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_USB3
+ tristate OMAP USB3 PHY Driver
+ select USB_OTG_UTILS
+ select OMAP_CONTROL_USB
+ help
+ Enable this to support the USB3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the OMAP Control USB Driver to power
+ on/off the PHY.
+
config OMAP_CONTROL_USB
tristate OMAP CONTROL USB Driver
depends on ARCH_OMAP2PLUS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 0dea4d2..6a07298 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_USB3)+= omap-usb3.o
obj-$(CONFIG_OMAP_CONTROL_USB) += omap-control-usb.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
new file mode 100644
index 000..fadc0c2
--- /dev/null
+++ b/drivers/usb/phy/omap-usb3.c
@@ -0,0 +1,355 @@
+/*
+ * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb/omap_usb.h
+#include linux/of.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/usb/omap_control_usb.h
+
+#defineNUM_SYS_CLKS5
+#definePLL_STATUS 0x0004
+#definePLL_GO 0x0008
+#definePLL_CONFIGURATION1 0x000C
+#definePLL_CONFIGURATION2 0x0010
+#definePLL_CONFIGURATION3 0x0014
+#definePLL_CONFIGURATION4 0x0020
+
+#definePLL_REGM_MASK 0x001FFE00
+#definePLL_REGM_SHIFT 0x9
+#definePLL_REGM_F_MASK 0x0003
+#definePLL_REGM_F_SHIFT0x0
+#definePLL_REGN_MASK
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Fri, Jan 25, 2013 at 10:23:57AM +, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy will be removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 30 +-
Documentation/devicetree/bindings/usb/usb-phy.txt |5 +
drivers/usb/phy/Kconfig| 10 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-control-usb.c | 295
include/linux/usb/omap_control_usb.h | 92 ++
6 files changed, 432 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/phy/omap-control-usb.c
create mode 100644 include/linux/usb/omap_control_usb.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..2d8c6c4 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
@@ -16,6 +16,10 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+Optional properties:
+ - ctrl-module : phandle of the control module this glue uses to write to
+ mailbox
+
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
@@ -23,6 +27,7 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
multipoint = 1;
num_eps = 16;
ram_bits = 12;
+ ctrl-module = omap_control_usb;
};
Board specific device node entry
@@ -31,3 +36,26 @@ Board specific device node entry
mode = 3;
power = 50;
};
+
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be ti,omap-control-usb
+ - reg : Address and length of the register set for the device. It contains
+ the address of control_dev_conf and otghs_control or phy_power_usb
Could you not use '-' over '_' here?
+ depending upon omap4 or omap5.
+ - reg-names: The names of the register addresses corresponding to the
registers
+ filled in reg.
+ - ti,type: This is used to differentiate whether the control module has
+ usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
+ notify events to the musb core and omap5 has usb3 phy power register to
+ power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
+ phy power.
Why not make this a string property, perhaps values mailbox or register?
That way it's easy for humans and code to verify the dts, and easy to expand
arbitrarily in future if necessary. It also means you're not leaking
kernel-side constants as an ABI.
+
+omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,type = 1;
+};
[...]
+static int omap_control_usb_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
+ struct omap_control_usb_platform_data *pdata =
pdev-dev.platform_data;
+
+ control_usb = devm_kzalloc(pdev-dev, sizeof(*control_usb),
+ GFP_KERNEL);
+ if (!control_usb) {
+ dev_err(pdev-dev, unable to alloc memory for control
usb\n);
+ return -ENOMEM;
+ }
+
+ if (np) {
+ of_property_read_u32(np, ti,type, control_usb-type);
+ } else if (pdata) {
+ control_usb-type = pdata-type;
+ } else {
+ dev_err(pdev-dev, no pdata present\n);
+ return -EINVAL;
+ }
Please do some sanity checking here on type. What if it's not
OMAP_CTRL_DEV_TYPE1 or OMAP_CTRL_DEV_TYPE2?
What if the values for OMAP_CTRL_DEV_TYPE{1,2} change? The binding will be
broken.
If you change ti,type to a string, the parsing also becomes sanity checking:
if (np) {
char *type;
if (of_property_read_string(np, ti,type, type) != 0)
return -EINVAL;
if (strcmp(type, mailbox) == 0)
control_usb-type = OMAP_CTRL_DEV_TYPE1;
else if (strcmp(type, register) == 0)
control_usb-type = OMAP_CTRL_DEV_TYPE2;
else
return -EINVAL;
} else {
... pdata case ...
}
Also, TYPE1 and TYPE2 aren't very descriptive. These could probably be better
named.
+
+ control_usb-dev= pdev-dev;
+
+ res =
[PATCH v4 09/11] usb: dwc3: core: add dt support for dwc3 core
Added dt support for dwc3 core and update the documentation with
device tree binding information. Getting a PHY is now done using
devm_usb_get_phy_by_phandle() for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 22 ++
drivers/usb/dwc3/core.c| 24
2 files changed, 42 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
new file mode 100644
index 000..5e68eb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -0,0 +1,22 @@
+synopsys DWC3 CORE
+
+DWC3- USB3 CONTROLLER
+
+Required properties:
+ - compatible: must be synopsys,dwc3
+ - reg : Address and length of the register set for the device
+ - interrupts: Interrupts used by the dwc3 controller.
+ - usb-phy : array of phandle for the PHY device
+
+Optional properties:
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+
+This is usually a subnode to DWC3 glue to which it is connected.
+
+dwc3@4a03 {
+ compatible = synopsys,dwc3;
+ reg = 0x4a03 0xcfff;
+ interrupts = 0 92 4
+ usb-phy = usb2_phy, usb3,phy;
+ tx-fifo-resize;
+};
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3a4004a..c1fb6d2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -420,13 +420,19 @@ static int dwc3_probe(struct platform_device *pdev)
return -ENOMEM;
}
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (node) {
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ } else {
+ dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ }
+
if (IS_ERR_OR_NULL(dwc-usb2_phy)) {
dev_err(dev, no usb2 phy configured\n);
return -EPROBE_DEFER;
}
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
if (IS_ERR_OR_NULL(dwc-usb3_phy)) {
dev_err(dev, no usb3 phy configured\n);
return -EPROBE_DEFER;
@@ -450,8 +456,7 @@ static int dwc3_probe(struct platform_device *pdev)
else
dwc-maximum_speed = DWC3_DCFG_SUPERSPEED;
- if (of_get_property(node, tx-fifo-resize, NULL))
- dwc-needs_fifo_resize = true;
+ dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -580,11 +585,22 @@ static int dwc3_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_match[] = {
+ {
+ .compatible = synopsys,dwc3
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_match);
+#endif
+
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = dwc3_remove,
.driver = {
.name = dwc3,
+ .of_match_table = of_match_ptr(of_dwc3_match),
},
};
--
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
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Fri, Jan 25, 2013 at 11:01:41AM +, Mark Rutland wrote:
On Fri, Jan 25, 2013 at 10:23:57AM +, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy will be removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 30 +-
Documentation/devicetree/bindings/usb/usb-phy.txt |5 +
drivers/usb/phy/Kconfig| 10 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-control-usb.c | 295
include/linux/usb/omap_control_usb.h | 92 ++
6 files changed, 432 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/phy/omap-control-usb.c
create mode 100644 include/linux/usb/omap_control_usb.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..2d8c6c4 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
@@ -16,6 +16,10 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+Optional properties:
+ - ctrl-module : phandle of the control module this glue uses to write to
+ mailbox
+
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
@@ -23,6 +27,7 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
multipoint = 1;
num_eps = 16;
ram_bits = 12;
+ ctrl-module = omap_control_usb;
};
Board specific device node entry
@@ -31,3 +36,26 @@ Board specific device node entry
mode = 3;
power = 50;
};
+
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be ti,omap-control-usb
+ - reg : Address and length of the register set for the device. It contains
+ the address of control_dev_conf and otghs_control or phy_power_usb
Could you not use '-' over '_' here?
that's part of omap hwmod.
+ depending upon omap4 or omap5.
+ - reg-names: The names of the register addresses corresponding to the
registers
+ filled in reg.
+ - ti,type: This is used to differentiate whether the control module has
+ usb mailbox or usb3 phy power. omap4 has usb mailbox in control module
to
+ notify events to the musb core and omap5 has usb3 phy power register to
+ power on usb3 phy. Should be 1 if it has mailbox and 2 if it has
usb3
+ phy power.
Why not make this a string property, perhaps values mailbox or register?
NAK.
--
balbi
signature.asc
Description: Digital signature
[PATCH 1/2] usb: dwc3: exynos/omap: Change platform device IDs for no_op_xceive to AUTO
Multiple dwc3 probe calls try to allocate no_op_xceive platform
device. Having static IDs for these will throw sysfs error -EEXIST.
Changing these static platform device IDs to AUTO to enable
multiple dwc3 controller support on a SoC.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c |4 ++--
drivers/usb/dwc3/dwc3-omap.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 1e95551..b50da53 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -42,7 +42,7 @@ static int dwc3_exynos_register_phys(struct dwc3_exynos
*exynos)
memset(pdata, 0x00, sizeof(pdata));
- pdev = platform_device_alloc(nop_usb_xceiv, 0);
+ pdev = platform_device_alloc(nop_usb_xceiv, PLATFORM_DEVID_AUTO);
if (!pdev)
return -ENOMEM;
@@ -53,7 +53,7 @@ static int dwc3_exynos_register_phys(struct dwc3_exynos
*exynos)
if (ret)
goto err1;
- pdev = platform_device_alloc(nop_usb_xceiv, 1);
+ pdev = platform_device_alloc(nop_usb_xceiv, PLATFORM_DEVID_AUTO);
if (!pdev) {
ret = -ENOMEM;
goto err1;
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 831b75f..22f337f 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -203,7 +203,7 @@ static int dwc3_omap_register_phys(struct dwc3_omap *omap)
memset(pdata, 0x00, sizeof(pdata));
- pdev = platform_device_alloc(nop_usb_xceiv, 0);
+ pdev = platform_device_alloc(nop_usb_xceiv, PLATFORM_DEVID_AUTO);
if (!pdev)
return -ENOMEM;
@@ -214,7 +214,7 @@ static int dwc3_omap_register_phys(struct dwc3_omap *omap)
if (ret)
goto err1;
- pdev = platform_device_alloc(nop_usb_xceiv, 1);
+ pdev = platform_device_alloc(nop_usb_xceiv, PLATFORM_DEVID_AUTO);
if (!pdev) {
ret = -ENOMEM;
goto err1;
--
1.7.6.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
[PATCH 0/2] usb: dwc3: Change platform device IDs to AUTO
Multiple dwc3 controllers will try to allocate multiple platform devices for no_op_xceive (for usb2_phy and usb3_phy) as well as xhci-hcd. This patchset updates the platform devices IDs for allocated devices to AUTO in order to support multiple dwc3 controllers. This is based on 'dwc3' branch of Felipe Balbi's usb tree. Vivek Gautam (2): usb: dwc3: exynos/omap: Change platform device IDs for no_op_xceive to AUTO usb: dwc3: host: Change platform device ID for xhci-hcd to AUTO drivers/usb/dwc3/dwc3-exynos.c |4 ++-- drivers/usb/dwc3/dwc3-omap.c |4 ++-- drivers/usb/dwc3/host.c|2 +- 3 files changed, 5 insertions(+), 5 deletions(-) -- 1.7.6.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
[PATCH 2/2] usb: dwc3: host: Change platform device ID for xhci-hcd to AUTO
Multiple dwc3 controllers will try to allocate multiple xhci-hcd
interfaces.
Changing platform device IDs from NONE to AUTO to support
such cases.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 56a6234..0fa1846 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -44,7 +44,7 @@ int dwc3_host_init(struct dwc3 *dwc)
struct platform_device *xhci;
int ret;
- xhci = platform_device_alloc(xhci-hcd, -1);
+ xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
ret = -ENOMEM;
--
1.7.6.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
Re: [PATCH v4 4/4] drivers: usb: start using the control module driver
On Friday 25 January 2013 03:57 PM, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote: Start using the control module driver for powering on the PHY and for writing to the mailbox instead of writing to the control module registers on their own. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++ Documentation/devicetree/bindings/usb/usb-phy.txt |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c change just to kill dependency. Can you send that single change as a separate patch which Tony can queue ? Sure. Thanks Kishon -- 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
[balbi-usb:xceiv 16/20] warning: (USB_MUSB_HDRC ..) selects OMAP_CONTROL_USB which has unmet direct dependencies (USB_SUPPORT ..)
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv head: 5088b6f5bcf1747345ef9fe217fc80935b1b07df commit: 57f6ce072e35770a63be0c5d5e82f90d8da7d665 [16/20] usb: phy: add a new driver for usb3 phy config: make ARCH=x86_64 allyesconfig All warnings: warning: (USB_MUSB_HDRC OMAP_USB3) selects OMAP_CONTROL_USB which has unmet direct dependencies (USB_SUPPORT ARCH_OMAP2PLUS) warning: (USB_MUSB_HDRC OMAP_USB3) selects OMAP_CONTROL_USB which has unmet direct dependencies (USB_SUPPORT ARCH_OMAP2PLUS) warning: (USB_MUSB_HDRC OMAP_USB3) selects OMAP_CONTROL_USB which has unmet direct dependencies (USB_SUPPORT ARCH_OMAP2PLUS) --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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
Re: [PATCH net] net: usbnet: prevent buggy devices from killing us
On Friday 25 January 2013 08:13:15 Bjørn Mork wrote: Oliver Neukum oli...@neukum.org writes: On Thursday 24 January 2013 20:16:56 Bjørn Mork wrote: A device sending 0 length frames as fast as it can has been observed killing the host system due to the resulting memory pressure. Temporarily disable RX skb allocation and URB submission when the current error ratio is high, preventing us from trying to allocate an infinite number of skbs. Reenable as soon as we are finished processing the done queue, allowing the device to continue working after short error bursts. Signed-off-by: Bjørn Mork bj...@mork.no --- So is this starting to look OK? It seems to me that we at least need to try some error recovery. Won't the disabling code in usbnet_bh do? RX will only stay disabled until the done queue is handled. So will the burst of bogus packets stop by itself? How about resetting the device when it is no longer used? Yes, that we should do. I guess usbnet_open is the place to reset the flag and counters? I'll send another version taking care of this and Joes comment. I was thinking about resetting the device, not just counters. But yes, open() needs to reset the counters, too. Regards Oliver -- 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
Re: [RESEND PATCH v5 4/7] usb: chipidea: consolidate ci_role_driver's API for both roles
Peter Chen peter.c...@freescale.com writes:
On Thu, Jan 24, 2013 at 04:35:30PM +0200, Alexander Shishkin wrote:
Peter Chen peter.c...@freescale.com writes:
- Create init/destroy API for probe and remove
- start/stop API are only used otg id switch process
- Create the gadget at ci_hdrc_probe if the gadget is supported
at that port, the main purpose for this is to avoid gadget module
load fail at init.rc
I don't think it's necessary to mention android-specific init scripts
here in our patches.
Ok, will just mention init script.
+static inline void ci_role_destroy(struct ci13xxx *ci)
+{
+ enum ci_role role = ci-role;
+
+ if (role == CI_ROLE_END)
+ return;
+
+ ci-role = CI_ROLE_END;
+
+ ci-roles[role]-destroy(ci);
+}
What does this do? It should take role an a parameter, at least. Or it
can be called ci_roles_destroy() and, well, destroy all the roles. Now
we're in a situation where we destroy one.
Yes, this function has some problems, I suggest just call two lines at
ci_role_destory, do you think so?
ci-roles[role]-destroy(ci);
ci-role = CI_ROLE_END;
I just don't see why it's needed at all. See below.
The idea is that, with this api, we can (and should) have both roles
allocated all the time, but only one role start()'ed.
What we can do here is move the udc's .init() code to
ci_hdrc_gadget_init() and add a complementary ci_hdrc_gadget_destroy(),
which we call in ci_hdrc_remove() and probe's error path. And we can
probably do something similar for the host, or just leave it as it is
now. Seems simpler to me.
Yes, current code has bug that it should call ci_role_destroy at probe's
error path.
For your comments, it still needs to add destory function for udc which will
be called at core.c. I still prefer current way due to below reasons:
- It can keep ci_hdrc_gadget_init() clean
- .init and .remove are different logical function with .start and .stop.
The .init and .remove are used for create and destroy, .start and .stop
are used at id role switch.
True, and we can keep it that way: (again, untested)
---cut---
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 342b430..36f495a 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -67,18 +67,14 @@ enum ci_role {
/**
* struct ci_role_driver - host/gadget role driver
- * init: init this role (used at module probe)
* start: start this role (used at id switch)
* stop: stop this role (used at id switch)
- * destroy: destroy this role (used at module remove)
* irq: irq handler for this role
* name: role name string (host/gadget)
*/
struct ci_role_driver {
- int (*init)(struct ci13xxx *);
int (*start)(struct ci13xxx *);
void(*stop)(struct ci13xxx *);
- void(*destroy)(struct ci13xxx *);
irqreturn_t (*irq)(struct ci13xxx *);
const char *name;
};
@@ -212,17 +208,6 @@ static inline void ci_role_stop(struct ci13xxx *ci)
ci-roles[role]-stop(ci);
}
-static inline void ci_role_destroy(struct ci13xxx *ci)
-{
- enum ci_role role = ci-role;
-
- if (role == CI_ROLE_END)
- return;
-
- ci-role = CI_ROLE_END;
-
- ci-roles[role]-destroy(ci);
-}
/**
* REGISTERS
*/
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a61e759..83f35fa 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -402,6 +402,12 @@ static ssize_t store_role(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ /*
+* there won't be an interrupt in case of manual switching,
+* so we need to check vbus session manually
+*/
+ ci_handle_vbus_change(ci);
+
return count;
}
@@ -592,30 +598,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
otgsc = hw_read(ci, OP_OTGSC, ~0);
- /*
-* If the gadget is supported, call its init unconditionally,
-* We need to support load gadget module at init.rc.
-*/
- if (ci-roles[CI_ROLE_GADGET]) {
- ret = ci-roles[CI_ROLE_GADGET]-init(ci);
- if (ret) {
- dev_err(dev, can't init %s role, ret=%d\n,
- ci_role(ci)-name, ret);
- ret = -ENODEV;
- goto rm_wq;
- }
- }
-
- if (ci-role == CI_ROLE_HOST) {
- ret = ci-roles[CI_ROLE_HOST]-init(ci);
- if (ret) {
- dev_err(dev, can't init %s role, ret=%d\n,
- ci_role(ci)-name, ret);
- ret = -ENODEV;
- goto
composite.c:1156 warn: calling potential NULL 'f-set_alt()'
I'm working on some new Smatch stuff and I hit the following problem
which I don't know how to fix.
drivers/usb/gadget/composite.c:1156 composite_setup()
warn: calling potential NULL 'f-set_alt()'
drivers/usb/gadget/composite.c
1143 /* function drivers must handle get/set altsetting; if there's
1144 * no get() method, we know only altsetting zero works.
The comment says we should check -get.
1145 */
1146 case USB_REQ_SET_INTERFACE:
1147 if (ctrl-bRequestType != USB_RECIP_INTERFACE)
1148 goto unknown;
1149 if (!cdev-config || intf = MAX_CONFIG_INTERFACES)
1150 break;
1151 f = cdev-config-interface[intf];
1152 if (!f)
1153 break;
1154 if (w_value !f-set_alt)
^^
We used to check -get_alt() until dd4dff8b03 USB: composite: Fix bug:
should test set_alt function pointer before use it.
1155 break;
1156 value = f-set_alt(f, w_index, w_value);
If w_value is zero then -set_alt() can be NULL leading to a NULL
dereference.
1157 if (value == USB_GADGET_DELAYED_STATUS) {
1158 DBG(cdev,
1159 %s: interface %d (%s) requested delayed
status\n,
1160 __func__, intf, f-name);
1161 cdev-delayed_status++;
1162 DBG(cdev, delayed_status count %d\n,
1163 cdev-delayed_status);
1164 }
1165 break;
regards,
dan carpenter
--
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
Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
Hello.
On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:
From: fangxiaozhi huana...@huawei.com
1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
linux-3.8-rc4/drivers/usb/storage/usb.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22 14:12:42.595238727
+0800
+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22 14:16:01.398250305 +0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, supplemental l
.useTransport = use_transport, \
}
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name, \
+ .useProtocol = use_protocol, \
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}
Shouldn't the field initilaizers be indented with tab, not space?
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usual-tables.c
linux-3.8-rc4/drivers/usb/storage/usual-tables.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usual-tables.c 2013-01-22
14:12:42.594238726 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usual-tables.c 2013-01-22
14:16:01.426250199 +0800
@@ -41,6 +41,19 @@
#define USUAL_DEV(useProto, useTrans) \
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans) }
+/* Define the device is matched with Vendor ID and interface descriptors */
+#define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+ vendorName, productName, useProtocol, useTransport, \
+ initFunction, flags) \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor= (id_vendor), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr), \
+ .driver_info = (flags) }
Same question. And trailing '}' should be on a separate line.
WBR, Sergei
--
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
Re: [PATCH v3 11/11] usb: dwc3: core: stray statements are removed
Hello. On 25-01-2013 7:00, Kishon Vijay Abraham I wrote: No functional change. Stray statements where removed from dwc3 core. s/where/are/ Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/dwc3/core.c |3 --- 1 file changed, 3 deletions(-) WBR, Sergei -- 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
Re: [PATCH net] net: usbnet: prevent buggy devices from killing us
Oliver Neukum oli...@neukum.org writes: On Friday 25 January 2013 08:13:15 Bjørn Mork wrote: Oliver Neukum oli...@neukum.org writes: On Thursday 24 January 2013 20:16:56 Bjørn Mork wrote: A device sending 0 length frames as fast as it can has been observed killing the host system due to the resulting memory pressure. Temporarily disable RX skb allocation and URB submission when the current error ratio is high, preventing us from trying to allocate an infinite number of skbs. Reenable as soon as we are finished processing the done queue, allowing the device to continue working after short error bursts. Signed-off-by: Bjørn Mork bj...@mork.no --- So is this starting to look OK? It seems to me that we at least need to try some error recovery. Won't the disabling code in usbnet_bh do? RX will only stay disabled until the done queue is handled. So will the burst of bogus packets stop by itself? No, in the case I am looking at it won't. So we end up switching this off/on endlessly. But I believe that is fine. There is no way we can *know* that the errors won't stop unless we start receiving packets again. Other devices may have similar temporary bugs, making them start working again after a while. If we permanently disable RX then we will just make any such device fail for no good reason. My only wish for this patch is that it makes usbnet survive the buggy device without bringing the host down. Not magically fix the device (of course impossible), or even hide the bug in any way. A non-functional device will still appear as a non-functional device. Manual user intervention is required to make it work. This might involve a firmware upgrade for all we know... How about resetting the device when it is no longer used? Yes, that we should do. I guess usbnet_open is the place to reset the flag and counters? I'll send another version taking care of this and Joes comment. I was thinking about resetting the device, not just counters. What's the point? We only risk making the issue worse if some device has a similar temporary bug, fixing itself a while after reset. I think we should leave any such actions to the user. But yes, open() needs to reset the counters, too. OK, will add that. Bjørn -- 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
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
[...] +OMAP CONTROL USB + +Required properties: + - compatible: Should be ti,omap-control-usb + - reg : Address and length of the register set for the device. It contains + the address of control_dev_conf and otghs_control or phy_power_usb Could you not use '-' over '_' here? that's part of omap hwmod. Aha, that makes sense (unlike my original comment, now I reread it). Sorry for the noise. + depending upon omap4 or omap5. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,type: This is used to differentiate whether the control module has + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to + notify events to the musb core and omap5 has usb3 phy power register to + power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3 + phy power. Why not make this a string property, perhaps values mailbox or register? NAK. Can I ask what your objection to using a string property is? As far as I can see, ti,type is only used by this driver, so there's no common convention to stick to. Using a string makes the binding easier for humans to read, and thus harder to mess up in a dts, and it decouples the binding from kernel-side constants. Thanks, Mark. -- 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
Re: [PATCH v2 1/6] usb: otg: Add an API to bind the USB controller and PHY
On 01/25/2013 04:33 AM, Kishon Vijay Abraham I wrote:
In order to support platforms which has multiple PHY's (of same type) and
which has multiple USB controllers, a new design is adopted wherin the binding
information (between the PHY and the USB controller) should be passed to the
PHY library from platform specific file (board file).
So added a new API to pass the binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 37 +
include/linux/usb/phy.h | 22 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..8e756d9 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -18,6 +18,7 @@
#include linux/usb/otg.h
static LIST_HEAD(phy_list);
+static LIST_HEAD(phy_bind_list);
static DEFINE_SPINLOCK(phy_lock);
static struct usb_phy *__usb_find_phy(struct list_head *list,
@@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
}
EXPORT_SYMBOL(usb_remove_phy);
+/**
+ * usb_bind_phy - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+int __init usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ struct usb_phy_bind *phy_bind;
+ unsigned long flags;
+
+ phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+ if (!phy_bind) {
+ pr_err(phy_bind(): No memory for phy_bind);
nitpick. Function name is usb_bind_phy() and you don't need to mention it twice
;).
Is it even needed to print here as the user would most likely print it anyways.
At least
the user can decide if it needs to be printed or not.
+ return -ENOMEM;
+ }
+
+ phy_bind-dev_name = dev_name;
+ phy_bind-phy_dev_name = phy_dev_name;
+ phy_bind-index = index;
+
+ spin_lock_irqsave(phy_lock, flags);
+ list_add_tail(phy_bind-list, phy_bind_list);
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_bind_phy);
+
const char *otg_state_string(enum usb_otg_state state)
{
switch (state) {
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..e7eb429 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -106,6 +106,21 @@ struct usb_phy {
enum usb_device_speed speed);
};
cheers,
-roger
--
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
Re: 3.4.4: disabling irq
On 2013-01-02 17:46, Alan Stern wrote: Or else leave those devices unplugged entirely -- use a network login instead of the USB keyboard and mouse. When the motion service is off, i.e. the USB webcam isnt used, the issue does not happen. On the other hand: If it is on, within a few days I see stuff like: Jan 25 03:08:26 s kernel: [128427.542235] irq 18: nobody cared (try booting with the irqpoll option) Jan 25 03:08:26 s kernel: [128427.542239] Pid: 1279, comm: irq/18-ohci_hcd Not tainted 3.6.11 #22 Jan 25 03:08:26 s kernel: [128427.542240] Call Trace: Jan 25 03:08:26 s kernel: [128427.542246] [8109e166] ? __report_bad_irq+0x36/0xd0 Jan 25 03:08:26 s kernel: [128427.542248] [8109e469] ? note_interrupt+0x1c9/0x220 Jan 25 03:08:26 s kernel: [128427.542250] [8109ccf0] ? irq_thread_fn+0x40/0x40 Jan 25 03:08:26 s kernel: [128427.542252] [8109cab5] ? irq_thread+0x145/0x180 Jan 25 03:08:26 s kernel: [128427.542255] [810611ec] ? __wake_up_common+0x4c/0x80 Jan 25 03:08:26 s kernel: [128427.542257] [8109cbf0] ? irq_finalize_oneshot+0x100/0x100 Jan 25 03:08:26 s kernel: [128427.542259] [8109c970] ? wake_threads_waitq+0x50/0x50 Jan 25 03:08:26 s kernel: [128427.542261] [810591d5] ? kthread+0x85/0x90 Jan 25 03:08:26 s kernel: [128427.542265] [814231f4] ? kernel_thread_helper+0x4/0x10 Jan 25 03:08:26 s kernel: [128427.542267] [81059150] ? kthread_freezable_should_stop+0x50/0x50 Jan 25 03:08:26 s kernel: [128427.542275] [814231f0] ? gs_change+0xb/0xb Jan 25 03:08:26 s kernel: [128427.542276] handlers: Jan 25 03:08:26 s kernel: [128427.542278] [8109c040] irq_default_primary_handler threaded [812d7ed0] usb_hcd_irq Jan 25 03:08:26 s kernel: [128427.542283] [8109c040] irq_default_primary_handler threaded [812d7ed0] usb_hcd_irq Jan 25 03:08:26 s kernel: [128427.542286] [8109c040] irq_default_primary_handler threaded [812d7ed0] usb_hcd_irq Jan 25 03:08:26 s kernel: [128427.542288] Disabling IRQ #18 [133970.593390] pwc: Iso frame 4 has error -18 [133970.593392] pwc: Iso frame 5 has error -18 [133970.593394] pwc: Iso frame 6 has error -18 [133970.593396] pwc: Iso frame 7 has error -114 [133970.593398] pwc: Iso frame 8 has error -18 [133970.593399] pwc: Iso frame 9 has error -18 And when I restart everything: [133971.011352] usbcore: deregistering interface driver Philips webcam [133971.056287] ohci_hcd :00:13.0: remove, state 1 [133971.056296] ohci_hcd :00:13.0: roothub graceful disconnect [133971.056303] usb usb2: USB disconnect, device number 1 [133971.056307] usb 2-4: USB disconnect, device number 2 [133971.056310] usb 2-4: unregistering device [133971.056314] usb 2-4: unregistering interface 2-4:1.0 [133971.056480] usb 2-4: unregistering interface 2-4:1.1 [133971.056951] usb 2-4: unregistering interface 2-4:1.2 [133971.057053] usb 2-4: usb_disable_device nuking all URBs [133971.058693] usb usb2: unregistering device [133971.058702] usb usb2: unregistering interface 2-0:1.0 [133971.058744] ohci_hcd :00:13.0: shutdown urb 8802342b7e00 ep1in-intr [133971.060699] usb usb2: usb_disable_device nuking all URBs [133971.061051] ohci_hcd :00:13.0: OHCI controller state [133971.061059] ohci_hcd :00:13.0: OHCI 1.0, NO legacy support registers, rh state running [133971.061066] ohci_hcd :00:13.0: control 0x083 HCFS=operational CBSR=3 [133971.061071] ohci_hcd :00:13.0: cmdstatus 0x0 SOC=0 [133971.061077] ohci_hcd :00:13.0: intrstatus 0x0024 FNO SF [133971.061082] ohci_hcd :00:13.0: intrenable 0x805a MIE RHSC UE RD WDH [133971.061088] ohci_hcd :00:13.0: ed_controlhead 4000 [133971.061095] ohci_hcd :00:13.0: hcca frame #86d9 [133971.061101] ohci_hcd :00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5) [133971.061106] ohci_hcd :00:13.0: roothub.b PPCM= DR= [133971.06] ohci_hcd :00:13.0: roothub.status 8000 DRWE [133971.061116] ohci_hcd :00:13.0: roothub.portstatus [0] 0x0100 PPS [133971.061121] ohci_hcd :00:13.0: roothub.portstatus [1] 0x0100 PPS [133971.061126] ohci_hcd :00:13.0: roothub.portstatus [2] 0x0100 PPS [133971.061131] ohci_hcd :00:13.0: roothub.portstatus [3] 0x0103 PPS PES CCS [133971.061136] ohci_hcd :00:13.0: roothub.portstatus [4] 0x0100 PPS [133971.061188] ohci_hcd :00:13.0: USB bus 2 deregistered [133971.061449] ohci_hcd :00:13.0: OHCI Host Controller [133971.061459] ohci_hcd :00:13.0: new USB bus registered, assigned bus number 2 [133971.061490] ohci_hcd :00:13.0: created debug files [133971.061494] ohci_hcd :00:13.0: supports USB remote wakeup [133971.061549] ohci_hcd :00:13.0: irq 18, io mem 0xfeb4e000 [133971.115480] hub 4-0:1.0: state 7 ports 5 chg evt 0010 [133971.115500] ehci_hcd :00:13.2: GetStatus port:4 status 001803 0 ACK POWER sig=j CSC CONNECT [133971.115514] hub 4-0:1.0: port 4,
Re: [PATCH v2 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
On 01/25/2013 04:33 AM, Kishon Vijay Abraham I wrote:
In order to add support for multipe PHY's of the same type, new API's
for adding PHY and getting PHY has been added. Now the binding
information for the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, usb_get_phy_dev will return
the
appropriate PHY.
Already existing API's to add and get phy by type is not removed. These
API's are deprecated and will be removed once all the platforms start to
use the new API.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 118
++-
include/linux/usb/phy.h | 13 ++
2 files changed, 130 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 8e756d9..4bb4333 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -36,6 +36,24 @@ static struct usb_phy *__usb_find_phy(struct list_head
*list,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_dev(struct device *dev,
+ struct list_head *list, u8 index)
+{
+ struct usb_phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index) {
+ if (phy_bind-phy)
+ return phy_bind-phy;
+ else
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -112,6 +130,69 @@ err0:
EXPORT_SYMBOL(usb_get_phy);
/**
+ * usb_get_phy_dev - find the USB PHY
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
PHY driver or PHY device?
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_dev(dev, phy_bind_list, index);
+ if (IS_ERR(phy)) {
+ pr_err(unable to find transceiver\n);
I would suggest not to print and leave it to the user. This print
unable to find transceiver gives no valuable information/context.
Also -EPROBE_DEFER is a valid case where this message must not be printed.
+ goto err0;
+ }
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL(usb_get_phy_dev);
+
+/**
+ * devm_usb_get_phy_dev - find the USB PHY using device ptr and index
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Gets the phy using usb_get_phy_dev(), and associates a device with it
using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
+{
+ struct usb_phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = usb_get_phy_dev(dev, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_dev);
+
+/**
* devm_usb_put_phy - release the USB PHY
* @dev - device that wants to release this phy
* @phy - the phy returned by devm_usb_get_phy()
@@ -186,6 +267,36 @@ out:
EXPORT_SYMBOL(usb_add_phy);
/**
+ * usb_add_phy_dev - declare the USB PHY
+ * @x: the USB phy to be used; or NULL
@phy is better than @x?
+ *
+ * This call is exclusively for use by phy drivers, which
+ * coordinate the activities of drivers for host and peripheral
+ * controllers, and in some cases for VBUS current regulation.
+ */
+int usb_add_phy_dev(struct usb_phy *x)
+{
+ struct usb_phy_bind *phy_bind;
+ unsigned long flags;
+
+ if (!x-dev) {
+ dev_err(x-dev, no device provided for PHY\n);
+ return -EINVAL;
+ }
+
+ spin_lock_irqsave(phy_lock, flags);
+ list_for_each_entry(phy_bind, phy_bind_list, list)
+ if (!(strcmp(phy_bind-phy_dev_name, dev_name(x-dev
+ phy_bind-phy = x;
+
+ list_add_tail(x-head, phy_list);
+
+
[PATCH 1/2] usb-uas: set max_lun and max_channel
256 luns is what the sam-4 address method 0 can handle and what the qemu uas emulation supports. So pick that for now. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- drivers/usb/storage/uas.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index 29c5dab..0b72257 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -991,6 +991,8 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id) shost-max_cmd_len = 16 + 252; shost-max_id = 1; + shost-max_lun = 256; + shost-max_channel = 1; shost-sg_tablesize = udev-bus-sg_tablesize; devinfo-intf = intf; -- 1.7.9.7 -- 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
[PATCH 2/2] usb-uas: update MAINTAINERS entry
Cc: Sarah Sharp sarah.a.sh...@linux.intel.com Signed-off-by: Gerd Hoffmann kra...@redhat.com --- MAINTAINERS |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8ae709e..c5b37de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7911,9 +7911,10 @@ F: drivers/net/wireless/ath/ar5523/ USB ATTACHED SCSI M: Matthew Wilcox wi...@linux.intel.com M: Sarah Sharp sarah.a.sh...@linux.intel.com +M: Gerd Hoffmann kra...@redhat.com L: linux-usb@vger.kernel.org L: linux-s...@vger.kernel.org -S: Supported +S: Maintained F: drivers/usb/storage/uas.c USB CDC ETHERNET DRIVER -- 1.7.9.7 -- 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
Re: [PATCH 2/2] usb-uas: update MAINTAINERS entry
On Fri, Jan 25, 2013 at 02:52:09PM +0100, Gerd Hoffmann wrote: Cc: Sarah Sharp sarah.a.sh...@linux.intel.com Signed-off-by: Gerd Hoffmann kra...@redhat.com --- MAINTAINERS |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8ae709e..c5b37de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7911,9 +7911,10 @@ F: drivers/net/wireless/ath/ar5523/ USB ATTACHED SCSI M: Matthew Wilcox wi...@linux.intel.com M: Sarah Sharp sarah.a.sh...@linux.intel.com +M: Gerd Hoffmann kra...@redhat.com Should Matthew be removed from this? Also, any word on when I can remove the CONFIG_BROKEN marking on this driver? greg k-h -- 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
[PATCH v2] usb-uas: set max_lun and max_channel
256 luns is what the sam-4 address method 0 can handle and what the qemu uas emulation supports. So pick that for now. [ v2: unlike the other two max_* fields max_channel isn't max+1 ] Signed-off-by: Gerd Hoffmann kra...@redhat.com --- drivers/usb/storage/uas.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index 29c5dab..2d40a11 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -991,6 +991,8 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id) shost-max_cmd_len = 16 + 252; shost-max_id = 1; + shost-max_lun = 256; + shost-max_channel = 0; shost-sg_tablesize = udev-bus-sg_tablesize; devinfo-intf = intf; -- 1.7.9.7 -- 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
Re: Regarding Docbook
On Fri, Jan 25, 2013 at 07:29:07PM +0530, Anil Nair wrote: Hello All, Wishing a happy new year to all. :) I was compiling the Docbook present in Linux Kernel version 3.8-rc4 using the command, make pdfdocs The compilation stops with the following error, make: *** No rule to make target `FORCE', needed by `/media_api.xml'. Stop. Any idea how to resolve this? Try asking on the linux-me...@vger.kernel.org mailing list, this sounds like one of their files, not a USB one. greg k-h -- 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
[PATCH corrected] usb/gadget: nokia: use function framework for ACM
From: Sebastian Andrzej Siewior bige...@linutronix.de
This patch converts the nokia gadget to make use of the function
framework to request the ACM function.
The old include interface for acm is now removed since nokia was the
last user of it (for ACM).
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
drivers/usb/gadget/Kconfig|1 +
drivers/usb/gadget/f_acm.c| 83 +++-
drivers/usb/gadget/nokia.c| 82 +++-
drivers/usb/gadget/u_serial.h |1 -
4 files changed, 72 insertions(+), 95 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 6665d25..afb78f6 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -833,6 +833,7 @@ config USB_G_NOKIA
depends on PHONET
select USB_LIBCOMPOSITE
select USB_U_SERIAL
+ select USB_F_ACM
help
The Nokia composite gadget provides support for acm, obex
and phonet in only one composite gadget driver.
diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c
index 1ae180b..61b33d2 100644
--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -715,72 +715,6 @@ fail:
return status;
}
-static struct f_acm *acm_alloc_basic_func(void)
-{
- struct f_acm*acm;
-
- acm = kzalloc(sizeof(*acm), GFP_KERNEL);
- if (!acm)
- return NULL;
-
- spin_lock_init(acm-lock);
-
- acm-port.connect = acm_connect;
- acm-port.disconnect = acm_disconnect;
- acm-port.send_break = acm_send_break;
-
- acm-port.func.name = acm;
- /* descriptors are per-instance copies */
- acm-port.func.bind = acm_bind;
- acm-port.func.set_alt = acm_set_alt;
- acm-port.func.setup = acm_setup;
- acm-port.func.disable = acm_disable;
-
- return acm;
-}
-
-#ifdef USB_FACM_INCLUDED
-static void
-acm_old_unbind(struct usb_configuration *c, struct usb_function *f)
-{
- struct f_acm*acm = func_to_acm(f);
-
- usb_free_all_descriptors(f);
- if (acm-notify_req)
- gs_free_req(acm-notify, acm-notify_req);
- kfree(acm);
-}
-
-/**
- * acm_bind_config - add a CDC ACM function to a configuration
- * @c: the configuration to support the CDC ACM instance
- * @port_num: /dev/ttyGS* port this interface will use
- * Context: single threaded during gadget setup
- *
- * Returns zero on success, else negative errno.
- *
- */
-int acm_bind_config(struct usb_configuration *c, u8 port_num)
-{
- struct f_acm*acm;
- int status;
-
- /* allocate and initialize one new instance */
- acm = acm_alloc_basic_func();
- if (!acm)
- return -ENOMEM;
-
- acm-port_num = port_num;
- acm-port.func.unbind = acm_old_unbind;
-
- status = usb_add_function(c, acm-port.func);
- if (status)
- kfree(acm);
- return status;
-}
-
-#else
-
static void acm_unbind(struct usb_configuration *c, struct usb_function *f)
{
struct f_acm*acm = func_to_acm(f);
@@ -803,10 +737,24 @@ static struct usb_function *acm_alloc_func(struct
usb_function_instance *fi)
struct f_serial_opts *opts;
struct f_acm *acm;
- acm = acm_alloc_basic_func();
+ acm = kzalloc(sizeof(*acm), GFP_KERNEL);
if (!acm)
return ERR_PTR(-ENOMEM);
+ spin_lock_init(acm-lock);
+
+ acm-port.connect = acm_connect;
+ acm-port.disconnect = acm_disconnect;
+ acm-port.send_break = acm_send_break;
+
+ acm-port.func.name = acm;
+ acm-port.func.strings = acm_strings;
+ /* descriptors are per-instance copies */
+ acm-port.func.bind = acm_bind;
+ acm-port.func.set_alt = acm_set_alt;
+ acm-port.func.setup = acm_setup;
+ acm-port.func.disable = acm_disable;
+
opts = container_of(fi, struct f_serial_opts, func_inst);
acm-port_num = opts-port_num;
acm-port.func.unbind = acm_unbind;
@@ -835,4 +783,3 @@ static struct usb_function_instance
*acm_alloc_instance(void)
}
DECLARE_USB_FUNCTION_INIT(acm, acm_alloc_instance, acm_alloc_func);
MODULE_LICENSE(GPL);
-#endif
diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c
index def3740..c3ad777 100644
--- a/drivers/usb/gadget/nokia.c
+++ b/drivers/usb/gadget/nokia.c
@@ -37,8 +37,6 @@
* the runtime footprint, and giving us at least some parts of what
* a gcc --combine ... part1.c part2.c part3.c ... build would.
*/
-#define USB_FACM_INCLUDED
-#include f_acm.c
#include f_ecm.c
#include f_obex.c
#include f_serial.c
@@ -98,7 +96,8 @@ MODULE_AUTHOR(Felipe Balbi);
MODULE_LICENSE(GPL);
/*-*/
-
+static struct usb_function *f_acm_cfg1;
+static struct usb_function *f_acm_cfg2;
Re: [PATCH 2/2] usb-uas: update MAINTAINERS entry
Hi, diff --git a/MAINTAINERS b/MAINTAINERS index 8ae709e..c5b37de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7911,9 +7911,10 @@ F:drivers/net/wireless/ath/ar5523/ USB ATTACHED SCSI M: Matthew Wilcox wi...@linux.intel.com M: Sarah Sharp sarah.a.sh...@linux.intel.com +M: Gerd Hoffmann kra...@redhat.com Should Matthew be removed from this? Dunno, Sarah? Also, any word on when I can remove the CONFIG_BROKEN marking on this driver? With the patches in -next uas itself should be reasonable solid. Problem is that uas is pretty much the only device using streams, so uas will be the one who triggers any stream bugs in xhci. I have no idea how solid xhci streams support is at the moment. Sarah, is there some way to avoid using streams? The UAS specs seems to imply using streams is mandatory when connected to a USB-3 port, is that correct? Is there some way to force usb3 devices into usb2 mode even when plugged into a usb3 port? I'd like to have a no_streams module option if possible ... cheers, Gerd -- 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
Re: [PATCH 2/2] usb-uas: update MAINTAINERS entry
On Fri, Jan 25, 2013 at 03:19:22PM +0100, Gerd Hoffmann wrote: Hi, diff --git a/MAINTAINERS b/MAINTAINERS index 8ae709e..c5b37de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7911,9 +7911,10 @@ F: drivers/net/wireless/ath/ar5523/ USB ATTACHED SCSI M:Matthew Wilcox wi...@linux.intel.com M:Sarah Sharp sarah.a.sh...@linux.intel.com +M:Gerd Hoffmann kra...@redhat.com Should Matthew be removed from this? Dunno, Sarah? Also, any word on when I can remove the CONFIG_BROKEN marking on this driver? With the patches in -next uas itself should be reasonable solid. Problem is that uas is pretty much the only device using streams, so uas will be the one who triggers any stream bugs in xhci. I have no idea how solid xhci streams support is at the moment. Sarah, is there some way to avoid using streams? The UAS specs seems to imply using streams is mandatory when connected to a USB-3 port, is that correct? Is there some way to force usb3 devices into usb2 mode even when plugged into a usb3 port? I'd like to have a no_streams module option if possible ... Well, I think we want to use streams, that's the whole advantage of UAS over the old spec. I wasn't aware that the bugs were in the xhci driver, I thought they were in the uas driver, but I could be totally wrong. Oh, and any hints on what device on the market today actually follows the UAS spec so I can buy one for testing? thanks, greg k-h -- 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
Re: Add USB Device
On Fri, Jan 25, 2013 at 09:30:25AM -0500, Hoyt Duff wrote: Vendor ID: 0x04b4 Device ID: 0x6830 Cypress Semiconductor USB2.0 Storage Device # uname -a Linux titan.maximumhoyt.com 3.4.24-desktop-3.mga2 #1 SMP Sat Jan 5 02:42:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/bus/usb/devices Why do we need to add this device? Does it not work properly with the existing kernel driver? confused, greg k-h -- 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
Re: USB3 host dying on SIGKILL
Hello, On 01/23/2013 01:01 PM, Frank Lömker wrote: We have a somewhat UVC compliant USB2 camera connected to a USB3 port. It works mostly great. But when we SIGKILL the program which opened the device, the corresponding host controller dies and the system must be rebooted to access the USB port again. If the program closes the device normally and then ends, everything works correctly. In the error case we get the following messages. The uvcvideo lines are additional debug messages which we added during debugging this problem: [ 130.812349] uvcvideo: uvc_v4l2_release [ 130.812352] uvcvideo: uvc_v4l2_release has_privileges [ 130.812355] uvcvideo: uvc_uninit_video start [ 130.812536] uvcvideo: uvc_uninit_video done [ 131.113099] uvcvideo: usb_set_interface start [ 131.113121] xhci_hcd :00:14.0: Signal while waiting for configure endpoint command [ 131.113163] usb 3-1: Not enough bandwidth for altsetting 0 [ 131.113165] uvcvideo: usb_set_interface done [ 131.416625] uvcvideo: uvc_queue_enable start [ 131.416630] uvcvideo: uvc_queue_enable done [ 131.720344] uvcvideo: uvc_v4l2_release 2 [ 131.720348] uvcvideo: uvc_v4l2_release 3 [ 131.720356] xhci_hcd :00:14.0: ERROR no room on ep ring [ 131.720359] xhci_hcd :00:14.0: ERR: No room for command on command ring [ 136.728324] xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command. [ 136.728330] xhci_hcd :00:14.0: Assuming host is dying, halting host. [ 136.728344] xhci_hcd :00:14.0: HC died; cleaning up [ 136.728364] usb 3-1: USB disconnect, device number 2 [ 136.728378] uvcvideo: uvc_v4l2_release 4 [ 136.728388] uvcvideo: uvc_v4l2_release 5 [ 136.768486] xhci_hcd :00:14.0: Slot 1 endpoint 2 not removed from BW list! I.e. the uvc driver calls usb_set_interface(stream-dev-udev, stream-intfnum, 0); during it's uvc_v4l2_release() execution. This fails with [ 131.113121] xhci_hcd :00:14.0: Signal while waiting for configure endpoint command [ 131.113163] usb 3-1: Not enough bandwidth for altsetting 0 If we remove this usb_set_interface() call everything seems to work correctly, no error messages are in the log, and the USB3 port remains accessible. But that's probably not the right solution. At least I, with my very limit knowledge about USB and xhci, don't see an error in calling this here during the release operation. So we looked further. The call chain which is performed starting from usb_set_interface() is: usb_set_interface() ret = usb_hcd_alloc_bandwidth(dev, NULL, iface-cur_altsetting, alt); ret = hcd-driver-check_bandwidth(hcd, udev); xhci_check_bandwidth() ret = xhci_configure_endpoint(xhci, udev, NULL, false, false); timeleft = wait_for_completion_interruptible_timeout( cmd_completion, XHCI_CMD_DEFAULT_TIMEOUT); It seems to me as if wait_for_completion_interruptible_timeout() stops because of the SIGKILL which the process received before. Changing the wait_for_completion_interruptible_timeout() in xhci_configure_endpoint() to wait_for_completion_timeout() fixed the problem for us as well. No error messages occur in the log and the USB3 port remains accessible. Don't now if this is anything near the right solution to this problem. Attached is a patch for this, probably wrong, solution and the kernel logs starting shortly before the SIGKILL and ending shortly after the HC died message. The kernel logs where generated with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on. Additionally uvcvideo was loaded with trace=255. During debugging this problem we used the kernels 3.2.0-35-generic from Ubuntu 12.4 and the latest vanilla kernel from the 3.6 series, version 3.6.11. The patch is against version 3.6.11. Just verified that kernel 3.8.0-rc4 does not change anything. When using SIGKILL the vanilla kernel fails with the same messages as kernel 3.6.11. With the patch applied the 3.8.0 kernel seems to work as well. Regards, We use an AAEON IMBM-B75A mainboard with an Intel B75 chipset, bios version 0601. The camera is a DFK 42AUC03 from The Imaging Source Europe GmbH. Does anybody know what's the right solution for this problem? Or is the patch even correct? Thanks in advance, -- Dr. Frank Lömker Leiter Softwareentwicklung E-Mail: frank.loem...@isa.de.com Tel : +49(0)3677-46929-63 Internet: www.isa.de.com ISA Institut für Serviceautomation GmbH Co. KG Ziolkowskistr. 8, 98693 Ilmenau phG: ISA GmbH, Ilmenau (AG Jena, HRB 306708) Geschäftsführer: Dipl.-Ing. (FH) Jürgen Utschig Ust-IdNr. DE 239745996 ILN 43 99901 84388 2 Amtsgericht Jena HRA 301735 HRB 306708 Member of SIELAFF GROUP -- 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
RE: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Hi Kishon, On Thu, Jan 24, 2013 at 17:21:45, Mohammed, Afzal wrote: On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote: On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote: USB first instance of am335x works in mainline as of now. Can you check if this series indeed breaks am335x? Thanks for your help. Do you have a tree having these changes, it would be easier for me. I tried with your omap5-with-palmas branch that was mentioned in the cover letter of your latest series (but couldn't find the commit that you mentioned in the cover letter, HEAD of that branch that I tested was 2c29519 ARM: dts: palmas: update dt data for palmas-usb) usb first instance of am335x works as earlier. Regards Afzal -- 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
Re: [PATCH 2/2] usb-uas: update MAINTAINERS entry
Hi, Sarah, is there some way to avoid using streams? The UAS specs seems to imply using streams is mandatory when connected to a USB-3 port, is that correct? Is there some way to force usb3 devices into usb2 mode even when plugged into a usb3 port? I'd like to have a no_streams module option if possible ... Well, I think we want to use streams, that's the whole advantage of UAS over the old spec. Sure, but being able to turn them off for trouble-shooting purposes would still be useful IMO. I wasn't aware that the bugs were in the xhci driver, I thought they were in the uas driver, but I could be totally wrong. Oh, uas had bugs too, pretty serious ones included, no question. Oh, and any hints on what device on the market today actually follows the UAS spec so I can buy one for testing? /me asked the same a while ago, here is the reply quoting sarah I would suggest getting a TI UAS evaluation board. They seem to be the most stable UAS device out there: http://www.ti.com/tool/tusb9261demo I have one of their boards from a year or so ago, but I suspect there's a new revision by now. I got the sample from Kevin Main km...@ti.com, and I suspect he might give you one for free as well. Another option might be to use the Linux UAS gadget stack with a OMAP5 board with the Synopsis Designware 3 USB 3.0 device controller. You could talk with Sebastian Andrzej Siewior bige...@linutronix.de, since he has been doing a lot of work on the UAS gadget driver lately. /quote cheers, Gerd -- 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
Re: Trouble with a USB 2.0 device with xhci_hcd
On Thu, 24 Jan 2013, Sarah Sharp wrote:
On Thu, Jan 24, 2013 at 10:51:04AM -0500, Alan Stern wrote:
On Wed, 23 Jan 2013, Sarah Sharp wrote:
So I guess my next question is: What are you plans, if any, to add the
new enumeration scheme to xHCI? Is this a huge amount of work?
Not a huge amount of work, but it does require an API change to the USB
host controller driver functions, so the patch itself is not likely to
get backported to stable kernels. And I have no idea how the current
batch of USB 3.0 devices will react to an enumeration sequence change.
I thought this wasn't possible at all, because the xHCI hardware
automatically assigns an address to the device when a reset completes.
No, the xHCI hardware doesn't assign an address on reset completion.
The xHCI host assigns an address and sends the Set Address control
transfer when the Set Address command issued (when hcd-address_device
is called in hub_set_address).
The Set Address command does two things: it tells the xHC that the
default control endpoint ring and associated device context information
is set up, and it tells the xHC to issue the Set Address control
transfer.
There's a flag you can pass to the Set Address command to make it not
actually send the control transfer. It's called 'Block Set Address
Request' (BSR). After you issue the Set Address command with the BSR
flag set, you can get the device descriptor through the default control
endpoint. Then you send the Set Address command again, with BSR
cleared, when you want to actually set the device address.
I asked the xHCI spec author to put the flag in, because I saw the two
enumeration schemes. I just haven't had time or motivation to implement
it.
I see. Thanks for the explanation.
Old scheme:
Reset
Get device descriptor (8 bytes)
Set address
Get device descriptor (18 bytes)
Does the core really get the 8 byte device descriptor before set
address? I'm pretty sure that would be skipped in the if block when we
try the old scheme:
for (i = 0; i GET_DESCRIPTOR_TRIES; (++i, msleep(100))) {
...
if (udev-wusb == 0) {
for (j = 0; j SET_ADDRESS_TRIES; ++j) {
retval = hub_set_address(udev, devnum);
if (retval = 0)
break;
msleep(200);
}
...
}
I thought the old scheme was:
Reset
Set address
Get device descriptor (8 bytes)
Get device descriptor (18 bytes)
You're right. I haven't looked at this stuff in years; my memory
cells are decaying...
I think it's still possible to do the new enumeration scheme with the
flag to the Set Address command. The new scheme would look like:
New scheme:
Reset
Set Address command (BSR flag set)
Get device descriptor (64 bytes)
Reset
Reset Device command
Set address
Set Address command (BSR flag clear)
Get device descriptor (18 bytes)
Does that make sense?
Yes.
Alan Stern
--
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
Re: USB subsystem stops working
On Fri, 25 Jan 2013, Ming Lei wrote: On Fri, Jan 25, 2013 at 4:11 AM, Alan Stern st...@rowland.harvard.edu wrote: Okay, here's a second test I'd like you to try. It fixes all the problems on my machine. For this test you don't need to change any settings under /sys. Just apply this patch and see what the dmesg log says. Looks the patch fixes the the failure of bus suspend fail, err -16 after root hub remote wakeup on my box. Good. Can I add your Tested-by: when I submit it? Alan Stern -- 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
Re: USB subsystem stops working
On Fri, 25 Jan 2013, Norbert Preining wrote: Hi Alan, here some status update, and a slight problem: I cannot recreate the problem anymore ... maybe because I pulled from master the latest changes, but whatever I do currently, I cannot trigger it again. No way. The last git commit I used was ed06ef318a, thee I think it happened (but I didn't retry till now). Now with current head and the changes that came in USB: EHCI: fix build error in ehci-mxc USB: EHCI: add a name for the platform-private field USB: EHCI: fix incorrect configuration test USB: EHCI: Move definition of EHCI_STATS to ehci.h USB: UHCI: fix IRQ race during initialization I cannot trigger it again. Umpf sorry ... I doubt that those changes would affect the behavior. If you really wanted to, you could check out an old commit for testing. But it really doesn't matter, since the problem seems to be fixed. Thanks for reporting it originally; that forced us to take a close look at the situation. Alan Stern -- 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
Re: [PATCH 2/2] usb-uas: update MAINTAINERS entry
On Fri, Jan 25, 2013 at 04:04:33PM +0100, Gerd Hoffmann wrote: Oh, and any hints on what device on the market today actually follows the UAS spec so I can buy one for testing? /me asked the same a while ago, here is the reply quoting sarah I would suggest getting a TI UAS evaluation board. They seem to be the most stable UAS device out there: http://www.ti.com/tool/tusb9261demo I have one of their boards from a year or so ago, but I suspect there's a new revision by now. I got the sample from Kevin Main km...@ti.com, and I suspect he might give you one for free as well. Ah, I already have one of these somewhere, I was wondering if there were devices you could buy on the market just yet. I guess not, which is fine. thanks, greg k-h -- 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
Re: [PATCH v4 2/3] usb: gadget: introduce gadget state tracking
On Fri, 25 Jan 2013, Felipe Balbi wrote:
I guess it would be good to have a:
enum usb_gadget_state usb_gadget_get_state(struct usb_gadget *gadget)
{
return gadget-state;
}
right ?? At least dwc3 can make use of it.
This seems like unnecessary embellishment. What's wrong with typing
gadget-state
instead of
usb_gadget_get_state(gadget)
? Do you have some reason to think the state field will need further
encapsulation in the future?
Alan Stern
--
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
Re: USB subsystem stops working
On Fri, Jan 25, 2013 at 11:23 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 25 Jan 2013, Ming Lei wrote: Good. Can I add your Tested-by: when I submit it? Sure, please feel free to add the below: Tested-by: Ming Lei ming@canonical.com Thanks, -- Ming Lei -- 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
[PATCH v2] usb: add driver for xsens motion trackers
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
This is a revision of the xsens_mt module. Since previous one, I've
reduced the allocated buffers, cause there seem to be no problems with
the default size right now.
Filtering the correct interface has been moved to the probe function,
which seems more appropriate. Filtering in attach is slightly easier,
but returning any error will result in EIO.
I'd remove the bNumEndpoints if I could.
That should be all.
Thanks,
Frans
---
drivers/usb/serial/Kconfig| 12 ++
drivers/usb/serial/Makefile | 1 +
drivers/usb/serial/xsens_mt.c | 86 +++
3 files changed, 99 insertions(+)
create mode 100644 drivers/usb/serial/xsens_mt.c
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 76f4622..dad8363 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -647,6 +647,18 @@ config USB_SERIAL_VIVOPAY_SERIAL
To compile this driver as a module, choose M here: the
module will be called vivopay-serial.
+config USB_SERIAL_XSENS_MT
+ tristate Xsens motion tracker serial interface driver
+ help
+ Say Y here if you want to use Xsens motion trackers.
+
+ This driver supports the new generation of motion trackers
+ by Xsens. Older devices can be accessed using the FTDI_SIO
+ driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called xsens_mt.
+
config USB_SERIAL_ZIO
tristate ZIO Motherboard USB serial interface driver
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 3b3e730..eaf5ca1 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -61,5 +61,6 @@ obj-$(CONFIG_USB_SERIAL_VISOR)+=
visor.o
obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
obj-$(CONFIG_USB_SERIAL_XIRCOM)+= keyspan_pda.o
obj-$(CONFIG_USB_SERIAL_VIVOPAY_SERIAL)+= vivopay-serial.o
+obj-$(CONFIG_USB_SERIAL_XSENS_MT) += xsens_mt.o
obj-$(CONFIG_USB_SERIAL_ZIO) += zio.o
obj-$(CONFIG_USB_SERIAL_ZTE) += zte_ev.o
diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
new file mode 100644
index 000..1d5798d
--- /dev/null
+++ b/drivers/usb/serial/xsens_mt.c
@@ -0,0 +1,86 @@
+/*
+ * Xsens MT USB driver
+ *
+ * Copyright (C) 2013 Xsens i...@xsens.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/tty.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/serial.h
+#include linux/uaccess.h
+
+#define XSENS_VID 0x2639
+
+#define MTi_10_IMU_PID 0x0001
+#define MTi_20_VRU_PID 0x0002
+#define MTi_30_AHRS_PID0x0003
+
+#define MTi_100_IMU_PID0x0011
+#define MTi_200_VRU_PID0x0012
+#define MTi_300_AHRS_PID 0x0013
+
+#define MTi_G_700_GPS_INS_PID 0x0017
+
+static const struct usb_device_id id_table[] = {
+ { USB_DEVICE(XSENS_VID, MTi_10_IMU_PID) },
+ { USB_DEVICE(XSENS_VID, MTi_20_VRU_PID) },
+ { USB_DEVICE(XSENS_VID, MTi_30_AHRS_PID) },
+
+ { USB_DEVICE(XSENS_VID, MTi_100_IMU_PID) },
+ { USB_DEVICE(XSENS_VID, MTi_200_VRU_PID) },
+ { USB_DEVICE(XSENS_VID, MTi_300_AHRS_PID) },
+
+ { USB_DEVICE(XSENS_VID, MTi_G_700_GPS_INS_PID) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table);
+
+static int has_required_endpoints(const struct usb_host_interface *interface)
+{
+ __u8 i;
+ int has_bulk_in = 0;
+ int has_bulk_out = 0;
+
+ for (i = 0; i interface-desc.bNumEndpoints; ++i) {
+ if (usb_endpoint_is_bulk_in(interface-endpoint[i].desc))
+ has_bulk_in = 1;
+ else if (usb_endpoint_is_bulk_out(interface-endpoint[i].desc))
+ has_bulk_out = 1;
+ }
+
+ return has_bulk_in has_bulk_out;
+}
+
+static int xsens_mt_probe(struct usb_serial *serial,
+ const struct usb_device_id *id)
+{
+ if (!has_required_endpoints(serial-interface-cur_altsetting))
+ return -ENODEV;
+ return 0;
+}
+
+static struct usb_serial_driver xsens_mt_device = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = xsens_mt,
+ },
+ .id_table = id_table,
+ .num_ports = 1,
+
+ .probe = xsens_mt_probe,
+};
+
+static struct usb_serial_driver * const serial_drivers[] = {
+ xsens_mt_device, NULL
+};
+
+module_usb_serial_driver(serial_drivers, id_table);
+
+MODULE_LICENSE(GPL);
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
Re: [PATCH v4 2/3] usb: gadget: introduce gadget state tracking
On Fri, Jan 25, 2013 at 05:31:35PM +0200, Felipe Balbi wrote:
Hi,
On Fri, Jan 25, 2013 at 10:27:24AM -0500, Alan Stern wrote:
On Fri, 25 Jan 2013, Felipe Balbi wrote:
I guess it would be good to have a:
enum usb_gadget_state usb_gadget_get_state(struct usb_gadget *gadget)
{
return gadget-state;
}
right ?? At least dwc3 can make use of it.
This seems like unnecessary embellishment. What's wrong with typing
gadget-state
instead of
usb_gadget_get_state(gadget)
? Do you have some reason to think the state field will need further
encapsulation in the future?
not really, just that a setter() usually follows up a getter(). But...
meh... no strong feelings
I would argue that for something as simple as -state, you don't even
need a setter() function. This is C, not Java :)
greg k-h
--
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
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Fri, Jan 25, 2013 at 02:59:28PM +, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 12:29:43PM +, Mark Rutland wrote: + depending upon omap4 or omap5. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,type: This is used to differentiate whether the control module has + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to + notify events to the musb core and omap5 has usb3 phy power register to + power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3 + phy power. Why not make this a string property, perhaps values mailbox or register? NAK. Can I ask what your objection to using a string property is? As far as I can see, ti,type is only used by this driver, so there's no common convention to stick to. Using a string makes the binding easier for humans to read, and thus harder to mess up in a dts, and it decouples the binding from kernel-side constants. IIRC there is some work going on to add #define-like support for DT, which would allow us to match against integers while still having meaningful symbolic representations. I was under the impression that the motivation for using the preprocessor on the DT was to allow symbolic names for device/soc-specific values like addresses, rather than what amounts to ABI values for the binding. I don't see the point in building a binding that depends on future functionality to be legible, especially as we can make it more readable, robust, and just as extensible today, with a simple change to the proposed binding. Even ignoring the above, the driver isn't doing appropriate sanity checking. If you use a string property, this sanity check is implicit in the parsing -- you've either matched a value you can handle or you haven't. Thanks, Mark. -- 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
[GIT PULL] usb: musb: patches for v3.9:x
Hi Greg, here's MUSB's pull request. Let me know if you want any changes. This one merged cleanly on top of your usb-next branch. The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/musb-for-v3.9 for you to fetch changes up to b37457d80bc3e2a6bb86a6036c572574614a7631: usb: musb: omap2430: fix wrong devm_kzalloc() result check (2013-01-17 15:45:45 +0200) usb: musb: patches for v3.9 merge window Mostly fixes all over which weren't urgent enough for the late -rc cycle. There is a Double Buffering fix for Host Mode TX, a dependency fix for the transceiver driver, some fixes to the error path and a fix for the use of omap_musb_maibox. Other than these fixes, there a removal duplicate headers from the dsps glue layer and removal of redundant assignments in omap2430_probe(). Aaro Koskinen (1): usb: musb: omap2430: fix the readiness check in omap_musb_mailbox Fabio Baltieri (1): usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare Ming Lei (2): usb: musb: core: fix failure path usb: musb: fix dependency on transceiver driver Sachin Kamat (1): usb: musb: dsps: Remove duplicate inclusion of linux/of.h Sergei Shtylyov (2): usb: musb: omap2430: kill redundant assignments in omap2430_probe() usb: musb: omap2430: fix wrong devm_kzalloc() result check supriya karanth (3): usb: musb: set TXMAXP and AUTOSET for full speed bulk in device mode usb: musb: set AUTOSET for full speed bulk DMA transfer in host mode usb: musb: Double buffering issues in host mode TX drivers/usb/musb/am35x.c | 2 +- drivers/usb/musb/blackfin.c| 2 +- drivers/usb/musb/da8xx.c | 7 +-- drivers/usb/musb/davinci.c | 7 +-- drivers/usb/musb/musb_core.c | 1 + drivers/usb/musb/musb_dsps.c | 3 +-- drivers/usb/musb/musb_gadget.c | 22 ++--- drivers/usb/musb/musb_host.c | 44 ++ drivers/usb/musb/omap2430.c| 16 +++ drivers/usb/musb/tusb6010.c| 2 +- drivers/usb/musb/ux500.c | 12 ++-- 11 files changed, 79 insertions(+), 39 deletions(-) -- balbi signature.asc Description: Digital signature
[GIT PULL] usb: dwc3: patches for v3.9
Hi Greg, here's dwc3 for v3.9 merge window. It also merged just fine with your usb-next branch. The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/dwc3-for-v3.9 for you to fetch changes up to 52758bcb7c12bede2a81849dee13f1edcd44e1c1: usb: dwc3: host: Change platform device ID for xhci-hcd to AUTO (2013-01-25 13:19:52 +0200) usb: dwc3: patches for v3.9 merge window We're saving some extra memory now by being a lot more conservative when allocating our event buffers. Our default HIRD threshold value was mistakenly set as one of the unsupported which would cause undefined behavior. Turns out that it broke OMAP5 ES2.0, so we're fixing it now by setting the maximum allowed HIRD threshold (12). Quite a few fixes to Isochronous transfers and scatter/gather support from Pratyush. We're also starting to support devicetree-based probe with the latest changes from Kishon. The usual set of cleanups also available: converting debugfs regdump utility to regsets, better compatible strings for Exynos platforms and the removal of the dependency for Host and Gadget; now dwc3 can be compiled host-only, device-only, and/or Dual-Role. Felipe Balbi (4): usb: dwc3: decrease event buffer size usb: dwc3: gadget: don't redefine 'ret' usb: dwc3: debugfs: convert our regdump to use regsets usb: dwc3: gadget: change HIRD threshold to 12 Jingoo Han (1): usb: dwc3: exynos: use devm_ functions Kishon Vijay Abraham I (7): usb: dwc3: omap: use device_for_each_child to handle child removal usb: dwc3: omap: use of_platform API to create dwc3 core pdev usb: dwc3: omap: use runtime API's to enable clocks usb: dwc3: omap: Remove explicit writes to SYSCONFIG register usb: dwc3: omap: Add an API to write to dwc mailbox usb: dwc3: core: enable the USB2 and USB3 phy in probe usb: dwc3: core: stray statements are removed Pratyush Anand (8): usb: dwc3: Enable usb2 LPM only when connected as usb2.0 usb: dwc3: gadget: fix missed isoc usb: dwc3: gadget: correct return from ep_queue usb: dwc3: gadget: fix isoc END TRANSFER Condition usb: dwc3: gadget: fix skip LINK_TRB on ISOC usb: dwc3: gadget: no need to pass params in case of UPDATE_TRANSFER usb: dwc3: gadget: fix scatter gather implementation usb: dwc3: gadget: req-queued must be forced to false in cleanup Vivek Gautam (4): usb: dwc3: remove dwc3 dependency on host AND gadget. usb: dwc3: exynos: fix compatible strings for the device usb: dwc3: exynos/omap: Change platform device IDs for no_op_xceive to AUTO usb: dwc3: host: Change platform device ID for xhci-hcd to AUTO drivers/usb/dwc3/Kconfig | 31 - drivers/usb/dwc3/Makefile | 10 +- drivers/usb/dwc3/core.c| 7 +- drivers/usb/dwc3/core.h| 24 +++- drivers/usb/dwc3/debugfs.c | 38 ++ drivers/usb/dwc3/dwc3-exynos.c | 57 drivers/usb/dwc3/dwc3-omap.c | 152 - drivers/usb/dwc3/gadget.c | 292 + drivers/usb/dwc3/host.c| 2 +- include/linux/usb/dwc3-omap.h | 30 + 10 files changed, 406 insertions(+), 237 deletions(-) create mode 100644 include/linux/usb/dwc3-omap.h -- balbi signature.asc Description: Digital signature
[GIT PULL] usb: gadget: patches for v3.9
Hi Greg, Here's the pull request for Gadget framework. Incredible this one also merged just fine ;-) The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/gadget-for-v3.9 for you to fetch changes up to eeef45876631a446eaedce16675f4ff344e16cf0: usb: gadget: constify all struct usb_gadget_ops (2013-01-24 21:11:35 +0200) usb: gadget: patches for v3.9 merge window finally getting rid of the old -start()/-stop() methods in favor of the better and improved -udc_start()/-udc_stop(). There were surprisingly quite a few users left, but all of them have been converted. f_mass_storage removed some dead code, which is always great ;-) There's also a big cleanup to the gadget framework from Sebastian which gets us a lot closer to having only function drivers in kernel and move over to configfs-based binding. Other than these, there's the usual set of cleanups: s3c UDCs are moving over to devm_regulator_bulk_get() API, at91_udc removed an unnecessary check for work_pending() before scheduling and there's the removal of an unused variable from uac2_pcm_trigger(). Andrzej Pietrasiewicz (1): usb: gadget: f_mass_storage: remove unused operations Armando Visconti (1): usb: gadget zero: avoid unnecessary reinit of data in f_sourcesink Chao Xie (6): usb: gadget: mv_udc: use udc_start and udc_stop functions usb: gadget: mv_udc: use devm_xxx for probe usb: gadget: mv_udc: fix the warning of mv_udc_remove usb: otg: mv_otg: use devm_xxx for probe usb: host: ehci-mv: remove unused variable usb: gadget: mv_udc: fix the value of tranceiver Felipe Balbi (14): usb: gadget: f_uac2: fix compile warning usb: gadget: fix two sparse warnings usb: gadget: amd5536udc: convert to udc_start/udc_stop usb: gadget: fusb300_udc: convert to udc_start/udc_stop usb: gadget: goku_udc: convert to udc_start/udc_stop usb: gadget: fsl_udc_core: convert to udc_start/udc_stop usb: gadget: m66592-udc: convert to udc_start/udc_stop usb: gadget: omap_udc: convert to udc_start/udc_stop usb: gadget: pch_udc: convert to udc_start/udc_stop usb: gadget: pxa25x_udc: convert to udc_start/udc_stop usb: gadget: pxa27x_udc: convert to udc_start/udc_stop usb: gadget: s3c2410: convert to udc_start/udc_stop usb: gadget: completely remove -start/-stop usb: gadget: constify all struct usb_gadget_ops Jean-Christophe PLAGNIOL-VILLARD (1): USB: gadget: at91_adc: fix pullup pin validity check Michal Nazarewicz (1): usb: gadget: FunctionFS: Use kstrtoul() Sachin Kamat (2): usb: gadget: s3c-hsudc: Use devm_regulator_bulk_get usb: gadget: s3c-hsotg: Use devm_regulator_bulk_get API Sebastian Andrzej Siewior (26): usb: gadget: file_storage: remove its last pieces usb: gadget: ncm: make global variable ndp*_opts read only usb: gadget: mass_storage: remove = 0 check for unsigned type usb: gadget: consider link speed for bMaxPower usb: gadget: composite: don't call driver's unbind() if bind() failed usb: gadget: remove u32 castings of address passed to readl() usb: gadget: provide a wrapper around SourceSink's setup function usb: gadget: move source sink's config descriptor out of f_sourcesink usb: gadget: move loopback's config descriptor out of f_loopback usb: gadget: add some infracture to register/unregister functions usb: gadget: convert source sink and loopback to new function interface usb: gadget: f_acm: remove empty function usb: gadget: g_serial: split the three possible functions into three bind functions usb: gadget: u_serial: convert into a module usb: gadget: composite: add usb_remove_function() usb: gadget: allocate giveback serial ports instead hard code them usb: gadget: f_acm: convert to new function interface with backwards compatibility usb: gadget: acm_ms: use function framework for ACM usb: gadget: cdc2: use function framework for ACM usb: gadget: multi: use function framework for ACM usb: gadget: add a forward pointer from usb_function to its instance usb: gadget: udc-core: introduce UDC binding by name usb: gadget: factor out two helper functions from composite_bind() usb: gadget: export composite's setup disconnect function usb: gadget: composite: introduce usb_gstrings_attach() usb: gadget: f_acm: use usb_gstrings_attach() Tejun Heo (1): usb: gadget: at91_udc: don't use [delayed_]work_pending() Wei Yongjun (1): usb: gadget: remove unused variable in uac2_pcm_trigger() drivers/usb/gadget/Kconfig | 20
[GIT PULL] usb: phy: patches for v3.9
Hi Greg, Here are some transceiver changes for v3.9 merge window. This tag merged clean, but there were some automatic merge resolutions by git. The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/xceiv-for-v3.9 for you to fetch changes up to 5088b6f5bcf1747345ef9fe217fc80935b1b07df: usb: dwc3: core: add dt support for dwc3 core (2013-01-25 13:17:54 +0200) usb: xceiv: patches for v3.9 merge window Two new PHY drivers coming here: one for Samsung, one for OMAP. Both architectures are adding USB3 support to mainline kernel. The PHY layer now allows us to have mulitple PHYs of the same type, which is necessary for platforms which provide more than one USB peripheral port. There's also a few cleanups here: removal of __dev* annotations, conversion of a cast to to_delayed_work(), and mxs-phy learns about -set_suspend. Cesar Eduardo Barros (1): usb: phy: mv-otg: use to_delayed_work instead of cast Kishon Vijay Abraham I (10): usb: otg: add an api to bind the usb controller and phy usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type usb: otg: add device tree support to otg library usb: phy: add a new driver for usb part of control module usb: start using the control module driver usb: phy: add a new driver for usb3 phy usb: musb: omap: make use of the new PHY lib APIs usb: musb: omap: get phy by phandle for dt boot usb: phy: omap-usb2: enable 960Mhz clock for omap5 usb: dwc3: core: add dt support for dwc3 core Peter Chen (1): usb: phy: mxs-phy: add set_suspend API Praveen Paneri (2): usb: phy: samsung: Introducing usb phy driver for hsotg usb: phy: s3c-hsotg: adding phy driver support Vivek Gautam (6): usb: phy: samsung: Add support to set pmu isolation ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support usb: phy: samsung: Remove __devinit, __devexit_p and __exit annotations Documentation/devicetree/bindings/usb/dwc3.txt | 22 + Documentation/devicetree/bindings/usb/omap-usb.txt | 34 +- .../devicetree/bindings/usb/samsung-usbphy.txt | 55 ++ Documentation/devicetree/bindings/usb/usb-phy.txt | 35 +- drivers/usb/dwc3/core.c| 24 +- drivers/usb/gadget/s3c-hsotg.c | 37 +- drivers/usb/host/ehci-s5p.c| 81 +- drivers/usb/host/ohci-exynos.c | 85 +- drivers/usb/musb/Kconfig | 1 + drivers/usb/musb/omap2430.c| 75 +- drivers/usb/musb/omap2430.h| 9 - drivers/usb/otg/mv_otg.c | 2 +- drivers/usb/otg/mxs-phy.c | 20 + drivers/usb/otg/otg.c | 235 +- drivers/usb/otg/twl4030-usb.c | 3 +- drivers/usb/phy/Kconfig| 29 + drivers/usb/phy/Makefile | 3 + drivers/usb/phy/omap-control-usb.c | 295 +++ drivers/usb/phy/omap-usb2.c| 72 +- drivers/usb/phy/omap-usb3.c| 355 drivers/usb/phy/samsung-usbphy.c | 930 + include/linux/platform_data/samsung-usbphy.h | 27 + include/linux/usb/omap_control_usb.h | 92 ++ include/linux/usb/omap_usb.h | 27 +- include/linux/usb/phy.h| 43 + include/linux/usb/samsung_usb_phy.h| 16 + 26 files changed, 2449 insertions(+), 158 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/omap-control-usb.c create mode 100644 drivers/usb/phy/omap-usb3.c create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h create mode 100644 include/linux/usb/omap_control_usb.h create mode 100644 include/linux/usb/samsung_usb_phy.h -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
Hi, On Fri, Jan 25, 2013 at 04:14:02PM +, Mark Rutland wrote: On Fri, Jan 25, 2013 at 02:59:28PM +, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 12:29:43PM +, Mark Rutland wrote: + depending upon omap4 or omap5. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,type: This is used to differentiate whether the control module has + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to + notify events to the musb core and omap5 has usb3 phy power register to + power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3 + phy power. Why not make this a string property, perhaps values mailbox or register? NAK. Can I ask what your objection to using a string property is? As far as I can see, ti,type is only used by this driver, so there's no common convention to stick to. Using a string makes the binding easier for humans to read, and thus harder to mess up in a dts, and it decouples the binding from kernel-side constants. IIRC there is some work going on to add #define-like support for DT, which would allow us to match against integers while still having meaningful symbolic representations. I was under the impression that the motivation for using the preprocessor on the DT was to allow symbolic names for device/soc-specific values like addresses, rather than what amounts to ABI values for the binding. I don't see the point in building a binding that depends on future functionality to be legible, especially as we can make it more readable, robust, and just as extensible today, with a simple change to the proposed binding. Even ignoring the above, the driver isn't doing appropriate sanity checking. If you use a string property, this sanity check is implicit in the parsing -- you've either matched a value you can handle or you haven't. Even IRQs use numbers (not talking about the IRQ number, but the IRQ flags), why would we depend on string comparisson ? It doesn't make sense. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 2/3] usb: gadget: introduce gadget state tracking
On Fri, Jan 25, 2013 at 08:07:31AM -0800, Greg KH wrote:
On Fri, Jan 25, 2013 at 05:31:35PM +0200, Felipe Balbi wrote:
Hi,
On Fri, Jan 25, 2013 at 10:27:24AM -0500, Alan Stern wrote:
On Fri, 25 Jan 2013, Felipe Balbi wrote:
I guess it would be good to have a:
enum usb_gadget_state usb_gadget_get_state(struct usb_gadget *gadget)
{
return gadget-state;
}
right ?? At least dwc3 can make use of it.
This seems like unnecessary embellishment. What's wrong with typing
gadget-state
instead of
usb_gadget_get_state(gadget)
? Do you have some reason to think the state field will need further
encapsulation in the future?
not really, just that a setter() usually follows up a getter(). But...
meh... no strong feelings
I would argue that for something as simple as -state, you don't even
need a setter() function. This is C, not Java :)
hehe, the setter also does a sysfs notify ;-)
--
balbi
signature.asc
Description: Digital signature
Re: Add USB Device
On 1/25/13, Greg KH gre...@linuxfoundation.org wrote: On Fri, Jan 25, 2013 at 09:30:25AM -0500, Hoyt Duff wrote: Vendor ID: 0x04b4 Device ID: 0x6830 Cypress Semiconductor USB2.0 Storage Device # uname -a Linux titan.maximumhoyt.com 3.4.24-desktop-3.mga2 #1 SMP Sat Jan 5 02:42:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/bus/usb/devices Why do we need to add this device? Does it not work properly with the existing kernel driver? confused, greg k-h Thanks for the reply. It appears to work fine, but it's not on the list. Is that not a valid reason to add it? If it is not, then ignore the request. -- Hoyt -- 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
Re: Add USB Device
On Fri, Jan 25, 2013 at 11:31:00AM -0500, Hoyt Duff wrote: On 1/25/13, Greg KH gre...@linuxfoundation.org wrote: On Fri, Jan 25, 2013 at 09:30:25AM -0500, Hoyt Duff wrote: Vendor ID: 0x04b4 Device ID: 0x6830 Cypress Semiconductor USB2.0 Storage Device # uname -a Linux titan.maximumhoyt.com 3.4.24-desktop-3.mga2 #1 SMP Sat Jan 5 02:42:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/bus/usb/devices Why do we need to add this device? Does it not work properly with the existing kernel driver? confused, greg k-h Thanks for the reply. It appears to work fine, but it's not on the list. Is that not a valid reason to add it? I'm confused, what list are you referring to? thanks, greg k-h -- 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
Re: [PATCH v4 2/3] usb: gadget: introduce gadget state tracking
On Fri, Jan 25, 2013 at 06:27:20PM +0200, Felipe Balbi wrote:
On Fri, Jan 25, 2013 at 08:07:31AM -0800, Greg KH wrote:
On Fri, Jan 25, 2013 at 05:31:35PM +0200, Felipe Balbi wrote:
Hi,
On Fri, Jan 25, 2013 at 10:27:24AM -0500, Alan Stern wrote:
On Fri, 25 Jan 2013, Felipe Balbi wrote:
I guess it would be good to have a:
enum usb_gadget_state usb_gadget_get_state(struct usb_gadget *gadget)
{
return gadget-state;
}
right ?? At least dwc3 can make use of it.
This seems like unnecessary embellishment. What's wrong with typing
gadget-state
instead of
usb_gadget_get_state(gadget)
? Do you have some reason to think the state field will need further
encapsulation in the future?
not really, just that a setter() usually follows up a getter(). But...
meh... no strong feelings
I would argue that for something as simple as -state, you don't even
need a setter() function. This is C, not Java :)
hehe, the setter also does a sysfs notify ;-)
Ah, missed that. Ok, that's fine :)
greg k-h
--
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
Re: [PATCH v2] usb: add driver for xsens motion trackers
On Fri, Jan 25, 2013 at 05:05:44PM +0100, Frans Klaver wrote:
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
This is a revision of the xsens_mt module. Since previous one, I've
reduced the allocated buffers, cause there seem to be no problems with
the default size right now.
That's good. Bigger buffers can make things go faster, but only up to a
point, it's nice to hear that our default sizes work well.
Filtering the correct interface has been moved to the probe function,
which seems more appropriate. Filtering in attach is slightly easier,
but returning any error will result in EIO.
That's the proper place for it (probe).
I'd remove the bNumEndpoints if I could.
What do you mean by that? You are iterating over the endpoints
correctly in the code:
+static int has_required_endpoints(const struct usb_host_interface *interface)
+{
+ __u8 i;
+ int has_bulk_in = 0;
+ int has_bulk_out = 0;
+
+ for (i = 0; i interface-desc.bNumEndpoints; ++i) {
+ if (usb_endpoint_is_bulk_in(interface-endpoint[i].desc))
+ has_bulk_in = 1;
+ else if (usb_endpoint_is_bulk_out(interface-endpoint[i].desc))
+ has_bulk_out = 1;
+ }
+
+ return has_bulk_in has_bulk_out;
+}
Well, only one _very_ tiny issue. And it's nothing to stop me from
taking this patch, but only for you to know about.
Variable types that start with __ are there as they cross the
user/kernel boundry. On the kernel side, they can always be referenced
by using the non-__ type, as it is the same. So you almost never see
local variables with the __ type.
So you really should just make the first line of this function be:
u8 i;
But it's not a big deal at all, I'll go queue this patch up now.
Nice job with it,
greg k-h
--
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
Re: [GIT PULL] usb: musb: patches for v3.9:x
On Fri, Jan 25, 2013 at 06:15:03PM +0200, Felipe Balbi wrote: Hi Greg, here's MUSB's pull request. Let me know if you want any changes. This one merged cleanly on top of your usb-next branch. The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/musb-for-v3.9 Pulled and pushed out, thanks. greg k-h -- 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
Re: [GIT PULL] usb: dwc3: patches for v3.9
On Fri, Jan 25, 2013 at 06:16:11PM +0200, Felipe Balbi wrote: Hi Greg, here's dwc3 for v3.9 merge window. It also merged just fine with your usb-next branch. The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/dwc3-for-v3.9 Pulled and pushed out, thanks. greg k-h -- 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
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Fri, Jan 25, 2013 at 04:23:46PM +, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 04:14:02PM +, Mark Rutland wrote: On Fri, Jan 25, 2013 at 02:59:28PM +, Felipe Balbi wrote: Hi, On Fri, Jan 25, 2013 at 12:29:43PM +, Mark Rutland wrote: + depending upon omap4 or omap5. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,type: This is used to differentiate whether the control module has + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to + notify events to the musb core and omap5 has usb3 phy power register to + power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3 + phy power. Why not make this a string property, perhaps values mailbox or register? NAK. Can I ask what your objection to using a string property is? As far as I can see, ti,type is only used by this driver, so there's no common convention to stick to. Using a string makes the binding easier for humans to read, and thus harder to mess up in a dts, and it decouples the binding from kernel-side constants. IIRC there is some work going on to add #define-like support for DT, which would allow us to match against integers while still having meaningful symbolic representations. I was under the impression that the motivation for using the preprocessor on the DT was to allow symbolic names for device/soc-specific values like addresses, rather than what amounts to ABI values for the binding. I don't see the point in building a binding that depends on future functionality to be legible, especially as we can make it more readable, robust, and just as extensible today, with a simple change to the proposed binding. Even ignoring the above, the driver isn't doing appropriate sanity checking. If you use a string property, this sanity check is implicit in the parsing -- you've either matched a value you can handle or you haven't. Even IRQs use numbers (not talking about the IRQ number, but the IRQ flags), why would we depend on string comparisson ? It doesn't make sense. When describing interrupts, the flags are associated with the interrupt number, and don't really make sense on their own. devicetree does not allow you to mix strings and integers in a value, so you'd never be able to encode irq flags with strings without completely breaking away from the way ePAPR describes how to encode interrupts. By using a string property, the binding is self-describing and easy for humans to read and verify. It doesn't add a large overhead to either the driver or the dts, and is no worse (possibly better) for future extension of bindings to support new device variants while retaining backwards compatibility. See the standard status property, which is string encoded. This would still work were it an integer-encoded enumeration. Having it as a string makes the meaning clear to a reader of the dts, and it's trivial for code to deal with. I don't understand why you think encoding a more legible value in the dt does not make sense. Thanks, Mark. -- 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
Re: [GIT PULL] usb: gadget: patches for v3.9
On Fri, Jan 25, 2013 at 06:17:23PM +0200, Felipe Balbi wrote: Hi Greg, Here's the pull request for Gadget framework. Incredible this one also merged just fine ;-) The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/gadget-for-v3.9 Pulled and pushed out. greg k-h -- 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
Re: [GIT PULL] usb: phy: patches for v3.9
On Fri, Jan 25, 2013 at 06:18:54PM +0200, Felipe Balbi wrote: Hi Greg, Here are some transceiver changes for v3.9 merge window. This tag merged clean, but there were some automatic merge resolutions by git. The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/xceiv-for-v3.9 With this, I get the following warning when running 'make oldconfig' warning: (USB_MUSB_HDRC OMAP_USB3) selects OMAP_CONTROL_USB which has unmet direct dependencies (USB_SUPPORT ARCH_OMAP2PLUS) Care to send a follow-on patch/pull to fix it up? Other than that, pulled and pushed out, thanks. greg k-h -- 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
Re: Add USB Device
usb.ids On 1/25/13, Greg KH gre...@linuxfoundation.org wrote: On Fri, Jan 25, 2013 at 11:31:00AM -0500, Hoyt Duff wrote: On 1/25/13, Greg KH gre...@linuxfoundation.org wrote: On Fri, Jan 25, 2013 at 09:30:25AM -0500, Hoyt Duff wrote: Vendor ID: 0x04b4 Device ID: 0x6830 Cypress Semiconductor USB2.0 Storage Device # uname -a Linux titan.maximumhoyt.com 3.4.24-desktop-3.mga2 #1 SMP Sat Jan 5 02:42:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/bus/usb/devices Why do we need to add this device? Does it not work properly with the existing kernel driver? confused, greg k-h Thanks for the reply. It appears to work fine, but it's not on the list. Is that not a valid reason to add it? I'm confused, what list are you referring to? thanks, greg k-h -- Hoyt -- 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
Re: [GIT PULL] usb: phy: patches for v3.9
On Fri, Jan 25, 2013 at 09:13:36AM -0800, Greg KH wrote: On Fri, Jan 25, 2013 at 06:18:54PM +0200, Felipe Balbi wrote: Hi Greg, Here are some transceiver changes for v3.9 merge window. This tag merged clean, but there were some automatic merge resolutions by git. The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/xceiv-for-v3.9 With this, I get the following warning when running 'make oldconfig' warning: (USB_MUSB_HDRC OMAP_USB3) selects OMAP_CONTROL_USB which has unmet direct dependencies (USB_SUPPORT ARCH_OMAP2PLUS) Care to send a follow-on patch/pull to fix it up? Other than that, pulled and pushed out, thanks. will do early monday, tks -- balbi signature.asc Description: Digital signature
Re: Add USB Device
It would be helpful if the website provided that direction (or provided that direction in a more clear manner if it already does) instead of implying that one needs to join the mail list. Thanks. On 1/25/13, Greg KH gre...@linuxfoundation.org wrote: On Fri, Jan 25, 2013 at 12:18:36PM -0500, Hoyt Duff wrote: usb.ids The top of the usb.ids file says how to have it updated, please read that and follow the directions there. thanks, greg k-h -- Hoyt -- 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
Re: [Pull Request] USB/xhci: Misc fixes for 3.8.
On Thu, Jan 24, 2013 at 04:19:35PM -0800, Sarah Sharp wrote: The following changes since commit dba63b2f733ebfd89bbb15e8fe8ca10fd3871a7f: USB: EHCI: fix build error in ehci-mxc (2013-01-23 11:27:08 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-01-24 I'll pull this into my tree once 3.8-rc5 is out to make merging and testing easier (for me at least.) thanks, greg k-h -- 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
Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
On Fri, Jan 25, 2013 at 04:18:34PM +0400, Sergei Shtylyov wrote:
Hello.
On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:
From: fangxiaozhi huana...@huawei.com
1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
linux-3.8-rc4/drivers/usb/storage/usb.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22
14:12:42.595238727 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22 14:16:01.398250305
+0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, supplemental l
.useTransport = use_transport, \
}
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name, \
+ .useProtocol = use_protocol, \
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}
Shouldn't the field initilaizers be indented with tab, not space?
Yes it must. fangxiaozhi, please always run your patches through the
scripts/checkpatch.pl tool before sending them out (note, you will have
to ignore the CamelCase warnings your patch produces, but not the other
ones.)
Please do that on both of these patches and resend them.
thanks,
greg k-h
--
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
Re: [PATCH v2] usb: add driver for xsens motion trackers
On Fri, 25 Jan 2013, Greg KH wrote:
+static int has_required_endpoints(const struct usb_host_interface
*interface)
+{
+ __u8 i;
+ int has_bulk_in = 0;
+ int has_bulk_out = 0;
+
+ for (i = 0; i interface-desc.bNumEndpoints; ++i) {
+ if (usb_endpoint_is_bulk_in(interface-endpoint[i].desc))
+ has_bulk_in = 1;
+ else if (usb_endpoint_is_bulk_out(interface-endpoint[i].desc))
+ has_bulk_out = 1;
+ }
+
+ return has_bulk_in has_bulk_out;
+}
Well, only one _very_ tiny issue. And it's nothing to stop me from
taking this patch, but only for you to know about.
Variable types that start with __ are there as they cross the
user/kernel boundry. On the kernel side, they can always be referenced
by using the non-__ type, as it is the same. So you almost never see
local variables with the __ type.
So you really should just make the first line of this function be:
u8 i;
In this case I'd say to make it a plain old
int i;
There's no reason for restricting i to be 8 bits. It isn't a field in
a structure or a member of an array, so saving space isn't an issue.
Neither is sign extension. Why force the compiler to go to extra
effort when using a natural-sized integer will work just as well?
Alan Stern
--
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
Re: Add USB Device
On Fri, Jan 25, 2013 at 12:41:21PM -0500, Hoyt Duff wrote: It would be helpful if the website provided that direction (or provided that direction in a more clear manner if it already does) instead of implying that one needs to join the mail list. Again, you are going to have to be more specific, exactly what web site says that you should email this mailing list? And you never need to join a vger.kernel.org mailing list in order to post something to it, it handles non-subscribers just fine (as long as you don't post html email, it hates that.) thanks, greg k-h -- 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
Re: 3.4.4: disabling irq
On Fri, 25 Jan 2013, Udo van den Heuvel wrote: On 2013-01-02 17:46, Alan Stern wrote: Or else leave those devices unplugged entirely -- use a network login instead of the USB keyboard and mouse. When the motion service is off, i.e. the USB webcam isnt used, the issue does not happen. On the other hand: If it is on, within a few days I see stuff like: Jan 25 03:08:26 s kernel: [128427.542235] irq 18: nobody cared (try booting with the irqpoll option) And when I restart everything: [133977.918683] ohci_hcd :00:13.0: IRQ: 4 805a [133985.698868] ohci_hcd :00:13.0: last IRQ repeated 100 times [134003.770072] ohci_hcd :00:13.0: IRQ: 24 805a [134006.297099] ohci_hcd :00:13.0: last IRQ repeated 100 times This seems pretty clear. The hardware in that OHCI controller is broken. It is issuing interrupt requests when it shouldn't. This isn't a software problem. I don't know of any way to fix it or work around it in the driver. The only thing to do is stop using that controller. Alan Stern -- 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
RE: [PATCH v2 0/2] usb: exynos: Fix compatible strings used for device
Vivek Gautam wrote: Using chip specific compatible string as it should be. So fixing this for ehci-s5p, ohci-exynos and dwc3-exynos which till now used a generic 'exynos' in their compatible strings. Changes from v1: - Changing compatible string from samsung,exynos5250-dwc3 to samsung,exynos5250-dwusb3 as per discussion happened in thread: [PATCH 0/2] usb: exynos: Fix compatible strings used for device. Vivek Gautam (2): usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device usb: dwc3-exynos: Fix compatible strings for the device drivers/usb/dwc3/dwc3-exynos.c |2 +- drivers/usb/host/ehci-s5p.c|2 +- drivers/usb/host/ohci-exynos.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) For now, I'm fine on this series, I'm still thinking we need to sort out the chip name in compatible for IP though. Felipe, please go ahead, if you want my ack, feel free to add: Acked-by: Kukjin Kim kgene@samsung.com Thanks. - Kukjin -- 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
Re: 3.4.4: disabling irq
On Fri, 25 Jan 2013, Alan Stern wrote:
This isn't a software problem. I don't know of any way to fix it or
work around it in the driver. The only thing to do is stop using that
controller.
Spoke too soon. Try this patch; maybe it will help. (You'll have to
remove the debugging patch first.)
Alan Stern
Index: usb-3.8/drivers/usb/host/ohci-hcd.c
===
--- usb-3.8.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.8/drivers/usb/host/ohci-hcd.c
@@ -794,6 +794,9 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_HANDLED;
}
+ /* Clear the pending status bits */
+ ohci_writel(ohci, ints, regs-intrstatus);
+
/* We only care about interrupts that are enabled */
ints = ohci_readl(ohci, regs-intrenable);
@@ -846,7 +849,6 @@ static irqreturn_t ohci_irq (struct usb_
*/
else if (ints OHCI_INTR_RD) {
ohci_vdbg(ohci, resume detect\n);
- ohci_writel(ohci, OHCI_INTR_RD, regs-intrstatus);
set_bit(HCD_FLAG_POLL_RH, hcd-flags);
if (ohci-autostop) {
spin_lock (ohci-lock);
@@ -903,9 +905,8 @@ static irqreturn_t ohci_irq (struct usb_
spin_unlock (ohci-lock);
if (ohci-rh_state == OHCI_RH_RUNNING) {
- ohci_writel (ohci, ints, regs-intrstatus);
ohci_writel (ohci, OHCI_INTR_MIE, regs-intrenable);
- // flush those writes
+ // flush the write
(void) ohci_readl (ohci, ohci-regs-control);
}
--
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
Re: USB issue with kernel 3.6
On Tue, Jan 22, 2013 at 12:45:32PM -0500, Alan Stern wrote: [...] Yes, remove all the previous patches before applying this one. Hi Alan, I tested the kernel with the latest patch you provide. I was not able to reproduce the problem, so it seems this change is fine. The only comment I've is that I'm under the impression that unlinking multiple queue element together was giving a slightly better perfomance, under certain trafic conditions (when working). I guess, if you're confident the code does not have other different issues, you can push it upstream. Thanks again for the support, bye, -- piergiorgio -- 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
Re: PATCH usbip small redesign
On Fri, Jan 25, 2013 at 06:51:17PM +0100, Daniel Danzberger wrote: Hi, in the last few weeks I worked on better support of usbip for embedded devices running openwrt and ddwrt. After compiling the kernel with lockdep, I decided to rewrite the current locking logic and some more parts of the usbip driver: - Rewrote debugging code. Removed sysfs debugging flags and replaced it with macro code for usual debug messages and verbose ones. - Removed sending of unlink urbs. This makes no sense in virtual connections ?! Unlink urbs are now given back in vhci's dequeue function. This has the advantage that the calling usb device driver code does not block until it waits for never returning urbs to complete. I am not very sure if this should stay this way forever ;) But at the moment it makes the code much more stable. - Removed usual usb_hcd_giveback_urb() calls. Some urb completion callback routines assume to be called in interrupt context and do not hold their locks interrupt safe. It's now done by usbip_hcd_giveback_urb. This function disables interrupts first. - Some code cleanups. After theses changes I can run this driver with no more kernel panics and deadlocks. But anyway there are some few usb-storage devices that do not work correctly yet. As far as I debugged it yet, they stop completing after about 12 submitted urbs on the host side with xhci or ehci. But it works with the dwc_otg hcd. After a timeout on the vhci side, the usb-storage code calls a command_abort function that can lead to a deadlock in the usb-storage code. A lockdep output of this attached to this mail. However, detach and reattach the device make it work. I had tested these changes, with 2 x86 machines(kernel 3.2.11 and 3.7.2) and openwrt (kernel 3.3.8 and 3.7.2) on two embedded devices (ARM and MIPS). I have only about 4 usb devices to test with, so please check my changes against all your usb devices. this patch is done by git diff e6577f3189d82a729b13e38f3d135f1becd6d294 from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git tag v3.7.2 Can you break this patch up into the logical parts and send it to the list as documented in the file, Documentation/SubmittingPatches so we can properly review it, and possibly apply them? thanks, greg k-h -- 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
v3.8-rc4: Page Allocation Failure
Hi folks, This now started to happen on my development PC. I'm running v3.8-rc4 with my gadget-specific patches (nothing on the Host side, no gadget code is running here). Below you will find dmesg of the failure which just triggered. Looks like it's related to the async function call problem which is going on, just thought I'd report anyway ;-) [632211.063220] usb 1-4: USB disconnect, device number 44 [632213.132568] usb 1-4: new high-speed USB device number 45 using ehci-pci [632213.249429] usb 1-4: New USB device found, idVendor=0951, idProduct=1607 [632213.249434] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [632213.249438] usb 1-4: Product: DataTraveler 2.0 [632213.249441] usb 1-4: Manufacturer: Kingston [632213.249444] usb 1-4: SerialNumber: 001478090230A9105FFF0014 [632213.250497] scsi81 : usb-storage 1-4:1.0 [632214.251418] scsi 81:0:0:0: Direct-Access Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2 [632214.252774] sd 81:0:0:0: Attached scsi generic sg4 type 0 [632214.253281] sd 81:0:0:0: [sdd] 31506432 512-byte logical blocks: (16.1 GB/15.0 GiB) [632214.253995] sd 81:0:0:0: [sdd] Write Protect is off [632214.254000] sd 81:0:0:0: [sdd] Mode Sense: 23 00 00 00 [632214.254768] sd 81:0:0:0: [sdd] No Caching mode page present [632214.254774] sd 81:0:0:0: [sdd] Assuming drive cache: write through [632214.258429] sd 81:0:0:0: [sdd] No Caching mode page present [632214.258434] sd 81:0:0:0: [sdd] Assuming drive cache: write through [632214.259066] kworker/u:3: page allocation failure: order:4, mode:0x2000d0 [632214.259071] Pid: 15804, comm: kworker/u:3 Tainted: GW3.8.0-rc4+ #206 [632214.259073] Call Trace: [632214.259083] [810d02a8] ? warn_alloc_failed+0x116/0x128 [632214.259088] [810d31d9] ? __alloc_pages_nodemask+0x6b5/0x751 [632214.259096] [81106297] ? kmem_getpages+0x59/0x129 [632214.259100] [81106b88] ? fallback_alloc+0x12f/0x1fc [632214.259105] [811071c7] ? kmem_cache_alloc_trace+0x87/0xf6 [632214.259111] [812a633c] ? check_partition+0x28/0x1ac [632214.259116] [812a60bd] ? rescan_partitions+0xa4/0x27c [632214.259121] [8113bcfb] ? __blkdev_get+0x1ac/0x3d2 [632214.259125] [8113c0b1] ? blkdev_get+0x190/0x2d8 [632214.259130] [8113b23f] ? bdget+0x3b/0x12b [632214.259173] [812a41a6] ? add_disk+0x268/0x3e2 [632214.259178] [81382f3d] ? sd_probe_async+0x11b/0x1cc [632214.259184] [81055f74] ? async_run_entry_fn+0xa2/0x173 [632214.259189] [81055ed2] ? async_schedule+0x15/0x15 [632214.259194] [8104bb79] ? process_one_work+0x172/0x2ca [632214.259199] [81055ed2] ? async_schedule+0x15/0x15 [632214.259203] [8104bfa4] ? worker_thread+0x11d/0x1b7 [632214.259207] [8104be87] ? rescuer_thread+0x18c/0x18c [632214.259212] [81050421] ? kthread+0x86/0x8e [632214.259218] [8105039b] ? __kthread_parkme+0x60/0x60 [632214.259233] [814a306c] ? ret_from_fork+0x7c/0xb0 [632214.259241] [8105039b] ? __kthread_parkme+0x60/0x60 [632214.259244] Mem-Info: [632214.259246] Node 0 DMA per-cpu: [632214.259249] CPU0: hi:0, btch: 1 usd: 0 [632214.259252] CPU1: hi:0, btch: 1 usd: 0 [632214.259254] CPU2: hi:0, btch: 1 usd: 0 [632214.259256] CPU3: hi:0, btch: 1 usd: 0 [632214.259258] CPU4: hi:0, btch: 1 usd: 0 [632214.259261] CPU5: hi:0, btch: 1 usd: 0 [632214.259263] CPU6: hi:0, btch: 1 usd: 0 [632214.259269] CPU7: hi:0, btch: 1 usd: 0 [632214.259276] Node 0 DMA32 per-cpu: [632214.259284] CPU0: hi: 186, btch: 31 usd: 0 [632214.259286] CPU1: hi: 186, btch: 31 usd: 0 [632214.259288] CPU2: hi: 186, btch: 31 usd: 0 [632214.259291] CPU3: hi: 186, btch: 31 usd: 0 [632214.259293] CPU4: hi: 186, btch: 31 usd: 0 [632214.259295] CPU5: hi: 186, btch: 31 usd: 0 [632214.259297] CPU6: hi: 186, btch: 31 usd: 0 [632214.259299] CPU7: hi: 186, btch: 31 usd: 0 [632214.259301] Node 0 Normal per-cpu: [632214.259311] CPU0: hi: 186, btch: 31 usd: 0 [632214.259319] CPU1: hi: 186, btch: 31 usd: 0 [632214.259324] CPU2: hi: 186, btch: 31 usd: 0 [632214.259326] CPU3: hi: 186, btch: 31 usd: 0 [632214.259328] CPU4: hi: 186, btch: 31 usd: 0 [632214.259330] CPU5: hi: 186, btch: 31 usd: 0 [632214.259333] CPU6: hi: 186, btch: 31 usd: 0 [632214.259335] CPU7: hi: 186, btch: 31 usd: 0 [632214.259342] active_anon:8098 inactive_anon:16550 isolated_anon:0 [632214.259342] active_file:400259 inactive_file:523089 isolated_file:0 [632214.259342] unevictable:0 dirty:22 writeback:0 unstable:0 [632214.259342] free:77221 slab_reclaimable:474822 slab_unreclaimable:12466 [632214.259342] mapped:4599 shmem:33 pagetables:2364 bounce:0 [632214.259342] free_cma:0 [632214.259348] Node 0 DMA free:15904kB min:168kB low:208kB high:252kB
Re: [PATCH v2] usb: add driver for xsens motion trackers
On Fri, Jan 25, 2013 at 6:47 PM, Alan Stern st...@rowland.harvard.edu wrote: There's no reason for restricting i to be 8 bits. It isn't a field in a structure or a member of an array, so saving space isn't an issue. Neither is sign extension. Why force the compiler to go to extra effort when using a natural-sized integer will work just as well? I'm not very keen on introducing possible warnings about signed/unsigned comparison or somesuch. Of course I could have done something like int num_endpoints = interface-desc.bNumEndpoints; int i; for (...) to remove any warnings. It would of course depend on the warning level you're compiling with. It's not a big deal to me to change it, if anyone insists. Thanks, Frans -- 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
Re: [PATCH v2] usb: add driver for xsens motion trackers
On Fri, Jan 25, 2013 at 5:51 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Jan 25, 2013 at 05:05:44PM +0100, Frans Klaver wrote:
Filtering the correct interface has been moved to the probe function,
which seems more appropriate. Filtering in attach is slightly easier,
but returning any error will result in EIO.
That's the proper place for it (probe).
I thought as much. There are some other drivers that filter out
interfaces using attach, though.
I'd remove the bNumEndpoints if I could.
What do you mean by that?
checkpatch was warning me about camel casing.
+static int has_required_endpoints(const struct usb_host_interface
*interface)
+{
+ __u8 i;
snip
+}
Well, only one _very_ tiny issue. And it's nothing to stop me from
taking this patch, but only for you to know about.
Variable types that start with __ are there as they cross the
user/kernel boundry. On the kernel side, they can always be referenced
by using the non-__ type, as it is the same. So you almost never see
local variables with the __ type.
So you really should just make the first line of this function be:
u8 i;
But it's not a big deal at all, I'll go queue this patch up now.
I wasn't aware of that. Feel free to remove the leading underscores,
if that's acceptable.
Thanks,
Frans
--
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
Re: [PATCH v2] usb: add driver for xsens motion trackers
On Fri, Jan 25, 2013 at 08:50:46PM +0100, Frans Klaver wrote:
On Fri, Jan 25, 2013 at 5:51 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Jan 25, 2013 at 05:05:44PM +0100, Frans Klaver wrote:
Filtering the correct interface has been moved to the probe function,
which seems more appropriate. Filtering in attach is slightly easier,
but returning any error will result in EIO.
That's the proper place for it (probe).
I thought as much. There are some other drivers that filter out
interfaces using attach, though.
I'd remove the bNumEndpoints if I could.
What do you mean by that?
checkpatch was warning me about camel casing.
checkpatch is stupid at times, thanks for ignoring it in this case :)
+static int has_required_endpoints(const struct usb_host_interface
*interface)
+{
+ __u8 i;
snip
+}
Well, only one _very_ tiny issue. And it's nothing to stop me from
taking this patch, but only for you to know about.
Variable types that start with __ are there as they cross the
user/kernel boundry. On the kernel side, they can always be referenced
by using the non-__ type, as it is the same. So you almost never see
local variables with the __ type.
So you really should just make the first line of this function be:
u8 i;
But it's not a big deal at all, I'll go queue this patch up now.
I wasn't aware of that. Feel free to remove the leading underscores,
if that's acceptable.
It's not a big deal at all, I've left it alone, and applied it as-is.
thanks for the clean driver submission,
greg k-h
--
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
