Re: [PATCH 1/1] [RFC] ethernet: Convert from tasklet to BH workqueue

[Simon Horman]

On Tue, May 07, 2024 at 12:27:10PM -0700, Allen wrote:
> On Tue, May 7, 2024 at 12:23 PM Russell King (Oracle)
>  wrote:
> >
> > On Tue, May 07, 2024 at 07:01:11PM +, Allen Pais wrote:
> > > The only generic interface to execute asynchronously in the BH context is
> > > tasklet; however, it's marked deprecated and has some design flaws. To
> > > replace tasklets, BH workqueue support was recently added. A BH workqueue
> > > behaves similarly to regular workqueues except that the queued work items
> > > are executed in the BH context.
> > >
> > > This patch converts drivers/ethernet/* from tasklet to BH workqueue.
> >
> > I doubt you're going to get many comments on this patch, being so large
> > and spread across all drivers. I'm not going to bother trying to edit
> > this down to something more sensible, I'll just plonk my comment here.
> >
> > For the mvpp2 driver, you're only updating a comment - and looking at
> > it, the comment no longer reflects the code. It doesn't make use of
> > tasklets at all. That makes the comment wrong whether or not it's
> > updated. So I suggest rather than doing a search and replace for
> > "tasklet" to "BH blahblah" (sorry, I don't remember what you replaced
> > it with) just get rid of that bit of the comment.
> >
> 
>  Thank you Russell.
> 
>  I will get rid of the comment. If it helps, I can create a patch for each
> driver. We did that in the past, with this series, I thought it would be
> easier to apply one patch.

Hi Allen and Russell,

My 2c worth:

* In general non bug-fix patches for networking code should be targeted at
  net-next. This means that they should include net-next in the subject,
  and be based on that tree.

  Subject: [PATCH net-next] ...

* This series does not appear to apply to net-next

* This series appears to depend on code which is not present in net-next.
  f.e. disable_work_sync

* The Infiniband patches should probably be submitted separately
  to the relevant maintainers

* As this patch seems to involve many non-trivial changes
  it seems to me that it would be best to break it up somehow.
  To allow proper review.

* Patch-sets for net-next should be limited to 15 patches,
  so perhaps multiple sequential batches would be a way forwards.

Link: https://docs.kernel.org/process/maintainer-netdev.html

Re: [PATCH v3 13/15] sh: Move defines needed for suppressing warning backtraces

[Simon Horman]

On Wed, Apr 03, 2024 at 06:19:34AM -0700, Guenter Roeck wrote:
> Declaring the defines needed for suppressing warning inside
> '#ifdef CONFIG_DEBUG_BUGVERBOSE' results in a kerneldoc warning.
> 
> .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY().
>   Prototype was for HAVE_BUG_FUNCTION() instead
> 
> Move the defines above the kerneldoc entry for _EMIT_BUG_ENTRY
> to make kerneldoc happy.
> 
> Reported-by: Simon Horman 
> Cc: Simon Horman 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: John Paul Adrian Glaubitz 
> Signed-off-by: Guenter Roeck 
> ---
> v3: Added patch. Possibly squash into previous patch.

FWIIW, this looks good to me.

>  arch/sh/include/asm/bug.h | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/sh/include/asm/bug.h b/arch/sh/include/asm/bug.h
> index 470ce6567d20..bf4947d51d69 100644
> --- a/arch/sh/include/asm/bug.h
> +++ b/arch/sh/include/asm/bug.h
> @@ -11,6 +11,15 @@
>  #define HAVE_ARCH_BUG
>  #define HAVE_ARCH_WARN_ON
>  
> +#ifdef CONFIG_DEBUG_BUGVERBOSE
> +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> +# define HAVE_BUG_FUNCTION
> +# define __BUG_FUNC_PTR  "\t.long %O2\n"
> +#else
> +# define __BUG_FUNC_PTR
> +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> +#endif /* CONFIG_DEBUG_BUGVERBOSE */
> +
>  /**
>   * _EMIT_BUG_ENTRY
>   * %1 - __FILE__
> @@ -25,13 +34,6 @@
>   */
>  #ifdef CONFIG_DEBUG_BUGVERBOSE
>  
> -#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> -# define HAVE_BUG_FUNCTION
> -# define __BUG_FUNC_PTR  "\t.long %O2\n"
> -#else
> -# define __BUG_FUNC_PTR
> -#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> -
>  #define _EMIT_BUG_ENTRY  \
>   "\t.pushsection __bug_table,\"aw\"\n"   \
>   "2:\t.long 1b, %O1\n"   \
> -- 
> 2.39.2
> 

Re: [PATCH v2 12/14] sh: Add support for suppressing warning backtraces

[Simon Horman]

On Wed, Mar 27, 2024 at 08:10:51AM -0700, Guenter Roeck wrote:
> On 3/27/24 07:44, Simon Horman wrote:
> > On Mon, Mar 25, 2024 at 10:52:46AM -0700, Guenter Roeck wrote:
> > > Add name of functions triggering warning backtraces to the __bug_table
> > > object section to enable support for suppressing WARNING backtraces.
> > > 
> > > To limit image size impact, the pointer to the function name is only added
> > > to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
> > > CONFIG_DEBUG_BUGVERBOSE are enabled. Otherwise, the __func__ assembly
> > > parameter is replaced with a (dummy) NULL parameter to avoid an image size
> > > increase due to unused __func__ entries (this is necessary because 
> > > __func__
> > > is not a define but a virtual variable).
> > > 
> > > Tested-by: Linux Kernel Functional Testing 
> > > Acked-by: Dan Carpenter 
> > > Signed-off-by: Guenter Roeck 
> > > ---
> > > - Rebased to v6.9-rc1
> > > - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> > > - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option
> > > 
> > >   arch/sh/include/asm/bug.h | 26 ++
> > >   1 file changed, 22 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/arch/sh/include/asm/bug.h b/arch/sh/include/asm/bug.h
> > > index 05a485c4fabc..470ce6567d20 100644
> > > --- a/arch/sh/include/asm/bug.h
> > > +++ b/arch/sh/include/asm/bug.h
> > > @@ -24,21 +24,36 @@
> > >* The offending file and line are encoded in the __bug_table section.
> > >*/
> > >   #ifdef CONFIG_DEBUG_BUGVERBOSE
> > > +
> > > +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> > > +# define HAVE_BUG_FUNCTION
> > > +# define __BUG_FUNC_PTR  "\t.long %O2\n"
> > > +#else
> > > +# define __BUG_FUNC_PTR
> > > +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> > > +
> > 
> > Hi Guenter,
> > 
> > a minor nit from my side: this change results in a Kernel doc warning.
> > 
> >   .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY(). 
> > Prototype was for HAVE_BUG_FUNCTION() instead
> > 
> > Perhaps either the new code should be placed above the Kernel doc,
> > or scripts/kernel-doc should be enhanced?
> > 
> 
> Thanks a lot for the feedback.
> 
> The definition block needs to be inside CONFIG_DEBUG_BUGVERBOSE,
> so it would be a bit odd to move it above the documentation
> just to make kerneldoc happy. I am not really sure that to do
> about it.

FWIIW, I agree that would be odd.
But perhaps the #ifdef could also move above the Kernel doc?
Maybe not a great idea, but the best one I've had so far.

> I'll wait for comments from others before making any changes.
> 
> Thanks,
> Guenter
> 
> > >   #define _EMIT_BUG_ENTRY \
> > >   "\t.pushsection __bug_table,\"aw\"\n"   \
> > >   "2:\t.long 1b, %O1\n"   \
> > > - "\t.short %O2, %O3\n"   \
> > > - "\t.org 2b+%O4\n"   \
> > > + __BUG_FUNC_PTR  \
> > > + "\t.short %O3, %O4\n"   \
> > > + "\t.org 2b+%O5\n"   \
> > >   "\t.popsection\n"
> > >   #else
> > >   #define _EMIT_BUG_ENTRY \
> > >   "\t.pushsection __bug_table,\"aw\"\n"   \
> > >   "2:\t.long 1b\n"\
> > > - "\t.short %O3\n"\
> > > - "\t.org 2b+%O4\n"   \
> > > + "\t.short %O4\n"\
> > > + "\t.org 2b+%O5\n"   \
> > >   "\t.popsection\n"
> > >   #endif
> > > +#ifdef HAVE_BUG_FUNCTION
> > > +# define __BUG_FUNC  __func__
> > > +#else
> > > +# define __BUG_FUNC  NULL
> > > +#endif
> > > +
> > >   #define BUG()   \
> > >   do {\
> > >   __asm__ __volatile__ (  \
> > 
> > ...
> 

Re: [PATCH v2 12/14] sh: Add support for suppressing warning backtraces

[Simon Horman]

On Mon, Mar 25, 2024 at 10:52:46AM -0700, Guenter Roeck wrote:
> Add name of functions triggering warning backtraces to the __bug_table
> object section to enable support for suppressing WARNING backtraces.
> 
> To limit image size impact, the pointer to the function name is only added
> to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
> CONFIG_DEBUG_BUGVERBOSE are enabled. Otherwise, the __func__ assembly
> parameter is replaced with a (dummy) NULL parameter to avoid an image size
> increase due to unused __func__ entries (this is necessary because __func__
> is not a define but a virtual variable).
> 
> Tested-by: Linux Kernel Functional Testing 
> Acked-by: Dan Carpenter 
> Signed-off-by: Guenter Roeck 
> ---
> - Rebased to v6.9-rc1
> - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option
> 
>  arch/sh/include/asm/bug.h | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/sh/include/asm/bug.h b/arch/sh/include/asm/bug.h
> index 05a485c4fabc..470ce6567d20 100644
> --- a/arch/sh/include/asm/bug.h
> +++ b/arch/sh/include/asm/bug.h
> @@ -24,21 +24,36 @@
>   * The offending file and line are encoded in the __bug_table section.
>   */
>  #ifdef CONFIG_DEBUG_BUGVERBOSE
> +
> +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> +# define HAVE_BUG_FUNCTION
> +# define __BUG_FUNC_PTR  "\t.long %O2\n"
> +#else
> +# define __BUG_FUNC_PTR
> +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> +

Hi Guenter,

a minor nit from my side: this change results in a Kernel doc warning.

 .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY(). 
Prototype was for HAVE_BUG_FUNCTION() instead

Perhaps either the new code should be placed above the Kernel doc,
or scripts/kernel-doc should be enhanced?

>  #define _EMIT_BUG_ENTRY  \
>   "\t.pushsection __bug_table,\"aw\"\n"   \
>   "2:\t.long 1b, %O1\n"   \
> - "\t.short %O2, %O3\n"   \
> - "\t.org 2b+%O4\n"   \
> + __BUG_FUNC_PTR  \
> + "\t.short %O3, %O4\n"   \
> + "\t.org 2b+%O5\n"   \
>   "\t.popsection\n"
>  #else
>  #define _EMIT_BUG_ENTRY  \
>   "\t.pushsection __bug_table,\"aw\"\n"   \
>   "2:\t.long 1b\n"\
> - "\t.short %O3\n"\
> - "\t.org 2b+%O4\n"   \
> + "\t.short %O4\n"\
> + "\t.org 2b+%O5\n"   \
>   "\t.popsection\n"
>  #endif
>  
> +#ifdef HAVE_BUG_FUNCTION
> +# define __BUG_FUNC  __func__
> +#else
> +# define __BUG_FUNC  NULL
> +#endif
> +
>  #define BUG()\
>  do { \
>   __asm__ __volatile__ (  \

...

[PATCH net-next] ps3/gelic: minor Kernel Doc corrections

[Simon Horman]

* Update the Kernel Doc for gelic_descr_set_tx_cmdstat()
  and gelic_net_setup_netdev() so that documented name
  and the actual name of the function match.

* Move define of GELIC_ALIGN() so that it is no longer
  between gelic_alloc_card_net() and it's Kernel Doc.

* Document netdev parameter of gelic_alloc_card_net()
  in a way consistent to the documentation of other netdev parameters
  in this file.

Addresses the following warnings flagged by ./scripts/kernel-doc -none:

  .../ps3_gelic_net.c:711: warning: expecting prototype for 
gelic_net_set_txdescr_cmdstat(). Prototype was for gelic_descr_set_tx_cmdstat() 
instead
  .../ps3_gelic_net.c:1474: warning: expecting prototype for 
gelic_ether_setup_netdev(). Prototype was for gelic_net_setup_netdev() instead
  .../ps3_gelic_net.c:1528: warning: expecting prototype for 
gelic_alloc_card_net(). Prototype was for GELIC_ALIGN() instead
  .../ps3_gelic_net.c:1531: warning: Function parameter or struct member 
'netdev' not described in 'gelic_alloc_card_net'

Signed-off-by: Simon Horman 
---
 drivers/net/ethernet/toshiba/ps3_gelic_net.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c 
b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index d5b75af163d3..12b96ca66877 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -698,7 +698,7 @@ gelic_card_get_next_tx_descr(struct gelic_card *card)
 }
 
 /**
- * gelic_net_set_txdescr_cmdstat - sets the tx descriptor command field
+ * gelic_descr_set_tx_cmdstat - sets the tx descriptor command field
  * @descr: descriptor structure to fill out
  * @skb: packet to consider
  *
@@ -1461,7 +1461,7 @@ static void gelic_ether_setup_netdev_ops(struct 
net_device *netdev,
 }
 
 /**
- * gelic_ether_setup_netdev - initialization of net_device
+ * gelic_net_setup_netdev - initialization of net_device
  * @netdev: net_device structure
  * @card: card structure
  *
@@ -1518,14 +1518,16 @@ int gelic_net_setup_netdev(struct net_device *netdev, 
struct gelic_card *card)
return 0;
 }
 
+#define GELIC_ALIGN (32)
+
 /**
  * gelic_alloc_card_net - allocates net_device and card structure
+ * @netdev: interface device structure
  *
  * returns the card structure or NULL in case of errors
  *
  * the card and net_device structures are linked to each other
  */
-#define GELIC_ALIGN (32)
 static struct gelic_card *gelic_alloc_card_net(struct net_device **netdev)
 {
struct gelic_card *card;

[PATCH RFC net] ps3/gelic: Fix possible NULL pointer dereference

[Simon Horman]

Fix possible NULL pointer dereference in gelic_card_release_tx_chain()

The cited commit introduced a netdev variable to
gelic_card_release_tx_chain() which is set unconditionally on each
iteration of a for loop.

It is set to the value of tx_chain->tail->skb->dev.  However, in some
cases it is assumed that tx_chain->tail->skb may be NULL. And if that
occurs, setting netdev will cause a NULl pointer dereference.

Given the age of this code I do wonder if this can occur in practice.
But to be on the safe side this patch assumes that it can and aims to
avoid the dereference in the case where tx_chain->tail->skb may be NULL.

Flagged by Smatch.
Compile tested only.

Fixes: 589866f9f1cb ("PS3: gelic: Add support for dual network interface")
Signed-off-by: Simon Horman 
---
 drivers/net/ethernet/toshiba/ps3_gelic_net.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c 
b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index d5b75af163d3..f03489799f5d 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -549,14 +549,13 @@ static void gelic_card_release_tx_chain(struct gelic_card 
*card, int stop)
 {
struct gelic_descr_chain *tx_chain;
enum gelic_descr_dma_status status;
-   struct net_device *netdev;
int release = 0;
 
for (tx_chain = >tx_chain;
 tx_chain->head != tx_chain->tail && tx_chain->tail;
 tx_chain->tail = tx_chain->tail->next) {
status = gelic_descr_get_status(tx_chain->tail);
-   netdev = tx_chain->tail->skb->dev;
+
switch (status) {
case GELIC_DESCR_DMA_RESPONSE_ERROR:
case GELIC_DESCR_DMA_PROTECTION_ERROR:
@@ -566,11 +565,14 @@ static void gelic_card_release_tx_chain(struct gelic_card 
*card, int stop)
 "%s: forcing end of tx descriptor " \
 "with status %x\n",
 __func__, status);
-   netdev->stats.tx_dropped++;
+   tx_chain->tail->skb->dev->stats.tx_dropped++;
break;
 
case GELIC_DESCR_DMA_COMPLETE:
if (tx_chain->tail->skb) {
+   struct net_device *netdev;
+
+   netdev = tx_chain->tail->skb->dev;
netdev->stats.tx_packets++;
netdev->stats.tx_bytes +=
tx_chain->tail->skb->len;

Re: [PATCH v4 21/28] net: wan: Add framer framework support

[Simon Horman]

On Fri, Aug 18, 2023 at 06:39:15PM +0200, Christophe Leroy wrote:
> From: Herve Codina 
> 
> A framer is a component in charge of an E1/T1 line interface.
> Connected usually to a TDM bus, it converts TDM frames to/from E1/T1
> frames. It also provides information related to the E1/T1 line.
> 
> The framer framework provides a set of APIs for the framer drivers
> (framer provider) to create/destroy a framer and APIs for the framer
> users (framer consumer) to obtain a reference to the framer, and
> use the framer.
> 
> This basic implementation provides a framer abstraction for:
>  - power on/off the framer
>  - get the framer status (line state)
>  - be notified on framer status changes
>  - get/set the framer configuration
> 
> Signed-off-by: Herve Codina 
> Reviewed-by: Christophe Leroy 
> Signed-off-by: Christophe Leroy 

Hi Christophe and Herve,

some minor feedback from my side.

...

> diff --git a/drivers/net/wan/framer/framer-core.c 
> b/drivers/net/wan/framer/framer-core.c

...

> +/**
> + * framer_create() - create a new framer
> + * @dev: device that is creating the new framer
> + * @node: device node of the framer. default to dev->of_node.
> + * @ops: function pointers for performing framer operations
> + *
> + * Called to create a framer using framer framework.
> + */
> +struct framer *framer_create(struct device *dev, struct device_node *node,
> +  const struct framer_ops *ops)
> +{
> + int ret;
> + int id;
> + struct framer *framer;

Please arrange local variable declarations for Networking code
using reverse xmas tree order - longest line to shortest.

https://github.com/ecree-solarflare/xmastree is helpful here.

...

> diff --git a/include/linux/framer/framer-provider.h 
> b/include/linux/framer/framer-provider.h

...

> +/**
> + * struct framer_ops - set of function pointers for performing framer 
> operations
> + * @init: operation to be performed for initializing the framer
> + * @exit: operation to be performed while exiting
> + * @power_on: powering on the framer
> + * @power_off: powering off the framer
> + * @flags: OR-ed flags (FRAMER_FLAG_*) to ask for core functionality
> + *  - @FRAMER_FLAG_POLL_STATUS:
> + *Ask the core to perfom a polling to get the framer status and

nit: perfom -> perform

 checkpatch.pl --codespell is your friend here

> + *notify consumers on change.
> + *The framer should call @framer_notify_status_change() when it
> + *detects a status change. This is usally done using interrutps.

nit: usally -> usually
 interrutps -> interrupts

...

> diff --git a/include/linux/framer/framer.h b/include/linux/framer/framer.h
> new file mode 100644
> index ..0bee7135142f
> --- /dev/null
> +++ b/include/linux/framer/framer.h
> @@ -0,0 +1,199 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Generic framer header file
> + *
> + * Copyright 2023 CS GROUP France
> + *
> + * Author: Herve Codina 
> + */
> +
> +#ifndef __DRIVERS_FRAMER_H
> +#define __DRIVERS_FRAMER_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * enum framer_iface - Framer interface

As this is a kernel-doc, please include documentation for
the defined constants: FRAMER_IFACE_E1 and FRAMER_IFACE_T1.

As flagged by: ./scripts/kernel-doc -none

> + */
> +enum framer_iface {
> + FRAMER_IFACE_E1,  /* E1 interface */
> + FRAMER_IFACE_T1,  /* T1 interface */
> +};
> +
> +/**
> + * enum framer_clock_mode - Framer clock mode

Likewise here too.

Also, nit: framer_clock_mode -> framer_clock_type

> + */
> +enum framer_clock_type {
> + FRAMER_CLOCK_EXT, /* External clock */
> + FRAMER_CLOCK_INT, /* Internal clock */
> +};
> +
> +/**
> + * struct framer_configuration - Framer configuration

nit: framer_configuration -> framer_config

> + * @line_iface: Framer line interface
> + * @clock_mode: Framer clock type
> + * @clock_rate: Framer clock rate
> + */
> +struct framer_config {
> + enum framer_iface iface;
> + enum framer_clock_type clock_type;
> + unsigned long line_clock_rate;
> +};
> +
> +/**
> + * struct framer_status - Framer status
> + * @link_is_on: Framer link state. true, the link is on, false, the link is 
> off.
> + */
> +struct framer_status {
> + bool link_is_on;
> +};
> +
> +/**
> + * framer_event - event available for notification

nit: framer_event -> enum framer_event

A~d please document FRAMER_EVENT_STATUS in the kernel doc too.

> + */
> +enum framer_event {
> + FRAMER_EVENT_STATUS,/* Event notified on framer_status changes */
> +};

...

Re: [PATCH -next] net/ps3_gelic_net: Use ether_addr_to_u64() to convert ethernet address

[Simon Horman]

On Tue, Aug 08, 2023 at 07:40:50PM +0800, Li Zetao wrote:
> Use ether_addr_to_u64() to convert an Ethernet address into a u64 value,
> instead of directly calculating, as this is exactly what
> this function does.
> 
> Signed-off-by: Li Zetao 
> ---
>  drivers/net/ethernet/toshiba/ps3_gelic_net.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c 
> b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> index 9d535ae59626..77a02819e412 100644
> --- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> +++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> @@ -596,7 +596,6 @@ void gelic_net_set_multi(struct net_device *netdev)
>   struct gelic_card *card = netdev_card(netdev);
>   struct netdev_hw_addr *ha;
>   unsigned int i;

Hi Li Zetao,

It looks like i is now unused in this function and should be removed.

> - uint8_t *p;
>   u64 addr;
>   int status;
>  
> @@ -629,12 +628,7 @@ void gelic_net_set_multi(struct net_device *netdev)
>  
>   /* set multicast addresses */
>   netdev_for_each_mc_addr(ha, netdev) {
> - addr = 0;
> - p = ha->addr;
> - for (i = 0; i < ETH_ALEN; i++) {
> - addr <<= 8;
> - addr |= *p++;
> - }
> + addr = ether_addr_to_u64(ha->addr);
>   status = lv1_net_add_multicast_address(bus_id(card),
>  dev_id(card),
>  addr, 0);
> -- 
> 2.34.1

-- 
pw-bot: changes-requested

Re: [PATCH net-next v2 00/10] net: fs_enet: Driver cleanup

[Simon Horman]

On Fri, Aug 04, 2023 at 03:30:10PM +0200, Christophe Leroy wrote:
> Over the years, platform and driver initialisation have evolved into
> more generic ways, and driver or platform specific stuff has gone
> away, leaving stale objects behind.
> 
> This series aims at cleaning all that up for fs_enet ethernet driver.
> 
> Changes in v2:
> - Remove a trailing whitespace in the old struct moved in patch 7.
> - Include powerpc people and list that I forgot when sending v1
> (and Rob as expected by Patchwork for patch 6, not sure why)

Thanks, this looks good to me.

For the series,

Reviewed-by: Simon Horman 

Re: [PATCH net-next v2 10/10] net: fs_enet: Use cpm_muram_xxx() functions instead of cpm_dpxxx() macros

[Simon Horman]

On Fri, Aug 04, 2023 at 03:30:20PM +0200, Christophe Leroy wrote:
> cpm_dpxxx() macros are now always referring to cpm_muram_xxx() fonctions

nit: fonctions -> functions

Thanks Christophe,

This minor nit notwithstanding, this series looks good to me.
I'll send a reviewed-by tag for the whole series in response
to the cover letter.

...

Re: [PATCH net-next v3] net: Explicitly include correct DT includes

[Simon Horman]

On Wed, Jul 26, 2023 at 07:49:39PM -0600, Rob Herring wrote:
> The DT of_device.h and of_platform.h date back to the separate
> of_platform_bus_type before it as merged into the regular platform bus.
> As part of that merge prepping Arm DT support 13 years ago, they
> "temporarily" include each other. They also include platform_device.h
> and of.h. As a result, there's a pretty much random mix of those include
> files used throughout the tree. In order to detangle these headers and
> replace the implicit includes with struct declarations, users need to
> explicitly include the correct includes.
> 
> Acked-by: Alex Elder 
> Reviewed-by: Bhupesh Sharma 
> Reviewed-by: Wei Fang 
> Signed-off-by: Rob Herring 

Reviewed-by: Simon Horman 

Re: [PATCH v2] net: Explicitly include correct DT includes

[Simon Horman]

On Mon, Jul 24, 2023 at 03:22:16PM -0600, Rob Herring wrote:

...

>  90 files changed, 88 insertions(+), 92 deletions(-)

Hi Rob,

I suppose that it's reasonable to take this patch through netdev.
But it does have a pretty wide surface, and netdev moves a lot.

As it stands the patch doesn't apply due to a conflict
in dwmac-qcom-ethqos.c

-- 
pw-bot: changes-requested

Re: [RFC PATCH 20/21] crypto: deflate - implement acomp API directly

[Simon Horman]

On Tue, Jul 18, 2023 at 02:58:46PM +0200, Ard Biesheuvel wrote:

...

> -static int deflate_comp_init(struct deflate_ctx *ctx)
> +static int deflate_process(struct acomp_req *req, struct z_stream_s *stream,
> +int (*process)(struct z_stream_s *, int))
>  {
> - int ret = 0;
> - struct z_stream_s *stream = >comp_stream;
> + unsigned int slen = req->slen;
> + unsigned int dlen = req->dlen;
> + struct scatter_walk src, dst;
> + unsigned int scur, dcur;
> + int ret;
>  
> - stream->workspace = vzalloc(zlib_deflate_workspacesize(
> - -DEFLATE_DEF_WINBITS, DEFLATE_DEF_MEMLEVEL));
> - if (!stream->workspace) {
> - ret = -ENOMEM;
> - goto out;
> - }
> + stream->avail_in = stream->avail_out = 0;
> +
> + scatterwalk_start(, req->src);
> + scatterwalk_start(, req->dst);
> +
> + scur = dcur = 0;
> +
> + do {
> + if (stream->avail_in == 0) {
> + if (scur) {
> + slen -= scur;
> +
> + scatterwalk_unmap(stream->next_in - scur);
> + scatterwalk_advance(, scur);
> + scatterwalk_done(, 0, slen);
> + }
> +
> + scur = scatterwalk_clamp(, slen);
> + if (scur) {
> + stream->next_in = scatterwalk_map();
> + stream->avail_in = scur;
> + }
> + }
> +
> + if (stream->avail_out == 0) {
> + if (dcur) {
> + dlen -= dcur;
> +
> + scatterwalk_unmap(stream->next_out - dcur);
> + scatterwalk_advance(, dcur);
> + scatterwalk_done(, 1, dlen);
> + }
> +
> + dcur = scatterwalk_clamp(, dlen);
> + if (!dcur)
> + break;

Hi Ard,

I'm unsure if this can happen. But if this break occurs in the first
iteration of this do loop, then ret will be used uninitialised below.

Smatch noticed this.

> +
> + stream->next_out = scatterwalk_map();
> + stream->avail_out = dcur;
> + }
> +
> + ret = process(stream, (slen == scur) ? Z_FINISH : Z_SYNC_FLUSH);
> + } while (ret == Z_OK);
> +
> + if (scur)
> + scatterwalk_unmap(stream->next_in - scur);
> + if (dcur)
> + scatterwalk_unmap(stream->next_out - dcur);
> +
> + if (ret != Z_STREAM_END)
> + return -EINVAL;
> +
> + req->dlen = stream->total_out;
> + return 0;
> +}

...

Re: [RFC PATCH 19/21] crypto: remove obsolete 'comp' compression API

[Simon Horman]

On Tue, Jul 18, 2023 at 02:58:45PM +0200, Ard Biesheuvel wrote:

...

> diff --git a/crypto/crypto_user_stat.c b/crypto/crypto_user_stat.c
> index d4f3d39b51376973..d3133eda2f528d17 100644
> --- a/crypto/crypto_user_stat.c
> +++ b/crypto/crypto_user_stat.c
> @@ -86,10 +86,6 @@ static int crypto_reportstat_one(struct crypto_alg *alg,
>   if (crypto_report_cipher(skb, alg))
>   goto nla_put_failure;
>   break;
> - case CRYPTO_ALG_TYPE_COMPRESS:
> - if (crypto_report_comp(skb, alg))
> - goto nla_put_failure;
> - break;

Hi Ard,

It seems that there is an implementation of crypto_report_comp() in this file
which is now unused and can be removed.

>   default:
>   pr_err("ERROR: Unhandled alg %d in %s\n",
>  alg->cra_flags & (CRYPTO_ALG_TYPE_MASK | 
> CRYPTO_ALG_LARVAL),

...

Re: [RFC PATCH 08/21] zram: Migrate to acomp compression API

[Simon Horman]

On Tue, Jul 18, 2023 at 02:58:34PM +0200, Ard Biesheuvel wrote:

...

> @@ -1618,9 +1614,7 @@ static int zram_recompress(struct zram *zram, u32 
> index, struct page *page,
>  
>   num_recomps++;
>   zstrm = zcomp_stream_get(zram->comps[prio]);
> - src = kmap_atomic(page);
> - ret = zcomp_compress(zstrm, src, _len_new);
> - kunmap_atomic(src);
> + ret = zcomp_compress(zstrm, page, _len_new);

Hi Ard,

src appears to be unused in this function with this change.

>  
>   if (ret) {
>   zcomp_stream_put(zram->comps[prio]);

...

Re: [RFC PATCH 07/21] ubifs: Migrate to acomp compression API

[Simon Horman]

On Tue, Jul 18, 2023 at 02:58:33PM +0200, Ard Biesheuvel wrote:
> UBIFS is one of the remaining users of the obsolete 'comp' compression
> API exposed by the crypto subsystem. Given that it operates strictly on
> contiguous buffers that are either entirely in lowmem or covered by a
> single page, the conversion to the acomp API is quite straight-forward.
> 
> Only synchronous acomp implementations are considered at the moment, and
> whether or not a future conversion to permit asynchronous ones too will
> be worth the effort remains to be seen.
> 
> Signed-off-by: Ard Biesheuvel 

...

> @@ -197,11 +205,24 @@ int ubifs_decompress(const struct ubifs_info *c, const 
> void *in_buf,
>  static int __init compr_init(struct ubifs_compressor *compr)
>  {
>   if (compr->capi_name) {
> - compr->cc = crypto_alloc_comp(compr->capi_name, 0, 0);
> + long ret;
> +
> + compr->cc = crypto_alloc_acomp(compr->capi_name, 0,
> +CRYPTO_ALG_ASYNC);
>   if (IS_ERR(compr->cc)) {
> + ret = PTR_ERR(compr->cc);
> + } else {
> + compr->req = acomp_request_alloc(compr->cc);
> + if (!compr->req) {
> + crypto_free_acomp(compr->cc);
> + ret = -ENOMEM;
> + }
> + }

Hi Ard,

clang-16 W=1 and Smatch flag that ret may not always be initialised here.

> +
> + if (ret) {
>   pr_err("UBIFS error (pid %d): cannot initialize 
> compressor %s, error %ld",
> -current->pid, compr->name, PTR_ERR(compr->cc));
> - return PTR_ERR(compr->cc);
> +current->pid, compr->name, ret);
> + return ret;
>   }
>   }
>  

...

> diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
> index 4c36044140e7eba9..2225de5b8ef50f71 100644
> --- a/fs/ubifs/ubifs.h
> +++ b/fs/ubifs/ubifs.h
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -849,7 +850,8 @@ struct ubifs_node_range {
>   */
>  struct ubifs_compressor {
>   int compr_type;
> - struct crypto_comp *cc;
> + struct crypto_acomp *cc;
> + struct acomp_req *req;

Please consider adding @req to the kernel doc for this structure.

>   struct mutex *comp_mutex;
>   struct mutex *decomp_mutex;
>   const char *name;

...

Re: [RFC PATCH 04/21] net: ipcomp: Migrate to acomp API from deprecated comp API

[Simon Horman]

On Tue, Jul 18, 2023 at 02:58:30PM +0200, Ard Biesheuvel wrote:
> Migrate the IPcomp network compression code to the acomp API, in order
> to drop the dependency on the obsolete 'comp' API which is going away.
> 
> For the time being, this is a rather mechanical conversion replacing
> each comp TFM object with an acomp TFM/request object pair - this is
> necessary because, at this point, there is still a 1:1 relation between
> acomp tranforms and requests in the acomp-to-scomp adaptation layer, and

nit: tranforms -> transforms

...

Re: [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)"

[Simon Horman]

On Tue, Jul 18, 2023 at 02:58:27PM +0200, Ard Biesheuvel wrote:
> This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5.
> 
> "zlib-deflate" was introduced 6 years ago, but it does not have any
> users. So let's remove the generic implementation and the test vectors,
> but retain the "zlib-deflate" entry in the testmgr code to avoid
> introducing warning messages on systems that implement zlib-deflate in
> hardware.
> 
> Note that RFC 1950 which forms the basis of this algorithm dates back to
> 1996, and predates RFC 1951, on which the existing IPcomp is based and
> which we have supported in the kernel since 2003. So it seems rather
> unlikely that we will ever grow the need to support zlib-deflate.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  crypto/deflate.c | 61 +---
>  crypto/testmgr.c |  8 +--
>  crypto/testmgr.h | 75 
>  3 files changed, 18 insertions(+), 126 deletions(-)
> 
> diff --git a/crypto/deflate.c b/crypto/deflate.c
> index b2a46f6dc961e71d..f4f127078fe2a5aa 100644
> --- a/crypto/deflate.c
> +++ b/crypto/deflate.c
> @@ -39,24 +39,20 @@ struct deflate_ctx {
>   struct z_stream_s decomp_stream;
>  };
>  
> -static int deflate_comp_init(struct deflate_ctx *ctx, int format)
> +static int deflate_comp_init(struct deflate_ctx *ctx)
>  {
>   int ret = 0;
>   struct z_stream_s *stream = >comp_stream;
>  
>   stream->workspace = vzalloc(zlib_deflate_workspacesize(
> - MAX_WBITS, MAX_MEM_LEVEL));
> + -DEFLATE_DEF_WINBITS, DEFLATE_DEF_MEMLEVEL));
>   if (!stream->workspace) {
>   ret = -ENOMEM;
>   goto out;
>   }
> - if (format)
> - ret = zlib_deflateInit(stream, 3);
> - else
> - ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
> - -DEFLATE_DEF_WINBITS,
> - DEFLATE_DEF_MEMLEVEL,
> - Z_DEFAULT_STRATEGY);
> + ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
> + -DEFLATE_DEF_WINBITS, DEFLATE_DEF_MEMLEVEL,
> + Z_DEFAULT_STRATEGY);

nit: The two lines above partially use spaces instead of tabs for
  indentation.

...

Re: [PATCH net] ibmvnic: Do not reset dql stats on NON_FATAL err

[Simon Horman]

On Fri, Jun 23, 2023 at 09:52:26AM +0200, Simon Horman wrote:
> + maintainers and blamed authors

A second time, because something went wrong with the first attempt.

> On Thu, Jun 22, 2023 at 02:03:32PM -0500, Nick Child wrote:
> > All ibmvnic resets, make a call to netdev_tx_reset_queue() when
> > re-opening the device. netdev_tx_reset_queue() resets the num_queued
> > and num_completed byte counters. These stats are used in Byte Queue
> > Limit (BQL) algorithms. The difference between these two stats tracks
> > the number of bytes currently sitting on the physical NIC. ibmvnic
> > increases the number of queued bytes though calls to
> > netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports
> > that it is done transmitting bytes, the ibmvnic device increases the
> > number of completed bytes through calls to netdev_tx_completed_queue().
> > It is important to note that the driver batches its transmit calls and
> > num_queued is increased every time that an skb is added to the next
> > batch, not necessarily when the batch is sent to VIOS for transmission.
> > 
> > Unlike other reset types, a NON FATAL reset will not flush the sub crq
> > tx buffers. Therefore, it is possible for the batched skb array to be
> > partially full. So if there is call to netdev_tx_reset_queue() when
> > re-opening the device, the value of num_queued (0) would not account
> > for the skb's that are currently batched. Eventually, when the batch
> > is sent to VIOS, the call to netdev_tx_completed_queue() would increase
> > num_completed to a value greater than the num_queued. This causes a
> > BUG_ON crash:
> > 
> > ibmvnic 3002: Firmware reports error, cause: adapter problem.
> > Starting recovery...
> > ibmvnic 3002: tx error 600
> > ibmvnic 3002: tx error 600
> > ibmvnic 3002: tx error 600
> > ibmvnic 3002: tx error 600
> > [ cut here ]
> > kernel BUG at lib/dynamic_queue_limits.c:27!
> > Oops: Exception in kernel mode, sig: 5
> > []
> > NIP dql_completed+0x28/0x1c0
> > LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]
> > Call Trace:
> > ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)
> > ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]
> > __handle_irq_event_percpu+0x98/0x270
> > ---[ end trace ]---
> > 
> > Therefore, do not reset the dql stats when performing a NON_FATAL reset.
> > Simply clearing the queues off bit is sufficient.
> > 
> > Fixes: 0d973388185d ("ibmvnic: Introduce xmit_more support using batched 
> > subCRQ hcalls")
> > Signed-off-by: Nick Child 
> > ---
> >  drivers/net/ethernet/ibm/ibmvnic.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
> > b/drivers/net/ethernet/ibm/ibmvnic.c
> > index c63d3ec9d328..5523ab52ff2b 100644
> > --- a/drivers/net/ethernet/ibm/ibmvnic.c
> > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> > @@ -1816,7 +1816,18 @@ static int __ibmvnic_open(struct net_device *netdev)
> > if (prev_state == VNIC_CLOSED)
> > enable_irq(adapter->tx_scrq[i]->irq);
> > enable_scrq_irq(adapter, adapter->tx_scrq[i]);
> > -   netdev_tx_reset_queue(netdev_get_tx_queue(netdev, i));
> > +   /* netdev_tx_reset_queue will reset dql stats and set the stacks
> > +* flag for queue status. During NON_FATAL resets, just
> > +* clear the bit, don't reset the stats because there could
> > +* be batched skb's waiting to be sent. If we reset dql stats,
> > +* we risk num_completed being greater than num_queued.
> > +* This will cause a BUG_ON in dql_completed().
> > +*/
> > +   if (adapter->reset_reason == VNIC_RESET_NON_FATAL)
> > +   clear_bit(__QUEUE_STATE_STACK_XOFF,
> > + _get_tx_queue(netdev, i)->state);
> > +   else
> > +   netdev_tx_reset_queue(netdev_get_tx_queue(netdev, i));
> > }
> >  
> > rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP);
> > -- 
> > 2.31.1
> > 
> > 

Re: [PATCH net-next v2 5/8] net: fs_enet: Convert to platform remove callback returning void

[Simon Horman]

On Tue, Jun 06, 2023 at 06:28:26PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Reviewed-by: Michal Kubiak 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Simon Horman 

Re: [PATCH net-next v2 8/8] net: ucc_geth: Convert to platform remove callback returning void

[Simon Horman]

On Tue, Jun 06, 2023 at 06:28:29PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Reviewed-by: Michal Kubiak 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Simon Horman 

Re: [PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec

[Simon Horman]

On Tue, Apr 18, 2023 at 09:44:09AM -0400, Stefan Berger wrote:
> The memory area of the TPM measurement log is currently not properly
> duplicated for carrying it across kexec when an Open Firmware
> Devicetree is used. Therefore, the contents of the log get corrupted.
> Fix this for the kexec_file_load() syscall by allocating a buffer and
> copying the contents of the existing log into it. The new buffer is
> preserved across the kexec and a pointer to it is available when the new
> kernel is started. To achieve this, store the allocated buffer's address
> in the flattened device tree (fdt) under the name linux,tpm-kexec-buffer
> and search for this entry early in the kernel startup before the TPM
> subsystem starts up. Adjust the pointer in the of-tree stored under
> linux,sml-base to point to this buffer holding the preserved log. The TPM
> driver can then read the base address from this entry when making the log
> available. Invalidate the log by removing 'linux,sml-base' from the
> devicetree if anything goes wrong with updating the buffer.
> 
> Use subsys_initcall() to call the function to restore the buffer even if
> the TPM subsystem or driver are not used. This allows the buffer to be
> carried across the next kexec without involvement of the TPM subsystem
> and ensures a valid buffer pointed to by the of-tree.

Hi Stefan,

some minor feedback from my side.

> Use the subsys_initcall(), rather than an ealier initcall, since

nit via checkpatch.pl --codespell: s/ealier/earlier/

> page_is_ram() in get_kexec_buffer() only starts working at this stage.
> 
> Signed-off-by: Stefan Berger 
> Cc: Rob Herring 
> Cc: Frank Rowand 
> Cc: Eric Biederman 
> Tested-by: Nageswara R Sastry 
> Tested-by: Coiby Xu 
> Reviewed-by: Rob Herring 

...

> +void tpm_add_kexec_buffer(struct kimage *image)
> +{
> + struct kexec_buf kbuf = { .image = image, .buf_align = 1,
> +   .buf_min = 0, .buf_max = ULONG_MAX,
> +   .top_down = true };
> + struct device_node *np;
> + void *buffer;
> + u32 size;
> + u64 base;
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_PPC64))
> + return;
> +
> + np = of_find_node_by_name(NULL, "vtpm");
> + if (!np)
> + return;
> +
> + if (of_tpm_get_sml_parameters(np, , ) < 0)
> + return;
> +
> + buffer = vmalloc(size);
> + if (!buffer)
> + return;
> + memcpy(buffer, __va(base), size);
> +
> + kbuf.buffer = buffer;
> + kbuf.bufsz = size;
> + kbuf.memsz = size;
> + ret = kexec_add_buffer();
> + if (ret) {
> + pr_err("Error passing over kexec TPM measurement log buffer: 
> %d\n",
> +ret);

Does buffer need to be freed here?

> + return;
> + }
> +
> + image->tpm_buffer = buffer;
> + image->tpm_buffer_addr = kbuf.mem;
> + image->tpm_buffer_size = size;
> +}

Re: [PATCH] net: Use of_property_read_bool() for boolean properties

[Simon Horman]

On Tue, Mar 14, 2023 at 02:14:37PM -0500, Rob Herring wrote:
> On Sat, Mar 11, 2023 at 5:50 AM Simon Horman  
> wrote:
> >
> > On Fri, Mar 10, 2023 at 08:47:16AM -0600, Rob Herring wrote:
> > > It is preferred to use typed property access functions (i.e.
> > > of_property_read_ functions) rather than low-level
> > > of_get_property/of_find_property functions for reading properties.
> > > Convert reading boolean properties to to of_property_read_bool().
> > >
> > > Signed-off-by: Rob Herring 
> >
> > Reviewed-by: Simon Horman 
> >
> > ...
> >
> > > diff --git a/drivers/net/ethernet/via/via-velocity.c 
> > > b/drivers/net/ethernet/via/via-velocity.c
> > > index a502812ac418..86f7843b4591 100644
> > > --- a/drivers/net/ethernet/via/via-velocity.c
> > > +++ b/drivers/net/ethernet/via/via-velocity.c
> > > @@ -2709,8 +2709,7 @@ static int velocity_get_platform_info(struct 
> > > velocity_info *vptr)
> > >   struct resource res;
> > >   int ret;
> > >
> > > - if (of_get_property(vptr->dev->of_node, "no-eeprom", NULL))
> > > - vptr->no_eeprom = 1;
> > > + vptr->no_eeprom = of_property_read_bool(vptr->dev->of_node, 
> > > "no-eeprom");
> >
> > As per my comment on "[PATCH] nfc: mrvl: Use of_property_read_bool() for
> > boolean properties".
> >
> > I'm not that enthusiastic about assigning a bool value to a field
> > with an integer type. But that is likely a topic for another patch.
> >
> > >   ret = of_address_to_resource(vptr->dev->of_node, 0, );
> > >   if (ret) {
> >
> > ...
> >
> > > diff --git a/drivers/net/wan/fsl_ucc_hdlc.c 
> > > b/drivers/net/wan/fsl_ucc_hdlc.c
> > > index 1c53b5546927..47c2ad7a3e42 100644
> > > --- a/drivers/net/wan/fsl_ucc_hdlc.c
> > > +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> > > @@ -1177,14 +1177,9 @@ static int ucc_hdlc_probe(struct platform_device 
> > > *pdev)
> > >   uhdlc_priv->dev = >dev;
> > >   uhdlc_priv->ut_info = ut_info;
> > >
> > > - if (of_get_property(np, "fsl,tdm-interface", NULL))
> > > - uhdlc_priv->tsa = 1;
> > > -
> > > - if (of_get_property(np, "fsl,ucc-internal-loopback", NULL))
> > > - uhdlc_priv->loopback = 1;
> > > -
> > > - if (of_get_property(np, "fsl,hdlc-bus", NULL))
> > > - uhdlc_priv->hdlc_bus = 1;
> > > + uhdlc_priv->tsa = of_property_read_bool(np, "fsl,tdm-interface");
> >
> > Here too.
> 
> These are already bool.

Sorry, I thought I checked. But clearly I messed it up somehow.

> Turns out the only one that needs changing is
> no_eeprom. netdev folks marked this as changes requested, so I'll add
> that in v2.

Thanks.

Re: [PATCH] net: Use of_property_read_bool() for boolean properties

[Simon Horman]

On Fri, Mar 10, 2023 at 08:47:16AM -0600, Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties.
> Convert reading boolean properties to to of_property_read_bool().
> 
> Signed-off-by: Rob Herring 

Reviewed-by: Simon Horman 

...

> diff --git a/drivers/net/ethernet/via/via-velocity.c 
> b/drivers/net/ethernet/via/via-velocity.c
> index a502812ac418..86f7843b4591 100644
> --- a/drivers/net/ethernet/via/via-velocity.c
> +++ b/drivers/net/ethernet/via/via-velocity.c
> @@ -2709,8 +2709,7 @@ static int velocity_get_platform_info(struct 
> velocity_info *vptr)
>   struct resource res;
>   int ret;
>  
> - if (of_get_property(vptr->dev->of_node, "no-eeprom", NULL))
> - vptr->no_eeprom = 1;
> + vptr->no_eeprom = of_property_read_bool(vptr->dev->of_node, 
> "no-eeprom");

As per my comment on "[PATCH] nfc: mrvl: Use of_property_read_bool() for
boolean properties".

I'm not that enthusiastic about assigning a bool value to a field
with an integer type. But that is likely a topic for another patch.

>   ret = of_address_to_resource(vptr->dev->of_node, 0, );
>   if (ret) {

...

> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 1c53b5546927..47c2ad7a3e42 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -1177,14 +1177,9 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
>   uhdlc_priv->dev = >dev;
>   uhdlc_priv->ut_info = ut_info;
>  
> - if (of_get_property(np, "fsl,tdm-interface", NULL))
> - uhdlc_priv->tsa = 1;
> -
> - if (of_get_property(np, "fsl,ucc-internal-loopback", NULL))
> - uhdlc_priv->loopback = 1;
> -
> - if (of_get_property(np, "fsl,hdlc-bus", NULL))
> - uhdlc_priv->hdlc_bus = 1;
> + uhdlc_priv->tsa = of_property_read_bool(np, "fsl,tdm-interface");

Here too.

> + uhdlc_priv->loopback = of_property_read_bool(np, 
> "fsl,ucc-internal-loopback");
> + uhdlc_priv->hdlc_bus = of_property_read_bool(np, "fsl,hdlc-bus");
>  
>   if (uhdlc_priv->tsa == 1) {
>   utdm = kzalloc(sizeof(*utdm), GFP_KERNEL);

...

Re: [PATCH v5 07/11] PCI: Replace pci_dev::driver usage that gets the driver name

[Simon Horman]

On Wed, Sep 29, 2021 at 10:53:02AM +0200, Uwe Kleine-König wrote:
> struct pci_dev::driver holds (apart from a constant offset) the same
> data as struct pci_dev::dev->driver. With the goal to remove struct
> pci_dev::driver to get rid of data duplication replace getting the
> driver name by dev_driver_string() which implicitly makes use of struct
> pci_dev::dev->driver.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/crypto/hisilicon/qm.c| 2 +-
>  drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c   | 2 +-
>  drivers/net/ethernet/marvell/prestera/prestera_pci.c | 2 +-
>  drivers/net/ethernet/mellanox/mlxsw/pci.c| 2 +-
>  drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 3 ++-
>  5 files changed, 6 insertions(+), 5 deletions(-)

Thanks Uwe.

For NFP:

Acked-by: Simon Horman 

Re: [PATCH v4 4/8] PCI: replace pci_dev::driver usage that gets the driver name

[Simon Horman]

On Tue, Sep 28, 2021 at 12:31:29PM +0200, Uwe Kleine-König wrote:
> On Tue, Sep 28, 2021 at 12:01:28PM +0200, Simon Horman wrote:
> > On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
> > > From: Uwe Kleine-König 
> > > 
> > > struct pci_dev::driver holds (apart from a constant offset) the same
> > > data as struct pci_dev::dev->driver. With the goal to remove struct
> > > pci_dev::driver to get rid of data duplication replace getting the
> > > driver name by dev_driver_string() which implicitly makes use of struct
> > > pci_dev::dev->driver.
> > > 
> > > Signed-off-by: Uwe Kleine-König 
> > 
> > ...
> > 
> > > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c 
> > > b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> > > index 0685ece1f155..23dfb599c828 100644
> > > --- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> > > +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> > > @@ -202,7 +202,7 @@ nfp_get_drvinfo(struct nfp_app *app, struct pci_dev 
> > > *pdev,
> > >  {
> > >   char nsp_version[ETHTOOL_FWVERS_LEN] = {};
> > >  
> > > - strlcpy(drvinfo->driver, pdev->driver->name, sizeof(drvinfo->driver));
> > > + strlcpy(drvinfo->driver, dev_driver_string(>dev), 
> > > sizeof(drvinfo->driver));
> > 
> > I'd slightly prefer to maintain lines under 80 columns wide.
> > But not nearly strongly enough to engage in a long debate about it.
> 
> :-)
> 
> Looking at the output of
> 
>   git grep strlcpy.\*sizeof
> 
> I wonder if it would be sensible to introduce something like
> 
>   #define strlcpy_array(arr, src) (strlcpy(arr, src, sizeof(arr)) + 
> __must_be_array(arr))
> 
> but not sure this is possible without a long debate either (and this
> line is over 80 chars wide, too :-).

My main motivation for the 80 char limit in nfp_net_ethtool.c is
not that I think 80 char is universally a good limit (although that is true),
but rather that I expect that is the prevailing style in nfp_net_ethtool.c.

So a macro more than 80 car wide somewhere else is fine by me.

However, when running checkpatch --strict over the patch it told me:

WARNING: Prefer strscpy over strlcpy - see: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
#276: FILE: drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c:205:
+   strlcpy(drvinfo->driver, dev_driver_string(>dev), 
sizeof(drvinfo->driver));

total: 0 errors, 1 warnings, 0 checks, 80 lines checked

(Amusingly, more text wider than 80 column, perhaps suggesting the folly of
 my original comment, but lets move on from that.)

As your patch doesn't introduce the usage of strlcpy() I was considering a
follow-up patch to change it to strscpy(). And in general the email at the
link above suggests all usages of strlcpy() should do so. So perhaps
creating strscpy_array is a better idea?

I have not thought about this much, and probably this just leads us to a
deeper part of the rabbit hole.

Re: [PATCH v4 4/8] PCI: replace pci_dev::driver usage that gets the driver name

[Simon Horman]

On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> struct pci_dev::driver holds (apart from a constant offset) the same
> data as struct pci_dev::dev->driver. With the goal to remove struct
> pci_dev::driver to get rid of data duplication replace getting the
> driver name by dev_driver_string() which implicitly makes use of struct
> pci_dev::dev->driver.
> 
> Signed-off-by: Uwe Kleine-König 

...

> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c 
> b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> index 0685ece1f155..23dfb599c828 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
> @@ -202,7 +202,7 @@ nfp_get_drvinfo(struct nfp_app *app, struct pci_dev *pdev,
>  {
>   char nsp_version[ETHTOOL_FWVERS_LEN] = {};
>  
> - strlcpy(drvinfo->driver, pdev->driver->name, sizeof(drvinfo->driver));
> + strlcpy(drvinfo->driver, dev_driver_string(>dev), 
> sizeof(drvinfo->driver));

I'd slightly prefer to maintain lines under 80 columns wide.
But not nearly strongly enough to engage in a long debate about it.

In any case, for the NFP portion of this patch.

Acked-by: Simon Horman 

>   nfp_net_get_nspinfo(app, nsp_version);
>   snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
>"%s %s %s %s", vnic_version, nsp_version,

...

Re: [oss-drivers] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

[Simon Horman]

On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
> 
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
> 
> Found using:
> 
> $ grep-2.5.4 -rP --include=*.[ch] -n 
> "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> 
> Miscellanea:
> 
> o Move or coalesce a couple label blocks above a default: block.
> 
> Signed-off-by: Joe Perches 

...

> diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c 
> b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> index 252fe06f58aa..1d5b87079104 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> @@ -345,7 +345,7 @@ static int matching_bar(struct nfp_bar *bar, u32 tgt, u32 
> act, u32 tok,
>   baract = NFP_CPP_ACTION_RW;
>   if (act == 0)
>   act = NFP_CPP_ACTION_RW;
> - fallthrough;
> + break;
>   case NFP_PCIE_BAR_PCIE2CPP_MapType_FIXED:
>   break;
>   default:

This is a cascading fall-through handling all map types.
I don't think this change improves readability.

...

Re: [oss-drivers] [PATCH 16/20] ethernet: netronome: convert tasklets to use new tasklet_setup() API

[Simon Horman]

On Mon, Aug 17, 2020 at 01:54:30PM +0530, Allen Pais wrote:
> In preparation for unconditionally passing the
> struct tasklet_struct pointer to all tasklet
> callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
> 
> Signed-off-by: Romain Perier 
> Signed-off-by: Allen Pais 

Reviewed-by: Simon Horman 

But:

This series should be targeted at net-next, and thus have net-next in its
subject

[PATCH net-next x/y] ...

And it should be posted when net-next is open: it is currently closed.

http://vger.kernel.org/~davem/net-next.html

> ---
>  drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c 
> b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> index 39ee23e8c0bf..1dcd24d899f5 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> @@ -2287,9 +2287,9 @@ static bool nfp_ctrl_rx(struct nfp_net_r_vector *r_vec)
>   return budget;
>  }
>  
> -static void nfp_ctrl_poll(unsigned long arg)
> +static void nfp_ctrl_poll(struct tasklet_struct *t)
>  {
> - struct nfp_net_r_vector *r_vec = (void *)arg;
> + struct nfp_net_r_vector *r_vec = from_tasklet(r_vec, t, tasklet);
>  
>   spin_lock(_vec->lock);
>   nfp_net_tx_complete(r_vec->tx_ring, 0);
> @@ -2337,8 +2337,7 @@ static void nfp_net_vecs_init(struct nfp_net *nn)
>  
>   __skb_queue_head_init(_vec->queue);
>   spin_lock_init(_vec->lock);
> - tasklet_init(_vec->tasklet, nfp_ctrl_poll,
> -  (unsigned long)r_vec);
> + tasklet_setup(_vec->tasklet, nfp_ctrl_poll);
>   tasklet_disable(_vec->tasklet);
>   }
>  
> -- 
> 2.17.1
> 

Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

[Simon Horman]

On Thu, Dec 06, 2018 at 01:38:42PM -0600, Rob Herring wrote:
> On Wed, Dec 5, 2018 at 1:44 PM Simon Horman  wrote:
> >
> > On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote:
> > > On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven  
> > > wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman  wrote:
> > > > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> > > > > > Convert Renesas SoC bindings to DT schema format using json-schema.
> > > > > >
> > > > > > Cc: Simon Horman 
> > > > > > Cc: Magnus Damm 
> > > > > > Cc: Mark Rutland 
> > > > > > Cc: linux-renesas-...@vger.kernel.org
> > > > > > Cc: devicet...@vger.kernel.org
> > > > > > Signed-off-by: Rob Herring 
> > > > > > ---
> > > > > >  .../devicetree/bindings/arm/shmobile.txt  | 151 
> > > > > >  .../devicetree/bindings/arm/shmobile.yaml | 218 
> > > > > > ++
> > > > > >  2 files changed, 218 insertions(+), 151 deletions(-)
> > > > > >  delete mode 100644 
> > > > > > Documentation/devicetree/bindings/arm/shmobile.txt
> > > > > >  create mode 100644 
> > > > > > Documentation/devicetree/bindings/arm/shmobile.yaml
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > what is this based on? I get a conflict when applying the .txt change
> > > > > and if I knew the base for this patch it would be rather easy to work
> > > > > out what has changed.
> > >
> > > 4.20-rc2
> > >
> > > > >
> > > > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?
> > >
> > > Yes. Though it was pointed out that get_maintainers.pl can pull emails
> > > out of this file. We'd need to get that to work by default though.
> > >
> > > > Probably even s/shmobile.yaml/renesas.yaml/, while at it?
> > >
> > > Sure, if that's what you all want.
> >
> > How about this?
> 
> LGTM

Thanks.

As my tree is already closed for v4.21 I have applied this for v4.22.

Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

[Simon Horman]

On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote:
> On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven  
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman  wrote:
> > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> > > > Convert Renesas SoC bindings to DT schema format using json-schema.
> > > >
> > > > Cc: Simon Horman 
> > > > Cc: Magnus Damm 
> > > > Cc: Mark Rutland 
> > > > Cc: linux-renesas-...@vger.kernel.org
> > > > Cc: devicet...@vger.kernel.org
> > > > Signed-off-by: Rob Herring 
> > > > ---
> > > >  .../devicetree/bindings/arm/shmobile.txt  | 151 
> > > >  .../devicetree/bindings/arm/shmobile.yaml | 218 ++
> > > >  2 files changed, 218 insertions(+), 151 deletions(-)
> > > >  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
> > > >  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml
> > >
> > > Hi Rob,
> > >
> > > what is this based on? I get a conflict when applying the .txt change
> > > and if I knew the base for this patch it would be rather easy to work
> > > out what has changed.
> 
> 4.20-rc2
> 
> > >
> > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?
> 
> Yes. Though it was pointed out that get_maintainers.pl can pull emails
> out of this file. We'd need to get that to work by default though.
> 
> > Probably even s/shmobile.yaml/renesas.yaml/, while at it?
> 
> Sure, if that's what you all want.

How about this?

From: Rob Herring 
Subject: [PATCH v2.1] dt-bindings: arm: Convert Renesas board/soc bindings to
 json-schema

Convert Renesas SoC bindings to DT schema format using json-schema.

v2.1 [Simon Horman]
- rebased on renesas-devel-20181204-v4.20-rc5
  + Added r8a7744 development platform and SoM
  + Correct RZ/G2E part number
- Update MAINTAINERS

Signed-off-by: Rob Herring 
Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/arm/renesas.yaml | 228 +
 Documentation/devicetree/bindings/arm/shmobile.txt | 155 --
 MAINTAINERS|   4 +-
 3 files changed, 230 insertions(+), 157 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/renesas.yaml
 delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt

diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml 
b/Documentation/devicetree/bindings/arm/renesas.yaml
new file mode 100644
index ..5e9d4864a600
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/renesas.yaml
@@ -0,0 +1,228 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/shmobile.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
+
+maintainers:
+  - Geert Uytterhoeven 
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+oneOf:
+  - description: Emma Mobile EV2
+items:
+  - enum:
+  - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual
+  - const: renesas,emev2
+
+  - description: RZ/A1H (R7S72100)
+items:
+  - enum:
+  - renesas,genmai # Genmai (RTK772100BC0BR)
+  - renesas,gr-peach # GR-Peach (X28A-M01-E/F)
+  - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE)
+  - const: renesas,r7s72100
+
+  - description: RZ/A2 (R7S9210)
+items:
+  - const: renesas,r7s9210
+
+  - description: SH-Mobile AG5 (R8A73A00/SH73A0)
+items:
+  - enum:
+  - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT
+  - const: renesas,sh73a0
+
+  - description: R-Mobile APE6 (R8A73A40)
+items:
+  - enum:
+  - renesas,ape6evm
+  - const: renesas,r8a73a4
+
+  - description: R-Mobile A1 (R8A77400)
+items:
+  - enum:
+  - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA
+  - const: renesas,r8a7740
+
+  - description: RZ/G1H (R8A77420)
+items:
+  - const: renesas,r8a7742
+
+  - description: RZ/G1M (R8A77430)
+items:
+  - enum:
+  # iWave Systems RZ/G1M Qseven Development Platform 
(iW-RainboW-G20D-Qseven)
+  - iwave,g20d
+  - const: iwave,g20m
+  - const: renesas,r8a7743
+
+  - items:
+  - enum:
+  # iWave Systems RZ/G1M Qseven System On Module 
(iW-RainboW-G20M-Qseven)
+  - iwave,g20m
+  - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE)
+  - const: renesas,r8a7743
+
+  - description: RZ

Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

[Simon Horman]

On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> Convert Renesas SoC bindings to DT schema format using json-schema.
> 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: Mark Rutland 
> Cc: linux-renesas-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/shmobile.txt  | 151 
>  .../devicetree/bindings/arm/shmobile.yaml | 218 ++
>  2 files changed, 218 insertions(+), 151 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml

Hi Rob,

what is this based on? I get a conflict when applying the .txt change
and if I knew the base for this patch it would be rather easy to work
out what has changed.

Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?

Re: [PATCH v2 25/34] dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc

[Simon Horman]

On Mon, Dec 03, 2018 at 03:32:14PM -0600, Rob Herring wrote:
> In preparation to convert board-level bindings to json-schema, move
> various misc SoC bindings out to their own file.
> 
> Cc: Mark Rutland 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: devicet...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/renesas,prr.txt   | 20 +++
>  .../devicetree/bindings/arm/shmobile.txt  | 18 -
>  2 files changed, 20 insertions(+), 18 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt

Applied for v4.21, but should we add renesas,prr.txt to MAINTAINERS
as a follow-up?

Re: [PATCH 05/36] dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc

[Simon Horman]

On Mon, Oct 08, 2018 at 09:59:19AM -0500, Rob Herring wrote:
> On Mon, Oct 8, 2018 at 2:05 AM Geert Uytterhoeven  
> wrote:
> >
> > Hi Rob,
> >
> > On Fri, Oct 5, 2018 at 6:58 PM Rob Herring  wrote:
> > > In preparation to convert board-level bindings to json-schema, move
> > > various misc SoC bindings out to their own file.
> > >
> > > Cc: Mark Rutland 
> > > Cc: Simon Horman 
> > > Cc: Magnus Damm 
> > > Cc: devicet...@vger.kernel.org
> > > Cc: linux-renesas-...@vger.kernel.org
> > > Signed-off-by: Rob Herring 
> >
> > Looks good to me, but needs a rebase, as the PRR section has been extended
> > in -next.
> 
> Is this something you all can apply still for 4.20?

Sorry, missing this until now. It was too late.

Shall I take it for v4.21?

Re: [PATCH 29/36] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

[Simon Horman]

On Mon, Oct 08, 2018 at 09:05:58AM -0500, Rob Herring wrote:
> On Mon, Oct 8, 2018 at 3:02 AM Simon Horman  wrote:
> >
> > On Fri, Oct 05, 2018 at 11:58:41AM -0500, Rob Herring wrote:
> > > Convert Renesas SoC bindings to DT schema format using json-schema.
> > >
> > > Cc: Simon Horman 
> > > Cc: Magnus Damm 
> > > Cc: Mark Rutland 
> > > Cc: linux-renesas-...@vger.kernel.org
> > > Cc: devicet...@vger.kernel.org
> > > Signed-off-by: Rob Herring 
> >
> > This seems fine to me other than that it does not seem
> > to apply cleanly to next.
> >
> > shmobile.txt sees a couple of updates per release cycle so from my point of
> > view it would ideal if this change could hit -rc1 to allow patches for
> > v4.21 to be accepted smoothly (already one from Sergei will need rebasing).
> 
> When we get to the point of merging (which isn't going to be 4.20),
> you and other maintainers can probably take all these patches. Other
> than the few restructuring patches, the only dependency is the build
> support which isn't a dependency to apply it, but build it. I plan to
> build any patches as part of reviewing at least early on. OTOH, the
> build support is small enough and self contained that maybe it can
> just be applied for 4.20.

Thanks, understood.

My preference would be to, as you suggest, take changes like
this through the renesas tree.

Re: [PATCH 29/36] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

[Simon Horman]

On Fri, Oct 05, 2018 at 11:58:41AM -0500, Rob Herring wrote:
> Convert Renesas SoC bindings to DT schema format using json-schema.
> 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: Mark Rutland 
> Cc: linux-renesas-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 

This seems fine to me other than that it does not seem
to apply cleanly to next.

shmobile.txt sees a couple of updates per release cycle so from my point of
view it would ideal if this change could hit -rc1 to allow patches for
v4.21 to be accepted smoothly (already one from Sergei will need rebasing).

> ---
>  .../devicetree/bindings/arm/shmobile.txt  | 143 
>  .../devicetree/bindings/arm/shmobile.yaml | 205 ++
>  2 files changed, 205 insertions(+), 143 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
> b/Documentation/devicetree/bindings/arm/shmobile.txt
> deleted file mode 100644
> index 619b765e5bee..
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ /dev/null
> @@ -1,143 +0,0 @@
> -Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
> -
> -
> -SoCs:
> -
> -  - Emma Mobile EV2
> -compatible = "renesas,emev2"
> -  - RZ/A1H (R7S72100)
> -compatible = "renesas,r7s72100"
> -  - SH-Mobile AG5 (R8A73A00/SH73A0)
> -compatible = "renesas,sh73a0"
> -  - R-Mobile APE6 (R8A73A40)
> -compatible = "renesas,r8a73a4"
> -  - R-Mobile A1 (R8A77400)
> -compatible = "renesas,r8a7740"
> -  - RZ/G1H (R8A77420)
> -compatible = "renesas,r8a7742"
> -  - RZ/G1M (R8A77430)
> -compatible = "renesas,r8a7743"
> -  - RZ/G1N (R8A77440)
> -compatible = "renesas,r8a7744"
> -  - RZ/G1E (R8A77450)
> -compatible = "renesas,r8a7745"
> -  - RZ/G1C (R8A77470)
> -compatible = "renesas,r8a77470"
> -  - R-Car M1A (R8A77781)
> -compatible = "renesas,r8a7778"
> -  - R-Car H1 (R8A77790)
> -compatible = "renesas,r8a7779"
> -  - R-Car H2 (R8A77900)
> -compatible = "renesas,r8a7790"
> -  - R-Car M2-W (R8A77910)
> -compatible = "renesas,r8a7791"
> -  - R-Car V2H (R8A77920)
> -compatible = "renesas,r8a7792"
> -  - R-Car M2-N (R8A77930)
> -compatible = "renesas,r8a7793"
> -  - R-Car E2 (R8A77940)
> -compatible = "renesas,r8a7794"
> -  - R-Car H3 (R8A77950)
> -compatible = "renesas,r8a7795"
> -  - R-Car M3-W (R8A77960)
> -compatible = "renesas,r8a7796"
> -  - R-Car M3-N (R8A77965)
> -compatible = "renesas,r8a77965"
> -  - R-Car V3M (R8A77970)
> -compatible = "renesas,r8a77970"
> -  - R-Car V3H (R8A77980)
> -compatible = "renesas,r8a77980"
> -  - R-Car E3 (R8A77990)
> -compatible = "renesas,r8a77990"
> -  - R-Car D3 (R8A77995)
> -compatible = "renesas,r8a77995"
> -  - RZ/N1D (R9A06G032)
> -compatible = "renesas,r9a06g032"
> -
> -Boards:
> -
> -  - Alt (RTP0RC7794SEB00010S)
> -compatible = "renesas,alt", "renesas,r8a7794"
> -  - APE6-EVM
> -compatible = "renesas,ape6evm", "renesas,r8a73a4"
> -  - Atmark Techno Armadillo-800 EVA
> -compatible = "renesas,armadillo800eva", "renesas,r8a7740"
> -  - Blanche (RTP0RC7792SEB00010S)
> -compatible = "renesas,blanche", "renesas,r8a7792"
> -  - BOCK-W
> -compatible = "renesas,bockw", "renesas,r8a7778"
> -  - Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01)
> -compatible = "renesas,condor", "renesas,r8a77980"
> -  - Draak (RTP0RC77995SEB0010S)
> -compatible = "renesas,draak", "renesas,r8a77995"
> -  - Eagle (RTP0RC77970SEB0010S)
> -compatible = "renesas,eagle", "renesas,r8a77970"
> -  - Ebisu (RTP0RC77990SEB0010S)
> -compatible = "renesas,ebisu", "renesas,r8a77990"
> -  - Genmai (RTK772100BC0BR)
> -compatible = "renesas,genmai", "renesas,r7s72100"
> -  - GR-Peach (X28A-M01-E/F)
> -compatible = "renesas,gr-peach", "renesas,r7s72100"
> -  - Gose (RTP0RC7793SEB00010S)
> -compatible = "renesas,gose", "renesas,r8a7793"
> -  - H3ULCB (R-Car Starter Kit Premier, RTP

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

[Simon Horman]

On Tue, Jul 24, 2018 at 01:13:25PM +0200, Arnd Bergmann wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
> 
> This converts them all to UTF-8 for consistency.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  .../devicetree/bindings/net/nfc/pn544.txt |   2 +-
>  arch/arm/boot/dts/sun4i-a10-inet97fv2.dts |   2 +-
>  arch/arm/crypto/sha256_glue.c |   2 +-
>  arch/arm/crypto/sha256_neon_glue.c|   4 +-
>  drivers/crypto/vmx/ghashp8-ppc.pl |  12 +-
>  drivers/iio/dac/ltc2632.c |   2 +-
>  drivers/power/reset/ltc2952-poweroff.c|   4 +-
>  kernel/events/callchain.c |   2 +-
>  net/netfilter/ipvs/Kconfig|   8 +-
>  net/netfilter/ipvs/ip_vs_mh.c         |   4 +-

IPVS portion:

Acked-by: Simon Horman 


>  tools/power/cpupower/po/de.po |  44 +++
>  tools/power/cpupower/po/fr.po | 120 +-
>  12 files changed, 103 insertions(+), 103 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt 
> b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> index 538a86f7b2b0..72593f056b75 100644
> --- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> @@ -2,7 +2,7 @@
>  
>  Required properties:
>  - compatible: Should be "nxp,pn544-i2c".
> -- clock-frequency: I�C work frequency.
> +- clock-frequency: I²C work frequency.
>  - reg: address on the bus
>  - interrupt-parent: phandle for the interrupt gpio controller
>  - interrupts: GPIO interrupt to which the chip is connected
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts 
> b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> index 5d096528e75a..71c27ea0b53e 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -1,7 +1,7 @@
>  /*
>   * Copyright 2014 Open Source Support GmbH
>   *
> - * David Lanzend�rfer 
> + * David Lanzendörfer 
>   *
>   * This file is dual-licensed: you can use it either under the terms
>   * of the GPL or the X11 license, at your option. Note that this dual
> diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
> index bf8ccff2c9d0..0ae900e778f3 100644
> --- a/arch/arm/crypto/sha256_glue.c
> +++ b/arch/arm/crypto/sha256_glue.c
> @@ -2,7 +2,7 @@
>   * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
>   * using optimized ARM assembler and NEON instructions.
>   *
> - * Copyright � 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
>   *
>   * This file is based on sha256_ssse3_glue.c:
>   *   Copyright (C) 2013 Intel Corporation
> diff --git a/arch/arm/crypto/sha256_neon_glue.c 
> b/arch/arm/crypto/sha256_neon_glue.c
> index 9bbee56fbdc8..1d82c6cd31a4 100644
> --- a/arch/arm/crypto/sha256_neon_glue.c
> +++ b/arch/arm/crypto/sha256_neon_glue.c
> @@ -2,10 +2,10 @@
>   * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
>   * using NEON instructions.
>   *
> - * Copyright � 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
>   *
>   * This file is based on sha512_neon_glue.c:
> - *   Copyright � 2014 Jussi Kivilinna 
> + *   Copyright © 2014 Jussi Kivilinna 
>   *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License as published by the Free
> diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl 
> b/drivers/crypto/vmx/ghashp8-ppc.pl
> index f746af271460..38b06503ede0 100644
> --- a/drivers/crypto/vmx/ghashp8-ppc.pl
> +++ b/drivers/crypto/vmx/ghashp8-ppc.pl
> @@ -129,9 +129,9 @@ $code=<<___;
>le?vperm   $IN,$IN,$IN,$lemask
>   vxor$zero,$zero,$zero
>  
> - vpmsumd $Xl,$IN,$Hl # H.lo�Xi.lo
> - vpmsumd $Xm,$IN,$H  # H.hi�Xi.lo+H.lo�Xi.hi
> - vpmsumd $Xh,$IN,$Hh # H.hi�Xi.hi
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>  
>   vpmsumd $t2,$Xl,$xC2# 1st phase
>  
> @@ -187,11 +187,11 @@ $code=<<___;
>  .align   5
>  Loop:
>subic  $len,$len,16
> - vpmsumd $Xl,$IN,$Hl # H.lo�Xi.lo
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
>subfe. r0,r0,r0# borrow?-1:0
> - vpmsumd $X

Re: [PATCH] powerpc: kexec_file: Fix error code when trying to load kdump kernel

[Simon Horman]

On Thu, Mar 29, 2018 at 04:05:43PM -0300, Thiago Jung Bauermann wrote:
> kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
> returns -ENOTSUPP in that case.
> 
> I've recently learned that this errno is internal to the kernel and isn't
> supposed to be exposed to userspace. Therefore, change to -EOPNOTSUPP which
> is defined in an uapi header.
> 
> This does indeed make kexec-tools happier. Before the patch, on ppc64le:
> 
>   # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
>   kexec_file_load failed: Unknown error 524
> 
> After the patch:
> 
>   # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
>   kexec_file_load failed: Operation not supported
> 
> Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()")
> Reported-by: Dave Young <dyo...@redhat.com>
> Signed-off-by: Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com>

Reviewed-by: Simon Horman <ho...@verge.net.au>

Re: [PATCH] soc: Convert to using %pOF instead of full_name

[Simon Horman]

On Tue, Jul 18, 2017 at 04:43:29PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring <r...@kernel.org>
> Cc: Scott Wood <o...@buserror.net>
> Cc: Qiang Zhao <qiang.z...@nxp.com>
> Cc: Matthias Brugger <matthias@gmail.com>
> Cc: Simon Horman <ho...@verge.net.au>
> Cc: Magnus Damm <magnus.d...@gmail.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Krzysztof Kozlowski <k...@kernel.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> ---
>  drivers/soc/fsl/qbman/bman_ccsr.c| 10 +-
>  drivers/soc/fsl/qbman/bman_portal.c  |  8 +++-
>  drivers/soc/fsl/qbman/qman_ccsr.c| 12 ++--
>  drivers/soc/fsl/qbman/qman_portal.c  | 11 ---
>  drivers/soc/fsl/qe/gpio.c|  4 ++--
>  drivers/soc/mediatek/mtk-pmic-wrap.c |  4 ++--
>  drivers/soc/renesas/rcar-rst.c   |  4 ++--
>  drivers/soc/renesas/rcar-sysc.c  |  6 +++---
>  drivers/soc/samsung/pm_domains.c |  8 
>  9 files changed, 31 insertions(+), 36 deletions(-)

Renesas portions:

Acked-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH 1 4/4] PCI: rcar: Use of_device_get_match_data() to simplify probe

[Simon Horman]

On Tue, Jan 31, 2017 at 02:20:20PM -0600, Bjorn Helgaas wrote:
> This is a DT-only driver, so the only way to call rcar_pcie_probe() is to
> match an entry in rcar_pcie_of_match[], so of_id cannot be NULL.
> 
> Furthermore, of_id->data can only be NULL if an rcar_pcie_of_match[] entry
> has a NULL .data member.  That's a driver defect, and we don't want to
> return -EINVAL, which is easy to ignore.  We'd rather take the NULL pointer
> dereference so we notice the problem and fix it.
> 
> Use of_device_get_match_data() to retrieve the hw_init_fn pointer.  No
> functional change intended.
> 
> Suggested-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>

Acked-by: Simon Horman <horms+rene...@verge.net.au>

> ---
>  drivers/pci/host/pcie-rcar.c |7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index aca85be101f8..b3b6d5273347 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1125,7 +1125,6 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct rcar_pcie *pcie;
>   unsigned int data;
> - const struct of_device_id *of_id;
>   int err;
>   int (*hw_init_fn)(struct rcar_pcie *);
>  
> @@ -1149,11 +1148,6 @@ static int rcar_pcie_probe(struct platform_device 
> *pdev)
>   if (err)
>   return err;
>  
> - of_id = of_match_device(rcar_pcie_of_match, dev);
> - if (!of_id || !of_id->data)
> - return -EINVAL;
> - hw_init_fn = of_id->data;
> -
>   pm_runtime_enable(dev);
>   err = pm_runtime_get_sync(dev);
>   if (err < 0) {
> @@ -1162,6 +1156,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>   }
>  
>   /* Failure to get a link might just be that no cards are inserted */
> + hw_init_fn = of_device_get_match_data(dev);
>   err = hw_init_fn(pcie);
>   if (err) {
>   dev_info(dev, "PCIe link down\n");
> 

Re: [PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

[Simon Horman]

On Tue, Dec 08, 2015 at 02:46:17PM +1100, Michael Ellerman wrote:
> On Mon, 2015-12-07 at 14:42 -0600, Scott Wood wrote:
> > On Tue, 2015-10-06 at 17:55 -0500, Scott Wood wrote:
> > > It needs to know this because the SMP release mechanism for Freescale
> > > book3e is different from when booting with normal hardware.  In theory
> > > we could simulate the normal spin table mechanism, but not (easily) at
> > > the addresses U-Boot put in the device tree -- so there'd need to be
> > > even more communication between the kernel and kexec to set that up.
> > > 
> > > Signed-off-by: Scott Wood 
> > > ---
> > > v2: Use a device tree property rather than setting a flag in the kernel
> > > image, as requested by Michael Ellerman.
> > 
> > ping?
> > 
> > Michael, can you review this?  Simon is waiting for another PPC person to
> > review it.
> 
> Oh sorry I thought it'd been merged already, but I see now only 1 & 2 went in.
> 
> Horms this looks fine to me:
> 
> Acked-by: Michael Ellerman 

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

Re: [PATCH v2 2/3] ppc64: Avoid rfid if no need to clear MSR_LE

[Simon Horman]

On Mon, Nov 02, 2015 at 11:21:43AM +1100, Sam Mendoza-Jonas wrote:
> On Mon, Nov 02, 2015 at 09:55:53AM +1100, Sam Mendoza-Jonas wrote:
> > On Tue, Oct 06, 2015 at 05:55:49PM -0500, Scott Wood wrote:
> > > Commit a304e2d82a8c3 ("ppc64: purgatory: Reset primary cpu endian to
> > > big-endian) changed bctr to rfid.  rfid is book3s-only and will cause a
> > > fatal exception on book3e.
> > > 
> > > Purgatory is an isolated environment which makes importing information
> > > about the subarch awkward, so instead rely on the fact that MSR_LE
> > > should never be set on book3e, and the rfid is only needed if MSR_LE is
> > > set (and thus needs to be cleared).  In theory that MSR bit is reserved
> > > on book3e, rather than zero, but in practice I have not seen it set.
> > > 
> > > Signed-off-by: Scott Wood 
> > > Cc: Samuel Mendoza-Jonas 
> > > ---
> > > v2: new patch
> > 
> > Looks good to me, thanks for catching this!
> > I'll ping Michael too if you'd like his reviewed-by.
> > 
> > Reviewed-by: Samuel Mendoza-Jonas 
> 
> Following up, also add my
> 
> Tested-by: Samuel Mendoza-Jonas 

Thanks, I have queued this up for v2.0.11.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [ANNOUNCE] kexec-tools 2.0.11-rc1

[Simon Horman]

On Thu, Oct 29, 2015 at 07:23:24PM -0500, Scott Wood wrote:
> On Fri, 2015-10-30 at 08:48 +0900, Simon Horman wrote:
> > Hi all,
> > 
> > I am happy to announce the release of kexec-tools 2.0.11-rc1.
> > 
> > This is an incremental feature pre-release.
> > 
> > So long as no serious problems arise I intend to release kexec-tools 2.0.11
> > shortly after the release of the v4.3 kernel, which I expect to occur in
> > the next week or so.  As such testing of 2.0.11-rc1 would be greatly
> > appreciated.
> > 
> > I do not have any outstanding changes for 2.0.11 at this time.
> > And I would like to only accept bug fixes at this time and take take
> > features patches once 2.0.11 has been released.
> 
> As I previously reported, "ppc64: purgatory: Reset primary cpu endian to big-
> endian" breaks book3e, so can http://patchwork.ozlabs.org/patch/527048/ be 
> considered for this release?

Yes of course, sorry for not taking more note of that.

Would it be possible to get a review, e.g. from Michael?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/3] ppc64: Fix warnings

[Simon Horman]

On Tue, Oct 06, 2015 at 05:55:48PM -0500, Scott Wood wrote:
> Produce a warning-free build on ppc64 (at least, when built as 64-bit
> userspace -- if a 64-bit binary for ppc64 is a requirement, why is -m64
> set only on purgatory?).  Mostly unused (or write-only) variable
> warnings, but also one nasty one where reserve() was used without a
> prototype, causing long long arguments to be passed as int.
> 
> Signed-off-by: Scott Wood 

Thanks, applied.

I would have slightly preferred one-patch per problem.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

[Simon Horman]

On Tue, Oct 06, 2015 at 05:55:50PM -0500, Scott Wood wrote:
> It needs to know this because the SMP release mechanism for Freescale
> book3e is different from when booting with normal hardware.  In theory
> we could simulate the normal spin table mechanism, but not (easily) at
> the addresses U-Boot put in the device tree -- so there'd need to be
> even more communication between the kernel and kexec to set that up.
> 
> Signed-off-by: Scott Wood 
> ---
> v2: Use a device tree property rather than setting a flag in the kernel
> image, as requested by Michael Ellerman.

I'd value a review of this from someone more familiar with ppc than I.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/3] ppc64: Avoid rfid if no need to clear MSR_LE

[Simon Horman]

On Tue, Oct 06, 2015 at 05:55:49PM -0500, Scott Wood wrote:
> Commit a304e2d82a8c3 ("ppc64: purgatory: Reset primary cpu endian to
> big-endian) changed bctr to rfid.  rfid is book3s-only and will cause a
> fatal exception on book3e.
> 
> Purgatory is an isolated environment which makes importing information
> about the subarch awkward, so instead rely on the fact that MSR_LE
> should never be set on book3e, and the rfid is only needed if MSR_LE is
> set (and thus needs to be cleared).  In theory that MSR bit is reserved
> on book3e, rather than zero, but in practice I have not seen it set.
> 
> Signed-off-by: Scott Wood 
> Cc: Samuel Mendoza-Jonas 
> ---
> v2: new patch

Could I get a review of this from at lest one ppc person?

>  purgatory/arch/ppc64/v2wrap.S | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/purgatory/arch/ppc64/v2wrap.S b/purgatory/arch/ppc64/v2wrap.S
> index 179ade9..3534080 100644
> --- a/purgatory/arch/ppc64/v2wrap.S
> +++ b/purgatory/arch/ppc64/v2wrap.S
> @@ -116,9 +116,17 @@ master:
>   stw 7,0x5c(4)   # and patch it into the kernel
>   mr  3,16# restore dt address
>  
> + mfmsr   5
> + andi.   10,5,1  # test MSR_LE
> + bne little_endian
> +
> + li  5,0 # r5 will be 0 for kernel
> + mtctr   4   # prepare branch to
> + bctr# start kernel
> + 
> +little_endian:   # book3s-only
>   mtsrr0  4   # prepare branch to
>  
> - mfmsr   5
>   clrrdi  5,5,1   # clear MSR_LE
>   mtsrr1  5
>  
> -- 
> 2.1.4
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] purgatory/arch/ppc64: Reset primary cpu endian to big-endian

[Simon Horman]

On Thu, Sep 03, 2015 at 03:18:02PM +1000, Michael Ellerman wrote:
> On Wed, 2015-09-02 at 10:02 +0900, Simon Horman wrote:
> > [CC linuxppc-dev]
> > 
> > On Fri, Aug 21, 2015 at 12:51:16PM +1000, Samuel Mendoza-Jonas wrote:
> > > Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> > > meaning if we kexec from a little-endian kernel the target kernel will
> > > fail to boot.
> > > Returning to big-endian before we enter the target kernel ensures that
> > > the target kernel can boot whether or not it includes FIXUP_ENDIAN.
> > > 
> > > This mirrors commit 150b14e7 in kexec-lite.
> > > 
> > > Signed-off-by: Samuel Mendoza-Jonas <sam...@au1.ibm.com>
> > 
> > I would value a review from one of the PPC folks.
> 
> The diff looks good to me, and I've also tested it, so take your pick:
> 
> Tested-by: Michael Ellerman <m...@ellerman.id.au>
> Acked-by: Michael Ellerman <m...@ellerman.id.au>

Thanks, I took the latter.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] purgatory/arch/ppc64: Reset primary cpu endian to big-endian

[Simon Horman]

[CC linuxppc-dev]

On Fri, Aug 21, 2015 at 12:51:16PM +1000, Samuel Mendoza-Jonas wrote:
> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> meaning if we kexec from a little-endian kernel the target kernel will
> fail to boot.
> Returning to big-endian before we enter the target kernel ensures that
> the target kernel can boot whether or not it includes FIXUP_ENDIAN.
> 
> This mirrors commit 150b14e7 in kexec-lite.
> 
> Signed-off-by: Samuel Mendoza-Jonas 

I would value a review from one of the PPC folks.

> ---
>  purgatory/arch/ppc64/v2wrap.S | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/purgatory/arch/ppc64/v2wrap.S b/purgatory/arch/ppc64/v2wrap.S
> index dc5034f..179ade9 100644
> --- a/purgatory/arch/ppc64/v2wrap.S
> +++ b/purgatory/arch/ppc64/v2wrap.S
> @@ -114,10 +114,16 @@ master:
>   LOADADDR(6,run_at_load) # the load flag
>   lwz 7,0(6)  # possibly patched by kexec-elf-ppc64
>   stw 7,0x5c(4)   # and patch it into the kernel
> - li  5,0 # r5 will be 0 for kernel
> - mtctr   4   # prepare branch too
>   mr  3,16# restore dt address
>  
> + mtsrr0  4   # prepare branch to
> +
> + mfmsr   5
> + clrrdi  5,5,1   # clear MSR_LE
> + mtsrr1  5
> +
> + li  5,0 # r5 will be 0 for kernel
> +
>   # skip cache flush, do we care?
>  
> - bctr# start kernel
> + rfid# update MSR and start kernel
> -- 
> 2.5.0
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 5/7] PCI: Remove unnecessary #includes of asm/pci.h

[Simon Horman]

On Thu, Jun 04, 2015 at 04:49:57PM -0500, Bjorn Helgaas wrote:
 In include/linux/pci.h, we already #include asm/pci.h, so we don't need
 to include asm/pci.h directly.
 
 Remove the unnecessary includes.  All the files here already include
 linux/pci.h.
 
 Signed-off-by: Bjorn Helgaas bhelg...@google.com
 CC: linux-al...@vger.kernel.org
 CC: linux-m...@linux-mips.org
 CC: linuxppc-dev@lists.ozlabs.org
 CC: linux...@vger.kernel.org
 CC: x...@kernel.org
 ---
  arch/alpha/kernel/core_irongate.c |1 -
  arch/alpha/kernel/sys_eiger.c |1 -
  arch/alpha/kernel/sys_nautilus.c  |1 -
  arch/mips/pci/fixup-cobalt.c  |1 -
  arch/mips/pci/ops-mace.c  |1 -
  arch/mips/pci/pci-lantiq.c|1 -
  arch/powerpc/kernel/prom.c|1 -
  arch/powerpc/kernel/prom_init.c   |1 -
  arch/sh/drivers/pci/ops-sh5.c |1 -
  arch/sh/drivers/pci/pci-sh5.c |1 -
  arch/x86/kernel/x86_init.c|1 -
  11 files changed, 11 deletions(-)

arch/sh/drivers portion:

Acked-by: Simon Horman horms+rene...@verge.net.au

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

Re: [PATCH 0/4] defconfigs: cleanup obsolete MTD configs

[Simon Horman]

On Sat, Jan 24, 2015 at 06:33:29PM +0200, Semen Protsenko wrote:
 This patch series removes next obsolete MTD configs from all defconfig files:
   - CONFIG_MTD_CHAR
   - CONFIG_MTD_CONCAT
   - CONFIG_MTD_DEBUG
   - CONFIG_MTD_DEBUG_VERBOSE
   - CONFIG_MTD_PARTITIONS
 
 All those configs were removed from drivers/mtd/Kconfig earlier, but their 
 usage
 in defconfig files was remain unnoticed. There are at least two obvious 
 reasons
 to get rid of those configs:
   1. Their usage may cause to build warnings
   2. Their usage may confuse someone who is grepping defconfig files to get
  the clue what MTD configuration may look like.
 
 This series is harmless for all those defconfigs and will not break anything.

FYI, there is a plan to remove arch/arm/configs/mackerel_defconfig in v3.21.

 
 
 Semen Protsenko (4):
   defconfigs: remove CONFIG_MTD_CONCAT
   defconfigs: remove CONFIG_MTD_PARTITIONS
   defconfigs: remove CONFIG_MTD_CHAR
   defconfigs: remove CONFIG_MTD_DEBUG*
 
  arch/arm/configs/acs5k_defconfig   |3 ---
  arch/arm/configs/acs5k_tiny_defconfig  |3 ---
  arch/arm/configs/am200epdkit_defconfig |1 -
  arch/arm/configs/assabet_defconfig |2 --
  arch/arm/configs/badge4_defconfig  |3 ---
  arch/arm/configs/bockw_defconfig   |1 -
  arch/arm/configs/cerfcube_defconfig|2 --
  arch/arm/configs/cm_x2xx_defconfig |1 -
  arch/arm/configs/cm_x300_defconfig |2 --
  arch/arm/configs/cns3420vb_defconfig   |2 --
  arch/arm/configs/colibri_pxa270_defconfig  |2 --
  arch/arm/configs/collie_defconfig  |2 --
  arch/arm/configs/corgi_defconfig   |2 --
  arch/arm/configs/davinci_all_defconfig |2 --
  arch/arm/configs/em_x270_defconfig |1 -
  arch/arm/configs/ezx_defconfig |1 -
  arch/arm/configs/h5000_defconfig   |1 -
  arch/arm/configs/hackkit_defconfig |3 ---
  arch/arm/configs/imote2_defconfig  |1 -
  arch/arm/configs/iop13xx_defconfig |1 -
  arch/arm/configs/iop32x_defconfig  |2 --
  arch/arm/configs/iop33x_defconfig  |2 --
  arch/arm/configs/ixp4xx_defconfig  |2 --
  arch/arm/configs/ks8695_defconfig  |2 --
  arch/arm/configs/lart_defconfig|4 
  arch/arm/configs/lpc32xx_defconfig |1 -
  arch/arm/configs/lpd270_defconfig  |2 --
  arch/arm/configs/lubbock_defconfig |2 --
  arch/arm/configs/mackerel_defconfig|3 ---
  arch/arm/configs/magician_defconfig|2 --
  arch/arm/configs/mainstone_defconfig   |2 --
  arch/arm/configs/mini2440_defconfig|3 ---
  arch/arm/configs/mv78xx0_defconfig |2 --
  arch/arm/configs/neponset_defconfig|2 --
  arch/arm/configs/netx_defconfig|2 --
  arch/arm/configs/nuc910_defconfig  |3 ---
  arch/arm/configs/nuc950_defconfig  |3 ---
  arch/arm/configs/nuc960_defconfig  |3 ---
  arch/arm/configs/omap1_defconfig   |4 
  arch/arm/configs/orion5x_defconfig |1 -
  arch/arm/configs/pcm027_defconfig  |2 --
  arch/arm/configs/pleb_defconfig|2 --
  arch/arm/configs/pxa255-idp_defconfig  |2 --
  arch/arm/configs/pxa3xx_defconfig  |2 --
  arch/arm/configs/raumfeld_defconfig|3 ---
  arch/arm/configs/realview-smp_defconfig|3 ---
  arch/arm/configs/realview_defconfig|3 ---
  arch/arm/configs/s3c2410_defconfig |1 -
  arch/arm/configs/shannon_defconfig |2 --
  arch/arm/configs/simpad_defconfig  |3 ---
  arch/arm/configs/spear13xx_defconfig   |1 -
  arch/arm/configs/spear3xx_defconfig|1 -
  arch/arm/configs/spear6xx_defconfig|1 -
  arch/arm/configs/spitz_defconfig   |2 --
  arch/arm/configs/tct_hammer_defconfig  |2 --
  arch/arm/configs/trizeps4_defconfig|2 --
  arch/arm/configs/viper_defconfig   |1 -
  arch/arm/configs/xcep_defconfig|1 -
  arch/arm/configs/zeus_defconfig|1 -
  arch/avr32/configs/atngw100_defconfig  |1 -
  arch/avr32/configs/atngw100_evklcd100_defconfig|1 -
  arch/avr32/configs/atngw100_evklcd101_defconfig|1 -
  arch/avr32/configs/atngw100_mrmt_defconfig |1 -
  

Re: [PATCH v2] kexec/ppc64 fix device tree endianess issues for memory attributes

[Simon Horman]

On Thu, Jan 30, 2014 at 04:06:22PM +0100, Laurent Dufour wrote:
 All the attributes exposed in the device tree are in Big Endian format.
 
 This patch add the byte swap operation for some entries which were not yet
 processed, including those fixed by the following kernel's patch :
 
 https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-January/114720.html
 
 To work on PPC64 Little Endian mode, kexec now requires that the kernel's
 patch mentioned above is applied on the kexecing kernel.
 
 Tested on ppc64 LPAR (kexec/dump) and ppc64le in a Qemu/KVM guest (kexec)
 
 Changes from v1 :
  * add processing of the following entries :
- ibm,dynamic-reconfiguration-memory
- chosen/linux,kernel-end
- chosen/linux,crashkernel-base  size
- chosen/linux,memory-limit
- chosen/linux,htab-base  size
- linux,tce-base  size
- memory@/reg
 Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com

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

Re: [PATCH 0/4] Minor fixes and improvements for kexec

[Simon Horman]

On Thu, Dec 12, 2013 at 12:18:56AM +, Geoff Levand wrote:
 Hi Eric,
 
 Here are a few minor fixes and improvements for kexec.  Please consider.

FWIW,

Reviewed-by: Simon Horman ho...@verge.net.au

 
 -Geoff
 
 The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
 
   Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
 
 are available in the git repository at:
 
   git://git.linaro.org/people/geoff.levand/linux-kexec.git for-kexec
 
 for you to fetch changes up to 594a3d26aac66e9668edc81d7bfb4e801575514f:
 
   sh/kexec: Fix kexec build warning (2013-12-11 16:03:27 -0800)
 
 
 Geoff Levand (4):
   kexec: Simplify conditional
   kexec: Add IND_FLAGS macro
   powerpc/kexec: Use global IND_FLAGS macro
   sh/kexec: Fix kexec build warning
 
  arch/powerpc/kernel/machine_kexec_64.c |  2 --
  arch/sh/kernel/machine_kexec.c |  2 +-
  include/linux/kexec.h  |  1 +
  kernel/kexec.c | 17 ++---
  4 files changed, 12 insertions(+), 10 deletions(-)
 
 -- 
 1.8.1.2
 
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Preliminary kexec support for Linux/m68k

[Simon Horman]

On Thu, Sep 19, 2013 at 11:20:22AM +0200, Geert Uytterhoeven wrote:
 On Tue, Sep 17, 2013 at 12:01 PM, Geert Uytterhoeven
 ge...@linux-m68k.org wrote:
  This is a preliminary set of patches to add kexec support for m68k.
 
- [PATCH 1/3] m68k: Add preliminary kexec support
- [PATCH 2/3] m68k: Add support to export bootinfo in procfs
- [PATCH 3/3] [RFC] m68k: Add System RAM to /proc/iomem
 
  Notes:
- The bootinfo is now saved and exported to /proc/bootinfo, so kexec-tools
  can read it and pass it (possibly after modification) to the new kernel.
  This is similar to /proc/atags on ARM.
 
- I based [PATCH 3/3] on the PowerPC version, but it's no longer needed 
  as we
  now get this information from the bootinfo.
  Does anyone think this is nice to have anyway?
 
 It seems kexec/kdump on ppc don't use /proc/iomem anymore, and only rely on
 /proc/device-tree these days?

I think thats entirely a matter for the m68k kernel maintainers to decide.
But my personal opinion is that it is nice not to add it if it isn't needed.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] kexec/ppc: Fix kernel program entry point while changing the load addr

[Simon Horman]

On Mon, Mar 04, 2013 at 11:26:24AM +0530, Suzuki K. Poulose wrote:
 On 03/04/2013 07:11 AM, Simon Horman wrote:
 [ Cc: linuxppc-dev@lists.ozlabs.org ]
 
 On Sun, Mar 03, 2013 at 01:06:00PM +0530, Suzuki K. Poulose wrote:
 From: Suzuki K. Poulose suz...@in.ibm.com
 
 uImage probe fills the entry point (ep) based on the load_addr
 from the uImage headers. If we change the load_addr, we should
 accordingly update the entry point.
 
 For ELF, calculate the offset of e_entry from the virtual start
 address and add it to the physical start address to find the
 physical address of kernel entry.
 
 i.e,
pa (e_entry) = pa(phdr[0].p_vaddr) + (e_entry - phdr[0].p_vaddr)
 = kernel_addr + (e_entry - phdr[0].p_vaddr)
 
 Would it be possible for someone to provide a review of this change?
 To make it bit more clear :
 
 The entry point of the kernel is usually at 0 offset from the first
 PT_LOAD section. The current code makes this assumption and uses the
 pa(phdr[0].p_vaddr) as the kernel entry.
 
 But this *may* not be true always, in such a case the kexec would fail.
 While I fixed the uImage case, I thought it would be better to
 handle the same case in ELF.
 
 Btw, this calculation is not specific to ppc32.

Thanks, I have applied the patch.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] kexec/ppc: Fix kernel program entry point while changing the load addr

[Simon Horman]

[ Cc: linuxppc-dev@lists.ozlabs.org ]

On Sun, Mar 03, 2013 at 01:06:00PM +0530, Suzuki K. Poulose wrote:
 From: Suzuki K. Poulose suz...@in.ibm.com
 
 uImage probe fills the entry point (ep) based on the load_addr
 from the uImage headers. If we change the load_addr, we should
 accordingly update the entry point.
 
 For ELF, calculate the offset of e_entry from the virtual start
 address and add it to the physical start address to find the
 physical address of kernel entry.
 
 i.e,
   pa (e_entry) = pa(phdr[0].p_vaddr) + (e_entry - phdr[0].p_vaddr)
= kernel_addr + (e_entry - phdr[0].p_vaddr)

Would it be possible for someone to provide a review of this change?

 
 Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
 Cc: Sebastian Andrzej Siewior bige...@linutronix.de
 Cc: Matthew McClintock m...@freescale.com
 ---
  kexec/arch/ppc/kexec-elf-ppc.c|   12 
  kexec/arch/ppc/kexec-uImage-ppc.c |6 +-
  2 files changed, 13 insertions(+), 5 deletions(-)
 
 diff --git a/kexec/arch/ppc/kexec-elf-ppc.c b/kexec/arch/ppc/kexec-elf-ppc.c
 index 8e408cc..5f63a64 100644
 --- a/kexec/arch/ppc/kexec-elf-ppc.c
 +++ b/kexec/arch/ppc/kexec-elf-ppc.c
 @@ -397,10 +397,14 @@ int elf_ppc_load(int argc, char **argv, const char 
 *buf, off_t len,
   die(Error device tree not loadded to address it was expecting 
 to be loaded too!\n);
   }
  
 - /* set various variables for the purgatory  ehdr.e_entry is a
 -  * virtual address, we can use kernel_addr which
 -  * should be the physical start address of the kernel */
 - addr = kernel_addr;
 + /* 
 +  * set various variables for the purgatory.
 +  * ehdr.e_entry is a virtual address. we know physical start
 +  * address of the kernel (kernel_addr). Find the offset of
 +  * e_entry from the virtual start address(e_phdr[0].p_vaddr)
 +  * and calculate the actual physical address of the 'kernel entry'.
 +  */
 + addr = kernel_addr + (ehdr.e_entry - ehdr.e_phdr[0].p_vaddr);
   elf_rel_set_symbol(info-rhdr, kernel, addr, sizeof(addr));
  
   addr = dtb_addr;
 diff --git a/kexec/arch/ppc/kexec-uImage-ppc.c 
 b/kexec/arch/ppc/kexec-uImage-ppc.c
 index e0bc7bb..900cd16 100644
 --- a/kexec/arch/ppc/kexec-uImage-ppc.c
 +++ b/kexec/arch/ppc/kexec-uImage-ppc.c
 @@ -159,15 +159,19 @@ static int ppc_load_bare_bits(int argc, char **argv, 
 const char *buf,
  
   /*
* If the provided load_addr cannot be allocated, find a new
 -  * area.
 +  * area. Rebase the entry point based on the new load_addr.
*/
   if (!valid_memory_range(info, load_addr, load_addr + (len + _1MiB))) {
 + int ep_offset = ep - load_addr;
 +
   load_addr = locate_hole(info, len + _1MiB, 0, 0, max_addr, 1);
   if (load_addr == ULONG_MAX) {
   printf(Can't allocate memory for kernel of len %ld\n,
   len + _1MiB);
   return -1;
   }
 +
 + ep = load_addr + ep_offset;
   }
  
   add_segment(info, buf, len, load_addr, len + _1MiB);
 
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type

[Simon Horman]

On Wed, Jan 16, 2013 at 08:30:59PM +0530, Kishon Vijay Abraham I wrote:
 In order to add support for multipe PHY's of the same type, the API's
 for adding PHY and getting PHY has been changed. Now the binding
 information of the PHY and controller should be done in platform file
 using usb_bind_phy API. And for getting a PHY, the device pointer of the
 USB controller and an index should be passed. Based on the binding
 information that is added in the platform file, get_phy will return the
 approappropriate PHY.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  arch/arm/mach-shmobile/board-marzen.c |2 +-

Modification to the above file:

Acked-by: Simon Horman horms+rene...@verge.net.au
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] [ppc] Do not reserve cpu spin-table for crash kernel

[Simon Horman]

On Thu, May 24, 2012 at 11:39:45AM +0530, Suzuki K. Poulose wrote:
 As of now, the kexec reserves the spin-table for all the CPUs
 on an SMP machine. The spin-table is pointed to by the 
 cpu-release-addr property in the device-tree. Reserving the
 spin-table in the crash kernel will cause a BUG(), if the table
 lies outside the memory reserved for the crashkernel.
 
 Disable reserving the spin-table regions and use maxcpus=1 to 
 use only the crashing CPU to boot the crash kernel.
 
 Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com

Thanks, applied.

Sorry for not seeing this (much) earlier.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/5] ppc: move DEBUG code to --debug

[Simon Horman]

[CC linuxppc-...@ozlabs.org]

On Thu, Mar 08, 2012 at 02:39:39PM +0800, Cong Wang wrote:
 Like patch 1/5, this one moves code under #if DEBUG to --debug
 on ppc arch.
 
 Signed-off-by: Cong Wang xiyou.wangc...@gmail.com
 ---
  kexec/arch/ppc/crashdump-powerpc.c |   18 --
  kexec/arch/ppc/fixup_dtb.c |   25 +++--
  kexec/arch/ppc/fs2dt.c |6 +++---
  kexec/arch/ppc/kexec-ppc.c |   17 -
  kexec/arch/ppc/libfdt-wrapper.c|4 ++--
  kexec/arch/ppc64/crashdump-ppc64.c |   16 ++--
  kexec/arch/ppc64/kexec-elf-ppc64.c |   23 +++
  kexec/arch/ppc64/kexec-ppc64.c |9 +++--
  8 files changed, 52 insertions(+), 66 deletions(-)
 
 diff --git a/kexec/arch/ppc/crashdump-powerpc.c 
 b/kexec/arch/ppc/crashdump-powerpc.c
 index 7c9dbff..1bef69b 100644
 --- a/kexec/arch/ppc/crashdump-powerpc.c
 +++ b/kexec/arch/ppc/crashdump-powerpc.c
 @@ -226,15 +226,15 @@ static int get_crash_memory_ranges(struct memory_range 
 **range, int *ranges)
  
   *range = crash_memory_range;
   *ranges = memory_ranges;
 -#if DEBUG
 +
   int j;
 - printf(CRASH MEMORY RANGES\n);
 + dbgprintf(CRASH MEMORY RANGES\n);
   for (j = 0; j  *ranges; j++) {
   start = crash_memory_range[j].start;
   end = crash_memory_range[j].end;
 - fprintf(stderr, %016Lx-%016Lx\n, start, end);
 + dbgprintf(%016Lx-%016Lx\n, start, end);
   }
 -#endif
 +
   return 0;
  
  err:
 @@ -289,9 +289,9 @@ static int add_cmdline_param(char *cmdline, unsigned long 
 long addr,
   if (cmdlen  (COMMAND_LINE_SIZE - 1))
   die(Command line overflow\n);
   strcat(cmdline, str);
 -#if DEBUG
 - fprintf(stderr, Command line after adding elfcorehdr: %s\n, cmdline);
 -#endif
 +
 + dbgprintf(Command line after adding elfcorehdr: %s\n, cmdline);
 +
   return 0;
  }
  
 @@ -403,10 +403,8 @@ void add_usable_mem_rgns(unsigned long long base, 
 unsigned long long size)
   usablemem_rgns.ranges[usablemem_rgns.size].start = base;
   usablemem_rgns.ranges[usablemem_rgns.size++].end = end;
  
 -#ifdef DEBUG
 - fprintf(stderr, usable memory rgns size:%u base:%llx size:%llx\n,
 + dbgprintf(usable memory rgns size:%u base:%llx size:%llx\n,
   usablemem_rgns.size, base, size);
 -#endif
  }
  
  int is_crashkernel_mem_reserved(void)
 diff --git a/kexec/arch/ppc/fixup_dtb.c b/kexec/arch/ppc/fixup_dtb.c
 index 189e0c7..e5f2717 100644
 --- a/kexec/arch/ppc/fixup_dtb.c
 +++ b/kexec/arch/ppc/fixup_dtb.c
 @@ -17,25 +17,26 @@
  
  const char proc_dts[] = /proc/device-tree;
  
 -#ifdef DEBUG
  static void print_fdt_reserve_regions(void)
  {
   int i, num;
  
 + if (!kexec_debug)
 + return;
   /* Print out a summary of the final reserve regions */
   num =  fdt_num_mem_rsv(blob_buf);

blob_buf does not exist in the context of this function.
So clearly it hasn't been compiled or exercised for a while.
I propose removing it altogether. It can always be re-added latter
if someone fixes and tests it - I do not have access to any ppc hw to do so.

 - printf (reserve regions: %d\n, num);
 + dbgprintf (reserve regions: %d\n, num);
   for (i = 0; i  num; i++) {
   uint64_t offset, size;
  
   if (fdt_get_mem_rsv(blob_buf, i, offset, size) == 0) {
 - printf(%d: offset: %llx, size: %llx\n, i, offset, 
 size);
 + dbgprintf(%d: offset: %llx, size: %llx\n, i, offset, 
 size);
   } else {
 - printf(Error retreiving reserved region\n);
 + dbgprintf(Error retreiving reserved region\n);
   }
   }
  }
 -#endif
 +
  
  static void fixup_nodes(char *nodes[])
  {
 @@ -203,9 +204,7 @@ static void fixup_reserve_regions(struct kexec_info 
 *info, char *blob_buf)
  
  out: ;
  
 -#ifdef DEBUG
   print_fdt_reserve_regions();
 -#endif
  }
  
  static void fixup_memory(struct kexec_info *info, char *blob_buf)
 @@ -369,23 +368,23 @@ char *fixup_dtb_init(struct kexec_info *info, char 
 *blob_buf, off_t *blob_size,
   return blob_buf;
  }
  
 -#ifdef DEBUG
  static void save_fixed_up_dtb(char *blob_buf, off_t blob_size)
  {
   FILE *fp;
  
 + if (!kexec_debug)
 + return;
   fp = fopen(debug.dtb, w);
   if (fp) {
   if ( blob_size == fwrite(blob_buf, sizeof(char), blob_size, 
 fp)) {
 - printf(debug.dtb written\n);
 + dbgprintf(debug.dtb written\n);
   } else {
 - printf(Unable to write debug.dtb\n);
 + dbgprintf(Unable to write debug.dtb\n);
   }
   } else {
 - printf(Unable to dump flat device tree to debug.dtb\n);
 + dbgprintf(Unable to dump flat device tree to debug.dtb\n);
   }
  }
 -#endif
  
  char 

Re: [PATCH] [v3] kexec-tools: ppc32: Fixup ThreadPointer for purgatory code

[Simon Horman]

On Tue, Jul 12, 2011 at 03:20:40PM +0530, Suzuki K. Poulose wrote:
 PPC32 ELF ABI expects r2 to be loaded with Thread Pointer, which is 0x7000
 bytes past the end of TCB. Though the purgatory is single threaded, it uses
 TCB scratch space in vsnprintf(). This patch allocates a 1024byte TCB
 and populates the TP with the address accordingly.
 
 Changes from V2: Avoid address overflow in TP allocation.
 Changes from V1: Fixed the addr calculation for uImage support.
 
 
 Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
 Cc: Ryan S. Arnold r...@us.ibm.com

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

Re: [PATCH v2] kexec-tools: powerpc: Use the #address-cells information to parsememory/reg

[Simon Horman]

On Thu, Jun 16, 2011 at 04:15:13PM +0530, Suzuki K. Poulose wrote:
 The format of memory/reg is based on the #address-cells,#size-cells. 
 Currently,
 the kexec-tools doesn't use the above values in parsing the memory/reg values.
 Hence the kexec cannot handle cases where #address-cells, #size-cells are
 different, (for e.g, PPC440X ).
 
 This patch introduces a read_memory_region_limits(), which parses the
 memory/reg contents based on the values of #address-cells and #size-cells.

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

Re: [RFC][PATCH] kexec-tools: powerpc: Use the #address-cells information to parsememory/reg - V2

[Simon Horman]

On Wed, Jun 08, 2011 at 12:08:55PM +0530, Suzuki Poulose wrote:
 Hi,
 
 This is version 2 of the patch
 
 Changes from Version 1 :
  : Changed the interface for read_memory_region_limits to use 'int fd'
   instead of FILE*.
  : Use sizeof(variable) for read(, instead of sizeof(type).
 
 
 ---
 
 Fix parsing of the memory region information from the device-tree.
 
 The format of memory/reg is based on the #address-cells,#size-cells. 
 Currently,
 the kexec-tools doesn't use the above values in parsing the memory/reg values.
 Hence the kexec cannot handle cases where #address-cells, #size-cells are
 different, (for e.g, PPC440X ).
 
 This patch introduces a read_memory_region_limits(), which parses the
 memory/reg contents based on the values of #address-cells and #size-cells.
 
 Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com

Hi,

this does not seem to apply to the master branch of
git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ppc64: increase TREEWORDS value in ppc64

[Simon Horman]

[ CCed linuxppc-dev ]

On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
 hey-
  Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
 Tracked it back to running over the end of the device tree buffer that we have
 allocated.  I can't find any docs on how big the device tree can legally be, 
 so
 for now I figure just upping its size is sufficient.  Confirmed that this 
 fixed
 the segfault.

Thanks Neil, though it would be nice to know what the limit actually is.
I'll hold off on applying this for a few days to see of the ppc people
have any comments on that.

 
 Signed-off-by: Neil Horman nhor...@tuxdriver.com
 
 
  fs2dt.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 
 diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c
 index 238a3f2..2f0f937 100644
 --- a/kexec/arch/ppc/fs2dt.c
 +++ b/kexec/arch/ppc/fs2dt.c
 @@ -33,7 +33,7 @@
  
  #define MAXPATH  1024/* max path name length */
  #define NAMESPACE16384   /* max bytes for property names */
 -#define TREEWORDS65536   /* max 32 bit words for properties */
 +#define TREEWORDS131070  /* max 32 bit words for properties */
  #define MEMRESERVE   256 /* max number of reserved memory blks */
  #define MAX_MEMORY_RANGES1024
  #define COMMAND_LINE_SIZE512 /* from kernel */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ppc64: increase TREEWORDS value in ppc64

[Simon Horman]

[ Repost with correct kexec ML address ]
[ CCed linuxppc-dev ]

On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
 hey-
  Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
 Tracked it back to running over the end of the device tree buffer that we have
 allocated.  I can't find any docs on how big the device tree can legally be, 
 so
 for now I figure just upping its size is sufficient.  Confirmed that this 
 fixed
 the segfault.

Thanks Neil, though it would be nice to know what the limit actually is.
I'll hold off on applying this for a few days to see of the PPC people
have any comments on that.

 
 Signed-off-by: Neil Horman nhor...@tuxdriver.com
 
 
  fs2dt.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 
 diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c
 index 238a3f2..2f0f937 100644
 --- a/kexec/arch/ppc/fs2dt.c
 +++ b/kexec/arch/ppc/fs2dt.c
 @@ -33,7 +33,7 @@
  
  #define MAXPATH  1024/* max path name length */
  #define NAMESPACE16384   /* max bytes for property names */
 -#define TREEWORDS65536   /* max 32 bit words for properties */
 +#define TREEWORDS131070  /* max 32 bit words for properties */
  #define MEMRESERVE   256 /* max number of reserved memory blks */
  #define MAX_MEMORY_RANGES1024
  #define COMMAND_LINE_SIZE512 /* from kernel */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 0/3] Misc. bug fixes for ppc32

[Simon Horman]

On Wed, Aug 18, 2010 at 11:56:48PM -0500, Matthew McClintock wrote:
 This patch series fixes a few issues I have discovered with my previous
 patch series. Nothing new has been added.

Thanks, all applied.

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

Re: [PATCH v2 5/7] Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc

[Simon Horman]

On Tue, Jul 20, 2010 at 03:14:58PM -0500, Matthew McClintock wrote:
 This fixes --reuseinitrd and --ramdisk option for ppc32 on
 uImage-ppc and Elf. It works for normal kexec as well as for
 kdump.
 
 When using --reuseinitrd you need to specifify retain_initrd
 on the command line. Also, if you are doing kdump you need to make
 sure your initrd lives in the crashdump region otherwise the
 kdump kernel will not be able to access it. The --ramdisk option
 should always work.

Thanks, I have applied this change.
I had to do a minor merge on the Makefile,
could you verify that the result is correct?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/7] Fixup booting with device trees and uImage/elf on ppc32

[Simon Horman]

On Mon, Jul 26, 2010 at 11:22:58PM -0500, Matthew McClintock wrote:
 
 On Jul 26, 2010, at 9:55 PM, Simon Horman wrote:
 
  [Cced linuxppc-dev]
  
  On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
  This patch series adds full support for booting with a flat device tree
  with either uImage or elf file formats. Kexec and Kdump should work, and
  you should also be able to use ramdisks or reuse your current ramdisk as 
  well
  
  This patch series was tested on an mpc85xx system with a kernel version
  2.6.35-rc3
  
  v1: Initial version
  
  v2: Added support for fs2dt (file system to device tree)
  
  v3: Fix some misc. git problems I had and other code cleanups
  
  Hi Matthew,
  
  I'm a little concerned that these changes are non trivial and haven't had
  much review. But I am prepared to put them into my tree once 2.0.2 is
  released - perhaps that way they will get some test coverage. Does
  that work for you?
 
 Either way works for me. I know they could use more review, however as Maxim 
 said the current tree does not work AFAIK. Either way, I'm willing to keeping 
 addressing everyones concerns and wait or move forward and make some quick 
 fixes as well.

All applied.

I made some minor changes to three of the patches.
I have noted each change in separate emails.

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

Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec

[Simon Horman]

On Fri, Jul 30, 2010 at 01:15:14PM +1000, Michael Neuling wrote:
 (adding kexec list to CC)
 
 In message 4c521fd2.4050...@ozlabs.org you wrote:
  Michael Neuling wrote:
   In message 4c511216.30...@ozlabs.org you wrote:
   When CPU hotplug is used, some CPUs may be offline at the time a kexec is
   performed.  The subsequent kernel may expect these CPUs to be already 
   runn
 ing
   ,
   and will declare them stuck.  On pseries, there's also a soft-offline 
   (ced
 e)
   state that CPUs may be in; this can also cause problems as the kexeced 
   ker
 nel
   may ask RTAS if they're online -- and RTAS would say they are.  Again, 
   stu
 ck.
  
   This patch kicks each present offline CPU awake before the kexec, so that
   none are lost to these assumptions in the subsequent kernel.
   
   There are a lot of cleanups in this patch.  The change you are making
   would be a lot clearer without all the additional cleanups in there.  I
   think I'd like to see this as two patches.  One for cleanups and one for
   the addition of wake_offline_cpus().
  
  Okay, I can split this.  Typofixy-add-debug in one, wake_offline_cpus
  in another. 
 
 Thanks.
 
  
   Other than that, I'm not completely convinced this is the functionality
   we want.  Do we really want to online these cpus?  Why where they
   offlined in the first place?  I understand the stuck problem, but is the
   solution to online them, or to change the device tree so that the second
   kernel doesn't detect them as stuck?
  
  Well... There are two cases.  If a CPU is soft-offlined on pseries, it
  must b e woken from that cede loop (in
  platforms/pseries/hotplug-cpu.c) as we're repla cing code under its
  feet.  We could either special-case the wakeup from this ce de loop to
  get that CPU to RTAS stop-self itself properly.  (Kind of like a 
  wake to die.)
 
 Makes sense.  
 
  So that leaves hard-offline CPUs (perhaps including the above): I
  don't know why they might have been offlined.  If it's something
  serious, like fire, they'd be removed from the present set too (and
  thus not be considered in this restarting case).  We could add a mask
  to the CPU node to show which of the threads (if any) are running, and
  alter the startup code to start everything if this mask doesn't exist
  (non-kexec) or only online currently-running threads if the mask is
  present.  That feels a little weird.
  
  My reasoning for restarting everything was: The first time you boot,
  all of your present CPUs are started up.  When you reboot, any CPUs
  you offlined for fun are restarted.  Kexec is (in this non-crash
  sense) a user-initiated 'quick reboot', so I reasoned that it should
  look the same as a 'hard reboot' and your new invocation would have
  all available CPUs running as is usual.
 
 OK, I like this justification.  Would be good to include it in the
 checkin comment since we're changing functionality somewhat.

FWIW, I do too. Personally I like to think of kexec as soft-reboot.
Where soft means, in software, not soft-touch.

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

Re: [PATCH v3 0/7] Fixup booting with device trees and uImage/elf on ppc32

[Simon Horman]

[Cced linuxppc-dev]

On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
 This patch series adds full support for booting with a flat device tree
 with either uImage or elf file formats. Kexec and Kdump should work, and
 you should also be able to use ramdisks or reuse your current ramdisk as well
 
 This patch series was tested on an mpc85xx system with a kernel version
 2.6.35-rc3
 
 v1: Initial version
 
 v2: Added support for fs2dt (file system to device tree)
 
 v3: Fix some misc. git problems I had and other code cleanups

Hi Matthew,

I'm a little concerned that these changes are non trivial and haven't had
much review. But I am prepared to put them into my tree once 2.0.2 is
released - perhaps that way they will get some test coverage. Does
that work for you?

 
 Matthew McClintock (7):
   Restore kexec uImage-ppc to working state
   Fix case where phys_addr_t != unsigned long when reading proc entries
   Update uImage to support crash kernel and misc fixes
   Update Elf-ppc to support crash kernel and misc fixes
   Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc
   Add support for reworking flat device tree support
   Add documentation/howto for mpc85xx systems
 
  doc/mpc85xx.txt   |  190 +
  kexec/arch/ppc/Makefile   |1 +
  kexec/arch/ppc/fixup_dtb.c|  298 
 -
  kexec/arch/ppc/fixup_dtb.h|6 +-
  kexec/arch/ppc/include/arch/options.h |3 +
  kexec/arch/ppc/kexec-elf-ppc.c|  186 +
  kexec/arch/ppc/kexec-ppc.c|  262 +
  kexec/arch/ppc/kexec-ppc.h|3 +
  kexec/arch/ppc/kexec-uImage-ppc.c |  136 ---
  kexec/arch/ppc/ops.h  |1 -
  purgatory/arch/ppc/purgatory-ppc.c|5 +
  11 files changed, 852 insertions(+), 239 deletions(-)
  create mode 100644 doc/mpc85xx.txt
 
 
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Restore kexec uImage-ppc to working state

[Simon Horman]

CCed linuxppc-dev to fish for an ack.

On Mon, Jun 14, 2010 at 02:38:42PM -0500, Matthew McClintock wrote:
 Booting with uImage-ppc was broken by previous work, this
 patch should restore it to working order
 
 Signed-off-by: Matthew McClintock m...@freescale.com
 ---
  kexec/arch/ppc/kexec-ppc.c |   68 ++-
  kexec/arch/ppc/kexec-uImage-ppc.c  |5 +--
  purgatory/arch/ppc/purgatory-ppc.c |5 +++
  3 files changed, 49 insertions(+), 29 deletions(-)
 
 diff --git a/kexec/arch/ppc/kexec-ppc.c b/kexec/arch/ppc/kexec-ppc.c
 index 55cadd6..c073f56 100644
 --- a/kexec/arch/ppc/kexec-ppc.c
 +++ b/kexec/arch/ppc/kexec-ppc.c
 @@ -261,11 +261,28 @@ static int get_base_ranges(void)
   break;
   }
   }
 - base_memory_range[local_memory_ranges].start =
 - ((uint32_t *)buf)[0];
 - base_memory_range[local_memory_ranges].end  =
 - base_memory_range[local_memory_ranges].start +
 - ((uint32_t *)buf)[1];
 +
 + if (n == 8)
 + {
 + base_memory_range[local_memory_ranges].start =
 + ((uint32_t *)buf)[0];
 + base_memory_range[local_memory_ranges].end  =
 + 
 base_memory_range[local_memory_ranges].start +
 + ((uint32_t *)buf)[1];
 + }
 + else if (n == 16)
 + {
 + base_memory_range[local_memory_ranges].start =
 +((uint64_t *)buf)[0];
 +base_memory_range[local_memory_ranges].end  =
 +
 base_memory_range[local_memory_ranges].start +
 +((uint64_t *)buf)[1];
 + }
 + else
 + {
 + fprintf(stderr, Mem node has invalid size: 
 %d\n, n);
 + return -1;
 + }
   base_memory_range[local_memory_ranges].type = RANGE_RAM;
   local_memory_ranges++;
   dbgprintf(%016llx-%016llx : %x\n,
 @@ -327,27 +344,28 @@ static int get_devtree_details(unsigned long 
 kexec_flags)
   }
  
   if (strncmp(dentry-d_name, chosen, 6) == 0) {
 - strcat(fname, /linux,kernel-end);
 - file = fopen(fname, r);
 - if (!file) {
 - perror(fname);
 - goto error_opencdir;
 - }
 - if (fread(tmp_long, sizeof(unsigned long), 1, file)
 - != 1) {
 - perror(fname);
 - goto error_openfile;
 - }
 - kernel_end = tmp_long;
 - fclose(file);
 -
 - /* Add kernel memory to exclude_range */
 - exclude_range[i].start = 0x0UL;
 - exclude_range[i].end = kernel_end;
 - i++;
 - if (i = max_memory_ranges)
 - realloc_memory_ranges();
 + /* only reserve kernel region if we are doing a crash 
 kernel */
   if (kexec_flags  KEXEC_ON_CRASH) {
 + strcat(fname, /linux,kernel-end);
 + file = fopen(fname, r);
 + if (!file) {
 + perror(fname);
 + goto error_opencdir;
 + }
 + if (fread(tmp_long, sizeof(unsigned long), 1, 
 file)
 + != 1) {
 + perror(fname);
 + goto error_openfile;
 + }
 + kernel_end = tmp_long;
 + fclose(file);
 +
 + /* Add kernel memory to exclude_range */
 + exclude_range[i].start = 0x0UL;
 + exclude_range[i].end = kernel_end;
 + i++;
 + if (i = max_memory_ranges)
 + realloc_memory_ranges();
   memset(fname, 0, sizeof(fname));
   strcpy(fname, device_tree);
   strcat(fname, dentry-d_name);
 diff --git a/kexec/arch/ppc/kexec-uImage-ppc.c 
 

Re: [PATCH v2] kexec-tools, ppc64: Fix segfault parsing DR memory property

[Simon Horman]

On Tue, May 18, 2010 at 09:30:32AM +1000, Michael Neuling wrote:
 
 
 In message 4becbe89.3020...@ozlabs.org you wrote:
  add_dyn_reconf_usable_mem_property() iterates over memory spans
  in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects
  these with usablemem_rgns ranges.  In doing so it used an unchecked
  fixed-size array which will overrun on machines with lots of LMBs.
  
  This patch removes the fixed-sized arrays from
  add_dyn_reconf_usable_mem_property() and add_usable_mem_property(), in lieu 
  o
 f
  malloc/realloc/free.
  
  Signed-off-by: Matt Evans m...@ozlabs.org
 
 So this works our large P7 machine unlike the last one.
 
 Acked-by: Michael Neuling mi...@neuling.org

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

Re: [patch] ppc: Fix gamecube build

[Simon Horman]

On Fri, May 14, 2010 at 12:25:19AM +0900, Simon Horman wrote:
 This fixes the kexec-build on ppc32 when
 the --game-cube option is supplied to ./configure.
 It seems to have bit-rotted a little.
 
 Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
 Cc: Maxim Uvarov muva...@gmail.com
 Signed-off-by: Simon Horman ho...@verge.net.au

I have gone ahead and applied this change.

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

Re: [PATCH v2 2/2] powerpc new toolchains fix (crt.S)

[Simon Horman]

On Wed, May 12, 2010 at 11:08:49AM +0400, Maxim Uvarov wrote:
 
 Hello everybody,
 
   Changes from previous version:
   - removed bogus hyphen from the patch;
   - move ifdefs to crt.S instead of Makefile
 
 
   Please find here patch for user land kexec-tools application. Following
   patch makes kexec-tools work for both kexec and kdump. I tested it with 
   git kernel (linus-tree) and Freescale/Logic MPC8360ERDK board with 
   mpc83xx_defconfig kernel config.
 
   kexec:
   kexec -l vmlinux --command-line=console= ... etc
   kexec -e
 
   kdump:
   kexec -p vmlinux_dump --command-line=console=... etc
   echo c  /proc/sysrq-trigger
 
   I also think that is is reasonable:
   - put GAME_CUBE specific code to separate files;
   - combine  ppc and ppc64 to powerpc directory (I'm planning to do it.
   And that why in some places my patch have ifdefs for PPC64);
 
 Best regards,
 Maxim Uvarov.

Thanks,

I'm assuming that the silence that this patch set received,
in contrast to the first revision where there was some quick discussion,
means that everyone is ok with these changes. So I've gone ahead and pushed
them into the tree.

 From: Maxim Uvarov muva...@gmail.com
 
 Linker does not provide some vital functions when building freestanding
 applications with a new toolchain, so we have to provide our own CRT.
 
 p.s.
 Without the CRT we won't see any build errors (since the purgatory is
 linked with --no-undefined), but the purgatory code won't work,
 'kexec -e' will just hang the board.
 
 
 I added option to configure to keep code buildable for old toolchais.
 But there should be way to do this automatically.

I seem to have an old toolchain :-)

 Author: Anton Vorontsov avoront...@ru.mvista.com
 Signed-off-by: Maxim Uvarov muva...@gmail.com
 Signed-off-by: Maxim Uvarov muva...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[patch] ppc: Fix gamecube build

[Simon Horman]

This fixes the kexec-build on ppc32 when
the --game-cube option is supplied to ./configure.
It seems to have bit-rotted a little.

Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Maxim Uvarov muva...@gmail.com
Signed-off-by: Simon Horman ho...@verge.net.au

Index: kexec-tools/kexec/arch/ppc/kexec-elf-ppc.c
===
--- kexec-tools.orig/kexec/arch/ppc/kexec-elf-ppc.c 2010-05-14 
00:18:25.0 +0900
+++ kexec-tools/kexec/arch/ppc/kexec-elf-ppc.c  2010-05-14 00:20:58.0 
+0900
@@ -162,17 +162,9 @@ int elf_ppc_load(int argc, char **argv,
unsigned long max_addr, hole_addr;
struct mem_phdr *phdr;
size_t size;
-   unsigned long long *rsvmap_ptr;
-   struct bootblock *bb_ptr;
-   unsigned int nr_segments;
-   unsigned long my_kernel, my_dt_offset;
-   unsigned long my_stack, my_backup_start;
 #ifdef CONFIG_PPC64
unsigned long toc_addr;
 #endif
-   unsigned int slave_code[256 / sizeof(unsigned int)], master_entry;
-   unsigned char *seg_buf = NULL;
-   off_t seg_size = 0;
 #ifdef WITH_GAMECUBE
int target_is_gamecube = 1;
char *arg_buf;
@@ -183,13 +175,21 @@ int elf_ppc_load(int argc, char **argv,
unsigned char *setup_start;
uint32_t setup_size;
 #else
+   unsigned long long *rsvmap_ptr;
+   struct bootblock *bb_ptr;
+   unsigned int nr_segments;
+   unsigned long my_kernel, my_dt_offset;
+   unsigned long my_stack, my_backup_start;
+   unsigned int slave_code[256 / sizeof(unsigned int)], master_entry;
+   unsigned char *seg_buf = NULL;
+   off_t seg_size = 0;
int target_is_gamecube = 0;
unsigned int addr;
unsigned long dtb_addr;
+#endif
 #define FIXUP_ENTRYS   (20)
char *fixup_nodes[FIXUP_ENTRYS + 1];
int cur_fixup = 0;
-#endif
int opt;
 
command_line = NULL;
Index: kexec-tools/kexec/arch/ppc/kexec-ppc.c
===
--- kexec-tools.orig/kexec/arch/ppc/kexec-ppc.c 2010-05-14 00:18:25.0 
+0900
+++ kexec-tools/kexec/arch/ppc/kexec-ppc.c  2010-05-14 00:20:58.0 
+0900
@@ -26,6 +26,11 @@
 
 #include config.h
 
+uint64_t rmo_top;
+unsigned long long crash_base, crash_size;
+unsigned int rtas_base, rtas_size;
+int max_memory_ranges;
+
 #ifdef WITH_GAMECUBE
 #define MAX_MEMORY_RANGES  64
 static struct memory_range memory_range[MAX_MEMORY_RANGES];
@@ -46,15 +51,11 @@ static int get_memory_ranges_gc(struct m
 }
 #else
 static int use_new_dtb;
-int max_memory_ranges;
 static int nr_memory_ranges, nr_exclude_ranges;
 static struct memory_range *exclude_range;
 static struct memory_range *memory_range;
 static struct memory_range *base_memory_range;
 static uint64_t memory_max;
-uint64_t rmo_top;
-unsigned long long crash_base, crash_size;
-unsigned int rtas_base, rtas_size;
 
 /*
  * Count the memory nodes under /proc/device-tree and populate the
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] Fix kexec on powerpc32

[Simon Horman]

On Wed, May 12, 2010 at 10:31:26AM +0400, Maxim Uvarov wrote:
 2010/5/12 Christian Kujau li...@nerdbynature.de
 
  Maxim Uvarov wrote on 2010-05-11 10:47 :
   This patch is required in case if you are using new toolchains.
 
  I'm on Debian/stable (binutils 2.18, gcc 4.3.2), so I applied your patches
  to the latest -git checkout:
 
  First, compilation fails with:
 
  cc1: warnings being treated as errors
  kexec/arch/ppc/kexec-ppc.c: In function ‘get_base_ranges’:
  kexec/arch/ppc/kexec-ppc.c:258: error: value computed is not used
  make: *** [kexec/arch/ppc/kexec-ppc.o] Error 1
 
  Somehow a - hyphen made it into one of the functions:
 
   --- a/kexec/arch/ppc/kexec-ppc.c
   +++ b/kexec/arch/ppc/kexec-ppc.c
  [...]
 if (local_memory_ranges = max_memory_ranges) {
   - fclose(file);
   - break;
   + if (realloc_memory_ranges()  0){
   + -   fclose(file);
 
  Oh, I sent this patch twice with stg -a by mistake. And second version has
 -. I will fix and resend patches.
 
 
  Removing this, gets me further, until:
 
 
  purgatory/arch/ppc/crt.o: In function `__lshrdi3':
  (.text+0xf0): multiple definition of `__lshrdi3'
  purgatory/arch/ppc/misc.o:(.text+0x50): first defined here
  collect2: ld returned 1 exit status
  make: *** [purgatory/purgatory.ro] Error 1
 
  And has been defined in purgatory/arch/ppc/crt.S and
  ./purgatory/arch/ppc/misc.S. Removing it from e.g. crt.S
  makes it compile, I have not tested it yet, though :-)
 
 
 Yes, that is expected result for old tool chains. New tool chains (from code
 sourcery )  need this crt.S.
 I think we can have --with-oldtoolchain option to configure to point to old
 tool chains. (or even rename it to --with-crts,
 I don't know what is better.)

I think --with-crts would be better as --with-oldtoolchain could
mean many things.

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

Re: [PATCH] kexec-tools, ppc64: Fix segfault on parsing of large device trees.

[Simon Horman]

On Mon, May 10, 2010 at 02:55:03PM +1000, Michael Neuling wrote:
 
 
 In message 4be78e06.6080...@ozlabs.org you wrote:
  
  ppc64's fs2dt used to use a fixed-size array into which the device tree
  was parsed.  There was no bounds checking, so with a large device tree other
  heap data ended up getting stomped -- SIGSEGV time.
  
  This patch adds a function, 'dt_reserve', to check whether there's enough 
  spa
 ce
  left prior to writing data to the array.  If not, the array is realloced.
  
  Signed-off-by: Matt Evans m...@ozlabs.org
 
 FWIW...
 
 Ack-by: Michael Neuling mi...@neuling.org
 
 (also added linuxppc-...@ozlabs.org to CC list)

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

Re: [PATCH] kexec-tools, ppc64: fix build error on ppc64

[Simon Horman]

On Wed, May 05, 2010 at 11:46:25AM +0400, Maxim Uvarov wrote:
 2010/5/5 Simon Horman ho...@verge.net.au
 
  On Wed, May 05, 2010 at 01:35:21PM +1000, Michael Neuling wrote:
  
  
   In message 20100505023316.gf13...@verge.net.au you wrote:
On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote:
 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 some kexec MIPS
 improvements broke pp64 as it turned on -Werror for all archs.

 This fixes the warning and hence ppc64 building.
   
Thanks.
   
While I'm very much in favour of using -Werror for testing
and these kind of patches are great, I think that -Werror
by default is rather silly. We can't control what will be
a warning in the future and sometimes fixing warnings isn't
appropriate - for instance there are warnings in fs2dt.c at
the moment, that is currently considered an upstream problem.
   
In short, this patch is great. But I plan to also remove -Werror
as the default now that its been brought to my attention.
  
   Cool.  My second patch should do this for all but MIPS.
 
  Unfortunately the second patch breaks make tarball.
  For now I have committed the following:
 
  From 76beff0507360f3001e23c9b4c765ef56384d5d5 Mon Sep 17 00:00:00 2001
  From: Simon Horman ho...@verge.net.au
  Date: Wed, 5 May 2010 13:33:21 +1000
  Subject: [PATCH] build: Don't modify CFLAGS in kexec/arch/mips/Makefile
 
  Revert this portion of recent MIPS changes as it actually effects the
  CFLAGS for all architectures.  Moreover I'm somewhat dubious about
  defaulting to -Werror for any architecture.
 
  Signed-off-by: Simon Horman ho...@verge.net.au
  ---
   kexec/arch/mips/Makefile |2 --
   1 files changed, 0 insertions(+), 2 deletions(-)
 
  diff --git a/kexec/arch/mips/Makefile b/kexec/arch/mips/Makefile
  index 831b263..03bdb9a 100644
  --- a/kexec/arch/mips/Makefile
  +++ b/kexec/arch/mips/Makefile
  @@ -14,5 +14,3 @@ dist += kexec/arch/mips/Makefile $(mips_KEXEC_SRCS)
  \
 kexec/arch/mips/kexec-mips.h\
 kexec/arch/mips/crashdump-mips.h\
 kexec/arch/mips/include/arch/options.h
  -
  -CFLAGS +=-Wall -Werror
  --
  1.7.1
 
 
 Plan was to have -Werror only for mips. Thanks for fixes.

No problem, I should have noticed this earlier.

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

Re: [PATCH] kexec-tools, ppc64: fix build error on ppc64

[Simon Horman]

On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote:
 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 some kexec MIPS
 improvements broke pp64 as it turned on -Werror for all archs.
 
 This fixes the warning and hence ppc64 building.

Thanks.

While I'm very much in favour of using -Werror for testing
and these kind of patches are great, I think that -Werror
by default is rather silly. We can't control what will be
a warning in the future and sometimes fixing warnings isn't
appropriate - for instance there are warnings in fs2dt.c at
the moment, that is currently considered an upstream problem.

In short, this patch is great. But I plan to also remove -Werror
as the default now that its been brought to my attention.

 
 Signed-off-by: Michael Neuling mi...@neuling.org
 ---
 I've posted a second patch to fix the issue of changing one archs
 Makefile, effecting all other archs.
 
  kexec/arch/ppc64/fs2dt.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 Index: kexec-tools/kexec/arch/ppc64/fs2dt.c
 ===
 --- kexec-tools.orig/kexec/arch/ppc64/fs2dt.c
 +++ kexec-tools/kexec/arch/ppc64/fs2dt.c
 @@ -357,7 +357,8 @@ static void putprops(char *fn, struct di
   * Compare function used to sort the device-tree directories
   * This function will be passed to scandir.
   */
 -static int comparefunc(const void *dentry1, const void *dentry2)
 +static int comparefunc(const struct dirent **dentry1,
 +const struct dirent **dentry2)
  {
   char *str1 = (*(struct dirent **)dentry1)-d_name;
   char *str2 = (*(struct dirent **)dentry2)-d_name;
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] kexec-tools, ppc64: fix build error on ppc64

[Simon Horman]

On Wed, May 05, 2010 at 01:35:21PM +1000, Michael Neuling wrote:
 
 
 In message 20100505023316.gf13...@verge.net.au you wrote:
  On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote:
   6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 some kexec MIPS
   improvements broke pp64 as it turned on -Werror for all archs.
   
   This fixes the warning and hence ppc64 building.
  
  Thanks.
  
  While I'm very much in favour of using -Werror for testing
  and these kind of patches are great, I think that -Werror
  by default is rather silly. We can't control what will be
  a warning in the future and sometimes fixing warnings isn't
  appropriate - for instance there are warnings in fs2dt.c at
  the moment, that is currently considered an upstream problem.
  
  In short, this patch is great. But I plan to also remove -Werror
  as the default now that its been brought to my attention.
 
 Cool.  My second patch should do this for all but MIPS.

Unfortunately the second patch breaks make tarball.
For now I have committed the following:

From 76beff0507360f3001e23c9b4c765ef56384d5d5 Mon Sep 17 00:00:00 2001
From: Simon Horman ho...@verge.net.au
Date: Wed, 5 May 2010 13:33:21 +1000
Subject: [PATCH] build: Don't modify CFLAGS in kexec/arch/mips/Makefile

Revert this portion of recent MIPS changes as it actually effects the
CFLAGS for all architectures.  Moreover I'm somewhat dubious about
defaulting to -Werror for any architecture.

Signed-off-by: Simon Horman ho...@verge.net.au
---
 kexec/arch/mips/Makefile |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/mips/Makefile b/kexec/arch/mips/Makefile
index 831b263..03bdb9a 100644
--- a/kexec/arch/mips/Makefile
+++ b/kexec/arch/mips/Makefile
@@ -14,5 +14,3 @@ dist += kexec/arch/mips/Makefile $(mips_KEXEC_SRCS)   
\
kexec/arch/mips/kexec-mips.h\
kexec/arch/mips/crashdump-mips.h\
kexec/arch/mips/include/arch/options.h
-
-CFLAGS +=-Wall -Werror
-- 
1.7.1

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

Re: [PATCH] Reserve memory for kdump kernel within RMO region

[Simon Horman]

On Fri, Nov 27, 2009 at 02:05:46PM +0530, M. Mohan Kumar wrote:
 On 11/27/2009 12:56 AM, Bernhard Walle wrote:
 M. Mohan Kumar schrieb:
 On 11/26/2009 12:22 AM, Bernhard Walle wrote:
 M. Mohan Kumar schrieb:
 Reserve memory for kdump kernel within RMO region
 
 When the kernel size exceeds 32MB(observed with some distros), memory
 for kdump kernel can not be reserved as kdump kernel base is assumed to
 be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
 provide the feature to reserve the memory for kdump kernel anywhere in
 the RMO region.
 
 Hi Bernhard,
 
 Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
 gets loaded as crashkernel, not for the kernel that loads the
 crashkernel. So it would be perfectly fine that a kernel that has not
 CONFIG_RELOCATABLE set would load another kernel that has
 CONFIG_RELOCATABLE set on an address != 32 M.
 
 No, with relocatable option, the same kernel is used as both production
 and kdump kernel.
 
 Can be, but it's not strictly necessary. It depends what userland does.
 Especially it's possible that a non-relocatable, self-compiled kernel
 loads a relocatable distribution kernel as capture kernel.
 
 
 I don't understand why a non-relocatable kernel will use relocatable
 kernel for capturing kdump kernel. The idea for relocatable kernel
 is to avoid using two different kernels to capture kernel dump.

True, but that doesn't necessarily mean that using a relocatable
kdump kernel is required. Well, hopefully not.

 Also, it would make sense to make the behaviour symmetric across
 platforms. Currently we have:
 
   - x86 and ia64: Without offset on command line, use any offset
   With offset on command line, use that offset and fail
   if no memory is available at that offset.
   - ppc64: Always use 32M and ignore the offset.
 
 If your patch gets applied, we have:
 
   - ppc64: With CONFIG_RELOCATABLE, use any offset
With offset on command
 
 I don't see why the behaviour on ppc64 should be completely different.
 
 Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the
 past, I always felt that ppc64 is more different from x86 than ia64 is
 from x86. That's one more step into that direction without a technical
 reason.
 
 Also with the crashkernel=auto parameter (patches are not yet
 merged), the crashkernel base (offset) by default would be 32MB. In
 this case if a kernel passed with crashkernel=auto and if the first
 kernel size exceeds 32MB, memory for kdump kernel will always fail.
 
 
 Having that all said: If your patch gets in mainline kernel, than we
 should change the behaviour also for x86 and ia64.
 
 
 
 Regards,
 Bernhard
 
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Write to HVC terminal from purgatory cod

[Simon Horman]

On Fri, Oct 16, 2009 at 11:56:02AM +0530, M. Mohan Kumar wrote:
 [PATCH] Write to HVC terminal from purgatory code
 
 Current x86/x86-64 kexec-tools print the message I'm in purgatory to serial
 console/VGA while executing the purgatory code.  Implement this feature for
 POWERPC pseries platform by using the H_PUT_TERM_CHAR hypervisor call by
 printng to hvc console.
 
 Includes the changes suggested by Michael Ellerman

Sorry for the long delay, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC] [PATCH] Write to HVC terminal from purgatory code

[Simon Horman]

On Mon, Sep 07, 2009 at 10:44:07AM +0530, M. Mohan Kumar wrote:
 Write to HVC terminal from purgatory code
 
 Current x86/x86-64 kexec-tools print the message I'm in purgatory to
 serial console/VGA while executing the purgatory code.  Implement this
 feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR
 hypervisor call by printng to hvc console.

This change seems reasonable to me, can any of the ppc people offer a review?

 Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
 ---
  kexec/arch/ppc64/fs2dt.c   |   47 
 +++-
  kexec/arch/ppc64/kexec-elf-ppc64.c |7 +
  kexec/arch/ppc64/kexec-ppc64.h |1 +
  purgatory/arch/ppc64/Makefile  |1 +
  purgatory/arch/ppc64/console-ppc64.c   |   14 +
  purgatory/arch/ppc64/hvCall.S  |   28 +++
  purgatory/arch/ppc64/hvCall.h  |8 +
  purgatory/arch/ppc64/purgatory-ppc64.c |1 +
  8 files changed, 106 insertions(+), 1 deletions(-)
  create mode 100644 purgatory/arch/ppc64/hvCall.S
  create mode 100644 purgatory/arch/ppc64/hvCall.h
 
 diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
 index b01ff86..bd9d36c 100644
 --- a/kexec/arch/ppc64/fs2dt.c
 +++ b/kexec/arch/ppc64/fs2dt.c
 @@ -434,6 +434,9 @@ static void putnode(void)
   if (!strcmp(basename,/chosen/)) {
   size_t cmd_len = 0;
   char *param = NULL;
 + char filename[MAXPATH];
 + char buff[64];

Is always 64 big enough?
It seems a bit arbitrary.

 + int fd;
  
   cmd_len = strlen(local_cmdline);
   if (cmd_len != 0) {
 @@ -446,7 +449,6 @@ static void putnode(void)
  
   /* ... if not, grab root= from the old command line */
   if (!param) {
 - char filename[MAXPATH];
   FILE *fp;
   char *last_cmdline = NULL;
   char *old_param;
 @@ -483,8 +485,51 @@ static void putnode(void)
   dt += (cmd_len + 3)/4;
  
   fprintf(stderr, Modified cmdline:%s\n, local_cmdline);
 +
 + /*
 +  * Determine the platform type/stdout type, so that purgatory
 +  * code can print 'I'm in purgatory' message. Currently only
 +  * pseries/hvcterminal is supported.
 +  */
 + strcpy(filename, pathname);
 + strcat(filename, linux,stdout-path);
 + fd = open(filename, O_RDONLY);
 + if (fd == -1) {
 + printf(Unable to find linux,stdout-path, printing
 +  from purgatory is diabled\n);
 + goto no_debug;
 + }
 + if (fstat(fd, statbuf)) {
 + printf(Unable to stat linux,stdout-path, printing
 +  from purgatory is diabled\n);
 + close(fd);
 + goto no_debug;
 + }
 + read(fd, buff, statbuf.st_size);
 + close(fd);
 + strcpy(filename, /proc/device-tree/);
 + strcat(filename, buff);
 + strcat(filename, /compatible);
 + fd = open(filename, O_RDONLY);
 + if (fd == -1) {
 + printf(Unable to find linux,stdout-path/compatible, 
 +  printing from purgatory is diabled\n);
 + goto no_debug;
 + }
 + if (fstat(fd, statbuf)) {
 + printf(Unable to stat linux,stdout-path/compatible, 
 +  printing from purgatory is diabled\n);
 + close(fd);
 + goto no_debug;
 + }
 + read(fd, buff, statbuf.st_size);
 + if (!strcmp(buff, hvterm1) ||
 + !strcmp(buff, hvterm-protocol))
 + my_debug = 1;
 + close(fd);
   }
  
 +no_debug:
   for (i=0; i  numlist; i++) {
   dp = namelist[i];
   strcpy(dn, dp-d_name);
 diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c 
 b/kexec/arch/ppc64/kexec-elf-ppc64.c
 index 21533cb..65fc42f 100644
 --- a/kexec/arch/ppc64/kexec-elf-ppc64.c
 +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
 @@ -41,6 +41,8 @@
  uint64_t initrd_base, initrd_size;
  unsigned char reuse_initrd = 0;
  const char *ramdisk;
 +/* Used for enabling printing message from purgatory code */
 +int my_debug = 0;
  
  int elf_ppc64_probe(const char *buf, off_t len)
  {
 @@ -296,6 +298,8 @@ int elf_ppc64_load(int argc, char **argv, const char 
 *buf, off_t len,
   toc_addr = my_r2(info-rhdr);
   elf_rel_set_symbol(info-rhdr, my_toc, toc_addr, sizeof(toc_addr));
  
 + /* Set debug */
 + elf_rel_set_symbol(info-rhdr, debug, my_debug, sizeof(my_debug));
  #ifdef DEBUG
   my_kernel = 0;
   

Re: [PATCH 2/2] Support R_PPC64_REL32 relocation type

[Simon Horman]

On Mon, Aug 10, 2009 at 07:44:42PM +0530, M. Mohan Kumar wrote:
 [PATCH 2/2] Support R_PPC64_REL32 relocation type
 
 gcc-4.4 compiler creates R_PPC64_REL32 relocation type in the ppc64
 purgatory code. Add support to handle R_PPC64_REL32 relocation type.
 
 Signed-off-by: M. Mohan Kumar mo...@in.ibm.com

Thanks, applied this one too.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] Make dtstruct variable to be 8 byte aligned

[Simon Horman]

On Mon, Aug 10, 2009 at 07:43:51PM +0530, M. Mohan Kumar wrote:
 [PATCH 1/2] Make dtstruct variable to be 8 byte aligned
 
 kexec is creating a version 3 device tree to be backwards compatible. This
 version of the struct has 8-byte alignment for properties whose value is 8 or
 more bytes. As the code directly checks the pointer when deciding to add the
 alignment word, the struct memory must start on an 8 byte boundary. Force the
 dtstruct variable to be always 8 bytes aligned.
 
 Signed-off-by: M. Mohan Kumar mo...@in.ibm.com

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

Re: [PATCH] Do not inline putprops function

[Simon Horman]

On Wed, Jun 17, 2009 at 05:04:56PM +0530, M. Mohan Kumar wrote:
 Do not inline putprops function
 
 With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
 kexec -l and kexec -p respectively). This happened after the patch ppc64:
 cleanups commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
 reverting each hunk and then found out that retaining following lines in
 fs2dt.c makes kexec/kdump work.
 
 -static unsigned *dt_len; /* changed len of modified cmdline
 -   in flat device-tree */
 
 []
 
 -   dt_len = dt;
 
 I don't have any clue why removing a unused variable would cause the kexec
 kernel to hang. After further investigation, I observed that if the putprops
 function is not inlined, kexec/kdump kernel would work even after removing
 the above lines.
 
 This patch directs gcc to not inline the putprops function. Now we could
 invoke kexec and kdump kernels.

I'm happy to apply this if you provide a sign-off,
but do you know why not inlining makes a difference here?

 ---
  kexec/arch/ppc64/fs2dt.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
 index 1f551fd..1e01f74 100644
 --- a/kexec/arch/ppc64/fs2dt.c
 +++ b/kexec/arch/ppc64/fs2dt.c
 @@ -259,7 +259,7 @@ static void add_usable_mem_property(int fd, int len)
  }
  
  /* put all properties (files) in the property structure */
 -static void putprops(char *fn, struct dirent **nlist, int numlist)
 +__attribute__ ((noinline)) static void putprops(char *fn, struct dirent 
 **nlist, int numlist)
  {
   struct dirent *dp;
   int i = 0, fd, len;
 -- 
 1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch] Possible fix for kexec-tools dynamic range allocation

[Simon Horman]

On Wed, Jan 07, 2009 at 05:01:26PM +1100, Michael Ellerman wrote:
 Hi all,
 
 The patch to dynamically allocate memory regions for ppc64 kexec-tools,
 ie. ppc64: kexec memory ranges dynamic allocation (d182ce5), has never
 worked AFAICT.
 
 Chandru reported it as broken when it was posted:
 http://lists.infradead.org/pipermail/kexec/2008-October/002751.html
 
 Still, it's in now, and I'm trying to work out what's going wrong.
 
 The symptom is as reported by Chandru, we end up not being able to
 allocate any memory (in locate_hole()). This is caused by the list of
 memory_ranges being empty.
 
 The memory_ranges are empty because they have been realloc'ed (by the
 dynamic alloc code), and the generic code is still looking at the old
 version.
 
 What I'm not clear on is why the ppc64 code is even calling
 setup_memory_ranges() a second time (in elf_ppc64_load()). It's already
 been called by get_memory_ranges() from my_load(). Or is there another
 route into elf_ppc64_load() that I'm not seeing?
 
 And in fact if I just remove that call, then everything is peachy.
 
 The following patch makes it work for me at least.

Hi Michael,

I must confess that I don't have a complete understanding of this problem.
Does Bernhard's recent patch (sorry that I applied it even though
it came in after your patch) help this problem?

commit 95c74405638c786bc76fbca5e4e8427dfe26e907
Author: Bernhard Walle bwa...@suse.de
Date:   Fri Jan 16 19:11:34 2009 +0100
Subject: Fix memory corruption when using realloc_memory_ranges()

 From 40958d8f957876ca612b666f40bebf28ea335314 Mon Sep 17 00:00:00 2001
 From: Michael Ellerman mich...@ellerman.id.au
 Date: Wed, 7 Jan 2009 16:57:05 +1100
 Subject: [PATCH] Don't call setup_memory_ranges() again
 
 There's no need to call setup_memory_ranges() again. Furthermore it can
 lead to the memory_ranges being realloc'ed, which results in the generic
 code (locate_hole() etc.) using the free'd memory_ranges.
 
 Signed-off-by: Michael Ellerman mich...@ellerman.id.au
 ---
  kexec/arch/ppc64/kexec-elf-ppc64.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)
 
 diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c 
 b/kexec/arch/ppc64/kexec-elf-ppc64.c
 index 21533cb..1e2d5a3 100644
 --- a/kexec/arch/ppc64/kexec-elf-ppc64.c
 +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
 @@ -151,8 +151,6 @@ int elf_ppc64_load(int argc, char **argv, const char 
 *buf, off_t len,
   if (ramdisk  reuse_initrd)
   die(Can't specify --ramdisk or --initrd with --reuseinitrd\n);
  
 - setup_memory_ranges(info-kexec_flags);
 -
   /* Need to append some command line parameters internally in case of
* taking crash dumps.
*/
 -- 
 1.5.3.7.1.g4e596e
 
 

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH 0/5 + 2] kexec updates

[Simon Horman]

On Tue, Jan 13, 2009 at 09:59:08AM -0600, Milton Miller wrote:
 On Jan 12, 2009, at 12:24 AM, Simon Horman wrote:
 On Fri, Jan 02, 2009 at 02:42:38PM -0600, Milton Miller wrote:
 Follwing this mail are 5 patches for kexec userspace and two for the
 kernel.  The first fixes an array overflow and the second updates
 userspace to the merged 2.6.28 kdump support.  The remaining are
 cleanups and warning fixes, including one for the common code.

 The two patchs for the kernel are independent.

 Hi all,

 sorry to be a bit slow in responding, this email landed just
 as I was leaving for a weeks holiday.


 No problem, I figured as much.

 The kexec-tools patches seem reasonable to me and I'm happy to merge  
 what I
 think are the latest versions - thanks Michael for your review.

 Milton, here are the Subjects, Dates and Message-Ids of what I have in  
 my
 queue.  If you could confirm this or repost that would be great.

 #1
 Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges  
 when adding them
 Date: Thu, 08 Jan 2009 06:33:50 -0600
 Message-ID: 1231418030_141...@mercury.realtime.net

 #2
 Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28  
 relocatable kernel
 Date: Fri, 02 Jan 2009 15:04:42 -0600
 Message-Id: kexec-29-1-2r.milt...@bga.com

 #3
 Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered
 Date: Fri, 02 Jan 2009 15:04:45 -0600
 Message-Id: kexec-29-1-3r.milt...@bga.com

 #4
 Subject: [PATCH kexec-tools 4/5] ppc64: cleanups
 Date: Fri, 02 Jan 2009 15:04:48 -0600
 Message-Id: kexec-29-1-4r.milt...@bga.com

 #5
 Subject: [PATCH kexec-tools 5/5] entry wants to be void *
 Date: Fri, 02 Jan 2009 15:04:51 -0600
 Message-Id: kexec-29-1-5r.milt...@bga.com

 Based on the subjects, yes, those are the lastest versions.

 And I assume you saw Mohan's tested message.

Thanks. I've added a Tested-by: M. Mohan Kumar mo...@in.ibm.com tag
to each of the five patches and applied them.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH 0/5 + 2] kexec updates

[Simon Horman]

On Fri, Jan 02, 2009 at 02:42:38PM -0600, Milton Miller wrote:
 Follwing this mail are 5 patches for kexec userspace and two for the
 kernel.  The first fixes an array overflow and the second updates
 userspace to the merged 2.6.28 kdump support.  The remaining are
 cleanups and warning fixes, including one for the common code.
 
 The two patchs for the kernel are independent.

Hi all,

sorry to be a bit slow in responding, this email landed just
as I was leaving for a weeks holiday.

The kexec-tools patches seem reasonable to me and I'm happy to merge what I
think are the latest versions - thanks Michael for your review.

Milton, here are the Subjects, Dates and Message-Ids of what I have in my
queue.  If you could confirm this or repost that would be great.

#1
Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges when 
adding them
Date: Thu, 08 Jan 2009 06:33:50 -0600
Message-ID: 1231418030_141...@mercury.realtime.net

#2
Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable 
kernel
Date: Fri, 02 Jan 2009 15:04:42 -0600
Message-Id: kexec-29-1-2r.milt...@bga.com

#3
Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered
Date: Fri, 02 Jan 2009 15:04:45 -0600
Message-Id: kexec-29-1-3r.milt...@bga.com

#4
Subject: [PATCH kexec-tools 4/5] ppc64: cleanups
Date: Fri, 02 Jan 2009 15:04:48 -0600
Message-Id: kexec-29-1-4r.milt...@bga.com

#5
Subject: [PATCH kexec-tools 5/5] entry wants to be void *
Date: Fri, 02 Jan 2009 15:04:51 -0600
Message-Id: kexec-29-1-5r.milt...@bga.com

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH] kexec memory ranges dynamic allocation

[Simon Horman]

On Sat, Nov 01, 2008 at 11:43:15AM +0300, Maxim Uvarov wrote:
 2008/11/1 Simon Horman [EMAIL PROTECTED]
 
  On Fri, Oct 31, 2008 at 09:53:23AM +0300, Maxim Uvarov wrote:
   2008/10/31 Simon Horman [EMAIL PROTECTED]
  
Hi,
   
Could someone please comment on the satus of this patch?
   
   Hello,  Simon
  
   I can not reproduce  error which you wrote before on my target. So it is
  a
   little bit
   difficult to say what  was wrong exactly.
 
  Hi,
 
  the version of the patch below (which I think is the latest)
  compiles fine for me. I wanted to confirm that you
  and Chandru are happy for it to be merged.
 
  If so, could you please provide a short descripton for the change-log
  and a Signed-off-by line.
 
 Patch looks good.
 
 Description is:
Do not count  max_memory_range for allocation. Increase allocation
 buffers
when it is needed. This actually allows us to avoid a lot of troubles
 with
various device-tree files.
 
 Signed-off-by: Maxim Uvarov [EMAIL PROTECTED]

Thanks, applied.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH] kexec memory ranges dynamic allocation

[Simon Horman]

On Fri, Oct 31, 2008 at 09:53:23AM +0300, Maxim Uvarov wrote:
 2008/10/31 Simon Horman [EMAIL PROTECTED]
 
  Hi,
 
  Could someone please comment on the satus of this patch?
 
 Hello,  Simon
 
 I can not reproduce  error which you wrote before on my target. So it is a
 little bit
 difficult to say what  was wrong exactly.

Hi,

the version of the patch below (which I think is the latest)
compiles fine for me. I wanted to confirm that you
and Chandru are happy for it to be merged.

If so, could you please provide a short descripton for the change-log
and a Signed-off-by line.

Thanks

  On Wed, Oct 15, 2008 at 12:46:24PM +0400, Maxim Uvarov wrote:
   Patch corrected. ( git_kexec_powerpc_v2.patch is attached.)
  
   I tested it on ppc64 pasemi electra board. Both kexec -l and kexec -p
  works.
  
   Maxim.
 
   diff --git a/kexec/arch/ppc64/kexec-ppc64.c
  b/kexec/arch/ppc64/kexec-ppc64.c
   index 069a9fc..0ad40fa 100644
   --- a/kexec/arch/ppc64/kexec-ppc64.c
   +++ b/kexec/arch/ppc64/kexec-ppc64.c
   @@ -96,96 +96,46 @@ err1:
  
}
  
   -static int count_dyn_reconf_memory_ranges(void)
   +static int realloc_memory_ranges()
{
   - char device_tree[] = /proc/device-tree/;
   - char fname[128];
   - char buf[32];
   - FILE *file;
   -
   - strcpy(fname, device_tree);
   - strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,lmb-size);
   - if ((file = fopen(fname, r)) == NULL) {
   - perror(fname);
   - return -1;
   - }
   + size_t memory_range_len;
  
   - if (fread(buf, 1, 8, file)  0) {
   - perror(fname);
   - fclose(file);
   - return -1;
   - }
   -
   - lmb_size = ((uint64_t *)buf)[0];
   - fclose(file);
   + max_memory_ranges++;
   + memory_range_len = sizeof(struct memory_range) * max_memory_ranges;
  
   - /* Get number of lmbs from ibm,dynamic-memory */
   - strcpy(fname, device_tree);
   - strcat(fname,
  ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory);
   - if ((file = fopen(fname, r)) == NULL) {
   - perror(fname);
   - return -1;
   - }
   - /*
   -  * first 4 bytes provide number of entries(lmbs)
   -  */
   - if (fread(buf, 1, 4, file)  0) {
   - perror(fname);
   - fclose(file);
   - return -1;
   - }
   - num_of_lmbs = ((unsigned int *)buf)[0];
   - max_memory_ranges += num_of_lmbs;
   - fclose(file);
   + memory_range = (struct memory_range *) realloc(memory_range,
  memory_range_len);
   + if (!memory_range)
   + goto err;
  
   - return 0;
   -}
   + base_memory_range = (struct memory_range *) realloc(memory_range,
  memory_range_len);
   + if (!base_memory_range)
   + goto err;
  
   -/*
   - * Count the memory nodes under /proc/device-tree and populate the
   - * max_memory_ranges variable. This variable replaces MAX_MEMORY_RANGES
   - * macro used earlier.
   - */
   -static int count_memory_ranges(void)
   -{
   - char device_tree[256] = /proc/device-tree/;
   - struct dirent *dentry;
   - DIR *dir;
   + exclude_range = (struct memory_range *) realloc(exclude_range,
  memory_range_len);
   + if (!exclude_range)
   + goto err;
  
   - if ((dir = opendir(device_tree)) == NULL) {
   - perror(device_tree);
   - return -1;
   - }
   + usablemem_rgns.ranges = (struct memory_range *)
   + realloc(usablemem_rgns.ranges,
  memory_range_len);
   + if (!(usablemem_rgns.ranges))
   + goto err;
  
   - while ((dentry = readdir(dir)) != NULL) {
   - if (!strncmp(dentry-d_name,
   - ibm,dynamic-reconfiguration-memory, 35)){
   - if (count_dyn_reconf_memory_ranges() != 0)
   - return -1;
   - continue;
   - }
   + return 0;
  
   - if (strncmp(dentry-d_name, memory@, 7) 
   - strcmp(dentry-d_name, memory) 
   - strncmp(dentry-d_name, pci@, 4))
   - continue;
   - max_memory_ranges++;
   - }
   - /* need to add extra region for retained initrd */
   - if (reuse_initrd) {
   - max_memory_ranges++;
   - }
   +err:
   + fprintf(stderr, memory range structure re-allocation failure\n);
   + return -1;
   +}
  
   - closedir(dir);
  
   - return 0;
   -}
static void add_base_memory_range(uint64_t start, uint64_t end)
{
 base_memory_range[nr_memory_ranges].start = start;
 base_memory_range[nr_memory_ranges].end  = end;
 base_memory_range[nr_memory_ranges].type = RANGE_RAM;
 nr_memory_ranges++;
   + if (nr_memory_ranges = max_memory_ranges)
   + realloc_memory_ranges();
  
 dbgprintf(%016llx

Re: [PATCH] kexec memory ranges dynamic allocation

[Simon Horman]

Hi,

Could someone please comment on the satus of this patch?

On Wed, Oct 15, 2008 at 12:46:24PM +0400, Maxim Uvarov wrote:
 Patch corrected. ( git_kexec_powerpc_v2.patch is attached.)
 
 I tested it on ppc64 pasemi electra board. Both kexec -l and kexec -p works.
 
 Maxim.
 
 
 
 2008/10/15 Simon Horman [EMAIL PROTECTED]
 
  On Tue, Oct 14, 2008 at 07:11:19PM +0400, Maxim Uvarov wrote:
   Hello all,
  
   As you all know it is not easy to count exact value of memory ranges from
   device tree on powerpc.
   It very depends on how dts file was written. What do you think about
  really
   dynamic allocation buffers
   for this buffers?
 
  Conceptually I have no objections to the change,
  though I would like to get some review from ppc people.
  (linuxppc-dev@ozlabs.org CCed)
 
   Patch is attached.
 
  This patch doesn't seem to compile for me.
 
  # powerpc64-unknown-linux-gnu-gcc --version
  powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.1
  Copyright (C) 2006 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
  #make
  [snip]
  kexec/arch/ppc64/kexec-ppc64.c:100: warning: function declaration isn't a
  prototype
  kexec/arch/ppc64/kexec-ppc64.c: In function 'realloc_memory_ranges':
  kexec/arch/ppc64/kexec-ppc64.c:107: warning: passing argument 1 of
  'realloc' makes pointer from integer without a cast
  kexec/arch/ppc64/kexec-ppc64.c:107: error: too few arguments to function
  'realloc'
  kexec/arch/ppc64/kexec-ppc64.c:102: warning: unused variable 'tmp'
 
  --
  Simon Horman
   VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
   H: www.vergenet.net/~horms/ http://www.vergenet.net/%7Ehorms/
W: www.valinux.co.jp/en
 
 
 
 
 -- 
 Best regards,
 Maxim Uvarov

 diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
 index 069a9fc..0ad40fa 100644
 --- a/kexec/arch/ppc64/kexec-ppc64.c
 +++ b/kexec/arch/ppc64/kexec-ppc64.c
 @@ -96,96 +96,46 @@ err1:
  
  }
  
 -static int count_dyn_reconf_memory_ranges(void)
 +static int realloc_memory_ranges()
  {
 - char device_tree[] = /proc/device-tree/;
 - char fname[128];
 - char buf[32];
 - FILE *file;
 -
 - strcpy(fname, device_tree);
 - strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,lmb-size);
 - if ((file = fopen(fname, r)) == NULL) {
 - perror(fname);
 - return -1;
 - }
 + size_t memory_range_len;
  
 - if (fread(buf, 1, 8, file)  0) {
 - perror(fname);
 - fclose(file);
 - return -1;
 - }
 -
 - lmb_size = ((uint64_t *)buf)[0];
 - fclose(file);
 + max_memory_ranges++;
 + memory_range_len = sizeof(struct memory_range) * max_memory_ranges;
  
 - /* Get number of lmbs from ibm,dynamic-memory */
 - strcpy(fname, device_tree);
 - strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory);
 - if ((file = fopen(fname, r)) == NULL) {
 - perror(fname);
 - return -1;
 - }
 - /*
 -  * first 4 bytes provide number of entries(lmbs)
 -  */
 - if (fread(buf, 1, 4, file)  0) {
 - perror(fname);
 - fclose(file);
 - return -1;
 - }
 - num_of_lmbs = ((unsigned int *)buf)[0];
 - max_memory_ranges += num_of_lmbs;
 - fclose(file);
 + memory_range = (struct memory_range *) realloc(memory_range, 
 memory_range_len);
 + if (!memory_range)
 + goto err;
  
 - return 0;
 -}
 + base_memory_range = (struct memory_range *) realloc(memory_range, 
 memory_range_len);
 + if (!base_memory_range)
 + goto err;
  
 -/*
 - * Count the memory nodes under /proc/device-tree and populate the
 - * max_memory_ranges variable. This variable replaces MAX_MEMORY_RANGES
 - * macro used earlier.
 - */
 -static int count_memory_ranges(void)
 -{
 - char device_tree[256] = /proc/device-tree/;
 - struct dirent *dentry;
 - DIR *dir;
 + exclude_range = (struct memory_range *) realloc(exclude_range, 
 memory_range_len);
 + if (!exclude_range)
 + goto err;
  
 - if ((dir = opendir(device_tree)) == NULL) {
 - perror(device_tree);
 - return -1;
 - }
 + usablemem_rgns.ranges = (struct memory_range *)
 + realloc(usablemem_rgns.ranges, 
 memory_range_len);
 + if (!(usablemem_rgns.ranges))
 + goto err;
  
 - while ((dentry = readdir(dir)) != NULL) {
 - if (!strncmp(dentry-d_name,
 - ibm,dynamic-reconfiguration-memory, 35)){
 - if (count_dyn_reconf_memory_ranges() != 0)
 - return -1;
 - continue;
 - }
 + return 0;
  
 - if (strncmp(dentry-d_name, memory@, 7) 
 - strcmp(dentry-d_name, memory

Re: [PATCH 1/3] powerpc: kexec exit should not use magic numbers

[Simon Horman]

[ Added Mohan Kumar to CC list ]

On Wed, Oct 22, 2008 at 03:39:18PM -0500, Milton Miller wrote:
 The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246)
 added a magic flag value in a register to tell purgatory that it should
 be a panic kernel.  This part is wrong and is reverted by this patch.
 
 The kernel gets a list of memory blocks and a entry point from user space.
 Its job is to copy the blocks into place and then branch to the designated
 entry point (after turning off the mmu).
 
 The user space tool inserts a trampoline, called purgatory, that runs
 before the user supplied code.   Its job is to establish the entry
 environment for the new kernel or other application based on the contents
 of memory.  The purgatory code is compiled and embedded in the tool,
 where it is later patched using the elf symbol table using elf symbols.
 
 Since the tool knows it is creating a purgatory that will run after a
 kernel crash, it should just patch purgatory (or the kernel directly)
 if something needs to happen.

Hi Milton,

All of these patches look fine to me.

On the kernel side:
Acked-by: Simon Horman [EMAIL PROTECTED]

On the kexec-tools side:
I'd rather wait until the kernel changes get merged before merging
the kexec-tools portion. Please ping me at that point.


I'd like to note that these changes really ought to go into the same kernel
(and kexec-tools) release that the relocateable kdump patches as they will
introduce incompatibility. For example, crash-dump kernels with only the
relocatable kdump changes will not be usable if the first-kernel includes
these changes. I think that means that this needs to go into 2.6.28 -
assuming that Linus accepts the pull request than Ben Herrenschmidt sent
recently.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH] powerpc: dtb and purgatory support for ppc32

[Simon Horman]

On Sun, Oct 12, 2008 at 03:39:55PM +0200, Sebastian Andrzej Siewior wrote:
 * Simon Horman | 2008-10-08 14:03:26 [+1100]:
 
  +#ifdef WITH_GAMECUBE
  +static int go_purgatory = 0;
  +#else
  +static int go_purgatory = 1;
  +#endif
 
 Can you just use WITH_GAMECUBE inside elf_ppc_load() and remove
 the need for go_purgatory, or do you plan to make go_purgatory
 switchable at run-time at some point in the future?

 For the first shot I would prefer to use WITH_GAMECUBE inside of
 elf_ppc_load(). In longterm I don't see any reason why GameCube can't
 use the purgatory code like the other archs and get the memory maps from
 the device tree. However I'm not sure if GameCube still runs on a recent
 kernel: now that arc/ppc isn't available anymore GameCube has to pass a
 dtb somehow and this isn't the case. So therefore I would like the keep
 #ifdef and the exisiting behavior until someone clears this up.

Ok, in this case I would like to request that you remove
go_purgatory (for now) and just use #ifdef WITH_GAMECUBE instead.
I think that it will make things cleaner (for now).

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH] Relocatable kdump kernel support in kexec-tools

[Simon Horman]

On Tue, Sep 30, 2008 at 06:26:21PM +0530, Mohan Kumar M wrote:
 Relocatable kdump kernel support in kexec-tools
 
 This patch adds relocatable kernel support for kdump in the kexec-tools
 code. A signature (0xfeed1234) is passed in r6 from panic code to the
 purgatory code through kexec_sequence function. The signature is used to
 differentiate between relocatable kdump kernel and non-kdump kernels.
 
 The purgatory code compares the signature and sets the __kdump_flag in
 head_64.S by using the offset with respect to next kernel load address.
 During the boot up, kernel code checks __kdump_flag and if it is set, the
 kernel will behave as relocatable kdump kernel.

Thanks Mohan, applied.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH] powerpc: dtb and purgatory support for ppc32

[Simon Horman]

 @@
  #include purgatory.h
  #include purgatory-ppc.h
  
 +unsigned long pul_stack = 0;
 +unsigned long dt_offset = 0;
 +unsigned long kernel = 0;
 +
  void setup_arch(void)
  {
   /* Nothing for now */
 diff --git a/purgatory/arch/ppc/v2wrap.S b/purgatory/arch/ppc/v2wrap.S
 new file mode 100644
 index 000..35803e7
 --- /dev/null
 +++ b/purgatory/arch/ppc/v2wrap.S
 @@ -0,0 +1,54 @@
 +#
 +#  kexec: Linux boots Linux
 +#
 +#  Copyright (C) 2004 - 2005, Milton D Miller II, IBM Corporation
 +#  Copyright (C) 2006, Mohan Kumar M ([EMAIL PROTECTED]), IBM Corporation
 +#  Copyright (C) 2008, Sebastian Andrzej Siewior ([EMAIL PROTECTED]), 
 linutronix
 +#
 +#  This program is free software; you can redistribute it and/or modify
 +#  it under the terms of the GNU General Public License as published by
 +#  the Free Software Foundation (version 2 of the License).
 +#
 +#  This program is distributed in the hope that it will be useful,
 +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
 +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +#  GNU General Public License for more details.
 +#
 +#  You should have received a copy of the GNU General Public License
 +#  along with this program; if not, write to the Free Software
 +#  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 +#
 +
 +#include ppc_asm.h
 +
 +# v2wrap.S
 +# a wrapper to call purgatory code
 +# Invokes ppc kernel with the expected arguments
 +# of kernel(device-tree)
 +
 +# calling convention:
 +#  no register are considred
 +#
 +
 +#define LOADADDR(rn,name)\
 + lis rn,[EMAIL PROTECTED];   \
 + ori rn,rn,[EMAIL PROTECTED];\
 +
 + .globl purgatory_start
 +purgatory_start:
 +
 + LOADADDR(r6,pul_stack)
 +##   lwz r1,0(r6)#setup stack
 +
 + subir1, r1, 112
 + bl  purgatory
 + nop
 +
 + LOADADDR(r6,kernel)
 + lwz r4,0(r6)# load the kernel address
 + mtlrr4  # prepare branch too
 +
 + LOADADDR(r6, dt_offset)
 + lwz r3, 0(r6)   # load device-tree address
 +
 + blr # start kernel
 -- 
 1.5.6.5
 
 
 ___
 kexec mailing list
 [EMAIL PROTECTED]
 http://lists.infradead.org/mailman/listinfo/kexec

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH] powerpc: dtb and purgatory support for ppc32

[Simon Horman]

On Thu, Oct 02, 2008 at 09:50:16AM +0200, Sebastian Siewior wrote:
 Kumar Gala wrote:
 
  are you trying to get this accepted?
 
 If the reviewer don't have any objections yes. You sound
 like there is something terrible wrong. Do you want it in smaller pieces?

I'm not speaking on behalf of Kumar Gala, just on behalf of myself.

I would like to get some review of this patch by if possible.
Also, I'm a little unclear of how it will interact with the
patches that Mohan Kumar sent this week. But at this point
I don't see any particular need to break the patch up into
smaller pieices.


-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH 3/3] ibm_newemac: MAL support for PowerPC 405EZ

[Simon Horman]

On Thu, Sep 04, 2008 at 11:02:16AM -0400, Josh Boyer wrote:
 The PowerPC 405EZ SoC has some differences in the interrupt layout and
 handling for the MAL.  The SERR, TXDE, and RXDE interrupts are OR'd into
 a single interrupt.  Also, due to the possibility for interrupt coalescing,
 the TXEOB and RXEOB interrupts require an interrupt bit to be cleared in
 the ICINTSTAT SDR.
 
 This sets the proper MAL feature bits for 405EZ boards, and adds a common
 shared handler for SERR, TXDE, and RXDE.  This has been adapted from code
 originally written by Stefan Roese.
 
 Signed-off-by: Josh Boyer [EMAIL PROTECTED]
 ---
  drivers/net/ibm_newemac/mal.c |   98 
  1 files changed, 78 insertions(+), 20 deletions(-)
 
 diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
 index 10c267b..3cef534 100644
 --- a/drivers/net/ibm_newemac/mal.c
 +++ b/drivers/net/ibm_newemac/mal.c
 @@ -28,6 +28,7 @@
  #include linux/delay.h
  
  #include core.h
 +#include asm/dcr-regs.h
  
  static int mal_count;
  
 @@ -279,6 +280,9 @@ static irqreturn_t mal_txeob(int irq, void *dev_instance)
   mal_schedule_poll(mal);
   set_mal_dcrn(mal, MAL_TXEOBISR, r);
  
 + if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
 + mtdcri(SDR0, 0x4510, (mfdcri(SDR0, 0x4510) | 0x6000));
 +
   return IRQ_HANDLED;
  }
  
 @@ -293,6 +297,9 @@ static irqreturn_t mal_rxeob(int irq, void *dev_instance)
   mal_schedule_poll(mal);
   set_mal_dcrn(mal, MAL_RXEOBISR, r);
  
 + if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
 + mtdcri(SDR0, 0x4510, (mfdcri(SDR0, 0x4510) | 0x8000));
 +
   return IRQ_HANDLED;
  }
  
 @@ -336,6 +343,25 @@ static irqreturn_t mal_rxde(int irq, void *dev_instance)
   return IRQ_HANDLED;
  }
  
 +static irqreturn_t mal_int(int irq, void *dev_instance)
 +{
 + struct mal_instance *mal = dev_instance;
 + u32 esr = get_mal_dcrn(mal, MAL_ESR);
 +
 + if (esr  MAL_ESR_EVB) {
 + /* descriptor error */
 + if (esr  MAL_ESR_DE) {
 + if (esr  MAL_ESR_CIDT)
 + return (mal_rxde(irq, dev_instance));

Return statements shouldn't be enlosed in brackets according to
checkpatch.pl. Also in a few other places.

 + else
 + return (mal_txde(irq, dev_instance));
 + } else { /* SERR */
 + return (mal_serr(irq, dev_instance));
 + }
 + }
 + return IRQ_HANDLED;
 +}
 +
  void mal_poll_disable(struct mal_instance *mal, struct mal_commac *commac)
  {
   /* Spinlock-type semantics: only one caller disable poll at a time */
 @@ -542,11 +568,22 @@ static int __devinit mal_probe(struct of_device *ofdev,
   goto fail;
   }
  
 - mal-txeob_irq = irq_of_parse_and_map(ofdev-node, 0);
 - mal-rxeob_irq = irq_of_parse_and_map(ofdev-node, 1);
 - mal-serr_irq = irq_of_parse_and_map(ofdev-node, 2);
 - mal-txde_irq = irq_of_parse_and_map(ofdev-node, 3);
 - mal-rxde_irq = irq_of_parse_and_map(ofdev-node, 4);
 + if (of_device_is_compatible(ofdev-node, ibm,mcmal-405ez))
 + mal-features |= (MAL_FTR_CLEAR_ICINTSTAT | 
 MAL_FTR_COMMON_ERR_INT);

The above like is 80 characters wide.
But I'm not sure that anyone cares.

 +
 + if (mal_has_feature(mal, MAL_FTR_COMMON_ERR_INT)) {
 + mal-txeob_irq = irq_of_parse_and_map(ofdev-node, 0);
 + mal-rxeob_irq = irq_of_parse_and_map(ofdev-node, 1);
 + mal-serr_irq = irq_of_parse_and_map(ofdev-node, 2);
 + mal-txde_irq = mal-rxde_irq = mal-serr_irq;
 + } else {
 + mal-txeob_irq = irq_of_parse_and_map(ofdev-node, 0);
 + mal-rxeob_irq = irq_of_parse_and_map(ofdev-node, 1);
 + mal-serr_irq = irq_of_parse_and_map(ofdev-node, 2);
 + mal-txde_irq = irq_of_parse_and_map(ofdev-node, 3);
 + mal-rxde_irq = irq_of_parse_and_map(ofdev-node, 4);
 + }

It seems that that first three calls to irq_of_parse_and_map() could
be moved outside of the if/else clause.

mal-txeob_irq = irq_of_parse_and_map(ofdev-node, 0);
mal-rxeob_irq = irq_of_parse_and_map(ofdev-node, 1);
mal-serr_irq = irq_of_parse_and_map(ofdev-node, 2);
if (mal_has_feature(mal, MAL_FTR_COMMON_ERR_INT)) {
mal-txde_irq = mal-rxde_irq = mal-serr_irq;
} else {
mal-txde_irq = irq_of_parse_and_map(ofdev-node, 3);
mal-rxde_irq = irq_of_parse_and_map(ofdev-node, 4);
}

 +
   if (mal-txeob_irq == NO_IRQ || mal-rxeob_irq == NO_IRQ ||
   mal-serr_irq == NO_IRQ || mal-txde_irq == NO_IRQ ||
   mal-rxde_irq == NO_IRQ) {
 @@ -608,21 +645,42 @@ static int __devinit mal_probe(struct of_device *ofdev,
sizeof(struct mal_descriptor) *
mal_rx_bd_offset(mal, i));

[patch 1/6] kdump: Make elfcorehdr_addr independent of CONFIG_PROC_VMCORE

[Simon Horman]

From: Vivek Goyal [EMAIL PROTECTED]

o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
  also by the code which is not inside CONFIG_PROC_VMCORE. For example,
  is_kdump_kernel() is used by powerpc code to determine if kernel is booting
  after a panic then use previous kernel's TCE table. So even if
  CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
  correctly determine that we are booting after a panic and setup calgary
  iommu accordingly.

o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.

o Move definition of elfcorehdr_addr to arch dependent crash files.
  (Unfortunately crash dump does not have an arch independent file otherwise
   that would have been the best place).

o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
  second kernel without KEXEC being enabled.

o I don't see sh setup code parsing the command line for elfcorehdr_addr. I 
  am wondering how does vmcore interface work on sh. Anyway, I am atleast
  defining elfcoredhr_addr so that compilation is not broken on sh.

Signed-off-by: Vivek Goyal [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
Acked-by: Simon Horman [EMAIL PROTECTED]
Acked-by: Paul Mundt [EMAIL PROTECTED]
---

 arch/ia64/kernel/crash_dump.c|4 
 arch/ia64/kernel/setup.c |9 -
 arch/powerpc/kernel/crash_dump.c |   10 --
 arch/sh/kernel/crash_dump.c  |3 +++
 arch/x86/kernel/crash_dump_32.c  |3 +++
 arch/x86/kernel/crash_dump_64.c  |3 +++
 arch/x86/kernel/setup.c  |8 +++-
 fs/proc/vmcore.c |3 ---
 include/linux/crash_dump.h   |   14 ++
 9 files changed, 46 insertions(+), 11 deletions(-)

Andrew, this patch is a clean-up and is not required by other patches,
so it could wait until post 2.6.27 if you prefer. However, it is a
valuable cleanup that removes messiness and should remove some of
the confusion around elfcorehdr_addr and is_kdump_kernel(). So I
would prefer it to be included in 2.6.27.

sh setup code has been added in a separate patch that will
be merged by Paul Mundt.

- Simon Horman

diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore 
include/linux/crash_dump.h
--- 
linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore
   2008-07-28 12:00:44.0 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h2008-07-28 
12:00:56.0 -0400
@@ -9,11 +9,7 @@
 
 #define ELFCORE_ADDR_MAX   (-1ULL)
 
-#ifdef CONFIG_PROC_VMCORE
 extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
 
 extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
 
 #define vmcore_elf_check_arch(x) (elf_check_arch(x) || 
vmcore_elf_check_arch_cross(x))
 
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
 static inline int is_kdump_kernel(void)
 {
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 
fs/proc/vmcore.c
--- 
linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 
2008-07-28 09:19:50.0 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c  2008-07-28 09:20:10.0 
-0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
 /* Total size of vmcore file. */
 static u64 vmcore_size;
 
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
 struct proc_dir_entry *proc_vmcore = NULL;
 
 /* Reads a page from the oldmem device from given offset. */
diff -puN 
arch/x86/kernel/crash_dump_32.c~remove-elfcore-hdr-addr-definition-vmcore 
arch/x86/kernel/crash_dump_32.c
--- 
linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_32.c~remove-elfcore-hdr-addr-definition-vmcore
  2008-07-29 05:28:26.0 -0400
+++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/crash_dump_32.c   2008-07-29 
05:28:26.0 -0400
@@ -13,6 +13,9 @@
 
 static void *kdump_buf_page;
 
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
 /**
  * copy_oldmem_page - copy one page from oldmem
  * @pfn: page frame number to be copied
diff -puN 
arch/x86/kernel/crash_dump_64.c~remove-elfcore-hdr-addr-definition-vmcore 
arch/x86/kernel/crash_dump_64.c
--- 
linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_64.c~remove-elfcore-hdr

Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')

[Simon Horman]

On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:
 Vivek Goyal [EMAIL PROTECTED] writes:
 
  Hi All,
 
  How does following series of patches look like. I have moved
  elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section 
  of crash dump to make sure that it can be worked with even when
  CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
 
  I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
  sh versions are completely untested.
 
 Given the current state of the code:
 Acked-by: Eric W. Biederman [EMAIL PROTECTED]
 
 To process a kernel crash dump we pass the kernel elfcorehdr option,
 so testing to see if it was passed seems reasonable.
 
 In general I think this method of handling the problems with kdump is
 too brittle to live, but in the case of iommus we certainly need to do
 something different, and unfortunately iommus were not common on x86
 when the original code was merged so we have not handled them well.

Agreed, however these patches look like they really ought to be merged
into a single patch for the sake of bisect. As things stand, applying
the first patch will break the build on each architecture with an
architecture specific until the latter is applied.

-- 
Horms

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

Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')

[Simon Horman]

On Mon, Jul 28, 2008 at 10:28:22PM -0400, Vivek Goyal wrote:
 On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote:
  On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:
   Vivek Goyal [EMAIL PROTECTED] writes:
   
Hi All,
   
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section 
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
   
I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
sh versions are completely untested.
   
   Given the current state of the code:
   Acked-by: Eric W. Biederman [EMAIL PROTECTED]
   
   To process a kernel crash dump we pass the kernel elfcorehdr option,
   so testing to see if it was passed seems reasonable.
   
   In general I think this method of handling the problems with kdump is
   too brittle to live, but in the case of iommus we certainly need to do
   something different, and unfortunately iommus were not common on x86
   when the original code was merged so we have not handled them well.
  
  Agreed, however these patches look like they really ought to be merged
  into a single patch for the sake of bisect. As things stand, applying
  the first patch will break the build on each architecture with an
  architecture specific until the latter is applied.
 
 That's a good point. I was not very sure because changes were in 
 different arches and I broke the patch. At the same time changes are
 really miniscule in each arch. 

I guessed that was why you split them up. But really the
per-arch change is very small.

 So, for the sake of not breaking compilation for git-bisect, I will
 generate a single patch tomorrow. (Until and unless somebody has an
 objection).

For combiled patch:

Acked-by: Simon Horman [EMAIL PROTECTED]

-- 
Horms

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