Re: [PATCH v2 2/2] stmmac: rename it to synopsys
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 singularit
Re: [PATCH v2 2/2] stmmac: rename it to synopsys
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
À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
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
À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
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
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
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
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
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
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
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
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
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
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 of
Re: [PATCH v2 2/2] stmmac: rename it to synopsys
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