On Fri, Feb 10, 2017 at 10:30:58AM -0800, Florian Fainelli wrote:
> On 02/10/2017 05:02 AM, Greg KH wrote:
> > On Thu, Jan 19, 2017 at 04:51:55PM +, Russell King - ARM Linux wrote:
> >> (This is mainly for Greg's benefit to help him understand the issue.)
> >>
> >> I think the diagram you gave
On 02/10/2017 05:02 AM, Greg KH wrote:
> On Thu, Jan 19, 2017 at 04:51:55PM +, Russell King - ARM Linux wrote:
>> (This is mainly for Greg's benefit to help him understand the issue.)
>>
>> I think the diagram you gave initially made this confusing, as it
>> talks about a CPU(sic) producing the
On Thu, Jan 19, 2017 at 04:51:55PM +, Russell King - ARM Linux wrote:
> (This is mainly for Greg's benefit to help him understand the issue.)
>
> I think the diagram you gave initially made this confusing, as it
> talks about a CPU(sic) producing the "RGMII" and "MII-MGMT".
>
> Let's instead
On 01/25/2017 01:25 PM, Greg KH wrote:
> On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote:
>> On 01/19/2017 10:12 AM, Florian Fainelli wrote:
>>>
>>> Back to the actual code that triggered this discussion, the whole
>>> purpose is just a safeguard. Given a device reference, we can a
On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote:
> On 01/19/2017 10:12 AM, Florian Fainelli wrote:
> >
> > Back to the actual code that triggered this discussion, the whole
> > purpose is just a safeguard. Given a device reference, we can assume
> > that it is indeed the backing d
On 01/19/2017 10:12 AM, Florian Fainelli wrote:
>
> Back to the actual code that triggered this discussion, the whole
> purpose is just a safeguard. Given a device reference, we can assume
> that it is indeed the backing device for a net_device, and we could do a
> to_net_device() right away (and
On 01/19/2017 08:51 AM, Russell King - ARM Linux wrote:
> (This is mainly for Greg's benefit to help him understand the issue.)
>
> I think the diagram you gave initially made this confusing, as it
> talks about a CPU(sic) producing the "RGMII" and "MII-MGMT".
>
> Let's instead show a better re
(This is mainly for Greg's benefit to help him understand the issue.)
I think the diagram you gave initially made this confusing, as it
talks about a CPU(sic) producing the "RGMII" and "MII-MGMT".
Let's instead show a better representation that hopefully helps Greg
understand networking. :)
C
On Thu, Jan 19, 2017 at 05:30:13PM +0100, Greg KH wrote:
> On Thu, Jan 19, 2017 at 03:53:15PM +0100, Andrew Lunn wrote:
> > > > > struct dsa_platform_data {
> > > > > /*
> > > > > * Reference to a Linux network interface that connects
> > > > > * to the root switch chip of
On Thu, Jan 19, 2017 at 03:53:15PM +0100, Andrew Lunn wrote:
> > > > struct dsa_platform_data {
> > > > /*
> > > > * Reference to a Linux network interface that connects
> > > > * to the root switch chip of the tree.
> > > > */
> > > > struct device *net
> > > struct dsa_platform_data {
> > > /*
> > > * Reference to a Linux network interface that connects
> > > * to the root switch chip of the tree.
> > > */
> > > struct device *netdev;
>
> This I think is the oddest thing, why do you need to have the "
On Mon, Jan 16, 2017 at 12:01:02PM -0800, Florian Fainelli wrote:
> On 01/15/2017 11:16 AM, Andrew Lunn wrote:
> >>> What exactly is the relationship between these devices (a ascii-art tree
> >>> or sysfs tree output might be nice) so I can try to understand what is
> >>> going on here.
> >
> > Hi
On Mon, Jan 16, 2017 at 12:01:02PM -0800, Florian Fainelli wrote:
> On 01/15/2017 11:16 AM, Andrew Lunn wrote:
> >>> What exactly is the relationship between these devices (a ascii-art tree
> >>> or sysfs tree output might be nice) so I can try to understand what is
> >>> going on here.
> >
> > Hi
On 01/15/2017 11:16 AM, Andrew Lunn wrote:
>>> What exactly is the relationship between these devices (a ascii-art tree
>>> or sysfs tree output might be nice) so I can try to understand what is
>>> going on here.
>
> Hi Greg, Florian
>
> A few diagrams and trees which might help understand what
> > What exactly is the relationship between these devices (a ascii-art tree
> > or sysfs tree output might be nice) so I can try to understand what is
> > going on here.
Hi Greg, Florian
A few diagrams and trees which might help understand what is going on.
The first diagram comes from the 2008
On 01/15/2017 09:39 AM, Greg KH wrote:
> On Sun, Jan 15, 2017 at 09:27:22AM -0800, Florian Fainelli wrote:
>>
>>
>> On 01/15/2017 03:06 AM, Greg KH wrote:
>>> On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
Now that the base device driver code provides an identical
imple
On Sun, Jan 15, 2017 at 09:27:22AM -0800, Florian Fainelli wrote:
>
>
> On 01/15/2017 03:06 AM, Greg KH wrote:
> > On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
> >> Now that the base device driver code provides an identical
> >> implementation of dev_find_class() utilize devi
On 01/15/2017 03:06 AM, Greg KH wrote:
> On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
>> Now that the base device driver code provides an identical
>> implementation of dev_find_class() utilize device_find_class() instead
>> of our own version of it.
>>
>> Signed-off-by: Flor
On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
> Now that the base device driver code provides an identical
> implementation of dev_find_class() utilize device_find_class() instead
> of our own version of it.
>
> Signed-off-by: Florian Fainelli
> ---
> net/dsa/dsa.c | 22 ++---
Now that the base device driver code provides an identical
implementation of dev_find_class() utilize device_find_class() instead
of our own version of it.
Signed-off-by: Florian Fainelli
---
net/dsa/dsa.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git
20 matches
Mail list logo
