Netdev List
 help / color / mirror / Atom feed
* RE: [PATCH net-next] net: phy: realtek: add support for RTL8821F(D)(I)-VD-CG
From: Wei Fang @ 2022-08-11  1:48 UTC (permalink / raw)
  To: Heiner Kallweit, andrew@lunn.ch, linux@armlinux.org.uk,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org
  Cc: Clark Wang
In-Reply-To: <910fdffd-53b5-8b9a-1ba5-496ddddb9230@gmail.com>



> -----Original Message-----
> From: Heiner Kallweit <hkallweit1@gmail.com>
> Sent: 2022年8月11日 3:55
> To: Wei Fang <wei.fang@nxp.com>; andrew@lunn.ch; linux@armlinux.org.uk;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; netdev@vger.kernel.org
> Cc: Clark Wang <xiaoning.wang@nxp.com>
> Subject: Re: [PATCH net-next] net: phy: realtek: add support for
> RTL8821F(D)(I)-VD-CG
> 
> On 10.08.2022 19:37, wei.fang@nxp.com wrote:
> > From: Clark Wang <xiaoning.wang@nxp.com>
> >
> > RTL8821F(D)(I)-VD-CG is the pin-to-pin upgrade chip from
> > RTL8821F(D)(I)-CG.
> >
> 
> Don't you mean 8211 instead of 8821 here?
> 
Sorry, It’s written error, I'll correct it in next version.

> > Add new PHY ID for this chip.
> > It does not support RTL8211F_PHYCR2 anymore, so remove the w/r
> > operation of this register.
> >
> > Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
> > ---
> >  drivers/net/phy/realtek.c | 48
> > +++++++++++++++++++++++++++++----------
> >  1 file changed, 36 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index a5671ab896b3..bfde22dc85f5 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -70,6 +70,7 @@
> >  #define RTLGEN_SPEED_MASK			0x0630
> >
> >  #define RTL_GENERIC_PHYID			0x001cc800
> > +#define RTL_8211FVD_PHYID			0x001cc878
> >
> >  MODULE_DESCRIPTION("Realtek PHY driver");
> MODULE_AUTHOR("Johnson
> > Leung"); @@ -80,6 +81,11 @@ struct rtl821x_priv {
> >  	u16 phycr2;
> >  };
> >
> > +static bool is_rtl8211fvd(u32 phy_id)
> 
> Better add a has_phycr2 to struct rtl821x_priv. Then you have:
> 
> if (priv->has_phycr2)
> 	do_something_with(priv->phycr2);
> 

Thanks for your suggestion, I will apply this method in next version.

> > +{
> > +	return phy_id == RTL_8211FVD_PHYID;
> > +}
> > +
> >  static int rtl821x_read_page(struct phy_device *phydev)  {
> >  	return __phy_read(phydev, RTL821x_PAGE_SELECT); @@ -94,6 +100,7
> @@
> > static int rtl821x_probe(struct phy_device *phydev)  {
> >  	struct device *dev = &phydev->mdio.dev;
> >  	struct rtl821x_priv *priv;
> > +	u32 phy_id = phydev->drv->phy_id;
> >  	int ret;
> >
> >  	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); @@ -108,13
> > +115,15 @@ static int rtl821x_probe(struct phy_device *phydev)
> >  	if (of_property_read_bool(dev->of_node, "realtek,aldps-enable"))
> >  		priv->phycr1 |= RTL8211F_ALDPS_PLL_OFF |
> RTL8211F_ALDPS_ENABLE |
> > RTL8211F_ALDPS_XTAL_OFF;
> >
> > -	ret = phy_read_paged(phydev, 0xa43, RTL8211F_PHYCR2);
> > -	if (ret < 0)
> > -		return ret;
> > +	if (!is_rtl8211fvd(phy_id)) {
> > +		ret = phy_read_paged(phydev, 0xa43, RTL8211F_PHYCR2);
> > +		if (ret < 0)
> > +			return ret;
> >
> > -	priv->phycr2 = ret & RTL8211F_CLKOUT_EN;
> > -	if (of_property_read_bool(dev->of_node, "realtek,clkout-disable"))
> > -		priv->phycr2 &= ~RTL8211F_CLKOUT_EN;
> > +		priv->phycr2 = ret & RTL8211F_CLKOUT_EN;
> > +		if (of_property_read_bool(dev->of_node, "realtek,clkout-disable"))
> > +			priv->phycr2 &= ~RTL8211F_CLKOUT_EN;
> > +	}
> >
> >  	phydev->priv = priv;
> >
> > @@ -333,6 +342,7 @@ static int rtl8211f_config_init(struct phy_device
> > *phydev)  {
> >  	struct rtl821x_priv *priv = phydev->priv;
> >  	struct device *dev = &phydev->mdio.dev;
> > +	u32 phy_id = phydev->drv->phy_id;
> >  	u16 val_txdly, val_rxdly;
> >  	int ret;
> >
> > @@ -400,12 +410,14 @@ static int rtl8211f_config_init(struct phy_device
> *phydev)
> >  			val_rxdly ? "enabled" : "disabled");
> >  	}
> >
> > -	ret = phy_modify_paged(phydev, 0xa43, RTL8211F_PHYCR2,
> > -			       RTL8211F_CLKOUT_EN, priv->phycr2);
> > -	if (ret < 0) {
> > -		dev_err(dev, "clkout configuration failed: %pe\n",
> > -			ERR_PTR(ret));
> > -		return ret;
> > +	if (!is_rtl8211fvd(phy_id)) {
> > +		ret = phy_modify_paged(phydev, 0xa43, RTL8211F_PHYCR2,
> > +				       RTL8211F_CLKOUT_EN, priv->phycr2);
> > +		if (ret < 0) {
> > +			dev_err(dev, "clkout configuration failed: %pe\n",
> > +				ERR_PTR(ret));
> > +			return ret;
> > +		}
> >  	}
> >
> >  	return genphy_soft_reset(phydev);
> > @@ -923,6 +935,18 @@ static struct phy_driver realtek_drvs[] = {
> >  		.resume		= rtl821x_resume,
> >  		.read_page	= rtl821x_read_page,
> >  		.write_page	= rtl821x_write_page,
> > +	}, {
> > +		PHY_ID_MATCH_EXACT(RTL_8211FVD_PHYID),
> > +		.name		= "RTL8211F-VD Gigabit Ethernet",
> > +		.probe		= rtl821x_probe,
> > +		.config_init	= &rtl8211f_config_init,
> > +		.read_status	= rtlgen_read_status,
> > +		.config_intr	= &rtl8211f_config_intr,
> > +		.handle_interrupt = rtl8211f_handle_interrupt,
> > +		.suspend	= genphy_suspend,
> > +		.resume		= rtl821x_resume,
> > +		.read_page	= rtl821x_read_page,
> > +		.write_page	= rtl821x_write_page,
> >  	}, {
> >  		.name		= "Generic FE-GE Realtek PHY",
> >  		.match_phy_device = rtlgen_match_phy_device,
> 
> And by the way, net-next is closed currently.

Okay, I will post the V2 when the net-next is re-opened, Thanks for your kindly reminder.

^ permalink raw reply

* Re: [PATCH] selftests:net:forwarding: Included install command
From: Hangbin Liu @ 2022-08-11  1:41 UTC (permalink / raw)
  To: Siddh Raman Pant
  Cc: Piyush Thange, davem, edumazet, kuba, pabeni, shuah,
	vladimir.oltean, idosch, petrm, troglobit, amcohen, tobias,
	po-hsu.lin, netdev, linux-kselftest, linux-kernel,
	linux-kernel-mentees
In-Reply-To: <182872c2de1.4461d55242061.8862004854197621952@siddh.me>

On Wed, Aug 10, 2022 at 03:23:15PM +0530, Siddh Raman Pant wrote:
> On Wed, 10 Aug 2022 15:05:08 +0530  Piyush Thange <pthange19@gmail.com>  wrote:
> > If the execution is skipped due to "jq not installed" message then
> > the installation methods on different OS's have been provided with
> > this message.
> > 
> > Signed-off-by: Piyush Thange <pthange19@gmail.com>
> > ---
> >  tools/testing/selftests/net/forwarding/lib.sh | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> > index 37ae49d47853..c4121856fe06 100755
> > --- a/tools/testing/selftests/net/forwarding/lib.sh
> > +++ b/tools/testing/selftests/net/forwarding/lib.sh
> > @@ -152,6 +152,14 @@ require_command()
> > 
> >  	if [[ ! -x "$(command -v "$cmd")" ]]; then
> >  		echo "SKIP: $cmd not installed"
> > +		if [[ $cmd == "jq" ]]; then
> > +			echo " Install on Debian based systems"
> > +			echo "	sudo apt -y install jq"
> > +			echo " Install on RHEL based systems"
> > +			echo "	sudo yum -y install jq"
> > +			echo " Install on Fedora based systems"
> > +			echo "	sudo dnf -y install jq"
> > +		fi
> >  		exit $ksft_skip
> >  	fi
> >  }
> > --
> > 2.37.1
> 
> This is very specific to `jq` command. What's special with `jq` and not
> others? If methods have to be shown, they should be shown for all the
> programs which are not installed.

Agree. The user could decide if jq should be install via REQUIRE_JQ. There are
also other cmds that vendor may not build by default. I didn't see any
selftests need to handle the installation. The users should takes care of it.

require_command() has takes care most of the needed cmds. If we want to
improve the user's experience for the needed cmds. I think add the needed cmds
to README file is better.

Thanks
Hangbin

^ permalink raw reply

* Re: [PATCH] fec: Restart PPS after link state change
From: Richard Cochran @ 2022-08-11  1:37 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Csókás Bence, netdev, Fugang Duan
In-Reply-To: <YvRH06S/7E6J8RY0@lunn.ch>

On Thu, Aug 11, 2022 at 02:05:39AM +0200, Andrew Lunn wrote:
> > Yes. We use PPS to synchronize devices on a common backplane. We use PTP to
> > sync this PPS to a master clock. But if PTP sync drops out, we wouldn't want
> > the backplane-level synchronization to fail. The PPS needs to stay on as
> > long as userspace *explicitly* disables it, regardless of what happens to
> > the link.
> 
> We need the PTP Maintainers view on that. I don't know if that is
> normal or not.

IMO the least surprising behavior is that once enabled, a feature
stays on until explicitly disabled.

Thanks,
Richard

^ permalink raw reply

* Re: [PATCH V4 5/6] vDPA: answer num of queue pairs = 1 to userspace when VIRTIO_NET_F_MQ == 0
From: Si-Wei Liu @ 2022-08-11  0:58 UTC (permalink / raw)
  To: Jason Wang
  Cc: Michael S. Tsirkin, Parav Pandit, netdev@vger.kernel.org,
	Zhu Lingshan, xieyongji@bytedance.com, gautam.dawar@amd.com,
	virtualization@lists.linux-foundation.org
In-Reply-To: <CACGkMEuSY=se+CnsiwH2BdaAv3Eu7L=-xJED-wSNiDwCP9RRXQ@mail.gmail.com>



On 8/9/2022 6:09 PM, Jason Wang wrote:
> On Wed, Aug 10, 2022 at 8:54 AM Si-Wei Liu <si-wei.liu@oracle.com> wrote:
>>
>>
>> On 8/9/2022 12:36 PM, Michael S. Tsirkin wrote:
>>> On Fri, Jul 22, 2022 at 01:14:42PM +0000, Parav Pandit wrote:
>>>>> From: Zhu Lingshan <lingshan.zhu@intel.com>
>>>>> Sent: Friday, July 22, 2022 7:53 AM
>>>>>
>>>>> If VIRTIO_NET_F_MQ == 0, the virtio device should have one queue pair, so
>>>>> when userspace querying queue pair numbers, it should return mq=1 than
>>>>> zero.
>>>>>
>>>>> Function vdpa_dev_net_config_fill() fills the attributions of the vDPA
>>>>> devices, so that it should call vdpa_dev_net_mq_config_fill() so the
>>>>> parameter in vdpa_dev_net_mq_config_fill() should be feature_device than
>>>>> feature_driver for the vDPA devices themselves
>>>>>
>>>>> Before this change, when MQ = 0, iproute2 output:
>>>>> $vdpa dev config show vdpa0
>>>>> vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false max_vq_pairs 0
>>>>> mtu 1500
>>>>>
>>>>> After applying this commit, when MQ = 0, iproute2 output:
>>>>> $vdpa dev config show vdpa0
>>>>> vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false max_vq_pairs 1
>>>>> mtu 1500
>>>>>
>>>> No. We do not want to diverge returning values of config space for fields which are not present as discussed in previous versions.
>>>> Please drop this patch.
>>>> Nack on this patch.
>>> Wrt this patch as far as I'm concerned you guys are bikeshedding.
>>>
>>> Parav generally don't send nacks please they are not helpful.
>>>
>>> Zhu Lingshan please always address comments in some way.  E.g. refer to
>>> them in the commit log explaining the motivation and the alternatives.
>>> I know you don't agree with Parav but ghosting isn't nice.
>>>
>>> I still feel what we should have done is
>>> not return a value, as long as we do return it we might
>>> as well return something reasonable, not 0.
>> Maybe I missed something but I don't get this, when VIRTIO_NET_F_MQ is
>> not negotiated, the VDPA_ATTR_DEV_NET_CFG_MAX_VQP attribute is simply
>> not there, but userspace (iproute) mistakenly puts a zero value there.
>> This is a pattern every tool in iproute follows consistently by large. I
>> don't get why kernel has to return something without seeing a very
>> convincing use case?
>>
>> Not to mention spec doesn't give us explicit definition for when the
>> field in config space becomes valid and/or the default value at first
>> sights as part of feature negotiation. If we want to stick to the model
>> Lingshan proposed, maybe fix the spec first then get back on the details?
> So spec said
>
> "
> The following driver-read-only field, max_virtqueue_pairs only exists
> if VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is set.
> "
>
> My understanding is that the field is always valid if the device
> offers the feature.
The tricky part is to deal with VERSION_1 on transitional device that 
determines the endianness of field. I know we don't support !VERSION_1 
vdpa provider for now, but the tool should be made independent of this 
assumption.

For the most of config fields there's no actual valid "default" value 
during feature negotiation until it can be determined after negotiation 
is done. I wonder what is the administrative value if presenting those 
random value to the end user? And there's even special feature like 
VIRTIO_BLK_F_CONFIG_WCE that only present valid feature value after 
negotiation. I'm afraid it may further confuse end user, or it would 
require them to read and understand all of details in spec, which 
apparently contradict to the goal of showing meaningful queue-pair value 
without requiring user to read the spec details.

-Siwei

>
> Btw, even if the spec is unclear, it would be very hard to "fix" it
> without introducing a new feature bit, it means we still need to deal
> with device without the new feature.
>
> Thanks
>
>> -Siwei
>>
>>> And I like it that this fixes sparse warning actually:
>>> max_virtqueue_pairs it tagged as __virtio, not __le.
>>>
>>> However, I am worried there is another bug here:
>>> this is checking driver features. But really max vqs
>>> should not depend on that, it depends on device
>>> features, no?
>>>
>>>
>>>
>>>>> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
>>>>> ---
>>>>>    drivers/vdpa/vdpa.c | 7 ++++---
>>>>>    1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index
>>>>> d76b22b2f7ae..846dd37f3549 100644
>>>>> --- a/drivers/vdpa/vdpa.c
>>>>> +++ b/drivers/vdpa/vdpa.c
>>>>> @@ -806,9 +806,10 @@ static int vdpa_dev_net_mq_config_fill(struct
>>>>> vdpa_device *vdev,
>>>>>      u16 val_u16;
>>>>>
>>>>>      if ((features & BIT_ULL(VIRTIO_NET_F_MQ)) == 0)
>>>>> -           return 0;
>>>>> +           val_u16 = 1;
>>>>> +   else
>>>>> +           val_u16 = __virtio16_to_cpu(true, config-
>>>>>> max_virtqueue_pairs);
>>>>> -   val_u16 = le16_to_cpu(config->max_virtqueue_pairs);
>>>>>      return nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MAX_VQP,
>>>>> val_u16);  }
>>>>>
>>>>> @@ -842,7 +843,7 @@ static int vdpa_dev_net_config_fill(struct
>>>>> vdpa_device *vdev, struct sk_buff *ms
>>>>>                            VDPA_ATTR_PAD))
>>>>>              return -EMSGSIZE;
>>>>>
>>>>> -   return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver,
>>>>> &config);
>>>>> +   return vdpa_dev_net_mq_config_fill(vdev, msg, features_device,
>>>>> +&config);
>>>>>    }
>>>>>
>>>>>    static int
>>>>> --
>>>>> 2.31.1
>>> _______________________________________________
>>> Virtualization mailing list
>>> Virtualization@lists.linux-foundation.org
>>> https://urldefense.com/v3/__https://lists.linuxfoundation.org/mailman/listinfo/virtualization__;!!ACWV5N9M2RV99hQ!NE42b1rl66ElGUzHr3b9xXGYCs2Vpb5dkhF0fPXnAyyFYzZZyzsY9NV_Qbf2AZCI3XxC13_nlWfSVN52yIM$
>> _______________________________________________
>> Virtualization mailing list
>> Virtualization@lists.linux-foundation.org
>> https://urldefense.com/v3/__https://lists.linuxfoundation.org/mailman/listinfo/virtualization__;!!ACWV5N9M2RV99hQ!NE42b1rl66ElGUzHr3b9xXGYCs2Vpb5dkhF0fPXnAyyFYzZZyzsY9NV_Qbf2AZCI3XxC13_nlWfSVN52yIM$
>>


^ permalink raw reply

* Re: [PATCH v2 net-next] net: ethernet: ti: davinci_mdio: Add workaround for errata i2329
From: Andrew Lunn @ 2022-08-11  0:30 UTC (permalink / raw)
  To: Ravi Gunasekaran
  Cc: davem, edumazet, kuba, pabeni, linux-omap, netdev, linux-kernel,
	linux-arm-kernel, kishon, vigneshr
In-Reply-To: <20220810111345.31200-1-r-gunasekaran@ti.com>

> +static int davinci_mdiobb_read(struct mii_bus *bus, int phy, int reg)
> +{
> +	int ret;
> +	struct mdiobb_ctrl *ctrl = bus->priv;
> +	struct davinci_mdio_data *data;
> +
> +	data = container_of(ctrl, struct davinci_mdio_data, bb_ctrl);
> +
> +	if (phy & ~PHY_REG_MASK || reg & ~PHY_ID_MASK)
> +		return -EINVAL;

You don't need this. Leave it up to the bit banging code to do the
validation. This also breaks C45, which the bit banging code can do,
and it looks like the hardware cannot.

> +
> +	ret = pm_runtime_resume_and_get(data->dev);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = mdiobb_read(bus, phy, reg);
> +
> +	pm_runtime_mark_last_busy(data->dev);
> +	pm_runtime_put_autosuspend(data->dev);

Once you take the validation out, this function then all becomes about
runtime power management. Should the bit banging core actually be
doing this? It seems like it is something which could be useful for
other devices.

struct mii_bus has a parent member. If set, you could apply these run
time PM functions to that. Please add a patch to modify the core bit
banging code, and then you should be able to remove these helpers.

>  static int davinci_mdio_probe(struct platform_device *pdev)
>  {
>  	struct mdio_platform_data *pdata = dev_get_platdata(&pdev->dev);
> @@ -340,12 +535,30 @@ static int davinci_mdio_probe(struct platform_device *pdev)
>  	struct phy_device *phy;
>  	int ret, addr;
>  	int autosuspend_delay_ms = -1;
> +	const struct soc_device_attribute *soc_match_data;

netdev uses reverse christmas tree. Variables should be sorted longest
first, shortest last.

       Andrew

^ permalink raw reply

* Re: [PATCH bpf-next v3 0/3] Add more bpf_*_ct_lookup() selftests
From: Kumar Kartikeya Dwivedi @ 2022-08-11  0:25 UTC (permalink / raw)
  To: Daniel Xu
  Cc: bpf, ast, daniel, andrii, linux-kernel, netdev, netfilter-devel,
	pablo, fw, toke@redhat.com
In-Reply-To: <cover.1660173222.git.dxu@dxuuu.xyz>

On Thu, 11 Aug 2022 at 01:16, Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> This patchset adds more bpf_*_ct_lookup() selftests. The goal is to test
> interaction with netfilter subsystem as well as reading from `struct
> nf_conn`. The first is important when migrating legacy systems towards
> bpf. The latter is important in general to take full advantage of
> connection tracking.
>

Thank you for contributing these tests. Feel free to add:
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

People often look at selftests for usage examples these days, so it's
great to have coverage + examples for more use cases.

> I'll follow this patchset up with support for writing to `struct nf_conn`.
>

Please also cc netfilter-devel, netdev, Pablo, and Florian when you send it.

I think we can directly enable stores to ct->mark, since that is what
ctnetlink is doing too, so adding another helper for this would be
unnecessary overhead.


> Past discussion:
> - v2: https://lore.kernel.org/bpf/cover.1660062725.git.dxu@dxuuu.xyz/
> - v1: https://lore.kernel.org/bpf/cover.1659209738.git.dxu@dxuuu.xyz/
>
> Changes since v2:
> - Add bpf-ci kconfig changes
>
> Changes since v1:
> - Reword commit message / cover letter to not mention connmark writing
>
>
> Daniel Xu (3):
>   selftests/bpf: Add existing connection bpf_*_ct_lookup() test
>   selftests/bpf: Add connmark read test
>   selftests/bpf: Update CI kconfig
>
>  tools/testing/selftests/bpf/config            |  2 +
>  .../testing/selftests/bpf/prog_tests/bpf_nf.c | 60 +++++++++++++++++++
>  .../testing/selftests/bpf/progs/test_bpf_nf.c | 21 +++++++
>  3 files changed, 83 insertions(+)
>
> --
> 2.37.1
>

^ permalink raw reply

* Re: [PATCH] igc: Remove _I_PHY_ID check for i225 devices
From: Linjun Bao @ 2022-08-11  0:09 UTC (permalink / raw)
  To: Tony Nguyen
  Cc: Jeff Kirsher, David S. Miller, intel-wired-lan, netdev,
	linux-kernel
In-Reply-To: <da087ad9-981a-2a9f-a134-1f6cab7addc0@intel.com>



On 2022/8/11 上午1:20, Tony Nguyen wrote:
> On 8/10/2022 1:22 AM, Linjun Bao wrote:
>> Yes this commit was committed to mainline about one year ago. But this commit has not been included into kernel 5.4 yet, and I encountered the probe failure when using alderlake-s with Ethernet adapter i225-LM. Since I could not directly apply the patch 7c496de538ee to kernel 5.4, so I generated this patch for kernel 5.4 usage.
>>
>>
>> Looks like sending a duplicated patch is not expected. Would you please advise what is the proper action when encountering such case? 
> 
> Sounds like you want this backported to stable. Documentation on how to do it is here [1]. Option 3 seems to be the correct choice.
> 
Thank you Tony, you guide me the correct way, yeah I want this backported to stable kernel 5.4. And now I understand the get_maintainer.pl is for mainline development.

Regards
Joseph

> Thanks,
> Tony
> 
> [1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#procedure-for-submitting-patches-to-the-stable-tree

^ permalink raw reply

* Re: [PATCH] fec: Restart PPS after link state change
From: Andrew Lunn @ 2022-08-11  0:05 UTC (permalink / raw)
  To: Csókás Bence; +Cc: netdev, Richard Cochran, Fugang Duan
In-Reply-To: <299d74d5-2d56-23f6-affc-78bb3ae3e03c@prolan.hu>

> The fec driver doesn't support anything other than PTP_CLK_REQ_PPS. And if
> it will at some point, this will need to be amended anyways.

O.K.

> > 
> > >   	/* Whack a reset.  We should wait for this.
> > >   	 * For i.MX6SX SOC, enet use AXI bus, we use disable MAC
> > > @@ -1119,6 +1120,13 @@ fec_restart(struct net_device *ndev)
> > >   	if (fep->bufdesc_ex)
> > >   		fec_ptp_start_cyclecounter(ndev);
> > > +	/* Restart PPS if needed */
> > > +	if (fep->pps_enable) {
> > > +		/* Clear flag so fec_ptp_enable_pps() doesn't return immediately */
> > > +		fep->pps_enable = 0;
> > 
> > If reset causes PPS to stop, maybe it would be better to do this
> > unconditionally?
> 
> But if it wasn't enabled before the reset in the first place, we wouldn't
> want to unexpectedly start it.

We should decide what fep->pps_enable actually means. It should be
enabled, or it is actually enabled? Then it becomes clear if the reset
function should clear it to reflect the hardware, or if the
fec_ptp_enable_pps() should not be looking at it, and needs to read
the status from the hardware.

> > 	fep->pps_enable = 0;
> > 	fep->ptp_caps.enable(&fep->ptp_caps, &ptp_rq, 1);
> > 
> > > +	if (fep->bufdesc_ex)
> > > +		ecntl |= (1 << 4);
> > 
> > Please replace (1 << 4) with a #define to make it clear what this is doing.
> 
> I took it from the original source, line 1138 as of commit #504148f. It is
> the EN1588 bit by the way. I shall replace it with a #define in both places
> then. Though the code is riddled with other magic numbers without
> explanation, and I probably won't be bothered to fix them all.

Yes, i understand. It just makes it easier to review if you fixup
parts of the code you are changing.

> > So you re-start PPS in stop()? Should it keep outputting when the
> > interface is down?
> 
> Yes. We use PPS to synchronize devices on a common backplane. We use PTP to
> sync this PPS to a master clock. But if PTP sync drops out, we wouldn't want
> the backplane-level synchronization to fail. The PPS needs to stay on as
> long as userspace *explicitly* disables it, regardless of what happens to
> the link.

We need the PTP Maintainers view on that. I don't know if that is
normal or not.

> > Also, if it is always outputting, don't you need to stop it in
> > fec_drv_remove(). You probably don't want to still going after the
> > driver is unloaded.
> 
> Good point, that is one exception we could make to the above statement
> (though even in this case, userspace *really* should disable PPS before
> unloading the module).

Never trust userspace. Ever.

      Andrew

^ permalink raw reply

* [PATCH] dpaa2-eth: trace the allocated address instead of page struct
From: Chen Lin @ 2022-08-10 23:29 UTC (permalink / raw)
  To: ioana.ciornei
  Cc: davem, edumazet, kuba, pabeni, netdev, linux-kernel, yi.liu,
	Chen Lin, Chen Lin

Follow the commit 27c874867c4(dpaa2-eth: Use a single page per Rx buffer),
we should trace the allocated address instead of page struct.

Signed-off-by: Chen Lin <chen.lin5@zte.com.cn>
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index cd9ec8052..75d515726 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -1660,8 +1660,8 @@ static int dpaa2_eth_add_bufs(struct dpaa2_eth_priv *priv,
 		buf_array[i] = addr;
 
 		/* tracing point */
-		trace_dpaa2_eth_buf_seed(priv->net_dev,
-					 page, DPAA2_ETH_RX_BUF_RAW_SIZE,
+		trace_dpaa2_eth_buf_seed(priv->net_dev, page_address(page),
+					 DPAA2_ETH_RX_BUF_RAW_SIZE,
 					 addr, priv->rx_buf_size,
 					 bpid);
 	}
-- 
2.25.1


^ permalink raw reply related

* Re: [RFC PATCH net-next] docs: net: add an explanation of VF (and other) Representors
From: Alexander Duyck @ 2022-08-10 22:58 UTC (permalink / raw)
  To: Edward Cree
  Cc: Jakub Kicinski, ecree, netdev, davem, pabeni, edumazet, corbet,
	linux-doc, linux-net-drivers, Jacob Keller, Jesse Brandeburg,
	Michael Chan, Andy Gospodarek, Saeed Mahameed, Jiri Pirko,
	Shannon Nelson, Simon Horman
In-Reply-To: <cccb1511-3200-d5aa-8872-804f0d7f43a8@gmail.com>

On Wed, Aug 10, 2022 at 12:21 PM Edward Cree <ecree.xilinx@gmail.com> wrote:
>
> On 10/08/2022 18:58, Jakub Kicinski wrote:
> > On Wed, 10 Aug 2022 17:02:33 +0100 Edward Cree wrote:
> >> On 09/08/2022 04:41, Jakub Kicinski wrote:
> >>> I'd use "host PF", somehow that makes most sense to me.
> >>
> >> Not sure about that, I've seen "host" used as antonym of "SoC", so
> >>  if the device is configured with the SoC as the admin this could
> >>  confuse people.
> >
> > In the literal definition of the word "host" it is the entity which
> > "owns the place".
>
> Sure, but as an application of that, people talk about e.g. "host"
>  and "device" ends of a bus, DMA transfer, etc.  As a result of which
>  "host" has come to mean "computer; server; the big rack-mounted box
>  you plug cards into".
> A connotation which is unfortunate once a single device can live on
>  two separate PCIe hierarchies, connected to two computers each with
>  its own hostname, and the one which owns the device is the cluster
>  of embedded CPUs inside the card, rather than the big metal box.

I agree that "host" isn't going to work as a multi-host capable device
might end up having only one "host" that can actually handle the
configuration of the switch for the entire device. So then you have
different types of "host" interfaces.

> >> I think whatever term we settle on, this document might need to
> >>  have a 'Definitions' section to make it clear :S
> >
> > Ack, to perhaps clarify my concern further, I've seen the term
> > "management PF" refer to a PF which is not a netdev PF, it only
> > performs management functions.
>
> Yeah, I saw that interpretation as soon as you queried it.  I agree
>  we probably can't use "management PF".

One thing we may want to think about is looking more at "interfaces"
rather than "devices" or "functions". Essentially a PF is a "Host
Network Interface", a VF or sub-function would be a "Virtual Network
Interface", and an external port would be an "External/Uplink
Interface". Then we have a set of "interfaces" which would allow us to
get away from confusing networking and PCI bus topology where we also
have functions that are present on the device that may not expose
networking interfaces and provide control only. In addition something
like a VNI is more extensible so if we start getting into some other
new virtualization option in the future we are not stuck having to go
through and add yet more documentation to describe it all.

> > So a perfect term would describe the privilege
> > not the function (as the primary function of such PF should still
> > networking).
>
> I'm probably gonna get shot for suggesting this, but how about
>  "master PF"?

Usually with "master" you are talking about something like a bus. It
also occurs to me that the use of PF is assuming a single PCIe
function dedicated to performing this role. With sub-functions
floating around I could easily see a PF getting partitioned to
dedicate queues to handling switchdev operations while still allowing
other networking to pass over the original network interface. Then the
question is which one is the PF and which one is the subfunction.

I'd be more a fan of sticking with the "interface" naming and
describing what the interface would be used for. The first thought
that comes to mind is to just refer to the configuration interface as
a "NIC" since that would be the "Network Interface Controller",
however I could see how that could easily be confusing since that is
the PCI description for the device. Maybe something like a "Controller
Interface", "CI", would make sense since it seems like OVS uses
"Controller" to describe the instance that programs the flows, so we
could use similar terminology.

^ permalink raw reply

* Re: [PATCH net-next] tcp: Make SYN ACK RTO tunable by BPF programs with TFO
From: Martin KaFai Lau @ 2022-08-10 22:30 UTC (permalink / raw)
  To: Jie Meng; +Cc: netdev, bpf
In-Reply-To: <20220806000635.472853-1-jmeng@fb.com>

On Fri, Aug 05, 2022 at 05:06:35PM -0700, Jie Meng wrote:
> Instead of the hardcoded TCP_TIMEOUT_INIT, this diff calls tcp_timeout_init
> to initiate req->timeout like the non TFO SYN ACK case.
> 
> Tested using the following packetdrill script, on a host with a BPF
> program that sets the initial connect timeout to 10ms.
Please also cc the bpf mailing list.

^ permalink raw reply

* [PATCH] mt76: connac: fix in comment
From: Ruffalo Lavoisier @ 2022-08-10 22:04 UTC (permalink / raw)
  To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
	Sean Wang, Kalle Valo, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Matthias Brugger
  Cc: Ruffalo Lavoisier, linux-wireless, netdev, linux-arm-kernel,
	linux-mediatek, linux-kernel

Correct spelling on 'transmitted' in comment

Signed-off-by: Ruffalo Lavoisier <RuffaloLavoisier@gmail.com>
---
 drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
index 9b17bd97ec09..972190f7b81f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
@@ -2648,7 +2648,7 @@ int mt76_connac_mcu_add_key(struct mt76_dev *dev, struct ieee80211_vif *vif,
 }
 EXPORT_SYMBOL_GPL(mt76_connac_mcu_add_key);
 
-/* SIFS 20us + 512 byte beacon tranmitted by 1Mbps (3906us) */
+/* SIFS 20us + 512 byte beacon transmitted by 1Mbps (3906us) */
 #define BCN_TX_ESTIMATE_TIME (4096 + 20)
 void mt76_connac_mcu_bss_ext_tlv(struct sk_buff *skb, struct mt76_vif *mvif)
 {
-- 
2.25.1


^ permalink raw reply related

* Re: [PATCH -next 1/2] brcmfmac: Support multiple AP interfaces and fix STA disconnection issue
From: Franky Lin @ 2022-08-10 21:32 UTC (permalink / raw)
  To: Alvin Šipraga
  Cc: Arend van Spriel, Hante Meuleman, Kalle Valo, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Soontak Lee,
	Chi-Hsien Lin, Ahmad Fatoum, Alvin Šipraga, linux-wireless,
	brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel
In-Reply-To: <20220722122956.841786-2-alvin@pqrs.dk>

[-- Attachment #1: Type: text/plain, Size: 8190 bytes --]

On Fri, Jul 22, 2022 at 5:30 AM Alvin Šipraga <alvin@pqrs.dk> wrote:
>
> From: Soontak Lee <soontak.lee@cypress.com>
>
> Support multiple AP interfaces for STA + AP + AP usecase.

AFAIK, Broadcom's fullmac firmware doesn't support such 2AP + 1STA use case.

> And fix STA disconnection when deactivating AP interface.
>
> Signed-off-by: Soontak Lee <soontak.lee@cypress.com>
> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c    | 48 +++++++++++++++----
>  .../broadcom/brcm80211/brcmfmac/cfg80211.h    |  1 +
>  .../broadcom/brcm80211/brcmfmac/common.c      |  5 ++
>  3 files changed, 44 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 3ae6779fe153..856fd5516ddf 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -4747,6 +4747,7 @@ brcmf_cfg80211_start_ap(struct wiphy *wiphy, struct net_device *ndev,
>                   settings->inactivity_timeout);
>         dev_role = ifp->vif->wdev.iftype;
>         mbss = ifp->vif->mbss;
> +       brcmf_dbg(TRACE, "mbss %s\n", mbss ? "enabled" : "disabled");
>
>         /* store current 11d setting */
>         if (brcmf_fil_cmd_int_get(ifp, BRCMF_C_GET_REGULATORY,
> @@ -4961,6 +4962,9 @@ brcmf_cfg80211_start_ap(struct wiphy *wiphy, struct net_device *ndev,
>         if ((err) && (!mbss)) {
>                 brcmf_set_mpc(ifp, 1);
>                 brcmf_configure_arp_nd_offload(ifp, true);
> +       } else {
> +               cfg->num_softap++;
> +               brcmf_dbg(TRACE, "Num of SoftAP %u\n", cfg->num_softap);
>         }
>         return err;
>  }
> @@ -4975,6 +4979,7 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct net_device *ndev,
>         s32 err;
>         struct brcmf_fil_bss_enable_le bss_enable;
>         struct brcmf_join_params join_params;
> +       s32 apsta = 0;
>
>         brcmf_dbg(TRACE, "Enter\n");
>
> @@ -4983,6 +4988,27 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct net_device *ndev,
>                 /* first to make sure they get processed by fw. */
>                 msleep(400);
>
> +               cfg->num_softap--;
> +
> +               /* Clear bss configuration and SSID */
> +               bss_enable.bsscfgidx = cpu_to_le32(ifp->bsscfgidx);
> +               bss_enable.enable = cpu_to_le32(0);
> +               err = brcmf_fil_iovar_data_set(ifp, "bss", &bss_enable,
> +                                              sizeof(bss_enable));
> +               if (err < 0)
> +                       brcmf_err("bss_enable config failed %d\n", err);
> +
> +               memset(&join_params, 0, sizeof(join_params));
> +               err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SET_SSID,
> +                                            &join_params, sizeof(join_params));
> +               if (err < 0)
> +                       bphy_err(drvr, "SET SSID error (%d)\n", err);
> +
> +               if (cfg->num_softap) {
> +                       brcmf_dbg(TRACE, "Num of SoftAP %u\n", cfg->num_softap);
> +                       return 0;
> +               }
> +
>                 if (profile->use_fwauth != BIT(BRCMF_PROFILE_FWAUTH_NONE)) {
>                         if (profile->use_fwauth & BIT(BRCMF_PROFILE_FWAUTH_PSK))
>                                 brcmf_set_pmk(ifp, NULL, 0);
> @@ -5000,17 +5026,18 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct net_device *ndev,
>                 if (ifp->bsscfgidx == 0)
>                         brcmf_fil_iovar_int_set(ifp, "closednet", 0);
>
> -               memset(&join_params, 0, sizeof(join_params));
> -               err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SET_SSID,
> -                                            &join_params, sizeof(join_params));
> -               if (err < 0)
> -                       bphy_err(drvr, "SET SSID error (%d)\n", err);
> -               err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_DOWN, 1);
> -               if (err < 0)
> -                       bphy_err(drvr, "BRCMF_C_DOWN error %d\n", err);
> -               err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
> +               err = brcmf_fil_iovar_int_get(ifp, "apsta", &apsta);
>                 if (err < 0)
> -                       bphy_err(drvr, "setting AP mode failed %d\n", err);
> +                       brcmf_err("wl apsta failed (%d)\n", err);
> +
> +               if (!apsta) {
> +                       err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_DOWN, 1);
> +                       if (err < 0)
> +                               bphy_err(drvr, "BRCMF_C_DOWN error %d\n", err);
> +                       err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
> +                       if (err < 0)
> +                               bphy_err(drvr, "Set AP mode error %d\n", err);
> +               }
>                 if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
>                         brcmf_fil_iovar_int_set(ifp, "mbss", 0);
>                 brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
> @@ -7641,6 +7668,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>
>         cfg->wiphy = wiphy;
>         cfg->pub = drvr;
> +       cfg->num_softap = 0;
>         init_vif_event(&cfg->vif_event);
>         INIT_LIST_HEAD(&cfg->vif_list);
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> index e90a30808c22..e4ebc2fa6ebb 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> @@ -371,6 +371,7 @@ struct brcmf_cfg80211_info {
>         struct brcmf_cfg80211_wowl wowl;
>         struct brcmf_pno_info *pno;
>         u8 ac_priority[MAX_8021D_PRIO];
> +       u8 num_softap;
>  };
>
>  /**
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index fe01da9e620d..83e023a22f9b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -303,6 +303,11 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>                 brcmf_dbg(INFO, "CLM version = %s\n", clmver);
>         }
>
> +       /* set apsta */
> +       err = brcmf_fil_iovar_int_set(ifp, "apsta", 1);
> +       if (err)
> +               brcmf_info("failed setting apsta, %d\n", err);
> +

I do not understand why entering apsta mode by default. The mode is
supposed to be enabled only when an AP interface is created in
brcmf_cfg80211_start_ap. I think one of the side effects of apsta mode
is that memory footprint significantly increases. It should remain
disabled for STA only mode (which is the major use case) for better
performance.

Regards,
- Franky

>         /* set mpc */
>         err = brcmf_fil_iovar_int_set(ifp, "mpc", 1);
>         if (err) {
> --
> 2.37.0
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4203 bytes --]

^ permalink raw reply

* Re: [PATCH v2] net:bonding:support balance-alb interface with vlan to bridge
From: Jay Vosburgh @ 2022-08-10 21:09 UTC (permalink / raw)
  To: patchwork-bot+netdevbpf
  Cc: Sun Shouxin, vfalico, andy, davem, edumazet, kuba, pabeni, netdev,
	linux-kernel, razor, huyd12
In-Reply-To: <166013581540.3703.5149069391225440733.git-patchwork-notify@kernel.org>

patchwork-bot+netdevbpf@kernel.org wrote:

>Hello:
>
>This patch was applied to netdev/net.git (master)
>by David S. Miller <davem@davemloft.net>:
>
>On Mon,  8 Aug 2022 23:21:03 -0700 you wrote:
>> In my test, balance-alb bonding with two slaves eth0 and eth1,
>> and then Bond0.150 is created with vlan id attached bond0.
>> After adding bond0.150 into one linux bridge, I noted that Bond0,
>> bond0.150 and  bridge were assigned to the same MAC as eth0.
>> Once bond0.150 receives a packet whose dest IP is bridge's
>> and dest MAC is eth1's, the linux bridge will not match
>> eth1's MAC entry in FDB, and not handle it as expected.
>> The patch fix the issue, and diagram as below:
>> 
>> [...]
>
>Here is the summary with links:
>  - [v2] net:bonding:support balance-alb interface with vlan to bridge
>    https://git.kernel.org/netdev/net/c/d5410ac7b0ba
>
>You are awesome, thank you!

	There looks to be a reference count leak in the existing patch
(ip_dev_find acquires a reference that is not released).  I.e., it needs
something like:

diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 60cb9a0225aa..b9dbad3a8af8 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -668,8 +668,11 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond)
 
 	dev = ip_dev_find(dev_net(bond->dev), arp->ip_src);
 	if (dev) {
-		if (netif_is_bridge_master(dev))
+		if (netif_is_bridge_master(dev)) {
+			dev_put(dev);
 			return NULL;
+		}
+		dev_put(dev);
 	}
 
 	if (arp->op_code == htons(ARPOP_REPLY)) {

	I haven't tested this, but it seems correct.  Comments?

	I'll create a formal submission here in a bit.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

^ permalink raw reply related

* Re: [PATCH] Bluetooth: Honor name resolve evt regardless of discov state
From: Luiz Augusto von Dentz @ 2022-08-10 19:58 UTC (permalink / raw)
  To: Archie Pusaka
  Cc: linux-bluetooth, Marcel Holtmann, CrosBT Upstreaming,
	Archie Pusaka, Ying Hsu, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Johan Hedberg, Paolo Abeni,
	Linux Kernel Mailing List, open list:NETWORKING [GENERAL]
In-Reply-To: <20220810164627.1.Id730b98f188a504d9835b96ddcbc83d49a70bb36@changeid>

Hi Archie,

On Wed, Aug 10, 2022 at 1:47 AM Archie Pusaka <apusaka@google.com> wrote:
>
> From: Archie Pusaka <apusaka@chromium.org>
>
> Currently, we don't update the name resolving cache when receiving
> a name resolve event if the discovery phase is not in the resolving
> stage.
>
> However, if the user connect to a device while we are still resolving
> remote name for another device, discovery will be stopped, and because
> we are no longer in the discovery resolving phase, the corresponding
> remote name event will be ignored, and thus the device being resolved
> will stuck in NAME_PENDING state.
>
> If discovery is then restarted and then stopped, this will cause us to
> try cancelling the name resolve of the same device again, which is
> incorrect and might upset the controller.

Please add the Fixes tag.

> Signed-off-by: Archie Pusaka <apusaka@chromium.org>
> Reviewed-by: Ying Hsu <yinghsu@chromium.org>
>
> ---
> The following steps are performed:
>     (1) Prepare 2 classic peer devices that needs RNR. Put device A
>         closer to DUT and device B (much) farther from DUT.
>     (2) Remove all cache and previous connection from DUT
>     (3) Put both peers into pairing mode, then start scanning on DUT
>     (4) After ~8 sec, turn off peer B.
>     *This is done so DUT can discover peer B (discovery time is 10s),
>     but it hasn't started RNR. Peer is turned off to buy us the max
>     time in the RNR phase (5s).
>     (5) Immediately as device A is shown on UI, click to connect.
>     *We thus know that the DUT is in the RNR phase and trying to
>     resolve the name of peer B when we initiate connection to peer A.
>     (6) Forget peer A.
>     (7) Restart scan and stop scan.
>     *Before the CL, stop scan is broken because we will try to cancel
>     a nonexistent RNR
>     (8) Restart scan again. Observe DUT can scan normally.
>
>
>  net/bluetooth/hci_event.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 395c6479456f..95e145e278c9 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2453,6 +2453,16 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
>             !test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags))
>                 mgmt_device_connected(hdev, conn, name, name_len);
>
> +       e = hci_inquiry_cache_lookup_resolve(hdev, bdaddr, NAME_PENDING);
> +
> +       if (e) {
> +               list_del(&e->list);
> +
> +               e->name_state = name ? NAME_KNOWN : NAME_NOT_KNOWN;
> +               mgmt_remote_name(hdev, bdaddr, ACL_LINK, 0x00, e->data.rssi,
> +                                name, name_len);
> +       }
> +
>         if (discov->state == DISCOVERY_STOPPED)
>                 return;
>
> @@ -2462,7 +2472,6 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
>         if (discov->state != DISCOVERY_RESOLVING)
>                 return;
>
> -       e = hci_inquiry_cache_lookup_resolve(hdev, bdaddr, NAME_PENDING);
>         /* If the device was not found in a list of found devices names of which
>          * are pending. there is no need to continue resolving a next name as it
>          * will be done upon receiving another Remote Name Request Complete
> @@ -2470,12 +2479,6 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
>         if (!e)
>                 return;
>
> -       list_del(&e->list);
> -
> -       e->name_state = name ? NAME_KNOWN : NAME_NOT_KNOWN;
> -       mgmt_remote_name(hdev, bdaddr, ACL_LINK, 0x00, e->data.rssi,
> -                        name, name_len);
> -
>         if (hci_resolve_next_name(hdev))
>                 return;
>
> --
> 2.37.1.595.g718a3a8f04-goog
>


-- 
Luiz Augusto von Dentz

^ permalink raw reply

* Re: [PATCH net-next] net: phy: realtek: add support for RTL8821F(D)(I)-VD-CG
From: Heiner Kallweit @ 2022-08-10 19:54 UTC (permalink / raw)
  To: wei.fang, andrew, linux, davem, edumazet, kuba, pabeni, netdev
  Cc: xiaoning.wang
In-Reply-To: <20220810173733.795897-1-wei.fang@nxp.com>

On 10.08.2022 19:37, wei.fang@nxp.com wrote:
> From: Clark Wang <xiaoning.wang@nxp.com>
> 
> RTL8821F(D)(I)-VD-CG is the pin-to-pin upgrade chip from
> RTL8821F(D)(I)-CG.
> 

Don't you mean 8211 instead of 8821 here?

> Add new PHY ID for this chip.
> It does not support RTL8211F_PHYCR2 anymore, so remove the w/r operation
> of this register.
> 
> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
> ---
>  drivers/net/phy/realtek.c | 48 +++++++++++++++++++++++++++++----------
>  1 file changed, 36 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index a5671ab896b3..bfde22dc85f5 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -70,6 +70,7 @@
>  #define RTLGEN_SPEED_MASK			0x0630
>  
>  #define RTL_GENERIC_PHYID			0x001cc800
> +#define RTL_8211FVD_PHYID			0x001cc878
>  
>  MODULE_DESCRIPTION("Realtek PHY driver");
>  MODULE_AUTHOR("Johnson Leung");
> @@ -80,6 +81,11 @@ struct rtl821x_priv {
>  	u16 phycr2;
>  };
>  
> +static bool is_rtl8211fvd(u32 phy_id)

Better add a has_phycr2 to struct rtl821x_priv. Then you have:

if (priv->has_phycr2)
	do_something_with(priv->phycr2);

> +{
> +	return phy_id == RTL_8211FVD_PHYID;
> +}
> +
>  static int rtl821x_read_page(struct phy_device *phydev)
>  {
>  	return __phy_read(phydev, RTL821x_PAGE_SELECT);
> @@ -94,6 +100,7 @@ static int rtl821x_probe(struct phy_device *phydev)
>  {
>  	struct device *dev = &phydev->mdio.dev;
>  	struct rtl821x_priv *priv;
> +	u32 phy_id = phydev->drv->phy_id;
>  	int ret;
>  
>  	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -108,13 +115,15 @@ static int rtl821x_probe(struct phy_device *phydev)
>  	if (of_property_read_bool(dev->of_node, "realtek,aldps-enable"))
>  		priv->phycr1 |= RTL8211F_ALDPS_PLL_OFF | RTL8211F_ALDPS_ENABLE | RTL8211F_ALDPS_XTAL_OFF;
>  
> -	ret = phy_read_paged(phydev, 0xa43, RTL8211F_PHYCR2);
> -	if (ret < 0)
> -		return ret;
> +	if (!is_rtl8211fvd(phy_id)) {
> +		ret = phy_read_paged(phydev, 0xa43, RTL8211F_PHYCR2);
> +		if (ret < 0)
> +			return ret;
>  
> -	priv->phycr2 = ret & RTL8211F_CLKOUT_EN;
> -	if (of_property_read_bool(dev->of_node, "realtek,clkout-disable"))
> -		priv->phycr2 &= ~RTL8211F_CLKOUT_EN;
> +		priv->phycr2 = ret & RTL8211F_CLKOUT_EN;
> +		if (of_property_read_bool(dev->of_node, "realtek,clkout-disable"))
> +			priv->phycr2 &= ~RTL8211F_CLKOUT_EN;
> +	}
>  
>  	phydev->priv = priv;
>  
> @@ -333,6 +342,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
>  {
>  	struct rtl821x_priv *priv = phydev->priv;
>  	struct device *dev = &phydev->mdio.dev;
> +	u32 phy_id = phydev->drv->phy_id;
>  	u16 val_txdly, val_rxdly;
>  	int ret;
>  
> @@ -400,12 +410,14 @@ static int rtl8211f_config_init(struct phy_device *phydev)
>  			val_rxdly ? "enabled" : "disabled");
>  	}
>  
> -	ret = phy_modify_paged(phydev, 0xa43, RTL8211F_PHYCR2,
> -			       RTL8211F_CLKOUT_EN, priv->phycr2);
> -	if (ret < 0) {
> -		dev_err(dev, "clkout configuration failed: %pe\n",
> -			ERR_PTR(ret));
> -		return ret;
> +	if (!is_rtl8211fvd(phy_id)) {
> +		ret = phy_modify_paged(phydev, 0xa43, RTL8211F_PHYCR2,
> +				       RTL8211F_CLKOUT_EN, priv->phycr2);
> +		if (ret < 0) {
> +			dev_err(dev, "clkout configuration failed: %pe\n",
> +				ERR_PTR(ret));
> +			return ret;
> +		}
>  	}
>  
>  	return genphy_soft_reset(phydev);
> @@ -923,6 +935,18 @@ static struct phy_driver realtek_drvs[] = {
>  		.resume		= rtl821x_resume,
>  		.read_page	= rtl821x_read_page,
>  		.write_page	= rtl821x_write_page,
> +	}, {
> +		PHY_ID_MATCH_EXACT(RTL_8211FVD_PHYID),
> +		.name		= "RTL8211F-VD Gigabit Ethernet",
> +		.probe		= rtl821x_probe,
> +		.config_init	= &rtl8211f_config_init,
> +		.read_status	= rtlgen_read_status,
> +		.config_intr	= &rtl8211f_config_intr,
> +		.handle_interrupt = rtl8211f_handle_interrupt,
> +		.suspend	= genphy_suspend,
> +		.resume		= rtl821x_resume,
> +		.read_page	= rtl821x_read_page,
> +		.write_page	= rtl821x_write_page,
>  	}, {
>  		.name		= "Generic FE-GE Realtek PHY",
>  		.match_phy_device = rtlgen_match_phy_device,

And by the way, net-next is closed currently.

^ permalink raw reply

* Re: [PATCH] net: dsa: mv88e6060: report max mtu 1536
From: Vladimir Oltean @ 2022-08-10 19:38 UTC (permalink / raw)
  To: Sergei Antonov; +Cc: netdev, Florian Fainelli
In-Reply-To: <CABikg9yVpQaU_cf+iuPn5EV0Hn9ydwigdmZrrdStq7y-y+=YsQ@mail.gmail.com>

On Wed, Aug 10, 2022 at 06:56:25PM +0300, Sergei Antonov wrote:
> > reg = <16> for switch@0? Something is wrong, probably switch@0.
> 
> Thanks for noticing it.
> In my case the device addresses are:
>   PHY Registers - 0x10-0x14
>   Switch Core Registers - 0x18-0x1D
>   Switch Global Registers - 0x1F
> I renamed switch@0 to switch@10 and made reg hexadecimal for clarity:
> "reg = <0x10>". It works, see below for more information on testing.
> Should I leave it like so?

Should be fine like that. I think Marvell switches tend to have this
habit of occupying multiple PHY addresses, and our DT bindings want to
see the first one.

> > The bug seems to have been introduced by commit 0abfd494deef ("net: dsa:
> > use dedicated CPU port"), because, although before we'd be uselessly
> > programming the port VLAN for a disabled port, now in doing so, we
> > dereference a NULL pointer.
> 
> The suggested fix with dsa_is_unused_port() works. I tested it on the
> 'netdev/net.git' repo, see below. Should I submit it as a patch
> (Fixes: 0abfd494deef)?

Yes. See the section that talks about "git log -1 --pretty=fixes" in
process/submitting-patches.rst for how the Fixes tag should actually
look like.

I thought about whether dsa_is_unused_port() is sufficient, since
theoretically dsa_is_dsa_port() is also a possibility which isn't
covered by the check. But I rechecked and it appears that the Marvell
6060 doesn't support cascade ports, so we should be fine with just that.

> So I tested "dsa_is_unused_port()" and "switch@10" fixes with
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> What I did after system boot-up:
> 
> ~ # dmesg | grep mv88
> [    7.187296] mv88e6060 92000090.mdio--1-mii:10: switch Marvell 88E6060 (B0) detected
> [    8.325712] mv88e6060 92000090.mdio--1-mii:10: switch Marvell 88E6060 (B0) detected
> [    9.190299] mv88e6060 92000090.mdio--1-mii:10 lan2 (uninitialized): PHY [dsa-0.0:02] driver [Generic PHY] (irq=POLL)
> 
> ~ # ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST> mtu 1504 qdisc noop qlen 1000
>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

The DSA master is super odd for starting with an all-zero MAC address.
What driver handles this part? Normally, drivers are expected to work
with a MAC address provided by the firmware (of_get_mac_address or
other, perhaps proprietary, means) and fall back to eth_random_addr()
if that is missing.

> 3: lan2@eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop qlen 1000
>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Here DSA inherits the MAC address of the master. It does this by default
in dsa_slave_create() -> eth_hw_addr_inherit(). If the OF node for the
DSA port has its own MAC address, that will have priority over the MAC
address of the master.

> ~ # ip link set dev eth0 address 00:90:e8:00:10:03 up

This shouldn't be necessary, neither assigning a MAC address nor putting
the master up, see Documentation/networking/dsa/configuration.rst, the
master comes up automatically.

> ~ # ip a add 192.168.127.254/24 dev lan2
> 
> ~ # ip link set dev lan2 address 00:90:e8:00:10:03 up
> [   56.383801] DSA: failed to set STP state 3 (-95)

errno 95 is EOPNOTSUPP, we shouldn't warn here, I'll submit a patch for
that.

> [   56.385491] mv88e6060 92000090.mdio--1-mii:10 lan2: configuring for phy/gmii link mode
> [   58.694319] mv88e6060 92000090.mdio--1-mii:10 lan2: Link is Up - 100Mbps/Full - flow control off

The link was negotiated without flow control, so you can't test flow
control under these conditions. This depends upon what the internal PHY
of the mv88e6060 is advertising, and what the link partner is advertising.
What is advertised is a subset of what is supported (and resolved by
linkmode_resolve_pause).

I'm a bit uncertain as to what happens when the 6060 driver doesn't
validate the phylink supported mask at all (it doesn't populate the
mac_capabilities structure and it doesn't implement ds->ops->phylink_validate)
but I think what happens is that whatever the PHY supports isn't further
reduced in any way by the MAC side of things.

> [   58.699244] IPv6: ADDRCONF(NETDEV_CHANGE): lan2: link becomes ready
> 
> ~ # ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast qlen 1000
>     link/ether 00:90:e8:00:10:03 brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::290:e8ff:fe00:1003/64 scope link
>        valid_lft forever preferred_lft forever
> 3: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
>     link/ether 00:90:e8:00:10:03 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.127.254/24 scope global lan2
>        valid_lft forever preferred_lft forever
>     inet6 fe80::290:e8ff:fe00:1003/64 scope link
>        valid_lft forever preferred_lft forever
> 
> Ping, ssh, scp work.
> 
> Is it correct for eth0 and lan2@eth0 to have the same MAC?

It is not wrong, it's a configuration that many deployed DSA systems use.

> I could not make it work with different MACs.

That is a problem, and I believe it's a problem with the DSA master driver.
See, the reason it should work is this. Switch ports don't really have a
MAC address, since they forward everything and not really terminate anything.
The MAC address of a switch port is a software construct which means
that software L3 termination interfaces (of which we have one per port)
should accept packets with some known MAC DA, and drop the rest, and
everything should be fine.

There are multiple kinds of DSA tags, but 6060 uses a trailer, and this
will not shift the 'real' MAC DA of packets compared to where the DSA
master expects to see them. So if the MAC address of the DSA master is A,
the MAC address of lan2 is B, and you ping lan2 from the outside world,
the DSA master will see packets with a MAC DA of B.

So the DSA master sees packets with a MAC DA different from its own
dev->dev_addr (A) and thinks it's within its right to drop them. Except
that it isn't, because we do the following to prevent it:

(1) in case the DSA master supports IFF_UNICAST_FLT, we call dev_uc_add()
    from dsa_slave_set_mac_address() and from dsa_slave_open(), and this
    informs it of our address B.
(2) in case it doesn't support IFF_UNICAST_FLT, we just call
    dsa_master_set_promiscuity() and that should keep it promiscuous and
    it should accept packets regardless of MAC DA (that's the definition).

So you should run some tcpdump and ethtool -S on the DSA master and see
whether it receives any packets or it drops them. It's possible that
tcpdump makes packets be accepted, since it puts the interface in
promiscuous mode.

> I don't know how to test flow control. Ping, ssh, scp work even with
> mv88e6060_setup_addr() code removed. Of course, if MAC SA plays some
> role in other scenarios, let it be :).

I think it's best to leave alone things you don't really care about.
The address in mv88e6060_setup_addr() should have nothing to do with
what you really seem to want to know, just with flow control.

^ permalink raw reply

* Re: [RFC 1/1] net: move IFF_LIVE_ADDR_CHANGE to public flag
From: James Prestwood @ 2022-08-10 19:35 UTC (permalink / raw)
  To: Johannes Berg, Jakub Kicinski; +Cc: netdev
In-Reply-To: <9ec77cf1ffaa29aedd57c29ac77b525d0e700acf.camel@sipsolutions.net>

Hi Johannes,

On Wed, 2022-08-10 at 19:17 +0200, Johannes Berg wrote:
> On Wed, 2022-08-10 at 09:26 -0700, James Prestwood wrote:
> > 
> > Ok, so this is how I originally did it in those old patches:
> > 
> > https://lore.kernel.org/linux-wireless/20190913195908.7871-2-prestwoj@gmail.com/
> > 
> > i.e. remove_interface, change the mac, add_interface. 
> 
> Hah, I didn't even remember that ... sorry.

No worries, it was a long time ago.

> 
> > But before I revive those I want to make sure a flag can be
> > advertised
> > to userspace e.g. NL80211_EXT_FEATURE_LIVE_ADDRESS_CHANGE. (or
> > POWERED). Since this was the reason the patches got dropped in the
> > first place.
> > 
> 
> Well it seems that my objection then was basically that you have a
> feature flag in nl80211, but it affects an RT netlink operation ...
> which is a bit strange.
> 
> Thinking about that now, maybe it's not _that_ bad? Especially given
> that "live" can mean different things (as discussed here), and for
> wireless that doesn't necessarily mean IFF_UP, but rather something
> like
> "IFF_UP + not active".
> 
> Jakub, what do you think?
> 
> 
> (I'll also note you also have error handling problems in your patch,
> so
> if/when you revive, please take a look at handling errors from add
> and
> remove interface. Also indentation, and a comment on station/p2p-
> client
> might be good, and the scanning check is wrong, can check scan_sdata
> regardless of the iftype.)

Yep, I'll get that fixed up for v2.

Thanks,
James
> 
> johannes



^ permalink raw reply

* Re: [RFC PATCH net-next] docs: net: add an explanation of VF (and other) Representors
From: Edward Cree @ 2022-08-10 19:21 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: ecree, netdev, davem, pabeni, edumazet, corbet, linux-doc,
	linux-net-drivers, Jacob Keller, Jesse Brandeburg, Michael Chan,
	Andy Gospodarek, Saeed Mahameed, Jiri Pirko, Shannon Nelson,
	Simon Horman, Alexander Duyck
In-Reply-To: <20220810105811.6423f188@kernel.org>

On 10/08/2022 18:58, Jakub Kicinski wrote:
> On Wed, 10 Aug 2022 17:02:33 +0100 Edward Cree wrote:
>> On 09/08/2022 04:41, Jakub Kicinski wrote:
>>> I'd use "host PF", somehow that makes most sense to me.  
>>
>> Not sure about that, I've seen "host" used as antonym of "SoC", so
>>  if the device is configured with the SoC as the admin this could
>>  confuse people.
> 
> In the literal definition of the word "host" it is the entity which
> "owns the place".

Sure, but as an application of that, people talk about e.g. "host"
 and "device" ends of a bus, DMA transfer, etc.  As a result of which
 "host" has come to mean "computer; server; the big rack-mounted box
 you plug cards into".
A connotation which is unfortunate once a single device can live on
 two separate PCIe hierarchies, connected to two computers each with
 its own hostname, and the one which owns the device is the cluster
 of embedded CPUs inside the card, rather than the big metal box.

>> I think whatever term we settle on, this document might need to
>>  have a 'Definitions' section to make it clear :S
> 
> Ack, to perhaps clarify my concern further, I've seen the term
> "management PF" refer to a PF which is not a netdev PF, it only
> performs management functions.

Yeah, I saw that interpretation as soon as you queried it.  I agree
 we probably can't use "management PF".

> So a perfect term would describe the privilege
> not the function (as the primary function of such PF should still
> networking).

I'm probably gonna get shot for suggesting this, but how about
 "master PF"?

-ed

^ permalink raw reply

* Re: [PATCH v7 0/4] Implement vdpasim suspend operation
From: Michael S. Tsirkin @ 2022-08-10 19:19 UTC (permalink / raw)
  To: Eugenio Pérez
  Cc: kvm, linux-kernel, Jason Wang, virtualization, netdev, dinang,
	martinpo, Wu Zongyong, Piotr.Uminski, gautam.dawar, ecree.xilinx,
	martinh, Stefano Garzarella, pabloc, habetsm.xilinx, lvivier,
	Zhu Lingshan, tanuj.kamde, Longpeng, lulu, hanand, Parav Pandit,
	Si-Wei Liu, Eli Cohen, Xie Yongji, Zhang Min, Dan Carpenter,
	Christophe JAILLET
In-Reply-To: <20220810171512.2343333-1-eperezma@redhat.com>

On Wed, Aug 10, 2022 at 07:15:08PM +0200, Eugenio Pérez wrote:
> Implement suspend operation for vdpa_sim devices, so vhost-vdpa will offer
> that backend feature and userspace can effectively suspend the device.
> 
> This is a must before getting virtqueue indexes (base) for live migration,
> since the device could modify them after userland gets them. There are
> individual ways to perform that action for some devices
> (VHOST_NET_SET_BACKEND, VHOST_VSOCK_SET_RUNNING, ...) but there was no
> way to perform it for any vhost device (and, in particular, vhost-vdpa).
> 
> After a successful return of ioctl the device must not process more virtqueue
> descriptors. The device can answer to read or writes of config fields as if it
> were not suspended. In particular, writing to "queue_enable" with a value of 1
> will not make the device start processing virtqueue buffers.
> 
> In the future, we will provide features similar to
> VHOST_USER_GET_INFLIGHT_FD so the device can save pending operations.
> 
> Applied on top of [1] branch after removing the old commits.

Except, I can't really do this without invaliding all testing.
Can't you post an incremental patch?

> Comments are welcome.
> 
> v7:
> * Remove ioctl leftover argument and update doc accordingly.

> v6:
> * Remove the resume operation, making the ioctl simpler. We can always add
>   another ioctl for VM_STOP/VM_RESUME operation later.
> * s/stop/suspend/ to differentiate more from reset.
> * Clarify scope of the suspend operation.
> 
> v5:
> * s/not stop/resume/ in doc.
> 
> v4:
> * Replace VHOST_STOP to VHOST_VDPA_STOP in vhost ioctl switch case too.
> 
> v3:
> * s/VHOST_STOP/VHOST_VDPA_STOP/
> * Add documentation and requirements of the ioctl above its definition.
> 
> v2:
> * Replace raw _F_STOP with BIT_ULL(_F_STOP).
> * Fix obtaining of stop ioctl arg (it was not obtained but written).
> * Add stop to vdpa_sim_blk.
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> 
> Eugenio Pérez (4):
>   vdpa: Add suspend operation
>   vhost-vdpa: introduce SUSPEND backend feature bit
>   vhost-vdpa: uAPI to suspend the device
>   vdpa_sim: Implement suspend vdpa op
> 
>  drivers/vdpa/vdpa_sim/vdpa_sim.c     | 14 +++++++++++
>  drivers/vdpa/vdpa_sim/vdpa_sim.h     |  1 +
>  drivers/vdpa/vdpa_sim/vdpa_sim_blk.c |  3 +++
>  drivers/vdpa/vdpa_sim/vdpa_sim_net.c |  3 +++
>  drivers/vhost/vdpa.c                 | 35 +++++++++++++++++++++++++++-
>  include/linux/vdpa.h                 |  4 ++++
>  include/uapi/linux/vhost.h           |  9 +++++++
>  include/uapi/linux/vhost_types.h     |  2 ++
>  8 files changed, 70 insertions(+), 1 deletion(-)
> 
> -- 
> 2.31.1
> 


^ permalink raw reply

* pull-request: bpf 2022-08-10
From: Daniel Borkmann @ 2022-08-10 19:06 UTC (permalink / raw)
  To: davem; +Cc: kuba, pabeni, edumazet, daniel, ast, andrii, netdev, bpf

Hi David, hi Jakub, hi Paolo, hi Eric,

The following pull-request contains BPF updates for your *net* tree.

We've added 23 non-merge commits during the last 7 day(s) which contain
a total of 19 files changed, 424 insertions(+), 35 deletions(-).

The main changes are:

1) Several fixes for BPF map iterator such as UAFs along with selftests, from Hou Tao.

2) Fix BPF syscall program's {copy,strncpy}_from_bpfptr() to not fault, from Jinghao Jia.

3) Reject BPF syscall programs calling BPF_PROG_RUN, from Alexei Starovoitov and YiFei Zhu.

4) Fix attach_btf_obj_id info to pick proper target BTF, from Stanislav Fomichev.

5) BPF design Q/A doc update to clarify what is not stable ABI, from Paul E. McKenney.

6) Fix BPF map's prealloc_lru_pop to not reinitialize, from Kumar Kartikeya Dwivedi.

7) Fix bpf_trampoline_put to avoid leaking ftrace hash, from Jiri Olsa.

8) Fix arm64 JIT to address sparse errors around BPF trampoline, from Xu Kuohai.

9) Fix arm64 JIT to use kvcalloc instead of kcalloc for internal program address
   offset buffer, from Aijun Sun.

Please consider pulling these changes from:

  git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git

Thanks a lot!

Also thanks to reporters, reviewers and testers of commits in this pull-request:

Hao Luo, Jean-Philippe Brucker, kernel test robot, Martin KaFai Lau, Mat 
Martineau, Song Liu, YiFei Zhu, Yonghong Song

----------------------------------------------------------------

The following changes since commit 4ae97cae07e15d41e5c0ebabba64c6eefdeb0bbe:

  nfp: ethtool: fix the display error of `ethtool -m DEVNAME` (2022-08-03 19:20:54 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git 

for you to fetch changes up to e7c677bdd03d54e9a1bafcaf1faf5c573a506bba:

  Merge branch 'fixes for bpf map iterator' (2022-08-10 10:12:49 -0700)

----------------------------------------------------------------
Aijun Sun (1):
      bpf, arm64: Allocate program buffer using kvcalloc instead of kcalloc

Alexei Starovoitov (3):
      Merge branch 'Don't reinit map value in prealloc_lru_pop'
      bpf: Disallow bpf programs call prog_run command.
      Merge branch 'fixes for bpf map iterator'

Hou Tao (9):
      bpf: Acquire map uref in .init_seq_private for array map iterator
      bpf: Acquire map uref in .init_seq_private for hash map iterator
      bpf: Acquire map uref in .init_seq_private for sock local storage map iterator
      bpf: Acquire map uref in .init_seq_private for sock{map,hash} iterator
      bpf: Check the validity of max_rdwr_access for sock local storage map iterator
      bpf: Only allow sleepable program for resched-able iterator
      selftests/bpf: Add tests for reading a dangling map iter fd
      selftests/bpf: Add write tests for sk local storage map iterator
      selftests/bpf: Ensure sleepable program is rejected by hash map iter

Jinghao Jia (1):
      BPF: Fix potential bad pointer dereference in bpf_sys_bpf()

Jiri Olsa (2):
      bpf: Cleanup ftrace hash in bpf_trampoline_put
      mptcp, btf: Add struct mptcp_sock definition when CONFIG_MPTCP is disabled

Kumar Kartikeya Dwivedi (3):
      bpf: Allow calling bpf_prog_test kfuncs in tracing programs
      bpf: Don't reinit map value in prealloc_lru_pop
      selftests/bpf: Add test for prealloc_lru_pop bug

Paul E. McKenney (3):
      bpf: Update bpf_design_QA.rst to clarify that kprobes is not ABI
      bpf: Update bpf_design_QA.rst to clarify that attaching to functions is not ABI
      bpf: Update bpf_design_QA.rst to clarify that BTF_ID does not ABIify a function

Stanislav Fomichev (2):
      bpf: Use proper target btf when exporting attach_btf_obj_id
      selftests/bpf: Excercise bpf_obj_get_info_by_fd for bpf2bpf

Xu Kuohai (1):
      bpf, arm64: Fix bpf trampoline instruction endianness

 Documentation/bpf/bpf_design_QA.rst                |  25 +++++
 arch/arm64/net/bpf_jit_comp.c                      |  16 +--
 include/linux/bpfptr.h                             |   8 +-
 include/net/mptcp.h                                |   4 +
 kernel/bpf/arraymap.c                              |   6 ++
 kernel/bpf/bpf_iter.c                              |  11 +-
 kernel/bpf/hashtab.c                               |   8 +-
 kernel/bpf/syscall.c                               |  27 +++--
 kernel/bpf/trampoline.c                            |   5 +-
 net/bpf/test_run.c                                 |   1 +
 net/core/bpf_sk_storage.c                          |  12 ++-
 net/core/sock_map.c                                |  20 +++-
 tools/lib/bpf/skel_internal.h                      |   4 +-
 tools/testing/selftests/bpf/prog_tests/bpf_iter.c  | 116 ++++++++++++++++++++-
 .../selftests/bpf/prog_tests/fexit_bpf2bpf.c       |  95 +++++++++++++++++
 tools/testing/selftests/bpf/prog_tests/lru_bug.c   |  21 ++++
 .../selftests/bpf/progs/bpf_iter_bpf_hash_map.c    |   9 ++
 .../bpf/progs/bpf_iter_bpf_sk_storage_map.c        |  22 +++-
 tools/testing/selftests/bpf/progs/lru_bug.c        |  49 +++++++++
 19 files changed, 424 insertions(+), 35 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/lru_bug.c
 create mode 100644 tools/testing/selftests/bpf/progs/lru_bug.c

^ permalink raw reply

* Re: [PATCH bpf-next 00/15] bpf: Introduce selectable memcg for bpf map
From: patchwork-bot+netdevbpf @ 2022-08-10 19:00 UTC (permalink / raw)
  To: Yafang Shao
  Cc: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend,
	kpsingh, sdf, haoluo, jolsa, hannes, mhocko, roman.gushchin,
	shakeelb, songmuchun, akpm, netdev, bpf, linux-mm
In-Reply-To: <20220810151840.16394-1-laoar.shao@gmail.com>

Hello:

This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Wed, 10 Aug 2022 15:18:25 +0000 you wrote:
> On our production environment, we may load, run and pin bpf programs and
> maps in containers. For example, some of our networking bpf programs and
> maps are loaded and pinned by a process running in a container on our
> k8s environment. In this container, there're also running some other
> user applications which watch the networking configurations from remote
> servers and update them on this local host, log the error events, monitor
> the traffic, and do some other stuffs. Sometimes we may need to update
> these user applications to a new release, and in this update process we
> will destroy the old container and then start a new genration. In order not
> to interrupt the bpf programs in the update process, we will pin the bpf
> programs and maps in bpffs. That is the background and use case on our
> production environment.
> 
> [...]

Here is the summary with links:
  - [bpf-next,01/15] bpf: Remove unneeded memset in queue_stack_map creation
    https://git.kernel.org/bpf/bpf-next/c/083818156d1e
  - [bpf-next,02/15] bpf: Use bpf_map_area_free instread of kvfree
    https://git.kernel.org/bpf/bpf-next/c/8f58ee54c2ea
  - [bpf-next,03/15] bpf: Make __GFP_NOWARN consistent in bpf map creation
    https://git.kernel.org/bpf/bpf-next/c/992c9e13f593
  - [bpf-next,04/15] bpf: Use bpf_map_area_alloc consistently on bpf map creation
    https://git.kernel.org/bpf/bpf-next/c/73cf09a36bf7
  - [bpf-next,05/15] bpf: Fix incorrect mem_cgroup_put
    (no matching commit)
  - [bpf-next,06/15] bpf: Define bpf_map_{get,put}_memcg for !CONFIG_MEMCG_KMEM
    (no matching commit)
  - [bpf-next,07/15] bpf: Call bpf_map_init_from_attr() immediately after map creation
    (no matching commit)
  - [bpf-next,08/15] bpf: Save memcg in bpf_map_init_from_attr()
    (no matching commit)
  - [bpf-next,09/15] bpf: Use scoped-based charge in bpf_map_area_alloc
    (no matching commit)
  - [bpf-next,10/15] bpf: Introduce new helpers bpf_ringbuf_pages_{alloc,free}
    (no matching commit)
  - [bpf-next,11/15] bpf: Use bpf_map_kzalloc in arraymap
    (no matching commit)
  - [bpf-next,12/15] bpf: Use bpf_map_kvcalloc in bpf_local_storage
    (no matching commit)
  - [bpf-next,13/15] mm, memcg: Add new helper get_obj_cgroup_from_cgroup
    (no matching commit)
  - [bpf-next,14/15] bpf: Add return value for bpf_map_init_from_attr
    (no matching commit)
  - [bpf-next,15/15] bpf: Introduce selectable memcg for bpf map
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* Question - bind(2) to local route on main routing table
From: Dhupar, Rishi @ 2022-08-10 18:39 UTC (permalink / raw)
  To: netdev@vger.kernel.org; +Cc: Gero, Charlie

Hi,

We recently discovered an inconsistency in the behavior of bind(2) with respect to a type local route being added to the main table. 

I was able to track down the issue and it appears it was introduced in this commit[1] which merged the local and main fib tries for performance and which are then later unmerged once the RPDB is modified.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ddcf43d5d4a03ded1ee3f6b3b72a0cbed4e90b1

Synopsis: a user can bind(2) to any address within the prefix of a type local route that has been added to the main routing table

Short example on an untainted Ubuntu 22.04 machine
$ ip route add local 1.2.3.4/32 dev lo table main
$ nc -n -s 1.2.3.4 -l -p 9999                      # Succeeds
$ ip rule add table 100                            # This can be any change to RPDB
$ nc -n -s 1.2.3.4 -l -p 9999
Can't grab 1.2.3.4:9999 with bind : Cannot assign requested address

Note: This also impacts implicit bind behavior wrt to system calls such as connect(2).

Does this warrant further investigation and/or possibly a patch to disallow this behavior?

Regards,
Rishi Dhupar



^ permalink raw reply

* Re: Question: Ethernet Phy issues on Colibri IMX8X (imx8qxp) - kernel 5.19
From: Philipp Rossak @ 2022-08-10 18:40 UTC (permalink / raw)
  To: Marcel Ziswiler, linux-arm-kernel@lists.infradead.org,
	netdev@vger.kernel.org, qiangqing.zhang@nxp.com
  Cc: philipp.rossak@formulastudent.de, guoniu.zhou@nxp.com,
	aisheng.dong@nxp.com, abel.vesa@nxp.com, andrew@lunn.ch
In-Reply-To: <7d541e1dfa1e93abf901f96c60be54b01c78371c.camel@toradex.com>

Hi Marcel,

thanks!

With the removed line it is working now!

I hope there will be a mainlined solution soon.

Cheers
Philipp

On 10.08.22 10:05, Marcel Ziswiler wrote:
> Sali Philipp
> 
> On Wed, 2022-08-10 at 00:55 +0200, Philipp Rossak wrote:
>> Hi,
>>
>> I currently have a project with a Toradex Colibri IMX8X SOM board whith
>> an onboard Micrel KSZ8041NL Ethernet PHY.
>>
>> The hardware is described in the devictree properly so I expected that
>> the onboard Ethernet with the phy is working.
>>
>> Currently I'm not able to get the link up.
>>
>> I already compared it to the BSP kernel, but I didn't found anything
>> helpful. The BSP kernel is working.
>>
>> Do you know if there is something in the kernel missing and got it running?
> 
> Yes, you may just revert the following commit babfaa9556d7 ("clk: imx: scu: add more scu clocks")
> 
> Alternatively, just commenting out the following single line also helps:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/imx/clk-imx8qxp.c?h=v5.19#n172
> 
> I just found this out about two weeks ago before I went to vacation and since have to find out with NXP what
> exactly the idea of this clocking/SCFW stuff is related to our hardware.
> 
> @NXP: If any of you guys could shed some light that would be much appreciated. Thanks!
> 
>> Thanks,
>> Philipp
> 
> Cheers
> 
> Marcel

^ permalink raw reply

* [PATCH ipsec 2/2] xfrm: Skip checking of already-verified secpath entries
From: Benedict Wong @ 2022-08-10 18:22 UTC (permalink / raw)
  To: steffen.klassert, netdev; +Cc: nharold, benedictwong, lorenzo
In-Reply-To: <20220810182210.721493-1-benedictwong@google.com>

This change fixes a bug where inbound packets to nested IPsec tunnels
fails to pass policy checks due to the inner tunnel's policy checks
not having a reference to the outer policy/template. This causes the
policy check to fail, since the first entries in the secpath correlate
to the outer tunnel, while the templates being verified are for the
inner tunnel.

In order to ensure that the appropriate policy and template context is
searchable, the policy checks must be done incrementally after each
decryption step. As such, this marks secpath entries as having been
successfully matched, skipping these on subsequent policy checks.

By skipping the immediate error return in the case where the secpath
entry had previously been validated, this change allows secpath entries
that matched a policy/template previously, while still requiring that
each searched template find a match in the secpath.

For security:
- All templates must have matching secpath entries
  - Unchanged by current patch; templates that do not match any secpath
    entry still return -1. This patch simply allows skipping earlier
    blocks of verified secpath entries
- All entries (except trailing transport mode entries) must have a
  matching template
  - Unvalidated entries, including transport-mode entries still return
    the errored index if it does not match the correct template.

Test: Tested against Android Kernel Unit Tests
Signed-off-by: Benedict Wong <benedictwong@google.com>
Change-Id: Ic32831cb00151d0de2e465f18ec37d5f7b680e54
---
 include/net/xfrm.h     |  1 +
 net/xfrm/xfrm_input.c  |  3 ++-
 net/xfrm/xfrm_policy.c | 11 ++++++++++-
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index c39d910d4b45..a2f2840aba6b 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1031,6 +1031,7 @@ struct xfrm_offload {
 struct sec_path {
 	int			len;
 	int			olen;
+	int			verified_cnt;
 
 	struct xfrm_state	*xvec[XFRM_MAX_DEPTH];
 	struct xfrm_offload	ovec[XFRM_MAX_OFFLOAD_DEPTH];
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index b24df8a44585..895935077a91 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -129,6 +129,7 @@ struct sec_path *secpath_set(struct sk_buff *skb)
 	memset(sp->ovec, 0, sizeof(sp->ovec));
 	sp->olen = 0;
 	sp->len = 0;
+	sp->verified_cnt = 0;
 
 	return sp;
 }
@@ -587,7 +588,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
 
 		// If nested tunnel, check outer states before context is lost.
 		if (x->outer_mode.flags & XFRM_MODE_FLAG_TUNNEL
-				&& sp->len > 0
+				&& sp->len > sp->verified_cnt
 				&& !xfrm_policy_check(NULL, XFRM_POLICY_IN, skb, family)) {
 			goto drop;
 		}
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index f1a0bab920a5..ee620a856c6f 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3261,7 +3261,7 @@ xfrm_state_ok(const struct xfrm_tmpl *tmpl, const struct xfrm_state *x,
  */
 static inline int
 xfrm_policy_ok(const struct xfrm_tmpl *tmpl, const struct sec_path *sp, int start,
-	       unsigned short family)
+			   unsigned short family)
 {
 	int idx = start;
 
@@ -3274,6 +3274,11 @@ xfrm_policy_ok(const struct xfrm_tmpl *tmpl, const struct sec_path *sp, int star
 		if (xfrm_state_ok(tmpl, sp->xvec[idx], family))
 			return ++idx;
 		if (sp->xvec[idx]->props.mode != XFRM_MODE_TRANSPORT) {
+			if (idx < sp->verified_cnt) {
+				// Secpath entry previously verified, continue searching
+				continue;
+			}
+
 			if (start == -1)
 				start = -2-idx;
 			break;
@@ -3650,6 +3655,8 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,
 		 * Order is _important_. Later we will implement
 		 * some barriers, but at the moment barriers
 		 * are implied between each two transformations.
+		 * Skips verifying secpath entries that have already been
+		 * verified in the past.
 		 */
 		for (i = xfrm_nr-1, k = 0; i >= 0; i--) {
 			k = xfrm_policy_ok(tpp[i], sp, k, family);
@@ -3668,6 +3675,8 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,
 		}
 
 		xfrm_pols_put(pols, npols);
+		sp->verified_cnt = k;
+
 		return 1;
 	}
 	XFRM_INC_STATS(net, LINUX_MIB_XFRMINPOLBLOCK);
-- 
2.37.1.595.g718a3a8f04-goog


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox