On Tue, Aug 06, 2024 at 12:35:44PM +0800, Jason Wang wrote:
> On Fri, Aug 2, 2024 at 6:00 PM Louis Peens wrote:
> >
> > From: Kyle Xu
> >
> > Add a new kernel module ‘nfp_vdpa’ for the NFP vDPA networking driver.
> >
> > The vDPA driver initializes th
of kernel vDPA framework.
Signed-off-by: Kyle Xu
Signed-off-by: Louis Peens
---
MAINTAINERS| 1 +
drivers/vdpa/Kconfig | 10 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/netronome/Makefile| 5 +
drivers/vdpa/netronome
ialized
as auxiliary device and registered to the auxiliary bus. Otherwise
the VF device will be initialized as PCI VF device as usual.
Signed-off-by: Kyle Xu
Signed-off-by: Louis Peens
---
drivers/net/ethernet/netronome/Kconfig| 1 +
drivers/net/ethernet/netronome/nfp/nfp_net.h |
e true cmode runtime
devlink dev param set pci/:01:00.0 \
name enable_vnet value false cmode runtime
devlink dev param show pci/:01:00.0 name enable_vnet
Signed-off-by: Kyle Xu
Signed-off-by: Louis Peens
---
.../ethernet/netronome/nfp/devlink_param.c| 49
This is the first foray into upstreaming a vDPA driver for the nfp.
Submitting it as RFC initially, since this is touching a new component,
not sure if there are potentially any new-to-us requirements this needs
to fulfill. We are hoping that this is already in a state to
resubmit as PATCH, dependi
On 2021/03/26 18:58, Marcelo Leitner wrote:
> On Tue, Mar 16, 2021 at 05:12:22PM +0200, Louis Peens wrote:
>> So in the end I think there are two problems - the on you identified with
>> only checking
>> the mask in commit 1bcc51ac0731. And then the second bigger one is t
On 2021/03/16 09:00, wenxu wrote:
>
> On 3/15/2021 11:29 PM, Louis Peens wrote:
>> Hi Marcelo
>>
>> Thanks for taking time to take a look. I've replied inline - and also found
>> a bit more info, although I'm not sure if it clears things up much. I do
.
Regards
Louis
On 2021/03/15 17:29, Louis Peens wrote:
> Hi Marcelo
>
> Thanks for taking time to take a look. I've replied inline - and also found
> a bit more info, although I'm not sure if it clears things up much. I do think
> that the main problem is the different u
ction as that is common conntrack code. I suspect
that ideally this is something we can try and address from the OVS side,
but at this moment I have no idea how this will be achieved, hence this
email.
Looking forward to get some suggestions on this
Regards
Louis Peens
PS: Tested on:
net-next k
An unsigned long variable should rely on '%lu' format strings, not '%zd'
Fixes: a1a6a4cf49ece ("iwlwifi: pnvm: implement reading PNVM from UEFI")
Signed-off-by: Pierre-Louis Bossart
---
warnings found with v5.12-rc1 and next-20210301
drivers/net/wireless/intel
+module_init(auxiliary_bus_init);
+module_exit(auxiliary_bus_exit);
+
+MODULE_LICENSE("GPL");
Per above SPDX is v2 only, so...
MODULE_LICENSE("GPL v2");
added v2.
"GPL v2" is the same as "GPL" here, it does not have any additional meaning.
https://www.kernel.org/doc/html/latest/process
+config SND_SOC_SOF_CLIENT_SUPPORT
+ bool "SOF enable clients"
Tell users what "SOF" means.
This option can only be reached if the user already selected the topic-level
option. From there on the SOF acronym is used. Is this not enough?
Yes, that's enough. I didn't see it. Sorry about
+config SND_SOC_SOF_CLIENT
+ tristate
+ select ANCILLARY_BUS
+ help
+ This option is not user-selectable but automagically handled by
+ 'select' statements at a higher level
+
+config SND_SOC_SOF_CLIENT_SUPPORT
+ bool "SOF enable clients"
Tell users what "SOF" means.
+config SND_SOC_SOF_CLIENT
+ tristate
+ select ANCILLARY_BUS
+ help
+ This option is not user-selectable but automagically handled by
+ 'select' statements at a higher level
+
+config SND_SOC_SOF_CLIENT_SUPPORT
+ bool "SOF enable clients"
Tell users wha
+
+ ancildrv->driver.owner = owner;
+ ancildrv->driver.bus = &ancillary_bus_type;
+ ancildrv->driver.probe = ancillary_probe_driver;
+ ancildrv->driver.remove = ancillary_remove_driver;
+ ancildrv->driver.shutdown = ancillary_shutdown_driver;
+
I think that this part is wrong, probe
+
+ ancildrv->driver.owner = owner;
+ ancildrv->driver.bus = &ancillary_bus_type;
+ ancildrv->driver.probe = ancillary_probe_driver;
+ ancildrv->driver.remove = ancillary_remove_driver;
+ ancildrv->driver.shutdown = ancillary_shutdown_driver;
+
I think that this part is wrong, prob
But ... since the init() function is performing both device_init and
device_add - it should probably be called ancillary_device_register,
and we are back to a single exported API for both register and
unregister.
Kind reminder that we introduced the two functions to allow the
caller to know i
On 10/7/20 4:22 PM, Ertman, David M wrote:
-Original Message-
From: Pierre-Louis Bossart
Sent: Wednesday, October 7, 2020 1:59 PM
To: Ertman, David M ; Parav Pandit
; Leon Romanovsky
Cc: alsa-de...@alsa-project.org; pa...@mellanox.com; ti...@suse.de;
netdev@vger.kernel.org
Below is most simple, intuitive and matching with core APIs for name and
design pattern wise.
init()
{
err = ancillary_device_initialize();
if (err)
return ret;
err = ancillary_device_add();
if (ret)
goto err_unwind;
err
Thanks for the review Leon.
Add support for the Ancillary Bus, ancillary_device and ancillary_driver.
It enables drivers to create an ancillary_device and bind an
ancillary_driver to it.
I was under impression that this name is going to be changed.
It's part of the opens stated in the cover
From: Louis Peens
emit_obj_refs_json needs to added the same as with emit_obj_refs_plain
to prevent segfaults, similar to Commit "8ae4121bd89e bpf: Fix bpftool
without skeleton code enabled"). See the error below:
# ./bpftool -p prog
{
"error": "
From: Louis Peens
The 'fw_load_policy' devlink parameter supports the 'disk' value
since kernel v5.4, seems like there was some oversight in adding
this to iproute, fixed by this patch.
Signed-off-by: Louis Peens
Reviewed-by: Simon Horman
---
devlink/devlink.c | 5
.
Thank you,
Louis.
---
Best regards,
Allan Chou
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: al...@asix.com.tw
https://www.asix.com.tw/
-Original Message-
From: Jeremy Kerr
Sent: Tuesday, June 2, 2020 11:18 AM
To: Freddy Xin ; Allan Chou
Cc
If yes, that's yet another problem... During the PCI probe, we start a
workqueue and return success to avoid blocking everything.
That's crazy.
And only 'later' do we actually create the card. So that's two levels
of probe that cannot report a failure. I didn't come up with this
design, II
On 5/24/20 1:35 AM, Greg KH wrote:
On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
On 5/23/20 1:23 AM, Greg KH wrote:
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
This is not an hypothetical case, we've had this recurring problem when
On 5/23/20 1:23 AM, Greg KH wrote:
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
This is not an hypothetical case, we've had this recurring problem when a
PCI device creates an audio card represented as a platform device. When the
card registration fails, typi
Maybe if you can present some diagram or something, because I really
can't understand why asoc is trying to do with virtual bus here.
instead of having a 1:1 mapping between PCI device and a monolithic
card, we want to split the sound card in multiple orthogonal parts such as:
PCI device
On 5/22/20 1:40 PM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 01:35:54PM -0500, Pierre-Louis Bossart wrote:
On 5/22/20 12:10 PM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
Maybe not great, but at least it is consistent with all the
On 5/22/20 12:10 PM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
Maybe not great, but at least it is consistent with all the lifetime
models and the operation of the driver core.
I agree your comments are valid ones, I just don't h
On 5/22/20 9:55 AM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
+ ret = virtbus_register_device(vdev);
+ if (ret < 0)
+ return ret;
+
+ /* make sure the probe is complete before updating client l
+ ret = virtbus_register_device(vdev);
+ if (ret < 0)
+ return ret;
+
+ /* make sure the probe is complete before updating client list
*/
+ timeout = msecs_to_jiffies(SOF_CLIENT_PROBE_TIMEOUT_MS);
+ time = wait_for_completion_timeout(&cdev->probe_comp
On 27/11/18 23:42, Eric Dumazet wrote:
Jean-Louis Dupond reported poor iscsi TCP receive performance
that we tracked to backlog drops.
Apparently we fail to send window updates reflecting the
fact that we are under stress.
Note that we might lack a proper window increase when
backlog is fully
Hi,
Was somebody able to check this?
Really think this should be fixed :)
Thanks
Jean-Louis
On 3/11/18 16:59, Jean-Louis Dupond wrote:
Hi All,
On recent kernels we noticed a way lower throughput to our SAN system
than before.
While on pre 4.18 kernels we had 400-700MB/sec read speed, on
net.ipv4.tcp_comp_sack_nr to 0 on 4.19 for example,
the throughput is (almost) back to normal again.
So it seems like this change causes quite some performance issues.
Any ideas?
Thanks
Jean-Louis
in the
timer callback function.
Reported-by: Jean-Louis Dupond
Signed-off-by: Wei Liu
Tested-by: Jean-Louis Dupond
Applied.
Could this get applied to stable & LTS kernels also?
Seems important enough in my opinion.
Thanks!
Hi,
Any chance on this? As it gives a possible freeze on all Xen machines
that use rate-limiting, I really think we should backport this straight
forward patch.
Thanks
Jean-Louis
Op 11-07-17 om 11:47 schreef Jean-Louis Dupond:
Hi All,
Is there a chance the following patch
(https
would be good to
have it backported :)
Thanks
Jean-Louis
On 6/21/16 12:40 PM, Richard Cochran wrote:
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote:
You can experiment with the 'dma' and 'link' timestamps today on any
HDaudio-based device. Like I said the synchronized part has not been
upstreamed yet (delays
On 6/20/16 5:18 AM, Richard Cochran wrote:
On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
The ALSA API provides support for 'audio' timestamps (playback/capture rate
defined by audio subsystem) and 'system' timestamps (typically linked to
TSC/ART) wit
On 6/20/16 5:31 AM, Richard Cochran wrote:
On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote:
Documentation/sound/alsa/timestamping.txt says:
Examples of typestamping with HDaudio:
1. DMA timestamp, no compensation for DMA+analog delay
$ ./audio_time -p --ts_type=1
Wh
Presentation time is either set by
a) Local sound card performing capture (in which case it will be 'capture
time')
b) Local media application sending a stream accross the network
(time when the sample should be played out remotely)
c) Remote media application streaming data *to* host, in
nn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
>> + if (conn)
>> + conn->type = ev->link_type;
>> + }
>> + if (!conn)
>> + goto unlock;
>> + }
>
> NAK. There is no need to check for ACL_LINK. The sync_complete will
> only be calle
Dave Young 쓴 글:
> On Mon, Feb 25, 2008 at 5:28 PM, Louis JANG <[EMAIL PROTECTED]> wrote:
>
>> > I ever asked marcel about the coding style. please see following thread:
>> > http://lkml.org/lkml/2008/1/22/91
>> >
>> > I think the style prob
The same without gmail problems
== Changelog ==
The value is_setbyuser from struct ip_options is never used and set
only one time (http://linux-net.osdl.org/index.php/TODO#IPV4).
This little patch removes it from the kernel source.
Signed-off-by: Louis Nyffenegger <[EMAIL PROTECTED]>
==
== Changelog ==
The value is_setbyuser from struct ip_options is never used and set
only one time (http://linux-net.osdl.org/index.php/TODO#IPV4).
This little patch removes it from the kernel source.
Signed-off-by: Louis Nyffenegger <[EMAIL PROTECTED]>
== Patch ==
--- /usr/src/linux/i
this cookie feature?
--
Louis.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
46 matches
Mail list logo
