Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1720871 > unrolled thread

Re: [PATCH] DSA support for Micrel KSZ8895

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] DSA support for Micrel KSZ8895 Andrew Lunn <andrew@lunn.ch> - 2017-08-27 18:40 +0200
    Re: [PATCH] DSA support for Micrel KSZ8895 Pavel Machek <pavel@ucw.cz> - 2017-08-28 09:10 +0200
      Re: [PATCH] DSA support for Micrel KSZ8895 Andrew Lunn <andrew@lunn.ch> - 2017-08-28 16:10 +0200
        Re: [PATCH] DSA support for Micrel KSZ8895 Maxim Uvarov <muvarov@gmail.com> - 2017-08-28 16:50 +0200
          Re: [PATCH] DSA support for Micrel KSZ8895 Pavel Machek <pavel@ucw.cz> - 2017-08-29 09:50 +0200
            Re: [PATCH] DSA support for Micrel KSZ8895 Andrew Lunn <andrew@lunn.ch> - 2017-08-29 14:30 +0200
              Re: [PATCH] DSA support for Micrel KSZ8895 Pavel Machek <pavel@ucw.cz> - 2017-08-29 23:20 +0200
                Re: [PATCH] DSA support for Micrel KSZ8895 Florian Fainelli <f.fainelli@gmail.com> - 2017-08-29 23:30 +0200
                  Re: [PATCH] DSA support for Micrel KSZ8895 Maxim Uvarov <muvarov@gmail.com> - 2017-08-30 12:10 +0200
        Re: [PATCH] DSA support for Micrel KSZ8895 Pavel Machek <pavel@ucw.cz> - 2017-08-29 09:50 +0200
          RE: [PATCH] DSA support for Micrel KSZ8895 <Tristram.Ha@microchip.com> - 2017-08-30 23:40 +0200
            Re: [PATCH] DSA support for Micrel KSZ8895 Andrew Lunn <andrew@lunn.ch> - 2017-08-31 00:10 +0200
            Re: [PATCH] DSA support for Micrel KSZ8895 Pavel Machek <pavel@ucw.cz> - 2017-09-01 14:20 +0200
              Re: [PATCH] DSA support for Micrel KSZ8895 Florian Fainelli <f.fainelli@gmail.com> - 2017-09-02 00:20 +0200
                Re: [PATCH] DSA support for Micrel KSZ8895 Pavel Machek <pavel@ucw.cz> - 2017-09-02 17:50 +0200
            Re: [PATCH] DSA support for Micrel KSZ8895 Maxim Uvarov <muvarov@gmail.com> - 2017-09-06 11:20 +0200
              RE: [PATCH] DSA support for Micrel KSZ8895 <Tristram.Ha@microchip.com> - 2017-09-06 18:50 +0200
                Re: [PATCH] DSA support for Micrel KSZ8895 Andrew Lunn <andrew@lunn.ch> - 2017-09-06 19:10 +0200

#1720871 — Re: [PATCH] DSA support for Micrel KSZ8895

> +/**
> + * sw_r_phy - read data from PHY register
> + * @sw:		The switch instance.
> + * @phy:	PHY address to read.
> + * @reg:	PHY register to read.
> + * @val:	Buffer to store the read data.
> + *
> + * This routine reads data from the PHY register.
> + */
> +static void sw_r_phy(struct ksz_device *sw, u16 phy, u16 reg, u16 *val)
> +{
> +	u8 ctrl;
> +	u8 restart;
> +	u8 link;
> +	u8 speed;
> +	u8 force;
> +	u8 p = phy;
> +	u16 data = 0;
> +
> +	switch (reg) {
> +	case PHY_REG_CTRL:
> +		ksz_pread8(sw, p, P_LOCAL_CTRL, &ctrl);
> +		ksz_pread8(sw, p, P_NEG_RESTART_CTRL, &restart);
> +		ksz_pread8(sw, p, P_SPEED_STATUS, &speed);
> +		ksz_pread8(sw, p, P_FORCE_CTRL, &force);
> +		if (restart & PORT_PHY_LOOPBACK)
> +			data |= PHY_LOOPBACK;
> +		if (force & PORT_FORCE_100_MBIT)
> +			data |= PHY_SPEED_100MBIT;
> +		if (!(force & PORT_AUTO_NEG_DISABLE))
> +			data |= PHY_AUTO_NEG_ENABLE;
> +		if (restart & PORT_POWER_DOWN)
> +			data |= PHY_POWER_DOWN;
> +		if (restart & PORT_AUTO_NEG_RESTART)
> +			data |= PHY_AUTO_NEG_RESTART;
> +		if (force & PORT_FORCE_FULL_DUPLEX)
> +			data |= PHY_FULL_DUPLEX;
> +		if (speed & PORT_HP_MDIX)
> +			data |= PHY_HP_MDIX;
> +		if (restart & PORT_FORCE_MDIX)
> +			data |= PHY_FORCE_MDIX;
> +		if (restart & PORT_AUTO_MDIX_DISABLE)
> +			data |= PHY_AUTO_MDIX_DISABLE;
> +		if (restart & PORT_TX_DISABLE)
> +			data |= PHY_TRANSMIT_DISABLE;
> +		if (restart & PORT_LED_OFF)
> +			data |= PHY_LED_DISABLE;
> +		break;
> +	case PHY_REG_STATUS:
> +		ksz_pread8(sw, p, P_LINK_STATUS, &link);
> +		ksz_pread8(sw, p, P_SPEED_STATUS, &speed);
> +		data = PHY_100BTX_FD_CAPABLE |
> +			PHY_100BTX_CAPABLE |
> +			PHY_10BT_FD_CAPABLE |
> +			PHY_10BT_CAPABLE |
> +			PHY_AUTO_NEG_CAPABLE;
> +		if (link & PORT_AUTO_NEG_COMPLETE)
> +			data |= PHY_AUTO_NEG_ACKNOWLEDGE;
> +		if (link & PORT_STAT_LINK_GOOD)
> +			data |= PHY_LINK_STATUS;
> +		break;
> +	case PHY_REG_ID_1:
> +		data = KSZ8895_ID_HI;
> +		break;
> +	case PHY_REG_ID_2:
> +		data = KSZ8895_ID_LO;
> +		break;

According to the datasheet, the PHY has the normal ID registers,
which have the value 0x0022, 0x1450. So it should be possible to have
a standard PHY driver in drivers/net/phy.

In fact, the IDs suggest it is a micrel phy, and 1430, 1435 are
already supported. So it could be you only need minor modifications to
the micrel.c.

    Andrew

[toc] | [next] | [standalone]

#1721098

[Multipart message — attachments visible in raw view] — view raw

Hi!

Thanks for review.

> > +	case PHY_REG_STATUS:
> > +		ksz_pread8(sw, p, P_LINK_STATUS, &link);
> > +		ksz_pread8(sw, p, P_SPEED_STATUS, &speed);
> > +		data = PHY_100BTX_FD_CAPABLE |
> > +			PHY_100BTX_CAPABLE |
> > +			PHY_10BT_FD_CAPABLE |
> > +			PHY_10BT_CAPABLE |
> > +			PHY_AUTO_NEG_CAPABLE;
> > +		if (link & PORT_AUTO_NEG_COMPLETE)
> > +			data |= PHY_AUTO_NEG_ACKNOWLEDGE;
> > +		if (link & PORT_STAT_LINK_GOOD)
> > +			data |= PHY_LINK_STATUS;
> > +		break;
> > +	case PHY_REG_ID_1:
> > +		data = KSZ8895_ID_HI;
> > +		break;
> > +	case PHY_REG_ID_2:
> > +		data = KSZ8895_ID_LO;
> > +		break;
> 
> According to the datasheet, the PHY has the normal ID registers,
> which have the value 0x0022, 0x1450. So it should be possible to have
> a standard PHY driver in drivers/net/phy.
> 
> In fact, the IDs suggest it is a micrel phy, and 1430, 1435 are
> already supported. So it could be you only need minor modifications to
> the micrel.c.

I may be confused here, but AFAICT:

1) Yes, it has standard layout when accessed over MDIO. But then
there's no access to the bridging functionality, and MDIO access may
not be available. [I was told not to use it for this design, so I did
not].

2) drivers/net/phy/spi_ks8995.c can be trivially modified to work with
this chip.. but then you don't get the bridge functionality. (And I'm
not sure how it works / who translates layouts in this case.)

I'd like to get rid of this code, or use some existing code instead,
but I don't think it is possible while keeping the SPI accesss. Let me
know if I'm wrong.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1721643

> I may be confused here, but AFAICT:
> 
> 1) Yes, it has standard layout when accessed over MDIO. 


Section 4.8 of the datasheet says:

	All the registers defined in this section can be also accessed
	via the SPI interface.

Meaning all PHY registers can be access via the SPI interface. So you
should be able to make a standard Linux MDIO bus driver which performs
SPI reads.

    Andrew

[toc] | [prev] | [next] | [standalone]

#1721689

Micrel has some drivers on their web site to support some chips. For
that chips they do virtual mdio over spi.
And driver is available on download page:
http://www.microchip.com/wwwproducts/en/KSZ8895

Documentation->Software library.

Both driver and DSA driver. Driver has to work with some minor fixups
related to your kernel version. But I think they are don't care about
up-streaming that code.
So you can take their code as a reference.

2017-08-28 17:09 GMT+03:00 Andrew Lunn <andrew@lunn.ch>:
>> I may be confused here, but AFAICT:
>>
>> 1) Yes, it has standard layout when accessed over MDIO.
>
>
> Section 4.8 of the datasheet says:
>
>         All the registers defined in this section can be also accessed
>         via the SPI interface.
>
> Meaning all PHY registers can be access via the SPI interface. So you
> should be able to make a standard Linux MDIO bus driver which performs
> SPI reads.
>
>     Andrew

Micrel has some drivers on their web site to support some chips. For
that chips they do virtual mdio over spi.
And driver is available on download page:
http://www.microchip.com/wwwproducts/en/KSZ8895

Documentation->Software library.

Both driver and DSA driver. Driver has to work with some minor fixups
related to your kernel version. But I think they are don't care about
up-streaming that code.
So you can take their code as a reference.

-- 
Best regards,
Maxim Uvarov

[toc] | [prev] | [next] | [standalone]

#1722201

[Multipart message — attachments visible in raw view] — view raw

Hi!

> Micrel has some drivers on their web site to support some chips. For
> that chips they do virtual mdio over spi.
> And driver is available on download page:
> http://www.microchip.com/wwwproducts/en/KSZ8895
> 
> Documentation->Software library.
> 
> Both driver and DSA driver. Driver has to work with some minor fixups
> related to your kernel version. But I think they are don't care about
> up-streaming that code.
> So you can take their code as a reference.

"Minor fixups". Take a look at the driver.. I wanted to do a "minor
fixups". It turned out it was easier to start from scratch.

But the MDIO emaulation code is from their driver, after lots of
deletions.

								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1722428

> But the MDIO emaulation code is from their driver, after lots of
> deletions.

Is this driver supposed to run on lots of different OSs? That would
explain why they ignored the Linux MDIO and PHY layers.

If possible, please make use of the Linux infrastructure.

   Andrew

[toc] | [prev] | [next] | [standalone]

#1722856

[Multipart message — attachments visible in raw view] — view raw

On Tue 2017-08-29 14:26:04, Andrew Lunn wrote:
> > But the MDIO emaulation code is from their driver, after lots of
> > deletions.
> 
> Is this driver supposed to run on lots of different OSs? That would
> explain why they ignored the Linux MDIO and PHY layers.

It did not look particulary portable.

> If possible, please make use of the Linux infrastructure.

I did not find any infrastructure I could use instead
ksz_mdio_emulation.

Now, drivers/net/phy/spi_ks8995.c can access the PHY registers, and I
can not see any translation there, so there may be something I'm
missing.

Pointers would be welcome at this point.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1722861

On 08/29/2017 02:15 PM, Pavel Machek wrote:
> On Tue 2017-08-29 14:26:04, Andrew Lunn wrote:
>>> But the MDIO emaulation code is from their driver, after lots of
>>> deletions.
>>
>> Is this driver supposed to run on lots of different OSs? That would
>> explain why they ignored the Linux MDIO and PHY layers.
> 
> It did not look particulary portable.

Part of the problem is that they need to duplicate the standard MII
definitions, whereas we could re-use those from include/linux/mii.h
and/or mdio.h.

> 
>> If possible, please make use of the Linux infrastructure.
> 
> I did not find any infrastructure I could use instead
> ksz_mdio_emulation.

fixed PHY/swphy.c is as close as it could get, but it is a highly
simplified version of this.

> 
> Now, drivers/net/phy/spi_ks8995.c can access the PHY registers, and I
> can not see any translation there, so there may be something I'm
> missing.

I don't see anything in that driver that seems to access PHY registers
what makes you think it does?

There's got to be a way to perform indirect accesses through SPI,
Woojung, do you know?

> 
> Pointers would be welcome at this point.
> 
> Thanks,
> 									Pavel
> 


-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1723182

2017-08-30 0:23 GMT+03:00 Florian Fainelli <f.fainelli@gmail.com>:
> On 08/29/2017 02:15 PM, Pavel Machek wrote:
>> On Tue 2017-08-29 14:26:04, Andrew Lunn wrote:
>>>> But the MDIO emaulation code is from their driver, after lots of
>>>> deletions.
>>>
>>> Is this driver supposed to run on lots of different OSs? That would
>>> explain why they ignored the Linux MDIO and PHY layers.
>>
>> It did not look particulary portable.
>
> Part of the problem is that they need to duplicate the standard MII
> definitions, whereas we could re-use those from include/linux/mii.h
> and/or mdio.h.
>
>>
>>> If possible, please make use of the Linux infrastructure.
>>
>> I did not find any infrastructure I could use instead
>> ksz_mdio_emulation.
>
> fixed PHY/swphy.c is as close as it could get, but it is a highly
> simplified version of this.
>
>>
>> Now, drivers/net/phy/spi_ks8995.c can access the PHY registers, and I
>> can not see any translation there, so there may be something I'm
>> missing.
>
> I don't see anything in that driver that seems to access PHY registers
> what makes you think it does?
>
> There's got to be a way to perform indirect accesses through SPI,
> Woojung, do you know?
>

As I understand they just attach phy on spi bus with generic driver:

        phy_addr = 0;
        phy_mode = PHY_INTERFACE_MODE_MII;
        snprintf(bus_id, MII_BUS_ID_SIZE, "sw.%d", sw_device_present);
        snprintf(phy_id, MII_BUS_ID_SIZE, PHY_ID_FMT, bus_id, phy_addr);
        phydev = phy_attach(netdev, phy_id, 0, phy_mode);
        if (!IS_ERR(phydev)) {
                phydev->adjust_link = sw_adjust_link;
                return phydev;
        }

Where is bus is:
bus = mdiobus_alloc();
bus->read = ksz_mii_read; (spi read function)
bus->write = ksz_mii_write;

Then just generic reads:
    .config_aneg    = genphy_config_aneg,
    .read_status    = genphy_read_status,


Maxim.

>>
>> Pointers would be welcome at this point.
>>
>> Thanks,
>>                                                                       Pavel
>>
>
>
> --
> Florian



-- 
Best regards,
Maxim Uvarov

[toc] | [prev] | [next] | [standalone]

#1722198

[Multipart message — attachments visible in raw view] — view raw

On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
> > I may be confused here, but AFAICT:
> > 
> > 1) Yes, it has standard layout when accessed over MDIO. 
> 
> 
> Section 4.8 of the datasheet says:
> 
> 	All the registers defined in this section can be also accessed
> 	via the SPI interface.
> 
> Meaning all PHY registers can be access via the SPI interface. So you
> should be able to make a standard Linux MDIO bus driver which performs
> SPI reads.

As far as I can tell (and their driver confirms) -- yes, all those
registers can be accessed over the SPI, they are just shuffled
around... hence MDIO emulation code. I copied it from their code (see
the copyrights) so no, I don't believe there's nicer solution.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1723682

> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
> > > I may be confused here, but AFAICT:
> > >
> > > 1) Yes, it has standard layout when accessed over MDIO.
> >
> >
> > Section 4.8 of the datasheet says:
> >
> > 	All the registers defined in this section can be also accessed
> > 	via the SPI interface.
> >
> > Meaning all PHY registers can be access via the SPI interface. So you
> > should be able to make a standard Linux MDIO bus driver which performs
> > SPI reads.
> 
> As far as I can tell (and their driver confirms) -- yes, all those registers can be
> accessed over the SPI, they are just shuffled around... hence MDIO
> emulation code. I copied it from their code (see the copyrights) so no, I don't
> believe there's nicer solution.
> 
> Best regards,
> 
> 									Pavel

Can you hold on your developing work on KSZ8895 driver?  I am afraid your effort may be in vain.  We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.

The driver files all follow the structures of the current KSZ9477 DSA driver, and the file tag_ksz.c will be updated to handle the tail tag of different chips, which requires including the ksz_priv.h header.  That is required nevertheless to support using the offload_fwd_mark indication.

The KSZ8795 driver will be submitted after Labor Day (9/4) if testing reveals no problem.  The KSZ8895 driver will be submitted right after that.  You should have no problem using the driver right away.

Tristram Ha
Principal Software Engineer
Microchip Technology Inc.

[toc] | [prev] | [next] | [standalone]

#1723706

> The KSZ8795 driver will be submitted after Labor Day (9/4) if
> testing reveals no problem.  The KSZ8895 driver will be submitted
> right after that.  You should have no problem using the driver right
> away.

Hi Tristram

Release early, release often. It stops people wasting time....

Also, we are likely to give you feedback, asking you to make
changes. Testing is important, but you are probably going to have to
do it a number of times. So it is not everything passes now, don't
worry, you will have time to fix things up as you go through review
cycles.

    Andrew

[toc] | [prev] | [next] | [standalone]

#1725009

[Multipart message — attachments visible in raw view] — view raw

Hi!

On Wed 2017-08-30 21:32:07, Tristram.Ha@microchip.com wrote:
> > On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
> > > > I may be confused here, but AFAICT:
> > > >
> > > > 1) Yes, it has standard layout when accessed over MDIO.
> > >
> > >
> > > Section 4.8 of the datasheet says:
> > >
> > > 	All the registers defined in this section can be also accessed
> > > 	via the SPI interface.
> > >
> > > Meaning all PHY registers can be access via the SPI interface. So you
> > > should be able to make a standard Linux MDIO bus driver which performs
> > > SPI reads.
> > 
> > As far as I can tell (and their driver confirms) -- yes, all those registers can be
> > accessed over the SPI, they are just shuffled around... hence MDIO
> > emulation code. I copied it from their code (see the copyrights) so no, I don't
> > believe there's nicer solution.
> > 
> > Best regards,
> 
> Can you hold on your developing work on KSZ8895 driver?  I am afraid your effort may be in vain.  We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
>

Well, thanks for heads up... but its too late to stop now. I already
have working code, without the advanced features.

I don't know how far away you are with the development. You may want
to start from my driver (but its probably too late now).

> The driver files all follow the structures of the current KSZ9477 DSA driver, and the file tag_ksz.c will be updated to handle the tail tag of different chips, which requires including the ksz_priv.h header.  That is required nevertheless to support using the offload_fwd_mark indication.
> 
> The KSZ8795 driver will be submitted after Labor Day (9/4) if
> testing reveals no problem.  The KSZ8895 driver will be submitted
> right after that.  You should have no problem using the driver right
> away.

Well, normally world can help with the testing, too. It would be nice
to see the code, as [RFC]. There's great chance that you'll have to
modify the code to adress review feedback, which is why seeing code
soon is useful.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1725386

On 09/01/2017 05:15 AM, Pavel Machek wrote:
> Hi!
> 
> On Wed 2017-08-30 21:32:07, Tristram.Ha@microchip.com wrote:
>>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
>>>>> I may be confused here, but AFAICT:
>>>>>
>>>>> 1) Yes, it has standard layout when accessed over MDIO.
>>>>
>>>>
>>>> Section 4.8 of the datasheet says:
>>>>
>>>> 	All the registers defined in this section can be also accessed
>>>> 	via the SPI interface.
>>>>
>>>> Meaning all PHY registers can be access via the SPI interface. So you
>>>> should be able to make a standard Linux MDIO bus driver which performs
>>>> SPI reads.
>>>
>>> As far as I can tell (and their driver confirms) -- yes, all those registers can be
>>> accessed over the SPI, they are just shuffled around... hence MDIO
>>> emulation code. I copied it from their code (see the copyrights) so no, I don't
>>> believe there's nicer solution.
>>>
>>> Best regards,
>>
>> Can you hold on your developing work on KSZ8895 driver?  I am afraid your effort may be in vain.  We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
>>
> 
> Well, thanks for heads up... but its too late to stop now. I already
> have working code, without the advanced features.

No driver has landed yet nor has any driver been posted in a proper form
or shape, so at this point neither of you are able to make any claims as
to which one should be chosen.

> 
> I don't know how far away you are with the development. You may want
> to start from my driver (but its probably too late now).

I would tend to favor Tristram's submission when we see it because he
claims support for more devices and it is likely to be backed and
maintained by Microchip in the future.

I am sure there will be opportunity for you to contribute a lot to this
driver. Of course, this all depends on the code quality and timing, but
having two people work on the same things in parallel is just a complete
waste of each other's time so we might as well wait for Tristram to post
the said driver and define a plan of action from there?
-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1725518

[Multipart message — attachments visible in raw view] — view raw

Hi!

> >>>> Section 4.8 of the datasheet says:
> >>>>
> >>>> 	All the registers defined in this section can be also accessed
> >>>> 	via the SPI interface.
> >>>>
> >>>> Meaning all PHY registers can be access via the SPI interface. So you
> >>>> should be able to make a standard Linux MDIO bus driver which performs
> >>>> SPI reads.
> >>>
> >>> As far as I can tell (and their driver confirms) -- yes, all those registers can be
> >>> accessed over the SPI, they are just shuffled around... hence MDIO
> >>> emulation code. I copied it from their code (see the copyrights) so no, I don't
> >>> believe there's nicer solution.
> >>>
> >>> Best regards,
> >>
> >> Can you hold on your developing work on KSZ8895 driver?  I am afraid your effort may be in vain.  We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
> >>
> > 
> > Well, thanks for heads up... but its too late to stop now. I already
> > have working code, without the advanced features.
> 
> No driver has landed yet nor has any driver been posted in a proper form
> or shape, so at this point neither of you are able to make any claims as
> to which one should be chosen.

I certainly do not want to make any claims. Tristram's driver is
likely to support all (most?) features of the chip, which is not my
goal.

> > I don't know how far away you are with the development. You may want
> > to start from my driver (but its probably too late now).
> 
> I would tend to favor Tristram's submission when we see it because he
> claims support for more devices and it is likely to be backed and
> maintained by Microchip in the future.

Well, I guess we decide when we see the code, that's how it works, right?

> I am sure there will be opportunity for you to contribute a lot to this
> driver. Of course, this all depends on the code quality and timing, but
> having two people work on the same things in parallel is just a complete
> waste of each other's time so we might as well wait for Tristram to post
> the said driver and define a plan of action from there?

Well, it would be good to see the code, so we can judge the
quality. Normally, code is posted before testing, so this kind of
problems does not arise.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1727274

2017-08-31 0:32 GMT+03:00  <Tristram.Ha@microchip.com>:
>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
>> > > I may be confused here, but AFAICT:
>> > >
>> > > 1) Yes, it has standard layout when accessed over MDIO.
>> >
>> >
>> > Section 4.8 of the datasheet says:
>> >
>> >     All the registers defined in this section can be also accessed
>> >     via the SPI interface.
>> >
>> > Meaning all PHY registers can be access via the SPI interface. So you
>> > should be able to make a standard Linux MDIO bus driver which performs
>> > SPI reads.
>>
>> As far as I can tell (and their driver confirms) -- yes, all those registers can be
>> accessed over the SPI, they are just shuffled around... hence MDIO
>> emulation code. I copied it from their code (see the copyrights) so no, I don't
>> believe there's nicer solution.
>>
>> Best regards,
>>
>>                                                                       Pavel
>
> Can you hold on your developing work on KSZ8895 driver?  I am afraid your effort may be in vain.  We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
>
> The driver files all follow the structures of the current KSZ9477 DSA driver, and the file tag_ksz.c will be updated to handle the tail tag of different chips, which requires including the ksz_priv.h header.  That is required nevertheless to support using the offload_fwd_mark indication.
>
> The KSZ8795 driver will be submitted after Labor Day (9/4) if testing reveals no problem.  The KSZ8895 driver will be submitted right after that.  You should have no problem using the driver right away.
>

Hello Tristram, is there any update for that driver?

Maxim.


> Tristram Ha
> Principal Software Engineer
> Microchip Technology Inc.
>



-- 
Best regards,
Maxim Uvarov

[toc] | [prev] | [next] | [standalone]

#1727648

> -----Original Message-----
> From: Maxim Uvarov [mailto:muvarov@gmail.com]
> Sent: Wednesday, September 06, 2017 2:15 AM
> To: Tristram Ha - C24268
> Cc: Pavel Machek; Woojung Huh - C21699; Nathan Conrad; Vivien Didelot;
> Florian Fainelli; netdev; linux-kernel@vger.kernel.org; Andrew Lunn
> Subject: Re: [PATCH] DSA support for Micrel KSZ8895
> 
> 2017-08-31 0:32 GMT+03:00  <Tristram.Ha@microchip.com>:
> >> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
> >> > > I may be confused here, but AFAICT:
> >> > >
> >> > > 1) Yes, it has standard layout when accessed over MDIO.
> >> >
> >> >
> >> > Section 4.8 of the datasheet says:
> >> >
> >> >     All the registers defined in this section can be also accessed
> >> >     via the SPI interface.
> >> >
> >> > Meaning all PHY registers can be access via the SPI interface. So
> >> > you should be able to make a standard Linux MDIO bus driver which
> >> > performs SPI reads.
> >>
> >> As far as I can tell (and their driver confirms) -- yes, all those
> >> registers can be accessed over the SPI, they are just shuffled
> >> around... hence MDIO emulation code. I copied it from their code (see
> >> the copyrights) so no, I don't believe there's nicer solution.
> >>
> >> Best regards,
> >>
> >>
> >> Pavel
> >
> > Can you hold on your developing work on KSZ8895 driver?  I am afraid your
> effort may be in vain.  We at Microchip are planning to release DSA drivers
> for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
> >
> > The driver files all follow the structures of the current KSZ9477 DSA driver,
> and the file tag_ksz.c will be updated to handle the tail tag of different chips,
> which requires including the ksz_priv.h header.  That is required
> nevertheless to support using the offload_fwd_mark indication.
> >
> > The KSZ8795 driver will be submitted after Labor Day (9/4) if testing reveals
> no problem.  The KSZ8895 driver will be submitted right after that.  You
> should have no problem using the driver right away.
> >
> 
> Hello Tristram, is there any update for that driver?
> 
> Maxim.
> 

The patches are under review internally and will need to be updated and approved by Woojung before formal submission.  Problem is although KSZ8795 and KSZ8895 drivers are new code and will be submitted as RFC, they depend on the change of KSZ9477 driver currently in the kernel, which require more rigorous review.

[toc] | [prev] | [next] | [standalone]

#1727657

> The patches are under review internally and will need to be updated
> and approved by Woojung before formal submission.  Problem is
> although KSZ8795 and KSZ8895 drivers are new code and will be
> submitted as RFC, they depend on the change of KSZ9477 driver
> currently in the kernel, which require more rigorous review.

Please be aware that they will also go though review when you post
them. This can be anything from great, nice job, to throw them away
and start again. Since you are submitting RFCs we understand it is
early code, issues still to be solved, and we can make suggestions how
to solve those issues.

Post early, post often...

     Andrew

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web