From: Jakub Kicinski <kuba@kernel.org>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>,
Manivannan Sadhasivam <mani@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, <andersson@kernel.org>,
<daniel@ffwll.ch>, <mhi@lists.linux.dev>,
<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>,
Kalle Valo <kvalo@kernel.org>
Subject: Re: [PATCH] bus: mhi: host: Add userspace character interface
Date: Wed, 31 May 2023 09:14:19 -0700 [thread overview]
Message-ID: <20230531091419.5373352d@kernel.org> (raw)
In-Reply-To: <31c8a9ef-bc48-138d-836b-61efd9f4128f@quicinc.com>
On Wed, 31 May 2023 09:04:10 -0600 Jeffrey Hugo wrote:
> I think Mani I looking for some "guidance" on the "architecture", and
> frankly so am I. An official Ack from Jakub might not be quite the
> right thing at this stage, but at-least Jakub could come in and say he
> isn't planning on NACKing this right off the bat, in particular because
> this functionality can be used by WWAN devices which seems to be what
> caused the mess the last time around.
>
> We've gone full circle here. This functionality was proposed as part of
> the bus. Jakub came in an NACKed that, which resulted in the WWAN
> subsystem and the guidance that this functionally belongs with the
> devices. I tried to put it with the AIC100/QAIC device based on that,
> and that got NACKed by Daniel (GPU) saying that this belongs with the
> bus. You (Greg) seemed to agree with Daniel on that.
>
> Fixing kernel robot tests is one thing (I haven't seen any reports on
> this iteration), but if there is no agreement on where this lives, isn't
> it DOA?
>
> In summary, if you don't like this, please give some clear guidance.
> Greg, you've told me in the past that you don't discuss "architecture"
> without seeing the code. Here is some code. I don't claim it is
> perfect (you mentioned the QAIC version had some issues you were going
> to help with), but I would like to see some input.
Nothing changed here as far as I'm concerned.
But while I have you -- you should probably discuss your broader
engagement in the upstream community with someone like Greg. The right
balance between throwing code at us and supporting maintainers.
I mean real maintainers of shared subsystems, not your own stuff.
prev parent reply other threads:[~2023-05-31 16:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 19:04 [PATCH] bus: mhi: host: Add userspace character interface Jeffrey Hugo
2023-05-23 1:27 ` kernel test robot
2023-05-31 14:28 ` Manivannan Sadhasivam
2023-05-31 14:35 ` Greg KH
2023-05-31 15:01 ` Manivannan Sadhasivam
2023-05-31 15:04 ` Jeffrey Hugo
2023-05-31 15:05 ` Jeffrey Hugo
2023-05-31 16:14 ` Jakub Kicinski [this message]
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=20230531091419.5373352d@kernel.org \
--to=kuba@kernel.org \
--cc=andersson@kernel.org \
--cc=daniel@ffwll.ch \
--cc=gregkh@linuxfoundation.org \
--cc=kvalo@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mani@kernel.org \
--cc=mhi@lists.linux.dev \
--cc=quic_jhugo@quicinc.com \
--cc=quic_pkanojiy@quicinc.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.