Date   

[RFC PATCH 7/7] ARM: shmobile: defconfig: Enable missing support based on DTSes

Biju Das <biju.das@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

Enable all missing support, extracted from the various Renesas ARM DTSes
using linux-config-from-dt.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 6161cc147277e7537d73a45d732a7112997c20f6)
(enabled only USB-DMAC apart from previously enabled CAN and
CAN_RCAR)
Signed-off-by: Biju Das <biju.das@...>
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 31d7ccc..69b95f5 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -189,6 +189,7 @@ CONFIG_RTC_DRV_RX8581=y
CONFIG_DMADEVICES=y
CONFIG_SH_DMAE=y
CONFIG_RCAR_DMAC=y
+CONFIG_RENESAS_USB_DMAC=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_IIO=y
CONFIG_AK8975=y
--
2.7.4


[RFC PATCH 6/7] dmaengine: usb-dmac: fix endless loop in usb_dmac_chan_terminate_all()

Biju Das <biju.das@...>
 

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

This patch fixes an issue that list_for_each_entry() in
usb_dmac_chan_terminate_all() is possible to cause endless loop because
this will move own desc to the desc_freed. So, this driver should use
list_for_each_entry_safe() instead of list_for_each_entry().

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Vinod Koul <vinod.koul@...>
(cherry picked from commit d9f5efade2cfd729138a7cafb46d01044da40f5e)
Signed-off-by: Biju Das <biju.das@...>
---
drivers/dma/sh/usb-dmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index 56410ea..6682b3e 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -448,7 +448,7 @@ usb_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
static int usb_dmac_chan_terminate_all(struct dma_chan *chan)
{
struct usb_dmac_chan *uchan = to_usb_dmac_chan(chan);
- struct usb_dmac_desc *desc;
+ struct usb_dmac_desc *desc, *_desc;
unsigned long flags;
LIST_HEAD(head);
LIST_HEAD(list);
@@ -459,7 +459,7 @@ static int usb_dmac_chan_terminate_all(struct dma_chan *chan)
if (uchan->desc)
uchan->desc = NULL;
list_splice_init(&uchan->desc_got, &list);
- list_for_each_entry(desc, &list, node)
+ list_for_each_entry_safe(desc, _desc, &list, node)
list_move_tail(&desc->node, &uchan->desc_freed);
spin_unlock_irqrestore(&uchan->vc.lock, flags);
vchan_dma_desc_free_list(&uchan->vc, &head);
--
2.7.4


[RFC PATCH 5/7] usb: gadget: f_ncm/u_ether: Move 'SKB reserve' quirk setup to u_ether

Biju Das <biju.das@...>
 

From: Dmitry Osipenko <digetx@...>

That quirk is required to make USB Ethernet gadget working on HW that
can't cope with unaligned DMA. For some reason only f_ncm sets up that
quirk, let's setup it directly in u_ether so other network models would
have that quirk applied as well. All network models have been tested with
ChipIdea UDC driver on NVIDIA Tegra20 SoC that require DMA to be aligned.

Signed-off-by: Dmitry Osipenko <digetx@...>
Signed-off-by: Felipe Balbi <felipe.balbi@...>
(cherry picked from commit 0852659ef071ccd84e85e37195e7c2f3e7c64d1f)
Signed-off-by: Biju Das <biju.das@...>
---
drivers/usb/gadget/function/f_ncm.c | 2 --
drivers/usb/gadget/function/u_ether.c | 2 +-
drivers/usb/gadget/function/u_ether.h | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c
index 025047f..7ad798a 100644
--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -852,8 +852,6 @@ static int ncm_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
*/
ncm->port.is_zlp_ok =
gadget_is_zlp_supported(cdev->gadget);
- ncm->port.no_skb_reserve =
- gadget_avoids_skb_reserve(cdev->gadget);
ncm->port.cdc_filter = DEFAULT_FILTER;
DBG(cdev, "activate ncm\n");
net = gether_connect(&ncm->port);
diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
index 96ec10d..be41ae5 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -1067,7 +1067,7 @@ struct net_device *gether_connect(struct gether *link)

if (result == 0) {
dev->zlp = link->is_zlp_ok;
- dev->no_skb_reserve = link->no_skb_reserve;
+ dev->no_skb_reserve = gadget_avoids_skb_reserve(dev->gadget);
DBG(dev, "qlen %d\n", qlen(dev->gadget, dev->qmult));

dev->header_len = link->header_len;
diff --git a/drivers/usb/gadget/function/u_ether.h b/drivers/usb/gadget/function/u_ether.h
index 81d94a7..c77145b 100644
--- a/drivers/usb/gadget/function/u_ether.h
+++ b/drivers/usb/gadget/function/u_ether.h
@@ -64,7 +64,6 @@ struct gether {
struct usb_ep *out_ep;

bool is_zlp_ok;
- bool no_skb_reserve;

u16 cdc_filter;

--
2.7.4


[RFC PATCH 4/7] usb: renesas_usbhs: set quirk_avoids_skb_reserve if USB-DMAC is used

Biju Das <biju.das@...>
 

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

This patch sets the quirk_avoids_skb_reserve flag to improve performance
of a network gadget driver (e.g. f_ncm.c) if USB-DMAC is used.

For example (on r8a7795 board + f_ncm.c + iperf udp mode / receiving):
- without this patch: 90.3 Mbits/sec
- with this patch: 273 Mbits/sec

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Felipe Balbi <felipe.balbi@...>
(cherry picked from commit ee5acabf5805612c72084276e0c215367a042d71)
Signed-off-by: Biju Das <biju.das@...>
---
drivers/usb/renesas_usbhs/mod_gadget.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c b/drivers/usb/renesas_usbhs/mod_gadget.c
index 8647d2c..8cb3815 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -1122,6 +1122,8 @@ int usbhs_mod_gadget_probe(struct usbhs_priv *priv)
gpriv->gadget.name = "renesas_usbhs_udc";
gpriv->gadget.ops = &usbhsg_gadget_ops;
gpriv->gadget.max_speed = USB_SPEED_HIGH;
+ gpriv->gadget.quirk_avoids_skb_reserve = usbhs_get_dparam(priv,
+ has_usb_dmac);

INIT_LIST_HEAD(&gpriv->gadget.ep_list);

--
2.7.4


[RFC PATCH 3/7] usb: gadget: f_ncm: add support for no_skb_reserve

Biju Das <biju.das@...>
 

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

This patch adds to support no_skb_reserve function to improve
performance for some platforms. About the detail, please refer to
the commit log of "quirk_avoids_skb_reserve" in
include/linux/usb/gadget.h.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Felipe Balbi <felipe.balbi@...>
(cherry picked from commit c4824f11fe07835c63209fb035f03f8f82e12827)
Signed-off-by: Biju Das <biju.das@...>
---
drivers/usb/gadget/function/f_ncm.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c
index 7ad798a..025047f 100644
--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -852,6 +852,8 @@ static int ncm_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
*/
ncm->port.is_zlp_ok =
gadget_is_zlp_supported(cdev->gadget);
+ ncm->port.no_skb_reserve =
+ gadget_avoids_skb_reserve(cdev->gadget);
ncm->port.cdc_filter = DEFAULT_FILTER;
DBG(cdev, "activate ncm\n");
net = gether_connect(&ncm->port);
--
2.7.4


[RFC PATCH 2/7] usb: gadget: u_ether: add a flag to avoid skb_reserve() calling

Biju Das <biju.das@...>
 

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

This patch adds a flag "no_skb_reserve" in struct eth_dev.
So, if a peripheral driver sets the quirk_avoids_skb_reserve flag,
upper network gadget drivers (e.g. f_ncm.c) can avoid skb_reserve()
calling using the flag as well.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Felipe Balbi <felipe.balbi@...>
(cherry picked from commit 05f6b0ff68429bb7c6b84b35e71b522c3bae76ae)
Signed-off-by: Biju Das <biju.das@...>
---
drivers/usb/gadget/function/u_ether.c | 5 ++++-
drivers/usb/gadget/function/u_ether.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
index 7413f89..96ec10d 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -82,6 +82,7 @@ struct eth_dev {
#define WORK_RX_MEMORY 0

bool zlp;
+ bool no_skb_reserve;
u8 host_mac[ETH_ALEN];
u8 dev_mac[ETH_ALEN];
};
@@ -243,7 +244,8 @@ rx_submit(struct eth_dev *dev, struct usb_request *req, gfp_t gfp_flags)
* but on at least one, checksumming fails otherwise. Note:
* RNDIS headers involve variable numbers of LE32 values.
*/
- skb_reserve(skb, NET_IP_ALIGN);
+ if (likely(!dev->no_skb_reserve))
+ skb_reserve(skb, NET_IP_ALIGN);

req->buf = skb->data;
req->length = size;
@@ -1065,6 +1067,7 @@ struct net_device *gether_connect(struct gether *link)

if (result == 0) {
dev->zlp = link->is_zlp_ok;
+ dev->no_skb_reserve = link->no_skb_reserve;
DBG(dev, "qlen %d\n", qlen(dev->gadget, dev->qmult));

dev->header_len = link->header_len;
diff --git a/drivers/usb/gadget/function/u_ether.h b/drivers/usb/gadget/function/u_ether.h
index c77145b..81d94a7 100644
--- a/drivers/usb/gadget/function/u_ether.h
+++ b/drivers/usb/gadget/function/u_ether.h
@@ -64,6 +64,7 @@ struct gether {
struct usb_ep *out_ep;

bool is_zlp_ok;
+ bool no_skb_reserve;

u16 cdc_filter;

--
2.7.4


[RFC PATCH 1/7] usb: gadget: add a new quirk to avoid skb_reserve in u_ether.c

Biju Das <biju.das@...>
 

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

Some platforms (e.g. USB-DMAC on R-Car SoCs) has memory alignment
restriction. If memory alignment is not match, the usb peripheral
driver decides not to use the DMA controller. Then, the performance
is not good.

In the case of u_ether.c, since it calls skb_reserve() in rx_submit(),
it is possible to cause memory alignment mismatch.

So, this patch adds a new quirk "quirk_avoids_skb_reserve" to avoid
skb_reserve() calling in u_ether.c to improve performance.

A peripheral driver will set this flag and network gadget drivers
(e.g. f_ncm.c) will reference the flag via gadget_avoids_skb_reserve().

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Signed-off-by: Felipe Balbi <felipe.balbi@...>
(cherry picked from commit 60e7396f820fa67a007f2a2eb5d97d3e77a74881)
Signed-off-by: Biju Das <biju.das@...>
---
include/linux/usb/gadget.h | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..2ba866f 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -594,6 +594,8 @@ struct usb_gadget_ops {
* enabled HNP support.
* @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
* MaxPacketSize.
+ * @quirk_avoids_skb_reserve: udc/platform wants to avoid skb_reserve() in
+ * u_ether.c to improve performance.
* @is_selfpowered: if the gadget is self-powered.
* @deactivated: True if gadget is deactivated - in deactivated state it cannot
* be connected.
@@ -643,6 +645,7 @@ struct usb_gadget {
unsigned quirk_altset_not_supp:1;
unsigned quirk_stall_not_supp:1;
unsigned quirk_zlp_not_supp:1;
+ unsigned quirk_avoids_skb_reserve:1;
unsigned is_selfpowered:1;
unsigned deactivated:1;
unsigned connected:1;
@@ -708,6 +711,16 @@ static inline int gadget_is_zlp_supported(struct usb_gadget *g)
}

/**
+ * gadget_avoids_skb_reserve - return true iff the hardware would like to avoid
+ * skb_reserve to improve performance.
+ * @g: controller to check for quirk
+ */
+static inline int gadget_avoids_skb_reserve(struct usb_gadget *g)
+{
+ return g->quirk_avoids_skb_reserve;
+}
+
+/**
* gadget_is_dualspeed - return true iff the hardware handles high speed
* @g: controller that might support both high and full speeds
*/
--
2.7.4


[RFC PATCH 0/7] 'SKB reserve' quirk setup to u_ether

Biju Das <biju.das@...>
 

Hi All,

Some platforms (e.g. USB-DMAC on R-Car and RZ/G1 SoCs) has memory
alignment restriction. If memory alignment is not match, the usb
peripheral driver decides not to use the DMA controller.
Then, the performance is not good.

Patch 1-4 --> basically add support only for NCM network model.

Patch 5--> supports for all network models.

Patch 6-->fixes cpulock up condition on the USB DMAC driver

Patch 7--> enables USB DMAC

Renesas USB DMAC driver is not enabled in 4.4 stable kernel.
So not planning to send the patch set to stable kernel.

Cheers,
Biju

Dmitry Osipenko (1):
usb: gadget: f_ncm/u_ether: Move 'SKB reserve' quirk setup to u_ether

Geert Uytterhoeven (1):
ARM: shmobile: defconfig: Enable missing support based on DTSes

Yoshihiro Shimoda (5):
usb: gadget: add a new quirk to avoid skb_reserve in u_ether.c
usb: gadget: u_ether: add a flag to avoid skb_reserve() calling
usb: gadget: f_ncm: add support for no_skb_reserve
usb: renesas_usbhs: set quirk_avoids_skb_reserve if USB-DMAC is used
dmaengine: usb-dmac: fix endless loop in usb_dmac_chan_terminate_all()

arch/arm/configs/shmobile_defconfig | 1 +
drivers/dma/sh/usb-dmac.c | 4 ++--
drivers/usb/gadget/function/u_ether.c | 5 ++++-
drivers/usb/renesas_usbhs/mod_gadget.c | 2 ++
include/linux/usb/gadget.h | 13 +++++++++++++
5 files changed, 22 insertions(+), 3 deletions(-)

--
2.7.4


Re: FW: Your message to cip-dev awaits moderator approval

Jeff ErnstFriedman <jernstfriedman@...>
 

Thank you Chris for your comments.

The value of the recipient limit is set to avoid spam, the current setting is '10' and can be adjusted. I don't see a view into how often this threshold has been triggered to see if this is a first time offense, or that we regularly are missing good content, or if we are somewhere inbetween.

Without objection, I will raise it to 20 and see if that is a workable solution.



Jeff ErnstFriedman
2201 Broadway #604, Oakland, CA 94612
mobile: 510.593.1367
skype: jeffrey.ernstfriedman
twitter: @namdeirf

On Tue, May 22, 2018 at 4:09 AM, Chris Paterson <Chris.Paterson2@...> wrote:
Hi guys,

Anyone know why mailman is queuing emails with lot of recipients? (In this case 16)

I'm not sure this is a great feature for a Kernel mailing list.

Chris


> -----Original Message-----
> From: cip-dev-bounces@...project.org
> [mailto:cip-dev-bounces@lists.cip-project.org]
> Sent: 22 May 2018 11:43
> To: Fabrizio Castro <fabrizio.castro@....com>
> Subject: Your message to cip-dev awaits moderator approval
>
> Your mail to 'cip-dev' with the subject
>
>     [PATCH repost] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond
> accounting
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>     Too many recipients to the message
>
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.  If you would like to cancel
> this posting, please visit the following URL:
>
>     
> https://lists.cip-project.org/mailman/confirm/cip-dev/0257364596438021
> 78ae057c2e864048647b60c2



Re: [PATCH 7/7] gpio: rcar: Add Runtime PM handling for interrupts

Fabrizio Castro <fabrizio.castro@...>
 

Hello Ben,

I would like to drop this patch. I am preparing a new version of this patch suitable for 4.4 stable to send to Greg. I'll put you in copy.

Thanks,
Fab

-----Original Message-----
From: Fabrizio Castro [mailto:fabrizio.castro@...]
Sent: 15 May 2018 12:20
To: Ben Hutchings <ben.hutchings@...>
Cc: cip-dev@...; Chris Paterson <Chris.Paterson2@...>; Biju Das <biju.das@...>; Fabrizio
Castro <fabrizio.castro@...>
Subject: [cip-dev][PATCH 7/7] gpio: rcar: Add Runtime PM handling for interrupts

From: Geert Uytterhoeven <geert+renesas@...>

The R-Car GPIO driver handles Runtime PM for requested GPIOs only.

When using a GPIO purely as an interrupt source, no Runtime PM handling
is done, and the GPIO module's clock may not be enabled.

To fix this:
- Add .irq_request_resources() and .irq_release_resources() callbacks
to handle Runtime PM when an interrupt is requested,
- Add irq_bus_lock() and sync_unlock() callbacks to handle Runtime PM
when e.g. disabling/enabling an interrupt, or configuring the
interrupt type.

Fixes: d5c3d84657db57bd "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
(cherry picked from commit b26a719bdba9aa926ceaadecc66e07623d2b8a53)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
drivers/gpio/gpio-rcar.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 75b2f2c..e38d97d 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -196,6 +196,44 @@ static int gpio_rcar_irq_set_wake(struct irq_data *d, unsigned int on)
return 0;
}

+static void gpio_rcar_irq_bus_lock(struct irq_data *d)
+{
+struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+
+pm_runtime_get_sync(&p->pdev->dev);
+}
+
+static void gpio_rcar_irq_bus_sync_unlock(struct irq_data *d)
+{
+struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+
+pm_runtime_put(&p->pdev->dev);
+}
+
+
+static int gpio_rcar_irq_request_resources(struct irq_data *d)
+{
+struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+int error;
+
+error = pm_runtime_get_sync(&p->pdev->dev);
+if (error < 0)
+return error;
+
+return 0;
+}
+
+static void gpio_rcar_irq_release_resources(struct irq_data *d)
+{
+struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+
+pm_runtime_put(&p->pdev->dev);
+}
+
static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
{
struct gpio_rcar_priv *p = dev_id;
@@ -455,6 +493,10 @@ static int gpio_rcar_probe(struct platform_device *pdev)
irq_chip->irq_unmask = gpio_rcar_irq_enable;
irq_chip->irq_set_type = gpio_rcar_irq_set_type;
irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
+irq_chip->irq_bus_lock = gpio_rcar_irq_bus_lock;
+irq_chip->irq_bus_sync_unlock = gpio_rcar_irq_bus_sync_unlock;
+irq_chip->irq_request_resources = gpio_rcar_irq_request_resources;
+irq_chip->irq_release_resources = gpio_rcar_irq_release_resources;
irq_chip->flags= IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;

ret = gpiochip_add_data(gpio_chip, p);
--
2.7.4



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.


Re: [PATCH 6/7] gpio: rcar: use gpiochip data pointer

Fabrizio Castro <fabrizio.castro@...>
 

Hello Ben,

I would like to drop this patch as it is not applicable to 4.4 stable.

Thanks,
Fab

-----Original Message-----
From: Fabrizio Castro [mailto:fabrizio.castro@...]
Sent: 15 May 2018 12:20
To: Ben Hutchings <ben.hutchings@...>
Cc: cip-dev@...; Chris Paterson <Chris.Paterson2@...>; Biju Das <biju.das@...>; Fabrizio
Castro <fabrizio.castro@...>
Subject: [cip-dev][PATCH 6/7] gpio: rcar: use gpiochip data pointer

From: Linus Walleij <linus.walleij@...>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Ulrich Hecht <ulrich.hecht+renesas@...>
Cc: Geert Uytterhoeven <geert+renesas@...>
Cc: Hisashi Nakamura <hisashi.nakamura.ak@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
(cherry picked from commit c7b6f457cb53bceece484f4c528d1c149995e6c7)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
drivers/gpio/gpio-rcar.c | 33 ++++++++++++---------------------
1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 22c8517..75b2f2c 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -84,8 +84,7 @@ static void gpio_rcar_modify_bit(struct gpio_rcar_priv *p, int offs,
static void gpio_rcar_irq_disable(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
-struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
-gpio_chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);

gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
}
@@ -93,8 +92,7 @@ static void gpio_rcar_irq_disable(struct irq_data *d)
static void gpio_rcar_irq_enable(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
-struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
-gpio_chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);

gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
}
@@ -137,8 +135,7 @@ static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
-struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
-gpio_chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);
unsigned int hwirq = irqd_to_hwirq(d);

dev_dbg(&p->pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
@@ -175,8 +172,7 @@ static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
static int gpio_rcar_irq_set_wake(struct irq_data *d, unsigned int on)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
-struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
-gpio_chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(gc);
int error;

if (p->irq_parent) {
@@ -218,16 +214,11 @@ static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
return irqs_handled ? IRQ_HANDLED : IRQ_NONE;
}

-static inline struct gpio_rcar_priv *gpio_to_priv(struct gpio_chip *chip)
-{
-return container_of(chip, struct gpio_rcar_priv, gpio_chip);
-}
-
static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,
unsigned int gpio,
bool output)
{
-struct gpio_rcar_priv *p = gpio_to_priv(chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(chip);
unsigned long flags;

/* follow steps in the GPIO documentation for
@@ -251,7 +242,7 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,

static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset)
{
-struct gpio_rcar_priv *p = gpio_to_priv(chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(chip);
int error;

error = pm_runtime_get_sync(&p->pdev->dev);
@@ -267,7 +258,7 @@ static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset)

static void gpio_rcar_free(struct gpio_chip *chip, unsigned offset)
{
-struct gpio_rcar_priv *p = gpio_to_priv(chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(chip);

pinctrl_free_gpio(chip->base + offset);

@@ -291,15 +282,15 @@ static int gpio_rcar_get(struct gpio_chip *chip, unsigned offset)

/* testing on r8a7790 shows that INDT does not show correct pin state
* when configured as output, so use OUTDT in case of output pins */
-if (gpio_rcar_read(gpio_to_priv(chip), INOUTSEL) & bit)
-return !!(gpio_rcar_read(gpio_to_priv(chip), OUTDT) & bit);
+if (gpio_rcar_read(gpiochip_get_data(chip), INOUTSEL) & bit)
+return !!(gpio_rcar_read(gpiochip_get_data(chip), OUTDT) & bit);
else
-return !!(gpio_rcar_read(gpio_to_priv(chip), INDT) & bit);
+return !!(gpio_rcar_read(gpiochip_get_data(chip), INDT) & bit);
}

static void gpio_rcar_set(struct gpio_chip *chip, unsigned offset, int value)
{
-struct gpio_rcar_priv *p = gpio_to_priv(chip);
+struct gpio_rcar_priv *p = gpiochip_get_data(chip);
unsigned long flags;

spin_lock_irqsave(&p->lock, flags);
@@ -466,7 +457,7 @@ static int gpio_rcar_probe(struct platform_device *pdev)
irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
irq_chip->flags= IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;

-ret = gpiochip_add(gpio_chip);
+ret = gpiochip_add_data(gpio_chip, p);
if (ret) {
dev_err(dev, "failed to add GPIO controller\n");
goto err0;
--
2.7.4



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.


New CIP Blog post

Maemalynn Meanor <maemalynn@...>
 

CIP Community:

As you know, CIP will be at Open Source Summit Japan on June 20-22. To see a preview of the demos, the speaking opportunities or to obtain our 20% discount code for registration, please read our latest blog post. You can find the blog here: https://www.cip-project.org/blog/2018/05/21/join-cip-at-open-source-summit-japan

As always, we ask that you share this with your social network. If you’d like to retweet us, you can do so here: https://twitter.com/cip_project/status/998822020325564416

Below are a few sample posts as well. 

Facebook/LinkedIn:
Join the CIP Project at Open Source Summit on June 20-22. Stop by the booth to see interactive demos, attend one of the three speaking opportunities or meet with one of our leaders to discuss the testing roadmap and the importance CIP has on the city of the future. 

Twitter:
.@cip_project will be at #OSSummit Japan. To see a preview of activities or to use CIP’s 20% discount code, take a look at this new #blog post: #opensource #LinuxFoundation #ciptesting

Please let us know if you have any questions.

Thank you!
Mae

Maemalynn Meanor
PR Manager 
The Linux Foundation
Maemalynn@...
(602) 541-0356
Skype: Maemalynn






FW: Your message to cip-dev awaits moderator approval

Chris Paterson
 

Hi guys,

Anyone know why mailman is queuing emails with lot of recipients? (In this case 16)

I'm not sure this is a great feature for a Kernel mailing list.

Chris

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...]
Sent: 22 May 2018 11:43
To: Fabrizio Castro <fabrizio.castro@...>
Subject: Your message to cip-dev awaits moderator approval

Your mail to 'cip-dev' with the subject

[PATCH repost] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond
accounting

Is being held until the list moderator can review it for approval.

The reason it is being held:

Too many recipients to the message

Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:


https://lists.cip-project.org/mailman/confirm/cip-dev/0257364596438021
78ae057c2e864048647b60c2


[PATCH repost] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting

Fabrizio Castro <fabrizio.castro@...>
 

From: John Stultz <john.stultz@...>

commit 3d88d56c5873f6eebe23e05c3da701960146b801 upstream.

Due to how the MONOTONIC_RAW accumulation logic was handled,
there is the potential for a 1ns discontinuity when we do
accumulations. This small discontinuity has for the most part
gone un-noticed, but since ARM64 enabled CLOCK_MONOTONIC_RAW
in their vDSO clock_gettime implementation, we've seen failures
with the inconsistency-check test in kselftest.

This patch addresses the issue by using the same sub-ns
accumulation handling that CLOCK_MONOTONIC uses, which avoids
the issue for in-kernel users.

Since the ARM64 vDSO implementation has its own clock_gettime
calculation logic, this patch reduces the frequency of errors,
but failures are still seen. The ARM64 vDSO will need to be
updated to include the sub-nanosecond xtime_nsec values in its
calculation for this issue to be completely fixed.

Signed-off-by: John Stultz <john.stultz@...>
Tested-by: Daniel Mentz <danielmentz@...>
Cc: Prarit Bhargava <prarit@...>
Cc: Kevin Brodsky <kevin.brodsky@...>
Cc: Richard Cochran <richardcochran@...>
Cc: Stephen Boyd <stephen.boyd@...>
Cc: Will Deacon <will.deacon@...>
Cc: "stable #4 . 8+" <stable@...>
Cc: Miroslav Lichvar <mlichvar@...>
Link: http://lkml.kernel.org/r/1496965462-20003-3-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@...>
[fabrizio: cherry-pick to 4.4. Kept cycle_t type for function
logarithmic_accumulation local variable "interval". Dropped
casting of "interval" variable]
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Signed-off-by: Biju Das <biju.das@...>
---
Hello Greg,

I am reposting this patch to include the relevant people in the email.
Could you please consider this patch for 4.4.y?
Testing 4.4.y without this patch makes tool
tools/testing/selftests/timers/clocksource-switch.c fail on Koelsch board
while running "Consistent CLOCK_MONOTONIC_RAW" with message "Delta: 1 ns".
This patch fixes the problem.

Thanks,
Fab

include/linux/timekeeper_internal.h | 4 ++--
kernel/time/timekeeping.c | 20 ++++++++++----------
2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/linux/timekeeper_internal.h b/include/linux/timekeeper_internal.h
index f0f1793..115216e 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -56,7 +56,7 @@ struct tk_read_base {
* interval.
* @xtime_remainder: Shifted nano seconds left over when rounding
* @cycle_interval
- * @raw_interval: Raw nano seconds accumulated per NTP interval.
+ * @raw_interval: Shifted raw nano seconds accumulated per NTP interval.
* @ntp_error: Difference between accumulated time and NTP time in ntp
* shifted nano seconds.
* @ntp_error_shift: Shift conversion between clock shifted nano seconds and
@@ -97,7 +97,7 @@ struct timekeeper {
cycle_t cycle_interval;
u64 xtime_interval;
s64 xtime_remainder;
- u32 raw_interval;
+ u64 raw_interval;
/* The ntp_tick_length() value currently being used.
* This cached copy ensures we consistently apply the tick
* length for an entire tick, as ntp_tick_length may change
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6e48668..fed86b2 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -277,8 +277,7 @@ static void tk_setup_internals(struct timekeeper *tk, struct clocksource *clock)
/* Go back from cycles -> shifted ns */
tk->xtime_interval = (u64) interval * clock->mult;
tk->xtime_remainder = ntpinterval - tk->xtime_interval;
- tk->raw_interval =
- ((u64) interval * clock->mult) >> clock->shift;
+ tk->raw_interval = interval * clock->mult;

/* if changing clocks, convert xtime_nsec shift units */
if (old_clock) {
@@ -1767,7 +1766,7 @@ static cycle_t logarithmic_accumulation(struct timekeeper *tk, cycle_t offset,
unsigned int *clock_set)
{
cycle_t interval = tk->cycle_interval << shift;
- u64 raw_nsecs;
+ u64 snsec_per_sec;

/* If the offset is smaller than a shifted interval, do nothing */
if (offset < interval)
@@ -1782,14 +1781,15 @@ static cycle_t logarithmic_accumulation(struct timekeeper *tk, cycle_t offset,
*clock_set |= accumulate_nsecs_to_secs(tk);

/* Accumulate raw time */
- raw_nsecs = (u64)tk->raw_interval << shift;
- raw_nsecs += tk->raw_time.tv_nsec;
- if (raw_nsecs >= NSEC_PER_SEC) {
- u64 raw_secs = raw_nsecs;
- raw_nsecs = do_div(raw_secs, NSEC_PER_SEC);
- tk->raw_time.tv_sec += raw_secs;
+ tk->tkr_raw.xtime_nsec += (u64)tk->raw_time.tv_nsec << tk->tkr_raw.shift;
+ tk->tkr_raw.xtime_nsec += tk->raw_interval << shift;
+ snsec_per_sec = (u64)NSEC_PER_SEC << tk->tkr_raw.shift;
+ while (tk->tkr_raw.xtime_nsec >= snsec_per_sec) {
+ tk->tkr_raw.xtime_nsec -= snsec_per_sec;
+ tk->raw_time.tv_sec++;
}
- tk->raw_time.tv_nsec = raw_nsecs;
+ tk->raw_time.tv_nsec = tk->tkr_raw.xtime_nsec >> tk->tkr_raw.shift;
+ tk->tkr_raw.xtime_nsec -= (u64)tk->raw_time.tv_nsec << tk->tkr_raw.shift;

/* Accumulate error between NTP and clock interval */
tk->ntp_error += tk->ntp_tick << shift;
--
2.7.4


Re: [PATCH 57/62] thermal: rcar: enable to use thermal-zone on DT

Biju Das <biju.das@...>
 

Hi Ben,

Thanks for the feedback.

Subject: Re: [PATCH 57/62] thermal: rcar: enable to use thermal-zone on DT

On Thu, 2018-05-10 at 16:08 +0100, Biju Das wrote:
From: Kuninori Morimoto <kuninori.morimoto.gx@...>

This patch enables to use thermal-zone on DT if it was calles as
"renesas,rcar-thermal-gen2".
Previous style (= non thermal-zone) is still supported by
"renesas,rcar-thermal" to keep compatibility for "git bisect".

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...>
Signed-off-by: Eduardo Valentin <edubezval@...> (cherry picked
from commit 8b477ea56383dc8b838f1f8b506e4571c14ceb30)
Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Fabrizio Castro <fabrizio.castro@...>
[...]
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
[...]
@@ -463,7 +492,13 @@ static int rcar_thermal_probe(struct
platform_device *pdev)
if (ret < 0)
goto error_unregister;

-priv->zone = thermal_zone_device_register("rcar_thermal",
+if (of_data == USE_OF_THERMAL)
+priv->zone = thermal_zone_of_sensor_register(
+dev, i, priv,
+
&rcar_thermal_zone_of_ops);

Doesn't this require a corresponding change to use
thermal_zone_of_sensor_unregister()?
As per the commit(d4b23c5c434a) message "devm_thermal_zone_of_sensor_register() case doesn't need to call thermal_zone_device_unregister()"

We are not using devm version of thermal_zone_of_sensor_register, so I guess the below commit is not required.
d4b23c5c434a ("thermal: rcar_thermal: don't call thermal_zone_device_unregister when USE_OF_THERMAL")

It looks like this was fixed upstream by commits 5e325868aa59
("thermal: convert rcar_thermal to use
devm_thermal_zone_of_sensor_register") and d4b23c5c434a ("thermal:
rcar_thermal: don't call thermal_zone_device_unregister when
USE_OF_THERMAL").
The commit 5e325868aa59 ("thermal: convert rcar_thermal to use devm_thermal_zone_of_sensor_register")
depend upon the commit e498b4984 ("thermal: of-thermal: Add devm version of thermal_zone_of_sensor_register")
which is outside the scope of renesas thermal driver.

Are you ok for backporting the above patch? If yes, then it make sense to backport the commits 5e325868aa59 and d4b23c5c434a.

Regards,
Biju







Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.


Re: Backport for LTS 4.4.129 for LTP fnctl35 tests

Daniel Sangorrin <daniel.sangorrin@...>
 

Ben, Daniel:

-----Original Message-----
From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: Friday, May 18, 2018 3:15 AM
To: Daniel Wagner <daniel.wagner@...>; Daniel Sangorrin
<daniel.sangorrin@...>; cip-dev@...
Cc: fuego@...
Subject: Re: [cip-dev] Backport for LTS 4.4.129 for LTP fnctl35 tests

On Thu, 2018-05-17 at 10:53 +0200, Daniel Wagner wrote:
Hi Daniel,

On 05/17/2018 10:33 AM, Daniel Sangorrin wrote:
Dear Ben,

The other day I mentioned on the list[1] that after running LTP with
Fuego there were a few test cases failing that needed investigation.

I reviewed the first one (fcntl35 and fcntl35_64). According to the
comments on the LTP fcntl35.c file (by Xiao Yang <yangx.jy@...>)
the bug tested by this test case was fixed by:
commit 086e774a57fba4695f14383c0818994c0b31da7c
Author: Michael Kerrisk (man-pages) <mtk.manpages@...>
Date: Tue Oct 11 13:53:43 2016 -0700

I backported that patch, see next e-mail:
[PATCH] pipe: cap initial pipe capacity according to pipe-max-size

I tested again and confirmed that the patch fixed the bug.

Before:
fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536
unexpectedly, expected 4096
After:
fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096
successfully

If you think the patch is OK (as mentor) I can send it to the LTS mailing list
myself.

Wouldn't it make sense to send it (also?) to Greg to include into the
stable trees?
I agree, this looks like suitable for stable.
OK, I got confused by this e-mail.
https://lists.cip-project.org/pipermail/cip-dev/2018-April/001061.html
I will send the patch directly to the stable mailing list then.

Thanks,
Daniel


Linux 4.4.130-cip23

Ben Hutchings <ben.hutchings@...>
 

I've released Linux version 4.4.130-cip23.  A summary of the changes
since 4.4.126-cip22:

- Merge fixes from stable versions 4.4.127-4.4.130 inclusive
- Fix a few stable regressions

I haven't yet reviewed later changes on the 4.4-stable branch (and no-
one else has reported doing so) so I didn't think I should merge them
yet.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 0/7] Add HDMI support to iwg20d

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2018-05-15 at 12:19 +0100, Fabrizio Castro wrote:
Dear Ben,

this series adds HDMI video output to iWave's iwg20d board.

I had to take out interrupt (hotplug) support from the hdmi DT node as
it looks like commit 9183e45db7774716d056319c237a4185baba19c7 introduced
"connector" data field with struct adv7511, but drm_connector_init was
left behind, and as such connector.dev is NULL, and that causes issues
to function adv7511_hpd_work, preventing HDMI hotplug from working
properly.

While investigating HDMI hotplugging, I have found out that when using
a GPIO purely as an interrupt source the corresponding GPIO module
clock is not enabled, therefore this series backports the fix for this.
I yet have to check if this fix is any good to 4.4 LTS, I'll send it to
stable@... in case it works for 4.4 LTS too.

This series applies on top of tag v4.4.126-cip22.
[...]

Sorry, I didn't have time to look at this yet. I will review it when I
get back from holiday on the 29th.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Backport for LTS 4.4.129 for LTP fnctl35 tests

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2018-05-17 at 10:53 +0200, Daniel Wagner wrote:
Hi Daniel,

On 05/17/2018 10:33 AM, Daniel Sangorrin wrote:
Dear Ben,

The other day I mentioned on the list[1] that after running LTP with
Fuego there were a few test cases failing that needed investigation.

I reviewed the first one (fcntl35 and fcntl35_64). According to the
comments on the LTP fcntl35.c file (by Xiao Yang <yangx.jy@...>)
the bug tested by this test case was fixed by:
    commit 086e774a57fba4695f14383c0818994c0b31da7c
    Author: Michael Kerrisk (man-pages) <mtk.manpages@...>
    Date:   Tue Oct 11 13:53:43 2016 -0700

I backported that patch, see next e-mail:
[PATCH] pipe: cap initial pipe capacity according to pipe-max-size

I tested again and confirmed that the patch fixed the bug.

Before:
fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536 unexpectedly, expected 4096
After:
fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096 successfully

If you think the patch is OK (as mentor) I can send it to the LTS mailing list myself.
Wouldn't it make sense to send it (also?) to Greg to include into the
stable trees?
I agree, this looks like suitable for stable.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Backport for LTS 4.4.129 for LTP fnctl35 tests

Daniel Wagner <daniel.wagner@...>
 

Hi Daniel,

On 05/17/2018 10:33 AM, Daniel Sangorrin wrote:
Dear Ben,

The other day I mentioned on the list[1] that after running LTP with
Fuego there were a few test cases failing that needed investigation.

I reviewed the first one (fcntl35 and fcntl35_64). According to the
comments on the LTP fcntl35.c file (by Xiao Yang <yangx.jy@...>)
the bug tested by this test case was fixed by:
commit 086e774a57fba4695f14383c0818994c0b31da7c
Author: Michael Kerrisk (man-pages) <mtk.manpages@...>
Date: Tue Oct 11 13:53:43 2016 -0700

I backported that patch, see next e-mail:
[PATCH] pipe: cap initial pipe capacity according to pipe-max-size

I tested again and confirmed that the patch fixed the bug.

Before:
fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536 unexpectedly, expected 4096
After:
fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096 successfully

If you think the patch is OK (as mentor) I can send it to the LTS mailing list myself.
Wouldn't it make sense to send it (also?) to Greg to include into the
stable trees?

Thanks,
Daniel

8321 - 8340 of 9541