mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v1] mod_devicetable: Bump auxiliary_device_id name size
@ 2025-10-31 19:02 Raag Jadav
  2025-11-01  6:18 ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Raag Jadav @ 2025-10-31 19:02 UTC (permalink / raw)
  To: kees, broonie, gregkh, arnd, andriy.shevchenko; +Cc: linux-kernel, Raag Jadav

Since auxiliary device id string is formed using the combination of parent
and child device names, it may require more than 32 bytes if both the names
are long enough. 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>
---
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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v1] mod_devicetable: Bump auxiliary_device_id name size
  2025-10-31 19:02 [PATCH v1] mod_devicetable: Bump auxiliary_device_id name size Raag Jadav
@ 2025-11-01  6:18 ` Greg KH
  2025-11-03  8:16   ` Andy Shevchenko
  0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2025-11-01  6:18 UTC (permalink / raw)
  To: Raag Jadav; +Cc: kees, broonie, arnd, andriy.shevchenko, linux-kernel

On Sat, Nov 01, 2025 at 12:32:34AM +0530, Raag Jadav wrote:
> Since auxiliary device id string is formed using the combination of parent
> and child device names, it may require more than 32 bytes if both the names
> are long enough. Bump the size to 40 bytes to satisfy such cases.

What in-kernel users need such a larger name?  If we allow larger names,
people will try to do crazy things and use memory addresses in them (has
happened already...)

> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> ---
> Triggered by [1].
> 
> [1] https://lore.kernel.org/r/aQSwWLVKH_3TthTW@smile.fi.intel.com

How long would this driver submission's name be?  I couldn't figure it
out, and really, any device with a huge name is going to be a pain...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v1] mod_devicetable: Bump auxiliary_device_id name size
  2025-11-01  6:18 ` Greg KH
@ 2025-11-03  8:16   ` Andy Shevchenko
  2025-11-03 12:50     ` Raag Jadav
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Shevchenko @ 2025-11-03  8:16 UTC (permalink / raw)
  To: Greg KH; +Cc: Raag Jadav, kees, broonie, arnd, linux-kernel

On Sat, Nov 01, 2025 at 07:18:22AM +0100, Greg KH wrote:
> On Sat, Nov 01, 2025 at 12:32:34AM +0530, Raag Jadav wrote:
> > Since auxiliary device id string is formed using the combination of parent
> > and child device names, it may require more than 32 bytes if both the names
> > are long enough. Bump the size to 40 bytes to satisfy such cases.
> 
> What in-kernel users need such a larger name?  If we allow larger names,
> people will try to do crazy things and use memory addresses in them (has
> happened already...)
> 
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> > ---
> > Triggered by [1].
> > 
> > [1] https://lore.kernel.org/r/aQSwWLVKH_3TthTW@smile.fi.intel.com
> 
> How long would this driver submission's name be?  I couldn't figure it
> out, and really, any device with a huge name is going to be a pain...

Right, Raag, please describe a use case.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v1] mod_devicetable: Bump auxiliary_device_id name size
  2025-11-03  8:16   ` Andy Shevchenko
@ 2025-11-03 12:50     ` Raag Jadav
  0 siblings, 0 replies; 4+ messages in thread
From: Raag Jadav @ 2025-11-03 12:50 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Greg KH, kees, broonie, arnd, linux-kernel

On Mon, Nov 03, 2025 at 10:16:58AM +0200, Andy Shevchenko wrote:
> On Sat, Nov 01, 2025 at 07:18:22AM +0100, Greg KH wrote:
> > On Sat, Nov 01, 2025 at 12:32:34AM +0530, Raag Jadav wrote:
> > > Since auxiliary device id string is formed using the combination of parent
> > > and child device names, it may require more than 32 bytes if both the names
> > > are long enough. Bump the size to 40 bytes to satisfy such cases.
> > 
> > What in-kernel users need such a larger name?  If we allow larger names,
> > people will try to do crazy things and use memory addresses in them (has
> > happened already...)
> > 
> > > Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> > > ---
> > > Triggered by [1].
> > > 
> > > [1] https://lore.kernel.org/r/aQSwWLVKH_3TthTW@smile.fi.intel.com
> > 
> > How long would this driver submission's name be?  I couldn't figure it
> > out, and really, any device with a huge name is going to be a pain...
> 
> Right, Raag, please describe a use case.

The driver linked above compiles to intel_ehl_pse_io, so the child will
match against "intel_ehl_pse_io.gpio-elkhartlake" which is 34 bytes
(including termination).

Would that be sufficient or did I miss something?

Raag

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-11-03 12:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-31 19:02 [PATCH v1] mod_devicetable: Bump auxiliary_device_id name size Raag Jadav
2025-11-01  6:18 ` Greg KH
2025-11-03  8:16   ` Andy Shevchenko
2025-11-03 12:50     ` Raag Jadav

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome