* [Buildroot] [PATCH 1/5] qt5: bump to 5.8.0-beta
From: Arnout Vandecappelle @ 2016-11-08 22:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1478601048-21388-2-git-send-email-anaumann@ultratronik.de>
On 08-11-16 11:30, Andreas Naumann wrote:
> Removed all hashes (until final release).
Review would have been easier if you did that in a separate patch.
>
> - qt5base: renamed library to EglFSDeviceIntegration ([1])
> - qt5base: remove ras-pi patch
You should mention in the commit message why: (applied upstream).
> - qt5base: remove obsolete config-option -large ([2])
-largefile, not -large. Also mention explicitly what happened: largefile is not
always enabled.
> - qt5base: make the directfb platform plugin compile ([3])
> - qt53d/quickcontrols2/serialbus: move out of tech-preview
I didn't see this in your patch?
> - qt5enginio: remove discontinued module
This should have been done in a separate commit.
>
> [1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=ec4eb4db61094179bc6a9ec26ec68fb710177053
> [2] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=84d3a21c9efe7efb2cce6d3bd14af1f9580b1108
> [3] Without this patch, qmake is looking for directfb_egl feature which usually is not
> provided (only by some raspi mkspec afaics).
>
> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
[snip]
> diff --git a/package/qt5/qt5base/0001-directfb-make-platform-plugin-compile.patch b/package/qt5/qt5base/0001-directfb-make-platform-plugin-compile.patch
> new file mode 100644
> index 0000000..96cc3b0
> --- /dev/null
> +++ b/package/qt5/qt5base/0001-directfb-make-platform-plugin-compile.patch
> @@ -0,0 +1,22 @@
Missing patch description + SoB. Also make it a git-formatted patch.
For this patch, it is absolutely necessary to get upstream feedback because it
looks very iffy to me.
> +diff --git a/src/plugins/platforms/directfb/directfb.pro b/src/plugins/platforms/directfb/directfb.pro
> +index 406b89e..a83b09f 100644
> +--- a/src/plugins/platforms/directfb/directfb.pro
> ++++ b/src/plugins/platforms/directfb/directfb.pro
> +@@ -3,7 +3,7 @@ TARGET = qdirectfb
> + QT += \
> + core-private gui-private \
> + eventdispatcher_support-private service_support-private \
> +- fontdatabase_support-private egl_support-private
> ++ fontdatabase_support-private
> +
> + QMAKE_USE += directfb
> +
> +@@ -27,7 +27,7 @@ HEADERS = qdirectfbintegration.h \
> + qdirectfbeglhooks.h
> +
> + # ### port the GL context
> +-qtConfig(directfb_egl) {
> ++contains(QT_CONFIG, directfb_egl) {
Aren't these two equivalent? If this is being built for anything other than
linux-mipsel-broadcom-97425-g++, there is really something weird going on...
Anyway, to make the patch correct, you should add QT += egl_support-private here.
Regards,
Arnout
> + HEADERS += qdirectfb_egl.h
> + SOURCES += qdirectfb_egl.cpp
> + DEFINES += DIRECTFB_GL_EGL
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* Re: [PATCH v3 1/8] exec: introduce cred_guard_light
From: Eric W. Biederman @ 2016-11-08 22:46 UTC (permalink / raw)
To: Kees Cook
Cc: Oleg Nesterov, Jann Horn, Alexander Viro, Roland McGrath,
John Johansen, James Morris, Serge E. Hallyn, Paul Moore,
Stephen Smalley, Eric Paris, Casey Schaufler, Andrew Morton,
Janis Danisevskis, Seth Forshee, Thomas Gleixner,
Benjamin LaHaise, Ben Hutchings, Andy Lutomirski, Linus Torvalds,
Krister Johansen, linux-fsdevel@vger.kernel.org,
linux-security-module, security@kernel.org
In-Reply-To: <CAGXu5jL3AZii611qGbVyOCaK-Ua1+3H7i2KAV3zfT0hGRUiAZQ@mail.gmail.com>
Kees Cook <keescook@chromium.org> writes:
> On Fri, Nov 4, 2016 at 11:45 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>> Eric, I hope you see my emails, I got the "Undelivered Mail Returned to Sender"
>> ...
Oleg I can receive your messages directly and through vger.kernel.org
lists, but I can't receive them through the email reflector at
security@kernel.org.
>> This is the mail system at host mail.kernel.org.
>> ...
>> <ebiederm@xmission.com> (expanded from <security@kernel.org>): host
>> mx.xmission.com[166.70.12.20] said: 550-XM-RJCT16: SPF Failure
>> (ip=198.145.29.136, frm=oleg@redhat.com, 550 result=fail) (in reply to RCPT
>> TO command)
>>
>> right now I have no idea what does this mean.
>
> This is a problem for Google folks too sometimes. This is saying that
> xmission.com is checking redhat.com's SPF records and refusing to let
> kernel.org deliver email as if it were redhat.com (due to
> security@kernel.org being an alias not a mailing list). There aren't
> good solutions for this, but best I've found is to have my
> security@kernel.org alias be a @kernel.org address instead of an
> @google.com address...
Ugh. Is even redhat configuring the redhat email to do that?
I will have to look.
Last I looked xmission.com was just enforcing the policy that the other
mail domains were asking to be enforced on themselves. But those are
policies that are incompatible with mailing lists in general. Although
I do get confused about which part SPF and DKIM play in this mess.
I just remember that the last several ``enhancements'' to email were
busily breaking mailing lists and I thought they were completely insane.
I can even find evidence that it is (or at least was) so bad that email
standards comittee member's can't comminicate with each other via email
lists.
vger.kernel.org appears to rewrite the envelope sender to avoid
problems.
If xmission is doing any more than just performing what the domain of
the senders of email asked them to do I will be happy to see if I can
to sort it out.
Eric
^ permalink raw reply
* Could receive allow updating an existing subvolume?
From: Ian Kelling @ 2016-11-08 22:48 UTC (permalink / raw)
To: linux-btrfs
It seems to be an artificially imposed limitation which hurts which
hurts its usefulness. Let me know if this makes sense. If so, perhaps it
can be implemented eventually. It seems a bit obvious but I couldn't
find any existing discussion of it.
Say you have this situation:
a/1, a/2 (parent is a/1)
b/1 (received from a/1)
Currently, you can (abbreviated) "send -p a/1 a/2 | receive" to create
b/2 (received from a/2, parent is b/1).
b/2 must start out as a rw snapshot from b/1, so we start out with 2
identical subvolumes except for some metadata and rw status, why not
have an option to update the existing subvol instead of the new one?
For example, when receive starts, rename b/1 to b/2, take an ro snapshot
of b/2 named b/1, set b/2 to rw, update b/2's metadata, then update b/2
with the new incremental data just as before.
The current situation severely limits the use case of having a host
which has read-only data which is incrementally updated, which is
read/served by standard programs, not just backup restore tools, because
to have any persistent paths, you need to remount using the new
subvolume (generally means killing programs reading from it), or using
paths that begin like /dir/b{1,2} and then renaming subvolumes, and then
requesting that all reading programs reopen their files because they
will still have references in the old subvolume (again, often means
killing programs).
^ permalink raw reply
* [PATCH] clk: pxa: Use __iomem properly and staticize lock variable
From: Stephen Boyd @ 2016-11-08 22:47 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd; +Cc: linux-kernel, linux-clk, Robert Jarzmik
This function is passed an __iomem pointer but we use a u32
pointer instead which makes checkers like spare complain.
Furthermore, "lock" is a pretty poor variable name for a string
that will go into lockdep reports and the symbol isn't marked
static. Cleanup all this.
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/clk/pxa/clk-pxa.c | 7 ++++---
drivers/clk/pxa/clk-pxa.h | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/pxa/clk-pxa.c b/drivers/clk/pxa/clk-pxa.c
index 50fb9d0ea58d..29fc71617bad 100644
--- a/drivers/clk/pxa/clk-pxa.c
+++ b/drivers/clk/pxa/clk-pxa.c
@@ -38,7 +38,7 @@
#define MDREFR_DB2_MASK (MDREFR_K2DB2 | MDREFR_K1DB2)
#define MDREFR_DRI_MASK 0xFFF
-DEFINE_SPINLOCK(lock);
+static DEFINE_SPINLOCK(pxa_clk_lock);
static struct clk *pxa_clocks[CLK_MAX];
static struct clk_onecell_data onecell_data = {
@@ -109,7 +109,7 @@ int __init clk_pxa_cken_init(const struct desc_clk_cken *clks, int nb_clks)
pxa_clk->lp = clks[i].lp;
pxa_clk->hp = clks[i].hp;
pxa_clk->gate = clks[i].gate;
- pxa_clk->gate.lock = &lock;
+ pxa_clk->gate.lock = &pxa_clk_lock;
clk = clk_register_composite(NULL, clks[i].name,
clks[i].parent_names, 2,
&pxa_clk->hw, &cken_mux_ops,
@@ -155,7 +155,8 @@ void pxa2xx_core_turbo_switch(bool on)
}
void pxa2xx_cpll_change(struct pxa2xx_freq *freq,
- u32 (*mdrefr_dri)(unsigned int), u32 *mdrefr, u32 *cccr)
+ u32 (*mdrefr_dri)(unsigned int), void __iomem *mdrefr,
+ void __iomem *cccr)
{
unsigned int clkcfg = freq->clkcfg;
unsigned int unused, preset_mdrefr, postset_mdrefr;
diff --git a/drivers/clk/pxa/clk-pxa.h b/drivers/clk/pxa/clk-pxa.h
index 58abfa816d53..2b90c5917b32 100644
--- a/drivers/clk/pxa/clk-pxa.h
+++ b/drivers/clk/pxa/clk-pxa.h
@@ -155,8 +155,8 @@ void clk_pxa_dt_common_init(struct device_node *np);
void pxa2xx_core_turbo_switch(bool on);
void pxa2xx_cpll_change(struct pxa2xx_freq *freq,
- u32 (*mdrefr_dri)(unsigned int), u32 *mdrefr,
- u32 *cccr);
+ u32 (*mdrefr_dri)(unsigned int), void __iomem *mdrefr,
+ void __iomem *cccr);
int pxa2xx_determine_rate(struct clk_rate_request *req,
struct pxa2xx_freq *freqs, int nb_freqs);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH] ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem
From: Dinh Nguyen @ 2016-11-08 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Enables:
CONFIG_AUTOFS4_FS=y
CONFIG_NFSD=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
Signed-off-by: Matthew Gerlach <mgerlach@opensource.altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm/configs/socfpga_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index 18d3ec1..2e1d254 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -116,13 +116,18 @@ CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
CONFIG_TMPFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
CONFIG_ROOT_NFS=y
+CONFIG_NFSD=y
+CONFIG_NFSD_V3_ACL=y
+CONFIG_NFSD_V4=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
--
2.8.3
^ permalink raw reply related
* Re: [RFC] fs: add userspace critical mounts event support
From: Luis R. Rodriguez @ 2016-11-08 22:47 UTC (permalink / raw)
To: Linus Torvalds, Jiri Kosina, Johannes Berg, Jouni Malinen,
Seth Forshee, Tom Gundersen, Kay Sievers, Bjorn Andersson,
Daniel Wagner, Daniel Wagner, Rafael J. Wysocki
Cc: Luis R. Rodriguez, Herbert, Marc, Daniel Vetter, Rob Landley,
Mimi Zohar, Felix Fietkau, David Woodhouse, Roman Pen, Ming Lei,
Andrew Morton, Michal Marek, Greg KH, Linux Kernel Mailing List,
Vikram Mulukutla, Stephen Boyd, Mark Brown, Takashi Iwai,
Christian Lamparter, Hauke Mehrtens, Josh Boyer, Dmitry Torokhov,
Jiri Slaby, Andy Lutomirski, Wu Fengguang, Richard Purdie,
Jeff Mahoney, Jacek Anaszewski, Abhay_Salunke, Julia Lawall,
Gilles.Muller, nicolas.palix, Tom Gundersen, David Howells,
Alessandro Rubini, Kevin Cernekee, Kees Cook, Jonathan Corbet,
Thierry Martinez, linux-serial, open list:DOCUMENTATION,
linuxppc-dev, Josh Triplett
In-Reply-To: <20161005194633.GE3296@wotan.suse.de>
On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote:
> On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote:
> > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
> > >
> > >> I did some shuffling around of those code to make initmpfs work, does
> > >> anybody know why initramfs extraction _before_ we initialize drivers
> > >> would be a bad thing?
> > >
> > > No, but it seems sensible to me, if its done before do_initcalls()
> > > that should resolve the race for initramfs users
> >
> > initramfs should already be set up before drivers are.
>
> Actually you are right, the issue would only be for old initrd, for initramfs
> we populate that via rootfs_initcall(populate_rootfs), so as long as drivers
> in question use an init level beyond rootfs's we're good there.
>
> > Exactly what is it that has trouble right now?
>
> It would seem then that the only current stated race possible should
> then be non-initramfs users.
Or:
a) initramfs users that include a driver but do not include the firmware
into initramfs
b) driver is built-in but firmware is not in initrafms (Johannes reports
this causes driver failure on intel wireless for instance, and I guess
you need to reload)
> One example if very large firmware for
> remote-proc, whereby an initramfs is just not practical or desirable.
This issue still stands. At Plumbers Johannes Berg did indicate to me
he had a simple elegant solution in mind. He suggested that since the
usermode helper was available, he had added support to be able to
differentiate async firmware request calls form sync requests, and that
userspace should not return an error *iff* the request made was async and
it can determine we're initramfs. The semantics issue is the same though,
is there a generic way to determine we're initramfs ? What if we move
multiple levels? Anyway -- provided we could figure this out, userspace
would simply yield and wait until the real rootfs is met. Upon pivot_root()
the assumption is all previous udev events pending would be re-triggered
and finally udev could finally confirm/deny if the firmware was present.
This would *also* allow you to stuff your firmware whever, however big
it was. This however relied on the userspace firmware loading support,
it turns out that (I think because of an incorrect negative backlash
back in the day over blaming this over booting issues due to the timeout
whereas the real issue was the kmod timeout was affecting our long
standing serial init()/probe()) the systemd userspace firmware laoding
support was removed from systemd udev in 2014 by Kay via commit
be2ea723b1d023b3d ("udev: remove userspace firmware loading support").
Systemd might *still* be able to provide a solution here, however I will
note Johannes was asking for *all* async firmware requests to always
rely on the kernel syfs UMH fallback -- this suggestion is against the
direction we've been taking to eventually compartamentalize the kernel UMH
code, so whatever we decide to do, lets please take a breather and seriously
address this properly *with* systemd folks.
A side race discussed at Plumbers worth mentioning given its related to the
UMH was inspired by Jiri's talk on the abuse of the freezer for kthreads --
and his suggestion to use freeze_super(). Currently the UMH lock is used
for the UMH but as I have noted in Daniel Wagner's recent patches to
give some love to this code and further compartamentalize the UMH --
the UMH lock was originally added to help avoid drivers use the firmware
API on resume, given the races. The firmware cache solution implemented by
Ming Lei years ago helped address this, whereby devm helpers are used
based on the requested firmware and prior to suspend we cache all required
firmware for drivers so that upon resume calls would work without the
effective race present. This mitigated the actual races / issues with
drivers, but they must not use the firmware API on suspend/resume. Since
this solution *kills* all pending UMH caller on suspend obviously this
means on suspend using request_firmware*() API and expecting it to work
is brutally dumb as we will eventually kill any pending requests. This
is a long winded way to say that if you rely on the UMH for firmware
you must figure out your own proactive firmware cache solution and
must definitely not request firmware on suspend. Two things then:
1) I've been brainstorming with Daniel how to use freeze_super() to
replace the now invalid UMH lock -- its purpose only helps races
on boot, for the fallback case to the UMH. But note most distributions
disable forcing it always on, so these days we *only* rely on the UMH
as a fallback if the driver explicitly requested it
2) Drivers relying on the UMH very likely have a broken cache solution
if they are doing this on suspend
Whatever the outcome of this discussion is -- Johannes seemed to *want*
to further use the UMH by default on *all* async alls... even if the
driver did not explicitly requested it -- I'm concerned about this given
all the above and the existing flip/flop on systemd for it. Whatever
we try to dream up here, please consider all the above as well.
> > The gating issue for initramfs is that technically the filesystem
> > setup needs to be done, which means that it currently ends up being
> > populated _fairly_ late in the initcall series, but certainly before
> > drivers. But since initramfs really only needs very limited filesystem
> > functionality, I assume Rob had few problems with just moving it
> > earlier.
> >
> > Still, what kind of ordering issues did people have? What is it that
> > needs to load files even before driver init? Some crazy subsystem?
>
> No, I think this is just about non-initramfs users now,
And as Johannes pointed two above to cases.
> if we disregard
> old initrd users. Bjorn, Marc, correct me if I'm wrong, as I think its
> so far you both who have seemed to run into race issues and have then
> ended up trying to look for hacks to address this race or considered using
> the usermode helper (which we're trying to minimize users for). Daniel
> seems to note a lot of video drivers use firmware on probe as well so
> there's a potential issue for those users if they don't use initramfs.
Luis
^ permalink raw reply
* Re: [RFC] fs: add userspace critical mounts event support
From: Luis R. Rodriguez @ 2016-11-08 22:47 UTC (permalink / raw)
To: Linus Torvalds, Jiri Kosina, Johannes Berg, Jouni Malinen,
Seth Forshee, Tom Gundersen, Kay Sievers, Bjorn Andersson,
Daniel Wagner, Daniel Wagner, Rafael J. Wysocki
Cc: Luis R. Rodriguez, Herbert, Marc, Daniel Vetter, Rob Landley,
Mimi Zohar, Felix Fietkau, David Woodhouse, Roman Pen, Ming Lei,
Andrew Morton, Michal Marek, Greg KH, Linux Kernel Mailing List,
Vikram Mulukutla, Stephen Boyd, Mark Brown, Takashi Iwai,
Christian Lamparter, Hauke Mehrtens, Josh Boyer
In-Reply-To: <20161005194633.GE3296@wotan.suse.de>
On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote:
> On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote:
> > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
> > >
> > >> I did some shuffling around of those code to make initmpfs work, does
> > >> anybody know why initramfs extraction _before_ we initialize drivers
> > >> would be a bad thing?
> > >
> > > No, but it seems sensible to me, if its done before do_initcalls()
> > > that should resolve the race for initramfs users
> >
> > initramfs should already be set up before drivers are.
>
> Actually you are right, the issue would only be for old initrd, for initramfs
> we populate that via rootfs_initcall(populate_rootfs), so as long as drivers
> in question use an init level beyond rootfs's we're good there.
>
> > Exactly what is it that has trouble right now?
>
> It would seem then that the only current stated race possible should
> then be non-initramfs users.
Or:
a) initramfs users that include a driver but do not include the firmware
into initramfs
b) driver is built-in but firmware is not in initrafms (Johannes reports
this causes driver failure on intel wireless for instance, and I guess
you need to reload)
> One example if very large firmware for
> remote-proc, whereby an initramfs is just not practical or desirable.
This issue still stands. At Plumbers Johannes Berg did indicate to me
he had a simple elegant solution in mind. He suggested that since the
usermode helper was available, he had added support to be able to
differentiate async firmware request calls form sync requests, and that
userspace should not return an error *iff* the request made was async and
it can determine we're initramfs. The semantics issue is the same though,
is there a generic way to determine we're initramfs ? What if we move
multiple levels? Anyway -- provided we could figure this out, userspace
would simply yield and wait until the real rootfs is met. Upon pivot_root()
the assumption is all previous udev events pending would be re-triggered
and finally udev could finally confirm/deny if the firmware was present.
This would *also* allow you to stuff your firmware whever, however big
it was. This however relied on the userspace firmware loading support,
it turns out that (I think because of an incorrect negative backlash
back in the day over blaming this over booting issues due to the timeout
whereas the real issue was the kmod timeout was affecting our long
standing serial init()/probe()) the systemd userspace firmware laoding
support was removed from systemd udev in 2014 by Kay via commit
be2ea723b1d023b3d ("udev: remove userspace firmware loading support").
Systemd might *still* be able to provide a solution here, however I will
note Johannes was asking for *all* async firmware requests to always
rely on the kernel syfs UMH fallback -- this suggestion is against the
direction we've been taking to eventually compartamentalize the kernel UMH
code, so whatever we decide to do, lets please take a breather and seriously
address this properly *with* systemd folks.
A side race discussed at Plumbers worth mentioning given its related to the
UMH was inspired by Jiri's talk on the abuse of the freezer for kthreads --
and his suggestion to use freeze_super(). Currently the UMH lock is used
for the UMH but as I have noted in Daniel Wagner's recent patches to
give some love to this code and further compartamentalize the UMH --
the UMH lock was originally added to help avoid drivers use the firmware
API on resume, given the races. The firmware cache solution implemented by
Ming Lei years ago helped address this, whereby devm helpers are used
based on the requested firmware and prior to suspend we cache all required
firmware for drivers so that upon resume calls would work without the
effective race present. This mitigated the actual races / issues with
drivers, but they must not use the firmware API on suspend/resume. Since
this solution *kills* all pending UMH caller on suspend obviously this
means on suspend using request_firmware*() API and expecting it to work
is brutally dumb as we will eventually kill any pending requests. This
is a long winded way to say that if you rely on the UMH for firmware
you must figure out your own proactive firmware cache solution and
must definitely not request firmware on suspend. Two things then:
1) I've been brainstorming with Daniel how to use freeze_super() to
replace the now invalid UMH lock -- its purpose only helps races
on boot, for the fallback case to the UMH. But note most distributions
disable forcing it always on, so these days we *only* rely on the UMH
as a fallback if the driver explicitly requested it
2) Drivers relying on the UMH very likely have a broken cache solution
if they are doing this on suspend
Whatever the outcome of this discussion is -- Johannes seemed to *want*
to further use the UMH by default on *all* async alls... even if the
driver did not explicitly requested it -- I'm concerned about this given
all the above and the existing flip/flop on systemd for it. Whatever
we try to dream up here, please consider all the above as well.
> > The gating issue for initramfs is that technically the filesystem
> > setup needs to be done, which means that it currently ends up being
> > populated _fairly_ late in the initcall series, but certainly before
> > drivers. But since initramfs really only needs very limited filesystem
> > functionality, I assume Rob had few problems with just moving it
> > earlier.
> >
> > Still, what kind of ordering issues did people have? What is it that
> > needs to load files even before driver init? Some crazy subsystem?
>
> No, I think this is just about non-initramfs users now,
And as Johannes pointed two above to cases.
> if we disregard
> old initrd users. Bjorn, Marc, correct me if I'm wrong, as I think its
> so far you both who have seemed to run into race issues and have then
> ended up trying to look for hacks to address this race or considered using
> the usermode helper (which we're trying to minimize users for). Daniel
> seems to note a lot of video drivers use firmware on probe as well so
> there's a potential issue for those users if they don't use initramfs.
Luis
^ permalink raw reply
* Re: [PATCH 1/2] clk: pxa mark dummy helper as 'inline'
From: Stephen Boyd @ 2016-11-08 22:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Michael Turquette, Robert Jarzmik, linux-clk, linux-kernel
In-Reply-To: <20161108144950.3472058-1-arnd@arndb.de>
On 11/08, Arnd Bergmann wrote:
> The dummy_clk_set_parent function is marked as 'static' but is
> no longer referenced from the pxa25x clk driver after the last use
> of the RATE_RO_OPS() macro is gone from this file, causing a
> harmless build warning:
>
> In file included from drivers/clk/pxa/clk-pxa25x.c:24:0:
> drivers/clk/pxa/clk-pxa.h:146:12: error: 'dummy_clk_set_parent' defined but not used [-Werror=unused-function]
>
> This marks the functon as 'inline', which lets the compiler simply
> drop it when it gets referenced.
>
> Fixes: 9fe694295098 ("clk: pxa: transfer CPU clock setting from pxa2xx-cpufreq")
I hope I don't rewrite clk-next history... I need some sort of
magic git pre-commit hook that rewrites fixes tags if the hash
changes.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()
From: Lukasz Majewski @ 2016-11-08 22:25 UTC (permalink / raw)
To: Thierry Reding, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen
Cc: linux-pwm, linux-kernel, Fabio Estevam, Fabio Estevam,
linux-fbdev, Liu Ying
In-Reply-To: <1477985147-18835-1-git-send-email-l.majewski@majess.pl>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
Dear All,
> The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> properties when necessary") has posed some extra restrictions on
> blanking and unblanking frame buffer device.
>
> Unfortunately, pwm_bl driver's probe did not initialize members of
> struct backlight_device necessary for further blank/unblank operation.
>
> This code in case of initial unblank of backlight device (default
> behaviour) sets use_count to 1 and marks this particular backlight
> device as used by all available fb devices (since it is not known
> during probe how much and which fb devices will be assigned).
>
> Without this code, the backlight works properly until one tries to
> blank it manually from sysfs with "echo 1
> > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > were both set to 0, the logic at
> fb_notifier_callback (@backlight.c) thought that we didn't turn on
> (unblanked) the backlight device and refuses to disable (blank) it.
> As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
Best regards,
Łukasz Majewski
>
> Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
> ---
> The patch has been tested on i.MX6q with 4.9-rc3
> SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> ---
> Changes for v2:
> - Update commit message with proper other commit reference
>
> ---
> drivers/video/backlight/pwm_bl.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> platform_device *pdev) struct pwm_bl_data *pb;
> int initial_blank = FB_BLANK_UNBLANK;
> struct pwm_args pargs;
> - int ret;
> + int ret, i;
>
> if (!data) {
> ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> @@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
> platform_device *pdev)
> bl->props.brightness = data->dft_brightness;
> bl->props.power = initial_blank;
> +
> + if (initial_blank == FB_BLANK_UNBLANK) {
> + for (i = 0; i < FB_MAX; i++)
> + bl->fb_bl_on[i] = true;
> +
> + bl->use_count = 1;
> + }
> +
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()
From: Lukasz Majewski @ 2016-11-08 22:25 UTC (permalink / raw)
To: Thierry Reding, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen
Cc: linux-pwm, linux-kernel, Fabio Estevam, Fabio Estevam,
linux-fbdev, Liu Ying
In-Reply-To: <1477985147-18835-1-git-send-email-l.majewski@majess.pl>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
Dear All,
> The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> properties when necessary") has posed some extra restrictions on
> blanking and unblanking frame buffer device.
>
> Unfortunately, pwm_bl driver's probe did not initialize members of
> struct backlight_device necessary for further blank/unblank operation.
>
> This code in case of initial unblank of backlight device (default
> behaviour) sets use_count to 1 and marks this particular backlight
> device as used by all available fb devices (since it is not known
> during probe how much and which fb devices will be assigned).
>
> Without this code, the backlight works properly until one tries to
> blank it manually from sysfs with "echo 1
> > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > were both set to 0, the logic at
> fb_notifier_callback (@backlight.c) thought that we didn't turn on
> (unblanked) the backlight device and refuses to disable (blank) it.
> As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
Best regards,
Łukasz Majewski
>
> Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
> ---
> The patch has been tested on i.MX6q with 4.9-rc3
> SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> ---
> Changes for v2:
> - Update commit message with proper other commit reference
>
> ---
> drivers/video/backlight/pwm_bl.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> platform_device *pdev) struct pwm_bl_data *pb;
> int initial_blank = FB_BLANK_UNBLANK;
> struct pwm_args pargs;
> - int ret;
> + int ret, i;
>
> if (!data) {
> ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> @@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
> platform_device *pdev)
> bl->props.brightness = data->dft_brightness;
> bl->props.power = initial_blank;
> +
> + if (initial_blank == FB_BLANK_UNBLANK) {
> + for (i = 0; i < FB_MAX; i++)
> + bl->fb_bl_on[i] = true;
> +
> + bl->use_count = 1;
> + }
> +
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/4] xfs: basic cow fork speculative preallocation
From: Brian Foster @ 2016-11-08 22:39 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <20161108204800.GA16813@birch.djwong.org>
On Tue, Nov 08, 2016 at 12:48:00PM -0800, Darrick J. Wong wrote:
> On Tue, Nov 08, 2016 at 03:27:32PM -0500, Brian Foster wrote:
> > Hi all,
> >
> > This is an experiment based on an idea for COW fork speculative
> > preallocation. This is experimental, lightly/barely tested and sent in
> > RFC form to solicit thoughts, ideas or flames before I spend time taking
> > it further.
> >
> > Patch 1 probably stands on its own. Patches 2 and 3 are some refactoring
> > and patch 4 implements the basic idea, which is described in the commit
> > log description. The testing I've done so far is basically similar to
> > how one would test the effects of traditional speculative preallocation:
> > write to multiple reflinked files in parallel and examine the resulting
> > fragmentation. Specifically, I wrote sequentially to 16 different
> > reflinked files of the same 8GB original (which has two data extents,
> > completely shared). Without preallocation, the test results in ~248
> > extents across the 16 files. With preallocation, the test results in 32
> > extents across the 16 files (i.e., 2 extents per file, same as the
> > source file).
> >
> > An obvious tradeoff is the unnecessarily aggressive allocation that
> > might occur in the event of random writes to a large file (such as in
> > the cloned VM disk image use case), but my thinking is that the
> > cowblocks tagging and reclaim infrastructure should manage that
> > sufficiently (lack of testing notwithstanding). In any event, I'm
> > interested in any thoughts along the lines of whether this is useful at
> > all, alternative algorithm ideas, etc.
>
> Was about to step out to lunch when this came in, but...
>
> Is there an xfstest for this, so I can play too? :)
>
Not yet.. I've only xfstests tested insofar as it hasn't blown anything
up yet. :) Otherwise, I've just run manual write tests to observe
whether it is doing what I expect it to in simple cases. It clearly
needs more work, as noted in the patch, but if this is something worth
pursuing further I can certainly come up with some tests as well.
FWIW, that COW fork fiemap hack I sent a bit ago came in handy for
playing with this as well. :)
> As far as random writes go, some of the reflink tests look at fragmentation
> behavior. generic/301 generic/302 xfs/180 xfs/182 xfs/184 xfs/192 xfs/193
> xfs/198 xfs/200 xfs/204 xfs/208 xfs/208 xfs/211 xfs/215 xfs/218 xfs/219 xfs/221
> xfs/223 xfs/224 xfs/225 xfs/226 xfs/228 xfs/230 xfs/231 xfs/232 xfs/344 xfs/345
> xfs/346 xfs/347 are the ones that grep 'new extents:' picked up.
>
Ok.
> Will look at the patches when I get back.
>
Thanks!
Brian
> --D
>
> >
> > Brian
> >
> > Brian Foster (4):
> > xfs: clean up cow fork reservation and tag inodes correctly
> > xfs: logically separate iomap range from allocation range
> > xfs: reuse xfs_file_iomap_begin_delay() for cow fork delalloc
> > xfs: implement basic COW fork speculative preallocation
> >
> > fs/xfs/xfs_iomap.c | 132 +++++++++++++++++++++++++++++++++++++++++----------
> > fs/xfs/xfs_reflink.c | 28 ++---------
> > 2 files changed, 111 insertions(+), 49 deletions(-)
> >
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Saint Germain @ 2016-11-08 22:36 UTC (permalink / raw)
To: linux-btrfs; +Cc: James Pharaoh
In-Reply-To: <2855552b-714c-d1de-08f9-89153c293772@wellbehavedsoftware.com>
On Sun, 6 Nov 2016 14:30:52 +0100, James Pharaoh
<james@wellbehavedsoftware.com> wrote :
> Hi all,
>
> I'm pleased to announce my btrfs deduplication utility, written in
> Rust. This operates on whole files, is fast, and I believe
> complements the existing utilities (duperemove, bedup), which exist
> currently.
>
> Please visit the homepage for more information:
>
> http://btrfs-dedupe.com
>
Thanks for having shared your work.
Please be aware of these other similar softwares:
- jdupes: https://github.com/jbruchon/jdupes
- rmlint: https://github.com/sahib/rmlint
And of course fdupes.
Some intesting points I have seen in them:
- use xxhash to identify potential duplicates (huge speedup)
- ability to deduplicate read-only snapshots
- identify potential reflinked files (see also my email here:
https://www.spinics.net/lists/linux-btrfs/msg60081.html)
- ability to filter out hardlinks
- triangle problem: see jdupes readme
- jdupes has started the process to be included in Debian
I hope that will help and that you can share some codes with them !
^ permalink raw reply
* + ipc-fixed-warnings.patch added to -mm tree
From: akpm @ 2016-11-08 22:36 UTC (permalink / raw)
To: p.shailesh, mm-commits
The patch titled
Subject: ipc/shm.c: coding style fixes
has been added to the -mm tree. Its filename is
ipc-fixed-warnings.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/ipc-fixed-warnings.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/ipc-fixed-warnings.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Shailesh Pandey <p.shailesh@samsung.com>
Subject: ipc/shm.c: coding style fixes
This patch fixes below warnings
WARNING: Missing a blank line after declarations
WARNING: Block comments use a trailing */ on a separate line
ERROR: spaces required around that '=' (ctx:WxV)
Above warnings were reported by checkpatch.pl
Link: http://lkml.kernel.org/r/1478604980-18062-1-git-send-email-p.shailesh@samsung.com
Signed-off-by: Shailesh Pandey <p.shailesh@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
ipc/shm.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff -puN ipc/shm.c~ipc-fixed-warnings ipc/shm.c
--- a/ipc/shm.c~ipc-fixed-warnings
+++ a/ipc/shm.c
@@ -89,6 +89,7 @@ void shm_init_ns(struct ipc_namespace *n
static void do_shm_rmid(struct ipc_namespace *ns, struct kern_ipc_perm *ipcp)
{
struct shmid_kernel *shp;
+
shp = container_of(ipcp, struct shmid_kernel, shm_perm);
if (shp->shm_nattch) {
@@ -387,6 +388,7 @@ static int shm_set_policy(struct vm_area
struct file *file = vma->vm_file;
struct shm_file_data *sfd = shm_file_data(file);
int err = 0;
+
if (sfd->vm_ops->set_policy)
err = sfd->vm_ops->set_policy(vma, new);
return err;
@@ -417,7 +419,7 @@ static int shm_mmap(struct file *file, s
* In case of remap_file_pages() emulation, the file can represent
* removed IPC ID: propogate shm_lock() error to caller.
*/
- ret =__shm_open(vma);
+ ret = __shm_open(vma);
if (ret)
return ret;
@@ -468,6 +470,7 @@ static unsigned long shm_get_unmapped_ar
unsigned long flags)
{
struct shm_file_data *sfd = shm_file_data(file);
+
return sfd->file->f_op->get_unmapped_area(sfd->file, addr, len,
pgoff, flags);
}
@@ -766,6 +769,7 @@ static void shm_add_rss_swap(struct shmi
} else {
#ifdef CONFIG_SHMEM
struct shmem_inode_info *info = SHMEM_I(inode);
+
spin_lock_irq(&info->lock);
*rss_add += inode->i_mapping->nrpages;
*swp_add += info->swapped;
@@ -1028,6 +1032,7 @@ SYSCALL_DEFINE3(shmctl, int, shmid, int,
if (!ns_capable(ns->user_ns, CAP_IPC_LOCK)) {
kuid_t euid = current_euid();
+
if (!uid_eq(euid, shp->shm_perm.uid) &&
!uid_eq(euid, shp->shm_perm.cuid)) {
err = -EPERM;
@@ -1045,6 +1050,7 @@ SYSCALL_DEFINE3(shmctl, int, shmid, int,
if (cmd == SHM_LOCK) {
struct user_struct *user = current_user();
+
err = shmem_lock(shm_file, 1, user);
if (!err && !(shp->shm_perm.mode & SHM_LOCKED)) {
shp->shm_perm.mode |= SHM_LOCKED;
@@ -1354,9 +1360,10 @@ SYSCALL_DEFINE1(shmdt, char __user *, sh
vma = next;
}
-#else /* CONFIG_MMU */
+#else /* CONFIG_MMU */
/* under NOMMU conditions, the exact address to be destroyed must be
- * given */
+ * given
+ */
if (vma && vma->vm_start == addr && vma->vm_ops == &shm_vm_ops) {
do_munmap(mm, vma->vm_start, vma->vm_end - vma->vm_start);
retval = 0;
_
Patches currently in -mm which might be from p.shailesh@samsung.com are
ipc-fixed-warnings.patch
^ permalink raw reply
* Re: [PATCH v4 3/9] selinux lsm IB/core: Implement LSM notification system
From: kbuild test robot @ 2016-11-08 22:35 UTC (permalink / raw)
To: Dan Jurgens
Cc: kbuild-all, chrisw, paul, sds, eparis, dledford, sean.hefty,
hal.rosenstock, selinux, linux-security-module, linux-rdma,
yevgenyp, liranl, leonro, Daniel Jurgens
In-Reply-To: <1478639185-47521-4-git-send-email-danielj@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
Hi Daniel,
[auto build test ERROR on rdma/master]
[also build test ERROR on v4.9-rc4]
[cannot apply to next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: i386-randconfig-s1-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "unregister_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
>> ERROR: "register_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/9] selinux lsm IB/core: Implement LSM notification system
From: kbuild test robot @ 2016-11-08 22:35 UTC (permalink / raw)
Cc: kbuild-all, chrisw, paul, sds, eparis, dledford, sean.hefty,
hal.rosenstock, selinux, linux-security-module, linux-rdma,
yevgenyp, liranl, leonro, Daniel Jurgens
In-Reply-To: <1478639185-47521-4-git-send-email-danielj@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
Hi Daniel,
[auto build test ERROR on rdma/master]
[also build test ERROR on v4.9-rc4]
[cannot apply to next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: i386-randconfig-s1-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "unregister_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
>> ERROR: "register_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] ath10k: Add support to enable or disable btcoex via nl80211
From: kbuild test robot @ 2016-11-08 22:34 UTC (permalink / raw)
To: c_traja; +Cc: kbuild-all, ath10k, linux-wireless, tamizhchelvam, Tamizh chelvam
In-Reply-To: <1478617354-28146-2-git-send-email-c_traja@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]
Hi Tamizh,
[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.9-rc4 next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add-support-for-BTCOEX-feature/20161109-043718
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/net/wireless/ath/ath10k/mac.c:7548:2: error: unknown field 'set_btcoex' specified in initializer
.set_btcoex = ath10k_mac_op_set_btcoex,
^
>> drivers/net/wireless/ath/ath10k/mac.c:7548:36: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.set_btcoex = ath10k_mac_op_set_btcoex,
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/mac.c:7548:36: note: (near initialization for 'ath10k_ops.reconfig_complete')
cc1: some warnings being treated as errors
vim +/set_btcoex +7548 drivers/net/wireless/ath/ath10k/mac.c
7542 .add_chanctx = ath10k_mac_op_add_chanctx,
7543 .remove_chanctx = ath10k_mac_op_remove_chanctx,
7544 .change_chanctx = ath10k_mac_op_change_chanctx,
7545 .assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
7546 .unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
7547 .switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
> 7548 .set_btcoex = ath10k_mac_op_set_btcoex,
7549
7550 CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
7551
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55638 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] ath10k: Add support to enable or disable btcoex via nl80211
From: kbuild test robot @ 2016-11-08 22:34 UTC (permalink / raw)
To: c_traja; +Cc: tamizhchelvam, linux-wireless, kbuild-all, ath10k
In-Reply-To: <1478617354-28146-2-git-send-email-c_traja@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]
Hi Tamizh,
[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.9-rc4 next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add-support-for-BTCOEX-feature/20161109-043718
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/net/wireless/ath/ath10k/mac.c:7548:2: error: unknown field 'set_btcoex' specified in initializer
.set_btcoex = ath10k_mac_op_set_btcoex,
^
>> drivers/net/wireless/ath/ath10k/mac.c:7548:36: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.set_btcoex = ath10k_mac_op_set_btcoex,
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/mac.c:7548:36: note: (near initialization for 'ath10k_ops.reconfig_complete')
cc1: some warnings being treated as errors
vim +/set_btcoex +7548 drivers/net/wireless/ath/ath10k/mac.c
7542 .add_chanctx = ath10k_mac_op_add_chanctx,
7543 .remove_chanctx = ath10k_mac_op_remove_chanctx,
7544 .change_chanctx = ath10k_mac_op_change_chanctx,
7545 .assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
7546 .unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
7547 .switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
> 7548 .set_btcoex = ath10k_mac_op_set_btcoex,
7549
7550 CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
7551
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55638 bytes --]
[-- Attachment #3: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-08 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108164948.GG20591@arm.com>
On Tuesday, November 8, 2016 4:49:49 PM CET Will Deacon wrote:
> On Tue, Nov 08, 2016 at 04:33:44PM +0000, John Garry wrote:
> > On 08/11/2016 16:12, Will Deacon wrote:
> > >On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > >Is there no way to make this slightly more generic, so that it can be
> > >re-used elsewhere? For example, if struct extio_ops was common, then
> > >you could have the singleton (which maybe should be an interval tree?),
> > >type definition, setter function and the BUILD_EXTIO invocations
> > >somewhere generic, rather than squirelled away in the arch backend.
> > >
> > The concern would be that some architecture which uses generic higher-level
> > ISA accessor ops, but have IO space, could be affected.
>
> You're already adding a Kconfig symbol for this stuff, so you can keep
> that if you don't want it on other architectures. I'm just arguing that
> plumbing drivers directly into arch code via arm64_set_extops is not
> something I'm particularly fond of, especially when it looks like it
> could be avoided with a small amount of effort.
Agreed, I initially suggested putting this into arch/arm64/, but there isn't
really a reason why it couldn't just live in lib/ with the header file
bits moved to include/asm-generic/io.h which we already use.
Arnd
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-08 22:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, John Garry, mark.rutland, catalin.marinas,
gabriele.paoloni, linux-pci, liviu.dudau, linuxarm,
lorenzo.pieralisi, minyard, xuwei5, linux-serial, benh,
devicetree, zhichang.yuan02, olof, robh+dt, bhelgaas, kantyzc,
linux-kernel, zhichang.yuan, zourongrong
In-Reply-To: <20161108164948.GG20591@arm.com>
On Tuesday, November 8, 2016 4:49:49 PM CET Will Deacon wrote:
> On Tue, Nov 08, 2016 at 04:33:44PM +0000, John Garry wrote:
> > On 08/11/2016 16:12, Will Deacon wrote:
> > >On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > >Is there no way to make this slightly more generic, so that it can be
> > >re-used elsewhere? For example, if struct extio_ops was common, then
> > >you could have the singleton (which maybe should be an interval tree?),
> > >type definition, setter function and the BUILD_EXTIO invocations
> > >somewhere generic, rather than squirelled away in the arch backend.
> > >
> > The concern would be that some architecture which uses generic higher-level
> > ISA accessor ops, but have IO space, could be affected.
>
> You're already adding a Kconfig symbol for this stuff, so you can keep
> that if you don't want it on other architectures. I'm just arguing that
> plumbing drivers directly into arch code via arm64_set_extops is not
> something I'm particularly fond of, especially when it looks like it
> could be avoided with a small amount of effort.
Agreed, I initially suggested putting this into arch/arm64/, but there isn't
really a reason why it couldn't just live in lib/ with the header file
bits moved to include/asm-generic/io.h which we already use.
Arnd
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-08 22:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, gabriele.paoloni, benh, Will Deacon, linuxarm,
lorenzo.pieralisi, xuwei5, linux-serial, catalin.marinas,
devicetree, minyard, liviu.dudau, John Garry, olof, robh+dt,
bhelgaas, kantyzc, zhichang.yuan02, linux-pci, linux-kernel,
zhichang.yuan, zourongrong
In-Reply-To: <20161108164948.GG20591@arm.com>
On Tuesday, November 8, 2016 4:49:49 PM CET Will Deacon wrote:
> On Tue, Nov 08, 2016 at 04:33:44PM +0000, John Garry wrote:
> > On 08/11/2016 16:12, Will Deacon wrote:
> > >On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > >Is there no way to make this slightly more generic, so that it can be
> > >re-used elsewhere? For example, if struct extio_ops was common, then
> > >you could have the singleton (which maybe should be an interval tree?),
> > >type definition, setter function and the BUILD_EXTIO invocations
> > >somewhere generic, rather than squirelled away in the arch backend.
> > >
> > The concern would be that some architecture which uses generic higher-level
> > ISA accessor ops, but have IO space, could be affected.
>
> You're already adding a Kconfig symbol for this stuff, so you can keep
> that if you don't want it on other architectures. I'm just arguing that
> plumbing drivers directly into arch code via arm64_set_extops is not
> something I'm particularly fond of, especially when it looks like it
> could be avoided with a small amount of effort.
Agreed, I initially suggested putting this into arch/arm64/, but there isn't
really a reason why it couldn't just live in lib/ with the header file
bits moved to include/asm-generic/io.h which we already use.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD
From: Stefan Wahren @ 2016-11-08 22:34 UTC (permalink / raw)
To: Ksenija Stanojevic, lee.jones
Cc: linux-input, pmeerw, jic23, knaack.h, lars, dmitry.torokhov,
harald, fabio.estevam, linux-iio, marex, linux-kernel
In-Reply-To: <c18883dfacaaf40ab98cbb4938d5164a95a817d7.1478071676.git.ksenija.stanojevic@gmail.com>
> Ksenija Stanojevic <ksenija.stanojevic@gmail.com> hat am 2. November 2016 um
> 08:38 geschrieben:
>
>
> Add core files for low resolution analog-to-digital converter (mxs-lradc)
> MFD driver.
>
> Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
for Patch 1 + 2
> ---
> ...
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e66..057ca15 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -211,3 +211,4 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
Btw this part won't apply anymore
^ permalink raw reply
* Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks
From: 'Stephen Boyd' @ 2016-11-08 22:33 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Sricharan, mturquette, linux-clk, linux-arm-msm, linux-kernel,
stanimir.varbanov
In-Reply-To: <58201597.6010207@codeaurora.org>
On 11/07, Rajendra Nayak wrote:
>
>
> On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote:
> > Well I'm also curious which case is failing. Does turning on the
> > clocks work after the gdsc is enabled? Does turning off the
> > clocks fail because we don't know when the gdsc has turned off? I
> > would hope that the firmware keeps the gdsc on when it's done
> > processing things, goes idle, and hands back control to software.
> > Right now I'm failing to see how the halt bits fail to toggle
> > assuming that firmware isn't misbehaving and the kernel driver is
> > power controlling in a coordinated manner with the firmware.
>
> What fails is turning ON the clocks after the gdsc is put under
> hardware control (by fails I mean the halt checks fail to indicate
> the clock is running, but register accesses etc thereafter suggest
> the clocks are actually running)
> The halt checks seem to work only while the gdsc is put in SW enabled
> state.
>
Um... that is bad. I don't see how that is possible. It sounds
like the clocks are not turning on when we're asking for them to
turn on. The register accesses are always working because these
subcore clks aren't required for register accesses. Most likely
the GDSC for the subdomains is off (even after we thought we
enabled it).
Let's take a step back. The video hardware has three GDSCs. One
for the main logic, and two for each subdomain. We're adding hw
control for the two subdomains here. From what I can tell there
isn't any hw control for the main domain. I see that there are
two registers in the video hardware to control those subdomain hw
enable signals that go to the GDSC. The reset value is OFF (not
ON like was stated earlier), so it seems that if we switch the
subdomain GDSCs on in these patches it will turn on for a short
time, and then turn off when we switch into hw mode (by virtue of
the way we enable the GDSC). Presumably we can assert these hw
signal bits regardless of the subdomain power states, because
otherwise we're in a chicken-egg situation for the firmware
controlling this stuff.
The proper sequence sounds like it should be:
1. Enable GDSC for main domain
2. Enable clocks for main domain (video_{core,maxi,ahb,axi}_clk)
3. Write the two registers to assert hw signal for subdomains
4. Enable GDSCs for two subdomains
5. Enable clocks for subdomains (video_subcore{0,1}_clk)
I can only guess that we're not doing this. Probably the sequence
right now is:
1. Enable GDSC for main domain and both sub-domains
2. Enable clocks for main domain (video_{core,maxi,ahb,axi}_clk)
3. Enable clocks for subdomains (video_subcore{0,1}_clk)
<clk stuff OFF because hw signal is still deasserted>
Sound right? If so, please fix the sequence in the video driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* + lib-stackdepot-export-save-fetch-stack-for-drivers.patch added to -mm tree
From: akpm @ 2016-11-08 22:33 UTC (permalink / raw)
To: chris, aryabinin, daniel.vetter, dvyukov, glider, iamjoonsoo.kim,
kirill, mm-commits
The patch titled
Subject: lib/stackdepot: export save/fetch stack for drivers
has been added to the -mm tree. Its filename is
lib-stackdepot-export-save-fetch-stack-for-drivers.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/lib-stackdepot-export-save-fetch-stack-for-drivers.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/lib-stackdepot-export-save-fetch-stack-for-drivers.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: lib/stackdepot: export save/fetch stack for drivers
Some drivers would like to record stacktraces in order to aide leak
tracing. As stackdepot already provides a facility for only storing the
unique traces, thereby reducing the memory required, export that
functionality for use by drivers.
The code was originally created for KASAN and moved under lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot
for SLAB") so that it could be shared with mm/. In turn, we want to share
it now with drivers.
Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/stackdepot.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers lib/stackdepot.c
--- a/lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers
+++ a/lib/stackdepot.c
@@ -192,6 +192,7 @@ void depot_fetch_stack(depot_stack_handl
trace->entries = stack->entries;
trace->skip = 0;
}
+EXPORT_SYMBOL_GPL(depot_fetch_stack);
/**
* depot_save_stack - save stack in a stack depot.
@@ -283,3 +284,4 @@ exit:
fast_exit:
return retval;
}
+EXPORT_SYMBOL_GPL(depot_save_stack);
_
Patches currently in -mm which might be from chris@chris-wilson.co.uk are
lib-stackdepot-export-save-fetch-stack-for-drivers.patch
^ permalink raw reply
* Re: [PATCH 03/30] usb: dwc2: gadget: Add descriptor DMA binding
From: John Youn @ 2016-11-08 22:32 UTC (permalink / raw)
To: Felipe Balbi, John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Vahram Aharonyan
In-Reply-To: <87r36mib8z.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/8/2016 1:15 AM, Felipe Balbi wrote:
> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>
>> From: Vahram Aharonyan <vahrama-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>
>> Add the devicetree binding to enable descriptor DMA and read it in to
>> the corresponding parameter during probe.
>>
>> Signed-off-by: Vahram Aharonyan <vahrama-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>> drivers/usb/dwc2/core.h | 4 ++++
>> drivers/usb/dwc2/gadget.c | 11 +++++++++++
>> drivers/usb/dwc2/params.c | 4 ++++
>> 4 files changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>> index 389a461..1db9c37 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>> @@ -27,6 +27,7 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>> Refer to usb/generic.txt
>> - snps,host-dma-disable: disable host DMA mode.
>> - snps,gadget-dma-enable: enable gadget DMA mode.
>> +- snps,gadget-dma-desc-enable: enable gadget DMA descriptor mode.
>
> seems to be discoverable as well:
>
> #define GHWCFG4_DESC_DMA_DYN (1 << 31)
> #define GHWCFG4_DESC_DMA (1 << 30)
>
> care to comment?
>
This is just following patch 1/30 for consistency.
We can make it discoverable and set automatically as well.
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/7] genirq/affinity: Introduce struct irq_affinity
From: Christoph Hellwig @ 2016-11-08 22:30 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Christoph Hellwig, tglx, axboe, linux-block, linux-pci,
linux-kernel
In-Reply-To: <20161108212526.GF14322@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Nov 08, 2016 at 03:25:27PM -0600, Bjorn Helgaas wrote:
> What tree would you prefer? I vote for the IRQ tree since that seems
> to be where the interesting parts are, and I think I acked all the PCI
> bits.
Yes, that would be my preference to.
>
> > + * struct irq_affinity - Description for auto irq affinity assignements
> > + * @pre_vectors: Reserved vectors at the beginning of the MSIX
> > + * vector space
> > + * @post_vectors: Reserved vectors at the end of the MSIX
> > + * vector space
>
> Maybe include something more informative than just "reserved", e.g.,
> "Don't apply affinity to @pre_vectors at beginning of MSI-X vector
> space" or "Vectors at beginning of MSI-X vector space that are exempt
> from affinity"?
Sure.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.