From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: "Daniel Scally" <djrscally@gmail.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
platform-driver-x86@vger.kernel.org,
laurent.pinchart@ideasonboard.com, hverkuil@xs4all.nl,
linux-media@vger.kernel.org
Subject: Re: [PATCH v3 1/1] platform/x86: int3472: Call "reset" GPIO "enable" for INT347E
Date: Wed, 22 Jan 2025 18:51:06 +0200 [thread overview]
Message-ID: <Z5Eh-mX-RiWw9giI@smile.fi.intel.com> (raw)
In-Reply-To: <20250122104344.245128-1-sakari.ailus@linux.intel.com>
On Wed, Jan 22, 2025 at 12:43:44PM +0200, Sakari Ailus wrote:
> The DT bindings for ov7251 specify "enable" GPIO (xshutdown in
> documentation) but the int3472 indiscriminately provides this as a "reset"
> GPIO to sensor drivers. Take this into account by assigning it as "enable"
> with active high polarity for INT347E devices, i.e. ov7251. "reset" with
> active low polarity remains the default GPIO name for other devices.
...
> +/**
> + * struct int3472_gpio_map - Map GPIOs to whatever is expected by the
> + * sensor driver (as in DT bindings)
> + * @hid: The ACPI HID of the device without the instance number e.g. i2c-INT347E
W/o "i2c-" part.
> + * @type_from: The GPIO type from ACPI ?SDT
> + * @type_to: The assigned GPIO type, typically same as type_from
@type_from
> + * @func: The function, e.g. "enable"
Should we speak in terms of GPIOLIB, like connection ID ?
> + * @polarity: GPIO_ACTIVE_{HIGH,LOW}
Please, avoid using patterns with the defined constants. It's better to have
this written as
* @polarity: One of %GPIO_ACTIVE_HIGH, %GPIO_ACTIVE_LOW
> + */
> + const char *hid;
> + u8 type_from;
> + u8 type_to;
> + const char *func;
> + unsigned int polarity;
Hmm... In other cases we usually use
bool active_low;
Can we do the same here?
> +};
...
> - int3472_get_func_and_polarity(type, &func, &polarity);
> + int3472_get_func_and_polarity(int3472->sensor, &type, &func,
> + &polarity);
AFAIK, we don't have hard attachment to the 80-[character limit rule, please
use more room on the previous line.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-01-22 16:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 10:43 [PATCH v3 1/1] platform/x86: int3472: Call "reset" GPIO "enable" for INT347E Sakari Ailus
2025-01-22 10:57 ` Hans de Goede
2025-01-22 16:51 ` Andy Shevchenko [this message]
2025-01-23 9:14 ` Sakari Ailus
2025-01-23 10:34 ` Hans de Goede
2025-01-23 10:47 ` Ilpo Järvinen
2025-01-23 13:37 ` Andy Shevchenko
2025-01-23 13:35 ` Andy Shevchenko
2025-01-23 13:37 ` Hans de Goede
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=Z5Eh-mX-RiWw9giI@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=djrscally@gmail.com \
--cc=hdegoede@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.