[alsa-devel] [PATCH 0/4] Decouple X86_32 dependency from the ISA Kconfig option
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(-)
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
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
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
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
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);
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
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; }
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
* 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
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
* 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
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
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
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
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
participants (5)
-
Greg KH -
Ingo Molnar -
Rafael J. Wysocki -
Takashi Iwai -
William Breathitt Gray