> The use of the 'readl' and 'writel' identifiers here causes build errors on
> architectures where those are macros. This renames the fields to
> read32/write32
> to avoid the problem.
Thanks. I'll apply the same to my repo and related drivers.
Acked-by: Alessandro Rubini
/alessandro
--
To u
On Wednesday 12 June 2013 09:13:36 Alessandro Rubini wrote:
> + */
> +struct fmc_operations {
> + uint32_t (*readl)(struct fmc_device *fmc, int offset);
> + void (*writel)(struct fmc_device *fmc, uint32_t value, int offset);
> + int (*validate)(struct fmc_device *fmc, struct fmc_d
On Tue, Jun 18, 2013 at 01:29:02AM +0200, Alessandro Rubini wrote:
> > Any way you can use MODULE_DEVICE_TABLE() for these devices to get
> > proper module auto-loading for your drivers?
>
> It's the next step.
Ok, good.
> We are not doing that in our installations because it is not a trivial
>
> Any way you can use MODULE_DEVICE_TABLE() for these devices to get
> proper module auto-loading for your drivers?
It's the next step.
We are not doing that in our installations because it is not a trivial
addition to running kernels -- we are plugging FMC devices in
already-deployed kernel vers
On Wed, Jun 12, 2013 at 09:13:36AM +0200, Alessandro Rubini wrote:
> +/*
> + * The device reports all information needed to access hw.
> + *
> + * If we have eeprom_len and not contents, the core reads it.
> + * Then, parsing of identifiers is done by the core which fills fmc_fru_id..
> + * Similar
5 matches
Mail list logo
