| Message ID | 20200509103956.26038-2-hui.song_1@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1,1/3] gpio: mpc8xxx: support fsl-layerscape platform. | expand |
On Sat, May 09, 2020 at 05:33:15PM +0200, Andrew Lunn wrote: > On Sat, May 09, 2020 at 06:39:55PM +0800, Hui Song wrote: > > From: "hui.song" <hui.song_1@nxp.com> > > > > add one struct mpc8xxx_gpio_plat to enable gpio feature. > > > > Signed-off-by: hui.song <hui.song_1@nxp.com> > > --- > > .../include/asm/arch-fsl-layerscape/gpio.h | 22 +++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/gpio.h > > > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/gpio.h b/arch/arm/include/asm/arch-fsl-layerscape/gpio.h > > new file mode 100644 > > index 0000000000..d8dd750a72 > > --- /dev/null > > +++ b/arch/arm/include/asm/arch-fsl-layerscape/gpio.h > > @@ -0,0 +1,22 @@ > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > +/* > > + * Copyright 2014 Freescale Semiconductor, Inc. > > + */ > > + > > +/* > > + * Dummy header file to enable CONFIG_OF_CONTROL. > > + * If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled. > > + * It includes <asm/arch/gpio.h> via <asm/gpio.h>, so those SoCs that enable > > + * OF_CONTROL must have arch/gpio.h. > > + */ > > This does not seem right. You would expect each sub arch to have a > subdirectory in arch/arm/include/asm/ when in fact none do. From what I can tell, these patches are not for the kernel. The filenames don't match th kernel layout.
> From what I can tell, these patches are not for the kernel. The > filenames don't match th kernel layout. These files looks to be from U-boot, and must be intended for U-boot as I see U-boot mailing address in recipient's address?
On Sat, May 09, 2020 at 11:34:59PM +0530, Amit Tomer wrote: > > From what I can tell, these patches are not for the kernel. The > > filenames don't match th kernel layout. > > These files looks to be from U-boot, and must be intended for U-boot > as I see U-boot mailing address in recipient's address? So why is it copied to: devicetree@vger.kernel.org - a kernel mailing list linux-kernel@vger.kernel.org - the main kernel mailing list linux-gpio@vger.kernel.org - the gpio driver kernel mailing list linux-arm-kernel@lists.infradead.org - the ARM kernel mailing list Given that it includes four kernel mailing lists (ok, devicetree may be argued to have a wider application), then I don't think the conclusion that "it's for u-boot, because there's _one_ u-boot mailing list in the recipients" is particularly obvious. The author really needs to state that up front if they're sending it to a wide audeience, rather than leaving people to guess, thereby potentially wasting their time. Not only did Andrew review the patch as if it were for the kernel, but I also wasted time on this as well when I double-took the ifdefs, and wanted to check the current driver in the kernel.
On Sat, May 09, 2020 at 07:18:45PM +0100, Russell King - ARM Linux admin wrote: > On Sat, May 09, 2020 at 11:34:59PM +0530, Amit Tomer wrote: > > > From what I can tell, these patches are not for the kernel. The > > > filenames don't match th kernel layout. > > > > These files looks to be from U-boot, and must be intended for U-boot > > as I see U-boot mailing address in recipient's address? > > So why is it copied to: > > devicetree@vger.kernel.org - a kernel mailing list > linux-kernel@vger.kernel.org - the main kernel mailing list > linux-gpio@vger.kernel.org - the gpio driver kernel mailing list > linux-arm-kernel@lists.infradead.org - the ARM kernel mailing list > > Given that it includes four kernel mailing lists (ok, devicetree > may be argued to have a wider application), then I don't think the > conclusion that "it's for u-boot, because there's _one_ u-boot > mailing list in the recipients" is particularly obvious. > > The author really needs to state that up front if they're sending > it to a wide audeience, rather than leaving people to guess, thereby > potentially wasting their time. > > Not only did Andrew review the patch as if it were for the kernel, > but I also wasted time on this as well when I double-took the > ifdefs, and wanted to check the current driver in the kernel. Oh, and... u-boot@linux.nxdi.nxp.com bounces because that domain is not resolvable - I guess that is internal to NXP, and this patch should have remained within NXP and not been posted publically.
> Oh, and... u-boot@linux.nxdi.nxp.com bounces because that domain is > not resolvable - I guess that is internal to NXP, and this patch > should have remained within NXP and not been posted publically. Yeah, realized it just after sending my reply. It is for internal NXP list. Had it been for open source U-boot, Author would have chosen "u-boot@lists.denx.de" ? But, I still believe Author did it unknowingly and we all should be easy on him/her. Thanks -Amit
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/gpio.h b/arch/arm/include/asm/arch-fsl-layerscape/gpio.h new file mode 100644 index 0000000000..d8dd750a72 --- /dev/null +++ b/arch/arm/include/asm/arch-fsl-layerscape/gpio.h @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2014 Freescale Semiconductor, Inc. + */ + +/* + * Dummy header file to enable CONFIG_OF_CONTROL. + * If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled. + * It includes <asm/arch/gpio.h> via <asm/gpio.h>, so those SoCs that enable + * OF_CONTROL must have arch/gpio.h. + */ + +#ifndef __ASM_ARCH_MX85XX_GPIO_H +#define __ASM_ARCH_MX85XX_GPIO_H + +struct mpc8xxx_gpio_plat { + ulong addr; + unsigned long size; + uint ngpios; +}; + +#endif