netdev - Re: [PATCH 3/3] dt-bindings: net: dsa: add new bindings MT7530

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]

Date:   Mon, 3 Dec 2018 17:03:24 +1000
From:   Greg Ungerer <gerg@...nel.org>
To:     Florian Fainelli <f.fainelli@...il.com>, sean.wang@...iatek.com,
        andrew@...n.ch, vivien.didelot@...oirfairelinux.com,
        netdev@...r.kernel.org
Cc:     blogic@...nwrt.org, neil@...wn.name
Subject: Re: [PATCH 3/3] dt-bindings: net: dsa: add new bindings MT7530

Hi Florian,

On 1/12/18 3:41 am, Florian Fainelli wrote:
> Hi Greg,
> 
> On 11/29/2018 11:57 PM, gerg@...nel.org wrote:
>> From: Greg Ungerer <gerg@...nel.org>
>>
>> Add descriptive entries for the new bindings introduced to support the
>> MT7530 implementation in the MediaTek MT7621 SoC.
>>
>> New bindings added for:
>>
>>    mediatek,no-clock-regulator
>>    mediatek,mfc-has-cpuport
> 
> I don't think any of these properties are necessary, if you can either
> use a compatible string, and/or infer the actual model at runtime in the
> driver's probe function, then you can assess based on that chip model as

There is an ID register in the 7530 - though I don't know if the lower
16 bits of it can tell us enough information about the device. For me on
the MT7621 they return "0001", I assume it is a revsion ID of some type.
Problem is we do not read that until after the regulators and some of
the clocking is setup.

A compatible string of some description would be simple enough.
Are you thinking something like "mediatek,mt7621" before
"mediatek,mt7530"?


> well as the properties being provided in Device Tree whether these
> resources must be grabbed and used. See mv88e6xxx and b53 for how these
> drivers deal with supporting several distinct models within the same
> code base.

I will have a close look at those, thanks.


> As far as the MFC programming goes, this is definitively something that
> must be done once you know the chip model you are dealing with.

Yep, certainly.

Thanks
Greg