From: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Gregory CLEMENT
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Wim Van Sebroeck <wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org>,
Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
kernel-build-reports-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
Date: Fri, 26 Feb 2016 09:14:10 +0100 [thread overview]
Message-ID: <20160226091410.5dad4306@free-electrons.com> (raw)
In-Reply-To: <20160226030949.GL18327-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Mark,
On Fri, 26 Feb 2016 12:09:49 +0900, Mark Brown wrote:
> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it. atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway. The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.
atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
not only during initialization. The reason we use atomic_io_modify()
here is because this TIMER_CTRL register is shared with the clocksource
drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
watchdogs share a single register that allows to enable/disable all
timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.
By far the easiest solution is to add "depends on ARM" to
ORION_WATCHDOG.
Another solution would be to provide an implementation of
atomic_io_modify() on arm64, though that would need the ACK from the
ARM64 maintainers.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Mark Brown <broonie@kernel.org>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>,
Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
Wim Van Sebroeck <wim@iguana.be>,
Guenter Roeck <linux@roeck-us.net>,
kernel-build-reports@lists.linaro.org,
linaro-kernel@lists.linaro.org, linux-next@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org
Subject: Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
Date: Fri, 26 Feb 2016 09:14:10 +0100 [thread overview]
Message-ID: <20160226091410.5dad4306@free-electrons.com> (raw)
In-Reply-To: <20160226030949.GL18327@sirena.org.uk>
Mark,
On Fri, 26 Feb 2016 12:09:49 +0900, Mark Brown wrote:
> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it. atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway. The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.
atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
not only during initialization. The reason we use atomic_io_modify()
here is because this TIMER_CTRL register is shared with the clocksource
drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
watchdogs share a single register that allows to enable/disable all
timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.
By far the easiest solution is to add "depends on ARM" to
ORION_WATCHDOG.
Another solution would be to provide an implementation of
atomic_io_modify() on arm64, though that would need the ACK from the
ARM64 maintainers.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
Date: Fri, 26 Feb 2016 09:14:10 +0100 [thread overview]
Message-ID: <20160226091410.5dad4306@free-electrons.com> (raw)
In-Reply-To: <20160226030949.GL18327@sirena.org.uk>
Mark,
On Fri, 26 Feb 2016 12:09:49 +0900, Mark Brown wrote:
> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it. atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway. The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.
atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
not only during initialization. The reason we use atomic_io_modify()
here is because this TIMER_CTRL register is shared with the clocksource
drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
watchdogs share a single register that allows to enable/disable all
timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.
By far the easiest solution is to add "depends on ARM" to
ORION_WATCHDOG.
Another solution would be to provide an implementation of
atomic_io_modify() on arm64, though that would need the ACK from the
ARM64 maintainers.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-02-26 8:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 10:04 next-20160225 build: 2 failures 44 warnings (next-20160225) Build bot for Mark Brown
2016-02-25 22:49 ` Stephen Rothwell
2016-02-26 10:37 ` Kirill A. Shutemov
2016-02-26 3:04 ` Mark Brown
2016-02-26 3:04 ` Mark Brown
2016-02-26 8:08 ` Thomas Petazzoni
2016-02-26 8:08 ` Thomas Petazzoni
2016-02-26 19:34 ` Bjorn Helgaas
2016-02-26 19:34 ` Bjorn Helgaas
2016-02-26 3:09 ` Mark Brown
2016-02-26 3:09 ` Mark Brown
2016-02-26 3:09 ` Mark Brown
[not found] ` <20160226030949.GL18327-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-02-26 7:41 ` Guenter Roeck
2016-02-26 7:41 ` Guenter Roeck
2016-02-26 7:41 ` Guenter Roeck
[not found] ` <56D001BE.2090209-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2016-02-26 8:21 ` Thomas Petazzoni
2016-02-26 8:21 ` Thomas Petazzoni
2016-02-26 8:21 ` Thomas Petazzoni
2016-02-26 8:14 ` Thomas Petazzoni [this message]
2016-02-26 8:14 ` Thomas Petazzoni
2016-02-26 8:14 ` Thomas Petazzoni
[not found] ` <20160226091410.5dad4306-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-02-26 12:12 ` Mark Brown
2016-02-26 12:12 ` Mark Brown
2016-02-26 12:12 ` Mark Brown
[not found] ` <20160226121220.GO18327-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-02-27 14:40 ` Thomas Petazzoni
2016-02-27 14:40 ` Thomas Petazzoni
2016-02-27 14:40 ` Thomas Petazzoni
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=20160226091410.5dad4306@free-electrons.com \
--to=thomas.petazzoni-wi1+55scjutkeb57/3fjtnbpr1lh4cv8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=kernel-build-reports-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.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 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.