Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

Hi Florian,

Às 7:42 PM de 1/12/2017, Florian Fainelli escreveu:
> On 01/12/2017 01:43 AM, Joao Pinto wrote:
>>
>> First of all, I am suggesting an alternative way of organizing the code, and
>> that's it, I have no second intentions about anything :).
>>
>> Please don't see this as a take-over or erase Stmicro from credits, 
>> please... it
>> makes no sense. You can leave STMicro license and all the credits fine by me 
>> and
>> I insist on it. But lets name it for something that makes sense... lets call 
>> it
>> dwc (designware controllers), I am totally open to suggestions.
> 
> I don't understand how you reached this conclusion based on what I
> wrote, but I have no concerns about take over or anything, and keep in
> mind that maintainership is by nature a volatile thing. One day, a group
> of people can be in charge of some piece of code, and in the future, it
> could be another group of people, let's be agile.
> 
>>
>> I don't understand the hostility of some comments, honestly.
> 
> It was not my intention to be hostile and I am sorry if this was how you
> perceived it.

No problem, things written by e-mail sometimes can be have different
interpretations :).

> 
> As an occasional contributor to netdev and the stmmac driver what I
> welcome more than anything is more eyeballs and dedicated people
> maintaining the driver, because it's always a good sign that there is
> interesting in making the driver rock solid and feature full. As a
> non-Linux kernel developer (OpenWrt/LEDE) what I care about is being
> able to quickly backport fixes without going through too many hoops
> (including driver rename, relocation etc.).

Yes, you are right and I understand your view.

> 
>>
>> The easiest way is to keep things like they are today, and believe me I have 
>> a
>> lot of things to do, like adding the support of multi-queues / 
>> multi-channels to
>> stmmac, so I not suggesting this because it is fun.
> 
> I believe this is what David is also asking for here.
> 
>>
>> I am suggesting this because it is what I am used to seeing in other 
>> subsystems.
>> USB has dwc2 and dwc3 folders that clearly identifies that they are 
>> Designware
>> (synopsys) extensions to the USB 2.0 and 3.0. The author of dwc3 was Texas
>> Instruments, and they did not name it ti/usb. For example I use an AXS101
>> Development board that does not have a stmicro SoC but has a Designware 
>> Ethernet
>> IP in it, so uses stmicro/stmmac. For me it is confusing.
> 
> The examples you are giving unfortunately unveil the same pattern: a
> customer of the DWC/SNPS IP was first in the upstreaming business, and
> because of that they were able to dictate how the initial submission
> would look like, this was noticed, and you are now as a company
> remedying that, and this is great!

Yes, Synopsys now has the strategy to contribute and help in mainline kernel
development. My main responsibility is to work in the mainline allocating 99% of
my time to it. I am focused on mainly in PCI and Ethernet.

> 
> There are ways to improve the situation to avoid the confusion:
> 
> - provide clear Kconfig help texts that indicate that the driver is not
> just for STMicro but for SNPS IPs in general
> 
> - provide a Documentation/networking/ entry that explains the history,
> why the driver remains with/has this name, and eventually technical
> information about it
>

Your suggestions make perfectly sense you in case we are not able to make the
simple change I suggest bellow.

>>
>> Lets not name it synopsys, for me it is totally fine, but naming it
>> stmicro/stmmac is not the right way because it seems like it is a driver just
>> for stmicro products, which is not, is for products that use Designware 
>> Ethernet
>> IPs.
>>
>> I am volunteering to do this work, let's discuss this.
> 
> I would focus on what has value: adding features, support for newer
> versions of the IP and fixing bugs, not moving the code around which is
> just fixing a cosmetic and historical problem, but not a functional
> problem. By moving the code you are making the job of David and other
> kernel maintainers dealing with -stable backports nearly impossible,
> ultimately arming your relationship with the community over something
> that is not considered an essential change.

In one of the last e-mails I suggested a different approach. We should just name
stmicro to dwc and keep stmmac. This way in the future we can have new Ethernet
IPs being deployed in this dwc folder like:

net/ethernet/dwc/
  stmmac/
  xxxmac/ (new Dwc Ethernet IP 1)
  yyymac/ (new Dwc Ethernet IP 2)
etc..

Although is a small change, it will mean a lot in the future, because it can
have centralized and it won't erase the history of the stmmac driver.

> 
> Let me give you another example, when Broadcom sold its bnx2x LoB to
> Qlogic, the driver was not renamed, nor moved, and now that Qlogic has
> been acquired by Cavium, it still remains under the same directory. Yes,
> it is presenting a 

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Florian Fainelli]

On 01/12/2017 01:43 AM, Joao Pinto wrote:
> 
> First of all, I am suggesting an alternative way of organizing the code, and
> that's it, I have no second intentions about anything :).
> 
> Please don't see this as a take-over or erase Stmicro from credits, please... 
> it
> makes no sense. You can leave STMicro license and all the credits fine by me 
> and
> I insist on it. But lets name it for something that makes sense... lets call 
> it
> dwc (designware controllers), I am totally open to suggestions.

I don't understand how you reached this conclusion based on what I
wrote, but I have no concerns about take over or anything, and keep in
mind that maintainership is by nature a volatile thing. One day, a group
of people can be in charge of some piece of code, and in the future, it
could be another group of people, let's be agile.

> 
> I don't understand the hostility of some comments, honestly.

It was not my intention to be hostile and I am sorry if this was how you
perceived it.

As an occasional contributor to netdev and the stmmac driver what I
welcome more than anything is more eyeballs and dedicated people
maintaining the driver, because it's always a good sign that there is
interesting in making the driver rock solid and feature full. As a
non-Linux kernel developer (OpenWrt/LEDE) what I care about is being
able to quickly backport fixes without going through too many hoops
(including driver rename, relocation etc.).

> 
> The easiest way is to keep things like they are today, and believe me I have a
> lot of things to do, like adding the support of multi-queues / multi-channels 
> to
> stmmac, so I not suggesting this because it is fun.

I believe this is what David is also asking for here.

> 
> I am suggesting this because it is what I am used to seeing in other 
> subsystems.
> USB has dwc2 and dwc3 folders that clearly identifies that they are Designware
> (synopsys) extensions to the USB 2.0 and 3.0. The author of dwc3 was Texas
> Instruments, and they did not name it ti/usb. For example I use an AXS101
> Development board that does not have a stmicro SoC but has a Designware 
> Ethernet
> IP in it, so uses stmicro/stmmac. For me it is confusing.

The examples you are giving unfortunately unveil the same pattern: a
customer of the DWC/SNPS IP was first in the upstreaming business, and
because of that they were able to dictate how the initial submission
would look like, this was noticed, and you are now as a company
remedying that, and this is great!

There are ways to improve the situation to avoid the confusion:

- provide clear Kconfig help texts that indicate that the driver is not
just for STMicro but for SNPS IPs in general

- provide a Documentation/networking/ entry that explains the history,
why the driver remains with/has this name, and eventually technical
information about it

> 
> Lets not name it synopsys, for me it is totally fine, but naming it
> stmicro/stmmac is not the right way because it seems like it is a driver just
> for stmicro products, which is not, is for products that use Designware 
> Ethernet
> IPs.
> 
> I am volunteering to do this work, let's discuss this.

I would focus on what has value: adding features, support for newer
versions of the IP and fixing bugs, not moving the code around which is
just fixing a cosmetic and historical problem, but not a functional
problem. By moving the code you are making the job of David and other
kernel maintainers dealing with -stable backports nearly impossible,
ultimately arming your relationship with the community over something
that is not considered an essential change.

Let me give you another example, when Broadcom sold its bnx2x LoB to
Qlogic, the driver was not renamed, nor moved, and now that Qlogic has
been acquired by Cavium, it still remains under the same directory. Yes,
it is presenting a singularity and is technically not correct, because
the IP now belongs to Cavium, but it is what it is for historical reasons.
-- 
Florian

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

Às 3:45 PM de 1/12/2017, David Miller escreveu:
> From: Joao Pinto 
> Date: Thu, 12 Jan 2017 15:39:47 +
> 
>> In my understanding the advantage is to prepare the future.
> 
> If the driver is named foo or bar, yet in both cases loads and
> properly attaches to the user's device, the user does not care.

Of course. Although my car works I like to open the hood a see it clean and
organized. Gives the user more confidence.

> 
> Therefore, there is no bonafide benefit to the user.
> 
> You aren't getting past that point.
> 
> You also are not addressing the pain this will cause for long
> term maintainence of this driver.

I am aware. I can co-maintain it if current maintainers wish it, no problem with
that. My activity at Synopsys in mainline contribution, so it is part of my job.

> 
> I'm the one who does all of the backporting of stmmac bug fixes to
> -stable, so I for one care a lot about this.
> 
> You are making more work for me and lots of other people by renaming
> this driver and I don't think you are considering that at all.
> 

I understand, it is a lot of work. I volunteer to help.

Joao

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[David Miller]

From: Joao Pinto 
Date: Thu, 12 Jan 2017 15:39:47 +

> In my understanding the advantage is to prepare the future.

If the driver is named foo or bar, yet in both cases loads and
properly attaches to the user's device, the user does not care.

Therefore, there is no bonafide benefit to the user.

You aren't getting past that point.

You also are not addressing the pain this will cause for long
term maintainence of this driver.

I'm the one who does all of the backporting of stmmac bug fixes to
-stable, so I for one care a lot about this.

You are making more work for me and lots of other people by renaming
this driver and I don't think you are considering that at all.

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

Às 3:26 PM de 1/12/2017, David Miller escreveu:
> 
> I don't understand at all why it is so important to change the name of
> these files nor the directory they live in.

GMAC4 is a nickname for the Designware Ethernet QoS, which began in version 4.x
for historical reasons. Soon, we will have version eQOS 5.x version release and
we will have some features in stmmac only available from version 5.x. If the
dwmac4* files and functions were called eqos it would clearer and easier to
include the 5.x stuff.

> 
> What bonafide benefit will users receive if we do this?

>From my point of view have a /net/ethernet/dwc/stmmac instead of a
/net/ethernet/stmicro/stmmac will be clearer for users that it is the spot for
Ethernet Designware IPs. This change will not cause any problems. We are going o
have new Synopsys Ethernet IPs with new drivers that would be placed inside this
/net/ethernet/dwc/. In my understanding the advantage is to prepare the future.
Imagine that I am developing a new driver for a new Ethernet IP. So I work at
Synopsys, I am developing a driver for Ethernet EXAMPLE IP. Where would put it?
This is my concern to the future.

> 
> The only clear part is the downside, which is that it is going to make
> it painful to browse source history and backport bug fixes.
> 
> Please, let's not do this.
> 
> Thanks.
> 

Thanks,
Joao

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[David Miller]

I don't understand at all why it is so important to change the name of
these files nor the directory they live in.

What bonafide benefit will users receive if we do this?

The only clear part is the downside, which is that it is going to make
it painful to browse source history and backport bug fixes.

Please, let's not do this.

Thanks.

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

Hi Alex, good morning!

Às 10:11 AM de 1/12/2017, Alexandre Torgue escreveu:
>>
>> Lets not name it synopsys, for me it is totally fine, but naming it
>> stmicro/stmmac is not the right way because it seems like it is a driver just
>> for stmicro products, which is not, is for products that use Designware 
>> Ethernet
>> IPs.
>>
>> I am volunteering to do this work, let's discuss this.
> 
> For me it makes no sens to rename only folder (stmicro/stmmac by synopsys) and
> keep stmmac* inside a synopsys folder (that is very confusing). If you propose
> that you have to change all.
> 
> BUT doing that, we will lose all stmmac driver story and we don't want that.

Totally understand your point. Do you agree on this approach?
rename "stmicro" to "dwc" (designware controllers) and leave stmmac as it is
today. This small change is enough in my point of view and sole the problems you
refer. We would have net/ethernet/dwc/stmmac/.

I can also rename the dwmac4 files and functions to eqos, since soon we will
have a new eqos version.

dwmac4.h -> eqos.h
dwmac4_core.c -> eqos_core.c
dwmac4_descs.c -> eqos_descs.c
dwmac4_descs.h -> eqos_descs.h
dwmac4_dma.c -> eqos_dma.c
dwmac4_dma.h -> eqos_dma.h
dwmac4_lib.c -> eqos_lib.c

What do you think about this approach?

Thanks,
Joao

> 
> 
> 
>>
>> Thanks,
>> Joao
>>
>>

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Alexandre Torgue]

Hi Joao

On 01/12/2017 10:43 AM, Joao Pinto wrote:


Hi Florian,

Às 9:14 PM de 1/11/2017, Florian Fainelli escreveu:

On 01/10/2017 06:52 AM, Joao Pinto wrote:

This patch renames stmicro/stmmac to synopsys/ since it is a standard
ethernet software package regarding synopsys ethernet controllers, supporting
the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
retro-compatibility, only the description was changed.


Do re really have to do this? ST Micro were the first to upstream
support for a Synopsys IP, and it was later on identified as being
"stmicro" instead of "synopsys" (during the big driver move under
drivers/net/ethernet) whichever came first in the driver essentially "wins".

As mentioned before, although git is able to track renames, git log does
not automatically have --follow, so it can be hard for people to track
down the (new) history of the driver.

Personally, I don't see much value in doing this rename, especially when
all the driver internal structures are still going to be named with
stmmac (and please don't even think about doing a s/stmmac/snps/ inside
the driver ;)).

My 2 cents.



First of all, I am suggesting an alternative way of organizing the code, and
that's it, I have no second intentions about anything :).

Please don't see this as a take-over or erase Stmicro from credits, please... it
makes no sense. You can leave STMicro license and all the credits fine by me and
I insist on it. But lets name it for something that makes sense... lets call it
dwc (designware controllers), I am totally open to suggestions.

I don't understand the hostility of some comments, honestly.

The easiest way is to keep things like they are today, and believe me I have a
lot of things to do, like adding the support of multi-queues / multi-channels to
stmmac, so I not suggesting this because it is fun.

I am suggesting this because it is what I am used to seeing in other subsystems.
USB has dwc2 and dwc3 folders that clearly identifies that they are Designware
(synopsys) extensions to the USB 2.0 and 3.0. The author of dwc3 was Texas
Instruments, and they did not name it ti/usb. For example I use an AXS101
Development board that does not have a stmicro SoC but has a Designware Ethernet
IP in it, so uses stmicro/stmmac. For me it is confusing.

Lets not name it synopsys, for me it is totally fine, but naming it
stmicro/stmmac is not the right way because it seems like it is a driver just
for stmicro products, which is not, is for products that use Designware Ethernet
IPs.

I am volunteering to do this work, let's discuss this.


For me it makes no sens to rename only folder (stmicro/stmmac by 
synopsys) and keep stmmac* inside a synopsys folder (that is very 
confusing). If you propose that you have to change all.


BUT doing that, we will lose all stmmac driver story and we don't want 
that.






Thanks,
Joao

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

Hi Florian,

Às 9:14 PM de 1/11/2017, Florian Fainelli escreveu:
> On 01/10/2017 06:52 AM, Joao Pinto wrote:
>> This patch renames stmicro/stmmac to synopsys/ since it is a standard
>> ethernet software package regarding synopsys ethernet controllers, supporting
>> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
>> retro-compatibility, only the description was changed.
> 
> Do re really have to do this? ST Micro were the first to upstream
> support for a Synopsys IP, and it was later on identified as being
> "stmicro" instead of "synopsys" (during the big driver move under
> drivers/net/ethernet) whichever came first in the driver essentially "wins".
> 
> As mentioned before, although git is able to track renames, git log does
> not automatically have --follow, so it can be hard for people to track
> down the (new) history of the driver.
> 
> Personally, I don't see much value in doing this rename, especially when
> all the driver internal structures are still going to be named with
> stmmac (and please don't even think about doing a s/stmmac/snps/ inside
> the driver ;)).
> 
> My 2 cents.
> 

First of all, I am suggesting an alternative way of organizing the code, and
that's it, I have no second intentions about anything :).

Please don't see this as a take-over or erase Stmicro from credits, please... it
makes no sense. You can leave STMicro license and all the credits fine by me and
I insist on it. But lets name it for something that makes sense... lets call it
dwc (designware controllers), I am totally open to suggestions.

I don't understand the hostility of some comments, honestly.

The easiest way is to keep things like they are today, and believe me I have a
lot of things to do, like adding the support of multi-queues / multi-channels to
stmmac, so I not suggesting this because it is fun.

I am suggesting this because it is what I am used to seeing in other subsystems.
USB has dwc2 and dwc3 folders that clearly identifies that they are Designware
(synopsys) extensions to the USB 2.0 and 3.0. The author of dwc3 was Texas
Instruments, and they did not name it ti/usb. For example I use an AXS101
Development board that does not have a stmicro SoC but has a Designware Ethernet
IP in it, so uses stmicro/stmmac. For me it is confusing.

Lets not name it synopsys, for me it is totally fine, but naming it
stmicro/stmmac is not the right way because it seems like it is a driver just
for stmicro products, which is not, is for products that use Designware Ethernet
IPs.

I am volunteering to do this work, let's discuss this.

Thanks,
Joao

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Florian Fainelli]

On 01/11/2017 07:44 PM, Jie Deng wrote:
> Hi Joao,
> 
> On 2017/1/11 18:35, Joao Pinto wrote:
>> Hi Jie,
>>
>> Às 4:00 AM de 1/11/2017, Jie Deng escreveu:
>>> Hi Joao,
>>>
>>>
>>> On 2017/1/10 22:52, Joao Pinto wrote:
 This patch renames stmicro/stmmac to synopsys/ since it is a standard
 ethernet software package regarding synopsys ethernet controllers, 
 supporting
 the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
 retro-compatibility, only the description was changed.

 Signed-off-by: Joao Pinto 
 ---
 changes v1->v2:
 - nothing changed. Just to keep up with patch set version

 @@ -1,5 +1,5 @@
  config STMMAC_ETH
 -  tristate "STMicroelectronics 10/100/1000 Ethernet driver"
 +  tristate "Synopsys Ethernet drivers"
depends on HAS_IOMEM && HAS_DMA
select MII
select PHYLIB
 @@ -14,7 +14,7 @@ config STMMAC_ETH
  if STMMAC_ETH
  
>>> "Synopsys Ethernet drivers" is too generic. The name should reflect the
>>> controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will 
>>> submit a
>>> driver for the new 25G/40G/50G/100G XLGMAC IP in the future.
>> As you know Synopsys is an IP vendor that as a wide range of IPs related to
>> Ethernet. stmmac is a driver that was well built and well maintained and
>> supports most of those Ethernet IPs, so it has the potential to be the 
>> official
>> Synopsys Ethernet driver suite in the future.
>>
>> Let's make baby steps. For now stmmac supports 10M/100M/1G and also QoS 
>> which is
>> a separated IP and the different IP cores are selected by device tree.
>>
>> In the future it would be usefull to be selectable by Kconfig options, 
>> making it
>> more clear to the kernel user. For example:
>>
>> Synopsys Ethernet drivers
>>   eQoS Core
>>   10M Core
>>   100M Core
>>   1G Core
>>   25G Core
>>   
>>
>> The XLGMAC will be great for our users and I will be 100% available to help 
>> you
>> with it.
>>
>> Thanks,
>> Joao
>>
> Currently, Synopsys has three series IPs cores. They are
> 1. 10M/100M/1G   (GMAC, QoS)
> 2. 1G/2.5G/5G/10G (XGMAC)
> 3. 10G/25G/40G/50G/100G (XLGMAC)
> More info: https://www.synopsys.com/designware-ip/interface-ip/ethernet.html
>  
> You have successfully merged  dwc_eth_qos.c into stmmac. stmmac now fully
> supports the 10M/100M/1G series IPs. Personally, I do support Florian's
> suggestion not to rename stmmac.
> considering to avoid  future confusion and make easy maintenance, Following is
> my suggestions
>1. not to do any rename
>2. keep all 10M/100M/1G IPs (GMAC, QoS) development in stmmac.
>3. keep all 1G/2.5G/5G/10G IP (XGMAC) development in amd-xgbe.
>4. submit a new driver under synopsys/ for the new 10G/25G/40G/50G/100G
> (XLGMAC) IP.
> 
> Welcome opinions from others.

Seems like a reasonable plan to me. If it helps avoid confusion, you
could always add an entry under Documentation/networking/ which
describes the history of the various drivers, and the reasons why they
are not consolidated under a synopsys directory.

Cheers
-- 
Florian

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Jie Deng]

Hi Joao,

On 2017/1/11 18:35, Joao Pinto wrote:
> Hi Jie,
>
> Às 4:00 AM de 1/11/2017, Jie Deng escreveu:
>> Hi Joao,
>>
>>
>> On 2017/1/10 22:52, Joao Pinto wrote:
>>> This patch renames stmicro/stmmac to synopsys/ since it is a standard
>>> ethernet software package regarding synopsys ethernet controllers, 
>>> supporting
>>> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
>>> retro-compatibility, only the description was changed.
>>>
>>> Signed-off-by: Joao Pinto 
>>> ---
>>> changes v1->v2:
>>> - nothing changed. Just to keep up with patch set version
>>>
>>> @@ -1,5 +1,5 @@
>>>  config STMMAC_ETH
>>> -   tristate "STMicroelectronics 10/100/1000 Ethernet driver"
>>> +   tristate "Synopsys Ethernet drivers"
>>> depends on HAS_IOMEM && HAS_DMA
>>> select MII
>>> select PHYLIB
>>> @@ -14,7 +14,7 @@ config STMMAC_ETH
>>>  if STMMAC_ETH
>>>  
>> "Synopsys Ethernet drivers" is too generic. The name should reflect the
>> controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will submit 
>> a
>> driver for the new 25G/40G/50G/100G XLGMAC IP in the future.
> As you know Synopsys is an IP vendor that as a wide range of IPs related to
> Ethernet. stmmac is a driver that was well built and well maintained and
> supports most of those Ethernet IPs, so it has the potential to be the 
> official
> Synopsys Ethernet driver suite in the future.
>
> Let's make baby steps. For now stmmac supports 10M/100M/1G and also QoS which 
> is
> a separated IP and the different IP cores are selected by device tree.
>
> In the future it would be usefull to be selectable by Kconfig options, making 
> it
> more clear to the kernel user. For example:
>
> Synopsys Ethernet drivers
>   eQoS Core
>   10M Core
>   100M Core
>   1G Core
>   25G Core
>   
>
> The XLGMAC will be great for our users and I will be 100% available to help 
> you
> with it.
>
> Thanks,
> Joao
>
Currently, Synopsys has three series IPs cores. They are
1. 10M/100M/1G   (GMAC, QoS)
2. 1G/2.5G/5G/10G (XGMAC)
3. 10G/25G/40G/50G/100G (XLGMAC)
More info: https://www.synopsys.com/designware-ip/interface-ip/ethernet.html
 
You have successfully merged  dwc_eth_qos.c into stmmac. stmmac now fully
supports the 10M/100M/1G series IPs. Personally, I do support Florian's
suggestion not to rename stmmac.
considering to avoid  future confusion and make easy maintenance, Following is
my suggestions
   1. not to do any rename
   2. keep all 10M/100M/1G IPs (GMAC, QoS) development in stmmac.
   3. keep all 1G/2.5G/5G/10G IP (XGMAC) development in amd-xgbe.
   4. submit a new driver under synopsys/ for the new 10G/25G/40G/50G/100G
(XLGMAC) IP.

Welcome opinions from others.

Thanks,
Jie

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[David Miller]

From: Florian Fainelli 
Date: Wed, 11 Jan 2017 13:14:32 -0800

> As mentioned before, although git is able to track renames, git log does
> not automatically have --follow, so it can be hard for people to track
> down the (new) history of the driver.
> 
> Personally, I don't see much value in doing this rename, especially when
> all the driver internal structures are still going to be named with
> stmmac (and please don't even think about doing a s/stmmac/snps/ inside
> the driver ;)).

I agree, this could really make long term maintainence and bug fix
backporting a nightmare for a lot of people.

Please strongly reconsider, I still don't see any true value in this
rename.

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Florian Fainelli]

On 01/10/2017 06:52 AM, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.

Do re really have to do this? ST Micro were the first to upstream
support for a Synopsys IP, and it was later on identified as being
"stmicro" instead of "synopsys" (during the big driver move under
drivers/net/ethernet) whichever came first in the driver essentially "wins".

As mentioned before, although git is able to track renames, git log does
not automatically have --follow, so it can be hard for people to track
down the (new) history of the driver.

Personally, I don't see much value in doing this rename, especially when
all the driver internal structures are still going to be named with
stmmac (and please don't even think about doing a s/stmmac/snps/ inside
the driver ;)).

My 2 cents.
-- 
Florian

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

Hi Jie,

Às 4:00 AM de 1/11/2017, Jie Deng escreveu:
> Hi Joao,
> 
> 
> On 2017/1/10 22:52, Joao Pinto wrote:
>> This patch renames stmicro/stmmac to synopsys/ since it is a standard
>> ethernet software package regarding synopsys ethernet controllers, supporting
>> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
>> retro-compatibility, only the description was changed.
>>
>> Signed-off-by: Joao Pinto 
>> ---
>> changes v1->v2:
>> - nothing changed. Just to keep up with patch set version
>>
>> @@ -1,5 +1,5 @@
>>  config STMMAC_ETH
>> -tristate "STMicroelectronics 10/100/1000 Ethernet driver"
>> +tristate "Synopsys Ethernet drivers"
>>  depends on HAS_IOMEM && HAS_DMA
>>  select MII
>>  select PHYLIB
>> @@ -14,7 +14,7 @@ config STMMAC_ETH
>>  if STMMAC_ETH
>>  
> "Synopsys Ethernet drivers" is too generic. The name should reflect the
> controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will submit a
> driver for the new 25G/40G/50G/100G XLGMAC IP in the future.

As you know Synopsys is an IP vendor that as a wide range of IPs related to
Ethernet. stmmac is a driver that was well built and well maintained and
supports most of those Ethernet IPs, so it has the potential to be the official
Synopsys Ethernet driver suite in the future.

Let's make baby steps. For now stmmac supports 10M/100M/1G and also QoS which is
a separated IP and the different IP cores are selected by device tree.

In the future it would be usefull to be selectable by Kconfig options, making it
more clear to the kernel user. For example:

Synopsys Ethernet drivers
  eQoS Core
  10M Core
  100M Core
  1G Core
  25G Core
  

The XLGMAC will be great for our users and I will be 100% available to help you
with it.

Thanks,
Joao

>>  config STMMAC_PLATFORM
>> -tristate "STMMAC Platform bus support"
>> +tristate "Platform bus support"
>>  depends on STMMAC_ETH
>>  select MFD_SYSCON
>>  default y
>> @@ -149,13 +149,13 @@ config DWMAC_SUNXI
>>  endif
>>  
>>  config STMMAC_PCI
>> -tristate "STMMAC PCI bus support"
>> +tristate "PCI bus support"
>>  depends on STMMAC_ETH && PCI
>>  ---help---
>>This is to select the Synopsys DWMAC available on PCI devices,
>>if you have a controller with this interface, say Y or M here.
>>  
>> -  This PCI support is tested on XLINX XC2V3000 FF1152AMT0221
>> +  This PCI support was tested on XLINX XC2V3000 FF1152AMT0221
>>D1215994A VIRTEX FPGA board.
> The name is also too generic. Please try to reflect the controller.
> 
> Thanks,
> Jie
> 

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[kbuild test robot]

Hi Joao,

[auto build test WARNING on net-next/master]
[also build test WARNING on next-20170111]
[cannot apply to v4.10-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joao-Pinto/remove-dwc_eth_qos-and-rename-stmicro-stmmac/20170111-003912
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:13,
from arch/m32r/include/asm/bug.h:3,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from drivers/net/ethernet/synopsys/dwmac1000_core.c:30:
   drivers/net/ethernet/synopsys/dwmac1000_core.c: In function 
'dwmac1000_dump_regs':
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/net/ethernet/synopsys/dwmac1000_core.c:107:3: note: in expansion of 
>> macro 'pr_info'
  pr_info("\tReg No. %d (offset 0x%x): 0x%08x\n", i,
  ^~~
--
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/synopsys/dwmac1000.h:25,
from drivers/net/ethernet/synopsys/dwmac1000_dma.c:30:
   drivers/net/ethernet/synopsys/dwmac1000_dma.c: In function 
'dwmac1000_dump_dma_regs':
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^~~~
   include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
>> drivers/net/ethernet/synopsys/dwmac1000_dma.c:215:4: note: in expansion of 
>> macro 'pr_err'
   pr_err("\t Reg No. %d (offset 0x%x): 0x%08x\n", i,
   ^~
--
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/synopsys/dwmac100.h:28,
from drivers/net/ethernet/synopsys/dwmac100_core.c:33:
   drivers/net/ethernet/synopsys/dwmac100_core.c: In function 
'dwmac100_dump_mac_regs':
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/net/ethernet/synopsys/dwmac100_core.c:53:2: note: in expansion of 
>> macro 'pr_info'
 pr_info("\tcontrol reg (offset 0x%x): 0x%08x\n", MAC_CONTROL,
 ^~~
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:299:9: note: in expansion 

Re: [PATCH v2 2/2] stmmac: rename it to synopsys

[Jie Deng]

Hi Joao,


On 2017/1/10 22:52, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.
>
> Signed-off-by: Joao Pinto 
> ---
> changes v1->v2:
> - nothing changed. Just to keep up with patch set version
>
> @@ -1,5 +1,5 @@
>  config STMMAC_ETH
> - tristate "STMicroelectronics 10/100/1000 Ethernet driver"
> + tristate "Synopsys Ethernet drivers"
>   depends on HAS_IOMEM && HAS_DMA
>   select MII
>   select PHYLIB
> @@ -14,7 +14,7 @@ config STMMAC_ETH
>  if STMMAC_ETH
>  
"Synopsys Ethernet drivers" is too generic. The name should reflect the
controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will submit a
driver for the new 25G/40G/50G/100G XLGMAC IP in the future.
>  config STMMAC_PLATFORM
> - tristate "STMMAC Platform bus support"
> + tristate "Platform bus support"
>   depends on STMMAC_ETH
>   select MFD_SYSCON
>   default y
> @@ -149,13 +149,13 @@ config DWMAC_SUNXI
>  endif
>  
>  config STMMAC_PCI
> - tristate "STMMAC PCI bus support"
> + tristate "PCI bus support"
>   depends on STMMAC_ETH && PCI
>   ---help---
> This is to select the Synopsys DWMAC available on PCI devices,
> if you have a controller with this interface, say Y or M here.
>  
> -   This PCI support is tested on XLINX XC2V3000 FF1152AMT0221
> +   This PCI support was tested on XLINX XC2V3000 FF1152AMT0221
> D1215994A VIRTEX FPGA board.
The name is also too generic. Please try to reflect the controller.

Thanks,
Jie

[PATCH v2 2/2] stmmac: rename it to synopsys

[Joao Pinto]

This patch renames stmicro/stmmac to synopsys/ since it is a standard
ethernet software package regarding synopsys ethernet controllers, supporting
the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
retro-compatibility, only the description was changed.

Signed-off-by: Joao Pinto 
---
changes v1->v2:
- nothing changed. Just to keep up with patch set version

 .../bindings/net/{stmmac.txt => synopsys.txt}   |  0
 MAINTAINERS |  4 ++--
 drivers/net/ethernet/Kconfig|  2 +-
 drivers/net/ethernet/Makefile   |  2 +-
 drivers/net/ethernet/stmicro/Kconfig| 21 -
 drivers/net/ethernet/stmicro/Makefile   |  5 -
 .../ethernet/{stmicro/stmmac => synopsys}/Kconfig   |  8 
 .../ethernet/{stmicro/stmmac => synopsys}/Makefile  |  0
 .../{stmicro/stmmac => synopsys}/altr_tse_pcs.c |  0
 .../{stmicro/stmmac => synopsys}/altr_tse_pcs.h |  0
 .../{stmicro/stmmac => synopsys}/chain_mode.c   |  0
 .../ethernet/{stmicro/stmmac => synopsys}/common.h  |  0
 .../ethernet/{stmicro/stmmac => synopsys}/descs.h   |  0
 .../{stmicro/stmmac => synopsys}/descs_com.h|  0
 .../stmmac => synopsys}/dwmac-dwc-qos-eth.c |  0
 .../{stmicro/stmmac => synopsys}/dwmac-generic.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac-ipq806x.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac-lpc18xx.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac-meson.c  |  0
 .../{stmicro/stmmac => synopsys}/dwmac-meson8b.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac-oxnas.c  |  0
 .../{stmicro/stmmac => synopsys}/dwmac-rk.c |  0
 .../{stmicro/stmmac => synopsys}/dwmac-socfpga.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac-sti.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac-stm32.c  |  0
 .../{stmicro/stmmac => synopsys}/dwmac-sunxi.c  |  0
 .../{stmicro/stmmac => synopsys}/dwmac100.h |  0
 .../{stmicro/stmmac => synopsys}/dwmac1000.h|  0
 .../{stmicro/stmmac => synopsys}/dwmac1000_core.c   |  0
 .../{stmicro/stmmac => synopsys}/dwmac1000_dma.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac100_core.c|  0
 .../{stmicro/stmmac => synopsys}/dwmac100_dma.c |  0
 .../ethernet/{stmicro/stmmac => synopsys}/dwmac4.h  |  0
 .../{stmicro/stmmac => synopsys}/dwmac4_core.c  |  0
 .../{stmicro/stmmac => synopsys}/dwmac4_descs.c |  0
 .../{stmicro/stmmac => synopsys}/dwmac4_descs.h |  0
 .../{stmicro/stmmac => synopsys}/dwmac4_dma.c   |  0
 .../{stmicro/stmmac => synopsys}/dwmac4_dma.h   |  0
 .../{stmicro/stmmac => synopsys}/dwmac4_lib.c   |  0
 .../{stmicro/stmmac => synopsys}/dwmac_dma.h|  0
 .../{stmicro/stmmac => synopsys}/dwmac_lib.c|  0
 .../{stmicro/stmmac => synopsys}/enh_desc.c |  0
 .../net/ethernet/{stmicro/stmmac => synopsys}/mmc.h |  0
 .../{stmicro/stmmac => synopsys}/mmc_core.c |  0
 .../{stmicro/stmmac => synopsys}/norm_desc.c|  0
 .../{stmicro/stmmac => synopsys}/ring_mode.c|  0
 .../ethernet/{stmicro/stmmac => synopsys}/stmmac.h  |  0
 .../{stmicro/stmmac => synopsys}/stmmac_ethtool.c   |  0
 .../{stmicro/stmmac => synopsys}/stmmac_hwtstamp.c  |  0
 .../{stmicro/stmmac => synopsys}/stmmac_main.c  |  0
 .../{stmicro/stmmac => synopsys}/stmmac_mdio.c  |  0
 .../{stmicro/stmmac => synopsys}/stmmac_pci.c   |  0
 .../{stmicro/stmmac => synopsys}/stmmac_pcs.h   |  0
 .../{stmicro/stmmac => synopsys}/stmmac_platform.c  |  0
 .../{stmicro/stmmac => synopsys}/stmmac_platform.h  |  0
 .../{stmicro/stmmac => synopsys}/stmmac_ptp.c   |  0
 .../{stmicro/stmmac => synopsys}/stmmac_ptp.h   |  0
 57 files changed, 8 insertions(+), 34 deletions(-)
 rename Documentation/devicetree/bindings/net/{stmmac.txt => synopsys.txt} 
(100%)
 delete mode 100644 drivers/net/ethernet/stmicro/Kconfig
 delete mode 100644 drivers/net/ethernet/stmicro/Makefile
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/Kconfig (95%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/Makefile (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/altr_tse_pcs.c (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/altr_tse_pcs.h (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/chain_mode.c (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/common.h (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/descs.h (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/descs_com.h (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-dwc-qos-eth.c 
(100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-generic.c (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-ipq806x.c (100%)
 rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-lpc18xx.c (100%)
 rename drivers/net/ethernet/{stmicro/stmmac =>