Re: [PATCH]change 'struct device' -> platform_data to firmware_data

[Deepak Saxena]

On Jan 12 2005, at 10:57, Li Shaohua was caught saying:
> Hi,
> struct device->platform_data is designed for ACPI, BIOS or other
> platform specific data, but some drivers misused the field which makes
> adding ACPI handle in device core impossible. Greg suggested me changing
> the name of the filed and so it breaks all such drivers, and then fix
> them. I'll try to fix some, but it would be great if the driver authors
> could do it.

Whatever the original purpose of this field was, it is now in use by
several drivers for ARM systems where we need to support multiple SOCs
with slight variations and we use the platform_data field to pass 
board-specific information to the drivers. Before we had this, we were
putting ugly #ifdefs in drivers.  Examples of drivers using this
include:

- serial/8250.c. 

  platform_data points to a plat_serial8250_port structure that 
  provides per-serial port information such as capabilities and 
  uart clk rate.

- mtd/maps/various ARM drivers

  platform_data points to a flash_platform_data structure containing
  information such as bus width and function pointers for some init
  and shutdown work.

- i2c/busses/i2c-ixp4xx.c and i2c-ixp2000.c

  The IXP4xx and IXP2000 chips do not have an I2C controller and 
  use GPIO pins to create a bit-bang "adapter". What I2C lines to
  use is up to the board designer so we pass that information via 
  a custom data structure shared between the driver and the board
  level code that contains the GPIO lines to use for SCL and SDA.

  i2c-s3c2410.c also seems to use platform_data to pass board-specific
  information to the driver.

So the question I have is whether we are using the field as intended
or we have overloaded it with our own purposes?

If we are doing things incorrectly, I am not argueing that our usage
has to the way it sits. We could create a new generic serial_device and 
flash_device structures and subsystems for these, but that requires 
rewriting drivers and board ports; however, we need enough time
to work with appropriate subsystem maintainers to do so. My suggestion
is to add a new firmware_data field for use by ACPI ATM while we
clean things up in ARM world if so required.  Since ACPI is non-existent 
on ARM systems, another option is that we keep using the renamed data
structure as we have been doing. /me votes for this option

Thoughts?
~Deepak
 

-- 
Deepak Saxena - dsaxena@xxxxxxxxxxx - http://www.plexity.net

If you complain once more, you'll meet an army of me. - Bjork
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/