Re: [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: > From: Nick Hawkins > > GXP is the name of the HPE SoC. > This SoC is used to implement BMC features of HPE servers > (all ProLiant, Synergy, and many Apollo, and Superdome machines) > It does support many features including: > ARMv7 architecture, and it is based on a Cortex A9 core > Use an AXI bus to which > a memory controller is attached, as well as > multiple SPI interfaces to connect boot flash, > and ROM flash, a 10/100/1000 Mac engine which > supports SGMII (2 ports) and RMII > Multiple I2C engines to drive connectivity with a host > infrastructure > A video engine which support VGA and DP, as well as > an hardware video encoder > Multiple PCIe ports > A PECI interface, and LPC eSPI > Multiple UART for debug purpose, and Virtual UART for host > connectivity > A GPIO engine > This Patch Includes: > Documentation for device tree bindings > Device Tree Bindings > GXP Timer Support > GXP Architecture Support This is far too big for a single patch. It needs to be broken into functional chunks that can be reviewed individually. Each driver and each device tree change along with it's accompanying code need to be done in individual patches. The way it is it can't be reviewed in any sane manner. -corey > > Signed-off-by: Nick Hawkins > --- > .../bindings/display/hpe,gxp-thumbnail.txt| 21 + > .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 + > .../devicetree/bindings/i2c/hpe,gxp-i2c.txt | 19 + > .../bindings/ipmi/hpegxp-kcs-bmc-cfg.txt | 13 + > .../bindings/ipmi/hpegxp-kcs-bmc.txt | 21 + > .../memory-controllers/hpe,gxp-srom.txt | 13 + > .../devicetree/bindings/mtd/hpe,gxp.txt | 16 + > .../bindings/net/hpe,gxp-umac-mdio.txt| 21 + > .../devicetree/bindings/net/hpe,gxp-umac.txt | 20 + > .../devicetree/bindings/pwm/hpe,gxp-fan.txt | 15 + > .../bindings/serial/hpe,gxp-vuart-cfg.txt | 17 + > .../bindings/serial/hpe,gxp-vuart.txt | 23 + > .../bindings/soc/hpe/hpe,gxp-chif.txt | 16 + > .../bindings/soc/hpe/hpe,gxp-csm.txt | 14 + > .../bindings/soc/hpe/hpe,gxp-dbg.txt | 18 + > .../bindings/soc/hpe/hpe,gxp-fn2.txt | 20 + > .../bindings/soc/hpe/hpe,gxp-xreg.txt | 19 + > .../devicetree/bindings/spi/hpe,gxp-spifi.txt | 76 +++ > .../bindings/thermal/hpe,gxp-coretemp.txt | 14 + > .../bindings/timer/hpe,gxp-timer.txt | 18 + > .../devicetree/bindings/usb/hpe,gxp-udc.txt | 21 + > .../devicetree/bindings/vendor-prefixes.yaml | 4 +- > .../bindings/watchdog/hpe,gxp-wdt.txt | 11 + > MAINTAINERS | 14 + > arch/arm/Kconfig | 2 + > arch/arm/boot/dts/Makefile| 2 + > arch/arm/boot/dts/hpe-bmc-dl360gen10.dts | 207 +++ > arch/arm/boot/dts/hpe-gxp.dtsi| 555 ++ > arch/arm/configs/gxp_defconfig| 243 > arch/arm/mach-hpe/Kconfig | 21 + > arch/arm/mach-hpe/Makefile| 1 + > arch/arm/mach-hpe/gxp.c | 62 ++ > drivers/clocksource/Kconfig | 8 + > drivers/clocksource/Makefile | 1 + > drivers/clocksource/gxp_timer.c | 158 + > 35 files changed, 1719 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/hpe,gxp-thumbnail.txt > create mode 100644 Documentation/devicetree/bindings/gpio/hpe,gxp-gpio.txt > create mode 100644 Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.txt > create mode 100644 > Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc-cfg.txt > create mode 100644 Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc.txt > create mode 100644 > Documentation/devicetree/bindings/memory-controllers/hpe,gxp-srom.txt > create mode 100644 Documentation/devicetree/bindings/mtd/hpe,gxp.txt > create mode 100644 > Documentation/devicetree/bindings/net/hpe,gxp-umac-mdio.txt > create mode 100644 Documentation/devicetree/bindings/net/hpe,gxp-umac.txt > create mode 100644 Documentation/devicetree/bindings/pwm/hpe,gxp-fan.txt > create mode 100644 > Documentation/devicetree/bindings/serial/hpe,gxp-vuart-cfg.txt > create mode 100644 Documentation/devicetree/bindings/serial/hpe,gxp-vuart.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-chif.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-csm.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-dbg.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-fn2.txt > create mode 100644
Re: [Openipmi-developer] [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 02, 2022 at 06:14:57PM +, Verdun, Jean-Marie wrote: > > This is far too big for a single patch. It needs to be broken into > > functional chunks that can be reviewed individually. Each driver and > > each device tree change along with it's accompanying code need to be > > done in individual patches. The way it is it can't be reviewed in any > > sane manner. > > > -corey > > Thanks for your feedback. We are getting a little bit lost here, as our plan > was to submit initial > > - bindings > - dts for SoC and 1 board > - initial platform init code > > Then drivers code avoiding to send many dts updates which might complexify > the review. We wanted to send all drivers code to relevant reviewers by > tomorrow. > > So, what you are asking ( do not worry I am not trying to negotiate, I just > want to avoid English misunderstandings as I am French) is to send per driver > > - binding > - dts update > - driver code > > For each driver through different submission (with each of them containing > the 3 associated parts) ? Arnd gave an excellent explaination for this. To be clear, you need to split out changes to individual subsystems and submit those to the maintainers for that subsystem and not send them to everyone. That way you reduce sending emails to people who don't need to see them. Once you have a set of patches for a subsystem, you can submit them as one set. That is generally preferred. The "git send-email" or "git format-patch" tools are generally what we use, they let you compose a header message where you can give an overall explaination, then it sends the individual changes as followup messages to the header message. -corey > > What shall be the initial one in our case as we are introducing a platform ? > An empty dts infrastructure and then we make it grow one step at a time ? > > vejmarie > > > > > > ___ > Openipmi-developer mailing list > openipmi-develo...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [PATCH] char: ipmi: convert tasklets to use new tasklet_setup() API
On Tue, Aug 18, 2020 at 02:46:23PM +0530, Allen wrote:
> > >
> > > Signed-off-by: Romain Perier
> > > Signed-off-by: Allen Pais
> >
> > This looks good to me.
> >
> > Reviewed-by: Corey Minyard
> >
> > Are you planning to push this, or do you want me to take it? If you
> > want me to take it, what is the urgency?
>
> Thanks. Well, not hurry, as long as it goes into 5.9 with all other
> changes.
Ok, this is queued in my for-next branch.
-corey
>
>
> >
> > -corey
> >
> > > ---
> > > drivers/char/ipmi/ipmi_msghandler.c | 13 ++---
> > > 1 file changed, 6 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> > > b/drivers/char/ipmi/ipmi_msghandler.c
> > > index 737c0b6b24ea..e1814b6a1225 100644
> > > --- a/drivers/char/ipmi/ipmi_msghandler.c
> > > +++ b/drivers/char/ipmi/ipmi_msghandler.c
> > > @@ -39,7 +39,7 @@
> > >
> > > static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
> > > static int ipmi_init_msghandler(void);
> > > -static void smi_recv_tasklet(unsigned long);
> > > +static void smi_recv_tasklet(struct tasklet_struct *t);
> > > static void handle_new_recv_msgs(struct ipmi_smi *intf);
> > > static void need_waiter(struct ipmi_smi *intf);
> > > static int handle_one_recv_msg(struct ipmi_smi *intf,
> > > @@ -3430,9 +3430,8 @@ int ipmi_add_smi(struct module *owner,
> > > intf->curr_seq = 0;
> > > spin_lock_init(>waiting_rcv_msgs_lock);
> > > INIT_LIST_HEAD(>waiting_rcv_msgs);
> > > - tasklet_init(>recv_tasklet,
> > > - smi_recv_tasklet,
> > > - (unsigned long) intf);
> > > + tasklet_setup(>recv_tasklet,
> > > + smi_recv_tasklet);
> > > atomic_set(>watchdog_pretimeouts_to_deliver, 0);
> > > spin_lock_init(>xmit_msgs_lock);
> > > INIT_LIST_HEAD(>xmit_msgs);
> > > @@ -4467,10 +4466,10 @@ static void handle_new_recv_msgs(struct ipmi_smi
> > > *intf)
> > > }
> > > }
> > >
> > > -static void smi_recv_tasklet(unsigned long val)
> > > +static void smi_recv_tasklet(struct tasklet_struct *t)
> > > {
> > > unsigned long flags = 0; /* keep us warning-free. */
> > > - struct ipmi_smi *intf = (struct ipmi_smi *) val;
> > > + struct ipmi_smi *intf = from_tasklet(intf, t, recv_tasklet);
> > > int run_to_completion = intf->run_to_completion;
> > > struct ipmi_smi_msg *newmsg = NULL;
> > >
> > > @@ -4542,7 +4541,7 @@ void ipmi_smi_msg_received(struct ipmi_smi *intf,
> > > spin_unlock_irqrestore(>xmit_msgs_lock, flags);
> > >
> > > if (run_to_completion)
> > > - smi_recv_tasklet((unsigned long) intf);
> > > + smi_recv_tasklet(>recv_tasklet);
> > > else
> > > tasklet_schedule(>recv_tasklet);
> > > }
> > > --
> > > 2.17.1
> > >
>
>
>
> --
>- Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char: ipmi: convert tasklets to use new tasklet_setup() API
On Mon, Aug 17, 2020 at 02:45:57PM +0530, Allen Pais wrote:
> From: Allen Pais
>
> 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
This looks good to me.
Reviewed-by: Corey Minyard
Are you planning to push this, or do you want me to take it? If you
want me to take it, what is the urgency?
-corey
> ---
> drivers/char/ipmi/ipmi_msghandler.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> b/drivers/char/ipmi/ipmi_msghandler.c
> index 737c0b6b24ea..e1814b6a1225 100644
> --- a/drivers/char/ipmi/ipmi_msghandler.c
> +++ b/drivers/char/ipmi/ipmi_msghandler.c
> @@ -39,7 +39,7 @@
>
> static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
> static int ipmi_init_msghandler(void);
> -static void smi_recv_tasklet(unsigned long);
> +static void smi_recv_tasklet(struct tasklet_struct *t);
> static void handle_new_recv_msgs(struct ipmi_smi *intf);
> static void need_waiter(struct ipmi_smi *intf);
> static int handle_one_recv_msg(struct ipmi_smi *intf,
> @@ -3430,9 +3430,8 @@ int ipmi_add_smi(struct module *owner,
> intf->curr_seq = 0;
> spin_lock_init(>waiting_rcv_msgs_lock);
> INIT_LIST_HEAD(>waiting_rcv_msgs);
> - tasklet_init(>recv_tasklet,
> - smi_recv_tasklet,
> - (unsigned long) intf);
> + tasklet_setup(>recv_tasklet,
> + smi_recv_tasklet);
> atomic_set(>watchdog_pretimeouts_to_deliver, 0);
> spin_lock_init(>xmit_msgs_lock);
> INIT_LIST_HEAD(>xmit_msgs);
> @@ -4467,10 +4466,10 @@ static void handle_new_recv_msgs(struct ipmi_smi
> *intf)
> }
> }
>
> -static void smi_recv_tasklet(unsigned long val)
> +static void smi_recv_tasklet(struct tasklet_struct *t)
> {
> unsigned long flags = 0; /* keep us warning-free. */
> - struct ipmi_smi *intf = (struct ipmi_smi *) val;
> + struct ipmi_smi *intf = from_tasklet(intf, t, recv_tasklet);
> int run_to_completion = intf->run_to_completion;
> struct ipmi_smi_msg *newmsg = NULL;
>
> @@ -4542,7 +4541,7 @@ void ipmi_smi_msg_received(struct ipmi_smi *intf,
> spin_unlock_irqrestore(>xmit_msgs_lock, flags);
>
> if (run_to_completion)
> - smi_recv_tasklet((unsigned long) intf);
> + smi_recv_tasklet(>recv_tasklet);
> else
> tasklet_schedule(>recv_tasklet);
> }
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_
On 12/19/2017 12:15 PM, Joe Perches wrote: drivers/char/ipmi/ipmi_msghandler.c| 17 +++--- For ipmi: Acked-by: Corey Minyard <cminy...@mvista.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
