| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CABXOdTe1N7iRTVrCZSgQo=dazofWByM_W6EZgWixLj=Z8Xg0ag@mail.gmail.com>
Date: Wed, 11 May 2022 09:23:24 -0700
From: Guenter Roeck <groeck@...gle.com>
To: Muhammad Usama Anjum <usama.anjum@...labora.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Hans de Goede <hdegoede@...hat.com>,
Mark Gross <markgross@...nel.org>,
Benson Leung <bleung@...omium.org>,
Enric Balletbo i Serra <eballetbo@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Collabora Kernel ML <kernel@...labora.com>,
Guenter Roeck <groeck@...omium.org>,
Dmitry Torokhov <dtor@...omium.org>,
Gwendal Grignou <gwendal@...omium.org>, vbendeb@...omium.org,
Andy Shevchenko <andy@...radead.org>,
Ayman Bagabas <ayman.bagabas@...il.com>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Blaž Hrastnik <blaz@...n.io>,
Darren Hart <dvhart@...radead.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jeremy Soller <jeremy@...tem76.com>,
Mattias Jacobsson <2pi@....nu>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Rajat Jain <rajatja@...gle.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Platform Driver <platform-driver-x86@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
chrome-platform@...ts.linux.dev
Subject: Re: [PATCH RESEND v11] platform/chrome: Add ChromeOS ACPI device driver
On Wed, May 11, 2022 at 8:59 AM Muhammad Usama Anjum
<usama.anjum@...labora.com> wrote:
>
> 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@...labora.com> wrote:
> >>
> >> From: Enric Balletbo i Serra <enric.balletbo@...labora.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@...el.com>
> >> Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>
> >> Cc: Hans de Goede <hdegoede@...hat.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.
>
else after return is _always_ unnecessary (and results in static
analyzer messages).
> >
> >> + 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
Powered by blists - more mailing lists