netdev - Re: [PATCH v2 05/10] can: kvaser_pciefd: Store device channel index

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMZ6RqKdTX0++J_TKGkK8=1mLwC3xE3ZZws85tvzv9bmvZRM0w@mail.gmail.com>
Date: Thu, 24 Jul 2025 16:54:04 +0900
From: Vincent Mailhol <mailhol.vincent@...adoo.fr>
To: Jimmy Assarsson <jimmyassarsson@...il.com>
Cc: Jimmy Assarsson <extja@...ser.com>, linux-can@...r.kernel.org, 
	Marc Kleine-Budde <mkl@...gutronix.de>, netdev@...r.kernel.org
Subject: Re: [PATCH v2 05/10] can: kvaser_pciefd: Store device channel index

On Thu. 24 Jul. 2025 at 16:09, Jimmy Assarsson <jimmyassarsson@...il.com> wrote:
> On 7/24/25 8:36 AM, Jimmy Assarsson wrote:
> > Store device channel index in netdev.dev_port.
> >
> > Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
> > Signed-off-by: Jimmy Assarsson <extja@...ser.com>
> > ---
> > Changes in v2:
> >    - Add Fixes tag.
> >
> >   drivers/net/can/kvaser_pciefd.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c
> > index 7153b9ea0d3d..8dcb1d1c67e4 100644
> > --- a/drivers/net/can/kvaser_pciefd.c
> > +++ b/drivers/net/can/kvaser_pciefd.c
> > @@ -1028,6 +1028,7 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie)
> >               can->completed_tx_bytes = 0;
> >               can->bec.txerr = 0;
> >               can->bec.rxerr = 0;
> > +             can->can.dev->dev_port = i;
> >
> >               init_completion(&can->start_comp);
> >               init_completion(&can->flush_comp);
>
> Would it be better to submit this as a separate patch, or keep it within
> this patch series?

Even if this is a bug, I see no urgency to it, so I am happy to have
this goes first to netdev-next and is picked-up by stable later on.
Doing the opposite would require you to split and seems more
troublesome.