lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bbffd884-b31a-4e95-8a72-3705745b49f9@amd.com>
Date:   Mon, 30 Oct 2023 16:32:12 +0000
From:   Kris Chaplin <kris.chaplin@....com>
To:     Rob Herring <robh@...nel.org>
Cc:     thomas.delev@....com, michal.simek@....com,
        krzysztof.kozlowski@...aro.org, conor+dt@...nel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        git@....com
Subject: Re: [RESEND v2 1/2] dt-bindings: w1: Add YAML DT schema for AMD AXI
 w1 host and MAINTAINERS entry

Thanks Rob,

On 30/10/2023 16:19, Rob Herring wrote:
>> Is there a device side implementation? I can't really imagine that
>> 1-wire would ever be implemented as firmware on the device side given
>> its limited nature. So adding 'host' doesn't make this any more
>> specific.
>>
>> There are slave drivers as well as master, although these do not have a device tree binding.
> 
> My question is whether there is slave/device IP for implementing the
> device side in software? The slave drivers in the kernel are for
> handling those devices, not a slave side controller interface.
> 
> For comparison, we have SPI slave in the kernel which is for
> implementing the device side in software (running Linux or another
> OS). There is no such thing in the kernel for 1-wire and I would doubt
> there would ever be a software implementation. Could you, yes, but
> given the limited nature of 1-wire why would you?

I agree - I'm not aware of any such interface or plans.  Yes - I've seen 
it with SPI, but I've not heard anything similar for 1-wire.
> 
>>
>> The IP device from AMD is called "axi_1wire_host", and so we are hoping to stick with this binding if appropriate as it relates to the IP name.
> 
> Okay, I suppose that is good enough reason.

Thank you - it does help when we can align the binding and IP name.

> However, the versioning comments in your first v2 have not been
> addressed. I believe the conclusion was to mention the IP has a
> version register. And Conor's R-by tag was not added.

I messed up with not adding a note about this to the commit on v2 which 
I can resolve in a v3 - yes the versioning is via register in the IP 
core at a known offset.  The binding name (and IP name) changed between 
v1 and v2 (from master to host) so I didn't add the review tag for Conor 
in v2 as the commit changed.

regards,
Kris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ