Hi,
Tal Shorer <tal.shorer@xxxxxxxxx> writes:
> struct ulpi_ops is defined as follows:
>
> struct ulpi_ops {
> struct device *dev;
> int (*read)(struct ulpi_ops *ops, u8 addr);
> int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
> };
>
> Upon calling ulpi_register_interface(), the struct device argument is
> put inside the struct ulpi_ops argument's dev field. Later, when
> calling the actual read()/write() operations, the struct ulpi_ops is
> passed to them and they use the stored device to access whatever
> private data they need.
>
> This means that if one wishes to reuse the same oprations for multiple
> interfaces (e.g if we have multiple instances of the same controller),
> any but the last interface registered will not operate properly (and
> the one that does work will be at the mercy of the others to not mess
> it up).
>
> I understand that barely any driver uses this bus right now, but I
> suppose it's there to be used at some point. We might as well fix the
> design here before we hit this bug.
>
> I would like to create a patch series to fix this by passing the given
> struct device directly to the operation functions via ulpi->dev.parent
> in ulpi_read() and ulpi_write(), but I'm not sure about the correct
> order of the patches that make such a series. Do I change the api and
> all users in one patch? one patch for api and one for each user?
>
> Any comments and guidelines are welcome :)
add new ->read_dev() and ->write_dev() methods which take a struct
device * as argument. Change users to new API, then remove old API and
later rename everybody back to ->read()/->write() (removing the extra
_dev) argument.
Another option would be to start by renaming current API to
->read_deprecated/->write_deprecated, adding new ->read/->write and the
rest is the same.
Either way, you shouldn't break anything along the way and make sure you
use lots of grepping to make sure there are no regressions.
--
balbi
Attachment:
signature.asc
Description: PGP signature
