Decouple X86_32 dependency from the ISA Kconfig 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.

Cc Rafael J. Wysocki <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

---
  drivers/pnp/pnpbios/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

drivers/pnp/pnpbios/Kconfig +1 -1

index 50c3dd0..a786086 100644
@@ -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

Quoted 7 lines · 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.

Quoted 2 lines

Cc Rafael J. Wysocki <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

Has anyone taken care of this already?

If not, can you possibly resend this patch with a CC to [email protected] so I can pick it up via Patchwork more easily?

Quoted 7 lines · 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.

Quoted 2 lines

Cc Rafael J. Wysocki <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

Has anyone taken care of this already?

If not, can you possibly resend this patch with a CC to [email protected] so I can pick it up via Patchwork more easily?

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 <[email protected]>

Cc Takashi Iwai <[email protected]>

Signed-off-by William Breathitt Gray <[email protected]>

---
 sound/isa/sscape.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/isa/sscape.c +1 -1

index 7b248cd..fdcfa29 100644
@@ -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);

Signature · 6 lines

2.7.3

_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

Quoted 5 lines · Ingo Molnar

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 <[email protected]>

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

Thanks,

Ingo

Quoted 5 lines · Ingo Molnar

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:

Quoted 7 lines

Acked-by Ingo Molnar <[email protected]>

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.

Quoted 14 lines · William Breathitt Gray

Quoted 5 lines · Ingo Molnar

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:

Quoted 7 lines

Acked-by Ingo Molnar <[email protected]>

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

Thanks,

Ingo

Quoted 7 lines

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

Quoted 25 lines · Greg KH

Quoted 14 lines · William Breathitt Gray

Quoted 5 lines · Ingo Molnar

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:

Quoted 7 lines

Acked-by Ingo Molnar <[email protected]>

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

Thanks,

Ingo

Quoted 7 lines

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.

Quoted 3 lines

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.