Re: [lm-sensors] [RFT][PATCH 1/2] hwmon: (adm9240) Avoid forward declaration

[Guenter Roeck <linux@roeck-us.net>]

On 07/04/2014 01:20 PM, Jean Delvare wrote:
> Hi Guenter,
>
> On Fri, 04 Jul 2014 10:10:14 -0700, Guenter Roeck wrote:
>> On 07/04/2014 05:23 AM, Jean Delvare wrote:
>>> Note that support for banked registers could be added if you think this
>>> would help.
>>
>> That would be quite useful. How would you implement it, though ? You would have
>> to have a means to tell the driver "this is a bank register". Another module
>> parameter, maybe ?
>
> Not just "this is a bank register". You also most specify which bits
> set the bank number (which in turn define the maximum number of banks),
> and the range of banked registers.
>
> I did not think about it in depth yet, but there are two options that
> come to my mind: module parameters indeed, or sysfs attributes. We
> could create a sysfs directory for every client address and have
> writable attributes bank_reg, bank_mask, banked_start_reg and
> banked_end_reg in that directory. Not sure exactly where actually,
> maybe we would need to introduce a virtual i2c-stub device, or use
> debugfs.
>
> Module parameters would work too, that's probably easier to implement
> that way, but that's also less flexible, as you have to setup
> everything upon module loading. That might be just fine though, as
> being able to change the bank setup at run-time has little practical
> value IMHO.
>

Hi Jean,

At least with my module test scripts, I re-load  the i2c-stub driver
before testing a new chip, to make sure that its state is 'clean'.
So module parameters work just fine for me.

Could we use a single module parameter ?

bank_reg=<reg> <mask>

would probably do for a start, and mask could even be optional. Not sure
if banked_start_reg and banked_end_reg are necessary. If so the above
could be extended to

bank_reg=<reg> <mask> <start> <end>

That would not work for PMBus chips - those are so complex that
it is unlikely we'll ever be able to simulate one without much
more complexity - it would require the ability to return a failure
when trying to access unsupported registers/commands, and that
on each of the pages.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors