Create a SoC folder for the ASPEED parts and place the misc drivers
currently present into this folder. These drivers are not generic part
drivers, but rather only apply to the ASPEED SoCs.
Signed-off-by: Patrick Venture <[email protected]>
---
v2:
Added configuration option for ASPEED to soc/Makefile
---
drivers/misc/Kconfig | 16 ----------------
drivers/misc/Makefile | 2 --
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/aspeed/Kconfig | 19 +++++++++++++++++++
drivers/soc/aspeed/Makefile | 2 ++
.../{misc => soc/aspeed}/aspeed-lpc-ctrl.c | 0
.../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
8 files changed, 23 insertions(+), 18 deletions(-)
create mode 100644 drivers/soc/aspeed/Kconfig
create mode 100644 drivers/soc/aspeed/Makefile
rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 42ab8ec92a04..b80cb6af0cb4 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
-config ASPEED_LPC_CTRL
- depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
- tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
- ---help---
- Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
- ioctl()s, the driver also provides a read/write interface to a BMC ram
- region where the host LPC read/write region can be buffered.
-
-config ASPEED_LPC_SNOOP
- tristate "Aspeed ast2500 HOST LPC snoop support"
- depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
- help
- Provides a driver to control the LPC snoop interface which
- allows the BMC to listen on and save the data written by
- the host to an arbitrary LPC I/O port.
-
config PCI_ENDPOINT_TEST
depends on PCI
select CRC32
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d5b7d3404dc7..b9affcdaa3d6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
-obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
-obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-y += cardreader/
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c07b4a85253f..b750a88547c7 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/actions/Kconfig"
source "drivers/soc/amlogic/Kconfig"
+source "drivers/soc/aspeed/Kconfig"
source "drivers/soc/atmel/Kconfig"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 90b686e586c6..814128fe479f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,6 +4,7 @@
#
obj-$(CONFIG_ARCH_ACTIONS) += actions/
+obj-$(CONFIG_ARCH_ASPEED) += aspeed/
obj-$(CONFIG_ARCH_AT91) += atmel/
obj-y += bcm/
obj-$(CONFIG_ARCH_DOVE) += dove/
diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
new file mode 100644
index 000000000000..457282cd1da5
--- /dev/null
+++ b/drivers/soc/aspeed/Kconfig
@@ -0,0 +1,19 @@
+menu "Aspeed SoC drivers"
+
+config ASPEED_LPC_CTRL
+ depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
+ tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
+ ---help---
+ Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
+ ioctl()s, the driver also provides a read/write interface to a BMC ram
+ region where the host LPC read/write region can be buffered.
+
+config ASPEED_LPC_SNOOP
+ tristate "Aspeed ast2500 HOST LPC snoop support"
+ depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
+ help
+ Provides a driver to control the LPC snoop interface which
+ allows the BMC to listen on and save the data written by
+ the host to an arbitrary LPC I/O port.
+
+
diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
new file mode 100644
index 000000000000..cfaa9adc67b5
--- /dev/null
+++ b/drivers/soc/aspeed/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
+obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
similarity index 100%
rename from drivers/misc/aspeed-lpc-ctrl.c
rename to drivers/soc/aspeed/aspeed-lpc-ctrl.c
diff --git a/drivers/misc/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
similarity index 100%
rename from drivers/misc/aspeed-lpc-snoop.c
rename to drivers/soc/aspeed/aspeed-lpc-snoop.c
--
2.21.0.593.g511ec345e18-goog
On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
>
> Create a SoC folder for the ASPEED parts and place the misc drivers
> currently present into this folder. These drivers are not generic part
> drivers, but rather only apply to the ASPEED SoCs.
>
> Signed-off-by: Patrick Venture <[email protected]>
Accidentally lost the Acked-by when re-sending this patchset as I
didn't see it on v1 before re-sending v2 to the larger audience.
> ---
> v2:
> Added configuration option for ASPEED to soc/Makefile
> ---
> drivers/misc/Kconfig | 16 ----------------
> drivers/misc/Makefile | 2 --
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/aspeed/Kconfig | 19 +++++++++++++++++++
> drivers/soc/aspeed/Makefile | 2 ++
> .../{misc => soc/aspeed}/aspeed-lpc-ctrl.c | 0
> .../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
> 8 files changed, 23 insertions(+), 18 deletions(-)
> create mode 100644 drivers/soc/aspeed/Kconfig
> create mode 100644 drivers/soc/aspeed/Makefile
> rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
> rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 42ab8ec92a04..b80cb6af0cb4 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
> bus. System Configuration interface is one of the possible means
> of generating transactions on this bus.
>
> -config ASPEED_LPC_CTRL
> - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> - tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> - ---help---
> - Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> - ioctl()s, the driver also provides a read/write interface to a BMC ram
> - region where the host LPC read/write region can be buffered.
> -
> -config ASPEED_LPC_SNOOP
> - tristate "Aspeed ast2500 HOST LPC snoop support"
> - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> - help
> - Provides a driver to control the LPC snoop interface which
> - allows the BMC to listen on and save the data written by
> - the host to an arbitrary LPC I/O port.
> -
> config PCI_ENDPOINT_TEST
> depends on PCI
> select CRC32
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index d5b7d3404dc7..b9affcdaa3d6 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
> obj-$(CONFIG_ECHO) += echo/
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE) += cxl/
> -obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> -obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
> obj-$(CONFIG_OCXL) += ocxl/
> obj-y += cardreader/
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index c07b4a85253f..b750a88547c7 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/actions/Kconfig"
> source "drivers/soc/amlogic/Kconfig"
> +source "drivers/soc/aspeed/Kconfig"
> source "drivers/soc/atmel/Kconfig"
> source "drivers/soc/bcm/Kconfig"
> source "drivers/soc/fsl/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 90b686e586c6..814128fe479f 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -4,6 +4,7 @@
> #
>
> obj-$(CONFIG_ARCH_ACTIONS) += actions/
> +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> obj-$(CONFIG_ARCH_AT91) += atmel/
> obj-y += bcm/
> obj-$(CONFIG_ARCH_DOVE) += dove/
> diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> new file mode 100644
> index 000000000000..457282cd1da5
> --- /dev/null
> +++ b/drivers/soc/aspeed/Kconfig
> @@ -0,0 +1,19 @@
> +menu "Aspeed SoC drivers"
> +
> +config ASPEED_LPC_CTRL
> + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> + tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> + ---help---
> + Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> + ioctl()s, the driver also provides a read/write interface to a BMC ram
> + region where the host LPC read/write region can be buffered.
> +
> +config ASPEED_LPC_SNOOP
> + tristate "Aspeed ast2500 HOST LPC snoop support"
> + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> + help
> + Provides a driver to control the LPC snoop interface which
> + allows the BMC to listen on and save the data written by
> + the host to an arbitrary LPC I/O port.
> +
> +
> diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
> new file mode 100644
> index 000000000000..cfaa9adc67b5
> --- /dev/null
> +++ b/drivers/soc/aspeed/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> +obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> similarity index 100%
> rename from drivers/misc/aspeed-lpc-ctrl.c
> rename to drivers/soc/aspeed/aspeed-lpc-ctrl.c
> diff --git a/drivers/misc/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> similarity index 100%
> rename from drivers/misc/aspeed-lpc-snoop.c
> rename to drivers/soc/aspeed/aspeed-lpc-snoop.c
> --
> 2.21.0.593.g511ec345e18-goog
>
On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
>
> On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> >
> > Create a SoC folder for the ASPEED parts and place the misc drivers
> > currently present into this folder. These drivers are not generic part
> > drivers, but rather only apply to the ASPEED SoCs.
> >
> > Signed-off-by: Patrick Venture <[email protected]>
>
> Accidentally lost the Acked-by when re-sending this patchset as I
> didn't see it on v1 before re-sending v2 to the larger audience.
Since there was a change between v1 and v2, Arnd, I'd appreciate you
Ack this version of the patchset since it changes when the soc/aspeed
Makefile is followed.
>
> > ---
> > v2:
> > Added configuration option for ASPEED to soc/Makefile
> > ---
> > drivers/misc/Kconfig | 16 ----------------
> > drivers/misc/Makefile | 2 --
> > drivers/soc/Kconfig | 1 +
> > drivers/soc/Makefile | 1 +
> > drivers/soc/aspeed/Kconfig | 19 +++++++++++++++++++
> > drivers/soc/aspeed/Makefile | 2 ++
> > .../{misc => soc/aspeed}/aspeed-lpc-ctrl.c | 0
> > .../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
> > 8 files changed, 23 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/soc/aspeed/Kconfig
> > create mode 100644 drivers/soc/aspeed/Makefile
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 42ab8ec92a04..b80cb6af0cb4 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
> > bus. System Configuration interface is one of the possible means
> > of generating transactions on this bus.
> >
> > -config ASPEED_LPC_CTRL
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > - ---help---
> > - Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > - ioctl()s, the driver also provides a read/write interface to a BMC ram
> > - region where the host LPC read/write region can be buffered.
> > -
> > -config ASPEED_LPC_SNOOP
> > - tristate "Aspeed ast2500 HOST LPC snoop support"
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - help
> > - Provides a driver to control the LPC snoop interface which
> > - allows the BMC to listen on and save the data written by
> > - the host to an arbitrary LPC I/O port.
> > -
> > config PCI_ENDPOINT_TEST
> > depends on PCI
> > select CRC32
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index d5b7d3404dc7..b9affcdaa3d6 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
> > obj-$(CONFIG_ECHO) += echo/
> > obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> > obj-$(CONFIG_CXL_BASE) += cxl/
> > -obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > -obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
> > obj-$(CONFIG_OCXL) += ocxl/
> > obj-y += cardreader/
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index c07b4a85253f..b750a88547c7 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/actions/Kconfig"
> > source "drivers/soc/amlogic/Kconfig"
> > +source "drivers/soc/aspeed/Kconfig"
> > source "drivers/soc/atmel/Kconfig"
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/fsl/Kconfig"
> > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> > index 90b686e586c6..814128fe479f 100644
> > --- a/drivers/soc/Makefile
> > +++ b/drivers/soc/Makefile
> > @@ -4,6 +4,7 @@
> > #
> >
> > obj-$(CONFIG_ARCH_ACTIONS) += actions/
> > +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> > obj-$(CONFIG_ARCH_AT91) += atmel/
> > obj-y += bcm/
> > obj-$(CONFIG_ARCH_DOVE) += dove/
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > new file mode 100644
> > index 000000000000..457282cd1da5
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -0,0 +1,19 @@
> > +menu "Aspeed SoC drivers"
> > +
> > +config ASPEED_LPC_CTRL
> > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > + tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > + ---help---
> > + Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > + ioctl()s, the driver also provides a read/write interface to a BMC ram
> > + region where the host LPC read/write region can be buffered.
> > +
> > +config ASPEED_LPC_SNOOP
> > + tristate "Aspeed ast2500 HOST LPC snoop support"
> > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > + help
> > + Provides a driver to control the LPC snoop interface which
> > + allows the BMC to listen on and save the data written by
> > + the host to an arbitrary LPC I/O port.
> > +
> > +
> > diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
> > new file mode 100644
> > index 000000000000..cfaa9adc67b5
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Makefile
> > @@ -0,0 +1,2 @@
> > +obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > +obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> > similarity index 100%
> > rename from drivers/misc/aspeed-lpc-ctrl.c
> > rename to drivers/soc/aspeed/aspeed-lpc-ctrl.c
> > diff --git a/drivers/misc/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> > similarity index 100%
> > rename from drivers/misc/aspeed-lpc-snoop.c
> > rename to drivers/soc/aspeed/aspeed-lpc-snoop.c
> > --
> > 2.21.0.593.g511ec345e18-goog
> >
On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> >
> > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > >
> > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > currently present into this folder. These drivers are not generic part
> > > drivers, but rather only apply to the ASPEED SoCs.
> > >
> > > Signed-off-by: Patrick Venture <[email protected]>
> >
> > Accidentally lost the Acked-by when re-sending this patchset as I
> > didn't see it on v1 before re-sending v2 to the larger audience.
>
> Since there was a change between v1 and v2, Arnd, I'd appreciate you
> Ack this version of the patchset since it changes when the soc/aspeed
> Makefile is followed.
I have no objection for moving stuff out of drivers/misc/ so the SOC
maintainers are free to take this.
Acked-by: Greg Kroah-Hartman <[email protected]>
On Thu, 25 Apr 2019 at 17:25, Greg KH <[email protected]> wrote:
>
> On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > >
> > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > >
> > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > currently present into this folder. These drivers are not generic part
> > > > drivers, but rather only apply to the ASPEED SoCs.
> > > >
> > > > Signed-off-by: Patrick Venture <[email protected]>
> > >
> > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > didn't see it on v1 before re-sending v2 to the larger audience.
> >
> > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > Ack this version of the patchset since it changes when the soc/aspeed
> > Makefile is followed.
>
> I have no objection for moving stuff out of drivers/misc/ so the SOC
> maintainers are free to take this.
I was on the fence about this. The downside of moving drivers out of
drivers/misc is it allows SoCs to hide little drivers away from
scrutiny, when in fact they could be sharing a common userspace API
with other BMCs. (Keep an eye out for the coming Nuvoton "bios post
code" driver which is very similar to
drivers/misc/aspeed-lpc-snoop.c).
However, in the effort to move away from BMC that are full of shell
scripts that bash on /dev/mem, we are going to see a collection of
small, very SoC specific, drivers and it doesn't make sense to clutter
up drivers/misc.
Acked-by: Joel Stanley <[email protected]>
The p2a driver has been merged by Greg. We should move that one over
too. Arnd, can you advise Patrick on how to proceed? We could have him
spin a v3 that includes the p2a driver, but it would depend on Greg's
char-misc-next branch.
Cheers,
Joel
On Mon, Apr 29, 2019 at 9:49 AM Joel Stanley <[email protected]> wrote:
>
> On Thu, 25 Apr 2019 at 17:25, Greg KH <[email protected]> wrote:
> >
> > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > >
> > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > >
> > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > currently present into this folder. These drivers are not generic part
> > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > >
> > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > >
> > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > >
> > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > Ack this version of the patchset since it changes when the soc/aspeed
> > > Makefile is followed.
> >
> > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > maintainers are free to take this.
>
> I was on the fence about this. The downside of moving drivers out of
> drivers/misc is it allows SoCs to hide little drivers away from
> scrutiny, when in fact they could be sharing a common userspace API
> with other BMCs. (Keep an eye out for the coming Nuvoton "bios post
> code" driver which is very similar to
> drivers/misc/aspeed-lpc-snoop.c).
Things like this should usually find a different home: drivers/misc
tends to be for one-of-a-kind stuff with a user interface, not for things
where you have multiple chips doing the same thing.
If you think there are going to be additional cases where you have
more than one bmc in need of a user interface for the same
functionality, we could introduce a drivers/bmc/ subsystem and
have a set of user interfaces backed by a set of chip specific
drivers.
> However, in the effort to move away from BMC that are full of shell
> scripts that bash on /dev/mem, we are going to see a collection of
> small, very SoC specific, drivers and it doesn't make sense to clutter
> up drivers/misc.
>
> Acked-by: Joel Stanley <[email protected]>
>
> The p2a driver has been merged by Greg. We should move that one over
> too. Arnd, can you advise Patrick on how to proceed? We could have him
> spin a v3 that includes the p2a driver, but it would depend on Greg's
> char-misc-next branch.
I don't think there is a rush here, so let's do that for the following
merge window.
Arnd
On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > >
> > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > >
> > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > currently present into this folder. These drivers are not generic part
> > > > drivers, but rather only apply to the ASPEED SoCs.
> > > >
> > > > Signed-off-by: Patrick Venture <[email protected]>
> > >
> > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > didn't see it on v1 before re-sending v2 to the larger audience.
> >
> > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > Ack this version of the patchset since it changes when the soc/aspeed
> > Makefile is followed.
>
> I have no objection for moving stuff out of drivers/misc/ so the SOC
> maintainers are free to take this.
>
> Acked-by: Greg Kroah-Hartman <[email protected]>
I'm totally confused. This is the second "PATCH v2" of this patch that I came
across, I already applied the first.
Patrick: Follow up with incremental patch in case there's any difference.
Meanwhile, please keep in mind that you're adding a lot of work for people when
you respin patches without following up on the previous version. Thanks!
-Olof
On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
>
> On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > >
> > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > >
> > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > currently present into this folder. These drivers are not generic part
> > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > >
> > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > >
> > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > >
> > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > Ack this version of the patchset since it changes when the soc/aspeed
> > > Makefile is followed.
> >
> > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > maintainers are free to take this.
> >
> > Acked-by: Greg Kroah-Hartman <[email protected]>
>
> I'm totally confused. This is the second "PATCH v2" of this patch that I came
> across, I already applied the first.
I think the issue here was that I added to the CC list another email
and so you may see the v2 without that mailing list, and a v2 with it
--
Does this require a v3? I honestly didn't think so, but this was the
first time I had to add more people without needing other changes.
>
> Patrick: Follow up with incremental patch in case there's any difference.
> Meanwhile, please keep in mind that you're adding a lot of work for people when
> you respin patches without following up on the previous version. Thanks!
w.r.t this patch series. I found an issue with v1, and released a v2
with the detail of what changed. I thought that was the correct
approach. I apologize for creating extra work, that's something
nobody needs.
>
>
> -Olof
On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
>
> On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > >
> > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > >
> > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > currently present into this folder. These drivers are not generic part
> > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > >
> > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > >
> > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > >
> > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > Ack this version of the patchset since it changes when the soc/aspeed
> > > Makefile is followed.
> >
> > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > maintainers are free to take this.
> >
> > Acked-by: Greg Kroah-Hartman <[email protected]>
>
> I'm totally confused. This is the second "PATCH v2" of this patch that I came
> across, I already applied the first.
>
> Patrick: Follow up with incremental patch in case there's any difference.
> Meanwhile, please keep in mind that you're adding a lot of work for people when
> you respin patches without following up on the previous version. Thanks!
Not only that, but subthreads were cc:d to [email protected] and some
were not, so I missed the overnight conversation on the topic.
If this email thread is any indication of how the code will be
flowing, there's definitely need for more structure. Joel, I'm hoping
you'll coordinate.
I'm with Arnd on whether the code should be in drivers/soc or not --
most of it likely should not.
-Olof
On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <[email protected]> wrote:
>
> On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
> >
> > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > > >
> > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > > >
> > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > currently present into this folder. These drivers are not generic part
> > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > >
> > > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > > >
> > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > >
> > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > Makefile is followed.
> > >
> > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > maintainers are free to take this.
> > >
> > > Acked-by: Greg Kroah-Hartman <[email protected]>
> >
> > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > across, I already applied the first.
> >
> > Patrick: Follow up with incremental patch in case there's any difference.
> > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > you respin patches without following up on the previous version. Thanks!
>
> Not only that, but subthreads were cc:d to [email protected] and some
> were not, so I missed the overnight conversation on the topic.
>
> If this email thread is any indication of how the code will be
> flowing, there's definitely need for more structure. Joel, I'm hoping
> you'll coordinate.
To be honest, this patchset thread was a bit less clear than anyone
prefers. I use get_maintainers to get the initial list, and so adding
arm@ or soc@ per a request tells me that perhaps those should be
output via that script.
>
> I'm with Arnd on whether the code should be in drivers/soc or not --
> most of it likely should not.
I think the misc drivers for a SoC that are a single user interface
that is focused on the use-case that belongs to that SoC only belong
in soc/, while if there is something we can do in common -- different
story. If it makes sense to just have misc/aspeed/ instead of
soc/aspeed -- would that align more?
>
>
> -Olof
On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <[email protected]> wrote:
>
> On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <[email protected]> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > > > >
> > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > >
> > > > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > > > >
> > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > >
> > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > Makefile is followed.
> > > >
> > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > maintainers are free to take this.
> > > >
> > > > Acked-by: Greg Kroah-Hartman <[email protected]>
> > >
> > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > across, I already applied the first.
> > >
> > > Patrick: Follow up with incremental patch in case there's any difference.
> > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > you respin patches without following up on the previous version. Thanks!
> >
> > Not only that, but subthreads were cc:d to [email protected] and some
> > were not, so I missed the overnight conversation on the topic.
> >
> > If this email thread is any indication of how the code will be
> > flowing, there's definitely need for more structure. Joel, I'm hoping
> > you'll coordinate.
>
> To be honest, this patchset thread was a bit less clear than anyone
> prefers. I use get_maintainers to get the initial list, and so adding
> arm@ or soc@ per a request tells me that perhaps those should be
> output via that script.
The tools are working as expected, we normally don't take patches
directly to [email protected], we let them go in through platform
maintainers who then send it on to us.
> >
> > I'm with Arnd on whether the code should be in drivers/soc or not --
> > most of it likely should not.
>
> I think the misc drivers for a SoC that are a single user interface
> that is focused on the use-case that belongs to that SoC only belong
> in soc/, while if there is something we can do in common -- different
> story. If it makes sense to just have misc/aspeed/ instead of
> soc/aspeed -- would that align more?
Those views are how the "board file hell" started on 32-bit ARM too,
so we're definitely hesitant to jump to that conclusion without
knowing more about what's actually anticipated.
Do you happen to have an estimate on what kind of drivers are
needed/anticipated?
-Olof
On Mon, Apr 29, 2019 at 10:19 AM Olof Johansson <[email protected]> wrote:
>
> On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <[email protected]> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <[email protected]> wrote:
> > >
> > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
> > > >
> > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > > > > >
> > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > > >
> > > > > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > > > > >
> > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > > >
> > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > > Makefile is followed.
> > > > >
> > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > > maintainers are free to take this.
> > > > >
> > > > > Acked-by: Greg Kroah-Hartman <[email protected]>
> > > >
> > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > > across, I already applied the first.
> > > >
> > > > Patrick: Follow up with incremental patch in case there's any difference.
> > > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > > you respin patches without following up on the previous version. Thanks!
> > >
> > > Not only that, but subthreads were cc:d to [email protected] and some
> > > were not, so I missed the overnight conversation on the topic.
> > >
> > > If this email thread is any indication of how the code will be
> > > flowing, there's definitely need for more structure. Joel, I'm hoping
> > > you'll coordinate.
> >
> > To be honest, this patchset thread was a bit less clear than anyone
> > prefers. I use get_maintainers to get the initial list, and so adding
> > arm@ or soc@ per a request tells me that perhaps those should be
> > output via that script.
>
> The tools are working as expected, we normally don't take patches
> directly to [email protected], we let them go in through platform
> maintainers who then send it on to us.
Thanks for clarifying.
>
> > >
> > > I'm with Arnd on whether the code should be in drivers/soc or not --
> > > most of it likely should not.
> >
> > I think the misc drivers for a SoC that are a single user interface
> > that is focused on the use-case that belongs to that SoC only belong
> > in soc/, while if there is something we can do in common -- different
> > story. If it makes sense to just have misc/aspeed/ instead of
> > soc/aspeed -- would that align more?
>
> Those views are how the "board file hell" started on 32-bit ARM too,
> so we're definitely hesitant to jump to that conclusion without
> knowing more about what's actually anticipated.
>
>
> Do you happen to have an estimate on what kind of drivers are
> needed/anticipated?
There is a UART routing control driver for ASPEED that spawned my push
to soc/aspeed. The advice on that thread was to put such drivers
there. There's likely to be a few more control-focused aspeed
drivers.
For Nuvoton, we definitely expect some similar LPC control drivers.
Possibly an LPC snoop driver, similar to aspeed-lpc-snoop. This
supports the idea of creating some form of bmc subsystem as suggested
above (or in a different thread).
>
>
> -Olof
On Mon, Apr 29, 2019 at 10:12 AM Patrick Venture <[email protected]> wrote:
>
> On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
> >
> > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > > >
> > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > > >
> > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > currently present into this folder. These drivers are not generic part
> > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > >
> > > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > > >
> > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > >
> > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > Makefile is followed.
> > >
> > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > maintainers are free to take this.
> > >
> > > Acked-by: Greg Kroah-Hartman <[email protected]>
> >
> > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > across, I already applied the first.
>
> I think the issue here was that I added to the CC list another email
> and so you may see the v2 without that mailing list, and a v2 with it
> --
>
> Does this require a v3? I honestly didn't think so, but this was the
> first time I had to add more people without needing other changes.
Well, v2 doesn't build. I'll fix it up locally by adding an 'endmenu'
to drivers/soc/aspeed/Kconfig. But... brings up questions how this was
tested before submitting?
scripts/kconfig/conf --allnoconfig Kconfig
drivers/soc/Kconfig:24: 'menu' in different file than 'menu'
drivers/soc/aspeed/Kconfig:1: location of the 'menu'
drivers/Kconfig:233: 'menu' in different file than 'menu'
drivers/soc/aspeed/Kconfig:1: location of the 'menu'
<none>:34: syntax error
> >
> > Patrick: Follow up with incremental patch in case there's any difference.
> > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > you respin patches without following up on the previous version. Thanks!
>
> w.r.t this patch series. I found an issue with v1, and released a v2
> with the detail of what changed. I thought that was the correct
> approach. I apologize for creating extra work, that's something
> nobody needs.
It's ok to submit newer versions, but it's convenient when they get
threaded also in non-gmail mail readers (by using in-reply-to).
-Olof
On Mon, Apr 29, 2019 at 12:27 PM Olof Johansson <[email protected]> wrote:
>
> On Mon, Apr 29, 2019 at 10:12 AM Patrick Venture <[email protected]> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > > > >
> > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > >
> > > > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > > > >
> > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > >
> > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > Makefile is followed.
> > > >
> > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > maintainers are free to take this.
> > > >
> > > > Acked-by: Greg Kroah-Hartman <[email protected]>
> > >
> > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > across, I already applied the first.
> >
> > I think the issue here was that I added to the CC list another email
> > and so you may see the v2 without that mailing list, and a v2 with it
> > --
> >
> > Does this require a v3? I honestly didn't think so, but this was the
> > first time I had to add more people without needing other changes.
>
> Well, v2 doesn't build. I'll fix it up locally by adding an 'endmenu'
> to drivers/soc/aspeed/Kconfig. But... brings up questions how this was
> tested before submitting?
That's a lost change issue. I'll try to be more diligent in the
future. My dev workspace is disconnected from the kernel used for
upstreaming patches, so if i make a change in one it isn't always
reflected in the other. I'm working on rectifying the underlying
build space issue to let me use the same repo.
>
> scripts/kconfig/conf --allnoconfig Kconfig
> drivers/soc/Kconfig:24: 'menu' in different file than 'menu'
> drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> drivers/Kconfig:233: 'menu' in different file than 'menu'
> drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> <none>:34: syntax error
>
> > >
> > > Patrick: Follow up with incremental patch in case there's any difference.
> > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > you respin patches without following up on the previous version. Thanks!
> >
> > w.r.t this patch series. I found an issue with v1, and released a v2
> > with the detail of what changed. I thought that was the correct
> > approach. I apologize for creating extra work, that's something
> > nobody needs.
>
> It's ok to submit newer versions, but it's convenient when they get
> threaded also in non-gmail mail readers (by using in-reply-to).
Roger that.
>
>
> -Olof
On Mon, Apr 29, 2019 at 12:35 PM Patrick Venture <[email protected]> wrote:
>
> On Mon, Apr 29, 2019 at 12:27 PM Olof Johansson <[email protected]> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:12 AM Patrick Venture <[email protected]> wrote:
> > >
> > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <[email protected]> wrote:
> > > >
> > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <[email protected]> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <[email protected]> wrote:
> > > > > > > >
> > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > > >
> > > > > > > > Signed-off-by: Patrick Venture <[email protected]>
> > > > > > >
> > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > > >
> > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > > Makefile is followed.
> > > > >
> > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > > maintainers are free to take this.
> > > > >
> > > > > Acked-by: Greg Kroah-Hartman <[email protected]>
> > > >
> > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > > across, I already applied the first.
> > >
> > > I think the issue here was that I added to the CC list another email
> > > and so you may see the v2 without that mailing list, and a v2 with it
> > > --
> > >
> > > Does this require a v3? I honestly didn't think so, but this was the
> > > first time I had to add more people without needing other changes.
> >
> > Well, v2 doesn't build. I'll fix it up locally by adding an 'endmenu'
> > to drivers/soc/aspeed/Kconfig. But... brings up questions how this was
> > tested before submitting?
Thanks for fixing this for me, and I apologize for the nuisance of it.
>
> That's a lost change issue. I'll try to be more diligent in the
> future. My dev workspace is disconnected from the kernel used for
> upstreaming patches, so if i make a change in one it isn't always
> reflected in the other. I'm working on rectifying the underlying
> build space issue to let me use the same repo.
>
> >
> > scripts/kconfig/conf --allnoconfig Kconfig
> > drivers/soc/Kconfig:24: 'menu' in different file than 'menu'
> > drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> > drivers/Kconfig:233: 'menu' in different file than 'menu'
> > drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> > <none>:34: syntax error
> >
> > > >
> > > > Patrick: Follow up with incremental patch in case there's any difference.
> > > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > > you respin patches without following up on the previous version. Thanks!
> > >
> > > w.r.t this patch series. I found an issue with v1, and released a v2
> > > with the detail of what changed. I thought that was the correct
> > > approach. I apologize for creating extra work, that's something
> > > nobody needs.
> >
> > It's ok to submit newer versions, but it's convenient when they get
> > threaded also in non-gmail mail readers (by using in-reply-to).
>
> Roger that.
>
> >
> >
> > -Olof