[PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Uwe Kleine-König (The Capable Hub)]

Hello Johannes,

On Tue, Apr 21, 2026 at 10:59:04AM +0200, Johannes Berg wrote:
> On Tue, 2026-04-21 at 10:12 +0200, Uwe Kleine-König (The Capable Hub)
> wrote:
> > > 
> > > We only received 1-3 of the 6:
> > > 
> > > https://patchwork.kernel.org/project/bluetooth/list/?series=1082520
> > > 
> > > Or is this on purpose, and we should consider the set complete?
> > 
> > The remaining patches are for wifi. My expectation was that they go in
> > via wifi+netdev once the first patch is in their base. But of course I'm
> > open for maintainer coordination to let the series go in in less steps
> > than I expected. If that helps I can also create an immutable branch,
> > but I have no urge here, so if only the first patch goes in during the
> > next merge window, I won't have problems to keep track of the remaining
> > bits.
> 
> It's probably better for everything all around, including the various
> automations that test patch series, if you just flip a coin, send these
> to either BT or WiFi, and then resend the others later :)

The first patch of this series adapting sdio_device_id is technically
mmc material. However to demonstrate the upside of this patch you also
have to look at at least one of bluetooth and wifi. So even if I drop
one of those there are still two subsystems involved. And then in my
subjective view it doesn't matter much if I involve two or three
subsystems. Regarding test automations I would assume that if the
bluetooth bot sees patches #1-#4 of this series it can do something
already (involving either testing the series only partially or finding
all 6 patches on lore). And then this isn't worse than just sending the
first four patches of the series and delaying wifi until later.

But I agree that's a trade-off.

Having said that, I'm happy if the first patch is merged and patches #2
to #6 are discarded by the bluetooth and wifi people. I'll come back to
them once the first patch is in a release.

> All assuming we get an ACK from whoever is responsible for patch 1 to
> merge it through some other tree :)

To make this more explicit: That would be Ulf as MMC maintainer.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20260421/1da62a11/attachment.sig>