[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VfqC166E57nZRsx97EQCCGnqYTk+4nRX3H2-rsnCohPfQ@mail.gmail.com>
Date: Tue, 25 Apr 2017 12:46:14 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Jan Kiszka <jan.kiszka@...mens.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>,
netdev <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sascha Weisenberger <sascha.weisenberger@...mens.com>
Subject: Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@...mens.com> wrote:
> On 2017-04-25 09:30, Andy Shevchenko wrote:
>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kiszka@...mens.com> wrote:
>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@...mens.com> wrote:
>>>>> The IOT2000 is industrial controller platform, derived from the Intel
>>>>> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
>>>>> IOT2040 has two of them. They can be told apart based on the board asset
>>>>> tag in the DMI table.
>>
>>>>> + const char *asset_tag;
>>>>
>>>> I guess this is redundant. See below.
>>>>
>>>>> + {
>>>>> + .name = "SIMATIC IOT2000",
>>>>> + .asset_tag = "6ES7647-0AA00-0YA2",
>>>>> + .func = 6,
>>>>> + .phy_addr = 1,
>>>>> + },
>>>>
>>>> The below has same definition disregard on asset_tag.
>>>>
>>>
>>> There is a small difference in the asset tag, just not at the last digit
>>> where one may expect it, look:
>>>
>>> ...-0YA2 -> IOT2020
>>> ...-1YA2 -> IOT2040
>>
>> Yes. And how does it change my statement? You may use one record here
>> instead of two.
>
> How? Please be more verbose in your comments.
{
.name = "SIMATIC IOT2000",
.func = 6,
.phy_addr = 1,
},
{
.name = "SIMATIC IOT2000",
.func = 7,
.phy_addr = 1,
},
That's all what you need.
>> Got it, though asset_tag here is redundant as well.
> It's not as it is the only differentiating criteria to tell the
> two-ports variant apart from the one-port (and to avoid confusing it
> with any potential future variant).
And why exactly is it needed?
Sorry, but I don't see any reason to blow the code for no benefit.
> We could leave out the name, but I
> kept it for documentation purposes.
Nobody prevents you to add a comment.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists