[PATCH v1] soc: renesas: rcar-sysc:- Prevent resource leake and NULL-pointer error

If rcar_sysc_pd_init will fail, Handle ERROR properly. -Release memory -Unmap I/O memory from kernel address space. In rcar_sysc_init, If ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. Signed-off-by: Arvind Yadav ---

Re: [PATCH 1/2] dt-bindings: document renesas-ostm timer

Hi Chris, On Fri, Jan 20, 2017 at 4:56 AM, Chris Brandt wrote: > On Monday, January 16, 2017, Geert Uytterhoeven wrote: >> As they're independent channels, it doesn't matter which one is used for >> which function, right? >> >> You could use the first probed channel for

Re: [PATCHv6 0/4] thermal: add driver for R-Car Gen3

Hi Eduardo, On 2017-01-19 20:31:03 -0800, Eduardo Valentin wrote: > On Thu, Dec 22, 2016 at 11:38:19AM +0100, Niklas Söderlund wrote: > > Hi all, > > > > Add this to my tree and to my linux-next branch. However, as usual, I am > taking the driver+docs, the dt binding must go through your arch

[RFC PATCH 2/2] drm: rcar-du: Allow for handling multiple sg table entries by IOMMU mapping

By having implemented dma-mapping through the VSP1 device, non physical contiguous memory can be handled by mapping it to the IOVA space with IOMMU, so we can use not only CMA objects but can import multiple sg table entries as dma-buf. This patch allows multiple sg table entries to be imported

[RFC PATCH 1/2] drm: rcar-du: Don't create a new sg table for dma-mapping when importing other driver's dma-buf

CMA GEM object imported from other devices already contain a valid sg-table, so there is no need to try to recreate it. Also, dma_get_sgtable() should be given a valid virtual address, (which is used for example when an IOMMU is present) but the cma import helper does not set this field.

[RFC PATCH 0/2] drm: rcar-du: Support importing multiple sg table entries via dma-buf

This patch series add support for importing dma-bufs with multiple sg table entries, exported from other drivers into the DU. The patches are based on the salvator-x-hdmi-prototype-2016-08-30-v4.8-rc4 topic branch in geert's git repository, which has IOMMU mapping support in the rcar-du driver.

Re: The failure summary report of GEN2 for linux stable v4.10-rc2

Dear Mr Laurent, Thank you for your quick reply. This is the log file contains information about the command "modetest -M rcar-du" (with the HDMI cable plugged). Thank you very much. Jinso Linux team Dong On 01/20/2017 08:49 AM, Laurent Pinchart wrote: Dear Dong, On Thursday 19 Jan 2017

RE: [PATCH 1/2] dt-bindings: document renesas-ostm timer

Hi Geert, On Monday, January 16, 2017, Geert Uytterhoeven wrote: > As they're independent channels, it doesn't matter which one is used for > which function, right? > > You could use the first probed channel for the most important function > (clocksource?), and the second one for the other

Re: The failure summary report of GEN2 for linux stable v4.10-rc2

Dear Dong, On Thursday 19 Jan 2017 18:14:45 DongCV wrote: > Dear Mr Laurent > > I apologize for the misunderstanding. No worries, I should have been more precise. > I've retested the HDMI output on Lager(H2) with v4.10-rc2. > > The results: > > Enabled CMA: > > The HDMI cable unplugged:

Re: [PATCH] watchdog: softdog: make pretimeout support a compile option

> > +#if IS_ENABLED(CONFIG_SOFT_WATCHDOG_PRETIMEOUT) > > static void softdog_pretimeout(unsigned long data) > > I would prefer __maybe_unused here .. > > > { > > watchdog_notify_pretimeout(_dev); > > @@ -82,16 +83,23 @@ static void softdog_pretimeout(unsigned long data) > > static struct

[PATCH v2 2/3] mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS

QUIRK sounds like there is something wrong, but actually there are just some bits which need to be 1. Rename it to be more clear. Signed-off-by: Wolfram Sang --- Change since RFC: make comments more precise drivers/mmc/host/sh_mobile_sdhi.c | 6 ++

[PATCH v2 1/3] mmc: host: tmio: refactor calls to sdio irq

tmio_mmc_sdio_irq() is not used as a seperate irq handler anymore, so we can make it similar to the other irq helper functions, namely: * only give the host as argument function which is what it really needs * prefix function name with __ Signed-off-by: Wolfram Sang

[PATCH v2 3/3] mmc: tmio: discard obsolete SDIO irqs before enabling irqs

Before enabling SDIO irqs, clear the status bit, so we discard old and stale interrupts. Needed to get two wireless cards working. Use the newly introduced macro in all places. Signed-off-by: Wolfram Sang --- Change since RFC: use #define for SETBITS_MASK

[PATCH 0/3] mmc: host: tmio: sdio irq improvements

Here is a small series with two minor improvements (patches 1+2) and one bigger change (patch 3) for SDIO handling with TMIO/SDHI. Since RFC, I addressed all comments (Thanks Simon!) and since it is needed for the WLAN cards, I think it should go in now. Wolfram Sang (3): mmc: host: tmio:

Re: [RFC 3/3] mmc: tmio: discard obsolete SDIO irqs before enabling irqs

> > + if (host->pdata->flags & TMIO_MMC_SDIO_STATUS_SETBITS) > > + sdio_status |= 6; > > Perhaps a #define would be an improvement over "6". OK.

Re: [RFC 2/3] mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS

> > --- a/include/linux/mfd/tmio.h > > +++ b/include/linux/mfd/tmio.h > > @@ -97,7 +97,7 @@ > > /* > > * Some controllers needs to set 1 on SDIO status reserved bits > > */ > > Is the following update to the above appropriate? > In particular, is it some or all? Some. > * Controllers

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks

On Wed, Jan 18, 2017 at 12:25:00PM -0500, Chris Brandt wrote: > Some controllers have 2 clock sources instead of 1, so they both need > to be turned on/off. > > Signed-off-by: Chris Brandt Reviewed-by: Wolfram Sang signature.asc

Re: [PATCH v3 2/3] mmc: sh_mobile_sdhi: explain clock bindings

On Wed, Jan 18, 2017 at 12:25:01PM -0500, Chris Brandt wrote: > In the case of a single clock source, you don't need names. However, > if the controller has 2 clock sources, you need to name them correctly > so the driver can find the 2nd one. > > Signed-off-by: Chris Brandt

Re: [PATCHv5 1/2] iio: adc: Add Maxim MAX11100 driver

> Add iio driver for Maxim MAX11100 single-channel ADC. minor comments, maybe Jonathan can fix it up when taking this... > Signed-off-by: Jacopo Mondi > Tested-by: Marek Vasut > --- > drivers/iio/adc/Kconfig| 9 +++ >

Re: About Rcar Du

Hellu Stuvart, On Thursday 19 Jan 2017 23:06:08 Stuvart S wrote: > Hi Laurent, > > Thank you for that information. I am not meaning to capture the > frames to memory but, I have my own C code snippet to alter image to > some other forms which reads from a frame buffer ..here I am going to > do

RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

Hello Hans, Do you have any further feedback on this? Thanks, Chris > From: Ramesh Shanmugasundaram > Sent: 10 January 2017 09:31 > Hi Laurent, > > > > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram > wrote: > > > Add binding documentation for Renesas R-Car Digital Radio >

Re: About Rcar Du

Hi Laurent, Thank you for that information. I am not meaning to capture the frames to memory but, I have my own C code snippet to alter image to some other forms which reads from a frame buffer ..here I am going to do the tapping of image data from DU and modify according to my code and

Re: [PATCH v3] pinctrl: sh-pfc: r8a7791: Add ADI pinconf support

Hi Marek, On 19/01/2017 17:06, Marek Vasut wrote: Please add my Tested-by: Marek Vasut Thanks! Sending to renesas-soc list as well as, if I'm not wrong, PFC patches go through Geert's tree -- To unsubscribe from this list: send the line "unsubscribe linux-gpio"

Re: About Rcar Du

Hello Stuvart, On Thursday 19 Jan 2017 09:43:16 Stuvart S wrote: > On Thu, Jan 19, 2017 at 2:44 PM Laurent Pinchart wrote: > > On Thursday 19 Jan 2017 08:24:38 Stuvart S wrote: > >> Hi Laurent and all, > >> > >> I would like to ask a very basic question here .. I have an Rcar E2 > >> board with

Re: [PATCHv6 0/4] thermal: add driver for R-Car Gen3

> larger. Therefore I would like to ask Morimoto-san and/or Khiem to > provide or proxy testing of this less accurate formula and feedback if > it's OK, let me know if there is anything I can do to help out. We now got the results of Renesas internal testing via internal channels. So, for this

Re: [PATCH v3 3/8] gpio: gpio-rz: GPIO driver for Renesas RZ series

Hi Linus, On Thu, Jan 19, 2017 at 10:27 AM, Linus Walleij wrote: > On Wed, Jan 18, 2017 at 3:06 PM, Geert Uytterhoeven > wrote: >> On Wed, Jan 18, 2017 at 2:58 PM, Linus Walleij >> wrote: + gpio_chip->request

Re: [PATCH v3 3/8] gpio: gpio-rz: GPIO driver for Renesas RZ series

On Thu, Jan 19, 2017 at 10:36 AM, Geert Uytterhoeven wrote: > On Thu, Jan 19, 2017 at 10:27 AM, Linus Walleij > wrote: >> On Wed, Jan 18, 2017 at 3:06 PM, Geert Uytterhoeven >> wrote: >>> On Wed, Jan 18, 2017 at 2:58 PM,

Re: [PATCH v3 3/8] gpio: gpio-rz: GPIO driver for Renesas RZ series

On Wed, Jan 18, 2017 at 3:06 PM, Geert Uytterhoeven wrote: > Hi Linus, > > On Wed, Jan 18, 2017 at 2:58 PM, Linus Walleij > wrote: >>> + gpio_chip->request = rz_gpio_request; >>> + gpio_chip->free = rz_gpio_free; >>> +