x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
Android as factory installed OS.
The ACPI fwnode for the codec on Android boards misses 2 things compared
to the Windows boards (this is hardcoded in the Android board kernels):
1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
for jack-detection.
2. The GPIOs used by the codec are not listed in the fwnode for the codec.
The ACPI tables on x86/ACPI boards shipped with Android being incomplete
happens a lot. The special drivers/platform/x86/x86-android-tablets.c
module contains DMI based per model handling to compensate for this.
This module will enable the 32KHz clock through the pinctrl framework
to fix 1. and it will also register a gpio-lookup table for all GPIOs
needed by the codec + machine driver, including the GPIOs coming from
the codec itself.
Add an arizona_spi_acpi_android_probe() function which waits for the
x86-android-tablets to have set things up before continue with probing
the arizona WM5102 codec.
Signed-off-by: Hans de Goede <[email protected]>
---
drivers/mfd/arizona-spi.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 238355542ab1..2c686e71db21 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -81,6 +81,29 @@ static int arizona_spi_acpi_windows_probe(struct arizona *arizona)
return 0;
}
+/* For ACPI tables from boards which ship with Android as factory OS */
+static int arizona_spi_acpi_android_probe(struct arizona *arizona)
+{
+ int ret;
+
+ /*
+ * Get the reset GPIO, treating -ENOENT as -EPROBE_DEFER to wait for
+ * the x86-android-tablets module to register the board specific GPIO
+ * lookup table.
+ */
+ arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(arizona->pdata.reset)) {
+ ret = PTR_ERR(arizona->pdata.reset);
+ if (ret == -ENOENT) {
+ dev_info_once(arizona->dev, "Deferring probe till GPIO lookup is registered\n");
+ ret = -EPROBE_DEFER;
+ }
+ return dev_err_probe(arizona->dev, ret, "getting reset GPIO\n");
+ }
+
+ return 0;
+}
+
/*
* The AOSP 3.5 mm Headset: Accessory Specification gives the following values:
* Function A Play/Pause: 0 ohm
@@ -102,9 +125,14 @@ static const struct arizona_micd_range arizona_micd_aosp_ranges[] = {
static int arizona_spi_acpi_probe(struct arizona *arizona)
{
+ struct acpi_device *adev = ACPI_COMPANION(arizona->dev);
int ret;
- ret = arizona_spi_acpi_windows_probe(arizona);
+ if (acpi_dev_hid_uid_match(adev, "10WM5102", NULL))
+ ret = arizona_spi_acpi_android_probe(arizona);
+ else
+ ret = arizona_spi_acpi_windows_probe(arizona);
+
if (ret)
return ret;
@@ -142,6 +170,10 @@ static const struct acpi_device_id arizona_acpi_match[] = {
.id = "WM510205",
.driver_data = WM5102,
},
+ {
+ .id = "10WM5102",
+ .driver_data = WM5102,
+ },
{ }
};
MODULE_DEVICE_TABLE(acpi, arizona_acpi_match);
--
2.35.1
On Wed, Feb 23, 2022 at 02:42:22PM +0100, Hans de Goede wrote:
> x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
> Android as factory installed OS.
>
> The ACPI fwnode for the codec on Android boards misses 2 things compared
> to the Windows boards (this is hardcoded in the Android board kernels):
>
> 1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
> for jack-detection.
>
> 2. The GPIOs used by the codec are not listed in the fwnode for the codec.
>
> The ACPI tables on x86/ACPI boards shipped with Android being incomplete
> happens a lot. The special drivers/platform/x86/x86-android-tablets.c
> module contains DMI based per model handling to compensate for this.
>
> This module will enable the 32KHz clock through the pinctrl framework
> to fix 1. and it will also register a gpio-lookup table for all GPIOs
> needed by the codec + machine driver, including the GPIOs coming from
> the codec itself.
>
> Add an arizona_spi_acpi_android_probe() function which waits for the
> x86-android-tablets to have set things up before continue with probing
> the arizona WM5102 codec.
>
> Signed-off-by: Hans de Goede <[email protected]>
> ---
Acked-by: Charles Keepax <[email protected]>
Thanks,
Charles
On Wed, 23 Feb 2022, Hans de Goede wrote:
> x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
> Android as factory installed OS.
>
> The ACPI fwnode for the codec on Android boards misses 2 things compared
> to the Windows boards (this is hardcoded in the Android board kernels):
>
> 1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
> for jack-detection.
>
> 2. The GPIOs used by the codec are not listed in the fwnode for the codec.
>
> The ACPI tables on x86/ACPI boards shipped with Android being incomplete
> happens a lot. The special drivers/platform/x86/x86-android-tablets.c
> module contains DMI based per model handling to compensate for this.
>
> This module will enable the 32KHz clock through the pinctrl framework
> to fix 1. and it will also register a gpio-lookup table for all GPIOs
> needed by the codec + machine driver, including the GPIOs coming from
> the codec itself.
>
> Add an arizona_spi_acpi_android_probe() function which waits for the
> x86-android-tablets to have set things up before continue with probing
> the arizona WM5102 codec.
>
> Signed-off-by: Hans de Goede <[email protected]>
> ---
> drivers/mfd/arizona-spi.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 238355542ab1..2c686e71db21 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -81,6 +81,29 @@ static int arizona_spi_acpi_windows_probe(struct arizona *arizona)
> return 0;
> }
>
> +/* For ACPI tables from boards which ship with Android as factory OS */
> +static int arizona_spi_acpi_android_probe(struct arizona *arizona)
> +{
> + int ret;
> +
> + /*
> + * Get the reset GPIO, treating -ENOENT as -EPROBE_DEFER to wait for
> + * the x86-android-tablets module to register the board specific GPIO
> + * lookup table.
> + */
> + arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(arizona->pdata.reset)) {
> + ret = PTR_ERR(arizona->pdata.reset);
> + if (ret == -ENOENT) {
> + dev_info_once(arizona->dev, "Deferring probe till GPIO lookup is registered\n");
Nit: How many chars is this?
I thought we were drawing the line at 100 these days?
Does this patch pass checkpatch.pl?
> + ret = -EPROBE_DEFER;
> + }
> + return dev_err_probe(arizona->dev, ret, "getting reset GPIO\n");
> + }
> +
> + return 0;
> +}
> +
> /*
> * The AOSP 3.5 mm Headset: Accessory Specification gives the following values:
> * Function A Play/Pause: 0 ohm
> @@ -102,9 +125,14 @@ static const struct arizona_micd_range arizona_micd_aosp_ranges[] = {
>
> static int arizona_spi_acpi_probe(struct arizona *arizona)
> {
> + struct acpi_device *adev = ACPI_COMPANION(arizona->dev);
> int ret;
>
> - ret = arizona_spi_acpi_windows_probe(arizona);
> + if (acpi_dev_hid_uid_match(adev, "10WM5102", NULL))
> + ret = arizona_spi_acpi_android_probe(arizona);
> + else
> + ret = arizona_spi_acpi_windows_probe(arizona);
> +
> if (ret)
> return ret;
>
> @@ -142,6 +170,10 @@ static const struct acpi_device_id arizona_acpi_match[] = {
> .id = "WM510205",
> .driver_data = WM5102,
> },
> + {
> + .id = "10WM5102",
> + .driver_data = WM5102,
> + },
> { }
> };
> MODULE_DEVICE_TABLE(acpi, arizona_acpi_match);
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Mon, 07 Mar 2022, Hans de Goede wrote:
> Hi,
>
> On 3/7/22 15:51, Lee Jones wrote:
> > On Wed, 23 Feb 2022, Hans de Goede wrote:
> >
> >> x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
> >> Android as factory installed OS.
> >>
> >> The ACPI fwnode for the codec on Android boards misses 2 things compared
> >> to the Windows boards (this is hardcoded in the Android board kernels):
> >>
> >> 1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
> >> for jack-detection.
> >>
> >> 2. The GPIOs used by the codec are not listed in the fwnode for the codec.
> >>
> >> The ACPI tables on x86/ACPI boards shipped with Android being incomplete
> >> happens a lot. The special drivers/platform/x86/x86-android-tablets.c
> >> module contains DMI based per model handling to compensate for this.
> >>
> >> This module will enable the 32KHz clock through the pinctrl framework
> >> to fix 1. and it will also register a gpio-lookup table for all GPIOs
> >> needed by the codec + machine driver, including the GPIOs coming from
> >> the codec itself.
> >>
> >> Add an arizona_spi_acpi_android_probe() function which waits for the
> >> x86-android-tablets to have set things up before continue with probing
> >> the arizona WM5102 codec.
> >>
> >> Signed-off-by: Hans de Goede <[email protected]>
> >> ---
> >> drivers/mfd/arizona-spi.c | 34 +++++++++++++++++++++++++++++++++-
> >> 1 file changed, 33 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> >> index 238355542ab1..2c686e71db21 100644
> >> --- a/drivers/mfd/arizona-spi.c
> >> +++ b/drivers/mfd/arizona-spi.c
> >> @@ -81,6 +81,29 @@ static int arizona_spi_acpi_windows_probe(struct arizona *arizona)
> >> return 0;
> >> }
> >>
> >> +/* For ACPI tables from boards which ship with Android as factory OS */
> >> +static int arizona_spi_acpi_android_probe(struct arizona *arizona)
> >> +{
> >> + int ret;
> >> +
> >> + /*
> >> + * Get the reset GPIO, treating -ENOENT as -EPROBE_DEFER to wait for
> >> + * the x86-android-tablets module to register the board specific GPIO
> >> + * lookup table.
> >> + */
> >> + arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset", GPIOD_OUT_LOW);
> >> + if (IS_ERR(arizona->pdata.reset)) {
> >> + ret = PTR_ERR(arizona->pdata.reset);
> >> + if (ret == -ENOENT) {
> >> + dev_info_once(arizona->dev, "Deferring probe till GPIO lookup is registered\n");
> >
> > Nit: How many chars is this?
>
> 105.
>
> > I thought we were drawing the line at 100 these days?
>
> We have an exception for log lines, since we don't want to break them
> up because that makes grepping for them impossible.
>
> > Does this patch pass checkpatch.pl?
>
> Yes because of the exception for log lines:
>
> [hans@x1 linux]$ scripts/checkpatch.pl 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch
> total: 0 errors, 0 warnings, 54 lines checked
>
> 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch has no obvious style problems and is ready for submission.
What do you mean by long lines?
I'm aware of the exception for long strings.
Not sure why anyone would grep for "dev_info_once(arizona->dev, ".
I would break this after the first comma.
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
On 3/7/22 15:51, Lee Jones wrote:
> On Wed, 23 Feb 2022, Hans de Goede wrote:
>
>> x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
>> Android as factory installed OS.
>>
>> The ACPI fwnode for the codec on Android boards misses 2 things compared
>> to the Windows boards (this is hardcoded in the Android board kernels):
>>
>> 1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
>> for jack-detection.
>>
>> 2. The GPIOs used by the codec are not listed in the fwnode for the codec.
>>
>> The ACPI tables on x86/ACPI boards shipped with Android being incomplete
>> happens a lot. The special drivers/platform/x86/x86-android-tablets.c
>> module contains DMI based per model handling to compensate for this.
>>
>> This module will enable the 32KHz clock through the pinctrl framework
>> to fix 1. and it will also register a gpio-lookup table for all GPIOs
>> needed by the codec + machine driver, including the GPIOs coming from
>> the codec itself.
>>
>> Add an arizona_spi_acpi_android_probe() function which waits for the
>> x86-android-tablets to have set things up before continue with probing
>> the arizona WM5102 codec.
>>
>> Signed-off-by: Hans de Goede <[email protected]>
>> ---
>> drivers/mfd/arizona-spi.c | 34 +++++++++++++++++++++++++++++++++-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
>> index 238355542ab1..2c686e71db21 100644
>> --- a/drivers/mfd/arizona-spi.c
>> +++ b/drivers/mfd/arizona-spi.c
>> @@ -81,6 +81,29 @@ static int arizona_spi_acpi_windows_probe(struct arizona *arizona)
>> return 0;
>> }
>>
>> +/* For ACPI tables from boards which ship with Android as factory OS */
>> +static int arizona_spi_acpi_android_probe(struct arizona *arizona)
>> +{
>> + int ret;
>> +
>> + /*
>> + * Get the reset GPIO, treating -ENOENT as -EPROBE_DEFER to wait for
>> + * the x86-android-tablets module to register the board specific GPIO
>> + * lookup table.
>> + */
>> + arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset", GPIOD_OUT_LOW);
>> + if (IS_ERR(arizona->pdata.reset)) {
>> + ret = PTR_ERR(arizona->pdata.reset);
>> + if (ret == -ENOENT) {
>> + dev_info_once(arizona->dev, "Deferring probe till GPIO lookup is registered\n");
>
> Nit: How many chars is this?
105.
> I thought we were drawing the line at 100 these days?
We have an exception for log lines, since we don't want to break them
up because that makes grepping for them impossible.
> Does this patch pass checkpatch.pl?
Yes because of the exception for log lines:
[hans@x1 linux]$ scripts/checkpatch.pl 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch
total: 0 errors, 0 warnings, 54 lines checked
0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch has no obvious style problems and is ready for submission.
Regards,
Hans
>
>> + ret = -EPROBE_DEFER;
>> + }
>> + return dev_err_probe(arizona->dev, ret, "getting reset GPIO\n");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * The AOSP 3.5 mm Headset: Accessory Specification gives the following values:
>> * Function A Play/Pause: 0 ohm
>> @@ -102,9 +125,14 @@ static const struct arizona_micd_range arizona_micd_aosp_ranges[] = {
>>
>> static int arizona_spi_acpi_probe(struct arizona *arizona)
>> {
>> + struct acpi_device *adev = ACPI_COMPANION(arizona->dev);
>> int ret;
>>
>> - ret = arizona_spi_acpi_windows_probe(arizona);
>> + if (acpi_dev_hid_uid_match(adev, "10WM5102", NULL))
>> + ret = arizona_spi_acpi_android_probe(arizona);
>> + else
>> + ret = arizona_spi_acpi_windows_probe(arizona);
>> +
>> if (ret)
>> return ret;
>>
>> @@ -142,6 +170,10 @@ static const struct acpi_device_id arizona_acpi_match[] = {
>> .id = "WM510205",
>> .driver_data = WM5102,
>> },
>> + {
>> + .id = "10WM5102",
>> + .driver_data = WM5102,
>> + },
>> { }
>> };
>> MODULE_DEVICE_TABLE(acpi, arizona_acpi_match);
>
Hi,
On 3/7/22 16:19, Lee Jones wrote:
> On Mon, 07 Mar 2022, Hans de Goede wrote:
>
>> Hi,
>>
>> On 3/7/22 15:51, Lee Jones wrote:
>>> On Wed, 23 Feb 2022, Hans de Goede wrote:
>>>
>>>> x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
>>>> Android as factory installed OS.
>>>>
>>>> The ACPI fwnode for the codec on Android boards misses 2 things compared
>>>> to the Windows boards (this is hardcoded in the Android board kernels):
>>>>
>>>> 1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
>>>> for jack-detection.
>>>>
>>>> 2. The GPIOs used by the codec are not listed in the fwnode for the codec.
>>>>
>>>> The ACPI tables on x86/ACPI boards shipped with Android being incomplete
>>>> happens a lot. The special drivers/platform/x86/x86-android-tablets.c
>>>> module contains DMI based per model handling to compensate for this.
>>>>
>>>> This module will enable the 32KHz clock through the pinctrl framework
>>>> to fix 1. and it will also register a gpio-lookup table for all GPIOs
>>>> needed by the codec + machine driver, including the GPIOs coming from
>>>> the codec itself.
>>>>
>>>> Add an arizona_spi_acpi_android_probe() function which waits for the
>>>> x86-android-tablets to have set things up before continue with probing
>>>> the arizona WM5102 codec.
>>>>
>>>> Signed-off-by: Hans de Goede <[email protected]>
>>>> ---
>>>> drivers/mfd/arizona-spi.c | 34 +++++++++++++++++++++++++++++++++-
>>>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
>>>> index 238355542ab1..2c686e71db21 100644
>>>> --- a/drivers/mfd/arizona-spi.c
>>>> +++ b/drivers/mfd/arizona-spi.c
>>>> @@ -81,6 +81,29 @@ static int arizona_spi_acpi_windows_probe(struct arizona *arizona)
>>>> return 0;
>>>> }
>>>>
>>>> +/* For ACPI tables from boards which ship with Android as factory OS */
>>>> +static int arizona_spi_acpi_android_probe(struct arizona *arizona)
>>>> +{
>>>> + int ret;
>>>> +
>>>> + /*
>>>> + * Get the reset GPIO, treating -ENOENT as -EPROBE_DEFER to wait for
>>>> + * the x86-android-tablets module to register the board specific GPIO
>>>> + * lookup table.
>>>> + */
>>>> + arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset", GPIOD_OUT_LOW);
>>>> + if (IS_ERR(arizona->pdata.reset)) {
>>>> + ret = PTR_ERR(arizona->pdata.reset);
>>>> + if (ret == -ENOENT) {
>>>> + dev_info_once(arizona->dev, "Deferring probe till GPIO lookup is registered\n");
>>>
>>> Nit: How many chars is this?
>>
>> 105.
>>
>>> I thought we were drawing the line at 100 these days?
>>
>> We have an exception for log lines, since we don't want to break them
>> up because that makes grepping for them impossible.
>>
>>> Does this patch pass checkpatch.pl?
>>
>> Yes because of the exception for log lines:
>>
>> [hans@x1 linux]$ scripts/checkpatch.pl 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch
>> total: 0 errors, 0 warnings, 54 lines checked
>>
>> 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch has no obvious style problems and is ready for submission.
>
> What do you mean by long lines?
Not long lines, log lines, as in lines logging a message,
sorry if that was unclear.
> I'm aware of the exception for long strings.
>
> Not sure why anyone would grep for "dev_info_once(arizona->dev, ".
>
> I would break this after the first comma.
Ok, I'll send a v2 with a break after the first comma.
Regards,
Hans
On Mon, 07 Mar 2022, Hans de Goede wrote:
> Hi,
>
> On 3/7/22 16:19, Lee Jones wrote:
> > On Mon, 07 Mar 2022, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 3/7/22 15:51, Lee Jones wrote:
> >>> On Wed, 23 Feb 2022, Hans de Goede wrote:
> >>>
> >>>> x86/ACPI boards with an arizona WM5102 codec ship with either Windows or
> >>>> Android as factory installed OS.
> >>>>
> >>>> The ACPI fwnode for the codec on Android boards misses 2 things compared
> >>>> to the Windows boards (this is hardcoded in the Android board kernels):
> >>>>
> >>>> 1. There is no CLKE ACPI method to enabe the 32 KHz clock the codec needs
> >>>> for jack-detection.
> >>>>
> >>>> 2. The GPIOs used by the codec are not listed in the fwnode for the codec.
> >>>>
> >>>> The ACPI tables on x86/ACPI boards shipped with Android being incomplete
> >>>> happens a lot. The special drivers/platform/x86/x86-android-tablets.c
> >>>> module contains DMI based per model handling to compensate for this.
> >>>>
> >>>> This module will enable the 32KHz clock through the pinctrl framework
> >>>> to fix 1. and it will also register a gpio-lookup table for all GPIOs
> >>>> needed by the codec + machine driver, including the GPIOs coming from
> >>>> the codec itself.
> >>>>
> >>>> Add an arizona_spi_acpi_android_probe() function which waits for the
> >>>> x86-android-tablets to have set things up before continue with probing
> >>>> the arizona WM5102 codec.
> >>>>
> >>>> Signed-off-by: Hans de Goede <[email protected]>
> >>>> ---
> >>>> drivers/mfd/arizona-spi.c | 34 +++++++++++++++++++++++++++++++++-
> >>>> 1 file changed, 33 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> >>>> index 238355542ab1..2c686e71db21 100644
> >>>> --- a/drivers/mfd/arizona-spi.c
> >>>> +++ b/drivers/mfd/arizona-spi.c
> >>>> @@ -81,6 +81,29 @@ static int arizona_spi_acpi_windows_probe(struct arizona *arizona)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> +/* For ACPI tables from boards which ship with Android as factory OS */
> >>>> +static int arizona_spi_acpi_android_probe(struct arizona *arizona)
> >>>> +{
> >>>> + int ret;
> >>>> +
> >>>> + /*
> >>>> + * Get the reset GPIO, treating -ENOENT as -EPROBE_DEFER to wait for
> >>>> + * the x86-android-tablets module to register the board specific GPIO
> >>>> + * lookup table.
> >>>> + */
> >>>> + arizona->pdata.reset = devm_gpiod_get(arizona->dev, "reset", GPIOD_OUT_LOW);
> >>>> + if (IS_ERR(arizona->pdata.reset)) {
> >>>> + ret = PTR_ERR(arizona->pdata.reset);
> >>>> + if (ret == -ENOENT) {
> >>>> + dev_info_once(arizona->dev, "Deferring probe till GPIO lookup is registered\n");
> >>>
> >>> Nit: How many chars is this?
> >>
> >> 105.
> >>
> >>> I thought we were drawing the line at 100 these days?
> >>
> >> We have an exception for log lines, since we don't want to break them
> >> up because that makes grepping for them impossible.
> >>
> >>> Does this patch pass checkpatch.pl?
> >>
> >> Yes because of the exception for log lines:
> >>
> >> [hans@x1 linux]$ scripts/checkpatch.pl 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch
> >> total: 0 errors, 0 warnings, 54 lines checked
> >>
> >> 0001-mfd-arizona-spi-Add-Android-board-ACPI-table-handlin.patch has no obvious style problems and is ready for submission.
> >
> > What do you mean by long lines?
>
> Not long lines, log lines, as in lines logging a message,
> sorry if that was unclear.
My fault, I misread.
> > I'm aware of the exception for long strings.
> >
> > Not sure why anyone would grep for "dev_info_once(arizona->dev, ".
> >
> > I would break this after the first comma.
>
> Ok, I'll send a v2 with a break after the first comma.
Thank you.
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog