ssible to have happen.
Please stop submitting known-invalid patches. Your professor is playing
around with the review process in order to achieve a paper in some
strange and bizarre way.
This is not ok, it is wasting our time, and we will have to report this,
AGAIN, to your university...
greg k-h
On Wed, Apr 14, 2021 at 10:49:41AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> UIO HV driver should not load in the isolation VM for security reason.
> Return ENOTSUPP in the hv_uio_probe() in the isolation VM.
>
> Signed-off-by: Tianyu Lan
> ---
> drivers/uio/uio_hv_generic.c | 5 +
>
On Wed, Apr 14, 2021 at 09:56:30AM +0200, Heiner Kallweit wrote:
> On 14.04.2021 09:49, Greg KH wrote:
> > On Wed, Apr 14, 2021 at 09:40:51AM +0200, Heiner Kallweit wrote:
> >> It has been reported [0] that using pause frames in jumbo mode impacts
> >> performance
On Wed, Apr 14, 2021 at 09:40:51AM +0200, Heiner Kallweit wrote:
> It has been reported [0] that using pause frames in jumbo mode impacts
> performance. There's no available chip documentation, but vendor
> drivers r8168 and r8125 don't advertise pause in jumbo mode. So let's
> do the same, accordi
ase break
this up into "one config option change per patch" to make it easier to
review and get merged through the proper subsystem.
thanks,
greg k-h
anges
> Signed-off-by: Nico Pache
Please put a blank line before your signed-off-by, as is required by the
tools :(
thanks,
greg k-h
g
Signed-off-by: Dmitry Safonov
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_compat.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/net/xfrm/xfrm_compat.c
+++ b/net/xfrm/xfrm_compat.c
@@ -216,7 +216,7 @@ static struct
g
Signed-off-by: Dmitry Safonov
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_compat.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/net/xfrm/xfrm_compat.c
+++ b/net/xfrm/xfrm_compat.c
@@ -216,7 +216,7 @@ static struct
ed in
> > > > 4.14.226
> > > >
> > > > --> ce59ffca5c49 ("can: flexcan: enable RX FIFO after FRZ/HALT valid")
> > > > --> bb7c9039a396 ("can: flexcan: assert FRZ bit in
> > > > flexcan_chip_freeze()")
> > > >
> >
reeze()")
> >
> > Reverting these fixes the splat.
>
> This patch should fix the problem:
>
> 47c5e474bc1e can: flexcan: flexcan_chip_freeze(): fix chip freeze for missing
> bitrate
>
> Greg, can you pick this up for v4.14?
Now queued up, thanks.
greg k-h
On Thu, Apr 08, 2021 at 07:11:48PM +, Jianmin Wang wrote:
> On Mon, Apr 05, 2021 at 16:14 UTC, Greg KH wrote:
> > On Mon, Apr 05, 2021 at 01:55:15PM +, Jianmin Wang wrote:
> > > There is same problem found in linux 4.19.y as upstream commit. The
> > > c
On Thu, Apr 08, 2021 at 12:10:42PM +0300, Eli Cohen wrote:
> Hi Michael,
>
> The following series contains fixes to mlx5 vdpa driver. Included first
> is Siwei's fix to queried MTU was already reviewed a while ago and is
> not in your tree.
>
> Patches 2 and 3 are required to allow mlx5_vdpa run
ee minor" isn't really needed now
that we have a data structure that does this all for us :)
But that's not going to fix this issue, that's for future changes.
thanks,
greg k-h
hould have corresponding
> release_minor() call.
>
> Reported-by: syzbot+c49fe6089f295a05e...@syzkaller.appspotmail.com
> Tested-by: syzbot+c49fe6089f295a05e...@syzkaller.appspotmail.com
>
> Signed-off-by: Anirudh Rayabharam
Reviewed-by: Greg Kroah-Hartman
ny non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Change looks correct to me, thanks!
greg k-h
se a newer kernel version?
What is preventing you from doing that?
thanks,
greg k-h
From: Stefan Metzmacher
[ Upstream commit 0031275d119efe16711cd93519b595e6f9b4b330 ]
Without that it's not safe to use them in a linked combination with
others.
Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
should be possible.
We already handle short reads and writes for
From: Stefan Metzmacher
[ Upstream commit 0031275d119efe16711cd93519b595e6f9b4b330 ]
Without that it's not safe to use them in a linked combination with
others.
Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
should be possible.
We already handle short reads and writes for
On Fri, Apr 02, 2021 at 05:41:01PM +0200, Loic Poulain wrote:
> On Fri, 2 Apr 2021 at 16:05, Greg KH wrote:
> >
> > On Fri, Apr 02, 2021 at 04:06:37PM +0200, Loic Poulain wrote:
> > > The MHI WWWAN control driver allows MHI QCOM-based modems to expose
> > > differ
ht after this check? Did you just miss the
call?
> +static const struct mhi_device_id mhi_wwan_ctrl_match_table[] = {
> + { .chan = "DUN", .driver_data = WWAN_PORT_AT },
> + { .chan = "MBIM", .driver_data = WWAN_PORT_MBIM },
> + { .chan = "QMI", .driver_data = WWAN_PORT_QMI },
> + { .chan = "DIAG", .driver_data = WWAN_PORT_QCDM },
> + { .chan = "FIREHOSE", .driver_data = WWAN_PORT_FIREHOSE },
Wait, I thought these were all going to be separate somehow. Now they
are all muxed back together?
totally confused,
greg k-h
_count;
> + unsigned long flags;
> + const struct wwan_port_ops *ops;
> + struct mutex ops_lock;
> + struct device dev;
> + struct sk_buff_head rxq;
> + wait_queue_head_t waitqueue;
> +};
No need to put the actual definition of struct wwan_port in this .h
file, keep it private in your .c file to keep wwan drivers from poking
around in it where they shouldn't be :)
thanks,
greg k-h
this up by wwan type and handle that in the "core" you are
creating properly, and then have your hardware driver tie into that.
Just like all other common class api interfaces, nothing new here...
thanks,
greg k-h
On Wed, Mar 31, 2021 at 09:19:29AM -0300, Jason Gunthorpe wrote:
> On Wed, Mar 31, 2021 at 08:38:39AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Mar 30, 2021 at 07:43:41PM -0300, Jason Gunthorpe wrote:
> > > > With :01:00.0/sriov/BB:DD.F/vf_msix_count, sriov/ will conta
On Wed, Mar 31, 2021 at 01:35:04PM +0200, Loic Poulain wrote:
> Hi Greg,
>
> On Wed, 31 Mar 2021 at 12:44, Greg KH wrote:
> >
> > On Wed, Mar 31, 2021 at 12:39:09PM +0200, Loic Poulain wrote:
> > > This change introduces initial support for a WWAN subsystem.
re.c
> @@ -0,0 +1,317 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2021, Linaro Ltd */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define WWAN_MAX_MINORS 256 /* Allow the whole available cdev range of
> minors */
That's not the "whole range of minors" at all...
And what are you using this chardev for at all? All you have is an
open() call, but you have nothing to do with it after that. What is it
for?
confused,
greg k-h
either.
It doesn't matter if you think it could be used, it _will_ be used as
you are exposing this stuff to userspace.
> I assume there is also the usual race about triggering the uevent
> before the subdirectories are created, but we have the
> dev_set_uevent_suppress() thing now for that..
Unless you are "pci bus code" you shouldn't be using that :)
thanks,
greg k-h
ee80211_is_s1g_beacon(mgmt->frame_control);
> - unsigned int fixedlen, hdrlen;
> + unsigned int fixedlen = 0 , hdrlen;
Please always use scripts/checkpatch.pl before sending out patches. It
would have pointed out that this line is incorrect and needs to be fixed
up :(
thanks,
greg k-h
On Mon, Mar 29, 2021 at 08:41:38PM +0200, Alaa Emad wrote:
> On Mon, 29 Mar 2021 at 20:20, Greg KH wrote:
>
> > On Mon, Mar 29, 2021 at 06:30:36PM +0200, Alaa Emad wrote:
> > > Reported-by: syzbot+72b99dcf4607e8c77...@syzkaller.appspotmail.com
> > > Signed-off-by:
exible :)
thanks,
greg k-h
On Mon, Mar 29, 2021 at 04:22:36PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
>
> On Mon, Mar 29, 2021 at 11:47:12AM +0200, Loic Poulain wrote:
> > Hi Greg,
> >
> > On Sun, 28 Mar 2021 at 14:28, Greg Kroah-Hartman
> >
> > wrote:
> >
> >
On Mon, Mar 29, 2021 at 09:30:25AM +0300, Leon Romanovsky wrote:
> On Mon, Mar 29, 2021 at 07:30:08AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Mar 29, 2021 at 08:17:06AM +0300, Leon Romanovsky wrote:
> > > On Sun, Mar 28, 2021 at 02:26:21PM +0200, Greg Kroah-Hartman wrote:
On Mon, Mar 29, 2021 at 08:17:06AM +0300, Leon Romanovsky wrote:
> On Sun, Mar 28, 2021 at 02:26:21PM +0200, Greg Kroah-Hartman wrote:
> > There does not seem to be any developers willing to maintain the
> > net/qrtr/ code, so move it to drivers/staging/ so that it can be remov
There does not seem to be any developers willing to maintain the
net/qrtr/ code, so move it to drivers/staging/ so that it can be removed
from the kernel tree entirely in a few kernel releases if no one steps
up to maintain it.
Reported-by: Matthew Wilcox
Cc: Du Cheng
Signed-off-by: Greg Kroah
On Sat, Mar 27, 2021 at 03:51:10PM +, Matthew Wilcox wrote:
> On Sat, Mar 27, 2021 at 03:31:18PM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Mar 27, 2021 at 10:25:20PM +0800, Du Cheng wrote:
> > > On Sat, Mar 27, 2021 at 03:12:14PM +0100, Greg Kroah-Hartman wrote:
> &g
On Sat, Mar 27, 2021 at 10:25:20PM +0800, Du Cheng wrote:
> On Sat, Mar 27, 2021 at 03:12:14PM +0100, Greg Kroah-Hartman wrote:
> > Adding the xarray maintainer...
> >
> > On Sat, Mar 27, 2021 at 10:07:02PM +0800, Du Cheng wrote:
> > > add idr_preload() and idr_prel
code that can't really handle
GFP_ATOMIC during a "normal" idr allocation that is causing this warning
to be hit? Why is this change the "correct" one?
thanks,
greg k-h
ne for one-off devices, and other oddities, but is not a
unified user/kernel api for a class of device types at all.
thanks,
greg k-h
the future to handle things like queues in the
> > future.
>
> Subdirectories would be nice, but Greg KH said earlier in a different
> context that there's an issue with them [1]. He went on to say tools
> like udev would miss uevents for the subdirs [2].
>
> I don't know
On Sat, Mar 27, 2021 at 09:44:37AM +0800, Du Cheng wrote:
> On Fri, Mar 26, 2021 at 10:31:57AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 26, 2021 at 11:33:45AM +0800, Du Cheng wrote:
> > > change the allocator flag of idr_alloc_u32 from GFP_ATOMIC to
> > > GFP_K
idr_alloc_u32(&qrtr_ports, ipc, &min_port,
> QRTR_MAX_EPH_SOCKET, GFP_KERNEL);
Are you sure that you can sleep in this code path?
thanks,
greg k-h
#undef PEGASUS_DEV
> #undef PEGASUS_DEV_CLASS
> {},
>
Did you build and test this code now with this change?
I think you broke this driver badly now :(
Please think about _why_ the code would have been written this way in
the first place, it is a bit odd, right?
netdev maintainers, consider this a NAK.
thanks,
greg k-h
On Wed, Mar 24, 2021 at 02:02:06PM +0530, Naresh Kamboju wrote:
> On Mon, 22 Mar 2021 at 18:15, Greg Kroah-Hartman
> wrote:
> >
> > From: Florian Westphal
> >
> > [ Upstream commit f07157792c633b528de5fc1dbe2e4ea54f8e09d4 ]
> >
> > mptcp_add_pendi
On Wed, Mar 24, 2021 at 10:04:12AM +0100, Florian Westphal wrote:
> Naresh Kamboju wrote:
> > On Mon, 22 Mar 2021 at 18:15, Greg Kroah-Hartman
> > wrote:
> > >
> > > From: Florian Westphal
> > >
> > > [ Upstr
ent against the latest networking tree?
thanks,
greg k-h
On Tue, Mar 16, 2021 at 05:35:43PM -0700, Florian Fainelli wrote:
> Hi Greg, Sasha, Jaakub and David,
>
> This patch series contains backports for a change that recently made it
> upstream as f9b3827ee66cfcf297d0acd6ecf33653a5f297ef ("net: dsa: b53:
> Support setting learni
iaTek tag with VLAN tag")
> Signed-off-by: DENG Qingfang
> Signed-off-by: David S. Miller
> ---
> net/dsa/tag_mtk.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
Thanks for the backport, now queued up.
greg k-h
process
> is not entirely clear to me about how to go about doing that.
If you need me to do that under the umbrella of the Linux Foundation,
I'll be glad to do so if you point me at the proper group to do that
with.
We did this for a few years with the USB-IF and have a vendor id
assigned to us for Linux through them, until they kicked us out because.
But as the number is in a global namespace, it can't be reused so we
keep it :)
thanks,
greg k-h
Cc: Ohad Ben-Cohen
> Cc: Mark Brown
> Cc: Cheng-Yi Chiang
> Cc: Benson Leung
> Cc: Zhang Rui
> Cc: Daniel Lezcano
> Cc: Greg Kroah-Hartman
> Cc: Stefan Wahren
> Cc: Masahiro Yamada
> Cc: Odelu Kukatla
> Cc: Alex Elder
> Cc: Suman Anna
> Cc: Kuninori Morimot
nding of what this
driver is supposed to be doing, and what this hardware is now than
before.
And here I thought I understood hardware devices, and if I am confused,
I pity anyone else looking at this code...
You all need to get some real documentation together to explain
everything here in terms that anyone can understand. Without that, this
code is going nowhere.
good luck!
greg k-h
On Sun, Mar 14, 2021 at 03:19:05PM +0300, Fatih Yildirim wrote:
> On Sun, 2021-03-14 at 09:36 +0100, Greg KH wrote:
> > On Sun, Mar 14, 2021 at 11:23:10AM +0300, Fatih Yildirim wrote:
> > > Hi Santosh,
> > >
> > > I've been working on a memory
On Sun, Mar 14, 2021 at 11:23:10AM +0300, Fatih Yildirim wrote:
> Hi Santosh,
>
> I've been working on a memory leak bug reported by syzbot.
> https://syzkaller.appspot.com/bug?id=39b72114839a6dbd66c1d2104522698a813f9ae2
>
> It seems that memory allocated in rds_send_probe function is not freed.
On Fri, Mar 12, 2021 at 12:11:50PM +0100, Loic Poulain wrote:
> Hi Greg,
>
> On Fri, 12 Mar 2021 at 07:56, Greg KH wrote:
> >
> > On Thu, Mar 11, 2021 at 09:41:03PM +0100, Loic Poulain wrote:
> > > This change introduces initial support for a WWAN subsystem.
t; We need to add READ_ONCE() annotations, and also make
> sure write sides use corresponding WRITE_ONCE() to avoid
> store-tearing.
>
> Note that tcp_inq_hint() was already using READ_ONCE(tp->copied_seq)
>
> Signed-off-by: Eric Dumazet
> Signed-off-by: David S. Miller
All now queued up, thanks!
greg k-h
+#define MHI_WWAN_CONNECTED BIT(2)
> +
> +struct mhi_wwan_buf {
> + struct list_head node;
> + void *data;
> + size_t len;
> + size_t consumed;
> +};
> +
> +struct mhi_wwan_dev {
> + unsigned int minor;
You never use this, why is it here?
{sigh}
Who reviewed this series before sending it out?
greg k-h
td */
> +
> +#ifndef __WWAN_H
> +#define __WWAN_H
> +
> +#include
> +#include
> +
> +/**
> + * struct wwan_device - The structure that defines a WWAN device
> + *
> + * @id: WWAN device unique ID.
> + * @usage: WWAN device usage counter.
> + * @dev: underlying device.
> + * @list:list to chain WWAN devices.
> + * @ports: list of attached wwan_port.
> + * @port_idx:port index counter.
> + * @lock:mutex protecting members of this structure.
> + */
> +struct wwan_device {
> + int id;
> + unsigned int usage;
Again, not needed.
> +
> + struct device dev;
> + struct list_head list;
You should use the list in the class instead.
> +
> + struct list_head ports;
Are you sure you need this?
> + unsigned int port_idx;
> +
> + struct mutex lock;
> +};
> +
> +/**
> + * enum wwan_port_type - WWAN port types
> + * @WWAN_PORT_AT:AT commands.
> + * @WWAN_PORT_MBIM: Mobile Broadband Interface Model control.
> + * @WWAN_PORT_QMI: Qcom modem/MSM interface for modem control.
> + * @WWAN_PORT_QCDM: Qcom Modem diagnostic interface.
> + * @WWAN_PORT_FIREHOSE: XML based command protocol.
> + * @WWAN_PORT_MAX
> + */
> +enum wwan_port_type {
> + WWAN_PORT_AT,
> + WWAN_PORT_MBIM,
> + WWAN_PORT_QMI,
> + WWAN_PORT_QCDM,
> + WWAN_PORT_FIREHOSE,
> + WWAN_PORT_MAX,
> +};
> +
> +/**
> + * struct wwan_port - The structure that defines a WWAN port
> + *
> + * @wwandev: WWAN device this port belongs to.
> + * @fops:Port file operations.
> + * @private_data:underlying device.
> + * @type:port type.
> + * @id: port allocated ID.
> + * @minor: port allocated minor ID for cdev.
> + * @list:list to chain WWAN ports.
> + */
> +struct wwan_port {
> + struct wwan_device *wwandev;
> + const struct file_operations *fops;
> + void *private_data;
> + enum wwan_port_type type;
> +
> + /* private */
> + unsigned int id;
> + int minor;
> + struct list_head list;
So a port is not a device? Why not?
For such a tiny amount of code, I had a lot of questions :(
greg k-h
gt; + provides a common framework for WWAN drivers.
module name if chosen?
thanks,
greg k-h
ate mode 100644 drivers/net/wwan/Makefile
> create mode 100644 drivers/net/wwan/wwan_core.c
> create mode 100644 drivers/net/wwan/wwan_core.h
> create mode 100644 drivers/net/wwan/wwan_port.c
> create mode 100644 include/linux/wwan.h
What changed from the last version(s)? That should be below the ---
somewhere, right?
v5?
thanks,
greg k-h
On Thu, Mar 11, 2021 at 03:13:49PM +0530, Shubhankar Kuranagatti wrote:
> Changed bare usage of unsigned to unsigned int
That says _what_ you did, but not _why_ you did it :(
thanks,
greg k-h
On Thu, Mar 11, 2021 at 08:04:29AM +0100, Greg KH wrote:
> On Thu, Mar 11, 2021 at 08:54:37AM +0200, Ioana Ciornei wrote:
> > On Wed, Mar 10, 2021 at 03:13:10PM -0800, David Miller wrote:
> > > From: Greg KH
> > > Date: Wed, 10 Mar 2021 15:12:57 +0100
> > >
On Thu, Mar 11, 2021 at 08:54:37AM +0200, Ioana Ciornei wrote:
> On Wed, Mar 10, 2021 at 03:13:10PM -0800, David Miller wrote:
> > From: Greg KH
> > Date: Wed, 10 Mar 2021 15:12:57 +0100
> >
> > > Yes, either I can provide a stable tag to pull from for the netdev
could also make a "virtfnX_msix_count"
> > in the PF directory? That's a really interesting idea.
>
> I want to remind that we are talking about mlx5 devices that support
> upto 255 VFs and they indeed are used to their limits. So seeing 255
> links of virtfnX_msix_count in the same directory looks too much unpleasant
> to me.
255 files are nothing, if that's what the hardware supports, what is the
problem? If it's "unpleasant", go complain to the hardware designers :)
greg k-h
On Wed, Mar 10, 2021 at 03:47:44PM +0200, Ioana Ciornei wrote:
> On Wed, Mar 10, 2021 at 01:44:46PM +0100, Greg KH wrote:
> > On Wed, Mar 10, 2021 at 02:14:37PM +0200, Ioana Ciornei wrote:
> > > From: Ioana Ciornei
> > >
> > > This patch set adds support fo
AN filtering on [fixed] and
> declining any request to join a VLAN unaware bridge.
I'll take the first 14 patches now, and then you will have a "clean"
place to ask for the movement of this out of staging.
thanks,
greg k-h
pport that at all.
Why not just use the normal networking functionality instead of this
custom char-device-node-monstrosity?
What is missing from todays kernel networking code that requires this
run-around?
thanks,
greg k-h
On Wed, Mar 10, 2021 at 02:45:10AM +, Chen, Mike Ximing wrote:
>
>
> > -Original Message-
> > From: Greg KH
> > On Wed, Feb 10, 2021 at 11:54:17AM -0600, Mike Ximing Chen wrote:
> > >
> > > diff --git a/drivers/misc/dlb/dlb_ioctl.c
On Wed, Mar 10, 2021 at 01:33:24AM +, Chen, Mike Ximing wrote:
>
> > -Original Message-
> > From: Greg KH
> >
> > On Wed, Feb 10, 2021 at 11:54:06AM -0600, Mike Ximing Chen wrote:
> > > +
> > > +#include "dlb_bitmap.h"
&
On Tue, Mar 09, 2021 at 09:01:11AM -0700, Jeffrey Hugo wrote:
> On 3/9/2021 3:33 AM, Greg KH wrote:
> > On Tue, Mar 09, 2021 at 11:28:49AM +0100, Loic Poulain wrote:
> > > Hi Greg,
> > >
> > > On Tue, 9 Mar 2021 at 10:35, Greg KH wrote:
> > > >
On Tue, Mar 09, 2021 at 11:28:49AM +0100, Loic Poulain wrote:
> Hi Greg,
>
> On Tue, 9 Mar 2021 at 10:35, Greg KH wrote:
> >
> > On Tue, Mar 09, 2021 at 09:42:16AM +0100, Loic Poulain wrote:
> > > The MHI WWWAN control driver allows MHI Qcom based modems to expose
i_wwan_ctrl.o
> diff --git a/drivers/net/wwan/mhi_wwan_ctrl.c
> b/drivers/net/wwan/mhi_wwan_ctrl.c
> new file mode 100644
> index 000..3904cd0
> --- /dev/null
> +++ b/drivers/net/wwan/mhi_wwan_ctrl.c
> @@ -0,0 +1,559 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2018-2021, The Linux Foundation. All rights reserved.*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MHI_WWAN_CTRL_DRIVER_NAME "mhi_wwan_ctrl"
So a driver name is the same as the class that is being created?
That feels wrong, shouldn't the "class" be wwan?
> +#define MHI_WWAN_CTRL_MAX_MINORS 128
Why so many?
thanks,
greg k-h
; diff --git a/drivers/misc/dlb/dlb_resource.h b/drivers/misc/dlb/dlb_resource.h
> new file mode 100644
> index ..2229813d9c45
> --- /dev/null
> +++ b/drivers/misc/dlb/dlb_resource.h
Why do you have lots of little .h files and not just one simple .h file
for the driver? That makes it much easier to maintain over time, right?
thanks,
greg k-h
eate_dir_queue,
> .create_ldb_port = dlb_pf_create_ldb_port,
> .create_dir_port = dlb_pf_create_dir_port,
> + .start_domain = dlb_pf_start_domain,
Why do you have a "callback" when you only ever call one function? Why
is that needed at all?
thanks,
greg k-h
t;len,
> + 0,
> + len,
> + 0);
> +
> + dlb_bitmap_free(complement_mask);
> +
> + /* No set bit range of length len? */
> + return (ret >= (int)bitmap->len) ? -ENOENT : ret;
> +}
Same here, why not put this in the core kernel instead of a tiny random
driver like this?
thanks,
greg k-h
ged in the future, just add a new ioctl, don't modify something that
is already working. Are you _SURE_ you need this type of functionality?
thanks,
greg k-h
As Jakub said, why is this file in this directory?
Flat out ignoring review comments is a sure way to always get pushed to
the bottom of the list of things anyone wants to ever look at...
greg k-h
From: Marek Vasut
[ Upstream commit 287431463e786766e05e4dc26d0a11d5f8ac8815 ]
The interrupt handling of the RS911x is particularly heavy. For each RX
packet, the card does three SDIO transactions, one to read interrupt
status register, one to RX buffer length, one to read the RX packet(s).
This
From: Marek Vasut
[ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ]
In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode,
the association fails. The former is using wpa_supplicant during association,
the later is set up using hostapd:
iwl$ cat hostapd.conf
int
From: Marek Vasut
[ Upstream commit 287431463e786766e05e4dc26d0a11d5f8ac8815 ]
The interrupt handling of the RS911x is particularly heavy. For each RX
packet, the card does three SDIO transactions, one to read interrupt
status register, one to RX buffer length, one to read the RX packet(s).
This
From: Marek Vasut
[ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ]
In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode,
the association fails. The former is using wpa_supplicant during association,
the later is set up using hostapd:
iwl$ cat hostapd.conf
int
From: Marek Vasut
[ Upstream commit 287431463e786766e05e4dc26d0a11d5f8ac8815 ]
The interrupt handling of the RS911x is particularly heavy. For each RX
packet, the card does three SDIO transactions, one to read interrupt
status register, one to RX buffer length, one to read the RX packet(s).
This
From: Marek Vasut
[ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ]
In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode,
the association fails. The former is using wpa_supplicant during association,
the later is set up using hostapd:
iwl$ cat hostapd.conf
int
On Tue, Mar 02, 2021 at 06:46:43PM -0800, Jakub Kicinski wrote:
> Leave it to Greg.
>
> Signed-off-by: Jakub Kicinski
Acked-by: Greg Kroah-Hartman
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
From: Steven Rostedt (VMware)
[ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of function
On Mon, Mar 01, 2021 at 10:32:09AM +0200, Leon Romanovsky wrote:
> On Mon, Mar 01, 2021 at 09:14:42AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 01, 2021 at 09:55:21AM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > A typical cloud p
t contains the
> + total number of MSI-X vectors available for assignment to
> + all VFs associated with PF. It will zero if the device
"The value will be zero if the device..."
And definition of "VF" and PF" are where in this file?
Otherwise looks semi-sane to me, thanks.
greg k-h
vid S. Miller"
Cc: Jakub Kicinski
Cc: intel-wired-...@lists.osuosl.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/intel/e1000e/hw.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/hw.h
b/drivers/net/ethernet/intel/
On Thu, Feb 25, 2021 at 08:53:22AM -0800, Florian Fainelli wrote:
>
>
> On 2/25/2021 12:15 AM, Greg KH wrote:
> > On Wed, Feb 24, 2021 at 05:08:53PM -0800, Florian Fainelli wrote:
> >> From: Florian Fainelli
> >>
> >> Hi Greg, Sasha, Jaakub and D
On Thu, Feb 25, 2021 at 09:54:06AM +0900, Punit Agrawal wrote:
> From: Corinna Vinschen
>
> commit 2643e6e90210e16c978919617170089b7c2164f7 upstream
>
> TSAUXC.DisableSystime is never set, so SYSTIM runs into a SYS WRAP
> every 1100 secs on 80580/i350/i354 (40 bit SYSTIM) and every 35000
> secs
hanged, 20 insertions(+), 14 deletions(-)
Note, 5.9.y and 5.8.y are long end-of-life. You can see that at the
front page of www.kernel.org if you ever are curious about it.
thanks,
greg k-h
On Wed, Feb 24, 2021 at 05:08:53PM -0800, Florian Fainelli wrote:
> From: Florian Fainelli
>
> Hi Greg, Sasha, Jaakub and David,
>
> This patch series contains backports for a change that recently made it
> upstream as:
>
> commit f3f9be9c58085d11f4448ec199bf49dc2f9b7f
On Tue, Feb 23, 2021 at 03:07:43PM -0600, Bjorn Helgaas wrote:
> On Sun, Feb 21, 2021 at 08:59:18AM +0200, Leon Romanovsky wrote:
> > On Sat, Feb 20, 2021 at 01:06:00PM -0600, Bjorn Helgaas wrote:
> > > On Fri, Feb 19, 2021 at 09:20:18AM +0100, Greg Kroah-Hartman wrote:
> &g
On Sun, Feb 21, 2021 at 03:55:18PM +0200, Leon Romanovsky wrote:
> On Sun, Feb 21, 2021 at 02:00:41PM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Feb 20, 2021 at 01:06:00PM -0600, Bjorn Helgaas wrote:
> > > On Fri, Feb 19, 2021 at 09:20:18AM +0100, Greg Kroah-Hartman wrote:
>
On Sat, Feb 20, 2021 at 01:06:00PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 19, 2021 at 09:20:18AM +0100, Greg Kroah-Hartman wrote:
>
> > Ok, can you step back and try to explain what problem you are trying to
> > solve first, before getting bogged down in odd details? I
On Fri, Feb 19, 2021 at 09:52:12AM +0200, Leon Romanovsky wrote:
> On Thu, Feb 18, 2021 at 04:39:50PM -0600, Bjorn Helgaas wrote:
> > On Thu, Feb 18, 2021 at 12:15:51PM +0200, Leon Romanovsky wrote:
> > > On Wed, Feb 17, 2021 at 12:02:39PM -0600, Bjorn Helgaas wrote:
> >
uot;series" of patches, it is a single patch. And no one
cares about why you are doing this, this text isn't needed at all.
thanks,
greg k-h
1 - 100 of 1399 matches
Mail list logo
