Initial Linux-wireless contribution

[Kalle Valo]

Eugene Krasnikov <k.eugene.e at gmail.com> writes:

> Could you please explain why do you think upstream will not accept
> that? wl12xx and ath9k are doing the same with "struct
> wl1271_if_operations" 

This is not coming from the board files, it's coming from internal spi
and sdio drivers:

drivers/net/wireless/ti/wlcore/sdio.c:static struct wl1271_if_operations sdio_ops = {
drivers/net/wireless/ti/wlcore/spi.c:static struct wl1271_if_operations spi_ops = {

> and "struct ath_bus_ops".

struct ath_bus_ops {
	enum ath_bus_type ath_bus_type;
	void (*read_cachesize)(struct ath_common *common, int *csz);
	bool (*eeprom_read)(struct ath_common *common, u32 off, u16 *data);
	int (*eeprom_read_mac)(struct ath5k_hw *ah, u8 *mac);
};

And that's just eeprom access, not the control path.

Of course it's possible that we can get the platform data SMD
abstractions into upstream, especially if nobody notices. But it's still
ugly.

I'm not able to come up with any better proposals either than
abstracting the SMD access or depending on ARCH_MSM, so I guess
abstracting them through platform data is the best choise. Or does
anyone have any other ideas?

-- 
Kalle Valo