linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux driver for IRPS5401 - status reg not found
@ 2020-03-30 11:33 Michal Simek
  2020-03-30 15:24 ` Guenter Roeck
  0 siblings, 1 reply; 14+ messages in thread
From: Michal Simek @ 2020-03-30 11:33 UTC (permalink / raw)
  To: Robert Hancock, Guenter Roeck; +Cc: linux-hwmon

Hi Robert and Guenter,

Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
I have checked that u-boot can detect that devices and read it.

ZynqMP> i2c probe
Valid chip addresses: 0C 13 14 20 43 44 74
ZynqMP> i2c md 13 0 10
0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
ZynqMP> i2c md 14 0 10
0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
ZynqMP> i2c md 43 0 10
0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
ZynqMP> i2c md 44 0 10
0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
ZynqMP>

Here is DT fragment which I use (it is under i2c mux)

185                         irps5401_43: irps5401@43 {
186                                 compatible = "infineon,irps5401";
187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
188                         };
189                         irps5401_4d: irps5401@44 {
190                                 compatible = "infineon,irps5401";
191                                 reg = <0x44>; /* pmbus / i2c 0x14 */
192                         };

I see that driver is used but with error.

[   37.553740] irps5401 3-0043: PMBus status register not found
[   37.559815] irps5401 3-0044: PMBus status register not found


That's why I want to check with you what could be the problem.

Also I would like to know if there is a way to disable it via any API.
One of this regulator is connected to another device which doesn't have
access to it. It means before powering up this device there is a need to
enable this power regulator. The best via any dedicated API.

Thanks,
Michal

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 11:33 Linux driver for IRPS5401 - status reg not found Michal Simek
@ 2020-03-30 15:24 ` Guenter Roeck
  2020-03-30 15:42   ` Robert Hancock
  2020-03-30 15:46   ` Michal Simek
  0 siblings, 2 replies; 14+ messages in thread
From: Guenter Roeck @ 2020-03-30 15:24 UTC (permalink / raw)
  To: Michal Simek, Robert Hancock; +Cc: linux-hwmon

On 3/30/20 4:33 AM, Michal Simek wrote:
> Hi Robert and Guenter,
> 
> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
> I have checked that u-boot can detect that devices and read it.
> 
> ZynqMP> i2c probe
> Valid chip addresses: 0C 13 14 20 43 44 74
> ZynqMP> i2c md 13 0 10
> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
> ZynqMP> i2c md 14 0 10
> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
> ZynqMP> i2c md 43 0 10
> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> ZynqMP> i2c md 44 0 10
> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> ZynqMP>
> 
> Here is DT fragment which I use (it is under i2c mux)
> 
> 185                         irps5401_43: irps5401@43 {
> 186                                 compatible = "infineon,irps5401";
> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */

Does that mean the mux is at 0x13 ?

> 188                         };
> 189                         irps5401_4d: irps5401@44 {
> 190                                 compatible = "infineon,irps5401";
> 191                                 reg = <0x44>; /* pmbus / i2c 0x14 */

Why _4d ?

> 192                         };
> 
> I see that driver is used but with error.
> 
> [   37.553740] irps5401 3-0043: PMBus status register not found
> [   37.559815] irps5401 3-0044: PMBus status register not found
> 
> 
> That's why I want to check with you what could be the problem.
> 

PMBus status registers are at 0x78 (byte) and 0x79 (word). The above
error is reported if reading both returns an error or 0xff / 0xffff,
which indicates that the chip is not accessible.

I can say for sure that whatever is at 0x43/0x44, it is very likely
not an irps5401. If it was, at least registers 0x2 and 0x6 should report
different values, and 0x01 doesn't look much better (the lower 2 bits
should never be set).

> Also I would like to know if there is a way to disable it via any API.

Not sure what you want to disable. The message ? The PMBus core needs
to have access to the chip to initialize. If there is no status register,
there is nothing it can do but to refuse to instantiate.

It might make sense to use i2cdetect / i2cget in Linux to determine
if the chips are accessible. I'd try reading the status registers (0x78
to 0x7e), value registers (0x88 to 0x8d, 0x96, 0x97), manufacturer
id (0x99) and model (0x9a), and i2c device ID (0xad) and revision (0xae).

> One of this regulator is connected to another device which doesn't have
> access to it. It means before powering up this device there is a need to
> enable this power regulator. The best via any dedicated API.
> 

We can add regulator support to the PMBus core or to the irps5401 driver
if necessary (patches welcome), assuming the regulator in question is
handled by Linux.

Hope this helps,
Guenter

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 15:24 ` Guenter Roeck
@ 2020-03-30 15:42   ` Robert Hancock
  2020-03-30 18:48     ` Guenter Roeck
  2020-03-30 15:46   ` Michal Simek
  1 sibling, 1 reply; 14+ messages in thread
From: Robert Hancock @ 2020-03-30 15:42 UTC (permalink / raw)
  To: Guenter Roeck, Michal Simek; +Cc: linux-hwmon

On 2020-03-30 9:24 a.m., Guenter Roeck wrote:
> On 3/30/20 4:33 AM, Michal Simek wrote:
>> Hi Robert and Guenter,
>>
>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>> I have checked that u-boot can detect that devices and read it.
>>
>> ZynqMP> i2c probe
>> Valid chip addresses: 0C 13 14 20 43 44 74
>> ZynqMP> i2c md 13 0 10
>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>> ZynqMP> i2c md 14 0 10
>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>> ZynqMP> i2c md 43 0 10
>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>> ZynqMP> i2c md 44 0 10
>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>> ZynqMP>
>>
>> Here is DT fragment which I use (it is under i2c mux)
>>
>> 185                         irps5401_43: irps5401@43 {
>> 186                                 compatible = "infineon,irps5401";
>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
> 
> Does that mean the mux is at 0x13 ?

These chips have two I2C addresses with two separate interfaces: the 
standard PMBus-compatible interface at an address between 0x40-0x4f, 
which the irps5401 driver supports, and another proprietary interface at 
an address between 0x10-0x1f. The specific addresses in those ranges is 
configured by the value of a resistor on one of the pins.

> 
>> 188                         };
>> 189                         irps5401_4d: irps5401@44 {
>> 190                                 compatible = "infineon,irps5401";
>> 191                                 reg = <0x44>; /* pmbus / i2c 0x14 */
> 
> Why _4d ?
> 
>> 192                         };
>>
>> I see that driver is used but with error.
>>
>> [   37.553740] irps5401 3-0043: PMBus status register not found
>> [   37.559815] irps5401 3-0044: PMBus status register not found
>>
>>
>> That's why I want to check with you what could be the problem.
>>
> 
> PMBus status registers are at 0x78 (byte) and 0x79 (word). The above
> error is reported if reading both returns an error or 0xff / 0xffff,
> which indicates that the chip is not accessible.
> 
> I can say for sure that whatever is at 0x43/0x44, it is very likely
> not an irps5401. If it was, at least registers 0x2 and 0x6 should report
> different values, and 0x01 doesn't look much better (the lower 2 bits
> should never be set).
> 
>> Also I would like to know if there is a way to disable it via any API.
> 
> Not sure what you want to disable. The message ? The PMBus core needs
> to have access to the chip to initialize. If there is no status register,
> there is nothing it can do but to refuse to instantiate.
> 
> It might make sense to use i2cdetect / i2cget in Linux to determine
> if the chips are accessible. I'd try reading the status registers (0x78
> to 0x7e), value registers (0x88 to 0x8d, 0x96, 0x97), manufacturer
> id (0x99) and model (0x9a), and i2c device ID (0xad) and revision (0xae).

This would be my first suggestion as well.

> 
>> One of this regulator is connected to another device which doesn't have
>> access to it. It means before powering up this device there is a need to
>> enable this power regulator. The best via any dedicated API.

I don't think the PMBus interface on these chips exposes any interface 
to command the regulator. However, one could do this over the Infineon 
programming/control interface on the 0x10-0x1f addresses. This protocol 
is documented publicly now (see the programming guide and register map 
document on the Infineon web site).

>>
> 
> We can add regulator support to the PMBus core or to the irps5401 driver
> if necessary (patches welcome), assuming the regulator in question is
> handled by Linux.
> 
> Hope this helps,
> Guenter
> 

-- 
Robert Hancock
Senior Hardware Designer
SED Systems, a division of Calian Ltd.
Email: hancock@sedsystems.ca

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 15:24 ` Guenter Roeck
  2020-03-30 15:42   ` Robert Hancock
@ 2020-03-30 15:46   ` Michal Simek
  2020-03-30 16:52     ` Guenter Roeck
  1 sibling, 1 reply; 14+ messages in thread
From: Michal Simek @ 2020-03-30 15:46 UTC (permalink / raw)
  To: Guenter Roeck, Michal Simek, Robert Hancock; +Cc: linux-hwmon

On 30. 03. 20 17:24, Guenter Roeck wrote:
> On 3/30/20 4:33 AM, Michal Simek wrote:
>> Hi Robert and Guenter,
>>
>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>> I have checked that u-boot can detect that devices and read it.
>>
>> ZynqMP> i2c probe
>> Valid chip addresses: 0C 13 14 20 43 44 74
>> ZynqMP> i2c md 13 0 10
>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>> ZynqMP> i2c md 14 0 10
>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>> ZynqMP> i2c md 43 0 10
>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>> ZynqMP> i2c md 44 0 10
>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>> ZynqMP>
>>
>> Here is DT fragment which I use (it is under i2c mux)
>>
>> 185                         irps5401_43: irps5401@43 {
>> 186                                 compatible = "infineon,irps5401";
>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
> 
> Does that mean the mux is at 0x13 ?

HW guys wrote that 0x13 is i2c address and 0x43 is pmbus address.


> 
>> 188                         };
>> 189                         irps5401_4d: irps5401@44 {
>> 190                                 compatible = "infineon,irps5401";
>> 191                                 reg = <0x44>; /* pmbus / i2c 0x14 */
> 
> Why _4d ?

Sorry - I was checking board and 4d was address on early revision and
didn't update it.

> 
>> 192                         };
>>
>> I see that driver is used but with error.
>>
>> [   37.553740] irps5401 3-0043: PMBus status register not found
>> [   37.559815] irps5401 3-0044: PMBus status register not found
>>
>>
>> That's why I want to check with you what could be the problem.
>>
> 
> PMBus status registers are at 0x78 (byte) and 0x79 (word). The above
> error is reported if reading both returns an error or 0xff / 0xffff,
> which indicates that the chip is not accessible.
> 
> I can say for sure that whatever is at 0x43/0x44, it is very likely
> not an irps5401. If it was, at least registers 0x2 and 0x6 should report
> different values, and 0x01 doesn't look much better (the lower 2 bits
> should never be set).

There is nothing else on schematics. When I try 0x13/0x14 I am getting.
irps5401 3-0013: Failed to identify chip capabilities
irps5401 3-0014: Failed to identify chip capabilities

>> Also I would like to know if there is a way to disable it via any API.
> 
> Not sure what you want to disable. The message ? The PMBus core needs
> to have access to the chip to initialize. If there is no status register,
> there is nothing it can do but to refuse to instantiate.

When driver is probed I would like to be able from user space
enable/disable the specific output from PMIC. This one has 4 VOUTs.


> It might make sense to use i2cdetect / i2cget in Linux to determine
> if the chips are accessible. I'd try reading the status registers (0x78
> to 0x7e), value registers (0x88 to 0x8d, 0x96, 0x97), manufacturer
> id (0x99) and model (0x9a), and i2c device ID (0xad) and revision (0xae).

ok. Will try.

> 
>> One of this regulator is connected to another device which doesn't have
>> access to it. It means before powering up this device there is a need to
>> enable this power regulator. The best via any dedicated API.
>>
> 
> We can add regulator support to the PMBus core or to the irps5401 driver
> if necessary (patches welcome), assuming the regulator in question is
> handled by Linux.

ok.

Thanks,
Michal


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 15:46   ` Michal Simek
@ 2020-03-30 16:52     ` Guenter Roeck
  0 siblings, 0 replies; 14+ messages in thread
From: Guenter Roeck @ 2020-03-30 16:52 UTC (permalink / raw)
  To: Michal Simek, Robert Hancock; +Cc: linux-hwmon

On 3/30/20 8:46 AM, Michal Simek wrote:
> On 30. 03. 20 17:24, Guenter Roeck wrote:
>> On 3/30/20 4:33 AM, Michal Simek wrote:
>>> Hi Robert and Guenter,
>>>
>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>>> I have checked that u-boot can detect that devices and read it.
>>>
>>> ZynqMP> i2c probe
>>> Valid chip addresses: 0C 13 14 20 43 44 74
>>> ZynqMP> i2c md 13 0 10
>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>> ZynqMP> i2c md 14 0 10
>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>> ZynqMP> i2c md 43 0 10
>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>> ZynqMP> i2c md 44 0 10
>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>> ZynqMP>
>>>
>>> Here is DT fragment which I use (it is under i2c mux)
>>>
>>> 185                         irps5401_43: irps5401@43 {
>>> 186                                 compatible = "infineon,irps5401";
>>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
>>
>> Does that mean the mux is at 0x13 ?
> 
> HW guys wrote that 0x13 is i2c address and 0x43 is pmbus address.
> 

Sorry, I have no idea what that is supposed to mean. PMBus is SMBus
which, for all practical purpose, is i2c. There is no difference between
PMBus and I2C addresses.


[ ... ]

> 
> There is nothing else on schematics. When I try 0x13/0x14 I am getting.
> irps5401 3-0013: Failed to identify chip capabilities
> irps5401 3-0014: Failed to identify chip capabilities
> 
Yes, the chips at those addresses don't look like PMBus chips.

Maybe the chips are on other i2c busses. There must be at least four
of them in the system.

>>> Also I would like to know if there is a way to disable it via any API.
>>
>> Not sure what you want to disable. The message ? The PMBus core needs
>> to have access to the chip to initialize. If there is no status register,
>> there is nothing it can do but to refuse to instantiate.
> 
> When driver is probed I would like to be able from user space
> enable/disable the specific output from PMIC. This one has 4 VOUTs.
> 
You mean to instantiate a regulator ? That is possible; see
drivers/hwmon/pmbus/ltc2978.c for an example. I don't know if one
can enable/disable regulators from userspace, though.

Guenter

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 15:42   ` Robert Hancock
@ 2020-03-30 18:48     ` Guenter Roeck
  2020-03-30 19:09       ` Robert Hancock
  0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2020-03-30 18:48 UTC (permalink / raw)
  To: Robert Hancock, Michal Simek; +Cc: linux-hwmon

On 3/30/20 8:42 AM, Robert Hancock wrote:
> On 2020-03-30 9:24 a.m., Guenter Roeck wrote:
>> On 3/30/20 4:33 AM, Michal Simek wrote:
>>> Hi Robert and Guenter,
>>>
>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>>> I have checked that u-boot can detect that devices and read it.
>>>
>>> ZynqMP> i2c probe
>>> Valid chip addresses: 0C 13 14 20 43 44 74
>>> ZynqMP> i2c md 13 0 10
>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>> ZynqMP> i2c md 14 0 10
>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>> ZynqMP> i2c md 43 0 10
>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>> ZynqMP> i2c md 44 0 10
>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>> ZynqMP>
>>>
>>> Here is DT fragment which I use (it is under i2c mux)
>>>
>>> 185                         irps5401_43: irps5401@43 {
>>> 186                                 compatible = "infineon,irps5401";
>>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
>>
>> Does that mean the mux is at 0x13 ?
> 
> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins.
> 

Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet
doesn't seem to include a description of the proprietary interface
registers/commands, or maybe I am missing it.

The chip datasheet does talk a lot about various MTP registers.
Part of that register set is Write_protect_section and
Read_protect_section. Maybe the PMBus registers are all read
protected ?

Guenter

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 18:48     ` Guenter Roeck
@ 2020-03-30 19:09       ` Robert Hancock
  2020-03-30 19:48         ` Guenter Roeck
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Hancock @ 2020-03-30 19:09 UTC (permalink / raw)
  To: Guenter Roeck, Michal Simek; +Cc: linux-hwmon

On 2020-03-30 12:48 p.m., Guenter Roeck wrote:
> On 3/30/20 8:42 AM, Robert Hancock wrote:
>> On 2020-03-30 9:24 a.m., Guenter Roeck wrote:
>>> On 3/30/20 4:33 AM, Michal Simek wrote:
>>>> Hi Robert and Guenter,
>>>>
>>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>>>> I have checked that u-boot can detect that devices and read it.
>>>>
>>>> ZynqMP> i2c probe
>>>> Valid chip addresses: 0C 13 14 20 43 44 74
>>>> ZynqMP> i2c md 13 0 10
>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>>> ZynqMP> i2c md 14 0 10
>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>>> ZynqMP> i2c md 43 0 10
>>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>>> ZynqMP> i2c md 44 0 10
>>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>>> ZynqMP>
>>>>
>>>> Here is DT fragment which I use (it is under i2c mux)
>>>>
>>>> 185                         irps5401_43: irps5401@43 {
>>>> 186                                 compatible = "infineon,irps5401";
>>>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
>>>
>>> Does that mean the mux is at 0x13 ?
>>
>> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins.
>>
> 
> Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet
> doesn't seem to include a description of the proprietary interface
> registers/commands, or maybe I am missing it.
> 
> The chip datasheet does talk a lot about various MTP registers.
> Part of that register set is Write_protect_section and
> Read_protect_section. Maybe the PMBus registers are all read
> protected ?

There is a programming guide and register map on the Infineon site under 
"Additional Technical Information" here:

https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/

-- 
Robert Hancock
Senior Hardware Designer
SED Systems, a division of Calian Ltd.
Email: hancock@sedsystems.ca

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 19:09       ` Robert Hancock
@ 2020-03-30 19:48         ` Guenter Roeck
  2020-03-31 12:38           ` Michal Simek
  0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2020-03-30 19:48 UTC (permalink / raw)
  To: Robert Hancock; +Cc: Michal Simek, linux-hwmon

On Mon, Mar 30, 2020 at 01:09:56PM -0600, Robert Hancock wrote:
> On 2020-03-30 12:48 p.m., Guenter Roeck wrote:
> > On 3/30/20 8:42 AM, Robert Hancock wrote:
> > > On 2020-03-30 9:24 a.m., Guenter Roeck wrote:
> > > > On 3/30/20 4:33 AM, Michal Simek wrote:
> > > > > Hi Robert and Guenter,
> > > > > 
> > > > > Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
> > > > > I have checked that u-boot can detect that devices and read it.
> > > > > 
> > > > > ZynqMP> i2c probe
> > > > > Valid chip addresses: 0C 13 14 20 43 44 74
> > > > > ZynqMP> i2c md 13 0 10
> > > > > 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
> > > > > ZynqMP> i2c md 14 0 10
> > > > > 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
> > > > > ZynqMP> i2c md 43 0 10
> > > > > 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > > > > ZynqMP> i2c md 44 0 10
> > > > > 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > > > > ZynqMP>
> > > > > 
> > > > > Here is DT fragment which I use (it is under i2c mux)
> > > > > 
> > > > > 185                         irps5401_43: irps5401@43 {
> > > > > 186                                 compatible = "infineon,irps5401";
> > > > > 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
> > > > 
> > > > Does that mean the mux is at 0x13 ?
> > > 
> > > These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins.
> > > 
> > 
> > Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet
> > doesn't seem to include a description of the proprietary interface
> > registers/commands, or maybe I am missing it.
> > 
> > The chip datasheet does talk a lot about various MTP registers.
> > Part of that register set is Write_protect_section and
> > Read_protect_section. Maybe the PMBus registers are all read
> > protected ?
> 
> There is a programming guide and register map on the Infineon site under
> "Additional Technical Information" here:
> 
> https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/
> 
Based on that my best guess would be that either the chips are not at the
expected addresses, or that the registers are indeed read protected.

Guenter

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-30 19:48         ` Guenter Roeck
@ 2020-03-31 12:38           ` Michal Simek
  2020-04-09 14:29             ` Michal Simek
  0 siblings, 1 reply; 14+ messages in thread
From: Michal Simek @ 2020-03-31 12:38 UTC (permalink / raw)
  To: Guenter Roeck, Robert Hancock; +Cc: Michal Simek, linux-hwmon

On 30. 03. 20 21:48, Guenter Roeck wrote:
> On Mon, Mar 30, 2020 at 01:09:56PM -0600, Robert Hancock wrote:
>> On 2020-03-30 12:48 p.m., Guenter Roeck wrote:
>>> On 3/30/20 8:42 AM, Robert Hancock wrote:
>>>> On 2020-03-30 9:24 a.m., Guenter Roeck wrote:
>>>>> On 3/30/20 4:33 AM, Michal Simek wrote:
>>>>>> Hi Robert and Guenter,
>>>>>>
>>>>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>>>>>> I have checked that u-boot can detect that devices and read it.
>>>>>>
>>>>>> ZynqMP> i2c probe
>>>>>> Valid chip addresses: 0C 13 14 20 43 44 74
>>>>>> ZynqMP> i2c md 13 0 10
>>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>>>>> ZynqMP> i2c md 14 0 10
>>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>>>>> ZynqMP> i2c md 43 0 10
>>>>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>>>>> ZynqMP> i2c md 44 0 10
>>>>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>>>>> ZynqMP>
>>>>>>
>>>>>> Here is DT fragment which I use (it is under i2c mux)
>>>>>>
>>>>>> 185                         irps5401_43: irps5401@43 {
>>>>>> 186                                 compatible = "infineon,irps5401";
>>>>>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
>>>>>
>>>>> Does that mean the mux is at 0x13 ?
>>>>
>>>> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins.
>>>>
>>>
>>> Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet
>>> doesn't seem to include a description of the proprietary interface
>>> registers/commands, or maybe I am missing it.
>>>
>>> The chip datasheet does talk a lot about various MTP registers.
>>> Part of that register set is Write_protect_section and
>>> Read_protect_section. Maybe the PMBus registers are all read
>>> protected ?
>>
>> There is a programming guide and register map on the Infineon site under
>> "Additional Technical Information" here:
>>
>> https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/
>>
> Based on that my best guess would be that either the chips are not at the
> expected addresses, or that the registers are indeed read protected.

I am able to detect that devices.

root@zcu104-debian:/etc/apt# i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- 13 14 -- -- -- -- -- -- -- -- -- -- --
20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- 43 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- UU -- -- --

Also disable/enable rail on 0x44 and see power good led on/off

root@zcu104-debian:~# i2cset -y 3 0x44 0 3
root@zcu104-debian:~# i2cset -y 3 0x44 1 0x80 b
root@zcu104-debian:~# i2cget -y 3 0x44 0x78 b

I can't read the rest of regs but checking with hw guys what they have
done with these devices.

Anyway thanks for your help and advices.

Thanks,
Michal



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-03-31 12:38           ` Michal Simek
@ 2020-04-09 14:29             ` Michal Simek
  2020-04-09 15:16               ` Guenter Roeck
  0 siblings, 1 reply; 14+ messages in thread
From: Michal Simek @ 2020-04-09 14:29 UTC (permalink / raw)
  To: Michal Simek, Guenter Roeck, Robert Hancock; +Cc: linux-hwmon

On 31. 03. 20 14:38, Michal Simek wrote:
> On 30. 03. 20 21:48, Guenter Roeck wrote:
>> On Mon, Mar 30, 2020 at 01:09:56PM -0600, Robert Hancock wrote:
>>> On 2020-03-30 12:48 p.m., Guenter Roeck wrote:
>>>> On 3/30/20 8:42 AM, Robert Hancock wrote:
>>>>> On 2020-03-30 9:24 a.m., Guenter Roeck wrote:
>>>>>> On 3/30/20 4:33 AM, Michal Simek wrote:
>>>>>>> Hi Robert and Guenter,
>>>>>>>
>>>>>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
>>>>>>> I have checked that u-boot can detect that devices and read it.
>>>>>>>
>>>>>>> ZynqMP> i2c probe
>>>>>>> Valid chip addresses: 0C 13 14 20 43 44 74
>>>>>>> ZynqMP> i2c md 13 0 10
>>>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>>>>>> ZynqMP> i2c md 14 0 10
>>>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08    ................
>>>>>>> ZynqMP> i2c md 43 0 10
>>>>>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>>>>>> ZynqMP> i2c md 44 0 10
>>>>>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>>>>>> ZynqMP>
>>>>>>>
>>>>>>> Here is DT fragment which I use (it is under i2c mux)
>>>>>>>
>>>>>>> 185                         irps5401_43: irps5401@43 {
>>>>>>> 186                                 compatible = "infineon,irps5401";
>>>>>>> 187                                 reg = <0x43>; /* pmbus / i2c 0x13 */
>>>>>>
>>>>>> Does that mean the mux is at 0x13 ?
>>>>>
>>>>> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins.
>>>>>
>>>>
>>>> Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet
>>>> doesn't seem to include a description of the proprietary interface
>>>> registers/commands, or maybe I am missing it.
>>>>
>>>> The chip datasheet does talk a lot about various MTP registers.
>>>> Part of that register set is Write_protect_section and
>>>> Read_protect_section. Maybe the PMBus registers are all read
>>>> protected ?
>>>
>>> There is a programming guide and register map on the Infineon site under
>>> "Additional Technical Information" here:
>>>
>>> https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/
>>>
>> Based on that my best guess would be that either the chips are not at the
>> expected addresses, or that the registers are indeed read protected.
> 
> I am able to detect that devices.
> 
> root@zcu104-debian:/etc/apt# i2cdetect -y -r 3
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- 13 14 -- -- -- -- -- -- -- -- -- -- --
> 20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- 43 44 -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- UU -- -- --
> 
> Also disable/enable rail on 0x44 and see power good led on/off
> 
> root@zcu104-debian:~# i2cset -y 3 0x44 0 3
> root@zcu104-debian:~# i2cset -y 3 0x44 1 0x80 b
> root@zcu104-debian:~# i2cget -y 3 0x44 0x78 b
> 
> I can't read the rest of regs but checking with hw guys what they have
> done with these devices.


Just to let you know issue is with i2c driver. Here is my output for the
record.

irps5401-i2c-3-43
Adapter: i2c-0-mux (chan_id 2)
vin1:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
vin2:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
vin3:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
vin4:             N/A
vin5:          2.52 V  (min =  +0.40 V, crit max =  +4.00 V)  ALARM (CRIT)
vout1:       851.00 mV (crit min =  +0.65 V, min =  +0.68 V)
                       (max =  +1.02 V, crit max =  +1.25 V)
vout2:         1.80 V  (crit min =  +1.55 V, min =  +1.56 V)
                       (max =  +2.16 V, crit max =  +2.20 V)
vout3:         1.20 V  (crit min =  +0.90 V, min =  +0.96 V)
                       (max =  +1.43 V, crit max =  +1.59 V)
vout4:            N/A
vout5:       906.00 mV (crit min =  +0.68 V, min =  +0.79 V)
                       (max =  +1.02 V, crit max =  +1.13 V)
temp1:        +43.0°C  (high = +100.0°C, crit = +120.0°C)
temp2:        +43.0°C  (high = +100.0°C, crit = +120.0°C)
temp3:        +43.0°C  (high = +100.0°C, crit = +120.0°C)
temp4:            N/A
temp5:        +44.0°C  (high = +100.0°C, crit = +120.0°C)
pin1:          1.75 W
pin2:        406.25 mW
pin3:        468.75 mW
pin4:             N/A
pin5:         15.62 mW
pout1:         1.50 W
pout2:       406.25 mW
pout3:       468.75 mW
pout4:            N/A
pout5:        15.62 mW
iin1:        125.00 mA
iin2:         31.00 mA
iin3:         39.00 mA
iin4:             N/A
iout1:         2.00 A  (max = +21.00 A, crit max = +25.00 A)
iout2:       234.00 mA (max =  +2.50 A, crit max =  +3.12 A)
iout3:       390.00 mA (max =  +8.50 A, crit max = +10.25 A)
iout4:            N/A
iout5:         8.00 mA (max =  +0.65 A, crit max =  +0.72 A)

irps5401-i2c-3-44
Adapter: i2c-0-mux (chan_id 2)
vin1:         11.53 V  (min =  +9.00 V, crit max = +14.00 V)
vin2:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
vin3:         11.41 V  (min =  +9.00 V, crit max = +14.00 V)
vin4:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
vin5:          2.51 V  (min =  +0.40 V, crit max =  +4.00 V)  ALARM (CRIT)
vout1:         3.30 V  (crit min =  +2.90 V, min =  +2.91 V)
                       (max =  +3.69 V, crit max =  +3.70 V)
vout2:         1.13 V  (crit min =  +0.73 V, min =  +0.90 V)
                       (max =  +1.35 V, crit max =  +1.52 V)
vout3:         5.00 V  (crit min =  +4.60 V, min =  +4.70 V)
                       (max =  +5.20 V, crit max =  +5.40 V)
vout4:       152.00 mV (crit min =  +1.40 V, min =  +1.44 V)
                       (max =  +2.16 V, crit max =  +2.20 V)
vout5:       851.00 mV (crit min =  +0.64 V, min =  +0.75 V)
                       (max =  +0.97 V, crit max =  +1.07 V)
temp1:        +40.0°C  (high = +100.0°C, crit = +120.0°C)
temp2:        +40.0°C  (high = +100.0°C, crit = +120.0°C)
temp3:        +40.0°C  (high = +100.0°C, crit = +120.0°C)
temp4:        +40.0°C  (high = +100.0°C, crit = +120.0°C)
temp5:        +40.0°C  (high = +100.0°C, crit = +120.0°C)
pin1:          2.50 W
pin2:         31.25 mW
pin3:          0.00 W
pin4:          0.00 W
pin5:        187.50 mW
pout1:         2.25 W
pout2:        31.25 mW
pout3:         0.00 W
pout4:        31.25 mW
pout5:        62.50 mW
iin1:        187.00 mA
iin2:          0.00 A
iin3:          0.00 A
iin4:          0.00 A
iout1:       750.00 mA (max = +12.00 A, crit max = +14.00 A)
iout2:        46.00 mA (max =  +1.81 A, crit max =  +2.19 A)
iout3:         0.00 A  (max =  +3.50 A, crit max =  +4.00 A)
iout4:         9.28 A  (max =  +3.81 A, crit max =  +4.81 A)
iout5:        73.00 mA (max =  +0.65 A, crit max =  +0.72 A)



Thanks,
Michal

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-04-09 14:29             ` Michal Simek
@ 2020-04-09 15:16               ` Guenter Roeck
  2020-04-09 15:30                 ` Robert Hancock
  0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2020-04-09 15:16 UTC (permalink / raw)
  To: monstr, Michal Simek, Robert Hancock; +Cc: linux-hwmon

Hi Michal,

On 4/9/20 7:29 AM, Michal Simek wrote:
[ ... ]
> 
> Just to let you know issue is with i2c driver. Here is my output for the
> record.
> 
Thanks a lot for the update.

> irps5401-i2c-3-43
> Adapter: i2c-0-mux (chan_id 2)
> vin1:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
> vin2:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
> vin3:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
> vin4:             N/A

This is interesting; it means that the rail is not active (?) or
not supported, or maybe even that the driver has a bug. The second
chip reports a value here, so I guess the rail is inactive.
If possible, it would be desirable to detect this during probe
and not try to report values for this rail. It would be great if
you can find the time to figure out what is going on.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-04-09 15:16               ` Guenter Roeck
@ 2020-04-09 15:30                 ` Robert Hancock
  2020-04-09 21:23                   ` Guenter Roeck
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Hancock @ 2020-04-09 15:30 UTC (permalink / raw)
  To: Guenter Roeck, monstr, Michal Simek; +Cc: linux-hwmon

On 2020-04-09 9:16 a.m., Guenter Roeck wrote:
> Hi Michal,
> 
> On 4/9/20 7:29 AM, Michal Simek wrote:
> [ ... ]
>>
>> Just to let you know issue is with i2c driver. Here is my output for the
>> record.
>>
> Thanks a lot for the update.
> 
>> irps5401-i2c-3-43
>> Adapter: i2c-0-mux (chan_id 2)
>> vin1:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>> vin2:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>> vin3:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>> vin4:             N/A
> 
> This is interesting; it means that the rail is not active (?) or
> not supported, or maybe even that the driver has a bug. The second
> chip reports a value here, so I guess the rail is inactive.
> If possible, it would be desirable to detect this during probe
> and not try to report values for this rail. It would be great if
> you can find the time to figure out what is going on.

I would assume that either that rail is not used in that board design 
and was disabled in the non-volatile config on the chip, or alternately 
the chip allows combining outputs C and D (i.e. 3 and 4) into a single 
output in which case only one will report valid data. Not sure offhand 
if there is a way to detect those cases from the PMBus interface at 
probe time.

-- 
Robert Hancock
Senior Hardware Designer
SED Systems, a division of Calian Ltd.
Email: hancock@sedsystems.ca

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-04-09 15:30                 ` Robert Hancock
@ 2020-04-09 21:23                   ` Guenter Roeck
  2020-04-10  7:19                     ` Michal Simek
  0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2020-04-09 21:23 UTC (permalink / raw)
  To: Robert Hancock, monstr, Michal Simek; +Cc: linux-hwmon

On 4/9/20 8:30 AM, Robert Hancock wrote:
> On 2020-04-09 9:16 a.m., Guenter Roeck wrote:
>> Hi Michal,
>>
>> On 4/9/20 7:29 AM, Michal Simek wrote:
>> [ ... ]
>>>
>>> Just to let you know issue is with i2c driver. Here is my output for the
>>> record.
>>>
>> Thanks a lot for the update.
>>
>>> irps5401-i2c-3-43
>>> Adapter: i2c-0-mux (chan_id 2)
>>> vin1:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>>> vin2:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>>> vin3:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>>> vin4:             N/A
>>
>> This is interesting; it means that the rail is not active (?) or
>> not supported, or maybe even that the driver has a bug. The second
>> chip reports a value here, so I guess the rail is inactive.
>> If possible, it would be desirable to detect this during probe
>> and not try to report values for this rail. It would be great if
>> you can find the time to figure out what is going on.
> 
> I would assume that either that rail is not used in that board design and was disabled in the non-volatile config on the chip, or alternately the chip allows combining outputs C and D (i.e. 3 and 4) into a single output in which case only one will report valid data. Not sure offhand if there is a way to detect those cases from the PMBus interface at probe time.
> 
I think it may be the output disable register (0x38). One would have
to know the i2c address, read the register, and set page bits
accordingly. Overall, I am not sure if it is worth the trouble.
Maybe we should just just add a note to the driver documentation.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Linux driver for IRPS5401 - status reg not found
  2020-04-09 21:23                   ` Guenter Roeck
@ 2020-04-10  7:19                     ` Michal Simek
  0 siblings, 0 replies; 14+ messages in thread
From: Michal Simek @ 2020-04-10  7:19 UTC (permalink / raw)
  To: Guenter Roeck, Robert Hancock, monstr, Michal Simek; +Cc: linux-hwmon

On 09. 04. 20 23:23, Guenter Roeck wrote:
> On 4/9/20 8:30 AM, Robert Hancock wrote:
>> On 2020-04-09 9:16 a.m., Guenter Roeck wrote:
>>> Hi Michal,
>>>
>>> On 4/9/20 7:29 AM, Michal Simek wrote:
>>> [ ... ]
>>>>
>>>> Just to let you know issue is with i2c driver. Here is my output for the
>>>> record.
>>>>
>>> Thanks a lot for the update.
>>>
>>>> irps5401-i2c-3-43
>>>> Adapter: i2c-0-mux (chan_id 2)
>>>> vin1:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>>>> vin2:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>>>> vin3:         11.56 V  (min =  +9.00 V, crit max = +14.00 V)
>>>> vin4:             N/A
>>>
>>> This is interesting; it means that the rail is not active (?) or
>>> not supported, or maybe even that the driver has a bug. The second
>>> chip reports a value here, so I guess the rail is inactive.
>>> If possible, it would be desirable to detect this during probe
>>> and not try to report values for this rail. It would be great if
>>> you can find the time to figure out what is going on.
>>
>> I would assume that either that rail is not used in that board design and was disabled in the non-volatile config on the chip, or alternately the chip allows combining outputs C and D (i.e. 3 and 4) into a single output in which case only one will report valid data. Not sure offhand if there is a way to detect those cases from the PMBus interface at probe time.
>>
> I think it may be the output disable register (0x38). One would have
> to know the i2c address, read the register, and set page bits
> accordingly. Overall, I am not sure if it is worth the trouble.
> Maybe we should just just add a note to the driver documentation.

https://www.xilinx.com/support/documentation/boards_and_kits/zcu104/ug1267-zcu104-eval-bd.pdf

page 83

0x43 is PHASE_C/D combined together a provide 1.2v.

Thanks,
Michal

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2020-04-10  7:19 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-30 11:33 Linux driver for IRPS5401 - status reg not found Michal Simek
2020-03-30 15:24 ` Guenter Roeck
2020-03-30 15:42   ` Robert Hancock
2020-03-30 18:48     ` Guenter Roeck
2020-03-30 19:09       ` Robert Hancock
2020-03-30 19:48         ` Guenter Roeck
2020-03-31 12:38           ` Michal Simek
2020-04-09 14:29             ` Michal Simek
2020-04-09 15:16               ` Guenter Roeck
2020-04-09 15:30                 ` Robert Hancock
2020-04-09 21:23                   ` Guenter Roeck
2020-04-10  7:19                     ` Michal Simek
2020-03-30 15:46   ` Michal Simek
2020-03-30 16:52     ` Guenter Roeck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).