<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/phy/bcm-phy-lib.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-06-09T09:38:43Z</updated>
<entry>
<title>net: phy: broadcom: Add support for setting LED brightness</title>
<updated>2023-06-09T09:38:43Z</updated>
<author>
<name>Florian Fainelli</name>
<email>florian.fainelli@broadcom.com</email>
</author>
<published>2023-06-07T18:34:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bd5736e146e35f9eabe8c1bfc0ab00979ae62930'/>
<id>urn:sha1:bd5736e146e35f9eabe8c1bfc0ab00979ae62930</id>
<content type='text'>
Broadcom PHYs have two LEDs selector registers which allow us to control
the LED assignment, including how to turn them on/off.

Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: Add LPI counter</title>
<updated>2023-06-02T04:40:10Z</updated>
<author>
<name>Florian Fainelli</name>
<email>florian.fainelli@broadcom.com</email>
</author>
<published>2023-05-31T23:17:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e8b6f79b41840c542b7ef45c16b31dd17e1cc6e1'/>
<id>urn:sha1:e8b6f79b41840c542b7ef45c16b31dd17e1cc6e1</id>
<content type='text'>
Add the ability to read the PHY maintained LPI counter which is in the
Clause 45 vendor space, device address 7, offset 0x803F. The counter is
cleared on read.

Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20230531231729.1873932-1-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: Register dummy IRQ handler</title>
<updated>2023-05-26T11:17:06Z</updated>
<author>
<name>Florian Fainelli</name>
<email>florian.fainelli@broadcom.com</email>
</author>
<published>2023-05-25T17:59:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4781e965e655b0f1736856908f861939dac79b4e'/>
<id>urn:sha1:4781e965e655b0f1736856908f861939dac79b4e</id>
<content type='text'>
In order to have our interrupt descriptor fully setup and in particular
the action, ensure that we register a full fledged interrupt handler.
This also allow us to set the interrupt polarity and flow through the
same call.

This is specifically necessary for kernel/irq/pm.c::suspend_device_irq
to set the interrupt descriptor to the IRQD_WAKEUP_ARMED state and
enable the interrupt for wake-up since it was still in a disabled state.

Without an interrupt descriptor we would have ran into cases where the
wake-up interrupt is not capable of waking up the system, specifically
if we resumed the system ACPI S5 using the Ethernet PHY. In that case
the Ethernet PHY interrupt would be pending by the time the kernel
booted, which it would acknowledge but then we could never use it as
a wake-up source again.

Fixes: 8baddaa9d4ba ("net: phy: broadcom: Add support for Wake-on-LAN")
Suggested-by: Doug Berger &lt;doug.berger@broadcom.com&gt;
Debugged-by: Doug Berger &lt;doug.berger@broadcom.com&gt;
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: Add support for Wake-on-LAN</title>
<updated>2023-05-13T15:56:29Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2023-05-11T17:21:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8baddaa9d4bac939004b5058f3ade7e2bf0a6e43'/>
<id>urn:sha1:8baddaa9d4bac939004b5058f3ade7e2bf0a6e43</id>
<content type='text'>
Add support for WAKE_UCAST, WAKE_MCAST, WAKE_BCAST, WAKE_MAGIC and
WAKE_MAGICSECURE. This is only supported with the BCM54210E and
compatible Ethernet PHYs. Using the in-band interrupt or an out of band
GPIO interrupts are supported.

Broadcom PHYs will generate a Wake-on-LAN level low interrupt on LED4 as
soon as one of the supported patterns is being matched. That includes
generating such an interrupt even if the PHY is operated during normal
modes. If WAKE_UCAST is selected, this could lead to the LED4 interrupt
firing up for every packet being received which is absolutely
undesirable from a performance point of view.

Because the Wake-on-LAN configuration can be set long before the system
is actually put to sleep, we cannot have an interrupt service routine to
clear on read the interrupt status register and ensure that new packet
matches will be detected.

It is desirable to enable the Wake-on-LAN interrupt as late as possible
during the system suspend process such that we limit the number of
interrupts to be handled by the system, but also conversely feed into
the Linux's system suspend way of dealing with interrupts in and around
the points of no return.

Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: move from strlcpy with unused retval to strscpy</title>
<updated>2022-08-31T21:11:07Z</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2022-08-30T20:14:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fb3ceec187e8bca474340e361a18163a2e79c0a2'/>
<id>urn:sha1:fb3ceec187e8bca474340e361a18163a2e79c0a2</id>
<content type='text'>
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Acked-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt; # for CAN
Link: https://lore.kernel.org/r/20220830201457.7984-1-wsa+renesas@sang-engineering.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: Only advertise EEE for supported modes</title>
<updated>2021-03-31T00:39:23Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2021-03-30T22:00:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c056d480b40a68f2520ccc156c7fae672d69d57d'/>
<id>urn:sha1:c056d480b40a68f2520ccc156c7fae672d69d57d</id>
<content type='text'>
We should not be advertising EEE for modes that we do not support,
correct that oversight by looking at the PHY device supported linkmodes.

Fixes: 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: remove use of ack_interrupt()</title>
<updated>2020-11-06T00:32:39Z</updated>
<author>
<name>Ioana Ciornei</name>
<email>ioana.ciornei@nxp.com</email>
</author>
<published>2020-11-01T12:51:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=15772e4ddf3fa07db7be3c0920dd21a580a05ffa'/>
<id>urn:sha1:15772e4ddf3fa07db7be3c0920dd21a580a05ffa</id>
<content type='text'>
In preparation of removing the .ack_interrupt() callback, we must replace
its occurrences (aka phy_clear_interrupt), from the 2 places where it is
called from (phy_enable_interrupts and phy_disable_interrupts), with
equivalent functionality.

This means that clearing interrupts now becomes something that the PHY
driver is responsible of doing, before enabling interrupts and after
clearing them. Make this driver follow the new contract.

Cc: Michael Walle &lt;michael@walle.cc&gt;
Cc: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: implement generic .handle_interrupt() callback</title>
<updated>2020-11-06T00:32:27Z</updated>
<author>
<name>Ioana Ciornei</name>
<email>ioana.ciornei@nxp.com</email>
</author>
<published>2020-11-01T12:51:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4567d5c3eb9b16dfbe8cc5103c0193affbad6491'/>
<id>urn:sha1:4567d5c3eb9b16dfbe8cc5103c0193affbad6491</id>
<content type='text'>
In an attempt to actually support shared IRQs in phylib, we now move the
responsibility of triggering the phylib state machine or just returning
IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
3 different IRQ handling callbacks (.handle_interrupt(),
.did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
driver implement directly an IRQ handler like any other device driver.
Make this driver follow the new convention.

Cc: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Tested-by: Michael Walle &lt;michael@walle.cc&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: don't export RDB/legacy access methods</title>
<updated>2020-06-01T19:02:57Z</updated>
<author>
<name>Michael Walle</name>
<email>michael@walle.cc</email>
</author>
<published>2020-05-30T20:34:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3190ca3b5f51a0e471ee3f04c898401c81b00385'/>
<id>urn:sha1:3190ca3b5f51a0e471ee3f04c898401c81b00385</id>
<content type='text'>
Don't export __bcm_phy_enable_rdb_access() and
__bcm_phy_enable_legacy_access() functions. They aren't used outside this
module and it was forgotten to provide a prototype for these functions.
Just make them static for now.

Fixes: 11ecf8c55b91 ("net: phy: broadcom: add cable test support")
Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Signed-off-by: Michael Walle &lt;michael@walle.cc&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: add cable test support</title>
<updated>2020-05-13T19:52:38Z</updated>
<author>
<name>Michael Walle</name>
<email>michael@walle.cc</email>
</author>
<published>2020-05-13T16:35:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=11ecf8c55b91806e4dc6a1b9fe7cbf68cdc9b006'/>
<id>urn:sha1:11ecf8c55b91806e4dc6a1b9fe7cbf68cdc9b006</id>
<content type='text'>
Most modern broadcom PHYs support ECD (enhanced cable diagnostics). Add
support for it in the bcm-phy-lib so they can easily be used in the PHY
driver.

There are two access methods for ECD: legacy by expansion registers and
via the new RDB registers which are exclusive. Provide functions in two
variants where the PHY driver can choose from. To keep things simple for
now, we just switch the register access to expansion registers in the
RDB variant for now. On the flipside, we have to keep a bus lock to
prevent any other non-legacy access on the PHY.

The results of the intra-pair tests are inconclusive (at least for the
BCM54140). Most of the times half the length is reported but sometimes
the length is correct.

Signed-off-by: Michael Walle &lt;michael@walle.cc&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
