On Wed, 16 Apr 2025 15:57:50 -0500 Dave Marquardt wrote:
> Reset the adapter through new function ibmveth_reset, called in
> WARN_ON situations. Removed conflicting and unneeded forward
> declaration.
There's a schedule_work() added but neither cancel nor flush when
interface is shut down or remov
On Fri, 11 Apr 2025 17:57:42 +0800 Wei Fang wrote:
> enetc4_pf_netdev_destroy(si);
> enetc4_pf_free(pf);
> + destroy_workqueue(si->workqueue);
I think that you need to flush or cancel the work after unregistering
the netdev but before freeing it? The work may access netdev after it
On Sat, 8 Mar 2025 02:05:35 + Wei Fang wrote:
> > > On Tue, 4 Mar 2025 15:21:49 +0800 Wei Fang wrote:
> > hm..., there are some interfaces of netc-lib are used in common .c files
> > in downstream, so I used "ifdef" in downstream. Now for the upstream,
> > I'm going to separate them from the
On Tue, 4 Mar 2025 15:21:54 +0800 Wei Fang wrote:
> Add Receive side scaling (RSS) support for i.MX95 ENETC PF to improve
> the network performance and balance the CPU loading. The main changes
> are as follows.
>
> 1. Since i.MX95 ENETC (v4) use NTMP 2.0 to manage the RSS table, which
> is diffe
On Tue, 4 Mar 2025 15:21:55 +0800 Wei Fang wrote:
> Both ENETC v1 and ENETC v4 only support the toeplitz algorithm for RSS,
> so add a check for RSS hfunc.
Rejecting unsupported configurations is considered a fix,
please send it to net with a Fixes tag.
--
pw-bot: cr
On Tue, 4 Mar 2025 15:21:49 +0800 Wei Fang wrote:
> +config NXP_NETC_LIB
> + tristate "NETC Library"
Remove the string after "tristate", the user should not be prompted
to make a choice for this, since the consumers "select" this config
directly.
> + help
> + This module provides c
On Thu, 16 Jan 2025 02:24:10 + Wei Fang wrote:
> > Why create full ops for something this trivial?
>
> We add enetc_pf_hw_ops to implement different hardware ops
> for different chips. So that they can be called in common functions.
> Although the change is minor, it is consistent with the o
On Mon, 13 Jan 2025 16:22:39 +0800 Wei Fang wrote:
> Add Receive side scaling (RSS) support for i.MX95 ENETC PF to improve the
> network performance and balance the CPU loading. In addition, since both
> ENETC v1 and ENETC v4 only support the toeplitz algorithm, so a check for
> hfunc was added.
T
On Fri, 3 Jan 2025 14:06:00 +0800 Wei Fang wrote:
> The i.MX95 ENETC supports both MAC hash filter and MAC exact filter. MAC
> hash filter is implenented through a 64-bits hash table to match against
> the hashed addresses, PF and VFs each have two MAC hash tables, one is
> for unicast and the oth
On Wed, 18 Dec 2024 17:59:17 -0800 Jakub Kicinski wrote:
> On Wed, 18 Dec 2024 21:55:12 +1100 Michael Ellerman wrote:
> > This driver can no longer be built since support for IBM Cell Blades was
> > removed, in particular PPC_IBM_CELL_BLADE.
> >
> > Remove the d
On Wed, 18 Dec 2024 21:55:12 +1100 Michael Ellerman wrote:
> This driver can no longer be built since support for IBM Cell Blades was
> removed, in particular PPC_IBM_CELL_BLADE.
>
> Remove the driver and the documentation.
> Remove the MAINTAINERS entry, and add Ishizaki and Geoff to CREDITS.
Ya
On Tue, 10 Dec 2024 18:50:40 -0800 Andrew Morton wrote:
> > > Very unlikely, and any such conflict will be trivial.
> >
> > Agreed, mainly I don't understand why we'd make an exception
> > and take the patchset via a special tree.
>
> It saves work for everyone?
>
> The patches are super-sim
On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > I'll just grab everything and see if anyone complains ;)
> >
> > I may, if this leads to a conflict :(
>
> Very unlikely, and any such conflict will be trivial.
Agreed, mainly I don't understand why we'd make an exception
and take
On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > I have the same question as before: How do you expect these to land?
> > Do you now have a maintainer who will take all of them?
> > Or do you want individual maintainers to take the ones applicable to them?
>
> I'll just grab everythin
On Tue, 12 Nov 2024 13:14:42 -0800 Rosen Penev wrote:
> drivers/net/ethernet/moxa/moxart_ether.c | 6 ++---
> .../ethernet/samsung/sxgbe/sxgbe_platform.c | 24 +++
coccicheck says:
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:130:6-26: WARNING: Unsigned
expression
On Mon, 11 Nov 2024 13:03:16 -0800 Rosen Penev wrote:
> --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
> +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
> @@ -111,7 +111,7 @@ static int sxgbe_platform_probe(struct platform_device
> *pdev)
> }
>
> /* Get the SXGBE
On Wed, 30 Oct 2024 18:23:26 -0600 Caleb Sander Mateos wrote:
> In a heavy TCP workload, mlx5e_handle_rx_dim() consumes 3% of CPU time,
> 94% of which is attributed to the first push instruction to copy
> dim_sample on the stack for the call to net_dim():
Change itself looks fine, so we can apply,
On Wed, 30 Oct 2024 13:49:08 -0600 Caleb Sander Mateos wrote:
> net_dim() is currently passed a struct dim_sample argument by value.
> struct dim_sample is 24 bytes. Since this is greater 16 bytes, x86-64
> passes it on the stack. All callers have already initialized dim_sample
> on the stack, so p
g/20240925-bizarre-earwig-from-pluto-1484aa@lemu/
Signed-off-by: Jakub Kicinski
---
CC: k...@linux-powerpc.org
CC: a...@arndb.de
CC: tsbog...@alpha.franken.de
CC: m...@ellerman.id.au
CC: npig...@gmail.com
CC: christophe.le...@csgroup.eu
CC: nav...@kernel.org
CC: ma...@linux.ibm.com
CC: pctamm...@mojat
On Sat, 14 Sep 2024 12:02:09 +1000 Michael Ellerman wrote:
> Can you try the patch below, it fixes the build error for me.
Excellent, fixes it for me too!
--
pw-bot: nap
On Fri, 13 Sep 2024 15:20:13 -0700 Mina Almasry wrote:
> I have not reported the issue to GCC yet. From the build break thread
> it seemed a fix was urgent, so I posted the fix and was planning to
> report the issue after. If not, no problem, I'll report the issue and
> repost the fix with a GCC bu
On Fri, 13 Sep 2024 13:05:32 -0700 Mina Almasry wrote:
> Change, got NAKed:
> https://lore.kernel.org/netdev/zusq9bt9vg7o2...@casper.infradead.org/
Humpf.
> But AFAICT we don't really need to do this inside of mm, affecting
> things like compound_head. This equivalent change also makes the build
On Fri, 13 Sep 2024 09:27:17 -0700 Mina Almasry wrote:
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 5769fe6e4950..ea4005d2d1a9 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -239,8 +239,8 @@ static inline unsigned long _compound_h
On Fri, 13 Sep 2024 08:34:26 -0700 Jakub Kicinski wrote:
> > The second "asm" above (CONFIG_PPC_KERNEL_PREFIXED is not set). I am
> > guessing by searching for "39" in net/core/page_pool.s
> >
> > This is maybe called from page_pool_unref_netmem()
On Fri, 13 Sep 2024 20:41:38 +1000 Stephen Rothwell wrote:
> I have bisected it (just using the net-next tree) to commit
>
> 8ab79ed50cf10f338465c296012500de1081646f is the first bad commit
> commit 8ab79ed50cf10f338465c296012500de1081646f
> Author: Mina Almasry
> Date: Tue Sep 10 17:14:49 2024
On Thu, 29 Aug 2024 18:15:30 +0200 Maxime Chevallier wrote:
> @@ -582,15 +591,12 @@ static void fs_timeout_work(struct work_struct *work)
>
> dev->stats.tx_errors++;
>
> - spin_lock_irqsave(&fep->lock, flags);
> -
> - if (dev->flags & IFF_UP) {
> - phy_stop(dev->phydev
cc-hdlc.yaml
> delete mode 100644
> Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
Any preference who applies this? net or soc or Rob? No preference here,
FWIW:
Acked-by: Jakub Kicinski
> Sorry, It is sent by accidently. it was already post at
> htt
On Thu, 11 Jul 2024 02:00:22 +0300 Vladimir Oltean wrote:
> + priv->egress_fqs = devm_kcalloc(dev, dpaa_max_num_txqs(),
> + sizeof(*priv->egress_fqs),
> + GFP_KERNEL);
> + if (!priv->egress_fqs)
> + goto fre
On Mon, 24 Jun 2024 09:21:19 -0700 Breno Leitao wrote:
> As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
> depend on COMPILE_TEST for compilation and testing.
>
> # grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l
> 29
Cover letter would be good..
Herbert
On Wed, 12 Jun 2024 20:38:02 -0700 Paul E. McKenney wrote:
> o Make rcu_barrier() wait for kfree_rcu() objects. (This is
> surprisingly complex and will wait unnecessarily in some cases.
> However, it does preserve current code.)
Not sure how much mental capacity for API variation
On Wed, 12 Jun 2024 15:37:55 -0700 Paul E. McKenney wrote:
> So 05/14, 11/14 and 12/14 are OK and can go ahead. The rest need some
> help.
Thank you for the breakdown!
On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> Since SLOB was removed, it is not necessary to use call_rcu
> when the callback only performs kmem_cache_free. Use
> kfree_rcu() directly.
>
> The changes were done using the following Coccinelle semantic patch.
> This semantic patch is desi
On Wed, 8 May 2024 10:11:35 -0700 Kees Cook wrote:
> > Split this per subsystem, please.
>
> I've done a few painful API transitions before, and I don't think the
> complexity of these changes needs a per-subsystem constification pass. I
> think this series is the right approach, but that patch
On Wed, 8 May 2024 10:55:05 +0200 Erhard Furtner wrote:
> I could do that with the explanation you stated. But should any
> further questions arise in this process I would also lack the
> technical background to deal with them. ;)
Alright, submitted :)
> I also noticed a similar #ifdef CONFIG_NET
On Tue, 7 May 2024 02:42:58 +0200 Erhard Furtner wrote:
> And indeed without gem_poll_controller() I don't hit the "WARNING: CPU: 1
> PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c" and "WARNING:
> CPU: 1 PID: 1 at kernel/locking/irqflag-debug.c:10
> warn_bogus_irq_restore+0x30/0x
On Sun, 5 May 2024 23:27:13 +0200 Erhard Furtner wrote:
> > On Sun, 28 Apr 2024 12:53:06 +0200 Erhard Furtner wrote:
> > > With netconsole enabled I get this "WARNING: CPU: 1 PID: 1 at
> > > net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c" and "WARNING:
> > > CPU: 1 PID: 1 at kernel/locking/i
On Sun, 28 Apr 2024 12:53:06 +0200 Erhard Furtner wrote:
> With netconsole enabled I get this "WARNING: CPU: 1 PID: 1 at
> net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c" and "WARNING:
> CPU: 1 PID: 1 at kernel/locking/irqflag-debug.c:10
> warn_bogus_irq_restore+0x30/0x44" at boot on my PowerM
On Tue, 23 Apr 2024 09:54:35 +0200 Thomas Weißschuh wrote:
> The series was split from my larger series sysctl-const series [0].
> It only focusses on the proc_handlers but is an important step to be
> able to move all static definitions of ctl_table into .rodata.
Split this per subsystem, please.
On Tue, 23 Apr 2024 18:41:48 +0300 Dan Carpenter wrote:
> > So, the point of the patch not doing any behavioral differences is still
> > true.
>
> Ah yes. You're right.
Hard call but overall I think this wasted more reviewer time than it's
worth. So in the spirit of not encouraging noise I'm n
On Fri, 5 Apr 2024 09:20:41 +0200 Uwe Kleine-König wrote:
> When sending a patch to (among others) Li Yang the nxp MTA replied that
> the address doesn't exist and so the mail couldn't be delivered. The
> error code was 550, so at least technically that's not a temporal issue.
>
> Signed-off-by:
On Wed, 3 Apr 2024 06:19:27 -0700 Guenter Roeck wrote:
> dev_addr_lists_test generates lock warning noise at the end of tests
> if lock debugging is enabled. There are two sets of warnings.
>
> WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923
> __mutex_unlock_slowpath.constprop.0+0x13c/0x3
On Tue, 26 Mar 2024 23:37:59 +0100 Arnd Bergmann wrote:
> I hope that the patches can get picked up by platform maintainers
> directly, so the final patch can go in later on.
platform == subsystem? :)
On Thu, 7 Mar 2024 12:39:03 +0100 Herve Codina wrote:
> This series introduces the QMC HDLC support.
>
> Patches were previously sent as part of a full feature series and were
> previously reviewed in that context:
> "Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]
>
> In
On Wed, 6 Mar 2024 15:38:10 +0200 Andy Shevchenko wrote:
> > It's minor, but you can avoid conditionals doing something like:
> >
> > netdev->stats.rx_over_errors += !!(flags &
> > QMC_RX_FLAG_HDLC_OVF);
>
> This is harder to read.
+1
On Thu, 29 Feb 2024 09:55:22 +0100 Eric Dumazet wrote:
> I do not see other solution than this, otherwise we have to add more
> pollution to include/linux/netdevice.h
Right :(
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index
> a9c973b92294bb110cf3cd336485972127b01b58.
On Tue, 6 Feb 2024 15:07:14 +0100 Herve Codina wrote:
> The bitmap_onto() function translates one bitmap relative to another but
> no function are present to perform the reverse translation.
>
> Introduce bitmap_off() to fill this hole.
Argh, Yury is not even CCed on this? I was about to ping hi
On Tue, 21 Nov 2023 08:43:30 +0100 Herve Codina wrote:
> I plan to send the v10 with the patch 23 fixed.
> Based on that v10, some patches (21 to 25 at least) could be applied and
> I will remove them for the future v11.
> I think it will be easier to follow if I iterate on the series removing
> pa
On Wed, 15 Nov 2023 15:39:36 +0100 Herve Codina wrote:
>- Removed Patches 6, 7 and 8 (patches applied)
>
>- Patches 7, 20, 21, 23 (patches 10, 23, 24, 26 in v8)
> Add 'Acked-by: Jakub Kicinski '
I thought someone (Mark?) asked for the networking stuff to b
On Wed, 8 Nov 2023 14:18:09 + Geoff Levand wrote:
> Seems good to me. I'll test it next chance I get.
>
> Signed-off-by: Geoff Levand
Seems like this is best routed via powerpc:
Acked-by: Jakub Kicinski
On Wed, 25 Oct 2023 17:00:51 +0200 Herve Codina wrote:
> > Which way will those patches go? Via some FSL SoC tree?
>
> This series seems mature now.
> What is the plan next in order to have it applied ?
>
> Don't hesitate to tell me if you prefer split series.
FWIW we are happy to take the dri
On Fri, 20 Oct 2023 17:31:56 +0800 Kunwu Chan wrote:
> reques -> request
>
> Fixes: 09dde54c6a69 ("PS3: gelic: Add wireless support for PS3")
> Signed-off-by: Kunwu Chan
Appears to have been applied to net, thank you!
On Wed, 11 Oct 2023 08:14:04 +0200 Herve Codina wrote:
> Compare to the previous iteration
>
> https://lore.kernel.org/linux-kernel/20230928070652.330429-1-herve.cod...@bootlin.com/
> This v8 series:
> - Fixes a race condition
> - Uses menuconfig instead of menu and hides CONFIG_GENERIC_FRAMER
On Wed, 11 Oct 2023 08:14:30 +0200 Herve Codina wrote:
> The Lantiq PEF2256 is a framer and line interface component designed to
> fulfill all required interfacing between an analog E1/T1/J1 line and the
> digital PCM system highway/H.100 bus.
Acked-by: Jakub Kicinski
ff the framer
> - get the framer status (line state)
> - be notified on framer status changes
> - get/set the framer configuration
Acked-by: Jakub Kicinski
ina
> Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
On Wed, 11 Oct 2023 08:14:14 +0200 Herve Codina wrote:
> The QMC HDLC driver provides support for HDLC using the QMC (QUICC
> Multichannel Controller) to transfer the HDLC data.
>
> Signed-off-by: Herve Codina
> Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
On Thu, 28 Sep 2023 09:06:42 +0200 Herve Codina wrote:
> +menu "Framer Subsystem"
> +
> +config GENERIC_FRAMER
> + bool "Framer Core"
> + help
> + Generic Framer support.
> + A framer is a component in charge of an E1/T1 line interface.
> + Connected usually to a TDM bus,
On Thu, 28 Sep 2023 09:06:44 +0200 Herve Codina wrote:
> + for (i = 0; i < count; i++) {
> + (audio_devs + i)->name = "framer-codec";
> + (audio_devs + i)->of_compatible = compatible;
> + (audio_devs + i)->id = i;
Why not array notation?
> + }
> +
> +
On Thu, 28 Sep 2023 09:06:28 +0200 Herve Codina wrote:
> +static int qmc_hdlc_close(struct net_device *netdev)
> +{
> + struct qmc_hdlc *qmc_hdlc = netdev_to_qmc_hdlc(netdev);
> + struct qmc_hdlc_desc *desc;
> + int i;
> +
> + netif_stop_queue(netdev);
> +
> + qmc_chan_stop(qmc_
On Thu, 5 Oct 2023 18:11:56 +0200 Eric Dumazet wrote:
> OK, but I suspect some users of napi_reschedule() might not be race-free...
What's the race you're thinking of?
On Mon, 2 Oct 2023 17:10:20 +0200 Christian Marangi wrote:
> queue_work(priv->xfer_wq, &priv->rx_work);
> - else if (napi_schedule_prep(&priv->napi))
> - __napi_schedule(&priv->napi);
> + else
> + napi_schedule(&
On Mon, 28 Aug 2023 15:12:35 +0300 Alexandra Diupina wrote:
> Process the result of hold_open() and return it from
> uhdlc_open() in case of an error
> It is necessary to pass the error code up the control flow,
> similar to a possible error in request_irq()
>
> Found by Linux Verification Center
On Mon, 21 Aug 2023 05:19:22 + Christophe Leroy wrote:
> As I said in the cover letter, this series only fixes critical build
> failures that happened when CONFIG_MODULES is set. The purpose was to
> allow robots to perform their job up to the end. Other feedback and
> comments will be taken
On Fri, 18 Aug 2023 18:39:15 +0200 Christophe Leroy wrote:
> From: Herve Codina
>
> A framer is a component in charge of an E1/T1 line interface.
> Connected usually to a TDM bus, it converts TDM frames to/from E1/T1
> frames. It also provides information related to the E1/T1 line.
Okay, progres
On Wed, 9 Aug 2023 15:27:27 +0200 Herve Codina wrote:
> The series contains the full story and detailed modifications.
> If needed, the series can be split and/or commmits can be squashed.
> Let me know.
Are there any dependencies in one of the -next trees?
As it the series doesn't seem to build
On Tue, 25 Jul 2023 11:23:36 +0200 Herve Codina wrote:
> I have a system where I need to handle an HDLC interface and some audio
> data.
The new code must build cleanly with C=1 W=1, after every individual
patch.
--
pw-bot: cr
On Fri, 21 Jul 2023 12:26:32 -0400 Steven Rostedt wrote:
> > if (!(in_hardirq() || irqs_disabled()))
> >
>
> Yeah, probably.
>
> > , nothing more elegant / already existing / ...?
>
> It's not a common check. What would you call that?
Looks like Olek started the weekend already so let me a
On Wed, 14 Jun 2023 21:02:33 -0700 Randy Dunlap wrote:
> On 6/14/23 20:52, Jakub Kicinski wrote:
> > Randy forwarded report from Stephen that on PowerPC:
>
> Stephen forwarded report from Randy?
>
> netdev & pantelis were cc-ed...
Ah, I misread, you were reporting
d, I can't repro this warning myself. With or without
the patch mpc512x_defconfig builds just fine.
Link:
https://lore.kernel.org/all/8f9f8d38-d9c7-9f1b-feb0-103d76902...@infradead.org/
Signed-off-by: Jakub Kicinski
---
CC: Randy Dunlap
CC: pantelis.anton...@gmail.com
CC: linuxppc-dev@lists.o
On Tue, 14 Mar 2023 14:18:27 -0500 Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties.
> Convert reading boolean properties to of_property_read_boo
://bugzilla.kernel.org/show_bug.cgi?id=217151
Fixes: d5e2d038dbec ("eth: fealnx: delete the driver for Myson MTD-800")
Signed-off-by: Jakub Kicinski
---
CC: tsbog...@alpha.franken.de
CC: m...@ellerman.id.au
CC: npig...@gmail.com
CC: christophe.le...@csgroup.eu
CC: lukas.bulw...@gmail.com
CC: step...@networkp
caller.
>
> This change is for macio bus based drivers.
>
> Signed-off-by: Dawei Li
Acked-by: Jakub Kicinski
On Thu, 26 Jan 2023 16:22:05 +0100 Luca Ceresoli wrote:
> Fix typos and add the following to the scripts/spelling.txt:
>
> exsits||exists
>
> Signed-off-by: Luca Ceresoli
You need to split this up per subsystem, I reckon :(
On Wed, 11 Jan 2023 22:55:33 +0300 Esina Ekaterina wrote:
> Signed-off-by: Esina Ekaterina
> ---
This --- is still indented.
On top of that please tag the patch for the tree to which networking
maintainers apply fixes (by specifying [PATCH net v5] instead just
[PATCH v5] in the subject).
And
On Wed, 11 Jan 2023 12:05:03 +0300 Esina Ekaterina wrote:
> Subject: [PATCH v3] net: wan: Add checks for NULL for utdm in
> undo_uhdlc_init and unmap_si_regs
net: wan: prevent null-deref on error path for non-tdm case
> If uhdlc_priv_tsa != 1 then utdm is not initialized.
> And if ret != N
On Tue, 10 Jan 2023 14:47:45 +0300 Esina Ekaterina wrote:
> Subject: [PATCH v2] net: wan: Add checks for NULL. If uhdlc_priv_tsa != 1
> then utdm is not initialized. And if ret != NULL then goto undo_uhdlc_init,
> where utdm is dereferenced. Same if dev == NULL.
>
> Found by Linux Verification Ce
On Fri, 6 Jan 2023 18:04:54 -0800 Anirudh Venkataramanan wrote:
> >> In a recent patch series that touched these drivers [1], it was suggested
> >> that these drivers should be removed completely. git logs suggest that
> >> there hasn't been any significant feature addition, improvement or fixes
>
On Fri, 23 Dec 2022 10:30:36 +1100 Michael Ellerman wrote:
> The commit it Fixes went in via the networking tree, so I think it would
> make sense for you to take this also via the networking tree.
Roger that, thanks for confirming.
On Thu, 22 Dec 2022 15:41:00 + Camelia Alexandra Groza wrote:
> > Reviewed-by: Camelia Groza
> > Tested-by: Camelia Groza
>
> I see the patch marked Not Applicable in the netdev patchwork.
> What tree will it go through?
I could be wrong but I think DTS patches are supposed to go via the
On Tue, 25 Oct 2022 16:04:15 -0700 Doug Berger wrote:
> > On Wed, 26 Oct 2022 01:17:48 +0800 kernel test robot wrote:
> >> drivers/net/ethernet/broadcom/genet/bcmgenet.c:1497:5-13: ERROR: invalid
> >> reference to the index variable of the iterator on line 1475
> >
> > CC Doug
> Thanks for
On Wed, 26 Oct 2022 01:17:48 +0800 kernel test robot wrote:
> drivers/net/ethernet/broadcom/genet/bcmgenet.c:1497:5-13: ERROR: invalid
> reference to the index variable of the iterator on line 1475
CC Doug
The git history for this driver seems to be completely
automated / tree wide changes. I can't find any boards
or systems which would use this chip. Google search
shows pictures of towel warmers and no networking products.
Signed-off-by: Jakub Kicinski
---
CC: tsbog...@alpha.franken.de
On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote:
> On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote:
> > But whatever. I mean - hopefully there aren't any conflicts in the ~50
> > networking files you touch. I just wish that people didn't pipe
On Sat, 22 Oct 2022 00:23:00 -0400 Jason A. Donenfeld wrote:
> > How big is it? Can you provide a stable branch to pull in the new
> > helpers and then everyone will be able to apply the patches to their
> > subsystem?
>
> It's a patch. But what you suggest sounds crazy to me. Supply some
> bra
On Fri, 21 Oct 2022 21:43:58 -0400 Jason A. Donenfeld wrote:
> Since get_random_u32_below() sits in my random.git tree, these patches
> too will flow through that same tree.
How big is it? Can you provide a stable branch to pull in the new
helpers and then everyone will be able to apply the patch
ay "non-uniform", because it doesn't do any rejection sampling or
> divisions. Hence, it stays within the prandom_* namespace.
Acked-by: Jakub Kicinski
On Tue, 4 Oct 2022 11:28:19 -0400 Sean Anderson wrote:
> I noticed that this series was marked "RFC" in patchwork.
Because the cover letter has RTF in the subject, presumably.
> I consider this series ready to apply. I am requesting *testing*, in
> particular on 10gec/dtsec boards (P-series). Sin
On Thu, 18 Aug 2022 23:00:34 +0200 Wolfram Sang wrote:
> 261 files changed, 568 insertions(+), 568 deletions(-)
Unfortunately looks like patchwork was unable to ingest this change :(
Not sure why.
Would you mind splitting it into 3 chunks - wireless, ethernet,
everything else, and resending? Let
On Thu, 18 Aug 2022 15:14:04 -0400 Sean Anderson wrote:
> > Ack, no question. I'm trying to tell you got to actually get stuff in.
> > It's the first week after the merge window and people are dumping code
> > the had written over the dead time on the list, while some reviewers
> > and maintainers
On Thu, 18 Aug 2022 14:37:23 -0400 Sean Anderson wrote:
> On 8/18/22 2:20 PM, Jakub Kicinski wrote:
> > On Thu, 18 Aug 2022 12:16:24 -0400 Sean Anderson wrote:
> >> This series contains several cleanup patches for dpaa/fman. While they
> >> are intended to prepare for
On Thu, 18 Aug 2022 12:16:24 -0400 Sean Anderson wrote:
> This series contains several cleanup patches for dpaa/fman. While they
> are intended to prepare for a phylink conversion, they stand on their
> own. This series was originally submitted as part of [1].
Still over the limit of patches in a
On Mon, 25 Jul 2022 11:10:14 -0400 Sean Anderson wrote:
> This series contains several cleanup patches for dpaa/fman. While they
> are intended to prepare for a phylink conversion, they stand on their
> own. This series was originally submitted as part of [1].
https://www.kernel.org/doc/html/lates
On Sat, 21 May 2022 10:44:30 -0700 Jakub Kicinski wrote:
> > Well, I say the contrary.
> >
> > On the mainline the patch may be applied as is, it won't harm.
> >
> > However, it is gets applied to kernel 4.9 (based on the fixes: tag), it
> > will
On Sat, 21 May 2022 06:44:41 + Christophe Leroy wrote:
> > Hm, I think the patch is necessary, sorry if you're also saying that
> > and I'm misinterpreting.
>
> Well, I say the contrary.
>
> On the mainline the patch may be applied as is, it won't harm.
>
> However, it is gets applied to k
On Fri, 20 May 2022 12:54:56 + Christophe Leroy wrote:
> Le 20/05/2022 à 14:35, Måns Rullgård a écrit :
> > Christophe Leroy writes:
> >> See original commit 070e1f01827c. It explicitely says that the cache
> >> must be invalidate _AFTER_ the copy.
> >>
> >> The cache is initialy invalidated b
A handful of WAN drivers use custom napi weights,
switch them to the new API.
Signed-off-by: Jakub Kicinski
---
CC: qiang.z...@nxp.com
CC: k...@pm.waw.pl
CC: m...@dev.tdt.de
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-...@vger.kernel.org
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
drivers/net
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Acked-by: Geoff Levand
Signed-off-by: Jakub Kicinski
---
CC: kou.ishiz...@toshiba.co.jp
CC: linuxppc-dev@lists.ozlabs.org
---
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
drivers
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Signed-off-by: Jakub Kicinski
---
CC: kou.ishiz...@toshiba.co.jp
CC: ge...@infradead.org
CC: linuxppc-dev@lists.ozlabs.org
---
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
drivers
he intention is for Andrew to take this
one, so FWIW:
Acked-by: Jakub Kicinski
On Fri, 15 Apr 2022 14:08:10 -0500 Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Only alpha, ia64, powerpc, and sh define SLOW_DOWN_IO, and there are no
> actual uses of it. The few references to it are in situations that are
> themselves unused. Remove them all.
>
> It should be safe to appl
1 - 100 of 169 matches
Mail list logo
