Re: [PATCH 9/9] mmc: Convert from tasklet to BH workqueue

[Ulf Hansson]

On Thu, 28 Mar 2024 at 17:21, Tejun Heo  wrote:
>
> Hello,
>
> On Thu, Mar 28, 2024 at 01:53:25PM +0100, Ulf Hansson wrote:
> > At this point we have suggested to drivers to switch to use threaded
> > irq handlers (and regular work queues if needed too). That said,
> > what's the benefit of using the BH work queue?
>
> BH workqueues should behave about the same as tasklets which have more
> limited interface and is subtly broken in an expensive-to-fix way (around
> freeing in-flight work item), so the plan is to replace tasklets with BH
> workqueues and remove tasklets from the kernel.

Seems like a good approach!

>
> The [dis]advantages of BH workqueues over threaded IRQs or regular threaded
> workqueues are the same as when you compare them to tasklets. No thread
> switching overhead, so latencies will be a bit tighter. Wheteher that
> actually matters really depends on the use case. Here, the biggest advantage
> is that it's mostly interchangeable with tasklets and can thus be swapped
> easily.

Right, thanks for clarifying!

However, the main question is then - if/when it makes sense to use the
BH workqueue for an mmc host driver. Unless there are some HW
limitations, a threaded irq handler should be sufficient, I think.

That said, moving to threaded irq handlers is a different topic and
doesn't prevent us from moving to BH workqueues as it seems like a
step in the right direction.

Kind regards
Uffe

Re: [PATCH 9/9] mmc: Convert from tasklet to BH workqueue

[Ulf Hansson]

On Wed, 27 Mar 2024 at 17:03, Allen Pais  wrote:
>
> The only generic interface to execute asynchronously in the BH context is
> tasklet; however, it's marked deprecated and has some design flaws. To
> replace tasklets, BH workqueue support was recently added. A BH workqueue
> behaves similarly to regular workqueues except that the queued work items
> are executed in the BH context.
>
> This patch converts drivers/infiniband/* from tasklet to BH workqueue.
>
> Based on the work done by Tejun Heo 
> Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10
>
> Signed-off-by: Allen Pais 

Overall, this makes sense to me. However, just to make things clear,
an mmc host driver shouldn't really need the tasklet. As I understand
it, the few remaining users are there for legacy reasons.

At this point we have suggested to drivers to switch to use threaded
irq handlers (and regular work queues if needed too). That said,
what's the benefit of using the BH work queue?

Kind regards
Uffe

> ---
>  drivers/mmc/host/atmel-mci.c  | 35 -
>  drivers/mmc/host/au1xmmc.c| 37 -
>  drivers/mmc/host/cb710-mmc.c  | 15 ++--
>  drivers/mmc/host/cb710-mmc.h  |  3 +-
>  drivers/mmc/host/dw_mmc.c | 25 ---
>  drivers/mmc/host/dw_mmc.h |  9 ++-
>  drivers/mmc/host/omap.c   | 17 +++--
>  drivers/mmc/host/renesas_sdhi.h   |  3 +-
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 24 +++---
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  |  9 +--
>  drivers/mmc/host/sdhci-bcm-kona.c |  2 +-
>  drivers/mmc/host/tifm_sd.c| 15 ++--
>  drivers/mmc/host/tmio_mmc.h   |  3 +-
>  drivers/mmc/host/tmio_mmc_core.c  |  4 +-
>  drivers/mmc/host/uniphier-sd.c| 13 ++--
>  drivers/mmc/host/via-sdmmc.c  | 25 ---
>  drivers/mmc/host/wbsd.c   | 75 ++-
>  drivers/mmc/host/wbsd.h   | 10 +--
>  18 files changed, 167 insertions(+), 157 deletions(-)
>
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index dba826db739a..0a92a7fd020f 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -284,12 +285,12 @@ struct atmel_mci_dma {
>   * EVENT_DATA_ERROR is pending.
>   * @stop_cmdr: Value to be loaded into CMDR when the stop command is
>   * to be sent.
> - * @tasklet: Tasklet running the request state machine.
> + * @work: Work running the request state machine.
>   * @pending_events: Bitmask of events flagged by the interrupt handler
> - * to be processed by the tasklet.
> + * to be processed by the work.
>   * @completed_events: Bitmask of events which the state machine has
>   * processed.
> - * @state: Tasklet state.
> + * @state: Work state.
>   * @queue: List of slots waiting for access to the controller.
>   * @need_clock_update: Update the clock rate before the next request.
>   * @need_reset: Reset controller before next request.
> @@ -363,7 +364,7 @@ struct atmel_mci {
> u32 data_status;
> u32 stop_cmdr;
>
> -   struct tasklet_struct   tasklet;
> +   struct work_struct  work;
> unsigned long   pending_events;
> unsigned long   completed_events;
> enum atmel_mci_statestate;
> @@ -761,7 +762,7 @@ static void atmci_timeout_timer(struct timer_list *t)
> host->need_reset = 1;
> host->state = STATE_END_REQUEST;
> smp_wmb();
> -   tasklet_schedule(>tasklet);
> +   queue_work(system_bh_wq, >work);
>  }
>
>  static inline unsigned int atmci_ns_to_clocks(struct atmel_mci *host,
> @@ -983,7 +984,7 @@ static void atmci_pdc_complete(struct atmel_mci *host)
>
> dev_dbg(>pdev->dev, "(%s) set pending xfer complete\n", 
> __func__);
> atmci_set_pending(host, EVENT_XFER_COMPLETE);
> -   tasklet_schedule(>tasklet);
> +   queue_work(system_bh_wq, >work);
>  }
>
>  static void atmci_dma_cleanup(struct atmel_mci *host)
> @@ -997,7 +998,7 @@ static void atmci_dma_cleanup(struct atmel_mci *host)
>  }
>
>  /*
> - * This function is called by the DMA driver from tasklet context.
> + * This function is called by the DMA driver from work context.
>   */
>  static void atmci_dma_complete(void *arg)
>  {
> @@ -1020,7 +1021,7 @@ static void atmci_dma_complete(void *arg)
> dev_dbg(>pdev->dev,
> "(%s) set pending xfer complete\n", __func__);
> atmci_set_pending(host, EVENT_XFER_COMPLETE);
> -   tasklet_schedule(>tasklet);
> +   queue_work(system_bh_wq, >work);
>
> /*
>  * Regardless of what the documentation 

Re: [PATCH v3 07/13] tty: Convert ->dtr_rts() to take bool argument

[Ulf Hansson]

On Wed, 11 Jan 2023 at 15:24, Ilpo Järvinen
 wrote:
>
> Convert the raise/on parameter in ->dtr_rts() to bool through the
> callchain. The parameter is used like bool. In USB serial, there
> remains a few implicit bool -> larger type conversions because some
> devices use u8 in their control messages.
>
> In moxa_tiocmget(), dtr variable was reused for line status which
> requires int so use a separate variable for status.
>
> Reviewed-by: Jiri Slaby 
> Signed-off-by: Ilpo Järvinen 

Acked-by: Ulf Hansson  # For MMC

Kind regards
Uffe


> ---
>  drivers/char/pcmcia/synclink_cs.c|  4 +--
>  drivers/mmc/core/sdio_uart.c |  4 +--
>  drivers/staging/greybus/uart.c   |  2 +-
>  drivers/tty/amiserial.c  |  2 +-
>  drivers/tty/hvc/hvc_console.c|  4 +--
>  drivers/tty/hvc/hvc_console.h|  2 +-
>  drivers/tty/hvc/hvc_iucv.c   |  4 +--
>  drivers/tty/moxa.c   | 54 ++--
>  drivers/tty/mxser.c  |  2 +-
>  drivers/tty/n_gsm.c  |  2 +-
>  drivers/tty/serial/serial_core.c |  8 ++---
>  drivers/tty/synclink_gt.c|  2 +-
>  drivers/tty/tty_port.c   |  4 +--
>  drivers/usb/class/cdc-acm.c  |  2 +-
>  drivers/usb/serial/ch341.c   |  2 +-
>  drivers/usb/serial/cp210x.c  |  4 +--
>  drivers/usb/serial/cypress_m8.c  |  6 ++--
>  drivers/usb/serial/digi_acceleport.c |  6 ++--
>  drivers/usb/serial/f81232.c  |  2 +-
>  drivers/usb/serial/f81534.c  |  2 +-
>  drivers/usb/serial/ftdi_sio.c|  2 +-
>  drivers/usb/serial/ipw.c |  2 +-
>  drivers/usb/serial/keyspan.c |  2 +-
>  drivers/usb/serial/keyspan_pda.c |  2 +-
>  drivers/usb/serial/mct_u232.c|  4 +--
>  drivers/usb/serial/mxuport.c |  2 +-
>  drivers/usb/serial/pl2303.c  |  2 +-
>  drivers/usb/serial/quatech2.c|  2 +-
>  drivers/usb/serial/sierra.c  |  2 +-
>  drivers/usb/serial/spcp8x5.c |  2 +-
>  drivers/usb/serial/ssu100.c  |  2 +-
>  drivers/usb/serial/upd78f0730.c  |  6 ++--
>  drivers/usb/serial/usb-serial.c  |  2 +-
>  drivers/usb/serial/usb-wwan.h|  2 +-
>  drivers/usb/serial/usb_wwan.c|  2 +-
>  drivers/usb/serial/xr_serial.c   |  6 ++--
>  include/linux/tty_port.h |  4 +--
>  include/linux/usb/serial.h   |  2 +-
>  38 files changed, 84 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/char/pcmcia/synclink_cs.c 
> b/drivers/char/pcmcia/synclink_cs.c
> index 4391138e1b8a..46a0b586d234 100644
> --- a/drivers/char/pcmcia/synclink_cs.c
> +++ b/drivers/char/pcmcia/synclink_cs.c
> @@ -378,7 +378,7 @@ static void async_mode(MGSLPC_INFO *info);
>  static void tx_timeout(struct timer_list *t);
>
>  static bool carrier_raised(struct tty_port *port);
> -static void dtr_rts(struct tty_port *port, int onoff);
> +static void dtr_rts(struct tty_port *port, bool onoff);
>
>  #if SYNCLINK_GENERIC_HDLC
>  #define dev_to_port(D) (dev_to_hdlc(D)->priv)
> @@ -2442,7 +2442,7 @@ static bool carrier_raised(struct tty_port *port)
> return info->serial_signals & SerialSignal_DCD;
>  }
>
> -static void dtr_rts(struct tty_port *port, int onoff)
> +static void dtr_rts(struct tty_port *port, bool onoff)
>  {
> MGSLPC_INFO *info = container_of(port, MGSLPC_INFO, port);
> unsigned long flags;
> diff --git a/drivers/mmc/core/sdio_uart.c b/drivers/mmc/core/sdio_uart.c
> index 47f58258d8ff..c6b4b2b2a4b2 100644
> --- a/drivers/mmc/core/sdio_uart.c
> +++ b/drivers/mmc/core/sdio_uart.c
> @@ -548,14 +548,14 @@ static bool uart_carrier_raised(struct tty_port *tport)
>   * adjusted during an open, close and hangup.
>   */
>
> -static void uart_dtr_rts(struct tty_port *tport, int onoff)
> +static void uart_dtr_rts(struct tty_port *tport, bool onoff)
>  {
> struct sdio_uart_port *port =
> container_of(tport, struct sdio_uart_port, port);
> int ret = sdio_uart_claim_func(port);
> if (ret)
> return;
> -   if (onoff == 0)
> +   if (!onoff)
> sdio_uart_clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
> else
> sdio_uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
> diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
> index 90ff07f2cbf7..92d49740d5a4 100644
> --- a/drivers/staging/greybus/uart.c
> +++ b/drivers/staging/greybus/uart.c
> @@ -701,7 +701,7 @@ static int gb_tty_ioctl(struct tty_struct *tty, unsigned 
> int cmd,
> return -ENOIOCTLCMD;
>  }
>
> -static void gb_tty_dtr_rts(struct tty

Re: [PATCH v3 11/13] tty/serial: Call ->dtr_rts() parameter active consistently

[Ulf Hansson]

On Wed, 11 Jan 2023 at 15:24, Ilpo Järvinen
 wrote:
>
> Convert various parameter names for ->dtr_rts() and related functions
> from onoff, on, and raise to active.
>
> Reviewed-by: Jiri Slaby 
> Signed-off-by: Ilpo Järvinen 

Acked-by: Ulf Hansson  # For MMC

Kind regards
Uffe

> ---
>  drivers/char/pcmcia/synclink_cs.c | 6 +++---
>  drivers/mmc/core/sdio_uart.c  | 6 +++---
>  drivers/staging/greybus/uart.c| 4 ++--
>  drivers/tty/amiserial.c   | 4 ++--
>  drivers/tty/hvc/hvc_console.h | 2 +-
>  drivers/tty/hvc/hvc_iucv.c| 6 +++---
>  drivers/tty/mxser.c   | 4 ++--
>  drivers/tty/n_gsm.c   | 4 ++--
>  drivers/tty/serial/serial_core.c  | 8 
>  drivers/tty/synclink_gt.c | 4 ++--
>  include/linux/tty_port.h  | 4 ++--
>  include/linux/usb/serial.h| 2 +-
>  12 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/char/pcmcia/synclink_cs.c 
> b/drivers/char/pcmcia/synclink_cs.c
> index 46a0b586d234..1577eba6fe0e 100644
> --- a/drivers/char/pcmcia/synclink_cs.c
> +++ b/drivers/char/pcmcia/synclink_cs.c
> @@ -378,7 +378,7 @@ static void async_mode(MGSLPC_INFO *info);
>  static void tx_timeout(struct timer_list *t);
>
>  static bool carrier_raised(struct tty_port *port);
> -static void dtr_rts(struct tty_port *port, bool onoff);
> +static void dtr_rts(struct tty_port *port, bool active);
>
>  #if SYNCLINK_GENERIC_HDLC
>  #define dev_to_port(D) (dev_to_hdlc(D)->priv)
> @@ -2442,13 +2442,13 @@ static bool carrier_raised(struct tty_port *port)
> return info->serial_signals & SerialSignal_DCD;
>  }
>
> -static void dtr_rts(struct tty_port *port, bool onoff)
> +static void dtr_rts(struct tty_port *port, bool active)
>  {
> MGSLPC_INFO *info = container_of(port, MGSLPC_INFO, port);
> unsigned long flags;
>
> spin_lock_irqsave(>lock, flags);
> -   if (onoff)
> +   if (active)
> info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
> else
> info->serial_signals &= ~(SerialSignal_RTS | 
> SerialSignal_DTR);
> diff --git a/drivers/mmc/core/sdio_uart.c b/drivers/mmc/core/sdio_uart.c
> index c6b4b2b2a4b2..50536fe59f1a 100644
> --- a/drivers/mmc/core/sdio_uart.c
> +++ b/drivers/mmc/core/sdio_uart.c
> @@ -542,20 +542,20 @@ static bool uart_carrier_raised(struct tty_port *tport)
>  /**
>   * uart_dtr_rts-port helper to set uart signals
>   * @tport: tty port to be updated
> - * @onoff: set to turn on DTR/RTS
> + * @active: set to turn on DTR/RTS
>   *
>   * Called by the tty port helpers when the modem signals need to be
>   * adjusted during an open, close and hangup.
>   */
>
> -static void uart_dtr_rts(struct tty_port *tport, bool onoff)
> +static void uart_dtr_rts(struct tty_port *tport, bool active)
>  {
> struct sdio_uart_port *port =
> container_of(tport, struct sdio_uart_port, port);
> int ret = sdio_uart_claim_func(port);
> if (ret)
> return;
> -   if (!onoff)
> +   if (!active)
> sdio_uart_clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
> else
> sdio_uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
> diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
> index 92d49740d5a4..20a34599859f 100644
> --- a/drivers/staging/greybus/uart.c
> +++ b/drivers/staging/greybus/uart.c
> @@ -701,7 +701,7 @@ static int gb_tty_ioctl(struct tty_struct *tty, unsigned 
> int cmd,
> return -ENOIOCTLCMD;
>  }
>
> -static void gb_tty_dtr_rts(struct tty_port *port, bool on)
> +static void gb_tty_dtr_rts(struct tty_port *port, bool active)
>  {
> struct gb_tty *gb_tty;
> u8 newctrl;
> @@ -709,7 +709,7 @@ static void gb_tty_dtr_rts(struct tty_port *port, bool on)
> gb_tty = container_of(port, struct gb_tty, port);
> newctrl = gb_tty->ctrlout;
>
> -   if (on)
> +   if (active)
> newctrl |= (GB_UART_CTRL_DTR | GB_UART_CTRL_RTS);
> else
> newctrl &= ~(GB_UART_CTRL_DTR | GB_UART_CTRL_RTS);
> diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
> index 29d4c554f6b8..d7515d61659e 100644
> --- a/drivers/tty/amiserial.c
> +++ b/drivers/tty/amiserial.c
> @@ -1459,13 +1459,13 @@ static bool amiga_carrier_raised(struct tty_port 
> *port)
> return !(ciab.pra & SER_DCD);
>  }
>
> -static void amiga_dtr_rts(struct tty_port *port, bool raise)
> +static void amiga_dtr_rts(struct tty_port *port, bool active)
>  {
>

Re: [PATCH v2 12/44] cpuidle,dt: Push RCU-idle into driver

[Ulf Hansson]

On Wed, 16 Nov 2022 at 16:29, Peter Zijlstra  wrote:
>
>
> Sorry; things keep getting in the way of finishing this :/
>
> As such, I need a bit of time to get on-track again..
>
> On Tue, Oct 04, 2022 at 01:03:57PM +0200, Ulf Hansson wrote:
>
> > > --- a/drivers/acpi/processor_idle.c
> > > +++ b/drivers/acpi/processor_idle.c
> > > @@ -1200,6 +1200,8 @@ static int acpi_processor_setup_lpi_stat
> > > state->target_residency = lpi->min_residency;
> > > if (lpi->arch_flags)
> > > state->flags |= CPUIDLE_FLAG_TIMER_STOP;
> > > +   if (lpi->entry_method == ACPI_CSTATE_FFH)
> > > +   state->flags |= CPUIDLE_FLAG_RCU_IDLE;
> >
> > I assume the state index here will never be 0?
> >
> > If not, it may lead to that acpi_processor_ffh_lpi_enter() may trigger
> > CPU_PM_CPU_IDLE_ENTER_PARAM() to call ct_cpuidle_enter|exit() for an
> > idle-state that doesn't have the CPUIDLE_FLAG_RCU_IDLE bit set.
>
> I'm not quite sure I see how. AFAICT this condition above implies
> acpi_processor_ffh_lpi_enter() gets called, no?
>
> Which in turn is an unconditional __CPU_PM_CPU_IDLE_ENTER() user, so
> even if idx==0, it ends up in ct_idle_{enter,exit}().

Seems like I was overlooking something here, you are right, this
shouldn't really be a problem.

>
> >
> > > state->enter = acpi_idle_lpi_enter;
> > > drv->safe_state_index = i;
> > > }
> > > --- a/drivers/cpuidle/cpuidle-arm.c
> > > +++ b/drivers/cpuidle/cpuidle-arm.c
> > > @@ -53,6 +53,7 @@ static struct cpuidle_driver arm_idle_dr
> > >  * handler for idle state index 0.
> > >  */
> > > .states[0] = {
> > > +   .flags  = CPUIDLE_FLAG_RCU_IDLE,
> >
> > Comparing arm64 and arm32 idle-states/idle-drivers, the $subject
> > series ends up setting the CPUIDLE_FLAG_RCU_IDLE for the ARM WFI idle
> > state (state zero), but only for the arm64 and psci cases (mostly
> > arm64). For arm32 we would need to update the ARM_CPUIDLE_WFI_STATE
> > too, as that is what most arm32 idle-drivers are using. My point is,
> > the code becomes a bit inconsistent.
>
> True.
>
> > Perhaps it's easier to avoid setting the CPUIDLE_FLAG_RCU_IDLE bit for
> > all of the ARM WFI idle states, for both arm64 and arm32?
>
> As per the below?
>
> >
> > > .enter  = arm_enter_idle_state,
> > > .exit_latency   = 1,
> > > .target_residency   = 1,
>
> > > --- a/include/linux/cpuidle.h
> > > +++ b/include/linux/cpuidle.h
> > > @@ -282,14 +282,18 @@ extern s64 cpuidle_governor_latency_req(
> > > int __ret = 0;  \
> > > \
> > > if (!idx) { \
> > > +   ct_idle_enter();\
> >
> > According to my comment above, we should then drop these calls to
> > ct_idle_enter and ct_idle_exit() here. Right?
>
> Yes, if we ensure idx==0 never has RCU_IDLE set then these must be
> removed.
>
> > > cpu_do_idle();  \
> > > +   ct_idle_exit(); \
> > > return idx; \
> > > }   \
> > > \
> > > if (!is_retention)  \
> > > __ret =  cpu_pm_enter();\
> > > if (!__ret) {   \
> > > +   ct_idle_enter();\
> > > __ret = low_level_idle_enter(state);\
> > > +   ct_idle_exit(); \
> > > if (!is_retention)  \
> > > cpu_pm_exit();  \
> > > }   \
> > >
>
> So the basic premise is that everything that ne

Re: [PATCH v3 0/5] treewide cleanup of random integer usage

[Ulf Hansson]

On Thu, 6 Oct 2022 at 18:54, Jason A. Donenfeld  wrote:
>
> Changes v2->v3:
> - Handle get_random_int() conversions too, which were overlooked before,
>   in the same way as the rest.
>
> Hi folks,
>
> This is a five part treewide cleanup of random integer handling. The
> rules for random integers are:
>
> - If you want a secure or an insecure random u64, use get_random_u64().
> - If you want a secure or an insecure random u32, use get_random_u32().
>   * The old function prandom_u32() has been deprecated for a while now
> and is just a wrapper around get_random_u32(). Same for
> get_random_int().
> - If you want a secure or an insecure random u16, use get_random_u16().
> - If you want a secure or an insecure random u8, use get_random_u8().
> - If you want secure or insecure random bytes, use get_random_bytes().
>   * The old function prandom_bytes() has been deprecated for a while now
> and has long been a wrapper around get_random_bytes().
> - If you want a non-uniform random u32, u16, or u8 bounded by a certain
>   open interval maximum, use prandom_u32_max().
>   * I say "non-uniform", because it doesn't do any rejection sampling or
> divisions. Hence, it stays within the prandom_* namespace.
>
> These rules ought to be applied uniformly, so that we can clean up the
> deprecated functions, and earn the benefits of using the modern
> functions. In particular, in addition to the boring substitutions, this
> patchset accomplishes a few nice effects:
>
> - By using prandom_u32_max() with an upper-bound that the compiler can
>   prove at compile-time is ≤65536 or ≤256, internally get_random_u16()
>   or get_random_u8() is used, which wastes fewer batched random bytes,
>   and hence has higher throughput.
>
> - By using prandom_u32_max() instead of %, when the upper-bound is not a
>   constant, division is still avoided, because prandom_u32_max() uses
>   a faster multiplication-based trick instead.
>
> - By using get_random_u16() or get_random_u8() in cases where the return
>   value is intended to indeed be a u16 or a u8, we waste fewer batched
>   random bytes, and hence have higher throughput.
>
> So, based on those rules and benefits from following them, this patchset
> breaks down into the following five steps, which were done mostly
> manually:
>
> 1) Replace `prandom_u32() % max` and variants thereof with
>prandom_u32_max(max).
>
> 2) Replace `(type)get_random_u32()` and variants thereof with
>get_random_u16() or get_random_u8(). I took the pains to actually
>look and see what every lvalue type was across the entire tree.
>
> 3) Replace remaining deprecated uses of prandom_u32() and
>get_random_int() with get_random_u32().
>
> 4) Replace remaining deprecated uses of prandom_bytes() with
>get_random_bytes().
>
> 5) Remove the deprecated and now-unused prandom_u32() and
>prandom_bytes() inline wrapper functions.
>
> I was thinking of taking this through my random.git tree (on which this
> series is currently based) and submitting it near the end of the merge
> window, or waiting for the very end of the 6.1 cycle when there will be
> the fewest new patches brewing. If somebody with some treewide-cleanup
> experience might share some wisdom about what the best timing usually
> winds up being, I'm all ears.
>
> Please take a look! At "379 insertions(+), 422 deletions(-)", this
> should be a somewhat small patchset to review, despite it having the
> scary "treewide" moniker on it.
>
> Thanks,
> Jason
>
> Cc: Andreas Noever 
> Cc: Andrew Morton 
> Cc: Andy Shevchenko 
> Cc: Borislav Petkov 
> Cc: Catalin Marinas 
> Cc: Christoph Böhmwalder 
> Cc: Christoph Hellwig 
> Cc: Christophe Leroy 
> Cc: Daniel Borkmann 
> Cc: Dave Airlie 
> Cc: Dave Hansen 
> Cc: David S. Miller 
> Cc: Eric Dumazet 
> Cc: Florian Westphal 
> Cc: Greg Kroah-Hartman ,
> Cc: H. Peter Anvin 
> Cc: Heiko Carstens 
> Cc: Helge Deller 
> Cc: Herbert Xu 
> Cc: Huacai Chen 
> Cc: Hugh Dickins 
> Cc: Jakub Kicinski 
> Cc: James E.J. Bottomley 
> Cc: Jan Kara 
> Cc: Jason Gunthorpe 
> Cc: Jens Axboe 
> Cc: Johannes Berg 
> Cc: Jonathan Corbet 
> Cc: Jozsef Kadlecsik 
> Cc: KP Singh 
> Cc: Kees Cook 
> Cc: Marco Elver 
> Cc: Mauro Carvalho Chehab 
> Cc: Michael Ellerman 
> Cc: Pablo Neira Ayuso 
> Cc: Paolo Abeni 
> Cc: Peter Zijlstra 
> Cc: Richard Weinberger 
> Cc: Russell King 
> Cc: Theodore Ts'o 
> Cc: Thomas Bogendoerfer 
> Cc: Thomas Gleixner 
> Cc: Thomas Graf 
> Cc: Ulf Hansson 
> Cc: Vignesh Raghavendra 
> Cc: WANG Xuerui 
> Cc: Will Deacon 
> Cc: Yury Norov 
> Cc: dri-de.

Re: [PATCH v2 00/44] cpuidle,rcu: Clean up the mess

[Ulf Hansson]

/process_32.c|  1 -
>  arch/sparc/kernel/process_64.c|  3 +-
>  arch/sparc/kernel/vmlinux.lds.S   |  1 -
>  arch/um/kernel/dyn.lds.S  |  1 -
>  arch/um/kernel/process.c  |  1 -
>  arch/um/kernel/uml.lds.S  |  1 -
>  arch/x86/boot/compressed/vmlinux.lds.S|  1 +
>  arch/x86/coco/tdx/tdcall.S| 15 +--
>  arch/x86/coco/tdx/tdx.c   | 25 
>  arch/x86/events/amd/brs.c | 13 +++
>  arch/x86/include/asm/fpu/xcr.h|  4 +-
>  arch/x86/include/asm/irqflags.h   | 11 ++
>  arch/x86/include/asm/mwait.h  | 14 +++
>  arch/x86/include/asm/nospec-branch.h  |  2 +-
>  arch/x86/include/asm/paravirt.h   |  6 ++-
>  arch/x86/include/asm/perf_event.h |  2 +-
>  arch/x86/include/asm/shared/io.h  |  4 +-
>  arch/x86/include/asm/shared/tdx.h |  1 -
>  arch/x86/include/asm/special_insns.h  |  8 ++--
>  arch/x86/include/asm/xen/hypercall.h  |  2 +-
>  arch/x86/kernel/cpu/bugs.c|  2 +-
>  arch/x86/kernel/fpu/core.c|  4 +-
>  arch/x86/kernel/paravirt.c| 14 ++-
>  arch/x86/kernel/process.c | 65 
> +++
>  arch/x86/kernel/vmlinux.lds.S |  1 -
>  arch/x86/lib/memcpy_64.S  |  5 +--
>  arch/x86/lib/memmove_64.S |  4 +-
>  arch/x86/lib/memset_64.S  |  4 +-
>  arch/x86/xen/enlighten_pv.c   |  2 +-
>  arch/x86/xen/irq.c|  2 +-
>  arch/xtensa/kernel/process.c  |  1 +
>  arch/xtensa/kernel/vmlinux.lds.S  |  1 -
>  drivers/acpi/processor_idle.c | 36 ++---
>  drivers/base/power/runtime.c  | 24 ++--
>  drivers/clk/clk.c |  8 ++--
>  drivers/cpuidle/cpuidle-arm.c |  1 +
>  drivers/cpuidle/cpuidle-big_little.c  |  8 +++-
>  drivers/cpuidle/cpuidle-mvebu-v7.c|  7 
>  drivers/cpuidle/cpuidle-psci.c| 10 +++--
>  drivers/cpuidle/cpuidle-qcom-spm.c|  1 +
>  drivers/cpuidle/cpuidle-riscv-sbi.c   | 10 +++--
>  drivers/cpuidle/cpuidle-tegra.c   | 21 +++---
>  drivers/cpuidle/cpuidle.c | 21 +-
>  drivers/cpuidle/dt_idle_states.c  |  2 +-
>  drivers/cpuidle/poll_state.c  | 10 -
>  drivers/idle/intel_idle.c | 19 +
>  drivers/perf/arm_pmu.c| 11 +-
>  drivers/perf/riscv_pmu_sbi.c  |  8 +---
>  include/asm-generic/vmlinux.lds.h |  9 ++---
>  include/linux/compiler_types.h|  8 +++-
>  include/linux/cpu.h   |  3 --
>  include/linux/cpuidle.h   | 34 
>  include/linux/cpumask.h   |  4 +-
>  include/linux/percpu-defs.h   |  2 +-
>  include/linux/sched/idle.h| 40 ++-
>  include/linux/thread_info.h   | 18 -
>  include/linux/tracepoint.h| 13 ++-
>  kernel/cpu_pm.c   |  9 -
>  kernel/printk/printk.c|  2 +-
>  kernel/sched/idle.c   | 47 +++---
>  kernel/time/tick-broadcast-hrtimer.c  | 29 ++
>  kernel/time/tick-broadcast.c  |  6 ++-
>  kernel/trace/trace.c  |  3 ++
>  lib/ubsan.c   |  5 ++-
>  mm/kasan/kasan.h  |  4 ++
>  mm/kasan/shadow.c | 38 ++
>  tools/objtool/check.c | 17 
>  121 files changed, 511 insertions(+), 420 deletions(-)

Thanks for cleaning up the situation!

I have applied this on a plain v6.0 (only one patch had a minor
conflict) and tested this on an ARM64 Dragonboard 410c, which uses
cpuidle-psci and the cpuidle-psci-domain. I didn't observe any
problems, so feel free to add:

Tested-by: Ulf Hansson 

Kind regards
Uffe

Re: [PATCH v2 12/44] cpuidle,dt: Push RCU-idle into driver

[Ulf Hansson]

On Tue, 4 Oct 2022 at 13:03, Ulf Hansson  wrote:
>
> On Mon, 19 Sept 2022 at 12:18, Peter Zijlstra  wrote:
> >
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again before going idle is daft.
> >
> > Notably: this converts all dt_init_idle_driver() and
> > __CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined.
> >
> > Signed-off-by: Peter Zijlstra (Intel) 
>
> Reviewed-by: Ulf Hansson 

This was not (yet) my intention. Please have a look at the comments I
provided below.

Kind regards
Uffe

>
> > ---
> >  arch/arm/mach-omap2/cpuidle34xx.c|4 ++--
> >  drivers/acpi/processor_idle.c|2 ++
> >  drivers/cpuidle/cpuidle-arm.c|1 +
> >  drivers/cpuidle/cpuidle-big_little.c |8 ++--
> >  drivers/cpuidle/cpuidle-psci.c   |1 +
> >  drivers/cpuidle/cpuidle-qcom-spm.c   |1 +
> >  drivers/cpuidle/cpuidle-riscv-sbi.c  |1 +
> >  drivers/cpuidle/dt_idle_states.c |2 +-
> >  include/linux/cpuidle.h  |4 
> >  9 files changed, 19 insertions(+), 5 deletions(-)
> >
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -1200,6 +1200,8 @@ static int acpi_processor_setup_lpi_stat
> > state->target_residency = lpi->min_residency;
> > if (lpi->arch_flags)
> > state->flags |= CPUIDLE_FLAG_TIMER_STOP;
> > +   if (lpi->entry_method == ACPI_CSTATE_FFH)
> > +   state->flags |= CPUIDLE_FLAG_RCU_IDLE;
>
> I assume the state index here will never be 0?
>
> If not, it may lead to that acpi_processor_ffh_lpi_enter() may trigger
> CPU_PM_CPU_IDLE_ENTER_PARAM() to call ct_cpuidle_enter|exit() for an
> idle-state that doesn't have the CPUIDLE_FLAG_RCU_IDLE bit set.
>
> > state->enter = acpi_idle_lpi_enter;
> > drv->safe_state_index = i;
> > }
> > --- a/drivers/cpuidle/cpuidle-arm.c
> > +++ b/drivers/cpuidle/cpuidle-arm.c
> > @@ -53,6 +53,7 @@ static struct cpuidle_driver arm_idle_dr
> >  * handler for idle state index 0.
> >  */
> > .states[0] = {
> > +   .flags  = CPUIDLE_FLAG_RCU_IDLE,
>
> Comparing arm64 and arm32 idle-states/idle-drivers, the $subject
> series ends up setting the CPUIDLE_FLAG_RCU_IDLE for the ARM WFI idle
> state (state zero), but only for the arm64 and psci cases (mostly
> arm64). For arm32 we would need to update the ARM_CPUIDLE_WFI_STATE
> too, as that is what most arm32 idle-drivers are using. My point is,
> the code becomes a bit inconsistent.
>
> Perhaps it's easier to avoid setting the CPUIDLE_FLAG_RCU_IDLE bit for
> all of the ARM WFI idle states, for both arm64 and arm32?
>
> > .enter  = arm_enter_idle_state,
> > .exit_latency   = 1,
> > .target_residency   = 1,
> > --- a/drivers/cpuidle/cpuidle-big_little.c
> > +++ b/drivers/cpuidle/cpuidle-big_little.c
> > @@ -64,7 +64,8 @@ static struct cpuidle_driver bl_idle_lit
> > .enter  = bl_enter_powerdown,
> > .exit_latency   = 700,
> > .target_residency   = 2500,
> > -   .flags  = CPUIDLE_FLAG_TIMER_STOP,
> > +   .flags  = CPUIDLE_FLAG_TIMER_STOP |
> > + CPUIDLE_FLAG_RCU_IDLE,
> > .name   = "C1",
> > .desc   = "ARM little-cluster power down",
> > },
> > @@ -85,7 +86,8 @@ static struct cpuidle_driver bl_idle_big
> > .enter  = bl_enter_powerdown,
> > .exit_latency   = 500,
> > .target_residency   = 2000,
> > -   .flags  = CPUIDLE_FLAG_TIMER_STOP,
> > +   .flags  = CPUIDLE_FLAG_TIMER_STOP |
> > + CPUIDLE_FLAG_RCU_IDLE,
> > .name   = "C1",
> > .desc   = "ARM big-cluster power down",
> > },
> > @@ -124,11 +126,13 @@ static int bl_enter_powerdown(struct cpu
> > struct cpuidle_driver *drv, int idx)
> >  {
> > cpu_pm_enter();
> > +   ct_idle_enter();
> >
> > cpu_suspend(0, bl_powerdown

Re: [PATCH v2 38/44] cpuidle,powerdomain: Remove trace_.*_rcuidle()

[Ulf Hansson]

On Mon, 19 Sept 2022 at 12:17, Peter Zijlstra  wrote:
>
> OMAP was the one and only user.
>
> Signed-off-by: Peter Zijlstra (Intel) 

There are changes to the runtime PM core as part of $subject patch.
Perhaps move those parts into a separate patch? In any case, the code
looks good to me.

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  arch/arm/mach-omap2/powerdomain.c |   10 +-
>  drivers/base/power/runtime.c  |   24 
>  2 files changed, 17 insertions(+), 17 deletions(-)
>
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -187,9 +187,9 @@ static int _pwrdm_state_switch(struct po
> trace_state = (PWRDM_TRACE_STATES_FLAG |
>((next & OMAP_POWERSTATE_MASK) << 8) |
>((prev & OMAP_POWERSTATE_MASK) << 0));
> -   trace_power_domain_target_rcuidle(pwrdm->name,
> - trace_state,
> - 
> raw_smp_processor_id());
> +   trace_power_domain_target(pwrdm->name,
> + trace_state,
> + raw_smp_processor_id());
> }
> break;
> default:
> @@ -541,8 +541,8 @@ int pwrdm_set_next_pwrst(struct powerdom
>
> if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
> /* Trace the pwrdm desired target state */
> -   trace_power_domain_target_rcuidle(pwrdm->name, pwrst,
> - raw_smp_processor_id());
> +   trace_power_domain_target(pwrdm->name, pwrst,
> + raw_smp_processor_id());
> /* Program the pwrdm desired target state */
> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
> }
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -442,7 +442,7 @@ static int rpm_idle(struct device *dev,
> int (*callback)(struct device *);
> int retval;
>
> -   trace_rpm_idle_rcuidle(dev, rpmflags);
> +   trace_rpm_idle(dev, rpmflags);
> retval = rpm_check_suspend_allowed(dev);
> if (retval < 0)
> ;   /* Conditions are wrong. */
> @@ -481,7 +481,7 @@ static int rpm_idle(struct device *dev,
> dev->power.request_pending = true;
> queue_work(pm_wq, >power.work);
> }
> -   trace_rpm_return_int_rcuidle(dev, _THIS_IP_, 0);
> +   trace_rpm_return_int(dev, _THIS_IP_, 0);
> return 0;
> }
>
> @@ -493,7 +493,7 @@ static int rpm_idle(struct device *dev,
> wake_up_all(>power.wait_queue);
>
>   out:
> -   trace_rpm_return_int_rcuidle(dev, _THIS_IP_, retval);
> +   trace_rpm_return_int(dev, _THIS_IP_, retval);
> return retval ? retval : rpm_suspend(dev, rpmflags | RPM_AUTO);
>  }
>
> @@ -557,7 +557,7 @@ static int rpm_suspend(struct device *de
> struct device *parent = NULL;
> int retval;
>
> -   trace_rpm_suspend_rcuidle(dev, rpmflags);
> +   trace_rpm_suspend(dev, rpmflags);
>
>   repeat:
> retval = rpm_check_suspend_allowed(dev);
> @@ -708,7 +708,7 @@ static int rpm_suspend(struct device *de
> }
>
>   out:
> -   trace_rpm_return_int_rcuidle(dev, _THIS_IP_, retval);
> +   trace_rpm_return_int(dev, _THIS_IP_, retval);
>
> return retval;
>
> @@ -760,7 +760,7 @@ static int rpm_resume(struct device *dev
> struct device *parent = NULL;
> int retval = 0;
>
> -   trace_rpm_resume_rcuidle(dev, rpmflags);
> +   trace_rpm_resume(dev, rpmflags);
>
>   repeat:
> if (dev->power.runtime_error) {
> @@ -925,7 +925,7 @@ static int rpm_resume(struct device *dev
> spin_lock_irq(>power.lock);
> }
>
> -   trace_rpm_return_int_rcuidle(dev, _THIS_IP_, retval);
> +   trace_rpm_return_int(dev, _THIS_IP_, retval);
>
> return retval;
>  }
> @@ -1081,7 +1081,7 @@ int __pm_runtime_idle(struct device *dev
> if (retval < 0) {
> return retval;
> } else if (retval > 0) {
> -   trace_rpm_usage_rcuidle(dev, rpmflags);
> +   trace_rpm_usage(dev, rpmflags);
> return 0;
> }
> }
>

Re: [PATCH v2 39/44] cpuidle,clk: Remove trace_.*_rcuidle()

[Ulf Hansson]

On Mon, 19 Sept 2022 at 12:17, Peter Zijlstra  wrote:
>
> OMAP was the one and only user.

OMAP? :-)

>
> Signed-off-by: Peter Zijlstra (Intel) 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  drivers/clk/clk.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -978,12 +978,12 @@ static void clk_core_disable(struct clk_
> if (--core->enable_count > 0)
> return;
>
> -   trace_clk_disable_rcuidle(core);
> +   trace_clk_disable(core);
>
> if (core->ops->disable)
> core->ops->disable(core->hw);
>
> -   trace_clk_disable_complete_rcuidle(core);
> +   trace_clk_disable_complete(core);
>
> clk_core_disable(core->parent);
>  }
> @@ -1037,12 +1037,12 @@ static int clk_core_enable(struct clk_co
> if (ret)
> return ret;
>
> -   trace_clk_enable_rcuidle(core);
> +   trace_clk_enable(core);
>
> if (core->ops->enable)
> ret = core->ops->enable(core->hw);
>
> -   trace_clk_enable_complete_rcuidle(core);
> +   trace_clk_enable_complete(core);
>
> if (ret) {
> clk_core_disable(core->parent);
>
>
> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 23/44] arm,smp: Remove trace_.*_rcuidle() usage

[Ulf Hansson]

On Mon, 19 Sept 2022 at 12:18, Peter Zijlstra  wrote:
>
> None of these functions should ever be ran with RCU disabled anymore.
>
> Specifically, do_handle_IPI() is only called from handle_IPI() which
> explicitly does irq_enter()/irq_exit() which ensures RCU is watching.
>
> The problem with smp_cross_call() was, per commit 7c64cc0531fa ("arm: Use
> _rcuidle for smp_cross_call() tracepoints"), that
> cpuidle_enter_state_coupled() already had RCU disabled, but that's
> long been fixed by commit 1098582a0f6c ("sched,idle,rcu: Push rcu_idle
> deeper into the idle path").
>
> Signed-off-by: Peter Zijlstra (Intel) 

FWIW:

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  arch/arm/kernel/smp.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -639,7 +639,7 @@ static void do_handle_IPI(int ipinr)
> unsigned int cpu = smp_processor_id();
>
> if ((unsigned)ipinr < NR_IPI)
> -   trace_ipi_entry_rcuidle(ipi_types[ipinr]);
> +   trace_ipi_entry(ipi_types[ipinr]);
>
> switch (ipinr) {
> case IPI_WAKEUP:
> @@ -686,7 +686,7 @@ static void do_handle_IPI(int ipinr)
> }
>
> if ((unsigned)ipinr < NR_IPI)
> -   trace_ipi_exit_rcuidle(ipi_types[ipinr]);
> +   trace_ipi_exit(ipi_types[ipinr]);
>  }
>
>  /* Legacy version, should go away once all irqchips have been converted */
> @@ -709,7 +709,7 @@ static irqreturn_t ipi_handler(int irq,
>
>  static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
>  {
> -   trace_ipi_raise_rcuidle(target, ipi_types[ipinr]);
> +   trace_ipi_raise(target, ipi_types[ipinr]);
> __ipi_send_mask(ipi_desc[ipinr], target);
>  }
>
>
>
> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 14/44] cpuidle,cpu_pm: Remove RCU fiddling from cpu_pm_{enter,exit}()

[Ulf Hansson]

On Mon, 19 Sept 2022 at 12:17, Peter Zijlstra  wrote:
>
> All callers should still have RCU enabled.
>
> Signed-off-by: Peter Zijlstra (Intel) 
> Acked-by: Mark Rutland 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  kernel/cpu_pm.c |9 -
>  1 file changed, 9 deletions(-)
>
> --- a/kernel/cpu_pm.c
> +++ b/kernel/cpu_pm.c
> @@ -30,16 +30,9 @@ static int cpu_pm_notify(enum cpu_pm_eve
>  {
> int ret;
>
> -   /*
> -* This introduces a RCU read critical section, which could be
> -* disfunctional in cpu idle. Copy RCU_NONIDLE code to let RCU know
> -* this.
> -*/
> -   ct_irq_enter_irqson();
> rcu_read_lock();
> ret = raw_notifier_call_chain(_pm_notifier.chain, event, NULL);
> rcu_read_unlock();
> -   ct_irq_exit_irqson();
>
> return notifier_to_errno(ret);
>  }
> @@ -49,11 +42,9 @@ static int cpu_pm_notify_robust(enum cpu
> unsigned long flags;
> int ret;
>
> -   ct_irq_enter_irqson();
> raw_spin_lock_irqsave(_pm_notifier.lock, flags);
> ret = raw_notifier_call_chain_robust(_pm_notifier.chain, 
> event_up, event_down, NULL);
> raw_spin_unlock_irqrestore(_pm_notifier.lock, flags);
> -   ct_irq_exit_irqson();
>
> return notifier_to_errno(ret);
>  }
>
>

Re: [PATCH v2 12/44] cpuidle,dt: Push RCU-idle into driver

[Ulf Hansson]

On Mon, 19 Sept 2022 at 12:18, Peter Zijlstra  wrote:
>
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again before going idle is daft.
>
> Notably: this converts all dt_init_idle_driver() and
> __CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined.
>
> Signed-off-by: Peter Zijlstra (Intel) 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  arch/arm/mach-omap2/cpuidle34xx.c|4 ++--
>  drivers/acpi/processor_idle.c|2 ++
>  drivers/cpuidle/cpuidle-arm.c|1 +
>  drivers/cpuidle/cpuidle-big_little.c |8 ++--
>  drivers/cpuidle/cpuidle-psci.c   |1 +
>  drivers/cpuidle/cpuidle-qcom-spm.c   |1 +
>  drivers/cpuidle/cpuidle-riscv-sbi.c  |1 +
>  drivers/cpuidle/dt_idle_states.c |2 +-
>  include/linux/cpuidle.h  |4 
>  9 files changed, 19 insertions(+), 5 deletions(-)
>
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1200,6 +1200,8 @@ static int acpi_processor_setup_lpi_stat
> state->target_residency = lpi->min_residency;
> if (lpi->arch_flags)
> state->flags |= CPUIDLE_FLAG_TIMER_STOP;
> +   if (lpi->entry_method == ACPI_CSTATE_FFH)
> +   state->flags |= CPUIDLE_FLAG_RCU_IDLE;

I assume the state index here will never be 0?

If not, it may lead to that acpi_processor_ffh_lpi_enter() may trigger
CPU_PM_CPU_IDLE_ENTER_PARAM() to call ct_cpuidle_enter|exit() for an
idle-state that doesn't have the CPUIDLE_FLAG_RCU_IDLE bit set.

> state->enter = acpi_idle_lpi_enter;
> drv->safe_state_index = i;
> }
> --- a/drivers/cpuidle/cpuidle-arm.c
> +++ b/drivers/cpuidle/cpuidle-arm.c
> @@ -53,6 +53,7 @@ static struct cpuidle_driver arm_idle_dr
>  * handler for idle state index 0.
>  */
> .states[0] = {
> +   .flags  = CPUIDLE_FLAG_RCU_IDLE,

Comparing arm64 and arm32 idle-states/idle-drivers, the $subject
series ends up setting the CPUIDLE_FLAG_RCU_IDLE for the ARM WFI idle
state (state zero), but only for the arm64 and psci cases (mostly
arm64). For arm32 we would need to update the ARM_CPUIDLE_WFI_STATE
too, as that is what most arm32 idle-drivers are using. My point is,
the code becomes a bit inconsistent.

Perhaps it's easier to avoid setting the CPUIDLE_FLAG_RCU_IDLE bit for
all of the ARM WFI idle states, for both arm64 and arm32?

> .enter  = arm_enter_idle_state,
> .exit_latency   = 1,
> .target_residency   = 1,
> --- a/drivers/cpuidle/cpuidle-big_little.c
> +++ b/drivers/cpuidle/cpuidle-big_little.c
> @@ -64,7 +64,8 @@ static struct cpuidle_driver bl_idle_lit
> .enter  = bl_enter_powerdown,
> .exit_latency   = 700,
> .target_residency   = 2500,
> -   .flags  = CPUIDLE_FLAG_TIMER_STOP,
> +   .flags  = CPUIDLE_FLAG_TIMER_STOP |
> + CPUIDLE_FLAG_RCU_IDLE,
> .name   = "C1",
> .desc   = "ARM little-cluster power down",
> },
> @@ -85,7 +86,8 @@ static struct cpuidle_driver bl_idle_big
> .enter  = bl_enter_powerdown,
> .exit_latency   = 500,
> .target_residency   = 2000,
> -   .flags  = CPUIDLE_FLAG_TIMER_STOP,
> +   .flags  = CPUIDLE_FLAG_TIMER_STOP |
> + CPUIDLE_FLAG_RCU_IDLE,
> .name   = "C1",
> .desc   = "ARM big-cluster power down",
> },
> @@ -124,11 +126,13 @@ static int bl_enter_powerdown(struct cpu
> struct cpuidle_driver *drv, int idx)
>  {
> cpu_pm_enter();
> +   ct_idle_enter();
>
> cpu_suspend(0, bl_powerdown_finisher);
>
> /* signals the MCPM core that CPU is out of low power state */
> mcpm_cpu_powered_up();
> +   ct_idle_exit();
>
> cpu_pm_exit();
>
> --- a/drivers/cpuidle/cpuidle-psci.c
> +++ b/drivers/cpuidle/cpuidle-psci.c
> @@ -357,6 +357,7 @@ static int psci_idle_init_cpu(struct dev
>  * PSCI idle states relies on architectural WFI to be represented as
>  * state index 0.
>  */
> +   drv->states[0].flags = CPUIDLE_FLAG_RCU_IDLE;
> drv->states[0].enter = psci_enter_idle_

Re: [PATCH v2 4/4] bus: Make remove callback return void

[Ulf Hansson]

On Tue, 6 Jul 2021 at 17:53, Uwe Kleine-König
 wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their remove callback.
> Additionally some resource leaks were fixed that were caused by drivers
> returning an error code in the expectation that the driver won't go
> away.
>
> With struct bus_type::remove returning void it's prevented that newly
> implemented buses return an ignored error code and so don't anticipate
> wrong expectations for driver authors.
>
> Acked-by: Russell King (Oracle)  (For ARM, Amba 
> and related parts)
> Acked-by: Mark Brown 
> Acked-by: Chen-Yu Tsai  (for drivers/bus/sunxi-rsb.c)
> Acked-by: Pali Rohár 
> Acked-by: Mauro Carvalho Chehab  (for drivers/media)
> Acked-by: Hans de Goede  (For drivers/platform)
> Acked-by: Alexandre Belloni 
> Acked-By: Vinod Koul 
> Acked-by: Juergen Gross  (For Xen)
> Acked-by: Lee Jones  (For drivers/mfd)
> Acked-by: Johannes Thumshirn  (For drivers/mcb)
> Acked-by: Johan Hovold 
> Acked-by: Srinivas Kandagatla  (For 
> drivers/slimbus)
> Acked-by: Kirti Wankhede  (For drivers/vfio)
> Acked-by: Maximilian Luz 
> Acked-by: Heikki Krogerus  (For ulpi and 
> typec)
> Acked-by: Samuel Iglesias Gonsálvez  (For ipack)
> Reviewed-by: Tom Rix  (For fpga)
> Acked-by: Geoff Levand  (For ps3)
> Signed-off-by: Uwe Kleine-König 

Acked-by: Ulf Hansson  # For MMC

[...]

Kind regards
Uffe

Re: [PATCH 08/30] mspro: use blk_mq_alloc_disk

[Ulf Hansson]

On Wed, 2 Jun 2021 at 08:54, Christoph Hellwig  wrote:
>
> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> allocation.
>
> Signed-off-by: Christoph Hellwig 

Acked-by: Ulf Hansson 

Kind regards
Uffe


> ---
>  drivers/memstick/core/mspro_block.c | 26 +++---
>  1 file changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/memstick/core/mspro_block.c 
> b/drivers/memstick/core/mspro_block.c
> index cf7fe0d58ee7..22778d0e24f5 100644
> --- a/drivers/memstick/core/mspro_block.c
> +++ b/drivers/memstick/core/mspro_block.c
> @@ -1205,21 +1205,17 @@ static int mspro_block_init_disk(struct memstick_dev 
> *card)
> if (disk_id < 0)
> return disk_id;
>
> -   msb->disk = alloc_disk(1 << MSPRO_BLOCK_PART_SHIFT);
> -   if (!msb->disk) {
> -   rc = -ENOMEM;
> +   rc = blk_mq_alloc_sq_tag_set(>tag_set, _mq_ops, 2,
> +BLK_MQ_F_SHOULD_MERGE);
> +   if (rc)
> goto out_release_id;
> -   }
>
> -   msb->queue = blk_mq_init_sq_queue(>tag_set, _mq_ops, 2,
> -   BLK_MQ_F_SHOULD_MERGE);
> -   if (IS_ERR(msb->queue)) {
> -   rc = PTR_ERR(msb->queue);
> -   msb->queue = NULL;
> -   goto out_put_disk;
> +   msb->disk = blk_mq_alloc_disk(>tag_set, card);
> +   if (IS_ERR(msb->disk)) {
> +   rc = PTR_ERR(msb->disk);
> +   goto out_free_tag_set;
> }
> -
> -   msb->queue->queuedata = card;
> +   msb->queue = msb->disk->queue;
>
> blk_queue_max_hw_sectors(msb->queue, MSPRO_BLOCK_MAX_PAGES);
> blk_queue_max_segments(msb->queue, MSPRO_BLOCK_MAX_SEGS);
> @@ -1228,10 +1224,10 @@ static int mspro_block_init_disk(struct memstick_dev 
> *card)
>
> msb->disk->major = major;
> msb->disk->first_minor = disk_id << MSPRO_BLOCK_PART_SHIFT;
> +   msb->disk->minors = 1 << MSPRO_BLOCK_PART_SHIFT;
> msb->disk->fops = _block_bdops;
> msb->usage_count = 1;
> msb->disk->private_data = msb;
> -   msb->disk->queue = msb->queue;
>
> sprintf(msb->disk->disk_name, "mspblk%d", disk_id);
>
> @@ -1247,8 +1243,8 @@ static int mspro_block_init_disk(struct memstick_dev 
> *card)
> msb->active = 1;
> return 0;
>
> -out_put_disk:
> -   put_disk(msb->disk);
> +out_free_tag_set:
> +   blk_mq_free_tag_set(>tag_set);
>  out_release_id:
> mutex_lock(_block_disk_lock);
> idr_remove(_block_disk_idr, disk_id);
> --
> 2.30.2
>

Re: [PATCH 07/30] ms_block: use blk_mq_alloc_disk

[Ulf Hansson]

On Wed, 2 Jun 2021 at 08:54, Christoph Hellwig  wrote:
>
> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> allocation.
>
> Signed-off-by: Christoph Hellwig 

Acked-by: Ulf Hansson 

Kind regards
Uffe


> ---
>  drivers/memstick/core/ms_block.c | 25 ++---
>  1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/memstick/core/ms_block.c 
> b/drivers/memstick/core/ms_block.c
> index 0bacf4268f83..dac258d12aca 100644
> --- a/drivers/memstick/core/ms_block.c
> +++ b/drivers/memstick/core/ms_block.c
> @@ -2110,21 +2110,17 @@ static int msb_init_disk(struct memstick_dev *card)
> if (msb->disk_id  < 0)
> return msb->disk_id;
>
> -   msb->disk = alloc_disk(0);
> -   if (!msb->disk) {
> -   rc = -ENOMEM;
> +   rc = blk_mq_alloc_sq_tag_set(>tag_set, _mq_ops, 2,
> +BLK_MQ_F_SHOULD_MERGE);
> +   if (rc)
> goto out_release_id;
> -   }
>
> -   msb->queue = blk_mq_init_sq_queue(>tag_set, _mq_ops, 2,
> -   BLK_MQ_F_SHOULD_MERGE);
> -   if (IS_ERR(msb->queue)) {
> -   rc = PTR_ERR(msb->queue);
> -   msb->queue = NULL;
> -   goto out_put_disk;
> +   msb->disk = blk_mq_alloc_disk(>tag_set, card);
> +   if (IS_ERR(msb->disk)) {
> +   rc = PTR_ERR(msb->disk);
> +   goto out_free_tag_set;
> }
> -
> -   msb->queue->queuedata = card;
> +   msb->queue = msb->disk->queue;
>
> blk_queue_max_hw_sectors(msb->queue, MS_BLOCK_MAX_PAGES);
> blk_queue_max_segments(msb->queue, MS_BLOCK_MAX_SEGS);
> @@ -2135,7 +2131,6 @@ static int msb_init_disk(struct memstick_dev *card)
> sprintf(msb->disk->disk_name, "msblk%d", msb->disk_id);
> msb->disk->fops = _bdops;
> msb->disk->private_data = msb;
> -   msb->disk->queue = msb->queue;
>
> capacity = msb->pages_in_block * msb->logical_block_count;
> capacity *= (msb->page_size / 512);
> @@ -2155,8 +2150,8 @@ static int msb_init_disk(struct memstick_dev *card)
> dbg("Disk added");
> return 0;
>
> -out_put_disk:
> -   put_disk(msb->disk);
> +out_free_tag_set:
> +   blk_mq_free_tag_set(>tag_set);
>  out_release_id:
> mutex_lock(_disk_lock);
> idr_remove(_disk_idr, msb->disk_id);
> --
> 2.30.2
>

Re: simplify gendisk and request_queue allocation for bio based drivers

[Ulf Hansson]

On Wed, 26 May 2021 at 06:49, Christoph Hellwig  wrote:
>
> On Wed, May 26, 2021 at 12:41:37AM +0200, Ulf Hansson wrote:
> > On Fri, 21 May 2021 at 07:51, Christoph Hellwig  wrote:
> > >
> > > Hi all,
> > >
> > > this series is the first part of cleaning up lifetimes and allocation of
> > > the gendisk and request_queue structure.  It adds a new interface to
> > > allocate the disk and queue together for bio based drivers, and a helper
> > > for cleanup/free them when a driver is unloaded or a device is removed.
> >
> > May I ask what else you have in the pipe for the next steps?
> >
> > The reason why I ask is that I am looking into some issues related to
> > lifecycle problems of gendisk/mmc, typically triggered at SD/MMC card
> > removal.
>
> In the short run not much more than superficial cleanups.  Eventually
> I want bio based drivers to not require a separate request_queue, leaving
> that purely as a data structure for blk-mq based drivers.  But it will
> take a while until we get there, so it should not block any fixes.

Alright, thanks for clarifying.

>
> For hot unplug handling it might be worth to take a look at nvme, as it
> is tested a lot for that case.

Okay, thanks for the hint.

Kind regards
Uffe

Re: simplify gendisk and request_queue allocation for bio based drivers

[Ulf Hansson]

On Fri, 21 May 2021 at 07:51, Christoph Hellwig  wrote:
>
> Hi all,
>
> this series is the first part of cleaning up lifetimes and allocation of
> the gendisk and request_queue structure.  It adds a new interface to
> allocate the disk and queue together for bio based drivers, and a helper
> for cleanup/free them when a driver is unloaded or a device is removed.

May I ask what else you have in the pipe for the next steps?

The reason why I ask is that I am looking into some issues related to
lifecycle problems of gendisk/mmc, typically triggered at SD/MMC card
removal.

>
> Together this removes the need to treat the gendisk and request_queue
> as separate entities for bio based drivers.
>
> Diffstat:
>  arch/m68k/emu/nfblock.c |   20 +---
>  arch/xtensa/platforms/iss/simdisk.c |   29 +--
>  block/blk-core.c|1
>  block/blk.h |6 -
>  block/genhd.c   |  149 
> +++-
>  block/partitions/core.c |   19 ++--
>  drivers/block/brd.c |   94 +++---
>  drivers/block/drbd/drbd_main.c  |   23 +
>  drivers/block/n64cart.c |8 -
>  drivers/block/null_blk/main.c   |   38 -
>  drivers/block/pktcdvd.c |   11 --
>  drivers/block/ps3vram.c |   31 +--
>  drivers/block/rsxx/dev.c|   39 +++--
>  drivers/block/rsxx/rsxx_priv.h  |1
>  drivers/block/zram/zram_drv.c   |   19 
>  drivers/lightnvm/core.c |   24 +
>  drivers/md/bcache/super.c   |   15 ---
>  drivers/md/dm.c |   16 +--
>  drivers/md/md.c |   25 ++
>  drivers/memstick/core/ms_block.c|1
>  drivers/nvdimm/blk.c|   27 +-
>  drivers/nvdimm/btt.c|   25 +-
>  drivers/nvdimm/btt.h|2
>  drivers/nvdimm/pmem.c   |   17 +---
>  drivers/nvme/host/core.c|1
>  drivers/nvme/host/multipath.c   |   46 +++
>  drivers/s390/block/dcssblk.c|   26 +-
>  drivers/s390/block/xpram.c  |   26 ++
>  include/linux/blkdev.h  |1
>  include/linux/genhd.h   |   23 +
>  30 files changed, 297 insertions(+), 466 deletions(-)

This looks like a nice cleanup to me.  Feel free to add, for the series:

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

Re: [PATCH] of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc

[Ulf Hansson]

On Sun, 26 Jan 2020 at 12:53, Michael Ellerman  wrote:
>
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms it's not possible to update existing device trees to add the
> "dma-coherent" property.
>
> So add a Kconfig symbol to allow arch code to tell
> of_dma_is_coherent() that devices are coherent by default, regardless
> of the presence of the property.
>
> Select that symbol on powerpc when NOT_COHERENT_CACHE is not set, ie.
> when the system has a coherent cache.
>
> Fixes: 92ea637edea3 ("of: introduce of_dma_is_coherent() helper")
> Cc: sta...@vger.kernel.org # v3.16+
> Reported-by: Christian Zigotzky 
> Tested-by: Christian Zigotzky 
> Signed-off-by: Michael Ellerman 

Thanks Michael for helping out fixing and this! The patch looks good to me.

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  arch/powerpc/Kconfig | 1 +
>  drivers/of/Kconfig   | 4 
>  drivers/of/address.c | 6 +-
>  3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1ec34e16ed65..19f5aa8ac9a3 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -238,6 +238,7 @@ config PPC
> select NEED_DMA_MAP_STATE   if PPC64 || NOT_COHERENT_CACHE
> select NEED_SG_DMA_LENGTH
> select OF
> +   select OF_DMA_DEFAULT_COHERENT  if !NOT_COHERENT_CACHE
> select OF_EARLY_FLATTREE
> select OLD_SIGACTIONif PPC32
> select OLD_SIGSUSPEND
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 37c2ccbefecd..d91618641be6 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -103,4 +103,8 @@ config OF_OVERLAY
>  config OF_NUMA
> bool
>
> +config OF_DMA_DEFAULT_COHERENT
> +   # arches should select this if DMA is coherent by default for OF 
> devices
> +   bool
> +
>  endif # OF
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 99c1b8058559..e8a39c3ec4d4 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -995,12 +995,16 @@ int of_dma_get_range(struct device_node *np, u64 
> *dma_addr, u64 *paddr, u64 *siz
>   * @np:device node
>   *
>   * It returns true if "dma-coherent" property was found
> - * for this device in DT.
> + * for this device in the DT, or if DMA is coherent by
> + * default for OF devices on the current platform.
>   */
>  bool of_dma_is_coherent(struct device_node *np)
>  {
> struct device_node *node = of_node_get(np);
>
> +   if (IS_ENABLED(CONFIG_OF_DMA_DEFAULT_COHERENT))
> +   return true;
> +
> while (node) {
> if (of_property_read_bool(node, "dma-coherent")) {
> of_node_put(node);
> --
> 2.21.1
>

Re: [FSL P5020 P5040 PPC] Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

[Ulf Hansson]

On Mon, 20 Jan 2020 at 10:17, Christian Zigotzky  wrote:
>
> Am 16.01.20 um 16:46 schrieb Ulf Hansson:
> > On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky  
> > wrote:
> >> Hi All,
> >>
> >> We still need the attached patch for our onboard SD card interface
> >> [1,2]. Could you please add this patch to the tree?
> > No, because according to previous discussion that isn't the correct
> > solution and more importantly it will break other archs (if I recall
> > correctly).
> >
> > Looks like someone from the ppc community needs to pick up the ball.
> I am not sure if the ppc community have to fix this issue because your
> updates (mmc-v5.4-2) are responsible for this issue. If nobody wants to
> fix this issue then we will lost the onboard SD card support in the
> future. PLEASE check the 'mmc-v5.4-2' updates again.

Applying your suggested fix breaks other archs/boards. It's really not
a good situation, but I will not take a step back when it's quite easy
to take a step forward instead.

Someone just need to care and send a patch, it doesn't look that hard
to me, but maybe I am wrong.

Apologies if this isn't the answer you wanted, but that's all I can do
for now, sorry.

Kind regards
Uffe

Re: [FSL P5020 P5040 PPC] Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

[Ulf Hansson]

On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky  wrote:
>
> Hi All,
>
> We still need the attached patch for our onboard SD card interface
> [1,2]. Could you please add this patch to the tree?

No, because according to previous discussion that isn't the correct
solution and more importantly it will break other archs (if I recall
correctly).

Looks like someone from the ppc community needs to pick up the ball.

>
> Thanks,
> Christian
>
> [1] https://www.spinics.net/lists/linux-mmc/msg56211.html

I think this discussion even suggested some viable solutions, so it
just be a matter of sending a patch :-)

> [2]
> http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4349=20#p49012
>

Kind regards
Uffe

Re: [PATCH v1 4/4] mmc: sdhci-of-esdhc: add erratum A011334 support in ls1028a 1.0 SoC

[Ulf Hansson]

On Wed, 14 Aug 2019 at 09:24, Yinbo Zhu  wrote:
>
> This patch is to add erratum A011334 support in ls1028a 1.0 SoC
>
> Signed-off-by: Yinbo Zhu 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sdhci-of-esdhc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index b16f7d440f78..eb2b290447fc 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1006,6 +1006,7 @@ static struct soc_device_attribute 
> soc_incorrect_hostver[] = {
>  static struct soc_device_attribute soc_fixup_sdhc_clkdivs[] = {
> { .family = "QorIQ LX2160A", .revision = "1.0", },
> { .family = "QorIQ LX2160A", .revision = "2.0", },
> +   { .family = "QorIQ LS1028A", .revision = "1.0", },
> { },
>  };
>
> --
> 2.17.1
>

Re: [PATCH v1 1/2] mmc/host: add FSP2(ppc476fpe) into depends for sdhci-st

[Ulf Hansson]

On 30 June 2017 at 13:53, Ivan Mikhaylov  wrote:
> shdci-st driver can be used for ppc476 fsp2 soc.
>
> Signed-off-by: Ivan Mikhaylov 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 2eb9701..edf5787 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -354,7 +354,7 @@ config MMC_MOXART
>
>  config MMC_SDHCI_ST
> tristate "SDHCI support on STMicroelectronics SoC"
> -   depends on ARCH_STI
> +   depends on ARCH_STI || FSP2
> depends on MMC_SDHCI_PLTFM
> select MMC_SDHCI_IO_ACCESSORS
> help
> --
> 1.7.1
>

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

[Ulf Hansson]

On 10 November 2016 at 10:22, Geert Uytterhoeven  wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann  wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann  wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(

No worries! :-)

>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?

Yes, I will take care of it during the day.

Kind regards
Uffe

Re: [v16, 0/7] Fix eSDHC host version register bug

[Ulf Hansson]

- i2c-list

On 9 November 2016 at 04:14, Yangbo Lu <yangbo...@nxp.com> wrote:
> This patchset is used to fix a host version register bug in the 
> T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 15 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only 
> available
> method left now. This v11 patchset introduces the soc_device_match interface 
> in
> soc driver.
>
> The first four patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other three patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> ---
> Changes for v15:
> - Dropped patch 'dt: bindings: update Freescale DCFG compatible'
>   since the work had been done by below patch on ShawnGuo's linux 
> tree.
>   'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
>and DCFG'
> - Fixed error code issue in guts driver
> Changes for v16:
> - Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
> - Added a bug-fix patch from Geert
> ---
>
> Arnd Bergmann (1):
>   base: soc: introduce soc_device_match() interface
>
> Geert Uytterhoeven (1):
>   base: soc: Check for NULL SoC device attributes
>
> Yangbo Lu (5):
>   ARM64: dts: ls2080a: add device configuration node
>   dt: bindings: move guts devicetree doc out of powerpc directory
>   soc: fsl: add GUTS driver for QorIQ platforms
>   MAINTAINERS: add entry for Freescale SoC drivers
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  MAINTAINERS|  11 +-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
>  drivers/base/Kconfig   |   1 +
>  drivers/base/soc.c |  70 ++
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
>  drivers/soc/Kconfig|   3 +-
>  drivers/soc/fsl/Kconfig|  18 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 236 
> +
>  include/linux/fsl/guts.h   | 125 ++-
>  include/linux/sys_soc.h|   3 +
>  13 files changed, 447 insertions(+), 51 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/guts.c
>
> --
> 2.1.0.27.g96db324
>

Thanks, applied on my mmc tree for next!

I noticed that some DT compatibles weren't documented, according to
checkpatch. Please fix that asap!

Kind regards
Ulf Hansson

Re: [v12, 0/8] Fix eSDHC host version register bug

[Ulf Hansson]

On 21 September 2016 at 08:57, Yangbo Lu  wrote:
> This patchset is used to fix a host version register bug in the 
> T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only 
> available
> method left now. This v11 patchset introduces the soc_device_match interface 
> in
> soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
>   base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
>   dt: bindings: update Freescale DCFG compatible
>   ARM64: dts: ls2080a: add device configuration node
>   dt: bindings: move guts devicetree doc out of powerpc directory
>   powerpc/fsl: move mpc85xx.h to include/linux/fsl
>   soc: fsl: add GUTS driver for QorIQ platforms
>   MAINTAINERS: add entry for Freescale SoC drivers
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
>  Documentation/devicetree/bindings/arm/fsl.txt  |   6 +-
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  MAINTAINERS|  11 +-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
>  arch/powerpc/sysdev/fsl_pci.c  |   2 +-
>  drivers/base/Kconfig   |   1 +
>  drivers/base/soc.c |  66 ++
>  drivers/clk/clk-qoriq.c|   3 +-
>  drivers/i2c/busses/i2c-mpc.c   |   2 +-
>  drivers/iommu/fsl_pamu.c   |   3 +-
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
>  drivers/net/ethernet/freescale/gianfar.c   |   2 +-
>  drivers/soc/Kconfig|   2 +-
>  drivers/soc/fsl/Kconfig|  19 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 257 
> +
>  include/linux/fsl/guts.h   | 125 ++
>  .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
>  include/linux/sys_soc.h|   3 +
>  21 files changed, 478 insertions(+), 61 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/guts.c
>  rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>

This looks good to me! I am not sure which tree you want this to be
picked up through, but unless no other volunteers I can take it
through my mmc tree.

Although, before considering to apply, I need an ack from Scott/Arnd
for the guts driver in patch 5/8 and I need an ack from Greg for patch
7/8, where the soc_device_match() interface is added (seems like you
didn't add him on cc/to).

Kind regards
Uffe

Re: [v11, 7/8] base: soc: introduce soc_device_match() interface

[Ulf Hansson]

On 6 September 2016 at 10:28, Yangbo Lu  wrote:
> We keep running into cases where device drivers want to know the exact
> version of the a SoC they are currently running on. In the past, this has
> usually been done through a vendor specific API that can be called by a
> driver, or by directly accessing some kind of version register that is
> not part of the device itself but that belongs to a global register area
> of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data about
>   on-chip devices, but just announces their presence using boot-time
>   platform devices, and the machine code itself does not care about the
>   revision.
>
> - There is existing firmware or boot loaders with existing DT binaries
>   with generic compatible strings that do not identify the particular
>   revision of each device, but the driver knows which SoC revisions
>   include which part.
>
> - A prerelease version of a chip has some quirks and we are using the same
>   version of the bootloader and the DT blob on both the prerelease and the
>   final version. An update of the DT binding seems inappropriate because
>   that would involve maintaining multiple copies of the dts and/or
>   bootloader.
>
> This patch introduces the soc_device_match() interface that is meant to
> work like of_match_node() but instead of identifying the version of a
> device, it identifies the SoC itself using a vendor-agnostic interface.
>
> Unlike of_match_node(), we do not do an exact string compare but instead
> use glob_match() to allow wildcards in strings.

Overall, this change make sense to me, although some minor comment below.

>
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v11:
> - Added this patch for soc match
> ---
>  drivers/base/Kconfig|  1 +
>  drivers/base/soc.c  | 61 
> +
>  include/linux/sys_soc.h |  3 +++
>  3 files changed, 65 insertions(+)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 98504ec..f1591ad2 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
>
>  config SOC_BUS
> bool
> +   select GLOB
>
>  source "drivers/base/regmap/Kconfig"
>
> diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> index 75b98aa..5c4e84a 100644
> --- a/drivers/base/soc.c
> +++ b/drivers/base/soc.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static DEFINE_IDA(soc_ida);
>
> @@ -168,3 +169,63 @@ static void __exit soc_bus_unregister(void)
> bus_unregister(_bus_type);
>  }
>  module_exit(soc_bus_unregister);
> +
> +static int soc_device_match_one(struct device *dev, void *arg)
> +{
> +   struct soc_device *soc_dev = container_of(dev, struct soc_device, 
> dev);
> +   const struct soc_device_attribute *match = arg;
> +
> +   if (match->machine &&
> +   !glob_match(match->machine, soc_dev->attr->machine))
> +   return 0;
> +
> +   if (match->family &&
> +   !glob_match(match->family, soc_dev->attr->family))
> +   return 0;
> +
> +   if (match->revision &&
> +   !glob_match(match->revision, soc_dev->attr->revision))
> +   return 0;
> +
> +   if (match->soc_id &&
> +   !glob_match(match->soc_id, soc_dev->attr->soc_id))
> +   return 0;
> +
> +   return 1;
> +}
> +
> +/*
> + * soc_device_match - identify the SoC in the machine
> + * @matches: zero-terminated array of possible matches

Perhaps also express the constraint on the matching entries. As you
need at least one of the ->machine(), ->family(), ->revision() or
->soc_id() callbacks implemented, right!?

> + *
> + * returns the first matching entry of the argument array, or NULL
> + * if none of them match.
> + *
> + * This function is meant as a helper in place of of_match_node()
> + * in cases where either no device tree is available or the information
> + * in a device node is insufficient to identify a particular variant
> + * by its compatible strings or other properties. For new devices,
> + * the DT binding should always provide unique compatible strings
> + * that allow the use of of_match_node() instead.
> + *
> + * The calling function can use the .data entry of the
> + * soc_device_attribute to pass a structure or function pointer for
> + * each entry.

I don't get the use case behind this, could you elaborate?

Perhaps we should postpone adding the .data entry until we actually
see a need for it?

> + */
> +const struct soc_device_attribute *soc_device_match(
> +   const struct soc_device_attribute *matches)
> +{
> +   struct device *dev;
> +   int ret;
> +
> +   for (ret = 0; ret == 0; matches++) {

This loop looks a bit weird and unsafe.

1) Perhaps using a while loop makes this more readable?
2) As this is an 

Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

[Ulf Hansson]

On 26 May 2016 at 06:05, Yangbo Lu  wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>

As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.

Kind regards
Uffe

> Best regards,
> Yangbo Lu
>
>
>> -Original Message-
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-ker...@lists.infradead.org
>> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
>> devicet...@vger.kernel.org; ulf.hans...@linaro.org; Russell King; Bhupesh
>> Sharma; net...@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> m...@vger.kernel.org; linux-ker...@vger.kernel.org; Yang-Leo Li;
>> io...@lists.linux-foundation.org; Rob Herring; linux-...@vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-...@vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v9, 6/7] MAINTAINERS: add entry for Freescale SoC driver

[Ulf Hansson]

On 4 May 2016 at 05:24, Yangbo Lu  wrote:
> Add maintainer entry for Freescale SoC driver including
> the QE library and the GUTS driver now. Also add maintainer
> for QE library.
>
> Signed-off-by: Yangbo Lu 

So I need an ack from Scott and Qiang for this one, then I intend to
queue up the series.

Kind regards
Uffe

> ---
> Changes for v8:
> - Added this patch
> Changes for v9:
> - Added linux-arm mail list
> - Removed GUTS driver entry
> ---
>  MAINTAINERS | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 42e65d1..ce91db7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4622,9 +4622,18 @@ F:   drivers/net/ethernet/freescale/fec_ptp.c
>  F: drivers/net/ethernet/freescale/fec.h
>  F: Documentation/devicetree/bindings/net/fsl-fec.txt
>
> +FREESCALE SOC DRIVER
> +M: Scott Wood 
> +L: linuxppc-dev@lists.ozlabs.org
> +L: linux-arm-ker...@lists.infradead.org
> +S: Maintained
> +F: drivers/soc/fsl/
> +F: include/linux/fsl/
> +
>  FREESCALE QUICC ENGINE LIBRARY
> +M: Qiang Zhao 
>  L: linuxppc-dev@lists.ozlabs.org
> -S: Orphan
> +S: Maintained
>  F: drivers/soc/fsl/qe/
>  F: include/soc/fsl/*qe*.h
>  F: include/soc/fsl/*ucc*.h
> --
> 2.1.0.27.g96db324
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v7, 0/5] Fix eSDHC host version register bug

[Ulf Hansson]

>>
>> I was about to queue this for next, when I noticed that checkpatch is
>> complaining/warning lots about these patches. Can you please a round of
>> checkpatch and fix what makes sense.
>>
>> Kind regards
>> Uffe
>
> [Lu Yangbo-B47093] Sorry about this, Uffe...

No worries!

> Should I ignore the warnings that update MAINTAINERS?

drivers/soc/fsl/guts.c isn't part of the MAINTAINERS file, it should be.

I also realize that the FREESCALE QUICC ENGINE LIBRARY section
drivers/soc/fsl/qe/* also need an active maintainer, as it's currently
orphan.

Perhaps we should have create a new section for drivers/soc/fsl/*
instead that covers all of the above? Maybe you or Scott are
interested to pick it up?

I also noted that, "include/linux/fsl/" isn't present in MAINTAINERS,
please add that as well.

> Regarding the 'undocumented' warning, I will added a patch updates doc before 
> all the patches, Ok?

Yes, good!

>
> Thanks a lot :)
>

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

Re: [v7, 0/5] Fix eSDHC host version register bug

[Ulf Hansson]

On 1 April 2016 at 05:07, Yangbo Lu  wrote:
> This patchset is used to fix a host version register bug in the 
> T4240-R1.0-R2.0
> eSDHC controller. To get the SoC version and revision, it's needed to add the
> GUTS driver to access the global utilities registers.
>
> So, the first three patches are to add the GUTS driver.
> The following two patches are to enable GUTS driver support to get SVR in 
> eSDHC
> driver and fix host version for T4240.
>
> Yangbo Lu (5):
>   ARM64: dts: ls2080a: add device configuration node
>   soc: fsl: add GUTS driver for QorIQ platforms
>   dt: move guts devicetree doc out of powerpc directory
>   powerpc/fsl: move mpc85xx.h to include/linux/fsl
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 ++
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
>  drivers/clk/clk-qoriq.c|   3 +-
>  drivers/i2c/busses/i2c-mpc.c   |   2 +-
>  drivers/iommu/fsl_pamu.c   |   3 +-
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  23 
>  drivers/net/ethernet/freescale/gianfar.c   |   2 +-
>  drivers/soc/Kconfig|   2 +-
>  drivers/soc/fsl/Kconfig|   8 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 119 
> +
>  include/linux/fsl/guts.h   |  98 -
>  .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
>  15 files changed, 219 insertions(+), 58 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/guts.c
>  rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>

I was about to queue this for next, when I noticed that checkpatch is
complaining/warning lots about these patches. Can you please a round
of checkpatch and fix what makes sense.

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

Re: [v7, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Ulf Hansson]

- decreasing the cc list significantly

On 1 April 2016 at 05:07, Yangbo Lu  wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
> a common header file. It has been used for mpc85xx and it will
> be used for ARM-based SoC as well.
>
> Signed-off-by: Yangbo Lu 
> Acked-by: Wolfram Sang 
> ---
> Changes for v2:
> - None
> Changes for v3:
> - None
> Changes for v4:
> - None
> Changes for v5:
> - Changed to Move mpc85xx.h to include/linux/fsl/
> - Adjusted '#include ' position in file
> Changes for v6:
> - None
> Changes for v7:
> - Added 'Acked-by: Wolfram Sang' for I2C part
> - Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
> ---
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
>  drivers/clk/clk-qoriq.c   | 3 +--
>  drivers/i2c/busses/i2c-mpc.c  | 2 +-
>  drivers/iommu/fsl_pamu.c  | 3 +--

Hi Joerg,

Could you have a look at the iommu parts here and provide your ack if
you like it.

I intend to queue this for 4.7 via my mmc tree, unless you see issues with that.

Kind regards
Uffe

>  drivers/net/ethernet/freescale/gianfar.c  | 2 +-
>  arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
>  6 files changed, 7 insertions(+), 9 deletions(-)
>  rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 462aed9..2b0284e 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -13,13 +13,13 @@
>   *
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>
>  _GLOBAL(__e500_icache_setup)
> mfspr   r0, SPRN_L1CSR1
> diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
> index 7bc1c45..fc7f722 100644
> --- a/drivers/clk/clk-qoriq.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1148,8 +1149,6 @@ bad_args:
>  }
>
>  #ifdef CONFIG_PPC
> -#include 
> -
>  static const u32 a4510_svrs[] __initconst = {
> (SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
> (SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index 48ecffe..600704c 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -27,9 +27,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
> -#include 
>  #include 
>
>  #define DRV_NAME "mpc-i2c"
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index a34355f..af8fb27 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -21,11 +21,10 @@
>  #include "fsl_pamu.h"
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> -#include 
> -
>  /* define indexes for each operation mapping scenario */
>  #define OMI_QMAN0x00
>  #define OMI_FMAN0x01
> diff --git a/drivers/net/ethernet/freescale/gianfar.c 
> b/drivers/net/ethernet/freescale/gianfar.c
> index d2f917a..2224b10 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -86,11 +86,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #ifdef CONFIG_PPC
>  #include 
> -#include 
>  #endif
>  #include 
>  #include 
> diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
> similarity index 97%
> rename from arch/powerpc/include/asm/mpc85xx.h
> rename to include/linux/fsl/svr.h
> index 213f3a8..8d13836 100644
> --- a/arch/powerpc/include/asm/mpc85xx.h
> +++ b/include/linux/fsl/svr.h
> @@ -9,8 +9,8 @@
>   * (at your option) any later version.
>   */
>
> -#ifndef __ASM_PPC_MPC85XX_H
> -#define __ASM_PPC_MPC85XX_H
> +#ifndef FSL_SVR_H
> +#define FSL_SVR_H
>
>  #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
>  #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
> --
> 2.1.0.27.g96db324
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Ulf Hansson]

On 27 July 2015 at 17:57, Scott Wood scottw...@freescale.com wrote:
 On Mon, 2015-07-27 at 09:58 +0200, Ulf Hansson wrote:
 On 25 July 2015 at 04:27, Scott Wood scottw...@freescale.com wrote:
  On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
   On 21 July 2015 at 11:45, Yangbo Lu yangbo...@freescale.com wrote:
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
  
   So T4240-R1.0-R2.0 is the version of the controller, right?
  
   If I understand correct you are checking what CPU/SoC you are running
   on, to figure out which controller version you are using, as that
   can't be fetched (trusted) from the registers of the esdhc controller
   itself!?
  
   Instead, you could deal with this directly in the DTS files. I assume
   you have some DTS file for each SoC/board variant, right?
 
  No, we do not have a separate DTS file for each revision of an SoC -- and
  if
  we did, we'd constantly have people using the wrong one.
 
   In principle, in your DTS file specific for the board/SoC that holds
   the T4240-R1.0-R2.0 version of the controller, should add a specific
   esdhc DT property to indicate this errata.
 
  No, because (in addition to the above issue about chip revisions) the
  device
  tree is stable ABI and errata are often discovered after device trees are
  deployed.

 Fair enough. Then what is your suggestion for the solution here?

 As I said in my comment on patch 2/3, read SVR from the device-config/guts
 MMIO block, which works on both PPC and ARM.


That's okay, as long as don't have include sections of non generic
header files in the driver.

To be more clear, this is not okay to have:
#include mach/*

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

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Ulf Hansson]

On 25 July 2015 at 04:27, Scott Wood scottw...@freescale.com wrote:
 On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
 On 21 July 2015 at 11:45, Yangbo Lu yangbo...@freescale.com wrote:
  For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
  version value and sdhc spec version value. This will break down
  the ADMA data transfer. So add workaround to get right value
  VVN=0x13, SVN = 0x1.

 So T4240-R1.0-R2.0 is the version of the controller, right?

 If I understand correct you are checking what CPU/SoC you are running
 on, to figure out which controller version you are using, as that
 can't be fetched (trusted) from the registers of the esdhc controller
 itself!?

 Instead, you could deal with this directly in the DTS files. I assume
 you have some DTS file for each SoC/board variant, right?

 No, we do not have a separate DTS file for each revision of an SoC -- and if
 we did, we'd constantly have people using the wrong one.

 In principle, in your DTS file specific for the board/SoC that holds
 the T4240-R1.0-R2.0 version of the controller, should add a specific
 esdhc DT property to indicate this errata.

 No, because (in addition to the above issue about chip revisions) the device
 tree is stable ABI and errata are often discovered after device trees are
 deployed.

Fair enough. Then what is your suggestion for the solution here?

As I understand it, you can't update the already deployed DTB. Shall
we make Linux patch the DTB during boot instead, depending on the chip
revision?

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

Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value

[Ulf Hansson]

On 21 July 2015 at 11:45, Yangbo Lu yangbo...@freescale.com wrote:
 For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
 version value and sdhc spec version value. This will break down
 the ADMA data transfer. So add workaround to get right value
 VVN=0x13, SVN = 0x1.

So T4240-R1.0-R2.0 is the version of the controller, right?

If I understand correct you are checking what CPU/SoC you are running
on, to figure out which controller version you are using, as that
can't be fetched (trusted) from the registers of the esdhc controller
itself!?

Instead, you could deal with this directly in the DTS files. I assume
you have some DTS file for each SoC/board variant, right?

In principle, in your DTS file specific for the board/SoC that holds
the T4240-R1.0-R2.0 version of the controller, should add a specific
esdhc DT property to indicate this errata. This DT property will then
be parsed by the esdhc driver.


 Signed-off-by: Yangbo Lu yangbo...@freescale.com
 ---
  drivers/mmc/host/sdhci-esdhc.h|  5 +
  drivers/mmc/host/sdhci-of-esdhc.c | 18 ++
  2 files changed, 23 insertions(+)

 diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
 index 3497cfa..5174233 100644
 --- a/drivers/mmc/host/sdhci-esdhc.h
 +++ b/drivers/mmc/host/sdhci-esdhc.h
 @@ -47,4 +47,9 @@

  #define ESDHC_HOST_CONTROL_RES 0x05

 +unsigned int esdhc_errata;
 +
 +/* Incorrect host version in T4240 HOSTVER register */
 +#define ESDHC_ERRATA_T4240_ERROR_HOSTVER   (10)
 +
  #endif /* _DRIVERS_MMC_SDHCI_ESDHC_H */
 diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
 b/drivers/mmc/host/sdhci-of-esdhc.c
 index 1295a96..c0ad765 100644
 --- a/drivers/mmc/host/sdhci-of-esdhc.c
 +++ b/drivers/mmc/host/sdhci-of-esdhc.c
 @@ -59,6 +59,11 @@ static u16 esdhc_readw(struct sdhci_host *host, int reg)
 ret = in_be32(host-ioaddr + base)  0x;
 else
 ret = (in_be32(host-ioaddr + base)  shift)  0x;
 +
 +   if ((reg == SDHCI_HOST_VERSION) 
 +   (esdhc_errata  ESDHC_ERRATA_T4240_ERROR_HOSTVER))
 +   ret = (VENDOR_V_23  SDHCI_VENDOR_VER_SHIFT) | 
 SDHCI_SPEC_200;
 +
 return ret;
  }

 @@ -352,6 +357,9 @@ static void esdhc_get_property(struct platform_device 
 *pdev)
  {
 struct device_node *np = pdev-dev.of_node;
 struct sdhci_host *host = platform_get_drvdata(pdev);
 +   struct device_node *cpus;
 +   const u32 *prop;
 +   u8 rev = 0xff;

 sdhci_get_of_property(pdev);

 @@ -359,6 +367,11 @@ static void esdhc_get_property(struct platform_device 
 *pdev)
 mmc_of_parse(host-mmc);
 mmc_of_parse_voltage(np, host-ocr_mask);

 +   cpus = of_find_node_by_path(/cpus);
 +   prop = of_get_property(cpus, cpu-rev, NULL);
 +   if (prop)
 +   rev = *(u8 *)prop;
 +
 if (of_device_is_compatible(np, fsl,p5040-esdhc) ||
 of_device_is_compatible(np, fsl,p5020-esdhc) ||
 of_device_is_compatible(np, fsl,p4080-esdhc) ||
 @@ -373,6 +386,11 @@ static void esdhc_get_property(struct platform_device 
 *pdev)
  */
 host-quirks2 |= SDHCI_QUIRK2_BROKEN_HOST_CONTROL;
 }
 +
 +   esdhc_errata = 0;
 +
 +   if (of_device_is_compatible(np, fsl,t4240-esdhc)  rev = 0x20)
 +   esdhc_errata |= ESDHC_ERRATA_T4240_ERROR_HOSTVER;
  }

  static int sdhci_esdhc_probe(struct platform_device *pdev)
 --
 2.1.0.27.g96db324


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

Re: [PATCH v8 2/2] mmc: host: sdhci: Disable 1.8V signaling for arasan 4.9a version of SDHCI controller.

[Ulf Hansson]

On 19 June 2015 at 14:28, Suman Tripathi stripa...@apm.com wrote:
 Hi ,

 On Fri, Jun 19, 2015 at 5:30 PM, Suman Tripathi stripa...@apm.com wrote:
 This patch disables the 1.8V signaling for arasan 4.9a version
 of SDHCI controller with the help SDHCI_QUIRK2_NO_1_8_V quirk.

 Signed-off-by: Suman Tripathi stripa...@apm.com
 ---
 ---
  drivers/mmc/host/sdhci-of-arasan.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
 b/drivers/mmc/host/sdhci-of-arasan.c
 index 21c0c08..4c99ea4 100644
 --- a/drivers/mmc/host/sdhci-of-arasan.c
 +++ b/drivers/mmc/host/sdhci-of-arasan.c
 @@ -171,7 +171,8 @@ static int sdhci_arasan_probe(struct platform_device 
 *pdev)

 if (of_device_is_compatible(pdev-dev.of_node, arasan,sdhci-4.9a)) 
 {
 host-quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
 -   host-quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 +   host-quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23 |
 +SDHCI_QUIRK2_NO_1_8_V;
 }


 I think I am  wrong here. No-1.8v is something related to board
 regulator circuitry not related to IP version. So it should be dts
 driven.

Agree!

So I guess that will change patch1 and this one can be completely dropped?

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

Re: [PATCH RESEND v7 2/2] mmc: host: sdhci: Add support to disable SDR104/SDR50/DDR50 based on capability register 0.

[Ulf Hansson]

[...]

 
 Can you test this patch  on imx SoC ?
 

 (Your email have some format issue.)

 Yeah missed to sent in plain text mode.


 I have tested this patch and it does not break imx SoC.
 You can add my tag.
 Tested-by: Dong Aisheng aisheng.d...@freescale.com

 Thanks Dong !!


 However, it looks to me SDHCI_CAN_VDD_180 is only indicating the host VDD
 capabiliies, not IO voltage capability.

I think Dong is correct. I don't think SDHCI_CAN_VDD_180 is not
related to UHS modes at all.

At least the name of the field (SDHCI_CAN_VDD_180) indicates it's
about VDD/VCC, the core power and not the IO voltage.

 Are you sure on this ?? If SDHCI host VDD is  1.8V then the cards are
 also capable to operate at 1.8V ? Didn't understand what you mean by
 IO voltage capability


 SD3.0 cards require 1.8v IO voltage support.
 So should this bit affect SD3.0 support?

 The preset value resgister says that  SDR modes requires 1.8V and we
 disable the modes based on capability or quirk.

It requires 1.8V *IO voltage*, not VDD/VCC.

[...]

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

Re: [PATCH RESEND v7 2/2] mmc: host: sdhci: Add support to disable SDR104/SDR50/DDR50 based on capability register 0.

[Ulf Hansson]

On 8 June 2015 at 10:37, Ulf Hansson ulf.hans...@linaro.org wrote:
 [...]

 
 Can you test this patch  on imx SoC ?
 

 (Your email have some format issue.)

 Yeah missed to sent in plain text mode.


 I have tested this patch and it does not break imx SoC.
 You can add my tag.
 Tested-by: Dong Aisheng aisheng.d...@freescale.com

 Thanks Dong !!


 However, it looks to me SDHCI_CAN_VDD_180 is only indicating the host VDD
 capabiliies, not IO voltage capability.

 I think Dong is correct. I don't think SDHCI_CAN_VDD_180 is not

/s /is not /is

 related to UHS modes at all.

 At least the name of the field (SDHCI_CAN_VDD_180) indicates it's
 about VDD/VCC, the core power and not the IO voltage.

 Are you sure on this ?? If SDHCI host VDD is  1.8V then the cards are
 also capable to operate at 1.8V ? Didn't understand what you mean by
 IO voltage capability


 SD3.0 cards require 1.8v IO voltage support.
 So should this bit affect SD3.0 support?

 The preset value resgister says that  SDR modes requires 1.8V and we
 disable the modes based on capability or quirk.

 It requires 1.8V *IO voltage*, not VDD/VCC.

 [...]

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

Re: [PATCH RESEND v7 2/2] mmc: host: sdhci: Add support to disable SDR104/SDR50/DDR50 based on capability register 0.

[Ulf Hansson]

On 21 May 2015 at 10:43, Suman Tripathi stripa...@apm.com wrote:
 The sdhci framework disables SDR104/SDR50/DDR50 based on only quirk.
 This patch adds the support to disable SDR104/SDR50/DDR50 based on
 reading the capability register 0.

 Signed-off-by: Suman Tripathi stripa...@apm.com
 ---
 ---
  drivers/mmc/host/sdhci.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
 index 58c1770..a3d9b8a 100644
 --- a/drivers/mmc/host/sdhci.c
 +++ b/drivers/mmc/host/sdhci.c
 @@ -3118,7 +3118,8 @@ int sdhci_add_host(struct sdhci_host *host)
 }
 }

 -   if (host-quirks2  SDHCI_QUIRK2_NO_1_8_V)
 +   if (host-quirks2  SDHCI_QUIRK2_NO_1_8_V ||
 +   !(caps[0]  SDHCI_CAN_VDD_180))
 caps[1] = ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);

 --
 1.8.2.1


I have no problem with this patch, except that it would be nice to get
a few tested by to make sure it doesn't break UHS support for some
SoCs.

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

Re: [PATCH RESEND v6 1/2] arm64: dts: Add the arasan sdhci nodes in apm-storm.dtsi

[Ulf Hansson]

On 12 May 2015 at 09:28, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 12 May 2015 11:03:46 Suman Tripathi wrote:
  @@ -533,6 +567,15 @@
  interrupts = 0x0 0x4f 0x4;
  };
 
  +   sdhci0: sdhci@1c00 {
  +   compatible = arasan,sdhci-4.9a;
  +   reg = 0x0 0x1c00 0x0 0x100;
  +   interrupts = 0x0 0x49 0x4;
  +   dma-coherent;
  +   clock-names = clk_xin, clk_ahb;
  +   clocks = sdioclk 0, ahbclk 0;
  +   };
  +
  phy1: phy@1f21a000 {
  compatible = apm,xgene-phy;
  reg = 0x0 0x1f21a000 0x0 0x100;
  --
  1.8.2.1
 

 Can anyone from dt community review this patch ? I have changed the dts node
 names from sdhc to sdhci as per Arnd, Michael comments .

 I was actually asking for it to be named 'mmc', not 'sdhci', because the
 name is supposed to indicate the purpose of the device, not the
 implementation. I realize that we are inconsistent here, just as with
 'uart' vs 'serial', and that ePAPR does not define what to do.

Then we need a common name to address the following purposes: SD, MMC,
eMMC, SDIO.


 We should probably add something to 
 Documentation/devicetree/bindings/mmc/mmc.txt
 about this topic and change all the dts files accordingly (unless there
 is a risk for regressions). At the moment, the mmc.txt file also includes
 an example with 'sdhci', not 'mmc'.


I am happy to change, as long as we can come up with something better.

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

Re: [PATCH v5 1/1] arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.

[Ulf Hansson]

On 5 May 2015 at 12:34, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 5 May 2015 at 11:17, Suman Tripathi stripa...@apm.com wrote:
 This patch adds the arasan sdhc nodes to reuse the of-arasan
 driver for APM X-Gene SoC.

 Signed-off-by: Suman Tripathi stripa...@apm.com

 I consider this one acked by Arnd, due to:
 http://www.spinics.net/lists/arm-kernel/msg415634.html

 Thus applied to my mmc tree.

According to follow up comments, I have dropped this patch from my tree for now.

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

Re: [PATCH v4 0/3] Add SDHCI support for APM X-Gene SoC using ARASAN SDHCI controller.

[Ulf Hansson]

On 5 May 2015 at 10:42, Suman Tripathi stripa...@apm.com wrote:
 On Tue, May 5, 2015 at 2:06 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 4 May 2015 at 15:39, Suman Tripathi stripa...@apm.com wrote:
 This patch adds the SDHCI support for APM X-Gene SoC using ARASAN SDHCI 
 controller.

 v1 change:
  * Use the CONFIG_ARM64_DMA_HAS_IOMMU for dma-mapping.

 v2 change:
  * Drop the IOMMU support and switching to PIO mode for arasan.
controller integrated inside APM X-Gene SoC.

 v3 change:
  * Change the sdhci-of-arasan.c to support arasan4.9a.
  * Add quirks for arasan4.9a.

 v4 change:
  * Cleanup the Documentation and dts.

 Signed-off-by: Suman Tripathi stripa...@apm.com
 ---

 Suman Tripathi (3):
   arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.
   mmc: host: arasan: Add the support for sdhci-arasan4.9a in
 sdhci-of-arasan.c
   Documentation: mmc: Update Arasan SDHC documentation to support 4.9a
 version of Arasan SDHC controller.

  .../devicetree/bindings/mmc/arasan,sdhci.txt   |  3 +-
  arch/arm64/boot/dts/apm-mustang.dts|  4 ++
  arch/arm64/boot/dts/apm-storm.dtsi | 44 
 ++
  drivers/mmc/host/sdhci-of-arasan.c |  7 
  4 files changed, 57 insertions(+), 1 deletion(-)


 Thanks!

 I have applied patch2 and patch3. Though, I decided to squash them
 into one patch and changed the commit message header a bit.

 I couldn't apply patch 1, so I guess that will be taken through arm soc?

 why it couldn't be applied?? I made it in top of

 git git://git.linaro.org/people/ulf.hansson/mmc.git

 Is this not correct ??

That's correct, but it apparently needs a rebase.
The below files has moved:
arch/arm64/boot/dts/apm-mustang.dts
arch/arm64/boot/dts/apm-storm.dtsi

Send a new version and I am happy to take it through my tree, since it
got Arnd's ack.

Kind regards
Uffe



 Kind regards
 Uffe



 --
 Thanks,
 with regards,
 Suman Tripathi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 0/3] Add SDHCI support for APM X-Gene SoC using ARASAN SDHCI controller.

[Ulf Hansson]

On 4 May 2015 at 15:39, Suman Tripathi stripa...@apm.com wrote:
 This patch adds the SDHCI support for APM X-Gene SoC using ARASAN SDHCI 
 controller.

 v1 change:
  * Use the CONFIG_ARM64_DMA_HAS_IOMMU for dma-mapping.

 v2 change:
  * Drop the IOMMU support and switching to PIO mode for arasan.
controller integrated inside APM X-Gene SoC.

 v3 change:
  * Change the sdhci-of-arasan.c to support arasan4.9a.
  * Add quirks for arasan4.9a.

 v4 change:
  * Cleanup the Documentation and dts.

 Signed-off-by: Suman Tripathi stripa...@apm.com
 ---

 Suman Tripathi (3):
   arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.
   mmc: host: arasan: Add the support for sdhci-arasan4.9a in
 sdhci-of-arasan.c
   Documentation: mmc: Update Arasan SDHC documentation to support 4.9a
 version of Arasan SDHC controller.

  .../devicetree/bindings/mmc/arasan,sdhci.txt   |  3 +-
  arch/arm64/boot/dts/apm-mustang.dts|  4 ++
  arch/arm64/boot/dts/apm-storm.dtsi | 44 
 ++
  drivers/mmc/host/sdhci-of-arasan.c |  7 
  4 files changed, 57 insertions(+), 1 deletion(-)


Thanks!

I have applied patch2 and patch3. Though, I decided to squash them
into one patch and changed the commit message header a bit.

I couldn't apply patch 1, so I guess that will be taken through arm soc?

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

Re: [PATCH v2 2/2] mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

[Ulf Hansson]

On 30 March 2015 at 16:46, Suman Tripathi stripa...@apm.com wrote:
 This patch adds some quirks support to be read from fdt.

 Signed-off-by: Suman Tripathi stripa...@apm.com
 ---
  drivers/mmc/host/sdhci-pltfm.c | 15 +++
  1 file changed, 15 insertions(+)

 diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
 index bef250e..9f6a4b9 100644
 --- a/drivers/mmc/host/sdhci-pltfm.c
 +++ b/drivers/mmc/host/sdhci-pltfm.c
 @@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device *pdev)

 if (of_get_property(np, broken-cd, NULL))
 host-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
 +
 +   if (of_get_property(np, delay-after-power, NULL))
 +   host-quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
 +
 +   if (of_get_property(np, no-hispd, NULL))
 +   host-quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
 +
 +   if (of_get_property(np, broken-adma, NULL))
 +   host-quirks |= SDHCI_QUIRK_BROKEN_ADMA;
 +
 +   if (of_get_property(np, broken-dma, NULL))
 +   host-quirks |= SDHCI_QUIRK_BROKEN_DMA;
 +
 +   if (of_get_property(np, no-cmd23, NULL))
 +   host-quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;

Can't at least some of these be distinguished from what sdhci variant
that is being used? Instead of having them in DT...

Kind regards
Uffe


 if (of_get_property(np, no-1-8-v, NULL))
 host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 --
 1.8.2.1

 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 09/11] mmc: kconfig: replace PPC_OF with PPC

[Ulf Hansson]

On 26 February 2015 at 13:08, Kevin Hao haoke...@gmail.com wrote:
 The PPC_OF is a ppc specific option which is used to mean that the
 firmware device tree access functions are available. Since all the
 ppc platforms have a device tree, it is aways set to 'y' for ppc.
 So it makes no sense to keep a such option in the current kernel.
 Replace it with PPC.

 Signed-off-by: Kevin Hao haoke...@gmail.com

Applied, thanks!

Kind regards
Uffe


 ---
 v2: No change.

  drivers/mmc/host/Kconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
 index 61ac63a3776a..7858d7a52818 100644
 --- a/drivers/mmc/host/Kconfig
 +++ b/drivers/mmc/host/Kconfig
 @@ -132,7 +132,7 @@ config MMC_SDHCI_OF_ARASAN
  config MMC_SDHCI_OF_ESDHC
 tristate SDHCI OF support for the Freescale eSDHC controller
 depends on MMC_SDHCI_PLTFM
 -   depends on PPC_OF
 +   depends on PPC
 select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
 help
   This selects the Freescale eSDHC controller support.
 @@ -144,7 +144,7 @@ config MMC_SDHCI_OF_ESDHC
  config MMC_SDHCI_OF_HLWD
 tristate SDHCI OF support for the Nintendo Wii SDHCI controllers
 depends on MMC_SDHCI_PLTFM
 -   depends on PPC_OF
 +   depends on PPC
 select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
 help
   This selects the Secure Digital Host Controller Interface (SDHCI)
 --
 1.9.3

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

Re: [PATCH] mmc: sdhci-pltfm: remove the unneeded check of disabled device

[Ulf Hansson]

On 4 February 2015 at 07:33, Kevin Hao haoke...@gmail.com wrote:
 Since commit cd1e65044d44 (of/device: Don't register disabled
 devices), the disabled device will not be registered at all. So
 we don't need to do the check again in the platform device driver.

 And the check in the current code is useless even if we really
 run into a disabled device. In this case, it just doesn't parse
 the dtb for the infos such as quirks or clock, but it will continue
 to try to init the disabled device after that check. So just remove it.

 Signed-off-by: Kevin Hao haoke...@gmail.com

Applied, thanks!

Kind regards
Uffe

 ---
  drivers/mmc/host/sdhci-pltfm.c | 54 
 --
  1 file changed, 26 insertions(+), 28 deletions(-)

 diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
 index c5b01d6bb85d..b609c03a9ef8 100644
 --- a/drivers/mmc/host/sdhci-pltfm.c
 +++ b/drivers/mmc/host/sdhci-pltfm.c
 @@ -75,43 +75,41 @@ void sdhci_get_of_property(struct platform_device *pdev)
 u32 bus_width;
 int size;

 -   if (of_device_is_available(np)) {
 -   if (of_get_property(np, sdhci,auto-cmd12, NULL))
 -   host-quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
 +   if (of_get_property(np, sdhci,auto-cmd12, NULL))
 +   host-quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;

 -   if (of_get_property(np, sdhci,1-bit-only, NULL) ||
 -   (of_property_read_u32(np, bus-width, bus_width) == 0 
 -   bus_width == 1))
 -   host-quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
 +   if (of_get_property(np, sdhci,1-bit-only, NULL) ||
 +   (of_property_read_u32(np, bus-width, bus_width) == 0 
 +   bus_width == 1))
 +   host-quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;

 -   if (sdhci_of_wp_inverted(np))
 -   host-quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
 +   if (sdhci_of_wp_inverted(np))
 +   host-quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;

 -   if (of_get_property(np, broken-cd, NULL))
 -   host-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
 +   if (of_get_property(np, broken-cd, NULL))
 +   host-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;

 -   if (of_get_property(np, no-1-8-v, NULL))
 -   host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 +   if (of_get_property(np, no-1-8-v, NULL))
 +   host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;

 -   if (of_device_is_compatible(np, fsl,p2020-rev1-esdhc))
 -   host-quirks |= SDHCI_QUIRK_BROKEN_DMA;
 +   if (of_device_is_compatible(np, fsl,p2020-rev1-esdhc))
 +   host-quirks |= SDHCI_QUIRK_BROKEN_DMA;

 -   if (of_device_is_compatible(np, fsl,p2020-esdhc) ||
 -   of_device_is_compatible(np, fsl,p1010-esdhc) ||
 -   of_device_is_compatible(np, fsl,t4240-esdhc) ||
 -   of_device_is_compatible(np, fsl,mpc8536-esdhc))
 -   host-quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 +   if (of_device_is_compatible(np, fsl,p2020-esdhc) ||
 +   of_device_is_compatible(np, fsl,p1010-esdhc) ||
 +   of_device_is_compatible(np, fsl,t4240-esdhc) ||
 +   of_device_is_compatible(np, fsl,mpc8536-esdhc))
 +   host-quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;

 -   clk = of_get_property(np, clock-frequency, size);
 -   if (clk  size == sizeof(*clk)  *clk)
 -   pltfm_host-clock = be32_to_cpup(clk);
 +   clk = of_get_property(np, clock-frequency, size);
 +   if (clk  size == sizeof(*clk)  *clk)
 +   pltfm_host-clock = be32_to_cpup(clk);

 -   if (of_find_property(np, keep-power-in-suspend, NULL))
 -   host-mmc-pm_caps |= MMC_PM_KEEP_POWER;
 +   if (of_find_property(np, keep-power-in-suspend, NULL))
 +   host-mmc-pm_caps |= MMC_PM_KEEP_POWER;

 -   if (of_find_property(np, enable-sdio-wakeup, NULL))
 -   host-mmc-pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
 -   }
 +   if (of_find_property(np, enable-sdio-wakeup, NULL))
 +   host-mmc-pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
  }
  #else
  void sdhci_get_of_property(struct platform_device *pdev) {}
 --
 1.9.3

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

Re: [PATCH] mmc: sdhci: Apply FSL ESDHC reset handling quirk to OF

[Ulf Hansson]

On 28 January 2015 at 20:52, Martin Hicks m...@bork.org wrote:

 The reset code was pushed into the esdhc-imx driver, but missed being
 pushed into the FSL OF driver at the same time.  The commit that broke
 the OF ESDHC driver was 0718e59ae259f7c48155b4e852d8b0632d59028e

 Signed-off-by: Martin Hicks m...@bork.org

Martin, thanks for the patch. Though I have already queued a patch for
this issue. It's available on my next branch.

Alessio Igor Bogani alessio.bog...@elettra.eu
mmc: sdhci: Fix FSL ESDHC reset handling quirk

Kind regards
Uffe

 ---
  drivers/mmc/host/sdhci-of-esdhc.c |   10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
 b/drivers/mmc/host/sdhci-of-esdhc.c
 index 8872c85..4a654d4 100644
 --- a/drivers/mmc/host/sdhci-of-esdhc.c
 +++ b/drivers/mmc/host/sdhci-of-esdhc.c
 @@ -276,6 +276,14 @@ static void esdhc_pltfm_set_bus_width(struct sdhci_host 
 *host, int width)
 ESDHC_CTRL_BUSWIDTH_MASK, ctrl);
  }

 +static void esdhc_reset(struct sdhci_host *host, u8 mask)
 +{
 +   sdhci_reset(host, mask);
 +
 +   sdhci_writel(host, host-ier, SDHCI_INT_ENABLE);
 +   sdhci_writel(host, host-ier, SDHCI_SIGNAL_ENABLE);
 +}
 +
  static const struct sdhci_ops sdhci_esdhc_ops = {
 .read_l = esdhc_readl,
 .read_w = esdhc_readw,
 @@ -290,7 +298,7 @@ static const struct sdhci_ops sdhci_esdhc_ops = {
 .platform_init = esdhc_of_platform_init,
 .adma_workaround = esdhci_of_adma_workaround,
 .set_bus_width = esdhc_pltfm_set_bus_width,
 -   .reset = sdhci_reset,
 +   .reset = esdhc_reset,
 .set_uhs_signaling = sdhci_set_uhs_signaling,
  };

 --
 1.7.10.4


 --
 Martin Hicks P.Eng.|  m...@bork.org
 Bork Consulting Inc.   |  +1 (613) 266-2296
 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device

[Ulf Hansson]

On 11 August 2014 11:32, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 11 August 2014 11:15, Pawel Moll pawel.m...@arm.com wrote:
 On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
 On 8 August 2014 18:36, Pawel Moll pawel.m...@arm.com wrote:
  On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
  The code selecting a device for the sdhci host has been
  continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
  mmc: sdhci-pltfm: Add structure for host-specific data and
  a4d2177f00a5252d825236c5124bc1e9918bdb41 mmc: sdhci-pltfm: dt
  device does not pass parent to sdhci_alloc_host) while there
  does not seem to be any reason to use platform device's parent
  in the first place.
 
  The comment saying Some PCI-based MFD need the parent here
  seem to refer to Timberdale FPGA driver (the only MFD driver
  registering SDHCI cell, drivers/mfd/timberdale.c) but again,
  the only situation when parent device matter is runtime PM,
  which is not implemented for Timberdale.
 
  Cc: Chris Ball ch...@printf.net
  Cc: Anton Vorontsov an...@enomsg.org
  Cc: Ulf Hansson ulf.hans...@linaro.org
  Cc: linux-...@vger.kernel.org
  Cc: linuxppc-dev@lists.ozlabs.org
  Signed-off-by: Pawel Moll pawel.m...@arm.com
  ---
 
  This patch is a part of effort to remove references to platform_bus
  and make it static.
 
  Chris, Anton, Ulf - could you please advise if the assumptions
  above are correct or if I'm completely wrong? Do you know what
  where the real reasons to use parent originally? The PCI comment
  seems like a red herring to me...
 
  Can I take the silence as a suggestion that the change looks ok-ish for
  you?

 Sorry for the delay. I suppose this make sense, but I really don't
 know for sure.

 I guess we need some testing in linux-next, to get some confidence.

 Would you take it into -next then? Unless I'm completely wrong there
 should be no impact on any in-tree driver...

 I will take it; though I think it's best to queue it for 3.18 to get
 some more testing.

This patch causes a compiler warning, could you please fix it.

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

Re: [PATCH 3/5 v2] mmc: sdhci-pltfm: Do not use parent as the host's device

[Ulf Hansson]

On 12 August 2014 12:37, Pawel Moll pawel.m...@arm.com wrote:
 The code selecting a device for the sdhci host has been
 continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
 mmc: sdhci-pltfm: Add structure for host-specific data and
 a4d2177f00a5252d825236c5124bc1e9918bdb41 mmc: sdhci-pltfm: dt
 device does not pass parent to sdhci_alloc_host while there
 does not seem to be any reason to use platform device's parent
 in the first place.

 The comment saying Some PCI-based MFD need the parent here
 seem to refer to Timberdale FPGA driver (the only MFD driver
 registering SDHCI cell, drivers/mfd/timberdale.c) but again,
 the only situation when parent device matter is runtime PM,
 which is not implemented for Timberdale.

 Signed-off-by: Pawel Moll pawel.m...@arm.com

Thanks! Queued for 3.18.

Kind regards
Uffe

 ---
  drivers/mmc/host/sdhci-pltfm.c | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

 diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
 index 7e834fb..c5b01d6 100644
 --- a/drivers/mmc/host/sdhci-pltfm.c
 +++ b/drivers/mmc/host/sdhci-pltfm.c
 @@ -123,7 +123,6 @@ struct sdhci_host *sdhci_pltfm_init(struct 
 platform_device *pdev,
 size_t priv_size)
  {
 struct sdhci_host *host;
 -   struct device_node *np = pdev-dev.of_node;
 struct resource *iomem;
 int ret;

 @@ -136,13 +135,8 @@ struct sdhci_host *sdhci_pltfm_init(struct 
 platform_device *pdev,
 if (resource_size(iomem)  0x100)
 dev_err(pdev-dev, Invalid iomem size!\n);

 -   /* Some PCI-based MFD need the parent here */
 -   if (pdev-dev.parent != platform_bus  !np)
 -   host = sdhci_alloc_host(pdev-dev.parent,
 -   sizeof(struct sdhci_pltfm_host) + priv_size);
 -   else
 -   host = sdhci_alloc_host(pdev-dev,
 -   sizeof(struct sdhci_pltfm_host) + priv_size);
 +   host = sdhci_alloc_host(pdev-dev,
 +   sizeof(struct sdhci_pltfm_host) + priv_size);

 if (IS_ERR(host)) {
 ret = PTR_ERR(host);
 --
 1.9.1

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

Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device

[Ulf Hansson]

On 8 August 2014 18:36, Pawel Moll pawel.m...@arm.com wrote:
 On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
 The code selecting a device for the sdhci host has been
 continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
 mmc: sdhci-pltfm: Add structure for host-specific data and
 a4d2177f00a5252d825236c5124bc1e9918bdb41 mmc: sdhci-pltfm: dt
 device does not pass parent to sdhci_alloc_host) while there
 does not seem to be any reason to use platform device's parent
 in the first place.

 The comment saying Some PCI-based MFD need the parent here
 seem to refer to Timberdale FPGA driver (the only MFD driver
 registering SDHCI cell, drivers/mfd/timberdale.c) but again,
 the only situation when parent device matter is runtime PM,
 which is not implemented for Timberdale.

 Cc: Chris Ball ch...@printf.net
 Cc: Anton Vorontsov an...@enomsg.org
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Cc: linux-...@vger.kernel.org
 Cc: linuxppc-dev@lists.ozlabs.org
 Signed-off-by: Pawel Moll pawel.m...@arm.com
 ---

 This patch is a part of effort to remove references to platform_bus
 and make it static.

 Chris, Anton, Ulf - could you please advise if the assumptions
 above are correct or if I'm completely wrong? Do you know what
 where the real reasons to use parent originally? The PCI comment
 seems like a red herring to me...

 Can I take the silence as a suggestion that the change looks ok-ish for
 you?

Sorry for the delay. I suppose this make sense, but I really don't
know for sure.

I guess we need some testing in linux-next, to get some confidence.

Kind regards
Uffe


 Paweł

 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device

[Ulf Hansson]

On 11 August 2014 11:15, Pawel Moll pawel.m...@arm.com wrote:
 On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
 On 8 August 2014 18:36, Pawel Moll pawel.m...@arm.com wrote:
  On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
  The code selecting a device for the sdhci host has been
  continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
  mmc: sdhci-pltfm: Add structure for host-specific data and
  a4d2177f00a5252d825236c5124bc1e9918bdb41 mmc: sdhci-pltfm: dt
  device does not pass parent to sdhci_alloc_host) while there
  does not seem to be any reason to use platform device's parent
  in the first place.
 
  The comment saying Some PCI-based MFD need the parent here
  seem to refer to Timberdale FPGA driver (the only MFD driver
  registering SDHCI cell, drivers/mfd/timberdale.c) but again,
  the only situation when parent device matter is runtime PM,
  which is not implemented for Timberdale.
 
  Cc: Chris Ball ch...@printf.net
  Cc: Anton Vorontsov an...@enomsg.org
  Cc: Ulf Hansson ulf.hans...@linaro.org
  Cc: linux-...@vger.kernel.org
  Cc: linuxppc-dev@lists.ozlabs.org
  Signed-off-by: Pawel Moll pawel.m...@arm.com
  ---
 
  This patch is a part of effort to remove references to platform_bus
  and make it static.
 
  Chris, Anton, Ulf - could you please advise if the assumptions
  above are correct or if I'm completely wrong? Do you know what
  where the real reasons to use parent originally? The PCI comment
  seems like a red herring to me...
 
  Can I take the silence as a suggestion that the change looks ok-ish for
  you?

 Sorry for the delay. I suppose this make sense, but I really don't
 know for sure.

 I guess we need some testing in linux-next, to get some confidence.

 Would you take it into -next then? Unless I'm completely wrong there
 should be no impact on any in-tree driver...

I will take it; though I think it's best to queue it for 3.18 to get
some more testing.

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

Re: [RFC PATCH v2 6/6] mmc: core: add manual resume capability

[Ulf Hansson]

On 27 juni 2014 04:23:42 CEST, Vincent Yang vincent.yang.fuji...@gmail.com 
wrote:
2014-06-26 17:42 GMT+08:00 Ulf Hansson ulf.hans...@linaro.org:


 On 26 juni 2014 08:23:32 CEST, Vincent Yang
vincent.yang.fuji...@gmail.com wrote:
This patch adds manual resume for some embedded platforms with rootfs
stored in SD card. It references CONFIG_MMC_BLOCK_DEFERRED_RESUME in
kernel 3.10. It lets host controller driver to manually handle resume
by itself.

[symptom]
This issue is found on mb86s7x platforms with rootfs stored in SD
card.
It failed to resume form STR suspend mode because SD card cannot be
ready
in time. It take longer time (e.g., 600ms) to be ready for access.
The error log looks like below:

root@localhost:~# echo mem  /sys/power/state
[   30.441974] SUSPEND

SCB Firmware : Category 01 Version 02.03 Rev. 00_
Config   : (no configuration)
root@localhost:~# [   30.702976] Buffer I/O error on device
mmcblk1p2,
logical block 31349
[   30.709678] Buffer I/O error on device mmcblk1p2, logical block
168073
[   30.716220] Buffer I/O error on device mmcblk1p2, logical block
168074
[   30.722759] Buffer I/O error on device mmcblk1p2, logical block
168075
[   30.729456] Buffer I/O error on device mmcblk1p2, logical block
31349
[   30.735916] Buffer I/O error on device mmcblk1p2, logical block
31350
[   30.742370] Buffer I/O error on device mmcblk1p2, logical block
31351
[   30.749025] Buffer I/O error on device mmcblk1p2, logical block
168075
[   30.755657] Buffer I/O error on device mmcblk1p2, logical block
31351
[   30.763130] Aborting journal on device mmcblk1p2-8.
[   30.768060] JBD2: Error -5 detected when updating journal
superblock
for mmcblk1p2-8.
[   30.776085] EXT4-fs error (device mmcblk1p2):
ext4_journal_check_start:56: Detected aborted journal
[   30.785259] EXT4-fs (mmcblk1p2): Remounting filesystem read-only
[   31.370716] EXT4-fs error (device mmcblk1p2):
ext4_find_entry:1309:
inode #2490369: comm udevd: reading directory lblock 0
[   31.382485] EXT4-fs error (device mmcblk1p2):
ext4_find_entry:1309:
inode #1048577: comm udevd: reading directory lblock 0

[analysis]
In system resume path, mmc_sd_resume() is failed with error code -123
because at that time SD card is still not ready on mb86s7x platforms.

 So why does it fail? It shouldn't!

 I get the impression that you are solving this in the wrong way.

Hi Uffe,
On mb86s7x EVB, power for SD card is completely removed when entering
STR suspend mode (i.e., echo mem  /sys/power/state). When system
starts to resume, it turns on the power for SD card again. However, It
take
longer time (e.g., 600ms) to get the power ready.
This is why mmc_sd_resume() failed with error code -123. At that time
point,
power for SD card is not ready yet.

At first we fixed it by a simple method of using
SDHCI_QUIRK_DELAY_AFTER_POWER:

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 169e17d..ed28896 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1283,7 +1283,7 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned char mode,
 * they can apply clock after applying power
 */
if (host-quirks  SDHCI_QUIRK_DELAY_AFTER_POWER)
-   mdelay(10);
+   mdelay(600);
}

If you can't model the power to the card through a regulator, this is what you 
need to do.


if (host-vmmc) {

However, we found it blocks the system resume path. It can slow down
system resume and also booting.
Therefore, we would like to resume SD card manually and asynchronously
by host controller driver itself. Thus system resume path is not
blocked.

That is accomplished by using MMC_CAP_RUNTIME_RESUME.

Kind regards
Uffe


Thanks a lot for your review!


Best regards,
Vincent Yang


 Kind regards
 Uffe


[solution]
In order to not blocking system resume path, this patch just sets a
flag
MMC_BUSRESUME_MANUAL_RESUME when this error happened, and then host
controller
driver can understand it by this flag. Then host controller driver
have
to
resume SD card manually and asynchronously.

Signed-off-by: Vincent Yang vincent.y...@tw.fujitsu.com
---
 drivers/mmc/core/core.c  |  4 ++
 drivers/mmc/core/sd.c|  4 ++
drivers/mmc/host/sdhci_f_sdh30.c | 89

 include/linux/mmc/host.h | 14 +++
 4 files changed, 111 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 764af63..51fce49 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2648,6 +2648,10 @@ int mmc_pm_notify(struct notifier_block
*notify_block,
   case PM_POST_RESTORE:

   spin_lock_irqsave(host-lock, flags);
+  if (mmc_bus_manual_resume(host)) {
+  spin_unlock_irqrestore(host-lock, flags);
+  break;
+  }
   host-rescan_disable = 0;
   spin_unlock_irqrestore(host-lock, flags

Re: [RFC PATCH v2 6/6] mmc: core: add manual resume capability

[Ulf Hansson]

On 26 juni 2014 08:23:32 CEST, Vincent Yang vincent.yang.fuji...@gmail.com 
wrote:
This patch adds manual resume for some embedded platforms with rootfs
stored in SD card. It references CONFIG_MMC_BLOCK_DEFERRED_RESUME in
kernel 3.10. It lets host controller driver to manually handle resume
by itself.

[symptom]
This issue is found on mb86s7x platforms with rootfs stored in SD card.
It failed to resume form STR suspend mode because SD card cannot be
ready
in time. It take longer time (e.g., 600ms) to be ready for access.
The error log looks like below:

root@localhost:~# echo mem  /sys/power/state
[   30.441974] SUSPEND

SCB Firmware : Category 01 Version 02.03 Rev. 00_
Config   : (no configuration)
root@localhost:~# [   30.702976] Buffer I/O error on device mmcblk1p2,
logical block 31349
[   30.709678] Buffer I/O error on device mmcblk1p2, logical block
168073
[   30.716220] Buffer I/O error on device mmcblk1p2, logical block
168074
[   30.722759] Buffer I/O error on device mmcblk1p2, logical block
168075
[   30.729456] Buffer I/O error on device mmcblk1p2, logical block
31349
[   30.735916] Buffer I/O error on device mmcblk1p2, logical block
31350
[   30.742370] Buffer I/O error on device mmcblk1p2, logical block
31351
[   30.749025] Buffer I/O error on device mmcblk1p2, logical block
168075
[   30.755657] Buffer I/O error on device mmcblk1p2, logical block
31351
[   30.763130] Aborting journal on device mmcblk1p2-8.
[   30.768060] JBD2: Error -5 detected when updating journal superblock
for mmcblk1p2-8.
[   30.776085] EXT4-fs error (device mmcblk1p2):
ext4_journal_check_start:56: Detected aborted journal
[   30.785259] EXT4-fs (mmcblk1p2): Remounting filesystem read-only
[   31.370716] EXT4-fs error (device mmcblk1p2): ext4_find_entry:1309:
inode #2490369: comm udevd: reading directory lblock 0
[   31.382485] EXT4-fs error (device mmcblk1p2): ext4_find_entry:1309:
inode #1048577: comm udevd: reading directory lblock 0

[analysis]
In system resume path, mmc_sd_resume() is failed with error code -123
because at that time SD card is still not ready on mb86s7x platforms.

So why does it fail? It shouldn't!

I get the impression that you are solving this in the wrong way.

Kind regards
Uffe


[solution]
In order to not blocking system resume path, this patch just sets a
flag
MMC_BUSRESUME_MANUAL_RESUME when this error happened, and then host
controller
driver can understand it by this flag. Then host controller driver have
to
resume SD card manually and asynchronously.

Signed-off-by: Vincent Yang vincent.y...@tw.fujitsu.com
---
 drivers/mmc/core/core.c  |  4 ++
 drivers/mmc/core/sd.c|  4 ++
drivers/mmc/host/sdhci_f_sdh30.c | 89

 include/linux/mmc/host.h | 14 +++
 4 files changed, 111 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 764af63..51fce49 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2648,6 +2648,10 @@ int mmc_pm_notify(struct notifier_block
*notify_block,
   case PM_POST_RESTORE:
 
   spin_lock_irqsave(host-lock, flags);
+  if (mmc_bus_manual_resume(host)) {
+  spin_unlock_irqrestore(host-lock, flags);
+  break;
+  }
   host-rescan_disable = 0;
   spin_unlock_irqrestore(host-lock, flags);
   _mmc_detect_change(host, 0, false);
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 0c44510..859390d 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -1133,6 +1133,10 @@ static int mmc_sd_resume(struct mmc_host *host)
 
   if (!(host-caps  MMC_CAP_RUNTIME_RESUME)) {
   err = _mmc_sd_resume(host);
+  if ((host-caps2  MMC_CAP2_MANUAL_RESUME)  err)
+  mmc_set_bus_resume_policy(host, 1);
+  else
+  mmc_set_bus_resume_policy(host, 0);
   pm_runtime_set_active(host-card-dev);
   pm_runtime_mark_last_busy(host-card-dev);
   }
diff --git a/drivers/mmc/host/sdhci_f_sdh30.c
b/drivers/mmc/host/sdhci_f_sdh30.c
index 6fae509..67bcff2 100644
--- a/drivers/mmc/host/sdhci_f_sdh30.c
+++ b/drivers/mmc/host/sdhci_f_sdh30.c
@@ -30,6 +30,12 @@
 #include ../core/core.h
 
 #define DRIVER_NAME f_sdh30
+#define RESUME_WAIT_COUNT 100
+#define RESUME_WAIT_TIME  50
+#define RESUME_WAIT_JIFFIES   msecs_to_jiffies(RESUME_DETECT_TIME)
+#define RESUME_DETECT_COUNT   16
+#define RESUME_DETECT_TIME50
+#define RESUME_DETECT_JIFFIES msecs_to_jiffies(RESUME_DETECT_TIME)
 
 
 struct f_sdhost_priv {
@@ -38,8 +44,59 @@ struct f_sdhost_priv {
   int gpio_select_1v8;
   u32 vendor_hs200;
   struct device *dev;
+  unsigned int quirks;/* Deviations from spec. */
+
+/* retry to detect mmc device when resume */
+#define F_SDH30_QUIRK_RESUME_DETECT_RETRY (10)
+
+  struct workqueue_struct *resume_detect_wq;
+  

Re: [PATCH 23/38] mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function

[Ulf Hansson]

On 16 June 2014 12:46, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
 @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
 struct mmc_ios *ios)
   host-ops-set_clock(host, host-clock);
   }

 - if (host-ops-set_uhs_signaling)
 - host-ops-set_uhs_signaling(host, ios-timing);
 - else {
 - ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
 - /* Select Bus Speed Mode for host */
 - ctrl_2 = ~SDHCI_CTRL_UHS_MASK;
 - if ((ios-timing == MMC_TIMING_MMC_HS200) ||
 - (ios-timing == MMC_TIMING_UHS_SDR104))
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
 - else if (ios-timing == MMC_TIMING_UHS_SDR12)
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
 - else if (ios-timing == MMC_TIMING_UHS_SDR25)
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
 - else if (ios-timing == MMC_TIMING_UHS_SDR50)
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
 - else if (ios-timing == MMC_TIMING_UHS_DDR50)
 - ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
 - sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
 - }
 + host-ops-set_uhs_signaling(host, ios-timing);

   if (!(host-quirks2  SDHCI_QUIRK2_PRESET_VALUE_BROKEN) 
   ((ios-timing == MMC_TIMING_UHS_SDR12) ||

 Whoever decided to poorly pick these patches up against my will has
 slightly messed this patch up - whereas my original patch left the
 code correctly formatted, when whoever applied this patch did so, they
 left an additional blank line in the above.

Hi Russell,

We kindly pinged you several times asking for your state and for the
PR, but I suppose you were just too busy. Your PR were kind of
blocking patches for sdhci, if you remember.

Anyway, we did get some folks to test the patches and was thus fairly
confident that we could merge them. Chris asked me to try to collect
them in a PR for him, so I did. Sorry if I managed to screw some
things up, there were several conflicts and actual regressions, which
I tried to take care of.

The mmc people were also very helping in sending patches to fixup
related regressions, immediately after we merged your patchset. Thus
together I think we managed to pull it off.


 The other thing I'd ask is that the MMC people learn C precedence
 rules, and realise that it's not necessary (and actively harmful)
 to add additional parenthesis around simple if() conditions.  Testing
 for timing being one of two values does not need anything more than
 one set of parenthesis - it does not need if ((a == b) || (a == c)) -
 if (a == b || a == c) does just fine, and is less confusing when
 encountering more complex statements, such as:

 if a == b) || (a == c))  ((d  a) || (d  c))) || (z == f))

 compared with:

 if (((a == b || a == c)  (d  a || d  c)) || z == f)

 With the former style, I normally end up having to pull the file into
 the editor, and rewrite the damned statement to work out what the
 grouping is, because the excessive use of parenthesis is detrimental to
 readability.  Don't do it.  Learn the C precedence rules and keep code
 readable.

Sure, we will adopt.

Please, feel free to send a patch to fixup my misstake. I will happily apply it.

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

Re: [PATCH 23/38] mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function

[Ulf Hansson]

On 16 June 2014 14:17, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 16 June 2014 12:46, Russell King - ARM Linux li...@arm.linux.org.uk 
 wrote:
 On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
 @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host 
 *host, struct mmc_ios *ios)
   host-ops-set_clock(host, host-clock);
   }

 - if (host-ops-set_uhs_signaling)
 - host-ops-set_uhs_signaling(host, ios-timing);
 - else {
 - ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
 - /* Select Bus Speed Mode for host */
 - ctrl_2 = ~SDHCI_CTRL_UHS_MASK;
 - if ((ios-timing == MMC_TIMING_MMC_HS200) ||
 - (ios-timing == MMC_TIMING_UHS_SDR104))
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
 - else if (ios-timing == MMC_TIMING_UHS_SDR12)
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
 - else if (ios-timing == MMC_TIMING_UHS_SDR25)
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
 - else if (ios-timing == MMC_TIMING_UHS_SDR50)
 - ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
 - else if (ios-timing == MMC_TIMING_UHS_DDR50)
 - ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
 - sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
 - }
 + host-ops-set_uhs_signaling(host, ios-timing);

   if (!(host-quirks2  SDHCI_QUIRK2_PRESET_VALUE_BROKEN) 
   ((ios-timing == MMC_TIMING_UHS_SDR12) ||

 Whoever decided to poorly pick these patches up against my will has
 slightly messed this patch up - whereas my original patch left the
 code correctly formatted, when whoever applied this patch did so, they
 left an additional blank line in the above.


[snip]

 Please, feel free to send a patch to fixup my misstake. I will happily apply 
 it.

I had a second look to fix it up myself, but I just can't find that
your patch was different than the one I applied (beside the conflict I
resolved).

If you do find any other issue regarding the patches in this patchset
- please let me know and I will try to help.

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

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 25 April 2014 11:03, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
 On 24 April 2014 12:57, Russell King - ARM Linux li...@arm.linux.org.uk 
 wrote:
  This is nothing new or unexpected - it was last posted back in February,
  and I elected that it should be held off until after the last merge
  window.
 
  Unfortunately, I didn't have time to post it immediately after the merge
  window closed, partly because it needed to be rebased on top of tglx's
  IRQ changes on which it depends.  I was carrying those as separate commits
  to the ones Thomas was carrying in his tree - and in the event, Thomas had
  modified his patches slightly between sending me copies of them and the
  versions he sent during the merge window.

 Okay, so let's keep up the frequency here then. I only had some minor
 comments, please fix them and send a v2.

 Right, so I've updated the patches, and added one ack to one patch.
 That seems insufficient to me - the only platform these have been
 tested on is iMX6, which is sdhci-esdhc-imx.c.

 They _really_ need testing elsewhere too.  Or is the plan to merge
 them and then see about getting people to test them and fix them up
 afterwards?

I was hoping people could start doing tests, before Chris actually
decided to pull them in. Now, if that doesn't happen, we could just
merge them, as you say, and thus we have to fix potential problems
afterwards. I would expect you to help out if problem occurs.

If we decide to not merge in a while, I am not sure how long we could
prevent other sdhci patches from being merged. I guess Chris will have
to take the final call.


 --
 FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
 improving, and getting towards what was expected from it.
 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 25 April 2014 13:20, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 On Fri, Apr 25, 2014 at 01:18:28PM +0200, Ulf Hansson wrote:
 On 25 April 2014 11:03, Russell King - ARM Linux li...@arm.linux.org.uk 
 wrote:
  On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
  On 24 April 2014 12:57, Russell King - ARM Linux li...@arm.linux.org.uk 
  wrote:
   This is nothing new or unexpected - it was last posted back in February,
   and I elected that it should be held off until after the last merge
   window.
  
   Unfortunately, I didn't have time to post it immediately after the merge
   window closed, partly because it needed to be rebased on top of tglx's
   IRQ changes on which it depends.  I was carrying those as separate 
   commits
   to the ones Thomas was carrying in his tree - and in the event, Thomas 
   had
   modified his patches slightly between sending me copies of them and the
   versions he sent during the merge window.
 
  Okay, so let's keep up the frequency here then. I only had some minor
  comments, please fix them and send a v2.
 
  Right, so I've updated the patches, and added one ack to one patch.
  That seems insufficient to me - the only platform these have been
  tested on is iMX6, which is sdhci-esdhc-imx.c.
 
  They _really_ need testing elsewhere too.  Or is the plan to merge
  them and then see about getting people to test them and fix them up
  afterwards?

 I was hoping people could start doing tests, before Chris actually
 decided to pull them in. Now, if that doesn't happen, we could just
 merge them, as you say, and thus we have to fix potential problems
 afterwards. I would expect you to help out if problem occurs.

 If we decide to not merge in a while, I am not sure how long we could
 prevent other sdhci patches from being merged. I guess Chris will have
 to take the final call.

 Or we just drop them for yet another cycle and show how mainline kernel
 development sucks, why getting stuff into mainline is utterly painful,
 and why using vendor kernels is /soo/ much better than this crap.

Dropping them is too me a bad option and I really don't think that
should be needed.

I would like to encourage people to help out with testing and I
suppose we have to give this at least some time.

Anyway, post your new version. I will create the pull request based on that.


 --
 FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
 improving, and getting towards what was expected from it.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 23 April 2014 20:55, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 All,

 This is where I'm at with trying to clean up the SDHCI mess, and sort out
 issues I've noticed when trying to get UHS support working on CuBoxes.
 This is my full patch set, but I recommend not applying patch 37 as there
 appears to be a hardware issue preventing it working reliably.

 In any case, patches 0-33 inclusive are the SDHCI clean up, based against
 v3.15-rc1.  Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
 those, and 38 adds the Broadcom Wifi and BT support for CuBox.

 The questions over how to handle these devices were never properly settled,
 so I recommend against merging patch 34 onwards.  As for the rest, I'm not
 planning on any further work, so it may be a good idea for people to
 consider testing them with a view to getting them merged.


I have looked though the patches up until patch 33 and this is clearly
a nice piece of clean-up /fixes work for sdhci. Besides my minor
comments per patch, I don't have any objections code-review wise to
proceed merging them.

I have also tried to applied them on Chris' mmc-next branch,
unfortunate it fails at patch 23, so it would be nice to get a
re-based patchset for the mmc-next branch.

Kind regards
Ulf Hansson

  Documentation/devicetree/bindings/mmc/mmc.txt |  11 +
  arch/arm/boot/dts/imx6qdl-cubox-i.dtsi|  34 +-
  arch/arm/boot/dts/imx6qdl-microsom.dtsi   |  98 
  drivers/mmc/core/core.c   |  42 ++
  drivers/mmc/core/host.c   |  68 +++
  drivers/mmc/core/sdio_irq.c   |  41 +-
  drivers/mmc/host/Kconfig  |  63 +--
  drivers/mmc/host/dw_mmc.c |   2 +
  drivers/mmc/host/sdhci-acpi.c |   8 +
  drivers/mmc/host/sdhci-bcm-kona.c |   4 +
  drivers/mmc/host/sdhci-bcm2835.c  |   4 +
  drivers/mmc/host/sdhci-cns3xxx.c  |  13 +-
  drivers/mmc/host/sdhci-dove.c |   4 +
  drivers/mmc/host/sdhci-esdhc-imx.c|  82 +--
  drivers/mmc/host/sdhci-esdhc.h|   4 +-
  drivers/mmc/host/sdhci-of-arasan.c|   4 +
  drivers/mmc/host/sdhci-of-esdhc.c |  70 ++-
  drivers/mmc/host/sdhci-of-hlwd.c  |   4 +
  drivers/mmc/host/sdhci-pci.c  |   9 +-
  drivers/mmc/host/sdhci-pltfm.c|   4 +
  drivers/mmc/host/sdhci-pxav2.c|  14 +-
  drivers/mmc/host/sdhci-pxav3.c|  13 +-
  drivers/mmc/host/sdhci-s3c.c  |  36 +-
  drivers/mmc/host/sdhci-sirf.c |   4 +
  drivers/mmc/host/sdhci-spear.c|   5 +-
  drivers/mmc/host/sdhci-tegra.c|  27 +-
  drivers/mmc/host/sdhci.c  | 728 
 +-
  drivers/mmc/host/sdhci.h  |  20 +-
  include/linux/mmc/host.h  |   8 +
  include/linux/mmc/sdhci.h |  15 +-
  30 files changed, 885 insertions(+), 554 deletions(-)


 --
 FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
 improving, and getting towards what was expected from it.
 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 24 April 2014 12:17, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
 I have looked though the patches up until patch 33 and this is clearly
 a nice piece of clean-up /fixes work for sdhci. Besides my minor
 comments per patch, I don't have any objections code-review wise to
 proceed merging them.

 I have also tried to applied them on Chris' mmc-next branch,
 unfortunate it fails at patch 23, so it would be nice to get a
 re-based patchset for the mmc-next branch.

 I /could/ rebase it but then I wouldn't be able to produce the patch
 sets/patches for others [*] (such as the Novena project) to derive
 their kernel tree from my iMX6 patch set.

 What I'd prefer is to keep the patch set intact, and provide Chris
 with a pull request for it up to patch 33, which would need a
 conflict fixed - and this would mean that I can be sure that what
 I'm testing, and what I'm distributing is what Chris will also be
 submitting.

Whether there are more than one conflict, I don't know. I just stopped
at patch 23.

Moreover, there are other patches for sdhci that have been posted and
being discussed. In principle, we then need to put all these on hold
to prevent further conflicts. I guess that doable, as long as we don't
to that for too long. Maybe Chris have some more thoughts how to
handle this!?

Kind regards
Ulf Hansson


 * - this currently stands at 230 patches in all - mmc + l2c + fec +
 imx-drm + other iMX6 changes.

 --
 FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
 improving, and getting towards what was expected from it.
 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 24 April 2014 12:57, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
 On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
 On 24 April 2014 12:17, Russell King - ARM Linux li...@arm.linux.org.uk 
 wrote:
  On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
  I have looked though the patches up until patch 33 and this is clearly
  a nice piece of clean-up /fixes work for sdhci. Besides my minor
  comments per patch, I don't have any objections code-review wise to
  proceed merging them.
 
  I have also tried to applied them on Chris' mmc-next branch,
  unfortunate it fails at patch 23, so it would be nice to get a
  re-based patchset for the mmc-next branch.
 
  I /could/ rebase it but then I wouldn't be able to produce the patch
  sets/patches for others [*] (such as the Novena project) to derive
  their kernel tree from my iMX6 patch set.
 
  What I'd prefer is to keep the patch set intact, and provide Chris
  with a pull request for it up to patch 33, which would need a
  conflict fixed - and this would mean that I can be sure that what
  I'm testing, and what I'm distributing is what Chris will also be
  submitting.

 Whether there are more than one conflict, I don't know. I just stopped
 at patch 23.

 Moreover, there are other patches for sdhci that have been posted and
 being discussed. In principle, we then need to put all these on hold
 to prevent further conflicts. I guess that doable, as long as we don't
 to that for too long. Maybe Chris have some more thoughts how to
 handle this!?

 This is nothing new or unexpected - it was last posted back in February,
 and I elected that it should be held off until after the last merge
 window.

 Unfortunately, I didn't have time to post it immediately after the merge
 window closed, partly because it needed to be rebased on top of tglx's
 IRQ changes on which it depends.  I was carrying those as separate commits
 to the ones Thomas was carrying in his tree - and in the event, Thomas had
 modified his patches slightly between sending me copies of them and the
 versions he sent during the merge window.

Okay, so let's keep up the frequency here then. I only had some minor
comments, please fix them and send a v2.

How about if I resolve the conflicts and send the pull request to
Chris? I suppose it makes life a bit easier for Chris.

Kind regards
Ulf Hansson


 --
 FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
 improving, and getting towards what was expected from it.
 --
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev