netdev - Re: [PATCH 3/3] net: via-rhine: add OF bus binding

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqK2aLSGzjp_gqJ=ePPybf85S0FFQ2n+XascUSYPnSoHcA@mail.gmail.com>
Date:	Wed, 29 Jan 2014 08:59:43 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Alexey Charkov <alchark@...il.com>
Cc:	Tony Prisk <linux@...sktech.co.nz>,
	netdev <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Roger Luethi <rl@...lgate.ch>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] net: via-rhine: add OF bus binding

On Tue, Jan 28, 2014 at 11:20 PM, Alexey Charkov <alchark@...il.com> wrote:
> 2014/1/29 Tony Prisk <linux@...sktech.co.nz>:
>> On 29/01/14 07:27, Alexey Charkov wrote:
>>>
>>> 2014/1/27 Rob Herring <robherring2@...il.com>:
>>>>
>>>> On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov <alchark@...il.com>
>>>> wrote:
>>>>>
>>>>> This should make the driver usable with VIA/WonderMedia ARM-based
>>>>> Systems-on-Chip integrated Rhine III adapters. Note that these
>>>>> are always in MMIO mode, and don't have any known EEPROM.
>>>>>
>>>>> Signed-off-by: Alexey Charkov <alchark@...il.com>
>>>>> Signed-off-by: Roger Luethi <rl@...lgate.ch>
>>>>> ---
>>>>>   .../devicetree/bindings/net/via-rhine.txt          |  18 ++
>>>>>   drivers/net/ethernet/via/Kconfig                   |   2 +-
>>>>>   drivers/net/ethernet/via/via-rhine.c               | 293
>>>>> +++++++++++++--------
>>>>>   3 files changed, 200 insertions(+), 113 deletions(-)
>>>>>   create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt
>>>>> b/Documentation/devicetree/bindings/net/via-rhine.txt
>>>>> new file mode 100644
>>>>> index 0000000..684dd3a
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/net/via-rhine.txt
>>>>> @@ -0,0 +1,18 @@
>>>>> +* VIA Rhine 10/100 Network Controller
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible : Should be "via,rhine"
>>>>
>>>> This should be more specific rather than...
>>>>
>>>>> +- reg : Address and length of the io space
>>>>> +- interrupts : Should contain the controller interrupt line
>>>>> +- rhine,revision : Rhine core revision, used to inform the
>>>>> +       driver of quirks and capabilities to expect from
>>>>> +       the device. Mimics the respective PCI attribute.
>>>>
>>>> having this property. The OF match table can then have the quirks set
>>>> based on compatible strings.
>>>
>>> Sounds fair. Do you think something like the following would fly?
>>>
>>> Required properties:
>>> - compatible : Should be "via,rhine-soc-vt8500" for integrated Rhine
>>> cores found in SoC's such as VIA VT8500, WonderMedia WM8950 and
>>> possibly others. These are listed as 1106:3106 rev. 0x84 on the
>>> virtual PCI bus under vendor-provided kernels.
>>
>> Does it need a special name? I would have assumed they are using their own
>> IP for the VT6105 or VT6106S.
>> Then you can use it to add quirks later on if needed.
>
> The problem is that I have no reliable source for the exact name of
> the IP block. The lookup table within the driver says that rev. 0x83
> is VT6105_B0, and rev. 0x8A is VT6105L (and it doesn't contain any
> entry for 0x84, so our case gets treated as 0x83 currently).
>
> If we only differentiate them by the compatible string, I would be
> reluctant to call it vt6105 or vt6106 or whatever else without knowing
> for sure. Otherwise, if at some point we need to add any quirks
> specific to rev. 0x84, we wouldn't be able to do that without
> side-effects.

If you don't know the IP rev, then you should assume it is different
and you should certainly know which chip it is in. This is why the soc
name is typically in the compatible string. You can always have
multiple compatible strings. You want to have a unique compatible
string so you can add quirks later if needed.

Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html