Re: [PATCH wireless-next 14/35] wifi: mm81x: add mac.c

[Lachlan Hodges]

On Mon, Mar 09, 2026 at 08:08:53AM +0100, Johannes Berg wrote:
> On Mon, 2026-03-09 at 15:43 +1100, Lachlan Hodges wrote:
> > >  2) Are you going to incur the wrath of mm/ folks, where instances of
> > >     'struct mm_struct' are commonly called 'mm'? I can find a few
> > >     examples of others (struct drm_buddy *mm, struct mqd_manager *mm),
> > >     but you'd double the instances.
> > 
> > This.. is definitely something I did not think of. I have no issue with
> > renaming to something else.. maybe mx? I'm not sure.
> 
> Yeah I really don't know. There's no 'mm->lock' (any more? for some
> reason _that_ was what caught my eye wrt. the naming) in mm/, and I
> guess soon also not in your driver. I'll try to ask around, but it's
> probably safer to rename, and shouldn't be _that_ hard with spatch I
> guess. I guess 'mx' seems reasonable, 'mmx' is also confusing perhaps,
> and 'mm81x' doesn't lend itself to obvious other abbreviations.

Thanks. Although not a huge deal at all of course. I just copied
what atheros does with ar :-) so mx seems good enough.

> > can we confirm that this means
> > we are to submit subsequent patchset revisions in the same per-file
> > format until everyone is happy with the driver, and then raise the PR?
> 
> I wouldn't necessarily way _everyone_, you can probably always find
> someone willing to nitpick if you look hard enough ;-)

:)

> Obviously I hope/expect you're going to continue to maintaining the
> driver and we'll have to figure out the workflow for that

That's the goal of course. As for future work, right now both the
kernel support + this driver is about as barebones as you get so we
intend to continue expanding that. It felt best to push the driver
now as the bare minimum such that people can start using the upstream
S1G work. We have a lot more to do.

> perhaps depending on how much work you're planning to put 
> into it.

We expect to see some larger features - including monitor mode, and
mesh in the near to mid-term future within the driver itself, but the
core development will still remain in mac80211 & cfg80211 as we
extend the S1G implementation. As for workflows, we are still figuring
that out for ourselves.

lachlan