[PATCH v3 18/46] usb: gadget: gr_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/gr_udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index c886887..8aa2593 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -2018,12 +2018,23 @@ static int gr_ep_init(struct gr_udc *dev, int num, int 
is_in, u32 maxplimit)
 
usb_ep_set_maxpacket_limit(&ep->ep, MAX_CTRL_PL_SIZE);
ep->bytes_per_buffer = MAX_CTRL_PL_SIZE;
+
+   ep->ep.caps.type_control = true;
} else {
usb_ep_set_maxpacket_limit(&ep->ep, (u16)maxplimit);
list_add_tail(&ep->ep.ep_list, &dev->gadget.ep_list);
+
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
}
list_add_tail(&ep->ep_list, &dev->ep_list);
 
+   if (is_in)
+   ep->ep.caps.dir_in = true;
+   else
+   ep->ep.caps.dir_out = true;
+
ep->tailbuf = dma_alloc_coherent(dev->dev, ep->ep.maxpacket_limit,
 &ep->tailbuf_paddr, GFP_ATOMIC);
if (!ep->tailbuf)
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 19/46] usb: gadget: lpc32xx_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/lpc32xx_udc.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c 
b/drivers/usb/gadget/udc/lpc32xx_udc.c
index 3b6a785..00b5006 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -2575,6 +2575,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep0",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 0,
@@ -2586,6 +2588,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep1-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 2,
@@ -2597,6 +2601,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep2-bulk",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 4,
@@ -2608,6 +2614,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep3-iso",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 1023,
.hwep_num_base  = 6,
@@ -2619,6 +2627,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep4-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 8,
@@ -2630,6 +2640,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep5-bulk",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 10,
@@ -2641,6 +2653,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep6-iso",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 1023,
.hwep_num_base  = 12,
@@ -2652,6 +2666,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep7-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 14,
@@ -2663,6 +2679,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep8-bulk",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 16,
@@ -2674,6 +2692,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep9-iso",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 1023,
.hwep_num_base  = 18,
@@ -2685,6 +2705,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep10-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
   

[PATCH v3 17/46] usb: gadget: goku_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/goku_udc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/gadget/udc/goku_udc.c 
b/drivers/usb/gadget/udc/goku_udc.c
index 9e8d842..46b8d14 100644
--- a/drivers/usb/gadget/udc/goku_udc.c
+++ b/drivers/usb/gadget/udc/goku_udc.c
@@ -1257,6 +1257,14 @@ static void udc_reinit (struct goku_udc *dev)
INIT_LIST_HEAD (&ep->queue);
 
ep_reset(NULL, ep);
+
+   if (i == 0)
+   ep->ep.caps.type_control = true;
+   else
+   ep->ep.caps.type_bulk = true;
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
 
dev->ep[0].reg_mode = NULL;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 16/46] usb: gadget: fusb300_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/fusb300_udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index 3970f45..948845c 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1450,6 +1450,17 @@ static int fusb300_probe(struct platform_device *pdev)
ep->ep.name = fusb300_ep_name[i];
ep->ep.ops = &fusb300_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, HS_BULK_MAX_PACKET_SIZE);
+
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&fusb300->ep[0]->ep, HS_CTL_MAX_PACKET_SIZE);
fusb300->ep[0]->epnum = 0;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 14/46] usb: gadget: fsl_qe_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/fsl_qe_udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index e0822f1..5fb6f8b 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -2417,6 +2417,17 @@ static int qe_ep_config(struct qe_udc *udc, unsigned 
char pipe_num)
strcpy(ep->name, ep_name[pipe_num]);
ep->ep.name = ep_name[pipe_num];
 
+   if (pipe_num == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
+
ep->ep.ops = &qe_ep_ops;
ep->stopped = 1;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 15/46] usb: gadget: fsl_udc_core: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index c60022b..aab5221 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2313,6 +2313,19 @@ static int struct_ep_setup(struct fsl_udc *udc, unsigned 
char index,
ep->ep.ops = &fsl_ep_ops;
ep->stopped = 0;
 
+   if (index == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   if (index & 1)
+   ep->ep.caps.dir_in = true;
+   else
+   ep->ep.caps.dir_out = true;
+
/* for ep0: maxP defined in desc
 * for other eps, maxP is set by epautoconfig() called by gadget layer
 */
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 13/46] usb: gadget: fotg210-udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/fotg210-udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/fotg210-udc.c 
b/drivers/usb/gadget/udc/fotg210-udc.c
index e547ea7..960c70c 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -1153,6 +1153,17 @@ static int fotg210_udc_probe(struct platform_device 
*pdev)
ep->ep.name = fotg210_ep_name[i];
ep->ep.ops = &fotg210_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
+
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&fotg210->ep[0]->ep, 0x40);
fotg210->gadget.ep0 = &fotg210->ep[0]->ep;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 12/46] usb: gadget: dummy-hcd: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/dummy_hcd.c | 65 +-
 1 file changed, 50 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/dummy_hcd.c 
b/drivers/usb/gadget/udc/dummy_hcd.c
index 181112c..69fd29a 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -127,23 +127,57 @@ static inline struct dummy_request 
*usb_request_to_dummy_request
 
 static const char ep0name[] = "ep0";
 
-static const char *const ep_name[] = {
-   ep0name,/* everyone has ep0 */
+static const struct {
+   const char *name;
+   const struct usb_ep_caps caps;
+} ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+   { \
+   .name = _name, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+   USB_EP_CAPS_DIR_ ## _dir), \
+   }
 
+   /* everyone has ep0 */
+   EP_INFO(ep0name,CONTROL, ALL),
/* act like a pxa250: fifteen fixed function endpoints */
-   "ep1in-bulk", "ep2out-bulk", "ep3in-iso", "ep4out-iso", "ep5in-int",
-   "ep6in-bulk", "ep7out-bulk", "ep8in-iso", "ep9out-iso", "ep10in-int",
-   "ep11in-bulk", "ep12out-bulk", "ep13in-iso", "ep14out-iso",
-   "ep15in-int",
-
+   EP_INFO("ep1in-bulk",   BULK,   IN),
+   EP_INFO("ep2out-bulk",  BULK,   OUT),
+   EP_INFO("ep3in-iso",ISO,IN),
+   EP_INFO("ep4out-iso",   ISO,OUT),
+   EP_INFO("ep5in-int",INT,IN),
+   EP_INFO("ep6in-bulk",   BULK,   IN),
+   EP_INFO("ep7out-bulk",  BULK,   OUT),
+   EP_INFO("ep8in-iso",ISO,IN),
+   EP_INFO("ep9out-iso",   ISO,OUT),
+   EP_INFO("ep10in-int",   INT,IN),
+   EP_INFO("ep11in-bulk",  BULK,   IN),
+   EP_INFO("ep12out-bulk", BULK,   OUT),
+   EP_INFO("ep13in-iso",   ISO,IN),
+   EP_INFO("ep14out-iso",  ISO,OUT),
+   EP_INFO("ep15in-int",   INT,IN),
/* or like sa1100: two fixed function endpoints */
-   "ep1out-bulk", "ep2in-bulk",
-
+   EP_INFO("ep1out-bulk",  BULK,   OUT),
+   EP_INFO("ep2in-bulk",   BULK,   IN),
/* and now some generic EPs so we have enough in multi config */
-   "ep3out", "ep4in", "ep5out", "ep6out", "ep7in", "ep8out", "ep9in",
-   "ep10out", "ep11out", "ep12in", "ep13out", "ep14in", "ep15out",
+   EP_INFO("ep3out",   ALL,OUT),
+   EP_INFO("ep4in",ALL,IN),
+   EP_INFO("ep5out",   ALL,OUT),
+   EP_INFO("ep6out",   ALL,OUT),
+   EP_INFO("ep7in",ALL,IN),
+   EP_INFO("ep8out",   ALL,OUT),
+   EP_INFO("ep9in",ALL,IN),
+   EP_INFO("ep10out",  ALL,OUT),
+   EP_INFO("ep11out",  ALL,OUT),
+   EP_INFO("ep12in",   ALL,IN),
+   EP_INFO("ep13out",  ALL,OUT),
+   EP_INFO("ep14in",   ALL,IN),
+   EP_INFO("ep15out",  ALL,OUT),
+
+#undef EP_INFO
 };
-#define DUMMY_ENDPOINTSARRAY_SIZE(ep_name)
+
+#define DUMMY_ENDPOINTSARRAY_SIZE(ep_info)
 
 /*-*/
 
@@ -938,9 +972,10 @@ static void init_dummy_udc_hw(struct dummy *dum)
for (i = 0; i < DUMMY_ENDPOINTS; i++) {
struct dummy_ep *ep = &dum->ep[i];
 
-   if (!ep_name[i])
+   if (!ep_info[i].name)
break;
-   ep->ep.name = ep_name[i];
+   ep->ep.name = ep_info[i].name;
+   ep->ep.caps = ep_info[i].caps;
ep->ep.ops = &dummy_ep_ops;
list_add_tail(&ep->ep.ep_list, &dum->gadget.ep_list);
ep->halted = ep->wedged = ep->already_seen =
@@ -1684,7 +1719,7 @@ static void dummy_timer(unsigned long _dum_hcd)
}
 
for (i = 0; i < DUMMY_ENDPOINTS; i++) {
-   if (!ep_name[i])
+   if (!ep_info[i].name)
break;
dum->ep[i].already_seen = 0;
}
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 10/46] usb: gadget: bcm63xx_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/bcm63xx_udc.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/bcm63xx_udc.c 
b/drivers/usb/gadget/udc/bcm63xx_udc.c
index 9db968b..c5e0894 100644
--- a/drivers/usb/gadget/udc/bcm63xx_udc.c
+++ b/drivers/usb/gadget/udc/bcm63xx_udc.c
@@ -44,9 +44,25 @@
 #define DRV_MODULE_NAME"bcm63xx_udc"
 
 static const char bcm63xx_ep0name[] = "ep0";
-static const char *const bcm63xx_ep_name[] = {
-   bcm63xx_ep0name,
-   "ep1in-bulk", "ep2out-bulk", "ep3in-int", "ep4out-int",
+
+static const struct {
+   const char *name;
+   const struct usb_ep_caps caps;
+} bcm63xx_ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+   { \
+   .name = _name, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+   USB_EP_CAPS_DIR_ ## _dir), \
+   }
+
+   EP_INFO(bcm63xx_ep0name, CONTROL, ALL),
+   EP_INFO("ep1in-bulk",   BULK,   IN),
+   EP_INFO("ep2out-bulk",  BULK,   OUT),
+   EP_INFO("ep3in-int",INT,IN),
+   EP_INFO("ep4out-int",   INT,OUT),
+
+#undef EP_INFO
 };
 
 static bool use_fullspeed;
@@ -943,7 +959,8 @@ static int bcm63xx_init_udc_hw(struct bcm63xx_udc *udc)
for (i = 0; i < BCM63XX_NUM_EP; i++) {
struct bcm63xx_ep *bep = &udc->bep[i];
 
-   bep->ep.name = bcm63xx_ep_name[i];
+   bep->ep.name = bcm63xx_ep_info[i].name;
+   bep->ep.caps = bcm63xx_ep_info[i].caps;
bep->ep_num = i;
bep->ep.ops = &bcm63xx_udc_ep_ops;
list_add_tail(&bep->ep.ep_list, &udc->gadget.ep_list);
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 11/46] usb: gadget: bdc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/bdc/bdc_ep.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index b04980c..f9a8f57 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -1952,12 +1952,18 @@ static int init_ep(struct bdc *bdc, u32 epnum, u32 dir)
ep->bdc = bdc;
ep->dir = dir;
 
+   if (dir)
+   ep->usb_ep.caps.dir_in = true;
+   else
+   ep->usb_ep.caps.dir_out = true;
+
/* ep->ep_num is the index inside bdc_ep */
if (epnum == 1) {
ep->ep_num = 1;
bdc->bdc_ep_array[ep->ep_num] = ep;
snprintf(ep->name, sizeof(ep->name), "ep%d", epnum - 1);
usb_ep_set_maxpacket_limit(&ep->usb_ep, EP0_MAX_PKT_SIZE);
+   ep->usb_ep.caps.type_control = true;
ep->comp_desc = NULL;
bdc->gadget.ep0 = &ep->usb_ep;
} else {
@@ -1971,6 +1977,9 @@ static int init_ep(struct bdc *bdc, u32 epnum, u32 dir)
 dir & 1 ? "in" : "out");
 
usb_ep_set_maxpacket_limit(&ep->usb_ep, 1024);
+   ep->usb_ep.caps.type_iso = true;
+   ep->usb_ep.caps.type_bulk = true;
+   ep->usb_ep.caps.type_int = true;
ep->usb_ep.max_streams = 0;
list_add_tail(&ep->usb_ep.ep_list, &bdc->gadget.ep_list);
}
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 08/46] usb: gadget: amd5536udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/amd5536udc.c | 57 ++---
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/udc/amd5536udc.c 
b/drivers/usb/gadget/udc/amd5536udc.c
index de7e5e2..1a1d91c 100644
--- a/drivers/usb/gadget/udc/amd5536udc.c
+++ b/drivers/usb/gadget/udc/amd5536udc.c
@@ -138,15 +138,51 @@ static DECLARE_TASKLET(disconnect_tasklet, 
udc_tasklet_disconnect,
 
 /* endpoint names used for print */
 static const char ep0_string[] = "ep0in";
-static const char *const ep_string[] = {
-   ep0_string,
-   "ep1in-int", "ep2in-bulk", "ep3in-bulk", "ep4in-bulk", "ep5in-bulk",
-   "ep6in-bulk", "ep7in-bulk", "ep8in-bulk", "ep9in-bulk", "ep10in-bulk",
-   "ep11in-bulk", "ep12in-bulk", "ep13in-bulk", "ep14in-bulk",
-   "ep15in-bulk", "ep0out", "ep1out-bulk", "ep2out-bulk", "ep3out-bulk",
-   "ep4out-bulk", "ep5out-bulk", "ep6out-bulk", "ep7out-bulk",
-   "ep8out-bulk", "ep9out-bulk", "ep10out-bulk", "ep11out-bulk",
-   "ep12out-bulk", "ep13out-bulk", "ep14out-bulk", "ep15out-bulk"
+static const struct {
+   const char *name;
+   const struct usb_ep_caps caps;
+} ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+   { \
+   .name = _name, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+   USB_EP_CAPS_DIR_ ## _dir), \
+   }
+
+   EP_INFO(ep0_string, CONTROL, IN),
+   EP_INFO("ep1in-int",BULK,   IN),
+   EP_INFO("ep2in-bulk",   BULK,   IN),
+   EP_INFO("ep3in-bulk",   BULK,   IN),
+   EP_INFO("ep4in-bulk",   BULK,   IN),
+   EP_INFO("ep5in-bulk",   BULK,   IN),
+   EP_INFO("ep6in-bulk",   BULK,   IN),
+   EP_INFO("ep7in-bulk",   BULK,   IN),
+   EP_INFO("ep8in-bulk",   BULK,   IN),
+   EP_INFO("ep9in-bulk",   BULK,   IN),
+   EP_INFO("ep10in-bulk",  BULK,   IN),
+   EP_INFO("ep11in-bulk",  BULK,   IN),
+   EP_INFO("ep12in-bulk",  BULK,   IN),
+   EP_INFO("ep13in-bulk",  BULK,   IN),
+   EP_INFO("ep14in-bulk",  BULK,   IN),
+   EP_INFO("ep15in-bulk",  BULK,   IN),
+   EP_INFO("ep0out",   CONTROL, OUT),
+   EP_INFO("ep1out-bulk",  BULK,   OUT),
+   EP_INFO("ep2out-bulk",  BULK,   OUT),
+   EP_INFO("ep3out-bulk",  BULK,   OUT),
+   EP_INFO("ep4out-bulk",  BULK,   OUT),
+   EP_INFO("ep5out-bulk",  BULK,   OUT),
+   EP_INFO("ep6out-bulk",  BULK,   OUT),
+   EP_INFO("ep7out-bulk",  BULK,   OUT),
+   EP_INFO("ep8out-bulk",  BULK,   OUT),
+   EP_INFO("ep9out-bulk",  BULK,   OUT),
+   EP_INFO("ep10out-bulk", BULK,   OUT),
+   EP_INFO("ep11out-bulk", BULK,   OUT),
+   EP_INFO("ep12out-bulk", BULK,   OUT),
+   EP_INFO("ep13out-bulk", BULK,   OUT),
+   EP_INFO("ep14out-bulk", BULK,   OUT),
+   EP_INFO("ep15out-bulk", BULK,   OUT),
+
+#undef EP_INFO
 };
 
 /* DMA usage flag */
@@ -1517,7 +1553,8 @@ static void udc_setup_endpoints(struct udc *dev)
for (tmp = 0; tmp < UDC_EP_NUM; tmp++) {
ep = &dev->ep[tmp];
ep->dev = dev;
-   ep->ep.name = ep_string[tmp];
+   ep->ep.name = ep_info[tmp].name;
+   ep->ep.caps = ep_info[tmp].caps;
ep->num = tmp;
/* txfifo size is calculated at enable time */
ep->txfifo = dev->txfifo;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 09/46] usb: gadget: at91_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/at91_udc.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/udc/at91_udc.c 
b/drivers/usb/gadget/udc/at91_udc.c
index fc42264..a04b073 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -59,15 +59,29 @@
 #defineDRIVER_VERSION  "3 May 2006"
 
 static const char driver_name [] = "at91_udc";
-static const char * const ep_names[] = {
-   "ep0",
-   "ep1",
-   "ep2",
-   "ep3-int",
-   "ep4",
-   "ep5",
+
+static const struct {
+   const char *name;
+   const struct usb_ep_caps caps;
+} ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+   { \
+   .name = _name, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+   USB_EP_CAPS_DIR_ ## _dir), \
+   }
+
+   EP_INFO("ep0",  CONTROL, ALL),
+   EP_INFO("ep1",  ALL,ALL),
+   EP_INFO("ep2",  ALL,ALL),
+   EP_INFO("ep3-int",  INT,ALL),
+   EP_INFO("ep4",  ALL,ALL),
+   EP_INFO("ep5",  ALL,ALL),
+
+#undef EP_INFO
 };
-#define ep0nameep_names[0]
+
+#define ep0nameep_info[0].name
 
 #define VBUS_POLL_TIMEOUT  msecs_to_jiffies(1000)
 
@@ -1830,7 +1844,8 @@ static int at91udc_probe(struct platform_device *pdev)
 
for (i = 0; i < NUM_ENDPOINTS; i++) {
ep = &udc->ep[i];
-   ep->ep.name = ep_names[i];
+   ep->ep.name = ep_info[i].name;
+   ep->ep.caps = ep_info[i].caps;
ep->ep.ops = &at91_ep_ops;
ep->udc = udc;
ep->int_mask = BIT(i);
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 07/46] usb: dwc3: gadget: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/dwc3/gadget.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0..8d1f768 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1713,6 +1713,19 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
*dwc,
return ret;
}
 
+   if (epnum == 0) {
+   dep->endpoint.caps.type_control = true;
+   } else {
+   dep->endpoint.caps.type_iso = true;
+   dep->endpoint.caps.type_bulk = true;
+   dep->endpoint.caps.type_int = true;
+   }
+
+   if (epnum & 1)
+   dep->endpoint.caps.dir_in = true;
+   else
+   dep->endpoint.caps.dir_out = true;
+
INIT_LIST_HEAD(&dep->request_list);
INIT_LIST_HEAD(&dep->req_queued);
}
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 06/46] usb: dwc2: gadget: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4d47b7c..8771b66 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3289,6 +3289,19 @@ static void s3c_hsotg_initep(struct dwc2_hsotg *hsotg,
usb_ep_set_maxpacket_limit(&hs_ep->ep, epnum ? 1024 : EP0_MPS_LIMIT);
hs_ep->ep.ops = &s3c_hsotg_ep_ops;
 
+   if (epnum == 0) {
+   hs_ep->ep.caps.type_control = true;
+   } else {
+   hs_ep->ep.caps.type_iso = true;
+   hs_ep->ep.caps.type_bulk = true;
+   hs_ep->ep.caps.type_int = true;
+   }
+
+   if (dir_in)
+   hs_ep->ep.caps.dir_in = true;
+   else
+   hs_ep->ep.caps.dir_out = true;
+
/*
 * if we're using dma, we need to set the next-endpoint pointer
 * to be something valid.
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 05/46] usb: chipidea: udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/chipidea/udc.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 764f668..eff7cfb 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1624,6 +1624,20 @@ static int init_eps(struct ci_hdrc *ci)
 
hwep->ep.name  = hwep->name;
hwep->ep.ops   = &usb_ep_ops;
+
+   if (i == 0) {
+   hwep->ep.caps.type_control = true;
+   } else {
+   hwep->ep.caps.type_iso = true;
+   hwep->ep.caps.type_bulk = true;
+   hwep->ep.caps.type_int = true;
+   }
+
+   if (j == TX)
+   hwep->ep.caps.dir_in = true;
+   else
+   hwep->ep.caps.dir_out = true;
+
/*
 * for ep0: maxP defined in desc, for other
 * eps, maxP is set by epautoconfig() called
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 04/46] staging: emxx_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Fixed typo in "epc-nulk" to "epc-bulk".

Signed-off-by: Robert Baldyga 
---
 drivers/staging/emxx_udc/emxx_udc.c | 60 ++---
 1 file changed, 29 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 3b7aa36..0d64bee 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops nbu2ss_gadget_ops = {
.ioctl  = nbu2ss_gad_ioctl,
 };
 
-static const char g_ep0_name[] = "ep0";
-static const char g_ep1_name[] = "ep1-bulk";
-static const char g_ep2_name[] = "ep2-bulk";
-static const char g_ep3_name[] = "ep3in-int";
-static const char g_ep4_name[] = "ep4-iso";
-static const char g_ep5_name[] = "ep5-iso";
-static const char g_ep6_name[] = "ep6-bulk";
-static const char g_ep7_name[] = "ep7-bulk";
-static const char g_ep8_name[] = "ep8in-int";
-static const char g_ep9_name[] = "ep9-iso";
-static const char g_epa_name[] = "epa-iso";
-static const char g_epb_name[] = "epb-bulk";
-static const char g_epc_name[] = "epc-nulk";
-static const char g_epd_name[] = "epdin-int";
-
-static const char *gp_ep_name[NUM_ENDPOINTS] = {
-   g_ep0_name,
-   g_ep1_name,
-   g_ep2_name,
-   g_ep3_name,
-   g_ep4_name,
-   g_ep5_name,
-   g_ep6_name,
-   g_ep7_name,
-   g_ep8_name,
-   g_ep9_name,
-   g_epa_name,
-   g_epb_name,
-   g_epc_name,
-   g_epd_name,
+static const struct {
+   const char *name;
+   const struct usb_ep_caps caps;
+} ep_info[NUM_ENDPOINTS] = {
+#define EP_INFO(_name, _type, _dir) \
+   { \
+   .name = _name, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+   USB_EP_CAPS_DIR_ ## _dir), \
+   }
+
+   EP_INFO("ep0",  CONTROL, ALL),
+   EP_INFO("ep1-bulk", BULK,   ALL),
+   EP_INFO("ep2-bulk", BULK,   ALL),
+   EP_INFO("ep3in-int",INT,IN),
+   EP_INFO("ep4-iso",  INT,ALL),
+   EP_INFO("ep5-iso",  ISO,ALL),
+   EP_INFO("ep6-bulk", ISO,ALL),
+   EP_INFO("ep7-bulk", BULK,   ALL),
+   EP_INFO("ep8in-int",INT,IN),
+   EP_INFO("ep9-iso",  ISO,ALL),
+   EP_INFO("epa-iso",  ISO,ALL),
+   EP_INFO("epb-bulk", BULK,   ALL),
+   EP_INFO("epc-bulk", BULK,   ALL),
+   EP_INFO("epdin-int",INT,IN),
+
+#undef EP_INFO
 };
 
 /*-*/
@@ -3200,7 +3197,8 @@ static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc 
*udc)
ep->desc = NULL;
 
ep->ep.driver_data = NULL;
-   ep->ep.name = gp_ep_name[i];
+   ep->ep.name = ep_info[i].name;
+   ep->ep.caps = ep_info[i].caps;
ep->ep.ops = &nbu2ss_ep_ops;
 
usb_ep_set_maxpacket_limit(&ep->ep,
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 03/46] usb: gadget: add endpoint capabilities helper macros

2015-07-14 Thread Robert Baldyga
Add macros useful while initializing array of endpoint capabilities
structures. These macros makes structure initialization more compact
to decrease number of code lines and increase readability of code.

Signed-off-by: Robert Baldyga 
---
 include/linux/usb/gadget.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 6f3e0fb..e6cbc25 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -158,6 +158,26 @@ struct usb_ep_caps {
unsigned dir_out:1;
 };
 
+#define USB_EP_CAPS_TYPE_CONTROL 0x01
+#define USB_EP_CAPS_TYPE_ISO 0x02
+#define USB_EP_CAPS_TYPE_BULK0x04
+#define USB_EP_CAPS_TYPE_INT 0x08
+#define USB_EP_CAPS_TYPE_ALL \
+   (USB_EP_CAPS_TYPE_ISO | USB_EP_CAPS_TYPE_BULK | USB_EP_CAPS_TYPE_INT)
+#define USB_EP_CAPS_DIR_IN   0x01
+#define USB_EP_CAPS_DIR_OUT  0x02
+#define USB_EP_CAPS_DIR_ALL  (USB_EP_CAPS_DIR_IN | USB_EP_CAPS_DIR_OUT)
+
+#define USB_EP_CAPS(_type, _dir) \
+   { \
+   .type_control = !!(_type & USB_EP_CAPS_TYPE_CONTROL), \
+   .type_iso = !!(_type & USB_EP_CAPS_TYPE_ISO), \
+   .type_bulk = !!(_type & USB_EP_CAPS_TYPE_BULK), \
+   .type_int = !!(_type & USB_EP_CAPS_TYPE_INT), \
+   .dir_in = !!(_dir & USB_EP_CAPS_DIR_IN), \
+   .dir_out = !!(_dir & USB_EP_CAPS_DIR_OUT), \
+   }
+
 /**
  * struct usb_ep - device side representation of USB endpoint
  * @name:identifier for the endpoint, such as "ep-a" or "ep9in-bulk"
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 02/46] usb: gadget: add endpoint capabilities flags

2015-07-14 Thread Robert Baldyga
Introduce struct usb_ep_caps which contains information about capabilities
of usb endpoints - supported transfer types and directions. This structure
should be filled by UDC driver for each of its endpoints, and will be
used in epautoconf in new ep matching mechanism which will replace ugly
guessing of endpoint capabilities basing on its name.

Signed-off-by: Robert Baldyga 
---
 include/linux/usb/gadget.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index fcb0a4e..6f3e0fb 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -141,10 +141,29 @@ struct usb_ep_ops {
 };
 
 /**
+ * struct usb_ep_caps - endpoint capabilities description
+ * @type_control:Endpoint supports control type (reserved for ep0).
+ * @type_iso:Endpoint supports isochronous transfers.
+ * @type_bulk:Endpoint supports bulk transfers.
+ * @type_int:Endpoint supports interrupt transfers.
+ * @dir_in:Endpoint supports IN direction.
+ * @dir_out:Endpoint supports OUT direction.
+ */
+struct usb_ep_caps {
+   unsigned type_control:1;
+   unsigned type_iso:1;
+   unsigned type_bulk:1;
+   unsigned type_int:1;
+   unsigned dir_in:1;
+   unsigned dir_out:1;
+};
+
+/**
  * struct usb_ep - device side representation of USB endpoint
  * @name:identifier for the endpoint, such as "ep-a" or "ep9in-bulk"
  * @ops: Function pointers used to access hardware-specific operations.
  * @ep_list:the gadget's ep_list holds all of its endpoints
+ * @caps:The structure describing types and directions supported by endoint.
  * @maxpacket:The maximum packet size used on this endpoint.  The initial
  * value can sometimes be reduced (hardware allowing), according to
  *  the endpoint descriptor used to configure the endpoint.
@@ -167,12 +186,14 @@ struct usb_ep_ops {
  * gadget->ep_list.  the control endpoint (gadget->ep0) is not in that list,
  * and is accessed only in response to a driver setup() callback.
  */
+
 struct usb_ep {
void*driver_data;
 
const char  *name;
const struct usb_ep_ops *ops;
struct list_headep_list;
+   struct usb_ep_caps  caps;
boolclaimed;
unsignedmaxpacket:16;
unsignedmaxpacket_limit:16;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 01/46] usb: gadget: encapsulate endpoint claiming mechanism

2015-07-14 Thread Robert Baldyga
So far it was necessary for usb functions to set ep->driver_data in
endpoint obtained from autoconfig to non-null value, to indicate that
endpoint is claimed by function (in autoconfig it was checked if endpoint
has set this field to non-null value, and if it has, it was assumed that
it is claimed). It could cause bugs becouse if some function doesn't
set this field autoconfig could return the same endpoint more than one
time.

To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
and  encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
and usb_ep_autoconfig_reset(), so now usb functions don't need to perform
any additional actions to mark endpoint obtained from autoconfig as claimed.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 11 ++-
 include/linux/usb/gadget.h  |  1 +
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 919cdfd..8e00ca7 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -53,7 +53,7 @@ ep_matches (
int num_req_streams = 0;
 
/* endpoint already claimed? */
-   if (NULL != ep->driver_data)
+   if (ep->claimed)
return 0;
 
/* only support ep0 for portable CONTROL traffic */
@@ -240,7 +240,7 @@ find_ep (struct usb_gadget *gadget, const char *name)
  * updated with the assigned number of streams if it is
  * different from the original value. To prevent the endpoint
  * from being returned by a later autoconfig call, claim it by
- * assigning ep->driver_data to some non-null value.
+ * assigning ep->claimed to true.
  *
  * On failure, this returns a null endpoint descriptor.
  */
@@ -323,6 +323,7 @@ struct usb_ep *usb_ep_autoconfig_ss(
 found_ep:
ep->desc = NULL;
ep->comp_desc = NULL;
+   ep->claimed = true;
return ep;
 }
 EXPORT_SYMBOL_GPL(usb_ep_autoconfig_ss);
@@ -354,7 +355,7 @@ EXPORT_SYMBOL_GPL(usb_ep_autoconfig_ss);
  * descriptor bEndpointAddress.  For bulk endpoints, the wMaxPacket value
  * is initialized as if the endpoint were used at full speed.  To prevent
  * the endpoint from being returned by a later autoconfig call, claim it
- * by assigning ep->driver_data to some non-null value.
+ * by assigning ep->claimed to true.
  *
  * On failure, this returns a null endpoint descriptor.
  */
@@ -373,7 +374,7 @@ EXPORT_SYMBOL_GPL(usb_ep_autoconfig);
  *
  * Use this for devices where one configuration may need to assign
  * endpoint resources very differently from the next one.  It clears
- * state such as ep->driver_data and the record of assigned endpoints
+ * state such as ep->claimed and the record of assigned endpoints
  * used by usb_ep_autoconfig().
  */
 void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
@@ -381,7 +382,7 @@ void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
struct usb_ep   *ep;
 
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
-   ep->driver_data = NULL;
+   ep->claimed = false;
}
gadget->in_epnum = 0;
gadget->out_epnum = 0;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 4f3dfb7..fcb0a4e 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -173,6 +173,7 @@ struct usb_ep {
const char  *name;
const struct usb_ep_ops *ops;
struct list_headep_list;
+   boolclaimed;
unsignedmaxpacket:16;
unsignedmaxpacket_limit:16;
unsignedmax_streams:16;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 00/46] usb: gadget: rework ep matching and claiming mechanism

2015-07-14 Thread Robert Baldyga
Hello,

This patch series reworks endpoint matching and claiming mechanism in
epautoconf. From v2 there are couple of new patches adding 'ep_match'
to usb_gadget_ops and removing chip-specific quirk handling from generic
code of autoconfig.

I'm not sure if this patch set isn't too long, as it has 46 patches,
but I decided to send it as single series to avoid problems with patch
applying order.

The aim of whole patchset is to rework epautoconf code to get rid of
things like name-based endpoint matching and UDC name-based quirks in
generic code. These needed to do some modifications in framework like
adding 'endpoint capabilities flags' feature or adding 'match_ep'.

Following paragraphs contain brief description of what modifications are
done by particular parts of this patch set:

Patch (1) introduces new safer endpoint claiming method, basing on new
'claimed' flag. It was discussed here [1]. I proposed this solution over
year ago and it was accepted, but I apparently forgot to send the final
version of my patch.

Patches (2-3) add the 'capabilities flags' structure and helper macros.
This solution is inspired by the 'feature flags' originally proposed
by Felipe Balbi in 2013 [2], but unfortunately implementation of this
feature has never been completed.

Patches (4-36) add' capabilites flags' support to all UDC drivers present
in the kernel tree. It's needed to be done before replacing old endpoint
matching mechanism, otherwise UDC drivers which doesn't set 'capabilities
flags' won't work with new matching function.

Patch (37) finally replaces old endpoint matching method with the new
one basing on capabilities flags.

These changes aims to get rid of code, which guesses endpoint capabilities
basing on it's name, and introduce new better replacement. In result
we have better way to describe types and directions supported by each
endpoint.

For example the old name-based method didn't allow to have endpoint
supporing two types of transfers - there were only ability to support
one or all of endpoint types. The 'capabilities flags' feature supply
precise, flexible and extensible mechanism of description of endpoint
hardware limitations, which is desired for proper endpoint matching.

Patch (38) removes chip-specific quirk from ep_matches() function.

Patches (39-40) remove code modifying endpoint and descriptor structures
from ep_matches() function and cleans it up to make it simpler and more
readable.

Patch (41) add 'match_ep' callback to usb_gadget_ops and make use of
it in epautoconf. This callback allows UDC drivers to supply non-standard
endpoint matching algorithms.

Patches (42-43) move ep_matches() and find_ep() functions outside
epautoconf and rename them to usb_gadget_ep_match_desc() and
gadget_find_ep_by_name(). It's because they may be useful in 'match_ep'
callbacks in UDC drivers to avoid writing repetitive code.

Patches (44-46) move chip-specific enpoint matching algorithms from
generic code of usb_ep_autoconfig_ss() function to UDC controller drivers
using 'match_ep' callback.

In the result we have epautoconf source free of chip-specific code, plus
two new mechanisms allowing to handle non-standard hardware limitations.

[1] https://lkml.org/lkml/2014/6/16/94
[2] http://www.spinics.net/lists/linux-usb/msg99662.html

Best regards,
Robert Baldyga

Changelog:

v3:
- addressed comments from Sergei Shtylyov

v2: https://lkml.org/lkml/2015/7/14/172
- remove PXA quirk from ep_matches() function without behaviour change
  using ep capabilities flags
- separate ep and desc configuration code from ep_match() function
- add 'ep_match' to usb_gadget_ops and move chip-specific endpoint
  matching algorithms from generic code to UDC controller drivers

v1: https://lkml.org/lkml/2015/7/8/436

Robert Baldyga (46):
  usb: gadget: encapsulate endpoint claiming mechanism
  usb: gadget: add endpoint capabilities flags
  usb: gadget: add endpoint capabilities helper macros
  staging: emxx_udc: add ep capabilities support
  usb: chipidea: udc: add ep capabilities support
  usb: dwc2: gadget: add ep capabilities support
  usb: dwc3: gadget: add ep capabilities support
  usb: gadget: amd5536udc: add ep capabilities support
  usb: gadget: at91_udc: add ep capabilities support
  usb: gadget: bcm63xx_udc: add ep capabilities support
  usb: gadget: bdc: add ep capabilities support
  usb: gadget: dummy-hcd: add ep capabilities support
  usb: gadget: fotg210-udc: add ep capabilities support
  usb: gadget: fsl_qe_udc: add ep capabilities support
  usb: gadget: fsl_udc_core: add ep capabilities support
  usb: gadget: fusb300_udc: add ep capabilities support
  usb: gadget: goku_udc: add ep capabilities support
  usb: gadget: gr_udc: add ep capabilities support
  usb: gadget: lpc32xx_udc: add ep capabilities support
  usb: gadget: m66592-udc: add ep capabilities support
  usb: gadget: mv_u3d_core: add ep capabilities support
  usb: gadget: mv_udc_core: add ep capabilities support
  usb: gadget: net2272: add ep capabiliti

Re: [PATCH v4 3/6] cpufreq: powernv: Register for OCC related opal_message notification

2015-07-14 Thread Joel Stanley
Hello,

On Mon, 2015-07-13 at 19:39 +0530, Shilpasri G Bhat wrote:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index d0c18c9..1f59958 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -414,6 +415,71 @@ static struct notifier_block powernv_cpufreq_reboot_nb = 
> {
>   .notifier_call = powernv_cpufreq_reboot_notifier,
>  };
>  
> +static char throttle_reason[][30] = {
> + "No throttling",
> + "Power Cap",
> + "Processor Over Temperature",
> + "Power Supply Failure",
> + "Over Current",
> + "OCC Reset"
> +  };
> +
> +static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> +unsigned long msg_type, void *_msg)
> +{
> + struct opal_msg *msg = _msg;
> + struct opal_occ_msg omsg;
> +
> + if (msg_type != OPAL_MSG_OCC)
> + return 0;
> +
> + memcpy(&omsg, msg->params, sizeof(omsg));

You need to ensure the of the members of struct opal_occ_msg are in the
correct byte order when copying them over.

Have you tested this code with in a little endian configuration?

Do the messages you're sending make sense for a system that has a BMC
instead of a FSP?

Cheers,

Joel

> +
> + switch (omsg.type) {

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

2015-07-14 Thread Baolin Wang
The cputime_to_timespec() and timespec_to_cputime() functions are
not year 2038 safe on 32bit systems due to that the struct timepsec
will overflow in 2038 year. This patch introduces cputime_to_timespec64()
and timespec64_to_cputime() functions which use struct timespec64.
And converts arch specific implementations in arch/s390 and arch/powerpc.

Signed-off-by: Baolin Wang 
---
 arch/powerpc/include/asm/cputime.h|6 +++---
 arch/s390/include/asm/cputime.h   |8 
 include/asm-generic/cputime_jiffies.h |   10 +-
 include/asm-generic/cputime_nsecs.h   |6 +++---
 include/linux/cputime.h   |   16 
 5 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h
index e245255..5dda5c0 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -154,9 +154,9 @@ static inline cputime_t secs_to_cputime(const unsigned long 
sec)
 }
 
 /*
- * Convert cputime <-> timespec
+ * Convert cputime <-> timespec64
  */
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec *p)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64 
*p)
 {
u64 x = (__force u64) ct;
unsigned int frac;
@@ -168,7 +168,7 @@ static inline void cputime_to_timespec(const cputime_t ct, 
struct timespec *p)
p->tv_nsec = x;
 }
 
-static inline cputime_t timespec_to_cputime(const struct timespec *p)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *p)
 {
u64 ct;
 
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index 221b454..3319b51 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -81,16 +81,16 @@ static inline cputime_t secs_to_cputime(const unsigned int 
s)
 }
 
 /*
- * Convert cputime to timespec and back.
+ * Convert cputime to timespec64 and back.
  */
-static inline cputime_t timespec_to_cputime(const struct timespec *value)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *value)
 {
unsigned long long ret = value->tv_sec * CPUTIME_PER_SEC;
return (__force cputime_t)(ret + __div(value->tv_nsec * 
CPUTIME_PER_USEC, NSEC_PER_USEC));
 }
 
-static inline void cputime_to_timespec(const cputime_t cputime,
-  struct timespec *value)
+static inline void cputime_to_timespec64(const cputime_t cputime,
+struct timespec64 *value)
 {
unsigned long long __cputime = (__force unsigned long long) cputime;
value->tv_nsec = (__cputime % CPUTIME_PER_SEC) * NSEC_PER_USEC / 
CPUTIME_PER_USEC;
diff --git a/include/asm-generic/cputime_jiffies.h 
b/include/asm-generic/cputime_jiffies.h
index fe386fc..54e034c 100644
--- a/include/asm-generic/cputime_jiffies.h
+++ b/include/asm-generic/cputime_jiffies.h
@@ -44,12 +44,12 @@ typedef u64 __nocast cputime64_t;
 #define secs_to_cputime(sec)   jiffies_to_cputime((sec) * HZ)
 
 /*
- * Convert cputime to timespec and back.
+ * Convert cputime to timespec64 and back.
  */
-#define timespec_to_cputime(__val) \
-   jiffies_to_cputime(timespec_to_jiffies(__val))
-#define cputime_to_timespec(__ct,__val)\
-   jiffies_to_timespec(cputime_to_jiffies(__ct),__val)
+#define timespec64_to_cputime(__val)   \
+   jiffies_to_cputime(timespec64_to_jiffies(__val))
+#define cputime_to_timespec64(__ct,__val)  \
+   jiffies_to_timespec64(cputime_to_jiffies(__ct),__val)
 
 /*
  * Convert cputime to timeval and back.
diff --git a/include/asm-generic/cputime_nsecs.h 
b/include/asm-generic/cputime_nsecs.h
index 0419485..c0cafc0 100644
--- a/include/asm-generic/cputime_nsecs.h
+++ b/include/asm-generic/cputime_nsecs.h
@@ -71,14 +71,14 @@ typedef u64 __nocast cputime64_t;
(__force cputime_t)((__secs) * NSEC_PER_SEC)
 
 /*
- * Convert cputime <-> timespec (nsec)
+ * Convert cputime <-> timespec64 (nsec)
  */
-static inline cputime_t timespec_to_cputime(const struct timespec *val)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *val)
 {
u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_nsec;
return (__force cputime_t) ret;
 }
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec 
*val)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64 
*val)
 {
u32 rem;
 
diff --git a/include/linux/cputime.h b/include/linux/cputime.h
index f2eb2ee..cd638a0 100644
--- a/include/linux/cputime.h
+++ b/include/linux/cputime.h
@@ -13,4 +13,20 @@
usecs_to_cputime((__nsecs) / NSEC_PER_USEC)
 #endif
 
+static inline cputime_t timespec_to_cputime(const struct timespec *ts)
+{
+   struct timespec64 ts64 = timespec_to_timespec64(*ts);
+
+   return timespec64_to_cputime(&ts64);
+}
+
+static inline void cputime_to_timespec(const cputime_t cputime,
+ 

[PATCH 0/6] Introduce 64bit accessors and structures required to address y2038 issues in the posix_clock subsystem

2015-07-14 Thread Baolin Wang
This patch series change the 32-bit time types (timespec/itimerspec) to
the 64-bit types (timespec64/itimerspec64), and add new 64bit accessor
functions, which are required in order to avoid y2038 issues in the
posix_clock subsystem.

In order to avoid spamming people too much, I'm only sending the first
few patches of the patch series, and left the other patches for later.

And if you are interested in the whole patch series, see:
https://git.linaro.org/people/baolin.wang/upstream_0627.git

Thoughts and feedback would be appreciated.

Baolin Wang (6):
  time: Introduce struct itimerspec64
  timekeeping: Introduce current_kernel_time64()
  security: Introduce security_settime64()
  time: Introduce do_sys_settimeofday64()
  time: Introduce timespec64_to_jiffies()/jiffies_to_timespec64()
  cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

 arch/powerpc/include/asm/cputime.h|6 +++---
 arch/s390/include/asm/cputime.h   |8 
 include/asm-generic/cputime_jiffies.h |   10 +-
 include/asm-generic/cputime_nsecs.h   |6 +++---
 include/linux/cputime.h   |   16 +++
 include/linux/jiffies.h   |   22 ++---
 include/linux/lsm_hooks.h |5 +++--
 include/linux/security.h  |   20 ---
 include/linux/time64.h|   35 +
 include/linux/timekeeping.h   |   24 +++---
 kernel/time/time.c|   28 +++---
 kernel/time/timekeeping.c |6 +++---
 security/commoncap.c  |2 +-
 security/security.c   |2 +-
 14 files changed, 148 insertions(+), 42 deletions(-)

-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()

2015-07-14 Thread Finn Thain

On Tue, 14 Jul 2015, Benjamin Herrenschmidt wrote:

> On Tue, 2015-07-14 at 17:58 +1000, Finn Thain wrote:
> > Make use of arch_nvram_ops in device drivers so that the nvram_* 
> > function exports can be removed.
> > 
> > Since they are no longer global symbols, rename the PPC32 nvram_* 
> > functions appropriately.
> > 
> > Add the missing CONFIG_NVRAM test to imsttfb to avoid a build failure.
> > 
> > Add a CONFIG_PPC32 test to matroxfb because PPC64 doesn't implement 
> > the read_byte() method.
> 
> This is a bit fishy in a way because some of that nvram stuff is really 
> about powermac/apple nvram offsets, ie, "XPRAM".

Yes, the generalization that PPC64 does not have XPRAM is wrong, but that 
wasn't originally my doing. If we were to address that issue, this patch 
series may not be the best place to do so.

The situation presently is that CONFIG_NVRAM cannot be enabled on PPC64. I 
took advantage of that simplification, despite the corner cases where it 
fails.

The corner cases are found among PPC64 systems with Matrox cards. The 
other PowerMac video drivers are not really relevant here due to "depends 
on PPC32" or "#if defined(CONFIG_PPC32)", meaning that nvram_read_byte() 
isn't a problem there.

Perhaps only dual-boot systems are at issue because AFAIK only Mac OS 
offers a user friendly way to edit XPRAM settings (?) Further, does the 
video mode setting in XPRAM relate only to the MacOS main screen and not 
to other devices? That is, are we concerned here only with dual-boot PPC64 
machines with one matrox card, as the main screen, and no Linux desktop 
environment and no video mode settings on the kernel command line?

> Maybe we should have a dedicated accessor for "mac_xpram" and NULL-check 
> it rather than using ifdef's ?

I wanted arch_nvram_ops to be const data, which means a NULL check won't 
work, because defined(CONFIG_PPC_PMAC) does not imply availability of 
XPRAM at run-time.

There is a similar situation in the m68k portion of this patch series: a 
multi-platform kernel binary might run on an Atari or a Mac. On m68k I 
resolved this with MACH_IS_MAC(), which is analogous to 
machine_is(powermac).

So I can see how to implement XPRAM for matroxfb and imsttfb on PPC64. But 
this is an enhancement that I would defer unless the present limitation is 
already problematic.

-- 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Masami Hiramatsu
On 2015/07/15 3:23, Vivek Goyal wrote:
> On Tue, Jul 14, 2015 at 01:01:12PM -0500, Eric W. Biederman wrote:
>> Vivek Goyal  writes:
>>
>>> On Tue, Jul 14, 2015 at 05:29:53PM +, dwal...@fifo99.com wrote:
>>>
>>> [..]
 If a machine is failing, there are high chance it can't deliver you the
 notification. Detecting that failure suing some kind of polling 
 mechanism
 might be more reliable. And it will make even kdump mechanism more
 reliable so that it does not have to run panic notifiers after the 
 crash.
>>>
>>> I think what your suggesting is that my company should change how it's 
>>> hardware works
>>> and that's not really an option for me. This isn't a simple thing like 
>>> checking over the
>>> network if the machine is down or not, this is way more complex 
>>> hardware design.
>>
>> That means you are ready to live with an unreliable design. There might 
>> be
>> cases where notifier does not get run properly and you will not do switch
>> despite the fact that OS has failed. I was just trying to nudge you in
>> a direction which could be more reliable mechanism.
>
> Sigh I see some deep confusion going on here.
>
> The panic notifiers are just that panic notifiers.  They have not been
> nor should they be tied to kexec.   If those notifiers force a switch
> over of between machines I fail to see why you would care if it was
> kexec or another panic situation that is forcing that switchover.

 Hidehiro isn't fixing the failover situation on my side, he's fixing 
 register
 information collection when crash_kexec_post_notifiers is used.
>>>
>>> Sure. Given that we have created this new parameter, let us fix it so that
>>> we can capture the other cpu register state in crash dump.
>>>
>>> I am little disappointed that it was not tested well when this parameter was
>>> introuced. We should have atleast tested it to the extent to see if there
>>> is proper cpu state present for all cpus in the crash dump.
>>>
>>> At that point of time it looked like a simple modification
>>> to allow panic notifiers before crash_kexec().
>>
>> Either that or we say no one cares enough, and it known broken so let's
>> just revert the fool thing.
> 
> Masami, you introduced this option. Are you fine with the revert? Is it
> really being used and tested?

Actually, it is tested but under very limited situation. I think we
need a clear acceptance criteria, IOW, we need a testset for kdump
so that we can make things better.
Would you have it? maybe we can push it into kselftest.

>> I honestly can't see how to support panic notifiers, before kexec.
>> There is no way to tell what is being done and all of the pieces
>> including smp_send_stop are known to be buggy.
> 
> we should be able to replace smp_send_stop() with what crash_kexec() is
> doing to stop the machine? If yes, then it should be fine I guess. This
> parameter description clearly says that specify it at your own risk. So
> we are not issuing a big support statement for successful kdump after
> panic notifiers. If it is something fixable, otherwise user needs
> to deal with it.

Agreed (as I've sent in other replay).

Thank you,

-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RESEND PATCH v3] powerpc/pseries: Limit EPOW reset event warnings

2015-07-14 Thread Kamalesh Babulal
Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts.Prompting
user to take action depending upon the severity of the event.

At times EPOW reset event warning, such as below could flood
kernel log, over a period of time.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

This patch avoids these multiple EPOW reset warnings by using a boolean
flag. This flag is initialized to false and is set to true upon arrival
of EPOW event. This same flag is checked and reset during EPOW_RESET
scenario to filter out valid EPOW reset events and avoid multiple warning
logs.

Also, merged adjacent pr_err/pr_emerg into single one to reduce
the number of lines printed per warning.

Suggested-by: Vipin K Parashar 
[Vipin: edited the changelog]
Cc: Anshuman Khandual 
Cc: Anton Blanchard 
Cc: Michael Ellerman 
Signed-off-by: Kamalesh Babulal 
---
v3 Changes:
   - Limit warning printed by EPOW RESET event, by guarding it with bool flag.
 Instead of rate limiting all the EPOW events.

v2 Changes:
   - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
 warnings, based on Michael's comments.

 arch/powerpc/platforms/pseries/ras.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..b30396a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,9 @@ static int ras_check_exception_token;
 #define EPOW_SENSOR_TOKEN  9
 #define EPOW_SENSOR_INDEX  0
 
+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
+
 static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
 static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
 
@@ -145,21 +148,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err("Non critical power or cooling issue cleared");
+   if (epow_state) {
+   pr_err("Non critical power or cooling issue cleared");
+   epow_state = false;
+   }
break;
 
case EPOW_WARN_COOLING:
-   pr_err("Non critical cooling issue reported by firmware");
-   pr_err("Check RTAS error log for details");
+   pr_err("Non critical cooling issue reported by firmware, "
+  "Check RTAS error log for details");
+   epow_state = true;
break;
 
case EPOW_WARN_POWER:
-   pr_err("Non critical power issue reported by firmware");
-   pr_err("Check RTAS error log for details");
+   pr_err("Non critical power issue reported by firmware, "
+  "Check RTAS error log for details");
+   epow_state = true;
break;
 
case EPOW_SYSTEM_SHUTDOWN:
handle_system_shutdown(epow_log->event_modifier);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_HALT:
@@ -169,9 +178,8 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
-   pr_emerg("Critical power/cooling issue reported by firmware");
-   pr_emerg("Check RTAS error log for details");
-   pr_emerg("Immediate power off");
+   pr_emerg("Critical power/cooling issue reported by firmware, "
+"Check RTAS error log for details. Immediate power 
off.");
emergency_sync();
kernel_power_off();
break;
@@ -179,6 +187,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
default:
pr_err("Unknown power/cooling event (action code %d)",
action_code);
+   epow_state = true;
}
 }
 
-- 
2.1.2

___
Linuxppc-dev mailing list
Linuxppc-

Re: [PATCH] rtc/rtc-opal: Enable alarms only when opal supports tpo

2015-07-14 Thread Stewart Smith
Vaibhav Jain  writes:
> rtc-opal driver provides support for rtc alarms via
> timed-power-on(tpo). However some Power platforms like BML use a fake
> rtc clock and don't support tpo. Such platforms are indicated by the
> missing 'has-tpo' property in the device tree.
>
> Current implementation however enables callback for
> rtc_class_ops.read/set alarm irrespective of the tpo support from the
> platform. This results in a failed opal call when kernel tries to read
> an existing alarms via opal_get_tpo_time during rtc device registration.
>
> This patch fixes this issue by setting opal_rtc_ops.read/set_alarm
> callback pointers only when tpo is supported.
>
> Acked-by: Michael Neuling 
> Acked-by: Neelesh Gupta 
> Signed-off-by: Vaibhav Jain 

Acked-by: Stewart Smith 

FWIW I'm updating OPAL docs with this. The TPO calls aren't actually
documented :(

In future, it'd be great if there was an accompanying skiboot patch
updating the documentation there too.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option

2015-07-14 Thread Masami Hiramatsu
On 2015/07/14 23:42, Vivek Goyal wrote:
> On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
>> This patch fixes problems reported by Daniel Walker
>> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
>> commits 5375b70 and f45d85f.
>>
>> If "crash_kexec_post_notifiers" boot option is specified,
>> other cpus are stopped by smp_send_stop() before entering
>> crash_kexec(), while usually machine_crash_shutdown() called by
>> crash_kexec() does that.  This behavior change leads two problems.
>>
>>  Problem 1:
>>  Some function in the crash_kexec() path depend on other cpus being
>>  still online.  If other cpus have been offlined already, they
>>  doesn't work properly.
>>
>>   Example:
>>panic()
>> crash_kexec()
>>  machine_crash_shutdown()
>>   octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>>  machine_kexec()
>>
>>  Problem 2:
>>  Most of architectures stop other cpus in the machine_crash_shutdown()
>>  path and save register information at the same time.  However, if
>>  smp_send_stop() is called before that, we can't save the register
>>  information.
>>
>> To solve these problems, this patch changes the timing of calling
>> the callbacks instead of changing the timing of crash_kexec() if
>> crash_kexec_post_notifiers boot option is specified.
>>
>>  Before:
>>   if (!crash_kexec_post_notifiers)
>>   crash_kexec()
>>
>>   smp_send_stop()
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>
>>   if (crash_kexec_post_notifiers)
>>   crash_kexec()
>>
>>  After:
>>   crash_kexec()
>>   machine_crash_shutdown()
>>   if (crash_kexec_post_notifiers) {
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>   }
>>   machine_kexec()
>>
>>   smp_send_stop()
>>   if (!crash_kexec_post_notifiers) {
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>   }
>>
> 
> I think this new code flow looks bad. Now we are calling kmsg_dump()
> and atomic_notifier_call_chain() from inside the crash_kexec() as well
> as from inside panic(). This is bad.
> 
> So basic problem seems to be that cpus need to be stopped once (with
> or without panic notifiers. So why don't we look into desiginig a 
> function which stops cpus, saves register states first and then does
> rest of the processing.
> 
> Something like.
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
>   crash_kexec()
> 
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> Here crash_kexec() will have to be modified and it will assume that cpus
> have already been stopped and register states have already been saved.

Ah, nice! I like this idea :)

> 
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?

I think there is no reason why we don't do so. smp_send_stop() just
stops other cpus, but crash's one does more (collect registers and
stop watchdogs if needed, etc.). why don't we just replace(improve) it?

Thank you!


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 6/8] perf: Rename perf_event_read_{one, group}, perf_read_hw

2015-07-14 Thread Sukadev Bhattiprolu
From: "Peter Zijlstra (Intel)" 

In order to free up the perf_event_read_group() name:

 s/perf_event_read_\(one\|group\)/perf_read_\1/g
 s/perf_read_hw/__perf_read/g

Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/events/core.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index b1e9a42..a83d45c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3675,7 +3675,7 @@ static void put_event(struct perf_event *event)
 * see the comment there.
 *
 *  2) there is a lock-inversion with mmap_sem through
-* perf_event_read_group(), which takes faults while
+* perf_read_group(), which takes faults while
 * holding ctx->mutex, however this is called after
 * the last filedesc died, so there is no possibility
 * to trigger the AB-BA case.
@@ -3781,7 +3781,7 @@ u64 perf_event_read_value(struct perf_event *event, u64 
*enabled, u64 *running)
 }
 EXPORT_SYMBOL_GPL(perf_event_read_value);
 
-static int perf_event_read_group(struct perf_event *event,
+static int perf_read_group(struct perf_event *event,
   u64 read_format, char __user *buf)
 {
struct perf_event *leader = event->group_leader, *sub;
@@ -3829,7 +3829,7 @@ static int perf_event_read_group(struct perf_event *event,
return ret;
 }
 
-static int perf_event_read_one(struct perf_event *event,
+static int perf_read_one(struct perf_event *event,
 u64 read_format, char __user *buf)
 {
u64 enabled, running;
@@ -3867,7 +3867,7 @@ static bool is_event_hup(struct perf_event *event)
  * Read the performance event - simple non blocking version for now
  */
 static ssize_t
-perf_read_hw(struct perf_event *event, char __user *buf, size_t count)
+__perf_read(struct perf_event *event, char __user *buf, size_t count)
 {
u64 read_format = event->attr.read_format;
int ret;
@@ -3885,9 +3885,9 @@ perf_read_hw(struct perf_event *event, char __user *buf, 
size_t count)
 
WARN_ON_ONCE(event->ctx->parent_ctx);
if (read_format & PERF_FORMAT_GROUP)
-   ret = perf_event_read_group(event, read_format, buf);
+   ret = perf_read_group(event, read_format, buf);
else
-   ret = perf_event_read_one(event, read_format, buf);
+   ret = perf_read_one(event, read_format, buf);
 
return ret;
 }
@@ -3900,7 +3900,7 @@ perf_read(struct file *file, char __user *buf, size_t 
count, loff_t *ppos)
int ret;
 
ctx = perf_event_ctx_lock(event);
-   ret = perf_read_hw(event, buf, count);
+   ret = __perf_read(event, buf, count);
perf_event_ctx_unlock(event, ctx);
 
return ret;
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 8/8] powerpc/perf/hv-24x7: Use PMU_TXN_READ interface

2015-07-14 Thread Sukadev Bhattiprolu
The 24x7 counters in Powerpc allow monitoring a large number of counters
simultaneously. They also allow reading several counters in a single
HCALL so we can get a more consistent snapshot of the system.

Use the PMU's transaction interface to monitor and read several event
counters at once. The idea is that users can group several 24x7 events
into a single group of events. We use the following logic to submit
the group of events to the PMU and read the values:

pmu->start_txn()// Initialize before first event

for each event in group
pmu->read(event);   // Queue each event to be read

pmu->commit_txn()   // Read/update all queuedcounters

The ->commit_txn() also updates the event counts in the respective
perf_event objects.  The perf subsystem can then directly get the
event counts from the perf_event and can avoid submitting a new
->read() request to the PMU.

Thanks to input from Peter Zijlstra.

Signed-off-by: Sukadev Bhattiprolu 

Changelog[v3]
[Peter Zijlstra] Save the transaction state in ->start_txn() and
drop the flags parameter from ->commit_txn() and ->cancel_txn().
[Peter Zijlstra] The nop txn interfaces don't need to disable/enable
PMU for PERF_PMU_TXN_READ transactions.
---
 arch/powerpc/perf/hv-24x7.c |  160 ++-
 1 file changed, 157 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 4d1a8d1..c28ef3f 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -142,8 +142,24 @@ static struct attribute_group event_long_desc_group = {
 
 static struct kmem_cache *hv_page_cache;
 
+struct h_24x7_hw {
+   int txn_err;
+   int txn_flags;
+   struct perf_event *events[255];
+} h24x7hw;
+
 /*
- * request_buffer and result_buffer are not required to be 4k aligned,
+ * The request and result buffers are also used in interrupt context
+ * (eg: we read/update the event counts in h_24x7_event_stop()). Rather
+ * than allocating buffers in interrupt context (i.e before each HCALL),
+ * pre-allocate per-CPU request and result buffers.
+ *
+ * However, for the transaction interface, the ->start_txn(), where the
+ * buffers are initialized and the ->read() operations (where the buffers
+ * are used) are not guaranteed to be on the same CPU. Hence, we cannot
+ * use the per-CPU buffers. Use PMU-wide request and result buffers instead.
+ *
+ * Note that request and result buffers are not required to be 4k aligned,
  * but are not allowed to cross any 4k boundary. Aligning them to 4k is
  * the simplest way to ensure that.
  */
@@ -151,6 +167,9 @@ static struct kmem_cache *hv_page_cache;
 DEFINE_PER_CPU(char, hv_24x7_reqb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
 DEFINE_PER_CPU(char, hv_24x7_resb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
 
+char hv_24x7_txn_reqb[H24x7_DATA_BUFFER_SIZE] __aligned(4096);
+char hv_24x7_txn_resb[H24x7_DATA_BUFFER_SIZE] __aligned(4096);
+
 static char *event_name(struct hv_24x7_event_data *ev, int *len)
 {
*len = be16_to_cpu(ev->event_name_len) - 2;
@@ -1233,9 +1252,42 @@ static void update_event_count(struct perf_event *event, 
u64 now)
 static void h_24x7_event_read(struct perf_event *event)
 {
u64 now;
+   struct hv_24x7_request_buffer *request_buffer;
+
+   /*
+* If in a READ transaction, add this counter to the list of
+* counters to read during the next HCALL (i.e commit_txn()).
+* If not in a READ transaction, go ahead and make the HCALL
+* to read this counter by itself.
+*/
+
+   if (h24x7hw.txn_flags & PERF_PMU_TXN_READ) {
+   int i;
+   int ret;
+
+   if (h24x7hw.txn_err)
+   return;
+
+   request_buffer = (void *)&hv_24x7_txn_reqb[0];
+
+   ret = add_event_to_24x7_request(event, request_buffer);
+   if (ret) {
+   h24x7hw.txn_err = ret;
+   } else {
+   /*
+* Assoicate the event with the HCALL request index,
+* so ->commit_txn() can quickly find/update count.
+*/
+   i = request_buffer->num_requests - 1;
+   h24x7hw.events[i] = event;
+   }
+
+   put_cpu_var(hv_24x7_reqb);
+   } else {
+   now = h_24x7_get_value(event);
+   update_event_count(event, now);
+   }
 
-   now = h_24x7_get_value(event);
-   update_event_count(event, now);
 }
 
 static void h_24x7_event_start(struct perf_event *event, int flags)
@@ -1257,6 +1309,105 @@ static int h_24x7_event_add(struct perf_event *event, 
int flags)
return 0;
 }
 
+/*
+ * 24x7 counters only support READ transactions. They are
+ * always counting and dont need/support ADD transactions.
+ * Cache the flags, but ot

[PATCH v3 7/8] perf: Define PMU_TXN_READ interface

2015-07-14 Thread Sukadev Bhattiprolu
Define a new PERF_PMU_TXN_READ interface to read a group of counters
at once. Note that we use this interface with all PMUs.

PMUs that implement this interface use the ->read() operation to _queue_
the counters to be read and use ->commit_txn() to actually read all the
queued counters at once.

PMUs that don't implement PERF_PMU_TXN_READ ignore ->start_txn() and
->commit_txn() and continue to read counters one at a time.

Thanks to input from Peter Zijlstra.

Signed-off-by: Sukadev Bhattiprolu 
---
 include/linux/perf_event.h |1 +
 kernel/events/core.c   |   35 +--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 44bf05f..da307ad 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -169,6 +169,7 @@ struct perf_event;
 #define PERF_EVENT_TXN 0x1
 
 #define PERF_PMU_TXN_ADD  0x1  /* txn to add/schedule event on PMU */
+#define PERF_PMU_TXN_READ 0x2  /* txn to read event group from PMU */
 
 /**
  * pmu::capabilities flags
diff --git a/kernel/events/core.c b/kernel/events/core.c
index a83d45c..2ea06c4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3763,6 +3763,33 @@ static void orphans_remove_work(struct work_struct *work)
put_ctx(ctx);
 }
 
+/*
+ * Use the transaction interface to read the group of events in @leader.
+ * PMUs like the 24x7 counters in Power, can use this to queue the events
+ * in the ->read() operation and perform the actual read in ->commit_txn.
+ *
+ * Other PMUs can ignore the ->start_txn and ->commit_txn and read each
+ * PMU directly in the ->read() operation.
+ */
+static int perf_event_read_group(struct perf_event *leader)
+{
+   int ret;
+   struct perf_event *sub;
+   struct pmu *pmu;
+
+   pmu = leader->pmu;
+
+   pmu->start_txn(pmu, PERF_PMU_TXN_READ);
+
+   perf_event_read(leader);
+   list_for_each_entry(sub, &leader->sibling_list, group_entry)
+   perf_event_read(sub);
+
+   ret = pmu->commit_txn(pmu);
+
+   return ret;
+}
+
 u64 perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *running)
 {
u64 total = 0;
@@ -3792,7 +3819,11 @@ static int perf_read_group(struct perf_event *event,
 
lockdep_assert_held(&ctx->mutex);
 
-   count = perf_event_read_value(leader, &enabled, &running);
+   ret = perf_event_read_group(leader);
+   if (ret)
+   return ret;
+
+   count = perf_event_compute(leader, &enabled, &running);
 
values[n++] = 1 + leader->nr_siblings;
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
@@ -3813,7 +3844,7 @@ static int perf_read_group(struct perf_event *event,
list_for_each_entry(sub, &leader->sibling_list, group_entry) {
n = 0;
 
-   values[n++] = perf_event_read_value(sub, &enabled, &running);
+   values[n++] = perf_event_compute(sub, &enabled, &running);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
 
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 5/8] perf: Split perf_event_read_value()

2015-07-14 Thread Sukadev Bhattiprolu
Move the part of perf_event_read_value() that computes the event
counts and event times into a new function, perf_event_compute().

This would allow us to call perf_event_compute() independently.

Signed-off-by: Sukadev Bhattiprolu 

Changelog[v3]
Rather than move perf_event_read() into callers and then
rename, just move the computations into a separate function
(redesign to address comment from Peter Zijlstra).
---
 kernel/events/core.c |   37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 44fb89d..b1e9a42 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3704,6 +3704,29 @@ static int perf_release(struct inode *inode, struct file 
*file)
return 0;
 }
 
+static u64 perf_event_compute(struct perf_event *event, u64 *enabled,
+ u64 *running)
+{
+   struct perf_event *child;
+   u64 total;
+
+   total = perf_event_count(event);
+
+   *enabled += event->total_time_enabled +
+   atomic64_read(&event->child_total_time_enabled);
+   *running += event->total_time_running +
+   atomic64_read(&event->child_total_time_running);
+
+   list_for_each_entry(child, &event->child_list, child_list) {
+   perf_event_read(child);
+   total += perf_event_count(child);
+   *enabled += child->total_time_enabled;
+   *running += child->total_time_running;
+   }
+
+   return total;
+}
+
 /*
  * Remove all orphanes events from the context.
  */
@@ -3742,7 +3765,6 @@ static void orphans_remove_work(struct work_struct *work)
 
 u64 perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *running)
 {
-   struct perf_event *child;
u64 total = 0;
 
*enabled = 0;
@@ -3751,19 +3773,8 @@ u64 perf_event_read_value(struct perf_event *event, u64 
*enabled, u64 *running)
mutex_lock(&event->child_mutex);
 
perf_event_read(event);
-   total += perf_event_count(event);
+   total = perf_event_compute(event, enabled, running);
 
-   *enabled += event->total_time_enabled +
-   atomic64_read(&event->child_total_time_enabled);
-   *running += event->total_time_running +
-   atomic64_read(&event->child_total_time_running);
-
-   list_for_each_entry(child, &event->child_list, child_list) {
-   perf_event_read(child);
-   total += perf_event_count(child);
-   *enabled += child->total_time_enabled;
-   *running += child->total_time_running;
-   }
mutex_unlock(&event->child_mutex);
 
return total;
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 3/8] perf: Add a flags parameter to pmu txn interfaces

2015-07-14 Thread Sukadev Bhattiprolu
Currently, the PMU interface allows reading only one counter at a time.
But some PMUs like the 24x7 counters in Power, support reading several
counters at once. To leveage this functionality, extend the transaction
interface to support a "transaction type".

The first type, PERF_PMU_TXN_ADD, refers to the existing transactions,
i.e. used to _schedule_ all the events on the PMU as a group. A second
transaction type, PERF_PMU_TXN_READ, will be used in a follow-on patch,
by the 24x7 counters to read several counters at once.

Extend the transaction interfaces to the PMU to accept a 'txn_flags'
parameter and use this parameter to ignore any transactions that are
not of type PERF_PMU_TXN_ADD.

Thanks to Peter Zijlstra for his input.

Signed-off-by: Sukadev Bhattiprolu 

Changelog[v3]
- [Peter Zijlstra] Ensure the nop_txn interfaces disable/enable
  PMU only for TXN_ADD transactions.
- [Peter Zijlstra] Cache the flags parameter in ->start_txn() and
  drop the flags parameter from ->commit_txn() and ->cancel_txn().
---
 arch/powerpc/perf/core-book3s.c  |   25 ++-
 arch/s390/kernel/perf_cpum_cf.c  |   24 +-
 arch/sparc/kernel/perf_event.c   |   19 +-
 arch/x86/kernel/cpu/perf_event.c |   27 ++--
 arch/x86/kernel/cpu/perf_event.h |1 +
 include/linux/perf_event.h   |   14 ---
 kernel/events/core.c |   51 +++---
 7 files changed, 150 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index d90893b..b92084b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -50,6 +50,7 @@ struct cpu_hw_events {
 
unsigned int group_flag;
int n_txn_start;
+   int txn_flags;
 
/* BHRB bits */
u64 bhrb_filter;/* BHRB HW branch 
filter */
@@ -1586,11 +1587,19 @@ static void power_pmu_stop(struct perf_event *event, 
int ef_flags)
  * Start group events scheduling transaction
  * Set the flag to make pmu::enable() not perform the
  * schedulability test, it will be performed at commit time
+ *
+ * We only support PERF_PMU_TXN_ADD transactions. Save the
+ * transaction flags but otherwise ignore non-PERF_PMU_TXN_ADD
+ * transactions.
  */
-static void power_pmu_start_txn(struct pmu *pmu)
+static void power_pmu_start_txn(struct pmu *pmu, int txn_flags)
 {
struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
 
+   cpuhw->txn_flags = txn_flags;
+   if (txn_flags & ~PERF_PMU_TXN_ADD)
+   return;
+
perf_pmu_disable(pmu);
cpuhw->group_flag |= PERF_EVENT_TXN;
cpuhw->n_txn_start = cpuhw->n_events;
@@ -1604,6 +1613,12 @@ static void power_pmu_start_txn(struct pmu *pmu)
 static void power_pmu_cancel_txn(struct pmu *pmu)
 {
struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
+   int txn_flags;
+
+   txn_flags = cpuhw->txn_flags;
+   cpuhw->txn_flags = 0;
+   if (cpuhw->txn_flags & ~PERF_PMU_TXN_ADD)
+   return;
 
cpuhw->group_flag &= ~PERF_EVENT_TXN;
perf_pmu_enable(pmu);
@@ -1618,10 +1633,18 @@ static int power_pmu_commit_txn(struct pmu *pmu)
 {
struct cpu_hw_events *cpuhw;
long i, n;
+   int txn_flags;
 
if (!ppmu)
return -EAGAIN;
+
cpuhw = this_cpu_ptr(&cpu_hw_events);
+
+   txn_flags = cpuhw->txn_flags;
+   cpuhw->txn_flags = 0;
+   if (cpuhw->txn_flags & ~PERF_PMU_TXN_ADD)
+   return 0;
+
n = cpuhw->n_events;
if (check_excludes(cpuhw->event, cpuhw->flags, 0, n))
return -EAGAIN;
diff --git a/arch/s390/kernel/perf_cpum_cf.c b/arch/s390/kernel/perf_cpum_cf.c
index 56fdad4..a6f9e7b 100644
--- a/arch/s390/kernel/perf_cpum_cf.c
+++ b/arch/s390/kernel/perf_cpum_cf.c
@@ -72,6 +72,7 @@ struct cpu_hw_events {
atomic_tctr_set[CPUMF_CTR_SET_MAX];
u64 state, tx_state;
unsigned intflags;
+   int txn_flags;
 };
 static DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events) = {
.ctr_set = {
@@ -82,6 +83,7 @@ static DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events) = {
},
.state = 0,
.flags = 0,
+   .txn_flags = 0,
 };
 
 static int get_counter_set(u64 event)
@@ -572,11 +574,19 @@ static void cpumf_pmu_del(struct perf_event *event, int 
flags)
 /*
  * Start group events scheduling transaction.
  * Set flags to perform a single test at commit time.
+ *
+ * We only support PERF_PMU_TXN_ADD transactions. Save the
+ * transaction flags but otherwise ignore non-PERF_PMU_TXN_ADD
+ * transactions.
  */
-static void cpumf_pmu_start_txn(struct pmu *pmu)
+static void cpumf_pmu_start_txn(struct pmu *pmu, int txn_flags)
 {
struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
 
+   cpuhw->txn_flags

[PATCH v3 4/8] perf: Split perf_event_read() and perf_event_count()

2015-07-14 Thread Sukadev Bhattiprolu
perf_event_read() does two things:

- call the PMU to read/update the counter value, and
- compute the total count of the event and its children

Not all callers need both. perf_event_reset() for instance needs the
first piece but doesn't need the second.  Similarly, when we implement
the ability to read a group of events using the transaction interface,
we would need the two pieces done independently.

Break up perf_event_read() and have it just read/update the counter
and have the callers compute the total count if necessary.

Signed-off-by: Sukadev Bhattiprolu 
---
 kernel/events/core.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index b79aad2..44fb89d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3212,7 +3212,7 @@ static inline u64 perf_event_count(struct perf_event 
*event)
return __perf_event_count(event);
 }
 
-static u64 perf_event_read(struct perf_event *event)
+static void perf_event_read(struct perf_event *event)
 {
/*
 * If event is enabled and currently active on a CPU, update the
@@ -3238,8 +3238,6 @@ static u64 perf_event_read(struct perf_event *event)
update_event_times(event);
raw_spin_unlock_irqrestore(&ctx->lock, flags);
}
-
-   return perf_event_count(event);
 }
 
 /*
@@ -3751,14 +3749,18 @@ u64 perf_event_read_value(struct perf_event *event, u64 
*enabled, u64 *running)
*running = 0;
 
mutex_lock(&event->child_mutex);
-   total += perf_event_read(event);
+
+   perf_event_read(event);
+   total += perf_event_count(event);
+
*enabled += event->total_time_enabled +
atomic64_read(&event->child_total_time_enabled);
*running += event->total_time_running +
atomic64_read(&event->child_total_time_running);
 
list_for_each_entry(child, &event->child_list, child_list) {
-   total += perf_event_read(child);
+   perf_event_read(child);
+   total += perf_event_count(child);
*enabled += child->total_time_enabled;
*running += child->total_time_running;
}
@@ -3918,7 +3920,7 @@ static unsigned int perf_poll(struct file *file, 
poll_table *wait)
 
 static void _perf_event_reset(struct perf_event *event)
 {
-   (void)perf_event_read(event);
+   perf_event_read(event);
local64_set(&event->count, 0);
perf_event_update_userpage(event);
 }
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 2/8] powerpc/perf/hv-24x7: Simplify extracting counter from result buffer

2015-07-14 Thread Sukadev Bhattiprolu
Simplify code that extracts a 24x7 counter from the HCALL's result buffer.

Suggested-by: Joe Perches 
Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 9d73c69..4d1a8d1 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1104,7 +1104,7 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
unsigned long ret;
struct hv_24x7_request_buffer *request_buffer;
struct hv_24x7_data_result_buffer *result_buffer;
-   struct hv_24x7_result *resb;
+   __be64 val;
 
BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
@@ -1125,8 +1125,8 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
}
 
/* process result from hcall */
-   resb = &result_buffer->results[0];
-   *count = be64_to_cpu(resb->elements[0].element_data[0]);
+   val = result_buffer->results[0].elements[0].element_data[0];
+   *count = be64_to_cpu(val);
 
 out:
put_cpu_var(hv_24x7_reqb);
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 1/8] powerpc/perf/hv-24x7: Whitespace - fix parameter alignment

2015-07-14 Thread Sukadev Bhattiprolu
Fix parameter alignment to be consistent with coding style.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index df95629..9d73c69 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -416,7 +416,7 @@ out_val:
 }
 
 static struct attribute *event_to_desc_attr(struct hv_24x7_event_data *event,
-   int nonce)
+   int nonce)
 {
int nl, dl;
char *name = event_name(event, &nl);
@@ -444,7 +444,7 @@ event_to_long_desc_attr(struct hv_24x7_event_data *event, 
int nonce)
 }
 
 static ssize_t event_data_to_attrs(unsigned ix, struct attribute **attrs,
-   struct hv_24x7_event_data *event, int nonce)
+  struct hv_24x7_event_data *event, int nonce)
 {
unsigned i;
 
@@ -512,7 +512,7 @@ static int memord(const void *d1, size_t s1, const void 
*d2, size_t s2)
 }
 
 static int ev_uniq_ord(const void *v1, size_t s1, unsigned d1, const void *v2,
-   size_t s2, unsigned d2)
+  size_t s2, unsigned d2)
 {
int r = memord(v1, s1, v2, s2);
 
@@ -526,7 +526,7 @@ static int ev_uniq_ord(const void *v1, size_t s1, unsigned 
d1, const void *v2,
 }
 
 static int event_uniq_add(struct rb_root *root, const char *name, int nl,
-   unsigned domain)
+ unsigned domain)
 {
struct rb_node **new = &(root->rb_node), *parent = NULL;
struct event_uniq *data;
@@ -650,8 +650,8 @@ static ssize_t catalog_event_len_validate(struct 
hv_24x7_event_data *event,
 #define MAX_4K (SIZE_MAX / 4096)
 
 static int create_events_from_catalog(struct attribute ***events_,
-   struct attribute ***event_descs_,
-   struct attribute ***event_long_descs_)
+ struct attribute ***event_descs_,
+ struct attribute ***event_long_descs_)
 {
unsigned long hret;
size_t catalog_len, catalog_page_len, event_entry_count,
@@ -1008,8 +1008,8 @@ static const struct attribute_group *attr_groups[] = {
 };
 
 static void log_24x7_hcall(struct hv_24x7_request_buffer *request_buffer,
-   struct hv_24x7_data_result_buffer *result_buffer,
-   unsigned long ret)
+  struct hv_24x7_data_result_buffer *result_buffer,
+  unsigned long ret)
 {
struct hv_24x7_request *req;
 
@@ -1026,7 +1026,7 @@ static void log_24x7_hcall(struct hv_24x7_request_buffer 
*request_buffer,
  * Start the process for a new H_GET_24x7_DATA hcall.
  */
 static void init_24x7_request(struct hv_24x7_request_buffer *request_buffer,
-   struct hv_24x7_data_result_buffer *result_buffer)
+ struct hv_24x7_data_result_buffer *result_buffer)
 {
 
memset(request_buffer, 0, 4096);
@@ -1041,7 +1041,7 @@ static void init_24x7_request(struct 
hv_24x7_request_buffer *request_buffer,
  * by 'init_24x7_request()' and 'add_event_to_24x7_request()'.
  */
 static int make_24x7_request(struct hv_24x7_request_buffer *request_buffer,
-   struct hv_24x7_data_result_buffer *result_buffer)
+struct hv_24x7_data_result_buffer *result_buffer)
 {
unsigned long ret;
 
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/8] Implement group-read of events using txn interface

2015-07-14 Thread Sukadev Bhattiprolu
Unlike normal hardware PMCs, the 24x7 counters in Power8 are stored in
memory and accessed via a hypervisor call(HCALL).  A major aspect of the
HCALL is that it allows retireving _several_ counters at once (unlike
regular PMCs, which are read one at a time). By reading several counters
at once, we can get a more consistent snapshot of the system.

This patchset extends the transaction interface to accomplish submitting
several events to the PMU and have the PMU read them all at once. User is
expected to submit the set of events they want to read as an "event group".

In the kernel, we submit each event to the PMU using the following logic
(from Peter Zijlstra).

pmu->start_txn(pmu, PMU_TXN_READ);

leader->read();
for_each_sibling()
sibling->read();
pmu->commit_txn();

where:
- the ->read()s queue events to be submitted to the hypervisor, and,
- the ->commit_txn() issues the HCALL, retrieves the result and
  updates the event count.

Architectures/PMUs that don't need/implement PMU_TXN_READ type of transactions,
simply ignore the ->start_txn() and ->commit_txn() and continue to read the
counters one at a time in the ->read() call.

Compile/touch tested on x86. Need help testing on s390 and Sparc.

Thanks to Peter Zijlstra for his input.

Changelog [v3]
- Simple changes/reorg of patchset to split/rename functions
- [Peter Zijlstra] Save the transaction flags in ->start_txn() and
  drop the flags parameter from ->commit_txn() and ->cancel_txn().
- [Peter Zijlstra] The nop txn interfaces don't need to disable/enable
  PMU for PERF_PMU_TXN_READ transactions.

Changelog [v2]
- Use the transaction interface unconditionally to avoid special-case
  code. Architectures/PMUs that don't need the READ transaction types
  simply ignore the ->start_txn() and ->commit_txn() calls.

Peter Zijlstra (Intel) (1):
  perf: Rename perf_event_read_{one,group}, perf_read_hw

Sukadev Bhattiprolu (7):
  powerpc/perf/hv-24x7: Whitespace - fix parameter alignment
  powerpc/perf/hv-24x7: Simplify extracting counter from result buffer
  perf: Add a flags parameter to pmu txn interfaces
  perf: Split perf_event_read() and perf_event_count()
  perf: Split perf_event_read_value()
  perf: Define PMU_TXN_READ interface
  powerpc/perf/hv-24x7: Use PMU_TXN_READ interface

 arch/powerpc/perf/core-book3s.c  |   25 -
 arch/powerpc/perf/hv-24x7.c  |  186 ++
 arch/s390/kernel/perf_cpum_cf.c  |   24 -
 arch/sparc/kernel/perf_event.c   |   19 +++-
 arch/x86/kernel/cpu/perf_event.c |   27 +-
 arch/x86/kernel/cpu/perf_event.h |1 +
 include/linux/perf_event.h   |   15 ++-
 kernel/events/core.c |  143 +++--
 8 files changed, 389 insertions(+), 51 deletions(-)

-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC,1/2] powerpc/numa: fix cpu_to_node() usage during boot

2015-07-14 Thread Michael Ellerman
On Wed, 2015-07-08 at 16:16 -0700, Nishanth Aravamudan wrote:
> On 08.07.2015 [14:00:56 +1000], Michael Ellerman wrote:
> > On Thu, 2015-02-07 at 23:02:02 UTC, Nishanth Aravamudan wrote:
> > > 
> > > we currently emit at boot:
> > > 
> > > [0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7 
> > > 
> > > After this commit, we correctly emit:
> > > 
> > > [0.00] pcpu-alloc: [0] 0 1 2 3 [1] 4 5 6 7 
> > 
> > 
> > So it looks fairly sane, and I guess it's a bug fix.
> > 
> > But I'm a bit reluctant to put it in straight away without some time in 
> > next.
> 
> I'm fine with that -- it could use some more extensive testing,
> admittedly (I only have been able to verify the pcpu areas are being
> correctly allocated on the right node so far).
> 
> I still need to test with hotplug and things like that. Hence the RFC.
> 
> > It looks like the symptom is that the per-cpu areas are all allocated on 
> > node
> > 0, is that all that goes wrong?
> 
> Yes, that's the symptom. I cc'd a few folks to see if they could help
> indicate the performance implications of such a setup -- sorry, I should
> have been more explicit about that.

OK cool. I'm happy to put it in next if you send a non-RFC version.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 48/49] PCI: Introduce resource_disabled()

2015-07-14 Thread Yinghai Lu
so we can cover !flags and IORESOURCE_DISABLED both.

Cc: linux-al...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-am33-l...@redhat.com
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
Cc: io...@lists.linux-foundation.org
Cc: linux...@vger.kernel.org
Signed-off-by: Yinghai Lu 
---
 arch/alpha/kernel/pci.c   |  2 +-
 arch/ia64/pci/pci.c   |  4 ++--
 arch/microblaze/pci/pci-common.c  | 15 ---
 arch/mn10300/unit-asb2305/pci-asb2305.c   |  4 ++--
 arch/mn10300/unit-asb2305/pci.c   |  4 ++--
 arch/powerpc/kernel/pci-common.c  | 16 +---
 arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++--
 arch/s390/pci/pci.c   |  2 +-
 arch/sparc/kernel/pci.c   |  2 +-
 arch/x86/pci/i386.c   |  4 ++--
 arch/xtensa/kernel/pci.c  |  4 ++--
 drivers/iommu/intel-iommu.c   |  3 ++-
 drivers/pci/host/pcie-rcar.c  |  2 +-
 drivers/pci/iov.c |  2 +-
 drivers/pci/probe.c   |  2 +-
 drivers/pci/quirks.c  |  2 +-
 drivers/pci/rom.c |  2 +-
 drivers/pci/setup-bus.c   |  8 
 drivers/pci/setup-res.c   |  2 +-
 include/linux/ioport.h|  4 
 20 files changed, 52 insertions(+), 44 deletions(-)

diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 82f738e..91a7153 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -282,7 +282,7 @@ pcibios_claim_one_bus(struct pci_bus *b)
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *r = &dev->resource[i];
 
-   if (r->parent || !r->start || !r->flags)
+   if (r->parent || !r->start || resource_disabled(r))
continue;
if (pci_has_flag(PCI_PROBE_ONLY) ||
(r->flags & IORESOURCE_PCI_FIXED)) {
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 7cc3be9..cc293ea 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -501,7 +501,7 @@ void pcibios_fixup_device_resources(struct pci_dev *dev)
for (idx = 0; idx < PCI_BRIDGE_RESOURCES; idx++) {
struct resource *r = &dev->resource[idx];
 
-   if (!r->flags || r->parent || !r->start)
+   if (resource_disabled(r) || r->parent || !r->start)
continue;
 
pci_claim_resource(dev, idx);
@@ -519,7 +519,7 @@ static void pcibios_fixup_bridge_resources(struct pci_dev 
*dev)
for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
struct resource *r = &dev->resource[idx];
 
-   if (!r->flags || r->parent || !r->start)
+   if (resource_disabled(r) || r->parent || !r->start)
continue;
 
pci_claim_bridge_resource(dev, idx);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 09b1af6..c123d3c 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -705,7 +705,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
}
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev->resource + i;
-   if (!res->flags)
+   if (resource_disabled(res))
continue;
if (res->start == 0) {
pr_debug("PCI:%s Resource %d %016llx-%016llx [%x]",
@@ -806,7 +806,7 @@ static void pcibios_fixup_bridge(struct pci_bus *bus)
pci_bus_for_each_resource(bus, res, i) {
if (!res)
continue;
-   if (!res->flags)
+   if (resource_disabled(res))
continue;
if (i >= 3 && bus->self->transparent)
continue;
@@ -985,7 +985,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus 
*bus)
 pci_domain_nr(bus), bus->number);
 
pci_bus_for_each_resource(bus, res, i) {
-   if (!res || !res->flags
+   if (!res || resource_disabled(res)
|| res->start > res->end || res->parent)
continue;
if (bus->parent == NULL)
@@ -1087,7 +1087,8 @@ static void __init pcibios_allocate_resources(int pass)
r = &dev->resource[idx];
if (r->parent)  /* Already allocated */
continue;
-   if (!r->flags || (r->flags & IORESOURCE_UNSET))
+   if (resource_disabled(r) ||
+   (r->flags & IORESOURCE_UNSET))
  

[PATCH v2 29/49] PCI: Unify skip_ioresource_align()

2015-07-14 Thread Yinghai Lu
There are powerpc generic version and x86 local version.

Move the powerpc version to setup-bus.c, and kill x86 local version.

Also kill dummy version in microblaze.

Cc: Michal Simek 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Arnd Bergmann 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Yinghai Lu 
---
 arch/microblaze/pci/pci-common.c |  8 
 arch/powerpc/kernel/pci-common.c | 11 +--
 arch/x86/include/asm/pci_x86.h   |  1 -
 arch/x86/pci/common.c|  4 ++--
 arch/x86/pci/i386.c  | 12 ++--
 drivers/pci/setup-bus.c  |  9 +
 include/asm-generic/pci-bridge.h |  2 ++
 7 files changed, 16 insertions(+), 31 deletions(-)

diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index ae838ed..09b1af6 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -878,11 +878,6 @@ void pcibios_fixup_bus(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibios_fixup_bus);
 
-static int skip_isa_ioresource_align(struct pci_dev *dev)
-{
-   return 0;
-}
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
@@ -899,12 +894,9 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
 {
-   struct pci_dev *dev = data;
resource_size_t start = res->start;
 
if (res->flags & IORESOURCE_IO) {
-   if (skip_isa_ioresource_align(dev))
-   return start;
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
}
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index b9de34d..2d8d654 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1064,15 +1064,6 @@ void pci_fixup_cardbus(struct pci_bus *bus)
pcibios_setup_bus_devices(bus);
 }
 
-
-static int skip_isa_ioresource_align(struct pci_dev *dev)
-{
-   if (pci_has_flag(PCI_CAN_SKIP_ISA_ALIGN) &&
-   !(dev->bus->bridge_ctl & PCI_BRIDGE_CTL_ISA))
-   return 1;
-   return 0;
-}
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
@@ -1093,7 +1084,7 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
resource_size_t start = res->start;
 
if (res->flags & IORESOURCE_IO) {
-   if (skip_isa_ioresource_align(dev))
+   if (skip_isa_ioresource_align(dev->bus))
return start;
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 164e3f8..ddac225 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -28,7 +28,6 @@ do {  \
 #define PCI_ASSIGN_ROMS0x1000
 #define PCI_BIOS_IRQ_SCAN  0x2000
 #define PCI_ASSIGN_ALL_BUSSES  0x4000
-#define PCI_CAN_SKIP_ISA_ALIGN 0x8000
 #define PCI_USE__CRS   0x1
 #define PCI_CHECK_ENABLE_AMD_MMCONF0x2
 #define PCI_HAS_IO_ECS 0x4
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 8fd6f44..e8df922 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -83,7 +83,7 @@ DEFINE_RAW_SPINLOCK(pci_config_lock);
 
 static int __init can_skip_ioresource_align(const struct dmi_system_id *d)
 {
-   pci_probe |= PCI_CAN_SKIP_ISA_ALIGN;
+   pci_add_flags(PCI_CAN_SKIP_ISA_ALIGN);
printk(KERN_INFO "PCI: %s detected, can skip ISA alignment\n", 
d->ident);
return 0;
 }
@@ -619,7 +619,7 @@ char *__init pcibios_setup(char *str)
pci_routeirq = 1;
return NULL;
} else if (!strcmp(str, "skip_isa_align")) {
-   pci_probe |= PCI_CAN_SKIP_ISA_ALIGN;
+   pci_add_flags(PCI_CAN_SKIP_ISA_ALIGN);
return NULL;
} else if (!strcmp(str, "noioapicquirk")) {
noioapicquirk = 1;
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 0a9f2ca..3f17726 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -128,15 +129,6 @@ static void __init pcibios_fw_addr_list_del(void)
pcibios_fw_addr_done = true;
 }
 
-static int
-skip_isa_ioresource_align(struct pci_dev *dev) {
-
-   if ((pci_probe & PCI_CAN_SKIP_ISA_ALIGN) &&
-   !(dev->bus->bridge_ctl & PCI_BRIDGE_CTL_ISA))
-   return 1;
-   return 0;
-}
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
@@ -158,7 +150,7 @@ pcibios_align_resource(void *data

[PATCH v2 40/49] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in of parsing

2015-07-14 Thread Yinghai Lu
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource, so set
IORESOUCE_MEM_64 for 64bit resource during of device resource flags
parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Gavin Shan 
Cc: Yijing Wang 
Cc: Anton Blanchard 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 42e02a2..f31bfd0 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
 
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
-   flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+   if (addr0 & 0x0100)
+   flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
 | PCI_BASE_ADDRESS_MEM_PREFETCH;
-- 
1.8.4.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 1/2] powerpc/numa: fix cpu_to_node() usage during boot

2015-07-14 Thread David Rientjes
On Fri, 10 Jul 2015, Nishanth Aravamudan wrote:

> > After the percpu areas on initialized and cpu_to_node() is correct, it 
> > would be really nice to be able to make numa_cpu_lookup_table[] be 
> > __initdata since it shouldn't be necessary anymore.  That probably has cpu 
> > callbacks that need to be modified to no longer look at 
> > numa_cpu_lookup_table[] or pass the value in, but it would make it much 
> > cleaner.  Then nobody will have to worry about figuring out whether 
> > early_cpu_to_node() or cpu_to_node() is the right one to call.
> 
> When I worked on the original pcpu patches for power, I wanted to do
> this, but got myself confused and never came back to it. Thank you for
> suggesting it and I'll work on it soon.
> 

Great, thanks for taking it on!  I have powerpc machines so I can test 
this and try to help where possible.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: BUG: sleeping function called from ras_epow_interrupt context

2015-07-14 Thread Benjamin Herrenschmidt
On Tue, 2015-07-14 at 20:43 +0200, Thomas Huth wrote:
> Any suggestions how to fix this? Simply revert 587f83e8dd50d? Use
> mdelay() instead of msleep() in rtas_busy_delay()? Something more
> fancy?

A proper fix would be more fancy, the get_sensor should happen in a
kernel thread instead.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

BUG: sleeping function called from ras_epow_interrupt context

2015-07-14 Thread Thomas Huth

 Hi all!

A colleague recently ran into some kernel BUG messages that happen when
hot-plugging a virtio disk to a KVM guest on powerpc (with "virsh
attach-disk"), and IIRC CONFIG_DEBUG_ATOMIC_SLEEP enabled. I've tried to
re-create the problem with an up-to-date kernel (4.2.0-rc2) and the
problem still seems to be there:

The hotplug action triggers the ras_epow_interrupt() in
arch/powerpc/platforms/pseries/ras.c, which again calls
rtas_get_sensor(). That function then uses rtas_busy_delay() to wait in
case the RTAS call did not succeed immediately. But rtas_busy_delay()
uses msleep() for sleeping - which is forbidden during an atomic
interrupt context!

Following backtrace is printed out by the kernel:

[   33.920528] BUG: sleeping function called from invalid context at
/home/thuth/devel/linux-up/arch/powerpc/kernel/rtas.c:496
[   33.920590] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
[   33.920624] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #1
[   33.920657] Call Trace:
[   33.920677] [c0007ffe79b0] [c07e43f4]
.dump_stack+0x98/0xd4 (unreliable)
[   33.920729] [c0007ffe7a30] [c00dcc78]
.___might_sleep+0x128/0x170
[   33.920769] [c0007ffe7aa0] [c0029f38]
.rtas_busy_delay+0x28/0xe0
[   33.920809] [c0007ffe7b20] [c002adb4]
.rtas_get_sensor+0x74/0xe0
[   33.920850] [c0007ffe7bc0] [c007ff58]
.ras_epow_interrupt+0x48/0x450
[   33.920896] [c0007ffe7c80] [c0119d94]
.handle_irq_event_percpu+0xa4/0x310
[   33.920942] [c0007ffe7d70] [c011a05c]
.handle_irq_event+0x5c/0xa0
[   33.920982] [c0007ffe7e00] [c011e7a8]
.handle_fasteoi_irq+0xe8/0x270
[   33.921028] [c0007ffe7e90] [c01190bc]
.generic_handle_irq+0x4c/0x80
[   33.921074] [c0007ffe7f10] [c0010a48] .__do_irq+0x88/0x1f0
[   33.921115] [c0007ffe7f90] [c0022a0c] .call_do_irq+0x14/0x24
[   33.921155] [c0007e6f37e0] [c0010c3c] .do_IRQ+0x8c/0x100
[   33.921195] [c0007e6f3880] [c0002594]
hardware_interrupt_common+0x114/0x180
[   33.921243] --- interrupt: 501 at .plpar_hcall_norets+0x14/0x20
[   33.921243] LR = .check_and_cede_processor+0x24/0x40
[   33.921300] [c0007e6f3b70] []   (null)
(unreliable)
[   33.921347] [c0007e6f3be0] [c0628068]
.shared_cede_loop+0x58/0x160
[   33.921393] [c0007e6f3c70] [c06259ac]
.cpuidle_enter_state+0xbc/0x3b0
[   33.921439] [c0007e6f3d30] [c00fe32c] .call_cpuidle+0x4c/0xa0
[   33.921479] [c0007e6f3db0] [c00fe700]
.cpu_startup_entry+0x380/0x4a0
[   33.921526] [c0007e6f3ed0] [c0043110]
.start_secondary+0x320/0x350
[   33.921571] [c0007e6f3f90] [c0008b6c]
start_secondary_prolog+0x10/0x14

I think that bug might have been introduced by commit
587f83e8dd50d22bc0c62 ("Use rtas_get_sensor in RAS code") since the
rtas_busy_delay() was not called before that commit, as far as I can see.

Any suggestions how to fix this? Simply revert 587f83e8dd50d? Use
mdelay() instead of msleep() in rtas_busy_delay()? Something more fancy?

 Thanks,
  Thomas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Vivek Goyal
On Tue, Jul 14, 2015 at 01:01:12PM -0500, Eric W. Biederman wrote:
> Vivek Goyal  writes:
> 
> > On Tue, Jul 14, 2015 at 05:29:53PM +, dwal...@fifo99.com wrote:
> >
> > [..]
> >> > >> > If a machine is failing, there are high chance it can't deliver you 
> >> > >> > the
> >> > >> > notification. Detecting that failure suing some kind of polling 
> >> > >> > mechanism
> >> > >> > might be more reliable. And it will make even kdump mechanism more
> >> > >> > reliable so that it does not have to run panic notifiers after the 
> >> > >> > crash.
> >> > >> 
> >> > >> I think what your suggesting is that my company should change how 
> >> > >> it's hardware works
> >> > >> and that's not really an option for me. This isn't a simple thing 
> >> > >> like checking over the
> >> > >> network if the machine is down or not, this is way more complex 
> >> > >> hardware design.
> >> > >
> >> > > That means you are ready to live with an unreliable design. There 
> >> > > might be
> >> > > cases where notifier does not get run properly and you will not do 
> >> > > switch
> >> > > despite the fact that OS has failed. I was just trying to nudge you in
> >> > > a direction which could be more reliable mechanism.
> >> > 
> >> > Sigh I see some deep confusion going on here.
> >> > 
> >> > The panic notifiers are just that panic notifiers.  They have not been
> >> > nor should they be tied to kexec.   If those notifiers force a switch
> >> > over of between machines I fail to see why you would care if it was
> >> > kexec or another panic situation that is forcing that switchover.
> >> 
> >> Hidehiro isn't fixing the failover situation on my side, he's fixing 
> >> register
> >> information collection when crash_kexec_post_notifiers is used.
> >
> > Sure. Given that we have created this new parameter, let us fix it so that
> > we can capture the other cpu register state in crash dump.
> >
> > I am little disappointed that it was not tested well when this parameter was
> > introuced. We should have atleast tested it to the extent to see if there
> > is proper cpu state present for all cpus in the crash dump.
> >
> > At that point of time it looked like a simple modification
> > to allow panic notifiers before crash_kexec().
> 
> Either that or we say no one cares enough, and it known broken so let's
> just revert the fool thing.

Masami, you introduced this option. Are you fine with the revert? Is it
really being used and tested?

> I honestly can't see how to support panic notifiers, before kexec.
> There is no way to tell what is being done and all of the pieces
> including smp_send_stop are known to be buggy.

we should be able to replace smp_send_stop() with what crash_kexec() is
doing to stop the machine? If yes, then it should be fine I guess. This
parameter description clearly says that specify it at your own risk. So
we are not issuing a big support statement for successful kdump after
panic notifiers. If it is something fixable, otherwise user needs
to deal with it.

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Eric W. Biederman
Vivek Goyal  writes:

> On Tue, Jul 14, 2015 at 05:29:53PM +, dwal...@fifo99.com wrote:
>
> [..]
>> > >> > If a machine is failing, there are high chance it can't deliver you 
>> > >> > the
>> > >> > notification. Detecting that failure suing some kind of polling 
>> > >> > mechanism
>> > >> > might be more reliable. And it will make even kdump mechanism more
>> > >> > reliable so that it does not have to run panic notifiers after the 
>> > >> > crash.
>> > >> 
>> > >> I think what your suggesting is that my company should change how it's 
>> > >> hardware works
>> > >> and that's not really an option for me. This isn't a simple thing like 
>> > >> checking over the
>> > >> network if the machine is down or not, this is way more complex 
>> > >> hardware design.
>> > >
>> > > That means you are ready to live with an unreliable design. There might 
>> > > be
>> > > cases where notifier does not get run properly and you will not do switch
>> > > despite the fact that OS has failed. I was just trying to nudge you in
>> > > a direction which could be more reliable mechanism.
>> > 
>> > Sigh I see some deep confusion going on here.
>> > 
>> > The panic notifiers are just that panic notifiers.  They have not been
>> > nor should they be tied to kexec.   If those notifiers force a switch
>> > over of between machines I fail to see why you would care if it was
>> > kexec or another panic situation that is forcing that switchover.
>> 
>> Hidehiro isn't fixing the failover situation on my side, he's fixing register
>> information collection when crash_kexec_post_notifiers is used.
>
> Sure. Given that we have created this new parameter, let us fix it so that
> we can capture the other cpu register state in crash dump.
>
> I am little disappointed that it was not tested well when this parameter was
> introuced. We should have atleast tested it to the extent to see if there
> is proper cpu state present for all cpus in the crash dump.
>
> At that point of time it looked like a simple modification
> to allow panic notifiers before crash_kexec().

Either that or we say no one cares enough, and it known broken so let's
just revert the fool thing.

I honestly can't see how to support panic notifiers, before kexec.
There is no way to tell what is being done and all of the pieces
including smp_send_stop are known to be buggy.

It isn't like this latest set of patches was reviewed/tested much
better, as the first patch was wrong.

Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3] powerpc/pseries: Limit EPOW reset event warnings

2015-07-14 Thread Vipin K Parashar


Patch looks good. Though it seems that we can improve upon
commit log description to better describe the problem and solution.
Few suggestions as below:

Avoid multiple EPOW reset ..
is better suited as one line description of this problem.

On 07/14/2015 08:39 PM, Kamalesh Babulal wrote:

We print the respective warning after parsing EPOW interrupts,


Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts.


prompting user to take action depending upon the severity of the
event.


Please merge below line with above one.



Some times EPOW rest event warning, such as below could flood

   ^^  ^^
At times EPOW reset  event warning is found to be flooding..

kernel log, over a period of time.


Paste the multiple warnings log here.


Limit these warnings by use of


This patch avoids these multiple EPOW reset warnings by using a boolean 
flag.



epow_state flag, which is initialized to false and when any event


This flag is initialized to false and is set to true upon arrival of 
EPOW event.



gets reported, the flag set to true once an event gets acknowledged
by a reset.

The reset action is guarded by bool flag (set only if there was event


This same flag is checked and reset during EPOW_RESET scenario to
filter out valid EPOW reset events and avoid multiple warning logs.


reported previously) and ignore multiple resets, without real EPOW
event.
Also, merge adjacent pr_err/pr_emerg into single one to reduce

  ^
 merged

the number of lines printed per warning.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

Suggested-by: Vipin K Parashar 
Cc: Anshuman Khandual 
Cc: Anton Blanchard 
Cc: Michael Ellerman 
Signed-off-by: Kamalesh Babulal 
---
v3 Changes:
   - Limit warning printed by EPOW RESET event, by guarding it with bool flag.
 Instead of rate limiting all the EPOW events.

v2 Changes:
   - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
 warnings, based on Michael's comments.

  arch/powerpc/platforms/pseries/ras.c | 25 +
  1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..b30396a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,9 @@ static int ras_check_exception_token;
  #define EPOW_SENSOR_TOKEN 9
  #define EPOW_SENSOR_INDEX 0

+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
+
  static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
  static irqreturn_t ras_error_interrupt(int irq, void *dev_id);

@@ -145,21 +148,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)

switch (action_code) {
case EPOW_RESET:
-   pr_err("Non critical power or cooling issue cleared");
+   if (epow_state) {
+   pr_err("Non critical power or cooling issue cleared");
+   epow_state = false;
+   }
break;

case EPOW_WARN_COOLING:
-   pr_err("Non critical cooling issue reported by firmware");
-   pr_err("Check RTAS error log for details");
+   pr_err("Non critical cooling issue reported by firmware, "
+  "Check RTAS error log for details");
+   epow_state = true;
break;

case EPOW_WARN_POWER:
-   pr_err("Non critical power issue reported by firmware");
-   pr_err("Check RTAS error log for details");
+   pr_err("Non critical power issue reported by firmware, "
+  "Check RTAS error log for details");
+   epow_state = true;
break;

case EPOW_SYSTEM_SHUTDOWN:
handle_system_shutdown(epow_log->event_modifier);
+   epow_state = true;
break;

case EPOW_SYSTEM_HALT:
@@ -169,9 +178,8 @@ static vo

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Vivek Goyal
On Tue, Jul 14, 2015 at 05:29:53PM +, dwal...@fifo99.com wrote:

[..]
> > >> > If a machine is failing, there are high chance it can't deliver you the
> > >> > notification. Detecting that failure suing some kind of polling 
> > >> > mechanism
> > >> > might be more reliable. And it will make even kdump mechanism more
> > >> > reliable so that it does not have to run panic notifiers after the 
> > >> > crash.
> > >> 
> > >> I think what your suggesting is that my company should change how it's 
> > >> hardware works
> > >> and that's not really an option for me. This isn't a simple thing like 
> > >> checking over the
> > >> network if the machine is down or not, this is way more complex hardware 
> > >> design.
> > >
> > > That means you are ready to live with an unreliable design. There might be
> > > cases where notifier does not get run properly and you will not do switch
> > > despite the fact that OS has failed. I was just trying to nudge you in
> > > a direction which could be more reliable mechanism.
> > 
> > Sigh I see some deep confusion going on here.
> > 
> > The panic notifiers are just that panic notifiers.  They have not been
> > nor should they be tied to kexec.   If those notifiers force a switch
> > over of between machines I fail to see why you would care if it was
> > kexec or another panic situation that is forcing that switchover.
> 
> Hidehiro isn't fixing the failover situation on my side, he's fixing register
> information collection when crash_kexec_post_notifiers is used.

Sure. Given that we have created this new parameter, let us fix it so that
we can capture the other cpu register state in crash dump.

I am little disappointed that it was not tested well when this parameter was
introuced. We should have atleast tested it to the extent to see if there
is proper cpu state present for all cpus in the crash dump.

At that point of time it looked like a simple modification
to allow panic notifiers before crash_kexec().

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread dwalker
On Tue, Jul 14, 2015 at 12:06:15PM -0500, Eric W. Biederman wrote:
> Vivek Goyal  writes:
> 
> > On Tue, Jul 14, 2015 at 03:48:33PM +, dwal...@fifo99.com wrote:
> >> On Tue, Jul 14, 2015 at 11:40:40AM -0400, Vivek Goyal wrote:
> >> > On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote:
> >> > > On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote:
> >> > > > On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> >> > > > > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> >> > > > > > dwal...@fifo99.com writes:
> >> > > > > > 
> >> > > > > > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman 
> >> > > > > > > wrote:
> >> > > > > > >> Hidehiro Kawai  writes:
> >> > > > > > >> 
> >> > > > > > >> > You can call panic notifiers and kmsg dumpers before kdump 
> >> > > > > > >> > by
> >> > > > > > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> >> > > > > > >> > However, it doesn't make sense if kdump is not available.  
> >> > > > > > >> > In that
> >> > > > > > >> > case, disable "crash_kexec_post_notifiers" boot parameter 
> >> > > > > > >> > so that
> >> > > > > > >> > you can't change the value of the parameter.
> >> > > > > > >> 
> >> > > > > > >> Nacked-by: "Eric W. Biederman" 
> >> > > > > > >
> >> > > > > > > I think it would make sense if he just replaced "kdump" with 
> >> > > > > > > "kexec".
> >> > > > > > 
> >> > > > > > It would be less insane, however it still makes no sense as 
> >> > > > > > without
> >> > > > > > kexec on panic support crash_kexec is a noop.  So the value of 
> >> > > > > > the
> >> > > > > > seeting makes no difference.
> >> > > > > 
> >> > > > > Can you explain more, I don't really understand what you mean. Are 
> >> > > > > you suggesting
> >> > > > > the whole "crash_kexec_post_notifiers" feature has no value ?
> >> > > > 
> >> > > > Daniel,
> >> > > > 
> >> > > > BTW, why are you using crash_kexec_post_notifiers commandline? Why 
> >> > > > not
> >> > > > without it?
> >> > > 
> >> > > It was explained in the prior thread but to rehash, the notifiers are 
> >> > > used to do a switch
> >> > > over from the crashed machine to another redundant machine.
> >> > 
> >> > So why not detect failure using polling or issue notifications from 
> >> > second
> >> > kernel.
> >> > 
> >> > IOW, expecting that a crashed machine will be able to deliver 
> >> > notification
> >> > reliably is falwed to begin with, IMHO.
> >> 
> >> It's flawed to think you can kexec, but you still do it right ? I've not 
> >> gotten into
> >> the deep details of this switching process, but that's how this interface 
> >> is used.
> >
> > Sure. But the deal here is that users of interface know that sometimes it
> > can be unreliable. And in the absence of more reliable mechanism, somewhat
> > less reliable mechanism is fine. 
> >
> >>  
> >> > If a machine is failing, there are high chance it can't deliver you the
> >> > notification. Detecting that failure suing some kind of polling mechanism
> >> > might be more reliable. And it will make even kdump mechanism more
> >> > reliable so that it does not have to run panic notifiers after the crash.
> >> 
> >> I think what your suggesting is that my company should change how it's 
> >> hardware works
> >> and that's not really an option for me. This isn't a simple thing like 
> >> checking over the
> >> network if the machine is down or not, this is way more complex hardware 
> >> design.
> >
> > That means you are ready to live with an unreliable design. There might be
> > cases where notifier does not get run properly and you will not do switch
> > despite the fact that OS has failed. I was just trying to nudge you in
> > a direction which could be more reliable mechanism.
> 
> Sigh I see some deep confusion going on here.
> 
> The panic notifiers are just that panic notifiers.  They have not been
> nor should they be tied to kexec.   If those notifiers force a switch
> over of between machines I fail to see why you would care if it was
> kexec or another panic situation that is forcing that switchover.

Hidehiro isn't fixing the failover situation on my side, he's fixing register
information collection when crash_kexec_post_notifiers is used.

Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Eric W. Biederman
Vivek Goyal  writes:

> On Tue, Jul 14, 2015 at 03:48:33PM +, dwal...@fifo99.com wrote:
>> On Tue, Jul 14, 2015 at 11:40:40AM -0400, Vivek Goyal wrote:
>> > On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote:
>> > > On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote:
>> > > > On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
>> > > > > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
>> > > > > > dwal...@fifo99.com writes:
>> > > > > > 
>> > > > > > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman 
>> > > > > > > wrote:
>> > > > > > >> Hidehiro Kawai  writes:
>> > > > > > >> 
>> > > > > > >> > You can call panic notifiers and kmsg dumpers before kdump by
>> > > > > > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
>> > > > > > >> > However, it doesn't make sense if kdump is not available.  In 
>> > > > > > >> > that
>> > > > > > >> > case, disable "crash_kexec_post_notifiers" boot parameter so 
>> > > > > > >> > that
>> > > > > > >> > you can't change the value of the parameter.
>> > > > > > >> 
>> > > > > > >> Nacked-by: "Eric W. Biederman" 
>> > > > > > >
>> > > > > > > I think it would make sense if he just replaced "kdump" with 
>> > > > > > > "kexec".
>> > > > > > 
>> > > > > > It would be less insane, however it still makes no sense as without
>> > > > > > kexec on panic support crash_kexec is a noop.  So the value of the
>> > > > > > seeting makes no difference.
>> > > > > 
>> > > > > Can you explain more, I don't really understand what you mean. Are 
>> > > > > you suggesting
>> > > > > the whole "crash_kexec_post_notifiers" feature has no value ?
>> > > > 
>> > > > Daniel,
>> > > > 
>> > > > BTW, why are you using crash_kexec_post_notifiers commandline? Why not
>> > > > without it?
>> > > 
>> > > It was explained in the prior thread but to rehash, the notifiers are 
>> > > used to do a switch
>> > > over from the crashed machine to another redundant machine.
>> > 
>> > So why not detect failure using polling or issue notifications from second
>> > kernel.
>> > 
>> > IOW, expecting that a crashed machine will be able to deliver notification
>> > reliably is falwed to begin with, IMHO.
>> 
>> It's flawed to think you can kexec, but you still do it right ? I've not 
>> gotten into
>> the deep details of this switching process, but that's how this interface is 
>> used.
>
> Sure. But the deal here is that users of interface know that sometimes it
> can be unreliable. And in the absence of more reliable mechanism, somewhat
> less reliable mechanism is fine. 
>
>>  
>> > If a machine is failing, there are high chance it can't deliver you the
>> > notification. Detecting that failure suing some kind of polling mechanism
>> > might be more reliable. And it will make even kdump mechanism more
>> > reliable so that it does not have to run panic notifiers after the crash.
>> 
>> I think what your suggesting is that my company should change how it's 
>> hardware works
>> and that's not really an option for me. This isn't a simple thing like 
>> checking over the
>> network if the machine is down or not, this is way more complex hardware 
>> design.
>
> That means you are ready to live with an unreliable design. There might be
> cases where notifier does not get run properly and you will not do switch
> despite the fact that OS has failed. I was just trying to nudge you in
> a direction which could be more reliable mechanism.

Sigh I see some deep confusion going on here.

The panic notifiers are just that panic notifiers.  They have not been
nor should they be tied to kexec.   If those notifiers force a switch
over of between machines I fail to see why you would care if it was
kexec or another panic situation that is forcing that switchover.

Now if you want a reliable design, I strongly recommend as I have been
recommending for the 15 years that magic failover code be placed in
either the new kernel or a stub that preceedes the new kernel.

That gives the greatest reliabilty we know how to engineer, and it lets
you do whatever you need to do.

Especially if it is not desirable for the panic notifiers to run without
the presence of kexec, I very strongly recommend not using them at all
and just writing a stub of code that can run before a new kernel starts.

Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Vivek Goyal
On Tue, Jul 14, 2015 at 03:48:33PM +, dwal...@fifo99.com wrote:
> On Tue, Jul 14, 2015 at 11:40:40AM -0400, Vivek Goyal wrote:
> > On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote:
> > > On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote:
> > > > On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> > > > > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> > > > > > dwal...@fifo99.com writes:
> > > > > > 
> > > > > > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> > > > > > >> Hidehiro Kawai  writes:
> > > > > > >> 
> > > > > > >> > You can call panic notifiers and kmsg dumpers before kdump by
> > > > > > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> > > > > > >> > However, it doesn't make sense if kdump is not available.  In 
> > > > > > >> > that
> > > > > > >> > case, disable "crash_kexec_post_notifiers" boot parameter so 
> > > > > > >> > that
> > > > > > >> > you can't change the value of the parameter.
> > > > > > >> 
> > > > > > >> Nacked-by: "Eric W. Biederman" 
> > > > > > >
> > > > > > > I think it would make sense if he just replaced "kdump" with 
> > > > > > > "kexec".
> > > > > > 
> > > > > > It would be less insane, however it still makes no sense as without
> > > > > > kexec on panic support crash_kexec is a noop.  So the value of the
> > > > > > seeting makes no difference.
> > > > > 
> > > > > Can you explain more, I don't really understand what you mean. Are 
> > > > > you suggesting
> > > > > the whole "crash_kexec_post_notifiers" feature has no value ?
> > > > 
> > > > Daniel,
> > > > 
> > > > BTW, why are you using crash_kexec_post_notifiers commandline? Why not
> > > > without it?
> > > 
> > > It was explained in the prior thread but to rehash, the notifiers are 
> > > used to do a switch
> > > over from the crashed machine to another redundant machine.
> > 
> > So why not detect failure using polling or issue notifications from second
> > kernel.
> > 
> > IOW, expecting that a crashed machine will be able to deliver notification
> > reliably is falwed to begin with, IMHO.
> 
> It's flawed to think you can kexec, but you still do it right ? I've not 
> gotten into
> the deep details of this switching process, but that's how this interface is 
> used.

Sure. But the deal here is that users of interface know that sometimes it
can be unreliable. And in the absence of more reliable mechanism, somewhat
less reliable mechanism is fine. 

>  
> > If a machine is failing, there are high chance it can't deliver you the
> > notification. Detecting that failure suing some kind of polling mechanism
> > might be more reliable. And it will make even kdump mechanism more
> > reliable so that it does not have to run panic notifiers after the crash.
> 
> I think what your suggesting is that my company should change how it's 
> hardware works
> and that's not really an option for me. This isn't a simple thing like 
> checking over the
> network if the machine is down or not, this is way more complex hardware 
> design.

That means you are ready to live with an unreliable design. There might be
cases where notifier does not get run properly and you will not do switch
despite the fact that OS has failed. I was just trying to nudge you in
a direction which could be more reliable mechanism.

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH net-next] ibmveth: add support for TSO6

2015-07-14 Thread Thomas Falcon
This patch adds support for a new method of signalling the firmware
that TSO packets are being sent. The new method removes the need to
alter the ip and tcp checksums and allows TSO6 support.

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmveth.c |  145 +--
 drivers/net/ethernet/ibm/ibmveth.h |   18 -
 2 files changed, 135 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmveth.c 
b/drivers/net/ethernet/ibm/ibmveth.c
index 29bbb62..d4b92cd 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -79,6 +79,11 @@ static unsigned int rx_flush __read_mostly = 0;
 module_param(rx_flush, uint, 0644);
 MODULE_PARM_DESC(rx_flush, "Flush receive buffers before use");
 
+static bool old_large_send __read_mostly;
+module_param(old_large_send, bool, S_IRUGO);
+MODULE_PARM_DESC(old_large_send,
+   "Use old large send method on firmware that supports the new method");
+
 struct ibmveth_stat {
char name[ETH_GSTRING_LEN];
int offset;
@@ -101,7 +106,8 @@ struct ibmveth_stat ibmveth_stats[] = {
{ "fw_enabled_ipv4_csum", IBMVETH_STAT_OFF(fw_ipv4_csum_support) },
{ "fw_enabled_ipv6_csum", IBMVETH_STAT_OFF(fw_ipv6_csum_support) },
{ "tx_large_packets", IBMVETH_STAT_OFF(tx_large_packets) },
-   { "rx_large_packets", IBMVETH_STAT_OFF(rx_large_packets) }
+   { "rx_large_packets", IBMVETH_STAT_OFF(rx_large_packets) },
+   { "fw_enabled_large_send", IBMVETH_STAT_OFF(fw_large_send_support) }
 };
 
 /* simple methods of getting data from the current rxq entry */
@@ -848,25 +854,91 @@ static int ibmveth_set_csum_offload(struct net_device 
*dev, u32 data)
return rc1 ? rc1 : rc2;
 }
 
+static int ibmveth_set_tso(struct net_device *dev, u32 data)
+{
+   struct ibmveth_adapter *adapter = netdev_priv(dev);
+   unsigned long set_attr, clr_attr, ret_attr;
+   long ret1, ret2;
+   int rc1 = 0, rc2 = 0;
+   int restart = 0;
+
+   if (netif_running(dev)) {
+   restart = 1;
+   adapter->pool_config = 1;
+   ibmveth_close(dev);
+   adapter->pool_config = 0;
+   }
+
+   set_attr = 0;
+   clr_attr = 0;
+
+   if (data)
+   set_attr = IBMVETH_ILLAN_LRG_SR_ENABLED;
+   else
+   clr_attr = IBMVETH_ILLAN_LRG_SR_ENABLED;
+
+   ret1 = h_illan_attributes(adapter->vdev->unit_address, 0, 0, &ret_attr);
+
+   if (ret1 == H_SUCCESS && (ret_attr & IBMVETH_ILLAN_LRG_SND_SUPPORT) &&
+   !old_large_send) {
+   ret2 = h_illan_attributes(adapter->vdev->unit_address, clr_attr,
+ set_attr, &ret_attr);
+
+   if (ret2 != H_SUCCESS) {
+   netdev_err(dev, "unable to change tso settings. %d 
rc=%ld\n",
+  data, ret2);
+
+   h_illan_attributes(adapter->vdev->unit_address,
+  set_attr, clr_attr, &ret_attr);
+
+   if (data == 1)
+   dev->features &= ~(NETIF_F_TSO | NETIF_F_TSO6);
+   rc1 = -EIO;
+
+   } else {
+   adapter->fw_large_send_support = data;
+   adapter->large_send = data;
+   }
+   } else {
+   /* Older firmware version of large send offload does not
+* support tcp6/ipv6
+*/
+   if (data == 1) {
+   dev->features &= ~NETIF_F_TSO6;
+   netdev_info(dev, "TSO feature requires all partitions 
to have updated driver");
+   }
+   adapter->large_send = data;
+   }
+
+   if (restart)
+   rc2 = ibmveth_open(dev);
+
+   return rc1 ? rc1 : rc2;
+}
+
 static int ibmveth_set_features(struct net_device *dev,
netdev_features_t features)
 {
struct ibmveth_adapter *adapter = netdev_priv(dev);
int rx_csum = !!(features & NETIF_F_RXCSUM);
-   int rc;
-   netdev_features_t changed = features ^ dev->features;
-
-   if (features & NETIF_F_TSO & changed)
-   netdev_info(dev, "TSO feature requires all partitions to have 
updated driver");
+   int large_send = !!(features & (NETIF_F_TSO | NETIF_F_TSO6));
+   int rc1 = 0, rc2 = 0;
 
-   if (rx_csum == adapter->rx_csum)
-   return 0;
+   if (rx_csum != adapter->rx_csum) {
+   rc1 = ibmveth_set_csum_offload(dev, rx_csum);
+   if (rc1 && !adapter->rx_csum)
+   dev->features =
+   features & ~(NETIF_F_ALL_CSUM | NETIF_F_RXCSUM);
+   }
 
-   rc = ibmveth_set_csum_offload(dev, rx_csum);
-   if (rc && !adapter->rx_csum)
-   dev->features = features & ~(NETIF_F_ALL_CSUM | NETIF_F_RXCSUM);
+   if (large_send != adapter->large_sen

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread dwalker
On Tue, Jul 14, 2015 at 11:40:40AM -0400, Vivek Goyal wrote:
> On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote:
> > On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote:
> > > On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> > > > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> > > > > dwal...@fifo99.com writes:
> > > > > 
> > > > > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> > > > > >> Hidehiro Kawai  writes:
> > > > > >> 
> > > > > >> > You can call panic notifiers and kmsg dumpers before kdump by
> > > > > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> > > > > >> > However, it doesn't make sense if kdump is not available.  In 
> > > > > >> > that
> > > > > >> > case, disable "crash_kexec_post_notifiers" boot parameter so that
> > > > > >> > you can't change the value of the parameter.
> > > > > >> 
> > > > > >> Nacked-by: "Eric W. Biederman" 
> > > > > >
> > > > > > I think it would make sense if he just replaced "kdump" with 
> > > > > > "kexec".
> > > > > 
> > > > > It would be less insane, however it still makes no sense as without
> > > > > kexec on panic support crash_kexec is a noop.  So the value of the
> > > > > seeting makes no difference.
> > > > 
> > > > Can you explain more, I don't really understand what you mean. Are you 
> > > > suggesting
> > > > the whole "crash_kexec_post_notifiers" feature has no value ?
> > > 
> > > Daniel,
> > > 
> > > BTW, why are you using crash_kexec_post_notifiers commandline? Why not
> > > without it?
> > 
> > It was explained in the prior thread but to rehash, the notifiers are used 
> > to do a switch
> > over from the crashed machine to another redundant machine.
> 
> So why not detect failure using polling or issue notifications from second
> kernel.
> 
> IOW, expecting that a crashed machine will be able to deliver notification
> reliably is falwed to begin with, IMHO.

It's flawed to think you can kexec, but you still do it right ? I've not gotten 
into
the deep details of this switching process, but that's how this interface is 
used.
 
> If a machine is failing, there are high chance it can't deliver you the
> notification. Detecting that failure suing some kind of polling mechanism
> might be more reliable. And it will make even kdump mechanism more
> reliable so that it does not have to run panic notifiers after the crash.

I think what your suggesting is that my company should change how it's hardware 
works
and that's not really an option for me. This isn't a simple thing like checking 
over the
network if the machine is down or not, this is way more complex hardware design.

Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Vivek Goyal
On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote:
> On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote:
> > On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> > > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> > > > dwal...@fifo99.com writes:
> > > > 
> > > > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> > > > >> Hidehiro Kawai  writes:
> > > > >> 
> > > > >> > You can call panic notifiers and kmsg dumpers before kdump by
> > > > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> > > > >> > However, it doesn't make sense if kdump is not available.  In that
> > > > >> > case, disable "crash_kexec_post_notifiers" boot parameter so that
> > > > >> > you can't change the value of the parameter.
> > > > >> 
> > > > >> Nacked-by: "Eric W. Biederman" 
> > > > >
> > > > > I think it would make sense if he just replaced "kdump" with "kexec".
> > > > 
> > > > It would be less insane, however it still makes no sense as without
> > > > kexec on panic support crash_kexec is a noop.  So the value of the
> > > > seeting makes no difference.
> > > 
> > > Can you explain more, I don't really understand what you mean. Are you 
> > > suggesting
> > > the whole "crash_kexec_post_notifiers" feature has no value ?
> > 
> > Daniel,
> > 
> > BTW, why are you using crash_kexec_post_notifiers commandline? Why not
> > without it?
> 
> It was explained in the prior thread but to rehash, the notifiers are used to 
> do a switch
> over from the crashed machine to another redundant machine.

So why not detect failure using polling or issue notifications from second
kernel.

IOW, expecting that a crashed machine will be able to deliver notification
reliably is falwed to begin with, IMHO.

If a machine is failing, there are high chance it can't deliver you the
notification. Detecting that failure suing some kind of polling mechanism
might be more reliable. And it will make even kdump mechanism more
reliable so that it does not have to run panic notifiers after the crash.

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread dwalker
On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote:
> On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> > On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> > > dwal...@fifo99.com writes:
> > > 
> > > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> > > >> Hidehiro Kawai  writes:
> > > >> 
> > > >> > You can call panic notifiers and kmsg dumpers before kdump by
> > > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> > > >> > However, it doesn't make sense if kdump is not available.  In that
> > > >> > case, disable "crash_kexec_post_notifiers" boot parameter so that
> > > >> > you can't change the value of the parameter.
> > > >> 
> > > >> Nacked-by: "Eric W. Biederman" 
> > > >
> > > > I think it would make sense if he just replaced "kdump" with "kexec".
> > > 
> > > It would be less insane, however it still makes no sense as without
> > > kexec on panic support crash_kexec is a noop.  So the value of the
> > > seeting makes no difference.
> > 
> > Can you explain more, I don't really understand what you mean. Are you 
> > suggesting
> > the whole "crash_kexec_post_notifiers" feature has no value ?
> 
> Daniel,
> 
> BTW, why are you using crash_kexec_post_notifiers commandline? Why not
> without it?

It was explained in the prior thread but to rehash, the notifiers are used to 
do a switch
over from the crashed machine to another redundant machine.

Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3] powerpc/pseries: Limit EPOW reset event warnings

2015-07-14 Thread Kamalesh Babulal
We print the respective warning after parsing EPOW interrupts,
prompting user to take action depending upon the severity of the
event.

Some times EPOW rest event warning, such as below could flood
kernel log, over a period of time. Limit these warnings by use of
epow_state flag, which is initialized to false and when any event
gets reported, the flag set to true once an event gets acknowledged
by a reset.

The reset action is guarded by bool flag (set only if there was event
reported previously) and ignore multiple resets, without real EPOW
event. Also, merge adjacent pr_err/pr_emerg into single one to reduce
the number of lines printed per warning.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

Suggested-by: Vipin K Parashar 
Cc: Anshuman Khandual 
Cc: Anton Blanchard 
Cc: Michael Ellerman 
Signed-off-by: Kamalesh Babulal 
---
v3 Changes:
  - Limit warning printed by EPOW RESET event, by guarding it with bool flag.
Instead of rate limiting all the EPOW events.

v2 Changes:
  - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
warnings, based on Michael's comments.

 arch/powerpc/platforms/pseries/ras.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..b30396a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,9 @@ static int ras_check_exception_token;
 #define EPOW_SENSOR_TOKEN  9
 #define EPOW_SENSOR_INDEX  0
 
+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
+
 static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
 static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
 
@@ -145,21 +148,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err("Non critical power or cooling issue cleared");
+   if (epow_state) {
+   pr_err("Non critical power or cooling issue cleared");
+   epow_state = false;
+   }
break;
 
case EPOW_WARN_COOLING:
-   pr_err("Non critical cooling issue reported by firmware");
-   pr_err("Check RTAS error log for details");
+   pr_err("Non critical cooling issue reported by firmware, "
+  "Check RTAS error log for details");
+   epow_state = true;
break;
 
case EPOW_WARN_POWER:
-   pr_err("Non critical power issue reported by firmware");
-   pr_err("Check RTAS error log for details");
+   pr_err("Non critical power issue reported by firmware, "
+  "Check RTAS error log for details");
+   epow_state = true;
break;
 
case EPOW_SYSTEM_SHUTDOWN:
handle_system_shutdown(epow_log->event_modifier);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_HALT:
@@ -169,9 +178,8 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
-   pr_emerg("Critical power/cooling issue reported by firmware");
-   pr_emerg("Check RTAS error log for details");
-   pr_emerg("Immediate power off");
+   pr_emerg("Critical power/cooling issue reported by firmware, "
+"Check RTAS error log for details. Immediate power 
off.");
emergency_sync();
kernel_power_off();
break;
@@ -179,6 +187,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
default:
pr_err("Unknown power/cooling event (action code %d)",
action_code);
+   epow_state = true;
}
 }
 
-- 
2.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxpp

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Vivek Goyal
On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> > dwal...@fifo99.com writes:
> > 
> > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> > >> Hidehiro Kawai  writes:
> > >> 
> > >> > You can call panic notifiers and kmsg dumpers before kdump by
> > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> > >> > However, it doesn't make sense if kdump is not available.  In that
> > >> > case, disable "crash_kexec_post_notifiers" boot parameter so that
> > >> > you can't change the value of the parameter.
> > >> 
> > >> Nacked-by: "Eric W. Biederman" 
> > >
> > > I think it would make sense if he just replaced "kdump" with "kexec".
> > 
> > It would be less insane, however it still makes no sense as without
> > kexec on panic support crash_kexec is a noop.  So the value of the
> > seeting makes no difference.
> 
> Can you explain more, I don't really understand what you mean. Are you 
> suggesting
> the whole "crash_kexec_post_notifiers" feature has no value ?

Daniel,

BTW, why are you using crash_kexec_post_notifiers commandline? Why not
without it?

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option

2015-07-14 Thread Vivek Goyal
On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
> This patch fixes problems reported by Daniel Walker
> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
> commits 5375b70 and f45d85f.
> 
> If "crash_kexec_post_notifiers" boot option is specified,
> other cpus are stopped by smp_send_stop() before entering
> crash_kexec(), while usually machine_crash_shutdown() called by
> crash_kexec() does that.  This behavior change leads two problems.
> 
>  Problem 1:
>  Some function in the crash_kexec() path depend on other cpus being
>  still online.  If other cpus have been offlined already, they
>  doesn't work properly.
> 
>   Example:
>panic()
> crash_kexec()
>  machine_crash_shutdown()
>   octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>  machine_kexec()
> 
>  Problem 2:
>  Most of architectures stop other cpus in the machine_crash_shutdown()
>  path and save register information at the same time.  However, if
>  smp_send_stop() is called before that, we can't save the register
>  information.
> 
> To solve these problems, this patch changes the timing of calling
> the callbacks instead of changing the timing of crash_kexec() if
> crash_kexec_post_notifiers boot option is specified.
> 
>  Before:
>   if (!crash_kexec_post_notifiers)
>   crash_kexec()
> 
>   smp_send_stop()
>   atomic_notifier_call_chain()
>   kmsg_dump()
> 
>   if (crash_kexec_post_notifiers)
>   crash_kexec()
> 
>  After:
>   crash_kexec()
>   machine_crash_shutdown()
>   if (crash_kexec_post_notifiers) {
>   atomic_notifier_call_chain()
>   kmsg_dump()
>   }
>   machine_kexec()
> 
>   smp_send_stop()
>   if (!crash_kexec_post_notifiers) {
>   atomic_notifier_call_chain()
>   kmsg_dump()
>   }
> 

I think this new code flow looks bad. Now we are calling kmsg_dump()
and atomic_notifier_call_chain() from inside the crash_kexec() as well
as from inside panic(). This is bad.

So basic problem seems to be that cpus need to be stopped once (with
or without panic notifiers. So why don't we look into desiginig a 
function which stops cpus, saves register states first and then does
rest of the processing.

Something like.

stop_cpus_save_register_state;

if (!crash_kexec_post_notifiers)
crash_kexec()

atomic_notifier_call_chain()
kmsg_dump()

Here crash_kexec() will have to be modified and it will assume that cpus
have already been stopped and register states have already been saved.

IOW, is there a reason that we can't get rid of smp_send_stop() and
use the mechanism crash_kexec() is using to stop cpus after panic()?

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread Vivek Goyal
On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote:
> On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> > dwal...@fifo99.com writes:
> > 
> > > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> > >> Hidehiro Kawai  writes:
> > >> 
> > >> > You can call panic notifiers and kmsg dumpers before kdump by
> > >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> > >> > However, it doesn't make sense if kdump is not available.  In that
> > >> > case, disable "crash_kexec_post_notifiers" boot parameter so that
> > >> > you can't change the value of the parameter.
> > >> 
> > >> Nacked-by: "Eric W. Biederman" 
> > >
> > > I think it would make sense if he just replaced "kdump" with "kexec".
> > 
> > It would be less insane, however it still makes no sense as without
> > kexec on panic support crash_kexec is a noop.  So the value of the
> > seeting makes no difference.
> 
> Can you explain more, I don't really understand what you mean. Are you 
> suggesting
> the whole "crash_kexec_post_notifiers" feature has no value ?

If CONFIG_KEXEC=n, then crash_kexec() is a nop. So it does not matter
whether crash_kexec() is called before panic notifiers or after.

IOW, what do you gain by disabling crash_kexec_post_notifiers, in 
case of CONFIG_KEXEC=n?

Thanks
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

2015-07-14 Thread dwalker
On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote:
> dwal...@fifo99.com writes:
> 
> > On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
> >> Hidehiro Kawai  writes:
> >> 
> >> > You can call panic notifiers and kmsg dumpers before kdump by
> >> > specifying "crash_kexec_post_notifiers" as a boot parameter.
> >> > However, it doesn't make sense if kdump is not available.  In that
> >> > case, disable "crash_kexec_post_notifiers" boot parameter so that
> >> > you can't change the value of the parameter.
> >> 
> >> Nacked-by: "Eric W. Biederman" 
> >
> > I think it would make sense if he just replaced "kdump" with "kexec".
> 
> It would be less insane, however it still makes no sense as without
> kexec on panic support crash_kexec is a noop.  So the value of the
> seeting makes no difference.

Can you explain more, I don't really understand what you mean. Are you 
suggesting
the whole "crash_kexec_post_notifiers" feature has no value ?

Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()

2015-07-14 Thread Benjamin Herrenschmidt
On Tue, 2015-07-14 at 17:58 +1000, Finn Thain wrote:
> Make use of arch_nvram_ops in device drivers so that the nvram_* function 
> exports can be removed.
> 
> Since they are no longer global symbols, rename the PPC32 nvram_* 
> functions appropriately.
> 
> Add the missing CONFIG_NVRAM test to imsttfb to avoid a build failure.
> 
> Add a CONFIG_PPC32 test to matroxfb because PPC64 doesn't implement the 
> read_byte() method.

This is a bit fishy in a way because some of that nvram stuff is really
about powermac/apple nvram offsets, ie, "XPRAM". Maybe we
should have a dedicated accessor for "mac_xpram" and NULL-check it
rather than using ifdef's ?

> Signed-off-by: Finn Thain 
> 
> ---
> 
> Changed since v4:
> - Added CONFIG_PPC32 test to matroxfb.
> 
> ---
>  arch/powerpc/kernel/setup_32.c |8 
>  drivers/char/generic_nvram.c   |4 ++--
>  drivers/video/fbdev/controlfb.c|4 ++--
>  drivers/video/fbdev/imsttfb.c  |7 +++
>  drivers/video/fbdev/matrox/matroxfb_base.c |4 ++--
>  drivers/video/fbdev/platinumfb.c   |4 ++--
>  drivers/video/fbdev/valkyriefb.c   |4 ++--
>  7 files changed, 17 insertions(+), 18 deletions(-)
> 
> Index: linux/arch/powerpc/kernel/setup_32.c
> ===
> --- linux.orig/arch/powerpc/kernel/setup_32.c 2015-07-13 21:33:01.0 
> +1000
> +++ linux/arch/powerpc/kernel/setup_32.c  2015-07-13 21:33:02.0 
> +1000
> @@ -170,20 +170,18 @@ __setup("l3cr=", ppc_setup_l3cr);
>  
>  #ifdef CONFIG_GENERIC_NVRAM
>  
> -unsigned char nvram_read_byte(int addr)
> +static unsigned char ppc_nvram_read_byte(int addr)
>  {
>   if (ppc_md.nvram_read_val)
>   return ppc_md.nvram_read_val(addr);
>   return 0xff;
>  }
> -EXPORT_SYMBOL(nvram_read_byte);
>  
> -void nvram_write_byte(unsigned char val, int addr)
> +static void ppc_nvram_write_byte(unsigned char val, int addr)
>  {
>   if (ppc_md.nvram_write_val)
>   ppc_md.nvram_write_val(addr, val);
>  }
> -EXPORT_SYMBOL(nvram_write_byte);
>  
>  static ssize_t ppc_nvram_get_size(void)
>  {
> @@ -200,6 +198,8 @@ static long ppc_nvram_sync(void)
>  }
>  
>  const struct nvram_ops arch_nvram_ops = {
> + .read_byte  = ppc_nvram_read_byte,
> + .write_byte = ppc_nvram_write_byte,
>   .get_size   = ppc_nvram_get_size,
>   .sync   = ppc_nvram_sync,
>  };
> Index: linux/drivers/char/generic_nvram.c
> ===
> --- linux.orig/drivers/char/generic_nvram.c   2015-07-13 21:33:01.0 
> +1000
> +++ linux/drivers/char/generic_nvram.c2015-07-13 21:33:02.0 
> +1000
> @@ -64,7 +64,7 @@ static ssize_t read_nvram(struct file *f
>   if (*ppos >= nvram_len)
>   return 0;
>   for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
> - if (__put_user(nvram_read_byte(i), p))
> + if (__put_user(arch_nvram_ops.read_byte(i), p))
>   return -EFAULT;
>   *ppos = i;
>   return p - buf;
> @@ -84,7 +84,7 @@ static ssize_t write_nvram(struct file *
>   for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
>   if (__get_user(c, p))
>   return -EFAULT;
> - nvram_write_byte(c, i);
> + arch_nvram_ops.write_byte(c, i);
>   }
>   *ppos = i;
>   return p - buf;
> Index: linux/drivers/video/fbdev/controlfb.c
> ===
> --- linux.orig/drivers/video/fbdev/controlfb.c2015-07-13 
> 21:32:43.0 +1000
> +++ linux/drivers/video/fbdev/controlfb.c 2015-07-13 21:33:02.0 
> +1000
> @@ -415,7 +415,7 @@ static int __init init_control(struct fb
>   /* Try to pick a video mode out of NVRAM if we have one. */
>  #ifdef CONFIG_NVRAM
>   if (default_cmode == CMODE_NVRAM) {
> - cmode = nvram_read_byte(NV_CMODE);
> + cmode = arch_nvram_ops.read_byte(NV_CMODE);
>   if(cmode < CMODE_8 || cmode > CMODE_32)
>   cmode = CMODE_8;
>   } else
> @@ -423,7 +423,7 @@ static int __init init_control(struct fb
>   cmode=default_cmode;
>  #ifdef CONFIG_NVRAM
>   if (default_vmode == VMODE_NVRAM) {
> - vmode = nvram_read_byte(NV_VMODE);
> + vmode = arch_nvram_ops.read_byte(NV_VMODE);
>   if (vmode < 1 || vmode > VMODE_MAX ||
>   control_mac_modes[vmode - 1].m[full] < cmode) {
>   sense = read_control_sense(p);
> Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
> ===
> --- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-13 
> 21:32:57.0 +1000
> +++ linux/drivers/video/fbdev/matrox/matroxfb_base.c  2015-07-13 
> 21:33:0

Re: [PATCH v2 48/48] usb: gadget: epautoconf: cleanup dead code

2015-07-14 Thread Sergei Shtylyov

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


Function find_ep() is no longer needed here, so we can remove it.
We also don't use anything from gadget_chips.h header any longer.



Signed-off-by: Robert Baldyga 
---
  drivers/usb/gadget/epautoconf.c | 14 --
  1 file changed, 14 deletions(-)



diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index e9a8682..9a80925 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -20,20 +20,6 @@
  #include 
  #include 

-#include "gadget_chips.h"
-
-static struct usb_ep *
-find_ep (struct usb_gadget *gadget, const char *name)
-{
-   struct usb_ep   *ep;
-
-   list_for_each_entry (ep, &gadget->ep_list, ep_list) {
-   if (0 == strcmp (ep->name, name))
-   return ep;
-   }
-   return NULL;
-}
-


   I don't think duplicating the function in each driver that needs it is 
better than turniong this function into public.


WBR, Sergei

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 45/48] usb: gadget: net2280: add net2280_match_ep() function

2015-07-14 Thread Sergei Shtylyov

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.



Signed-off-by: Robert Baldyga 


[...]

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 0295cf7..4933321 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1533,6 +1533,49 @@ static int net2280_pullup(struct usb_gadget *_gadget, 
int is_on)
return 0;
  }

+static struct usb_ep *net2280_find_ep(struct usb_gadget *_gadget,
+   const char *name)


   Shouldn't this be a generic function as before?


+{
+   struct usb_ep *ep;
+
+   list_for_each_entry(ep, &_gadget->ep_list, ep_list) {
+   if (0 == strcmp(ep->name, name))


   Please make 0 the 2nd operand to ==.


+   return ep;
+   }
+
+   return NULL;
+}

[...]

WBR, Sergei

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 47/48] usb: musb: gadget: add musb_match_ep() function

2015-07-14 Thread Sergei Shtylyov

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.



Signed-off-by: Robert Baldyga 


[...]

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 043248a..5f1eb35 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1684,6 +1684,49 @@ static int musb_gadget_pullup(struct usb_gadget *gadget, 
int is_on)
return 0;
  }

+#ifdef CONFIG_BLACKFIN
+static struct usb_ep *musb_find_ep(struct usb_gadget *g,
+   const char *name)
+{
+   struct usb_ep *ep;
+
+   list_for_each_entry(ep, &g->ep_list, ep_list) {
+   if (0 == strcmp(ep->name, name))


   Please make the immediate value the 2nd operand of ==.


+   return ep;
+   }
+
+   return NULL;
+}
+
+static struct usb_ep *match_match_ep(struct usb_gadget *g,
+   struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp)
+{
+   struct usb_ep *ep = NULL;
+   u8 type = usb_endpoint_type(desc);
+
+   if ((USB_ENDPOINT_XFER_BULK == type) ||
+   (USB_ENDPOINT_XFER_ISOC == type)) {


   Likewise.


+   if (USB_DIR_IN & desc->bEndpointAddress)


   The same about &.


+   ep = musb_find_ep(g, "ep5in");
+   else
+   ep = musb_find_ep(g, "ep6out");
+   } else if (USB_ENDPOINT_XFER_INT == type) {


   Likewise.


+   if (USB_DIR_IN & desc->bEndpointAddress)
+   ep = musb_find_ep(g, "ep1in");
+   else
+   ep = musb_find_ep(g, "ep2out");
+   }


   This string of *if* statements is asking to be *switch* instead.

[...]

WBR, Sergei

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 42/48] usb: gadget: epautoconf: use 'ep_match' gadget callback

2015-07-14 Thread Sergei Shtylyov

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


If gadget has set 'ep_match' callback we prefer to call it first to allow
UDC driver to find the best matching endpoint basing on chip-specific "best
usage" knowledge.



Signed-off-by: Robert Baldyga 
---
  drivers/usb/gadget/epautoconf.c | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index ee0d4e6..92a1a4c 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -165,6 +165,12 @@ struct usb_ep *usb_ep_autoconfig_ss(

type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;

+   if (gadget->ops->match_ep) {
+   ep = gadget->ops->match_ep(gadget, desc, ep_comp);
+   if (ep)
+   goto found_ep;
+   }
+


   I think this patch should be merged with the previous one.

[...]

WBR, Sergei

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] spi: mpc512x-psc: add support for Freescale MPC5125

2015-07-14 Thread Mark Brown
On Tue, Jul 14, 2015 at 11:19:56AM +0200, Uwe Kleine-König wrote:

>  static const struct of_device_id mpc512x_psc_spi_of_match[] = {
> - { .compatible = "fsl,mpc5121-psc-spi", },
> + { .compatible = "fsl,mpc5121-psc-spi", .data = (void *)TYPE_MPC5121 },
> + { .compatible = "fsl,mpc5125-psc-spi", .data = (void *)TYPE_MPC5125 },
>   {},

The code seems fine but this should update the binding document to
include the new compatible string.


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 48/48] usb: gadget: epautoconf: cleanup dead code

2015-07-14 Thread Robert Baldyga
Function find_ep() is no longer needed here, so we can remove it.
We also don't use anything from gadget_chips.h header any longer.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index e9a8682..9a80925 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -20,20 +20,6 @@
 #include 
 #include 
 
-#include "gadget_chips.h"
-
-static struct usb_ep *
-find_ep (struct usb_gadget *gadget, const char *name)
-{
-   struct usb_ep   *ep;
-
-   list_for_each_entry (ep, &gadget->ep_list, ep_list) {
-   if (0 == strcmp (ep->name, name))
-   return ep;
-   }
-   return NULL;
-}
-
 /**
  * usb_ep_autoconfig_ss() - choose an endpoint matching the ep
  * descriptor and ep companion descriptor
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 45/48] usb: gadget: net2280: add net2280_match_ep() function

2015-07-14 Thread Robert Baldyga
Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c  | 23 +
 drivers/usb/gadget/udc/net2280.c | 44 
 2 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 7c43b7c..3ac92b4 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -98,28 +98,7 @@ struct usb_ep *usb_ep_autoconfig_ss(
/* First, apply chip-specific "best usage" knowledge.
 * This might make a good usb_gadget_ops hook ...
 */
-   if (gadget_is_net2280(gadget)) {
-   char name[8];
-
-   if (type == USB_ENDPOINT_XFER_INT) {
-   /* ep-e, ep-f are PIO with only 64 byte fifos */
-   ep = find_ep(gadget, "ep-e");
-   if (ep && usb_gadget_ep_match_desc(gadget,
-   ep, desc, ep_comp))
-   goto found_ep;
-   ep = find_ep(gadget, "ep-f");
-   if (ep && usb_gadget_ep_match_desc(gadget,
-   ep, desc, ep_comp))
-   goto found_ep;
-   }
-
-   /* USB3380: use same address for usb and hardware endpoints */
-   snprintf(name, sizeof(name), "ep%d%s", usb_endpoint_num(desc),
-   usb_endpoint_dir_in(desc) ? "in" : "out");
-   ep = find_ep(gadget, name);
-   if (ep && usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
-   goto found_ep;
-   } else if (gadget_is_goku (gadget)) {
+   if (gadget_is_goku (gadget)) {
if (USB_ENDPOINT_XFER_INT == type) {
/* single buffering is enough */
ep = find_ep(gadget, "ep3-bulk");
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 0295cf7..4933321 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1533,6 +1533,49 @@ static int net2280_pullup(struct usb_gadget *_gadget, 
int is_on)
return 0;
 }
 
+static struct usb_ep *net2280_find_ep(struct usb_gadget *_gadget,
+   const char *name)
+{
+   struct usb_ep *ep;
+
+   list_for_each_entry(ep, &_gadget->ep_list, ep_list) {
+   if (0 == strcmp(ep->name, name))
+   return ep;
+   }
+
+   return NULL;
+}
+
+static struct usb_ep *net2280_match_ep(struct usb_gadget *_gadget,
+   struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp)
+{
+   char name[8];
+   struct usb_ep *ep;
+   u8 type;
+
+   type = usb_endpoint_type(desc);
+
+   if (type == USB_ENDPOINT_XFER_INT) {
+   /* ep-e, ep-f are PIO with only 64 byte fifos */
+   ep = net2280_find_ep(_gadget, "ep-e");
+   if (ep && usb_gadget_ep_match_desc(_gadget, ep, desc, ep_comp))
+   return ep;
+   ep = net2280_find_ep(_gadget, "ep-f");
+   if (ep && usb_gadget_ep_match_desc(_gadget, ep, desc, ep_comp))
+   return ep;
+   }
+
+   /* USB3380: use same address for usb and hardware endpoints */
+   snprintf(name, sizeof(name), "ep%d%s", usb_endpoint_num(desc),
+   usb_endpoint_dir_in(desc) ? "in" : "out");
+   ep = net2280_find_ep(_gadget, name);
+   if (ep && usb_gadget_ep_match_desc(_gadget, ep, desc, ep_comp))
+   return ep;
+
+   return NULL;
+}
+
 static int net2280_start(struct usb_gadget *_gadget,
struct usb_gadget_driver *driver);
 static int net2280_stop(struct usb_gadget *_gadget);
@@ -1544,6 +1587,7 @@ static const struct usb_gadget_ops net2280_ops = {
.pullup = net2280_pullup,
.udc_start  = net2280_start,
.udc_stop   = net2280_stop,
+   .match_ep   = net2280_match_ep,
 };
 
 /*-*/
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 44/48] usb: gadget: epautoconf: remove ep_matches() function

2015-07-14 Thread Robert Baldyga
As now we have usb_gadget_ep_match_desc() function which does exactly the same
thing as ep_matches(), we can remove the second one and replace all of its calls
with usb_gadget_ep_match_desc() calls.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 95 +
 1 file changed, 11 insertions(+), 84 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 92a1a4c..7c43b7c 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -22,82 +22,6 @@
 
 #include "gadget_chips.h"
 
-static int
-ep_matches (
-   struct usb_gadget   *gadget,
-   struct usb_ep   *ep,
-   struct usb_endpoint_descriptor  *desc,
-   struct usb_ss_ep_comp_descriptor *ep_comp
-)
-{
-   u8  type;
-   u16 max;
-   int num_req_streams = 0;
-
-   /* endpoint already claimed? */
-   if (ep->claimed)
-   return 0;
-
-   type = usb_endpoint_type(desc);
-   max = 0x7ff & usb_endpoint_maxp(desc);
-
-   if (usb_endpoint_dir_in(desc) && !ep->caps.dir_in)
-   return 0;
-   else if (!ep->caps.dir_out)
-   return 0;
-
-   if (max > ep->maxpacket_limit)
-   return 0;
-
-   /* "high bandwidth" works only at high speed */
-   if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
-   return 0;
-
-   switch (type) {
-   case USB_ENDPOINT_XFER_CONTROL:
-   /* only support ep0 for portable CONTROL traffic */
-   return 0;
-   case USB_ENDPOINT_XFER_ISOC:
-   if (!ep->caps.type_iso)
-   return 0;
-   /* ISO:  limit 1023 bytes full speed,
-* 1024 high/super speed
-*/
-   if (!gadget_is_dualspeed(gadget) && max > 1023)
-   return 0;
-   break;
-   case USB_ENDPOINT_XFER_BULK:
-   if (!ep->caps.type_bulk)
-   return 0;
-   if (ep_comp && gadget_is_superspeed(gadget)) {
-   /* Get the number of required streams from the
-* EP companion descriptor and see if the EP
-* matches it
-*/
-   num_req_streams = ep_comp->bmAttributes & 0x1f;
-   if (num_req_streams > ep->max_streams)
-   return 0;
-   }
-   break;
-   case USB_ENDPOINT_XFER_INT:
-   /* Bulk endpoints handle interrupt transfers,
-* except the toggle-quirky iso-synch kind
-*/
-   if (!ep->caps.type_int && !ep->caps.type_bulk)
-   return 0;
-   /* INT:  limit 64 bytes full speed,
-* 1024 high/super speed
-*/
-   if (!gadget_is_dualspeed(gadget) && max > 64)
-   return 0;
-   break;
-   }
-
-   /* MATCH!! */
-
-   return 1;
-}
-
 static struct usb_ep *
 find_ep (struct usb_gadget *gadget, const char *name)
 {
@@ -180,10 +104,12 @@ struct usb_ep *usb_ep_autoconfig_ss(
if (type == USB_ENDPOINT_XFER_INT) {
/* ep-e, ep-f are PIO with only 64 byte fifos */
ep = find_ep(gadget, "ep-e");
-   if (ep && ep_matches(gadget, ep, desc, ep_comp))
+   if (ep && usb_gadget_ep_match_desc(gadget,
+   ep, desc, ep_comp))
goto found_ep;
ep = find_ep(gadget, "ep-f");
-   if (ep && ep_matches(gadget, ep, desc, ep_comp))
+   if (ep && usb_gadget_ep_match_desc(gadget,
+   ep, desc, ep_comp))
goto found_ep;
}
 
@@ -191,20 +117,21 @@ struct usb_ep *usb_ep_autoconfig_ss(
snprintf(name, sizeof(name), "ep%d%s", usb_endpoint_num(desc),
usb_endpoint_dir_in(desc) ? "in" : "out");
ep = find_ep(gadget, name);
-   if (ep && ep_matches(gadget, ep, desc, ep_comp))
+   if (ep && usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
goto found_ep;
} else if (gadget_is_goku (gadget)) {
if (USB_ENDPOINT_XFER_INT == type) {
/* single buffering is enough */
ep = find_ep(gadget, "ep3-bulk");
-   if (ep && ep_matches(gadget, ep, desc, ep_comp))
+   if (ep && usb_gadget_ep_match_desc(gadget,
+   ep, desc, ep_comp))
goto found_ep;
} else if (USB_ENDPOINT_XFER_BUL

[PATCH v2 47/48] usb: musb: gadget: add musb_match_ep() function

2015-07-14 Thread Robert Baldyga
Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 23 -
 drivers/usb/musb/musb_gadget.c  | 44 +
 2 files changed, 44 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 038b21d..e9a8682 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -95,29 +95,6 @@ struct usb_ep *usb_ep_autoconfig_ss(
goto found_ep;
}
 
-   /* First, apply chip-specific "best usage" knowledge.
-* This might make a good usb_gadget_ops hook ...
-*/
-#ifdef CONFIG_BLACKFIN
-   if (gadget_is_musbhdrc(gadget)) {
-   if ((USB_ENDPOINT_XFER_BULK == type) ||
-   (USB_ENDPOINT_XFER_ISOC == type)) {
-   if (USB_DIR_IN & desc->bEndpointAddress)
-   ep = find_ep (gadget, "ep5in");
-   else
-   ep = find_ep (gadget, "ep6out");
-   } else if (USB_ENDPOINT_XFER_INT == type) {
-   if (USB_DIR_IN & desc->bEndpointAddress)
-   ep = find_ep(gadget, "ep1in");
-   else
-   ep = find_ep(gadget, "ep2out");
-   } else
-   ep = NULL;
-   if (ep && usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
-   goto found_ep;
-   }
-#endif
-
/* Second, look at endpoints until an unclaimed one looks usable */
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
if (usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 043248a..5f1eb35 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1684,6 +1684,49 @@ static int musb_gadget_pullup(struct usb_gadget *gadget, 
int is_on)
return 0;
 }
 
+#ifdef CONFIG_BLACKFIN
+static struct usb_ep *musb_find_ep(struct usb_gadget *g,
+   const char *name)
+{
+   struct usb_ep *ep;
+
+   list_for_each_entry(ep, &g->ep_list, ep_list) {
+   if (0 == strcmp(ep->name, name))
+   return ep;
+   }
+
+   return NULL;
+}
+
+static struct usb_ep *match_match_ep(struct usb_gadget *g,
+   struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp)
+{
+   struct usb_ep *ep = NULL;
+   u8 type = usb_endpoint_type(desc);
+
+   if ((USB_ENDPOINT_XFER_BULK == type) ||
+   (USB_ENDPOINT_XFER_ISOC == type)) {
+   if (USB_DIR_IN & desc->bEndpointAddress)
+   ep = musb_find_ep(g, "ep5in");
+   else
+   ep = musb_find_ep(g, "ep6out");
+   } else if (USB_ENDPOINT_XFER_INT == type) {
+   if (USB_DIR_IN & desc->bEndpointAddress)
+   ep = musb_find_ep(g, "ep1in");
+   else
+   ep = musb_find_ep(g, "ep2out");
+   }
+
+   if (ep && usb_gadget_ep_match_desc(g, ep, desc, ep_comp))
+   return ep;
+
+   return NULL;
+}
+#else
+#define musb_match_ep NULL
+#endif
+
 static int musb_gadget_start(struct usb_gadget *g,
struct usb_gadget_driver *driver);
 static int musb_gadget_stop(struct usb_gadget *g);
@@ -1697,6 +1740,7 @@ static const struct usb_gadget_ops musb_gadget_operations 
= {
.pullup = musb_gadget_pullup,
.udc_start  = musb_gadget_start,
.udc_stop   = musb_gadget_stop,
+   .match_ep   = musb_match_ep,
 };
 
 /* --- */
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 46/48] usb: gadget: goku_udc: add goku_match_ep() function

2015-07-14 Thread Robert Baldyga
Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c   | 20 ++--
 drivers/usb/gadget/udc/goku_udc.c | 25 +
 2 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 3ac92b4..038b21d 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -98,24 +98,8 @@ struct usb_ep *usb_ep_autoconfig_ss(
/* First, apply chip-specific "best usage" knowledge.
 * This might make a good usb_gadget_ops hook ...
 */
-   if (gadget_is_goku (gadget)) {
-   if (USB_ENDPOINT_XFER_INT == type) {
-   /* single buffering is enough */
-   ep = find_ep(gadget, "ep3-bulk");
-   if (ep && usb_gadget_ep_match_desc(gadget,
-   ep, desc, ep_comp))
-   goto found_ep;
-   } else if (USB_ENDPOINT_XFER_BULK == type
-   && (USB_DIR_IN & desc->bEndpointAddress)) {
-   /* DMA may be available */
-   ep = find_ep(gadget, "ep2-bulk");
-   if (ep && usb_gadget_ep_match_desc(gadget,
-   ep, desc, ep_comp))
-   goto found_ep;
-   }
-
 #ifdef CONFIG_BLACKFIN
-   } else if (gadget_is_musbhdrc(gadget)) {
+   if (gadget_is_musbhdrc(gadget)) {
if ((USB_ENDPOINT_XFER_BULK == type) ||
(USB_ENDPOINT_XFER_ISOC == type)) {
if (USB_DIR_IN & desc->bEndpointAddress)
@@ -131,8 +115,8 @@ struct usb_ep *usb_ep_autoconfig_ss(
ep = NULL;
if (ep && usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
goto found_ep;
-#endif
}
+#endif
 
/* Second, look at endpoints until an unclaimed one looks usable */
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
diff --git a/drivers/usb/gadget/udc/goku_udc.c 
b/drivers/usb/gadget/udc/goku_udc.c
index 46b8d14..d25b3a3 100644
--- a/drivers/usb/gadget/udc/goku_udc.c
+++ b/drivers/usb/gadget/udc/goku_udc.c
@@ -990,6 +990,30 @@ static int goku_get_frame(struct usb_gadget *_gadget)
return -EOPNOTSUPP;
 }
 
+static struct usb_ep *goku_match_ep(struct usb_gadget *g,
+   struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp)
+{
+   struct goku_udc *dev = to_goku_udc(g);
+   struct usb_ep *ep;
+   u8 type = usb_endpoint_type(desc);
+
+   if (USB_ENDPOINT_XFER_INT == type) {
+   /* single buffering is enough */
+   ep = &dev->ep[3].ep;
+   if (ep && usb_gadget_ep_match_desc(g, ep, desc, ep_comp))
+   return ep;
+   } else if (USB_ENDPOINT_XFER_BULK == type
+   && usb_endpoint_dir_in(desc)) {
+   /* DMA may be available */
+   ep = &dev->ep[2].ep;
+   if (ep && usb_gadget_ep_match_desc(g, ep, desc, ep_comp))
+   return ep;
+   }
+
+   return NULL;
+}
+
 static int goku_udc_start(struct usb_gadget *g,
struct usb_gadget_driver *driver);
 static int goku_udc_stop(struct usb_gadget *g);
@@ -998,6 +1022,7 @@ static const struct usb_gadget_ops goku_ops = {
.get_frame  = goku_get_frame,
.udc_start  = goku_udc_start,
.udc_stop   = goku_udc_stop,
+   .match_ep   = goku_match_ep,
// no remote wakeup
// not selfpowered
 };
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 43/48] usb: gadget: udc: add usb_gadget_ep_match_desc() function

2015-07-14 Thread Robert Baldyga
Add function matching endpoint with ep descriptor. This function checks if
hardware endponit can fulfill requirements requested in descriptor. This
function can be used by UDC drivers in match_ep() callback to avoid writing
lots of repetitive code.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/udc-core.c | 69 +++
 include/linux/usb/gadget.h|  8 +
 2 files changed, 77 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index d69c355..2dff8df 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -129,6 +129,75 @@ EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
 
 /* - */
 
+int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
+   struct usb_ep *ep, struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp)
+{
+   u8  type;
+   u16 max;
+   int num_req_streams = 0;
+
+   /* endpoint already claimed? */
+   if (ep->claimed)
+   return 0;
+
+   type = usb_endpoint_type(desc);
+   max = 0x7ff & usb_endpoint_maxp(desc);
+
+   if (usb_endpoint_dir_in(desc) && !ep->caps.dir_in)
+   return 0;
+   else if (!ep->caps.dir_out)
+   return 0;
+
+   if (max > ep->maxpacket_limit)
+   return 0;
+
+   /* "high bandwidth" works only at high speed */
+   if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
+   return 0;
+
+   switch (type) {
+   case USB_ENDPOINT_XFER_CONTROL:
+   /* only support ep0 for portable CONTROL traffic */
+   return 0;
+   case USB_ENDPOINT_XFER_ISOC:
+   if (!ep->caps.type_iso)
+   return 0;
+   /* ISO:  limit 1023 bytes full speed, 1024 high/super speed */
+   if (!gadget_is_dualspeed(gadget) && max > 1023)
+   return 0;
+   break;
+   case USB_ENDPOINT_XFER_BULK:
+   if (!ep->caps.type_bulk)
+   return 0;
+   if (ep_comp && gadget_is_superspeed(gadget)) {
+   /* Get the number of required streams from the
+* EP companion descriptor and see if the EP
+* matches it
+*/
+   num_req_streams = ep_comp->bmAttributes & 0x1f;
+   if (num_req_streams > ep->max_streams)
+   return 0;
+   }
+   break;
+   case USB_ENDPOINT_XFER_INT:
+   /* Bulk endpoints handle interrupt transfers,
+* except the toggle-quirky iso-synch kind
+*/
+   if (!ep->caps.type_int && !ep->caps.type_bulk)
+   return 0;
+   /* INT:  limit 64 bytes full speed, 1024 high/super speed */
+   if (!gadget_is_dualspeed(gadget) && max > 64)
+   return 0;
+   break;
+   }
+
+   return 1;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_ep_match_desc);
+
+/* - */
+
 static void usb_gadget_state_work(struct work_struct *work)
 {
struct usb_gadget *gadget = work_to_gadget(work);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 0041bb9..77e2c1e 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1079,6 +1079,14 @@ extern void usb_gadget_giveback_request(struct usb_ep 
*ep,
 
 /*-*/
 
+/* utility to check if endpoint caps match descriptor needs */
+
+extern int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
+   struct usb_ep *ep, struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp);
+
+/*-*/
+
 /* utility to update vbus status for udc core, it may be scheduled */
 extern void usb_udc_vbus_handler(struct usb_gadget *gadget, bool status);
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 40/48] usb: gadget: epautoconf: rework ep_matches() function

2015-07-14 Thread Robert Baldyga
Rework ep_matches() function to make it shorter and better readable.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 87 +
 1 file changed, 35 insertions(+), 52 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index d00b443..ee0d4e6 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -30,16 +30,29 @@ ep_matches (
struct usb_ss_ep_comp_descriptor *ep_comp
 )
 {
-   u8  type;
-   u16 max;
-
-   int num_req_streams = 0;
+   u8  type;
+   u16 max;
+   int num_req_streams = 0;
 
/* endpoint already claimed? */
if (ep->claimed)
return 0;
 
type = usb_endpoint_type(desc);
+   max = 0x7ff & usb_endpoint_maxp(desc);
+
+   if (usb_endpoint_dir_in(desc) && !ep->caps.dir_in)
+   return 0;
+   else if (!ep->caps.dir_out)
+   return 0;
+
+   if (max > ep->maxpacket_limit)
+   return 0;
+
+   /* "high bandwidth" works only at high speed */
+   if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
+   return 0;
+
switch (type) {
case USB_ENDPOINT_XFER_CONTROL:
/* only support ep0 for portable CONTROL traffic */
@@ -47,66 +60,36 @@ ep_matches (
case USB_ENDPOINT_XFER_ISOC:
if (!ep->caps.type_iso)
return 0;
+   /* ISO:  limit 1023 bytes full speed,
+* 1024 high/super speed
+*/
+   if (!gadget_is_dualspeed(gadget) && max > 1023)
+   return 0;
break;
case USB_ENDPOINT_XFER_BULK:
if (!ep->caps.type_bulk)
return 0;
+   if (ep_comp && gadget_is_superspeed(gadget)) {
+   /* Get the number of required streams from the
+* EP companion descriptor and see if the EP
+* matches it
+*/
+   num_req_streams = ep_comp->bmAttributes & 0x1f;
+   if (num_req_streams > ep->max_streams)
+   return 0;
+   }
break;
case USB_ENDPOINT_XFER_INT:
-   /* bulk endpoints handle interrupt transfers,
+   /* Bulk endpoints handle interrupt transfers,
 * except the toggle-quirky iso-synch kind
 */
if (!ep->caps.type_int && !ep->caps.type_bulk)
return 0;
-   break;
-   }
-
-   if (usb_endpoint_dir_in(desc)) {
-   if (!ep->caps.dir_in)
-   return 0;
-   } else {
-   if (!ep->caps.dir_out)
-   return 0;
-   }
-
-   /*
-* Get the number of required streams from the EP companion
-* descriptor and see if the EP matches it
-*/
-   if (usb_endpoint_xfer_bulk(desc)) {
-   if (ep_comp && gadget->max_speed >= USB_SPEED_SUPER) {
-   num_req_streams = ep_comp->bmAttributes & 0x1f;
-   if (num_req_streams > ep->max_streams)
-   return 0;
-   }
-
-   }
-
-   /* endpoint maxpacket size is an input parameter, except for bulk
-* where it's an output parameter representing the full speed limit.
-* the usb spec fixes high speed bulk maxpacket at 512 bytes.
-*/
-   max = 0x7ff & usb_endpoint_maxp(desc);
-   switch (type) {
-   case USB_ENDPOINT_XFER_INT:
-   /* INT:  limit 64 bytes full speed, 1024 high/super speed */
+   /* INT:  limit 64 bytes full speed,
+* 1024 high/super speed
+*/
if (!gadget_is_dualspeed(gadget) && max > 64)
return 0;
-   /* FALLTHROUGH */
-
-   case USB_ENDPOINT_XFER_ISOC:
-   /* ISO:  limit 1023 bytes full speed, 1024 high/super speed */
-   if (ep->maxpacket_limit < max)
-   return 0;
-   if (!gadget_is_dualspeed(gadget) && max > 1023)
-   return 0;
-
-   /* BOTH:  "high bandwidth" works only at high speed */
-   if ((desc->wMaxPacketSize & cpu_to_le16(3<<11))) {
-   if (!gadget_is_dualspeed(gadget))
-   return 0;
-   /* configure your hardware with enough buffering!! */
-   }
break;
}
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 39/48] usb: gadget: epautoconf: remove ep and desc configuration from ep_matches()

2015-07-14 Thread Robert Baldyga
As function ep_matches() is used to match endpoint with usb descriptor it's
highly unintuitive that it modifies endpoint and descriptor structures fields.
This patch moves code configuring ep and desc from ep_matches() to
usb_ep_autoconfig_ss(), so now function ep_matches() does nothing more than
its name is suggesting.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 66 +
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 4f66e9d73..d00b443 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -82,13 +82,6 @@ ep_matches (
 
}
 
-   /*
-* If the protocol driver hasn't yet decided on wMaxPacketSize
-* and wants to know the maximum possible, provide the info.
-*/
-   if (desc->wMaxPacketSize == 0)
-   desc->wMaxPacketSize = cpu_to_le16(ep->maxpacket_limit);
-
/* endpoint maxpacket size is an input parameter, except for bulk
 * where it's an output parameter representing the full speed limit.
 * the usb spec fixes high speed bulk maxpacket at 512 bytes.
@@ -119,31 +112,6 @@ ep_matches (
 
/* MATCH!! */
 
-   /* report address */
-   desc->bEndpointAddress &= USB_DIR_IN;
-   if (isdigit (ep->name [2])) {
-   u8  num = simple_strtoul (&ep->name [2], NULL, 10);
-   desc->bEndpointAddress |= num;
-   } else if (desc->bEndpointAddress & USB_DIR_IN) {
-   if (++gadget->in_epnum > 15)
-   return 0;
-   desc->bEndpointAddress = USB_DIR_IN | gadget->in_epnum;
-   } else {
-   if (++gadget->out_epnum > 15)
-   return 0;
-   desc->bEndpointAddress |= gadget->out_epnum;
-   }
-
-   /* report (variable) full speed bulk maxpacket */
-   if ((USB_ENDPOINT_XFER_BULK == type) && !ep_comp) {
-   int size = ep->maxpacket_limit;
-
-   /* min() doesn't work on bitfields with gcc-3.5 */
-   if (size > 64)
-   size = 64;
-   desc->wMaxPacketSize = cpu_to_le16(size);
-   }
-   ep->address = desc->bEndpointAddress;
return 1;
 }
 
@@ -280,6 +248,40 @@ struct usb_ep *usb_ep_autoconfig_ss(
/* Fail */
return NULL;
 found_ep:
+
+   /*
+* If the protocol driver hasn't yet decided on wMaxPacketSize
+* and wants to know the maximum possible, provide the info.
+*/
+   if (desc->wMaxPacketSize == 0)
+   desc->wMaxPacketSize = cpu_to_le16(ep->maxpacket_limit);
+
+   /* report address */
+   desc->bEndpointAddress &= USB_DIR_IN;
+   if (isdigit(ep->name[2])) {
+   u8 num = simple_strtoul(&ep->name[2], NULL, 10);
+   desc->bEndpointAddress |= num;
+   } else if (desc->bEndpointAddress & USB_DIR_IN) {
+   if (++gadget->in_epnum > 15)
+   return 0;
+   desc->bEndpointAddress = USB_DIR_IN | gadget->in_epnum;
+   } else {
+   if (++gadget->out_epnum > 15)
+   return 0;
+   desc->bEndpointAddress |= gadget->out_epnum;
+   }
+
+   /* report (variable) full speed bulk maxpacket */
+   if ((USB_ENDPOINT_XFER_BULK == type) && !ep_comp) {
+   int size = ep->maxpacket_limit;
+
+   /* min() doesn't work on bitfields with gcc-3.5 */
+   if (size > 64)
+   size = 64;
+   desc->wMaxPacketSize = cpu_to_le16(size);
+   }
+
+   ep->address = desc->bEndpointAddress;
ep->desc = NULL;
ep->comp_desc = NULL;
ep->claimed = true;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 42/48] usb: gadget: epautoconf: use 'ep_match' gadget callback

2015-07-14 Thread Robert Baldyga
If gadget has set 'ep_match' callback we prefer to call it first to allow
UDC driver to find the best matching endpoint basing on chip-specific "best
usage" knowledge.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index ee0d4e6..92a1a4c 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -165,6 +165,12 @@ struct usb_ep *usb_ep_autoconfig_ss(
 
type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
 
+   if (gadget->ops->match_ep) {
+   ep = gadget->ops->match_ep(gadget, desc, ep_comp);
+   if (ep)
+   goto found_ep;
+   }
+
/* First, apply chip-specific "best usage" knowledge.
 * This might make a good usb_gadget_ops hook ...
 */
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 41/48] usb: gadget: add 'ep_match' callback to usb_gadget_ops

2015-07-14 Thread Robert Baldyga
This callback will be called by epautoconf to allow UDC driver match best
endpoint for specific descriptor. It's intended to supply mechanism which
allows to get rid of chip-specific endpoint matching code from epautoconf.

Signed-off-by: Robert Baldyga 
---
 include/linux/usb/gadget.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e6cbc25..0041bb9 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -534,6 +534,9 @@ struct usb_gadget_ops {
int (*udc_start)(struct usb_gadget *,
struct usb_gadget_driver *);
int (*udc_stop)(struct usb_gadget *);
+   struct usb_ep *(*match_ep)(struct usb_gadget *,
+   struct usb_endpoint_descriptor *,
+   struct usb_ss_ep_comp_descriptor *);
 };
 
 /**
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 38/48] usb: gadget: epautoconf: remove pxa quirk from ep_matches()

2015-07-14 Thread Robert Baldyga
The same effect can be achieved by using capabilities flags, so now we can
get rid of handing of hardware specific limitations in generic code.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 5 -
 drivers/usb/gadget/udc/pxa25x_udc.c | 9 +++--
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index af4b10a..4f66e9d73 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -58,11 +58,6 @@ ep_matches (
 */
if (!ep->caps.type_int && !ep->caps.type_bulk)
return 0;
-   /* for now, avoid PXA "interrupt-in";
-* it's documented as never using DATA1.
-*/
-   if (gadget_is_pxa(gadget) && ep->caps.type_int)
-   return 0;
break;
}
 
diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c 
b/drivers/usb/gadget/udc/pxa25x_udc.c
index 1301e29..f53e526 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -1898,8 +1898,7 @@ static struct pxa25x_udc memory = {
.name   = "ep5in-int",
.ops= &pxa25x_ep_ops,
.maxpacket  = INT_FIFO_SIZE,
-   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
-   USB_EP_CAPS_DIR_IN),
+   .caps   = USB_EP_CAPS(0, 0),
},
.dev= &memory,
.fifo_size  = INT_FIFO_SIZE,
@@ -1977,8 +1976,7 @@ static struct pxa25x_udc memory = {
.name   = "ep10in-int",
.ops= &pxa25x_ep_ops,
.maxpacket  = INT_FIFO_SIZE,
-   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
-   USB_EP_CAPS_DIR_IN),
+   .caps   = USB_EP_CAPS(0, 0),
},
.dev= &memory,
.fifo_size  = INT_FIFO_SIZE,
@@ -2056,8 +2054,7 @@ static struct pxa25x_udc memory = {
.name   = "ep15in-int",
.ops= &pxa25x_ep_ops,
.maxpacket  = INT_FIFO_SIZE,
-   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
-   USB_EP_CAPS_DIR_IN),
+   .caps   = USB_EP_CAPS(0, 0),
},
.dev= &memory,
.fifo_size  = INT_FIFO_SIZE,
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 37/48] usb: gadget: epautoconf: add endpoint capabilities flags verification

2015-07-14 Thread Robert Baldyga
Introduce endpoint matching mechanism basing on endpoint capabilities
flags. We check if endpoint supports transfer type and direction requested
in ep descriptor. Since we have this new endpoint matching mechanism
there is no need to have old code guessing endpoint capabilities basing
on its name, so we are getting rid of it. Remove also the obsolete comment.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/epautoconf.c | 96 +
 1 file changed, 30 insertions(+), 66 deletions(-)

diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 8e00ca7..af4b10a 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -22,22 +22,6 @@
 
 #include "gadget_chips.h"
 
-/*
- * This should work with endpoints from controller drivers sharing the
- * same endpoint naming convention.  By example:
- *
- * - ep1, ep2, ... address is fixed, not direction or type
- * - ep1in, ep2out, ... address and direction are fixed, not type
- * - ep1-bulk, ep2-bulk, ... address and type are fixed, not direction
- * - ep1in-bulk, ep2out-iso, ... all three are fixed
- * - ep-* ... no functionality restrictions
- *
- * Type suffixes are "-bulk", "-iso", or "-int".  Numbers are decimal.
- * Less common restrictions are implied by gadget_is_*().
- *
- * NOTE:  each endpoint is unidirectional, as specified by its USB
- * descriptor; and isn't specific to a configuration or altsetting.
- */
 static int
 ep_matches (
struct usb_gadget   *gadget,
@@ -47,7 +31,6 @@ ep_matches (
 )
 {
u8  type;
-   const char  *tmp;
u16 max;
 
int num_req_streams = 0;
@@ -56,58 +39,39 @@ ep_matches (
if (ep->claimed)
return 0;
 
-   /* only support ep0 for portable CONTROL traffic */
type = usb_endpoint_type(desc);
-   if (USB_ENDPOINT_XFER_CONTROL == type)
-   return 0;
-
-   /* some other naming convention */
-   if ('e' != ep->name[0])
+   switch (type) {
+   case USB_ENDPOINT_XFER_CONTROL:
+   /* only support ep0 for portable CONTROL traffic */
return 0;
+   case USB_ENDPOINT_XFER_ISOC:
+   if (!ep->caps.type_iso)
+   return 0;
+   break;
+   case USB_ENDPOINT_XFER_BULK:
+   if (!ep->caps.type_bulk)
+   return 0;
+   break;
+   case USB_ENDPOINT_XFER_INT:
+   /* bulk endpoints handle interrupt transfers,
+* except the toggle-quirky iso-synch kind
+*/
+   if (!ep->caps.type_int && !ep->caps.type_bulk)
+   return 0;
+   /* for now, avoid PXA "interrupt-in";
+* it's documented as never using DATA1.
+*/
+   if (gadget_is_pxa(gadget) && ep->caps.type_int)
+   return 0;
+   break;
+   }
 
-   /* type-restriction:  "-iso", "-bulk", or "-int".
-* direction-restriction:  "in", "out".
-*/
-   if ('-' != ep->name[2]) {
-   tmp = strrchr (ep->name, '-');
-   if (tmp) {
-   switch (type) {
-   case USB_ENDPOINT_XFER_INT:
-   /* bulk endpoints handle interrupt transfers,
-* except the toggle-quirky iso-synch kind
-*/
-   if ('s' == tmp[2])  // == "-iso"
-   return 0;
-   /* for now, avoid PXA "interrupt-in";
-* it's documented as never using DATA1.
-*/
-   if (gadget_is_pxa (gadget)
-   && 'i' == tmp [1])
-   return 0;
-   break;
-   case USB_ENDPOINT_XFER_BULK:
-   if ('b' != tmp[1])  // != "-bulk"
-   return 0;
-   break;
-   case USB_ENDPOINT_XFER_ISOC:
-   if ('s' != tmp[2])  // != "-iso"
-   return 0;
-   }
-   } else {
-   tmp = ep->name + strlen (ep->name);
-   }
-
-   /* direction-restriction:  "..in-..", "out-.." */
-   tmp--;
-   if (!isdigit (*tmp)) {
-   if (desc->bEndpointAddress & USB_DIR_IN) {
-   if ('n' != *tmp)
-   return 0;
-   } else {
-   if ('t' != *tmp)
-   retur

[PATCH v2 36/48] usb: gadget: atmel_usba_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 37d414e..267d84f 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -2067,6 +2067,17 @@ static struct usba_ep * usba_udc_pdata(struct 
platform_device *pdev,
ep->can_dma = pdata->ep[i].can_dma;
ep->can_isoc = pdata->ep[i].can_isoc;
 
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = ep->can_isoc;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
+
if (i)
list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
}
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 35/48] usb: renesas: gadget: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/renesas_usbhs/mod_gadget.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
b/drivers/usb/renesas_usbhs/mod_gadget.c
index dc2aa32..ed8d890 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -1041,12 +1041,18 @@ int usbhs_mod_gadget_probe(struct usbhs_priv *priv)
if (usbhsg_is_dcp(uep)) {
gpriv->gadget.ep0 = &uep->ep;
usb_ep_set_maxpacket_limit(&uep->ep, 64);
+   uep->ep.caps.type_control = true;
}
/* init normal pipe */
else {
usb_ep_set_maxpacket_limit(&uep->ep, 512);
+   uep->ep.caps.type_iso = true;
+   uep->ep.caps.type_bulk = true;
+   uep->ep.caps.type_int = true;
list_add_tail(&uep->ep.ep_list, &gpriv->gadget.ep_list);
}
+   uep->ep.caps.dir_in = true;
+   uep->ep.caps.dir_out = true;
}
 
ret = usb_add_gadget_udc(dev, &gpriv->gadget);
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 33/48] usb: isp1760: udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/isp1760/isp1760-udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/isp1760/isp1760-udc.c 
b/drivers/usb/isp1760/isp1760-udc.c
index 3699962..1c3d0fd 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -1383,13 +1383,24 @@ static void isp1760_udc_init_eps(struct isp1760_udc 
*udc)
 */
if (ep_num == 0) {
usb_ep_set_maxpacket_limit(&ep->ep, 64);
+   ep->ep.caps.type_control = true;
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
ep->maxpacket = 64;
udc->gadget.ep0 = &ep->ep;
} else {
usb_ep_set_maxpacket_limit(&ep->ep, 512);
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
ep->maxpacket = 0;
list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
}
+
+   if (is_in)
+   ep->ep.caps.dir_in = true;
+   else
+   ep->ep.caps.dir_out = true;
}
 }
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 34/48] usb: musb: gadget: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/musb/musb_gadget.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 625d482f..043248a 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1729,6 +1729,7 @@ init_peripheral_ep(struct musb *musb, struct musb_ep *ep, 
u8 epnum, int is_in)
INIT_LIST_HEAD(&ep->end_point.ep_list);
if (!epnum) {
usb_ep_set_maxpacket_limit(&ep->end_point, 64);
+   ep->end_point.caps.type_control = true;
ep->end_point.ops = &musb_g_ep0_ops;
musb->g.ep0 = &ep->end_point;
} else {
@@ -1736,9 +1737,20 @@ init_peripheral_ep(struct musb *musb, struct musb_ep 
*ep, u8 epnum, int is_in)
usb_ep_set_maxpacket_limit(&ep->end_point, 
hw_ep->max_packet_sz_tx);
else
usb_ep_set_maxpacket_limit(&ep->end_point, 
hw_ep->max_packet_sz_rx);
+   ep->end_point.caps.type_iso = true;
+   ep->end_point.caps.type_bulk = true;
+   ep->end_point.caps.type_int = true;
ep->end_point.ops = &musb_ep_ops;
list_add_tail(&ep->end_point.ep_list, &musb->g.ep_list);
}
+
+   if (!epnum || hw_ep->is_shared_fifo) {
+   ep->end_point.caps.dir_in = true;
+   ep->end_point.caps.dir_out = true;
+   } else if (is_in)
+   ep->end_point.caps.dir_in = true;
+   else
+   ep->end_point.caps.dir_out = true;
 }
 
 /*
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 32/48] usb: gadget: udc-xilinx: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/udc-xilinx.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
b/drivers/usb/gadget/udc/udc-xilinx.c
index 1f24274..1cbb0ac 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -1317,12 +1317,21 @@ static void xudc_eps_init(struct xusb_udc *udc)
snprintf(ep->name, EPNAME_SIZE, "ep%d", ep_number);
ep->ep_usb.name = ep->name;
ep->ep_usb.ops = &xusb_ep_ops;
+
+   ep->ep_usb.caps.type_iso = true;
+   ep->ep_usb.caps.type_bulk = true;
+   ep->ep_usb.caps.type_int = true;
} else {
ep->ep_usb.name = ep0name;
usb_ep_set_maxpacket_limit(&ep->ep_usb, EP0_MAX_PACKET);
ep->ep_usb.ops = &xusb_ep0_ops;
+
+   ep->ep_usb.caps.type_control = true;
}
 
+   ep->ep_usb.caps.dir_in = true;
+   ep->ep_usb.caps.dir_out = true;
+
ep->udc = udc;
ep->epnumber = ep_number;
ep->desc = NULL;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 31/48] usb: gadget: s3c2410_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/s3c2410_udc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c 
b/drivers/usb/gadget/udc/s3c2410_udc.c
index 5d9aa81..eb3571e 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -1691,6 +1691,8 @@ static struct s3c2410_udc memory = {
.name   = ep0name,
.ops= &s3c2410_ep_ops,
.maxpacket  = EP0_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+   USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
},
@@ -1702,6 +1704,8 @@ static struct s3c2410_udc memory = {
.name   = "ep1-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket  = EP_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size  = EP_FIFO_SIZE,
@@ -1714,6 +1718,8 @@ static struct s3c2410_udc memory = {
.name   = "ep2-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket  = EP_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size  = EP_FIFO_SIZE,
@@ -1726,6 +1732,8 @@ static struct s3c2410_udc memory = {
.name   = "ep3-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket  = EP_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size  = EP_FIFO_SIZE,
@@ -1738,6 +1746,8 @@ static struct s3c2410_udc memory = {
.name   = "ep4-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket  = EP_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size  = EP_FIFO_SIZE,
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 27/48] usb: gadget: pxa25x_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/pxa25x_udc.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c 
b/drivers/usb/gadget/udc/pxa25x_udc.c
index f6cbe66..1301e29 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -1821,6 +1821,8 @@ static struct pxa25x_udc memory = {
.name   = ep0name,
.ops= &pxa25x_ep_ops,
.maxpacket  = EP0_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+   USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.reg_udccs  = &UDCCS0,
@@ -1833,6 +1835,8 @@ static struct pxa25x_udc memory = {
.name   = "ep1in-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket  = BULK_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size  = BULK_FIFO_SIZE,
@@ -1846,6 +1850,8 @@ static struct pxa25x_udc memory = {
.name   = "ep2out-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket  = BULK_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_OUT),
},
.dev= &memory,
.fifo_size  = BULK_FIFO_SIZE,
@@ -1861,6 +1867,8 @@ static struct pxa25x_udc memory = {
.name   = "ep3in-iso",
.ops= &pxa25x_ep_ops,
.maxpacket  = ISO_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size  = ISO_FIFO_SIZE,
@@ -1874,6 +1882,8 @@ static struct pxa25x_udc memory = {
.name   = "ep4out-iso",
.ops= &pxa25x_ep_ops,
.maxpacket  = ISO_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_OUT),
},
.dev= &memory,
.fifo_size  = ISO_FIFO_SIZE,
@@ -1888,6 +1898,8 @@ static struct pxa25x_udc memory = {
.name   = "ep5in-int",
.ops= &pxa25x_ep_ops,
.maxpacket  = INT_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size  = INT_FIFO_SIZE,
@@ -1903,6 +1915,8 @@ static struct pxa25x_udc memory = {
.name   = "ep6in-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket  = BULK_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size  = BULK_FIFO_SIZE,
@@ -1916,6 +1930,8 @@ static struct pxa25x_udc memory = {
.name   = "ep7out-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket  = BULK_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_OUT),
},
.dev= &memory,
.fifo_size  = BULK_FIFO_SIZE,
@@ -1930,6 +1946,8 @@ static struct pxa25x_udc memory = {
.name   = "ep8in-iso",
.ops= &pxa25x_ep_ops,
.maxpacket  = ISO_FIFO_SIZE,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size  = ISO_FIFO_SIZE,
@@ -1943,6 +1961,8 @@ static struct pxa25x_udc memory = {
.name   = "ep9out-iso",
.ops= &pxa25x_ep_ops,
.maxpacket  = ISO_FI

[PATCH v2 26/48] usb: gadget: pch_ud: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/pch_udc.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..cc8fb3c 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -2895,11 +2895,21 @@ static void pch_udc_pcd_reinit(struct pch_udc_dev *dev)
ep->in = ~i & 1;
ep->ep.name = ep_string[i];
ep->ep.ops = &pch_udc_ep_ops;
-   if (ep->in)
+   if (ep->in) {
ep->offset_addr = ep->num * UDC_EP_REG_SHIFT;
-   else
+   ep->ep.caps.dir_in = true;
+   } else {
ep->offset_addr = (UDC_EPINT_OUT_SHIFT + ep->num) *
  UDC_EP_REG_SHIFT;
+   ep->ep.caps.dir_out = true;
+   }
+   if (i == UDC_EP0IN_IDX || i == UDC_EP0OUT_IDX) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
/* need to set ep->ep.maxpacket and set Default Configuration?*/
usb_ep_set_maxpacket_limit(&ep->ep, UDC_BULK_MAX_PKT_SIZE);
list_add_tail(&ep->ep.ep_list, &dev->gadget.ep_list);
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 30/48] usb: gadget: s3c-hsudc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/s3c-hsudc.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/gadget/udc/s3c-hsudc.c 
b/drivers/usb/gadget/udc/s3c-hsudc.c
index 85a712a..e9def42 100644
--- a/drivers/usb/gadget/udc/s3c-hsudc.c
+++ b/drivers/usb/gadget/udc/s3c-hsudc.c
@@ -1005,6 +1005,21 @@ static void s3c_hsudc_initep(struct s3c_hsudc *hsudc,
hsep->stopped = 0;
hsep->wedge = 0;
 
+   if (epnum == 0) {
+   hsep->ep.caps.type_control = true;
+   hsep->ep.caps.dir_in = true;
+   hsep->ep.caps.dir_out = true;
+   } else {
+   hsep->ep.caps.type_iso = true;
+   hsep->ep.caps.type_bulk = true;
+   hsep->ep.caps.type_int = true;
+   }
+
+   if (epnum & 1)
+   hsep->ep.caps.dir_in = true;
+   else
+   hsep->ep.caps.dir_out = true;
+
set_index(hsudc, epnum);
writel(hsep->ep.maxpacket, hsudc->regs + S3C_MPR);
 }
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 29/48] usb: gadget: r8a66597-udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/r8a66597-udc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c 
b/drivers/usb/gadget/udc/r8a66597-udc.c
index 0293f71..baa0609 100644
--- a/drivers/usb/gadget/udc/r8a66597-udc.c
+++ b/drivers/usb/gadget/udc/r8a66597-udc.c
@@ -1935,6 +1935,16 @@ static int r8a66597_probe(struct platform_device *pdev)
ep->ep.name = r8a66597_ep_name[i];
ep->ep.ops = &r8a66597_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, 512);
+
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&r8a66597->ep[0].ep, 64);
r8a66597->ep[0].pipenum = 0;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 28/48] usb: gadget: pxa27x_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/pxa27x_udc.h | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/pxa27x_udc.h 
b/drivers/usb/gadget/udc/pxa27x_udc.h
index 11e1423..ded058c 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.h
+++ b/drivers/usb/gadget/udc/pxa27x_udc.h
@@ -234,25 +234,28 @@
 /*
  * Endpoint definition helpers
  */
-#define USB_EP_DEF(addr, bname, dir, type, maxpkt) \
-{ .usb_ep = { .name = bname, .ops = &pxa_ep_ops, .maxpacket = maxpkt, }, \
+#define USB_EP_DEF(addr, bname, dir, type, maxpkt, ctype, cdir) \
+{ .usb_ep = {  .name = bname, .ops = &pxa_ep_ops, .maxpacket = maxpkt, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## ctype, \
+   USB_EP_CAPS_DIR_ ## cdir), }, \
   .desc = {.bEndpointAddress = addr | (dir ? USB_DIR_IN : 0), \
-   .bmAttributes = type, \
+   .bmAttributes = USB_ENDPOINT_XFER_ ## type, \
.wMaxPacketSize = maxpkt, }, \
   .dev = &memory \
 }
-#define USB_EP_BULK(addr, bname, dir) \
-  USB_EP_DEF(addr, bname, dir, USB_ENDPOINT_XFER_BULK, BULK_FIFO_SIZE)
-#define USB_EP_ISO(addr, bname, dir) \
-  USB_EP_DEF(addr, bname, dir, USB_ENDPOINT_XFER_ISOC, ISO_FIFO_SIZE)
-#define USB_EP_INT(addr, bname, dir) \
-  USB_EP_DEF(addr, bname, dir, USB_ENDPOINT_XFER_INT, INT_FIFO_SIZE)
-#define USB_EP_IN_BULK(n)  USB_EP_BULK(n, "ep" #n "in-bulk", 1)
-#define USB_EP_OUT_BULK(n) USB_EP_BULK(n, "ep" #n "out-bulk", 0)
-#define USB_EP_IN_ISO(n)   USB_EP_ISO(n,  "ep" #n "in-iso", 1)
-#define USB_EP_OUT_ISO(n)  USB_EP_ISO(n,  "ep" #n "out-iso", 0)
-#define USB_EP_IN_INT(n)   USB_EP_INT(n,  "ep" #n "in-int", 1)
-#define USB_EP_CTRLUSB_EP_DEF(0,  "ep0", 0, 0, EP0_FIFO_SIZE)
+#define USB_EP_BULK(addr, bname, dir, cdir) \
+   USB_EP_DEF(addr, bname, dir, BULK, BULK_FIFO_SIZE, BULK, cdir)
+#define USB_EP_ISO(addr, bname, dir, cdir) \
+   USB_EP_DEF(addr, bname, dir, ISOC, ISO_FIFO_SIZE, ISO, cdir)
+#define USB_EP_INT(addr, bname, dir, cdir) \
+   USB_EP_DEF(addr, bname, dir, INT, INT_FIFO_SIZE, INT, cdir)
+#define USB_EP_IN_BULK(n)  USB_EP_BULK(n, "ep" #n "in-bulk", 1, IN)
+#define USB_EP_OUT_BULK(n) USB_EP_BULK(n, "ep" #n "out-bulk", 0, OUT)
+#define USB_EP_IN_ISO(n)   USB_EP_ISO(n,  "ep" #n "in-iso", 1, IN)
+#define USB_EP_OUT_ISO(n)  USB_EP_ISO(n,  "ep" #n "out-iso", 0, OUT)
+#define USB_EP_IN_INT(n)   USB_EP_INT(n,  "ep" #n "in-int", 1, IN)
+#define USB_EP_CTRLUSB_EP_DEF(0,  "ep0", 0, CONTROL, \
+  EP0_FIFO_SIZE, CONTROL, ALL)
 
 #define PXA_EP_DEF(_idx, _addr, dir, _type, maxpkt, _config, iface, altset) \
 { \
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 25/48] usb: gadget: omap_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/omap_udc.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/usb/gadget/udc/omap_udc.c 
b/drivers/usb/gadget/udc/omap_udc.c
index e2fcdb8..9b7d394 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -2579,6 +2579,28 @@ omap_ep_setup(char *name, u8 addr, u8 type,
ep->double_buf = dbuf;
ep->udc = udc;
 
+   switch (type) {
+   case USB_ENDPOINT_XFER_CONTROL:
+   ep->ep.caps.type_control = true;
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
+   break;
+   case USB_ENDPOINT_XFER_ISOC:
+   ep->ep.caps.type_iso = true;
+   break;
+   case USB_ENDPOINT_XFER_BULK:
+   ep->ep.caps.type_bulk = true;
+   break;
+   case USB_ENDPOINT_XFER_INT:
+   ep->ep.caps.type_int = true;
+   break;
+   };
+
+   if (addr & USB_DIR_IN)
+   ep->ep.caps.dir_in = true;
+   else
+   ep->ep.caps.dir_out = true;
+
ep->ep.name = ep->name;
ep->ep.ops = &omap_ep_ops;
ep->maxpacket = maxp;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 24/48] usb: gadget: net2280: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/net2280.c | 50 ++--
 1 file changed, 38 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 2bee912..0295cf7 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -74,19 +74,41 @@ static const char driver_desc[] = DRIVER_DESC;
 
 static const u32 ep_bit[9] = { 0, 17, 2, 19, 4, 1, 18, 3, 20 };
 static const char ep0name[] = "ep0";
-static const char *const ep_name[] = {
-   ep0name,
-   "ep-a", "ep-b", "ep-c", "ep-d",
-   "ep-e", "ep-f", "ep-g", "ep-h",
-};
 
-/* Endpoint names for usb3380 advance mode */
-static const char *const ep_name_adv[] = {
-   ep0name,
-   "ep1in", "ep2out", "ep3in", "ep4out",
-   "ep1out", "ep2in", "ep3out", "ep4in",
+#define EP_INFO(_name, _type, _dir) \
+   { \
+   .name = _name, \
+   .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+   USB_EP_CAPS_DIR_ ## _dir), \
+   }
+
+static const struct {
+   const char *name;
+   const struct usb_ep_caps caps;
+} ep_info_dft[] = { /* Default endpoint configuration */
+   EP_INFO(ep0name, CONTROL, ALL),
+   EP_INFO("ep-a", ALL,ALL),
+   EP_INFO("ep-b", ALL,ALL),
+   EP_INFO("ep-c", ALL,ALL),
+   EP_INFO("ep-d", ALL,ALL),
+   EP_INFO("ep-e", ALL,ALL),
+   EP_INFO("ep-f", ALL,ALL),
+   EP_INFO("ep-g", ALL,ALL),
+   EP_INFO("ep-h", ALL,ALL),
+}, ep_info_adv[] = { /* Endpoints for usb3380 advance mode */
+   EP_INFO(ep0name, CONTROL, ALL),
+   EP_INFO("ep1in",ALL,IN),
+   EP_INFO("ep2out",   ALL,OUT),
+   EP_INFO("ep3in",ALL,IN),
+   EP_INFO("ep4out",   ALL,OUT),
+   EP_INFO("ep1out",   ALL,OUT),
+   EP_INFO("ep2in",ALL,IN),
+   EP_INFO("ep3out",   ALL,OUT),
+   EP_INFO("ep4in",ALL,IN),
 };
 
+#undef EP_INFO
+
 /* mode 0 == ep-{a,b,c,d} 1K fifo each
  * mode 1 == ep-{a,b} 2K fifo each, ep-{c,d} unavailable
  * mode 2 == ep-a 2K fifo, ep-{b,c} 1K each, ep-d unavailable
@@ -2055,7 +2077,8 @@ static void usb_reinit_228x(struct net2280 *dev)
for (tmp = 0; tmp < 7; tmp++) {
struct net2280_ep   *ep = &dev->ep[tmp];
 
-   ep->ep.name = ep_name[tmp];
+   ep->ep.name = ep_info_dft[tmp].name;
+   ep->ep.caps = ep_info_dft[tmp].caps;
ep->dev = dev;
ep->num = tmp;
 
@@ -2095,7 +2118,10 @@ static void usb_reinit_338x(struct net2280 *dev)
for (i = 0; i < dev->n_ep; i++) {
struct net2280_ep *ep = &dev->ep[i];
 
-   ep->ep.name = dev->enhanced_mode ? ep_name_adv[i] : ep_name[i];
+   ep->ep.name = dev->enhanced_mode ? ep_info_adv[i].name :
+  ep_info_dft[i].name;
+   ep->ep.caps = dev->enhanced_mode ? ep_info_adv[i].caps :
+  ep_info_dft[i].caps;
ep->dev = dev;
ep->num = i;
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 22/48] usb: gadget: mv_udc_core: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/mv_udc_core.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/udc/mv_udc_core.c 
b/drivers/usb/gadget/udc/mv_udc_core.c
index d32160d..306a7ff 100644
--- a/drivers/usb/gadget/udc/mv_udc_core.c
+++ b/drivers/usb/gadget/udc/mv_udc_core.c
@@ -1257,6 +1257,9 @@ static int eps_init(struct mv_udc *udc)
ep->wedge = 0;
ep->stopped = 0;
usb_ep_set_maxpacket_limit(&ep->ep, EP0_MAX_PKT_SIZE);
+   ep->ep.caps.type_control = true;
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
ep->ep_num = 0;
ep->ep.desc = &mv_ep0_desc;
INIT_LIST_HEAD(&ep->queue);
@@ -1269,14 +1272,20 @@ static int eps_init(struct mv_udc *udc)
if (i % 2) {
snprintf(name, sizeof(name), "ep%din", i / 2);
ep->direction = EP_DIR_IN;
+   ep->ep.caps.dir_in = true;
} else {
snprintf(name, sizeof(name), "ep%dout", i / 2);
ep->direction = EP_DIR_OUT;
+   ep->ep.caps.dir_out = true;
}
ep->udc = udc;
strncpy(ep->name, name, sizeof(ep->name));
ep->ep.name = ep->name;
 
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+
ep->ep.ops = &mv_ep_ops;
ep->stopped = 0;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 21/48] usb: gadget: mv_u3d_core: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/mv_u3d_core.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/udc/mv_u3d_core.c 
b/drivers/usb/gadget/udc/mv_u3d_core.c
index ea35a24..4c48969 100644
--- a/drivers/usb/gadget/udc/mv_u3d_core.c
+++ b/drivers/usb/gadget/udc/mv_u3d_core.c
@@ -1324,6 +1324,9 @@ static int mv_u3d_eps_init(struct mv_u3d *u3d)
ep->ep.ops = &mv_u3d_ep_ops;
ep->wedge = 0;
usb_ep_set_maxpacket_limit(&ep->ep, MV_U3D_EP0_MAX_PKT_SIZE);
+   ep->ep.caps.type_control = true;
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
ep->ep_num = 0;
ep->ep.desc = &mv_u3d_ep0_desc;
INIT_LIST_HEAD(&ep->queue);
@@ -1339,14 +1342,20 @@ static int mv_u3d_eps_init(struct mv_u3d *u3d)
if (i & 1) {
snprintf(name, sizeof(name), "ep%din", i >> 1);
ep->direction = MV_U3D_EP_DIR_IN;
+   ep->ep.caps.dir_in = true;
} else {
snprintf(name, sizeof(name), "ep%dout", i >> 1);
ep->direction = MV_U3D_EP_DIR_OUT;
+   ep->ep.caps.dir_out = true;
}
ep->u3d = u3d;
strncpy(ep->name, name, sizeof(ep->name));
ep->ep.name = ep->name;
 
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+
ep->ep.ops = &mv_u3d_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
ep->ep_num = i / 2;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 23/48] usb: gadget: net2272: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/net2272.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 195baf3..34ec1ec 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -1404,6 +1404,17 @@ net2272_usb_reinit(struct net2272 *dev)
else
ep->fifo_size = 64;
net2272_ep_reset(ep);
+
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&dev->ep[0].ep, 64);
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 19/48] usb: gadget: lpc32xx_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/lpc32xx_udc.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c 
b/drivers/usb/gadget/udc/lpc32xx_udc.c
index 3b6a785..00b5006 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -2575,6 +2575,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep0",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 0,
@@ -2586,6 +2588,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep1-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 2,
@@ -2597,6 +2601,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep2-bulk",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 4,
@@ -2608,6 +2614,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep3-iso",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 1023,
.hwep_num_base  = 6,
@@ -2619,6 +2627,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep4-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 8,
@@ -2630,6 +2640,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep5-bulk",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 10,
@@ -2641,6 +2653,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep6-iso",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 1023,
.hwep_num_base  = 12,
@@ -2652,6 +2666,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep7-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 14,
@@ -2663,6 +2679,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep8-bulk",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 64,
.hwep_num_base  = 16,
@@ -2674,6 +2692,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep9-iso",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+   USB_EP_CAPS_DIR_ALL),
},
.maxpacket  = 1023,
.hwep_num_base  = 18,
@@ -2685,6 +2705,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name   = "ep10-int",
.ops= &lpc32xx_ep_ops,
+   .caps   = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+   USB_EP_CAPS_DIR_ALL),
},
   

[PATCH v2 20/48] usb: gadget: m66592-udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/m66592-udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/m66592-udc.c 
b/drivers/usb/gadget/udc/m66592-udc.c
index 309706f..e404553 100644
--- a/drivers/usb/gadget/udc/m66592-udc.c
+++ b/drivers/usb/gadget/udc/m66592-udc.c
@@ -1644,6 +1644,17 @@ static int m66592_probe(struct platform_device *pdev)
ep->ep.name = m66592_ep_name[i];
ep->ep.ops = &m66592_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, 512);
+
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&m66592->ep[0].ep, 64);
m66592->ep[0].pipenum = 0;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 18/48] usb: gadget: gr_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/gr_udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index c886887..8aa2593 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -2018,12 +2018,23 @@ static int gr_ep_init(struct gr_udc *dev, int num, int 
is_in, u32 maxplimit)
 
usb_ep_set_maxpacket_limit(&ep->ep, MAX_CTRL_PL_SIZE);
ep->bytes_per_buffer = MAX_CTRL_PL_SIZE;
+
+   ep->ep.caps.type_control = true;
} else {
usb_ep_set_maxpacket_limit(&ep->ep, (u16)maxplimit);
list_add_tail(&ep->ep.ep_list, &dev->gadget.ep_list);
+
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
}
list_add_tail(&ep->ep_list, &dev->ep_list);
 
+   if (is_in)
+   ep->ep.caps.dir_in = true;
+   else
+   ep->ep.caps.dir_out = true;
+
ep->tailbuf = dma_alloc_coherent(dev->dev, ep->ep.maxpacket_limit,
 &ep->tailbuf_paddr, GFP_ATOMIC);
if (!ep->tailbuf)
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 17/48] usb: gadget: goku_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/goku_udc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/gadget/udc/goku_udc.c 
b/drivers/usb/gadget/udc/goku_udc.c
index 9e8d842..46b8d14 100644
--- a/drivers/usb/gadget/udc/goku_udc.c
+++ b/drivers/usb/gadget/udc/goku_udc.c
@@ -1257,6 +1257,14 @@ static void udc_reinit (struct goku_udc *dev)
INIT_LIST_HEAD (&ep->queue);
 
ep_reset(NULL, ep);
+
+   if (i == 0)
+   ep->ep.caps.type_control = true;
+   else
+   ep->ep.caps.type_bulk = true;
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
 
dev->ep[0].reg_mode = NULL;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 16/48] usb: gadget: fusb300_udc: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/fusb300_udc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index 3970f45..948845c 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1450,6 +1450,17 @@ static int fusb300_probe(struct platform_device *pdev)
ep->ep.name = fusb300_ep_name[i];
ep->ep.ops = &fusb300_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, HS_BULK_MAX_PACKET_SIZE);
+
+   if (i == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   ep->ep.caps.dir_in = true;
+   ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&fusb300->ep[0]->ep, HS_CTL_MAX_PACKET_SIZE);
fusb300->ep[0]->epnum = 0;
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 15/48] usb: gadget: fsl_udc_core: add ep capabilities support

2015-07-14 Thread Robert Baldyga
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index c60022b..aab5221 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2313,6 +2313,19 @@ static int struct_ep_setup(struct fsl_udc *udc, unsigned 
char index,
ep->ep.ops = &fsl_ep_ops;
ep->stopped = 0;
 
+   if (index == 0) {
+   ep->ep.caps.type_control = true;
+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
+
+   if (index & 1)
+   ep->ep.caps.dir_in = true;
+   else
+   ep->ep.caps.dir_out = true;
+
/* for ep0: maxP defined in desc
 * for other eps, maxP is set by epautoconfig() called by gadget layer
 */
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

  1   2   >