From: Stephen Boyd <sboyd@kernel.org>
To: Matti Vaittinen <mazziesaccount@gmail.com>,
Maxime Ripard <maxime@cerno.tech>
Cc: "Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Emma Anholt" <emma@anholt.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Maíra Canal" <mcanal@igalia.com>,
"Javier Martinez Canillas" <javierm@redhat.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Noralf Trønnes" <noralf@tronnes.org>,
"Matti Vaittinen" <matti.vaittinen@fi.rohmeurope.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v4 2/8] kunit: drm/tests: move generic helpers
Date: Tue, 21 Mar 2023 11:59:57 -0700 [thread overview]
Message-ID: <3479e3d4e5e1d84243ca35398ab392ef.sboyd@kernel.org> (raw)
In-Reply-To: <d13cd7bf-0b1e-e9e1-266a-00db40e51de7@gmail.com>
Quoting Matti Vaittinen (2023-03-20 22:45:52)
> Morning Stephen,
>
> On 3/20/23 21:23, Stephen Boyd wrote:
> > Quoting Matti Vaittinen (2023-03-18 23:36:20)
> >>>
> >>> I think you would have an easier time if you just copied and renamed
> >>> them into the kunit folder as an preparation series.
> >>
> >> Yes. That would simplify the syncing between the trees. It slightly bugs
> >> me to add dublicate code in kernel-but the clean-up series for DRM users
> >> could be prepared at the same time. It would be even possible to just
> >> change the drm-helper to be a wrapper for the generic one - and leave
> >> the callers intact - although it leaves some seemingly unnecessary
> >> "onion code" there.
> >>
> >>> That way, you wouldn't have to coordinate DRM, CCF and IIO, you'd just
> >>> create new helpers that can be reused/converted to by everyone eventually
> >>
> >> Yes. Thanks - I think I may go with this approach for the v5 :)
> >
> > Which kunit directory?
>
> I was thinking of adding the platform_device.h (I liked your suggestion)
> in the include/kunit/
Ok, thanks for clarifying.
>
> > I imagine if there are conflicts they will be
> > trivial so it probably doesn't matter.
>
> Probably so. Still, I am not the one who needs to deal with the
> conflicts. Hence I like at least asking if people see good way to avoid
> them in the first place.
Same for me. I'm not the maintainer of the drivers/base directory.
>
> Besides, I was not sure if you were planning to add similar helper or
> just wrappers to individual functions. Wanted to ping you just in case
> this has some impact to what you do.
I don't have a need to bind a device to a driver to satisfy devm APIs
currently. I could probably use it though to test some devm code in the
clk APIs. The only impact is that we're modifying the same files.
>
> > Have you Cced kunit folks and the
> > list on the kunit patches? They may have some opinion.
>
> This patch was should have contained the
> include/kunit/platform_device.h. That file was pulling the Kunit people
> in recipients but I messed up things with last minute changes so both
> the header and people were dropped. I'll fix this for v5.
>
Ok, I'll be on the lookout for v5. From what I can tell kunit goes
through the kernel selftest tree and there isn't a kunit git tree as
such.
next prev parent reply other threads:[~2023-03-21 19:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 14:40 [PATCH v4 0/8] Support ROHM BU27034 ALS sensor Matti Vaittinen
2023-03-17 14:41 ` [PATCH v4 1/8] drm/tests: helpers: rename generic helpers Matti Vaittinen
2023-03-17 14:42 ` [PATCH v4 2/8] kunit: drm/tests: move " Matti Vaittinen
2023-03-17 15:09 ` Maxime Ripard
2023-03-19 6:36 ` Matti Vaittinen
2023-03-20 19:23 ` Stephen Boyd
2023-03-21 5:45 ` Matti Vaittinen
2023-03-21 18:59 ` Stephen Boyd [this message]
2023-03-22 6:16 ` Vaittinen, Matti
2023-03-22 9:44 ` Andy Shevchenko
2023-03-19 16:57 ` [PATCH v4 0/8] Support ROHM BU27034 ALS sensor Jonathan Cameron
2023-03-20 10:10 ` Matti Vaittinen
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=3479e3d4e5e1d84243ca35398ab392ef.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emma@anholt.net \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=javierm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=maxime@cerno.tech \
--cc=mazziesaccount@gmail.com \
--cc=mcanal@igalia.com \
--cc=noralf@tronnes.org \
--cc=rafael@kernel.org \
--cc=tzimmermann@suse.de \
/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