Re: [PATCH v2 1/3] dmaengine: rcar-dmac: store channel IRQ in struct rcar_dmac_chan

On Tue, May 16, 2017 at 01:09:15AM +0200, Niklas Söderlund wrote: > The IRQ number is needed after probe to be able to add synchronisation > points in other places in the driver when freeing resources and to > implement a device_synchronize() callback. Store the IRQ number in the > struct

Re: [PATCH/RFC 1/2] clk: renesas: Rework Kconfig and Makefile logic

On 04/25, Geert Uytterhoeven wrote: > The goals are to: > - Allow precise control over and automatic selection of which > (sub)drivers are used for which SoC (which may change in the > future), > - Allow adding support for new SoCs easily, > - Allow compile-testing of all

[PATCH 4/4] ASoC: audio-graph-scu-card: tidyup return method from probe()

From: Kuninori Morimoto Current return method from probe() is very confusable. This patch tidyup it to normal return method Reported-by: Dan Carpenter Signed-off-by: Kuninori Morimoto ---

[PATCH 2/4] ASoC: simple-scu-card: tidyup return method from probe()

From: Kuninori Morimoto Current return method from probe() is very confusable. This patch tidyup it to normal return method Reported-by: Dan Carpenter Signed-off-by: Kuninori Morimoto ---

[PATCH 0/4] ASoC: tidyup return method from probe()

Hi Mark As Dan reported, current simple / simple-scu / audio-graph / audio-grach-scu(it is now posting) are using strange return method on probe() These patches fix these up. Kuninori Morimoto (4): ASoC: simple-card: tidyup return method from probe() ASoC: simple-scu-card: tidyup return

Re: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Shimoda-san, I just saw that you patch predates mine. I will drop my version and integrate yours. Many thanks for for your support, Petre On Fri, May 19, 2017 at 12:50 AM, Petre Pircalabu wrote: > Hi Geert, Shimoda-san, > > I have also used initialy the name

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

Hi Laurent, On Fri, May 19, 2017 at 12:59:12AM +0300, Laurent Pinchart wrote: > Hi Sakari, > > On Friday 19 May 2017 00:05:17 Sakari Ailus wrote: > > On Thu, May 18, 2017 at 11:54:46PM +0300, Laurent Pinchart wrote: > > > On Thursday 18 May 2017 23:50:34 Sakari Ailus wrote: > > >> On Thu, May

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

On 05/18/2017 01:36 PM, Geert Uytterhoeven wrote: > Hi Andrew, > > On Thu, May 18, 2017 at 9:34 PM, Andrew Lunn wrote: This most certainly works fine in the simple case where you have one PHY hanging off the MDIO bus, now what happens if you have several?

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

Hi Sakari, On Friday 19 May 2017 00:05:17 Sakari Ailus wrote: > On Thu, May 18, 2017 at 11:54:46PM +0300, Laurent Pinchart wrote: > > On Thursday 18 May 2017 23:50:34 Sakari Ailus wrote: > >> On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote: > >>> On Wednesday 17 May 2017 22:20:57

Re: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Geert, Shimoda-san, I have also used initialy the name "use-xtal-clk" to describe the flag, but I've changed it to "use-on-chip-clk" to make a clear distinction between the on-chip and the external clocks. If you think "usb-extal" is more descriptive I can change he name to this value.

Re: [PATCH v3 2/2] media: i2c: adv748x: add adv748x driver

Hi Kieran, Thank you for the patch. On Wednesday 17 May 2017 15:13:18 Kieran Bingham wrote: > From: Kieran Bingham > > Provide basic support for the ADV7481 and ADV7482. > > The driver is modelled with 2 subdevices to allow simultaneous streaming >

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

Hi Kieran, On Thu, May 18, 2017 at 01:04:55PM +0100, Kieran Bingham wrote: > Hi Sakari, > > >>> In omap3isp/isp.c: isp_fwnodes_parse() the async notifier is registered > >>> looking > >>> at the endpoints parent fwnode: > >>> > >>> isd->asd.match.fwnode.fwnode = > >>>

[RFC PATCH 0/2] i2c: sh_mobile: remove platform_data support

Here is a cleanup series for the i2c-sh_mobile driver. Patch 1 states why I think it can safely be removed, but I certainly want others people feedback on this, so this is RFC for now. Found while cleaning up include/linux/i2c. Wolfram Sang (2): i2c: sh_mobile: remove platform_data i2c:

[RFC PATCH 2/2] i2c: sh_mobile: drop needless check for of_node

After removal of platform_data support, we can simplify OF handling. of_match_device() evaluates to NULL if !CONFIG_OF or if there is no node pointer for that device, so we can remove the check for the node ptr. Signed-off-by: Wolfram Sang ---

[RFC PATCH 1/2] i2c: sh_mobile: remove platform_data

No platform currently upstream makes use of this platform_data anymore. The ones that did are converted to DT meanwhile. So, remove it. The old platforms likely don't have the 'clks_per_cnt' feature, otherwise it would have been implemented by now. And in the unlikely case they need to setup a

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

Hi Laurent, On Thu, May 18, 2017 at 11:54:46PM +0300, Laurent Pinchart wrote: > Hi Sakari, > > On Thursday 18 May 2017 23:50:34 Sakari Ailus wrote: > > On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote: > > > On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote: > > >> On Wed, May

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

Hi Sakari, On Thursday 18 May 2017 23:50:34 Sakari Ailus wrote: > On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote: > > On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote: > >> On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote: > >>> From: Kieran Bingham

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

Hi Laurent, On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote: > Hi Sakari, > > On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote: > > On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote: > > > From: Kieran Bingham > > > > >

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

Hi Andrew, On Thu, May 18, 2017 at 9:34 PM, Andrew Lunn wrote: >> > This most certainly works fine in the simple case where you have one PHY >> > hanging off the MDIO bus, now what happens if you have several? >> > >> > Presumably, the first PHY that returns EPROBE_DEFER will

Re: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Geert, Shimoda-san, First, thank you very much for your comments. I will refactor the patch and send a v2 patchset as soon as possible. To my understanding, although the RCAR Gen3 HW manual references the clk frequencies (50MHz for XTAL and 100MHz for external clock) the actual register

Re: [PATCH v2 0/6] mmc: renesas-sdhi: refactor DMA support

On Wed, May 10, 2017 at 11:25:24AM +0200, Simon Horman wrote: > Hi Wolfram, Hi Ulf, Hi Arnd, Hi all, > > the intention of this patch-set is to refactor the DMA support in > the Renesas SDHI driver in order to make it easier to add support > for using the SDHI hardware with different DMA

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

> > This most certainly works fine in the simple case where you have one PHY > > hanging off the MDIO bus, now what happens if you have several? > > > > Presumably, the first PHY that returns EPROBE_DEFER will make the entire > > bus registration return EPROB_DEFER as well, and so on, and so

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

Hi Florian, On Thu, May 18, 2017 at 8:25 PM, Florian Fainelli wrote: > On 05/18/2017 05:59 AM, Geert Uytterhoeven wrote: >> If an Ethernet PHY is initialized before the interrupt controller it is >> connected to, a message like the following is printed: >> >> irq: no

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

On 05/18/2017 05:59 AM, Geert Uytterhoeven wrote: > If an Ethernet PHY is initialized before the interrupt controller it is > connected to, a message like the following is printed: > > irq: no irq domain found for /interrupt-controller@e61c ! > > However, the actual error is ignored,

Re: [PATCH 2/2] sh_eth: Do not print an error message for probe deferral

On 05/18/2017 04:01 PM, Geert Uytterhoeven wrote: EPROBE_DEFER is not an error, hence printing an error message like sh-eth ee70.ethernet: failed to initialise MDIO may confuse the user. To fix this, suppress the error message in case of probe deferral. While at it, shorten the

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

> >> phy = get_phy_device(mdio, addr, is_c45); > >> if (IS_ERR(phy)) > >> - return; > >> + return PTR_ERR(phy); > >> > >> - rc = irq_of_parse_and_map(child, 0); > >> + rc = of_irq_get(child, 0); > >> + if (rc == -EPROBE_DEFER) { > >> +

Re: [PATCH 1/2] sh_eth: Use platform device for printing before register_netdev()

On 05/18/2017 04:01 PM, Geert Uytterhoeven wrote: The MDIO initialization failure message is printed using the network device, before it has been registered, leading to: (null): failed to initialise MDIO Use the platform device instead to fix this: sh-eth ee70.ethernet: failed

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

Hi Andrew, On Thu, May 18, 2017 at 6:09 PM, Andrew Lunn wrote: > On Thu, May 18, 2017 at 02:59:05PM +0200, Geert Uytterhoeven wrote: >> If an Ethernet PHY is initialized before the interrupt controller it is >> connected to, a message like the following is printed: >> >> irq:

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

On Thu, May 18, 2017 at 02:59:05PM +0200, Geert Uytterhoeven wrote: > If an Ethernet PHY is initialized before the interrupt controller it is > connected to, a message like the following is printed: > > irq: no irq domain found for /interrupt-controller@e61c ! > > However, the actual

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

Hi Sakari, On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote: > On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote: > > From: Kieran Bingham > > > > Return NULL, if a null entity is parsed for it's v4l2_subdev > > > > Signed-off-by:

Re: [PATCH v4 5/6] spi: slave: Add SPI slave handler reporting uptime at previous message

On Wed, May 17, 2017 at 3:47 PM, Geert Uytterhoeven wrote: > Add an example SPI slave handler responding with the uptime at the time > of reception of the last SPI message. > > This can be used by an external microcontroller as a dead man's switch. > +static int

Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent

Hi Kieran, On Wed, May 17, 2017 at 04:03:38PM +0100, Kieran Bingham wrote: > From: Kieran Bingham > > V4L2 async notifiers can pass the endpoint fwnode rather than the device > fwnode. > > Provide a helper to obtain the parent device fwnode without

Re: [PATCH 1/2] sh_eth: Use platform device for printing before register_netdev()

From: Geert Uytterhoeven Date: Thu, 18 May 2017 15:01:34 +0200 > The MDIO initialization failure message is printed using the network > device, before it has been registered, leading to: > > (null): failed to initialise MDIO > > Use the platform device instead to

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

From: Geert Uytterhoeven Date: Thu, 18 May 2017 14:59:05 +0200 > If an Ethernet PHY is initialized before the interrupt controller it is > connected to, a message like the following is printed: > > irq: no irq domain found for /interrupt-controller@e61c ! > >

Re: [PATCH 2/2] sh_eth: Do not print an error message for probe deferral

From: Geert Uytterhoeven Date: Thu, 18 May 2017 15:01:35 +0200 > EPROBE_DEFER is not an error, hence printing an error message like > > sh-eth ee70.ethernet: failed to initialise MDIO > > may confuse the user. > > To fix this, suppress the error message in

[renesas-drivers:test/rcar2-cpg-mssr-v2 22/51] (.text+0x1916e): multiple definition of `clk_get'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git test/rcar2-cpg-mssr-v2 head: e073b349f98d3db06a54d26904561ab78c02767b commit: 8cc60e1ad7c6850d1a0be02a3d1606cecb298602 [22/51] [TEST] m68k: Enable COMMON_CLK config: m68k-m5475evb_defconfig (attached as .config)

Re: [PATCH v1 3/3] v4l: async: Match parent devices

Hi Kieran, Thank you for the patch. On Wednesday 17 May 2017 16:03:39 Kieran Bingham wrote: > From: Kieran Bingham > > Devices supporting multiple endpoints on a single device node must set > their subdevice fwnode to the endpoint to allow distinct

Re: [PATCH v4 4/4] drm: rcar-du: Register a completion callback with VSP1

Em Fri, 5 May 2017 16:21:10 +0100 Kieran Bingham escreveu: > Currently we process page flip events on every display interrupt, > however this does not take into consideration the processing time needed > by the VSP1 utilised in the pipeline. > >

Re: [PATCH] ravb: add wake-on-lan support via magic packet

On Tue, May 16, 2017 at 02:16:04PM +0200, Niklas Söderlund wrote: > Hi, > > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote: > > Hi Simon, > > > > On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote: > > > On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven

Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent

Hi Kieran, Thank you for the patch. On Wednesday 17 May 2017 16:03:38 Kieran Bingham wrote: > From: Kieran Bingham > > V4L2 async notifiers can pass the endpoint fwnode rather than the device > fwnode. I'm not sure I would mention V4L2 in the commit

Re: [PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()

Hi Kieran, On Wednesday 17 May 2017 21:02:42 Kieran Bingham wrote: > On 17/05/17 17:36, Rob Herring wrote: > > On Wed, May 17, 2017 at 10:03 AM, Kieran Bingham wrote: > >> From: Kieran Bingham > >> > >> When handling endpoints, the v4l2 async framework

Re: [PATCH 2/2] sh_eth: Do not print an error message for probe deferral

Hi Geert, Thank you for the patch. On Thursday 18 May 2017 15:01:35 Geert Uytterhoeven wrote: > EPROBE_DEFER is not an error, hence printing an error message like > > sh-eth ee70.ethernet: failed to initialise MDIO > > may confuse the user. > > To fix this, suppress the error message

Re: [PATCH 1/2] sh_eth: Use platform device for printing before register_netdev()

Hi Geert, Thank you for the patch. On Thursday 18 May 2017 15:01:34 Geert Uytterhoeven wrote: > The MDIO initialization failure message is printed using the network > device, before it has been registered, leading to: > > (null): failed to initialise MDIO > > Use the platform device

[PATCH 2/2] sh_eth: Do not print an error message for probe deferral

EPROBE_DEFER is not an error, hence printing an error message like sh-eth ee70.ethernet: failed to initialise MDIO may confuse the user. To fix this, suppress the error message in case of probe deferral. While at it, shorten the message, and add the actual error code. Signed-off-by:

[PATCH 1/2] sh_eth: Use platform device for printing before register_netdev()

The MDIO initialization failure message is printed using the network device, before it has been registered, leading to: (null): failed to initialise MDIO Use the platform device instead to fix this: sh-eth ee70.ethernet: failed to initialise MDIO Fixes: daacf03f0bbfefee ("sh_eth:

[PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

If an Ethernet PHY is initialized before the interrupt controller it is connected to, a message like the following is printed: irq: no irq domain found for /interrupt-controller@e61c ! However, the actual error is ignored, leading to a non-functional (-1) PHY interrupt later: Micrel

Re: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Shimoda-san, On Thu, May 18, 2017 at 2:19 PM, Yoshihiro Shimoda wrote: >> From: Geert Uytterhoeven >> Sent: Thursday, May 18, 2017 8:41 PM >> On Thu, May 18, 2017 at 1:13 PM, Yoshihiro Shimoda >> wrote: >> >> >> +- reg:

RE: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Geert-san, > From: Geert Uytterhoeven > Sent: Thursday, May 18, 2017 8:41 PM > > Hi Shimoda-san, > > On Thu, May 18, 2017 at 1:13 PM, Yoshihiro Shimoda > wrote: > >> >> +- reg: offset and length of the partial USB 3.0 Host PHY register > >> >> block. > >>

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

Hi Sakari, >>> In omap3isp/isp.c: isp_fwnodes_parse() the async notifier is registered >>> looking >>> at the endpoints parent fwnode: >>> >>> isd->asd.match.fwnode.fwnode = >>> fwnode_graph_get_remote_port_parent(fwnode); >>> >>> This would therefore not support

Re: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Shimoda-san, On Thu, May 18, 2017 at 1:13 PM, Yoshihiro Shimoda wrote: >> >> +- reg: offset and length of the partial USB 3.0 Host PHY register block. >> >> +- #phy-cells: see phy-bindings.txt in the same directory, must be <0>. >> > >> > I think we should

RE: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

Hi Geert-san, > -Original Message- > From: Geert Uytterhoeven > Sent: Thursday, May 18, 2017 5:46 PM > > On Thu, May 18, 2017 at 4:53 AM, Yoshihiro Shimoda > wrote: > >> From: Petre Pircalabu > >> The USB30PHY of a RCAR-Gen3 XHCI device can select the

Re: [RFC] i2c-stub: make it usable with DT when booting

Hi Jean, > I get the idea and I understand the need to emulate the devices early > in the boot process. However, how do you deal with the I2C devices > pre-initialization (setting initial register values)? This is typically > done in user-space with the i2c-stub-from-dump script, or manual calls

Re: [RFC] i2c-stub: make it usable with DT when booting

Hi Wolfram, On Tue, 16 May 2017 13:27:58 +0200, Wolfram Sang wrote: > This patch makes the stub driver parse the device tree when booting and > create a virtual bus with the desired devices attached. Here is an > example DTS snipplet making use of it. It is for simulating a more > complex camera

Re: [PATCH] ravb: add wake-on-lan support via magic packet

Hi Niklas, On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund wrote: > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote: >> On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote: >> > Is there some way for - e.g. the driver - to not enable

Re: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

On Thu, May 18, 2017 at 4:53 AM, Yoshihiro Shimoda wrote: >> From: Petre Pircalabu >> The USB30PHY of a RCAR-Gen3 XHCI device can select the reference clock >> source. The 2 available options are the differential input clock pair >> supplied on pins USB3S0_CLK_P

Re: [PATCH 2/2] i2c: stub: use pr_fmt

On Tue, 16 May 2017 13:21:05 +0200, Wolfram Sang wrote: > Instead of hard coding "i2c-stub:", let's use the pr_fmt mechanism to > achieve the same more easily. This makes it easier to stay consistent > when adding new messages. Also, remove an unneeded OOM message while we > are here. > >

Re: [PATCH 1/2] i2c: stub: move module_init/exit annotations to the proper place

Hi Jean, > > -module_init(i2c_stub_init); > > -module_exit(i2c_stub_exit); > > I'm not sure on what you base your claim that this is the "proper > place". checkpatch doesn't complain about either, and if anything, the > original style (module_init/exit) at end of file seems a lot more > popular

Re: [PATCH 1/2] i2c: stub: move module_init/exit annotations to the proper place

Hi Wolfram, On Tue, 16 May 2017 13:21:04 +0200, Wolfram Sang wrote: > Signed-off-by: Wolfram Sang > --- > drivers/i2c/i2c-stub.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/i2c/i2c-stub.c b/drivers/i2c/i2c-stub.c >

RE: [PATCH] mmc: tmio: use SDIO master interrupt bit only when allowed

Hi Shoji-san, > From: Yasushi SHOJI > Sent: Thursday, May 18, 2017 2:10 PM > > Hi, > > On Wed, May 17, 2017 at 4:47 PM, Yoshihiro Shimoda > wrote: > >> > >> drivers/mmc/host/tmio_mmc_pio.c | 7 --- > >> 1 file changed, 4 insertions(+), 3 deletions(-) > >>

RE: [PATCH] mmc: tmio: use SDIO master interrupt bit only when allowed

Hi Wolfram-san, > From: Wolfram Sang > Sent: Thursday, May 18, 2017 3:18 PM > > Shimoda-san, > > > This patch enables CTL_TRANSACTION_CTL to 0x0001 in tmio_mmc_host_probe(). > > But, I have a concern we have to disable/enable the register in > > suspend/resume() > > because registers setting

Re: [PATCH] mmc: tmio: use SDIO master interrupt bit only when allowed

Shimoda-san, > This patch enables CTL_TRANSACTION_CTL to 0x0001 in tmio_mmc_host_probe(). > But, I have a concern we have to disable/enable the register in > suspend/resume() > because registers setting is possible to be cleared after resume. > What do you think? This is very likely true. I'll