* [PATCH 4.8 094/138] mac80211: discard multicast and 4-addr A-MSDUs
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.
In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
* drop A-MSDUs with a multicast A1 (RA), as required by the
spec in 9.11 (802.11-2012 version)
* drop A-MSDUs with a 4-addr header, since the fourth address
can't actually be useful for them; unless 4-address frame
format is actually requested, even though the fourth address
is still not useful in this case, but ignored
Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/rx.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2253,16 +2253,22 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx
if (!(status->rx_flags & IEEE80211_RX_AMSDU))
return RX_CONTINUE;
- if (ieee80211_has_a4(hdr->frame_control) &&
- rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- !rx->sdata->u.vlan.sta)
- return RX_DROP_UNUSABLE;
+ if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+ switch (rx->sdata->vif.type) {
+ case NL80211_IFTYPE_AP_VLAN:
+ if (!rx->sdata->u.vlan.sta)
+ return RX_DROP_UNUSABLE;
+ break;
+ case NL80211_IFTYPE_STATION:
+ if (!rx->sdata->u.mgd.use_4addr)
+ return RX_DROP_UNUSABLE;
+ break;
+ default:
+ return RX_DROP_UNUSABLE;
+ }
+ }
- if (is_multicast_ether_addr(hdr->addr1) &&
- ((rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- rx->sdata->u.vlan.sta) ||
- (rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- rx->sdata->u.mgd.use_4addr)))
+ if (is_multicast_ether_addr(hdr->addr1))
return RX_DROP_UNUSABLE;
skb->dev = dev;
^ permalink raw reply
* [PATCH 4.8 102/138] md: be careful not lot leak internal curr_resync value into metadata. -- (all)
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Viswesh, NeilBrown, Shaohua Li
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <neilb@suse.com>
commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 upstream.
mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.
1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to
start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.
3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.
It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint. In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.
There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.
Change them to only propagate the value if it is > 3.
As this can cause an array to fail, the patch is suitable for -stable.
Reported-by: Viswesh <viswesh.vichu@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/md.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8120,14 +8120,14 @@ void md_do_sync(struct md_thread *thread
if (!test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) &&
!test_bit(MD_RECOVERY_INTR, &mddev->recovery) &&
- mddev->curr_resync > 2) {
+ mddev->curr_resync > 3) {
mddev->curr_resync_completed = mddev->curr_resync;
sysfs_notify(&mddev->kobj, NULL, "sync_completed");
}
mddev->pers->sync_request(mddev, max_sectors, &skipped);
if (!test_bit(MD_RECOVERY_CHECK, &mddev->recovery) &&
- mddev->curr_resync > 2) {
+ mddev->curr_resync > 3) {
if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) {
if (test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
if (mddev->curr_resync >= mddev->recovery_cp) {
^ permalink raw reply
* [PATCH 4.8 099/138] mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jaehoon Chung, Shawn Lin, Ulf Hansson
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jaehoon Chung <jh80.chung@samsung.com>
commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream.
platform_get_resource can be returned the NULL pointer.
Then regs->start should be referred to NULL Pointer.
devm_ioremap_resource() checks whether res is NULL or not.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc-pltfm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -46,12 +46,13 @@ int dw_mci_pltfm_register(struct platfor
host->pdata = pdev->dev.platform_data;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- /* Get registers' physical base address */
- host->phy_regs = regs->start;
host->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);
+ /* Get registers' physical base address */
+ host->phy_regs = regs->start;
+
platform_set_drvdata(pdev, host);
return dw_mci_probe(host);
}
^ permalink raw reply
* [Bug 98656] [NVE6] Nouveau hangs after opening Chromium on GNOME 3
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2016-11-09 11:14 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-98656-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
[-- Attachment #1.1: Type: text/plain, Size: 490 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98656
pgkos <pgkos.bugzilla-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #127865|application/x-octet-stream |text/plain
mime type| |
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1163 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH 4.8 131/138] [media] v4l: vsp1: Prevent pipelines from running when not streaming
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kieran Bingham, Laurent Pinchart,
Mauro Carvalho Chehab
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
commit e4e70a147a48618a36ae1b81c641516cb9d45993 upstream.
Pipelines can only be run if all their video nodes are streaming. Commit
b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first
STREAMOFF") fixed the pipeline stop sequence, but introduced a race
condition that makes it possible to run a pipeline after stopping the
stream on a video node by queuing a buffer on the other side of the
pipeline.
Fix this by clearing the buffers ready flag when stopping the stream,
which will prevent the QBUF handler from running the pipeline.
Fixes: b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF")
Reported-by: Kieran Bingham <kieran@bingham.xyz>
Tested-by: Kieran Bingham <kieran@bingham.xyz>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/vsp1/vsp1_video.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -675,6 +675,13 @@ static void vsp1_video_stop_streaming(st
unsigned long flags;
int ret;
+ /* Clear the buffers ready flag to make sure the device won't be started
+ * by a QBUF on the video node on the other side of the pipeline.
+ */
+ spin_lock_irqsave(&video->irqlock, flags);
+ pipe->buffers_ready &= ~(1 << video->pipe_index);
+ spin_unlock_irqrestore(&video->irqlock, flags);
+
mutex_lock(&pipe->lock);
if (--pipe->stream_count == pipe->num_inputs) {
/* Stop the pipeline. */
^ permalink raw reply
* Re: xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0
From: Daniel Vetter @ 2016-11-09 11:14 UTC (permalink / raw)
To: Greg KH; +Cc: intel-gfx, stable, Gaston Gonzalez, linux-kernel
In-Reply-To: <20161029134724.GA3972@kroah.com>
On Sat, Oct 29, 2016 at 09:47:24AM -0400, Greg KH wrote:
> On Sat, Oct 29, 2016 at 10:13:25AM -0300, Gaston Gonzalez wrote:
> > On Fri, Oct 28, 2016 at 07:23:24PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote:
> > > > On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote:
> > > > > On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> > > > > > On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > After hibernation I get the following error when I tried to connect to monitor
> > > > > > > through hdmi:
> > > > > > >
> > > > > > > $ xrandr --output LVDS1 --off --output HDMI1 --auto
> > > > > > > xrandr: Configure crtc 1 failed
> > > > > > >
> > > > > > > This does not happen in kernel in kernel v4.6.7 but do happen in kernels v4.7.4
> > > > > > > and v4.8.0
> > > > > >
> > > > > > Ah, can you use 'git bisect' to track down the offending patch?
> > > > > >
> > > > > > Also, if you let the graphics driver authors know, they are probably the
> > > > > > best ones to help out with this, not the "generic" stable mailing list.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > Hello,
> > > > >
> > > > > The culprit commit seems to be:
> > > > >
> > > > > commit: ed4a6a7
> > > > > drm/i915: Add two-stage ILK-style watermark programming
> > > > >
> > > > > Attached the bisection log.
> > > > >
> > > > > Let me know if additional test or bisect is needed.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Gaston
> > > >
> > > > > git bisect start '--' 'drivers/gpu/drm/'
> > > > > # good: [096998b11906dd79df5af4d688c9974342dd09f2] Linux 4.6.7
> > > > > git bisect good 096998b11906dd79df5af4d688c9974342dd09f2
> > > > > # bad: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
> > > > > git bisect bad c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
> > > > > # good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
> > > > > git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
> > > > > # bad: [3c85f20a289d044f303f473ee6ab7502303fc3b0] Merge tag 'omapdrm-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
> > > > > git bisect bad 3c85f20a289d044f303f473ee6ab7502303fc3b0
> > > > > # bad: [a64424d722504926f3375bc4887976e3bfe3a01d] Merge branch 'drm-next-4.7' of git://people.freedesktop.org/~agd5f/linux into drm-next
> > > > > git bisect bad a64424d722504926f3375bc4887976e3bfe3a01d
> > > > > # bad: [b5bf0f1ea3658254bd72ef64abc97786e8a32255] drm/exynos: clean up register definions for fimd and decon
> > > > > git bisect bad b5bf0f1ea3658254bd72ef64abc97786e8a32255
> > > > > # bad: [27878ede4fec7b929c3010710ba4d55c617c621d] drm/i915: Throw out BUGs from DPLL/PCH functions
> > > > > git bisect bad 27878ede4fec7b929c3010710ba4d55c617c621d
> > > > > # bad: [72341af4285ae1337c0dfdfa3e68318b52b8757c] drm/i915: hide away VBT private data in a separate header
> > > > > git bisect bad 72341af4285ae1337c0dfdfa3e68318b52b8757c
> > > > > # bad: [71f0a626143368b8aead361ffaff7e36d043fd8e] drm/i915: Only use sanitized values for ILK watermarks
> > > > > git bisect bad 71f0a626143368b8aead361ffaff7e36d043fd8e
> > > > > # bad: [66e2c4c39cc37beaccc24c9d14c75d627fce9cf4] drm/i915/gen9: Disable DC states if power well support is disabled
> > > > > git bisect bad 66e2c4c39cc37beaccc24c9d14c75d627fce9cf4
> > > > > # bad: [4f2d9934bd6ac73950832c96b385822846670668] drm/i915: Pass drm_frambuffer to intel_compute_page_offset()
> > > > > git bisect bad 4f2d9934bd6ac73950832c96b385822846670668
> > > > > # bad: [1d5bf5d9d9ef0c1e639d36178a224d83888c5a29] drm/i915: Add missing NULL check before calling initial_watermarks
> > > > > git bisect bad 1d5bf5d9d9ef0c1e639d36178a224d83888c5a29
> > > > > # bad: [d9f8e52b22454a30aaaf26b7ef029598b30abf8e] drm/i915: remove dead code
> > > > > git bisect bad d9f8e52b22454a30aaaf26b7ef029598b30abf8e
> > > > > # bad: [c3454d575da162cd310d9b83696baefb29d10a70] drm/i915: remove left over dead code
> > > > > git bisect bad c3454d575da162cd310d9b83696baefb29d10a70
> > > > > # bad: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage ILK-style watermark programming (v11)
> > > > > git bisect bad ed4a6a7ca853253f9b86f3005d76345482a71283
> > > > > # first bad commit: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage ILK-style watermark programming (v11)
> > > >
> > > >
> > > > Nothing from the graphics developers? Come on, here is someone who
> > > > found a specific patch that causes a problem, and no one responds?
> > >
> > > Probably no one noticed the mail on account of the relevant lists
> > > not getting Cc:d from the get go. Sorry.
> > >
> > > >
> > > > Why isn't this fixed by reverting the above mentioned patch in Linus's
> > > > tree already? Or, is there something else that needs to be done?
> > >
> > > IIRC the problems caused by that watermark stuff should have been fixed by
> > > some combination of these
> > > 9bd18728a3f2 ("drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)")
> > > 7045c3689f14 ("drm/i915: Don't leave old junk in ilk active watermarks on readout")
> > > d890565c4444 ("drm/i915: Use the active wm config for merging on ILK-BDW")
> > > f1ecaf8f9c99 ("drm/i915: Start WM computation from scratch on ILK-BDW")
> > >
> > > so it's not quite clear if the bisect landed at the right spot, or if we
> > > have more than one overlapping regression around.
> > >
> > > Please file a bug at
> > > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> > > and attach the full dmesg from boot up to when you reproduced the
> > > problem. And pass drm.debug=0xe to kernel so that we'll get (hopefully)
> > > enough debug information into the log.
> > >
> > > Trying the latest nightly tree from
> > > git://anongit.freedesktop.org/drm-intel drm-intel-nightly
> > > would also be a good idea, in case we already fixed the problem.
> > >
> > > --
> > > Ville Syrjälä
> > > Intel OTC
> >
> > Hi,
> >
> > Now I'm running a 4.8.4 kernel and the problem seems to be solved. So no
> > need to file a bug report, right?
>
> Ah, that's great, no need!
Yeah, 4.8 had a bunch of wm fallout because we're reworking that code and
the freeze for the 4.8 merge window seemed to have hit a bad time.
Bugfixes are slowly percolating through the system. I think the regression
from Ted also has a big chance to be a similar issue.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0
From: Daniel Vetter @ 2016-11-09 11:14 UTC (permalink / raw)
To: Greg KH; +Cc: Gaston Gonzalez, stable, intel-gfx, linux-kernel
In-Reply-To: <20161029134724.GA3972@kroah.com>
On Sat, Oct 29, 2016 at 09:47:24AM -0400, Greg KH wrote:
> On Sat, Oct 29, 2016 at 10:13:25AM -0300, Gaston Gonzalez wrote:
> > On Fri, Oct 28, 2016 at 07:23:24PM +0300, Ville Syrj�l� wrote:
> > > On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote:
> > > > On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote:
> > > > > On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> > > > > > On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > After hibernation I get the following error when I tried to connect to monitor
> > > > > > > through hdmi:
> > > > > > >
> > > > > > > $ xrandr --output LVDS1 --off --output HDMI1 --auto
> > > > > > > xrandr: Configure crtc 1 failed
> > > > > > >
> > > > > > > This does not happen in kernel in kernel v4.6.7 but do happen in kernels v4.7.4
> > > > > > > and v4.8.0
> > > > > >
> > > > > > Ah, can you use 'git bisect' to track down the offending patch?
> > > > > >
> > > > > > Also, if you let the graphics driver authors know, they are probably the
> > > > > > best ones to help out with this, not the "generic" stable mailing list.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > Hello,
> > > > >
> > > > > The culprit commit seems to be:
> > > > >
> > > > > commit: ed4a6a7
> > > > > drm/i915: Add two-stage ILK-style watermark programming
> > > > >
> > > > > Attached the bisection log.
> > > > >
> > > > > Let me know if additional test or bisect is needed.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Gaston
> > > >
> > > > > git bisect start '--' 'drivers/gpu/drm/'
> > > > > # good: [096998b11906dd79df5af4d688c9974342dd09f2] Linux 4.6.7
> > > > > git bisect good 096998b11906dd79df5af4d688c9974342dd09f2
> > > > > # bad: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
> > > > > git bisect bad c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
> > > > > # good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
> > > > > git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
> > > > > # bad: [3c85f20a289d044f303f473ee6ab7502303fc3b0] Merge tag 'omapdrm-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
> > > > > git bisect bad 3c85f20a289d044f303f473ee6ab7502303fc3b0
> > > > > # bad: [a64424d722504926f3375bc4887976e3bfe3a01d] Merge branch 'drm-next-4.7' of git://people.freedesktop.org/~agd5f/linux into drm-next
> > > > > git bisect bad a64424d722504926f3375bc4887976e3bfe3a01d
> > > > > # bad: [b5bf0f1ea3658254bd72ef64abc97786e8a32255] drm/exynos: clean up register definions for fimd and decon
> > > > > git bisect bad b5bf0f1ea3658254bd72ef64abc97786e8a32255
> > > > > # bad: [27878ede4fec7b929c3010710ba4d55c617c621d] drm/i915: Throw out BUGs from DPLL/PCH functions
> > > > > git bisect bad 27878ede4fec7b929c3010710ba4d55c617c621d
> > > > > # bad: [72341af4285ae1337c0dfdfa3e68318b52b8757c] drm/i915: hide away VBT private data in a separate header
> > > > > git bisect bad 72341af4285ae1337c0dfdfa3e68318b52b8757c
> > > > > # bad: [71f0a626143368b8aead361ffaff7e36d043fd8e] drm/i915: Only use sanitized values for ILK watermarks
> > > > > git bisect bad 71f0a626143368b8aead361ffaff7e36d043fd8e
> > > > > # bad: [66e2c4c39cc37beaccc24c9d14c75d627fce9cf4] drm/i915/gen9: Disable DC states if power well support is disabled
> > > > > git bisect bad 66e2c4c39cc37beaccc24c9d14c75d627fce9cf4
> > > > > # bad: [4f2d9934bd6ac73950832c96b385822846670668] drm/i915: Pass drm_frambuffer to intel_compute_page_offset()
> > > > > git bisect bad 4f2d9934bd6ac73950832c96b385822846670668
> > > > > # bad: [1d5bf5d9d9ef0c1e639d36178a224d83888c5a29] drm/i915: Add missing NULL check before calling initial_watermarks
> > > > > git bisect bad 1d5bf5d9d9ef0c1e639d36178a224d83888c5a29
> > > > > # bad: [d9f8e52b22454a30aaaf26b7ef029598b30abf8e] drm/i915: remove dead code
> > > > > git bisect bad d9f8e52b22454a30aaaf26b7ef029598b30abf8e
> > > > > # bad: [c3454d575da162cd310d9b83696baefb29d10a70] drm/i915: remove left over dead code
> > > > > git bisect bad c3454d575da162cd310d9b83696baefb29d10a70
> > > > > # bad: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage ILK-style watermark programming (v11)
> > > > > git bisect bad ed4a6a7ca853253f9b86f3005d76345482a71283
> > > > > # first bad commit: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage ILK-style watermark programming (v11)
> > > >
> > > >
> > > > Nothing from the graphics developers? Come on, here is someone who
> > > > found a specific patch that causes a problem, and no one responds?
> > >
> > > Probably no one noticed the mail on account of the relevant lists
> > > not getting Cc:d from the get go. Sorry.
> > >
> > > >
> > > > Why isn't this fixed by reverting the above mentioned patch in Linus's
> > > > tree already? Or, is there something else that needs to be done?
> > >
> > > IIRC the problems caused by that watermark stuff should have been fixed by
> > > some combination of these
> > > 9bd18728a3f2 ("drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)")
> > > 7045c3689f14 ("drm/i915: Don't leave old junk in ilk active watermarks on readout")
> > > d890565c4444 ("drm/i915: Use the active wm config for merging on ILK-BDW")
> > > f1ecaf8f9c99 ("drm/i915: Start WM computation from scratch on ILK-BDW")
> > >
> > > so it's not quite clear if the bisect landed at the right spot, or if we
> > > have more than one overlapping regression around.
> > >
> > > Please file a bug at
> > > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> > > and attach the full dmesg from boot up to when you reproduced the
> > > problem. And pass drm.debug=0xe to kernel so that we'll get (hopefully)
> > > enough debug information into the log.
> > >
> > > Trying the latest nightly tree from
> > > git://anongit.freedesktop.org/drm-intel drm-intel-nightly
> > > would also be a good idea, in case we already fixed the problem.
> > >
> > > --
> > > Ville Syrj�l�
> > > Intel OTC
> >
> > Hi,
> >
> > Now I'm running a 4.8.4 kernel and the problem seems to be solved. So no
> > need to file a bug report, right?
>
> Ah, that's great, no need!
Yeah, 4.8 had a bunch of wm fallout because we're reworking that code and
the freeze for the 4.8 merge window seemed to have hit a bad time.
Bugfixes are slowly percolating through the system. I think the regression
from Ted also has a big chance to be a similar issue.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [Intel-gfx] xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0
From: Daniel Vetter @ 2016-11-09 11:14 UTC (permalink / raw)
To: Greg KH; +Cc: Gaston Gonzalez, stable, intel-gfx, linux-kernel
In-Reply-To: <20161029134724.GA3972@kroah.com>
On Sat, Oct 29, 2016 at 09:47:24AM -0400, Greg KH wrote:
> On Sat, Oct 29, 2016 at 10:13:25AM -0300, Gaston Gonzalez wrote:
> > On Fri, Oct 28, 2016 at 07:23:24PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote:
> > > > On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote:
> > > > > On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> > > > > > On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > After hibernation I get the following error when I tried to connect to monitor
> > > > > > > through hdmi:
> > > > > > >
> > > > > > > $ xrandr --output LVDS1 --off --output HDMI1 --auto
> > > > > > > xrandr: Configure crtc 1 failed
> > > > > > >
> > > > > > > This does not happen in kernel in kernel v4.6.7 but do happen in kernels v4.7.4
> > > > > > > and v4.8.0
> > > > > >
> > > > > > Ah, can you use 'git bisect' to track down the offending patch?
> > > > > >
> > > > > > Also, if you let the graphics driver authors know, they are probably the
> > > > > > best ones to help out with this, not the "generic" stable mailing list.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > Hello,
> > > > >
> > > > > The culprit commit seems to be:
> > > > >
> > > > > commit: ed4a6a7
> > > > > drm/i915: Add two-stage ILK-style watermark programming
> > > > >
> > > > > Attached the bisection log.
> > > > >
> > > > > Let me know if additional test or bisect is needed.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Gaston
> > > >
> > > > > git bisect start '--' 'drivers/gpu/drm/'
> > > > > # good: [096998b11906dd79df5af4d688c9974342dd09f2] Linux 4.6.7
> > > > > git bisect good 096998b11906dd79df5af4d688c9974342dd09f2
> > > > > # bad: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
> > > > > git bisect bad c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
> > > > > # good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
> > > > > git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
> > > > > # bad: [3c85f20a289d044f303f473ee6ab7502303fc3b0] Merge tag 'omapdrm-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
> > > > > git bisect bad 3c85f20a289d044f303f473ee6ab7502303fc3b0
> > > > > # bad: [a64424d722504926f3375bc4887976e3bfe3a01d] Merge branch 'drm-next-4.7' of git://people.freedesktop.org/~agd5f/linux into drm-next
> > > > > git bisect bad a64424d722504926f3375bc4887976e3bfe3a01d
> > > > > # bad: [b5bf0f1ea3658254bd72ef64abc97786e8a32255] drm/exynos: clean up register definions for fimd and decon
> > > > > git bisect bad b5bf0f1ea3658254bd72ef64abc97786e8a32255
> > > > > # bad: [27878ede4fec7b929c3010710ba4d55c617c621d] drm/i915: Throw out BUGs from DPLL/PCH functions
> > > > > git bisect bad 27878ede4fec7b929c3010710ba4d55c617c621d
> > > > > # bad: [72341af4285ae1337c0dfdfa3e68318b52b8757c] drm/i915: hide away VBT private data in a separate header
> > > > > git bisect bad 72341af4285ae1337c0dfdfa3e68318b52b8757c
> > > > > # bad: [71f0a626143368b8aead361ffaff7e36d043fd8e] drm/i915: Only use sanitized values for ILK watermarks
> > > > > git bisect bad 71f0a626143368b8aead361ffaff7e36d043fd8e
> > > > > # bad: [66e2c4c39cc37beaccc24c9d14c75d627fce9cf4] drm/i915/gen9: Disable DC states if power well support is disabled
> > > > > git bisect bad 66e2c4c39cc37beaccc24c9d14c75d627fce9cf4
> > > > > # bad: [4f2d9934bd6ac73950832c96b385822846670668] drm/i915: Pass drm_frambuffer to intel_compute_page_offset()
> > > > > git bisect bad 4f2d9934bd6ac73950832c96b385822846670668
> > > > > # bad: [1d5bf5d9d9ef0c1e639d36178a224d83888c5a29] drm/i915: Add missing NULL check before calling initial_watermarks
> > > > > git bisect bad 1d5bf5d9d9ef0c1e639d36178a224d83888c5a29
> > > > > # bad: [d9f8e52b22454a30aaaf26b7ef029598b30abf8e] drm/i915: remove dead code
> > > > > git bisect bad d9f8e52b22454a30aaaf26b7ef029598b30abf8e
> > > > > # bad: [c3454d575da162cd310d9b83696baefb29d10a70] drm/i915: remove left over dead code
> > > > > git bisect bad c3454d575da162cd310d9b83696baefb29d10a70
> > > > > # bad: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage ILK-style watermark programming (v11)
> > > > > git bisect bad ed4a6a7ca853253f9b86f3005d76345482a71283
> > > > > # first bad commit: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage ILK-style watermark programming (v11)
> > > >
> > > >
> > > > Nothing from the graphics developers? Come on, here is someone who
> > > > found a specific patch that causes a problem, and no one responds?
> > >
> > > Probably no one noticed the mail on account of the relevant lists
> > > not getting Cc:d from the get go. Sorry.
> > >
> > > >
> > > > Why isn't this fixed by reverting the above mentioned patch in Linus's
> > > > tree already? Or, is there something else that needs to be done?
> > >
> > > IIRC the problems caused by that watermark stuff should have been fixed by
> > > some combination of these
> > > 9bd18728a3f2 ("drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)")
> > > 7045c3689f14 ("drm/i915: Don't leave old junk in ilk active watermarks on readout")
> > > d890565c4444 ("drm/i915: Use the active wm config for merging on ILK-BDW")
> > > f1ecaf8f9c99 ("drm/i915: Start WM computation from scratch on ILK-BDW")
> > >
> > > so it's not quite clear if the bisect landed at the right spot, or if we
> > > have more than one overlapping regression around.
> > >
> > > Please file a bug at
> > > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> > > and attach the full dmesg from boot up to when you reproduced the
> > > problem. And pass drm.debug=0xe to kernel so that we'll get (hopefully)
> > > enough debug information into the log.
> > >
> > > Trying the latest nightly tree from
> > > git://anongit.freedesktop.org/drm-intel drm-intel-nightly
> > > would also be a good idea, in case we already fixed the problem.
> > >
> > > --
> > > Ville Syrjälä
> > > Intel OTC
> >
> > Hi,
> >
> > Now I'm running a 4.8.4 kernel and the problem seems to be solved. So no
> > need to file a bug report, right?
>
> Ah, that's great, no need!
Yeah, 4.8 had a bunch of wm fallout because we're reworking that code and
the freeze for the 4.8 merge window seemed to have hit a bad time.
Bugfixes are slowly percolating through the system. I think the regression
from Ted also has a big chance to be a similar issue.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 4.8 129/138] usb: chipidea: host: fix NULL ptr dereference during shutdown
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, Stefan Wahren, Peter Chen
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <stefan.wahren@i2se.com>
commit 991d5add50a5bb6ab8f12f2129f5c7487f6baaf6 upstream.
After commit b09b5224fe86 ("usb: chipidea: implement platform shutdown
callback") and commit 43a404577a93 ("usb: chipidea: host: set host to
be null after hcd is freed") a NULL pointer dereference is caused
on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and
we finish interrupt handling before the hcd is deallocated. This avoids
the NULL pointer dereference.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: b09b5224fe86 ("usb: chipidea: implement platform shutdown callback")
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/host.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci
if (hcd) {
usb_remove_hcd(hcd);
+ ci->role = CI_ROLE_END;
+ synchronize_irq(ci->irq);
usb_put_hcd(hcd);
if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
(ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))
^ permalink raw reply
* Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support
From: Borislav Petkov @ 2016-11-09 11:14 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel, user-mode-linux-devel,
user-mode-linux-user, linux-fsdevel, linux-kselftest, kvm
In-Reply-To: <20161108183956.4521-6-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:54AM -0800, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. This will allow a ptracer to emulate the CPUID
> instruction.
>
> Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
> documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
>
> Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> Reviewed-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/msr-index.h | 2 ++
> arch/x86/kernel/cpu/scattered.c | 22 +++++++++++++++++++++-
> 3 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index a396292..62962e8 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -184,16 +184,17 @@
> * Auxiliary flags: Linux defined - For features scattered in various
> * CPUID levels like 0x6, 0xA etc, word 7.
> *
> * Reuse free bits when adding new feature flags!
> */
>
> #define X86_FEATURE_CPB ( 7*32+ 2) /* AMD Core Performance Boost */
> #define X86_FEATURE_EPB ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
> +#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */
Bit 0 in that leaf is free. Also, bit 4 is already claimed by RDT/CAT/...
whatever that thing is going to be called so please do:
#define X86_FEATURE_CPUID_FAULT ( 7*32+ 0) /* Intel CPUID faulting */
>
> #define X86_FEATURE_HW_PSTATE ( 7*32+ 8) /* AMD HW-PState */
> #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
>
> #define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */
> #define X86_FEATURE_AVX512_4VNNIW (7*32+16) /* AVX-512 Neural Network Instructions */
> #define X86_FEATURE_AVX512_4FMAPS (7*32+17) /* AVX-512 Multiply Accumulation Single precision */
...
> for (cb = cpuid_bits; cb->feature; cb++) {
>
> /* Verify that the level is valid */
> max_level = cpuid_eax(cb->level & 0xffff0000);
> if (max_level < cb->level ||
> max_level > (cb->level | 0xffff))
> continue;
>
> cpuid_count(cb->level, cb->sub_leaf, ®s[CR_EAX],
> ®s[CR_EBX], ®s[CR_ECX], ®s[CR_EDX]);
>
> if (regs[cb->reg] & (1 << cb->bit))
> set_cpu_cap(c, cb->feature);
> }
> +
> + for (mb = msr_bits; mb->feature; mb++) {
> + if (rdmsrl_safe(mb->msr, &msrval))
> + continue;
<--- newline here.
> + if (msrval & (1ULL << mb->bit))
if (msrval & BIT_ULL(mb->bit))
> + set_cpu_cap(c, mb->feature);
> + }
> }
> --
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support
From: Borislav Petkov @ 2016-11-09 11:14 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel
In-Reply-To: <20161108183956.4521-6-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:54AM -0800, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. This will allow a ptracer to emulate the CPUID
> instruction.
>
> Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
> documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
>
> Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> Reviewed-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/msr-index.h | 2 ++
> arch/x86/kernel/cpu/scattered.c | 22 +++++++++++++++++++++-
> 3 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index a396292..62962e8 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -184,16 +184,17 @@
> * Auxiliary flags: Linux defined - For features scattered in various
> * CPUID levels like 0x6, 0xA etc, word 7.
> *
> * Reuse free bits when adding new feature flags!
> */
>
> #define X86_FEATURE_CPB ( 7*32+ 2) /* AMD Core Performance Boost */
> #define X86_FEATURE_EPB ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
> +#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */
Bit 0 in that leaf is free. Also, bit 4 is already claimed by RDT/CAT/...
whatever that thing is going to be called so please do:
#define X86_FEATURE_CPUID_FAULT ( 7*32+ 0) /* Intel CPUID faulting */
>
> #define X86_FEATURE_HW_PSTATE ( 7*32+ 8) /* AMD HW-PState */
> #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
>
> #define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */
> #define X86_FEATURE_AVX512_4VNNIW (7*32+16) /* AVX-512 Neural Network Instructions */
> #define X86_FEATURE_AVX512_4FMAPS (7*32+17) /* AVX-512 Multiply Accumulation Single precision */
...
> for (cb = cpuid_bits; cb->feature; cb++) {
>
> /* Verify that the level is valid */
> max_level = cpuid_eax(cb->level & 0xffff0000);
> if (max_level < cb->level ||
> max_level > (cb->level | 0xffff))
> continue;
>
> cpuid_count(cb->level, cb->sub_leaf, ®s[CR_EAX],
> ®s[CR_EBX], ®s[CR_ECX], ®s[CR_EDX]);
>
> if (regs[cb->reg] & (1 << cb->bit))
> set_cpu_cap(c, cb->feature);
> }
> +
> + for (mb = msr_bits; mb->feature; mb++) {
> + if (rdmsrl_safe(mb->msr, &msrval))
> + continue;
<--- newline here.
> + if (msrval & (1ULL << mb->bit))
if (msrval & BIT_ULL(mb->bit))
> + set_cpu_cap(c, mb->feature);
> + }
> }
> --
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: task isolation discussion at Linux Plumbers
From: Andy Lutomirski @ 2016-11-09 11:14 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Chris Metcalf, Gilad Ben Yossef, Steven Rostedt, Ingo Molnar,
Peter Zijlstra, Andrew Morton, Rik van Riel, Tejun Heo,
Frederic Weisbecker, Thomas Gleixner, Christoph Lameter,
Viresh Kumar, Catalin Marinas, Will Deacon, Daniel Lezcano,
Francis Giraldeau, Andi Kleen, Arnd Bergmann,
linux-kernel@vger.kernel.org
In-Reply-To: <20161109014045.GI4127@linux.vnet.ibm.com>
On Tue, Nov 8, 2016 at 5:40 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> commit 49961e272333ac720ac4ccbaba45521bfea259ae
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Tue Nov 8 14:25:21 2016 -0800
>
> rcu: Maintain special bits at bottom of ->dynticks counter
>
> Currently, IPIs are used to force other CPUs to invalidate their TLBs
> in response to a kernel virtual-memory mapping change. This works, but
> degrades both battery lifetime (for idle CPUs) and real-time response
> (for nohz_full CPUs), and in addition results in unnecessary IPIs due to
> the fact that CPUs executing in usermode are unaffected by stale kernel
> mappings. It would be better to cause a CPU executing in usermode to
> wait until it is entering kernel mode to
missing words here?
>
> This commit therefore reserves a bit at the bottom of the ->dynticks
> counter, which is checked upon exit from extended quiescent states. If it
> is set, it is cleared and then a new rcu_dynticks_special_exit() macro
> is invoked, which, if not supplied, is an empty single-pass do-while loop.
> If this bottom bit is set on -entry- to an extended quiescent state,
> then a WARN_ON_ONCE() triggers.
>
> This bottom bit may be set using a new rcu_dynticks_special_set()
> function, which returns true if the bit was set, or false if the CPU
> turned out to not be in an extended quiescent state. Please note that
> this function refuses to set the bit for a non-nohz_full CPU when that
> CPU is executing in usermode because usermode execution is tracked by
> RCU as a dyntick-idle extended quiescent state only for nohz_full CPUs.
I'm inclined to suggest s/dynticks/eqs/ in the public API. To me,
"dynticks" is a feature, whereas "eqs" means "extended quiescent
state" and means something concrete about the CPU state
>
> Reported-by: Andy Lutomirski <luto@amacapital.net>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index 4f9b2fa2173d..130d911e4ba1 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -33,6 +33,11 @@ static inline int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
> return 0;
> }
>
> +static inline bool rcu_dynticks_special_set(int cpu)
> +{
> + return false; /* Never flag non-existent other CPUs! */
> +}
> +
> static inline unsigned long get_state_synchronize_rcu(void)
> {
> return 0;
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index dbf20b058f48..8de83830e86b 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -279,23 +279,36 @@ static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
> };
>
> /*
> + * Steal a bit from the bottom of ->dynticks for idle entry/exit
> + * control. Initially this is for TLB flushing.
> + */
> +#define RCU_DYNTICK_CTRL_MASK 0x1
> +#define RCU_DYNTICK_CTRL_CTR (RCU_DYNTICK_CTRL_MASK + 1)
> +#ifndef rcu_dynticks_special_exit
> +#define rcu_dynticks_special_exit() do { } while (0)
> +#endif
> +
> /*
> @@ -305,17 +318,21 @@ static void rcu_dynticks_eqs_enter(void)
> static void rcu_dynticks_eqs_exit(void)
> {
> struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
> + int seq;
>
> /*
> - * CPUs seeing atomic_inc() must see prior idle sojourns,
> + * CPUs seeing atomic_inc_return() must see prior idle sojourns,
> * and we also must force ordering with the next RCU read-side
> * critical section.
> */
> - smp_mb__before_atomic(); /* See above. */
> - atomic_inc(&rdtp->dynticks);
> - smp_mb__after_atomic(); /* See above. */
> + seq = atomic_inc_return(&rdtp->dynticks);
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> - !(atomic_read(&rdtp->dynticks) & 0x1));
> + !(seq & RCU_DYNTICK_CTRL_CTR));
> + if (seq & RCU_DYNTICK_CTRL_MASK) {
> + atomic_and(~RCU_DYNTICK_CTRL_MASK, &rdtp->dynticks);
> + smp_mb__after_atomic(); /* Clear bits before acting on them */
> + rcu_dynticks_special_exit();
I think this needs to be reversed for NMI safety: do the callback and
then clear the bits.
> +/*
> + * Set the special (bottom) bit of the specified CPU so that it
> + * will take special action (such as flushing its TLB) on the
> + * next exit from an extended quiescent state. Returns true if
> + * the bit was successfully set, or false if the CPU was not in
> + * an extended quiescent state.
> + */
> +bool rcu_dynticks_special_set(int cpu)
> +{
> + int old;
> + int new;
> + struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
> +
> + do {
> + old = atomic_read(&rdtp->dynticks);
> + if (old & RCU_DYNTICK_CTRL_CTR)
> + return false;
> + new = old | ~RCU_DYNTICK_CTRL_MASK;
Shouldn't this be old | RCU_DYNTICK_CTRL_MASK?
> + } while (atomic_cmpxchg(&rdtp->dynticks, old, new) != old);
> + return true;
> }
--Andy
^ permalink raw reply
* [PATCH 4.8 078/138] ovl: fsync after copy-up
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Miklos Szeredi
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <mszeredi@redhat.com>
commit 641089c1549d8d3df0b047b5de7e9a111362cdce upstream.
Make sure the copied up file hits the disk before renaming to the final
destination. If this is not done then the copy-up may corrupt the data in
the file in case of a crash.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/overlayfs/copy_up.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -171,6 +171,8 @@ static int ovl_copy_up_data(struct path
len -= bytes;
}
+ if (!error)
+ error = vfs_fsync(new_file, 0);
fput(new_file);
out_fput:
fput(old_file);
^ permalink raw reply
* [PATCH 4.8 076/138] ovl: fix get_acl() on tmpfs
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Amir Goldstein, Miklos Szeredi
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <mszeredi@redhat.com>
commit b93d4a0eb308d4400b84c8b24c1b80e09a9497d0 upstream.
tmpfs doesn't have ->get_acl() because it only uses cached acls.
This fixes the acl tests in pjdfstest when tmpfs is used as the upper layer
of the overlay.
Reported-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: 39a25b2b3762 ("ovl: define ->get_acl() for overlay inodes")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/overlayfs/inode.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -294,9 +294,6 @@ struct posix_acl *ovl_get_acl(struct ino
if (!IS_ENABLED(CONFIG_FS_POSIX_ACL) || !IS_POSIXACL(realinode))
return NULL;
- if (!realinode->i_op->get_acl)
- return NULL;
-
old_cred = ovl_override_creds(inode->i_sb);
acl = get_acl(realinode, type);
revert_creds(old_cred);
^ permalink raw reply
* [PATCH 4.8 074/138] nfsd: Fix general protection fault in release_lock_stateid()
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chuck Lever, Jeff Layton,
J. Bruce Fields
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever <chuck.lever@oracle.com>
commit f46c445b79906a9da55c13e0a6f6b6a006b892fe upstream.
When I push NFSv4.1 / RDMA hard, (xfstests generic/089, for example),
I get this crash on the server:
Oct 28 22:04:30 klimt kernel: general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
Oct 28 22:04:30 klimt kernel: Modules linked in: cts rpcsec_gss_krb5 iTCO_wdt iTCO_vendor_support sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm btrfs irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd xor pcspkr raid6_pq i2c_i801 i2c_smbus lpc_ich mfd_core sg mei_me mei ioatdma shpchp wmi ipmi_si ipmi_msghandler rpcrdma ib_ipoib rdma_ucm acpi_power_meter acpi_pad ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx4_ib mlx4_en ib_core sr_mod cdrom sd_mod ast drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel igb ahci libahci ptp mlx4_core pps_core dca libata i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
Oct 28 22:04:30 klimt kernel: CPU: 7 PID: 1558 Comm: nfsd Not tainted 4.9.0-rc2-00005-g82cd754 #8
Oct 28 22:04:30 klimt kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
Oct 28 22:04:30 klimt kernel: task: ffff880835c3a100 task.stack: ffff8808420d8000
Oct 28 22:04:30 klimt kernel: RIP: 0010:[<ffffffffa05a759f>] [<ffffffffa05a759f>] release_lock_stateid+0x1f/0x60 [nfsd]
Oct 28 22:04:30 klimt kernel: RSP: 0018:ffff8808420dbce0 EFLAGS: 00010246
Oct 28 22:04:30 klimt kernel: RAX: ffff88084e6660f0 RBX: ffff88084e667020 RCX: 0000000000000000
Oct 28 22:04:30 klimt kernel: RDX: 0000000000000007 RSI: 0000000000000000 RDI: ffff88084e667020
Oct 28 22:04:30 klimt kernel: RBP: ffff8808420dbcf8 R08: 0000000000000001 R09: 0000000000000000
Oct 28 22:04:30 klimt kernel: R10: ffff880835c3a100 R11: ffff880835c3aca8 R12: 6b6b6b6b6b6b6b6b
Oct 28 22:04:30 klimt kernel: R13: ffff88084e6670d8 R14: ffff880835f546f0 R15: ffff880835f1c548
Oct 28 22:04:30 klimt kernel: FS: 0000000000000000(0000) GS:ffff88087bdc0000(0000) knlGS:0000000000000000
Oct 28 22:04:30 klimt kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 28 22:04:30 klimt kernel: CR2: 00007ff020389000 CR3: 0000000001c06000 CR4: 00000000001406e0
Oct 28 22:04:30 klimt kernel: Stack:
Oct 28 22:04:30 klimt kernel: ffff88084e667020 0000000000000000 ffff88084e6670d8 ffff8808420dbd20
Oct 28 22:04:30 klimt kernel: ffffffffa05ac80d ffff880835f54548 ffff88084e640008 ffff880835f545b0
Oct 28 22:04:30 klimt kernel: ffff8808420dbd70 ffffffffa059803d ffff880835f1c768 0000000000000870
Oct 28 22:04:30 klimt kernel: Call Trace:
Oct 28 22:04:30 klimt kernel: [<ffffffffa05ac80d>] nfsd4_free_stateid+0xfd/0x1b0 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa059803d>] nfsd4_proc_compound+0x40d/0x690 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa0583114>] nfsd_dispatch+0xd4/0x1d0 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa047bbf9>] svc_process_common+0x3d9/0x700 [sunrpc]
Oct 28 22:04:30 klimt kernel: [<ffffffffa047ca64>] svc_process+0xf4/0x330 [sunrpc]
Oct 28 22:04:30 klimt kernel: [<ffffffffa05827ca>] nfsd+0xfa/0x160 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa05826d0>] ? nfsd_destroy+0x170/0x170 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffff810b367b>] kthread+0x10b/0x120
Oct 28 22:04:30 klimt kernel: [<ffffffff810b3570>] ? kthread_stop+0x280/0x280
Oct 28 22:04:30 klimt kernel: [<ffffffff8174e8ba>] ret_from_fork+0x2a/0x40
Oct 28 22:04:30 klimt kernel: Code: c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 87 b0 00 00 00 48 89 fb 4c 8b a0 98 00 00 00 <49> 8b 44 24 20 48 8d b8 80 03 00 00 e8 10 66 1a e1 48 89 df e8
Oct 28 22:04:30 klimt kernel: RIP [<ffffffffa05a759f>] release_lock_stateid+0x1f/0x60 [nfsd]
Oct 28 22:04:30 klimt kernel: RSP <ffff8808420dbce0>
Oct 28 22:04:30 klimt kernel: ---[ end trace cf5d0b371973e167 ]---
Jeff Layton says:
> Hm...now that I look though, this is a little suspicious:
>
> struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
>
> I wonder if it's possible for the openstateid to have already been
> destroyed at this point.
>
> We might be better off doing something like this to get the client pointer:
>
> stp->st_stid.sc_client;
>
> ...which should be more direct and less dependent on other stateids
> staying valid.
With the suggested change, I am no longer able to reproduce the above oops.
v2: Fix unhash_lock_stateid() as well
Fix-suggested-by: Jeff Layton <jlayton@redhat.com>
Fixes: 42691398be08 ('nfsd: Fix race between FREE_STATEID and LOCK')
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1147,9 +1147,7 @@ static void put_ol_stateid_locked(struct
static bool unhash_lock_stateid(struct nfs4_ol_stateid *stp)
{
- struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
-
- lockdep_assert_held(&oo->oo_owner.so_client->cl_lock);
+ lockdep_assert_held(&stp->st_stid.sc_client->cl_lock);
list_del_init(&stp->st_locks);
nfs4_unhash_stid(&stp->st_stid);
@@ -1158,12 +1156,12 @@ static bool unhash_lock_stateid(struct n
static void release_lock_stateid(struct nfs4_ol_stateid *stp)
{
- struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
+ struct nfs4_client *clp = stp->st_stid.sc_client;
bool unhashed;
- spin_lock(&oo->oo_owner.so_client->cl_lock);
+ spin_lock(&clp->cl_lock);
unhashed = unhash_lock_stateid(stp);
- spin_unlock(&oo->oo_owner.so_client->cl_lock);
+ spin_unlock(&clp->cl_lock);
if (unhashed)
nfs4_put_stid(&stp->st_stid);
}
^ permalink raw reply
* [PATCH 4.8 077/138] ovl: update S_ISGID when setting posix ACLs
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Amir Goldstein, Miklos Szeredi
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <mszeredi@redhat.com>
commit fd3220d37b1f6f0cab6142d98b0e6c4082e63299 upstream.
This change fixes xfstest generic/375, which failed to clear the
setgid bit in the following test case on overlayfs:
touch $testfile
chown 100:100 $testfile
chmod 2755 $testfile
_runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
Reported-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Tested-by: Amir Goldstein <amir73il@gmail.com>
Fixes: d837a49bd57f ("ovl: fix POSIX ACL setting")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/overlayfs/super.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -1026,6 +1026,21 @@ ovl_posix_acl_xattr_set(const struct xat
posix_acl_release(acl);
+ /*
+ * Check if sgid bit needs to be cleared (actual setacl operation will
+ * be done with mounter's capabilities and so that won't do it for us).
+ */
+ if (unlikely(inode->i_mode & S_ISGID) &&
+ handler->flags == ACL_TYPE_ACCESS &&
+ !in_group_p(inode->i_gid) &&
+ !capable_wrt_inode_uidgid(inode, CAP_FSETID)) {
+ struct iattr iattr = { .ia_valid = ATTR_KILL_SGID };
+
+ err = ovl_setattr(dentry, &iattr);
+ if (err)
+ return err;
+ }
+
err = ovl_xattr_set(dentry, handler->name, value, size, flags);
if (!err)
ovl_copyattr(ovl_inode_real(inode, NULL), inode);
^ permalink raw reply
* [Qemu-devel] [Bug 899961] Re: qemu/kvm locks up when run 32bit userspace with 64bit kernel
From: Thomas Huth @ 2016-11-09 10:58 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20111204161619.13512.72277.malonedeb@soybean.canonical.com>
The bug in Debian has been marked as "Fix released", so I assume this
has been fixed in upstream QEMU, too? Or is there still anything left to
do here?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/899961
Title:
qemu/kvm locks up when run 32bit userspace with 64bit kernel
Status in QEMU:
Incomplete
Status in qemu-kvm package in Debian:
Fix Released
Bug description:
Only applies to qemu-kvm 1.0, and only when kernel is 64bit and
userspace is 32bit, on x86. Did not happen with previous released
versions, such as 0.15. Not all guests triggers this issue - so far,
only (32bit) windows 7 guest shows it, but does that quite reliable:
first boot of an old guest with new qemu-kvm, windows finds a new CPU
and suggests rebooting - hit "Reboot" and in a few seconds it will be
locked up (including the monitor), with no CPU usage whatsoever.
Killable only with -9.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/899961/+subscriptions
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Jani Nikula @ 2016-11-09 11:16 UTC (permalink / raw)
To: Markus Heiser, Josh Triplett
Cc: ksummit-discuss, linux-doc, linux-kernel, Mauro Carvalho Chehab,
linux-media
In-Reply-To: <A4091944-D727-45B5-AC24-FE3B2700298E@darmarit.de>
On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 07.11.2016 um 18:01 schrieb Josh Triplett <josh@joshtriplett.org>:
>
>> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>>> inkscape to convert the bitmap;
>>
>> This seems sensible; Sphinx should directly handle the source format we
>> want to use for images/diagrams.
>>
>>> 3) if possible, add an extension to trick Sphinx for it to consider the
>>> output dir as a source dir too.
>>
>> Or to provide an additional source path and point that at the output
>> directory.
>
> The sphinx-build command excepts only one 'sourcedir' argument. All
> reST files in this folder (and below) are parsed.
>
> Most (all?) directives which include content like images or literalinclude
> except only relative pathnames. Where *relative* means, relative to the
> reST file where the directive is used. For security reasons relative
> pathnames outside 'sourcepath' are not excepted.
>
> So I vote for :
>
>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> build dir specified via O= directive) and generate the *.pdf there,
>> and produce those converted images via Makefile.;
We're supposed to solve problems, not create new ones.
> Placing reST files together with the *autogenerated* (intermediate)
> content from
>
> * image conversions,
> * reST content build from MAINTAINERS,
> * reST content build for ABI
> * etc.
>
> has the nice side effect, that we can get rid of all theses BUILDDIR
> quirks in the Makefile.sphinx
>
> Additional, we can write Makefile targets to build the above listed
> intermediate content relative to the $PWD, which is what Linux's
> Makefiles usual do (instead of quirking with a BUILDDIR).
>
> E.g. with, we can also get rid of the 'kernel-include' directive
> and replace it, with Sphinx's common 'literaliclude' and we do not
> need any extensions to include intermediate PDFs or whatever
> intermediate content we might want to generate.
Well, kernel-include is a hack to make parse-headers.pl work, which is
also a hack that IMHO shouldn't exist...
> IMO placing 'sourcedir' to O= is more sane since this marries the
> Linux Makefile concept (relative to $PWD) with the sphinx concept
> (in or below 'sourcedir').
>
>
> -- Markus --
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Jani Nikula @ 2016-11-09 11:16 UTC (permalink / raw)
To: Markus Heiser, Josh Triplett
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel, linux-media,
ksummit-discuss, linux-doc
In-Reply-To: <A4091944-D727-45B5-AC24-FE3B2700298E@darmarit.de>
On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 07.11.2016 um 18:01 schrieb Josh Triplett <josh@joshtriplett.org>:
>
>> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>>> inkscape to convert the bitmap;
>>
>> This seems sensible; Sphinx should directly handle the source format we
>> want to use for images/diagrams.
>>
>>> 3) if possible, add an extension to trick Sphinx for it to consider the
>>> output dir as a source dir too.
>>
>> Or to provide an additional source path and point that at the output
>> directory.
>
> The sphinx-build command excepts only one 'sourcedir' argument. All
> reST files in this folder (and below) are parsed.
>
> Most (all?) directives which include content like images or literalinclude
> except only relative pathnames. Where *relative* means, relative to the
> reST file where the directive is used. For security reasons relative
> pathnames outside 'sourcepath' are not excepted.
>
> So I vote for :
>
>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> build dir specified via O= directive) and generate the *.pdf there,
>> and produce those converted images via Makefile.;
We're supposed to solve problems, not create new ones.
> Placing reST files together with the *autogenerated* (intermediate)
> content from
>
> * image conversions,
> * reST content build from MAINTAINERS,
> * reST content build for ABI
> * etc.
>
> has the nice side effect, that we can get rid of all theses BUILDDIR
> quirks in the Makefile.sphinx
>
> Additional, we can write Makefile targets to build the above listed
> intermediate content relative to the $PWD, which is what Linux's
> Makefiles usual do (instead of quirking with a BUILDDIR).
>
> E.g. with, we can also get rid of the 'kernel-include' directive
> and replace it, with Sphinx's common 'literaliclude' and we do not
> need any extensions to include intermediate PDFs or whatever
> intermediate content we might want to generate.
Well, kernel-include is a hack to make parse-headers.pl work, which is
also a hack that IMHO shouldn't exist...
> IMO placing 'sourcedir' to O= is more sane since this marries the
> Linux Makefile concept (relative to $PWD) with the sphinx concept
> (in or below 'sourcedir').
>
>
> -- Markus --
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH 4.8 127/138] pwm: Unexport children before chip removal
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, David Hsu, Thierry Reding
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hsu <davidhsu@google.com>
commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pwm/core.c | 2 ++
drivers/pwm/sysfs.c | 18 ++++++++++++++++++
include/linux/pwm.h | 5 +++++
3 files changed, 25 insertions(+)
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -339,6 +339,8 @@ int pwmchip_remove(struct pwm_chip *chip
unsigned int i;
int ret = 0;
+ pwmchip_sysfs_unexport_children(chip);
+
mutex_lock(&pwm_lock);
for (i = 0; i < chip->npwm; i++) {
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -409,6 +409,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
}
}
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+ struct device *parent;
+ unsigned int i;
+
+ parent = class_find_device(&pwm_class, NULL, chip,
+ pwmchip_sysfs_match);
+ if (!parent)
+ return;
+
+ for (i = 0; i < chip->npwm; i++) {
+ struct pwm_device *pwm = &chip->pwms[i];
+
+ if (test_bit(PWMF_EXPORTED, &pwm->flags))
+ pwm_unexport_child(parent, pwm);
+ }
+}
+
static int __init pwm_sysfs_init(void)
{
return class_register(&pwm_class);
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -641,6 +641,7 @@ static inline void pwm_remove_table(stru
#ifdef CONFIG_PWM_SYSFS
void pwmchip_sysfs_export(struct pwm_chip *chip);
void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
#else
static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
{
@@ -649,6 +650,10 @@ static inline void pwmchip_sysfs_export(
static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
{
}
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
#endif /* CONFIG_PWM_SYSFS */
#endif /* __LINUX_PWM_H */
^ permalink raw reply
* Re: [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Jan Beulich @ 2016-11-09 11:17 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
In-Reply-To: <1478684526-3678-1-git-send-email-rcojocaru@bitdefender.com>
>>> On 09.11.16 at 10:42, <rcojocaru@bitdefender.com> wrote:
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
> The patch also fixes the behaviour of the xc_hvm_inject_trap()
> hypercall, which would lead to non-architectural interrupts
> overwriting pending (specifically reinjected) architectural ones.
Looks quite okay, just some more or less mechanical comments.
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
> }
> }
>
> - /* Inject pending hw/sw trap */
> - if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
> - {
> + /* Inject pending hw/sw trap if there are no other pending interrupts. */
> + if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) )
> hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
> - v->arch.hvm_vcpu.inject_trap.vector = -1;
> +
> + v->arch.hvm_vcpu.inject_trap.vector = -1;
I don't see why you pull this out of the if() body.
> + if ( unlikely(v->arch.vm_event) &&
> + v->arch.vm_event->monitor_next_interrupt )
Hard tab.
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -150,6 +150,21 @@ int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
> return monitor_traps(curr, 1, &req);
> }
>
> +void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
> + unsigned int err, uint64_t cr2)
> +{
> + struct vcpu *curr = current;
Pointless local variable (used just once).
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2220,6 +2220,21 @@ static void svm_invlpg(struct vcpu *v, unsigned long vaddr)
> svm_asid_g_invlpg(v, vaddr);
> }
>
> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> +{
> + struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +
> + if ( vmcb->eventinj.fields.v )
> + return false;
> +
> + info->vector = vmcb->eventinj.fields.vector;
> + info->type = vmcb->eventinj.fields.type;
> + info->error_code = vmcb->eventinj.fields.errorcode;
> + info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
I'd prefer for this last part to be put into generic code (i.e. the
wrapper).
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
> /* Not supported on ARM. */
> }
>
> +static inline
> +void vm_event_monitor_next_interrupt(struct vcpu *v)
> +{
> + /* Not supported on ARM. */
> +}
That's unfortunate. If it can't be implemented, shouldn't the caller at
least be advised of this being unavailable? Wasn't there even some
mechanism to report capabilities?
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -237,6 +237,8 @@ struct hvm_function_table {
> /* Architecture function to setup TSC scaling ratio */
> void (*setup)(struct vcpu *v);
> } tsc_scaling;
> +
> + bool (*get_pending_event)(struct vcpu *v, struct hvm_trap *info);
> };
Stylistically I think this would better go a little earlier.
> --- a/xen/include/asm-x86/vm_event.h
> +++ b/xen/include/asm-x86/vm_event.h
> @@ -32,6 +32,7 @@ struct arch_vm_event {
> struct vm_event_emul_insn_data insn;
> } emul;
> struct monitor_write_data write_data;
> + bool monitor_next_interrupt;
> };
I think there's a 32-bit padding hole before write_data, so the new
field would better go earlier (perhaps even right after flags).
> @@ -139,6 +144,8 @@
> * These kinds of events will be filtered out in future versions.
> */
> #define VM_EVENT_REASON_PRIVILEGED_CALL 11
> +/* Result of toolstack-requested (non-architectural) trap injection. */
> +#define VM_EVENT_REASON_INTERRUPT 12
Considering the event reports all kinds of interruptions, I don't think
the comment is appropriate.
> @@ -259,6 +266,13 @@ struct vm_event_cpuid {
> uint32_t _pad;
> };
>
> +struct vm_event_interrupt {
> + uint32_t vector;
> + uint32_t type;
> + uint32_t error_code;
> + uint64_t cr2;
> +};
This being x86-specific, I think it should be named or union-ized
accordingly.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: Review required to use custom script
From: sujith h @ 2016-11-09 11:17 UTC (permalink / raw)
To: Michael Wood; +Cc: toaster
In-Reply-To: <CADyYWLksjVLwK2O8uo7ajtTNsxhbdp-+XOQssCETrjTKk+gqUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5489 bytes --]
Hi,
I have split my patches into 2. And the top two patches need review. Below
is the link to the branch:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sujith/toaster-use-custom-build-scriptsV2
Thanks,
Sujith H
On Fri, Nov 4, 2016 at 11:50 AM, sujith h <sujith.h@gmail.com> wrote:
> Hi,
>
> I have updated the patch: http://git.yoctoproject.org/
> cgit/cgit.cgi/poky-contrib/commit/?h=sujith/toaster-use-
> custom-build-scripts&id=e0cdebe26298c014db68f61955586e66d7f2ea83
>
> Added except ToasterSetting.DoesNotExist: instead of just except:
>
> Let me know if this looks ok. Else I can rework on the same.
>
> Thanks,
> Sujith H
>
> On Wed, Nov 2, 2016 at 9:42 PM, Michael Wood <michael.g.wood@intel.com>
> wrote:
>
>> Couple of comments below:
>>
>>
>> From b874cbeae00a4e0d34336d3857731c1233ac73d0 Mon Sep 17 00:00:00 2001
>> From: Sujith H <sujith.h@gmail.com>
>> Date: Fri, 28 Oct 2016 07:40:22 +0000
>> Subject: toaster: accept custom init script for build
>>
>> When passed variable CUSTOM_BUILD_INIT_SCRIPT to toaster
>> setting, it would be nice to use it. Else toaster
>> can use oe-init script. This gives an oppurtunity to
>> use customized build init scritps.
>>
>> Signed-off-by: Sujith H <sujith.h@gmail.com>
>>
>> diff --git a/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py
>> b/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py
>> index a64e89b..33717cd 100644
>> --- a/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py
>> +++ b/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py
>> @@ -27,7 +27,7 @@ import shutil
>> from django.db import transaction
>> from django.db.models import Q
>> from bldcontrol.models import BuildEnvironment, BRLayer, BRVariable,
>> BRTarget, BRBitbake
>> -from orm.models import CustomImageRecipe, Layer, Layer_Version,
>> ProjectLayer
>> +from orm.models import CustomImageRecipe, Layer, Layer_Version,
>> ProjectLayer, ToasterSetting
>> import subprocess
>> from toastermain import settings
>> @@ -277,20 +277,23 @@ class LocalhostBEController(BuildEnv
>> ironmentController):
>> builddir = '%s-toaster-%d' % (self.be.builddir,
>> bitbake.req.project.id)
>> oe_init = os.path.join(self.pokydirname, 'oe-init-build-env')
>> # init build environment
>> - self._shellcmd("bash -c 'source %s %s'" % (oe_init, builddir),
>> + try:
>> + custom_script = ToasterSetting.objects.get(nam
>> e="CUSTOM_BUILD_INIT_SCRIPT").value
>> + custom_script = custom_script.replace("%BUILDDIR%"
>> ,builddir)
>> + self._shellcmd("bash -c 'source %s'" % (custom_script))
>> + except:
>>
>>
>>
>> Please add the exception type in here. It'll be something like
>> ToaserSettings.DoesNotExist see
>> https://docs.djangoproject.com/en/1.8/ref/models/instances/#
>> django.db.models.Model.DoesNotExist
>>
>>
>>
>>
>> + self._shellcmd("bash -c 'source %s %s'" % (oe_init,
>> builddir),
>> self.be.sourcedir)
>> # update bblayers.conf
>> bblconfpath = os.path.join(builddir, "conf/bblayers.conf")
>> conflines = open(bblconfpath, "r").readlines()
>> - skip = False
>> + if "# line added by toaster build control\n" in conflines:
>> + conflines.pop()
>>
>>
>>
>> This is something that needs to be a in separate patch as it's a
>> different issue.
>>
>>
>>
>>
>> with open(bblconfpath, 'w') as bblayers:
>> for line in conflines:
>> if line.startswith("# line added by toaster"):
>> - skip = True
>> continue
>> - if skip:
>> - skip = False
>> else:
>> bblayers.write(line)
>>
>>
>> --
>> cgit v0.10.2
>>
>> Thanks,
>>
>> Michael
>>
>>
>> On 02/11/16 05:03, sujith h wrote:
>>
>>> Hi,
>>>
>>> I have created a patch: http://git.yoctoproject.org/cg
>>> it/cgit.cgi/poky-contrib/commit/?h=sujith/toaster-use-custom
>>> -build-scripts&id=b874cbeae00a4e0d34336d3857731c1233ac73d0 to review
>>> the usage of custom init or setup script. This will help users to use their
>>> own script instead of poky's oe-init, if they wish. If
>>> CUSTOM_BUILD_INIT_SCRIPT variable is not available it will fall back to
>>> poky's oe-init. Kindly let me know if the patch is ok or not ( basically
>>> feedback ), I can do the needful to get it better.
>>>
>>> Thanks,
>>> Sujith H
>>>
>>> --
>>> സുജിത് ഹരിദാസന്
>>> Bangalore
>>> <Project>Contributor to KDE project
>>> <Project>Contributor to Yocto project
>>> http://fci.wikia.com/wiki/Anti-DRM-Campaign
>>> <Blog> http://sujithh.info
>>> C-x C-c
>>>
>>>
>>>
>> --
>> _______________________________________________
>> toaster mailing list
>> toaster@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster
>>
>
>
>
> --
> സുജിത് ഹരിദാസന്
> Bangalore
> <Project>Contributor to KDE project
> <Project>Contributor to Yocto project
> http://fci.wikia.com/wiki/Anti-DRM-Campaign
> <Blog> http://sujithh.info
> C-x C-c
>
--
സുജിത് ഹരിദാസന്
Bangalore
<Project>Contributor to KDE project
<Project>Contributor to Yocto project
http://fci.wikia.com/wiki/Anti-DRM-Campaign
<Blog> http://sujithh.info
C-x C-c
[-- Attachment #2: Type: text/html, Size: 8840 bytes --]
^ permalink raw reply
* [PATCH 4.8 123/138] UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Richard Weinberger
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.
scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/ubi/fastmap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -515,10 +515,11 @@ static int scan_pool(struct ubi_device *
unsigned long long ec = be64_to_cpu(ech->ec);
unmap_peb(ai, pnum);
dbg_bld("Adding PEB to free: %i", pnum);
+
if (err == UBI_IO_FF_BITFLIPS)
- add_aeb(ai, free, pnum, ec, 1);
- else
- add_aeb(ai, free, pnum, ec, 0);
+ scrub = 1;
+
+ add_aeb(ai, free, pnum, ec, scrub);
continue;
} else if (err == 0 || err == UBI_IO_BITFLIPS) {
dbg_bld("Found non empty PEB:%i in pool", pnum);
^ permalink raw reply
* [PATCH 4.8 114/138] drm/i915/gen9: fix watermarks when using the pipe scaler
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paulo Zanoni, Matt Roper, Jani Nikula
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
commit 5e33791e1f27c3207e7b44071e7c94a487d1eb39 upstream.
Luckily, the necessary adjustments for when we're using the scaler are
exactly the same as the ones needed on ILK+, so just reuse the
function we already have.
v2: Invert the patch order so stable backports get easier.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit cfd7e3a20251b9ac95651d64556f87f86128a966)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3471,12 +3471,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_
return 0;
}
-static uint32_t skl_pipe_pixel_rate(const struct intel_crtc_state *config)
-{
- /* TODO: Take into account the scalers once we support them */
- return config->base.adjusted_mode.crtc_clock;
-}
-
/*
* The max latency should be 257 (max the punit can code is 255 and we add 2us
* for the read latency) and cpp should always be <= 8, so that
@@ -3527,7 +3521,7 @@ static uint32_t skl_adjusted_plane_pixel
* Adjusted plane pixel rate is just the pipe's adjusted pixel rate
* with additional adjustments for plane-specific scaling.
*/
- adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
+ adjusted_pixel_rate = ilk_pipe_pixel_rate(cstate);
downscale_amount = skl_plane_downscale_amount(pstate);
pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;
@@ -3739,11 +3733,11 @@ skl_compute_linetime_wm(struct intel_crt
if (!cstate->base.active)
return 0;
- if (WARN_ON(skl_pipe_pixel_rate(cstate) == 0))
+ if (WARN_ON(ilk_pipe_pixel_rate(cstate) == 0))
return 0;
return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
- skl_pipe_pixel_rate(cstate));
+ ilk_pipe_pixel_rate(cstate));
}
static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
^ permalink raw reply
* RE: [PATCH v2] HID:i2c-hid: add a simple quirk to fix device defects
From: Hn Chen @ 2016-11-09 11:18 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: jkosina@suse.cz, dmitry.torokhov@gmail.com,
linux-input@vger.kernel.org
In-Reply-To: <20161109103319.GE10327@mail.corp.redhat.com>
Hi Benjamin,
Thanks for the advice !
Will resubmit soon after make the changes and have a test.
Hn.chen.
-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
Sent: Wednesday, November 09, 2016 6:33 PM
To: Hn Chen
Cc: jkosina@suse.cz; dmitry.torokhov@gmail.com; linux-input@vger.kernel.org
Subject: Re: [PATCH v2] HID:i2c-hid: add a simple quirk to fix device defects
On Nov 09 2016 or thereabouts, hn.chen@weidahitech.com wrote:
> From: HungNien Chen <hn.chen@weidahitech.com>
>
> Add a static quirk table and lookup for the quirks in i2c_hid_probe().
> Also add comments and do return value check in i2c_hid_set_power().
>
> Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
> ---
> drivers/hid/hid-ids.h | 5 ++++
> drivers/hid/i2c-hid/i2c-hid.c | 57
> +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index
> 6cfb5ca..787afdf 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -1033,6 +1033,11 @@
> #define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH 0x0500
> #define USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET 0x0502
>
> +#define USB_VENDOR_ID_WEIDA 0x2575
> +#define USB_DEVICE_ID_WEIDA_8756 0x8756
> +#define USB_DEVICE_ID_WEIDA_8752 0xC300
> +#define USB_DEVICE_ID_WEIDA_8755 0xC301
> +
> #define USB_VENDOR_ID_WISEGROUP 0x0925
> #define USB_DEVICE_ID_SMARTJOY_PLUS 0x0005
> #define USB_DEVICE_ID_SUPER_JOY_BOX_3 0x8888
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c
> b/drivers/hid/i2c-hid/i2c-hid.c index b3ec4f2..b32a063 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -41,6 +41,11 @@
>
> #include <linux/i2c/i2c-hid.h>
>
> +#include "../hid-ids.h"
> +
> +/* quirks to control the device */
> +#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV (1 << 0)
You can use BIT(0) instead of (1 << 0)
> +
> /* flags */
> #define I2C_HID_STARTED 0
> #define I2C_HID_RESET_PENDING 1
> @@ -143,6 +148,7 @@ struct i2c_hid {
> char *argsbuf; /* Command arguments buffer */
>
> unsigned long flags; /* device flags */
> + unsigned long quirks; /* Various quirks */
>
> wait_queue_head_t wait; /* For waiting the interrupt */
> struct gpio_desc *desc;
> @@ -154,6 +160,39 @@ struct i2c_hid {
> struct mutex reset_lock;
> };
>
> +static const struct i2c_hid_blacklist {
> + __u16 idVendor;
> + __u16 idProduct;
> + __u32 quirks;
> +} i2c_hid_blacklist[] = {
I'd prefer not using "blacklist". i2c_hid_quirks?
> + { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8752,
> + I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> + { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8755,
> + I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> + { 0, 0 }
> +};
> +
> +/*
> + * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID
> +device
> + * @idVendor: the 16-bit vendor ID
> + * @idProduct: the 16-bit product ID
> + *
> + * Returns: a u32 quirks value.
> + */
> +static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16
> +idProduct) {
> + u32 quirks = 0;
> + int n = 0;
int n;
> +
> + for (; i2c_hid_blacklist[n].idVendor; n++)
for (n = 0; ...)
please :)
> + if (i2c_hid_blacklist[n].idVendor == idVendor &&
> + (i2c_hid_blacklist[n].idProduct == (__u16)HID_ANY_ID ||
> + i2c_hid_blacklist[n].idProduct == idProduct))
> + quirks = i2c_hid_blacklist[n].quirks;
> +
> + return quirks;
> +}
> +
> static int __i2c_hid_command(struct i2c_client *client,
> const struct i2c_hid_cmd *command, u8 reportID,
> u8 reportType, u8 *args, int args_len, @@ -346,11 +385,27 @@ static
> int i2c_hid_set_power(struct i2c_client *client, int power_state)
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> + /*
> + * Some devices require to send a command to wakeup before power on.
> + * The call will get a return value (EREMOTEIO) but device will be
> + * triggered and activated. After that, it goes like a normal device.
> + */
> + if (power_state == I2C_HID_PWR_ON &&
> + ihid->quirks & I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV) {
> + ret = i2c_hid_command(client, &hid_set_power_cmd, NULL, 0);
> +
> + /* Device was already activated */
> + if (!ret)
> + goto set_pwr_exit;
> + }
> +
> ret = __i2c_hid_command(client, &hid_set_power_cmd, power_state,
> 0, NULL, 0, NULL, 0);
> +
> if (ret)
> dev_err(&client->dev, "failed to change power setting.\n");
>
> +set_pwr_exit:
> return ret;
> }
>
> @@ -1050,6 +1105,8 @@ static int i2c_hid_probe(struct i2c_client *client,
> client->name, hid->vendor, hid->product);
> strlcpy(hid->phys, dev_name(&client->dev), sizeof(hid->phys));
>
> + ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
> +
> ret = hid_add_device(hid);
> if (ret) {
> if (ret != -ENODEV)
> --
> 1.9.1
>
OK, thanks for the resubmission. I am happy with the changes so far, so
with the few nitpicks I expressed, it should be mergeable soon.
Cheers,
Benjamin
^ 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.