From: Lukasz Luba <lukasz.luba@arm.com>
To: Christoph Hellwig <hch@infradead.org>,
Xuewen Yan <xuewen.yan94@gmail.com>
Cc: Xuewen Yan <xuewen.yan@unisoc.com>,
rafael@kernel.org, pavel@kernel.org, lenb@kernel.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
ke.wang@unisoc.com
Subject: Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free
Date: Mon, 27 Jul 2026 09:03:04 +0100 [thread overview]
Message-ID: <82e71c8f-7755-43f6-9518-209525f5acbc@arm.com> (raw)
In-Reply-To: <amCHAZgQQkgDSQYo@infradead.org>
On 7/22/26 10:01, Christoph Hellwig wrote:
> On Tue, Jul 21, 2026 at 07:10:38PM +0800, Xuewen Yan wrote:
>> we use it in android vendor specific ko, and the ko is not upstream.
>> We use them with em_dev_update_perf_domain(), Just like
>> em_dev_update_perf_domain() was exported, export the
>> em_table_alloc/free.
>
> As you've probably been told many times exporting symbols without
> in-tree users that are in the same series or at least directly
> references is a no-go, and continuing to post them is considered
> extremely offensive. Don't do this.
>
It's a bit more complex situation IMHO. We have been always
struggling to involve kernel folks from Android world to contribute
into the mainline Linux. The thing is they have to apply some hacks
in order to make the plumbing for the new devices. This is
an example where they struggle. They ask work vendor hooks to workaround
which complicates even more the maintenance of stable Android kernel.
I have seen those good examples where finally the drivers are pushed
upstream, since downstream maintenance complexity is too high. Something
has to break this circle.
next prev parent reply other threads:[~2026-07-27 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 8:24 Xuewen Yan
2026-07-10 8:24 ` [RFC PATCH 2/2] PM: EM: Validate new_table in em_dev_update_perf_domain() Xuewen Yan
2026-07-10 8:36 ` Lukasz Luba
2026-07-10 8:34 ` [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free Lukasz Luba
2026-07-13 7:34 ` Christoph Hellwig
2026-07-21 11:10 ` Xuewen Yan
2026-07-22 9:01 ` Christoph Hellwig
2026-07-27 8:03 ` Lukasz Luba [this message]
2026-07-28 3:36 ` Christoph Hellwig
2026-07-28 8:07 ` Lukasz Luba
2026-07-28 8:17 ` Christoph Hellwig
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=82e71c8f-7755-43f6-9518-209525f5acbc@arm.com \
--to=lukasz.luba@arm.com \
--cc=hch@infradead.org \
--cc=ke.wang@unisoc.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®