Re: [PATCH v2] brcmfmac: expose firmware config files through modinfo
On 20/11/2020 11:05, Dmitry Osipenko wrote: 20.11.2020 12:52, matthias@kernel.org пишет: From: Matthias Brugger Apart from a firmware binary the chip needs a config file used by the FW. Add the config files to modinfo so that they can be read by userspace. Signed-off-by: Matthias Brugger --- Changes in v2: In comparison to first version [0] we use wildcards to enumerate the firmware configuration files. Wildcard support was added to dracut recently [1]. [0] https://lore.kernel.org/linux-wireless/20200701153123.25602-1-matthias@kernel.org/ [1] https://github.com/dracutdevs/dracut/pull/860 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index 99987a789e7e..dd6d287b1b00 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -625,6 +625,15 @@ BRCMF_FW_DEF(4359, "brcmfmac4359-sdio"); BRCMF_FW_DEF(4373, "brcmfmac4373-sdio"); BRCMF_FW_DEF(43012, "brcmfmac43012-sdio"); +/* firmware config files */ +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac4330-sdio.*.txt"); +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43340-sdio.*.txt"); +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43362-sdio.*.txt"); +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43430a0-sdio.*.txt"); +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43430-sdio.*.txt"); +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43455-sdio.*.txt"); +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac4356-pcie.*.txt"); This doesn't cover all hardware models. Note that the upstream linux-firmware has files only for a few hardware models. I suppose that the correct mask should be "brcm/brcmfmac*-sdio.*.txt". We can use the two "brcm/brcmfmac*-sdio.*.txt" and "brcm/brcmfmac*-pcie.*.txt" to also include firmware files for chips that don't have any config file in linux-firmware. I'm indifferent to that, although I think we should make incentivize to upstream firmware config files to linux-firmware. Regards, Matthias
Re: [PATCH net-next v5 0/6] net-next: dsa: mt7530: add support for MT7531
On 15/09/2020 01:32, David Miller wrote: From: Landen Chao Date: Fri, 11 Sep 2020 21:48:50 +0800 This patch series adds support for MT7531. MT7531 is the next generation of MT7530 which could be found on Mediatek router platforms such as MT7622 or MT7629. It is also a 7-ports switch with 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu port 6 only supports SGMII interface. Cpu port 5 supports either RGMII or SGMII in different HW SKU, but cannot be muxed to PHY of port 0/4 like mt7530. Due to support for SGMII interface, pll, and pad setting are different from MT7530. MT7531 SGMII interface can be configured in following mode: - 'SGMII AN mode' with in-band negotiation capability which is compatible with PHY_INTERFACE_MODE_SGMII. - 'SGMII force mode' without in-band negotiation which is compatible with 10B/8B encoding of PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. - 2.5 times faster clocked 'SGMII force mode' without in-band negotiation which is compatible with 10B/8B encoding of PHY_INTERFACE_MODE_2500BASEX with fixed full-duplex and fixed pause. ... Series applied, thank you. Regarding the DTS patches: Please coordinate with me the next time. I want to prevent merge conflicts if both mine and your tree add patches to the files. Thanks, Matthias
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On 09/09/2020 22:06, Joe Perches wrote:
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c
b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 09f931d4598c..778be26d329f 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -193,11 +193,11 @@ static void mt7601u_complete_rx(struct urb *urb)
case -ESHUTDOWN:
case -ENOENT:
return;
+ case 0:
+ break;
default:
dev_err_ratelimited(dev->dev, "rx urb failed: %d\n",
urb->status);
- fallthrough;
- case 0:
break;
}
@@ -238,11 +238,11 @@ static void mt7601u_complete_tx(struct urb *urb)
case -ESHUTDOWN:
case -ENOENT:
return;
+ case 0:
+ break;
default:
dev_err_ratelimited(dev->dev, "tx urb failed: %d\n",
urb->status);
- fallthrough;
- case 0:
break;
}
Reviewed-by: Matthias Brugger
Re: [PATCH] brcmfmac: expose firmware config files through modinfo
On 02/07/2020 20:00, Hans de Goede wrote:
> Hi,
>
> On 7/1/20 5:46 PM, Matthias Brugger wrote:
>> Hi Hans,
>>
>> On 01/07/2020 17:38, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 7/1/20 5:31 PM, matthias@kernel.org wrote:
>>>> From: Matthias Brugger
>>>>
>>>> Apart from a firmware binary the chip needs a config file used by the
>>>> FW. Add the config files to modinfo so that they can be read by
>>>> userspace.
>>>
>>> The configfile firmware filename is dynamically generated, just adding the
>>> list
>>> of all currently shipped ones is not really helpful and this is going to get
>>> out of sync with what we actually have in linux-firmware.
>>
>> I'm aware of this, and I agree.
>>
>>>
>>> I must honestly say that I'm not a fan of this, I guess you are trying to
>>> get some tool which builds a minimal image, such as an initrd generator
>>> to add these files to the image ?
>>>
>>
>> Yes exactly.
>>
>>> I do not immediately have a better idea, but IMHO the solution
>>> this patch proposes is not a good one, so nack from me for this change.
>>>
>>
>> Another path we could go is add a wildcard string instead, for example:
>> MODULE_FIRMWARE("brcm/brcmfmac43455-sdio.*.txt");
>
> I was thinking about the same lines, but I'm afraid some user-space
> utils may blow up if we introduce this, which is why I did not suggest
> it in my previous email.
>
>> AFAIK there is no driver in the kernel that does this. I checked with our
>> dracut
>> developer and right now dracut can't cope with that.
>
> Can't cope as in tries to add "/lib/firmware/brcm/brcmfmac43455-sdio.*.txt"
> and then skips it (as it does for other missing firmware files); or can't
> cope as in blows-up and aborts without leaving a valid initrd behind.
>
> If is the former, that is fine, if it is the latter that is a problem.
>
>> But he will try to
>> implement that in the future.
>>
>> So my idea was to maintain that list for now and switch to the wildcard
>> approach
>> once we have dracut support that.
>
> So lets assume that the wildcard approach is ok and any initrd tools looking
> at
> the MODULE_FIRMWARE metadata either accidentally do what we want; or fail
> gracefully. Then if we temporarily add the long MODULE_FIRMWARE list now,
> those
> which fail gracefully will start doing the right thing (except they add too
> much firmware), and later on we cannot remove all the non wildcard
> MODULE_FIRMWARE list entries because that will cause a regression.
>
> Because of this I'm not a fan of temporarily fixing this like this. Using wifi
> inside the initrd is very much a cornercase anyways, so I think users can
> use a workaround by dropping an /etc/dracut.conf.d file adding the necessary
> config file for now.
>
> As for the long run, I was thinking that even with regular firmware files
> we are adding too much firmware to host-specific initrds since we add all
> the firmwares listed with MODULE_FIRMWARE, and typically only a few are
> actually necessary.
>
> We could modify the firmware_loader code under drivers/base/firmware_loader
> to keep a list of all files loaded since boot; and export that somewhere
> under /sys, then dracut could use that list in host-only mode and we get
> a smaller initrd. One challenge with this approach though is firmware files
> which are necessary for a new kernel, but not used by the running kernel ...
> I'm afraid I do not have a good answer to that.
>
That would work for creating a new minimal initrd from a working image. But it
would not help in bootstrapping an image. My understanding is that for
bootstrapping an image we will need to support wildcards in MODULE_FIRMWARE()
strings.
Regards,
Matthias
> Regards,
>
> Hans
>
>
>
>
>
>
>
>>>> Signed-off-by: Matthias Brugger
>>>>
>>>> ---
>>>>
>>>> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 16
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> index 310d8075f5d7..ba18df6d8d94 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> @@ -624,6 +624,22 @@ BRCMF_FW_DEF(4359, "brcmfmac4359-sdio&q
Re: [PATCH] brcmfmac: expose firmware config files through modinfo
Hi Hans,
On 01/07/2020 17:38, Hans de Goede wrote:
> Hi,
>
> On 7/1/20 5:31 PM, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Apart from a firmware binary the chip needs a config file used by the
>> FW. Add the config files to modinfo so that they can be read by
>> userspace.
>
> The configfile firmware filename is dynamically generated, just adding the
> list
> of all currently shipped ones is not really helpful and this is going to get
> out of sync with what we actually have in linux-firmware.
I'm aware of this, and I agree.
>
> I must honestly say that I'm not a fan of this, I guess you are trying to
> get some tool which builds a minimal image, such as an initrd generator
> to add these files to the image ?
>
Yes exactly.
> I do not immediately have a better idea, but IMHO the solution
> this patch proposes is not a good one, so nack from me for this change.
>
Another path we could go is add a wildcard string instead, for example:
MODULE_FIRMWARE("brcm/brcmfmac43455-sdio.*.txt");
AFAIK there is no driver in the kernel that does this. I checked with our dracut
developer and right now dracut can't cope with that. But he will try to
implement that in the future.
So my idea was to maintain that list for now and switch to the wildcard approach
once we have dracut support that.
Regards,
Matthias
> Regards,
>
> Hans
>
>
>
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> index 310d8075f5d7..ba18df6d8d94 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> @@ -624,6 +624,22 @@ BRCMF_FW_DEF(4359, "brcmfmac4359-sdio");
>> BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
>> BRCMF_FW_DEF(43012, "brcmfmac43012-sdio");
>> +/* firmware config files */
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac4330-sdio.Prowise-PT301.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43340-sdio.meegopad-t08.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43340-sdio.pov-tab-p1006w-data.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43430a0-sdio.jumper-ezpad-mini3.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43430a0-sdio.ONDA-V80
>> PLUS.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43430-sdio.AP6212.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43430-sdio.MUR1DX.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcm/brcmfmac43455-sdio.MINIX-NEO
>> Z83-4.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt");
>> +MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH
>> "brcm/brcmfmac4356-pcie.gpd-win-pocket.txt");
>> +
>> static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
>> BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0x, 43143),
>> BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x001F, 43241B0),
>>
>
Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
On 5/22/20 11:36 PM, David Miller wrote: > From: Matthias Brugger > Date: Fri, 22 May 2020 23:31:50 +0200 > >> >> >> On 22/05/2020 23:20, David Miller wrote: >>> From: Bartosz Golaszewski >>> Date: Fri, 22 May 2020 14:06:49 +0200 >>> >>>> This series adds support for the STAR Ethernet Controller present on >>>> MediaTeK >>>> SoCs from the MT8* family. >>> >>> Series applied to net-next, thank you. >>> >> >> If you say "series applied" do you mean you also applied the device tree >> parts? >> These should go through my branch, because there could be conflicts if there >> are >> other device tree patches from other series, not related with network, >> touching >> the same files. > > It's starting to get rediculous and tedious to manage the DT changes > when they are tied to new networking drivers and such. > > And in any event, it is the patch series submitter's responsibility to > sort these issues out, separate the patches based upon target tree, and > clearly indicate this in the introductory posting and Subject lines. > My experience in with other subsystems is that the DTS changes which enables de device are part of the series. They are normally prefixed with "arm64: dts:" or "ARM: dts:" for 32 bit SoCs. That also normally the way I detect patches which should through my tree. Anyway I'll try to remember submitters in the future to send DTS patches for network devices as separate series. That makes my life a bit more complicated as I afterwards have to find the related DTS series to the driver you accepted, but I'll try. Regards, Matthias
Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
On 22/05/2020 23:20, David Miller wrote: > From: Bartosz Golaszewski > Date: Fri, 22 May 2020 14:06:49 +0200 > >> This series adds support for the STAR Ethernet Controller present on MediaTeK >> SoCs from the MT8* family. > > Series applied to net-next, thank you. > If you say "series applied" do you mean you also applied the device tree parts? These should go through my branch, because there could be conflicts if there are other device tree patches from other series, not related with network, touching the same files. Regards, Matthias
Re: [PATCH v5 06/11] net: ethernet: mtk-star-emac: new driver
On 22/05/2020 14:06, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This adds the driver for the MediaTek STAR Ethernet MAC currently used
> on the MT8* SoC family. For now we only support full-duplex.
MT85** SoC family, AFAIU it's not used on MT81** devices. Correct?
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/net/ethernet/mediatek/Kconfig |7 +
> drivers/net/ethernet/mediatek/Makefile|1 +
> drivers/net/ethernet/mediatek/mtk_star_emac.c | 1678 +
> 3 files changed, 1686 insertions(+)
> create mode 100644 drivers/net/ethernet/mediatek/mtk_star_emac.c
>
> diff --git a/drivers/net/ethernet/mediatek/Kconfig
> b/drivers/net/ethernet/mediatek/Kconfig
> index 5079b8090f16..500c15e7ea4a 100644
> --- a/drivers/net/ethernet/mediatek/Kconfig
> +++ b/drivers/net/ethernet/mediatek/Kconfig
> @@ -14,4 +14,11 @@ config NET_MEDIATEK_SOC
> This driver supports the gigabit ethernet MACs in the
> MediaTek SoC family.
>
> +config NET_MEDIATEK_STAR_EMAC
> + tristate "MediaTek STAR Ethernet MAC support"
> + select PHYLIB
> + help
> + This driver supports the ethernet MAC IP first used on
> + MediaTek MT85** SoCs.
> +
> endif #NET_VENDOR_MEDIATEK
> diff --git a/drivers/net/ethernet/mediatek/Makefile
> b/drivers/net/ethernet/mediatek/Makefile
> index 3362fb7ef859..3a777b4a6cd3 100644
> --- a/drivers/net/ethernet/mediatek/Makefile
> +++ b/drivers/net/ethernet/mediatek/Makefile
> @@ -5,3 +5,4 @@
>
> obj-$(CONFIG_NET_MEDIATEK_SOC) += mtk_eth.o
> mtk_eth-y := mtk_eth_soc.o mtk_sgmii.o mtk_eth_path.o
> +obj-$(CONFIG_NET_MEDIATEK_STAR_EMAC) += mtk_star_emac.o
> diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c
> b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> new file mode 100644
> index ..789c77af501f
> --- /dev/null
> +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> @@ -0,0 +1,1678 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2020 MediaTek Corporation
> + * Copyright (c) 2020 BayLibre SAS
> + *
> + * Author: Bartosz Golaszewski
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_STAR_DRVNAME "mtk_star_emac"
> +
> +#define MTK_STAR_WAIT_TIMEOUT300
> +#define MTK_STAR_MAX_FRAME_SIZE 1514
> +#define MTK_STAR_SKB_ALIGNMENT 16
> +#define MTK_STAR_NAPI_WEIGHT 64
> +#define MTK_STAR_HASHTABLE_MC_LIMIT 256
> +#define MTK_STAR_HASHTABLE_SIZE_MAX 512
> +
> +/* Normally we'd use NET_IP_ALIGN but on arm64 its value is 0 and it doesn't
> + * work for this controller.
> + */
> +#define MTK_STAR_IP_ALIGN2
> +
> +static const char *const mtk_star_clk_names[] = { "core", "reg", "trans" };
> +#define MTK_STAR_NCLKS ARRAY_SIZE(mtk_star_clk_names)
> +
> +/* PHY Control Register 0 */
> +#define MTK_STAR_REG_PHY_CTRL0 0x
> +#define MTK_STAR_BIT_PHY_CTRL0_WTCMD BIT(13)
> +#define MTK_STAR_BIT_PHY_CTRL0_RDCMD BIT(14)
> +#define MTK_STAR_BIT_PHY_CTRL0_RWOK BIT(15)
> +#define MTK_STAR_MSK_PHY_CTRL0_PREG GENMASK(12, 8)
> +#define MTK_STAR_OFF_PHY_CTRL0_PREG 8
> +#define MTK_STAR_MSK_PHY_CTRL0_RWDATAGENMASK(31, 16)
> +#define MTK_STAR_OFF_PHY_CTRL0_RWDATA16
> +
> +/* PHY Control Register 1 */
> +#define MTK_STAR_REG_PHY_CTRL1 0x0004
> +#define MTK_STAR_BIT_PHY_CTRL1_LINK_ST BIT(0)
> +#define MTK_STAR_BIT_PHY_CTRL1_AN_EN BIT(8)
> +#define MTK_STAR_OFF_PHY_CTRL1_FORCE_SPD 9
> +#define MTK_STAR_VAL_PHY_CTRL1_FORCE_SPD_10M 0x00
> +#define MTK_STAR_VAL_PHY_CTRL1_FORCE_SPD_100M0x01
> +#define MTK_STAR_VAL_PHY_CTRL1_FORCE_SPD_1000M 0x02
> +#define MTK_STAR_BIT_PHY_CTRL1_FORCE_DPX BIT(11)
> +#define MTK_STAR_BIT_PHY_CTRL1_FORCE_FC_RX BIT(12)
> +#define MTK_STAR_BIT_PHY_CTRL1_FORCE_FC_TX BIT(13)
> +
> +/* MAC Configuration Register */
> +#define MTK_STAR_REG_MAC_CFG 0x0008
> +#define MTK_STAR_OFF_MAC_CFG_IPG 10
> +#define MTK_STAR_VAL_MAC_CFG_IPG_96BIT GENMASK(4, 0)
> +#define MTK_STAR_BIT_MAC_CFG_MAXLEN_1522 BIT(16)
> +#define MTK_STAR_BIT_MAC_CFG_AUTO_PADBIT(19)
> +#define MTK_STAR_BIT_MAC_CFG_CRC_STRIP BIT(20)
> +#define MTK_STAR_BIT_MAC_CFG_VLAN_STRIP BIT(22)
> +#define MTK_STAR_BIT_MAC_CFG_NIC_PD BIT(31)
> +
> +/* Flow-Control Configuration Register */
> +#define MTK_STAR_REG_FC_CFG 0x000c
> +#define MTK_STAR_BIT_FC_CFG_BP_ENBIT(7)
> +#define MTK_STAR_BIT_FC_CFG_UC_PAUSE_DIR BIT(8)
> +#define MTK_STAR_OFF_FC_CFG_SEND_PAUSE_TH1
Re: [PATCH net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
On 28/08/2019 21:56, David Miller wrote: > From: Matthias Brugger > Date: Wed, 28 Aug 2019 11:29:45 +0200 > >> Thanks for taking this patch. For the next time, please make sure that dts[i] >> patches are independent from the binding description, as dts[i] should go >> through my tree. No problem for this round, just saying for the future. > > That's not always possible nor reasonable, to be quite honest. > Right now no case comes to my mind. What would be a case where this is not reasonable or possible? Regards, Matthias
Re: [PATCH net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
Hi David,
On 25/08/2019 19:43, René van Dorst wrote:
> This patch the removes the recently added mediatek,physpeed property.
> Use the fixed-link property speed = <2500> to set the phy in 2.5Gbit.
> See mt7622-bananapi-bpi-r64.dts for a working example.
>
> Signed-off-by: René van Dorst
> --
> v3->v4:
> * no change
> v2->v3:
> * no change
> v1->v2:
> * SGMII port only support BASE-X at 2.5Gbit.
> ---
> .../arm/mediatek/mediatek,sgmiisys.txt| 2 --
> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +--
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
> 3 files changed, 19 insertions(+), 12 deletions(-)
Thanks for taking this patch. For the next time, please make sure that dts[i]
patches are independent from the binding description, as dts[i] should go
through my tree. No problem for this round, just saying for the future.
Regards,
Matthias
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> index f5518f26a914..30cb645c0e54 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> @@ -9,8 +9,6 @@ Required Properties:
> - "mediatek,mt7622-sgmiisys", "syscon"
> - "mediatek,mt7629-sgmiisys", "syscon"
> - #clock-cells: Must be 1
> -- mediatek,physpeed: Should be one of "auto", "1000" or "2500" to match up
> - the capability of the target PHY.
>
> The SGMIISYS controller uses the common clk binding from
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> index 710c5c3d87d3..83e10591e0e5 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> @@ -115,24 +115,34 @@
> };
>
> ð {
> - pinctrl-names = "default";
> - pinctrl-0 = <ð_pins>;
> status = "okay";
> + gmac0: mac@0 {
> + compatible = "mediatek,eth-mac";
> + reg = <0>;
> + phy-mode = "2500base-x";
> +
> + fixed-link {
> + speed = <2500>;
> + full-duplex;
> + pause;
> + };
> + };
>
> gmac1: mac@1 {
> compatible = "mediatek,eth-mac";
> reg = <1>;
> - phy-handle = <&phy5>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> };
>
> - mdio-bus {
> + mdio: mdio-bus {
> #address-cells = <1>;
> #size-cells = <0>;
> -
> - phy5: ethernet-phy@5 {
> - reg = <5>;
> - phy-mode = "sgmii";
> - };
> };
> };
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> index d1e13d340e26..dac51e98204c 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> @@ -931,6 +931,5 @@
>"syscon";
> reg = <0 0x1b128000 0 0x3000>;
> #clock-cells = <1>;
> - mediatek,physpeed = "2500";
> };
> };
>
Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3
On 30/11/2018 20:40, Kees Cook wrote: > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen > wrote: >> >> In order to comply with the CoC, replace with a hug. > > Heh. I support the replacement of the stronger language, but I find > "hug", "hugged", and "hugging" to be very weird replacements. Can we > bikeshed this to "heck", "hecked", and "hecking" (or "heckin" to > follow true Doggo meme style). > > "This API is hugged" doesn't make any sense to me. "This API is > hecked" is better, or at least funnier (to me). "Hug this interface" > similarly makes no sense, but "Heck this interface" seems better. > "Don't touch my hecking code", "What the heck were they thinking?" > etc... "hug" is odd. > Like John I don't think that the word "fuck" is something we have to ban from the source code, but I don't care too much. Anyway, please don't change it to something like heck as it might be difficult for non-english speaker to understand. Regards, Matthias > Better yet, since it's only 17 files, how about doing context-specific > changes? "This API is terrible", "Hateful interface", "Don't touch my > freakin' code", "What in the world were they thinking?" etc? > > -Kees > >> >> Jarkko Sakkinen (15): >> MIPS: replace with a hug >> Documentation: replace with a hug >> drm/nouveau: replace with a hug >> m68k: replace with a hug >> parisc: replace with a hug >> cpufreq: replace with a hug >> ide: replace with a hug >> media: replace with a hug >> mtd: replace with a hug >> net/sunhme: replace with a hug >> scsi: replace with a hug >> inotify: replace with a hug >> irq: replace with a hug >> lib: replace with a hug >> net: replace with a hug >> >> Documentation/kernel-hacking/locking.rst | 2 +- >> arch/m68k/include/asm/sun3ints.h | 2 +- >> arch/mips/pci/ops-bridge.c| 24 +-- >> arch/mips/sgi-ip22/ip22-setup.c | 2 +- >> arch/parisc/kernel/sys_parisc.c | 2 +- >> drivers/cpufreq/powernow-k7.c | 2 +- >> .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +- >> .../nouveau/nvkm/subdev/pmu/fuc/macros.fuc| 2 +- >> drivers/ide/cmd640.c | 2 +- >> drivers/media/i2c/bt819.c | 8 --- >> drivers/mtd/mtd_blkdevs.c | 2 +- >> drivers/net/ethernet/sun/sunhme.c | 4 ++-- >> drivers/scsi/qlogicpti.h | 2 +- >> fs/notify/inotify/inotify_user.c | 2 +- >> kernel/irq/timings.c | 2 +- >> lib/vsprintf.c| 2 +- >> net/core/skbuff.c | 2 +- >> 17 files changed, 33 insertions(+), 31 deletions(-) >> >> -- >> 2.19.1 >> > >
[PATCH] net: hns: Fix ethtool private flags
The driver implementation returns support for private flags, while
no private flags are present. When asked for the number of private
flags it returns the number of statistic flag names.
Fix this by returning EOPNOTSUPP for not implemented ethtool flags.
Signed-off-by: Matthias Brugger
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 4 +++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 86944bc3b273..74bd260ca02a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -666,7 +666,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data)
static int hns_gmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+ if (stringset == ETH_SS_STATS)
return ARRAY_SIZE(g_gmac_stats_string);
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index b62816c1574e..93e71e27401b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -422,7 +422,7 @@ void hns_ppe_update_stats(struct hns_ppe_cb *ppe_cb)
int hns_ppe_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+ if (stringset == ETH_SS_STATS)
return ETH_PPE_STATIC_NUM;
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 6f3570cfb501..e2e28532e4dc 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -876,7 +876,7 @@ void hns_rcb_get_stats(struct hnae_queue *queue, u64 *data)
*/
int hns_rcb_get_ring_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
+ if (stringset == ETH_SS_STATS)
return HNS_RING_STATIC_REG_NUM;
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 7ea7f8a4aa2a..2e14a3ae1d8b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -993,8 +993,10 @@ int hns_get_sset_count(struct net_device *netdev, int
stringset)
cnt--;
return cnt;
- } else {
+ } else if (stringset == ETH_SS_STATS) {
return (HNS_NET_STATS_CNT + ops->get_sset_count(h, stringset));
+ } else {
+ return -EOPNOTSUPP;
}
}
--
2.16.2
Re: [PATCH] net: ethernet: mediatek: add NULL check on of_match_device() return value
On 07/07/2017 09:11 AM, Gustavo A. R. Silva wrote:
Check return value from call to of_match_device()
in order to prevent a NULL pointer dereference.
In case of NULL print error message and return -ENODEV
Signed-off-by: Gustavo A. R. Silva
---
Reviewed-by: Matthias Brugger
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index adaaafc..6a77dea 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2408,6 +2408,11 @@ static int mtk_probe(struct platform_device *pdev)
int i;
match = of_match_device(of_mtk_match, &pdev->dev);
+ if (!match) {
+ dev_err(&pdev->dev, "failed to match device\n");
+ return -ENODEV;
+ }
+
soc = (struct mtk_soc_data *)match->data;
eth = devm_kzalloc(&pdev->dev, sizeof(*eth), GFP_KERNEL);
Re: [PATCH net-next v5 1/2] net: hns: support deferred probe when can not obtain irq
On 28/04/17 08:49, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, the interrupt lines from the
DSAF controllers are connected to mbigen hw module.
The mbigen module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
Signed-off-by: lipeng
Reviewed-by: Yisen Zhuang
Reviewed-by: Matthias Brugger
Looks good now, so you can keep my Reviewed-by.
---
change log:
V4 -> V5:
1. Float on net-next;
V3 -> V4:
1. Delete redundant commit message;
2. add Reviewed-by: Matthias Brugger ;
V2 -> V3:
1. Check return value when platform_get_irq in hns_rcb_get_cfg;
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 4 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 8 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index eba406b..93e71e2 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -510,7 +510,9 @@ int hns_ppe_init(struct dsaf_device *dsaf_dev)
hns_ppe_get_cfg(dsaf_dev->ppe_common[i]);
- hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ ret = hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ if (ret)
+ goto get_cfg_fail;
}
for (i = 0; i < HNS_PPE_COM_NUM; i++)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index c20a0f4..e2e2853 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -492,7 +492,7 @@ static int hns_rcb_get_base_irq_idx(struct rcb_common_cb
*rcb_common)
*hns_rcb_get_cfg - get rcb config
*@rcb_common: rcb common device
*/
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
{
struct ring_pair_cb *ring_pair_cb;
u32 i;
@@ -517,10 +517,16 @@ void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] =
is_ver1 ? platform_get_irq(pdev, base_irq_idx + i * 2 + 1) :
platform_get_irq(pdev, base_irq_idx + i * 3);
+ if ((ring_pair_cb->virq[HNS_RCB_IRQ_IDX_TX] == -EPROBE_DEFER) ||
+ (ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] == -EPROBE_DEFER))
+ return -EPROBE_DEFER;
+
ring_pair_cb->q.phy_base =
RCB_COMM_BASE_TO_RING_BASE(rcb_common->phy_base, i);
hns_rcb_ring_pair_get_cfg(ring_pair_cb);
}
+
+ return 0;
}
/**
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
index a664ee8..6028164 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
@@ -121,7 +121,7 @@ struct rcb_common_cb {
void hns_rcb_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index);
int hns_rcb_common_init_hw(struct rcb_common_cb *rcb_common);
void hns_rcb_start(struct hnae_queue *q, u32 val);
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
void hns_rcb_get_queue_mode(enum dsaf_mode dsaf_mode,
u16 *max_vfn, u16 *max_q_per_vf);
Re: [PATCH net v4 1/3] net: hns: support deferred probe when can not obtain irq
On 27/04/17 04:44, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, the interrupt lines from the
DSAF controllers are connected to mbigen hw module.
The mbigen module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
Signed-off-by: lipeng
Reviewed-by: Yisen Zhuang
Reviewed-by: Matthias Brugger
---
change log:
V3 -> V4:
1. Delete redundant commit message;
2. add Reviewed-by: Matthias Brugger ;
V2 -> V3:
1. Check return value when platform_get_irq in hns_rcb_get_cfg;
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 4 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 8 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 6ea8722..a41cf95 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -510,7 +510,9 @@ int hns_ppe_init(struct dsaf_device *dsaf_dev)
hns_ppe_get_cfg(dsaf_dev->ppe_common[i]);
- hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ ret = hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ if (ret)
+ goto get_rcb_cfg_fail;
a2185587ade7 ("net: hns: Simplify the exception sequence in hns_ppe_init()")
deleted get_rcb_cfg_fail label. This does not compile. Please rebase
against net-next.
Best regards,
Matthias
}
for (i = 0; i < HNS_PPE_COM_NUM; i++)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index f0ed80d6..673a5d3 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -452,7 +452,7 @@ static int hns_rcb_get_base_irq_idx(struct rcb_common_cb
*rcb_common)
*hns_rcb_get_cfg - get rcb config
*@rcb_common: rcb common device
*/
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
{
struct ring_pair_cb *ring_pair_cb;
u32 i;
@@ -477,10 +477,16 @@ void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] =
is_ver1 ? platform_get_irq(pdev, base_irq_idx + i * 2 + 1) :
platform_get_irq(pdev, base_irq_idx + i * 3);
+ if ((ring_pair_cb->virq[HNS_RCB_IRQ_IDX_TX] == -EPROBE_DEFER) ||
+ (ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] == -EPROBE_DEFER))
+ return -EPROBE_DEFER;
+
ring_pair_cb->q.phy_base =
RCB_COMM_BASE_TO_RING_BASE(rcb_common->phy_base, i);
hns_rcb_ring_pair_get_cfg(ring_pair_cb);
}
+
+ return 0;
}
/**
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
index 99b4e1b..3d7b484 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
@@ -110,7 +110,7 @@ struct rcb_common_cb {
void hns_rcb_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index);
int hns_rcb_common_init_hw(struct rcb_common_cb *rcb_common);
void hns_rcb_start(struct hnae_queue *q, u32 val);
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
void hns_rcb_get_queue_mode(enum dsaf_mode dsaf_mode,
u16 *max_vfn, u16 *max_q_per_vf);
Re: [PATCH net v3 2/3] net: hns: support deferred probe when no mdio
On 26/04/17 09:00, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, phy connect to mdio bus.The mdio
module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
We check for probe deferral in the mac init, so we not init DSAF
when there is no mdio, and free all resource, to later learn that
we need to defer the probe.
Signed-off-by: lipeng
Reviewed-by: Yisen Zhuang
Reviewed-by: Matthias Brugger
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 39 +++
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index bdd8cdd..8c00e09 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -735,6 +735,8 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
rc = phy_device_register(phy);
if (rc) {
phy_device_free(phy);
+ dev_err(&mdio->dev, "registered phy fail at address %i\n",
+ addr);
return -ENODEV;
}
@@ -745,7 +747,7 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
return 0;
}
-static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
+static int hns_mac_register_phy(struct hns_mac_cb *mac_cb)
{
struct acpi_reference_args args;
struct platform_device *pdev;
@@ -755,24 +757,39 @@ static void hns_mac_register_phy(struct hns_mac_cb
*mac_cb)
/* Loop over the child nodes and register a phy_device for each one */
if (!to_acpi_device_node(mac_cb->fw_port))
- return;
+ return -ENODEV;
rc = acpi_node_get_property_reference(
mac_cb->fw_port, "mdio-node", 0, &args);
if (rc)
- return;
+ return rc;
addr = hns_mac_phy_parse_addr(mac_cb->dev, mac_cb->fw_port);
if (addr < 0)
- return;
+ return addr;
/* dev address in adev */
pdev = hns_dsaf_find_platform_device(acpi_fwnode_handle(args.adev));
+ if (!pdev) {
+ dev_err(mac_cb->dev, "mac%d mdio pdev is NULL\n",
+ mac_cb->mac_id);
+ return -EINVAL;
+ }
+
mii_bus = platform_get_drvdata(pdev);
+ if (!mii_bus) {
+ dev_err(mac_cb->dev,
+ "mac%d mdio is NULL, dsaf will probe again later\n",
+ mac_cb->mac_id);
+ return -EPROBE_DEFER;
+ }
+
rc = hns_mac_register_phydev(mii_bus, mac_cb, addr);
if (!rc)
dev_dbg(mac_cb->dev, "mac%d register phy addr:%d\n",
mac_cb->mac_id, addr);
+
+ return rc;
}
#define MAC_MEDIA_TYPE_MAX_LEN 16
@@ -793,7 +810,7 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
*@np:device node
* return: 0 --success, negative --fail
*/
-static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
+static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
{
struct device_node *np;
struct regmap *syscon;
@@ -903,7 +920,15 @@ static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
}
}
} else if (is_acpi_node(mac_cb->fw_port)) {
- hns_mac_register_phy(mac_cb);
+ ret = hns_mac_register_phy(mac_cb);
+ /*
+* Mac can work well if there is phy or not.If the port don't
+* connect with phy, the return value will be ignored. Only
+* when there is phy but can't find mdio bus, the return value
+* will be handled.
+*/
+ if (ret == -EPROBE_DEFER)
+ return ret;
} else {
dev_err(mac_cb->dev, "mac%d cannot find phy node\n",
mac_cb->mac_id);
@@ -1065,6 +1090,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
dsaf_dev->mac_cb[port_id] = mac_cb;
}
}
+
/* init mac_cb for all port */
for (port_id = 0; port_id < max_port_num; port_id++) {
mac_cb = dsaf_dev->mac_cb[port_id];
@@ -1074,6 +1100,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
ret = hns_mac_get_cfg(dsaf_dev, mac_cb);
if (ret)
return ret;
+
ret = hns_mac_init_ex(mac_cb);
if (ret)
return ret;
Re: [PATCH net v3 1/3] net: hns: support deferred probe when can not obtain irq
On 26/04/17 09:00, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, the interrupt lines from the
DSAF controllers are connected to mbigen hw module.
The mbigen module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
We check for probe deferral in the hw layer probe, so we not
probe into the main layer and memories, etc., to later learn
that we need to defer the probe.
This paragraph does not hold any more and should be deleted.
Other then this:
Reviewed-by: Matthias Brugger
Signed-off-by: lipeng
Reviewed-by: Yisen Zhuang
---
V2 -> V3:
1. Check return value when platform_get_irq in hns_rcb_get_cfg;
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 4 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 8 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 6ea8722..a41cf95 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -510,7 +510,9 @@ int hns_ppe_init(struct dsaf_device *dsaf_dev)
hns_ppe_get_cfg(dsaf_dev->ppe_common[i]);
- hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ ret = hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ if (ret)
+ goto get_rcb_cfg_fail;
}
for (i = 0; i < HNS_PPE_COM_NUM; i++)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index f0ed80d6..673a5d3 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -452,7 +452,7 @@ static int hns_rcb_get_base_irq_idx(struct rcb_common_cb
*rcb_common)
*hns_rcb_get_cfg - get rcb config
*@rcb_common: rcb common device
*/
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
{
struct ring_pair_cb *ring_pair_cb;
u32 i;
@@ -477,10 +477,16 @@ void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] =
is_ver1 ? platform_get_irq(pdev, base_irq_idx + i * 2 + 1) :
platform_get_irq(pdev, base_irq_idx + i * 3);
+ if ((ring_pair_cb->virq[HNS_RCB_IRQ_IDX_TX] == -EPROBE_DEFER) ||
+ (ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] == -EPROBE_DEFER))
+ return -EPROBE_DEFER;
+
ring_pair_cb->q.phy_base =
RCB_COMM_BASE_TO_RING_BASE(rcb_common->phy_base, i);
hns_rcb_ring_pair_get_cfg(ring_pair_cb);
}
+
+ return 0;
}
/**
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
index 99b4e1b..3d7b484 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
@@ -110,7 +110,7 @@ struct rcb_common_cb {
void hns_rcb_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index);
int hns_rcb_common_init_hw(struct rcb_common_cb *rcb_common);
void hns_rcb_start(struct hnae_queue *q, u32 val);
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
void hns_rcb_get_queue_mode(enum dsaf_mode dsaf_mode,
u16 *max_vfn, u16 *max_q_per_vf);
Re: [PATCH net v2 1/3] net: hns: support deferred probe when can not obtain irq
On 24/04/17 13:43, lipeng (Y) wrote:
On 2017/4/24 18:28, Matthias Brugger wrote:
On 21/04/17 09:44, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, the interrupt lines from the
DSAF controllers are connected to mbigen hw module.
The mbigen module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
We check for probe deferral in the hw layer probe, so we not
probe into the main layer and memories, etc., to later learn
that we need to defer the probe.
Why? This looks like a hack.
From what I see, we can handle EPROBE_DEFER easily inside hns_ppe_init
checking the return value of hns_rcb_get_cfg. Like you do in 2/3 of
this series.
Regards,
Matthias
Hi Matthias,
mdio && phy is not necessary condition, and port can work well for port
+ SFP (without mdio &&phy).
BUT irq is the necessary condition, port can not work well without irq.
So, I check IRQ first,and do not probe dsaf if can't obtain irq(1/3 of
this series), and check mdio only when there is phy(2/3 of this series).
And thanks for your review.
I think I didn't explained myself good enough.
I was suggesting the following (not even compile tested):
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index eba406bea52f..be38d47bc399 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -510,7 +510,9 @@ int hns_ppe_init(struct dsaf_device *dsaf_dev)
hns_ppe_get_cfg(dsaf_dev->ppe_common[i]);
- hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ ret = hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ if (reg < 0)
+ goto get_cfg_fail;
}
for (i = 0; i < HNS_PPE_COM_NUM; i++)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index c20a0f4f8f02..c7e801d0c3b7 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -492,7 +492,7 @@ static int hns_rcb_get_base_irq_idx(struct
rcb_common_cb *rcb_common)
*hns_rcb_get_cfg - get rcb config
*@rcb_common: rcb common device
*/
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
{
struct ring_pair_cb *ring_pair_cb;
u32 i;
@@ -517,10 +517,18 @@ void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] =
is_ver1 ? platform_get_irq(pdev, base_irq_idx + i * 2 +
1) :
platform_get_irq(pdev, base_irq_idx + i * 3);
+
+ if ((ring_pair_cb->virq[HNS_RCB_IRQ_IDX_TX] ==
-EPROBE_DEFER) ||
+ (ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] ==
-EPROBE_DEFER)) {
+ return -EPROBE_DEFER;
+ }
+
ring_pair_cb->q.phy_base =
RCB_COMM_BASE_TO_RING_BASE(rcb_common->phy_base, i);
hns_rcb_ring_pair_get_cfg(ring_pair_cb);
}
+
+ return 0;
}
/**
Regards,
Matthias
lipeng
Signed-off-by: lipeng
Reviewed-by: Yisen Zhuang
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 403ea9d..2da5b42 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2971,6 +2971,18 @@ static int hns_dsaf_probe(struct
platform_device *pdev)
struct dsaf_device *dsaf_dev;
int ret;
+/*
+ * Check if we should defer the probe before we probe the
+ * dsaf, as it's hard to defer later on.
+ */
+ret = platform_get_irq(pdev, 0);
+if (ret < 0) {
+if (ret != -EPROBE_DEFER)
+dev_err(&pdev->dev, "Cannot obtain irq\n");
+
+return ret;
+}
+
dsaf_dev = hns_dsaf_alloc_dev(&pdev->dev, sizeof(struct
dsaf_drv_priv));
if (IS_ERR(dsaf_dev)) {
ret = PTR_ERR(dsaf_dev);
.
Re: [PATCH net v2 1/3] net: hns: support deferred probe when can not obtain irq
On 21/04/17 09:44, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, the interrupt lines from the
DSAF controllers are connected to mbigen hw module.
The mbigen module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
We check for probe deferral in the hw layer probe, so we not
probe into the main layer and memories, etc., to later learn
that we need to defer the probe.
Why? This looks like a hack.
From what I see, we can handle EPROBE_DEFER easily inside hns_ppe_init
checking the return value of hns_rcb_get_cfg. Like you do in 2/3 of this
series.
Regards,
Matthias
Signed-off-by: lipeng
Reviewed-by: Yisen Zhuang
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 403ea9d..2da5b42 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2971,6 +2971,18 @@ static int hns_dsaf_probe(struct platform_device *pdev)
struct dsaf_device *dsaf_dev;
int ret;
+ /*
+* Check if we should defer the probe before we probe the
+* dsaf, as it's hard to defer later on.
+*/
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Cannot obtain irq\n");
+
+ return ret;
+ }
+
dsaf_dev = hns_dsaf_alloc_dev(&pdev->dev, sizeof(struct dsaf_drv_priv));
if (IS_ERR(dsaf_dev)) {
ret = PTR_ERR(dsaf_dev);
Re: [PATCH net-next 2/3] net: hns: support deferred probe when no mdio
On 18/04/17 12:12, Yankejian wrote:
From: lipeng
In the hip06 and hip07 SoCs, phy connect to mdio bus.The mdio
module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
We check for probe deferral in the mac init, so we not init DSAF
when there is no mdio, and free all resource, to later learn that
we need to defer the probe.
Signed-off-by: lipeng
on which kernel version is this patch based?
I checked against next-20170420 and it does not apply.
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 34 +++
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index bdd8cdd..284ebfe 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -735,6 +735,8 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
rc = phy_device_register(phy);
if (rc) {
phy_device_free(phy);
+ dev_err(&mdio->dev, "registered phy fail at address %i\n",
+ addr);
return -ENODEV;
}
@@ -745,7 +747,7 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
return 0;
}
-static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
+static int hns_mac_register_phy(struct hns_mac_cb *mac_cb)
{
struct acpi_reference_args args;
struct platform_device *pdev;
@@ -755,24 +757,39 @@ static void hns_mac_register_phy(struct hns_mac_cb
*mac_cb)
/* Loop over the child nodes and register a phy_device for each one */
if (!to_acpi_device_node(mac_cb->fw_port))
- return;
+ return 0;
Please return appropriate errno.
rc = acpi_node_get_property_reference(
mac_cb->fw_port, "mdio-node", 0, &args);
if (rc)
- return;
+ return 0;
Please return appropriate errno.
addr = hns_mac_phy_parse_addr(mac_cb->dev, mac_cb->fw_port);
if (addr < 0)
- return;
+ return 0;
Shouldn't we just error out here by returning addr?
/* dev address in adev */
pdev = hns_dsaf_find_platform_device(acpi_fwnode_handle(args.adev));
+ if (!pdev) {
+ dev_err(mac_cb->dev, "mac%d mdio pdev is NULL\n",
+ mac_cb->mac_id);
+ return 0;
Please return appropriate errno.
Regards,
Matthias
+ }
+
mii_bus = platform_get_drvdata(pdev);
+ if (!mii_bus) {
+ dev_err(mac_cb->dev,
+ "mac%d mdio is NULL, dsaf will probe again later\n",
+ mac_cb->mac_id);
+ return -EPROBE_DEFER;
+ }
+
rc = hns_mac_register_phydev(mii_bus, mac_cb, addr);
if (!rc)
dev_dbg(mac_cb->dev, "mac%d register phy addr:%d\n",
mac_cb->mac_id, addr);
+
+ return rc;
}
#define MAC_MEDIA_TYPE_MAX_LEN 16
@@ -793,7 +810,7 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
*@np:device node
* return: 0 --success, negative --fail
*/
-static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
+static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
{
struct device_node *np;
struct regmap *syscon;
@@ -903,7 +920,10 @@ static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
}
}
} else if (is_acpi_node(mac_cb->fw_port)) {
- hns_mac_register_phy(mac_cb);
+ ret = hns_mac_register_phy(mac_cb);
+
+ if (ret)
+ return ret;
} else {
dev_err(mac_cb->dev, "mac%d cannot find phy node\n",
mac_cb->mac_id);
@@ -1065,6 +1085,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
dsaf_dev->mac_cb[port_id] = mac_cb;
}
}
+
/* init mac_cb for all port */
for (port_id = 0; port_id < max_port_num; port_id++) {
mac_cb = dsaf_dev->mac_cb[port_id];
@@ -1074,6 +1095,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
ret = hns_mac_get_cfg(dsaf_dev, mac_cb);
if (ret)
return ret;
+
ret = hns_mac_init_ex(mac_cb);
if (ret)
return ret;
Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string
On 01/25/2017 09:20 AM, John Crispin wrote: When the binding was defined, I was not aware that mt2701 was an earlier version of the SoC. For sake of consistency, the ethernet driver should use mt2701 inside the compat string as this is the earliest SoC with the ethernet core. The ethernet driver is currently of no real use until we finish and upstream the DSA driver. There are no users of this binding yet. It should be safe to fix this now before it is too late and we need to provide backward compatibility for the mt7623-eth compat string. Reported-by: Sean Wang Signed-off-by: John Crispin --- sounds reasonable to me: Reviewed-by: Matthias Brugger Documentation/devicetree/bindings/net/mediatek-net.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt index c010faf..c7194e8 100644 --- a/Documentation/devicetree/bindings/net/mediatek-net.txt +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt @@ -7,7 +7,7 @@ have dual GMAC each represented by a child node.. * Ethernet controller node Required properties: -- compatible: Should be "mediatek,mt7623-eth" +- compatible: Should be "mediatek,mt2701-eth" - reg: Address and length of the register set for the device - interrupts: Should contain the three frame engines interrupts in numeric order. These are fe_int0, fe_int1 and fe_int2.
Re: [PATCH 0/5] net: thunderx: Miscellaneous fixes
On 11/14/2016 06:32 PM, David Miller wrote: From: Matthias Brugger Date: Mon, 14 Nov 2016 13:01:25 +0100 On 14/11/16 11:54, sunil.kovv...@gmail.com wrote: From: Sunil Goutham This patchset includes fixes for incorrect LMAC credits, unreliable driver statistics, memory leak upon interface down e.t.c Are these fixes relevant to for older kernels as well? If so, please add "Cc: sta...@vger.kernel.org" to the Sigend-off list. This is not appropriate for networking patches. People instead explicitly request -stable inclusion when the submit networking changes to me, and I queue them up for later submission. Ok, thanks for clarification.
Re: [PATCH 0/5] net: thunderx: Miscellaneous fixes
On 14/11/16 11:54, sunil.kovv...@gmail.com wrote: From: Sunil Goutham This patchset includes fixes for incorrect LMAC credits, unreliable driver statistics, memory leak upon interface down e.t.c Are these fixes relevant to for older kernels as well? If so, please add "Cc: sta...@vger.kernel.org" to the Sigend-off list. Thanks, Matthias Radha Mohan Chintakuntla (1): net: thunderx: Introduce BGX_ID_MASK macro to extract bgx_id Sunil Goutham (4): net: thunderx: Program LMAC credits based on MTU net: thunderx: Fix configuration of L3/L4 length checking net: thunderx: Fix VF driver's interface statistics net: thunderx: Fix memory leak and other issues upon interface toggle drivers/net/ethernet/cavium/thunder/nic.h | 64 + drivers/net/ethernet/cavium/thunder/nic_main.c | 37 +++-- drivers/net/ethernet/cavium/thunder/nic_reg.h | 1 + .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 105 +++--- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 153 +++-- drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 118 +--- drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 24 +--- drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 4 +- drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 2 + 9 files changed, 274 insertions(+), 234 deletions(-)
Re: [PATCH v3 2/5] drivers: net: xgene: Backward compatibility with older firmware
On 06/06/16 20:15, Iyappan Subramanian wrote:
This patch looks for CONFIG_MDIO_XGENE and based on phy-handle DT/ACPI
fields, sets the mdio_driver flag. The rest of the driver uses the
I'm a bit confused, you introduced mdio_driver flag already in patch 1.
this flag for any MDIO management, in the case of backward compatibility.
Also, some code clean up done around mdio configuration/remove.
IMHO code clean up should be part of a different patch.
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
Tested-by: Matthias Brugger
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c| 60 +++-
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 165 +++---
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 2 +
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 13 +-
4 files changed, 148 insertions(+), 92 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 5d6d14b..38d6ee4 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -476,9 +476,13 @@ static void xgene_gmac_reset(struct xgene_enet_pdata
*pdata)
static void xgene_enet_configure_clock(struct xgene_enet_pdata *pdata)
{
struct device *dev = &pdata->pdev->dev;
+ struct clk *parent;
if (dev->of_node) {
- struct clk *parent = clk_get_parent(pdata->clk);
+ if (IS_ERR(pdata->clk))
+ return;
+
+ parent = clk_get_parent(pdata->clk);
switch (pdata->phy_speed) {
case SPEED_10:
@@ -572,6 +576,9 @@ static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
{
u32 value;
+ if (!pdata->mdio_driver)
+ xgene_gmac_reset(pdata);
+
xgene_gmac_set_speed(pdata);
xgene_gmac_set_mac_addr(pdata);
@@ -677,7 +684,14 @@ static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
- xgene_enet_ecc_init(pdata);
+ if (!pdata->mdio_driver) {
+ if (!IS_ERR(pdata->clk)) {
+ clk_prepare_enable(pdata->clk);
+ clk_disable_unprepare(pdata->clk);
+ clk_prepare_enable(pdata->clk);
+ xgene_enet_ecc_init(pdata);
+ }
+ }
In the first patch you add xgene_enet_ecc_init and delete the clock
handling. Here you do it the other way round. And in patch 5 you put
both after calling xgene_enet_config_ring_if_assoc.
Are these changes needed like this in every patch?
xgene_enet_config_ring_if_assoc(pdata);
return 0;
@@ -800,27 +814,9 @@ static int xgene_mdiobus_register(struct xgene_enet_pdata
*pdata,
struct mii_bus *mdio)
{
struct device *dev = &pdata->pdev->dev;
- struct device_node *mdio_np = NULL;
- struct device_node *child_np;
- u32 phyid;
if (dev->of_node) {
- for_each_child_of_node(dev->of_node, child_np) {
- if (of_device_is_compatible(child_np,
- "apm,xgene-mdio")) {
- mdio_np = child_np;
- break;
- }
- }
-
- if (!mdio_np) {
- mdiobus_free(mdio);
- return 0;
- }
-
- pdata->mdio_driver = false;
-
- return of_mdiobus_register(mdio, mdio_np);
+ return of_mdiobus_register(mdio, pdata->mdio_np);
} else {
#ifdef CONFIG_ACPI
struct phy_device *phy;
@@ -839,13 +835,7 @@ static int xgene_mdiobus_register(struct xgene_enet_pdata
*pdata,
if (ret)
return ret;
- ret = device_property_read_u32(dev, "phy-channel", &phyid);
- if (ret)
- ret = device_property_read_u32(dev, "phy-addr", &phyid);
- if (ret)
- return -EINVAL;
-
- phy = get_phy_device(mdio, phyid, false);
+ phy = get_phy_device(mdio, pdata->phy_id, false);
if (IS_ERR(phy))
return -EIO;
@@ -858,6 +848,8 @@ static int xgene_mdiobus_register(struct xgene_enet_pdata
*pdata,
return ret;
#endif
}
+
+ return 0;
}
int xgene_enet_mdio_config(struct xgene_enet_pdata *pdata)
@@ -885,10 +877,6 @@ int xgene_enet_mdio_config(struct xgene_enet_pdata *pdata)
if (mdio_bus->state == MDIOBUS_REGISTERED)
mdiobus_unregister(pdata->mdio_bus);
mdiobu
Re: [PATCH v3 3/5] drivers: net: phy: Add MDIO driver
On 06/06/16 20:16, Iyappan Subramanian wrote:
Currently, SGMII based 1G rely on the hardware registers for link state
and sometimes it's not reliable. To get most accurate link state, this
interface has to use the MDIO bus to poll the PHY.
In X-Gene SoC, MDIO bus is shared across RGMII and SGMII based 1G
interfaces, so adding this driver to manage MDIO bus. This driver
registers the mdio bus and registers the PHYs connected to it.
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
Tested-by: Matthias Brugger
---
drivers/net/ethernet/apm/xgene/Kconfig | 1 +
drivers/net/phy/Kconfig| 7 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-xgene.c | 532 +
drivers/net/phy/mdio-xgene.h | 140 +
5 files changed, 681 insertions(+)
create mode 100644 drivers/net/phy/mdio-xgene.c
create mode 100644 drivers/net/phy/mdio-xgene.h
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig
b/drivers/net/ethernet/apm/xgene/Kconfig
index 19e38af..300e3b5 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -3,6 +3,7 @@ config NET_XGENE
depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
+ select MDIO_XGENE
help
This is the Ethernet driver for the on-chip ethernet interface on the
APM X-Gene SoC.
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 6dad9a9..193f418 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -271,6 +271,13 @@ config MDIO_BCM_IPROC
This module provides a driver for the MDIO busses found in the
Broadcom iProc SoC's.
+config MDIO_XGENE
+ tristate "APM X-Gene SoC MDIO bus controller"
+ help
+ This module provides a driver for the MDIO busses found in the
+ APM X-Gene SoC's.
+
+
endif # PHYLIB
config MICREL_KS8995MA
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index fcdbb92..9cbd2af 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -44,3 +44,4 @@ obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
+obj-$(CONFIG_MDIO_XGENE) += mdio-xgene.o
diff --git a/drivers/net/phy/mdio-xgene.c b/drivers/net/phy/mdio-xgene.c
new file mode 100644
index 000..48273e3
--- /dev/null
+++ b/drivers/net/phy/mdio-xgene.c
@@ -0,0 +1,532 @@
+/* Applied Micro X-Gene SoC MDIO Driver
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Author: Iyappan Subramanian
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mdio-xgene.h"
+
+static bool xgene_mdio_status;
+
+static bool xgene_enet_rd_indirect(void __iomem *addr, void __iomem *rd,
+ void __iomem *cmd, void __iomem *cmd_done,
+ u32 rd_addr, u32 *rd_data)
+{
+ u32 done;
+ u8 wait = 10;
+
+ iowrite32(rd_addr, addr);
+ iowrite32(XGENE_ENET_RD_CMD, cmd);
+
+ /* wait for read command to complete */
+ while (!(done = ioread32(cmd_done)) && wait--)
+ udelay(1);
+
+ if (!done)
+ return false;
+
+ *rd_data = ioread32(rd);
+ iowrite32(0, cmd);
+
+ return true;
+}
+
+static void xgene_enet_rd_mcx_mac(struct xgene_mdio_pdata *pdata,
+ u32 rd_addr, u32 *rd_data)
+{
+ void __iomem *addr, *rd, *cmd, *cmd_done;
+
+ addr = pdata->mac_csr_addr + MAC_ADDR_REG_OFFSET;
+ rd = pdata->mac_csr_addr + MAC_READ_REG_OFFSET;
+ cmd = pdata->mac_csr_addr + MAC_COMMAND_REG_OFFSET;
+ cmd_done = pdata->mac_csr_addr + MAC_COMMAND_DONE_REG_OFFSET;
+
+ if (!xgene_enet_rd_indirect(addr, rd, cmd, cmd_done, rd_addr, rd_data))
+ dev_err(pdata->dev, "MCX mac read failed, addr: 0x%04x\n",
+ rd_addr);
+}
+
+static bool xgene_enet_wr_indirect(void __iomem *addr, void __iom
Re: [PATCH v3 1/5] drivers: net: xgene: MAC and PHY configuration changes
On 06/06/16 20:15, Iyappan Subramanian wrote:
This patch fixes MAC configuration to support 10/100GbE for SGMII and
link_state call back. It also sets pdata->mdio_driver flag based on
ethernet mdio subnode and prepare for MDIO driver support.
In summary, following are the changes,
- Added set_speed function pointer in mac_ops
This can be a seperate patch, or would it break the driver?
In the end, the decision how to split up the patches is up to Dave. I
prefer to have more small patches which do incrementally add new stuff
to the driver, taking into account that every single patch does not
break it.
- Changed link_state to call the set_speed
- Add 10/100 support for SGMII based 1G
- Fixed mac_init for 1G
- Call mac_ops rx_enable/disable and tx_enable/disable function pointers
For me, this is a seperate patch which does a cleanup of the driver. You
just use the mac_ops for these function (enable/disable and init) and in
a second patch you add the set_speed and delete the init call.
- Add acpi_phy_find_device to find PHY using phy-handle reference object
- Changing phy_start and phy_stop calls based on phy_dev object existence
- Calling phy_connect based on pdata->mdio_driver flag
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
Tested-by: Matthias Brugger
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c| 190 +-
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h| 5 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 41 +++--
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 2 +
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 106 +++-
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.h | 8 +
drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.h | 4 +
7 files changed, 259 insertions(+), 97 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 2f5638f..5d6d14b 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -512,14 +512,11 @@ static void xgene_enet_configure_clock(struct
xgene_enet_pdata *pdata)
#endif
}
-static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
+static void xgene_gmac_set_speed(struct xgene_enet_pdata *pdata)
{
struct device *dev = &pdata->pdev->dev;
- u32 value, mc2;
- u32 intf_ctl, rgmii;
- u32 icm0, icm2;
-
- xgene_gmac_reset(pdata);
+ u32 icm0, icm2, mc2;
+ u32 intf_ctl, rgmii, value;
xgene_enet_rd_mcx_csr(pdata, ICM_CONFIG0_REG_0_ADDR, &icm0);
xgene_enet_rd_mcx_csr(pdata, ICM_CONFIG2_REG_0_ADDR, &icm2);
@@ -564,7 +561,18 @@ static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
mc2 |= FULL_DUPLEX2 | PAD_CRC;
xgene_enet_wr_mcx_mac(pdata, MAC_CONFIG_2_ADDR, mc2);
xgene_enet_wr_mcx_mac(pdata, INTERFACE_CONTROL_ADDR, intf_ctl);
+ xgene_enet_wr_csr(pdata, RGMII_REG_0_ADDR, rgmii);
+ xgene_enet_configure_clock(pdata);
+
+ xgene_enet_wr_mcx_csr(pdata, ICM_CONFIG0_REG_0_ADDR, icm0);
+ xgene_enet_wr_mcx_csr(pdata, ICM_CONFIG2_REG_0_ADDR, icm2);
+}
+static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
+{
+ u32 value;
+
+ xgene_gmac_set_speed(pdata);
xgene_gmac_set_mac_addr(pdata);
/* Adjust MDC clock frequency */
@@ -579,15 +587,10 @@ static void xgene_gmac_init(struct xgene_enet_pdata
*pdata)
/* Rtype should be copied from FP */
xgene_enet_wr_csr(pdata, RSIF_RAM_DBG_REG0_ADDR, 0);
- xgene_enet_wr_csr(pdata, RGMII_REG_0_ADDR, rgmii);
- xgene_enet_configure_clock(pdata);
/* Rx-Tx traffic resume */
xgene_enet_wr_csr(pdata, CFG_LINK_AGGR_RESUME_0_ADDR, TX_PORT0);
- xgene_enet_wr_mcx_csr(pdata, ICM_CONFIG0_REG_0_ADDR, icm0);
- xgene_enet_wr_mcx_csr(pdata, ICM_CONFIG2_REG_0_ADDR, icm2);
-
Is this the part you refer to with "Fixed mac_init for 1G"?
What does it fix? Does this fix something which might be worth getting
backported to older kernel versions?
xgene_enet_rd_mcx_csr(pdata, RX_DV_GATE_REG_0_ADDR, &value);
value &= ~TX_DV_GATE_EN0;
value &= ~RX_DV_GATE_EN0;
@@ -671,25 +674,12 @@ bool xgene_ring_mgr_init(struct xgene_enet_pdata *p)
static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
{
- u32 val;
-
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
- if (!IS_ERR(pdata->clk)) {
- clk_prepare_enable(pdata->clk);
- clk_disable_unprepare(pdata->clk);
- clk_prepare_enable(pdata->clk);
- xgene_enet_ecc_init(pdata);
- }
+ xgene_enet_ecc_init(pdata);
xgene_enet_config_ring_if_assoc(pdata);
- /* Enable auto-incr for scanning */
- xgene_enet_rd_mcx_mac(pdata, MII_MGMT_CONFIG_ADDR, &val);
-
Re: [PATCH v1 5/6] dtb: xgene: Remove clock nodes
On 27/05/16 09:22, Iyappan Subramanian wrote:
Since the MDIO will be responsible for clock reset, removing the clock
nodes from shadowcat xge0 and storm sgenet1.
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 12
arch/arm64/boot/dts/apm/apm-storm.dtsi | 18 --
2 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 8106957..f27563d 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -299,17 +299,6 @@
clock-output-names = "pcie1clk";
};
- xge0clk: xge0clk@1f61c000 {
- compatible = "apm,xgene-device-clock";
- #clock-cells = <1>;
- clocks = <&socplldiv2 0>;
- reg = <0x0 0x1f61c000 0x0 0x1000>;
- reg-names = "csr-reg";
- enable-mask = <0x3>;
- csr-mask = <0x3>;
- clock-output-names = "xge0clk";
- };
-
mdio@0x1f61 has xge0clk as input (patch 4), so deleting the node
here will break the device tree. I suppose the mdio consumes the
menetclk as in apm-storm.dtsi.
Regards,
Matthias
xge1clk: xge1clk@1f62c000 {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
@@ -643,7 +632,6 @@
interrupts = <0 96 4>,
<0 97 4>;
dma-coherent;
- clocks = <&xge0clk 0>;
local-mac-address = [00 01 73 00 00 01];
phy-connection-type = "sgmii";
phy-handle = <&sgenet0phy>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 18f694ea..f631fe4 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -237,20 +237,11 @@
clocks = <&socplldiv2 0>;
reg = <0x0 0x1f21c000 0x0 0x1000>;
reg-names = "csr-reg";
- csr-mask = <0x3>;
+ csr-mask = <0xa>;
+ enable-mask = <0xf>;
clock-output-names = "sge0clk";
};
- sge1clk: sge1clk@1f21c000 {
- compatible = "apm,xgene-device-clock";
- #clock-cells = <1>;
- clocks = <&socplldiv2 0>;
- reg = <0x0 0x1f21c000 0x0 0x1000>;
- reg-names = "csr-reg";
- csr-mask = <0xc>;
- clock-output-names = "sge1clk";
- };
-
xge0clk: xge0clk@1f61c000 {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
@@ -938,9 +929,9 @@
reg-names = "enet_csr", "ring_csr", "ring_cmd";
interrupts = <0x0 0x3c 0x4>;
dma-coherent;
- clocks = <&menetclk 0>;
/* mac address will be overwritten by the bootloader */
local-mac-address = [00 00 00 00 00 00];
+ clocks = <&menetclk 0>;
phy-connection-type = "rgmii";
phy-handle = <&menetphy>;
};
@@ -955,8 +946,8 @@
interrupts = <0x0 0xA0 0x4>,
<0x0 0xA1 0x4>;
dma-coherent;
- clocks = <&sge0clk 0>;
local-mac-address = [00 00 00 00 00 00];
+ clocks = <&sge0clk 0>;
phy-connection-type = "sgmii";
phy-handle = <&sgenet0phy>;
};
@@ -972,7 +963,6 @@
<0x0 0xAD 0x4>;
port-id = <1>;
dma-coherent;
- clocks = <&sge1clk 0>;
local-mac-address = [00 00 00 00 00 00];
phy-connection-type = "sgmii";
phy-handle = <&sgenet1phy>;
Re: [PATCH v1 1/6] drivers: net: xgene: MAC and PHY configuration changes
On 27/05/16 09:22, Iyappan Subramanian wrote:
This patch fixes MAC configuration to support 10/100GbE for SGMII and
link_state call back. It also sets pdata->mdio_driver flag based on
ethernet mdio subnode and prepare for MDIO driver support.
In summary, following are the changes,
- Added set_speed function pointer in mac_ops
- Changed link_state to call the set_speed
- Add 10/100 support for SGMII based 1G
- Fixed mac_init for 1G
- Call mac_ops rx_enable/disable and tx_enable/disable function pointers
This is just a code clean-up, right? If so, this should be a patch apart.
- Add acpi_phy_find_device to find PHY using phy-handle reference object
- Changing phy_start and phy_stop calls based on phy_dev object existence
- Calling phy_connect based on pdata->mdio_driver flag
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c| 189 +-
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h| 4 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 40 +++--
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 2 +
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 106 +++-
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.h | 8 +
drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.h | 4 +
7 files changed, 256 insertions(+), 97 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 2f5638f..6bc8360 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -512,14 +512,11 @@ static void xgene_enet_configure_clock(struct
xgene_enet_pdata *pdata)
[...]
static void xgene_sgmac_init(struct xgene_enet_pdata *p)
{
u32 data, loop = 10;
- u32 offset = p->port_id * 4;
+ u32 offset = 0;
u32 enet_spare_cfg_reg, rsif_config_reg;
u32 cfg_bypass_reg, rx_dv_gate_reg;
xgene_sgmac_reset(p);
/* Enable auto-negotiation */
- xgene_mii_phy_write(p, INT_PHY_ADDR, SGMII_CONTROL_ADDR >> 2, 0x1000);
+ xgene_mii_phy_write(p, INT_PHY_ADDR, SGMII_TBI_CONTROL_ADDR >> 2,
+ 0x8000);
+ xgene_mii_phy_write(p, INT_PHY_ADDR, SGMII_CONTROL_ADDR >> 2, 0x9000);
xgene_mii_phy_write(p, INT_PHY_ADDR, SGMII_TBI_CONTROL_ADDR >> 2, 0);
while (loop--) {
@@ -256,16 +343,14 @@ static void xgene_sgmac_init(struct xgene_enet_pdata *p)
if (!(data & AUTO_NEG_COMPLETE) || !(data & LINK_STATUS))
netdev_err(p->ndev, "Auto-negotiation failed\n");
- data = xgene_enet_rd_mac(p, MAC_CONFIG_2_ADDR);
- ENET_INTERFACE_MODE2_SET(&data, 2);
- xgene_enet_wr_mac(p, MAC_CONFIG_2_ADDR, data | FULL_DUPLEX2);
- xgene_enet_wr_mac(p, INTERFACE_CONTROL_ADDR, ENET_GHD_MODE);
+ xgene_sgmac_set_speed(p);
if (p->enet_id == XGENE_ENET1) {
enet_spare_cfg_reg = ENET_SPARE_CFG_REG_ADDR;
rsif_config_reg = RSIF_CONFIG_REG_ADDR;
cfg_bypass_reg = CFG_BYPASS_ADDR;
rx_dv_gate_reg = SG_RX_DV_GATE_REG_0_ADDR;
+ offset = p->port_id * 4;
At least for me it is not clear where the "4" comes from. Maybe you can
add a comment or declare a constant for that.
Anyway this looks like it fixes the driver for xgene2-sgnet and therefor
should go into a separate patch, or am I wrong?
Regards,
Matthias
Re: [PATCH v1 0/6] drivers: net: xgene: Fix 1G hot-plug and module support
On 27/05/16 09:22, Iyappan Subramanian wrote: This patchset addresses the following issues, 1. hot-plug issue on the SGMII 1G interface - by adding a driver for MDIO management 2. fixes the kernel crash when the driver loaded as an kernel module - by fixing hardware cleanups and rearrange kernel API calls Signed-off-by: Iyappan Subramanian --- Without this patches we observed problems on some hardware when the driver was loaded as modules, as well as the kernel crash when unloading/loading the module. I tested this with an older FW and both issues are fixed, so you can add Tested-by: Matthias Brugger But I think the way the series is split in different patches is not correct. Patch 1 on its own won't compile and get fixed in patch 2. Although I think backward compatibility to older firmware should be part of the changes which provide support for the new firmware and should not be a patch apart. Said this, I'm not sure if just squashing patch 1 and patch 2 is the right to do, as to me it seems as if some other fixes slipped into the series. From my point of view, patch 4 and 5 should be squashed, as xge0clk and sge1clk nodes are useless when the mdio nodes are present. Regards, Matthias Iyappan Subramanian (6): drivers: net: xgene: MAC and PHY configuration changes drivers: net: xgene: Backward compatibility with older firmware drivers: net: phy: Add MDIO driver dtb: xgene: Add MDIO node dtb: xgene: Remove clock nodes drivers: net: xgene: Fix module load/unload crash arch/arm64/boot/dts/apm/apm-merlin.dts| 10 + arch/arm64/boot/dts/apm/apm-mustang.dts | 12 + arch/arm64/boot/dts/apm/apm-shadowcat.dtsi| 23 +- arch/arm64/boot/dts/apm/apm-storm.dtsi| 38 +- drivers/net/ethernet/apm/xgene/Kconfig| 1 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.c| 241 ++ drivers/net/ethernet/apm/xgene/xgene_enet_hw.h| 18 +- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 325 - drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 36 +- drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 191 +++- drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.h | 8 + drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 66 ++- drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.h | 4 + drivers/net/phy/Kconfig | 7 + drivers/net/phy/Makefile | 1 + drivers/net/phy/mdio-xgene.c | 531 ++ drivers/net/phy/mdio-xgene.h | 140 ++ 17 files changed, 1373 insertions(+), 279 deletions(-) create mode 100644 drivers/net/phy/mdio-xgene.c create mode 100644 drivers/net/phy/mdio-xgene.h
[PATCH] drivers: net: xgene: Fix error handling
When probe bails out with an error, we try to unregister the
netdev before we have even registered it. Fix the goto statements
for that.
Signed-off-by: Matthias Brugger
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 8d4c1ad..99d7e58 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1595,21 +1595,22 @@ static int xgene_enet_probe(struct platform_device
*pdev)
ret = xgene_enet_init_hw(pdata);
if (ret)
- goto err;
+ goto err_netdev;
mac_ops = pdata->mac_ops;
if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII) {
ret = xgene_enet_mdio_config(pdata);
if (ret)
- goto err;
+ goto err_netdev;
} else {
INIT_DELAYED_WORK(&pdata->link_work, mac_ops->link_state);
}
xgene_enet_napi_add(pdata);
return 0;
-err:
+err_netdev:
unregister_netdev(ndev);
+err:
free_netdev(ndev);
return ret;
}
--
2.6.6
Re: [PATCH] net: mediatek: fix checking for NULL instead of IS_ERR() in .probe
On 23/03/16 00:06, Vladimir Zapolskiy wrote:
devm_ioremap_resource() returns ERR_PTR() value on error, it never
returns NULL, fix it and propagate the returned error upwards.
Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet")
Signed-off-by: Vladimir Zapolskiy
---
Reviewed-by: Matthias Brugger
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 7f2126b..e0b68af 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1690,8 +1690,8 @@ static int mtk_probe(struct platform_device *pdev)
return -ENOMEM;
eth->base = devm_ioremap_resource(&pdev->dev, res);
- if (!eth->base)
- return -EADDRNOTAVAIL;
+ if (IS_ERR(eth->base))
+ return PTR_ERR(eth->base);
spin_lock_init(ð->page_lock);
