Hi Russell,
Thanks for your suggestions, I will change it accordingly.
> Searching the driver for "air_buckpbus_reg_read", there are four
> instances where you read-modify-write, and only one instance which is
> just a read.
>
> I wonder whether it would make more sense to structure the accessors as
>
> __air_buckpbus_set_address(phydev, addr)
> __air_buckpbus_read(phydev, *data)
> __air_buckpbus_write(phydev, data)
>
> which would make implementing reg_read, reg_write and reg_modify()
> easier, and the addition of reg_modify() means that (a) there are less
> bus cycles (through having to set the address twice) and (b) ensures
> that the read-modify-write can be done atomically on the bus. This
> assumes that reading data doesn't auto-increment the address (which
> you would need to check.)
I will see if I can change the code to:
__air_buckpbus_set_address(phydev, addr)
__air_buckpbus_read(phydev, *data)
__air_buckpbus_write(phydev, data)
air_buckpbus_reg_read()
air_buckpbus_reg_write()
air_buckpbus_reg_modify()
While not changing (except if (saved_page >= 0)):
__air_write_buf()
air_write_buf()
> While you only support 2500base-T, is there any reason not to use
> linkmode_adv_to_mii_10gbt_adv_t() ?
I will change it to use linkmode_adv_to_mii_10gbt_adv_t().
Best Regards,
Eric Woudstra
