linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Damien Riégel" <damien.riegel@silabs.com>
To: greybus-dev@lists.linaro.org
Cc: linux-kernel@vger.kernel.org, linux-devel@silabs.com,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Alex Elder" <elder@kernel.org>,
	"Johan Hovold" <johan@kernel.org>,
	"Damien Riégel" <damien.riegel@silabs.com>
Subject: [RFC 5/6] greybus: match device with bundle ID
Date: Fri,  4 Jul 2025 20:40:35 -0400	[thread overview]
Message-ID: <20250705004036.3828-6-damien.riegel@silabs.com> (raw)
In-Reply-To: <20250705004036.3828-1-damien.riegel@silabs.com>

When matching a device, only the vendor ID and product ID are used. As
all bundles in an interface share the same VID and PID, there is no way
to differentiate between two bundles, and they are forced to use the
same driver.

To allow using several vendor bundles in the same device, include the
bundle ID when matching. The assumption here is that bundle IDs are
stable across the lifespan of a product and never change.

The goal of this change is to open the discussion. Greybus standardizes
a bunch of protocols like GPIO, SPI, etc. but also has provisioning for
vendor bundle and protocol. There is only one ID reserved for vendor,
0xFF, so the question is did Greybus ever envision supporting several
vendor bundles, or one vendor bundle with several vendor cports in it?
Or the assumption always was that there could be at most only vendor
cport?

Signed-off-by: Damien Riégel <damien.riegel@silabs.com>
---
 drivers/greybus/core.c             | 4 ++++
 include/linux/greybus.h            | 7 ++++---
 include/linux/greybus/greybus_id.h | 2 ++
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/greybus/core.c b/drivers/greybus/core.c
index 313eb65cf70..a4968a24a08 100644
--- a/drivers/greybus/core.c
+++ b/drivers/greybus/core.c
@@ -68,6 +68,10 @@ static bool greybus_match_one_id(struct gb_bundle *bundle,
 	    (id->product != bundle->intf->product_id))
 		return false;
 
+	if ((id->match_flags & GREYBUS_ID_MATCH_BUNDLE_ID) &&
+	    (id->bundle_id != bundle->id))
+		return false;
+
 	if ((id->match_flags & GREYBUS_ID_MATCH_CLASS) &&
 	    (id->class != bundle->class))
 		return false;
diff --git a/include/linux/greybus.h b/include/linux/greybus.h
index 4d58e27ceaf..9c29a1099a4 100644
--- a/include/linux/greybus.h
+++ b/include/linux/greybus.h
@@ -38,12 +38,13 @@
 #define GREYBUS_VERSION_MINOR	0x01
 
 #define GREYBUS_ID_MATCH_DEVICE \
-	(GREYBUS_ID_MATCH_VENDOR | GREYBUS_ID_MATCH_PRODUCT)
+	(GREYBUS_ID_MATCH_VENDOR | GREYBUS_ID_MATCH_PRODUCT | GREYBUS_ID_MATCH_BUNDLE_ID)
 
-#define GREYBUS_DEVICE(v, p)					\
+#define GREYBUS_DEVICE(v, p, id)				\
 	.match_flags	= GREYBUS_ID_MATCH_DEVICE,		\
 	.vendor		= (v),					\
-	.product	= (p),
+	.product	= (p),					\
+	.bundle_id	= (id),
 
 #define GREYBUS_DEVICE_CLASS(c)					\
 	.match_flags	= GREYBUS_ID_MATCH_CLASS,		\
diff --git a/include/linux/greybus/greybus_id.h b/include/linux/greybus/greybus_id.h
index f4c8440093e..3e0728e1f44 100644
--- a/include/linux/greybus/greybus_id.h
+++ b/include/linux/greybus/greybus_id.h
@@ -15,6 +15,7 @@ struct greybus_bundle_id {
 	__u32	vendor;
 	__u32	product;
 	__u8	class;
+	__u8	bundle_id;
 
 	kernel_ulong_t	driver_info __aligned(sizeof(kernel_ulong_t));
 };
@@ -23,5 +24,6 @@ struct greybus_bundle_id {
 #define GREYBUS_ID_MATCH_VENDOR		BIT(0)
 #define GREYBUS_ID_MATCH_PRODUCT	BIT(1)
 #define GREYBUS_ID_MATCH_CLASS		BIT(2)
+#define GREYBUS_ID_MATCH_BUNDLE_ID	BIT(3)
 
 #endif /* __LINUX_GREYBUS_ID_H */
-- 
2.49.0


  parent reply	other threads:[~2025-07-05  0:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-05  0:40 [RFC 0/6] Introducing CPC support in Greybus Damien Riégel
2025-07-05  0:40 ` [RFC 1/6] greybus: move host controller drivers comment in Makefile Damien Riégel
2025-07-16 13:20   ` Greg Kroah-Hartman
2025-07-05  0:40 ` [RFC 2/6] greybus: cpc: add core logic Damien Riégel
2025-07-16 13:21   ` Greg Kroah-Hartman
2025-07-05  0:40 ` [RFC 3/6] greybus: cpc: add SPI driver Damien Riégel
2025-07-05  0:40 ` [RFC 4/6] greybus: add API for async unidirectional transfer Damien Riégel
2025-07-16 13:21   ` Greg Kroah-Hartman
2025-07-05  0:40 ` Damien Riégel [this message]
2025-07-16 13:19   ` [RFC 5/6] greybus: match device with bundle ID Greg Kroah-Hartman
2025-07-05  0:40 ` [RFC 6/6] greybus: add class driver for Silabs Bluetooth Damien Riégel
2025-07-16 13:23   ` Greg Kroah-Hartman

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=20250705004036.3828-6-damien.riegel@silabs.com \
    --to=damien.riegel@silabs.com \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=linux-devel@silabs.com \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).