On 7/10/20 4:35 PM, Andrew Lunn wrote:
>> In principle there is nothing in this para-virtualization design that
>> would preclude a quirky quad PHY from being accessed in a
>> virtualization-safe mode. The main use case for PHY access in a VM is
>> for detecting when the link went down. Worst case,
> In principle there is nothing in this para-virtualization design that
> would preclude a quirky quad PHY from being accessed in a
> virtualization-safe mode. The main use case for PHY access in a VM is
> for detecting when the link went down. Worst case, the QEMU host-side
> driver could lie abou
Hi Tobias,
On Fri, Jul 10, 2020 at 11:30:21AM +0200, Tobias Waldekranz wrote:
> On Fri Jul 10, 2020 at 4:33 AM CEST, Vladimir Oltean wrote:
> > On Fri, Jul 10, 2020 at 01:20:35AM +0200, Andrew Lunn wrote:
> > > > Virtualization is a reasonable use case in my opinion and it would
> > > > need somet
On Fri Jul 10, 2020 at 4:33 AM CEST, Vladimir Oltean wrote:
> On Fri, Jul 10, 2020 at 01:20:35AM +0200, Andrew Lunn wrote:
> > > Virtualization is a reasonable use case in my opinion and it would
> > > need something like this, for the guest kernel to have access to its
> > > PHY.
> >
> > And i wo
On Fri Jul 10, 2020 at 2:39 AM CEST, Andrew Lunn wrote:
> On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> > Hi netdev,
> >
> > TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> > idea?
> >
> > The kernel does not, as far as I know, have a low-level debug
> >
On Thu Jul 9, 2020 at 5:36 PM CEST, Florian Fainelli wrote:
> Certainly, the current interface clearly has deficiencies and since
> mdio_device instances were introduced, we should have an interface to
> debug those from user-space ala i2c-dev or spidev.
>
> Can you post the kernel code for review?
On Fri Jul 10, 2020 at 3:18 AM CEST, Vladimir Oltean wrote:
> I will let the PHY library maintainers comment about implementation
> design choices made by mdio-netlink. However, I want to add a big "+1"
> from my side for identifying the correct issues in the existing PHY
> ioctls and doing somethi
On Fri, Jul 10, 2020 at 01:20:35AM +0200, Andrew Lunn wrote:
> > Virtualization is a reasonable use case in my opinion and it would
> > need something like this, for the guest kernel to have access to its
> > PHY.
>
> And i would like a better understanding of this use case. It seems odd
> you are
> Fear not, the lack of a mainline UAPI for MDIO access will not prevent
> any vendor from adding a sysfs mdio_read and mdio_write, if they need it
> for their user space SDK :)
They do. But it means you have to use their kernel, or at least their
kernel module. That will put off some people. But
Hi Andrew,
On Fri, Jul 10, 2020 at 12:39:36AM +0200, Andrew Lunn wrote:
> On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> > Hi netdev,
> >
> > TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> > idea?
> >
> > The kernel does not, as far as I know, have a lo
> And, while we're at it: context switches from a VM to a host are
> expensive. And the PHY library polls around 5 MDIO registers per PHY
> every second.
Just wire up the interrupt. That stops all polling.
It would however be good to have details of what QEMU wants.
Andrew
On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> Hi netdev,
>
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
>
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c-dev or
> sp
On 7/9/2020 1:47 PM, Tobias Waldekranz wrote:
> Hi netdev,
>
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
>
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c-dev or
> spi-dev for example.
Hi Tobias,
On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> Hi netdev,
>
> TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> idea?
>
> The kernel does not, as far as I know, have a low-level debug
> interface to MDIO devices. I.e. something equivalent to i2c
14 matches
Mail list logo
