[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1348130157.2006.87.camel@jtkirshe-mobl>
Date: Thu, 20 Sep 2012 01:35:57 -0700
From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To: byungho an <bh74an@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
peppe.cavallaro@...com, deepak.silki@...com,
francesco.virlinzi@...com, eilong@...adcom.com,
alexander.h.duyck@...el.com, bhutchings@...arflare.com,
linville@...driver.com, wey-ty.w.guy@...el.com, coelho@...com,
e.wahlig@...sung.com, aditya.ps@...sung.com, ihlee215@...il.com
Subject: Re: Regarding ethernet directory between IP and SoC chip vendor.
On Wed, 2012-09-19 at 21:39 +0900, byungho an wrote:
> Hi all,
>
> I have one suggestion for ethernet dir.
> Currently It is well-defined and good for management.
>
> But if IP vendor is different from SoC vender, It is a bit confusing
> to guess dir name.
> For example, stmmac is using Synopsys dwmac.
> In this case, if another SoC vendors try to use Synopsys IP, they
> sould make their own dir under the their name? Even the IP is same...
>
> If there is common dir of IP vendor, It would be more clear.
> If that, other SoC vendors that try to use the IP can make their own
> directory and drivers intuitionally.
>
> What do you think about it?
> I want to exchange opinion and find a resonable and rational way.
>
> Thank you.
> Andy
A lot of thought went into how to organize all the Ethernet drivers, and
after much discussion, it seemed best to organize the drivers by the
manufacturer rather than by who was supporting/writing the driver. The
reason being is that the manufacturer of the silicon was not going to
change as frequently as the driver supporters. We did not want to have
to change the location of a driver every time a company was bought.
I personally am open to suggestions on improving the directory structure
so if have an idea on how to improve the directory structure please
provide a patch. Keep in mind, that drivers can not keep moving because
some company bought another company.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists