On Fri, Aug 16, 2019 at 12:19:42AM +0200, Max Staudt wrote:
> On 08/15/2019 02:58 PM, Max Staudt wrote:
> > - if (of_node) {
> > - ret = of_property_read_u32_array(of_node, "lltc,meas-mode",
> > -data->mode, 2);
> > + if (i2c->dev.of_node
On 08/15/2019 08:33 PM, Guenter Roeck wrote:
> On Thu, Aug 15, 2019 at 02:58:01PM +0200, Max Staudt wrote:
>> ltc2990 will now use device_property_read_u32_array() instead of
>> of_property_read_u32_array() - allowing the use of software nodes
>> via fwnode_create_software_node().
>>
>> This
On Thu, Aug 15, 2019 at 02:58:01PM +0200, Max Staudt wrote:
> ltc2990 will now use device_property_read_u32_array() instead of
> of_property_read_u32_array() - allowing the use of software nodes
> via fwnode_create_software_node().
>
> This allows code using i2c_new_device() to specify a default
This is the i2c-icy driver for the ICY board for Amiga computers.
It connects a PCF8584 I2C controller to the Zorro bus, providing I2C
connectivity. The original documentation can be found on Aminet:
https://aminet.net/package/docs/hard/icy
IRQ support is currently not implemented, as
Since the 2019 a1k.org community re-print of these PCBs sports an
LTC2990 hwmon chip as an example use case, let this driver autoprobe
for that as well. If it is present, modprobing ltc2990 is sufficient.
The property_entry enables the three additional inputs available on
this particular board:
ltc2990 will now use device_property_read_u32_array() instead of
of_property_read_u32_array() - allowing the use of software nodes
via fwnode_create_software_node().
This allows code using i2c_new_device() to specify a default
measurement mode for the LTC2990.
Signed-off-by: Max Staudt
---
> The callback, just like getclock(), is from the existing i2c-algo-pcf,
> which I don't want to touch right now. So I'm afraid it has to stay,
> even if it returns a fixed number.
Sure. I was just thinking loud and did not expect you to do it. Maybe I
will do it once your driver is upstream.
>
On 08/15/2019 02:04 PM, Wolfram Sang wrote:
>> When the PCF8584 is addressed as slave, this register
>> must be loaded with the 7-bit I 2 C-bus address to which the
>> PCF8584 is to respond. During initialization, the own
>> address register S0' must be written to, regardless
>> whether
> My suggestion is to not touch i2c-elektor at all for now, and remove
> the 'clock' parameter from the first iteration of i2c-icy. It can be
> added back in case someone complains, which I deem unlikely.
Full ack.
> When the PCF8584 is addressed as slave, this register
> must be loaded
On 08/15/2019 01:48 PM, Wolfram Sang wrote:
>> Well, the other option is to remove it, and then add it back once
>> somebody complains - which is unlikely to happen. The clock parameter
>> is PCF8584 specific anyway, and I think removing it is a good option,
>
> My suggestion is to do that
> Well, the other option is to remove it, and then add it back once
> somebody complains - which is unlikely to happen. The clock parameter
> is PCF8584 specific anyway, and I think removing it is a good option,
My suggestion is to do that incrementally. First, get your driver
accepted. Second,
On 08/15/2019 09:12 AM, Wolfram Sang wrote:
>> I kept it in because i2c-elektor also exposes it in the same way, and
>> it seems useful.
>
> Yeah, I noticed. I don't know how useful it is in practice (same for the
> getown callback) but I don't have better ideas, so let's just keep this
> to be
> I kept it in because i2c-elektor also exposes it in the same way, and
> it seems useful.
Yeah, I noticed. I don't know how useful it is in practice (same for the
getown callback) but I don't have better ideas, so let's just keep this
to be consistent.
> > Your SPDX header says GPL 2.0 only.
>
13 matches
Mail list logo
