From: <Parthiban.Veerasooran@microchip.com>
To: <andrew@lunn.ch>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
<corbet@lwn.net>, <Steen.Hegelund@microchip.com>,
<rdunlap@infradead.org>, <horms@kernel.org>,
<casper.casan@gmail.com>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <Horatiu.Vultur@microchip.com>,
<Woojung.Huh@microchip.com>, <Nicolas.Ferre@microchip.com>,
<UNGLinuxDriver@microchip.com>,
<Thorsten.Kummermehr@microchip.com>
Subject: Re: [PATCH net-next v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY
Date: Tue, 31 Oct 2023 11:04:12 +0000 [thread overview]
Message-ID: <296aa172-404e-414a-a56a-ca82b3e90397@microchip.com> (raw)
In-Reply-To: <eee6df3d-5e6b-4b4c-bfcc-55b31814fb82@lunn.ch>
Hi Andrew,
On 24/10/23 8:03 am, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> +static int lan865x_set_hw_macaddr(struct net_device *netdev)
>> +{
>> + u32 regval;
>> + bool ret;
>> + struct lan865x_priv *priv = netdev_priv(netdev);
>> + const u8 *mac = netdev->dev_addr;
>> +
>> + ret = oa_tc6_read_register(priv->tc6, LAN865X_MAC_NCR, ®val);
>> + if (ret)
>> + goto error_mac;
>> + if ((regval & LAN865X_TXEN) | (regval & LAN865X_RXEN)) {
>
> Would testing netif_running(netdev) be enough? That is a more common
> test you see. In fact, you already have that in
> lan865x_set_mac_address(). And in lan865x_probe() why would the
> hardware be enabled?
Ah yes, this check is not needed at all. Will correct it.
>
>
>> + if (netif_msg_drv(priv))
>> + netdev_warn(netdev, "Hardware must be disabled for MAC setting\n");
>> + return -EBUSY;
>> + }
>> + /* MAC address setting */
>> + regval = (mac[3] << 24) | (mac[2] << 16) | (mac[1] << 8) | mac[0];
>> + ret = oa_tc6_write_register(priv->tc6, LAN865X_MAC_SAB1, regval);
>> + if (ret)
>> + goto error_mac;
>> +
>> + regval = (mac[5] << 8) | mac[4];
>> + ret = oa_tc6_write_register(priv->tc6, LAN865X_MAC_SAT1, regval);
>> + if (ret)
>> + goto error_mac;
>> +
>> + return 0;
>> +
>> +error_mac:
>> + return -ENODEV;
>
> oa_tc6_write_register() should return an error code, so return it.
Yes, noted. Will do it.
>
>> +static int lan865x_set_mac_address(struct net_device *netdev, void *addr)
>> +{
>> + struct sockaddr *address = addr;
>> +
>> + if (netif_running(netdev))
>> + return -EBUSY;
>> +
>> + eth_hw_addr_set(netdev, address->sa_data);
>> +
>> + return lan865x_set_hw_macaddr(netdev);
>
> You should ideally only update the netdev MAC address, if you managed
> to change the value in the hardware.
Ah ok, then it is supposed to be like below, isn't it?
static int lan865x_set_mac_address(struct net_device *netdev, void *addr)
{
struct sockaddr *address = addr;
int ret;
if (netif_running(netdev))
return -EBUSY;
ret = lan865x_set_hw_macaddr(netdev);
if (ret)
return ret;
eth_hw_addr_set(netdev, address->sa_data);
return 0;
}
>
>> +static void lan865x_set_multicast_list(struct net_device *netdev)
>> +{
>> + struct lan865x_priv *priv = netdev_priv(netdev);
>> + u32 regval = 0;
>> +
>> + if (netdev->flags & IFF_PROMISC) {
>> + /* Enabling promiscuous mode */
>> + regval |= MAC_PROMISCUOUS_MODE;
>> + regval &= (~MAC_MULTICAST_MODE);
>> + regval &= (~MAC_UNICAST_MODE);
>> + } else if (netdev->flags & IFF_ALLMULTI) {
>> + /* Enabling all multicast mode */
>> + regval &= (~MAC_PROMISCUOUS_MODE);
>> + regval |= MAC_MULTICAST_MODE;
>> + regval &= (~MAC_UNICAST_MODE);
>> + } else if (!netdev_mc_empty(netdev)) {
>> + /* Enabling specific multicast addresses */
>> + struct netdev_hw_addr *ha;
>> + u32 hash_lo = 0;
>> + u32 hash_hi = 0;
>> +
>> + netdev_for_each_mc_addr(ha, netdev) {
>> + u32 bit_num = lan865x_hash(ha->addr);
>> + u32 mask = 1 << (bit_num & 0x1f);
>> +
>> + if (bit_num & 0x20)
>> + hash_hi |= mask;
>> + else
>> + hash_lo |= mask;
>> + }
>> + if (oa_tc6_write_register(priv->tc6, LAN865X_MAC_HRT, hash_hi)) {
>> + if (netif_msg_timer(priv))
>> + netdev_err(netdev, "Failed to write reg_hashh");
>> + return;
>> + }
>> + if (oa_tc6_write_register(priv->tc6, LAN865X_MAC_HRB, hash_lo)) {
>> + if (netif_msg_timer(priv))
>> + netdev_err(netdev, "Failed to write reg_hashl");
>> + return;
>> + }
>> + regval &= (~MAC_PROMISCUOUS_MODE);
>> + regval &= (~MAC_MULTICAST_MODE);
>> + regval |= MAC_UNICAST_MODE;
>> + } else {
>> + /* enabling local mac address only */
>> + if (oa_tc6_write_register(priv->tc6, LAN865X_MAC_HRT, regval)) {
>> + if (netif_msg_timer(priv))
>> + netdev_err(netdev, "Failed to write reg_hashh");
>> + return;
>> + }
>> + if (oa_tc6_write_register(priv->tc6, LAN865X_MAC_HRB, regval)) {
>> + if (netif_msg_timer(priv))
>> + netdev_err(netdev, "Failed to write reg_hashl");
>> + return;
>> + }
>> + }
>> + if (oa_tc6_write_register(priv->tc6, LAN865X_MAC_NCFGR, regval)) {
>> + if (netif_msg_timer(priv))
>> + netdev_err(netdev, "Failed to enable promiscuous mode");
>> + }
>> +}
>
> Another of those big functions which could be lots of simple functions
> each doing one thing.
Sure, will split into multiple functions.
>
>> +/* Configures the number of bytes allocated to each buffer in the
>> + * transmit/receive queue. LAN865x supports only 64 and 32 bytes cps and also 64
>> + * is the default value. So it is enough to configure the queue buffer size only
>> + * for 32 bytes. Generally cps can't be changed during run time and also it is
>> + * configured in the device tree. The values for the Tx/Rx queue buffer size are
>> + * taken from the LAN865x datasheet.
>> + */
>
> Its unclear why this needs to be a callback. Why not just set it after
> oa_tc6_init() returns?
oa_tc6_init() function internally calls oa_tc6_configure() function to
configure different settings. At the end it writes SYNC bit to CONFIG0
register which enables the MAC-PHY to start the data transfer. So the
buffer configuration should be done prior to that. Since this is part of
the configuration this callback is implemented.
>
>> +static void lan865x_remove(struct spi_device *spi)
>> +{
>> + struct lan865x_priv *priv = spi_get_drvdata(spi);
>> +
>> + oa_tc6_exit(priv->tc6);
>> + unregister_netdev(priv->netdev);
>
> Is that the correct order? Seems like you should unregister the netdev
> first.
Ah yes, will correct it.
>
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id lan865x_acpi_ids[] = {
>> + { .id = "LAN865X",
>> + },
>> + {},
>
> Does this work? You don't have access to the device tree properties.
Going to remove all the OA specific configurations in the next revisions.
Best Regards,
Parthiban V
>
> Andrew
>
next prev parent reply other threads:[~2023-10-31 11:04 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 15:46 [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface Parthiban Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 1/9] net: ethernet: implement OPEN Alliance control transaction interface Parthiban Veerasooran
2023-10-23 21:28 ` Andrew Lunn
2023-10-25 11:16 ` Parthiban.Veerasooran
2023-10-26 19:46 ` Andrew Lunn
2023-10-27 7:15 ` Parthiban.Veerasooran
2023-10-23 23:09 ` kernel test robot
2023-10-25 19:09 ` kernel test robot
2023-10-23 15:46 ` [PATCH net-next v2 2/9] net: ethernet: oa_tc6: implement mac-phy software reset Parthiban Veerasooran
2023-10-23 22:43 ` Andrew Lunn
2023-10-25 11:39 ` Parthiban.Veerasooran
2023-10-26 20:01 ` Andrew Lunn
2023-10-27 7:00 ` Parthiban.Veerasooran
2023-10-25 11:39 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 3/9] net: ethernet: oa_tc6: implement OA TC6 configuration function Parthiban Veerasooran
2023-10-23 22:58 ` Andrew Lunn
2023-10-25 12:02 ` Parthiban.Veerasooran
2023-10-26 20:06 ` Andrew Lunn
2023-10-27 7:10 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 4/9] dt-bindings: net: add OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface Parthiban Veerasooran
2023-10-23 17:40 ` Rob Herring
2023-10-25 12:28 ` Parthiban.Veerasooran
2023-10-24 0:37 ` Andrew Lunn
2023-10-27 9:12 ` Parthiban.Veerasooran
2023-10-27 12:32 ` Andrew Lunn
2023-10-30 10:09 ` Parthiban.Veerasooran
2023-10-24 7:44 ` Krzysztof Kozlowski
2023-10-31 12:59 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 5/9] net: ethernet: oa_tc6: implement internal PHY initialization Parthiban Veerasooran
2023-10-24 0:56 ` Andrew Lunn
2023-10-31 4:20 ` Parthiban.Veerasooran
2023-10-31 12:48 ` Andrew Lunn
2023-11-01 4:53 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 6/9] dt-bindings: net: oa-tc6: add PHY register access capability Parthiban Veerasooran
2023-10-24 1:21 ` Andrew Lunn
2023-10-31 4:22 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 7/9] net: ethernet: oa_tc6: implement data transaction interface Parthiban Veerasooran
2023-10-24 2:07 ` Andrew Lunn
2023-10-31 8:26 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY Parthiban Veerasooran
2023-10-24 2:33 ` Andrew Lunn
2023-10-31 11:04 ` Parthiban.Veerasooran [this message]
2023-10-31 12:53 ` Andrew Lunn
2023-11-01 4:51 ` Parthiban.Veerasooran
2023-10-24 11:57 ` Krzysztof Kozlowski
2023-10-31 10:25 ` Parthiban.Veerasooran
2023-11-02 12:20 ` Ramón Nordin Rodriguez
2023-11-02 12:39 ` Andrew Lunn
2023-11-02 13:40 ` Ramón Nordin Rodriguez
2023-11-03 14:59 ` Parthiban.Veerasooran
2023-11-06 8:59 ` Ramón Nordin Rodriguez
2023-10-23 15:46 ` [PATCH net-next v2 9/9] dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY Parthiban Veerasooran
2023-10-23 17:40 ` Rob Herring
2023-10-30 12:41 ` Parthiban.Veerasooran
2023-10-24 8:03 ` Krzysztof Kozlowski
2023-10-30 13:16 ` Parthiban.Veerasooran
2023-10-30 14:45 ` Krzysztof Kozlowski
2023-11-02 13:31 ` Parthiban.Veerasooran
2024-03-24 11:55 ` [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface Benjamin Bigler
2024-03-25 13:24 ` Parthiban.Veerasooran
2024-03-25 14:01 ` Andrew Lunn
2024-03-26 9:43 ` Parthiban.Veerasooran
2024-04-03 21:40 ` Benjamin Bigler
2024-04-08 13:41 ` Parthiban.Veerasooran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=296aa172-404e-414a-a56a-ca82b3e90397@microchip.com \
--to=parthiban.veerasooran@microchip.com \
--cc=Horatiu.Vultur@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Steen.Hegelund@microchip.com \
--cc=Thorsten.Kummermehr@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=andrew@lunn.ch \
--cc=casper.casan@gmail.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).