From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Guenter Roeck <linux@roeck-us.net>,
linux-arm-kernel@lists.infradead.org,
Duanqiang Wen <duanqiangwen@net-swift.com>,
mturquette@baylibre.com, sboyd@kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clkdev: report over-sized strings when creating clkdev entries
Date: Wed, 22 May 2024 10:34:22 +0100 [thread overview]
Message-ID: <Zk28HtN30TJvnZan@shell.armlinux.org.uk> (raw)
In-Reply-To: <44151fe7-1822-4b95-8981-9a1f1884d662@leemhuis.info>
On Wed, May 22, 2024 at 08:53:18AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hmmm. Communication problem aside, this in the end seems to be a
> regression that is caused by a change of yours. Maybe not a major one
> that is making a fuzz about, but still one that would be good to get
> fixed. So who will take care of that?
I have suggested several approaches to fixing it, and each time I'm
being ignored by Guenter, who seems to have some other agenda -
because he seems to believe that using dev_name() when registering
the clk with clkdev is wrong... despite the fact that clkdev uses
dev_name().
What I am uncertain about is:
1) whether clkdev is even necessary here, or whether it is pure noise.
I think it's pure noise. Why? The dev_name() that is being used#
to register the clk seems to be the _source_ device of the clock,
whereas the name given should be the _consumer_ of the clock (when
clk_get(dev, con_id) is called, dev is the _consumer_ device, and
this is the device that dev_name() is used internally with.) Thus,
if _that_ device is not the same as the struct device that is being
passed to dev_name() when registering the clk, the entry in clkdev
is utterly useless.
2) why someone would think that using best_dev_name() to work around
this would be a good idea. One might as well pass the string
"hahaha" when registering the clk - because if the device name is
truncated, clk_get() is not going to find it. So, by registering
it with clkdev, we're just eating memory for no reason.
Therefore, this change is finding bugs elsewhere. Should it cause a
boot failure? No, and I'm happy to make clkdev just warn about it.
However, reverting the change means we're not going to find these
issues.
Why was the change originally proposed (by Duanqiang Wen) ? The reason
was because of this truncation causing clk_get() to fail unexpectedly.
I am all for a _sensible_ discussion over this - not one that seems to
have an agenda about "should dev_name() be used when registering a
clk" that seems to be Guenter's approach because _that_ is not the root
cause of the issue and I've already explained that _that_ is not the
issue here. Yet, Guenter insists on that.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-05-22 9:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 11:47 [PATCH] clkdev: report over-sized strings when creating clkdev entries Russell King (Oracle)
2024-04-08 3:48 ` Stephen Boyd
2024-05-02 0:59 ` Stephen Boyd
2024-05-02 1:02 ` Stephen Boyd
2024-05-02 8:02 ` Russell King (Oracle)
2024-05-02 8:22 ` Russell King (Oracle)
2024-05-02 11:08 ` Russell King (Oracle)
2024-05-02 22:18 ` Stephen Boyd
2024-05-17 22:09 ` Guenter Roeck
2024-05-17 22:22 ` Russell King (Oracle)
2024-05-17 23:34 ` Guenter Roeck
2024-05-17 23:37 ` Russell King (Oracle)
2024-05-18 3:24 ` Guenter Roeck
2024-05-18 7:01 ` Russell King (Oracle)
2024-05-22 6:53 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-22 9:34 ` Russell King (Oracle) [this message]
2024-05-22 9:37 ` Russell King (Oracle)
2024-05-22 21:32 ` Guenter Roeck
2024-05-18 13:44 ` Guenter Roeck
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=Zk28HtN30TJvnZan@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=duanqiangwen@net-swift.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mturquette@baylibre.com \
--cc=regressions@lists.linux.dev \
--cc=sboyd@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).