On Wed, 23 May 2018 16:07:40 +0530, Sandipan Das wrote:
> "name": "bpf_prog_196af774a3477707_F",
> "insns": [{
> "pc": "0x0",
> "operation": "nop",
> "operands": [null
> ]
> },{
> "pc":
for each JIT image dump
> otherwise the masked start address is printed.
...
> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com>
Reviewed-by: Jakub Kicinski <jakub.kicin...@netronome.com>
Thank you!
On Tue, 22 May 2018 22:46:10 +0530, Sandipan Das wrote:
> Currently, for multi-function programs, we cannot get the JITed
> instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD
> command. Because of this, userspace tools such as bpftool fail
> to identify a multi-function program as
On Tue, 22 May 2018 22:46:13 +0530, Sandipan Das wrote:
> + if (info.nr_jited_func_lens && info.jited_func_lens) {
> + struct kernel_sym *sym = NULL;
> + unsigned char *img = buf;
> + __u64 *ksyms = NULL;
> +
r all the JITed
> functions is provided in the program info. We now use the imm
> field as an index for this list to lookup a callee's symbol's
> address and resolve its name.
>
> Suggested-by: Daniel Borkmann <dan...@iogearbox.net>
> Signed-off-by: Sandipan Das <san
On Fri, 18 May 2018 18:20:38 +0530, Sandipan Das wrote:
> Currently, we resolve the callee's address for a JITed function
> call by using the imm field of the call instruction as an offset
> from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further
> use this address to get the callee's
On Thu, 17 May 2018 12:05:47 +0530, Sandipan Das wrote:
> Currently, we resolve the callee's address for a JITed function
> call by using the imm field of the call instruction as an offset
> from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further
> use this address to get the callee's
On Wed, 24 Oct 2018 07:35:48 +, Corentin Labbe wrote:
> This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and
> setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header.
>
> Signed-off-by: Corentin Labbe
Did you have a look at all the functions defined in bitfield.h?
On Tue, 6 Aug 2019 11:23:08 -0500, Thomas Falcon wrote:
> Reported ethtool link settings for the ibmveth driver are currently
> hardcoded and no longer reflect the actual capabilities of supported
> hardware. There is no interface designed for retrieving this information
> from device firmware
On Wed, 11 Dec 2019 09:38:39 -0600, Thomas Falcon wrote:
> This conditional is missing a bang, with the intent
> being to break when the retry count reaches zero.
>
> Fixes: 476d96ca9c ("ibmvnic: Bound waits for device queries")
> Suggested-by: Juliet Kim
> Signed-off-by: Thomas Falcon
Ah
On Wed, 20 Nov 2019 12:14:51 +1100, Michael Ellerman wrote:
> From: Eric Dumazet
>
> A patch in net-next triggered a compile error on powerpc:
>
> include/linux/u64_stats_sync.h: In function 'u64_stats_read':
> include/asm-generic/local64.h:30:37: warning: passing argument 1 of
>
On Mon, 25 Nov 2019 12:40:42 -0600, Thomas Falcon wrote:
> On 11/23/19 7:49 PM, Jakub Kicinski wrote:
> > On Fri, 22 Nov 2019 13:41:42 -0600, Thomas Falcon wrote:
> >> This patch series fixes some shortcomings with the current
> >> VNIC device command implementa
On Fri, 22 Nov 2019 13:41:42 -0600, Thomas Falcon wrote:
> This patch series fixes some shortcomings with the current
> VNIC device command implementation. The first patch fixes
> the initialization of driver completion structures used
> for device commands. Additionally, all waits for device
>
On Fri, 22 Nov 2019 13:41:45 -0600, Thomas Falcon wrote:
> +static int ibmvnic_wait_for_completion(struct ibmvnic_adapter *adapter,
> +struct completion *comp_done,
> +unsigned long timeout)
> +{
> + struct net_device
On Fri, 22 Nov 2019 13:41:46 -0600, Thomas Falcon wrote:
> @@ -5050,6 +5090,7 @@ static int ibmvnic_probe(struct vio_dev *dev, const
> struct vio_device_id *id)
> __ibmvnic_delayed_reset);
> INIT_LIST_HEAD(>rwi_list);
> spin_lock_init(>rwi_lock);
> +
On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote:
> On 02 February 2020 at 09:19 am, Christophe Leroy wrote:
> > Hello,
> >
> > Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
> >> Hello,
> >>
> >> We regularly compile and test Linux kernels every day during the
> >> merge
On Mon, 7 Sep 2020 12:31:40 -0400 Sasha Levin wrote:
> [ Upstream commit 9f13457377907fa253aef560e1a37e1ca4197f9b ]
> @@ -2024,10 +2033,14 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> } else {
> rc = reset_tx_pools(adapter);
>
On Mon, 17 Aug 2020 13:54:20 +0530 Allen Pais wrote:
> In preparation for unconditionally passing the
> struct tasklet_struct pointer to all tasklet
> callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> Signed-off-by: Romain Perier
On Mon, 17 Aug 2020 13:54:22 +0530 Allen Pais wrote:
> In preparation for unconditionally passing the
> struct tasklet_struct pointer to all tasklet
> callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> Signed-off-by: Romain Perier
On Wed, 27 May 2020 15:14:41 +0200 Emanuele Giuseppe Esposito wrote:
> Regarding the config, as I said the idea is to gather multiple
> subsystems' statistics, therefore there wouldn't be a single
> configuration method like in netlink.
> For example in kvm there are file descriptors for
On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote:
> > Again, I have little KVM knowledge, but BPF also uses a fd-based API,
> > and carries stats over the same syscall interface.
>
> Can BPF stats (for BPF scripts created by whatever process is running in
> the system) be collected by an
On Tue, 26 May 2020 13:03:10 +0200 Emanuele Giuseppe Esposito wrote:
> There is currently no common way for Linux kernel subsystems to expose
> statistics to userspace shared throughout the Linux kernel; subsystems have
> to take care of gathering and displaying statistics by themselves, for
>
On Fri, 23 Oct 2020 14:32:36 +1100 Michael Ellerman wrote:
> Clang warns about the extra parentheses in this comparison:
>
> drivers/net/ethernet/freescale/ucc_geth.c:1361:28:
> warning: equality comparison with extraneous parentheses
> if ((ugeth->phy_interface ==
On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> From: Thomas Bogendoerfer
>
> The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> Commit 6f2275433a2f wanted to shut down messages for loopback packets,
> but now suppresses bridged frames, which are accepted by
On Mon, 26 Oct 2020 20:04:07 +0100 Thomas Bogendoerfer wrote:
> > On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> > > From: Thomas Bogendoerfer
> > >
> > > The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> > > Commit 6f2275433a2f wanted to shut down
On Wed, 29 Jul 2020 16:36:32 -0500 Thomas Falcon wrote:
> RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
> error paths. Fix this and dispose of TX IRQ mappings correctly in
> case of an error.
>
> Signed-off-by: Thomas Falcon
Thomas, please remember about Fixes tags (for
On Thu, 18 Jun 2020 10:43:46 -0500 Thomas Falcon wrote:
> The max MTU limit defined for ibmveth is not accounting for
> virtual ethernet buffer overhead, which is twenty-two additional
> bytes set aside for the ethernet header and eight additional bytes
> of an opaque handle reserved for use by
On Wed, 15 Jul 2020 18:51:55 -0500 Thomas Falcon wrote:
> free_netdev(netdev);
> dev_set_drvdata(>dev, NULL);
> + netdev_info(netdev, "VNIC client device has been successfully
> removed.\n");
A step too far, perhaps.
In general this patch looks a little questionable IMHO, this
On Thu, 16 Jul 2020 18:07:37 +0200 Michal Suchánek wrote:
> On Thu, Jul 16, 2020 at 10:59:58AM -0500, Thomas Falcon wrote:
> > On 7/15/20 8:29 PM, David Miller wrote:
> > > From: Jakub Kicinski
> > > Date: Wed, 15 Jul 2020 17:06:32 -0700
> > >
> &
On Thu, 26 Nov 2020 13:38:45 + Lee Jones wrote:
> Resending the stragglers.
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
This set doesn't apply to net-next, please rebase.
On Sat, 28 Nov 2020 12:28:19 +1100 Stephen Rothwell wrote:
> There are 2 drivers that have arrays of packed structures that contain
> pointers that end up at unaligned offsets. These produce warnings in
> the PowerPC allyesconfig build like this:
>
> WARNING: 148 bad relocations
>
On Wed, 18 Nov 2020 19:12:16 -0600 Thomas Falcon wrote:
> The first three patches utilize a hypervisor call allowing multiple
> TX and RX buffer replenishment descriptors to be sent in one operation,
> which significantly reduces hypervisor call overhead. The xmit_more
> and Byte Queue Limit
On Sat, 5 Dec 2020 20:17:34 +0100 Rasmus Villemoes wrote:
> - unregister_netdev(dev);
> - free_netdev(dev);
> ucc_geth_memclean(ugeth);
> if (of_phy_is_fixed_link(np))
> of_phy_deregister_fixed_link(np);
> of_node_put(ugeth->ug_info->tbi_node);
>
On Sat, 5 Dec 2020 20:17:23 +0100 Rasmus Villemoes wrote:
> While trying to figure out how to allow bumping the MTU with the
> ucc_geth driver, I fell into a rabbit hole and stumbled on a whole
> bunch of issues of varying importance - some are outright bug fixes,
> while most are a matter of
On Sat, 5 Dec 2020 22:04:28 +0100 Rasmus Villemoes wrote:
> On 05/12/2020 21.48, Jakub Kicinski wrote:
> > On Sat, 5 Dec 2020 20:17:34 +0100 Rasmus Villemoes wrote:
> >> - unregister_netdev(dev);
> >> - free_netdev(dev);
> >>ucc_geth_memclean(ugeth);
On Sat, 5 Dec 2020 22:11:39 +0100 Rasmus Villemoes wrote:
> > Looks like a nice clean up on a quick look.
> >
> > Please separate patches 1 and 11 (which are the two bug fixes I see)
>
> I think patch 2 is a bug fix as well, but I'd like someone from NXP to
> comment.
Sure, makes sense.
> >
On Sat, 28 Nov 2020 16:20:54 +1100 Stephen Rothwell wrote:
> On Fri, 27 Nov 2020 17:56:42 -0800 Jakub Kicinski wrote:
> >
> > What's the offending structure in hisilicon? I'd rather have a look
> > packing structs with pointers in 'em sounds questionable.
> >
On Wed, 25 Nov 2020 18:04:23 -0600 Dany Madden wrote:
> Assorted fixes for ibmvnic originated from "[PATCH net 00/15] ibmvnic:
> assorted bug fixes" sent by Lijun Pan.
Applied, thanks!
On Mon, 30 Nov 2020 13:07:22 -0600 Thomas Falcon wrote:
> This series resolves a few issues in the ibmvnic driver's
> RX buffer and TX completion processing. The first patch
> includes memory barriers to synchronize queue descriptor
> reads. The second patch fixes a memory leak that could
> occur
On Thu, 12 Nov 2020 13:09:56 -0600 Thomas Falcon wrote:
> Ensure that received Subordinate Command-Response Queue
> entries are properly read in order by the driver.
>
> Signed-off-by: Thomas Falcon
Are you sure this is not a bug fix?
On Thu, 12 Nov 2020 13:09:57 -0600 Thomas Falcon wrote:
> This patch introduces the infrastructure to send batched subordinate
> Command Response Queue descriptors, which are used by the ibmvnic
> driver to send TX frame and RX buffer descriptors.
>
> Signed-off-by: Thomas Falcon
> @@ -2957,6
On Thu, 12 Nov 2020 13:09:59 -0600 Thomas Falcon wrote:
> Include support for the xmit_more feature utilizing the
> H_SEND_SUB_CRQ_INDIRECT hypervisor call which allows the sending
> of multiple subordinate Command Response Queue descriptors in one
> hypervisor call via a DMA-mapped buffer. This
On Mon, 16 Nov 2020 12:28:05 -0600 Thomas Falcon wrote:
> On 11/14/20 5:35 PM, Jakub Kicinski wrote:
> > On Thu, 12 Nov 2020 13:09:56 -0600 Thomas Falcon wrote:
> >> Ensure that received Subordinate Command-Response Queue
> >> entries are properly read in order by t
On Fri, 6 Nov 2020 14:17:45 -0500 Dany Madden wrote:
> This reverts commit 16b5f5ce351f8709a6b518cc3cbf240c378305bf
> where it restructures do_reset. There are patches being tested that
> would require major rework if this is committed first.
>
> We will resend this after the other patches have
On Tue, 27 Oct 2020 23:54:39 +0100 Sebastian Andrzej Siewior wrote:
> Folks,
>
> in the discussion about preempt count consistency across kernel
> configurations:
>
> https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
>
> Linus clearly requested that code in drivers and
r and NAPI should be scheduled.
>
> Signed-off-by: Sebastian Andrzej Siewior
> Cc: "Horia Geantă"
> Cc: Aymen Sghaier
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Madalin Bucur
> Cc: Jakub Kicinski
> Cc: Li Yang
> Cc: linux-cry...@vger.kernel.org
On Tue, 27 Oct 2020 23:54:39 +0100 Sebastian Andrzej Siewior wrote:
> Folks,
>
> in the discussion about preempt count consistency across kernel
> configurations:
>
> https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
>
> Linus clearly requested that code in drivers and
ady so
> using it for the lock variant decision is a straight forward replacement
> for in_irq().
>
> Signed-off-by: Sebastian Andrzej Siewior
> Cc: Saeed Mahameed
> Cc: Leon Romanovsky
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Cc: linux-r...@vger.kernel.org
Saeed, please pick this up into your tree.
On Fri, 06 Nov 2020 13:30:25 -0600 ljp wrote:
> On 2020-11-06 13:17, Dany Madden wrote:
> > This reverts commit 16b5f5ce351f8709a6b518cc3cbf240c378305bf
> > where it restructures do_reset. There are patches being tested that
> > would require major rework if this is committed first.
> >
> > We
On Thu, 14 Jan 2021 08:33:49 + Lee Jones wrote:
> On Wed, 13 Jan 2021, Jakub Kicinski wrote:
>
> > On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> > > Resending
On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> Resending the stragglers again.
>
>
> This set is part of a larger effort attempting to clean-up W=1
>
>
On Fri, 15 Jan 2021 13:38:48 + Lee Jones wrote:
> Okay, so what would you like me to do? Would you like me to re-submit
> the set based only on net-next
Yes, rebase your patches on net-next, recheck everything builds okay
and resubmit. You should always develop against the tree that will
On Mon, 22 Feb 2021 16:02:21 +0800 Yang Li wrote:
> fixed the following coccicheck:
> ./drivers/net/ethernet/ibm/ibmveth.c:1805:51-52: WARNING opportunity for
> kobj_to_dev()
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
# Form letter - net-next is closed
We have already sent the
We'll want to make netdev->dev_addr const, remove the local
helper which is missing a const qualifier on the argument
and use ether_addr_to_u64().
Similar story to mlx4.
Signed-off-by: Jakub Kicinski
---
CC: cforn...@linux.ibm.com
CC: m...@ellerman.id.au
CC: b...@kernel.crashing.org
CC:
On Wed, 5 Jan 2022 13:56:53 +0530 Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
> Powerpc LPAR
>
> Perform below dlpar commands in a loop from linux OS
>
> drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
> drmgr -a -c slot -s
On Mon, 3 Jan 2022 19:10:01 +0530 Abdul Haleem wrote:
> Greeting's
>
> Today's netdev/net-next kernel 5.16.0-rc7 failed to build on my powerpc box
> with below error
>
> CC [M] drivers/net/ethernet/mellanox/mlx5/core/en_main.o
> In file included from
^
>
> Fix it by making the modifications to a local macaddr variable and then
> passing that to eth_hw_addr_set(), as well as adding some missing const
> qualifiers.
>
> Signed-off-by: Michael Ellerman
Reviewed-by: Jakub Kicinski
ns to a local macaddr variable and then
> passing that to eth_hw_addr_set().
>
> We don't use the existing addr variable because the bitrev8() would
> mutate it, but it is already used unreversed later in the function.
>
> Signed-off-by: Michael Ellerman
Reviewed-by: Jakub Kicinski
Thank you!
On Wed, 16 Mar 2022 11:49:39 + Manish Chopra wrote:
> As ethtool over netlink has some limitations of the size,
> I believe you can configure ethtool with "--disable-netlink" and set those
> message levels fine
Yup, IIUC it works for Paul on a 5.17 system, that system likely has
old ethtool
On Wed, 16 Mar 2022 19:52:32 +0100 Michal Kubecek wrote:
> > Yup, IIUC it works for Paul on a 5.17 system, that system likely has
> > old ethtool user space tool which uses ioctls instead of netlink.
> >
> > What makes the netlink path somewhat non-trivial is that there is
> > an expectation
On Tue, 15 Mar 2022 22:58:57 +0100 Paul Menzel wrote:
> On the POWER8 server IBM S822LC (ppc64le), I am unable to set the
> message level for the network device to 0x010 but it fails.
>
> $ sudo ethtool -s enP1p1s0f2 msglvl 0x010
> netlink error: cannot modify bits past kernel
On Mon, 28 Feb 2022 16:41:04 -0800 Linus Torvalds wrote:
> So yes, initially my idea had been to just move the iterator entirely
> inside the macro. But specifying the type got so ugly that I think
> that
>
> typeof (pos) pos
>
> trick inside the macro really ends up giving us the best
On Mon, 28 Mar 2022 13:51:42 +0200 Benjamin Stürz wrote:
> > Just a small tip: If you are new, start with something small and learn
> > from that. Don't do a controversial big patchset spanning multiple
> > subsystems, that's the hard way to learn things. First submit one patch
> > at a time to
On Mon, 17 Jan 2022 15:00:41 +0100 Andrew Lunn wrote:
> > Should I send a v2 even if nothing else
> > pops up, or is this more of a if-you're-sending-a-v2-anyway type of
> > comment?
>
> If you reply with a Fixes: patchwork will automagically append it like
> it does Reviewed-by, Tested-by etc.
On Mon, 24 Jan 2022 08:55:40 +0100 (CET) Geert Uytterhoeven wrote:
> > + /kisskb/src/drivers/net/ethernet/freescale/fec_mpc52xx.c: error: passing
> > argument 2 of 'mpc52xx_fec_set_paddr' discards 'const' qualifier from
> > pointer target type [-Werror=discarded-qualifiers]: => 659:29
>
>
On Mon, 24 Jan 2022 09:04:33 -0800 Jakub Kicinski wrote:
> On Mon, 24 Jan 2022 08:55:40 +0100 (CET) Geert Uytterhoeven wrote:
> > > + /kisskb/src/drivers/net/ethernet/freescale/fec_mpc52xx.c: error:
> > > passing argument 2 of 'mpc52xx_fec_set_paddr' discards 'const'
On Tue, 12 Apr 2022 14:15:53 +0200 Jakob Koschel wrote:
> - struct list_head *head = >rss_context.list;
> + struct list_head *head = *pos = >rss_context.list;
ENOTBUILT, please wait with the reposting. Since you posted two
versions today I guess that's 2x 24h? :)
On Thu, 7 Apr 2022 12:28:47 +0200 Jakob Koschel wrote:
> diff --git a/drivers/net/dsa/sja1105/sja1105_vl.c
> b/drivers/net/dsa/sja1105/sja1105_vl.c
> index b7e95d60a6e4..cfcae4d19eef 100644
> --- a/drivers/net/dsa/sja1105/sja1105_vl.c
> +++ b/drivers/net/dsa/sja1105/sja1105_vl.c
> @@ -27,20
On Sat, 9 Apr 2022 01:58:29 +0200 Jakob Koschel wrote:
> > This turns a pretty slick piece of code into something ugly :(
> > I'd rather you open coded the iteration here than make it more
> > complex to satisfy "safe coding guidelines".
>
> I'm not entirely sure I understand what you mean
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
On Mon, 2 Oct 2023 17:10:20 +0200 Christian Marangi wrote:
> queue_work(priv->xfer_wq, >rx_work);
> - else if (napi_schedule_prep(>napi))
> - __napi_schedule(>napi);
> + else
> + napi_schedule(>napi)
Missing
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);
> +
> +
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 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!
ff the framer
> - get the framer status (line state)
> - be notified on framer status changes
> - get/set the framer configuration
Acked-by: Jakub Kicinski
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
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
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
Codina
> Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
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
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,
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 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
e the intention is for Andrew to take this
one, so FWIW:
Acked-by: Jakub Kicinski
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 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
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
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 break
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].
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.
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
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
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 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 prepa
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?
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 up with
&g
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
>
1 - 100 of 130 matches
Mail list logo
