From: Tony Lindgren <tony@atomide.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Mark Brown <broonie@kernel.org>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-pm@vger.kernel.org
Subject: Re: PM regression in next
Date: Mon, 15 Jan 2018 08:50:51 -0800 [thread overview]
Message-ID: <20180115165050.GJ4821@atomide.com> (raw)
In-Reply-To: <87wp0jzyig.wl%kuninori.morimoto.gx@renesas.com>
* Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> [180115 01:46]:
>
> Hi all
>
> > > > Most devices have one regmap per device which can be retrieved with
> > > > dev_get_regmap(), it's the attempt to use that which I suspect is
> > > > broken. Like I said snd_soc_codec_init_regmap() ought to fix things if
> > > > that's the issue.
> >
> > > OK. Adding Peter to loop as it's his driver after all. Not sure
> > > how well mixing regmap register access to the same module with
> > > cached twl4030_read() would work :)
> >
> > Yes, that local cache is not a super good idea any more and hopefully
> > redundant.
> >
> > > Maybe there should also be some big warning happening if
> > > snd_soc_codec_init_regmap() is now needed and no regmap is
> > > found?
> >
> > Some devices just plain don't have registers at all (perhaps GPIOs or
> > just stub drivers providing capability information). However we should
> > be screaming loudly about the fact that the I/O we tried to do fails,
> > that clearly shouldn't be being ignored.
>
> I'm sorry that my patch breaks your drivers.
> It seems removing .read/.write callback was too much aggressive.
No problem, things happen. The thing I'm worried about here
though is that these patches were "completely untested
clean-up patches" :) For the next set of changes like this,
please make sure you Cc the driver authors so they can test
and ack the changes if you can't test them, OK?
> I hope your driver will be OK by using regmap.
> In worst case, we can back .read/.write, but it will be component driver side.
Well we have the merge window about to open in a week, so
please just revert the known broken patches.
Like I described, it looks all the non-regmap drivers with
read/write function pointers removed are broken now.
Just adding back the read/write function pointers while
keeping your other changes seems also risky to me at this
point. It seems it should work for twl4030 and twl6030
though, have not checked the other drivers but they seem
to have more changes.
Regards,
Tony
next prev parent reply other threads:[~2018-01-15 16:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 0:01 PM regression in next Tony Lindgren
2018-01-12 0:18 ` Andrew Morton
2018-01-12 0:23 ` Tony Lindgren
2018-01-12 0:45 ` Andrew Morton
2018-01-12 1:20 ` Tony Lindgren
2018-01-12 1:32 ` Tony Lindgren
2018-01-12 12:23 ` Rafael J. Wysocki
2018-01-12 12:30 ` Rafael J. Wysocki
2018-01-12 13:01 ` Lars-Peter Clausen
2018-01-12 13:16 ` Andrew Lunn
2018-01-12 13:52 ` Tony Lindgren
2018-01-12 13:55 ` Andrew Lunn
2018-01-12 14:14 ` Tony Lindgren
2018-01-12 19:00 ` Tony Lindgren
2018-01-12 19:12 ` Mark Brown
2018-01-12 21:07 ` Tony Lindgren
2018-01-12 21:15 ` Mark Brown
2018-01-12 21:50 ` Tony Lindgren
2018-01-12 22:11 ` Mark Brown
2018-01-12 22:49 ` Tony Lindgren
2018-01-12 22:59 ` Mark Brown
2018-01-15 1:45 ` Kuninori Morimoto
2018-01-15 16:50 ` Tony Lindgren [this message]
2018-01-15 17:19 ` Mark Brown
2018-01-15 17:52 ` Tony Lindgren
2018-01-15 17:56 ` Mark Brown
2018-01-15 18:06 ` Tony Lindgren
2018-01-15 18:13 ` Mark Brown
2018-01-15 18:55 ` Tony Lindgren
2018-01-16 0:38 ` Kuninori Morimoto
2018-01-17 9:47 ` Peter Ujfalusi
2018-01-15 23:22 ` Kuninori Morimoto
2018-01-16 0:36 ` Tony Lindgren
2018-01-12 21:38 ` Mark Brown
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=20180115165050.GJ4821@atomide.com \
--to=tony@atomide.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=rafael.j.wysocki@intel.com \
--cc=sfr@canb.auug.org.au \
/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).