We have an upcoming driver named "intel_ehl_pse_io". This creates an
auxiliary child device for it's GPIO sub-functionality, which matches
against "intel_ehl_pse_io.gpio-elkhartlake" and overshoots the current
maximum limit of 32 bytes for auxiliary device id string. Bump the size
to 40 bytes to satisfy such cases.

Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
v2: Describe the use case (Greg, Andy)

Triggered by [1].

[1] https://lore.kernel.org/r/aQSwWLVKH_3TthTW@smile.fi.intel.com

 include/linux/mod_devicetable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 6077972e8b45..24eb5a88a5c5 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -867,7 +867,7 @@ struct mhi_device_id {
 	kernel_ulong_t driver_data;
 };
 
-#define AUXILIARY_NAME_SIZE 32
+#define AUXILIARY_NAME_SIZE 40
 #define AUXILIARY_MODULE_PREFIX "auxiliary:"
 
 struct auxiliary_device_id {
-- 
2.34.1

On Thu, Nov 06, 2025 at 10:58:38AM +0530, Raag Jadav wrote:
> We have an upcoming driver named "intel_ehl_pse_io". This creates an
> auxiliary child device for it's GPIO sub-functionality, which matches
> against "intel_ehl_pse_io.gpio-elkhartlake" and overshoots the current

Looking at the name there is another question: Why do we need 'elkhartlake in
the GPIO driver's name now? It's a dup to 'ehl' in the first part.

> maximum limit of 32 bytes for auxiliary device id string. Bump the size
> to 40 bytes to satisfy such cases.

> ---
> v2: Describe the use case (Greg, Andy)

Thanks for the update!


-- 
With Best Regards,
Andy Shevchenko

On Thu, Nov 06, 2025 at 09:40:46AM +0200, Andy Shevchenko wrote:
> On Thu, Nov 06, 2025 at 10:58:38AM +0530, Raag Jadav wrote:
> > We have an upcoming driver named "intel_ehl_pse_io". This creates an
> > auxiliary child device for it's GPIO sub-functionality, which matches
> > against "intel_ehl_pse_io.gpio-elkhartlake" and overshoots the current
> 
> Looking at the name there is another question: Why do we need 'elkhartlake in
> the GPIO driver's name now? It's a dup to 'ehl' in the first part.

Just kept it for historic consistency and I'm a bit terrible at naming.

Perhaps "gpio-aux"? But that's too generic from subsystem POV.

Open to suggestions.

Raag

> > maximum limit of 32 bytes for auxiliary device id string. Bump the size
> > to 40 bytes to satisfy such cases.
> 
> > ---
> > v2: Describe the use case (Greg, Andy)
> 
> Thanks for the update!

On Thu, Nov 06, 2025 at 08:58:44AM +0100, Raag Jadav wrote:
> On Thu, Nov 06, 2025 at 09:40:46AM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 06, 2025 at 10:58:38AM +0530, Raag Jadav wrote:
> > > We have an upcoming driver named "intel_ehl_pse_io". This creates an
> > > auxiliary child device for it's GPIO sub-functionality, which matches
> > > against "intel_ehl_pse_io.gpio-elkhartlake" and overshoots the current
> > 
> > Looking at the name there is another question: Why do we need 'elkhartlake in
> > the GPIO driver's name now? It's a dup to 'ehl' in the first part.
> 
> Just kept it for historic consistency and I'm a bit terrible at naming.

I am afraid this alone wouldn't be enough to justify the bump.

> Perhaps "gpio-aux"? But that's too generic from subsystem POV.

From the above the simple 'gpio' would suffice (as long as this driver won't be
used by name directly, also makes sense to check the sysfs file / folder list
to see where it may appear and may or may not clash with the similar driver
from other AUX bucket).

> Open to suggestions.

-- 
With Best Regards,
Andy Shevchenko