Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>,
	 "Yan, Dongcheng" <dongcheng.yan@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-media@vger.kernel.org,  hverkuil@xs4all.nl,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	 Hans de Goede <hdegoede@redhat.com>,
	u.kleine-koenig@baylibre.com,  ricardo.ribalda@gmail.com,
	bingbu.cao@linux.intel.com,  stable@vger.kernel.org,
	dongcheng.yan@linux.intel.com, hao.yao@intel.com
Subject: Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support
Date: Wed, 2 Jul 2025 14:09:04 +0300 (EEST)	[thread overview]
Message-ID: <268e959b-84e8-ddb0-e760-46b7901b4c2e@linux.intel.com> (raw)
In-Reply-To: <aGUPsDglThYGc/3g@svinhufvud>

[-- Attachment #1: Type: text/plain, Size: 4245 bytes --]

On Wed, 2 Jul 2025, Sakari Ailus wrote:

> Hi Dongcheng, Ilpo,
> 
> On Wed, Jul 02, 2025 at 06:23:19PM +0800, Yan, Dongcheng wrote:
> > Hi Ilpo,
> > 
> > On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
> > > On Fri, 25 Apr 2025, Dongcheng Yan wrote:
> > > 
> > >> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> > >> being received. On the host side this is wired to a GPIO for polling or
> > >> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> > >> lt6911uxe and lt6911uxc.
> > >>
> > >> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> > >> here as well.
> > >>
> > >> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
> > >> ---
> > >>  drivers/platform/x86/intel/int3472/common.h   | 1 +
> > >>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
> > >>  2 files changed, 7 insertions(+)
> > >>
> > >> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> > >> index 51b818e62a25..4593d567caf4 100644
> > >> --- a/drivers/platform/x86/intel/int3472/common.h
> > >> +++ b/drivers/platform/x86/intel/int3472/common.h
> > >> @@ -23,6 +23,7 @@
> > >>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
> > >>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
> > >>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> > >> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
> > >>  
> > >>  #define INT3472_PDEV_MAX_NAME_LEN				23
> > >>  #define INT3472_MAX_SENSOR_GPIOS				3
> > >> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> > >> index 394975f55d64..efa3bc7af193 100644
> > >> --- a/drivers/platform/x86/intel/int3472/discrete.c
> > >> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> > >> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> > >>  		*con_id = "privacy-led";
> > >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> > >>  		break;
> > >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > >> +		*con_id = "hpd";
> > >> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> > >> +		break;
> > >>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
> > >>  		*con_id = "avdd";
> > >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> > >> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> > >>   * 0x0b Power enable
> > >>   * 0x0c Clock enable
> > >>   * 0x0d Privacy LED
> > >> + * 0x13 Hotplug detect
> > >>   *
> > >>   * There are some known platform specific quirks where that does not quite
> > >>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> > >> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> > >>  	switch (type) {
> > >>  	case INT3472_GPIO_TYPE_RESET:
> > >>  	case INT3472_GPIO_TYPE_POWERDOWN:
> > >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > >>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
> > >>  		if (ret)
> > >>  			err_msg = "Failed to map GPIO pin to sensor\n";
> > > 
> > > I was informed about existance of this patch through an off-band channel 
> > > (as I was not among receipients). In future, please include all relevant 
> > > maintainers and MLs as receipients as indicated by 
> > > scripts/get_maintainers.pl.
> 
> Hans used to handle these previously and I think that's why you weren't
> cc'd.

I understand I'm relatively new to this and changes such as this can be 
easily missed for relatively long time. However, it won't explain why 
pdx86 ML was not included.

Usually it's an indication of using fragile patch sending routine if the 
get_maintainers.pl provided receipients are not factored in at least 
semi-automatically at the time of sending, and ends up easily missing 
necessary receipients. So my suggestion is the original submitter looks 
into the process used at the moment of sending the patches out.

-- 
 i.

> > > This may go through a media tree,
> > > 
> > > Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> Thank you!
> 
> > > 
> > > 
> > 
> > Thanks a lot and sorry for the trouble caused by me.
> 
> No worries.
> 
> 

  reply	other threads:[~2025-07-02 11:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25 10:43 [PATCH v3 1/2] platform/x86: int3472: add hpd pin support Dongcheng Yan
2025-04-25 10:43 ` [PATCH v3 2/2] media: i2c: change lt6911uxe irq_gpio name to "hpd" Dongcheng Yan
2025-04-25 10:51 ` [PATCH v3 1/2] platform/x86: int3472: add hpd pin support kernel test robot
2025-04-25 10:54 ` Yan, Dongcheng
2025-04-28 14:16 ` Hans de Goede
2025-04-28 15:29 ` Sakari Ailus
2025-07-02 10:19 ` Ilpo Järvinen
2025-07-02 10:23   ` Yan, Dongcheng
2025-07-02 10:53     ` Sakari Ailus
2025-07-02 11:09       ` Ilpo Järvinen [this message]
2025-07-02 11:22         ` Sakari Ailus
2025-07-02 11:48       ` Andy Shevchenko
2025-07-03  3:09         ` Yan, Dongcheng

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=268e959b-84e8-ddb0-e760-46b7901b4c2e@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bingbu.cao@linux.intel.com \
    --cc=dongcheng.yan@intel.com \
    --cc=dongcheng.yan@linux.intel.com \
    --cc=hao.yao@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=ricardo.ribalda@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=u.kleine-koenig@baylibre.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox