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] [thread-next>] [day] [month] [year] [list]
Message-ID: <8316b645-72a8-7348-ad4c-1a84535b8b3f@pengutronix.de>
Date:   Thu, 23 Jan 2020 12:54:27 +0100
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Faiz Abbas <faiz_abbas@...com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        linux-can@...r.kernel.org
Cc:     catalin.marinas@....com, mark.rutland@....com, robh+dt@...nel.org,
        davem@...emloft.net, wg@...ndegger.com, sriram.dash@...sung.com,
        dmurphy@...com, nm@...com, t-kristo@...com
Subject: Re: [PATCH 0/3] Add Support for MCAN in AM654x-idk

On 1/23/20 12:46 PM, Faiz Abbas wrote:
> Marc,
> 
> On 23/01/20 4:47 pm, Marc Kleine-Budde wrote:
>> On 1/22/20 9:03 AM, Faiz Abbas wrote:
>>> This series adds driver patches to support MCAN in TI's AM654x-idk.
>>>
>>> Faiz Abbas (3):
>>>   dt-bindings: net: can: m_can: Add Documentation for stb-gpios
>>>   can: m_can: m_can_platform: Add support for enabling transceiver
>>>     through the STB line
>>>   arm64: defconfig: Add Support for Bosch M_CAN controllers
>>>
>>>  Documentation/devicetree/bindings/net/can/m_can.txt |  2 ++
>>>  arch/arm64/configs/defconfig                        |  3 +++
>>>  drivers/net/can/m_can/m_can_platform.c              | 12 ++++++++++++
>>>  3 files changed, 17 insertions(+)
>>
>> What about adding support for xceiver-supply as done in several other
>> drivers (ti_hecc.c, flexcan.c, mcp251x.c)? And using this for the stb line?
> 
> Looks like you had given this feedback a long time ago and I forgot
> about it. Sorry about that :-)
> 
> https://lore.kernel.org/patchwork/patch/1006238/
> 
> But now that I think about it, its kinda weird that we are modelling
> part of the transceiver as a separate child node
> (Documentation/devicetree/bindings/net/can/can-transceiver.txt) and the
> other parts as a regulator.

We need a regulator, as there are dual phy chips with a single enable line.

> Anyone looking at the transceiver node would figure thats where the
> enable gpio/regulator node needs to go instead of the parent node.
> Shouldn't we have all transceiver properties under the same node?

Feel free to add support for the regulator to the transceiver node and
convert the existing drivers to accept both bindings.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ