Re: [PATCH] genirq: reduce irqdebug bouncing cachelines

[Cédric Le Goater]

On 4/13/21 10:24 PM, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 14:16, Cédric Le Goater wrote:
>>>> We could test irq_settings_no_debug() directly under handle_nested_irq() 
>>>> and handle_irq_event_percpu() to avoid calling note_interrupt(), just 
>>>> like we do for noirqdebug.
>>>
>>> We can do that, but then we should not just make it:
>>>
>>>if (!irqnodebug && !irq_settings_no_debug(desc))
>>> note_interrupt(...);
>>>
>>> Instead have only one condition:
>>>
>>>if (!irq_settings_no_debug(desc))
>>> note_interrupt(...);
>>>
>>> See the uncompiled delta patch below.
>>
>> I merged this second part with the first and gave IRQF_NO_DEBUG a try 
>> on P8 and P9 systems and all looked fine. I should send both patches 
>> after IRQF_NO_AUTOEN is merged in mainline. 
> 
> Does having that NODEBUG flag set on the IPI irqs make a measurable
> difference or is it just too small to matter?

It does not add much benefits on the 2s and 4s systems but I will give it 
a try on bigger ones when I can grab them. Then we can decide if it is 
worth merging. 

Thanks,

C.

Re: [PATCH] genirq: reduce irqdebug bouncing cachelines

[Cédric Le Goater]

Thomas,

>> We could test irq_settings_no_debug() directly under handle_nested_irq() 
>> and handle_irq_event_percpu() to avoid calling note_interrupt(), just 
>> like we do for noirqdebug.
> 
> We can do that, but then we should not just make it:
> 
>if (!irqnodebug && !irq_settings_no_debug(desc))
>   note_interrupt(...);
> 
> Instead have only one condition:
> 
>if (!irq_settings_no_debug(desc))
>   note_interrupt(...);
> 
> See the uncompiled delta patch below.

I merged this second part with the first and gave IRQF_NO_DEBUG a try 
on P8 and P9 systems and all looked fine. I should send both patches 
after IRQF_NO_AUTOEN is merged in mainline. 

Thanks,

C.

Re: [PATCH] genirq: reduce irqdebug bouncing cachelines

[Cédric Le Goater]

Hello,

On 4/10/21 1:58 PM, Thomas Gleixner wrote:
> Nicholas,
> 
> On Fri, Apr 02 2021 at 23:20, Nicholas Piggin wrote:
>> note_interrupt increments desc->irq_count for each interrupt even for
>> percpu interrupt handlers, even when they are handled successfully. This
>> causes cacheline bouncing and limits scalability.
>>
>> Instead of incrementing irq_count every time, only start incrementing it
>> after seeing an unhandled irq, which should avoid the cache line
>> bouncing in the common path.
>>
>> This actually should give better consistency in handling misbehaving
>> irqs too, because instead of the first unhandled irq arriving at an
>> arbitrary point in the irq_count cycle, its arrival will begin the
>> irq_count cycle.
> 
> I've applied that because it makes sense in general, but I think the whole
> call to note_interrupt() can be avoided or return early when interrupts
> would be marked accordingly. For IPI handlers which always return
> HANDLED the whole procedure is pretty pointless to begin with.
> 
> Something like the completely untested below.
> 
> Thanks,
> 
> tglx
> ---
>  include/linux/interrupt.h |3 +++
>  include/linux/irq.h   |2 ++
>  kernel/irq/manage.c   |2 ++
>  kernel/irq/settings.h |   12 
>  kernel/irq/spurious.c |2 +-
>  5 files changed, 20 insertions(+), 1 deletion(-)
> 
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -64,6 +64,8 @@
>   * IRQF_NO_AUTOEN - Don't enable IRQ or NMI automatically when users request 
> it.
>   *Users will enable it explicitly by enable_irq() or 
> enable_nmi()
>   *later.
> + * IRQF_NO_DEBUG - Exclude from runnaway detection for IPI and similar 
> handlers,
> + *  depends on IRQF_PERCPU.
>   */
>  #define IRQF_SHARED  0x0080
>  #define IRQF_PROBE_SHARED0x0100
> @@ -78,6 +80,7 @@
>  #define IRQF_EARLY_RESUME0x0002
>  #define IRQF_COND_SUSPEND0x0004
>  #define IRQF_NO_AUTOEN   0x0008
> +#define IRQF_NO_DEBUG0x0010
>  
>  #define IRQF_TIMER   (__IRQF_TIMER | IRQF_NO_SUSPEND | 
> IRQF_NO_THREAD)
>  
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -72,6 +72,7 @@ enum irqchip_irq_state;
>   * mechanism and from core side polling.
>   * IRQ_DISABLE_UNLAZY- Disable lazy irq disable
>   * IRQ_HIDDEN- Don't show up in /proc/interrupts
> + * IRQ_NO_DEBUG  - Exclude from note_interrupt() 
> debugging
>   */
>  enum {
>   IRQ_TYPE_NONE   = 0x,
> @@ -99,6 +100,7 @@ enum {
>   IRQ_IS_POLLED   = (1 << 18),
>   IRQ_DISABLE_UNLAZY  = (1 << 19),
>   IRQ_HIDDEN  = (1 << 20),
> + IRQ_NO_DEBUG= (1 << 21),
>  };
>  
>  #define IRQF_MODIFY_MASK \
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1682,6 +1682,8 @@ static int
>   if (new->flags & IRQF_PERCPU) {
>   irqd_set(>irq_data, IRQD_PER_CPU);
>   irq_settings_set_per_cpu(desc);
> + if (new->flags & IRQF_NO_DEBUG)
> + irq_settings_set_no_debug(desc);
>   }
>  
>   if (new->flags & IRQF_ONESHOT)
> --- a/kernel/irq/settings.h
> +++ b/kernel/irq/settings.h
> @@ -18,6 +18,7 @@ enum {
>   _IRQ_IS_POLLED  = IRQ_IS_POLLED,
>   _IRQ_DISABLE_UNLAZY = IRQ_DISABLE_UNLAZY,
>   _IRQ_HIDDEN = IRQ_HIDDEN,
> + _IRQ_NO_DEBUG   = IRQ_NO_DEBUG,
>   _IRQF_MODIFY_MASK   = IRQF_MODIFY_MASK,
>  };
>  
> @@ -33,6 +34,7 @@ enum {
>  #define IRQ_IS_POLLEDGOT_YOU_MORON
>  #define IRQ_DISABLE_UNLAZY   GOT_YOU_MORON
>  #define IRQ_HIDDEN   GOT_YOU_MORON
> +#define IRQ_NO_DEBUG GOT_YOU_MORON
>  #undef IRQF_MODIFY_MASK
>  #define IRQF_MODIFY_MASK GOT_YOU_MORON
>  
> @@ -174,3 +176,13 @@ static inline bool irq_settings_is_hidde
>  {
>   return desc->status_use_accessors & _IRQ_HIDDEN;
>  }
> +
> +static inline void irq_settings_set_no_debug(struct irq_desc *desc)
> +{
> + desc->status_use_accessors |= _IRQ_NO_DEBUG;
> +}
> +
> +static inline bool irq_settings_no_debug(struct irq_desc *desc)
> +{
> + return desc->status_use_accessors & _IRQ_NO_DEBUG;
> +}
> --- a/kernel/irq/spurious.c
> +++ b/kernel/irq/spurious.c
> @@ -274,7 +274,7 @@ void note_interrupt(struct irq_desc *des
>   unsigned int irq;
>  
>   if (desc->istate & IRQS_POLL_INPROGRESS ||
> - irq_settings_is_polled(desc))
> + irq_settings_is_polled(desc) | irq_settings_no_debug(desc))

Shouldn't it be '||' instead  ? 

>   return;
>  
>   if (bad_action_ret(action_ret)) {
> 

We could test irq_settings_no_debug() directly under handle_nested_irq() 
and handle_irq_event_percpu() to avoid calling note_interrupt(), just 
like we do for noirqdebug.

Re: [PATCH] powerpc: define the variable 'uaccess_flush' as static

[Cédric Le Goater]

On 3/12/21 12:06 PM, He Ying wrote:
> The variable 'uaccess_fulsh' is not referenced outside the file. Perhaps we
> should define it as static to avoid the warning as follows:
> 
> arch/powerpc/kernel/setup_64.c:953:6: warning: symbol 'uaccess_flush'
> was not declared. Should it be static?
> 
> Reported-by: Hulk Robot 
> Signed-off-by: He Ying 
> ---
>  arch/powerpc/kernel/setup_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 560ed8b975e7..22aca271496b 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -950,7 +950,7 @@ static bool no_entry_flush;
>  static bool no_uaccess_flush;
>  bool rfi_flush;
>  bool entry_flush;

I think this is the case also for entry_flush. compiling with W=1 will tell you 
more.

Thanks,

C. 

> -bool uaccess_flush;
> +static bool uaccess_flush;
>  DEFINE_STATIC_KEY_FALSE(uaccess_flush_key);
>  EXPORT_SYMBOL(uaccess_flush_key);
>  
> 

Re: [PATCH] arch/powerpc/include/asm/book3s/64/: remove duplicate include in mmu-hash.h

[Cédric Le Goater]

On 3/4/21 3:42 AM, menglong8.d...@gmail.com wrote:
> From: Zhang Yunkai 
> 
> 'asm/bug.h' included in 'arch/powerpc/include/asm/book3s/64/mmu-hash.h'
> is duplicated.It is also included in the 12th line.
> 
> Signed-off-by: Zhang Yunkai 

Reviewed-by: Cédric Le Goater 

> ---
>  arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
> b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> index f911bdb68d8b..3004f3323144 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> @@ -18,7 +18,6 @@
>   * complete pgtable.h but only a portion of it.
>   */
>  #include 
> -#include 
>  #include 
>  #include 
>  
> 

Re: arch/powerpc/sysdev/xive/common.c:1614 xive_debug_show_irq() warn: variable dereferenced before check 'd' (see line 1596)

[Cédric Le Goater]

On 2/27/21 4:03 PM, Dan Carpenter wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   3fb6d0e00efc958d01c2f109c8453033a2d96796
> commit: 930914b7d528fc6b0249bffc00564100bcf6ef75 powerpc/xive: Add a debugfs 
> file to dump internal XIVE state
> config: powerpc64-randconfig-m031-20210226 (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 
> 
> New smatch warnings:
> arch/powerpc/sysdev/xive/common.c:1614 xive_debug_show_irq() warn: variable 
> dereferenced before check 'd' (see line 1596)

This should be addressed by patch : 

  
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210209161936.377760-5-...@kaod.org/

> Old smatch warnings:
> arch/powerpc/sysdev/xive/common.c:280 xmon_xive_get_irq_config() warn: 
> variable dereferenced before check 'd' (see line 262)
This one needs a very similar fix which can come as a followup.

Thanks,

C.

> vim +/d +1614 arch/powerpc/sysdev/xive/common.c
> 
> 930914b7d528fc Cédric Le Goater 2020-03-06  1594  void 
> xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
> 930914b7d528fc Cédric Le Goater 2020-03-06  1595  {
> 930914b7d528fc Cédric Le Goater 2020-03-06 @1596  struct irq_chip *chip = 
> irq_data_get_irq_chip(d);
>   
>         ^
> Dereferenced inside function
> 
> 930914b7d528fc Cédric Le Goater 2020-03-06  1597  int rc;
> 930914b7d528fc Cédric Le Goater 2020-03-06  1598  u32 target;
> 930914b7d528fc Cédric Le Goater 2020-03-06  1599  u8 prio;
> 930914b7d528fc Cédric Le Goater 2020-03-06  1600      u32 lirq;
> 930914b7d528fc Cédric Le Goater 2020-03-06  1601  
> 930914b7d528fc Cédric Le Goater 2020-03-06  1602  if (!is_xive_irq(chip))
> 930914b7d528fc Cédric Le Goater 2020-03-06  1603  return;
> 930914b7d528fc Cédric Le Goater 2020-03-06  1604  
> 930914b7d528fc Cédric Le Goater 2020-03-06  1605  rc = 
> xive_ops->get_irq_config(hw_irq, , , );
> 930914b7d528fc Cédric Le Goater 2020-03-06  1606  if (rc) {
> 930914b7d528fc Cédric Le Goater 2020-03-06  1607  seq_printf(m, 
> "IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
> 930914b7d528fc Cédric Le Goater 2020-03-06  1608  return;
> 930914b7d528fc Cédric Le Goater 2020-03-06  1609  }
> 930914b7d528fc Cédric Le Goater 2020-03-06  1610  
> 930914b7d528fc Cédric Le Goater 2020-03-06  1611  seq_printf(m, "IRQ 
> 0x%08x : target=0x%x prio=%02x lirq=0x%x ",
> 930914b7d528fc Cédric Le Goater 2020-03-06  1612 hw_irq, 
> target, prio, lirq);
> 930914b7d528fc Cédric Le Goater 2020-03-06  1613  
> 930914b7d528fc Cédric Le Goater 2020-03-06 @1614  if (d) {
>     ^^^^
> Checked too late.
> 
> 930914b7d528fc Cédric Le Goater 2020-03-06  1615  struct 
> xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> 930914b7d528fc Cédric Le Goater 2020-03-06  1616  u64 val = 
> xive_esb_read(xd, XIVE_ESB_GET);
> 930914b7d528fc Cédric Le Goater 2020-03-06  1617  
> 930914b7d528fc Cédric Le Goater 2020-03-06  1618          seq_printf(m, 
> "flags=%c%c%c PQ=%c%c",
> 930914b7d528fc Cédric Le Goater 2020-03-06  1619         
> xd->flags & XIVE_IRQ_FLAG_STORE_EOI ? 'S' : ' ',
> 930914b7d528fc Cédric Le Goater 2020-03-06  1620 
> xd->flags & XIVE_IRQ_FLAG_LSI ? 'L' : ' ',
> 930914b7d528fc Cédric Le Goater 2020-03-06  1621 
> xd->flags & XIVE_IRQ_FLAG_H_INT_ESB ? 'H' : ' ',
> 930914b7d528fc Cédric Le Goater 2020-03-06  1622     val 
> & XIVE_ESB_VAL_P ? 'P' : '-',
> 930914b7d528fc Cédric Le Goater 2020-03-06  1623 val 
> & XIVE_ESB_VAL_Q ? 'Q' : '-');
> 930914b7d528fc Cédric Le Goater 2020-03-06  1624  }
> 930914b7d528fc Cédric Le Goater 2020-03-06  1625  seq_puts(m, "\n");
> 930914b7d528fc Cédric Le Goater 2020-03-06  1626  }
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> 

Re: arch/powerpc/sysdev/xive/common.c:279 xmon_xive_get_irq_config() warn: variable dereferenced before check 'd' (see line 261)

[Cédric Le Goater]

On 2/27/21 10:30 AM, Dan Carpenter wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   8b83369ddcb3fb9cab5c1088987ce477565bb630
> commit: 97ef275077932c65b1b8ec5022abd737a9fbf3e0 powerpc/xive: Fix xmon 
> support on the PowerNV platform
> config: powerpc64-randconfig-m031-20210226 (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 
> 
> smatch warnings:
> arch/powerpc/sysdev/xive/common.c:279 xmon_xive_get_irq_config() warn: 
> variable dereferenced before check 'd' (see line 261)

Yes. That's ugly :/

I would prefer to address this issue after the cleanup provided
by the patchset adding an IRQ domain for IPIs.

  http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=228762

Most of the mess comes from the XIVE IPI HW IRQ number which
hijacks IRQ number 0. It should be easier after this is fixed.

Thanks,

C. 

> vim +/d +279 arch/powerpc/sysdev/xive/common.c
> 
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  259  int 
> xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)
> b4868ff55d082bc Cédric Le Goater 2019-08-14  260  {
> 97ef275077932c6 Cédric Le Goater 2020-03-06 @261  struct irq_chip *chip = 
> irq_data_get_irq_chip(d);
>   
>             ^
> Dereferenced inside function
> 
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  262  int rc;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  263  u32 target;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  264  u8 prio;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  265      u32 lirq;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  266  
> 97ef275077932c6 Cédric Le Goater 2020-03-06  267  if (!is_xive_irq(chip))
> 97ef275077932c6 Cédric Le Goater 2020-03-06  268          return -EINVAL;
> 97ef275077932c6 Cédric Le Goater 2020-03-06  269  
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  270  rc = 
> xive_ops->get_irq_config(hw_irq, , , );
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  271  if (rc) {
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  272  
> xmon_printf("IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  273  return rc;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  274  }
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  275  
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  276  xmon_printf("IRQ 0x%08x 
> : target=0x%x prio=%02x lirq=0x%x ",
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  277  hw_irq, 
> target, prio, lirq);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  278  
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 @279  if (d) {
> ^^
> Checked too late
> 
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  280  struct 
> xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  281  u64 val = 
> xive_esb_read(xd, XIVE_ESB_GET);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  282  
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  283  
> xmon_printf("PQ=%c%c",
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  284  val 
> & XIVE_ESB_VAL_P ? 'P' : '-',
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  285  val 
> & XIVE_ESB_VAL_Q ? 'Q' : '-');
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  286  }
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  287  
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  288  xmon_printf("\n");
> 5896163f7f91c05 Cédric Le Goater 2019-09-10  289  return 0;
> b4868ff55d082bc Cédric Le Goater 2019-08-14  290  }
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> 

Re: [PATCH] powerpc/pseries: Don't enforce MSI affinity with kdump

[Cédric Le Goater]

On 2/12/21 5:41 PM, Greg Kurz wrote:
> Depending on the number of online CPUs in the original kernel, it is
> likely for CPU #0 to be offline in a kdump kernel. The associated IRQs
> in the affinity mappings provided by irq_create_affinity_masks() are
> thus not started by irq_startup(), as per-design with managed IRQs.
> 
> This can be a problem with multi-queue block devices driven by blk-mq :
> such a non-started IRQ is very likely paired with the single queue
> enforced by blk-mq during kdump (see blk_mq_alloc_tag_set()). This
> causes the device to remain silent and likely hangs the guest at
> some point.
> 
> This is a regression caused by commit 9ea69a55b3b9 ("powerpc/pseries:
> Pass MSI affinity to irq_create_mapping()"). Note that this only happens
> with the XIVE interrupt controller because XICS has a workaround to bypass
> affinity, which is activated during kdump with the "noirqdistrib" kernel
> parameter.
> 
> The issue comes from a combination of factors:
> - discrepancy between the number of queues detected by the multi-queue
>   block driver, that was used to create the MSI vectors, and the single
>   queue mode enforced later on by blk-mq because of kdump (i.e. keeping
>   all queues fixes the issue)
> - CPU#0 offline (i.e. kdump always succeed with CPU#0)
> 
> Given that I couldn't reproduce on x86, which seems to always have CPU#0
> online even during kdump, I'm not sure where this should be fixed. Hence
> going for another approach : fine-grained affinity is for performance
> and we don't really care about that during kdump. Simply revert to the
> previous working behavior of ignoring affinity masks in this case only.
> 
> Fixes: 9ea69a55b3b9 ("powerpc/pseries: Pass MSI affinity to 
> irq_create_mapping()")
> Cc: lviv...@redhat.com
> Cc: sta...@vger.kernel.org
> Signed-off-by: Greg Kurz 


Reviewed-by: Cédric Le Goater 

Thanks for tracking this issue. 

This layer needs a rework. Patches adding a MSI domain should be ready 
in a couple of releases. Hopefully. 

C. 

> ---
>  arch/powerpc/platforms/pseries/msi.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/msi.c 
> b/arch/powerpc/platforms/pseries/msi.c
> index b3ac2455faad..29d04b83288d 100644
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -458,8 +458,28 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int 
> nvec_in, int type)
>   return hwirq;
>   }
>  
> - virq = irq_create_mapping_affinity(NULL, hwirq,
> -entry->affinity);
> + /*
> +  * Depending on the number of online CPUs in the original
> +  * kernel, it is likely for CPU #0 to be offline in a kdump
> +  * kernel. The associated IRQs in the affinity mappings
> +  * provided by irq_create_affinity_masks() are thus not
> +  * started by irq_startup(), as per-design for managed IRQs.
> +  * This can be a problem with multi-queue block devices driven
> +  * by blk-mq : such a non-started IRQ is very likely paired
> +  * with the single queue enforced by blk-mq during kdump (see
> +  * blk_mq_alloc_tag_set()). This causes the device to remain
> +  * silent and likely hangs the guest at some point.
> +  *
> +  * We don't really care for fine-grained affinity when doing
> +  * kdump actually : simply ignore the pre-computed affinity
> +  * masks in this case and let the default mask with all CPUs
> +  * be used when creating the IRQ mappings.
> +  */
> + if (is_kdump_kernel())
> + virq = irq_create_mapping(NULL, hwirq);
> + else
> + virq = irq_create_mapping_affinity(NULL, hwirq,
> +entry->affinity);
>  
>   if (!virq) {
>   pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
> 

Re: [PATCH 3/5] powerpc/xive: remove unnecessary unmap_kernel_range

[Cédric Le Goater]

On 1/26/21 5:54 AM, Nicholas Piggin wrote:
> iounmap will remove ptes.
> 
> Cc: "Cédric Le Goater" 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Nicholas Piggin 

Looks good. 

Acked-by: Cédric Le Goater 

Thanks,

C. 

> ---
>  arch/powerpc/sysdev/xive/common.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/xive/common.c 
> b/arch/powerpc/sysdev/xive/common.c
> index 595310e056f4..d6c2069cc828 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -959,16 +959,12 @@ EXPORT_SYMBOL_GPL(is_xive_irq);
>  void xive_cleanup_irq_data(struct xive_irq_data *xd)
>  {
>   if (xd->eoi_mmio) {
> - unmap_kernel_range((unsigned long)xd->eoi_mmio,
> -1u << xd->esb_shift);
>   iounmap(xd->eoi_mmio);
>   if (xd->eoi_mmio == xd->trig_mmio)
>   xd->trig_mmio = NULL;
>   xd->eoi_mmio = NULL;
>   }
>   if (xd->trig_mmio) {
> - unmap_kernel_range((unsigned long)xd->trig_mmio,
> -1u << xd->esb_shift);
>   iounmap(xd->trig_mmio);
>   xd->trig_mmio = NULL;
>   }
> 

Re: [PATCH] KVM: PPC: Book3S HV: XIVE: Fix vCPU id sanity check

[Cédric Le Goater]

On 11/30/20 1:19 PM, Greg Kurz wrote:
> Commit 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size
> configurable") updated kvmppc_xive_vcpu_id_valid() in a way that
> allows userspace to trigger an assertion in skiboot and crash the host:
> 
> [  696.186248988,3] XIVE[ IC 08  ] eq_blk != vp_blk (0 vs. 1) for target 
> 0x438c/0
> [  696.186314757,0] Assert fail: hw/xive.c:2370:0
> [  696.186342458,0] Aborting!
> xive-kvCPU 0043 Backtrace:
>  S: 31e2b8f0 R: 30013840   .backtrace+0x48
>  S: 31e2b990 R: 3001b2d0   ._abort+0x4c
>  S: 31e2ba10 R: 3001b34c   .assert_fail+0x34
>  S: 31e2ba90 R: 30058984   .xive_eq_for_target.part.20+0xb0
>  S: 31e2bb40 R: 30059fdc   .xive_setup_silent_gather+0x2c
>  S: 31e2bc20 R: 3005a334   .opal_xive_set_vp_info+0x124
>  S: 31e2bd20 R: 300051a4   opal_entry+0x134
>  --- OPAL call token: 0x8a caller R1: 0xc01f28563850 ---
> 
> XIVE maintains the interrupt context state of non-dispatched vCPUs in
> an internal VP structure. We allocate a bunch of those on startup to
> accommodate all possible vCPUs. Each VP has an id, that we derive from
> the vCPU id for efficiency:
> 
> static inline u32 kvmppc_xive_vp(struct kvmppc_xive *xive, u32 server)
> {
>   return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
> }
> 
> The KVM XIVE device used to allocate KVM_MAX_VCPUS VPs. This was
> limitting the number of concurrent VMs because the VP space is
> limited on the HW. Since most of the time, VMs run with a lot less
> vCPUs, commit 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP
> block size configurable") gave the possibility for userspace to
> tune the size of the VP block through the KVM_DEV_XIVE_NR_SERVERS
> attribute.
> 
> The check in kvmppc_pack_vcpu_id() was changed from
> 
>   cpu < KVM_MAX_VCPUS * xive->kvm->arch.emul_smt_mode
> 
> to
> 
>   cpu < xive->nr_servers * xive->kvm->arch.emul_smt_mode
> 
> The previous check was based on the fact that the VP block had
> KVM_MAX_VCPUS entries and that kvmppc_pack_vcpu_id() guarantees
> that packed vCPU ids are below KVM_MAX_VCPUS. We've changed the
> size of the VP block, but kvmppc_pack_vcpu_id() has nothing to
> do with it and it certainly doesn't ensure that the packed vCPU
> ids are below xive->nr_servers. kvmppc_xive_vcpu_id_valid() might
> thus return true when the VM was configured with a non-standard
> VSMT mode, even if the packed vCPU id is higher than what we
> expect. We end up using an unallocated VP id, which confuses
> OPAL. The assert in OPAL is probably abusive and should be
> converted to a regular error that the kernel can handle, but
> we shouldn't really use broken VP ids in the first place.
> 
> Fix kvmppc_xive_vcpu_id_valid() so that it checks the packed
> vCPU id is below xive->nr_servers, which is explicitly what we
> want.
> 
> Fixes: 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size 
> configurable")
> Cc: sta...@vger.kernel.org # v5.5+
> Signed-off-by: Greg Kurz 

Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
>  arch/powerpc/kvm/book3s_xive.c |7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 85215e79db42..a0ebc29f30b2 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -1214,12 +1214,9 @@ void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu)
>  static bool kvmppc_xive_vcpu_id_valid(struct kvmppc_xive *xive, u32 cpu)
>  {
>   /* We have a block of xive->nr_servers VPs. We just need to check
> -  * raw vCPU ids are below the expected limit for this guest's
> -  * core stride ; kvmppc_pack_vcpu_id() will pack them down to an
> -  * index that can be safely used to compute a VP id that belongs
> -  * to the VP block.
> +  * packed vCPU ids are below that.
>*/
> - return cpu < xive->nr_servers * xive->kvm->arch.emul_smt_mode;
> + return kvmppc_pack_vcpu_id(xive->kvm, cpu) < xive->nr_servers;
>  }
>  
>  int kvmppc_xive_compute_vp_id(struct kvmppc_xive *xive, u32 cpu, u32 *vp)
> 
> 

Re: [PATCH kernel v4 1/8] genirq/ipi: Simplify irq_reserve_ipi

[Cédric Le Goater]

On 11/24/20 7:17 AM, Alexey Kardashevskiy wrote:
> __irq_domain_alloc_irqs() can already handle virq==-1 and free
> descriptors if it failed allocating hardware interrupts so let's skip
> this extra step.
> 
> Signed-off-by: Alexey Kardashevskiy 

LGTM,

Reviewed-by: Cédric Le Goater 

Copying the MIPS folks since the IPI interface is only used under arch/mips.

C.
 
> ---
>  kernel/irq/ipi.c | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/irq/ipi.c b/kernel/irq/ipi.c
> index 43e3d1be622c..1b2807318ea9 100644
> --- a/kernel/irq/ipi.c
> +++ b/kernel/irq/ipi.c
> @@ -75,18 +75,12 @@ int irq_reserve_ipi(struct irq_domain *domain,
>   }
>   }
>  
> - virq = irq_domain_alloc_descs(-1, nr_irqs, 0, NUMA_NO_NODE, NULL);
> - if (virq <= 0) {
> - pr_warn("Can't reserve IPI, failed to alloc descs\n");
> - return -ENOMEM;
> - }
> -
> - virq = __irq_domain_alloc_irqs(domain, virq, nr_irqs, NUMA_NO_NODE,
> -(void *) dest, true, NULL);
> + virq = __irq_domain_alloc_irqs(domain, -1, nr_irqs, NUMA_NO_NODE,
> +(void *) dest, false, NULL);
>  
>   if (virq <= 0) {
>   pr_warn("Can't reserve IPI, failed to alloc hw irqs\n");
> - goto free_descs;
> + return -EBUSY;
>   }
>  
>   for (i = 0; i < nr_irqs; i++) {
> @@ -96,10 +90,6 @@ int irq_reserve_ipi(struct irq_domain *domain,
>   irq_set_status_flags(virq + i, IRQ_NO_BALANCING);
>   }
>   return virq;
> -
> -free_descs:
> - irq_free_descs(virq, nr_irqs);
> - return -EBUSY;
>  }
>  
>  /**
> 

Re: [PATCH kernel v3] genirq/irqdomain: Add reference counting to IRQs

[Cédric Le Goater]

On 11/9/20 10:46 AM, Alexey Kardashevskiy wrote:
> PCI devices share 4 legacy INTx interrupts from the same PCI host bridge.
> Device drivers map/unmap hardware interrupts via irq_create_mapping()/
> irq_dispose_mapping(). The problem with that these interrupts are
> shared and when performing hot unplug, we need to unmap the interrupt
> only when the last device is released.

The background context for such a need is that the POWER9 and POWER10 
processors have a new XIVE interrupt controller which uses MMIO pages 
for interrupt management. Each interrupt has a pair of pages which are
required to be unmapped in some environment, like PHB removal. And so,
all interrupts need to be unmmaped. 

> 
> This reuses already existing irq_desc::kobj for this purpose.
> The refcounter is naturally 1 when the descriptor is allocated already;
> this adds kobject_get() in places where already existing mapped virq
> is returned.
> 
> This reorganizes irq_dispose_mapping() to release the kobj and let
> the release callback do the cleanup.
> 
> As kobject_put() is called directly now (not via RCU), it can also handle
> the early boot case (irq_kobj_base==NULL) with the help of
> the kobject::state_in_sysfs flag and without additional irq_sysfs_del().

Could this change be done in a following patch ? 

> While at this, clean up the comment at where irq_sysfs_del() was called.>
> Quick grep shows no sign of irq reference counting in drivers. Drivers
> typically request mapping when probing and dispose it when removing;

Some ARM drivers call directly irq_alloc_descs() and irq_free_descs(). 
Is  that a problem ? 

> platforms tend to dispose only if setup failed and the rest seems
> calling one dispose per one mapping. Except (at least) PPC/pseries
> which needs https://lkml.org/lkml/2020/10/27/259
> 
> Cc: Cédric Le Goater 
> Cc: Marc Zyngier 
> Cc: Michael Ellerman 
> Cc: Qian Cai 
> Cc: Rob Herring 
> Cc: Frederic Barrat 
> Cc: Michal Suchánek 
> Cc: Thomas Gleixner 
> Signed-off-by: Alexey Kardashevskiy 

I used this patch and the ppc one doing the LSI removal:  

  
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20201027090655.14118-3-...@ozlabs.ru/

on different P10 and P9 systems, on a large system (>1K HW theads), 
KVM guests and pSeries machines. Checked that PHB removal was OK. 
 
Tested-by: Cédric Le Goater 

But IRQ subsystem covers much more than these systems.


Some comments below, 

> ---
> 
> This is what it is fixing for powerpc:
> 
> There was a comment about whether hierarchical IRQ domains should
> contribute to this reference counter and I need some help here as
> I cannot see why.
> It is reverse now - IRQs contribute to domain->mapcount and
> irq_domain_associate/irq_domain_disassociate take necessary steps to
> keep this counter in order. What might be missing is that if we have
> cascade of IRQs (as in the IOAPIC example from
> Documentation/core-api/irq/irq-domain.rst ), then a parent IRQ should
> contribute to the children IRQs and it is up to
> irq_domain_ops::alloc/free hooks, and they all seem to be eventually
> calling irq_domain_alloc_irqs_xxx/irq_domain_free_irqs_xxx which seems
> right.
> 
> Documentation/core-api/irq/irq-domain.rst also suggests there is a lot
> to see in debugfs about IRQs but on my thinkpad there nothing about
> hierarchy.
> 
> So I'll ask again :)
> 
> What is the easiest way to get irq-hierarchical hardware?
> I have a bunch of powerpc boxes (no good) but also a raspberry pi,
> a bunch of 32/64bit orange pi's, an "armada" arm box,
> thinkpads - is any of this good for the task?
> 
> 
> 
> ---
> Changes:
> v3:
> * removed very wrong kobject_get/_put from irq_domain_associate/
> irq_domain_disassociate as these are called from kobject_release so
> irq_descs were never actually released
> * removed irq_sysfs_del as 1) we do not seem to need it with changed
> counting  2) produces a "no parent" warning as it would be called from
> kobject_release which removes sysfs nodes itself
> 
> v2:
> * added more get/put, including irq_domain_associate/irq_domain_disassociate
> ---
>  kernel/irq/irqdesc.c   | 55 ++
>  kernel/irq/irqdomain.c | 37 
>  2 files changed, 46 insertions(+), 46 deletions(-)
> 
> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
> index 1a7723604399..79c904ebfd5c 100644
> --- a/kernel/irq/irqdesc.c
> +++ b/kernel/irq/irqdesc.c
> @@ -295,18 +295,6 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc)
>   }
>  }
>  
> -static void irq_sysfs_del(struct irq_desc *desc)
> -{
> - /*
> -  * If irq_sysfs_init() has not yet been invoked (early boot), then
> -

Re: [RFC PATCH kernel 2/2] powerpc/pci: Remove LSI mappings on device teardown

[Cédric Le Goater]

On 10/27/20 10:06 AM, Alexey Kardashevskiy wrote:
> From: Oliver O'Halloran 
> 
> When a passthrough IO adapter is removed from a pseries machine using hash
> MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
> to clear all page table entries related to the adapter. If some are still
> present, the RTAS call which isolates the PCI slot returns error 9001
> "valid outstanding translations" and the removal of the IO adapter fails.
> This is because when the PHBs are scanned, Linux maps automatically the
> INTx interrupts in the Linux interrupt number space but these are never
> removed.
> 
> This problem can be fixed by adding the corresponding unmap operation when
> the device is removed. There's no pcibios_* hook for the remove case, but
> the same effect can be achieved using a bus notifier.
> 
> Cc: Cédric Le Goater 
> Cc: Michael Ellerman 
> Signed-off-by: Oliver O'Halloran 
> Signed-off-by: Alexey Kardashevskiy 


Reviewed-by: Cédric Le Goater 

Thanks taking care of this.

C. 

> ---
>  arch/powerpc/kernel/pci-common.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/pci-common.c 
> b/arch/powerpc/kernel/pci-common.c
> index be108616a721..95f4e173368a 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -404,6 +404,27 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
>   return 0;
>  }
>  
> +static int ppc_pci_unmap_irq_line(struct notifier_block *nb,
> +unsigned long action, void *data)
> +{
> + struct pci_dev *pdev = to_pci_dev(data);
> +
> + if (action == BUS_NOTIFY_DEL_DEVICE)
> + irq_dispose_mapping(pdev->irq);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block ppc_pci_unmap_irq_notifier = {
> + .notifier_call = ppc_pci_unmap_irq_line,
> +};
> +
> +static int ppc_pci_register_irq_notifier(void)
> +{
> + return bus_register_notifier(_bus_type, 
> _pci_unmap_irq_notifier);
> +}
> +arch_initcall(ppc_pci_register_irq_notifier);
> +
>  /*
>   * Platform support for /proc/bus/pci/X/Y mmap()s.
>   *  -- paulus.
> 

Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver

[Cédric Le Goater]

Hello Chin-Ting,

Thanks for this driver. It's much cleaner than the previous and we should 
try adding support for the AST2500 SoC also. I guess we can keep the old 
driver for the AST2400 which has a different register layout.

On the patchset, I think we should split this patch in three : 

 - basic support
 - AHB window calculation depending on the flash size
 - read training support  

We should avoid magic values when setting registers. This is confusing 
and defines are much better.
 
AST2500 support will be a bit challenging because HW does not allow
to configure a 128MB AHB window, max is 120MB This is a bug and the work 
around is to use user mode for the remaining 8MB. Something to keep in
mind.

I gave it a try on QEMU. It looks good. When I can revive my EVB, I will
do the same.

More comments below, 

Thanks,

C.


On 11/5/20 1:03 PM, Chin-Ting Kuo wrote:
> Add driver for ASPEED BMC FMC/SPI memory controller which
> supports spi-mem interface.
> 
> There are three SPI memory controllers embedded in an ASPEED SoC.
> Each of them can connect to two or three SPI NOR flashes. The first
> SPI memory controller is also named as Firmware Memory Controller (FMC),
> which is similar to SPI memory controller. After device AC on, MCU ROM
> can fetch device boot code from FMC CS 0. Thus, there exists additional
> registers for boot process control in FMC.
> 
> ASPEED SPI memory controller supports single, dual and quad mode for
> SPI NOR flash. It also supports two types of command mode, user mode
> and command read/write mode. User mode is traditional pure SPI operations
> where all transmission is controlled by CPU. Contrarily, with command
> read/write mode, SPI controller can send command and address automatically
> when CPU read/write related remapped address.
> 
> Besides, different wafer processes of SPI NOR flash result in different
> signal response time. This phenomenon will be enlarged when SPI clock
> frequency increases. ASPEED SPI memory controller provides a mechanism
> for timing compensation in order to satisfy various SPI NOR flash parts
> and PCB layout.
> 
> Signed-off-by: Chin-Ting Kuo 
> ---
>  v2: Fix sparse warnings reported by kernel test robot .
>  v3: Fix build warnings with x86 allmodconfig.
> 
>  drivers/spi/Kconfig  |  10 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/spi-aspeed.c | 969 +++
>  3 files changed, 980 insertions(+)
>  create mode 100644 drivers/spi/spi-aspeed.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 5cff60de8e83..c848f2f7b694 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -70,6 +70,16 @@ config SPI_AR934X
> This enables support for the SPI controller present on the
> Qualcomm Atheros AR934X/QCA95XX SoCs.
>  
> +config SPI_ASPEED
> + tristate "ASPEED FMC/SPI Memory Controller"
> + depends on OF && HAS_IOMEM && (ARCH_ASPEED || COMPILE_TEST)

We will need to do something about the other driver. For the moment,
we can select both but that won't be the case anymore when we add
AST2500 support.

> + help
> +   Enable driver for ASPEED FMC/SPI Memory Controller.
> +
> +   This driver is not a generic pure SPI driver, which
> +   is especially designed for spi-mem framework with
> +   SPI NOR flash direct read and write features.
> +
>  config SPI_ATH79
>   tristate "Atheros AR71XX/AR724X/AR913X SPI controller driver"
>   depends on ATH79 || COMPILE_TEST
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 6fea5821662e..9e62c650fca0 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST) += 
> spi-loopback-test.o
>  obj-$(CONFIG_SPI_ALTERA) += spi-altera.o
>  obj-$(CONFIG_SPI_AR934X) += spi-ar934x.o
>  obj-$(CONFIG_SPI_ARMADA_3700)+= spi-armada-3700.o
> +obj-$(CONFIG_SPI_ASPEED) += spi-aspeed.o
>  obj-$(CONFIG_SPI_ATMEL)  += spi-atmel.o
>  obj-$(CONFIG_SPI_ATMEL_QUADSPI)  += atmel-quadspi.o
>  obj-$(CONFIG_SPI_AT91_USART) += spi-at91-usart.o
> diff --git a/drivers/spi/spi-aspeed.c b/drivers/spi/spi-aspeed.c
> new file mode 100644
> index ..cfaaa0d5bac6
> --- /dev/null
> +++ b/drivers/spi/spi-aspeed.c
> @@ -0,0 +1,969 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * ASPEED FMC/SPI Memory Controller Driver
> + *
> + * Copyright (c) 2020, ASPEED Corporation.
> + * Copyright (c) 2015-2016, IBM Corporation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* ASPEED FMC/SPI memory control register related */
> +#define OFFSET_CE_TYPE_SETTING   0x00
> +#define OFFSET_CE_ADDR_MODE_CTRL 0x04
> +#define OFFSET_INTR_CTRL_STATUS  0x08
> +#define 

Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

[Cédric Le Goater]

On 10/14/20 4:55 AM, Alexey Kardashevskiy wrote:
> 
> 
> On 23/09/2020 17:06, Cédric Le Goater wrote:
>> On 9/23/20 2:33 AM, Qian Cai wrote:
>>> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
>>>> When a passthrough IO adapter is removed from a pseries machine using
>>>> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
>>>> guest OS to clear all page table entries related to the adapter. If
>>>> some are still present, the RTAS call which isolates the PCI slot
>>>> returns error 9001 "valid outstanding translations" and the removal of
>>>> the IO adapter fails. This is because when the PHBs are scanned, Linux
>>>> maps automatically the INTx interrupts in the Linux interrupt number
>>>> space but these are never removed.
>>>>
>>>> To solve this problem, we introduce a PPC platform specific
>>>> pcibios_remove_bus() routine which clears all interrupt mappings when
>>>> the bus is removed. This also clears the associated page table entries
>>>> of the ESB pages when using XIVE.
>>>>
>>>> For this purpose, we record the logical interrupt numbers of the
>>>> mapped interrupt under the PHB structure and let pcibios_remove_bus()
>>>> do the clean up.
>>>>
>>>> Since some PCI adapters, like GPUs, use the "interrupt-map" property
>>>> to describe interrupt mappings other than the legacy INTx interrupts,
>>>> we can not restrict the size of the mapping array to PCI_NUM_INTX. The
>>>> number of interrupt mappings is computed from the "interrupt-map"
>>>> property and the mapping array is allocated accordingly.
>>>>
>>>> Cc: "Oliver O'Halloran" 
>>>> Cc: Alexey Kardashevskiy 
>>>> Signed-off-by: Cédric Le Goater 
>>>
>>> Some syscall fuzzing will trigger this on POWER9 NV where the traces 
>>> pointed to
>>> this patch.
>>>
>>> .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config
>>
>> OK. The patch is missing a NULL assignement after kfree() and that
>> might be the issue.
>>
>> I did try PHB removal under PowerNV, so I would like to understand
>> how we managed to remove twice the PCI bus and possibly reproduce.
>> Any chance we could grab what the syscall fuzzer (syzkaller) did ?
> 
> 
> How do you remove PHBs exactly? There is no such thing in the powernv 
> platform, I thought someone added this and you are fixing it but no. PHBs on 
> powernv are created at the boot time and there is no way to remove them, you 
> can only try removing all the bridges.

yes. I noticed that later when proposing the fix for the double 
free.

> So what exactly are you doing?

What you just said above, with the commands : 

  echo 1 >  /sys/devices/pci0031\:00/0031\:00\:00.0/remove
  echo 1 >  /sys/devices/pci0031\:00/pci_bus/0031\:00/rescan


C. 

Re: [PATCH v2] mtd: spi-nor: Fix address width on flash chips > 16MB

[Cédric Le Goater]

On 10/7/20 3:51 AM, Joel Stanley wrote:
> On Sun, 4 Oct 2020 at 21:33, Bert Vermeulen  wrote:
>>
>> If a flash chip has more than 16MB capacity but its BFPT reports
>> BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3.
>>
>> The check in spi_nor_set_addr_width() doesn't catch it because addr_width
>> did get set. This fixes that check.
>>
>> Signed-off-by: Bert Vermeulen 
> 
> After replying to the other thread, I just saw this one.
> 
> Reviewed-by: Joel Stanley 
> Tested-by: Joel Stanley 
> 
> Thanks Bert!


Yes. I was starting to add bfpt-fixups for all chips we use on Aspeed 
based system.

Reviewed-by: Cédric Le Goater 
Tested-by: Cédric Le Goater 

Thanks,

C. 



> Cheers,
> 
> Joel
> 
>> ---
>>  drivers/mtd/spi-nor/core.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 0369d98b2d12..a2c35ad9645c 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -3009,13 +3009,15 @@ static int spi_nor_set_addr_width(struct spi_nor 
>> *nor)
>> /* already configured from SFDP */
>> } else if (nor->info->addr_width) {
>> nor->addr_width = nor->info->addr_width;
>> -   } else if (nor->mtd.size > 0x100) {
>> -   /* enable 4-byte addressing if the device exceeds 16MiB */
>> -   nor->addr_width = 4;
>> } else {
>> nor->addr_width = 3;
>> }
>>
>> +   if (nor->addr_width == 3 && nor->mtd.size > 0x100) {
>> +   /* enable 4-byte addressing if the device exceeds 16MiB */
>> +   nor->addr_width = 4;
>> +   }
>> +
>> if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
>> dev_dbg(nor->dev, "address width is too large: %u\n",
>> nor->addr_width);
>> --
>> 2.17.1
>>

Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

[Cédric Le Goater]

On 9/24/20 7:11 AM, Alexey Kardashevskiy wrote:
> 
> 
> On 23/09/2020 17:06, Cédric Le Goater wrote:
>> On 9/23/20 2:33 AM, Qian Cai wrote:
>>> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
>>>> When a passthrough IO adapter is removed from a pseries machine using
>>>> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
>>>> guest OS to clear all page table entries related to the adapter. If
>>>> some are still present, the RTAS call which isolates the PCI slot
>>>> returns error 9001 "valid outstanding translations" and the removal of
>>>> the IO adapter fails. This is because when the PHBs are scanned, Linux
>>>> maps automatically the INTx interrupts in the Linux interrupt number
>>>> space but these are never removed.
>>>>
>>>> To solve this problem, we introduce a PPC platform specific
>>>> pcibios_remove_bus() routine which clears all interrupt mappings when
>>>> the bus is removed. This also clears the associated page table entries
>>>> of the ESB pages when using XIVE.
>>>>
>>>> For this purpose, we record the logical interrupt numbers of the
>>>> mapped interrupt under the PHB structure and let pcibios_remove_bus()
>>>> do the clean up.
>>>>
>>>> Since some PCI adapters, like GPUs, use the "interrupt-map" property
>>>> to describe interrupt mappings other than the legacy INTx interrupts,
>>>> we can not restrict the size of the mapping array to PCI_NUM_INTX. The
>>>> number of interrupt mappings is computed from the "interrupt-map"
>>>> property and the mapping array is allocated accordingly.
>>>>
>>>> Cc: "Oliver O'Halloran" 
>>>> Cc: Alexey Kardashevskiy 
>>>> Signed-off-by: Cédric Le Goater 
>>>
>>> Some syscall fuzzing will trigger this on POWER9 NV where the traces 
>>> pointed to
>>> this patch.
>>>
>>> .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config
>>
>> OK. The patch is missing a NULL assignement after kfree() and that
>> might be the issue. 
>>
>> I did try PHB removal under PowerNV, so I would like to understand 
>> how we managed to remove twice the PCI bus and possibly reproduce. 
>> Any chance we could grab what the syscall fuzzer (syzkaller) did ? 
> 
> 
> 
> My guess would be it is doing this in parallel to provoke races.

Concurrency removal and rescan should be controlled by : 

   pci_stop_and_remove_bus_device_locked()
   pci_lock_rescan_remove() 

And, in the report, the stack traces are on the same CPU and PID. 



What I think is happening is that we did a couple of remove/rescan
of the same PHB. The problem is that ->irq_map is not reallocated
the second time because the PHB is re-scanned differently on the 
PowerNV platform. At the second remove, the ->irq_map being not NULL, 
we try to kfree it again and the allocator warns of a double free :/

This works fine on pseries/KVM because the PHB is never removed and 
on pseries/pHyp, pcibios_scan_phb() is called at PHB hotplug. But on 
PowerNV, pcibios_scan_phb() is only called at probe/boot time and 
not at hotplug time :/

I was a good thing to spot that before merge. But I need to revise 
that patch again.

Thanks,

C.

Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

[Cédric Le Goater]

On 9/23/20 2:33 AM, Qian Cai wrote:
> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
>> When a passthrough IO adapter is removed from a pseries machine using
>> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
>> guest OS to clear all page table entries related to the adapter. If
>> some are still present, the RTAS call which isolates the PCI slot
>> returns error 9001 "valid outstanding translations" and the removal of
>> the IO adapter fails. This is because when the PHBs are scanned, Linux
>> maps automatically the INTx interrupts in the Linux interrupt number
>> space but these are never removed.
>>
>> To solve this problem, we introduce a PPC platform specific
>> pcibios_remove_bus() routine which clears all interrupt mappings when
>> the bus is removed. This also clears the associated page table entries
>> of the ESB pages when using XIVE.
>>
>> For this purpose, we record the logical interrupt numbers of the
>> mapped interrupt under the PHB structure and let pcibios_remove_bus()
>> do the clean up.
>>
>> Since some PCI adapters, like GPUs, use the "interrupt-map" property
>> to describe interrupt mappings other than the legacy INTx interrupts,
>> we can not restrict the size of the mapping array to PCI_NUM_INTX. The
>> number of interrupt mappings is computed from the "interrupt-map"
>> property and the mapping array is allocated accordingly.
>>
>> Cc: "Oliver O'Halloran" 
>> Cc: Alexey Kardashevskiy 
>> Signed-off-by: Cédric Le Goater 
> 
> Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed 
> to
> this patch.
> 
> .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config

OK. The patch is missing a NULL assignement after kfree() and that
might be the issue. 

I did try PHB removal under PowerNV, so I would like to understand 
how we managed to remove twice the PCI bus and possibly reproduce. 
Any chance we could grab what the syscall fuzzer (syzkaller) did ? 


Thanks,

C. 

> 
> [ 3574.564109][  T965] ata1.00: disabled
> [ 3574.580373][T151472] sd 0:0:0:0: [sdb] Synchronizing SCSI cache
> [ 3574.581180][T151472] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: 
> Result: hostbyte=0x04 driverbyte=0x00
> [ 3574.581226][T151472] sd 0:0:0:0: [sdb] Stopping disk
> [ 3574.581289][T151472] sd 0:0:0:0: [sdb] Start/Stop Unit failed: Result: 
> hostbyte=0x04 driverbyte=0x00
> [ 3574.611424][ T3019] Read-error on swap-device (254:1:849792)
> [ 3574.611685][ T3019] Read-error on swap-device (254:1:914944)
> [ 3574.611769][ T3019] Read-error on swap-device (254:1:915072)
> [ 3574.611838][ T3019] Read-error on swap-device (254:1:915200)
> [ 3574.611926][ T3019] Read-error on swap-device (254:1:915328)
> [ 3574.612268][ T3084] Read-error on swap-device (254:1:792576)
> [ 3574.612342][ T3084] Read-error on swap-device (254:1:792704)
> [ 3574.612757][ T2362] Read-error on swap-device (254:1:957440)
> [ 3574.612773][ T2905] Read-error on swap-device (254:1:784128)
> [ 3574.613015][ T2362] Read-error on swap-device (254:1:957568)
> [ 3574.613160][ T2905] Read-error on swap-device (254:1:784256)
> [ 3574.613241][ T2362] Read-error on swap-device (254:1:957696)
> [ 3574.613342][ T2362] Read-error on swap-device (254:1:957824)
> [ 3574.614448][ T3019] Core dump to |/usr/lib/systemd/systemd-coredump pipe 
> failed
> [ 3574.614663][ T3019] Read-error on swap-device (254:1:961536)
> [ 3574.675330][T151844] Read-error on swap-device (254:1:128)
> [ 3574.675515][T151844] Read-error on swap-device (254:1:256)
> [ 3574.675700][T151844] Read-error on swap-device (254:1:384)
> [ 3574.703570][  T971] ata2.00: disabled
> [ 3574.710393][T151472] sd 1:0:0:0: [sda] Synchronizing SCSI cache
> [ 3574.710864][T151472] sd 1:0:0:0: [sda] Synchronize Cache(10) failed: 
> Result: hostbyte=0x04 driverbyte=0x00
> [ 3574.710922][T151472] sd 1:0:0:0: [sda] Stopping disk
> [ 3574.711010][T151472] sd 1:0:0:0: [sda] Start/Stop Unit failed: Result: 
> hostbyte=0x04 driverbyte=0x00
> [ 3574.826569][  T674] dm-0: writeback error on inode 68507862, offset 65536, 
> sector 54281504
> [ 3575.117547][ T3366] dm-0: writeback error on inode 68507851, offset 0, 
> sector 54378880
> [ 3575.140104][T151472] pci 0004:03:00.0: Removing from iommu group 3
> [ 3575.141778][T151472] pci 0004:03 : [PE# fb] Releasing PE
> [ 3575.141965][T151472] pci 0004:03 : [PE# fb] Removing DMA window #0
> [ 3575.142452][T151472] pci 0004:03 : [PE# fb] Disabling 64-bit DMA bypass
> [ 3575.149369][T151472] pci_bus 0004:03: busn_res: [bus 03] is released
> [ 3575.150574][T152037] Read-error on swap-device (254:1:35584)
> [ 3575.150713][T152

Re: [PATCH -next v2] KVM: PPC: Book3S HV: XIVE: Convert to DEFINE_SHOW_ATTRIBUTE

[Cédric Le Goater]

On 9/19/20 3:29 AM, Qinglang Miao wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Qinglang Miao 

Reviewed-by: Cédric Le Goater 

> ---
> v2: based on linux-next(20200917), and can be applied to
> mainline cleanly now.
> 
>  arch/powerpc/kvm/book3s_xive_native.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c 
> b/arch/powerpc/kvm/book3s_xive_native.c
> index bdea91df1..d0c2db0e0 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -1227,17 +1227,7 @@ static int xive_native_debug_show(struct seq_file *m, 
> void *private)
>   return 0;
>  }
>  
> -static int xive_native_debug_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, xive_native_debug_show, inode->i_private);
> -}
> -
> -static const struct file_operations xive_native_debug_fops = {
> - .open = xive_native_debug_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(xive_native_debug);
>  
>  static void xive_native_debugfs_init(struct kvmppc_xive *xive)
>  {
> 

Re: [PATCH 5/5] powerpc: use the generic dma_ops_bypass mode

[Cédric Le Goater]

On 8/31/20 8:40 AM, Christoph Hellwig wrote:
> On Sun, Aug 30, 2020 at 11:04:21AM +0200, Cédric Le Goater wrote:
>> Hello,
>>
>> On 7/8/20 5:24 PM, Christoph Hellwig wrote:
>>> Use the DMA API bypass mechanism for direct window mappings.  This uses
>>> common code and speed up the direct mapping case by avoiding indirect
>>> calls just when not using dma ops at all.  It also fixes a problem where
>>> the sync_* methods were using the bypass check for DMA allocations, but
>>> those are part of the streaming ops.
>>>
>>> Note that this patch loses the DMA_ATTR_WEAK_ORDERING override, which
>>> has never been well defined, as is only used by a few drivers, which
>>> IIRC never showed up in the typical Cell blade setups that are affected
>>> by the ordering workaround.
>>>
>>> Fixes: efd176a04bef ("powerpc/pseries/dma: Allow SWIOTLB")
>>> Signed-off-by: Christoph Hellwig 
>>> ---
>>>  arch/powerpc/Kconfig  |  1 +
>>>  arch/powerpc/include/asm/device.h |  5 --
>>>  arch/powerpc/kernel/dma-iommu.c   | 90 ---
>>>  3 files changed, 10 insertions(+), 86 deletions(-)
>>
>> I am seeing corruptions on a couple of POWER9 systems (boston) when
>> stressed with IO. stress-ng gives some results but I have first seen
>> it when compiling the kernel in a guest and this is still the best way
>> to raise the issue.
>>
>> These systems have of a SAS Adaptec controller :
>>
>>   0003:01:00.0 Serial Attached SCSI controller: Adaptec Series 8 12G 
>> SAS/PCIe 3 (rev 01)
>>
>> When the failure occurs, the POWERPC EEH interrupt fires and dumps
>> lowlevel PHB4 registers among which :
>>
>>   [ 2179.251069490,3] PHB#0003[0:3]:   phbErrorStatus = 
>> 0280
>>   [ 2179.251117476,3] PHB#0003[0:3]:  phbFirstErrorStatus = 
>> 0200
>>
>> The bits raised identify a PPC 'TCE' error, which means it is related
>> to DMAs. See below for more details.
>>
>>
>> Reverting this patch "fixes" the issue but it is probably else where,
>> in some other layers or in the aacraid driver. How should I proceed 
>> to get more information ?
> 
> The aacraid DMA masks look like a mess.  Can you try the hack
> below and see it it helps?

No effect. The system crashes the same. But Alexey spotted some issue 
with swiotlb.

C. 

Re: [PATCH 5/5] powerpc: use the generic dma_ops_bypass mode

[Cédric Le Goater]

Hello,

On 7/8/20 5:24 PM, Christoph Hellwig wrote:
> Use the DMA API bypass mechanism for direct window mappings.  This uses
> common code and speed up the direct mapping case by avoiding indirect
> calls just when not using dma ops at all.  It also fixes a problem where
> the sync_* methods were using the bypass check for DMA allocations, but
> those are part of the streaming ops.
> 
> Note that this patch loses the DMA_ATTR_WEAK_ORDERING override, which
> has never been well defined, as is only used by a few drivers, which
> IIRC never showed up in the typical Cell blade setups that are affected
> by the ordering workaround.
> 
> Fixes: efd176a04bef ("powerpc/pseries/dma: Allow SWIOTLB")
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/powerpc/Kconfig  |  1 +
>  arch/powerpc/include/asm/device.h |  5 --
>  arch/powerpc/kernel/dma-iommu.c   | 90 ---
>  3 files changed, 10 insertions(+), 86 deletions(-)

I am seeing corruptions on a couple of POWER9 systems (boston) when
stressed with IO. stress-ng gives some results but I have first seen
it when compiling the kernel in a guest and this is still the best way
to raise the issue.

These systems have of a SAS Adaptec controller :

  0003:01:00.0 Serial Attached SCSI controller: Adaptec Series 8 12G SAS/PCIe 3 
(rev 01)

When the failure occurs, the POWERPC EEH interrupt fires and dumps
lowlevel PHB4 registers among which :
  
  [ 2179.251069490,3] PHB#0003[0:3]:   phbErrorStatus = 0280
  [ 2179.251117476,3] PHB#0003[0:3]:  phbFirstErrorStatus = 0200

The bits raised identify a PPC 'TCE' error, which means it is related
to DMAs. See below for more details.


Reverting this patch "fixes" the issue but it is probably else where,
in some other layers or in the aacraid driver. How should I proceed 
to get more information ?

Thanks,

C.


[ 2054.970339] EEH: Frozen PE#1fd on PHB#3 detected
[ 2054.970375] EEH: PE location: UOPWR.BOS0019-Node0-Onboard SAS, PHB location: 
N/A
[ 2179.249415973,3] PHB#0003[0:3]:  brdgCtl = 0002
[ 2179.249515795,3] PHB#0003[0:3]: deviceStatus = 00060040
[ 2179.249596452,3] PHB#0003[0:3]:   slotStatus = 00402000
[ 2179.249633728,3] PHB#0003[0:3]:   linkStatus = a0830008
[ 2179.249674807,3] PHB#0003[0:3]: devCmdStatus = 00100107
[ 2179.249725974,3] PHB#0003[0:3]: devSecStatus = 00100107
[ 2179.249773550,3] PHB#0003[0:3]:  rootErrorStatus = 
[ 2179.249809823,3] PHB#0003[0:3]:  corrErrorStatus = 
[ 2179.249850439,3] PHB#0003[0:3]:uncorrErrorStatus = 
[ 2179.249887411,3] PHB#0003[0:3]:   devctl = 0040
[ 2179.249928677,3] PHB#0003[0:3]:  devStat = 0006
[ 2179.249967150,3] PHB#0003[0:3]:  tlpHdr1 = 
[ 2179.250054987,3] PHB#0003[0:3]:  tlpHdr2 = 
[ 2179.250146600,3] PHB#0003[0:3]:  tlpHdr3 = 
[ 2179.250262780,3] PHB#0003[0:3]:  tlpHdr4 = 
[ 2179.250343101,3] PHB#0003[0:3]: sourceId = 
[ 2179.250514264,3] PHB#0003[0:3]: nFir = 
[ 2179.250717971,3] PHB#0003[0:3]: nFirMask = 0030001c
[ 2179.250791474,3] PHB#0003[0:3]:  nFirWOF = 
[ 2179.250842054,3] PHB#0003[0:3]: phbPlssr = 001c
[ 2179.250886003,3] PHB#0003[0:3]:   phbCsr = 001c
[ 2179.250929859,3] PHB#0003[0:3]:   lemFir = 00010080
[ 2179.250973720,3] PHB#0003[0:3]: lemErrorMask = 
[ 2179.251018622,3] PHB#0003[0:3]:   lemWOF = 0080
[ 2179.251069490,3] PHB#0003[0:3]:   phbErrorStatus = 0280
[ 2179.251117476,3] PHB#0003[0:3]:  phbFirstErrorStatus = 0200
[ 2179.251162218,3] PHB#0003[0:3]: phbErrorLog0 = 214898000240
[ 2179.251206251,3] PHB#0003[0:3]: phbErrorLog1 = a0084000
[ 2179.251253096,3] PHB#0003[0:3]:phbTxeErrorStatus = 
[ 2179.265087656,3] PHB#0003[0:3]:   phbTxeFirstErrorStatus = 
[ 2179.265142247,3] PHB#0003[0:3]:  phbTxeErrorLog0 = 
[ 2179.265189734,3] PHB#0003[0:3]:  phbTxeErrorLog1 = 
[ 2179.266335296,3] PHB#0003[0:3]: phbRxeArbErrorStatus = 
[ 2179.266380366,3] PHB#0003[0:3]: phbRxeArbFrstErrorStatus = 
[ 2179.266426523,3] PHB#0003[0:3]:   phbRxeArbErrorLog0 = 
[ 2179.267537283,3] PHB#0003[0:3]:   phbRxeArbErrorLog1 = 
[ 2179.267581708,3] PHB#0003[0:3]: phbRxeMrgErrorStatus = 
[ 2179.267628324,3] PHB#0003[0:3]: phbRxeMrgFrstErrorStatus = 
[ 2179.268748771,3] PHB#0003[0:3]:   

Re: [PATCH -next] ipmi: bt-bmc: use devm_platform_ioremap_resource() to simplify code

[Cédric Le Goater]

On 16/10/2019 16:19, Corey Minyard wrote:
> On Wed, Oct 16, 2019 at 05:21:31PM +0800, YueHaibing wrote:
>> Use devm_platform_ioremap_resource() to simplify the code a bit.
>> This is detected by coccinelle.
> 
> Adding the module author and others. I can't see a reason to not do
> this.

yes. Looks good to me.

Reviewed-by: Cédric Le Goater 

Thanks,

C.

> -corey
> 
>>
>> Signed-off-by: YueHaibing 
>> ---
>>  drivers/char/ipmi/bt-bmc.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index 40b9927..d36aeac 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -444,15 +444,13 @@ static int bt_bmc_probe(struct platform_device *pdev)
>>  
>>  bt_bmc->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>>  if (IS_ERR(bt_bmc->map)) {
>> -struct resource *res;
>>  void __iomem *base;
>>  
>>  /*
>>   * Assume it's not the MFD-based devicetree description, in
>>   * which case generate a regmap ourselves
>>   */
>> -res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -base = devm_ioremap_resource(>dev, res);
>> +base = devm_platform_ioremap_resource(pdev, 0);
>>  if (IS_ERR(base))
>>  return PTR_ERR(base);
>>  
>> -- 
>> 2.7.4
>>
>>

Re: [PATCH v2] powerpc/xive: Fix bogus error code returned by OPAL

[Cédric Le Goater]

On 11/09/2019 17:52, Greg Kurz wrote:
> There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
> to return the 32-bit value 0x when OPAL has run out of IRQs.
> Unfortunatelty, OPAL return values are signed 64-bit entities and
> errors are supposed to be negative. If that happens, the linux code
> confusingly treats 0x as a valid IRQ number and panics at some
> point.
> 
> A fix was recently merged in skiboot:
> 
> e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()")
> 
> but we need a workaround anyway to support older skiboots already
> in the field.
> 
> Internally convert 0x to OPAL_RESOURCE which is the usual error
> returned upon resource exhaustion.
> 
> Cc: sta...@vger.kernel.org # v4.12+
> Signed-off-by: Greg Kurz 



Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
> v2: - fix syntax error in changelog
> - Cc stable
> - rename original OPAL wrapper
> - rewrite fixup wrapper (style, use s64 and u32)
> ---
>  arch/powerpc/include/asm/opal.h|2 +-
>  arch/powerpc/platforms/powernv/opal-call.c |2 +-
>  arch/powerpc/sysdev/xive/native.c  |   11 +++
>  3 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 57bd029c715e..d5a0807d21db 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -272,7 +272,7 @@ int64_t opal_xive_get_vp_info(uint64_t vp,
>  int64_t opal_xive_set_vp_info(uint64_t vp,
> uint64_t flags,
> uint64_t report_cl_pair);
> -int64_t opal_xive_allocate_irq(uint32_t chip_id);
> +int64_t opal_xive_allocate_irq_raw(uint32_t chip_id);
>  int64_t opal_xive_free_irq(uint32_t girq);
>  int64_t opal_xive_sync(uint32_t type, uint32_t id);
>  int64_t opal_xive_dump(uint32_t type, uint32_t id);
> diff --git a/arch/powerpc/platforms/powernv/opal-call.c 
> b/arch/powerpc/platforms/powernv/opal-call.c
> index 29ca523c1c79..dccdc9df5213 100644
> --- a/arch/powerpc/platforms/powernv/opal-call.c
> +++ b/arch/powerpc/platforms/powernv/opal-call.c
> @@ -257,7 +257,7 @@ OPAL_CALL(opal_xive_set_queue_info,   
> OPAL_XIVE_SET_QUEUE_INFO);
>  OPAL_CALL(opal_xive_donate_page, OPAL_XIVE_DONATE_PAGE);
>  OPAL_CALL(opal_xive_alloc_vp_block,  OPAL_XIVE_ALLOCATE_VP_BLOCK);
>  OPAL_CALL(opal_xive_free_vp_block,   OPAL_XIVE_FREE_VP_BLOCK);
> -OPAL_CALL(opal_xive_allocate_irq,OPAL_XIVE_ALLOCATE_IRQ);
> +OPAL_CALL(opal_xive_allocate_irq_raw,OPAL_XIVE_ALLOCATE_IRQ);
>  OPAL_CALL(opal_xive_free_irq,OPAL_XIVE_FREE_IRQ);
>  OPAL_CALL(opal_xive_get_vp_info, OPAL_XIVE_GET_VP_INFO);
>  OPAL_CALL(opal_xive_set_vp_info, OPAL_XIVE_SET_VP_INFO);
> diff --git a/arch/powerpc/sysdev/xive/native.c 
> b/arch/powerpc/sysdev/xive/native.c
> index 37987c815913..ad8ee7dd7f57 100644
> --- a/arch/powerpc/sysdev/xive/native.c
> +++ b/arch/powerpc/sysdev/xive/native.c
> @@ -231,6 +231,17 @@ static bool xive_native_match(struct device_node *node)
>   return of_device_is_compatible(node, "ibm,opal-xive-vc");
>  }
>  
> +static s64 opal_xive_allocate_irq(u32 chip_id)
> +{
> + s64 irq = opal_xive_allocate_irq_raw(chip_id);
> +
> + /*
> +  * Old versions of skiboot can incorrectly return 0x to
> +  * indicate no space, fix it up here.
> +  */
> + return irq == 0x ? OPAL_RESOURCE : irq;
> +}
> +
>  #ifdef CONFIG_SMP
>  static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc)
>  {
> 

Re: [PATCH] powerpc/xive: Fix bogus error code returned by OPAL

[Cédric Le Goater]

On 10/09/2019 15:53, Greg Kurz wrote:
> There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
> to return the 32-bit value 0x when OPAL has run out of IRQs.
> Unfortunatelty, OPAL return values are signed 64-bit entities and
> errors are supposed to be negative. If that happens, the linux code
> confusingly treats 0x as a valid IRQ number and panics at some
> point.
> 
> A fix was recently merged in skiboot:
> 
> e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()")
> 
> but we need a workaround anyway to support older skiboots already
> on the field.
> 
> Internally convert 0x to OPAL_RESOURCE which is the usual error
> returned upon resource exhaustion.
> 
> Signed-off-by: Greg Kurz 



Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
>  arch/powerpc/sysdev/xive/native.c |   13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/xive/native.c 
> b/arch/powerpc/sysdev/xive/native.c
> index 37987c815913..c35583f84f9f 100644
> --- a/arch/powerpc/sysdev/xive/native.c
> +++ b/arch/powerpc/sysdev/xive/native.c
> @@ -231,6 +231,15 @@ static bool xive_native_match(struct device_node *node)
>   return of_device_is_compatible(node, "ibm,opal-xive-vc");
>  }
>  
> +static int64_t opal_xive_allocate_irq_fixup(uint32_t chip_id)
> +{
> + s64 irq = opal_xive_allocate_irq(chip_id);
> +
> +#define XIVE_ALLOC_NO_SPACE  0x /* No possible space */
> + return
> + irq == XIVE_ALLOC_NO_SPACE ? OPAL_RESOURCE : irq;
> +}
> +
>  #ifdef CONFIG_SMP
>  static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc)
>  {
> @@ -238,7 +247,7 @@ static int xive_native_get_ipi(unsigned int cpu, struct 
> xive_cpu *xc)
>  
>   /* Allocate an IPI and populate info about it */
>   for (;;) {
> - irq = opal_xive_allocate_irq(xc->chip_id);
> + irq = opal_xive_allocate_irq_fixup(xc->chip_id);
>   if (irq == OPAL_BUSY) {
>   msleep(OPAL_BUSY_DELAY_MS);
>   continue;
> @@ -259,7 +268,7 @@ u32 xive_native_alloc_irq(void)
>   s64 rc;
>  
>   for (;;) {
> - rc = opal_xive_allocate_irq(OPAL_XIVE_ANY_CHIP);
> + rc = opal_xive_allocate_irq_fixup(OPAL_XIVE_ANY_CHIP);
>   if (rc != OPAL_BUSY)
>   break;
>   msleep(OPAL_BUSY_DELAY_MS);
> 

Re: [PATCH] powerpc/xive: Add some error handling code to 'xive_spapr_init()'

[Cédric Le Goater]

On 01/08/2019 13:09, Christophe JAILLET wrote:
> 'xive_irq_bitmap_add()' can return -ENOMEM.
> In this case, we should free the memory already allocated and return
> 'false' to the caller.
> 
> Also add an error path which undoes the 'tima = ioremap(...)'
> 
> Signed-off-by: Christophe JAILLET 
> ---
> NOT compile tested (I don't have a cross compiler and won't install one).

All distros have a packaged powerpc cross compiler. 

Then, you need to compile a kernel for a pseries machine and run a pseries
machine with it under QEMU. You can use a simple ppc initrd, a net install 
one for example.

You could also hack the device tree in QEMU to torture the XIVE sPAPR driver.
Nothing too complex, all is here : 

https://git.qemu.org/?p=qemu.git;a=blob;f=hw/intc/spapr_xive.c;h=097f88d4608d8ba160526756a3a224e5176b6e0f;hb=HEAD#l1427


> So if some correction or improvement are needed, feel free to propose and
> commit it directly.

Yes there is I think. I would move at the end all the code that needs a 
rollback.

Thanks for taking a look, I might do that one day.

Cheers,
C.  


> ---
>  arch/powerpc/sysdev/xive/spapr.c | 36 +---
>  1 file changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/xive/spapr.c 
> b/arch/powerpc/sysdev/xive/spapr.c
> index 52198131c75e..b3ae0b76c433 100644
> --- a/arch/powerpc/sysdev/xive/spapr.c
> +++ b/arch/powerpc/sysdev/xive/spapr.c
> @@ -64,6 +64,17 @@ static int xive_irq_bitmap_add(int base, int count)
>   return 0;
>  }
>  
> +static void xive_irq_bitmap_remove_all(void)
> +{
> + struct xive_irq_bitmap *xibm, *tmp;
> +
> + list_for_each_entry_safe(xibm, tmp, _irq_bitmaps, list) {
> + list_del(>list);
> + kfree(xibm->bitmap);
> + kfree(xibm);
> + }
> +}
> +
>  static int __xive_irq_bitmap_alloc(struct xive_irq_bitmap *xibm)
>  {
>   int irq;
> @@ -723,7 +734,7 @@ bool __init xive_spapr_init(void)
>   u32 val;
>   u32 len;
>   const __be32 *reg;
> - int i;
> + int i, err;
>  
>   if (xive_spapr_disabled())
>   return false;
> @@ -748,23 +759,26 @@ bool __init xive_spapr_init(void)
>   }
>  
>   if (!xive_get_max_prio(_prio))
> - return false;
> + goto err_unmap;
>  
>   /* Feed the IRQ number allocator with the ranges given in the DT */
>   reg = of_get_property(np, "ibm,xive-lisn-ranges", );
>   if (!reg) {
>   pr_err("Failed to read 'ibm,xive-lisn-ranges' property\n");
> - return false;
> + goto err_unmap;
>   }
>  
>   if (len % (2 * sizeof(u32)) != 0) {
>   pr_err("invalid 'ibm,xive-lisn-ranges' property\n");
> - return false;
> + goto err_unmap;
>   }
>  
> - for (i = 0; i < len / (2 * sizeof(u32)); i++, reg += 2)
> - xive_irq_bitmap_add(be32_to_cpu(reg[0]),
> - be32_to_cpu(reg[1]));
> + for (i = 0; i < len / (2 * sizeof(u32)); i++, reg += 2) {
> + err = xive_irq_bitmap_add(be32_to_cpu(reg[0]),
> +   be32_to_cpu(reg[1]));
> + if (err < 0)
> + goto err_mem_free;
> + }
>  
>   /* Iterate the EQ sizes and pick one */
>   of_property_for_each_u32(np, "ibm,xive-eq-sizes", prop, reg, val) {
> @@ -775,8 +789,14 @@ bool __init xive_spapr_init(void)
>  
>   /* Initialize XIVE core with our backend */
>   if (!xive_core_init(_spapr_ops, tima, TM_QW1_OS, max_prio))
> - return false;
> + goto err_mem_free;
>  
>   pr_info("Using %dkB queues\n", 1 << (xive_queue_shift - 10));
>   return true;
> +
> +err_mem_free:
> + xive_irq_bitmap_remove_all();
> +err_unmap:
> + iounmap(tima);
> + return false;
>  }
> 

Re: [PATCH 1/2] powerpc/xive: Use GFP_KERNEL instead of GFP_ATOMIC in 'xive_irq_bitmap_add()'

[Cédric Le Goater]

On 01/08/2019 10:32, Christophe JAILLET wrote:
> There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough.
> GFP_KERNEL is also already used for another allocation just a few lines
> below.

This is correct.
 
> Signed-off-by: Christophe JAILLET 


Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
>  arch/powerpc/sysdev/xive/spapr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/sysdev/xive/spapr.c 
> b/arch/powerpc/sysdev/xive/spapr.c
> index 8ef9cf4ebb1c..b4f5eb9e0f82 100644
> --- a/arch/powerpc/sysdev/xive/spapr.c
> +++ b/arch/powerpc/sysdev/xive/spapr.c
> @@ -45,7 +45,7 @@ static int xive_irq_bitmap_add(int base, int count)
>  {
>   struct xive_irq_bitmap *xibm;
>  
> - xibm = kzalloc(sizeof(*xibm), GFP_ATOMIC);
> + xibm = kzalloc(sizeof(*xibm), GFP_KERNEL);
>   if (!xibm)
>   return -ENOMEM;
>  
> 

Re: [PATCH 1/4] powerpc/powernv: remove the unused pnv_pci_set_p2p function

[Cédric Le Goater]

Hello Christoph,

On 25/06/2019 10:15, Christoph Hellwig wrote:
> This function has never been used anywhere in the kernel tree since it
> was added to the tree.  We also now have proper PCIe P2P APIs in the core
> kernel, and any new P2P support should be using those.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/powerpc/include/asm/opal.h|  7 --
>  arch/powerpc/include/asm/pnv-pci.h |  2 -
>  arch/powerpc/platforms/powernv/opal-call.c |  1 -
>  arch/powerpc/platforms/powernv/pci.c   | 74 --
>  arch/powerpc/platforms/powernv/pci.h   |  5 --
>  5 files changed, 89 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 4cc37e708bc7..7b0bc104a89c 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -280,13 +280,6 @@ int64_t opal_xive_allocate_irq(uint32_t chip_id);
>  int64_t opal_xive_free_irq(uint32_t girq);
>  int64_t opal_xive_sync(uint32_t type, uint32_t id);
>  int64_t opal_xive_dump(uint32_t type, uint32_t id);
> -int64_t opal_xive_get_queue_state(uint64_t vp, uint32_t prio,
> -   __be32 *out_qtoggle,
> -   __be32 *out_qindex);
> -int64_t opal_xive_set_queue_state(uint64_t vp, uint32_t prio,
> -   uint32_t qtoggle,
> -   uint32_t qindex);
> -int64_t opal_xive_get_vp_state(uint64_t vp, __be64 *out_w01);


This hunk seems unrelated.

These OPAL calls are new. They are used by the XIVE KVM device 
to get/set the interrupt controller state of a guest. 


>  int64_t opal_pci_set_p2p(uint64_t phb_init, uint64_t phb_target,
>   uint64_t desc, uint16_t pe_number);

I suppose this is the one ^ you wanted to remove.

Cheers,

C. 



>  
> diff --git a/arch/powerpc/include/asm/pnv-pci.h 
> b/arch/powerpc/include/asm/pnv-pci.h
> index 630eb8b1b7ed..9fcb0bc462c6 100644
> --- a/arch/powerpc/include/asm/pnv-pci.h
> +++ b/arch/powerpc/include/asm/pnv-pci.h
> @@ -26,8 +26,6 @@ extern int pnv_pci_get_presence_state(uint64_t id, uint8_t 
> *state);
>  extern int pnv_pci_get_power_state(uint64_t id, uint8_t *state);
>  extern int pnv_pci_set_power_state(uint64_t id, uint8_t state,
>  struct opal_msg *msg);
> -extern int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target,
> -u64 desc);
>  
>  extern int pnv_pci_enable_tunnel(struct pci_dev *dev, uint64_t *asnind);
>  extern int pnv_pci_disable_tunnel(struct pci_dev *dev);
> diff --git a/arch/powerpc/platforms/powernv/opal-call.c 
> b/arch/powerpc/platforms/powernv/opal-call.c
> index 36c8fa3647a2..29ca523c1c79 100644
> --- a/arch/powerpc/platforms/powernv/opal-call.c
> +++ b/arch/powerpc/platforms/powernv/opal-call.c
> @@ -273,7 +273,6 @@ OPAL_CALL(opal_npu_map_lpar,  
> OPAL_NPU_MAP_LPAR);
>  OPAL_CALL(opal_imc_counters_init,OPAL_IMC_COUNTERS_INIT);
>  OPAL_CALL(opal_imc_counters_start,   OPAL_IMC_COUNTERS_START);
>  OPAL_CALL(opal_imc_counters_stop,OPAL_IMC_COUNTERS_STOP);
> -OPAL_CALL(opal_pci_set_p2p,  OPAL_PCI_SET_P2P);
>  OPAL_CALL(opal_get_powercap, OPAL_GET_POWERCAP);
>  OPAL_CALL(opal_set_powercap, OPAL_SET_POWERCAP);
>  OPAL_CALL(opal_get_power_shift_ratio,
> OPAL_GET_POWER_SHIFT_RATIO);
> diff --git a/arch/powerpc/platforms/powernv/pci.c 
> b/arch/powerpc/platforms/powernv/pci.c
> index ef9448a907c6..8d28f2932c3b 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -38,7 +38,6 @@
>  #include "powernv.h"
>  #include "pci.h"
>  
> -static DEFINE_MUTEX(p2p_mutex);
>  static DEFINE_MUTEX(tunnel_mutex);
>  
>  int pnv_pci_get_slot_id(struct device_node *np, uint64_t *id)
> @@ -861,79 +860,6 @@ void pnv_pci_dma_bus_setup(struct pci_bus *bus)
>   }
>  }
>  
> -int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target, u64 
> desc)
> -{
> - struct pci_controller *hose;
> - struct pnv_phb *phb_init, *phb_target;
> - struct pnv_ioda_pe *pe_init;
> - int rc;
> -
> - if (!opal_check_token(OPAL_PCI_SET_P2P))
> - return -ENXIO;
> -
> - hose = pci_bus_to_host(initiator->bus);
> - phb_init = hose->private_data;
> -
> - hose = pci_bus_to_host(target->bus);
> - phb_target = hose->private_data;
> -
> - pe_init = pnv_ioda_get_pe(initiator);
> - if (!pe_init)
> - return -ENODEV;
> -
> - /*
> -  * Configuring the initiator's PHB requires to adjust its
> -  * TVE#1 setting. Since the same device can be an initiator
> -  * several times for different target devices, we need to keep
> -  * a reference count to know when we can restore the default
> -  * bypass setting on its TVE#1 when disabling. Opal is not
> -  * tracking PE states, so we add a reference count on the PE

Re: [PATCH] powerpc/pseries: Fix xive=off command line

[Cédric Le Goater]

On 5/15/19 12:05 PM, Greg Kurz wrote:
> On POWER9, if the hypervisor supports XIVE exploitation mode, the guest OS
> will unconditionally requests for the XIVE interrupt mode even if XIVE was
> deactivated with the kernel command line xive=off. Later on, when the spapr
> XIVE init code handles xive=off, it disables XIVE and tries to fall back on
> the legacy mode XICS.
> 
> This discrepency causes a kernel panic because the hypervisor is configured
> to provide the XIVE interrupt mode to the guest :
> 
> [0.008837] kernel BUG at arch/powerpc/sysdev/xics/xics-common.c:135!
> [0.008877] Oops: Exception in kernel mode, sig: 5 [#1]
> [0.008908] LE SMP NR_CPUS=1024 NUMA pSeries
> [0.008939] Modules linked in:
> [0.008964] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 
> 5.0.13-200.fc29.ppc64le #1
> [0.009018] NIP:  c1029ab8 LR: c1029aac CTR: 
> c18e
> [0.009065] REGS: c007f96d7900 TRAP: 0700   Tainted: GW
>   (5.0.13-200.fc29.ppc64le)
> [0.009119] MSR:  82029033   CR: 
> 28000222  XER: 2004
> [0.009168] CFAR: c01b1e28 IRQMASK: 0
> [0.009168] GPR00: c1029aac c007f96d7b90 c15e8600 
> 
> [0.009168] GPR04: 0001  0061 
> 646f6d61696e0d0a
> [0.009168] GPR08: 0007fd8f 0001 c14c44c0 
> c007f96d76cf
> [0.009168] GPR12:  c18e 0001 
> 
> [0.009168] GPR16:  0001 c007f96d7c08 
> c16903d0
> [0.009168] GPR20: c007fffe04e8 ffea c1620164 
> c161fe58
> [0.009168] GPR24: c0ea6c88 c11151a8 006000c0 
> c007f96d7c34
> [0.009168] GPR28:  c14b286c c1115180 
> c161dc70
> [0.009558] NIP [c1029ab8] xics_smp_probe+0x38/0x98
> [0.009590] LR [c1029aac] xics_smp_probe+0x2c/0x98
> [0.009622] Call Trace:
> [0.009639] [c007f96d7b90] [c1029aac] xics_smp_probe+0x2c/0x98 
> (unreliable)
> [0.009687] [c007f96d7bb0] [c1033404] 
> pSeries_smp_probe+0x40/0xa0
> [0.009734] [c007f96d7bd0] [c10212a4] 
> smp_prepare_cpus+0x62c/0x6ec
> [0.009782] [c007f96d7cf0] [c10141b8] 
> kernel_init_freeable+0x148/0x448
> [0.009829] [c007f96d7db0] [c0010ba4] kernel_init+0x2c/0x148
> [0.009870] [c007f96d7e20] [c000bdd4] 
> ret_from_kernel_thread+0x5c/0x68
> [0.009916] Instruction dump:
> [0.009940] 7c0802a6 6000 7c0802a6 3882 f8010010 f821ffe1 3c62001c 
> e863b9a0
> [0.009988] 4b1882d1 6000 7c690034 5529d97e <0b09> 3d22001c 
> e929b998 3ce2ff8f
> 
> Look for xive=off during prom_init and don't ask for XIVE in this case. One
> exception though: if the host only supports XIVE, we still want to boot so
> we ignore xive=off.
> 
> Similarly, have the spapr XIVE init code to looking at the interrupt mode
> negociated during CAS, and ignore xive=off if the hypervisor only supports
> XIVE.
> 
> Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt 
> controller")
> Cc: sta...@vger.kernel.org # v4.20
> Reported-by: Pavithra R. Prakash 
> Signed-off-by: Greg Kurz 


Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
> eac1e731b59e is a v4.16 commit actually but this patch only applies
> cleanly to v4.20 and newer. If needed I can send a backport for
> older versions.
> ---
>  arch/powerpc/kernel/prom_init.c  |   16 +++-
>  arch/powerpc/sysdev/xive/spapr.c |   52 
> +-
>  2 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 523bb99d7676..c8f7eb845927 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -172,6 +172,7 @@ static unsigned long __prombss prom_tce_alloc_end;
>  
>  #ifdef CONFIG_PPC_PSERIES
>  static bool __prombss prom_radix_disable;
> +static bool __prombss prom_xive_disable;
>  #endif
>  
>  struct platform_support {
> @@ -808,6 +809,12 @@ static void __init early_cmdline_parse(void)
>   }
>   if (prom_radix_disable)
>   prom_debug("Radix disabled from cmdline\n");
> +
> + opt = prom_strstr(prom_cmd_line, "xive=off");
> + if (opt) {
> + prom_xive_disable = true;
> + prom_debug("XIVE disabled from cmdline\n");
> + }
>  #endif /* CONFIG_PPC_PSERIES */
>  }
>  
> @@ -1

Re: KVM: Introduce a 'release' method for KVM devices

[Cédric Le Goater]

On 5/2/19 4:35 AM, Alexey Kardashevskiy wrote:
> 
> 
> On 02/05/2019 00:42, Colin Ian King wrote:
>> Hi,
>>
>> Static analysis with Coverity picked up an issue in the following commit:
>>
>> commit 2bde9b3ec8bdf60788e9e2ce8c07a2f8d6003dbd
>> Author: Cédric Le Goater 
>> Date:   Thu Apr 18 12:39:41 2019 +0200
>>
>> KVM: Introduce a 'release' method for KVM devices
>>
>>
>> struct kvm *kvm = dev->kvm;
>>
>> +   if (!dev)
>> +   return -ENODEV;
>>
>> If dev is null then the dereference of dev->kvm when assigning pointer
>> kvm will cause an null pointer dereference.  This is easily fixed by
>> assigning kvm after the dev null check.
> 
> Yes, this is a bug.

Clearly.

>>
>> +
>> +   if (dev->kvm != kvm)
>> +   return -EPERM;
>>
>> I don't understand the logic of the above check. kvm is the same
>> dev->kvm on the earlier assignment, so dev->kvm != kvm seems to be
>> always false, so this check seems to be redundant. Am I missing
>> something more fundamental here?
> 
> Nope. This looks like unfortunate cut-n-paste which slipped through out
> reviewing process :-D

Yes. My bad :/ I will send a cleanup patch for 5.2

Thanks,

C.
 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

>>> That seems to suggest that none of the status bits auto-clears, and that
>>> the above code clearing intr_status should be removed entirely.
>>> Am I missing something ?
>>
>> You are right. I just pushed another version of the previous patch with this
>> new hunk :
>>
>> @@ -188,7 +200,6 @@ static void aspeed_i2c_bus_handle_cmd(As
>>   {
>>   bus->cmd &= ~0x;
>>   bus->cmd |= value & 0x;
>> -    bus->intr_status = 0;
>>     if (bus->cmd & I2CD_M_START_CMD) {
>>   uint8_t state = aspeed_i2c_get_state(bus) & I2CD_MACTIVE ?
>>
>>
>> The QEMU palmetto and witherspoon machines seem to behave fine. Can you give
>> it a try ?
>>
> 
> Works fine for me for all affected qemu platforms.
> 
> How do you want to proceed with the qemu patches ? I attached my patches
> for reference. Maybe you can add them to your tree if they are ok and submit
> the entire series together to the qemu mailing list ?

yes. They are pushed in my aspeed-3.1 branch. I will send the series 
on the list.

Thanks,

C. 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

>>> That seems to suggest that none of the status bits auto-clears, and that
>>> the above code clearing intr_status should be removed entirely.
>>> Am I missing something ?
>>
>> You are right. I just pushed another version of the previous patch with this
>> new hunk :
>>
>> @@ -188,7 +200,6 @@ static void aspeed_i2c_bus_handle_cmd(As
>>   {
>>   bus->cmd &= ~0x;
>>   bus->cmd |= value & 0x;
>> -    bus->intr_status = 0;
>>     if (bus->cmd & I2CD_M_START_CMD) {
>>   uint8_t state = aspeed_i2c_get_state(bus) & I2CD_MACTIVE ?
>>
>>
>> The QEMU palmetto and witherspoon machines seem to behave fine. Can you give
>> it a try ?
>>
> 
> Works fine for me for all affected qemu platforms.
> 
> How do you want to proceed with the qemu patches ? I attached my patches
> for reference. Maybe you can add them to your tree if they are ok and submit
> the entire series together to the qemu mailing list ?

yes. They are pushed in my aspeed-3.1 branch. I will send the series 
on the list.

Thanks,

C. 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

Hello ! 

On 09/13/2018 06:31 PM, Jae Hyun Yoo wrote:
> Hi Cédric,
> 
> On 9/12/2018 10:47 PM, Cédric Le Goater wrote:
>> On 09/12/2018 06:54 PM, Jae Hyun Yoo wrote:
>>> On 9/11/2018 6:34 PM, Guenter Roeck wrote:
>>>> On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
>>>>> On 9/11/2018 4:33 PM, Guenter Roeck wrote:
>>>>>> Looking into the patch, clearing the interrupt status at the end of an
>>>>>> interrupt handler is always suspicious and tends to result in race
>>>>>> conditions (because additional interrupts may have arrived while handling
>>>>>> the existing interrupts, or because interrupt handling itself may trigger
>>>>>> another interrupt). With that in mind, the following patch fixes the
>>>>>> problem for me.
>>>>>>
>>>>>> Guenter
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> diff --git a/drivers/i2c/busses/i2c-aspeed.c 
>>>>>> b/drivers/i2c/busses/i2c-aspeed.c
>>>>>> index c258c4d9a4c0..c488e6950b7c 100644
>>>>>> --- a/drivers/i2c/busses/i2c-aspeed.c
>>>>>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>>>>>> @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>>>>> *dev_id)
>>>>>>    spin_lock(>lock);
>>>>>>    irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
>>>>>> +    /* Ack all interrupt bits. */
>>>>>> +    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>>>>>    irq_remaining = irq_received;
>>>>>>    #if IS_ENABLED(CONFIG_I2C_SLAVE)
>>>>>> @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>>>>> *dev_id)
>>>>>>    "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
>>>>>>    irq_received, irq_handled);
>>>>>> -    /* Ack all interrupt bits. */
>>>>>> -    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>>>>>    spin_unlock(>lock);
>>>>>>    return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
>>>>>>    }
>>>>>>
>>>>>
>>>>> My intention of putting the code at the end of interrupt handler was,
>>>>> to reduce possibility of combined irq calls which is explained in this
>>>>> patch. But YES, I agree with you. It could make a potential race
>>>>
>>>> Hmm, yes, but that doesn't explain why it would make sense to acknowledge
>>>> the interrupt late. The interrupt ack only means "I am going to handle 
>>>> these
>>>> interrupts". If additional interrupts arrive while the interrupt handler
>>>> is active, those will have to be acknowledged separately.
>>>>
>>>> Sure, there is a risk that an interrupt arrives while the handler is
>>>> running, and that it is handled but not acknowledged. That can happen
>>>> with pretty much all interrupt handlers, and there are mitigations to
>>>> limit the impact (for example, read the interrupt status register in
>>>> a loop until no more interrupts are pending). But acknowledging
>>>> an interrupt that was possibly not handled is always bad idea.
>>>
>>> Well, that's generally right but not always. Sometimes that depends on
>>> hardware and Aspeed I2C is the case.
>>>
>>> This is a description from Aspeed AST2500 datasheet:
>>>    I2CD10 Interrupt Status Register
>>>    bit 2 Receive Done Interrupt status
>>>  S/W needs to clear this status bit to allow next data receiving.
>>>
>>> It means, driver should hold this bit to prevent transition of hardware
>>> state machine until the driver handles received data, so the bit should
>>> be cleared at the end of interrupt handler.
>>>
>>> Let me share my test result. Your code change works on 100KHz bus speed
>>> but doesn't work well on 1MHz bus speed. Investigated that interrupt
>>> handling is fast enough in 100KHz test but in 1MHz, most of data is
>>> corrupted because the bit is cleared at the beginning of interrupt
>>> handler so it allows receiving of the next data but the interrupt
>>> handler isn't fast enough to read the data buffer on time. I checked
>>> this problem on BMC-ME channel which ME sends lots of IPMB packets to
>>> BMC at 1MHz speed. You could simply check the data corruption problem on
>>> the BMC-ME channel.
>>
>> OK.
>>  
>>> My thought is, the current code is right for real Aspeed I2C hardware.
>>> It seems that QEMU 3.0 model for witherspoon-bmc doesn't simulate the
>>> actual Aspeed I2C hardware correctly.
>>
>> That might be very well possible yes. it also misses support for the slave
>> mode and the DMA registers.
>>
> 
> Yes, it would be good if qemu's Aspeed I2C model supports slave mode.
> Since the current linux Aspeed I2C driver supports byte transfer mode
> only, so DMA transfer mode support in qemu could be considered later.

The Aspeed SDK already does, so yes, we will need to consider it.

> Implementing pool mode and DMA mode for linux Aspeed I2C are in my
> backlog at this moment.

Is there a QEMU model for an I2C/IPMB device ? 

There is already a large IPMI framework in QEMU, that would be interesting.
to extend.

Thanks,

C. 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

Hello ! 

On 09/13/2018 06:31 PM, Jae Hyun Yoo wrote:
> Hi Cédric,
> 
> On 9/12/2018 10:47 PM, Cédric Le Goater wrote:
>> On 09/12/2018 06:54 PM, Jae Hyun Yoo wrote:
>>> On 9/11/2018 6:34 PM, Guenter Roeck wrote:
>>>> On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
>>>>> On 9/11/2018 4:33 PM, Guenter Roeck wrote:
>>>>>> Looking into the patch, clearing the interrupt status at the end of an
>>>>>> interrupt handler is always suspicious and tends to result in race
>>>>>> conditions (because additional interrupts may have arrived while handling
>>>>>> the existing interrupts, or because interrupt handling itself may trigger
>>>>>> another interrupt). With that in mind, the following patch fixes the
>>>>>> problem for me.
>>>>>>
>>>>>> Guenter
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> diff --git a/drivers/i2c/busses/i2c-aspeed.c 
>>>>>> b/drivers/i2c/busses/i2c-aspeed.c
>>>>>> index c258c4d9a4c0..c488e6950b7c 100644
>>>>>> --- a/drivers/i2c/busses/i2c-aspeed.c
>>>>>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>>>>>> @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>>>>> *dev_id)
>>>>>>    spin_lock(>lock);
>>>>>>    irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
>>>>>> +    /* Ack all interrupt bits. */
>>>>>> +    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>>>>>    irq_remaining = irq_received;
>>>>>>    #if IS_ENABLED(CONFIG_I2C_SLAVE)
>>>>>> @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>>>>> *dev_id)
>>>>>>    "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
>>>>>>    irq_received, irq_handled);
>>>>>> -    /* Ack all interrupt bits. */
>>>>>> -    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>>>>>    spin_unlock(>lock);
>>>>>>    return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
>>>>>>    }
>>>>>>
>>>>>
>>>>> My intention of putting the code at the end of interrupt handler was,
>>>>> to reduce possibility of combined irq calls which is explained in this
>>>>> patch. But YES, I agree with you. It could make a potential race
>>>>
>>>> Hmm, yes, but that doesn't explain why it would make sense to acknowledge
>>>> the interrupt late. The interrupt ack only means "I am going to handle 
>>>> these
>>>> interrupts". If additional interrupts arrive while the interrupt handler
>>>> is active, those will have to be acknowledged separately.
>>>>
>>>> Sure, there is a risk that an interrupt arrives while the handler is
>>>> running, and that it is handled but not acknowledged. That can happen
>>>> with pretty much all interrupt handlers, and there are mitigations to
>>>> limit the impact (for example, read the interrupt status register in
>>>> a loop until no more interrupts are pending). But acknowledging
>>>> an interrupt that was possibly not handled is always bad idea.
>>>
>>> Well, that's generally right but not always. Sometimes that depends on
>>> hardware and Aspeed I2C is the case.
>>>
>>> This is a description from Aspeed AST2500 datasheet:
>>>    I2CD10 Interrupt Status Register
>>>    bit 2 Receive Done Interrupt status
>>>  S/W needs to clear this status bit to allow next data receiving.
>>>
>>> It means, driver should hold this bit to prevent transition of hardware
>>> state machine until the driver handles received data, so the bit should
>>> be cleared at the end of interrupt handler.
>>>
>>> Let me share my test result. Your code change works on 100KHz bus speed
>>> but doesn't work well on 1MHz bus speed. Investigated that interrupt
>>> handling is fast enough in 100KHz test but in 1MHz, most of data is
>>> corrupted because the bit is cleared at the beginning of interrupt
>>> handler so it allows receiving of the next data but the interrupt
>>> handler isn't fast enough to read the data buffer on time. I checked
>>> this problem on BMC-ME channel which ME sends lots of IPMB packets to
>>> BMC at 1MHz speed. You could simply check the data corruption problem on
>>> the BMC-ME channel.
>>
>> OK.
>>  
>>> My thought is, the current code is right for real Aspeed I2C hardware.
>>> It seems that QEMU 3.0 model for witherspoon-bmc doesn't simulate the
>>> actual Aspeed I2C hardware correctly.
>>
>> That might be very well possible yes. it also misses support for the slave
>> mode and the DMA registers.
>>
> 
> Yes, it would be good if qemu's Aspeed I2C model supports slave mode.
> Since the current linux Aspeed I2C driver supports byte transfer mode
> only, so DMA transfer mode support in qemu could be considered later.

The Aspeed SDK already does, so yes, we will need to consider it.

> Implementing pool mode and DMA mode for linux Aspeed I2C are in my
> backlog at this moment.

Is there a QEMU model for an I2C/IPMB device ? 

There is already a large IPMI framework in QEMU, that would be interesting.
to extend.

Thanks,

C. 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/13/2018 05:57 PM, Guenter Roeck wrote:
> On Thu, Sep 13, 2018 at 05:48:59PM +0200, Cédric Le Goater wrote:
>> On 09/13/2018 03:33 PM, Guenter Roeck wrote:
> [ ... ]
>>>>>   /*
>>>>>    * The state machine needs some refinement. It is only used to track
>>>>>    * invalid STOP commands for the moment.
>>>>> @@ -188,7 +215,7 @@ static void aspeed_i2c_bus_handle_cmd(AspeedI2CBus 
>>>>> *bus, uint64_t value)
>>>>>   {
>>>>>   bus->cmd &= ~0x;
>>>>>   bus->cmd |= value & 0x;
>>>>> -    bus->intr_status = 0;> +    bus->intr_status &= I2CD_INTR_RX_DONE;
>>>>
>>>> it deserves a comment to understand which scenario we are trying to handle.
>>>>    
>>>
>>> Ok. FWIW, I wonder if intr_status should be touched here in the first place,
>>> but I neither have the hardware nor a datasheet, so I don't know if any bits
>>> are auto-cleared.
>>
>> I just pushed a patch on my branch with some more explanation : 
>>
>>  https://github.com/legoater/qemu/commits/aspeed-3.1
>>
> That seems to suggest that none of the status bits auto-clears, and that
> the above code clearing intr_status should be removed entirely.
> Am I missing something ?

You are right. I just pushed another version of the previous patch with this 
new hunk :

@@ -188,7 +200,6 @@ static void aspeed_i2c_bus_handle_cmd(As
 {
 bus->cmd &= ~0x;
 bus->cmd |= value & 0x;
-bus->intr_status = 0;
 
 if (bus->cmd & I2CD_M_START_CMD) {
 uint8_t state = aspeed_i2c_get_state(bus) & I2CD_MACTIVE ?


The QEMU palmetto and witherspoon machines seem to behave fine. Can you give 
it a try ?

Thanks,

C.

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/13/2018 05:57 PM, Guenter Roeck wrote:
> On Thu, Sep 13, 2018 at 05:48:59PM +0200, Cédric Le Goater wrote:
>> On 09/13/2018 03:33 PM, Guenter Roeck wrote:
> [ ... ]
>>>>>   /*
>>>>>    * The state machine needs some refinement. It is only used to track
>>>>>    * invalid STOP commands for the moment.
>>>>> @@ -188,7 +215,7 @@ static void aspeed_i2c_bus_handle_cmd(AspeedI2CBus 
>>>>> *bus, uint64_t value)
>>>>>   {
>>>>>   bus->cmd &= ~0x;
>>>>>   bus->cmd |= value & 0x;
>>>>> -    bus->intr_status = 0;> +    bus->intr_status &= I2CD_INTR_RX_DONE;
>>>>
>>>> it deserves a comment to understand which scenario we are trying to handle.
>>>>    
>>>
>>> Ok. FWIW, I wonder if intr_status should be touched here in the first place,
>>> but I neither have the hardware nor a datasheet, so I don't know if any bits
>>> are auto-cleared.
>>
>> I just pushed a patch on my branch with some more explanation : 
>>
>>  https://github.com/legoater/qemu/commits/aspeed-3.1
>>
> That seems to suggest that none of the status bits auto-clears, and that
> the above code clearing intr_status should be removed entirely.
> Am I missing something ?

You are right. I just pushed another version of the previous patch with this 
new hunk :

@@ -188,7 +200,6 @@ static void aspeed_i2c_bus_handle_cmd(As
 {
 bus->cmd &= ~0x;
 bus->cmd |= value & 0x;
-bus->intr_status = 0;
 
 if (bus->cmd & I2CD_M_START_CMD) {
 uint8_t state = aspeed_i2c_get_state(bus) & I2CD_MACTIVE ?


The QEMU palmetto and witherspoon machines seem to behave fine. Can you give 
it a try ?

Thanks,

C.

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/13/2018 03:33 PM, Guenter Roeck wrote:
> On 09/12/2018 10:45 PM, Cédric Le Goater wrote
> 
> [ ... ]
> 
>>> ---
>>> qemu:
>>>
>>> diff --git a/hw/i2c/aspeed_i2c.c b/hw/i2c/aspeed_i2c.c
>>> index c762c73..0d4aa08 100644
>>> --- a/hw/i2c/aspeed_i2c.c
>>> +++ b/hw/i2c/aspeed_i2c.c
>>> @@ -180,6 +180,33 @@ static uint8_t aspeed_i2c_get_state(AspeedI2CBus *bus)
>>>   return (bus->cmd >> I2CD_TX_STATE_SHIFT) & I2CD_TX_STATE_MASK;
>>>   }
>>>   +static void aspeed_i2c_handle_rx_cmd(AspeedI2CBus *bus)
>>> +{
>>> +    int ret;
>>> +
>>> +    if (!(bus->cmd & (I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST))) {
>>> +    return;
>>> +    }
>>
>> it deserves a comment to understand which scenario we are trying to handle.
>>
>>> +    if (bus->intr_status & I2CD_INTR_RX_DONE) {
>>> +    return;
>>> +    }
>>
>> should be handled in aspeed_i2c_bus_handle_cmd() I think
>>
> 
> I moved those two checks into the calling code.

ok

 
>>> +    aspeed_i2c_set_state(bus, I2CD_MRXD);
>>> +    ret = i2c_recv(bus->bus);
>>> +    if (ret < 0) {
>>> +    qemu_log_mask(LOG_GUEST_ERROR, "%s: read failed\n", __func__);
>>> +    ret = 0xff;
>>> +    } else {
>>> +    bus->intr_status |= I2CD_INTR_RX_DONE;
>>> +    }
>>> +    bus->buf = (ret & I2CD_BYTE_BUF_RX_MASK) << I2CD_BYTE_BUF_RX_SHIFT;
>>> +    if (bus->cmd & I2CD_M_S_RX_CMD_LAST) {
>>> +    i2c_nack(bus->bus);
>>> +    }
>>> +    bus->cmd &= ~(I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST);
>>> +    aspeed_i2c_set_state(bus, I2CD_MACTIVE);
>>> +}
>>> +
>>>   /*
>>>    * The state machine needs some refinement. It is only used to track
>>>    * invalid STOP commands for the moment.
>>> @@ -188,7 +215,7 @@ static void aspeed_i2c_bus_handle_cmd(AspeedI2CBus 
>>> *bus, uint64_t value)
>>>   {
>>>   bus->cmd &= ~0x;
>>>   bus->cmd |= value & 0x;
>>> -    bus->intr_status = 0;> +    bus->intr_status &= I2CD_INTR_RX_DONE;
>>
>> it deserves a comment to understand which scenario we are trying to handle.
>>    
> 
> Ok. FWIW, I wonder if intr_status should be touched here in the first place,
> but I neither have the hardware nor a datasheet, so I don't know if any bits
> are auto-cleared.

I just pushed a patch on my branch with some more explanation : 

https://github.com/legoater/qemu/commits/aspeed-3.1

> 
>>>   if (bus->cmd & I2CD_M_START_CMD) {
>>>   uint8_t state = aspeed_i2c_get_state(bus) & I2CD_MACTIVE ?
>>> @@ -227,22 +254,7 @@ static void aspeed_i2c_bus_handle_cmd(AspeedI2CBus 
>>> *bus, uint64_t value)
>>>   }
>>>     if (bus->cmd & (I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST)) {
>>> -    int ret;
>>> -
>>> -    aspeed_i2c_set_state(bus, I2CD_MRXD);
>>> -    ret = i2c_recv(bus->bus);
>>> -    if (ret < 0) {
>>> -    qemu_log_mask(LOG_GUEST_ERROR, "%s: read failed\n", __func__);
>>> -    ret = 0xff;
>>> -    } else {
>>> -    bus->intr_status |= I2CD_INTR_RX_DONE;
>>> -    }
>>> -    bus->buf = (ret & I2CD_BYTE_BUF_RX_MASK) << I2CD_BYTE_BUF_RX_SHIFT;
>>> -    if (bus->cmd & I2CD_M_S_RX_CMD_LAST) {
>>> -    i2c_nack(bus->bus);
>>> -    }
>>> -    bus->cmd &= ~(I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST);
>>> -    aspeed_i2c_set_state(bus, I2CD_MACTIVE);
>>> +    aspeed_i2c_handle_rx_cmd(bus);
>>>   }
>>>     if (bus->cmd & I2CD_M_STOP_CMD) {
>>> @@ -263,6 +275,7 @@ static void aspeed_i2c_bus_write(void *opaque, hwaddr 
>>> offset,
>>>    uint64_t value, unsigned size)
>>>   {
>>>   AspeedI2CBus *bus = opaque;
>>> +    int status;
>>>     switch (offset) {
>>>   case I2CD_FUN_CTRL_REG:
>>> @@ -283,9 +296,16 @@ static void aspeed_i2c_bus_write(void *opaque, hwaddr 
>>> offset,
>>>   bus->intr_ctrl = value & 0x7FFF;
>>>   break;
>>>   case I2CD_INTR_STS_REG:
>>> +    status = bus->intr_status;
>>>   bus->intr_status &= ~(value & 0x7FFF);

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/13/2018 03:33 PM, Guenter Roeck wrote:
> On 09/12/2018 10:45 PM, Cédric Le Goater wrote
> 
> [ ... ]
> 
>>> ---
>>> qemu:
>>>
>>> diff --git a/hw/i2c/aspeed_i2c.c b/hw/i2c/aspeed_i2c.c
>>> index c762c73..0d4aa08 100644
>>> --- a/hw/i2c/aspeed_i2c.c
>>> +++ b/hw/i2c/aspeed_i2c.c
>>> @@ -180,6 +180,33 @@ static uint8_t aspeed_i2c_get_state(AspeedI2CBus *bus)
>>>   return (bus->cmd >> I2CD_TX_STATE_SHIFT) & I2CD_TX_STATE_MASK;
>>>   }
>>>   +static void aspeed_i2c_handle_rx_cmd(AspeedI2CBus *bus)
>>> +{
>>> +    int ret;
>>> +
>>> +    if (!(bus->cmd & (I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST))) {
>>> +    return;
>>> +    }
>>
>> it deserves a comment to understand which scenario we are trying to handle.
>>
>>> +    if (bus->intr_status & I2CD_INTR_RX_DONE) {
>>> +    return;
>>> +    }
>>
>> should be handled in aspeed_i2c_bus_handle_cmd() I think
>>
> 
> I moved those two checks into the calling code.

ok

 
>>> +    aspeed_i2c_set_state(bus, I2CD_MRXD);
>>> +    ret = i2c_recv(bus->bus);
>>> +    if (ret < 0) {
>>> +    qemu_log_mask(LOG_GUEST_ERROR, "%s: read failed\n", __func__);
>>> +    ret = 0xff;
>>> +    } else {
>>> +    bus->intr_status |= I2CD_INTR_RX_DONE;
>>> +    }
>>> +    bus->buf = (ret & I2CD_BYTE_BUF_RX_MASK) << I2CD_BYTE_BUF_RX_SHIFT;
>>> +    if (bus->cmd & I2CD_M_S_RX_CMD_LAST) {
>>> +    i2c_nack(bus->bus);
>>> +    }
>>> +    bus->cmd &= ~(I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST);
>>> +    aspeed_i2c_set_state(bus, I2CD_MACTIVE);
>>> +}
>>> +
>>>   /*
>>>    * The state machine needs some refinement. It is only used to track
>>>    * invalid STOP commands for the moment.
>>> @@ -188,7 +215,7 @@ static void aspeed_i2c_bus_handle_cmd(AspeedI2CBus 
>>> *bus, uint64_t value)
>>>   {
>>>   bus->cmd &= ~0x;
>>>   bus->cmd |= value & 0x;
>>> -    bus->intr_status = 0;> +    bus->intr_status &= I2CD_INTR_RX_DONE;
>>
>> it deserves a comment to understand which scenario we are trying to handle.
>>    
> 
> Ok. FWIW, I wonder if intr_status should be touched here in the first place,
> but I neither have the hardware nor a datasheet, so I don't know if any bits
> are auto-cleared.

I just pushed a patch on my branch with some more explanation : 

https://github.com/legoater/qemu/commits/aspeed-3.1

> 
>>>   if (bus->cmd & I2CD_M_START_CMD) {
>>>   uint8_t state = aspeed_i2c_get_state(bus) & I2CD_MACTIVE ?
>>> @@ -227,22 +254,7 @@ static void aspeed_i2c_bus_handle_cmd(AspeedI2CBus 
>>> *bus, uint64_t value)
>>>   }
>>>     if (bus->cmd & (I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST)) {
>>> -    int ret;
>>> -
>>> -    aspeed_i2c_set_state(bus, I2CD_MRXD);
>>> -    ret = i2c_recv(bus->bus);
>>> -    if (ret < 0) {
>>> -    qemu_log_mask(LOG_GUEST_ERROR, "%s: read failed\n", __func__);
>>> -    ret = 0xff;
>>> -    } else {
>>> -    bus->intr_status |= I2CD_INTR_RX_DONE;
>>> -    }
>>> -    bus->buf = (ret & I2CD_BYTE_BUF_RX_MASK) << I2CD_BYTE_BUF_RX_SHIFT;
>>> -    if (bus->cmd & I2CD_M_S_RX_CMD_LAST) {
>>> -    i2c_nack(bus->bus);
>>> -    }
>>> -    bus->cmd &= ~(I2CD_M_RX_CMD | I2CD_M_S_RX_CMD_LAST);
>>> -    aspeed_i2c_set_state(bus, I2CD_MACTIVE);
>>> +    aspeed_i2c_handle_rx_cmd(bus);
>>>   }
>>>     if (bus->cmd & I2CD_M_STOP_CMD) {
>>> @@ -263,6 +275,7 @@ static void aspeed_i2c_bus_write(void *opaque, hwaddr 
>>> offset,
>>>    uint64_t value, unsigned size)
>>>   {
>>>   AspeedI2CBus *bus = opaque;
>>> +    int status;
>>>     switch (offset) {
>>>   case I2CD_FUN_CTRL_REG:
>>> @@ -283,9 +296,16 @@ static void aspeed_i2c_bus_write(void *opaque, hwaddr 
>>> offset,
>>>   bus->intr_ctrl = value & 0x7FFF;
>>>   break;
>>>   case I2CD_INTR_STS_REG:
>>> +    status = bus->intr_status;
>>>   bus->intr_status &= ~(value & 0x7FFF);

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/12/2018 06:54 PM, Jae Hyun Yoo wrote:
> On 9/11/2018 6:34 PM, Guenter Roeck wrote:
>> On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
>>> On 9/11/2018 4:33 PM, Guenter Roeck wrote:
 Looking into the patch, clearing the interrupt status at the end of an
 interrupt handler is always suspicious and tends to result in race
 conditions (because additional interrupts may have arrived while handling
 the existing interrupts, or because interrupt handling itself may trigger
 another interrupt). With that in mind, the following patch fixes the
 problem for me.

 Guenter

 ---

 diff --git a/drivers/i2c/busses/i2c-aspeed.c 
 b/drivers/i2c/busses/i2c-aspeed.c
 index c258c4d9a4c0..c488e6950b7c 100644
 --- a/drivers/i2c/busses/i2c-aspeed.c
 +++ b/drivers/i2c/busses/i2c-aspeed.c
 @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
 *dev_id)
   spin_lock(>lock);
   irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
 +    /* Ack all interrupt bits. */
 +    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
   irq_remaining = irq_received;
   #if IS_ENABLED(CONFIG_I2C_SLAVE)
 @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
 *dev_id)
   "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
   irq_received, irq_handled);
 -    /* Ack all interrupt bits. */
 -    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
   spin_unlock(>lock);
   return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
   }

>>>
>>> My intention of putting the code at the end of interrupt handler was,
>>> to reduce possibility of combined irq calls which is explained in this
>>> patch. But YES, I agree with you. It could make a potential race
>>
>> Hmm, yes, but that doesn't explain why it would make sense to acknowledge
>> the interrupt late. The interrupt ack only means "I am going to handle these
>> interrupts". If additional interrupts arrive while the interrupt handler
>> is active, those will have to be acknowledged separately.
>>
>> Sure, there is a risk that an interrupt arrives while the handler is
>> running, and that it is handled but not acknowledged. That can happen
>> with pretty much all interrupt handlers, and there are mitigations to
>> limit the impact (for example, read the interrupt status register in
>> a loop until no more interrupts are pending). But acknowledging
>> an interrupt that was possibly not handled is always bad idea.
> 
> Well, that's generally right but not always. Sometimes that depends on
> hardware and Aspeed I2C is the case.
> 
> This is a description from Aspeed AST2500 datasheet:
>   I2CD10 Interrupt Status Register
>   bit 2 Receive Done Interrupt status
>     S/W needs to clear this status bit to allow next data receiving.
> 
> It means, driver should hold this bit to prevent transition of hardware
> state machine until the driver handles received data, so the bit should
> be cleared at the end of interrupt handler.
> 
> Let me share my test result. Your code change works on 100KHz bus speed
> but doesn't work well on 1MHz bus speed. Investigated that interrupt
> handling is fast enough in 100KHz test but in 1MHz, most of data is
> corrupted because the bit is cleared at the beginning of interrupt
> handler so it allows receiving of the next data but the interrupt
> handler isn't fast enough to read the data buffer on time. I checked
> this problem on BMC-ME channel which ME sends lots of IPMB packets to
> BMC at 1MHz speed. You could simply check the data corruption problem on
> the BMC-ME channel.

OK.
 
> My thought is, the current code is right for real Aspeed I2C hardware.
> It seems that QEMU 3.0 model for witherspoon-bmc doesn't simulate the
> actual Aspeed I2C hardware correctly.

That might be very well possible yes. it also misses support for the slave 
mode and the DMA registers.

Thanks for the info,

C.

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/12/2018 06:54 PM, Jae Hyun Yoo wrote:
> On 9/11/2018 6:34 PM, Guenter Roeck wrote:
>> On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
>>> On 9/11/2018 4:33 PM, Guenter Roeck wrote:
 Looking into the patch, clearing the interrupt status at the end of an
 interrupt handler is always suspicious and tends to result in race
 conditions (because additional interrupts may have arrived while handling
 the existing interrupts, or because interrupt handling itself may trigger
 another interrupt). With that in mind, the following patch fixes the
 problem for me.

 Guenter

 ---

 diff --git a/drivers/i2c/busses/i2c-aspeed.c 
 b/drivers/i2c/busses/i2c-aspeed.c
 index c258c4d9a4c0..c488e6950b7c 100644
 --- a/drivers/i2c/busses/i2c-aspeed.c
 +++ b/drivers/i2c/busses/i2c-aspeed.c
 @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
 *dev_id)
   spin_lock(>lock);
   irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
 +    /* Ack all interrupt bits. */
 +    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
   irq_remaining = irq_received;
   #if IS_ENABLED(CONFIG_I2C_SLAVE)
 @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
 *dev_id)
   "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
   irq_received, irq_handled);
 -    /* Ack all interrupt bits. */
 -    writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
   spin_unlock(>lock);
   return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
   }

>>>
>>> My intention of putting the code at the end of interrupt handler was,
>>> to reduce possibility of combined irq calls which is explained in this
>>> patch. But YES, I agree with you. It could make a potential race
>>
>> Hmm, yes, but that doesn't explain why it would make sense to acknowledge
>> the interrupt late. The interrupt ack only means "I am going to handle these
>> interrupts". If additional interrupts arrive while the interrupt handler
>> is active, those will have to be acknowledged separately.
>>
>> Sure, there is a risk that an interrupt arrives while the handler is
>> running, and that it is handled but not acknowledged. That can happen
>> with pretty much all interrupt handlers, and there are mitigations to
>> limit the impact (for example, read the interrupt status register in
>> a loop until no more interrupts are pending). But acknowledging
>> an interrupt that was possibly not handled is always bad idea.
> 
> Well, that's generally right but not always. Sometimes that depends on
> hardware and Aspeed I2C is the case.
> 
> This is a description from Aspeed AST2500 datasheet:
>   I2CD10 Interrupt Status Register
>   bit 2 Receive Done Interrupt status
>     S/W needs to clear this status bit to allow next data receiving.
> 
> It means, driver should hold this bit to prevent transition of hardware
> state machine until the driver handles received data, so the bit should
> be cleared at the end of interrupt handler.
> 
> Let me share my test result. Your code change works on 100KHz bus speed
> but doesn't work well on 1MHz bus speed. Investigated that interrupt
> handling is fast enough in 100KHz test but in 1MHz, most of data is
> corrupted because the bit is cleared at the beginning of interrupt
> handler so it allows receiving of the next data but the interrupt
> handler isn't fast enough to read the data buffer on time. I checked
> this problem on BMC-ME channel which ME sends lots of IPMB packets to
> BMC at 1MHz speed. You could simply check the data corruption problem on
> the BMC-ME channel.

OK.
 
> My thought is, the current code is right for real Aspeed I2C hardware.
> It seems that QEMU 3.0 model for witherspoon-bmc doesn't simulate the
> actual Aspeed I2C hardware correctly.

That might be very well possible yes. it also misses support for the slave 
mode and the DMA registers.

Thanks for the info,

C.

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/12/2018 10:30 PM, Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 01:10:45PM -0700, Jae Hyun Yoo wrote:
>> On 9/12/2018 12:58 PM, Guenter Roeck wrote:
>>> On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
 On 9/11/2018 6:34 PM, Guenter Roeck wrote:
> On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
>> On 9/11/2018 4:33 PM, Guenter Roeck wrote:
>>> Looking into the patch, clearing the interrupt status at the end of an
>>> interrupt handler is always suspicious and tends to result in race
>>> conditions (because additional interrupts may have arrived while 
>>> handling
>>> the existing interrupts, or because interrupt handling itself may 
>>> trigger
>>> another interrupt). With that in mind, the following patch fixes the
>>> problem for me.
>>>
>>> Guenter
>>>
>>> ---
>>>
>>> diff --git a/drivers/i2c/busses/i2c-aspeed.c 
>>> b/drivers/i2c/busses/i2c-aspeed.c
>>> index c258c4d9a4c0..c488e6950b7c 100644
>>> --- a/drivers/i2c/busses/i2c-aspeed.c
>>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>>> @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>> *dev_id)
>>> spin_lock(>lock);
>>> irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
>>> +   /* Ack all interrupt bits. */
>>> +   writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>> irq_remaining = irq_received;
>>>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
>>> @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>> *dev_id)
>>> "irq handled != irq. expected 0x%08x, but was 
>>> 0x%08x\n",
>>> irq_received, irq_handled);
>>> -   /* Ack all interrupt bits. */
>>> -   writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>> spin_unlock(>lock);
>>> return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
>>>  }
>>>
>>
>> My intention of putting the code at the end of interrupt handler was,
>> to reduce possibility of combined irq calls which is explained in this
>> patch. But YES, I agree with you. It could make a potential race
>
> Hmm, yes, but that doesn't explain why it would make sense to acknowledge
> the interrupt late. The interrupt ack only means "I am going to handle 
> these
> interrupts". If additional interrupts arrive while the interrupt handler
> is active, those will have to be acknowledged separately.
>
> Sure, there is a risk that an interrupt arrives while the handler is
> running, and that it is handled but not acknowledged. That can happen
> with pretty much all interrupt handlers, and there are mitigations to
> limit the impact (for example, read the interrupt status register in
> a loop until no more interrupts are pending). But acknowledging
> an interrupt that was possibly not handled is always bad idea.

 Well, that's generally right but not always. Sometimes that depends on
 hardware and Aspeed I2C is the case.

 This is a description from Aspeed AST2500 datasheet:
   I2CD10 Interrupt Status Register
   bit 2 Receive Done Interrupt status
 S/W needs to clear this status bit to allow next data receiving.

 It means, driver should hold this bit to prevent transition of hardware
 state machine until the driver handles received data, so the bit should
 be cleared at the end of interrupt handler.

>>> That makes sense. Does that apply to the other status bits as well ?
>>> Reason for asking is that the current code actually gets stuck
>>> in transmit, not receive.
>>>
>> Only bit 2 has that description in datasheet. Is slave config enabled
>> for QEMU build? Does that get stuck in master sending or slave
>> receiving?
>>
> qemu does not support slave mode. Linux gets stuck in master tx.
> 
> I played with the code on both sides. I had to make changes in both
> the linux kernel and in qemu to get the code to work again.
> See attached.
> 
> Guenter
> 
> ---
> Linux:
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index c258c4d9a4c0..3d518e09369f 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -552,6 +552,9 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>  
>   spin_lock(>lock);
>   irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> + /* Ack all interrupts except for Rx done */
> + writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
> +bus->base + ASPEED_I2C_INTR_STS_REG);
>   irq_remaining = irq_received;
>  
>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> @@ -584,8 +587,10 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>   "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
>   irq_received, 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/12/2018 10:30 PM, Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 01:10:45PM -0700, Jae Hyun Yoo wrote:
>> On 9/12/2018 12:58 PM, Guenter Roeck wrote:
>>> On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
 On 9/11/2018 6:34 PM, Guenter Roeck wrote:
> On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
>> On 9/11/2018 4:33 PM, Guenter Roeck wrote:
>>> Looking into the patch, clearing the interrupt status at the end of an
>>> interrupt handler is always suspicious and tends to result in race
>>> conditions (because additional interrupts may have arrived while 
>>> handling
>>> the existing interrupts, or because interrupt handling itself may 
>>> trigger
>>> another interrupt). With that in mind, the following patch fixes the
>>> problem for me.
>>>
>>> Guenter
>>>
>>> ---
>>>
>>> diff --git a/drivers/i2c/busses/i2c-aspeed.c 
>>> b/drivers/i2c/busses/i2c-aspeed.c
>>> index c258c4d9a4c0..c488e6950b7c 100644
>>> --- a/drivers/i2c/busses/i2c-aspeed.c
>>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>>> @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>> *dev_id)
>>> spin_lock(>lock);
>>> irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
>>> +   /* Ack all interrupt bits. */
>>> +   writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>> irq_remaining = irq_received;
>>>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
>>> @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
>>> *dev_id)
>>> "irq handled != irq. expected 0x%08x, but was 
>>> 0x%08x\n",
>>> irq_received, irq_handled);
>>> -   /* Ack all interrupt bits. */
>>> -   writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>>> spin_unlock(>lock);
>>> return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
>>>  }
>>>
>>
>> My intention of putting the code at the end of interrupt handler was,
>> to reduce possibility of combined irq calls which is explained in this
>> patch. But YES, I agree with you. It could make a potential race
>
> Hmm, yes, but that doesn't explain why it would make sense to acknowledge
> the interrupt late. The interrupt ack only means "I am going to handle 
> these
> interrupts". If additional interrupts arrive while the interrupt handler
> is active, those will have to be acknowledged separately.
>
> Sure, there is a risk that an interrupt arrives while the handler is
> running, and that it is handled but not acknowledged. That can happen
> with pretty much all interrupt handlers, and there are mitigations to
> limit the impact (for example, read the interrupt status register in
> a loop until no more interrupts are pending). But acknowledging
> an interrupt that was possibly not handled is always bad idea.

 Well, that's generally right but not always. Sometimes that depends on
 hardware and Aspeed I2C is the case.

 This is a description from Aspeed AST2500 datasheet:
   I2CD10 Interrupt Status Register
   bit 2 Receive Done Interrupt status
 S/W needs to clear this status bit to allow next data receiving.

 It means, driver should hold this bit to prevent transition of hardware
 state machine until the driver handles received data, so the bit should
 be cleared at the end of interrupt handler.

>>> That makes sense. Does that apply to the other status bits as well ?
>>> Reason for asking is that the current code actually gets stuck
>>> in transmit, not receive.
>>>
>> Only bit 2 has that description in datasheet. Is slave config enabled
>> for QEMU build? Does that get stuck in master sending or slave
>> receiving?
>>
> qemu does not support slave mode. Linux gets stuck in master tx.
> 
> I played with the code on both sides. I had to make changes in both
> the linux kernel and in qemu to get the code to work again.
> See attached.
> 
> Guenter
> 
> ---
> Linux:
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index c258c4d9a4c0..3d518e09369f 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -552,6 +552,9 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>  
>   spin_lock(>lock);
>   irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> + /* Ack all interrupts except for Rx done */
> + writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
> +bus->base + ASPEED_I2C_INTR_STS_REG);
>   irq_remaining = irq_received;
>  
>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> @@ -584,8 +587,10 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>   "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
>   irq_received, 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/12/2018 01:33 AM, Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 08:23:29AM +0930, Joel Stanley wrote:
>> On Wed, 12 Sep 2018 at 07:48, Jae Hyun Yoo  
>> wrote:
>>>
>>> On 9/11/2018 1:41 PM, Guenter Roeck wrote:
>>>> On Tue, Sep 11, 2018 at 01:30:41PM -0700, Jae Hyun Yoo wrote:
>>
>>>>> I checked this patch again but it doesn't have any change that could
>>>>> affect to the probing flow. I'll debug the issue on qemu 3.0 environment
>>>>> and will share if I find something.
>>>>>
>>>> The problem may be that qemu and the new code disagree how interrupts
>>>> should be generated and handled, and the new code does not handle the
>>>> interrupts it receives from the simulated hardware. This will result
>>>> in i2c device probe failure, which in turn can cause all kinds of
>>>> problems.
>>>>
>>>
>>> Yes, that makes sense. Looks like it should be reverted until the issue
>>> is fixed. Will submit a patch to revert it.
>>
>> Let's not rush. The qemu model was written in order to allow us to
>> test the kernel code, and was validated by the kernel driver we have.
>> We've had situations in the past (with the i2c driver in fact) where a
>> change in the driver required an update of the model to be more
>> accurate.
>>
>> I suggest we wait until Cedric has a chance to look at the issue
>> before reverting the patch.
>>
> 
> Looking into the patch, clearing the interrupt status at the end of an
> interrupt handler is always suspicious and tends to result in race

yes. That happened in the past with the I2C aspeed driver. I can not find
the thread anymore but we had to move up the ack of the interrupts. 

QEMU tends to be much faster to fire interrupts than real HW.


> conditions (because additional interrupts may have arrived while handling
> the existing interrupts, or because interrupt handling itself may trigger
> another interrupt). With that in mind, the following patch fixes the
> problem for me.

Acked-by: Cédric Le Goater 

Thanks,

C.

> Guenter
> 
> ---
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index c258c4d9a4c0..c488e6950b7c 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>  
>   spin_lock(>lock);
>   irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> + /* Ack all interrupt bits. */
> + writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>   irq_remaining = irq_received;
>  
>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>   "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
>   irq_received, irq_handled);
>  
> - /* Ack all interrupt bits. */
> - writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>   spin_unlock(>lock);
>   return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
>  }
> 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/12/2018 01:33 AM, Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 08:23:29AM +0930, Joel Stanley wrote:
>> On Wed, 12 Sep 2018 at 07:48, Jae Hyun Yoo  
>> wrote:
>>>
>>> On 9/11/2018 1:41 PM, Guenter Roeck wrote:
>>>> On Tue, Sep 11, 2018 at 01:30:41PM -0700, Jae Hyun Yoo wrote:
>>
>>>>> I checked this patch again but it doesn't have any change that could
>>>>> affect to the probing flow. I'll debug the issue on qemu 3.0 environment
>>>>> and will share if I find something.
>>>>>
>>>> The problem may be that qemu and the new code disagree how interrupts
>>>> should be generated and handled, and the new code does not handle the
>>>> interrupts it receives from the simulated hardware. This will result
>>>> in i2c device probe failure, which in turn can cause all kinds of
>>>> problems.
>>>>
>>>
>>> Yes, that makes sense. Looks like it should be reverted until the issue
>>> is fixed. Will submit a patch to revert it.
>>
>> Let's not rush. The qemu model was written in order to allow us to
>> test the kernel code, and was validated by the kernel driver we have.
>> We've had situations in the past (with the i2c driver in fact) where a
>> change in the driver required an update of the model to be more
>> accurate.
>>
>> I suggest we wait until Cedric has a chance to look at the issue
>> before reverting the patch.
>>
> 
> Looking into the patch, clearing the interrupt status at the end of an
> interrupt handler is always suspicious and tends to result in race

yes. That happened in the past with the I2C aspeed driver. I can not find
the thread anymore but we had to move up the ack of the interrupts. 

QEMU tends to be much faster to fire interrupts than real HW.


> conditions (because additional interrupts may have arrived while handling
> the existing interrupts, or because interrupt handling itself may trigger
> another interrupt). With that in mind, the following patch fixes the
> problem for me.

Acked-by: Cédric Le Goater 

Thanks,

C.

> Guenter
> 
> ---
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index c258c4d9a4c0..c488e6950b7c 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -552,6 +552,8 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>  
>   spin_lock(>lock);
>   irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> + /* Ack all interrupt bits. */
> + writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>   irq_remaining = irq_received;
>  
>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> @@ -584,8 +586,6 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void 
> *dev_id)
>   "irq handled != irq. expected 0x%08x, but was 0x%08x\n",
>   irq_received, irq_handled);
>  
> - /* Ack all interrupt bits. */
> - writel(irq_received, bus->base + ASPEED_I2C_INTR_STS_REG);
>   spin_unlock(>lock);
>   return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
>  }
> 

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/11/2018 08:37 PM, Guenter Roeck wrote:
> Hi,
> 
> On Thu, Aug 23, 2018 at 03:57:31PM -0700, Jae Hyun Yoo wrote:
>> In most of cases, interrupt bits are set one by one but there are
>> also a lot of other cases that Aspeed I2C IP sends multiple
>> interrupt bits with combining master and slave events using a
>> single interrupt call. It happens much more in multi-master
>> environment than single-master. For an example, when master is
>> waiting for a NORMAL_STOP interrupt in its MASTER_STOP state,
>> SLAVE_MATCH and RX_DONE interrupts could come along with the
>> NORMAL_STOP in case of an another master immediately sends data
>> just after acquiring the bus. In this case, the NORMAL_STOP
>> interrupt should be handled by master_irq and the SLAVE_MATCH and
>> RX_DONE interrupts should be handled by slave_irq. This commit
>> modifies irq hadling logic to handle the master/slave combined
>> events properly.
>>
>> Signed-off-by: Jae Hyun Yoo 
>> Reviewed-by: Brendan Higgins 
> 
> This patch causes a boot stall when booting witherspoon-bmc with
> qemu v3.0, and all i2c device probes fail with error -110 (timeout).
> Bisect log is attached for reference.
> 
> With the same kernel configuration (aspeed_g5_defconfig),
> ast2500-evb and romulus-bmc are still able to boot.
> palmetto-bmc with aspeed_g4_defconfig also appears to work.
> 
> Is this a problem with qemu ? Should I drop the qemu test
> for witherspoon-bmc starting with the next kernel release ?

The QEMU model for the Aspeed I2C controller does not support 
slave mode or DMA registers. That might be the issue. 

I will check what this patch does when I have sometime. 

Thanks, 


C.

Re: [PATCH i2c-next v6] i2c: aspeed: Handle master/slave combined irq events properly

[Cédric Le Goater]

On 09/11/2018 08:37 PM, Guenter Roeck wrote:
> Hi,
> 
> On Thu, Aug 23, 2018 at 03:57:31PM -0700, Jae Hyun Yoo wrote:
>> In most of cases, interrupt bits are set one by one but there are
>> also a lot of other cases that Aspeed I2C IP sends multiple
>> interrupt bits with combining master and slave events using a
>> single interrupt call. It happens much more in multi-master
>> environment than single-master. For an example, when master is
>> waiting for a NORMAL_STOP interrupt in its MASTER_STOP state,
>> SLAVE_MATCH and RX_DONE interrupts could come along with the
>> NORMAL_STOP in case of an another master immediately sends data
>> just after acquiring the bus. In this case, the NORMAL_STOP
>> interrupt should be handled by master_irq and the SLAVE_MATCH and
>> RX_DONE interrupts should be handled by slave_irq. This commit
>> modifies irq hadling logic to handle the master/slave combined
>> events properly.
>>
>> Signed-off-by: Jae Hyun Yoo 
>> Reviewed-by: Brendan Higgins 
> 
> This patch causes a boot stall when booting witherspoon-bmc with
> qemu v3.0, and all i2c device probes fail with error -110 (timeout).
> Bisect log is attached for reference.
> 
> With the same kernel configuration (aspeed_g5_defconfig),
> ast2500-evb and romulus-bmc are still able to boot.
> palmetto-bmc with aspeed_g4_defconfig also appears to work.
> 
> Is this a problem with qemu ? Should I drop the qemu test
> for witherspoon-bmc starting with the next kernel release ?

The QEMU model for the Aspeed I2C controller does not support 
slave mode or DMA registers. That might be the issue. 

I will check what this patch does when I have sometime. 

Thanks, 


C.

Re: [PATCH 07/13] ocxl: Add AFU interrupt support

[Cédric Le Goater]

On 12/19/2017 04:05 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2017-12-18 at 16:21 +0100, Frederic Barrat wrote:
>> Add user APIs through ioctl to allocate, free, and be notified of an
>> AFU interrupt.
>>
>> For opencapi, an AFU can trigger an interrupt on the host by sending a
>> specific command targeting a 64-bit object handle. On POWER9, this is
>> implemented by mapping a special page in the address space of a
>> process and a write to that page will trigger an interrupt.
> 
> We need to figure out how that plays with KVM. +Cedric..
> 
> For all those "generic xive" interrupts, whether they are used for
> OpenCAPI, plain guest IPIs, NX interrupts etc... but also for actual
> pass-through ones, we'll need a mechanism to map the trigger and ESB
> pages into qemu.
It seems feasible to use a common driver, at least for QEMU/KVM 
and OCXL, to expose the ESB pages of a range of IRQ numbers. Fred 
has already defined a user API, a set of ioctl which allocate, free 
one IRQ and also associate an IRQ with an eventfd for handling. 
The VMA is populated on demand. 

This XIVE IRQ "device", that I don't know how to name, defines 
generic IRQ sources and handlers for a given range. We would need 
a couple of properties to describe it in a device tree, 

  - "ibm,xive-lisn-ranges" for the range.
  
Anymore ? 

The current code needs some changes to distinguish the XIVE IRQ 
driver from the OCXL one, range support should be added, using a 
bitmap to track allocation I guess.

>From a OCXL perspective, the XIVE IRQ device driver would be 
instantiated from the OCXL one using an ioctl returning an fd,
like KVM does with KVM devices. User space would then alloc, free, 
associate IRQs and mmap the ESB pages to configure the OpenCAPI 
device. As for QEMU, I think we could add an extra KVM device, 
QEMU does not need the 'associate' feature though.

Such devices could theoretically be defined by the firmware for 
general purpose also, and be used through a char device. This is 
a possibility.


> We can't have a bazillion VMAs and KVM memory regions either, so we'll
> need some kind of mechanism/driver which allows for a single fairly
> large mmap'ed VMA which can then be "populated" with interrupt control
> pages.

yes. the full address range should mmapped for the IRQ range defined
for the device. access to pages not populated would return EFAULT.  
 
> The issue of course is that we can't really do a "generic" system that
> allows to map any interrupt, it's a security issue. So we need the
> interrupt "owner" to be the one allowing this. VFIO for PCI for
> example, possibly a specific VFIO variant for OpenCAPI, something else
> for guest IPIs ?
If we have defined ranges per devices, that should be enough no ?

Thanks,

C. 
 
> Food for thoughts...
> 
> Ben.
> 
>>
>> Signed-off-by: Frederic Barrat 
>> ---
>>  arch/powerpc/include/asm/pnv-ocxl.h   |   3 +
>>  arch/powerpc/platforms/powernv/ocxl.c |  30 +
>>  drivers/misc/ocxl/afu_irq.c   | 204 
>> ++
>>  drivers/misc/ocxl/context.c   |  40 ++-
>>  drivers/misc/ocxl/file.c  |  33 ++
>>  drivers/misc/ocxl/link.c  |  28 +
>>  drivers/misc/ocxl/ocxl_internal.h |   7 ++
>>  include/uapi/misc/ocxl.h  |   9 ++
>>  8 files changed, 352 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/misc/ocxl/afu_irq.c
>>
>> diff --git a/arch/powerpc/include/asm/pnv-ocxl.h 
>> b/arch/powerpc/include/asm/pnv-ocxl.h
>> index 5a7ae7f28209..1e26f0a39500 100644
>> --- a/arch/powerpc/include/asm/pnv-ocxl.h
>> +++ b/arch/powerpc/include/asm/pnv-ocxl.h
>> @@ -37,4 +37,7 @@ extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void 
>> *spa_mem, int PE_mask,
>>  extern void pnv_ocxl_spa_release(void *platform_data);
>>  extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle);
>>  
>> +extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
>> +extern void pnv_ocxl_free_xive_irq(u32 irq);
>> +
>>  #endif /* _ASM_PVN_OCXL_H */
>> diff --git a/arch/powerpc/platforms/powernv/ocxl.c 
>> b/arch/powerpc/platforms/powernv/ocxl.c
>> index 6c79924b95c8..96cafba6aef1 100644
>> --- a/arch/powerpc/platforms/powernv/ocxl.c
>> +++ b/arch/powerpc/platforms/powernv/ocxl.c
>> @@ -9,6 +9,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include "pci.h"
>>  
>> @@ -487,3 +488,32 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int 
>> pe_handle)
>>  return rc;
>>  }
>>  EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe);
>> +
>> +int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
>> +{
>> +__be64 flags, trigger_page;
>> +s64 rc;
>> +u32 hwirq;
>> +
>> +hwirq = xive_native_alloc_irq();
>> +if (!hwirq)
>> +return -ENOENT;
>> +
>> +rc = opal_xive_get_irq_info(hwirq, , NULL, _page, NULL,
>> +NULL);
>> +if (rc || !trigger_page) {
>> +xive_native_free_irq(hwirq);

Re: [PATCH 07/13] ocxl: Add AFU interrupt support

[Cédric Le Goater]

On 12/19/2017 04:05 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2017-12-18 at 16:21 +0100, Frederic Barrat wrote:
>> Add user APIs through ioctl to allocate, free, and be notified of an
>> AFU interrupt.
>>
>> For opencapi, an AFU can trigger an interrupt on the host by sending a
>> specific command targeting a 64-bit object handle. On POWER9, this is
>> implemented by mapping a special page in the address space of a
>> process and a write to that page will trigger an interrupt.
> 
> We need to figure out how that plays with KVM. +Cedric..
> 
> For all those "generic xive" interrupts, whether they are used for
> OpenCAPI, plain guest IPIs, NX interrupts etc... but also for actual
> pass-through ones, we'll need a mechanism to map the trigger and ESB
> pages into qemu.
It seems feasible to use a common driver, at least for QEMU/KVM 
and OCXL, to expose the ESB pages of a range of IRQ numbers. Fred 
has already defined a user API, a set of ioctl which allocate, free 
one IRQ and also associate an IRQ with an eventfd for handling. 
The VMA is populated on demand. 

This XIVE IRQ "device", that I don't know how to name, defines 
generic IRQ sources and handlers for a given range. We would need 
a couple of properties to describe it in a device tree, 

  - "ibm,xive-lisn-ranges" for the range.
  
Anymore ? 

The current code needs some changes to distinguish the XIVE IRQ 
driver from the OCXL one, range support should be added, using a 
bitmap to track allocation I guess.

>From a OCXL perspective, the XIVE IRQ device driver would be 
instantiated from the OCXL one using an ioctl returning an fd,
like KVM does with KVM devices. User space would then alloc, free, 
associate IRQs and mmap the ESB pages to configure the OpenCAPI 
device. As for QEMU, I think we could add an extra KVM device, 
QEMU does not need the 'associate' feature though.

Such devices could theoretically be defined by the firmware for 
general purpose also, and be used through a char device. This is 
a possibility.


> We can't have a bazillion VMAs and KVM memory regions either, so we'll
> need some kind of mechanism/driver which allows for a single fairly
> large mmap'ed VMA which can then be "populated" with interrupt control
> pages.

yes. the full address range should mmapped for the IRQ range defined
for the device. access to pages not populated would return EFAULT.  
 
> The issue of course is that we can't really do a "generic" system that
> allows to map any interrupt, it's a security issue. So we need the
> interrupt "owner" to be the one allowing this. VFIO for PCI for
> example, possibly a specific VFIO variant for OpenCAPI, something else
> for guest IPIs ?
If we have defined ranges per devices, that should be enough no ?

Thanks,

C. 
 
> Food for thoughts...
> 
> Ben.
> 
>>
>> Signed-off-by: Frederic Barrat 
>> ---
>>  arch/powerpc/include/asm/pnv-ocxl.h   |   3 +
>>  arch/powerpc/platforms/powernv/ocxl.c |  30 +
>>  drivers/misc/ocxl/afu_irq.c   | 204 
>> ++
>>  drivers/misc/ocxl/context.c   |  40 ++-
>>  drivers/misc/ocxl/file.c  |  33 ++
>>  drivers/misc/ocxl/link.c  |  28 +
>>  drivers/misc/ocxl/ocxl_internal.h |   7 ++
>>  include/uapi/misc/ocxl.h  |   9 ++
>>  8 files changed, 352 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/misc/ocxl/afu_irq.c
>>
>> diff --git a/arch/powerpc/include/asm/pnv-ocxl.h 
>> b/arch/powerpc/include/asm/pnv-ocxl.h
>> index 5a7ae7f28209..1e26f0a39500 100644
>> --- a/arch/powerpc/include/asm/pnv-ocxl.h
>> +++ b/arch/powerpc/include/asm/pnv-ocxl.h
>> @@ -37,4 +37,7 @@ extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void 
>> *spa_mem, int PE_mask,
>>  extern void pnv_ocxl_spa_release(void *platform_data);
>>  extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle);
>>  
>> +extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
>> +extern void pnv_ocxl_free_xive_irq(u32 irq);
>> +
>>  #endif /* _ASM_PVN_OCXL_H */
>> diff --git a/arch/powerpc/platforms/powernv/ocxl.c 
>> b/arch/powerpc/platforms/powernv/ocxl.c
>> index 6c79924b95c8..96cafba6aef1 100644
>> --- a/arch/powerpc/platforms/powernv/ocxl.c
>> +++ b/arch/powerpc/platforms/powernv/ocxl.c
>> @@ -9,6 +9,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include "pci.h"
>>  
>> @@ -487,3 +488,32 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int 
>> pe_handle)
>>  return rc;
>>  }
>>  EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe);
>> +
>> +int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
>> +{
>> +__be64 flags, trigger_page;
>> +s64 rc;
>> +u32 hwirq;
>> +
>> +hwirq = xive_native_alloc_irq();
>> +if (!hwirq)
>> +return -ENOENT;
>> +
>> +rc = opal_xive_get_irq_info(hwirq, , NULL, _page, NULL,
>> +NULL);
>> +if (rc || !trigger_page) {
>> +xive_native_free_irq(hwirq);
>> +return 

Re: [PATCH] powerpc/xive: Properly use static keyword for inline function

[Cédric Le Goater]

On 12/26/2017 02:00 PM, Mathieu Malaterre wrote:
> Fix fatal warning during compilation:
> 
> In file included from arch/powerpc/xmon/xmon.c:54:0:
> ./arch/powerpc/include/asm/xive.h:157:20: error: no previous prototype for 
> ‘xive_smp_prepare_cpu’ [-Werror=missing-prototypes]
>  extern inline int  xive_smp_prepare_cpu(unsigned int cpu) { return -EINVAL; }
> ^
> 
> Signed-off-by: Mathieu Malaterre <ma...@debian.org>

Reviewed-by: Cédric Le Goater <c...@kaod.org>

Thanks,

C. 

> ---
>  arch/powerpc/include/asm/xive.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index 371fbebf1ec9..83dc2cc320a3 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -154,7 +154,7 @@ static inline bool xive_enabled(void) { return false; }
>  static inline bool xive_spapr_init(void) { return false; }
>  static inline bool xive_native_init(void) { return false; }
>  static inline void xive_smp_probe(void) { }
> -extern inline int  xive_smp_prepare_cpu(unsigned int cpu) { return -EINVAL; }
> +static inline int  xive_smp_prepare_cpu(unsigned int cpu) { return -EINVAL; }
>  static inline void xive_smp_setup_cpu(void) { }
>  static inline void xive_smp_disable_cpu(void) { }
>  static inline void xive_kexec_teardown_cpu(int secondary) { }
> 

Re: [PATCH] powerpc/xive: Properly use static keyword for inline function

[Cédric Le Goater]

On 12/26/2017 02:00 PM, Mathieu Malaterre wrote:
> Fix fatal warning during compilation:
> 
> In file included from arch/powerpc/xmon/xmon.c:54:0:
> ./arch/powerpc/include/asm/xive.h:157:20: error: no previous prototype for 
> ‘xive_smp_prepare_cpu’ [-Werror=missing-prototypes]
>  extern inline int  xive_smp_prepare_cpu(unsigned int cpu) { return -EINVAL; }
> ^
> 
> Signed-off-by: Mathieu Malaterre 

Reviewed-by: Cédric Le Goater 

Thanks,

C. 

> ---
>  arch/powerpc/include/asm/xive.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index 371fbebf1ec9..83dc2cc320a3 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -154,7 +154,7 @@ static inline bool xive_enabled(void) { return false; }
>  static inline bool xive_spapr_init(void) { return false; }
>  static inline bool xive_native_init(void) { return false; }
>  static inline void xive_smp_probe(void) { }
> -extern inline int  xive_smp_prepare_cpu(unsigned int cpu) { return -EINVAL; }
> +static inline int  xive_smp_prepare_cpu(unsigned int cpu) { return -EINVAL; }
>  static inline void xive_smp_setup_cpu(void) { }
>  static inline void xive_smp_disable_cpu(void) { }
>  static inline void xive_kexec_teardown_cpu(int secondary) { }
> 

Re: [PATCH v3 18/20] ARM: dts: aspeed-romulus: Update Romulus system

[Cédric Le Goater]

On 12/20/2017 04:23 AM, Joel Stanley wrote:
>  - Fix incorrect RAM size
>  - Remove alias; these are now specified in the dtsi
>  - Add newly upstreamed devices
>  - Include OpenBMC flash layout
> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>

Reviewed-by: Cédric Le Goater <c...@kaod.org>

> ---
>  v3:
>   - Add GPIO include
>   - Fix duplicate fmc and spi nodes
>   - Add unit name for memory node to fix warning
> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 133 
> +--
>  1 file changed, 126 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..623b6ab42021 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,23 +1,19 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
> -
>  #include "aspeed-g5.dtsi"
> +#include 
>  
>  / {
>   model = "Romulus BMC";
>   compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>  
> - aliases {
> - serial4 = 
> - };
> -
>   chosen {
>   stdout-path = 
>   bootargs = "console=ttyS4,115200 earlyprintk";
>   };
>  
> - memory {
> - reg = <0x8000 0x4000>;
> + memory@8000 {
> + reg = <0x8000 0x2000>;
>   };
>  
>   reserved-memory {
> @@ -29,6 +25,49 @@
>   no-map;
>   reg = <0xbf00 0x0100>; /* 16M */
>   };
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = < ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = < ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = < ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = < ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = < ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = < ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = < ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = < ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(J, 2)>;
> + };
>   };
>  };
>  
> @@ -38,6 +77,7 @@
>   status = "okay";
>   m25p,fast-read;
>   label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
>   };
>  };
>  
> @@ -53,6 +93,12 @@
>   };
>  };
>  
> +_ctrl {
> + status = "okay";
> + memory-region = <_memory>;
> + flash = <>;
> +};
> +
>   {
>   /* Rear RS-232 connector */
>   status = "okay";
> @@ -81,6 +127,10 @@
>   pinctrl-0 = <_rmii1_default>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -133,8 +183,77 @@
>  
>   {
>   status = "okay";
> +
> + max31785@52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> + {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 3) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
>  };
>  
>   {
>   status = "okay";
>  };
&g

Re: [PATCH v3 18/20] ARM: dts: aspeed-romulus: Update Romulus system

[Cédric Le Goater]

On 12/20/2017 04:23 AM, Joel Stanley wrote:
>  - Fix incorrect RAM size
>  - Remove alias; these are now specified in the dtsi
>  - Add newly upstreamed devices
>  - Include OpenBMC flash layout
> 
> Signed-off-by: Joel Stanley 

Reviewed-by: Cédric Le Goater 

> ---
>  v3:
>   - Add GPIO include
>   - Fix duplicate fmc and spi nodes
>   - Add unit name for memory node to fix warning
> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 133 
> +--
>  1 file changed, 126 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..623b6ab42021 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,23 +1,19 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
> -
>  #include "aspeed-g5.dtsi"
> +#include 
>  
>  / {
>   model = "Romulus BMC";
>   compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>  
> - aliases {
> - serial4 = 
> - };
> -
>   chosen {
>   stdout-path = 
>   bootargs = "console=ttyS4,115200 earlyprintk";
>   };
>  
> - memory {
> - reg = <0x8000 0x4000>;
> + memory@8000 {
> + reg = <0x8000 0x2000>;
>   };
>  
>   reserved-memory {
> @@ -29,6 +25,49 @@
>   no-map;
>   reg = <0xbf00 0x0100>; /* 16M */
>   };
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = < ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = < ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = < ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = < ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = < ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = < ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = < ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = < ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
>   };
>  };
>  
> @@ -38,6 +77,7 @@
>   status = "okay";
>   m25p,fast-read;
>   label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
>   };
>  };
>  
> @@ -53,6 +93,12 @@
>   };
>  };
>  
> +_ctrl {
> + status = "okay";
> + memory-region = <_memory>;
> + flash = <>;
> +};
> +
>   {
>   /* Rear RS-232 connector */
>   status = "okay";
> @@ -81,6 +127,10 @@
>   pinctrl-0 = <_rmii1_default>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -133,8 +183,77 @@
>  
>   {
>   status = "okay";
> +
> + max31785@52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> + {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = ;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = ;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
>  };
>  
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + aspeed,external-nodes = < >;
> +};
> +
> +

Re: [PATCH v2 18/19] ARM: dts: aspeed-romulus: Update Romulus system

[Cédric Le Goater]

Some comments below,

On 12/15/2017 07:24 AM, Joel Stanley wrote:
>  - Fix incorrect RAM size
>  - Remove alias; these are now specified in the dtsi
>  - Add newly upstreamed devices
>  - Include OpenBMC flash layout
> 
> Signed-off-by: Joel Stanley 
> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 153 
> ++-
>  1 file changed, 148 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..bfdf643584df 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -7,17 +7,13 @@
>   model = "Romulus BMC";
>   compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>  
> - aliases {
> - serial4 = 
> - };
> -
>   chosen {
>   stdout-path = 
>   bootargs = "console=ttyS4,115200 earlyprintk";
>   };
>  
>   memory {
> - reg = <0x8000 0x4000>;
> + reg = <0x8000 0x2000>;
>   };
>  
>   reserved-memory {
> @@ -29,6 +25,73 @@
>   no-map;
>   reg = <0xbf00 0x0100>; /* 16M */
>   };
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = < ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = < ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = < ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = < ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = < ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = < ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = < ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = < ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
> +#include "openbmc-flash-layout.dtsi"
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi1_default>;
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
>   };
>  };


hmm, the fmc and spi1 bindings were already added in commit 1142aea9ff9d.


> @@ -38,6 +101,7 @@
>   status = "okay";
>   m25p,fast-read;
>   label = "bmc";
> +#include "openbmc-flash-layout.dtsi"


This looks like an extra "fmc" node ? 

>   };
>  };
>  
> @@ -53,6 +117,12 @@
>   };
>  };
>  
> +_ctrl {
> + status = "okay";
> + memory-region = <_memory>;
> + flash = <>;
> +};
> +
>   {
>   /* Rear RS-232 connector */
>   status = "okay";
> @@ -81,6 +151,10 @@
>   pinctrl-0 = <_rmii1_default>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -133,8 +207,77 @@
>  
>   {
>   status = "okay";
> +
> + max31785@52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> + {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = ;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = ;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
>  };
>  
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + aspeed,external-nodes = < >;
> +};
> +
> +_tacho {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pwm0_default _pwm1_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x08>;
> + };
> +
> + fan@1 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan@2 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
> 

Re: [PATCH v2 18/19] ARM: dts: aspeed-romulus: Update Romulus system

[Cédric Le Goater]

Some comments below,

On 12/15/2017 07:24 AM, Joel Stanley wrote:
>  - Fix incorrect RAM size
>  - Remove alias; these are now specified in the dtsi
>  - Add newly upstreamed devices
>  - Include OpenBMC flash layout
> 
> Signed-off-by: Joel Stanley 
> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 153 
> ++-
>  1 file changed, 148 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..bfdf643584df 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -7,17 +7,13 @@
>   model = "Romulus BMC";
>   compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>  
> - aliases {
> - serial4 = 
> - };
> -
>   chosen {
>   stdout-path = 
>   bootargs = "console=ttyS4,115200 earlyprintk";
>   };
>  
>   memory {
> - reg = <0x8000 0x4000>;
> + reg = <0x8000 0x2000>;
>   };
>  
>   reserved-memory {
> @@ -29,6 +25,73 @@
>   no-map;
>   reg = <0xbf00 0x0100>; /* 16M */
>   };
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = < ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = < ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = < ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = < ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = < ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = < ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = < ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = < ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
> +#include "openbmc-flash-layout.dtsi"
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi1_default>;
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
>   };
>  };


hmm, the fmc and spi1 bindings were already added in commit 1142aea9ff9d.


> @@ -38,6 +101,7 @@
>   status = "okay";
>   m25p,fast-read;
>   label = "bmc";
> +#include "openbmc-flash-layout.dtsi"


This looks like an extra "fmc" node ? 

>   };
>  };
>  
> @@ -53,6 +117,12 @@
>   };
>  };
>  
> +_ctrl {
> + status = "okay";
> + memory-region = <_memory>;
> + flash = <>;
> +};
> +
>   {
>   /* Rear RS-232 connector */
>   status = "okay";
> @@ -81,6 +151,10 @@
>   pinctrl-0 = <_rmii1_default>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -133,8 +207,77 @@
>  
>   {
>   status = "okay";
> +
> + max31785@52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> + {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = ;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = ;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
>  };
>  
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + aspeed,external-nodes = < >;
> +};
> +
> +_tacho {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pwm0_default _pwm1_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x08>;
> + };
> +
> + fan@1 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan@2 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
> + };
> +
> + fan@3 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 

Re: [PATCH v2 03/19] ARM: dts: aspeed: Add LPC and child devices

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> From: Andrew Jeffery <and...@aj.id.au>
> 
> Ensure the ordering is correct and add all of the children in the SoC
> device trees for the ast2400 and ast2500.
> 
> Signed-off-by: Andrew Jeffery <and...@aj.id.au>
> Signed-off-by: Joel Stanley <j...@jms.id.au>
> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 35 +++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 27 +--
>  2 files changed, 52 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 100d092e6c07..a3bc5da7d42c 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -226,6 +226,41 @@
>   status = "disabled";
>   };
>  
> + lpc: lpc@1e789000 {
> + compatible = "aspeed,ast2400-lpc", "simple-mfd";
> + reg = <0x1e789000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e789000 0x1000>;
> +
> + lpc_bmc: lpc-bmc@0 {
> + compatible = "aspeed,ast2400-lpc-bmc";
> + reg = <0x0 0x80>;
> + };
> +
> + lpc_host: lpc-host@80 {
> + compatible = "aspeed,ast2400-lpc-host", 
> "simple-mfd", "syscon";
> + reg = <0x80 0x1e0>;
> + reg-io-width = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x80 0x1e0>;
> +
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = 
> "aspeed,ast2400-lpc-ctrl";
> + reg = <0x0 0x80>;
> + status = "disabled";
> +     };
> +
> + lhc: lhc@20 {
> + compatible = 
> "aspeed,ast2500-lhc";

aspeed,ast2400-lhc

The layout of the registers are the same but there a couple of differences
in the bit definitions between the two SoCs.

a part from that :

Reviewed-by: Cédric Le Goater <c...@kaod.org>

C. 

> + reg = <0x20 0x24 0x48 0x8>;
> + };
> + };
> + };
> +
>   uart2: serial@1e78d000 {
>   compatible = "ns16550a";
>   reg = <0x1e78d000 0x20>;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 1f9d28313f82..7861631940fe 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -266,6 +266,16 @@
>   status = "disabled";
>   };
>  
> + vuart: serial@1e787000 {
> + compatible = "aspeed,ast2500-vuart";
> + reg = <0x1e787000 0x40>;
> + reg-shift = <2>;
> + interrupts = <10>;
> + clocks = <_uart>;
> + no-loopback-test;
> + status = "disabled";
> + };
> +
>   lpc: lpc@1e789000 {
>   compatible = "aspeed,ast2500-lpc", "simple-mfd";
>   reg = <0x1e789000 0x1000>;
> @@ -289,6 +299,13 @@
>  
>   reg-io-width = <4>;
>  
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = 
> "aspeed,ast2500-lpc-ctrl";
> + reg = <0x0 0x80>;
> + status = "disabled";
> + };
> +
> +
>   

Re: [PATCH v2 03/19] ARM: dts: aspeed: Add LPC and child devices

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> From: Andrew Jeffery 
> 
> Ensure the ordering is correct and add all of the children in the SoC
> device trees for the ast2400 and ast2500.
> 
> Signed-off-by: Andrew Jeffery 
> Signed-off-by: Joel Stanley 
> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 35 +++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 27 +--
>  2 files changed, 52 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 100d092e6c07..a3bc5da7d42c 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -226,6 +226,41 @@
>   status = "disabled";
>   };
>  
> + lpc: lpc@1e789000 {
> + compatible = "aspeed,ast2400-lpc", "simple-mfd";
> + reg = <0x1e789000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e789000 0x1000>;
> +
> + lpc_bmc: lpc-bmc@0 {
> + compatible = "aspeed,ast2400-lpc-bmc";
> + reg = <0x0 0x80>;
> + };
> +
> + lpc_host: lpc-host@80 {
> + compatible = "aspeed,ast2400-lpc-host", 
> "simple-mfd", "syscon";
> + reg = <0x80 0x1e0>;
> + reg-io-width = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x80 0x1e0>;
> +
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = 
> "aspeed,ast2400-lpc-ctrl";
> + reg = <0x0 0x80>;
> + status = "disabled";
> + };
> +
> +         lhc: lhc@20 {
> + compatible = 
> "aspeed,ast2500-lhc";

aspeed,ast2400-lhc

The layout of the registers are the same but there a couple of differences
in the bit definitions between the two SoCs.

a part from that :

Reviewed-by: Cédric Le Goater 

C. 

> + reg = <0x20 0x24 0x48 0x8>;
> + };
> + };
> + };
> +
>   uart2: serial@1e78d000 {
>   compatible = "ns16550a";
>   reg = <0x1e78d000 0x20>;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 1f9d28313f82..7861631940fe 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -266,6 +266,16 @@
>   status = "disabled";
>   };
>  
> + vuart: serial@1e787000 {
> + compatible = "aspeed,ast2500-vuart";
> + reg = <0x1e787000 0x40>;
> + reg-shift = <2>;
> + interrupts = <10>;
> + clocks = <_uart>;
> + no-loopback-test;
> + status = "disabled";
> + };
> +
>   lpc: lpc@1e789000 {
>   compatible = "aspeed,ast2500-lpc", "simple-mfd";
>   reg = <0x1e789000 0x1000>;
> @@ -289,6 +299,13 @@
>  
>   reg-io-width = <4>;
>  
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = 
> "aspeed,ast2500-lpc-ctrl";
> + reg = <0x0 0x80>;
> + status = "disabled";
> + };
> +
> +
>   lhc: lhc@20 {
>   compatible = 
> "aspeed,as

Re: [PATCH v2 06/19] ARM: dts: aspeed: Add watchdog clocks

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> Signed-off-by: Joel Stanley <j...@jms.id.au>


Reviewed-by: Cédric Le Goater <c...@kaod.org>


> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 2 ++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index cf407b4db630..2e3666d4fbeb 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -177,11 +177,13 @@
>   wdt1: watchdog@1e785000 {
>   compatible = "aspeed,ast2400-wdt";
>   reg = <0x1e785000 0x1c>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   wdt2: watchdog@1e785020 {
>   compatible = "aspeed,ast2400-wdt";
>   reg = <0x1e785020 0x1c>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   vuart: serial@1e787000 {
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index ab26156d6822..24bb2d16b900 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -219,16 +219,19 @@
>   wdt1: watchdog@1e785000 {
>   compatible = "aspeed,ast2500-wdt";
>   reg = <0x1e785000 0x20>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   wdt2: watchdog@1e785020 {
>   compatible = "aspeed,ast2500-wdt";
>   reg = <0x1e785020 0x20>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   wdt3: watchdog@1e785040 {
>   compatible = "aspeed,ast2500-wdt";
>   reg = <0x1e785040 0x20>;
> + clocks = < ASPEED_CLK_APB>;
>   status = "disabled";
>   };
>  
> 

Re: [PATCH v2 06/19] ARM: dts: aspeed: Add watchdog clocks

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 


> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 2 ++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index cf407b4db630..2e3666d4fbeb 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -177,11 +177,13 @@
>   wdt1: watchdog@1e785000 {
>   compatible = "aspeed,ast2400-wdt";
>   reg = <0x1e785000 0x1c>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   wdt2: watchdog@1e785020 {
>   compatible = "aspeed,ast2400-wdt";
>   reg = <0x1e785020 0x1c>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   vuart: serial@1e787000 {
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index ab26156d6822..24bb2d16b900 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -219,16 +219,19 @@
>   wdt1: watchdog@1e785000 {
>   compatible = "aspeed,ast2500-wdt";
>   reg = <0x1e785000 0x20>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   wdt2: watchdog@1e785020 {
>   compatible = "aspeed,ast2500-wdt";
>   reg = <0x1e785020 0x20>;
> + clocks = < ASPEED_CLK_APB>;
>   };
>  
>   wdt3: watchdog@1e785040 {
>   compatible = "aspeed,ast2500-wdt";
>   reg = <0x1e785040 0x20>;
> + clocks = < ASPEED_CLK_APB>;
>   status = "disabled";
>   };
>  
> 

Re: [PATCH v2 13/19] ARM: dts: Add OpenBMC flash layout

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> This is a layout used by OpenBMC systems. It describes the fixed flash
> layout of a 32MB mtd device.
> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>


Reviewed-by: Cédric Le Goater <c...@kaod.org>


> ---
>  arch/arm/boot/dts/openbmc-flash-layout.dtsi | 32 
> +
>  1 file changed, 32 insertions(+)
>  create mode 100644 arch/arm/boot/dts/openbmc-flash-layout.dtsi
> 
> diff --git a/arch/arm/boot/dts/openbmc-flash-layout.dtsi 
> b/arch/arm/boot/dts/openbmc-flash-layout.dtsi
> new file mode 100644
> index ..63ad8db7a431
> --- /dev/null
> +++ b/arch/arm/boot/dts/openbmc-flash-layout.dtsi
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + u-boot@0 {
> + reg = <0x0 0x6>;
> + label = "u-boot";
> + };
> +
> + u-boot-env@6 {
> + reg = <0x6 0x2>;
> + label = "u-boot-env";
> + };
> +
> + kernel@8 {
> + reg = <0x8 0x44>;
> + label = "kernel";
> + };
> +
> + rofs@0c {
> + reg = <0x4c 0x174>;
> + label = "rofs";
> + };
> +
> + rwfs@1c0 {
> + reg = <0x1c0 0x40>;
> + label = "rwfs";
> + };
> +};
> 

Re: [PATCH v2 13/19] ARM: dts: Add OpenBMC flash layout

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> This is a layout used by OpenBMC systems. It describes the fixed flash
> layout of a 32MB mtd device.
> 
> Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 


> ---
>  arch/arm/boot/dts/openbmc-flash-layout.dtsi | 32 
> +
>  1 file changed, 32 insertions(+)
>  create mode 100644 arch/arm/boot/dts/openbmc-flash-layout.dtsi
> 
> diff --git a/arch/arm/boot/dts/openbmc-flash-layout.dtsi 
> b/arch/arm/boot/dts/openbmc-flash-layout.dtsi
> new file mode 100644
> index ..63ad8db7a431
> --- /dev/null
> +++ b/arch/arm/boot/dts/openbmc-flash-layout.dtsi
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + u-boot@0 {
> + reg = <0x0 0x6>;
> + label = "u-boot";
> + };
> +
> + u-boot-env@6 {
> + reg = <0x6 0x2>;
> + label = "u-boot-env";
> + };
> +
> + kernel@8 {
> + reg = <0x8 0x44>;
> + label = "kernel";
> + };
> +
> + rofs@0c {
> + reg = <0x4c 0x174>;
> + label = "rofs";
> + };
> +
> + rwfs@1c0 {
> + reg = <0x1c0 0x40>;
> + label = "rwfs";
> + };
> +};
> 

Re: [PATCH] ARM: dts: aspeed-g4: Correct VUART IRQ number

[Cédric Le Goater]

On 12/15/2017 06:33 AM, Joel Stanley wrote:
> This should have always been 8.
> 
> Fixes: db4d6d9d80fa ("ARM: dts: aspeed: Correctly order UART nodes")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Joel Stanley <j...@jms.id.au>

Reviewed-by: Cédric Le Goater <c...@kaod.org>

> ---
> ARM maintainers, please include this fix for 4.15
> 
>  arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 45d815a86d42..de08d9045cb8 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -219,7 +219,7 @@
>   compatible = "aspeed,ast2400-vuart";
>   reg = <0x1e787000 0x40>;
>   reg-shift = <2>;
> - interrupts = <10>;
> + interrupts = <8>;
>   clocks = <_uart>;
>   no-loopback-test;
>   status = "disabled";
> 

Re: [PATCH] ARM: dts: aspeed-g4: Correct VUART IRQ number

[Cédric Le Goater]

On 12/15/2017 06:33 AM, Joel Stanley wrote:
> This should have always been 8.
> 
> Fixes: db4d6d9d80fa ("ARM: dts: aspeed: Correctly order UART nodes")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Joel Stanley 

Reviewed-by: Cédric Le Goater 

> ---
> ARM maintainers, please include this fix for 4.15
> 
>  arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 45d815a86d42..de08d9045cb8 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -219,7 +219,7 @@
>   compatible = "aspeed,ast2400-vuart";
>   reg = <0x1e787000 0x40>;
>   reg-shift = <2>;
> - interrupts = <10>;
> + interrupts = <8>;
>   clocks = <_uart>;
>   no-loopback-test;
>   status = "disabled";
> 

Re: [PATCH v2 11/19] ARM: dts: aspeed: Remove skeleton.dtsi

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> We don't require it for any of the ASPEED systems.

Reviewed-by: Cédric Le Goater <c...@kaod.org>


> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>
> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 1 -
>  arch/arm/boot/dts/aspeed-g5.dtsi | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index b3580f37f507..2d7ac577d6b5 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -1,5 +1,4 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "skeleton.dtsi"
>  #include 
>  #include 
>  
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 50766f0629f8..030a760696fd 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -1,5 +1,4 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "skeleton.dtsi"
>  #include 
>  #include 
>  
> 

Re: [PATCH v2 11/19] ARM: dts: aspeed: Remove skeleton.dtsi

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> We don't require it for any of the ASPEED systems.

Reviewed-by: Cédric Le Goater 


> 
> Signed-off-by: Joel Stanley 
> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 1 -
>  arch/arm/boot/dts/aspeed-g5.dtsi | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index b3580f37f507..2d7ac577d6b5 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -1,5 +1,4 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "skeleton.dtsi"
>  #include 
>  #include 
>  
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 50766f0629f8..030a760696fd 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -1,5 +1,4 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "skeleton.dtsi"
>  #include 
>  #include 
>  
> 

Re: [PATCH v2 19/19] ARM: dts: aspeed-plametto: Add flash layout

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> The OpenBMC flash layout is used by Palmetto systems.
> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>



Reviewed-by: Cédric Le Goater <c...@kaod.org>

> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index a8f0c046e83e..cc18137386f2 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -34,6 +34,7 @@
>   status = "okay";
>   m25p,fast-read;
>   label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
>   };
>  };
>  
> 

Re: [PATCH v2 19/19] ARM: dts: aspeed-plametto: Add flash layout

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> The OpenBMC flash layout is used by Palmetto systems.
> 
> Signed-off-by: Joel Stanley 



Reviewed-by: Cédric Le Goater 

> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index a8f0c046e83e..cc18137386f2 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -34,6 +34,7 @@
>   status = "okay";
>   m25p,fast-read;
>   label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
>   };
>  };
>  
> 

Re: [PATCH v2 10/19] ARM: dts: aspeed: Add LPC Snoop device

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> LPC snoop hardware on the ASPEED BMC, used for monitoring
> host I/O port activity.
> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>
> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 7 +++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 6 ++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index f6fee40c04c0..b3580f37f507 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -236,6 +236,13 @@
>   status = "disabled";
>   };
>  
> + lpc_snoop: lpc-snoop@0 {
> + compatible = 
> "aspeed,ast2500-lpc-snoop";

it should be :

aspeed,ast2400-lpc-snoop

a part from that :

Reviewed-by: Cédric Le Goater <c...@kaod.org>

> + reg = <0x0 0x80>;
> + interrupts = <8>;
> + status = "disabled";
> + };
> +
>   lhc: lhc@20 {
>   compatible = 
> "aspeed,ast2500-lhc";
>   reg = <0x20 0x24 0x48 0x8>;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 96a9d2fe3f0d..50766f0629f8 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -287,6 +287,12 @@
>   status = "disabled";
>   };
>  
> + lpc_snoop: lpc-snoop@0 {
> + compatible = 
> "aspeed,ast2500-lpc-snoop";
> + reg = <0x0 0x80>;
> + interrupts = <8>;
> + status = "disabled";
> + };
>  
>   lhc: lhc@20 {
>   compatible = 
> "aspeed,ast2500-lhc";
> 

Re: [PATCH v2 10/19] ARM: dts: aspeed: Add LPC Snoop device

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> LPC snoop hardware on the ASPEED BMC, used for monitoring
> host I/O port activity.
> 
> Signed-off-by: Joel Stanley 
> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 7 +++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 6 ++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index f6fee40c04c0..b3580f37f507 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -236,6 +236,13 @@
>   status = "disabled";
>   };
>  
> + lpc_snoop: lpc-snoop@0 {
> + compatible = 
> "aspeed,ast2500-lpc-snoop";

it should be :

aspeed,ast2400-lpc-snoop

a part from that :

Reviewed-by: Cédric Le Goater 

> + reg = <0x0 0x80>;
> + interrupts = <8>;
> + status = "disabled";
> + };
> +
>   lhc: lhc@20 {
>   compatible = 
> "aspeed,ast2500-lhc";
>   reg = <0x20 0x24 0x48 0x8>;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 96a9d2fe3f0d..50766f0629f8 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -287,6 +287,12 @@
>   status = "disabled";
>   };
>  
> + lpc_snoop: lpc-snoop@0 {
> + compatible = 
> "aspeed,ast2500-lpc-snoop";
> + reg = <0x0 0x80>;
> + interrupts = <8>;
> + status = "disabled";
> + };
>  
>   lhc: lhc@20 {
>   compatible = 
> "aspeed,ast2500-lhc";
> 

Re: [PATCH v2 12/19] ARM: dts: aspeed: Update license headers

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> In b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier
> to files with no license") these files had the GPL-2.0 licence added
> automatically. Update them to be GPL 2.0+ in line with other IBM kernel
> contributions.
> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>


Reviewed-by: Cédric Le Goater <c...@kaod.org>

> ---
>  arch/arm/boot/dts/aspeed-ast2500-evb.dts  | 2 +-
>  arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 2 +-
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts  | 2 +-
>  arch/arm/boot/dts/aspeed-g4.dtsi  | 2 +-
>  arch/arm/boot/dts/aspeed-g5.dtsi  | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-ast2500-evb.dts 
> b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> index 602bc10fdaf4..3e6f38e5d5d0 100644
> --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
>  
>  #include "aspeed-g5.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index c786bc2f2919..a8f0c046e83e 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
>  
>  #include "aspeed-g4.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index 8067793129ea..a7a9386f964d 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
>  
>  #include "aspeed-g5.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 2d7ac577d6b5..9c175832babc 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  #include 
>  #include 
>  
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 030a760696fd..360329eab7c3 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  #include 
>  #include 
>  
> 

Re: [PATCH v2 12/19] ARM: dts: aspeed: Update license headers

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> In b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier
> to files with no license") these files had the GPL-2.0 licence added
> automatically. Update them to be GPL 2.0+ in line with other IBM kernel
> contributions.
> 
> Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

> ---
>  arch/arm/boot/dts/aspeed-ast2500-evb.dts  | 2 +-
>  arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 2 +-
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts  | 2 +-
>  arch/arm/boot/dts/aspeed-g4.dtsi  | 2 +-
>  arch/arm/boot/dts/aspeed-g5.dtsi  | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-ast2500-evb.dts 
> b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> index 602bc10fdaf4..3e6f38e5d5d0 100644
> --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
>  
>  #include "aspeed-g5.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index c786bc2f2919..a8f0c046e83e 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
>  
>  #include "aspeed-g4.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index 8067793129ea..a7a9386f964d 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  /dts-v1/;
>  
>  #include "aspeed-g5.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 2d7ac577d6b5..9c175832babc 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  #include 
>  #include 
>  
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 030a760696fd..360329eab7c3 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
>  #include 
>  #include 
>  
> 

Re: [PATCH v2 07/19] ARM: dts: aspeed: Add flash controller clocks

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> Signed-off-by: Joel Stanley <j...@jms.id.au>


Reviewed-by: Cédric Le Goater <c...@kaod.org>


> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 2 ++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 2e3666d4fbeb..afac0ca0cb10 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -56,6 +56,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2400-fmc";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   interrupts = <19>;
>   flash@0 {
> @@ -71,6 +72,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2400-spi";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   flash@0 {
>   reg = < 0 >;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 24bb2d16b900..f3689caf6fe2 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -56,6 +56,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2500-fmc";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   interrupts = <19>;
>   flash@0 {
> @@ -81,6 +82,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2500-spi";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   flash@0 {
>   reg = < 0 >;
> @@ -100,6 +102,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2500-spi";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   flash@0 {
>   reg = < 0 >;
> 

Re: [PATCH v2 07/19] ARM: dts: aspeed: Add flash controller clocks

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 


> ---
>  arch/arm/boot/dts/aspeed-g4.dtsi | 2 ++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi 
> b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 2e3666d4fbeb..afac0ca0cb10 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -56,6 +56,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2400-fmc";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   interrupts = <19>;
>   flash@0 {
> @@ -71,6 +72,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2400-spi";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   flash@0 {
>   reg = < 0 >;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 24bb2d16b900..f3689caf6fe2 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -56,6 +56,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2500-fmc";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   interrupts = <19>;
>   flash@0 {
> @@ -81,6 +82,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2500-spi";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   flash@0 {
>   reg = < 0 >;
> @@ -100,6 +102,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "aspeed,ast2500-spi";
> + clocks = < ASPEED_CLK_AHB>;
>   status = "disabled";
>   flash@0 {
>   reg = < 0 >;
> 

Re: [PATCH v2 14/19] ARM: dts: aspeed: Sort ASPEED entries in makefile

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> In preperation for adding more boards.
> 
> Signed-off-by: Joel Stanley <j...@jms.id.au>


Reviewed-by: Cédric Le Goater <c...@kaod.org>

> ---
>  arch/arm/boot/dts/Makefile | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..5d1e9d37bf3a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1101,7 +1101,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>   mt8127-moose.dtb \
>   mt8135-evbp1.dtb
>  dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> -dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \
> - aspeed-bmc-opp-romulus.dtb \
> - aspeed-ast2500-evb.dtb
> +dtb-$(CONFIG_ARCH_ASPEED) += \
> + aspeed-ast2500-evb.dtb \
> + aspeed-bmc-opp-palmetto.dtb \
> + aspeed-bmc-opp-romulus.dtb
>  endif
> 

Re: [PATCH v2 14/19] ARM: dts: aspeed: Sort ASPEED entries in makefile

[Cédric Le Goater]

On 12/15/2017 07:24 AM, Joel Stanley wrote:
> In preperation for adding more boards.
> 
> Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

> ---
>  arch/arm/boot/dts/Makefile | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..5d1e9d37bf3a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1101,7 +1101,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>   mt8127-moose.dtb \
>   mt8135-evbp1.dtb
>  dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> -dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \
> - aspeed-bmc-opp-romulus.dtb \
> - aspeed-ast2500-evb.dtb
> +dtb-$(CONFIG_ARCH_ASPEED) += \
> + aspeed-ast2500-evb.dtb \
> + aspeed-bmc-opp-palmetto.dtb \
> + aspeed-bmc-opp-romulus.dtb
>  endif
> 

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/25/2017 12:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
> 
> Il 24/10/2017 07:51, Cédric Le Goater ha scritto:
>> On 10/17/2017 11:16 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>
>>>> On 10/17/2017 10:20 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>>>
>>>>> Il 17/10/2017 10:18, Cédric Le Goater ha scritto:
>>>>>> On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I'm working on an iMX6 based board with a PCA9555 which is used both to 
>>>>>>> drive LEDs and manage some GPIOs.
>>>>>> The PCA9555 chip and the PCA955[0-3] chips have different control
>>>>>> registers. You need a different led driver for it.
>>>>>
>>>>> My typo sorry, as you can see in the device tree below, I'm using pca9551
>>>>
>>>> ok.
>>>>
>>>> You might want to take a look at how we mixed gpios and leds on the 
>>>> witherspoon
>>>> system using pca9552 chips. we added a gpio-leds binding.
>>>>
>>>> https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>
>>> understood: you configure all pins of PCA955x as GPIOs and the map the one 
>>> you need as led with gpio-leds binding.
>>
>> Sorry I got distracted.
>>
>>> However to me this is a kind of workaround or, at least, there's nothing 
>>> about this limitation into the devicetree binding (in fact, IMHO, the 
>>> device tree binding example will just fail)
>>
>> euh ? what do you mean. There is a real system using this device tree.
>> I think we would know about it if it didn't work. Please explain
>>
> 
> I mean that, for what I understand, your configuration is working because all 
> pin of 9551 are configured as GPIOs (and the binded back as led)
> In my configuration I have some pins configured as led and some as GPIOs, and 
> this is not working.

ok. That might the case. 

We have declared all pins as GPIOs on pca0 then used on top :  

gpio-keys-polled {
compatible = "gpio-keys-polled";
...
}

and

leds {
compatible = "gpio-leds";
...
}

which works perfecty fine.


>>> I wrote the attached patch which should fix the issue and allow a more 
>>> generic approach. WDYT?
>>>
>>> (in case it looks good, I'll send the patch in the correct way)
>>
>> Please send the patch to discuss, add Andrew Jeffery <and...@aj.id.au>
>> in cc:
>>
> 
> Sorry for the delay but I'm busy in Prague with OSSummit and ELCE. 
> I 'll send a proper patch 
> and more comments, if needed, by the begin of next week.

ok thanks, I have not seen anything wrong with it. I will see if we can 
get it tested on our systems.

> (BTW, if some of you are here, drop me a line and have a beer together! ;-) )

Nah, not this time. Enjoy :)

Cheers,

C.

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/25/2017 12:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
> 
> Il 24/10/2017 07:51, Cédric Le Goater ha scritto:
>> On 10/17/2017 11:16 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>
>>>> On 10/17/2017 10:20 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>>>
>>>>> Il 17/10/2017 10:18, Cédric Le Goater ha scritto:
>>>>>> On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I'm working on an iMX6 based board with a PCA9555 which is used both to 
>>>>>>> drive LEDs and manage some GPIOs.
>>>>>> The PCA9555 chip and the PCA955[0-3] chips have different control
>>>>>> registers. You need a different led driver for it.
>>>>>
>>>>> My typo sorry, as you can see in the device tree below, I'm using pca9551
>>>>
>>>> ok.
>>>>
>>>> You might want to take a look at how we mixed gpios and leds on the 
>>>> witherspoon
>>>> system using pca9552 chips. we added a gpio-leds binding.
>>>>
>>>> https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>
>>> understood: you configure all pins of PCA955x as GPIOs and the map the one 
>>> you need as led with gpio-leds binding.
>>
>> Sorry I got distracted.
>>
>>> However to me this is a kind of workaround or, at least, there's nothing 
>>> about this limitation into the devicetree binding (in fact, IMHO, the 
>>> device tree binding example will just fail)
>>
>> euh ? what do you mean. There is a real system using this device tree.
>> I think we would know about it if it didn't work. Please explain
>>
> 
> I mean that, for what I understand, your configuration is working because all 
> pin of 9551 are configured as GPIOs (and the binded back as led)
> In my configuration I have some pins configured as led and some as GPIOs, and 
> this is not working.

ok. That might the case. 

We have declared all pins as GPIOs on pca0 then used on top :  

gpio-keys-polled {
compatible = "gpio-keys-polled";
...
}

and

leds {
compatible = "gpio-leds";
...
}

which works perfecty fine.


>>> I wrote the attached patch which should fix the issue and allow a more 
>>> generic approach. WDYT?
>>>
>>> (in case it looks good, I'll send the patch in the correct way)
>>
>> Please send the patch to discuss, add Andrew Jeffery 
>> in cc:
>>
> 
> Sorry for the delay but I'm busy in Prague with OSSummit and ELCE. 
> I 'll send a proper patch 
> and more comments, if needed, by the begin of next week.

ok thanks, I have not seen anything wrong with it. I will see if we can 
get it tested on our systems.

> (BTW, if some of you are here, drop me a line and have a beer together! ;-) )

Nah, not this time. Enjoy :)

Cheers,

C.

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/17/2017 11:16 AM, Andrea Scian - DAVE Embedded Systems wrote:
> 
>> On 10/17/2017 10:20 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>
>>> Il 17/10/2017 10:18, Cédric Le Goater ha scritto:
>>>> On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>>> Dear all,
>>>>>
>>>>> I'm working on an iMX6 based board with a PCA9555 which is used both to 
>>>>> drive LEDs and manage some GPIOs.
>>>> The PCA9555 chip and the PCA955[0-3] chips have different control
>>>> registers. You need a different led driver for it.
>>>
>>> My typo sorry, as you can see in the device tree below, I'm using pca9551
>>
>> ok.
>>
>> You might want to take a look at how we mixed gpios and leds on the 
>> witherspoon
>> system using pca9552 chips. we added a gpio-leds binding.
>>
>> https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> 
> understood: you configure all pins of PCA955x as GPIOs and the map the one 
> you need as led with gpio-leds binding.

Sorry I got distracted.

> However to me this is a kind of workaround or, at least, there's nothing 
> about this limitation into the devicetree binding (in fact, IMHO, the device 
> tree binding example will just fail)

euh ? what do you mean. There is a real system using this device tree. 
I think we would know about it if it didn't work. Please explain

> I wrote the attached patch which should fix the issue and allow a more 
> generic approach. WDYT?
> 
> (in case it looks good, I'll send the patch in the correct way)

Please send the patch to discuss, add Andrew Jeffery <and...@aj.id.au> 
in cc:

Thanks,

C.


> 
> Kind Regards,
> 
> Andrea
> 
>>>
>>>>> My current kernel is quite old (4.1.15) but I've found Cédric patches on 
>>>>> mainline and backported to this old revision.
>>>>>
>>>>> I'm facing an issue with it, because it seems that it fails when it's 
>>>>> used in a mixed (led/gpios) environment.
>>>>>
>>>>> E.g.: let's say that I have one led connected to LED0 output and one GPIO 
>>>>> connected at LED1 output.
>>>>>
>>>>> I define it as
>>>>>
>>>>>   pca9551: pca9551@60 {
>>>>>   compatible = "nxp,pca9551";
>>>>>   reg = <0x60>;
>>>>>   #address-cells = <1>;
>>>>>   #size-cells = <0>;
>>>>>   #gpio-cells = <1>;
>>>>>
>>>>>   led@0 {
>>>>>   label = "led0";
>>>>>   reg = <0>;
>>>>>   linux,default-trigger = "none";
>>>>>   };
>>>>>   gpio@1 {
>>>>>   label = "gpio1";
>>>>>   reg = <1>;
>>>>>   type = <2>; /* GPIO */
>>>>>   };
>>>>>               };
>>>>>
>>>>> At boot it's probed as
>>>>>
>>>>> root@sbc-lynx:~# dmesg | grep pca
>>>>> [    5.315425] leds-pca955x 5-0060: leds-pca955x: Using pca9551 8-bit LED 
>>>>> driver at slave address 0x60
>>>>> [    5.350349] leds-pca955x 5-0060: gpios 511...511
>>>>>
>>>>> But I cannot access it:
>>>>>
>>>>> root@sbc-lynx:~# echo 511 > /sys/class/gpio/export
>>>>> -sh: echo: write error: Device or resource busy
>>>>>
>>>>> Because for pca955x_gpio_request_pin() this is at offset 0 (in fact is 
>>>>> the first gpio registered of this gpio_chip) but it's the index 1 inside 
>>>>> pca955x->leds[]
>>>>>
>>>>> Am I missing something? (maybe I made a mistake in my backport and/or I'm 
>>>>> missing some patches about the GPIO subsystems).
>>>>>
>>>>> If I'm right I think I can send a patch to fix this (I'm thinking about 
>>>>> having an array of GPIO index to map offset -> pca955x->leds[] index or 
>>>>> just register all pins as GPIOs and then just report the busy state)
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Kind Regards,
>>>>>
>>>
>>

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/17/2017 11:16 AM, Andrea Scian - DAVE Embedded Systems wrote:
> 
>> On 10/17/2017 10:20 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>
>>> Il 17/10/2017 10:18, Cédric Le Goater ha scritto:
>>>> On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>>>> Dear all,
>>>>>
>>>>> I'm working on an iMX6 based board with a PCA9555 which is used both to 
>>>>> drive LEDs and manage some GPIOs.
>>>> The PCA9555 chip and the PCA955[0-3] chips have different control
>>>> registers. You need a different led driver for it.
>>>
>>> My typo sorry, as you can see in the device tree below, I'm using pca9551
>>
>> ok.
>>
>> You might want to take a look at how we mixed gpios and leds on the 
>> witherspoon
>> system using pca9552 chips. we added a gpio-leds binding.
>>
>> https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> 
> understood: you configure all pins of PCA955x as GPIOs and the map the one 
> you need as led with gpio-leds binding.

Sorry I got distracted.

> However to me this is a kind of workaround or, at least, there's nothing 
> about this limitation into the devicetree binding (in fact, IMHO, the device 
> tree binding example will just fail)

euh ? what do you mean. There is a real system using this device tree. 
I think we would know about it if it didn't work. Please explain

> I wrote the attached patch which should fix the issue and allow a more 
> generic approach. WDYT?
> 
> (in case it looks good, I'll send the patch in the correct way)

Please send the patch to discuss, add Andrew Jeffery  
in cc:

Thanks,

C.


> 
> Kind Regards,
> 
> Andrea
> 
>>>
>>>>> My current kernel is quite old (4.1.15) but I've found Cédric patches on 
>>>>> mainline and backported to this old revision.
>>>>>
>>>>> I'm facing an issue with it, because it seems that it fails when it's 
>>>>> used in a mixed (led/gpios) environment.
>>>>>
>>>>> E.g.: let's say that I have one led connected to LED0 output and one GPIO 
>>>>> connected at LED1 output.
>>>>>
>>>>> I define it as
>>>>>
>>>>>   pca9551: pca9551@60 {
>>>>>   compatible = "nxp,pca9551";
>>>>>   reg = <0x60>;
>>>>>   #address-cells = <1>;
>>>>>   #size-cells = <0>;
>>>>>   #gpio-cells = <1>;
>>>>>
>>>>>   led@0 {
>>>>>   label = "led0";
>>>>>   reg = <0>;
>>>>>   linux,default-trigger = "none";
>>>>>   };
>>>>>   gpio@1 {
>>>>>   label = "gpio1";
>>>>>   reg = <1>;
>>>>>   type = <2>; /* GPIO */
>>>>>   };
>>>>>               };
>>>>>
>>>>> At boot it's probed as
>>>>>
>>>>> root@sbc-lynx:~# dmesg | grep pca
>>>>> [    5.315425] leds-pca955x 5-0060: leds-pca955x: Using pca9551 8-bit LED 
>>>>> driver at slave address 0x60
>>>>> [    5.350349] leds-pca955x 5-0060: gpios 511...511
>>>>>
>>>>> But I cannot access it:
>>>>>
>>>>> root@sbc-lynx:~# echo 511 > /sys/class/gpio/export
>>>>> -sh: echo: write error: Device or resource busy
>>>>>
>>>>> Because for pca955x_gpio_request_pin() this is at offset 0 (in fact is 
>>>>> the first gpio registered of this gpio_chip) but it's the index 1 inside 
>>>>> pca955x->leds[]
>>>>>
>>>>> Am I missing something? (maybe I made a mistake in my backport and/or I'm 
>>>>> missing some patches about the GPIO subsystems).
>>>>>
>>>>> If I'm right I think I can send a patch to fix this (I'm thinking about 
>>>>> having an array of GPIO index to map offset -> pca955x->leds[] index or 
>>>>> just register all pins as GPIOs and then just report the busy state)
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Kind Regards,
>>>>>
>>>
>>

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
> Dear all,
> 
> I'm working on an iMX6 based board with a PCA9555 which is used both to drive 
> LEDs and manage some GPIOs.

The PCA9555 chip and the PCA955[0-3] chips have different control 
registers. You need a different led driver for it.

C.  

> My current kernel is quite old (4.1.15) but I've found Cédric patches on 
> mainline and backported to this old revision.
> 
> I'm facing an issue with it, because it seems that it fails when it's used in 
> a mixed (led/gpios) environment.
> 
> E.g.: let's say that I have one led connected to LED0 output and one GPIO 
> connected at LED1 output.
> 
> I define it as
> 
>     pca9551: pca9551@60 {
>     compatible = "nxp,pca9551";
>     reg = <0x60>;
>     #address-cells = <1>;
>     #size-cells = <0>;
>     #gpio-cells = <1>;
> 
>     led@0 {
>     label = "led0";
>     reg = <0>;
>     linux,default-trigger = "none";
>     };
>     gpio@1 {
>     label = "gpio1";
>     reg = <1>;
>     type = <2>; /* GPIO */
>     };
>                 };
> 
> At boot it's probed as
> 
> root@sbc-lynx:~# dmesg | grep pca
> [    5.315425] leds-pca955x 5-0060: leds-pca955x: Using pca9551 8-bit LED 
> driver at slave address 0x60
> [    5.350349] leds-pca955x 5-0060: gpios 511...511
> 
> But I cannot access it:
> 
> root@sbc-lynx:~# echo 511 > /sys/class/gpio/export
> -sh: echo: write error: Device or resource busy
> 
> Because for pca955x_gpio_request_pin() this is at offset 0 (in fact is the 
> first gpio registered of this gpio_chip) but it's the index 1 inside 
> pca955x->leds[]
> 
> Am I missing something? (maybe I made a mistake in my backport and/or I'm 
> missing some patches about the GPIO subsystems).
> 
> If I'm right I think I can send a patch to fix this (I'm thinking about 
> having an array of GPIO index to map offset -> pca955x->leds[] index or just 
> register all pins as GPIOs and then just report the busy state)
> 
> WDYT?
> 
> Kind Regards,
> 

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
> Dear all,
> 
> I'm working on an iMX6 based board with a PCA9555 which is used both to drive 
> LEDs and manage some GPIOs.

The PCA9555 chip and the PCA955[0-3] chips have different control 
registers. You need a different led driver for it.

C.  

> My current kernel is quite old (4.1.15) but I've found Cédric patches on 
> mainline and backported to this old revision.
> 
> I'm facing an issue with it, because it seems that it fails when it's used in 
> a mixed (led/gpios) environment.
> 
> E.g.: let's say that I have one led connected to LED0 output and one GPIO 
> connected at LED1 output.
> 
> I define it as
> 
>     pca9551: pca9551@60 {
>     compatible = "nxp,pca9551";
>     reg = <0x60>;
>     #address-cells = <1>;
>     #size-cells = <0>;
>     #gpio-cells = <1>;
> 
>     led@0 {
>     label = "led0";
>     reg = <0>;
>     linux,default-trigger = "none";
>     };
>     gpio@1 {
>     label = "gpio1";
>     reg = <1>;
>     type = <2>; /* GPIO */
>     };
>                 };
> 
> At boot it's probed as
> 
> root@sbc-lynx:~# dmesg | grep pca
> [    5.315425] leds-pca955x 5-0060: leds-pca955x: Using pca9551 8-bit LED 
> driver at slave address 0x60
> [    5.350349] leds-pca955x 5-0060: gpios 511...511
> 
> But I cannot access it:
> 
> root@sbc-lynx:~# echo 511 > /sys/class/gpio/export
> -sh: echo: write error: Device or resource busy
> 
> Because for pca955x_gpio_request_pin() this is at offset 0 (in fact is the 
> first gpio registered of this gpio_chip) but it's the index 1 inside 
> pca955x->leds[]
> 
> Am I missing something? (maybe I made a mistake in my backport and/or I'm 
> missing some patches about the GPIO subsystems).
> 
> If I'm right I think I can send a patch to fix this (I'm thinking about 
> having an array of GPIO index to map offset -> pca955x->leds[] index or just 
> register all pins as GPIOs and then just report the busy state)
> 
> WDYT?
> 
> Kind Regards,
> 

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/17/2017 10:20 AM, Andrea Scian - DAVE Embedded Systems wrote:
> 
> Il 17/10/2017 10:18, Cédric Le Goater ha scritto:
>> On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>> Dear all,
>>>
>>> I'm working on an iMX6 based board with a PCA9555 which is used both to 
>>> drive LEDs and manage some GPIOs.
>> The PCA9555 chip and the PCA955[0-3] chips have different control
>> registers. You need a different led driver for it.
> 
> My typo sorry, as you can see in the device tree below, I'm using pca9551

ok.

You might want to take a look at how we mixed gpios and leds on the witherspoon
system using pca9552 chips. we added a gpio-leds binding.

https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts

Cheers,

C. 

> 
>>> My current kernel is quite old (4.1.15) but I've found Cédric patches on 
>>> mainline and backported to this old revision.
>>>
>>> I'm facing an issue with it, because it seems that it fails when it's used 
>>> in a mixed (led/gpios) environment.
>>>
>>> E.g.: let's say that I have one led connected to LED0 output and one GPIO 
>>> connected at LED1 output.
>>>
>>> I define it as
>>>
>>>  pca9551: pca9551@60 {
>>>  compatible = "nxp,pca9551";
>>>  reg = <0x60>;
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>>  #gpio-cells = <1>;
>>>
>>>  led@0 {
>>>  label = "led0";
>>>  reg = <0>;
>>>  linux,default-trigger = "none";
>>>  };
>>>  gpio@1 {
>>>  label = "gpio1";
>>>  reg = <1>;
>>>  type = <2>; /* GPIO */
>>>  };
>>>              };
>>>
>>> At boot it's probed as
>>>
>>> root@sbc-lynx:~# dmesg | grep pca
>>> [    5.315425] leds-pca955x 5-0060: leds-pca955x: Using pca9551 8-bit LED 
>>> driver at slave address 0x60
>>> [    5.350349] leds-pca955x 5-0060: gpios 511...511
>>>
>>> But I cannot access it:
>>>
>>> root@sbc-lynx:~# echo 511 > /sys/class/gpio/export
>>> -sh: echo: write error: Device or resource busy
>>>
>>> Because for pca955x_gpio_request_pin() this is at offset 0 (in fact is the 
>>> first gpio registered of this gpio_chip) but it's the index 1 inside 
>>> pca955x->leds[]
>>>
>>> Am I missing something? (maybe I made a mistake in my backport and/or I'm 
>>> missing some patches about the GPIO subsystems).
>>>
>>> If I'm right I think I can send a patch to fix this (I'm thinking about 
>>> having an array of GPIO index to map offset -> pca955x->leds[] index or 
>>> just register all pins as GPIOs and then just report the busy state)
>>>
>>> WDYT?
>>>
>>> Kind Regards,
>>>
> 

Re: about pca955x led driver gpio management

[Cédric Le Goater]

On 10/17/2017 10:20 AM, Andrea Scian - DAVE Embedded Systems wrote:
> 
> Il 17/10/2017 10:18, Cédric Le Goater ha scritto:
>> On 10/17/2017 09:36 AM, Andrea Scian - DAVE Embedded Systems wrote:
>>> Dear all,
>>>
>>> I'm working on an iMX6 based board with a PCA9555 which is used both to 
>>> drive LEDs and manage some GPIOs.
>> The PCA9555 chip and the PCA955[0-3] chips have different control
>> registers. You need a different led driver for it.
> 
> My typo sorry, as you can see in the device tree below, I'm using pca9551

ok.

You might want to take a look at how we mixed gpios and leds on the witherspoon
system using pca9552 chips. we added a gpio-leds binding.

https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts

Cheers,

C. 

> 
>>> My current kernel is quite old (4.1.15) but I've found Cédric patches on 
>>> mainline and backported to this old revision.
>>>
>>> I'm facing an issue with it, because it seems that it fails when it's used 
>>> in a mixed (led/gpios) environment.
>>>
>>> E.g.: let's say that I have one led connected to LED0 output and one GPIO 
>>> connected at LED1 output.
>>>
>>> I define it as
>>>
>>>  pca9551: pca9551@60 {
>>>  compatible = "nxp,pca9551";
>>>  reg = <0x60>;
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>>  #gpio-cells = <1>;
>>>
>>>  led@0 {
>>>  label = "led0";
>>>  reg = <0>;
>>>  linux,default-trigger = "none";
>>>  };
>>>  gpio@1 {
>>>  label = "gpio1";
>>>  reg = <1>;
>>>  type = <2>; /* GPIO */
>>>  };
>>>              };
>>>
>>> At boot it's probed as
>>>
>>> root@sbc-lynx:~# dmesg | grep pca
>>> [    5.315425] leds-pca955x 5-0060: leds-pca955x: Using pca9551 8-bit LED 
>>> driver at slave address 0x60
>>> [    5.350349] leds-pca955x 5-0060: gpios 511...511
>>>
>>> But I cannot access it:
>>>
>>> root@sbc-lynx:~# echo 511 > /sys/class/gpio/export
>>> -sh: echo: write error: Device or resource busy
>>>
>>> Because for pca955x_gpio_request_pin() this is at offset 0 (in fact is the 
>>> first gpio registered of this gpio_chip) but it's the index 1 inside 
>>> pca955x->leds[]
>>>
>>> Am I missing something? (maybe I made a mistake in my backport and/or I'm 
>>> missing some patches about the GPIO subsystems).
>>>
>>> If I'm right I think I can send a patch to fix this (I'm thinking about 
>>> having an array of GPIO index to map offset -> pca955x->leds[] index or 
>>> just register all pins as GPIOs and then just report the busy state)
>>>
>>> WDYT?
>>>
>>> Kind Regards,
>>>
> 

Re: linux-next: build warning after merge of the powerpc tree

[Cédric Le Goater]

On 09/04/2017 10:53 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
> 
> WARNING: vmlinux.o(.text+0xa7cb8): Section mismatch in reference from the 
> function .xive_spapr_init() to the function .init.text:.xive_core_init()
> The function .xive_spapr_init() references
> the function __init .xive_core_init().
> This is often because .xive_spapr_init lacks a __init 
> annotation or the annotation of .xive_core_init is wrong.
> 
> Introduced by commit
> 
>   eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt 
> controller")
> 

yes. I just sent a patch for this :

http://patchwork.ozlabs.org/patch/809542/

Cheers,

C.

Re: linux-next: build warning after merge of the powerpc tree

[Cédric Le Goater]

On 09/04/2017 10:53 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
> 
> WARNING: vmlinux.o(.text+0xa7cb8): Section mismatch in reference from the 
> function .xive_spapr_init() to the function .init.text:.xive_core_init()
> The function .xive_spapr_init() references
> the function __init .xive_core_init().
> This is often because .xive_spapr_init lacks a __init 
> annotation or the annotation of .xive_core_init is wrong.
> 
> Introduced by commit
> 
>   eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt 
> controller")
> 

yes. I just sent a patch for this :

http://patchwork.ozlabs.org/patch/809542/

Cheers,

C.

Re: [PATCH v2] leds: pca955x: Don't invert requested value in pca955x_gpio_set_value()

[Cédric Le Goater]

value;
>   return _gpiod_direction_output_raw(desc, value);
>  }
> 
> All-in-all, with a value of 'keep' for default-state property in a
> leds-gpio child node, the current state of the hardware will in-fact be
> inverted; precisely the opposite of what was intended.
> 
> Rework leds-pca955x so that we avoid the incorrect inversion and clarify
> the semantics with respect to GPIO.
> 
> Signed-off-by: Andrew Jeffery <and...@aj.id.au>

Reviewed-by: Cédric Le Goater <c...@kaod.org>

Thanks for digging into the code, that was a lot of inversions.

C.

> ---
> 
> I've rebased on top of "1591caf2d5ea leds: pca955x: check for I2C errors" and
> resolved the conflicts.
> 
>  drivers/leds/leds-pca955x.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
> index 905729191d3e..6dcd2d7cc6a4 100644
> --- a/drivers/leds/leds-pca955x.c
> +++ b/drivers/leds/leds-pca955x.c
> @@ -61,6 +61,9 @@
>  #define PCA955X_LS_BLINK00x2 /* Blink at PWM0 rate */
>  #define PCA955X_LS_BLINK10x3 /* Blink at PWM1 rate */
>  
> +#define PCA955X_GPIO_HIGHLED_OFF
> +#define PCA955X_GPIO_LOW LED_FULL
> +
>  enum pca955x_type {
>   pca9550,
>   pca9551,
> @@ -329,9 +332,9 @@ static int pca955x_set_value(struct gpio_chip *gc, 
> unsigned int offset,
>   struct pca955x_led *led = >leds[offset];
>  
>   if (val)
> - return pca955x_led_set(>led_cdev, LED_FULL);
> - else
> - return pca955x_led_set(>led_cdev, LED_OFF);
> + return pca955x_led_set(>led_cdev, PCA955X_GPIO_HIGH);
> +
> + return pca955x_led_set(>led_cdev, PCA955X_GPIO_LOW);
>  }
>  
>  static void pca955x_gpio_set_value(struct gpio_chip *gc, unsigned int offset,
> 

Re: [PATCH v2] leds: pca955x: Don't invert requested value in pca955x_gpio_set_value()

[Cédric Le Goater]

value;
>   return _gpiod_direction_output_raw(desc, value);
>  }
> 
> All-in-all, with a value of 'keep' for default-state property in a
> leds-gpio child node, the current state of the hardware will in-fact be
> inverted; precisely the opposite of what was intended.
> 
> Rework leds-pca955x so that we avoid the incorrect inversion and clarify
> the semantics with respect to GPIO.
> 
> Signed-off-by: Andrew Jeffery 

Reviewed-by: Cédric Le Goater 

Thanks for digging into the code, that was a lot of inversions.

C.

> ---
> 
> I've rebased on top of "1591caf2d5ea leds: pca955x: check for I2C errors" and
> resolved the conflicts.
> 
>  drivers/leds/leds-pca955x.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
> index 905729191d3e..6dcd2d7cc6a4 100644
> --- a/drivers/leds/leds-pca955x.c
> +++ b/drivers/leds/leds-pca955x.c
> @@ -61,6 +61,9 @@
>  #define PCA955X_LS_BLINK00x2 /* Blink at PWM0 rate */
>  #define PCA955X_LS_BLINK10x3 /* Blink at PWM1 rate */
>  
> +#define PCA955X_GPIO_HIGHLED_OFF
> +#define PCA955X_GPIO_LOW LED_FULL
> +
>  enum pca955x_type {
>   pca9550,
>   pca9551,
> @@ -329,9 +332,9 @@ static int pca955x_set_value(struct gpio_chip *gc, 
> unsigned int offset,
>   struct pca955x_led *led = >leds[offset];
>  
>   if (val)
> - return pca955x_led_set(>led_cdev, LED_FULL);
> - else
> - return pca955x_led_set(>led_cdev, LED_OFF);
> + return pca955x_led_set(>led_cdev, PCA955X_GPIO_HIGH);
> +
> + return pca955x_led_set(>led_cdev, PCA955X_GPIO_LOW);
>  }
>  
>  static void pca955x_gpio_set_value(struct gpio_chip *gc, unsigned int offset,
> 

Re: [PATCH] i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency

[Cédric Le Goater]

On 08/16/2017 08:49 AM, Joel Stanley wrote:
> On Tue, Aug 15, 2017 at 4:51 PM, Andrew Jeffery  wrote:
>> In addition to the base, low and high clock configuration, the AC timing
>> register #1 on the AST2400 houses fields controlling:
>>
>> 1. tBUF: Minimum delay between Stop and Start conditions
>> 2. tHDSTA: Hold time for the Start condition
>> 3. tACST: Setup time for Start and Stop conditions, and hold time for the
>>Repeated Start condition
>>
>> These values are defined in hardware on the AST2500 and therefore don't
>> need to be set.
>>
>> aspeed_i2c_init_clk() was performing a direct write of the generated
>> clock values rather than a read/mask/modify/update sequence to retain
>> tBUF, tHDSTA and tACST, and therefore cleared the tBUF, tHDSTA and tACST
>> fields on the AST2400. This resulted in a delay/setup/hold time of 1
>> base clock, which in some configurations is not enough for some devices
>> (e.g. the MAX31785 fan controller, with an APB of 48MHz and a desired
>> bus speed of 100kHz).
>>
>> Signed-off-by: Andrew Jeffery 
>> ---
>>  drivers/i2c/busses/i2c-aspeed.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-aspeed.c 
>> b/drivers/i2c/busses/i2c-aspeed.c
>> index ee76e6dddc4b..284f8670dbeb 100644
>> --- a/drivers/i2c/busses/i2c-aspeed.c
>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>> @@ -53,6 +53,9 @@
>>  #define ASPEED_I2CD_MASTER_EN  BIT(0)
>>
>>  /* 0x04 : I2CD Clock and AC Timing Control Register #1 */
>> +#define ASPEED_I2CD_TIME_TBUF_MASK GENMASK(31, 28)
>> +#define ASPEED_I2CD_TIME_THDSTA_MASK   GENMASK(27, 24)
>> +#define ASPEED_I2CD_TIME_TACST_MASKGENMASK(23, 20)
>>  #define ASPEED_I2CD_TIME_SCL_HIGH_SHIFT16
>>  #define ASPEED_I2CD_TIME_SCL_HIGH_MASK GENMASK(19, 16)
>>  #define ASPEED_I2CD_TIME_SCL_LOW_SHIFT 12
>> @@ -744,7 +747,11 @@ static int aspeed_i2c_init_clk(struct aspeed_i2c_bus 
>> *bus)
>> u32 divisor, clk_reg_val;
>>
>> divisor = DIV_ROUND_UP(bus->parent_clk_frequency, 
>> bus->bus_frequency);
>> -   clk_reg_val = bus->get_clk_reg_val(divisor);
>> +   clk_reg_val = readl(bus->base + ASPEED_I2C_AC_TIMING_REG1);
>> +   clk_reg_val &= (ASPEED_I2CD_TIME_TBUF_MASK |
>> +   ASPEED_I2CD_TIME_THDSTA_MASK |
>> +   ASPEED_I2CD_TIME_TACST_MASK);
> 
> Instead of keeping the u-boot values (which appear to be hard-coded),
> should we instead put the known working values in the register?

Yes. I was wondering where the initial setting was from on the AST400.

C.

Re: [PATCH] i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency

[Cédric Le Goater]

On 08/16/2017 08:49 AM, Joel Stanley wrote:
> On Tue, Aug 15, 2017 at 4:51 PM, Andrew Jeffery  wrote:
>> In addition to the base, low and high clock configuration, the AC timing
>> register #1 on the AST2400 houses fields controlling:
>>
>> 1. tBUF: Minimum delay between Stop and Start conditions
>> 2. tHDSTA: Hold time for the Start condition
>> 3. tACST: Setup time for Start and Stop conditions, and hold time for the
>>Repeated Start condition
>>
>> These values are defined in hardware on the AST2500 and therefore don't
>> need to be set.
>>
>> aspeed_i2c_init_clk() was performing a direct write of the generated
>> clock values rather than a read/mask/modify/update sequence to retain
>> tBUF, tHDSTA and tACST, and therefore cleared the tBUF, tHDSTA and tACST
>> fields on the AST2400. This resulted in a delay/setup/hold time of 1
>> base clock, which in some configurations is not enough for some devices
>> (e.g. the MAX31785 fan controller, with an APB of 48MHz and a desired
>> bus speed of 100kHz).
>>
>> Signed-off-by: Andrew Jeffery 
>> ---
>>  drivers/i2c/busses/i2c-aspeed.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-aspeed.c 
>> b/drivers/i2c/busses/i2c-aspeed.c
>> index ee76e6dddc4b..284f8670dbeb 100644
>> --- a/drivers/i2c/busses/i2c-aspeed.c
>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>> @@ -53,6 +53,9 @@
>>  #define ASPEED_I2CD_MASTER_EN  BIT(0)
>>
>>  /* 0x04 : I2CD Clock and AC Timing Control Register #1 */
>> +#define ASPEED_I2CD_TIME_TBUF_MASK GENMASK(31, 28)
>> +#define ASPEED_I2CD_TIME_THDSTA_MASK   GENMASK(27, 24)
>> +#define ASPEED_I2CD_TIME_TACST_MASKGENMASK(23, 20)
>>  #define ASPEED_I2CD_TIME_SCL_HIGH_SHIFT16
>>  #define ASPEED_I2CD_TIME_SCL_HIGH_MASK GENMASK(19, 16)
>>  #define ASPEED_I2CD_TIME_SCL_LOW_SHIFT 12
>> @@ -744,7 +747,11 @@ static int aspeed_i2c_init_clk(struct aspeed_i2c_bus 
>> *bus)
>> u32 divisor, clk_reg_val;
>>
>> divisor = DIV_ROUND_UP(bus->parent_clk_frequency, 
>> bus->bus_frequency);
>> -   clk_reg_val = bus->get_clk_reg_val(divisor);
>> +   clk_reg_val = readl(bus->base + ASPEED_I2C_AC_TIMING_REG1);
>> +   clk_reg_val &= (ASPEED_I2CD_TIME_TBUF_MASK |
>> +   ASPEED_I2CD_TIME_THDSTA_MASK |
>> +   ASPEED_I2CD_TIME_TACST_MASK);
> 
> Instead of keeping the u-boot values (which appear to be hard-coded),
> should we instead put the known working values in the register?

Yes. I was wondering where the initial setting was from on the AST400.

C.

Re: [PATCH] i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency

[Cédric Le Goater]

On 08/16/2017 08:59 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2017-08-16 at 08:53 +0200, Cédric Le Goater wrote:
>>>>  divisor = DIV_ROUND_UP(bus->parent_clk_frequency, 
>>>> bus->bus_frequency);
>>>> -   clk_reg_val = bus->get_clk_reg_val(divisor);
>>>> +   clk_reg_val = readl(bus->base + ASPEED_I2C_AC_TIMING_REG1);
>>>> +   clk_reg_val &= (ASPEED_I2CD_TIME_TBUF_MASK |
>>>> +   ASPEED_I2CD_TIME_THDSTA_MASK |
>>>> +   ASPEED_I2CD_TIME_TACST_MASK);
>>>
>>> Instead of keeping the u-boot values (which appear to be hard-coded),
>>> should we instead put the known working values in the register?
>>
>> Yes. I was wondering where the initial setting was from on the AST400.
> 
> Well, the AST2500 hard codes them in HW, so it makes some amount of
> sense to use whatever aspeed platform.S hard codes in u-boot for the
> 2400. The values look reasonably sane.
> 
> If we ever see a need to change them, we can add DT props etc... but
> for now I'd just not bother.
> 
> The way it is now, at least, if I have problems, I can tweak the values
> with devmem and try again without the driver overwriting them :-)

ah yes. that is useful I agree. 

C.

Re: [PATCH] i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency

[Cédric Le Goater]

On 08/16/2017 08:59 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2017-08-16 at 08:53 +0200, Cédric Le Goater wrote:
>>>>  divisor = DIV_ROUND_UP(bus->parent_clk_frequency, 
>>>> bus->bus_frequency);
>>>> -   clk_reg_val = bus->get_clk_reg_val(divisor);
>>>> +   clk_reg_val = readl(bus->base + ASPEED_I2C_AC_TIMING_REG1);
>>>> +   clk_reg_val &= (ASPEED_I2CD_TIME_TBUF_MASK |
>>>> +   ASPEED_I2CD_TIME_THDSTA_MASK |
>>>> +   ASPEED_I2CD_TIME_TACST_MASK);
>>>
>>> Instead of keeping the u-boot values (which appear to be hard-coded),
>>> should we instead put the known working values in the register?
>>
>> Yes. I was wondering where the initial setting was from on the AST400.
> 
> Well, the AST2500 hard codes them in HW, so it makes some amount of
> sense to use whatever aspeed platform.S hard codes in u-boot for the
> 2400. The values look reasonably sane.
> 
> If we ever see a need to change them, we can add DT props etc... but
> for now I'd just not bother.
> 
> The way it is now, at least, if I have problems, I can tweak the values
> with devmem and try again without the driver overwriting them :-)

ah yes. that is useful I agree. 

C.

Re: [RFC v1 4/4] ipmi_bmc: bt-aspeed: port driver to IPMI BMC framework

[Cédric Le Goater]

On 08/10/2017 04:31 AM, Jeremy Kerr wrote:
> Hi Brendan,
> 
>> The driver was handling interaction with userspace on its own. This
>> patch changes it to use the functionality of the ipmi_bmc framework
>> instead.
>>
>> Note that this removes the ability for the BMC to set SMS_ATN by making
>> an ioctl. If this functionality is required, it can be added back in
>> with a later patch.
> 
> As Chris has mentioned, we do use this actively at the moment, so I'd
> prefer if we could not drop the support for SMS_ATN. However, using a
> different interface should be fine, if that helps.

The ioctl is part of the kernel user API now. We should keep it.

Thanks,

C.  

Re: [RFC v1 4/4] ipmi_bmc: bt-aspeed: port driver to IPMI BMC framework

[Cédric Le Goater]

On 08/10/2017 04:31 AM, Jeremy Kerr wrote:
> Hi Brendan,
> 
>> The driver was handling interaction with userspace on its own. This
>> patch changes it to use the functionality of the ipmi_bmc framework
>> instead.
>>
>> Note that this removes the ability for the BMC to set SMS_ATN by making
>> an ioctl. If this functionality is required, it can be added back in
>> with a later patch.
> 
> As Chris has mentioned, we do use this actively at the moment, so I'd
> prefer if we could not drop the support for SMS_ATN. However, using a
> different interface should be fine, if that helps.

The ioctl is part of the kernel user API now. We should keep it.

Thanks,

C.  

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Cédric Le Goater]

On 06/20/2017 09:15 AM, Shilpasri G Bhat wrote:
> 
> 
> On 06/20/2017 11:36 AM, Cédric Le Goater wrote:
>> On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
>>> From: Cédric Le Goater <c...@kaod.org>
>>>
>>> Today, the type of a PowerNV sensor system is determined with the
>>> "compatible" property for legacy Firmwares and with the "sensor-type"
>>> for newer ones. The same array of strings is used for both to do the
>>> matching and this raises some issue to introduce new sensor types.
>>>
>>> Let's introduce two different arrays (legacy and current) to make
>>> things easier for new sensor types.
>>>
>>> Signed-off-by: Cédric Le Goater <c...@kaod.org>
>>> Tested-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
>>
>> Did you test on a Tuleta (IBM Power) system ? 
> 
> I have tested this patch on P9 FSP and Firestone.

OK. I just gave it a try on a Tuleta, P8 FSP, IBM Power system
Looks good.

Thanks,

C.

> 
>>
>> Thanks,
>>
>> C. 
>>
>>> ---
>>>  drivers/hwmon/ibmpowernv.c | 26 ++
>>>  1 file changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>>> index 862b832..6d8909c 100644
>>> --- a/drivers/hwmon/ibmpowernv.c
>>> +++ b/drivers/hwmon/ibmpowernv.c
>>> @@ -55,17 +55,27 @@ enum sensors {
>>>  
>>>  #define INVALID_INDEX (-1U)
>>>  
>>> +/*
>>> + * 'compatible' string properties for sensor types as defined in old
>>> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
>>> + */
>>> +static const char * const legacy_compatibles[] = {
>>> +   "ibm,opal-sensor-cooling-fan",
>>> +   "ibm,opal-sensor-amb-temp",
>>> +   "ibm,opal-sensor-power-supply",
>>> +   "ibm,opal-sensor-power"
>>> +};
>>> +
>>>  static struct sensor_group {
>>> -   const char *name;
>>> -   const char *compatible;
>>> +   const char *name; /* matches property 'sensor-type' */
>>> struct attribute_group group;
>>> u32 attr_count;
>>> u32 hwmon_index;
>>>  } sensor_groups[] = {
>>> -   {"fan", "ibm,opal-sensor-cooling-fan"},
>>> -   {"temp", "ibm,opal-sensor-amb-temp"},
>>> -   {"in", "ibm,opal-sensor-power-supply"},
>>> -   {"power", "ibm,opal-sensor-power"}
>>> +   { "fan"   },
>>> +   { "temp"  },
>>> +   { "in"},
>>> +   { "power" }
>>>  };
>>>  
>>>  struct sensor_data {
>>> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>>> enum sensors type;
>>> const char *str;
>>>  
>>> -   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
>>> -   if (of_device_is_compatible(np, sensor_groups[type].compatible))
>>> +   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
>>> +   if (of_device_is_compatible(np, legacy_compatibles[type]))
>>> return type;
>>> }
>>>  
>>>
>>
> 

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Cédric Le Goater]

On 06/20/2017 09:15 AM, Shilpasri G Bhat wrote:
> 
> 
> On 06/20/2017 11:36 AM, Cédric Le Goater wrote:
>> On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
>>> From: Cédric Le Goater 
>>>
>>> Today, the type of a PowerNV sensor system is determined with the
>>> "compatible" property for legacy Firmwares and with the "sensor-type"
>>> for newer ones. The same array of strings is used for both to do the
>>> matching and this raises some issue to introduce new sensor types.
>>>
>>> Let's introduce two different arrays (legacy and current) to make
>>> things easier for new sensor types.
>>>
>>> Signed-off-by: Cédric Le Goater 
>>> Tested-by: Shilpasri G Bhat 
>>
>> Did you test on a Tuleta (IBM Power) system ? 
> 
> I have tested this patch on P9 FSP and Firestone.

OK. I just gave it a try on a Tuleta, P8 FSP, IBM Power system
Looks good.

Thanks,

C.

> 
>>
>> Thanks,
>>
>> C. 
>>
>>> ---
>>>  drivers/hwmon/ibmpowernv.c | 26 ++
>>>  1 file changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>>> index 862b832..6d8909c 100644
>>> --- a/drivers/hwmon/ibmpowernv.c
>>> +++ b/drivers/hwmon/ibmpowernv.c
>>> @@ -55,17 +55,27 @@ enum sensors {
>>>  
>>>  #define INVALID_INDEX (-1U)
>>>  
>>> +/*
>>> + * 'compatible' string properties for sensor types as defined in old
>>> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
>>> + */
>>> +static const char * const legacy_compatibles[] = {
>>> +   "ibm,opal-sensor-cooling-fan",
>>> +   "ibm,opal-sensor-amb-temp",
>>> +   "ibm,opal-sensor-power-supply",
>>> +   "ibm,opal-sensor-power"
>>> +};
>>> +
>>>  static struct sensor_group {
>>> -   const char *name;
>>> -   const char *compatible;
>>> +   const char *name; /* matches property 'sensor-type' */
>>> struct attribute_group group;
>>> u32 attr_count;
>>> u32 hwmon_index;
>>>  } sensor_groups[] = {
>>> -   {"fan", "ibm,opal-sensor-cooling-fan"},
>>> -   {"temp", "ibm,opal-sensor-amb-temp"},
>>> -   {"in", "ibm,opal-sensor-power-supply"},
>>> -   {"power", "ibm,opal-sensor-power"}
>>> +   { "fan"   },
>>> +   { "temp"  },
>>> +   { "in"},
>>> +   { "power" }
>>>  };
>>>  
>>>  struct sensor_data {
>>> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>>> enum sensors type;
>>> const char *str;
>>>  
>>> -   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
>>> -   if (of_device_is_compatible(np, sensor_groups[type].compatible))
>>> +   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
>>> +   if (of_device_is_compatible(np, legacy_compatibles[type]))
>>> return type;
>>> }
>>>  
>>>
>>
> 

Re: [PATCH V2 2/2] hwmon: (ibmpowernv) Add current(A) sensor

[Cédric Le Goater]

On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
> This patch exports current(A) sensors in inband sensors copied to
> main memory by OCC.
> 
> Signed-off-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>

Reviewed-by: Cédric Le Goater <c...@kaod.org>

Thanks,

C.

> ---
> Changes from V1:
> - Rebased on top of Cedric's patch to remove legay-compatible type for
>   the current(A) sensor.
> 
>  drivers/hwmon/ibmpowernv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 6d8909c..9b11b13 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -50,6 +50,7 @@ enum sensors {
>   TEMP,
>   POWER_SUPPLY,
>   POWER_INPUT,
> + CURRENT,
>   MAX_SENSOR_TYPE,
>  };
>  
> @@ -75,7 +76,8 @@ enum sensors {
>   { "fan"   },
>   { "temp"  },
>   { "in"},
> - { "power" }
> + { "power" },
> + { "curr"  },
>  };
>  
>  struct sensor_data {
> 

Re: [PATCH V2 2/2] hwmon: (ibmpowernv) Add current(A) sensor

[Cédric Le Goater]

On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
> This patch exports current(A) sensors in inband sensors copied to
> main memory by OCC.
> 
> Signed-off-by: Shilpasri G Bhat 

Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
> Changes from V1:
> - Rebased on top of Cedric's patch to remove legay-compatible type for
>   the current(A) sensor.
> 
>  drivers/hwmon/ibmpowernv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 6d8909c..9b11b13 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -50,6 +50,7 @@ enum sensors {
>   TEMP,
>   POWER_SUPPLY,
>   POWER_INPUT,
> + CURRENT,
>   MAX_SENSOR_TYPE,
>  };
>  
> @@ -75,7 +76,8 @@ enum sensors {
>   { "fan"   },
>   { "temp"  },
>   { "in"},
> - { "power" }
> + { "power" },
> + { "curr"  },
>  };
>  
>  struct sensor_data {
> 

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Cédric Le Goater]

On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
> From: Cédric Le Goater <c...@kaod.org>
> 
> Today, the type of a PowerNV sensor system is determined with the
> "compatible" property for legacy Firmwares and with the "sensor-type"
> for newer ones. The same array of strings is used for both to do the
> matching and this raises some issue to introduce new sensor types.
> 
> Let's introduce two different arrays (legacy and current) to make
> things easier for new sensor types.
> 
> Signed-off-by: Cédric Le Goater <c...@kaod.org>
> Tested-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>

Did you test on a Tuleta (IBM Power) system ? 

Thanks,

C. 

> ---
>  drivers/hwmon/ibmpowernv.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 862b832..6d8909c 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -55,17 +55,27 @@ enum sensors {
>  
>  #define INVALID_INDEX (-1U)
>  
> +/*
> + * 'compatible' string properties for sensor types as defined in old
> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
> + */
> +static const char * const legacy_compatibles[] = {
> + "ibm,opal-sensor-cooling-fan",
> + "ibm,opal-sensor-amb-temp",
> + "ibm,opal-sensor-power-supply",
> + "ibm,opal-sensor-power"
> +};
> +
>  static struct sensor_group {
> - const char *name;
> - const char *compatible;
> + const char *name; /* matches property 'sensor-type' */
>   struct attribute_group group;
>   u32 attr_count;
>   u32 hwmon_index;
>  } sensor_groups[] = {
> - {"fan", "ibm,opal-sensor-cooling-fan"},
> - {"temp", "ibm,opal-sensor-amb-temp"},
> - {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + { "fan"   },
> + { "temp"  },
> + { "in"},
> + { "power" }
>  };
>  
>  struct sensor_data {
> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>   enum sensors type;
>   const char *str;
>  
> - for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> - if (of_device_is_compatible(np, sensor_groups[type].compatible))
> + for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
> + if (of_device_is_compatible(np, legacy_compatibles[type]))
>   return type;
>   }
>  
> 

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Cédric Le Goater]

On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
> From: Cédric Le Goater 
> 
> Today, the type of a PowerNV sensor system is determined with the
> "compatible" property for legacy Firmwares and with the "sensor-type"
> for newer ones. The same array of strings is used for both to do the
> matching and this raises some issue to introduce new sensor types.
> 
> Let's introduce two different arrays (legacy and current) to make
> things easier for new sensor types.
> 
> Signed-off-by: Cédric Le Goater 
> Tested-by: Shilpasri G Bhat 

Did you test on a Tuleta (IBM Power) system ? 

Thanks,

C. 

> ---
>  drivers/hwmon/ibmpowernv.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 862b832..6d8909c 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -55,17 +55,27 @@ enum sensors {
>  
>  #define INVALID_INDEX (-1U)
>  
> +/*
> + * 'compatible' string properties for sensor types as defined in old
> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
> + */
> +static const char * const legacy_compatibles[] = {
> + "ibm,opal-sensor-cooling-fan",
> + "ibm,opal-sensor-amb-temp",
> + "ibm,opal-sensor-power-supply",
> + "ibm,opal-sensor-power"
> +};
> +
>  static struct sensor_group {
> - const char *name;
> - const char *compatible;
> + const char *name; /* matches property 'sensor-type' */
>   struct attribute_group group;
>   u32 attr_count;
>   u32 hwmon_index;
>  } sensor_groups[] = {
> - {"fan", "ibm,opal-sensor-cooling-fan"},
> - {"temp", "ibm,opal-sensor-amb-temp"},
> - {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + { "fan"   },
> + { "temp"  },
> + { "in"},
> + { "power" }
>  };
>  
>  struct sensor_data {
> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>   enum sensors type;
>   const char *str;
>  
> - for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> - if (of_device_is_compatible(np, sensor_groups[type].compatible))
> + for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
> + if (of_device_is_compatible(np, legacy_compatibles[type]))
>   return type;
>   }
>  
> 

Re: [PATCH] hwmon: (ibmpowernv) Add current(A) sensors

[Cédric Le Goater]

On 06/19/2017 11:25 AM, Shilpasri G Bhat wrote:
> This patch exports current(A) sensors in inband sensors copied to
> main memory by OCC.
> 
> Signed-off-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
> ---
>  drivers/hwmon/ibmpowernv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 862b832..e0557f9 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -50,6 +50,7 @@ enum sensors {
>   TEMP,
>   POWER_SUPPLY,
>   POWER_INPUT,
> + CURRENT,
>   MAX_SENSOR_TYPE,
>  };
>  
> @@ -65,7 +66,8 @@ enum sensors {
>   {"fan", "ibm,opal-sensor-cooling-fan"},
>   {"temp", "ibm,opal-sensor-amb-temp"},
>   {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + {"power", "ibm,opal-sensor-power"},
> + {"curr", "ibm,opal-sensor-current"},
>  };
>  
>  struct sensor_data {
> 


I know why you are doing that but that is the old (cr?@#!y) way to 
define sensor types. we should try to improve thing a little more 
and use the "sensor-type" property only.

I think the patch below should help you adding new types without 
too much changes to your skiboot patchset. Could you please check ? 

Thanks,

C. 

From: Cédric Le Goater <c...@kaod.org>
Subject: [PATCH] hwmon: (ibmpowernv) introduce a legacy_compatibles array
Date: Mon, 19 Jun 2017 14:29:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Today, the type of a PowerNV sensor system is determined with the
"compatible" property for legacy Firmwares and with the "sensor-type"
for newer ones. The same array of strings is used for both to do the
matching and this raises some issue to introduce new sensor types.

Let's introduce two different arrays (legacy and current) to make
things easier for new sensor types.

Signed-off-by: Cédric Le Goater <c...@kaod.org>
---
 drivers/hwmon/ibmpowernv.c |   26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -55,17 +55,27 @@ enum sensors {
 
 #define INVALID_INDEX (-1U)
 
+/*
+ * 'compatible' string properties for sensor types as defined in old
+ * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
+ */
+static const char * const legacy_compatibles[] = {
+   "ibm,opal-sensor-cooling-fan",
+   "ibm,opal-sensor-amb-temp",
+   "ibm,opal-sensor-power-supply",
+   "ibm,opal-sensor-power"
+};
+
 static struct sensor_group {
-   const char *name;
-   const char *compatible;
+   const char *name; /* matches property 'sensor-type' */
struct attribute_group group;
u32 attr_count;
u32 hwmon_index;
 } sensor_groups[] = {
-   {"fan", "ibm,opal-sensor-cooling-fan"},
-   {"temp", "ibm,opal-sensor-amb-temp"},
-   {"in", "ibm,opal-sensor-power-supply"},
-   {"power", "ibm,opal-sensor-power"}
+   { "fan"   },
+   { "temp"  },
+   { "in"},
+   { "power" }
 };
 
 struct sensor_data {
@@ -239,8 +249,8 @@ static int get_sensor_type(struct device
enum sensors type;
const char *str;
 
-   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
-   if (of_device_is_compatible(np, sensor_groups[type].compatible))
+   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
+   if (of_device_is_compatible(np, legacy_compatibles[type]))
return type;
}
 

Re: [PATCH] hwmon: (ibmpowernv) Add current(A) sensors

[Cédric Le Goater]

On 06/19/2017 11:25 AM, Shilpasri G Bhat wrote:
> This patch exports current(A) sensors in inband sensors copied to
> main memory by OCC.
> 
> Signed-off-by: Shilpasri G Bhat 
> ---
>  drivers/hwmon/ibmpowernv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 862b832..e0557f9 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -50,6 +50,7 @@ enum sensors {
>   TEMP,
>   POWER_SUPPLY,
>   POWER_INPUT,
> + CURRENT,
>   MAX_SENSOR_TYPE,
>  };
>  
> @@ -65,7 +66,8 @@ enum sensors {
>   {"fan", "ibm,opal-sensor-cooling-fan"},
>   {"temp", "ibm,opal-sensor-amb-temp"},
>   {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + {"power", "ibm,opal-sensor-power"},
> + {"curr", "ibm,opal-sensor-current"},
>  };
>  
>  struct sensor_data {
> 


I know why you are doing that but that is the old (cr?@#!y) way to 
define sensor types. we should try to improve thing a little more 
and use the "sensor-type" property only.

I think the patch below should help you adding new types without 
too much changes to your skiboot patchset. Could you please check ? 

Thanks,

C. 

From: Cédric Le Goater 
Subject: [PATCH] hwmon: (ibmpowernv) introduce a legacy_compatibles array
Date: Mon, 19 Jun 2017 14:29:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Today, the type of a PowerNV sensor system is determined with the
"compatible" property for legacy Firmwares and with the "sensor-type"
for newer ones. The same array of strings is used for both to do the
matching and this raises some issue to introduce new sensor types.

Let's introduce two different arrays (legacy and current) to make
things easier for new sensor types.

Signed-off-by: Cédric Le Goater 
---
 drivers/hwmon/ibmpowernv.c |   26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -55,17 +55,27 @@ enum sensors {
 
 #define INVALID_INDEX (-1U)
 
+/*
+ * 'compatible' string properties for sensor types as defined in old
+ * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
+ */
+static const char * const legacy_compatibles[] = {
+   "ibm,opal-sensor-cooling-fan",
+   "ibm,opal-sensor-amb-temp",
+   "ibm,opal-sensor-power-supply",
+   "ibm,opal-sensor-power"
+};
+
 static struct sensor_group {
-   const char *name;
-   const char *compatible;
+   const char *name; /* matches property 'sensor-type' */
struct attribute_group group;
u32 attr_count;
u32 hwmon_index;
 } sensor_groups[] = {
-   {"fan", "ibm,opal-sensor-cooling-fan"},
-   {"temp", "ibm,opal-sensor-amb-temp"},
-   {"in", "ibm,opal-sensor-power-supply"},
-   {"power", "ibm,opal-sensor-power"}
+   { "fan"   },
+   { "temp"  },
+   { "in"},
+   { "power" }
 };
 
 struct sensor_data {
@@ -239,8 +249,8 @@ static int get_sensor_type(struct device
enum sensors type;
const char *str;
 
-   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
-   if (of_device_is_compatible(np, sensor_groups[type].compatible))
+   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
+   if (of_device_is_compatible(np, legacy_compatibles[type]))
return type;
}
 

Re: [PATCH 7/8] clocksource/drivers/fttmr010: Merge Moxa into FTTMR010

[Cédric Le Goater]

On 05/18/2017 11:09 PM, Cédric Le Goater wrote:
> On 05/18/2017 10:20 PM, Linus Walleij wrote:
>> On Thu, May 18, 2017 at 2:43 PM, Linus Walleij <linus.wall...@linaro.org> 
>> wrote:
>>> On Thu, May 18, 2017 at 9:22 AM, Joel Stanley <j...@jms.id.au> wrote:
>>>> On Wed, May 17, 2017 at 10:05 PM, Linus Walleij
>>>> <linus.wall...@linaro.org> wrote:
>>>>> This merges the Moxa Art timer driver into the Faraday FTTMR010
>>>>> driver and replaces all Kconfig symbols to use the Faraday
>>>>> driver instead. We are now so similar that the drivers can
>>>>> be merged by just adding a few lines to the Faraday timer.
>>>>
>>>> Nice work!
>>>>
>>>> I gave this a spin on hardware and it didn't work :(
>>>
>>> How typical.
>>
>> I sent a v2 patch set.
>>
>> I couldn't get qemu to work because Fedora's QEMU is not
>> up-to-date and I didn't want to venture into compiling from source...
>>
>> I did the second best and tested Gemini with downward counting
>> timers, after just adding that as general code path in the driver
>> in the commit merging the two drivers.
>>
>> Please test it, and I hope I'm not wasting too much of your time :/
>>
>> If it still doesn't work I guess I have to try to get qemu going.
>>
>> The fttmr010 branch in my git is updated:
>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/
> 
> So a real AST2500 evb board boot fines with this branch but the timer 
> model in QEMU crashes miserably :
> 
>   [0.00] NR_IRQS:16 nr_irqs:16 16
>   Floating point exception (core dumped)

This is because the FTTMR010 driver enables a timer before setting
its reload value. This is 'against' the specs but the HW works fine
as it only starts decrementing when a reload is set.   

So, I changed the QEMU model.

Cheers,

C.