On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning
On Wednesday, February 24, 2016 04:22:27 PM Derek Basehore wrote:
> This tries to runtime suspend devices that are still active for direct
> complete. This is for cases such as autosuspend delays which leaves
> devices able to runtime suspend but still active. It's beneficial in
> this case to runt
PNPBIOS configuration
option is changed to an explicit X86_32 dependency in order to prevent
an attempt to build for an unsupported architecture.
Cc: Rafael J. Wysocki
Signed-off-by: William Breathitt Gray
Has anyone taken care of this already?
If not, can you possibly resend this patch with a
and no such limitation exists
> anymore. As you can see, we can simply set the ACPI handle before this
> device is added in driver core, and the binding will be done.
Yeah, we made that change in the ACPI core around 3.8 IIRC.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysoc
On Monday, November 26, 2012 09:03:11 AM James Bottomley wrote:
> On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
> > On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
> > > > I really think we need a way for (auto)pm and event polling to talk to
On Friday, November 30, 2012 04:55:56 PM Aaron Lu wrote:
> On 11/28/2012 09:39 AM, Tejun Heo wrote:
> > Hey, Rafael.
> >
> > On Wed, Nov 28, 2012 at 01:51:00AM +0100, Rafael J. Wysocki wrote:
> >> Having considered that a bit more I'm now thinking that in
ode needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
>
> Signed-off-by: Viresh Kumar
Acked-by: Rafael J. Wysocki
Greg, please take this one if the [2/2] looks good to you.
&
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 b
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call whe
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() tak
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
&
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte
>> long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki
> > > wrote:
>
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do
needs to be robust for such a case.
>
> Fix that by changing type of 'global_lock' to u32.
>
> Signed-off-by: Viresh Kumar
Acked-by: Rafael J. Wysocki
Greg, please take this one along with the [2/2] if that one looks good to you.
> ---
> BCC'd a lot of people (
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > >
On Friday, 30 of November 2007, Andrew Morton wrote:
> On Sat, 01 Dec 2007 11:30:01 +1300
> Michael Cree <[EMAIL PROTECTED]> wrote:
>
> > Bob Tracy wrote:
> > > Andrew Morton wrote:
> > >> Could be something change in sysfs. Please double-check the config
> > >> options, make sure that something
On Friday, 7 of December 2007, Bob Tracy wrote:
> OK. Finally have this thing painted into a corner: git has identified
> 6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
>
> From "git bisect log", this corresponds to
>
> # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge
On Wednesday, 2 of January 2008, James Bottomley wrote:
>
> On Tue, 2008-01-01 at 18:10 -0800, Andrew Morton wrote:
> > On Tue, 1 Jan 2008 14:55:45 -0800 (PST) [EMAIL PROTECTED] wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9674
> > >
> > >Summary: Oops during rmmod'in
On Friday, 4 of January 2008, Meelis Roos wrote:
> Todays git gives the following warning during bootup on a Intel 845+PATA
> PC (using libata to drive PATA):
>
> Driver 'sd' needs updating - please use bus_type methods
> Driver 'sr' needs updating - please use bus_type methods
They are due to c
nded if it is not being used,
> no matter which power state it is in. The trigger for the PM state
> transition are all based on this, if we want to do it the other way
> around(update device's runtime PM status based on device's actual power
> state), we are in a knotty situa
On Thursday, January 09, 2014 01:17:12 PM Rafael J. Wysocki wrote:
> On Thursday, January 09, 2014 09:29:59 AM Aaron Lu wrote:
> > On 01/09/2014 05:21 AM, Alan Stern wrote:
> > > On Wed, 8 Jan 2014, Phillip Susi wrote:
> > >> You issue a REQUEST SENSE command and
From: Rafael J. Wysocki
Multiple race conditions are possible between the Xen pcifront
device addition and removal and the generic PCI device addition
and removal that can be triggered via sysfs.
To avoid those race conditions make the Xen pcifront code use global
PCI rescan-remove locking
From: Rafael J. Wysocki
Race conditions are theoretically possible between the MPT PCI
device removal and the generic PCI bus rescan and device removal
that can be triggered via sysfs.
To avoid those race conditions make the MPT PCI code use
pci_stop_and_remove_bus_device_locked().
Signed-off
From: Rafael J. Wysocki
Multiple race conditions are possible between the cardbus PCI
device addition and removal and the generic PCI bus rescan and device
removal that can be triggered via sysfs.
To avoid those race conditions make the cardbus code use global
PCI rescan-remove locking.
Signed
From: Rafael J. Wysocki
Race conditions are theoretically possible between the PCI device
addition and removal in the PPC64 PCI error recovery driver and
the generic PCI bus rescan and device removal that can be triggered
via sysfs.
To avoid those race conditions make PPC64 PCI error recovery
[Cc: adding linux-scsi for the MPT changes, Ben for powerpc, Matthew for
platform/x86 and Konrad for Xen]
On Friday, December 06, 2013 02:21:50 AM Rafael J. Wysocki wrote:
[...]
>
> OK
>
> To be a bit more constructive, as the next step I'd try to use
> pci_remove_resca
From: Rafael J. Wysocki
Multiple race conditions are possible between the rfkill hotplug in
the asus-wmi and eeepc-laptop drivers and the generic PCI bus rescan
and device removal that can be triggered via sysfs.
To avoid those race conditions make asus-wmi and eeepc-laptop use
global PCI
From: Rafael J. Wysocki
There are multiple PCI device addition and removal code paths that
may be run concurrently with the generic PCI bus rescan and device
removal that can be triggered via sysfs. If that happens, it may
lead to multiple different, potentially dangerous race conditions.
The
From: Rafael J. Wysocki
Multiple race conditions are possible between the addition and
removal of PCI devices during ACPI PCI host bridge hotplug and the
generic PCI bus rescan and device removal that can be triggered via
sysfs.
To avoid those race conditions make the ACPI PCI host bridge
From: Rafael J. Wysocki
Multiple race conditions are possible between the ACPI-based PCI
hotplug (ACPIPHP) and the generic PCI bus rescan and device removal
that can be triggered via sysfs.
To avoid those race conditions make the ACPIPHP code use global PCI
rescan-remove locking.
Signed-off-by
From: Rafael J. Wysocki
Multiple race conditions are possible between PCI hotplug and the
generic PCI bus rescan and device removal that can be triggered via
sysfs.
To avoid those race conditions make PCI hotplug use global PCI
rescan-remove locking.
Signed-off-by: Rafael J. Wysocki
From: Rafael J. Wysocki
Subject: powerpc / eeh_driver: Use global PCI rescan-remove locking
Race conditions are theoretically possible between the PCI device
addition and removal in the PPC64 PCI error recovery driver and
the generic PCI bus rescan and device removal that can be triggered
via
On Tuesday, 2 October 2007 20:46, Burton Windle wrote:
> On Tue, 2 Oct 2007, Adrian Bunk wrote:
>
> > Cc's added, the complete bug report is at
> > http://lkml.org/lkml/2007/10/2/243
> >
> > On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
> >> 2.6.23-rc9 fails to boot for me; 2.6.2
ese.
>
> Signed-off-by: Bart Van Assche
> Cc: Rafael J. Wysocki
> ---
> include/linux/suspend.h | 28 ++--
> kernel/power/main.c | 29 +
> 2 files changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/
On Sat, Jan 6, 2018 at 12:32 AM, Bart Van Assche wrote:
> On Sat, 2018-01-06 at 00:00 +0100, Rafael J. Wysocki wrote:
>> The changes are fine by me, but I really would prefer them to go in
>> via the PM tree which I guess means that the second patch would need
>> to go in th
On Monday, January 8, 2018 5:02:53 PM CET Martin K. Petersen wrote:
>
> Bart,
>
> > Avoid that the following warning is reported when suspending a system
> > that is using the mptspi driver:
>
> Acked-by: Martin K. Petersen
Thanks!
Let me take both patches to the linux-pm tree then.
Thanks,
On Wednesday, September 19, 2012, James Bottomley wrote:
> On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
> > Hi James,
> >
> > May I know if this patchset will enter v3.7?
>
> Sigh, well, I was hoping to persuade the PM people to sort this out
> first.
>
> The first observation is that all
On Wednesday, September 19, 2012, Aaron Lu wrote:
> On 09/19/2012 08:50 PM, Rafael J. Wysocki wrote:
> > On Wednesday, September 19, 2012, James Bottomley wrote:
> >> On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
> >>> Hi James,
> >>>
> &g
Please add a changelog explaining who's going to use the new interface, in
addition to the original user of that code, and why it is exported.
Thanks,
Rafael
On Wednesday, September 12, 2012, Aaron Lu wrote:
> Signed-off-by: Aaron Lu
> ---
> block/genhd.c | 23 +--
>
On Wednesday, September 12, 2012, Aaron Lu wrote:
> Place the ODD into runtime suspend state as soon as there is nobody
> using it.
OK, so how is ODD related to the sr driver?
> The only exception is, if we just find that a new medium is
> inserted, we wait for the next events checking to idle it
On Wednesday, September 19, 2012, James Bottomley wrote:
> On Wed, 2012-09-19 at 14:50 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, September 19, 2012, James Bottomley wrote:
> > > On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
> > > > Hi James,
>
On Wednesday, September 12, 2012, Aaron Lu wrote:
> When ODD is runtime suspended, we will check if it is OK to remove
> its power:
> 1 For tray type, no medium inside and tray closed;
> 2 For slot type, no medium inside.
> And if yes, we will set the ready_to_power_off flag as an indication to
> A
On Friday, September 21, 2012, Aaron Lu wrote:
> On Thu, Sep 20, 2012 at 10:48:10PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, September 12, 2012, Aaron Lu wrote:
> > > Place the ODD into runtime suspend state as soon as there is nobody
> > > using it.
> >
On Friday, September 21, 2012, Aaron Lu wrote:
> On Fri, Sep 21, 2012 at 12:07:23AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, September 12, 2012, Aaron Lu wrote:
> > > static struct scsi_driver sr_template = {
> > > .owner = THIS_MODULE,
>
On Friday, September 21, 2012, Aaron Lu wrote:
> On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, September 19, 2012, Aaron Lu wrote:
> > > Thanks Rafael, and if there is any question/problem,
> > > please kindly let me know.
>
On Saturday, September 22, 2012, Oliver Neukum wrote:
> On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote:
>
> > Now, James says he doesn't like the way ready_to_power_off is used. Sure
> > enough, it is totally irrelevant to the majority of SCSI devices.
On Saturday, September 22, 2012, Alan Stern wrote:
> On Sat, 22 Sep 2012, Rafael J. Wysocki wrote:
>
> > > There are sd devices with removable media.
> >
> > OK. Does the SCSI layer distinguish them from devices without removable
> > media?
>
>
On Saturday, September 22, 2012, Alan Stern wrote:
> On Sat, 22 Sep 2012, Rafael J. Wysocki wrote:
>
> > > > I see. So the sr's runtime suspend may be useful even without the
> > > > power-off
> > > > feature, right?
> > >
> > >
On Monday, September 24, 2012, Aaron Lu wrote:
> On Fri, Sep 21, 2012 at 10:49:32PM +0200, Rafael J. Wysocki wrote:
> > On Friday, September 21, 2012, Aaron Lu wrote:
> > > On Thu, Sep 20, 2012 at 10:48:10PM +0200, Rafael J. Wysocki wrote:
> > > > On Wednesday, Sept
On Monday, September 24, 2012, Aaron Lu wrote:
> On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
> > On Friday, September 21, 2012, Aaron Lu wrote:
> > > On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
> > > > On Wednesday, Sept
On Monday, September 24, 2012, Aaron Lu wrote:
> On Mon, Sep 24, 2012 at 02:55:31PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 24, 2012, Aaron Lu wrote:
> > > On Fri, Sep 21, 2012 at 10:49:32PM +0200, Rafael J. Wysocki wrote:
> > > > On Friday, Sept
On Monday, September 24, 2012, Aaron Lu wrote:
> On Mon, Sep 24, 2012 at 03:06:11PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 24, 2012, Aaron Lu wrote:
> > > On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
> > > > On Friday, Sept
On Tuesday, September 25, 2012, Aaron Lu wrote:
> On Mon, Sep 24, 2012 at 11:40:18PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 24, 2012, Aaron Lu wrote:
> > > On Mon, Sep 24, 2012 at 02:55:31PM +0200, Rafael J. Wysocki wrote:
> > > > And I'
On Tuesday, September 25, 2012, Aaron Lu wrote:
> On 09/25/2012 10:23 PM, Oliver Neukum wrote:
> > On Tuesday 25 September 2012 22:20:21 Aaron Lu wrote:
> >> On Tue, Sep 25, 2012 at 01:47:52PM +0200, Rafael J. Wysocki wrote:
> >>> On Tuesday, September 25, 2012, Aaron
On Wednesday, September 26, 2012, Aaron Lu wrote:
> On Tue, Sep 25, 2012 at 11:45:34PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, September 25, 2012, Aaron Lu wrote:
> > > On 09/25/2012 10:23 PM, Oliver Neukum wrote:
> > > > On Tuesday 25 September 2012 22:20:
On Thursday, September 27, 2012, Aaron Lu wrote:
> On 09/27/2012 10:42 PM, Alan Stern wrote:
> > On Thu, 27 Sep 2012, Aaron Lu wrote:
> >
> >>> Moreover, I'd like to migrate SCSI drivers to the PM handling based on
> >>> struct
> >>> dev_pm_ops eventually and your change is kind of going in the o
On Saturday, September 29, 2012, Aaron Lu wrote:
> [Adding more people and list back in]
>
> On 09/29/2012 05:46 AM, Rafael J. Wysocki wrote:
> > On Friday, September 28, 2012, Aaron Lu wrote:
> >> On 09/28/2012 07:15 AM, Rafael J. Wysocki wrote:
> >>> On Th
On Saturday, September 29, 2012, Alan Stern wrote:
> On Sat, 29 Sep 2012, Aaron Lu wrote:
>
> > > I don't think this is a good idea, quite frankly. sr seems to be a too
> > > generic place for that.
> >
> > Does this mean sr can only have code that is useful to all devices it
> > manages? i.e. I
On Saturday, September 29, 2012, Aaron Lu wrote:
> On 09/29/2012 10:29 PM, Alan Stern wrote:
> > On Sat, 29 Sep 2012, Aaron Lu wrote:
> >
> >>> I don't think this is a good idea, quite frankly. sr seems to be a too
> >>> generic place for that.
> >>
> >> Does this mean sr can only have code that
blem,
> that I'm setting a scsi device's runtime status in ATA layer, this
> doesn't feel right. And someday, someone may want to add runtime pm
> support for sr and the runtime status of the scsi device will be messed.
>
> The reason I want to use runtime PM is, when
r = scsi_dev_type_resume(dev, pm ? pm->runtime_resume : NULL);
>
> /* Insert hooks here for targets, hosts, and transport classes */
>
> @@ -229,11 +248,11 @@ void scsi_autopm_put_host(struct Scsi_Host *shost)
> const struct dev_pm_ops scsi_bus_pm_ops = {
> .prepare =
r scsi devices
> > sd: update sd to use the new pm callbacks
> >
> > drivers/scsi/scsi_pm.c | 97
> > +++---
> > drivers/scsi/sd.c | 18 +++---
> > 2 files changed, 66 insertions(+), 49 deletions(-)
>
(+), 49 deletions(-)
Do you have any plans with respect to this patchset?
It has been acked by Alan and me, do you have any objections against it?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that SCSI (and ATA) power management is mostly invisible. If we
> currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact
> ZPREADY emulation), we won't care (except for flipping the sofware bit)
> whether the device support ZPODD or ZPREADY and it will all just
> wor
meone else that the device has been
turned off. Clearly, we need a way to do that, but not through PM QoS.
Did you consider using pm_runtime_suspended() to check the device status?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
> On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> > On Tuesday, November 20, 2012 04:59:57 PM Aaron Lu wrote:
> >> On 11/20/2012 02:00 PM, Aaron Lu wrote:
> >>> On 11/19/2012 10:56 PM, Tejun Heo wrote:
>
On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
> On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
> > On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
> >> On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> >>> On Tuesday, November 20, 2012 04:59:5
On Monday, November 26, 2012 09:09:36 AM Aaron Lu wrote:
> On 11/26/2012 09:11 AM, Rafael J. Wysocki wrote:
> > On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
> >> On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
> >>> On Monday, November 26, 2012 08:48:51 A
From: Rafael J. Wysocki
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
On Tuesday, December 09, 2014 02:19:57 PM Aaron Lu wrote:
> On 12/04/2014 09:22 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> > selected) PM_RUNTIME is always set if
From: Rafael J. Wysocki
Subject: SCSI / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM
It is OK AFAICS.
Reviewed-by: Rafael J. Wysocki
;
>
> -static struct config_item_type acpi_root_group_type = {
> +static const struct config_item_type acpi_root_group_type = {
> .ct_owner = THIS_MODULE,
> };
>
>
Acked-by: Rafael J. Wysocki
>
> const struct raid6_calls raid6_sse2x2 = {
> raid6_sse22_gen_syndrome,
> @@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t
> bytes, void **ptrs)
> kernel_fpu_end();
> }
>
> - static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
> +static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
>size_t bytes, void **ptrs)
> - {
> +{
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
> @@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t
> bytes, void **ptrs)
> }
> asm volatile("sfence" : : : "memory");
> kernel_fpu_end();
> - }
> +}
>
>
> const struct raid6_calls raid6_sse2x4 = {
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0c11f434a374..ec619f51d336 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = {
> };
>
> static int fsl_soc_dma_probe(struct platform_device *pdev)
> - {
> +{
> struct dma_object *dma;
> struct device_node *np = pdev->dev.of_node;
> struct device_node *ssi_np;
>
> --
Acked-by: Rafael J. Wysocki
for the ACPI part.
Thanks!
75 matches
Mail list logo
