* Re: [PATCH v2 1/3] net: phy: at803x: add QCA8084 ethernet phy support
From: Maxime Chevallier @ 2023-11-09 9:16 UTC (permalink / raw)
To: Jie Luo
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <423a3ee3-bed5-02f9-f872-7b5dba64f994@quicinc.com>
Hello,
On Thu, 9 Nov 2023 16:32:36 +0800
Jie Luo <quic_luoj@quicinc.com> wrote:
[...]
> > What I understand from this is that this PHY can be used either as a
> > switch, in which case port 4 would be connected to the host interface
> > at up to 2.5G, or as a quad-phy, but since it uses QUSGMII the link
> > speed would be limited to 1G per-port, is that correct ?
>
> When the PHY works on the interface mode QUSGMII for quad-phy, all 4
> PHYs can support to the max link speed 2.5G, actually the PHY can
> support to max link speed 2.5G for all supported interface modes
> including qusgmii and sgmii.
I'm a bit confused then, as the USGMII spec says that Quad USGMII really
is for quad 10/100/1000 speeds, using 10b/8b encoding.
Aren't you using the USXGMII mode instead, which can convey 4 x 2.5Gbps
with 66b/64b encoding ?
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH iwl-net] i40e: Fix waiting for queues of all VSIs to be disabled
From: Wojciech Drewek @ 2023-11-09 9:20 UTC (permalink / raw)
To: Ivan Vecera, intel-wired-lan
Cc: Jacob Keller, Jesse Brandeburg, Tony Nguyen, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Kirsher,
Neerav Parikh, open list:NETWORKING DRIVERS, open list
In-Reply-To: <20231108160104.86140-1-ivecera@redhat.com>
On 08.11.2023 17:01, Ivan Vecera wrote:
> The function i40e_pf_wait_queues_disabled() iterates all PF's VSIs
> up to 'pf->hw.func_caps.num_vsis' but this is incorrect because
> the real number of VSIs can be up to 'pf->num_alloc_vsi' that
> can be higher. Fix this loop.
>
> Fixes: 69129dc39fac ("i40e: Modify Tx disable wait flow in case of DCB reconfiguration")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Thanks Ivan!
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 6a2907674583..de19d753ba83 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -5340,7 +5340,7 @@ static int i40e_pf_wait_queues_disabled(struct i40e_pf *pf)
> {
> int v, ret = 0;
>
> - for (v = 0; v < pf->hw.func_caps.num_vsis; v++) {
> + for (v = 0; v < pf->num_alloc_vsi; v++) {
> if (pf->vsi[v]) {
> ret = i40e_vsi_wait_queues_disabled(pf->vsi[v]);
> if (ret)
^ permalink raw reply
* Re: [PATCH net-next 04/15] net: page_pool: id the page pools
From: Ilias Apalodimas @ 2023-11-09 9:21 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, edumazet, pabeni, almasrymina, hawk
In-Reply-To: <20231024160220.3973311-5-kuba@kernel.org>
On Tue, 24 Oct 2023 at 19:02, Jakub Kicinski <kuba@kernel.org> wrote:
>
> To give ourselves the flexibility of creating netlink commands
> and ability to refer to page pool instances in uAPIs create
> IDs for page pools.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> include/net/page_pool/types.h | 4 ++++
> net/core/Makefile | 2 +-
> net/core/page_pool.c | 21 +++++++++++++++-----
> net/core/page_pool_priv.h | 9 +++++++++
> net/core/page_pool_user.c | 36 +++++++++++++++++++++++++++++++++++
> 5 files changed, 66 insertions(+), 6 deletions(-)
> create mode 100644 net/core/page_pool_priv.h
> create mode 100644 net/core/page_pool_user.c
>
[...]
> +int page_pool_list(struct page_pool *pool)
> +{
> + static u32 id_alloc_next;
> + int err;
> +
> + mutex_lock(&page_pools_lock);
> + err = xa_alloc_cyclic(&page_pools, &pool->user.id, pool, xa_limit_32b,
> + &id_alloc_next, GFP_KERNEL);
> + if (err < 0)
> + goto err_unlock;
A nit really, but get rid of the if/goto and just let this return err; ?
> +
> + mutex_unlock(&page_pools_lock);
> + return 0;
> +
> +err_unlock:
> + mutex_unlock(&page_pools_lock);
> + return err;
> +}
> +
> +void page_pool_unlist(struct page_pool *pool)
> +{
> + mutex_lock(&page_pools_lock);
> + xa_erase(&page_pools, pool->user.id);
> + mutex_unlock(&page_pools_lock);
> +}
> --
> 2.41.0
>
^ permalink raw reply
* Re: [RFC PATCH v3 04/12] netdev: support binding dma-buf to netdevice
From: Yunsheng Lin @ 2023-11-09 9:29 UTC (permalink / raw)
To: Mina Almasry
Cc: netdev, linux-kernel, linux-arch, linux-kselftest, linux-media,
dri-devel, linaro-mm-sig, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Jesper Dangaard Brouer,
Ilias Apalodimas, Arnd Bergmann, David Ahern, Willem de Bruijn,
Shuah Khan, Sumit Semwal, Christian König, Shakeel Butt,
Jeroen de Borst, Praveen Kaligineedi, Willem de Bruijn,
Kaiyuan Zhang
In-Reply-To: <CAHS8izMXkaGE_jqYJJk9KpfxWEYDu95XAJNqajws57QWV2yRJQ@mail.gmail.com>
On 2023/11/9 10:22, Mina Almasry wrote:
> On Tue, Nov 7, 2023 at 7:40 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2023/11/8 5:59, Mina Almasry wrote:
>>> On Mon, Nov 6, 2023 at 11:46 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>>>
>>>> On 2023/11/6 10:44, Mina Almasry wrote:
>>>>> +
>>>>> +void __netdev_devmem_binding_free(struct netdev_dmabuf_binding *binding)
>>>>> +{
>>>>> + size_t size, avail;
>>>>> +
>>>>> + gen_pool_for_each_chunk(binding->chunk_pool,
>>>>> + netdev_devmem_free_chunk_owner, NULL);
>>>>> +
>>>>> + size = gen_pool_size(binding->chunk_pool);
>>>>> + avail = gen_pool_avail(binding->chunk_pool);
>>>>> +
>>>>> + if (!WARN(size != avail, "can't destroy genpool. size=%lu, avail=%lu",
>>>>> + size, avail))
>>>>> + gen_pool_destroy(binding->chunk_pool);
>>>>
>>>>
>>>> Is there any other place calling the gen_pool_destroy() when the above
>>>> warning is triggered? Do we have a leaking for binding->chunk_pool?
>>>>
>>>
>>> gen_pool_destroy BUG_ON() if it's not empty at the time of destroying.
>>> Technically that should never happen, because
>>> __netdev_devmem_binding_free() should only be called when the refcount
>>> hits 0, so all the chunks have been freed back to the gen_pool. But,
>>> just in case, I don't want to crash the server just because I'm
>>> leaking a chunk... this is a bit of defensive programming that is
>>> typically frowned upon, but the behavior of gen_pool is so severe I
>>> think the WARN() + check is warranted here.
>>
>> It seems it is pretty normal for the above to happen nowadays because of
>> retransmits timeouts, NAPI defer schemes mentioned below:
>>
>> https://lkml.kernel.org/netdev/168269854650.2191653.8465259808498269815.stgit@firesoul/
>>
>> And currently page pool core handles that by using a workqueue.
>
> Forgive me but I'm not understanding the concern here.
>
> __netdev_devmem_binding_free() is called when binding->ref hits 0.
>
> binding->ref is incremented when an iov slice of the dma-buf is
> allocated, and decremented when an iov is freed. So,
> __netdev_devmem_binding_free() can't really be called unless all the
> iovs have been freed, and gen_pool_size() == gen_pool_avail(),
> regardless of what's happening on the page_pool side of things, right?
I seems to misunderstand it. In that case, it seems to be about
defensive programming like other checking.
By looking at it more closely, it seems napi_frag_unref() call
page_pool_page_put_many() directly， which means devmem seems to
be bypassing the napi_safe optimization.
Can napi_frag_unref() reuse napi_pp_put_page() in order to reuse
the napi_safe optimization?
>
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] page-pool: device memory support
From: Yunsheng Lin @ 2023-11-09 9:30 UTC (permalink / raw)
To: Mina Almasry
Cc: netdev, linux-kernel, linux-arch, linux-kselftest, linux-media,
dri-devel, linaro-mm-sig, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Jesper Dangaard Brouer,
Ilias Apalodimas, Arnd Bergmann, David Ahern, Willem de Bruijn,
Shuah Khan, Sumit Semwal, Christian König, Shakeel Butt,
Jeroen de Borst, Praveen Kaligineedi
In-Reply-To: <CAHS8izM1P6d8jgyWE9wFJUJah2YFsjHP2uikDwA0vR=3QA+BXQ@mail.gmail.com>
On 2023/11/9 11:20, Mina Almasry wrote:
> On Wed, Nov 8, 2023 at 2:56 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> Agreed everything above is undoable.
>
>> But we might be able to do something as folio is doing now, mm subsystem
>> is still seeing 'struct folio/page', but other subsystem like slab is using
>> 'struct slab', and there is still some common fields shared between
>> 'struct folio' and 'struct slab'.
>>
>
> In my eyes this is almost exactly what I suggested in RFC v1 and got
> immediately nacked with no room to negotiate. What we did for v1 is to
> allocate struct pages for dma-buf to make dma-bufs look like struct
> page to mm subsystem. Almost exactly what you're describing above.
Maybe the above is where we have disagreement:
Do we still need make dma-bufs look like struct page to mm subsystem?
IMHO, the answer is no. We might only need to make dma-bufs look like
struct page to net stack and page pool subsystem. I think that is already
what this pacthset is trying to do, what I am suggesting is just make
it more like 'struct page' to net stack and page pool subsystem, in order
to try to avoid most of the 'if' checking in net stack and page pool
subsystem.
> It's a no-go. I don't think renaming struct page to netmem is going to
> move the needle (it also re-introduces code-churn). What I feel like I
> learnt is that dma-bufs are not struct pages and can't be made to look
> like one, I think.
>
>> As the netmem patchset, is devmem able to reuse the below 'struct netmem'
>> and rename it to 'struct page_pool_iov'?
>
> I don't think so. For the reasons above, but also practically it
> immediately falls apart. Consider this field in netmem:
>
> + * @flags: The same as the page flags. Do not use directly.
>
> dma-buf don't have or support page-flags, and making dma-buf looks
> like they support page flags or any page-like features (other than
> dma_addr) seems extremely unacceptable to mm folks.
As far as I tell, as we limit the devmem usage in netstack, the below
is the related mm function call for 'struct page' for devmem:
page_ref_*(): page->_refcount does not need changing
page_is_pfmemalloc(): which is corresponding to page->pp_magic, and
devmem provider can set/unset it in it's 'alloc_pages'
ops.
page_to_nid(): we may need to handle it differently somewhat like this
patch does as page_to_nid() may has different implementation
based on different configuration.
page_pool_iov_put_many(): as mentioned in other thread, if net stack is not
calling page_pool_page_put_many() directly, we
can reuse napi_pp_put_page() for devmem too, and
handle the special case for devmem in 'release_page'
ops.
>
>> So that 'struct page' for normal
>> memory and 'struct page_pool_iov' for devmem share the common fields used
>> by page pool and net stack?
>
> Are you suggesting that we'd cast a netmem* to a page* and call core
> mm APIs on it? It's basically what was happening with RFC v1, where
> things that are not struct pages were made to look like struct pages.
>
> Also, there isn't much upside for what you're suggesting, I think. For
> example I can align the refcount variable in struct page_pool_iov with
> the refcount in struct page so that this works:
>
> put_page((struct page*)ppiov);
>
> but it's a disaster. Because put_page() will call __put_page() if the
> page is freed, and __put_page() will try to return the page to the
> buddy allocator!
As what I suggested above, Can we handle this in devmem provider's
'release_page' ops instead of calling put_page() directly as for devmem.
>
>> And we might be able to reuse the 'flags',
>> '_pp_mapping_pad' and '_mapcount' for specific mem provider, which is enough
>> for the devmem only requiring a single pointer to point to it's
>> owner?
>>
>
> All the above seems quite similar to RFC v1 again, using netmem
> instead of struct page. In RFC v1 we re-used zone_device_data() for
> the dma-buf owner equivalent.
As we have added a few checkings to limit 'struct page' for devmem to
be only used in net stack, we can decouple 'struct page' for devmem
from mm subsystem, zone_device_data() is not really needed, right?
If we can decouple 'struct page' for normal memory from mm subsystem
through the folio work in the future, then we may define a more abstract
structure for page pool and net stack instead of reusing 'struct page'
from mm.
>
^ permalink raw reply
* Re: [PATCH net v2] page_pool: Add myself as page pool reviewer in MAINTAINERS
From: Yunsheng Lin @ 2023-11-09 9:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, pabeni, netdev, linux-kernel, Jesper Dangaard Brouer,
Ilias Apalodimas
In-Reply-To: <20231108084739.59adead6@kernel.org>
On 2023/11/9 0:47, Jakub Kicinski wrote:
> On Wed, 8 Nov 2023 11:31:45 +0800 Yunsheng Lin wrote:
>> For 2, yes, maybe I should stick to the rule even if it is a simple
>> patch and obivous format error.
>
> Yes, maybe you should.
Thanks for clarifying.
Maybe I should be targetting the net-next branch for the repost
after merge window open, in order not to cause any confusion.
> .
>
^ permalink raw reply
* Re: [PATCH net 1/1] net: stmmac: fix MAC and phylink mismatch issue after resume with STMMAC_FLAG_USE_PHY_WOL enabled
From: Russell King (Oracle) @ 2023-11-09 9:46 UTC (permalink / raw)
To: Gan Yi Fang
Cc: Alexandre Torgue, Jose Abreu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Joakim Zhang,
netdev, linux-stm32, linux-arm-kernel, linux-kernel,
Looi Hong Aun, Voon Weifeng, Song Yoong Siang
In-Reply-To: <ZUyjOEQHHnnbzwrV@shell.armlinux.org.uk>
On Thu, Nov 09, 2023 at 09:15:36AM +0000, Russell King (Oracle) wrote:
> On Thu, Nov 09, 2023 at 01:00:27PM +0800, Gan Yi Fang wrote:
> > From: "Gan, Yi Fang" <yi.fang.gan@intel.com>
> >
> > The issue happened when flag STMMAC_FLAG_USE_PHY_WOL is enabled.
> > It can be reproduced with steps below:
> > 1. Advertise only one speed on the host
> > 2. Enable the WoL on the host
> > 3. Suspend the host
> > 4. Wake up the host
> >
> > When the WoL is disabled, both the PHY and MAC will suspend and wake up
> > with everything configured well. When WoL is enabled, the PHY needs to be
> > stay awake to receive the signal from remote client but MAC will enter
> > suspend mode.
> >
> > When the MAC resumes from suspend, phylink_resume() will call
> > phylink_start() to start the phylink instance which will trigger the
> > phylink machine to invoke the mac_link_up callback function. The
> > stmmac_mac_link_up() will configure the MAC_CTRL_REG based on the current
> > link state. Then the stmmac_hw_setup() will be called to configure the MAC.
> >
> > This sequence might cause mismatch of the link state between MAC and
> > phylink. This patch moves the phylink_resume() after stmamc_hw_setup() to
> > ensure the MAC is initialized before phylink is being configured.
>
> Isn't this going to cause problems?
>
> stmamc_hw_setup() calls stmmac_init_dma_engine(), which then calls
> stmmac_reset() - and stmmac_reset() can fail if the PHY clock isn't
> running, which is why phylink_resume() gets called before this.
I think these two commits should be reviewed to understand why the code
is the way it is, and why changing it may cause regressions:
90702dcd19c0 ("net: stmmac: fix MAC not working when system resume back
with WoL active")
36d18b5664ef ("net: stmmac: start phylink instance before
stmmac_hw_setup()")
As part of my work on stmmac that got junked, I was looking at a
solution to the "we need the PHY clock to be running for the MAC to
work for things like reset" problem - but those patches got thrown
away when stmmac folk were very nitpicky over %u vs %d in format
strings to print what was a _signed_ value that stmmac code stupidly
converts to an unsigned integer... it's still a signed integer no
matter if code decides to use "unsigned int". I suspect all those
patches (and there was a considerable number of them) have now been
expired from git, so are now totally lost, and honestly I have no
desire to put further work into stmmac stuff.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* RE: [PATCH net 1/3] dpll: fix pin dump crash after module unbind
From: Kubalewski, Arkadiusz @ 2023-11-09 9:49 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev@vger.kernel.org, vadim.fedorenko@linux.dev,
Michalik, Michal, Olech, Milena, pabeni@redhat.com,
kuba@kernel.org
In-Reply-To: <ZUukeokxH2NVvmpe@nanopsycho>
>From: Jiri Pirko <jiri@resnulli.us>
>Sent: Wednesday, November 8, 2023 4:09 PM
>
>Wed, Nov 08, 2023 at 11:32:24AM CET, arkadiusz.kubalewski@intel.com wrote:
>>Disallow dump of unregistered parent pins, it is possible when parent
>>pin and dpll device registerer kernel module instance unbinds, and
>>other kernel module instances of the same dpll device have pins
>>registered with the parent pin. The user can invoke a pin-dump but as
>>the parent was unregistered, thus shall not be accessed by the
>>userspace, prevent that by checking if parent pin is still registered.
>>
>>Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base functions")
>>Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
>>---
>> drivers/dpll/dpll_netlink.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>>diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
>>index a6dc3997bf5c..93fc6c4b8a78 100644
>>--- a/drivers/dpll/dpll_netlink.c
>>+++ b/drivers/dpll/dpll_netlink.c
>>@@ -328,6 +328,13 @@ dpll_msg_add_pin_parents(struct sk_buff *msg, struct
>dpll_pin *pin,
>> void *parent_priv;
>>
>> ppin = ref->pin;
>>+ /*
>>+ * dump parent only if it is registered, thus prevent crash on
>>+ * pin dump called when driver which registered the pin unbinds
>>+ * and different instance registered pin on that parent pin
>
>Read this sentence like 10 times, still don't get what you mean.
>Shouldn't comments be easy to understand?
>
Hi,
Hmm, wondering isn't it better to remove this comment at all?
If you think it is needed I will rephrase it somehow..
Thank you!
Arkadiusz
>
>>+ */
>>+ if (!xa_get_mark(&dpll_pin_xa, ppin->id, DPLL_REGISTERED))
>>+ continue;
>> parent_priv = dpll_pin_on_dpll_priv(dpll_ref->dpll, ppin);
>> ret = ops->state_on_pin_get(pin,
>> dpll_pin_on_pin_priv(ppin, pin),
>>--
>>2.38.1
>>
^ permalink raw reply
* RE: [PATCH net 3/3] dpll: fix register pin with unregistered parent pin
From: Kubalewski, Arkadiusz @ 2023-11-09 9:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev@vger.kernel.org, vadim.fedorenko@linux.dev,
Michalik, Michal, Olech, Milena, pabeni@redhat.com,
kuba@kernel.org
In-Reply-To: <ZUukPbTCww26jltC@nanopsycho>
>From: Jiri Pirko <jiri@resnulli.us>
>Sent: Wednesday, November 8, 2023 4:08 PM
>
>Wed, Nov 08, 2023 at 11:32:26AM CET, arkadiusz.kubalewski@intel.com wrote:
>>In case of multiple kernel module instances using the same dpll device:
>>if only one registers dpll device, then only that one can register
>
>They why you don't register in multiple instances? See mlx5 for a
>reference.
>
Every registration requires ops, but for our case only PF0 is able to
control dpll pins and device, thus only this can provide ops.
Basically without PF0, dpll is not able to be controlled, as well
as directly connected pins.
>
>>directly connected pins with a dpll device. If unregistered parent
>>determines if the muxed pin can be register with it or not, it forces
>>serialized driver load order - first the driver instance which
>>registers the direct pins needs to be loaded, then the other instances
>>could register muxed type pins.
>>
>>Allow registration of a pin with a parent even if the parent was not
>>yet registered, thus allow ability for unserialized driver instance
>
>Weird.
>
Yeah, this is issue only for MUX/parent pin part, couldn't find better
way, but it doesn't seem to break things around..
Thank you!
Arkadiusz
>
>>load order.
>>Do not WARN_ON notification for unregistered pin, which can be invoked
>>for described case, instead just return error.
>>
>>Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions")
>>Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base
>>functions")
>>Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
>>---
>> drivers/dpll/dpll_core.c | 4 ----
>> drivers/dpll/dpll_netlink.c | 2 +-
>> 2 files changed, 1 insertion(+), 5 deletions(-)
>>
>>diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c index
>>4077b562ba3b..ae884b92d68c 100644
>>--- a/drivers/dpll/dpll_core.c
>>+++ b/drivers/dpll/dpll_core.c
>>@@ -28,8 +28,6 @@ static u32 dpll_xa_id;
>> WARN_ON_ONCE(!xa_get_mark(&dpll_device_xa, (d)->id, DPLL_REGISTERED))
>> #define ASSERT_DPLL_NOT_REGISTERED(d) \
>> WARN_ON_ONCE(xa_get_mark(&dpll_device_xa, (d)->id, DPLL_REGISTERED))
>>-#define ASSERT_PIN_REGISTERED(p) \
>>- WARN_ON_ONCE(!xa_get_mark(&dpll_pin_xa, (p)->id, DPLL_REGISTERED))
>>
>> struct dpll_device_registration {
>> struct list_head list;
>>@@ -641,8 +639,6 @@ int dpll_pin_on_pin_register(struct dpll_pin *parent,
>struct dpll_pin *pin,
>> WARN_ON(!ops->state_on_pin_get) ||
>> WARN_ON(!ops->direction_get))
>> return -EINVAL;
>>- if (ASSERT_PIN_REGISTERED(parent))
>>- return -EINVAL;
>>
>> mutex_lock(&dpll_lock);
>> ret = dpll_xa_ref_pin_add(&pin->parent_refs, parent, ops, priv); diff
>>--git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c index
>>963bbbbe6660..ff430f43304f 100644
>>--- a/drivers/dpll/dpll_netlink.c
>>+++ b/drivers/dpll/dpll_netlink.c
>>@@ -558,7 +558,7 @@ dpll_pin_event_send(enum dpll_cmd event, struct
>dpll_pin *pin)
>> int ret = -ENOMEM;
>> void *hdr;
>>
>>- if (WARN_ON(!xa_get_mark(&dpll_pin_xa, pin->id, DPLL_REGISTERED)))
>>+ if (!xa_get_mark(&dpll_pin_xa, pin->id, DPLL_REGISTERED))
>> return -ENODEV;
>>
>> msg = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>>--
>>2.38.1
>>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 04/15] ice: track q_id in representor
From: Buvaneswaran, Sujai @ 2023-11-09 10:19 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-5-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 04/15] ice: track q_id in
> representor
>
> Previously queue index of control plane VSI used by port representor was
> always id of VF. If we want to allow adding port representors for different
> devices we have to track queue index in the port representor structure.
>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_repr.c | 1 +
> drivers/net/ethernet/intel/ice/ice_repr.h | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes
From: Michael Ellerman @ 2023-11-09 10:18 UTC (permalink / raw)
To: Arnd Bergmann, Christophe Leroy, Arnd Bergmann, Andrew Morton,
linux-kernel@vger.kernel.org, Masahiro Yamada,
linux-kbuild@vger.kernel.org
Cc: Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Steven Rostedt, Masami Hiramatsu, Mark Rutland,
guoren, Peter Zijlstra, Ard Biesheuvel, Huacai Chen, Greg Ungerer,
Michal Simek, Thomas Bogendoerfer, Dinh Nguyen, Nicholas Piggin,
Geoff Levand, Palmer Dabbelt, Heiko Carstens,
John Paul Adrian Glaubitz, David S . Miller, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, x86@kernel.org, Helge Deller,
Sudip Mukherjee, Greg Kroah-Hartman, Timur Tabi, Kent Overstreet,
David Woodhouse, Naveen N. Rao, Anil S Keshavamurthy, Kees Cook,
Vincenzo Frascino, Juri Lelli, Vincent Guittot, Nathan Chancellor,
Nick Desaulniers, Nicolas Schier, Alexander Viro,
Uwe Kleine-König, linux-alpha@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-trace-kernel@vger.kernel.org, linux-csky@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Netdev,
linux-parisc@vger.kernel.org, linux-usb@vger.kernel.org,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-bcachefs@vger.kernel.org, linux-mtd@lists.infradead.org
In-Reply-To: <d94de5b8-db92-4055-9484-f2666973c02a@app.fastmail.com>
"Arnd Bergmann" <arnd@arndb.de> writes:
> On Wed, Nov 8, 2023, at 19:31, Christophe Leroy wrote:
>> Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
>
>> powerpc has functions doing more or less the same, they are called
>> __c_kernel_clock_gettime() and alike with their prototypes siting in
>> arch/powerpc/include/asm/vdso/gettimeofday.h
>>
>> Should those prototypes be moved to include/vdso/gettime.h too and
>> eventually renamed, or are they considered too powerpc specific ?
>
> I don't actually know, my initial interpretation was that
> these function names are part of the user ABI for the vdso,
> but I never looked closely enough at how vdso works to
> be sure what the actual ABI is.
AFAIK the ABI is just the symbols we export, as defined in the linker
script:
/*
* This controls what symbols we export from the DSO.
*/
VERSION
{
VDSO_VERSION_STRING {
global:
__kernel_get_syscall_map;
__kernel_gettimeofday;
__kernel_clock_gettime;
__kernel_clock_getres;
__kernel_get_tbfreq;
__kernel_sync_dicache;
__kernel_sigtramp_rt64;
__kernel_getcpu;
__kernel_time;
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vdso/vdso64.lds.S?h=v6.6&#n117
> If __c_kernel_clock_gettime() etc are not part of the user-facing
> ABI, I think renaming them for consistency with the other
> architectures would be best.
The __c symbols are not part of the ABI, so we could rename them.
At the moment though they don't have the same prototype as the generic
versions, because we find the VDSO data in asm and pass it to the C
functions, eg:
int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
const struct vdso_data *vd);
I think we can rework that though, by implementing
__arch_get_vdso_data() and getting the vdso_data in C. Then we'd be able
to share the prototypes.
cheers
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 06/15] ice: track port representors in xarray
From: Buvaneswaran, Sujai @ 2023-11-09 10:20 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-7-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 06/15] ice: track port
> representors in xarray
>
> Instead of assuming that each VF has pointer to port representor save it in
> xarray. It will allow adding port representor for other device types.
>
> Drop reference to VF where it is use only to get port representor. Get it from
> xarray instead.
>
> The functions will no longer by specific for VF, rename them.
>
> Track id assigned by xarray in port representor structure. The id can't be
> used as ::q_id, because it is fixed during port representor lifetime.
> ::q_id can change after adding / removing other port representors.
>
> Side effect of removing VF pointer is that we are losing VF MAC information
> used in unrolling. Store it in port representor as parent MAC.
>
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice.h | 1 +
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 182 +++++++++----------
> drivers/net/ethernet/intel/ice/ice_main.c | 2 +
> drivers/net/ethernet/intel/ice/ice_repr.c | 8 +
> drivers/net/ethernet/intel/ice/ice_repr.h | 2 +
> 5 files changed, 94 insertions(+), 101 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 07/15] ice: remove VF pointer reference in eswitch code
From: Buvaneswaran, Sujai @ 2023-11-09 10:21 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-8-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 07/15] ice: remove VF pointer
> reference in eswitch code
>
> Make eswitch code generic by removing VF pointer reference in functions.
> It is needed to support eswitch mode for other type of devices.
>
> Previously queue id used for Rx was based on VF number. Use ::q_id saved in
> port representor instead.
>
> After adding or removing port representor ::q_id value can change. It isn't
> good idea to iterate over representors list using this value.
> Use xa_find starting from the first one instead to get next port representor to
> remap.
>
> The number of port representors has to be equal to ::num_rx/tx_q. Warn if it
> isn't true.
>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 39 ++++++++++----------
> drivers/net/ethernet/intel/ice/ice_eswitch.h | 5 ++-
> drivers/net/ethernet/intel/ice/ice_repr.c | 1 +
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 2 +-
> 4 files changed, 25 insertions(+), 22 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 08/15] ice: make representor code generic
From: Buvaneswaran, Sujai @ 2023-11-09 10:22 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-9-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 08/15] ice: make representor
> code generic
>
> Representor code needs to be independent from specific device type, like in
> this case VF. Make generic add / remove representor function and specific
> add VF / rem VF function. New device types will follow this scheme.
>
> In bridge offload code there is a need to get representor pointer based on
> VSI. Implement helper function to achieve that.
>
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 9 +-
> drivers/net/ethernet/intel/ice/ice_eswitch.h | 4 +-
> .../net/ethernet/intel/ice/ice_eswitch_br.c | 10 +-
> drivers/net/ethernet/intel/ice/ice_lib.c | 10 +-
> drivers/net/ethernet/intel/ice/ice_repr.c | 184 ++++++++++--------
> drivers/net/ethernet/intel/ice/ice_repr.h | 2 +
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_vf_lib.h | 2 +-
> 8 files changed, 131 insertions(+), 92 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 09/15] ice: return pointer to representor
From: Buvaneswaran, Sujai @ 2023-11-09 10:23 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-10-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 09/15] ice: return pointer to
> representor
>
> In follow up patches it will be easier to obtain created port representor
> pointer instead of the id. Without it the pattern from eswitch side will look
> like:
> - create PR
> - get PR based on the id
>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_repr.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 09/15] ice: return pointer to representor
From: Buvaneswaran, Sujai @ 2023-11-09 10:25 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-10-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 09/15] ice: return pointer to
> representor
>
> In follow up patches it will be easier to obtain created port representor
> pointer instead of the id. Without it the pattern from eswitch side will look
> like:
> - create PR
> - get PR based on the id
>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_repr.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 10/15] ice: allow changing SWITCHDEV_CTRL VSI queues
From: Buvaneswaran, Sujai @ 2023-11-09 10:25 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-11-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 10/15] ice: allow changing
> SWITCHDEV_CTRL VSI queues
>
> Implement mechanism to change number of queues for SWITCHDEV_CTRL
> VSI type.
>
> Value from ::req_txq/rxq will be written to ::alloc_txq/rxq after calling
> ice_vsi_rebuild().
>
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_lib.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 11/15] ice: set Tx topology every time new repr is added
From: Buvaneswaran, Sujai @ 2023-11-09 10:26 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-12-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 11/15] ice: set Tx topology every
> time new repr is added
>
> It is needed to track correct Tx topology. Update it every time new
> representor is created or remove node in case of removing corresponding
> representor.
>
> Still clear all node when removing switchdev mode as part of Tx topology
> isn't related only to representors. Also clear ::rate_note value to prevent
> skipping this node next time Tx topology is created.
>
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_devlink.c | 29 ++++++++++++++++++++
> drivers/net/ethernet/intel/ice/ice_devlink.h | 1 +
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 9 ++++++
> drivers/net/ethernet/intel/ice/ice_repr.c | 27 +++++++++++++-----
> 4 files changed, 59 insertions(+), 7 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 12/15] ice: realloc VSI stats arrays
From: Buvaneswaran, Sujai @ 2023-11-09 10:30 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-13-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 12/15] ice: realloc VSI stats
> arrays
>
> Previously only case when queues amount is lower was covered. Implement
> realloc for case when queues amount is higher than previous one. Use
> krealloc() function and zero new allocated elements.
>
> It has to be done before ice_vsi_def_cfg(), because stats element for ring is
> set there.
>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_lib.c | 58 ++++++++++++++++--------
> 1 file changed, 39 insertions(+), 19 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 13/15] ice: add VF representors one by one
From: Buvaneswaran, Sujai @ 2023-11-09 10:31 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-14-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 13/15] ice: add VF representors
> one by one
>
> Implement adding representors one by one. Always set switchdev
> environment when first representor is being added and clear environment
> when last one is being removed.
>
> Basic switchdev configuration remains the same. Code related to creating
> and configuring representor was changed.
>
> Instead of setting whole representors in one function handle only one
> representor in setup function. The same with removing representors.
>
> Stop representors when new one is being added or removed. Stop means,
> disabling napi, stopping traffic and removing slow path rule. It is needed
> because ::q_id will change after remapping, so each representor will need
> new rule.
>
> When representor are stopped rebuild control plane VSI with one more or
> one less queue. One more if new representor is being added, one less if
> representor is being removed.
>
> Bridge port is removed during unregister_netdev() call on PR, so there is no
> need to call it from driver side.
>
> After that do remap new queues to correct vector. At the end start all
> representors (napi enable, start queues, add slow path rule).
>
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 351 +++++++++++--------
> drivers/net/ethernet/intel/ice/ice_eswitch.h | 13 +-
> drivers/net/ethernet/intel/ice/ice_repr.c | 85 +----
> drivers/net/ethernet/intel/ice/ice_repr.h | 4 +-
> drivers/net/ethernet/intel/ice/ice_sriov.c | 17 +-
> 5 files changed, 228 insertions(+), 242 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 14/15] ice: adjust switchdev rebuild path
From: Buvaneswaran, Sujai @ 2023-11-09 10:31 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-15-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 14/15] ice: adjust switchdev
> rebuild path
>
> There is no need to use specific functions for rebuilding path. Let's use
> current implementation by removing all representors and as the result
> remove switchdev environment.
>
> It will be added in devices rebuild path. For example during adding VFs, port
> representors for them also will be created.
>
> Rebuild control plane VSI before removing representors with INIT_VSI flag
> set to reinit VSI in hardware after reset.
>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 66 +++++++-------------
> drivers/net/ethernet/intel/ice/ice_main.c | 4 +-
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 7 +--
> 3 files changed, 28 insertions(+), 49 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 15/15] ice: reserve number of CP queues
From: Buvaneswaran, Sujai @ 2023-11-09 10:32 UTC (permalink / raw)
To: Michal Swiatkowski, intel-wired-lan@lists.osuosl.org
Cc: Drewek, Wojciech, Szycik, Marcin, netdev@vger.kernel.org,
Brandeburg, Jesse, Kitszel, Przemyslaw, Keller, Jacob E,
Raczynski, Piotr
In-Reply-To: <20231024110929.19423-16-michal.swiatkowski@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Tuesday, October 24, 2023 4:39 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Drewek, Wojciech <wojciech.drewek@intel.com>; Szycik, Marcin
> <marcin.szycik@intel.com>; netdev@vger.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Raczynski, Piotr
> <piotr.raczynski@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 15/15] ice: reserve number of
> CP queues
>
> Rebuilding CP VSI each time the PR is created drastically increase the time of
> maximum VFs creation. Add function to reserve number of CP queues to deal
> with this problem.
>
> Use the same function to decrease number of queues in case of removing
> VFs. Assume that caller of ice_eswitch_reserve_cp_queues() will also call
> ice_eswitch_attach/detach() correct number of times.
>
> Still one by one PR adding is handy for VF resetting routine.
>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice.h | 6 +++
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 52 +++++++++++++++++---
> drivers/net/ethernet/intel/ice/ice_eswitch.h | 4 ++
> drivers/net/ethernet/intel/ice/ice_sriov.c | 3 ++
> 4 files changed, 58 insertions(+), 7 deletions(-)
>
Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
^ permalink raw reply
* Re: [net-next RFC PATCH v5 4/4] dt-bindings: Document bindings for Marvell Aquantia PHY
From: Christian Marangi @ 2023-11-09 10:38 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, Heiner Kallweit,
Russell King, Robert Marko, Vladimir Oltean, netdev, devicetree,
linux-kernel
In-Reply-To: <20231107192232.GA3296102-robh@kernel.org>
On Tue, Nov 07, 2023 at 01:22:32PM -0600, Rob Herring wrote:
> On Mon, Nov 06, 2023 at 05:54:33PM +0100, Christian Marangi wrote:
> > Document bindings for Marvell Aquantia PHY.
>
> For the subject: dt-bindings: net: Add Marvell Aquantia PHY
>
> ('Document bindings' is redundant)
>
> >
> > The Marvell Aquantia PHY require a firmware to work correctly and there
> > at least 3 way to load this firmware.
> >
> > Describe all the different way and document the binding "firmware-name"
> > to load the PHY firmware from userspace.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > Changes v5:
> > - Drop extra entry not related to HW description
> > Changes v3:
> > - Make DT description more OS agnostic
> > - Use custom select to fix dtbs checks
> > Changes v2:
> > - Add DT patch
> >
> > .../bindings/net/marvell,aquantia.yaml | 123 ++++++++++++++++++
> > 1 file changed, 123 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/marvell,aquantia.yaml b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> > new file mode 100644
> > index 000000000000..7106c5bdf73c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
> > @@ -0,0 +1,123 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/marvell,aquantia.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Marvell Aquantia Ethernet PHY
> > +
> > +maintainers:
> > + - Christian Marangi <ansuelsmth@gmail.com>
> > +
> > +description: |
> > + Marvell Aquantia Ethernet PHY require a firmware to be loaded to actually
> > + work.
> > +
> > + This can be done and is implemented by OEM in 3 different way:
> > + - Attached SPI flash directly to the PHY with the firmware. The PHY
> > + will self load the firmware in the presence of this configuration.
> > + - Dedicated partition on system NAND with firmware in it. NVMEM
> > + subsystem will be used and the declared NVMEM cell will load
> > + the firmware to the PHY using the PHY mailbox interface.
> > + - Manually provided firmware loaded from a file in the filesystem.
> > +
> > +allOf:
> > + - $ref: ethernet-phy.yaml#
> > +
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id03a1.b445
> > + - ethernet-phy-id03a1.b460
> > + - ethernet-phy-id03a1.b4a2
> > + - ethernet-phy-id03a1.b4d0
> > + - ethernet-phy-id03a1.b4e0
> > + - ethernet-phy-id03a1.b5c2
> > + - ethernet-phy-id03a1.b4b0
> > + - ethernet-phy-id03a1.b662
> > + - ethernet-phy-id03a1.b712
> > + - ethernet-phy-id31c3.1c12
> > + required:
> > + - compatible
> > +
> > +properties:
> > + reg:
> > + maxItems: 1
> > +
> > + firmware-name:
> > + description: specify the name of PHY firmware to load
> > +
> > + nvmem-cells:
> > + description: phandle to the firmware nvmem cell
> > + maxItems: 1
> > +
> > + nvmem-cell-names:
> > + const: firmware
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethernet-phy@0 {
> > + /* Only needed to make DT lint tools work. Do not copy/paste
> > + * into real DTS files.
> > + */
>
> I don't agree with this statement. Pretty sure we've been through this
> before...
>
> If we have a node, we need to define what it is. The way that is done is
> with compatible. Whether some particular OS implementation (currently)
> needs compatible or not is irrelevant. It's not about dtschema needing
> it, that just exposes the issue.
>
> These MDIO PHY bindings are all broken because they are never actually
> applied to anything.
>
I will just drop these comments, the additional compatible is redundant
as it will be scanned from PHY ID but won't cause any problem.
Also the scenario with fw in nvmem cells or in fs is in devices where
the PHY is soldered to the device, so describe them in DT is correct.
--
Ansuel
^ permalink raw reply
* Re: [PATCH net v4 1/3] net: ethernet: cortina: Fix max RX frame define
From: Vladimir Oltean @ 2023-11-09 10:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Hans Ulli Kroll, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Michał Mirosław, Andrew Lunn,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20231109-gemini-largeframe-fix-v4-1-6e611528db08@linaro.org>
On Thu, Nov 09, 2023 at 10:03:12AM +0100, Linus Walleij wrote:
> Enumerator 3 is 1548 bytes according to the datasheet.
> Not 1542.
>
> Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
^ permalink raw reply
* Re: [PATCH net v4 2/3] net: ethernet: cortina: Handle large frames
From: Vladimir Oltean @ 2023-11-09 10:46 UTC (permalink / raw)
To: Linus Walleij
Cc: Hans Ulli Kroll, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Michał Mirosław, Andrew Lunn,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20231109-gemini-largeframe-fix-v4-2-6e611528db08@linaro.org>
On Thu, Nov 09, 2023 at 10:03:13AM +0100, Linus Walleij wrote:
> The Gemini ethernet controller provides hardware checksumming
> for frames up to 1514 bytes including ethernet headers but not
> FCS.
>
> If we start sending bigger frames (after first bumping up the MTU
> on both interfaces sending and receiving the frames), truncated
> packets start to appear on the target such as in this tcpdump
> resulting from ping -s 1474:
>
> 23:34:17.241983 14:d6:4d:a8:3c:4f (oui Unknown) > bc:ae:c5:6b:a8:3d (oui Unknown),
> ethertype IPv4 (0x0800), length 1514: truncated-ip - 2 bytes missing!
> (tos 0x0, ttl 64, id 32653, offset 0, flags [DF], proto ICMP (1), length 1502)
> OpenWrt.lan > Fecusia: ICMP echo request, id 1672, seq 50, length 1482
>
> If we bypass the hardware checksumming and provide a software
> fallback, everything starts working fine up to the max TX MTU
> of 2047 bytes, for example ping -s2000 192.168.1.2:
>
> 00:44:29.587598 bc:ae:c5:6b:a8:3d (oui Unknown) > 14:d6:4d:a8:3c:4f (oui Unknown),
> ethertype IPv4 (0x0800), length 2042:
> (tos 0x0, ttl 64, id 51828, offset 0, flags [none], proto ICMP (1), length 2028)
> Fecusia > OpenWrt.lan: ICMP echo reply, id 1683, seq 4, length 2008
>
> The bit enabling to bypass hardware checksum (or any of the
> "TSS" bits) are undocumented in the hardware reference manual.
> The entire hardware checksum unit appears undocumented. The
> conclusion that we need to use the "bypass" bit was found by
> trial-and-error.
>
> Since no hardware checksum will happen, we slot in a software
> checksum fallback.
>
> Check for the condition where we need to compute checksum on the
> skb with either hardware or software using == CHECKSUM_PARTIAL instead
> of != CHECKSUM_NONE which is an incomplete check according to
> <linux/skbuff.h>.
>
> On the D-Link DIR-685 router this fixes a bug on the conduit
> interface to the RTL8366RB DSA switch: as the switch needs to add
> space for its tag it increases the MTU on the conduit interface
> to 1504 and that means that when the router sends packages
> of 1500 bytes these get an extra 4 bytes of DSA tag and the
> transfer fails because of the erroneous hardware checksumming,
> affecting such basic functionality as the LuCI web interface.
>
> Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox