Re: [PATCH] USB: Add uPD78F0730 USB to Serial Adaptor Driver

[kbuild test robot]

Hi Maksim,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.5-rc5 next-20160226]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Maksim-Salau/USB-Add-uPD78F0730-USB-to-Serial-Adaptor-Driver/20160226-213015
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: s390-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All warnings (new ones prefixed by >>):

>> drivers/usb/serial/upd78f0730.c:117:0: warning: "PARITY_NONE" redefined
#define PARITY_NONE 0x00
^
   In file included from include/uapi/linux/if.h:28:0,
from include/linux/compat.h:14,
from arch/s390/include/asm/elf.h:132,
from include/linux/elf.h:4,
from include/linux/module.h:15,
from drivers/usb/serial/upd78f0730.c:28:
   include/uapi/linux/hdlc/ioctl.h:23:0: note: this is the location of the 
previous definition
#define PARITY_NONE  1 /* No parity */
^

vim +/PARITY_NONE +117 drivers/usb/serial/upd78f0730.c

   101  #define SET_DTR_RTS 0x01
   102  #define SET_XON_XOFF_CHR0x02
   103  #define OPEN_CLOSE  0x03
   104  #define SET_ERR_CHR 0x04
   105  
   106  /* Data sizes in LINE_CONTROL command */
   107  #define DATA_SIZE_7_BITS0x00
   108  #define DATA_SIZE_8_BITS0x01
   109  #define DATA_SIZE_MASK  0x01
   110  
   111  /* Stop-bit modes in LINE_CONTROL command */
   112  #define STOP_BIT_1_BIT  0x00
   113  #define STOP_BIT_2_BIT  0x02
   114  #define STOP_BIT_MASK   0x02
   115  
   116  /* Parity modes in LINE_CONTROL command */
 > 117  #define PARITY_NONE 0x00
   118  #define PARITY_EVEN 0x04
   119  #define PARITY_ODD  0x08
   120  #define PARITY_MASK 0x0C
   121  
   122  /* Flow control modes in LINE_CONTROL command */
   123  #define FLOW_CONTROL_NONE   0x00
   124  #define FLOW_CONTROL_HW 0x10
   125  #define FLOW_CONTROL_SW 0x20

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] usb: gadget: bdc_udc: fix race condition in bdc_udc_exit()

[Alexey Khoroshilov]

bdc_ep_disable() expects to be called with bdc->lock held.
The assumption is met in all the cases except for call from bdc_udc_exit(),
that is called from bdc_remove(). As a result a race can happen or unheld
bdc->lock can be unlocked in bdc_req_complete().

The patch proposes to acquire-release bdc->lock around bdc_ep_disable()
in bdc_udc_exit().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/usb/gadget/udc/bdc/bdc_udc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_udc.c 
b/drivers/usb/gadget/udc/bdc/bdc_udc.c
index 7f77db5d1278..aae7458d8986 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_udc.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_udc.c
@@ -581,8 +581,13 @@ err0:
 
 void bdc_udc_exit(struct bdc *bdc)
 {
+   unsigned long flags;
+
dev_dbg(bdc->dev, "%s()\n", __func__);
+   spin_lock_irqsave(&bdc->lock, flags);
bdc_ep_disable(bdc->bdc_ep_array[1]);
+   spin_unlock_irqrestore(&bdc->lock, flags);
+
usb_del_gadget_udc(&bdc->gadget);
bdc_free_ep(bdc);
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: System hangs with weak USB cable

[Alan Stern]

On Fri, 26 Feb 2016, Radosław Warowny wrote:

> > I agree, but where was a crash?  I don't have any context here, was
> > there a kernel oops somewhere?  I thought the hub just reset itself.  I
> > have a hub like that here, it resets itself a few times a day, but
> > there's no kernel crash because of it.
> 
> Yes, there were kernel oopses, you can find details at syslog output
> attached to the bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=112311. I don't cite it
> here since it's too large. I provided two versions of logs - with and
> without  apparmor to exclude it as a cause of problem since there is
> some apparmor call at the first call trace.

It's worth noting that none of the stack traces in that bug report 
mentions USB anywhere.  In every case the problem occurred during 
memory allocation for something else.

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

[PATCH] usb: musb: gadget: fix possible NULL pointer dereference

[John Ogness]

txstate() assumes that if the request buffer is mapped, a DMA channel
is allocated. There is a case here where the DMA channel is released
and then shortly thereafter (in general PIO code) the request buffer
is unmapped. However, in this case unmap_dma_buffer() silently fails
because the DMA channel is already gone. Thus, the next time txstate()
is called, there is a NULL pointer exception because the buffer is
mapped but no DMA channel is allocated.

This patch adds an extra call unmap_dma_buffer() before releasing the
channel.

Signed-off-by: John Ogness 
---
 patch against next-20160226

 drivers/usb/musb/musb_gadget.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 87bd578..c518d3c 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -393,6 +393,7 @@ static void txstate(struct musb *musb, struct musb_request 
*req)
request->dma + request->actual,
request_size);
if (!use_dma) {
+   unmap_dma_buffer(req, musb);
c->channel_release(musb_ep->dma);
musb_ep->dma = NULL;
csr &= ~MUSB_TXCSR_DMAENAB;
-- 
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5 v7] usb: musb: core: added helper functions for parsing DT

[Bin Liu]

Hi,

On Fri, Feb 26, 2016 at 10:29:12AM +0100, Petr Kulhavy wrote:
> 
> On 26.02.2016 04:15, Bin Liu wrote:
> >On Thu, Feb 25, 2016 at 01:04:13PM +0100, Petr Kulhavy wrote:
> >
> >>Well, so we're still at the same point - there is a fundamental
> >>mismatch in the different developers' view how the "power" parameter
> >>should be represented.
> >>There already 3 opinions at the moment:
> >>1) hard code - Felipe, Rob
> >>2) use the "mentor,power" - Sergei, Petr
> >>3) use a regulator - Rob
> >>
> >>So unless this conflict is resolved it is slightly difficult to
> >>submit a patch that would get accepted.
> >>How can we resolve this conflict ?
> >This power property is used by core to control the hub port power
> >budget, which is sourced by vbus. But vbus is not coming from musb, but
> >a board power rail. So hardcode it does not make sense.
> >
> >Regards,
> >-Bin.
> So what would be your take then?

Don't hardcode in 5/5, and drop musb_get_power() in this patch.

Regards,
-Bin.

> 
> Petr
--
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] USB: Add uPD78F0730 USB to Serial Adaptor Driver

[Maksim Salau]

The adaptor can be found on development boards for 78k, RL78 and V850
microcontrollers produced by Renesas Electronics Corporation.

This is not a full-featured USB to serial converter, however it allows
basic communication and simple control which is enough for programming of
on-board flash and debugging through a debug monitor.

uPD78F0730 is a USB-enabled microcontroller with USB-to-UART conversion
implemented in firmware.

This chip is also present in some debugging adaptors which use it for
USB-to-SPI conversion as well. The present driver doesn't cover SPI,
only USB-to-UART conversion is supported.

Signed-off-by: Maksim Salau 
---
 drivers/usb/serial/Kconfig  |   9 +
 drivers/usb/serial/Makefile |   1 +
 drivers/usb/serial/upd78f0730.c | 537 
 3 files changed, 547 insertions(+)
 create mode 100644 drivers/usb/serial/upd78f0730.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index f612dda..f9c0950 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -719,6 +719,15 @@ config USB_SERIAL_QT2
  To compile this driver as a module, choose M here: the
  module will be called quatech-serial.
 
+config USB_SERIAL_UPD78F0730
+   tristate "USB Renesas uPD78F0730 Single Port Serial Driver"
+   help
+ Say Y here if you want to use the Renesas uPD78F0730
+ serial driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called upd78f0730.
+
 config USB_SERIAL_DEBUG
tristate "USB Debugging Device"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index f3fa5e5..7fcb758 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -61,3 +61,4 @@ obj-$(CONFIG_USB_SERIAL_WISHBONE) += 
wishbone-serial.o
 obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
 obj-$(CONFIG_USB_SERIAL_XIRCOM)+= keyspan_pda.o
 obj-$(CONFIG_USB_SERIAL_XSENS_MT)  += xsens_mt.o
+obj-$(CONFIG_USB_SERIAL_UPD78F0730)+= upd78f0730.o
diff --git a/drivers/usb/serial/upd78f0730.c b/drivers/usb/serial/upd78f0730.c
new file mode 100644
index 000..6d90199
--- /dev/null
+++ b/drivers/usb/serial/upd78f0730.c
@@ -0,0 +1,537 @@
+/*
+ * Renesas Electronics uPD78F0730 USB to serial converter driver
+ *
+ * Copyright (C) 2014,2016 Maksim Salau 
+ *
+ * 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.
+ *
+ * Protocol of the adaptor is described in the application note U19660EJ1V0AN00
+ * μPD78F0730 8-bit Single-Chip Microcontroller
+ * USB-to-Serial Conversion Software
+ * 
+ *
+ * The adaptor functionality is limited to the following:
+ * - data bits: 7 or 8
+ * - stop bits: 1 or 2
+ * - parity: even, odd or none
+ * - flow control: XON/XOFF or none
+ * - baudrates: 2400, 4800, 9600, 19200, 38400, 57600, 115200
+ * - signals: DTS, RTS and BREAK
+ * - there is an option to enable parity error character substitution,
+ *   but it is not supported by this driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_DESC "Renesas uPD78F0730 USB to serial converter driver"
+
+#define DRIVER_AUTHOR "Maksim Salau "
+
+static const struct usb_device_id id_table[] = {
+   { USB_DEVICE(0x045B, 0x0212) }, /* YRPBRL78G13, YRPBRL78G14 */
+   { USB_DEVICE(0x0409, 0x0063) }, /* V850ESJX3-STICK */
+   {}
+};
+
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/*
+ * Private data structure type declaration.
+ * Each adaptor is associated with a private structure, that holds the current
+ * state of control signals (DTR, RTS and BREAK).
+ */
+struct upd78f0730_serial_private {
+   spinlock_t  lock;
+   __u8line_signals;
+};
+
+/* Function prototypes */
+static int upd78f0730_send_ctl(struct usb_serial_port *port,
+   void *data, int size);
+static int upd78f0730_attach(struct usb_serial *serial);
+static void upd78f0730_release(struct usb_serial *serial);
+static int upd78f0730_open(struct tty_struct *tty,
+   struct usb_serial_port *port);
+static void upd78f0730_close(struct usb_serial_port *port);
+static void upd78f0730_set_termios(struct tty_struct *tty,
+   struct usb_serial_port *port,
+   struct ktermios *old_termios);
+static int upd78f0730_tiocmget(struct tty_struct *tty);
+static int upd78f0730_tiocmset(struct tty_struct *tty,
+   unsigned int set, unsigned int clear);
+static void upd78f0730_dtr_rts(struct usb_serial_port *port, int on);
+static void upd78f0730_break_ctl(struct tty_struct *tty, int break_state);
+
+static struct usb_serial_driver upd78f0730_device = {
+

Re: [PATCH 1/3] usb: USB Type-C Connector Class

[Heikki Krogerus]

Hi Oliver,

I've missed couple of your questions..

> > > Furthermore, do these files support poll?
> 
> At least the current role and mode can change, so in principle
> poll() makes sense.

Yes I agree. I'll add support for polling.

> > > And lastly we can get "Attention" as a message connected
> > > with a connector in an alternate mode. How does user space
> > > learn about that?
> > 
> > The class should notify the userspace with uevent on
> > connection/disconnection regardless what is being connected, or what
> > mode the connector enters initially.
> 
> Yes, but "Attention" in the sense of 6.4.4.3.6 of the PD spec.
> Does this need to be handled in the kernel? Do we generate a uevent
> for that?

OK, got it. Not for now, but it makes sense, though for example with
UCSI we don't receive any notification in case of Attention, so this
is something that is not going to be always available.

I'm going to be away next week, but I'm planning to prepare v2 of
these patches after that. I'll also propose something for handling
Attention Command and polling then.


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] configfs: switch ->default groups to a linked list

[Felipe Balbi]

Christoph Hellwig  writes:

> Replace the current NULL-terminated array of default groups with a linked
> list.  This gets rid of lots of nasty code to size and/or dynamically
> allocate the array.
>
> While we're at it also provide a conveniant helper to remove the default
> groups.
>

looks ok to my eyes. For drivers/usb/gadget:

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 1/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

This patch adds support for 0x1045 PID of Telit LE922.

Signed-off-by: Daniele Palmas 
---
 drivers/usb/serial/option.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index db86e51..4be2c7c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -270,6 +270,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_UE910_V2 0x1012
 #define TELIT_PRODUCT_LE922_USBCFG00x1042
 #define TELIT_PRODUCT_LE922_USBCFG30x1043
+#define TELIT_PRODUCT_LE922_USBCFG50x1045
 #define TELIT_PRODUCT_LE9200x1200
 #define TELIT_PRODUCT_LE9100x1201
 
@@ -627,6 +628,11 @@ static const struct option_blacklist_info 
telit_le922_blacklist_usbcfg3 = {
.reserved = BIT(1) | BIT(2) | BIT(3),
 };
 
+static const struct option_blacklist_info telit_le922_blacklist_usbcfg5 = {
+   .sendsetup = BIT(2),
+   .reserved = BIT(0) | BIT(1) | BIT(3) | BIT(8) | BIT(9) | BIT(10),
+};
+
 static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1176,6 +1182,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg0 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG3),
.driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg3 },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG5),
+   .driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg5 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
.driver_info = (kernel_ulong_t)&telit_le910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

This patch adds support for PID 0x1045 of Telit LE922.
The reserved usb interfaces belong to an adb device, a RNDIS device and
an audio device.

The usb composition can be set using the AT command AT#USBCFG=5

Following the lsusb output:

Bus 003 Device 122: ID 1bc7:1045 Telit 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x1bc7 Telit
  idProduct  0x1045 
  bcdDevice3.10
  iManufacturer   1 Android
  iProduct2 Android
  iSerial 3 0123456789ABCDEF
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  490
bNumInterfaces 11
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  500mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass224 Wireless
  bFunctionSubClass   1 Radio Frequency
  bFunctionProtocol   3 RNDIS
  iFunction   7 RNDIS
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  3 RNDIS
  iInterface  5 RNDIS Communications Control
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 01
  ** UNRECOGNIZED:  04 24 02 00
  ** UNRECOGNIZED:  05 24 06 00 01
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval   9
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  6 RNDIS Ethernet Data
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass 66 
  bInterfaceProtocol  1 
  iInterface  4 ADB Interface
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAdd

[PATCH] configfs: switch ->default groups to a linked list

[Christoph Hellwig]

Replace the current NULL-terminated array of default groups with a linked
list.  This gets rid of lots of nasty code to size and/or dynamically
allocate the array.

While we're at it also provide a conveniant helper to remove the default
groups.

Signed-off-by: Christoph Hellwig 
---
 Documentation/filesystems/configfs/configfs.txt |  11 +-
 drivers/infiniband/core/cma_configfs.c  |  31 ++--
 drivers/target/iscsi/iscsi_target_configfs.c|  75 +++--
 drivers/target/target_core_configfs.c   | 203 +---
 drivers/target/target_core_fabric_configfs.c| 194 ++
 drivers/target/target_core_internal.h   |   1 -
 drivers/target/target_core_stat.c   |  41 ++---
 drivers/usb/gadget/configfs.c   |  36 ++---
 drivers/usb/gadget/function/f_mass_storage.c|   6 +-
 drivers/usb/gadget/function/f_rndis.c   |   1 -
 drivers/usb/gadget/function/uvc_configfs.c  | 198 +--
 fs/configfs/dir.c   |  44 +++--
 fs/configfs/item.c  |   1 +
 fs/dlm/config.c |  38 +
 fs/ocfs2/cluster/nodemanager.c  |  22 +--
 include/linux/configfs.h|  11 +-
 include/target/target_core_base.h   |   3 -
 17 files changed, 284 insertions(+), 632 deletions(-)

diff --git a/Documentation/filesystems/configfs/configfs.txt 
b/Documentation/filesystems/configfs/configfs.txt
index e5fe521..8ec9136 100644
--- a/Documentation/filesystems/configfs/configfs.txt
+++ b/Documentation/filesystems/configfs/configfs.txt
@@ -250,7 +250,8 @@ child item.
struct config_item  cg_item;
struct list_headcg_children;
struct configfs_subsystem   *cg_subsys;
-   struct config_group **default_groups;
+   struct list_headdefault_groups;
+   struct list_headgroup_entry;
};
 
void config_group_init(struct config_group *group);
@@ -420,15 +421,15 @@ These automatic subgroups, or default groups, do not 
preclude other
 children of the parent group.  If ct_group_ops->make_group() exists,
 other child groups can be created on the parent group directly.
 
-A configfs subsystem specifies default groups by filling in the
-NULL-terminated array default_groups on the config_group structure.
-Each group in that array is populated in the configfs tree at the same
+A configfs subsystem specifies default groups by adding them using the
+configfs_add_default_group() function to the parent config_group
+structure.  Each added group is populated in the configfs tree at the same
 time as the parent group.  Similarly, they are removed at the same time
 as the parent.  No extra notification is provided.  When a ->drop_item()
 method call notifies the subsystem the parent group is going away, it
 also means every default group child associated with that parent group.
 
-As a consequence of this, default_groups cannot be removed directly via
+As a consequence of this, default groups cannot be removed directly via
 rmdir(2).  They also are not considered when rmdir(2) on the parent
 group is checking for children.
 
diff --git a/drivers/infiniband/core/cma_configfs.c 
b/drivers/infiniband/core/cma_configfs.c
index 18b112a..41573df 100644
--- a/drivers/infiniband/core/cma_configfs.c
+++ b/drivers/infiniband/core/cma_configfs.c
@@ -49,8 +49,6 @@ struct cma_dev_group {
charname[IB_DEVICE_NAME_MAX];
struct config_group device_group;
struct config_group ports_group;
-   struct config_group *default_dev_group[2];
-   struct config_group **default_ports_group;
struct cma_dev_port_group   *ports;
 };
 
@@ -158,7 +156,6 @@ static int make_cma_ports(struct cma_dev_group 
*cma_dev_group,
unsigned int i;
unsigned int ports_num;
struct cma_dev_port_group *ports;
-   struct config_group **ports_group;
int err;
 
ibdev = cma_get_ib_dev(cma_dev);
@@ -169,9 +166,8 @@ static int make_cma_ports(struct cma_dev_group 
*cma_dev_group,
ports_num = ibdev->phys_port_cnt;
ports = kcalloc(ports_num, sizeof(*cma_dev_group->ports),
GFP_KERNEL);
-   ports_group = kcalloc(ports_num + 1, sizeof(*ports_group), GFP_KERNEL);
 
-   if (!ports || !ports_group) {
+   if (!ports) {
err = -ENOMEM;
goto free;
}
@@ -185,18 +181,16 @@ static int make_cma_ports(struct cma_dev_group 
*cma_dev_group,
config_group_init_type_name(&ports[i].group,
port_str,
&cma_port_group_type);
-   ports_group[i] = &ports[i].group;
+   configfs_a

RE: USB: core: let USB device know device node

[Peter Chen]

 
> 
> Hi,
> 
> I'm wondering if you plan to include the "USB: core: let USB device know 
> device
> node" change in 4.6? I didn't see it hit the next tree yet and I'd like to 
> submit
> patches that would need it (MAC address for USB ethernet for Raspberry Pi).
> 

I have already submitted it, Greg will queue it for v4.6 if nothing special.
But you may not submit a patch depends on other subsystem's next tree,
I am not sure if it will cause a build error.

Ideally, you should submit it until you see this patch at linus tree, eg, 
v4.6-rc1 is out.

Peter

Re: [PATCH 2/5 v7] usb: musb: core: added helper functions for parsing DT

[Petr Kulhavy]

On 26.02.2016 04:15, Bin Liu wrote:

On Thu, Feb 25, 2016 at 01:04:13PM +0100, Petr Kulhavy wrote:


Well, so we're still at the same point - there is a fundamental
mismatch in the different developers' view how the "power" parameter
should be represented.
There already 3 opinions at the moment:
1) hard code - Felipe, Rob
2) use the "mentor,power" - Sergei, Petr
3) use a regulator - Rob

So unless this conflict is resolved it is slightly difficult to
submit a patch that would get accepted.
How can we resolve this conflict ?

This power property is used by core to control the hub port power
budget, which is sourced by vbus. But vbus is not coming from musb, but
a board power rail. So hardcode it does not make sense.

Regards,
-Bin.

So what would be your take then?

Petr
--
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