From: Tony Lindgren <tony@atomide.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Arnd Bergmann <arnd@arndb.de>, Tero Kristo <t-kristo@ti.com>,
Philipp Zabel <philipp.zabel@gmail.com>,
linux-omap@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: GPIO regression in Linux next caused by syscon change
Date: Mon, 15 Feb 2016 08:47:57 -0800 [thread overview]
Message-ID: <20160215164757.GV19432@atomide.com> (raw)
In-Reply-To: <1455552961.4899.37.camel@pengutronix.de>
* Philipp Zabel <p.zabel@pengutronix.de> [160215 08:17]:
> Am Montag, den 15.02.2016, 08:01 -0800 schrieb Tony Lindgren:
> > * Philipp Zabel <philipp.zabel@gmail.com> [160214 11:24]:
> > > I've just replaced the of_iomap() call with an open coded version,
> > > calling of_address_to_resource() and ioremap() directly. That was
> > > needed so I can use the struct resource returned by
> > > of_address_to_resource() to set the syscon_config.max_register. I
> > > don't see where this could cause resource overlap. Does just setting
> > > syscon_config.max_register to zero again make the problem disappear?
> >
> > Yes commenting out the syscon_config.max_register line in your patch
> > makes things work again.
> >
> > So what does that tell us about the problem?
>
> Maybe some out of bounds writes that previously worked are now catched
> by the max_register check in regmap_writable and regmap_write returns
> -EIO instead of the write being executed.
Hmm weird that something like that would not produce errors?
> Is there any omap_ctrl_write?() call with an offset > 0x32c into
> scm_conf?
Indeed, that's where things go wrong. Adding Tero to Cc, something
is wrong there.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: GPIO regression in Linux next caused by syscon change
Date: Mon, 15 Feb 2016 08:47:57 -0800 [thread overview]
Message-ID: <20160215164757.GV19432@atomide.com> (raw)
In-Reply-To: <1455552961.4899.37.camel@pengutronix.de>
* Philipp Zabel <p.zabel@pengutronix.de> [160215 08:17]:
> Am Montag, den 15.02.2016, 08:01 -0800 schrieb Tony Lindgren:
> > * Philipp Zabel <philipp.zabel@gmail.com> [160214 11:24]:
> > > I've just replaced the of_iomap() call with an open coded version,
> > > calling of_address_to_resource() and ioremap() directly. That was
> > > needed so I can use the struct resource returned by
> > > of_address_to_resource() to set the syscon_config.max_register. I
> > > don't see where this could cause resource overlap. Does just setting
> > > syscon_config.max_register to zero again make the problem disappear?
> >
> > Yes commenting out the syscon_config.max_register line in your patch
> > makes things work again.
> >
> > So what does that tell us about the problem?
>
> Maybe some out of bounds writes that previously worked are now catched
> by the max_register check in regmap_writable and regmap_write returns
> -EIO instead of the write being executed.
Hmm weird that something like that would not produce errors?
> Is there any omap_ctrl_write?() call with an offset > 0x32c into
> scm_conf?
Indeed, that's where things go wrong. Adding Tero to Cc, something
is wrong there.
Regards,
Tony
next prev parent reply other threads:[~2016-02-15 16:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-13 0:26 GPIO regression in Linux next caused by syscon change Tony Lindgren
2016-02-13 0:26 ` Tony Lindgren
2016-02-13 0:49 ` Tony Lindgren
2016-02-13 0:49 ` Tony Lindgren
2016-02-14 19:22 ` Philipp Zabel
2016-02-14 19:22 ` Philipp Zabel
2016-02-15 16:01 ` Tony Lindgren
2016-02-15 16:01 ` Tony Lindgren
2016-02-15 16:16 ` Philipp Zabel
2016-02-15 16:16 ` Philipp Zabel
2016-02-15 16:47 ` Tony Lindgren [this message]
2016-02-15 16:47 ` Tony Lindgren
2016-02-15 18:06 ` Tony Lindgren
2016-02-15 18:06 ` Tony Lindgren
2016-02-20 10:59 ` Tero Kristo
2016-02-20 10:59 ` Tero Kristo
2016-02-22 16:35 ` Tony Lindgren
2016-02-22 16:35 ` Tony Lindgren
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=20160215164757.GV19432@atomide.com \
--to=tony@atomide.com \
--cc=arnd@arndb.de \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=philipp.zabel@gmail.com \
--cc=t-kristo@ti.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.