Re: [git pull] pinctrl: sh-pfc: Updates for v4.13

[Linus Walleij]

On Mon, May 29, 2017 at 1:57 PM, Geert Uytterhoeven
 wrote:

> Hi Linus,
>
> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>
>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/sh-pfc-for-v4.13-tag1
>
> for you to fetch changes up to c8bac70f079bb3ecaf9a716f141f3d85cef27231:
>
>   pinctrl: sh-pfc: r8a7794: Add R8A7745 support (2017-05-16 13:53:15 +0200)

Awesome, good work as usual.

Pulled to my pinctrl devel branch.

Yours,
Linus Walleij

Re: [PATCH 5/7] pci: use proper name for the R-Car SoC

[Bjorn Helgaas]

On Sun, May 28, 2017 at 11:30:48AM +0200, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
> 
> Signed-off-by: Wolfram Sang 
> ---
> I suggest this trivial patch should be picked individually per susbsystem.
> 
>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied with Geert and Simon's acks to pci/host-rcar for v4.13, thanks!

> 
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt 
> b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 34712d6fd25376..bd27428dda619d 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -1,4 +1,4 @@
> -* Renesas RCar PCIe interface
> +* Renesas R-Car PCIe interface
>  
>  Required properties:
>  compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> -- 
> 2.11.0
> 

Re: [PATCH] mmc: renesas_sdhi_core: on R-Car 2+, make use of CBSY bit

[Wolfram Sang]

On Tue, May 30, 2017 at 11:03:46AM +0200, Wolfram Sang wrote:
> Most registers need to wait until the command is completed, not
> necessarily until the bus is free. At least, R-Car 2+ SoCs can signal
> that via the CBSY bit, so let's use it there instead of SCLKDIVEN to
> save a little bit of delay.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Tested with a Renesas Lager board (H2). Moved big files around across 
> different
> SD cards, re- inserted cards multiple times. All worked fine.
> 
> @Dirk: can you do some additional testing for your use case? That would be 
> much
> appreciated!

OK, since Dirk told me he'll need some more time to test it anyhow and
Simon meanwhile sent some cleanup patches, I'll simply post an updated
version of this patch once Simon's cleanup patches hit mmc/next. I think
this will be easiest.



signature.asc
Description: PGP signature

Re: [PATCH 4/5] mmc: tmio: improve checkpatch cleanness

[Wolfram Sang]

On Tue, May 30, 2017 at 02:50:53PM +0200, Simon Horman wrote:
> Trivial updates to improve checkpatch cleanness.
> 
> Signed-off-by: Simon Horman 

Wow, all of them! When I reviewed your DMA refactoring patches, I meant
to fix only the whitespace issues which were affecting your patches. But
okay, it is a good timing to fix all of those, because of the said DMA
refactoring work, the BSP patches won't fit anymore anyhow, so upporting
them will not become significantly harder.

And while I don't agree with all of checkpatch suggestions, this patch
increases code readability for sure. I guess, what I am saying is:

Reviewed-by: Wolfram Sang 

and

Tested-by: Wolfram Sang 

I moved big files around two SD cards attached simultaneously to two
card slots on my Renesas Lager (H2).

> - if (host->chan_tx && (data->flags & MMC_DATA_WRITE) && 
> !host->force_pio) {
> + if (host->chan_tx && (data->flags & MMC_DATA_WRITE) &&
> + !host->force_pio) {
>   u32 status = sd_ctrl_read16_and_16_as_32(host, CTL_STATUS);
>   bool done = false;

Let me give just one example where I think the 80 char limit doesn't
help readability. But no need to fix IMO; as I said, most of the stuff
is really helpful.



signature.asc
Description: PGP signature

Re: [PATCH 5/5] mmc: renesas-sdhi: improve checkpatch cleanness

[Wolfram Sang]

On Tue, May 30, 2017 at 02:50:54PM +0200, Simon Horman wrote:
> Trivial updates to improve checkpatch cleanness.
> 
> Signed-off-by: Simon Horman 

Two comments here:

> - /* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
> - if (!host->bus_shift && resource_size(res) > 0x100) /* old way to 
> determine the shift */
> + /*
> +  * Originally registers were 16 bit apart, could be 32 or 64 nowadays.
> +  * Old way to determine the shift:
> +  */
> + if (!host->bus_shift && resource_size(res) > 0x100)
>   host->bus_shift = 1;

I liked the old way much better because it makes clearer which comment
belongs to the whole block and which comment belongs to just this one
line.

>   /*
> -  * All SDHI have CMD12 controll bit
> +  * All SDHI have CMD12 control bit
>*/

Single line comment?

And hooray for finally fixing the controll bit :D



signature.asc
Description: PGP signature

Re: [PATCH 3/5] mmc: tmio, renesas-sdhi: update Renesas related copyrights

[Wolfram Sang]

On Tue, May 30, 2017 at 02:50:52PM +0200, Simon Horman wrote:
> Update copyrights to reflect work by Wolfram Sang and myself since last
> year.
> 
> Signed-off-by: Simon Horman 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH 2/5] mmc: tmio: use EXPORT_SYMBOL_GPL

[Wolfram Sang]

On Tue, May 30, 2017 at 02:50:51PM +0200, Simon Horman wrote:
> Use EXPORT_SYMBOL_GPL rather than the non _GPL variant as there seems to be
> no reason not to.
> 
> Signed-off-by: Simon Horman 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH 1/5] MAINTAINERS: Update files for TMIO/SDHI MMC driver

[Wolfram Sang]

On Tue, May 30, 2017 at 02:50:50PM +0200, Simon Horman wrote:
> Update files for tmio/sdhi MMC driver to reflect recent filename
> changes.
> 
> Signed-off-by: Simon Horman 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

RE: [PATCH] ARM: dts: r7s72100: add clock bit definitions

[Chris Brandt]

Hi Geert,

As always Thank you for your review!


On Monday, May 29, 2017, Geert Uytterhoeven wrote:
> >  #define R7S72100_CLK_PLL   0
> 
> No CoreSight (MSTP20)?

OK, I'll add that in.


> > +#define R7S72100_CLK_MCPWM 0
> 
> Perhaps just R7S72100_CLK_PWM?

OK.
People don't seem to be using it for motor control anyway ;)


> > +#define R7S72100_CLK_SNDGEN0   5
> > +#define R7S72100_CLK_SNDGEN1   4
> > +#define R7S72100_CLK_SNDGEN2   3
> > +#define R7S72100_CLK_SNDGEN3   2
> 
> R7S72100_CLK_SG[0-3]?

I debated against 'SG' vs 'SNDGEN'.
Since you also suggested SG, I'll change it.

> >  /* MSTP7 */
> > +#define R7S72100_CLK_VDEC0 7
> > +#define R7S72100_CLK_VDEC1 6
> 
> R7S72100_CLK_VIN[01]?

These are analog video inputs (NTSC/PAL).
For R-Car, "VIN" seem to refer to parallel digital inputs (ie, rcar-vin 
driver)

So for the RZ/A series, I was going to keep with the convention that we 
use for the non-Linux sample code and app notes such that these inputs 
are 'analog video decoders' and not just video input/capture 
pinshence vdec.


> > +#define R7S72100_CLK_ETHABV2
> 
> R7S72100_CLK_ETHAVB

Opps. Thank you!


> > +#define R7S72100_CLK_SPIMBC0   3
> > +#define R7S72100_CLK_SPIMBC1   2
> 
> R7S72100_CLK_SPB[0-1]?

Here's the one that I'm struggling with what to call.

Internally, the IP block is referred to as the "SPIBSC". As in, SPI Bus 
State Controller (because basically anything that has a parallel 
interface to the internal bus the design guys call it a BSC: LBSC, DBSC, 
etc...).

However, for every device this IP is used in it is called the "SPI 
Multi I/O Bus Controller" in the Hardware Manual (SH7769, RZ/A1, R-Car Gen3, 
etc...).

So, that might be confusing to users.

Originally, it was called "SPI BSC" because they were only connecting a 
"SPI" bus interface as a "Bus State Controller". However, now they've 
added onto the IP and it does more than just SPI.


> All related registers and clocks are called SPB.
Only the pins are labeled SPB, not the registers. The 
registers doesn't really have a common prefix.


So in general, what's your opinion on what to call this thing (since 
I'd like to name the driver in a similar manner)?

(1) "SPIBSC": Because that's what all the non-Linux sample code and app 
 note refer to it.

(2) "SPIMBC": Taken from "SPI Multi I/O Bus Controller" (using all 1st 
letters except the "I/O" part)

(3) "SPB": Because that is how they named the pins for RZ/1 (NOTE that
is just for RZ/A1 and SH7269, for RZ/A2++ and R-Car they are labeled
QSPI_xxx...so you will probably never see SPB again in future hardware
manuals)

(4) "SBC": For Serial Bus Controller


I am leaning to just staying with "SPIBSC" which is what I use now for 
our current Linux BSP and non-Linux sample code, or "SBC" just to 
shorten it.

Any opinions???



> No SSI (MSTP11[0-5])?

Opps, I missed that register somehow.
I'll add them in.


Thank you,
Chris

RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

[Chris Brandt]

Hello Jacopo and Linus,

On Monday, May 29, 2017, jmondi wrote:
> > > We can handle 'bi-directional' pins with static tables in our pin
> > > controller driver and not have it anywhere in DT.
> >
> > This sounds like a viable approach.
> >
> > I just want to know if "output-enable" is the right name?
> > "output-buffer-enable"?
> 
> Great! Thanks!
> 
> On naming: if we need "output-buffer-enable" should we add
> "input-buffer-enable" as well?
> 
> Currently we are using "input-enable" to pair with "output-enable",
> but as you said, just "output-enable" when "output-high" and
> "output-low" are there already seems a bit confusing.
> At the same time "input-buffer-enable" seems to actually be just
> electrically equivalent to "input-enable", so adding it is a bit of a
> waste as well.

Here is what I think:


In the case of this driver, after we remove the 'bi-directional'
properties and hide the other odd-ball pin configurations in an internal
table, we are left with the MTU2 timer pins that can be either input or
output depending on what you want to do with them.

 * If you want to use a MTU2 channel as a PWM, you set the pin as an
   output.
 * If you want to use a MTU2 channel as a input capture, you set the
   pin as an input.

They are simply "direction-input" and "direction-output" properties that
don't really need to talk about "buffers".


But, instead of making any new properties, for the Renesas driver, let's
just stick with what already exists today: 
 * If you want a MTU2 channel as a PWM: select "output-low"
 * If you want a MTU2 channel as a input capture: select "input-enable"


Side Note: You can also use output-high in addition to output-low
  because it doesn't matter (the driver can't set the pin level anyway
  because as soon as you assign the pin to MTU2, the MTU2 controls the
  pin, not the PFC). So the Renesas driver can check for both.



Chris

[PATCH 5/5] mmc: renesas-sdhi: improve checkpatch cleanness

[Simon Horman]

Trivial updates to improve checkpatch cleanness.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi.h  |  2 +-
 drivers/mmc/host/renesas_sdhi_core.c | 48 ++--
 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 25 +
 3 files changed, 42 insertions(+), 33 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi.h b/drivers/mmc/host/renesas_sdhi.h
index 6b4a79508c6b..ca83acc113b8 100644
--- a/drivers/mmc/host/renesas_sdhi.h
+++ b/drivers/mmc/host/renesas_sdhi.h
@@ -34,6 +34,6 @@ struct renesas_sdhi_of_data {
 };
 
 int renesas_sdhi_probe(struct platform_device *pdev,
-   const struct tmio_mmc_dma_ops *dma_ops);
+  const struct tmio_mmc_dma_ops *dma_ops);
 int renesas_sdhi_remove(struct platform_device *pdev);
 #endif
diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index f4690cba3443..92ca2124ef44 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -45,7 +45,8 @@
 #define SDHI_VER_GEN3_SD   0xcc10
 #define SDHI_VER_GEN3_SDMMC0xcd10
 
-#define host_to_priv(host) container_of((host)->pdata, struct renesas_sdhi, 
mmc_data)
+#define host_to_priv(host) \
+   container_of((host)->pdata, struct renesas_sdhi, mmc_data)
 
 struct renesas_sdhi {
struct clk *clk;
@@ -94,6 +95,7 @@ static int renesas_sdhi_clk_enable(struct tmio_mmc_host *host)
struct mmc_host *mmc = host->mmc;
struct renesas_sdhi *priv = host_to_priv(host);
int ret = clk_prepare_enable(priv->clk);
+
if (ret < 0)
return ret;
 
@@ -125,7 +127,7 @@ static int renesas_sdhi_clk_enable(struct tmio_mmc_host 
*host)
 }
 
 static unsigned int renesas_sdhi_clk_update(struct tmio_mmc_host *host,
- unsigned int new_clock)
+   unsigned int new_clock)
 {
struct renesas_sdhi *priv = host_to_priv(host);
unsigned int freq, diff, best_freq = 0, diff_min = ~0;
@@ -175,11 +177,12 @@ static int renesas_sdhi_card_busy(struct mmc_host *mmc)
 {
struct tmio_mmc_host *host = mmc_priv(mmc);
 
-   return !(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) & 
TMIO_STAT_DAT0);
+   return !(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) &
+TMIO_STAT_DAT0);
 }
 
 static int renesas_sdhi_start_signal_voltage_switch(struct mmc_host *mmc,
- struct mmc_ios *ios)
+   struct mmc_ios *ios)
 {
struct tmio_mmc_host *host = mmc_priv(mmc);
struct renesas_sdhi *priv = host_to_priv(host);
@@ -285,7 +288,7 @@ static unsigned int renesas_sdhi_init_tuning(struct 
tmio_mmc_host *host)
 }
 
 static void renesas_sdhi_prepare_tuning(struct tmio_mmc_host *host,
-unsigned long tap)
+   unsigned long tap)
 {
struct renesas_sdhi *priv = host_to_priv(host);
 
@@ -318,9 +321,9 @@ static int renesas_sdhi_select_tuning(struct tmio_mmc_host 
*host)
tap_start = 0;
tap_end = 0;
for (i = 0; i < host->tap_num * 2; i++) {
-   if (test_bit(i, host->taps))
+   if (test_bit(i, host->taps)) {
ntap++;
-   else {
+   } else {
if (ntap > tap_cnt) {
tap_start = i - ntap;
tap_end = i - 1;
@@ -352,7 +355,6 @@ static int renesas_sdhi_select_tuning(struct tmio_mmc_host 
*host)
return 0;
 }
 
-
 static bool renesas_sdhi_check_scc_error(struct tmio_mmc_host *host)
 {
struct renesas_sdhi *priv = host_to_priv(host);
@@ -414,8 +416,7 @@ static int renesas_sdhi_wait_idle(struct tmio_mmc_host 
*host)
 
 static int renesas_sdhi_write16_hook(struct tmio_mmc_host *host, int addr)
 {
-   switch (addr)
-   {
+   switch (addr) {
case CTL_SD_CMD:
case CTL_STOP_INTERNAL_ACTION:
case CTL_XFER_BLK_COUNT:
@@ -432,7 +433,7 @@ static int renesas_sdhi_write16_hook(struct tmio_mmc_host 
*host, int addr)
 }
 
 static int renesas_sdhi_multi_io_quirk(struct mmc_card *card,
-unsigned int direction, int blk_size)
+  unsigned int direction, int blk_size)
 {
/*
 * In Renesas controllers, when performing a
@@ -460,20 +461,23 @@ static void renesas_sdhi_enable_dma(struct tmio_mmc_host 
*host, bool enable)
 int renesas_sdhi_probe(struct platform_device *pdev,
   const struct tmio_mmc_dma_ops *dma_ops)
 {
-   const struct renesas_sdhi_of_data *of_data = of_device_get_match_data( 
&pdev->dev);
-   struct renesas_sdhi *priv;
-   struct tmio_mmc_data *mmc_data;
struct tmio_mmc_data *mmd = pdev->dev.platform_data;
+   const struct

[PATCH 4/5] mmc: tmio: improve checkpatch cleanness

[Simon Horman]

Trivial updates to improve checkpatch cleanness.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi.h  |   2 +-
 drivers/mmc/host/tmio_mmc.c  |   8 +--
 drivers/mmc/host/tmio_mmc.h  |  17 +++---
 drivers/mmc/host/tmio_mmc_core.c | 114 +++
 include/linux/mfd/tmio.h |  33 ++--
 5 files changed, 100 insertions(+), 74 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi.h b/drivers/mmc/host/renesas_sdhi.h
index eb3ea15ff92d..6b4a79508c6b 100644
--- a/drivers/mmc/host/renesas_sdhi.h
+++ b/drivers/mmc/host/renesas_sdhi.h
@@ -27,7 +27,7 @@ struct renesas_sdhi_of_data {
unsigned long capabilities2;
enum dma_slave_buswidth dma_buswidth;
dma_addr_t dma_rx_offset;
-   unsigned bus_shift;
+   unsigned int bus_shift;
int scc_offset;
struct renesas_sdhi_scc *taps;
int taps_num;
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 61cf36fb270b..64b7e9f18361 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -104,8 +104,8 @@ static int tmio_mmc_probe(struct platform_device *pdev)
goto host_free;
 
ret = devm_request_irq(&pdev->dev, irq, tmio_mmc_irq,
-   IRQF_TRIGGER_FALLING,
-   dev_name(&pdev->dev), host);
+  IRQF_TRIGGER_FALLING,
+  dev_name(&pdev->dev), host);
if (ret)
goto host_remove;
 
@@ -132,6 +132,7 @@ static int tmio_mmc_remove(struct platform_device *pdev)
 
if (mmc) {
struct tmio_mmc_host *host = mmc_priv(mmc);
+
tmio_mmc_host_remove(host);
if (cell->disable)
cell->disable(pdev);
@@ -145,8 +146,7 @@ static int tmio_mmc_remove(struct platform_device *pdev)
 static const struct dev_pm_ops tmio_mmc_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(tmio_mmc_suspend, tmio_mmc_resume)
SET_RUNTIME_PM_OPS(tmio_mmc_host_runtime_suspend,
-   tmio_mmc_host_runtime_resume,
-   NULL)
+  tmio_mmc_host_runtime_resume, NULL)
 };
 
 static struct platform_driver tmio_mmc_driver = {
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 768c8abaedda..6ad6704175dc 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -239,24 +239,26 @@ static inline u16 sd_ctrl_read16(struct tmio_mmc_host 
*host, int addr)
 }
 
 static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int addr,
-   u16 *buf, int count)
+ u16 *buf, int count)
 {
readsw(host->ctl + (addr << host->bus_shift), buf, count);
 }
 
-static inline u32 sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host, int 
addr)
+static inline u32 sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host,
+ int addr)
 {
return readw(host->ctl + (addr << host->bus_shift)) |
   readw(host->ctl + ((addr + 2) << host->bus_shift)) << 16;
 }
 
 static inline void sd_ctrl_read32_rep(struct tmio_mmc_host *host, int addr,
-   u32 *buf, int count)
+ u32 *buf, int count)
 {
readsl(host->ctl + (addr << host->bus_shift), buf, count);
 }
 
-static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr, u16 
val)
+static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr,
+  u16 val)
 {
/* If there is a hook and it returns non-zero then there
 * is an error and the write should be skipped
@@ -267,19 +269,20 @@ static inline void sd_ctrl_write16(struct tmio_mmc_host 
*host, int addr, u16 val
 }
 
 static inline void sd_ctrl_write16_rep(struct tmio_mmc_host *host, int addr,
-   u16 *buf, int count)
+  u16 *buf, int count)
 {
writesw(host->ctl + (addr << host->bus_shift), buf, count);
 }
 
-static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host, 
int addr, u32 val)
+static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host,
+   int addr, u32 val)
 {
writew(val & 0x, host->ctl + (addr << host->bus_shift));
writew(val >> 16, host->ctl + ((addr + 2) << host->bus_shift));
 }
 
 static inline void sd_ctrl_write32_rep(struct tmio_mmc_host *host, int addr,
-   const u32 *buf, int count)
+  const u32 *buf, int count)
 {
writesl(host->ctl + (addr << host->bus_shift), buf, count);
 }
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 70516abd50a1..07905c05f356 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -127,16 +127,17 @@ static int tmio_mmc_n

[PATCH 2/5] mmc: tmio: use EXPORT_SYMBOL_GPL

[Simon Horman]

Use EXPORT_SYMBOL_GPL rather than the non _GPL variant as there seems to be
no reason not to.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/tmio_mmc_core.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index e1ad461c4b8c..242d9bcc365a 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -91,14 +91,14 @@ void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host, 
u32 i)
host->sdcard_irq_mask &= ~(i & TMIO_MASK_IRQ);
sd_ctrl_write32_as_16_and_16(host, CTL_IRQ_MASK, host->sdcard_irq_mask);
 }
-EXPORT_SYMBOL(tmio_mmc_enable_mmc_irqs);
+EXPORT_SYMBOL_GPL(tmio_mmc_enable_mmc_irqs);
 
 void tmio_mmc_disable_mmc_irqs(struct tmio_mmc_host *host, u32 i)
 {
host->sdcard_irq_mask |= (i & TMIO_MASK_IRQ);
sd_ctrl_write32_as_16_and_16(host, CTL_IRQ_MASK, host->sdcard_irq_mask);
 }
-EXPORT_SYMBOL(tmio_mmc_disable_mmc_irqs);
+EXPORT_SYMBOL_GPL(tmio_mmc_disable_mmc_irqs);
 
 static void tmio_mmc_ack_mmc_irqs(struct tmio_mmc_host *host, u32 i)
 {
@@ -562,7 +562,7 @@ void tmio_mmc_do_data_irq(struct tmio_mmc_host *host)
 
schedule_work(&host->done);
 }
-EXPORT_SYMBOL(tmio_mmc_do_data_irq);
+EXPORT_SYMBOL_GPL(tmio_mmc_do_data_irq);
 
 static void tmio_mmc_data_irq(struct tmio_mmc_host *host, unsigned int stat)
 {
@@ -766,7 +766,7 @@ irqreturn_t tmio_mmc_irq(int irq, void *devid)
 
return IRQ_HANDLED;
 }
-EXPORT_SYMBOL(tmio_mmc_irq);
+EXPORT_SYMBOL_GPL(tmio_mmc_irq);
 
 static int tmio_mmc_start_data(struct tmio_mmc_host *host,
struct mmc_data *data)
@@ -1189,13 +1189,13 @@ tmio_mmc_host_alloc(struct platform_device *pdev)
 
return host;
 }
-EXPORT_SYMBOL(tmio_mmc_host_alloc);
+EXPORT_SYMBOL_GPL(tmio_mmc_host_alloc);
 
 void tmio_mmc_host_free(struct tmio_mmc_host *host)
 {
mmc_free_host(host->mmc);
 }
-EXPORT_SYMBOL(tmio_mmc_host_free);
+EXPORT_SYMBOL_GPL(tmio_mmc_host_free);
 
 int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
struct tmio_mmc_data *pdata,
@@ -1338,7 +1338,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 
return 0;
 }
-EXPORT_SYMBOL(tmio_mmc_host_probe);
+EXPORT_SYMBOL_GPL(tmio_mmc_host_probe);
 
 void tmio_mmc_host_remove(struct tmio_mmc_host *host)
 {
@@ -1363,7 +1363,7 @@ void tmio_mmc_host_remove(struct tmio_mmc_host *host)
 
tmio_mmc_clk_disable(host);
 }
-EXPORT_SYMBOL(tmio_mmc_host_remove);
+EXPORT_SYMBOL_GPL(tmio_mmc_host_remove);
 
 #ifdef CONFIG_PM
 int tmio_mmc_host_runtime_suspend(struct device *dev)
@@ -1380,7 +1380,7 @@ int tmio_mmc_host_runtime_suspend(struct device *dev)
 
return 0;
 }
-EXPORT_SYMBOL(tmio_mmc_host_runtime_suspend);
+EXPORT_SYMBOL_GPL(tmio_mmc_host_runtime_suspend);
 
 static bool tmio_mmc_can_retune(struct tmio_mmc_host *host)
 {
@@ -1405,7 +1405,7 @@ int tmio_mmc_host_runtime_resume(struct device *dev)
 
return 0;
 }
-EXPORT_SYMBOL(tmio_mmc_host_runtime_resume);
+EXPORT_SYMBOL_GPL(tmio_mmc_host_runtime_resume);
 #endif
 
 MODULE_LICENSE("GPL v2");
-- 
2.1.4

[PATCH 1/5] MAINTAINERS: Update files for TMIO/SDHI MMC driver

[Simon Horman]

Update files for tmio/sdhi MMC driver to reflect recent filename
changes.

Signed-off-by: Simon Horman 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..5b4c477573dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12882,7 +12882,7 @@ M:  Wolfram Sang 
 L: linux-...@vger.kernel.org
 S: Supported
 F: drivers/mmc/host/tmio_mmc*
-F: drivers/mmc/host/sh_mobile_sdhi.c
+F: drivers/mmc/host/renesas_sdhi*
 F: include/linux/mfd/tmio.h
 
 TMP401 HARDWARE MONITOR DRIVER
-- 
2.1.4

[PATCH 3/5] mmc: tmio, renesas-sdhi: update Renesas related copyrights

[Simon Horman]

Update copyrights to reflect work by Wolfram Sang and myself since last
year.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi_core.c | 5 +++--
 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 3 +++
 drivers/mmc/host/tmio_mmc.c  | 2 ++
 drivers/mmc/host/tmio_mmc.h  | 5 +++--
 drivers/mmc/host/tmio_mmc_core.c | 5 +++--
 5 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 82150a966391..f4690cba3443 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -1,8 +1,9 @@
 /*
  * Renesas SDHI
  *
- * Copyright (C) 2016 Sang Engineering, Wolfram Sang
- * Copyright (C) 2015-16 Renesas Electronics Corporation
+ * Copyright (C) 2015-17 Renesas Electronics Corporation
+ * Copyright (C) 2016-17 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2016-17 Horms Solutions, Simon Horman
  * Copyright (C) 2009 Magnus Damm
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index 7eab55adc5b2..202cf4346fdf 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -1,6 +1,9 @@
 /*
  * DMA function for TMIO MMC implementations
  *
+ * Copyright (C) 2016-17 Renesas Electronics Corporation
+ * Copyright (C) 2016-17 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2017 Horms Solutions, Simon Horman
  * Copyright (C) 2010-2011 Guennadi Liakhovetski
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 59880146e7f9..61cf36fb270b 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -3,6 +3,8 @@
  *
  * TC6393XB TC6391XB TC6387XB T7L66XB ASIC3
  *
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ * Copyright (C) 2017 Horms Solutions, Simon Horman
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
  *
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 9c94b6eb9b49..768c8abaedda 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -3,8 +3,9 @@
  *
  * TC6393XB TC6391XB TC6387XB T7L66XB ASIC3
  *
- * Copyright (C) 2016 Sang Engineering, Wolfram Sang
- * Copyright (C) 2015-16 Renesas Electronics Corporation
+ * Copyright (C) 2015-17 Renesas Electronics Corporation
+ * Copyright (C) 2016-17 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2016-17 Horms Solutions, Simon Horman
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
  *
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 242d9bcc365a..70516abd50a1 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -3,8 +3,9 @@
  *
  * TC6393XB, TC6391XB, TC6387XB, T7L66XB, ASIC3, SH-Mobile SoCs
  *
- * Copyright (C) 2016 Sang Engineering, Wolfram Sang
- * Copyright (C) 2015-16 Renesas Electronics Corporation
+ * Copyright (C) 2015-17 Renesas Electronics Corporation
+ * Copyright (C) 2016-17 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2017 Horms Solutions, Simon Horman
  * Copyright (C) 2011 Guennadi Liakhovetski
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
-- 
2.1.4

[PATCH 0/5] mmc: tmio, renesas-sdhi: cleanups

[Simon Horman]

Hi,

this short series provides some cleanups to the tmio and renesas-sdhi
drivers.

* Update files listed in MAINTAINERS
* Consistently use EXPORT_SYMBOL_GPL
* Update Renesas related copyrights
* Improve checkpatch cleanness

Simon Horman (5):
  MAINTAINERS: Update files for TMIO/SDHI MMC driver
  mmc: tmio: use EXPORT_SYMBOL_GPL
  mmc: tmio, renesas-sdhi: update Renesas related copyrights
  mmc: tmio: improve checkpatch cleanness
  mmc: renesas-sdhi: improve checkpatch cleanness

 MAINTAINERS  |   2 +-
 drivers/mmc/host/renesas_sdhi.h  |   4 +-
 drivers/mmc/host/renesas_sdhi_core.c |  53 +++-
 drivers/mmc/host/renesas_sdhi_sys_dmac.c |  28 ---
 drivers/mmc/host/tmio_mmc.c  |  10 ++-
 drivers/mmc/host/tmio_mmc.h  |  22 +++--
 drivers/mmc/host/tmio_mmc_core.c | 139 ++-
 include/linux/mfd/tmio.h |  33 
 8 files changed, 167 insertions(+), 124 deletions(-)

-- 
2.1.4

renesas-drivers-2017-05-30-v4.12-rc3

[Geert Uytterhoeven]

I have pushed renesas-drivers-2017-05-30-v4.12-rc3 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20170529-v4.12-rc3.

Included branches with driver code:
  - clk-renesas-for-v4.13
  - sh-pfc-for-v4.13
  - topic/rza1-pfc-gpio-v5
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - topic/suspend-to-idle-v1
  - git://linuxtv.org/pinchartl/media.git#drm/next/du-vsp
  - topic/spi-generalize-spi-controller-v2
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/submissions/vsp1/suspend-resume/v5
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/submissions/vsp1/writeback/v3
  - topic/sh-sh7722-sh7757-sh7264-sh7269-fix-pinctrl-v2
  - topic/rcar2-cpg-mssr-dt-v2
  - topic/iommu-fixes-v6

Included fixes:
  - iio: adc: max9611: Fix attribute measure unit
  - [media] v4l: vsp1: Add missing braces for vsp1_rwpf_memory initializers
  - of_mdio: Fix broken PHY IRQ in case of probe deferral
  - soc: renesas: Rework Kconfig and Makefile logic
  - watchdog: renesas-wdt: add support for rza
  - watchdog: add rza_wdt driver

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] i2c: i2c-mux: Fix channel parent node assignment

[Peter Rosin]

On 2017-05-30 10:54, Jacopo Mondi wrote:
> I2c-mux channels are created as mux siblings while they should be
> children of the mux itself. Fix it.

Has this received any testing at all?

I think it will break various users of i2c_parent_is_i2c_adapter()
that expect the current situation that a i2c mux child adapter is
direct child of the parent i2c adapter. I.e. with no intermediate
device node.

Cheers,
peda

> Signed-off-by: Jacopo Mondi 
> Suggested-by: Laurent Pinchart 
> ---
> 
> Hello,
>while inspecting child nodes of an i2c adapter it has been noted that
> child devices of an i2c-mux are listed as children of the i2c adapter itself,
> and not of the i2c-mux.
> 
> The hierarchy of devices looked like
> 
> -- i2c-04
> --- eeprom@57
> --- video_receiver@70
> --- video_receiver@34
> --- gmsl-deserializer@0   <-- MUX
> --- gmsl-deserializer@0/i2c@0 <-- MUX CHANNEL
> 
> It now looks like
> 
> -- i2c-04
> --- eeprom@57
> --- video_receiver@70
> --- video_receiver@34
> --- gmsl-deserializer@0
>  gmsl-deserializer@0/i2c@0
> 
> v1 -> v2:
> - change commit message as suggested by Geert
> 
>  drivers/i2c/i2c-mux.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 83768e8..37b7804 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -324,7 +324,7 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>   priv->adap.owner = THIS_MODULE;
>   priv->adap.algo = &priv->algo;
>   priv->adap.algo_data = priv;
> - priv->adap.dev.parent = &parent->dev;
> + priv->adap.dev.parent = muxc->dev;
>   priv->adap.retries = parent->retries;
>   priv->adap.timeout = parent->timeout;
>   priv->adap.quirks = parent->quirks;
> --
> 2.7.4
> 

Re: [linux-next / tty] possible circular locking dependency detected

[Geert Uytterhoeven]

On Mon, May 22, 2017 at 9:39 AM, Sergey Senozhatsky
 wrote:
>
> [ 1274.378287] ==
> [ 1274.378289] WARNING: possible circular locking dependency detected
> [ 1274.378290] 4.12.0-rc1-next-20170522-dbg-7-gc09b2ab28b74-dirty #1317 
> Not tainted
> [ 1274.378291] --
> [ 1274.378293] kworker/u8:5/111 is trying to acquire lock:
> [ 1274.378294]  (&buf->lock){+.+...}, at: [] 
> tty_buffer_flush+0x34/0x88
> [ 1274.378300]
>but task is already holding lock:
> [ 1274.378301]  (&o_tty->termios_rwsem/1){..}, at: [] 
> isig+0x47/0xd2
> [ 1274.378307]
>which lock already depends on the new lock.
>
> [ 1274.378309]
>the existing dependency chain (in reverse order) is:
> [ 1274.378310]
>-> #2 (&o_tty->termios_rwsem/1){..}:
> [ 1274.378316]lock_acquire+0x183/0x1ae
> [ 1274.378319]down_read+0x3e/0x62
> [ 1274.378321]n_tty_write+0x6c/0x3d6
> [ 1274.378322]tty_write+0x1cc/0x25f
> [ 1274.378325]__vfs_write+0x26/0xec
> [ 1274.378327]vfs_write+0xe1/0x16a
> [ 1274.378329]SyS_write+0x51/0x8e
> [ 1274.378330]entry_SYSCALL_64_fastpath+0x18/0xad
> [ 1274.378331]
>-> #1 (&tty->atomic_write_lock){+.+.+.}:
> [ 1274.378335]lock_acquire+0x183/0x1ae
> [ 1274.378337]__mutex_lock+0x95/0x7ba
> [ 1274.378339]mutex_lock_nested+0x1b/0x1d
> [ 1274.378340]tty_port_default_receive_buf+0x4e/0x81
> [ 1274.378342]flush_to_ldisc+0x87/0xa1
> [ 1274.378345]process_one_work+0x2be/0x52b
> [ 1274.378346]worker_thread+0x1f3/0x2c5
> [ 1274.378349]kthread+0x131/0x139
> [ 1274.378350]ret_from_fork+0x2e/0x40
> [ 1274.378351]
>-> #0 (&buf->lock){+.+...}:
> [ 1274.378355]__lock_acquire+0xec4/0x1444
> [ 1274.378357]lock_acquire+0x183/0x1ae
> [ 1274.378358]__mutex_lock+0x95/0x7ba
> [ 1274.378360]mutex_lock_nested+0x1b/0x1d
> [ 1274.378362]tty_buffer_flush+0x34/0x88
> [ 1274.378364]pty_flush_buffer+0x27/0x70
> [ 1274.378366]tty_driver_flush_buffer+0x1b/0x1e
> [ 1274.378367]isig+0x9b/0xd2
> [ 1274.378369]n_tty_receive_signal_char+0x1c/0x59
> [ 1274.378371]n_tty_receive_char_special+0xa4/0x740
> [ 1274.378373]n_tty_receive_buf_common+0x452/0x810
> [ 1274.378374]n_tty_receive_buf2+0x14/0x16
> [ 1274.378376]tty_ldisc_receive_buf+0x1f/0x4a
> [ 1274.378377]tty_port_default_receive_buf+0x5f/0x81
> [ 1274.378379]flush_to_ldisc+0x87/0xa1
> [ 1274.378380]process_one_work+0x2be/0x52b
> [ 1274.378382]worker_thread+0x1f3/0x2c5
> [ 1274.378383]kthread+0x131/0x139
> [ 1274.378385]ret_from_fork+0x2e/0x40
> [ 1274.378386]
>other info that might help us debug this:

JFTR, I'm also seeing this on various arm/arm64 platforms.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: ravb WoL interrupt flood

[Niklas Söderlund]

Hi Geert,

Thanks for the report. I did run a 200+ loop suspend/resume without 
issues so this error is probably hard to reproduce or something changed 
since v4.11-rc1 which if IIRC was the base I used to do the tests.

All I can think of is that if the interface was down at the time the 
system was suspend. There is a bug in  the driver which is in 
renesas-drivers related to that. But given that you woken up by WoL that 
is probably not the case :-)

I will do more tests and see if I can reproduce this once I'm back in 
Stockholm.


On 2017-05-30 11:23:23 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> I just got a flood of messages after WoL from s2idle on r8a7795/salvator-x:
> 
> [  802.341060] ravb e680.ethernet eth0: ignoring interrupt, rx
> status 0x0001, rx mask 0x0001,
> [  802.350369] ravb e680.ethernet eth0: tx
> status 0x, tx mask 0x0001.
> [  802.359684] ravb e680.ethernet eth0: ignoring interrupt, rx
> status 0x0001, rx mask 0x0001,
> [  802.368993] ravb e680.ethernet eth0: tx
> status 0x, tx mask 0x0001.
> [  802.378308] ravb e680.ethernet eth0: ignoring interrupt, rx
> status 0x0001, rx mask 0x0001,
> [  802.387616] ravb e680.ethernet eth0: tx
> status 0x, tx mask 0x0001.
> [  802.396931] ravb e680.ethernet eth0: ignoring interrupt, rx
> status 0x0001, rx mask 0x0001,
> [  802.406240] ravb e680.ethernet eth0: tx
> status 0x, tx mask 0x0001.
> ...
> 
> Unfortunately I cannot reproduce it.
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

-- 
Regards,
Niklas Söderlund

Re: [PATCH] mmc: tmio: make sure SDIO gets reinitialized after resume

[Ulf Hansson]

On 23 May 2017 at 15:34, Wolfram Sang  wrote:
> To achieve that, we set the registers in the generic HW reset routine
> which gets called at both, init and resume. We also make sure to move
> SDIO initialization before reset gets called in probe().
>
> Signed-off-by: Wolfram Sang 
> Tested-by: Masaharu Hayakawa 

Thanks, applied for next!

Kind regards
Uffe

> ---
>
> Changes since RFT:
> * added tag from Hayakawa-san (thanks!)
> * rebased to mmc/next (on top of the DMA refactor series)
>
>  drivers/mmc/host/tmio_mmc_core.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_core.c 
> b/drivers/mmc/host/tmio_mmc_core.c
> index e1ad461c4b8c8f..ed40681253497a 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -265,6 +265,12 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
> if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
> msleep(10);
> +
> +   if (host->pdata->flags & TMIO_MMC_SDIO_IRQ) {
> +   sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
> +   sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
> +   }
> +
>  }
>
>  static void tmio_mmc_reset_work(struct work_struct *work)
> @@ -1280,6 +1286,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
> if (_host->native_hotplug)
> pm_runtime_get_noresume(&pdev->dev);
>
> +   _host->sdio_irq_enabled = false;
> +   if (pdata->flags & TMIO_MMC_SDIO_IRQ)
> +   _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
> +
> tmio_mmc_clk_stop(_host);
> tmio_mmc_reset(_host);
>
> @@ -1296,13 +1306,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
>
> _host->sdcard_irq_mask &= ~irq_mask;
>
> -   _host->sdio_irq_enabled = false;
> -   if (pdata->flags & TMIO_MMC_SDIO_IRQ) {
> -   _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
> -   sd_ctrl_write16(_host, CTL_SDIO_IRQ_MASK, 
> _host->sdio_irq_mask);
> -   sd_ctrl_write16(_host, CTL_TRANSACTION_CTL, 0x0001);
> -   }
> -
> spin_lock_init(&_host->lock);
> mutex_init(&_host->ios_lock);
>
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/7] mmc: use proper name for the R-Car SoC

[Ulf Hansson]

On 30 May 2017 at 09:16, Lee Jones  wrote:
> On Mon, 29 May 2017, Ulf Hansson wrote:
>
>> On 28 May 2017 at 11:30, Wolfram Sang  
>> wrote:
>> > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive 
>> > text.
>> >
>> > Signed-off-by: Wolfram Sang 
>>
>> Thanks, applied for next!
>>
>> For mfd, Lee, please tell if you have any issues me picking this via
>> my mmc tree.
>
> I don't, but it is normal procedure to wait for an Ack from all
> Maintainers involved before applying. ;)

Yeah! However this was that trivial so I went ahead. :-)

Kind regards
Uffe

ravb WoL interrupt flood

[Geert Uytterhoeven]

Hi Niklas,

I just got a flood of messages after WoL from s2idle on r8a7795/salvator-x:

[  802.341060] ravb e680.ethernet eth0: ignoring interrupt, rx
status 0x0001, rx mask 0x0001,
[  802.350369] ravb e680.ethernet eth0: tx
status 0x, tx mask 0x0001.
[  802.359684] ravb e680.ethernet eth0: ignoring interrupt, rx
status 0x0001, rx mask 0x0001,
[  802.368993] ravb e680.ethernet eth0: tx
status 0x, tx mask 0x0001.
[  802.378308] ravb e680.ethernet eth0: ignoring interrupt, rx
status 0x0001, rx mask 0x0001,
[  802.387616] ravb e680.ethernet eth0: tx
status 0x, tx mask 0x0001.
[  802.396931] ravb e680.ethernet eth0: ignoring interrupt, rx
status 0x0001, rx mask 0x0001,
[  802.406240] ravb e680.ethernet eth0: tx
status 0x, tx mask 0x0001.
...

Unfortunately I cannot reproduce it.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] mmc: renesas_sdhi_core: on R-Car 2+, make use of CBSY bit

[Wolfram Sang]

Most registers need to wait until the command is completed, not
necessarily until the bus is free. At least, R-Car 2+ SoCs can signal
that via the CBSY bit, so let's use it there instead of SCLKDIVEN to
save a little bit of delay.

Signed-off-by: Wolfram Sang 
---

Tested with a Renesas Lager board (H2). Moved big files around across different
SD cards, re- inserted cards multiple times. All worked fine.

@Dirk: can you do some additional testing for your use case? That would be much
appreciated!

Changes since RFC (from Jan 2016):
* rebased to latest code base
* use existing bit defines instead of creating new ones

 drivers/mmc/host/renesas_sdhi_core.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 82150a96639195..288153b5f6835e 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -395,12 +395,14 @@ static void renesas_sdhi_hw_reset(struct tmio_mmc_host 
*host)
   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL));
 }
 
-static int renesas_sdhi_wait_idle(struct tmio_mmc_host *host)
+static int renesas_sdhi_wait_idle(struct tmio_mmc_host *host, u32 bit)
 {
int timeout = 1000;
+   /* CBSY is set when busy, SCLKDIVEN is cleared when busy */
+   u32 wait_state = (bit == TMIO_STAT_CMD_BUSY ? TMIO_STAT_CMD_BUSY : 0);
 
-   while (--timeout && !(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS)
- & TMIO_STAT_SCLKDIVEN))
+   while (--timeout && (sd_ctrl_read16_and_16_as_32(host, CTL_STATUS)
+ & bit) == wait_state)
udelay(1);
 
if (!timeout) {
@@ -413,18 +415,23 @@ static int renesas_sdhi_wait_idle(struct tmio_mmc_host 
*host)
 
 static int renesas_sdhi_write16_hook(struct tmio_mmc_host *host, int addr)
 {
+   u32 bit = TMIO_STAT_SCLKDIVEN;
+
switch (addr)
{
case CTL_SD_CMD:
case CTL_STOP_INTERNAL_ACTION:
case CTL_XFER_BLK_COUNT:
-   case CTL_SD_CARD_CLK_CTL:
case CTL_SD_XFER_LEN:
case CTL_SD_MEM_CARD_OPT:
case CTL_TRANSACTION_CTL:
case CTL_DMA_ENABLE:
case EXT_ACC:
-   return renesas_sdhi_wait_idle(host);
+   if (host->pdata->flags & TMIO_MMC_MIN_RCAR2)
+   bit = TMIO_STAT_CMD_BUSY;
+   /* fallthrough */
+   case CTL_SD_CARD_CLK_CTL:
+   return renesas_sdhi_wait_idle(host, bit);
}
 
return 0;
-- 
2.11.0

[PATCH v2] i2c: i2c-mux: Fix channel parent node assignment

[Jacopo Mondi]

I2c-mux channels are created as mux siblings while they should be
children of the mux itself. Fix it.

Signed-off-by: Jacopo Mondi 
Suggested-by: Laurent Pinchart 
---

Hello,
   while inspecting child nodes of an i2c adapter it has been noted that
child devices of an i2c-mux are listed as children of the i2c adapter itself,
and not of the i2c-mux.

The hierarchy of devices looked like

-- i2c-04
--- eeprom@57
--- video_receiver@70
--- video_receiver@34
--- gmsl-deserializer@0 <-- MUX
--- gmsl-deserializer@0/i2c@0   <-- MUX CHANNEL

It now looks like

-- i2c-04
--- eeprom@57
--- video_receiver@70
--- video_receiver@34
--- gmsl-deserializer@0
 gmsl-deserializer@0/i2c@0

v1 -> v2:
- change commit message as suggested by Geert

 drivers/i2c/i2c-mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 83768e8..37b7804 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -324,7 +324,7 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
priv->adap.owner = THIS_MODULE;
priv->adap.algo = &priv->algo;
priv->adap.algo_data = priv;
-   priv->adap.dev.parent = &parent->dev;
+   priv->adap.dev.parent = muxc->dev;
priv->adap.retries = parent->retries;
priv->adap.timeout = parent->timeout;
priv->adap.quirks = parent->quirks;
--
2.7.4

Re: [PATCH] i2c: i2c-mux: Fix channel parent node assignment

[Geert Uytterhoeven]

Hi Jacopo,

On Tue, May 30, 2017 at 10:38 AM, jmondi  wrote:
> On Tue, May 30, 2017 at 10:31:21AM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 30, 2017 at 10:13 AM, Jacopo Mondi
>>  wrote:
>> > I2c-mux channels are created with the mux parent device as their own
>> > parent, while they should be siblings of the mux itself.
>>
>> Isn't it the other way around? Cfr. the example and the patch.
>
> Yeah, I actually didn't know the exact meaning of "siblings" then.
>
> So:
> I2c-mux channels are created as mux siblings while they should be
> children of the mux itself. Fix it.
>
> Any better? ;)

Perfect!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 0/4] r8a7793 Gose video input support

[Simon Horman]

On Fri, May 26, 2017 at 08:49:07AM +0200, Simon Horman wrote:
> On Fri, May 19, 2017 at 03:07:00PM +0200, Ulrich Hecht wrote:
> > Hi!
> > 
> > This is a by-the-datasheet implementation of analog and digital video input
> > on the Gose board.
> > 
> > This revision adds new bindings that distinguish between ADV7180 variants
> > with three and six input ports. There are numerous variants of this chip,
> > but since all that have "CP" in their names have three inputs, and all that
> > have "ST" have six, I have limited myself to two new compatible strings,
> > "adv7180cp" and "adv7180st".
> > 
> > The digital input patch has received minor tweaks of the port names for
> > consistency, and the Gose analog input patch has been modified to use the
> > new bindings, and a composite video connector has been added.
> > 
> > CU
> > Uli
> > 
> > 
> > Changes since v2:
> > - hdmi: port hdmi_con renamed to hdmi_con_out
> > - adv7180: added new compatibility strings and bindings
> > - composite: added connector, use new bindings
> > 
> > Changes since v1:
> > - r8a7793.dtsi: added VIN2
> > - modeled HDMI decoder input/output and connector
> > - added "renesas,rcar-gen2-vin" compat strings
> > - removed unnecessary "remote" node and aliases
> > - set ADV7612 interrupt to GP4_2
> > 
> > 
> > Ulrich Hecht (4):
> >   ARM: dts: gose: add HDMI input
> 
> I have queued-up the above patch for v4.13.
> 
> >   media: adv7180: add adv7180cp, adv7180st compatible strings
> >   media: adv7180: Add adv7180cp, adv7180st bindings
> >   ARM: dts: gose: add composite video input
> 
> I have marked the above dts patch as "deferred" pending acceptance
> of the binding. Please repost or otherwise ping me once that has happened.

It looks like Hans will pick up the driver patches.
Accordingly I have queued-up the last dts patch above.

Re: [PATCH v3 0/4] r8a7793 Gose video input support

[Simon Horman]

On Mon, May 29, 2017 at 11:08:12AM +0200, Hans Verkuil wrote:
> On 05/19/2017 03:07 PM, Ulrich Hecht wrote:
> >Hi!
> >
> >This is a by-the-datasheet implementation of analog and digital video input
> >on the Gose board.
> >
> >This revision adds new bindings that distinguish between ADV7180 variants
> >with three and six input ports. There are numerous variants of this chip,
> >but since all that have "CP" in their names have three inputs, and all that
> >have "ST" have six, I have limited myself to two new compatible strings,
> >"adv7180cp" and "adv7180st".
> >
> >The digital input patch has received minor tweaks of the port names for
> >consistency, and the Gose analog input patch has been modified to use the
> >new bindings, and a composite video connector has been added.
> 
> Looks good. I assume the dts changes go through 
> linux-renesas-soc@vger.kernel.org?

Yes, I will pick up the dts changes.

> I'll pick up the adv7180 changes.

Thanks!

Re: [PATCH] ARM: dts: r7s72100: add clock bit definitions

[Simon Horman]

On Mon, May 29, 2017 at 11:31:37AM +0200, Geert Uytterhoeven wrote:
> Hi Chris,
> 
> On Thu, May 25, 2017 at 6:05 PM, Chris Brandt  
> wrote:
> > Add the remaining bit locations for the module stop clock registers.
> >
> > Signed-off-by: Chris Brandt 
> 
> Reviewed-by: Geert Uytterhoeven 

Chris, please address Geert's review and repost as appropriate.

> 
> > --- a/include/dt-bindings/clock/r7s72100-clock.h
> > +++ b/include/dt-bindings/clock/r7s72100-clock.h
> > @@ -13,7 +13,14 @@
> >  #define R7S72100_CLK_PLL   0
> 
> No CoreSight (MSTP20)?
> 
> >  /* MSTP3 */
> > +#define R7S72100_CLK_IEBUS 7
> > +#define R7S72100_CLK_IRDA  6
> > +#define R7S72100_CLK_LIN0  5
> > +#define R7S72100_CLK_LIN1  4
> >  #define R7S72100_CLK_MTU2  3
> > +#define R7S72100_CLK_CAN   2
> > +#define R7S72100_CLK_ADCPWR1
> > +#define R7S72100_CLK_MCPWM 0
> 
> Perhaps just R7S72100_CLK_PWM?
> 
> >  /* MSTP4 */
> >  #define R7S72100_CLK_SCIF0 7
> > @@ -26,25 +33,51 @@
> >  #define R7S72100_CLK_SCIF7 0
> >
> >  /* MSTP5 */
> > +#define R7S72100_CLK_SCI0  7
> > +#define R7S72100_CLK_SCI1  6
> > +#define R7S72100_CLK_SNDGEN0   5
> > +#define R7S72100_CLK_SNDGEN1   4
> > +#define R7S72100_CLK_SNDGEN2   3
> > +#define R7S72100_CLK_SNDGEN3   2
> 
> R7S72100_CLK_SG[0-3]?
> 
> >  #define R7S72100_CLK_OSTM0 1
> >  #define R7S72100_CLK_OSTM1 0
> >
> >  /* MSTP6 */
> > +#define R7S72100_CLK_ADC   7
> > +#define R7S72100_CLK_CEU   6
> > +#define R7S72100_CLK_DOC0  5
> > +#define R7S72100_CLK_DOC1  4
> > +#define R7S72100_CLK_DRC0  3
> > +#define R7S72100_CLK_DRC1  2
> > +#define R7S72100_CLK_JCU   1
> >  #define R7S72100_CLK_RTC   0
> >
> >  /* MSTP7 */
> > +#define R7S72100_CLK_VDEC0 7
> > +#define R7S72100_CLK_VDEC1 6
> 
> R7S72100_CLK_VIN[01]?
> 
> >  #define R7S72100_CLK_ETHER 4
> > +#define R7S72100_CLK_NAND  3
> >  #define R7S72100_CLK_USB0  1
> >  #define R7S72100_CLK_USB1  0
> >
> >  /* MSTP8 */
> > +#define R7S72100_CLK_IMR0  7
> > +#define R7S72100_CLK_IMR1  6
> > +#define R7S72100_CLK_IMRDISP   5
> >  #define R7S72100_CLK_MMCIF 4
> > +#define R7S72100_CLK_MLB   3
> > +#define R7S72100_CLK_ETHABV2
> 
> R7S72100_CLK_ETHAVB
> 
> > +#define R7S72100_CLK_SCUX  1
> >
> >  /* MSTP9 */
> >  #define R7S72100_CLK_I2C0  7
> >  #define R7S72100_CLK_I2C1  6
> >  #define R7S72100_CLK_I2C2  5
> >  #define R7S72100_CLK_I2C3  4
> > +#define R7S72100_CLK_SPIMBC0   3
> > +#define R7S72100_CLK_SPIMBC1   2
> 
> R7S72100_CLK_SPB[0-1]?
> All related registers and clocks are called SPB.
> 
> > +#define R7S72100_CLK_VDC50 1   /* and LVDS */
> > +#define R7S72100_CLK_VDC51 0
> >
> >  /* MSTP10 */
> >  #define R7S72100_CLK_SPI0  7
> > @@ -52,6 +85,9 @@
> >  #define R7S72100_CLK_SPI2  5
> >  #define R7S72100_CLK_SPI3  4
> >  #define R7S72100_CLK_SPI4  3
> > +#define R7S72100_CLK_CDROM 2
> > +#define R7S72100_CLK_SPDIF 1
> > +#define R7S72100_CLK_RGPVG20
> 
> No SSI (MSTP11[0-5])?
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH 5/7] pci: use proper name for the R-Car SoC

[Simon Horman]

On Mon, May 29, 2017 at 11:13:48AM +0200, Geert Uytterhoeven wrote:
> On Sun, May 28, 2017 at 11:30 AM, Wolfram Sang
>  wrote:
> > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive 
> > text.
> >
> > Signed-off-by: Wolfram Sang 
> 
> Acked-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

Re: [PATCH 0/2] arm64: dts: r8a779[56]: add DMA for IIC_DVFS

[Simon Horman]

On Sun, May 28, 2017 at 12:14:28PM +0200, Wolfram Sang wrote:
> Based on renesas-drivers/master as of today. Please apply.
> 
> Wolfram Sang (2):
>   arm64: dts: r8a7795: add DMA for IIC_DVFS
>   arm64: dts: r8a7796: add DMA for IIC_DVFS

Thanks, I have queued these up.

Re: [PATCH] i2c: i2c-mux: Fix channel parent node assignment

[jmondi]

Hi Geert,

On Tue, May 30, 2017 at 10:31:21AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, May 30, 2017 at 10:13 AM, Jacopo Mondi
>  wrote:
> > I2c-mux channels are created with the mux parent device as their own
> > parent, while they should be siblings of the mux itself.
>
> Isn't it the other way around? Cfr. the example and the patch.

Yeah, I actually didn't know the exact meaning of "siblings" then.

So:
I2c-mux channels are created as mux siblings while they should be
children of the mux itself. Fix it.

Any better? ;)

Thanks
   j
>
> > Fix this.
> >
> > Signed-off-by: Jacopo Mondi 
> > Suggested-by: Laurent Pinchart 
> >
> > ---
> >
> > Hello,
> >while inspecting child nodes of an i2c adapter it has been noted that
> > child devices of an i2c-mux are listed as children of the i2c adapter 
> > itself,
> > and not of the i2c-mux.
> >
> > The hierarchy of devices looked like
> >
> > -- i2c-04
> > --- eeprom@57
> > --- video_receiver@70
> > --- video_receiver@34
> > --- gmsl-deserializer@0 <-- MUX
> > --- gmsl-deserializer@0/i2c@0   <-- MUX CHANNEL
>
> = sibling of mux
>
> >
> > It now looks like
> >
> > -- i2c-04
> > --- eeprom@57
> > --- video_receiver@70
> > --- video_receiver@34
> > --- gmsl-deserializer@0
> >  gmsl-deserializer@0/i2c@0
>
> = child of mux
>
> >
> >  drivers/i2c/i2c-mux.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> > index 83768e8..37b7804 100644
> > --- a/drivers/i2c/i2c-mux.c
> > +++ b/drivers/i2c/i2c-mux.c
> > @@ -324,7 +324,7 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
> > priv->adap.owner = THIS_MODULE;
> > priv->adap.algo = &priv->algo;
> > priv->adap.algo_data = priv;
> > -   priv->adap.dev.parent = &parent->dev;
>
> = sibling of mux
>
> > +   priv->adap.dev.parent = muxc->dev;
>
> = child of mux
>
> > priv->adap.retries = parent->retries;
> > priv->adap.timeout = parent->timeout;
> > priv->adap.quirks = parent->quirks;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH] i2c: i2c-mux: Fix channel parent node assignment

[Geert Uytterhoeven]

Hi Jacopo,

On Tue, May 30, 2017 at 10:13 AM, Jacopo Mondi
 wrote:
> I2c-mux channels are created with the mux parent device as their own
> parent, while they should be siblings of the mux itself.

Isn't it the other way around? Cfr. the example and the patch.

> Fix this.
>
> Signed-off-by: Jacopo Mondi 
> Suggested-by: Laurent Pinchart 
>
> ---
>
> Hello,
>while inspecting child nodes of an i2c adapter it has been noted that
> child devices of an i2c-mux are listed as children of the i2c adapter itself,
> and not of the i2c-mux.
>
> The hierarchy of devices looked like
>
> -- i2c-04
> --- eeprom@57
> --- video_receiver@70
> --- video_receiver@34
> --- gmsl-deserializer@0 <-- MUX
> --- gmsl-deserializer@0/i2c@0   <-- MUX CHANNEL

= sibling of mux

>
> It now looks like
>
> -- i2c-04
> --- eeprom@57
> --- video_receiver@70
> --- video_receiver@34
> --- gmsl-deserializer@0
>  gmsl-deserializer@0/i2c@0

= child of mux

>
>  drivers/i2c/i2c-mux.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 83768e8..37b7804 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -324,7 +324,7 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
> priv->adap.owner = THIS_MODULE;
> priv->adap.algo = &priv->algo;
> priv->adap.algo_data = priv;
> -   priv->adap.dev.parent = &parent->dev;

= sibling of mux

> +   priv->adap.dev.parent = muxc->dev;

= child of mux

> priv->adap.retries = parent->retries;
> priv->adap.timeout = parent->timeout;
> priv->adap.quirks = parent->quirks;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] i2c: i2c-mux: Fix channel parent node assignment

[Jacopo Mondi]

I2c-mux channels are created with the mux parent device as their own
parent, while they should be siblings of the mux itself.
Fix this.

Signed-off-by: Jacopo Mondi 
Suggested-by: Laurent Pinchart 

---

Hello,
   while inspecting child nodes of an i2c adapter it has been noted that
child devices of an i2c-mux are listed as children of the i2c adapter itself,
and not of the i2c-mux.

The hierarchy of devices looked like

-- i2c-04
--- eeprom@57
--- video_receiver@70
--- video_receiver@34
--- gmsl-deserializer@0 <-- MUX
--- gmsl-deserializer@0/i2c@0   <-- MUX CHANNEL

It now looks like

-- i2c-04
--- eeprom@57
--- video_receiver@70
--- video_receiver@34
--- gmsl-deserializer@0
 gmsl-deserializer@0/i2c@0

 drivers/i2c/i2c-mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 83768e8..37b7804 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -324,7 +324,7 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
priv->adap.owner = THIS_MODULE;
priv->adap.algo = &priv->algo;
priv->adap.algo_data = priv;
-   priv->adap.dev.parent = &parent->dev;
+   priv->adap.dev.parent = muxc->dev;
priv->adap.retries = parent->retries;
priv->adap.timeout = parent->timeout;
priv->adap.quirks = parent->quirks;
--
2.7.4

Re: [PATCH 4/7] mmc: use proper name for the R-Car SoC

[Lee Jones]

On Mon, 29 May 2017, Ulf Hansson wrote:

> On 28 May 2017 at 11:30, Wolfram Sang  
> wrote:
> > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive 
> > text.
> >
> > Signed-off-by: Wolfram Sang 
> 
> Thanks, applied for next!
> 
> For mfd, Lee, please tell if you have any issues me picking this via
> my mmc tree.

I don't, but it is normal procedure to wait for an Ack from all
Maintainers involved before applying. ;)

> > ---
> > I suggest this trivial patch should be picked individually per susbsystem.
> >
> >  drivers/mmc/host/renesas_sdhi_core.c | 2 +-
> >  include/linux/mfd/tmio.h | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
> > b/drivers/mmc/host/renesas_sdhi_core.c
> > index 846ee1a8e5a675..397b3e29977ea8 100644
> > --- a/drivers/mmc/host/renesas_sdhi_core.c
> > +++ b/drivers/mmc/host/renesas_sdhi_core.c
> > @@ -130,7 +130,7 @@ static unsigned int renesas_sdhi_clk_update(struct 
> > tmio_mmc_host *host,
> > unsigned int freq, diff, best_freq = 0, diff_min = ~0;
> > int i, ret;
> >
> > -   /* tested only on RCar Gen2+ currently; may work for others */
> > +   /* tested only on R-Car Gen2+ currently; may work for others */
> > if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> > return clk_get_rate(priv->clk);
> >
> > diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
> > index a1520d88ebf3a3..c83c16b931a886 100644
> > --- a/include/linux/mfd/tmio.h
> > +++ b/include/linux/mfd/tmio.h
> > @@ -66,7 +66,7 @@
> >   */
> >  #define TMIO_MMC_SDIO_IRQ  (1 << 2)
> >
> > -/* Some features are only available or tested on RCar Gen2 or later */
> > +/* Some features are only available or tested on R-Car Gen2 or later */
> >  #define TMIO_MMC_MIN_RCAR2 (1 << 3)
> >
> >  /*
> >

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog