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
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 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
23 matches
Mail list logo
