From: Muhammad Usama Anjum <usama.anjum@collabora.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: usama.anjum@collabora.com,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Len Brown" <lenb@kernel.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Mark Gross" <markgross@kernel.org>,
"Benson Leung" <bleung@chromium.org>,
"Enric Balletbo i Serra" <eballetbo@gmail.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Collabora Kernel ML" <kernel@collabora.com>,
"Guenter Roeck" <groeck@chromium.org>,
"Dmitry Torokhov" <dtor@chromium.org>,
"Gwendal Grignou" <gwendal@chromium.org>,
vbendeb@chromium.org, "Andy Shevchenko" <andy@infradead.org>,
"Ayman Bagabas" <ayman.bagabas@gmail.com>,
"Benjamin Tissoires" <benjamin.tissoires@redhat.com>,
"Blaž Hrastnik" <blaz@mxxn.io>,
"Darren Hart" <dvhart@infradead.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Jeremy Soller" <jeremy@system76.com>,
"Mattias Jacobsson" <2pi@mok.nu>,
"Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>,
"Rajat Jain" <rajatja@google.com>,
"Srinivas Pandruvada" <srinivas.pandruvada@linux.intel.com>,
"Platform Driver" <platform-driver-x86@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
chrome-platform@lists.linux.dev
Subject: Re: [PATCH RESEND v11] platform/chrome: Add ChromeOS ACPI device driver
Date: Wed, 11 May 2022 20:59:07 +0500 [thread overview]
Message-ID: <8bd83f45-5278-e817-3f65-88fafd0ad3f4@collabora.com> (raw)
In-Reply-To: <CAHp75Vd574LCnEq-KX=WHnnDyrjZgGu6W9wNEbnw79FBpyx=Lw@mail.gmail.com>
Hi Andy,
Thank you for reviewing.
On 5/10/22 2:33 PM, Andy Shevchenko wrote:
> On Tue, May 10, 2022 at 8:44 AM Muhammad Usama Anjum
> <usama.anjum@collabora.com> wrote:
>>
>> From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>
>> The x86 Chromebooks have the ChromeOS ACPI device. This driver attaches
>> to the ChromeOS ACPI device and exports the values reported by ACPI in a
>> sysfs directory. This data isn't present in ACPI tables when read
>> through ACPI tools, hence a driver is needed to do it. The driver gets
>> data from firmware using the ACPI component of the kernel. The ACPI values
>> are presented in string form (numbers as decimal values) or binary
>> blobs, and can be accessed as the contents of the appropriate read only
>> files in the standard ACPI device's sysfs directory tree. This data is
>> consumed by the ChromeOS user space.
>
>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Cc: Hans de Goede <hdegoede@redhat.com>
>
> You can use --cc parameter to `git send-email` instead of putting
> these lines in the commit message.
>
> ...
>
>> +#define DEV_ATTR(_var, _name) \
>> + static struct device_attribute dev_attr_##_var = \
>> + __ATTR(_name, 0444, chromeos_first_level_attr_show, NULL);
>> +
>
> Why not ATTR_RO()?
It'll not work as attribute name has . in it.
>
> ...
>
>> +#define GPIO_ATTR_GROUP(_group, _name, _num) \
>> + static umode_t attr_is_visible_gpio_##_num(struct kobject *kobj, \
>> + struct attribute *attr, int n) \
>> + { \
>> + if (_num < chromeos_acpi_gpio_groups) \
>> + return attr->mode; \
>
>> + else \
>
> Redundant.
We are deciding on run time that how many GPIO attribute groups need to
be shown. chromeos_acpi_gpio_groups is set at run time. I don't see why
`else` can be redundant here.
>
>> + return 0; \
>> + } \
>> + static ssize_t chromeos_attr_show_gpio_##_num(struct device *dev, \
>> + struct device_attribute *attr, \
>> + char *buf) \
>> + { \
>> + char name[ACPI_ATTR_NAME_LEN + 1]; \
>> + int ret, num; \
>> + \
>> + ret = parse_attr_name(attr->attr.name, name, &num); \
>> + if (ret) \
>> + return ret; \
>
>> + ret = chromeos_acpi_evaluate_method(dev, _num, num, name, buf); \
>> + if (ret < 0) \
>> + ret = 0; \
>
> Below I saw the same code, why is the error ignored?
>
I'll return the error in both places.
>> + return ret; \
>> + } \
>> + static struct device_attribute dev_attr_0_##_group = \
>> + __ATTR(GPIO.0, 0444, chromeos_attr_show_gpio_##_num, NULL); \
>> + static struct device_attribute dev_attr_1_##_group = \
>> + __ATTR(GPIO.1, 0444, chromeos_attr_show_gpio_##_num, NULL); \
>> + static struct device_attribute dev_attr_2_##_group = \
>> + __ATTR(GPIO.2, 0444, chromeos_attr_show_gpio_##_num, NULL); \
>> + static struct device_attribute dev_attr_3_##_group = \
>> + __ATTR(GPIO.3, 0444, chromeos_attr_show_gpio_##_num, NULL); \
>> + \
>> + static struct attribute *attrs_##_group[] = { \
>> + &dev_attr_0_##_group.attr, \
>> + &dev_attr_1_##_group.attr, \
>> + &dev_attr_2_##_group.attr, \
>> + &dev_attr_3_##_group.attr, \
>> + NULL \
>> + }; \
>> + static const struct attribute_group attr_group_##_group = { \
>> + .name = _name, \
>> + .is_visible = attr_is_visible_gpio_##_num, \
>
>> + .attrs = attrs_##_group \
>
> Keep a comma here.
Is there any particular reason for it? If there is, I'll add commas to
all the structures.
...
>
> ...
>
>> +static int parse_attr_name(const char *name, char *attr_name, int *attr_num)
>> +{
>> + int ret = 0;
>> +
>> + strscpy(attr_name, name, ACPI_ATTR_NAME_LEN + 1);
>> +
>> + if (strlen(name) > ACPI_ATTR_NAME_LEN)
>
> This seems strange, esp. taking into account that strscpy() returns that.
>
> int ret;
>
> ret = strscpy(...);
> if (ret == -E2BIG)
> return kstrtoint(...);
>
> return 0;
This is very nice way to do it. I'll update.
...
--
Muhammad Usama Anjum
next prev parent reply other threads:[~2022-05-11 15:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 6:44 [PATCH RESEND v11] platform/chrome: Add ChromeOS ACPI device driver Muhammad Usama Anjum
2022-05-10 9:33 ` Andy Shevchenko
2022-05-10 10:10 ` Greg Kroah-Hartman
2022-05-11 15:59 ` Muhammad Usama Anjum [this message]
2022-05-11 16:23 ` Guenter Roeck
2022-05-11 16:29 ` Muhammad Usama Anjum
2022-05-11 17:40 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bd83f45-5278-e817-3f65-88fafd0ad3f4@collabora.com \
--to=usama.anjum@collabora.com \
--cc=2pi@mok.nu \
--cc=andy.shevchenko@gmail.com \
--cc=andy@infradead.org \
--cc=ayman.bagabas@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=blaz@mxxn.io \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dmitry.torokhov@gmail.com \
--cc=dtor@chromium.org \
--cc=dvhart@infradead.org \
--cc=eballetbo@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=gwendal@chromium.org \
--cc=hdegoede@redhat.com \
--cc=jeremy@system76.com \
--cc=kernel@collabora.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=rajatja@google.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=vbendeb@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox