[PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[William Breathitt Gray]

This patchset is based on top of commit 3a3a5fece6f2 ("fs: kernfs: Replace
CURRENT_TIME by current_fs_time()") of the driver-core-testing branch of
the driver-core repository.

The introduction of the ISA_BUS option in commit b3c1be1b789c
("base: isa: Remove X86_32 dependency") blocks the compilation of ISA
drivers on non-x86 platforms. The ISA_BUS configuration option should not
be necessary if the X86_32 dependency can be decoupled from the ISA
configuration option. This patchset both removes the ISA_BUS configuration
option entirely and decouples the X86_32 dependency from the ISA
configuration option.

The PNPBIOS driver requires preprocessor defines (located in
include/asm/segment.h) only declared if the architecture is set to X86_32.
If the architecture is set to X86_64, the PNPBIOS driver will not build
properly. The X86 dependecy for the PNPBIOS configuration option is changed
to an explicit X86_32 dependency in order to prevent an attempt to build
for an unsupported architecture.

Changes to the ISA SSCAPE and SCSI ULTRASTOR drivers are also included. The
relevant patches simply fix format string identifier mismatches exposed
during an attempted X86_64 compilation after the decoupling of the X86_32
dependency from the ISA configuration option. These patches fix compilation
warnings rather than errors, but the solutions were so trivial that I
decided to include them in this patchset. If it would be inappropriate to
include them in this patchset, let me know and I will rebase to remove the
relevant patches.

William Breathitt Gray (4):
  pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS
  sound: isa: sscape: Use correct format identifier for size_t
  scsi: ultrastor: Use correct format identifier for kernel pointer
  isa: Remove the ISA_BUS Kconfig option

 arch/x86/Kconfig            | 10 ++--------
 drivers/base/Makefile       |  2 +-
 drivers/pnp/pnpbios/Kconfig |  2 +-
 drivers/scsi/ultrastor.c    |  8 ++++----
 include/linux/isa.h         |  2 +-
 sound/isa/sscape.c          |  2 +-
 6 files changed, 10 insertions(+), 16 deletions(-)

-- 
2.7.3

[PATCH 1/4] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

[William Breathitt Gray]

The PNPBIOS driver requires preprocessor defines (located in
include/asm/segment.h) only declared if the architecture is set to
X86_32. If the architecture is set to X86_64, the PNPBIOS driver will
not build properly. The X86 dependecy for the PNPBIOS configuration
option is changed to an explicit X86_32	dependency in order to prevent
an attempt to build for an unsupported architecture.

Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/pnp/pnpbios/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pnp/pnpbios/Kconfig b/drivers/pnp/pnpbios/Kconfig
index 50c3dd0..a786086 100644
--- a/drivers/pnp/pnpbios/Kconfig
+++ b/drivers/pnp/pnpbios/Kconfig
@@ -3,7 +3,7 @@
 #
 config PNPBIOS
 	bool "Plug and Play BIOS support"
-	depends on ISA && X86
+	depends on ISA && X86_32
 	default n
 	---help---
 	  Linux uses the PNPBIOS as defined in "Plug and Play BIOS
-- 
2.7.3

[PATCH 2/4] sound: isa: sscape: Use correct format identifier for size_t

[William Breathitt Gray]

The 'size' member of a struct firmware is passed to snd_printk with a
respective format string using the %d identifier. The 'size' member is
of type size_t, but format identifier %d indicates a signed int data
type. This patch replaces the %d format identifier with the correct %zu
format identifier for size_t data types.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 sound/isa/sscape.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
index 7b248cd..fdcfa29 100644
--- a/sound/isa/sscape.c
+++ b/sound/isa/sscape.c
@@ -591,7 +591,7 @@ static int sscape_upload_microcode(struct snd_card *card, int version)
 	}
 	err = upload_dma_data(sscape, init_fw->data, init_fw->size);
 	if (err == 0)
-		snd_printk(KERN_INFO "sscape: MIDI firmware loaded %d KBs\n",
+		snd_printk(KERN_INFO "sscape: MIDI firmware loaded %zu KBs\n",
 				init_fw->size >> 10);
 
 	release_firmware(init_fw);
-- 
2.7.3

[PATCH 3/4] scsi: ultrastor: Use correct format identifier for kernel pointer

[William Breathitt Gray]

The 'bios_segment' member of a struct ultrastor_config is passed to the
sprintf function with a respective %05X format identifier. The
'bio_segment' member is a kernel pointer, but the %X format identifier
expects an int data type. A cast to int is correctly used to satisfy the
format identifier, but this assumes that the int data type is the same
size as the kernel pointer, which is not the case on several
architectures such as X86_64. This patch removes the int cast and
replaces the %05X format identifier with %pK in order to print the
'bio_segment' member regardless of architecture.

Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/scsi/ultrastor.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ultrastor.c b/drivers/scsi/ultrastor.c
index 14e0c40..2e99f98 100644
--- a/drivers/scsi/ultrastor.c
+++ b/drivers/scsi/ultrastor.c
@@ -670,12 +670,12 @@ static const char *ultrastor_info(struct Scsi_Host * shpnt)
       sprintf(buf, "UltraStor 24F SCSI @ Slot %u IRQ%u",
 	      config.slot, config.interrupt);
     else if (config.subversion)
-      sprintf(buf, "UltraStor 34F SCSI @ Port %03X BIOS %05X IRQ%u",
-	      config.port_address, (int)config.bios_segment,
+      sprintf(buf, "UltraStor 34F SCSI @ Port %03X BIOS %pK IRQ%u",
+	      config.port_address, config.bios_segment,
 	      config.interrupt);
     else
-      sprintf(buf, "UltraStor 14F SCSI @ Port %03X BIOS %05X IRQ%u DMA%u",
-	      config.port_address, (int)config.bios_segment,
+      sprintf(buf, "UltraStor 14F SCSI @ Port %03X BIOS %pK IRQ%u DMA%u",
+	      config.port_address, config.bios_segment,
 	      config.interrupt, config.dma_channel);
     return buf;
 }
-- 
2.7.3

[PATCH 4/4] isa: Remove the ISA_BUS Kconfig option

[William Breathitt Gray]

The introduction of the ISA_BUS option blocks the compilation of ISA
drivers on non-x86 platforms. The ISA_BUS configuration option should
not be necessary if the X86_32 dependency can be decoupled from the ISA
configuration option. This patch both removes the ISA_BUS configuration
option entirely and removes the X86_32 dependency from the ISA
configuration option.

Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 arch/x86/Kconfig      | 10 ++--------
 drivers/base/Makefile |  2 +-
 include/linux/isa.h   |  2 +-
 3 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a597798..280e5eb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2472,16 +2472,8 @@ config ISA_DMA_API
 	  Enables ISA-style DMA support for devices requiring such controllers.
 	  If unsure, say Y.
 
-config ISA_BUS
-	bool "ISA bus support"
-	help
-	  Enables ISA bus support for devices requiring such controllers.
-
-if X86_32
-
 config ISA
 	bool "ISA support"
-	depends on ISA_BUS
 	---help---
 	  Find out whether you have ISA slots on your motherboard.  ISA is the
 	  name of a bus system, i.e. the way the CPU talks to the other stuff
@@ -2489,6 +2481,8 @@ config ISA
 	  (MCA) or VESA.  ISA is an older system, now being displaced by PCI;
 	  newer boards don't support it.  If you have ISA, say Y, otherwise N.
 
+if X86_32
+
 config EISA
 	bool "EISA support"
 	depends on ISA
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4ebfb81..6b2a84e 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_ISA_BUS)	+= isa.o
+obj-$(CONFIG_ISA)	+= isa.o
 obj-$(CONFIG_FW_LOADER)	+= firmware_class.o
 obj-$(CONFIG_NUMA)	+= node.o
 obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
diff --git a/include/linux/isa.h b/include/linux/isa.h
index 2a02862..b0270e3 100644
--- a/include/linux/isa.h
+++ b/include/linux/isa.h
@@ -22,7 +22,7 @@ struct isa_driver {
 
 #define to_isa_driver(x) container_of((x), struct isa_driver, driver)
 
-#ifdef CONFIG_ISA_BUS
+#ifdef CONFIG_ISA
 int isa_register_driver(struct isa_driver *, unsigned int);
 void isa_unregister_driver(struct isa_driver *);
 #else
-- 
2.7.3

Re: [alsa-devel] [PATCH 2/4] sound: isa: sscape: Use correct format identifier for size_t

[Takashi Iwai]

On Mon, 11 Apr 2016 15:25:52 +0200,
William Breathitt Gray wrote:
> 
> The 'size' member of a struct firmware is passed to snd_printk with a
> respective format string using the %d identifier. The 'size' member is
> of type size_t, but format identifier %d indicates a signed int data
> type. This patch replaces the %d format identifier with the correct %zu
> format identifier for size_t data types.
> 
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>

This is basically irrelevant from ISA issue you're trying to solve, so
I'm going to apply this one individually to my tree.


thanks,

Takashi

> ---
>  sound/isa/sscape.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
> index 7b248cd..fdcfa29 100644
> --- a/sound/isa/sscape.c
> +++ b/sound/isa/sscape.c
> @@ -591,7 +591,7 @@ static int sscape_upload_microcode(struct snd_card *card, int version)
>  	}
>  	err = upload_dma_data(sscape, init_fw->data, init_fw->size);
>  	if (err == 0)
> -		snd_printk(KERN_INFO "sscape: MIDI firmware loaded %d KBs\n",
> +		snd_printk(KERN_INFO "sscape: MIDI firmware loaded %zu KBs\n",
>  				init_fw->size >> 10);
>  
>  	release_firmware(init_fw);
> -- 
> 2.7.3
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [PATCH 2/4] sound: isa: sscape: Use correct format identifier for size_t

[Takashi Iwai]

On Mon, 11 Apr 2016 15:25:52 +0200,
William Breathitt Gray wrote:
> 
> The 'size' member of a struct firmware is passed to snd_printk with a
> respective format string using the %d identifier. The 'size' member is
> of type size_t, but format identifier %d indicates a signed int data
> type. This patch replaces the %d format identifier with the correct %zu
> format identifier for size_t data types.
> 
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>

This is basically irrelevant from ISA issue you're trying to solve, so
I'm going to apply this one individually to my tree.


thanks,

Takashi

> ---
>  sound/isa/sscape.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
> index 7b248cd..fdcfa29 100644
> --- a/sound/isa/sscape.c
> +++ b/sound/isa/sscape.c
> @@ -591,7 +591,7 @@ static int sscape_upload_microcode(struct snd_card *card, int version)
>  	}
>  	err = upload_dma_data(sscape, init_fw->data, init_fw->size);
>  	if (err == 0)
> -		snd_printk(KERN_INFO "sscape: MIDI firmware loaded %d KBs\n",
> +		snd_printk(KERN_INFO "sscape: MIDI firmware loaded %zu KBs\n",
>  				init_fw->size >> 10);
>  
>  	release_firmware(init_fw);
> -- 
> 2.7.3
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[Ingo Molnar]

* William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> This patchset is based on top of commit 3a3a5fece6f2 ("fs: kernfs: Replace
> CURRENT_TIME by current_fs_time()") of the driver-core-testing branch of
> the driver-core repository.
> 
> The introduction of the ISA_BUS option in commit b3c1be1b789c
> ("base: isa: Remove X86_32 dependency") blocks the compilation of ISA
> drivers on non-x86 platforms. The ISA_BUS configuration option should not
> be necessary if the X86_32 dependency can be decoupled from the ISA
> configuration option. This patchset both removes the ISA_BUS configuration
> option entirely and decouples the X86_32 dependency from the ISA
> configuration option.
> 
> The PNPBIOS driver requires preprocessor defines (located in
> include/asm/segment.h) only declared if the architecture is set to X86_32.
> If the architecture is set to X86_64, the PNPBIOS driver will not build
> properly. The X86 dependecy for the PNPBIOS configuration option is changed
> to an explicit X86_32 dependency in order to prevent an attempt to build
> for an unsupported architecture.
> 
> Changes to the ISA SSCAPE and SCSI ULTRASTOR drivers are also included. The
> relevant patches simply fix format string identifier mismatches exposed
> during an attempted X86_64 compilation after the decoupling of the X86_32
> dependency from the ISA configuration option. These patches fix compilation
> warnings rather than errors, but the solutions were so trivial that I
> decided to include them in this patchset. If it would be inappropriate to
> include them in this patchset, let me know and I will rebase to remove the
> relevant patches.
> 
> William Breathitt Gray (4):
>   pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS
>   sound: isa: sscape: Use correct format identifier for size_t
>   scsi: ultrastor: Use correct format identifier for kernel pointer
>   isa: Remove the ISA_BUS Kconfig option
> 
>  arch/x86/Kconfig            | 10 ++--------
>  drivers/base/Makefile       |  2 +-
>  drivers/pnp/pnpbios/Kconfig |  2 +-
>  drivers/scsi/ultrastor.c    |  8 ++++----
>  include/linux/isa.h         |  2 +-
>  sound/isa/sscape.c          |  2 +-
>  6 files changed, 10 insertions(+), 16 deletions(-)

What's the practical motivation of this? What exact hardware is this for?

Thanks,

	Ingo

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[William Breathitt Gray]

On Wed, Apr 13, 2016 at 09:26:02AM +0200, Ingo Molnar wrote:
>What's the practical motivation of this? What exact hardware is this for?
>
>Thanks,
>
>	Ingo

The PC/104 bus is equivalent to the ISA bus regarding software
communication. Many small form factor systems have a PC/104 bus where
PC/104 cards may be stacked. Nowadays, these systems are commonly
running 64-bit processors such as the Intel Atom.

I would like to utilize the ISA bus driver to support these PC/104
devices (see http://lkml.org/lkml/2016/4/7/418), but the ISA
configuration option has an arbitrary X86_32 dependency. Decoupling the
X86_32 dependency from the ISA configuration option will allow these
PC/104 drivers to build for 64-bit architectures.

The existing kernel drivers which I intend to utilize the ISA bus driver
in a X86_64 architecture for PC/104 support are the ACCES 104-DIO-48E
GPIO driver, the ACCES 104-IDI-48 GPIO driver, the ACCES 104-IDIO-16
GPIO driver, and the Apex Embedded Systems STX104 DAC driver. I have
several more PC/104 devices for which I wish to write drivers, but I
would like to resolve this ISA bus driver situation before submitting
new code.

William Breathitt Gray

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[Ingo Molnar]

* William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> On Wed, Apr 13, 2016 at 09:26:02AM +0200, Ingo Molnar wrote:
> >What's the practical motivation of this? What exact hardware is this for?
> >
> >Thanks,
> >
> >	Ingo
> 
> The PC/104 bus is equivalent to the ISA bus regarding software
> communication. Many small form factor systems have a PC/104 bus where
> PC/104 cards may be stacked. Nowadays, these systems are commonly
> running 64-bit processors such as the Intel Atom.
> 
> I would like to utilize the ISA bus driver to support these PC/104
> devices (see http://lkml.org/lkml/2016/4/7/418), but the ISA
> configuration option has an arbitrary X86_32 dependency. Decoupling the
> X86_32 dependency from the ISA configuration option will allow these
> PC/104 drivers to build for 64-bit architectures.
> 
> The existing kernel drivers which I intend to utilize the ISA bus driver
> in a X86_64 architecture for PC/104 support are the ACCES 104-DIO-48E
> GPIO driver, the ACCES 104-IDI-48 GPIO driver, the ACCES 104-IDIO-16
> GPIO driver, and the Apex Embedded Systems STX104 DAC driver. I have
> several more PC/104 devices for which I wish to write drivers, but I
> would like to resolve this ISA bus driver situation before submitting
> new code.

Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
want to put that info into the boilerplate mail or so.

I'm perfectly fine with all the patches that touch x86 code:

  Acked-by: Ingo Molnar <mingo@kernel.org>

I suppose you'd like to have these in the driver tree, all in one place?

Thanks,

	Ingo

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[Ingo Molnar]

* William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> On Wed, Apr 13, 2016 at 09:26:02AM +0200, Ingo Molnar wrote:
> >What's the practical motivation of this? What exact hardware is this for?
> >
> >Thanks,
> >
> >	Ingo
> 
> The PC/104 bus is equivalent to the ISA bus regarding software
> communication. Many small form factor systems have a PC/104 bus where
> PC/104 cards may be stacked. Nowadays, these systems are commonly
> running 64-bit processors such as the Intel Atom.
> 
> I would like to utilize the ISA bus driver to support these PC/104
> devices (see http://lkml.org/lkml/2016/4/7/418), but the ISA
> configuration option has an arbitrary X86_32 dependency. Decoupling the
> X86_32 dependency from the ISA configuration option will allow these
> PC/104 drivers to build for 64-bit architectures.
> 
> The existing kernel drivers which I intend to utilize the ISA bus driver
> in a X86_64 architecture for PC/104 support are the ACCES 104-DIO-48E
> GPIO driver, the ACCES 104-IDI-48 GPIO driver, the ACCES 104-IDIO-16
> GPIO driver, and the Apex Embedded Systems STX104 DAC driver. I have
> several more PC/104 devices for which I wish to write drivers, but I
> would like to resolve this ISA bus driver situation before submitting
> new code.

Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
want to put that info into the boilerplate mail or so.

I'm perfectly fine with all the patches that touch x86 code:

  Acked-by: Ingo Molnar <mingo@kernel.org>

I suppose you'd like to have these in the driver tree, all in one place?

Thanks,

	Ingo

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[William Breathitt Gray]

On Wed, Apr 13, 2016 at 04:38:38PM +0200, Ingo Molnar wrote:
>Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
>want to put that info into the boilerplate mail or so.
>
>I'm perfectly fine with all the patches that touch x86 code:
>
>  Acked-by: Ingo Molnar <mingo@kernel.org>
>
>I suppose you'd like to have these in the driver tree, all in one place?
>
>Thanks,
>
>	Ingo

Ah yes, in retrospect I should have made it clear that this was for
supporting hardware rather than simply code cleanup. That was an
oversight on my part not to have made it more explicit.

Introducing everything to the driver tree would be most convenient, thus
allowing me to quickly release my subsequent patches which will be
rebased on top of these.

William Breathitt Gray

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[Greg KH]

On Wed, Apr 13, 2016 at 10:48:42AM -0400, William Breathitt Gray wrote:
> On Wed, Apr 13, 2016 at 04:38:38PM +0200, Ingo Molnar wrote:
> >Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
> >want to put that info into the boilerplate mail or so.
> >
> >I'm perfectly fine with all the patches that touch x86 code:
> >
> >  Acked-by: Ingo Molnar <mingo@kernel.org>
> >
> >I suppose you'd like to have these in the driver tree, all in one place?
> >
> >Thanks,
> >
> >	Ingo
> 
> Ah yes, in retrospect I should have made it clear that this was for
> supporting hardware rather than simply code cleanup. That was an
> oversight on my part not to have made it more explicit.
> 
> Introducing everything to the driver tree would be most convenient, thus
> allowing me to quickly release my subsequent patches which will be
> rebased on top of these.

Ok, I can take these.

thanks,

greg k-h

Re: [PATCH 1/4] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

[Rafael J. Wysocki]

On 4/11/2016 3:25 PM, William Breathitt Gray wrote:
> The PNPBIOS driver requires preprocessor defines (located in
> include/asm/segment.h) only declared if the architecture is set to
> X86_32. If the architecture is set to X86_64, the PNPBIOS driver will
> not build properly. The X86 dependecy for the PNPBIOS configuration
> option is changed to an explicit X86_32	dependency in order to prevent
> an attempt to build for an unsupported architecture.
>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>

Has anyone taken care of this already?

If not, can you possibly resend this patch with a CC to 
linux-acpi@vger.kernel.org so I can pick it up via Patchwork more easily?

> ---
>   drivers/pnp/pnpbios/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pnp/pnpbios/Kconfig b/drivers/pnp/pnpbios/Kconfig
> index 50c3dd0..a786086 100644
> --- a/drivers/pnp/pnpbios/Kconfig
> +++ b/drivers/pnp/pnpbios/Kconfig
> @@ -3,7 +3,7 @@
>   #
>   config PNPBIOS
>   	bool "Plug and Play BIOS support"
> -	depends on ISA && X86
> +	depends on ISA && X86_32
>   	default n
>   	---help---
>   	  Linux uses the PNPBIOS as defined in "Plug and Play BIOS

Re: [PATCH 1/4] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

[William Breathitt Gray]

On Sat, Apr 23, 2016 at 01:51:19AM +0200, Rafael J. Wysocki wrote:
>On 4/11/2016 3:25 PM, William Breathitt Gray wrote:
>> The PNPBIOS driver requires preprocessor defines (located in
>> include/asm/segment.h) only declared if the architecture is set to
>> X86_32. If the architecture is set to X86_64, the PNPBIOS driver will
>> not build properly. The X86 dependecy for the PNPBIOS configuration
>> option is changed to an explicit X86_32	dependency in order to prevent
>> an attempt to build for an unsupported architecture.
>>
>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>
>Has anyone taken care of this already?
>
>If not, can you possibly resend this patch with a CC to 
>linux-acpi@vger.kernel.org so I can pick it up via Patchwork more easily?

Greg K-H,

Will this patch appear in the driver-core repository along with the
other patches in this set?

Thanks,

William Breathitt Gray

Re: [PATCH 1/4] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

[William Breathitt Gray]

On Sat, Apr 23, 2016 at 01:51:19AM +0200, Rafael J. Wysocki wrote:
>On 4/11/2016 3:25 PM, William Breathitt Gray wrote:
>> The PNPBIOS driver requires preprocessor defines (located in
>> include/asm/segment.h) only declared if the architecture is set to
>> X86_32. If the architecture is set to X86_64, the PNPBIOS driver will
>> not build properly. The X86 dependecy for the PNPBIOS configuration
>> option is changed to an explicit X86_32	dependency in order to prevent
>> an attempt to build for an unsupported architecture.
>>
>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>
>Has anyone taken care of this already?
>
>If not, can you possibly resend this patch with a CC to 
>linux-acpi@vger.kernel.org so I can pick it up via Patchwork more easily?

I'm not sure when this patchset will appear in driver-core, so I have
resent this particular patch with a CC to linux-acpi@vger.kernel.org so
that Rafael J. Wysocki can pick it up more easily.

William Breathitt Gray

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[William Breathitt Gray]

On Wed, Apr 13, 2016 at 08:18:26AM -0700, Greg KH wrote:
>On Wed, Apr 13, 2016 at 10:48:42AM -0400, William Breathitt Gray wrote:
>> On Wed, Apr 13, 2016 at 04:38:38PM +0200, Ingo Molnar wrote:
>> >Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
>> >want to put that info into the boilerplate mail or so.
>> >
>> >I'm perfectly fine with all the patches that touch x86 code:
>> >
>> >  Acked-by: Ingo Molnar <mingo@kernel.org>
>> >
>> >I suppose you'd like to have these in the driver tree, all in one place?
>> >
>> >Thanks,
>> >
>> >	Ingo
>> 
>> Ah yes, in retrospect I should have made it clear that this was for
>> supporting hardware rather than simply code cleanup. That was an
>> oversight on my part not to have made it more explicit.
>> 
>> Introducing everything to the driver tree would be most convenient, thus
>> allowing me to quickly release my subsequent patches which will be
>> rebased on top of these.
>
>Ok, I can take these.
>
>thanks,
>
>greg k-h

Forgive me for probing again; what is that status of this patchset? I'm
anxious to see them accepted to prevent the regression introduced by the
ISA_BUS configuration option from appearing in the next merge window.

Many thanks,

William Breathitt Gray

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[William Breathitt Gray]

On Wed, Apr 13, 2016 at 08:18:26AM -0700, Greg KH wrote:
>On Wed, Apr 13, 2016 at 10:48:42AM -0400, William Breathitt Gray wrote:
>> On Wed, Apr 13, 2016 at 04:38:38PM +0200, Ingo Molnar wrote:
>> >Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
>> >want to put that info into the boilerplate mail or so.
>> >
>> >I'm perfectly fine with all the patches that touch x86 code:
>> >
>> >  Acked-by: Ingo Molnar <mingo@kernel.org>
>> >
>> >I suppose you'd like to have these in the driver tree, all in one place?
>> >
>> >Thanks,
>> >
>> >	Ingo
>> 
>> Ah yes, in retrospect I should have made it clear that this was for
>> supporting hardware rather than simply code cleanup. That was an
>> oversight on my part not to have made it more explicit.
>> 
>> Introducing everything to the driver tree would be most convenient, thus
>> allowing me to quickly release my subsequent patches which will be
>> rebased on top of these.
>
>Ok, I can take these.
>
>thanks,
>
>greg k-h

Forgive me for probing again; what is that status of this patchset? I'm
anxious to see them accepted to prevent the regression introduced by the
ISA_BUS configuration option from appearing in the next merge window.

Many thanks,

William Breathitt Gray

Re: [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option

[Greg KH]

On Sun, May 01, 2016 at 12:17:07PM -0400, William Breathitt Gray wrote:
> On Wed, Apr 13, 2016 at 08:18:26AM -0700, Greg KH wrote:
> >On Wed, Apr 13, 2016 at 10:48:42AM -0400, William Breathitt Gray wrote:
> >> On Wed, Apr 13, 2016 at 04:38:38PM +0200, Ingo Molnar wrote:
> >> >Ah, ok, so it's for enabling real hardware, not just a cleanup, right? You might 
> >> >want to put that info into the boilerplate mail or so.
> >> >
> >> >I'm perfectly fine with all the patches that touch x86 code:
> >> >
> >> >  Acked-by: Ingo Molnar <mingo@kernel.org>
> >> >
> >> >I suppose you'd like to have these in the driver tree, all in one place?
> >> >
> >> >Thanks,
> >> >
> >> >	Ingo
> >> 
> >> Ah yes, in retrospect I should have made it clear that this was for
> >> supporting hardware rather than simply code cleanup. That was an
> >> oversight on my part not to have made it more explicit.
> >> 
> >> Introducing everything to the driver tree would be most convenient, thus
> >> allowing me to quickly release my subsequent patches which will be
> >> rebased on top of these.
> >
> >Ok, I can take these.
> >
> >thanks,
> >
> >greg k-h
> 
> Forgive me for probing again; what is that status of this patchset? I'm
> anxious to see them accepted to prevent the regression introduced by the
> ISA_BUS configuration option from appearing in the next merge window.

Not all of these patches had anything to do with the subject of this 0/4
patch, and seem to have gone in through other trees.

So can you resend just the patches that are for this series that have
not been picked up?

thanks,

greg k-h