29 Nov, 2016
4 commits
-
Signed-off-by: Julian Wollrath
Signed-off-by: David S. Miller -
Martin Blumenstingl says:
====================
net: phy: realtek: fix RTL8211F TX-delay handlingThe RTL8211F PHY driver currently enables the TX-delay only when the
phy-mode is PHY_INTERFACE_MODE_RGMII. This is incorrect, because there
are three RGMII variations of the phy-mode which explicitly request the
PHY to enable the RX and/or TX delay, while PHY_INTERFACE_MODE_RGMII
specifies that the PHY should disable the RX and/or TX delays.Additionally to the RTL8211F PHY driver change this contains a small
update to the phy-mode documentation to clarify the purpose of the
RGMII phy-modes.
While this may not be perfect yet it's at least a start. Please feel
free to drop this patch from this series and send an improved version
yourself.These patches are the results of recent discussions, see [0]
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001688.html
====================Signed-off-by: David S. Miller
-
The old logic always enabled the TX-delay when the phy-mode was set to
PHY_INTERFACE_MODE_RGMII. There are dedicated phy-modes which tell the
PHY driver to enable the RX and/or TX delays:
- PHY_INTERFACE_MODE_RGMII should disable the RX and TX delay in the
PHY (if required, the MAC should add the delays in this case)
- PHY_INTERFACE_MODE_RGMII_ID should enable RX and TX delay in the PHY
- PHY_INTERFACE_MODE_RGMII_TXID should enable the TX delay in the PHY
- PHY_INTERFACE_MODE_RGMII_RXID should enable the RX delay in the PHY
(currently not supported by RTL8211F)With this patch we enable the TX delay for PHY_INTERFACE_MODE_RGMII_ID
and PHY_INTERFACE_MODE_RGMII_TXID.
Additionally we now explicity disable the TX-delay, which seems to be
enabled automatically after a hard-reset of the PHY (by triggering it's
reset pin) to get a consistent state (as defined by the phy-mode).This fixes a compatibility problem with some SoCs where the TX-delay was
also added by the MAC. With the TX-delay being applied twice the TX
clock was off and TX traffic was broken or very slow (
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
RGMII requires special RX and/or TX delays depending on the actual
hardware circuit/wiring. These delays can be added by the MAC, the PHY
or the designer of the circuit (the latter means that no delay has to
be added by PHY or MAC).
There are 4 RGMII phy-modes used describe where a delay should be
applied:
- rgmii: the RX and TX delays are either added by the MAC (where the
exact delay is typically configurable, and can be turned off when no
extra delay is needed) or not needed at all (because the hardware
wiring adds the delay already). The PHY should neither add the RX nor
TX delay in this case.
- rgmii-rxid: configures the PHY to enable the RX delay. The MAC should
not add the RX delay in this case.
- rgmii-txid: configures the PHY to enable the TX delay. The MAC should
not add the TX delay in this case.
- rgmii-id: combines rgmii-rxid and rgmii-txid and thus configures the
PHY to enable the RX and TX delays. The MAC should neither add the RX
nor TX delay in this case.Document these cases in the ethernet.txt documentation to make it clear
when to use each mode.
If applied incorrectly one might end up with MAC and PHY both enabling
for example the TX delay, which breaks ethernet TX traffic on 1000Mbit/s
links.Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
28 Nov, 2016
12 commits
-
Roi reported a crash in flower where tp->root was NULL in ->classify()
callbacks. Reason is that in ->destroy() tp->root is set to NULL via
RCU_INIT_POINTER(). It's problematic for some of the classifiers, because
this doesn't respect RCU grace period for them, and as a result, still
outstanding readers from tc_classify() will try to blindly dereference
a NULL tp->root.The tp->root object is strictly private to the classifier implementation
and holds internal data the core such as tc_ctl_tfilter() doesn't know
about. Within some classifiers, such as cls_bpf, cls_basic, etc, tp->root
is only checked for NULL in ->get() callback, but nowhere else. This is
misleading and seemed to be copied from old classifier code that was not
cleaned up properly. For example, d3fa76ee6b4a ("[NET_SCHED]: cls_basic:
fix NULL pointer dereference") moved tp->root initialization into ->init()
routine, where before it was part of ->change(), so ->get() had to deal
with tp->root being NULL back then, so that was indeed a valid case, after
d3fa76ee6b4a, not really anymore. We used to set tp->root to NULL long
ago in ->destroy(), see 47a1a1d4be29 ("pkt_sched: remove unnecessary xchg()
in packet classifiers"); but the NULLifying was reintroduced with the
RCUification, but it's not correct for every classifier implementation.In the cases that are fixed here with one exception of cls_cgroup, tp->root
object is allocated and initialized inside ->init() callback, which is always
performed at a point in time after we allocate a new tp, which means tp and
thus tp->root was not globally visible in the tp chain yet (see tc_ctl_tfilter()).
Also, on destruction tp->root is strictly kfree_rcu()'ed in ->destroy()
handler, same for the tp which is kfree_rcu()'ed right when we return
from ->destroy() in tcf_destroy(). This means, the head object's lifetime
for such classifiers is always tied to the tp lifetime. The RCU callback
invocation for the two kfree_rcu() could be out of order, but that's fine
since both are independent.Dropping the RCU_INIT_POINTER(tp->root, NULL) for these classifiers here
means that 1) we don't need a useless NULL check in fast-path and, 2) that
outstanding readers of that tp in tc_classify() can still execute under
respect with RCU grace period as it is actually expected.Things that haven't been touched here: cls_fw and cls_route. They each
handle tp->root being NULL in ->classify() path for historic reasons, so
their ->destroy() implementation can stay as is. If someone actually
cares, they could get cleaned up at some point to avoid the test in fast
path. cls_u32 doesn't set tp->root to NULL. For cls_rsvp, I just added a
!head should anyone actually be using/testing it, so it at least aligns with
cls_fw and cls_route. For cls_flower we additionally need to defer rhashtable
destruction (to a sleepable context) after RCU grace period as concurrent
readers might still access it. (Note that in this case we need to hold module
reference to keep work callback address intact, since we only wait on module
unload for all call_rcu()s to finish.)This fixes one race to bring RCU grace period guarantees back. Next step
as worked on by Cong however is to fix 1e052be69d04 ("net_sched: destroy
proto tp when all filters are gone") to get the order of unlinking the tp
in tc_ctl_tfilter() for the RTM_DELTFILTER case right by moving
RCU_INIT_POINTER() before tcf_destroy() and let the notification for
removal be done through the prior ->delete() callback. Both are independant
issues. Once we have that right, we can then clean tp->root up for a number
of classifiers by not making them RCU pointers, which requires a new callback
(->uninit) that is triggered from tp's RCU callback, where we just kfree()
tp->root from there.Fixes: 1f947bf151e9 ("net: sched: rcu'ify cls_bpf")
Fixes: 9888faefe132 ("net: sched: cls_basic use RCU")
Fixes: 70da9f0bf999 ("net: sched: cls_flow use RCU")
Fixes: 77b9900ef53a ("tc: introduce Flower classifier")
Fixes: bf3994d2ed31 ("net/sched: introduce Match-all classifier")
Fixes: 952313bd6258 ("net: sched: cls_cgroup use RCU")
Reported-by: Roi Dayan
Signed-off-by: Daniel Borkmann
Cc: Cong Wang
Cc: John Fastabend
Cc: Roi Dayan
Cc: Jiri Pirko
Acked-by: John Fastabend
Acked-by: Cong Wang
Signed-off-by: David S. Miller -
In commit e4bf4f76962b ("tipc: simplify packet sequence number
handling") we changed the internal representation of the packet
sequence number counters from u32 to u16, reflecting what is really
sent over the wire.Since then some link statistics counters have been displaying incorrect
values, partially because the counters meant to be used as sequence
number snapshots are now used as direct counters, stored as u32, and
partially because some counter updates are just missing in the code.In this commit we correct this in two ways. First, we base the
displayed packet sent/received values on direct counters instead
of as previously a calculated difference between current sequence
number and a snapshot. Second, we add the missing updates of the
counters.This change is compatible with the current netlink API, and requires
no changes to the user space tools.Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller -
Steffen Klassert says:
====================
pull request (net): ipsec 2016-11-251) Fix a refcount leak in vti6.
From Nicolas Dichtel.2) Fix a wrong if statement in xfrm_sk_policy_lookup.
From Florian Westphal.3) The flowcache watermarks are per cpu. Take this into
account when comparing to the threshold where we
refusing new allocations. From Miroslav Urbanek.Please pull or let me know if there are problems.
====================Signed-off-by: David S. Miller
-
The macvtap_newlink registers the netdev rx_handler firstly, but it
does not unregister the handler if macvlan_common_newlink failed.Signed-off-by: Gao Feng
Acked-by: Jason Wang
Signed-off-by: David S. Miller -
Johan Hovold says:
====================
net: fix phydev reference leaksThis series fixes a number of phydev reference leaks (and one of_node
leak) due to failure to put the reference taken by of_phy_find_device().Note that I did not try to fix drivers/net/phy/xilinx_gmii2rgmii.c which
still leaks a reference.Against net but should apply just as fine to net-next.
v2:
- use put_device() instead of phy_dev_free() to put the references
taken in net/dsa (patch 1/4).
- add four new patches fixing similar leaks
====================Signed-off-by: David S. Miller
-
Make sure to drop the reference taken by of_phy_find_device() during
probe on probe errors and on driver unbind.Also drop the of_node reference taken by of_parse_phandle() in the same
path.Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
Signed-off-by: Johan Hovold
Signed-off-by: David S. Miller -
Make sure to drop the reference taken by of_phy_find_device() when
looking up a fixed-link phydev during probe.Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
Signed-off-by: Johan Hovold
Signed-off-by: David S. Miller -
Make sure to drop the reference taken by of_phy_find_device() during
initialisation when later freeing the struct fman_mac.Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
Signed-off-by: Johan Hovold
Signed-off-by: David S. Miller -
Make sure to drop the reference taken by of_phy_find_device() when
initialising MOCA PHYs.Fixes: 6ac9de5f6563 ("net: bcmgenet: Register link_update callback for
all MoCA PHYs")
Signed-off-by: Johan Hovold
Signed-off-by: David S. Miller -
Make sure to drop the reference taken by of_phy_find_device() when
registering and deregistering the fixed-link PHY-device.Fixes: 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port
speeds/duplex")
Signed-off-by: Johan Hovold
Signed-off-by: David S. Miller -
irda_get_mtt() returns a hardcoded '10000' in some cases,
and with gcc-7, we get a build error because this triggers a
compile-time check in udelay():drivers/net/irda/w83977af_ir.o: In function `w83977af_hard_xmit':
w83977af_ir.c:(.text.w83977af_hard_xmit+0x14c): undefined reference to `__bad_udelay'Older compilers did not run into this because they either did not
completely inline the irda_get_mtt() or did not consider the
10000 value a constant expression.The code has been wrong since the start of git history.
Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller -
When ipvlan_link_new fails and creates one ipvlan port, it does not
destroy the ipvlan port created. It causes mem leak and the physical
device contains invalid ipvlan data.Signed-off-by: Gao Feng
Signed-off-by: David S. Miller
27 Nov, 2016
8 commits
-
Pull vfs splice fix from Al Viro.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fix default_file_splice_read() -
Botched calculation of number of pages. As the result,
we were dropping pieces when doing splice to pipe from
e.g. 9p.Reported-by: Alexei Starovoitov
Tested-by: Alexei Starovoitov
Signed-off-by: Al Viro -
Pull i2c fixes from Wolfram Sang:
"Here is a revert and two bugfixes for the I2C designware driver.Please note that we are still hunting down a regression for the
i2c-octeon driver. While there is a fix pending, we have unclear
feedback from the testers currently. An rc8 would be quite helpful
for this case"* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
Revert "i2c: designware: do not disable adapter after transfer"
i2c: designware: fix rx fifo depth tracking
i2c: designware: report short transfers -
Pull ARM fix from Russell King:
"This resolves the ksyms issues by reverting the commit which
introduced the breakage"There was what I consider to be a better fix, but it's late in the rc
game, so I'll take the revert.* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
Revert "arm: move exports to definitions" -
Pull networking fixes from David Miller:
1) Fix leak in fsl/fman driver, from Dan Carpenter.
2) Call flow dissector initcall earlier than any networking driver can
register and start to use it, from Eric Dumazet.3) Some dup header fixes from Geliang Tang.
4) TIPC link monitoring compat fix from Jon Paul Maloy.
5) Link changes require EEE re-negotiation in bcm_sf2 driver, from
Florian Fainelli.6) Fix bogus handle ID passed into tfilter_notify_chain(), from Roman
Mashak.7) Fix dump size calculation in rtnl_calcit(), from Zhang Shengju.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (26 commits)
tipc: resolve connection flow control compatibility problem
mvpp2: use correct size for memset
net/mlx5: drop duplicate header delay.h
net: ieee802154: drop duplicate header delay.h
ibmvnic: drop duplicate header seq_file.h
fsl/fman: fix a leak in tgec_free()
net: ethtool: don't require CAP_NET_ADMIN for ETHTOOL_GLINKSETTINGS
tipc: improve sanity check for received domain records
tipc: fix compatibility bug in link monitoring
net: ethernet: mvneta: Remove IFF_UNICAST_FLT which is not implemented
dwc_eth_qos: drop duplicate headers
net sched filters: fix filter handle ID in tfilter_notify_chain()
net: dsa: bcm_sf2: Ensure we re-negotiate EEE during after link change
bnxt: do not busy-poll when link is down
udplite: call proper backlog handlers
ipv6: bump genid when the IFA_F_TENTATIVE flag is clear
net/mlx4_en: Free netdev resources under state lock
net: revert "net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit"
rtnetlink: fix the wrong minimal dump size getting from rtnl_calcit()
bnxt_en: Fix a VXLAN vs GENEVE issue
... -
Pull libnvdimm fixes from Dan Williams:
- Fix a crash that occurs at driver initialization if the memory region
is already busy (request_mem_region() fails).- Fix a vma validation check that mistakenly allows a private device-
dax mapping to be established. Device-dax explicitly forbids private
mappings so it can guarantee a given fault granularity and backing
memory type.Both of these fixes have soaked in -next and are tagged for -stable.
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
device-dax: fail all private mapping attempts
device-dax: check devm_nsio_enable() return value -
Pull KVM fixes from Radim Krčmář:
"Four fixes for bugs found by syzkaller on x86, all for stable"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: check for pic and ioapic presence before use
KVM: x86: fix out-of-bounds accesses of rtc_eoi map
KVM: x86: drop error recovery in em_jmp_far and em_ret_far
KVM: x86: fix out-of-bounds access in lapic -
Pull powerpc fixes from Michael Ellerman:
"Fixes marked for stable:
- Set missing wakeup bit in LPCR on POWER9
- Fix the early OPAL console wrappers
- Fixup kernel read only mappingFixes for code merged this cycle:
- Fix missing CRCs, add more asm-prototypes.h declarations"* tag 'powerpc-4.9-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/mm: Fixup kernel read only mapping
powerpc/boot: Fix the early OPAL console wrappers
powerpc: Fix missing CRCs, add more asm-prototypes.h declarations
powerpc: Set missing wakeup bit in LPCR on POWER9
26 Nov, 2016
16 commits
-
In commit 10724cc7bb78 ("tipc: redesign connection-level flow control")
we replaced the previous message based flow control with one based on
1k blocks. In order to ensure backwards compatibility the mechanism
falls back to using message as base unit when it senses that the peer
doesn't support the new algorithm. The default flow control window,
i.e., how many units can be sent before the sender blocks and waits
for an acknowledge (aka advertisement) is 512. This was tested against
the previous version, which uses an acknowledge frequency of on ack per
256 received message, and found to work fine.However, we missed the fact that versions older than Linux 3.15 use an
acknowledge frequency of 512, which is exactly the limit where a 4.6+
sender will stop and wait for acknowledge. This would also work fine if
it weren't for the fact that if the first sent message on a 4.6+ server
side is an empty SYNACK, this one is also is counted as a sent message,
while it is not counted as a received message on a legacy 3.15-receiver.
This leads to the sender always being one step ahead of the receiver, a
scenario causing the sender to block after 512 sent messages, while the
receiver only has registered 511 read messages. Hence, the legacy
receiver is not trigged to send an acknowledge, with a permanently
blocked sender as result.We solve this deadlock by simply allowing the sender to send one more
message before it blocks, i.e., by a making minimal change to the
condition used for determining connection congestion.Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller -
gcc-7 detects a short memset in mvpp2, introduced in the original
merge of the driver:drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_cls_init':
drivers/net/ethernet/marvell/mvpp2.c:3296:2: error: 'memset' used with length equal to number of elements without multiplication by element size [-Werror=memset-elt-size]The result seems to be that we write uninitialized data into the
flow table registers, although we did not get any warning about
that uninitialized data usage.Using sizeof() lets us initialize then entire array instead.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller -
Drop duplicate header delay.h from mlx5/core/main.c.
Signed-off-by: Geliang Tang
Acked-by: Matan Barak
Acked-by: Saeed Mahameed
Signed-off-by: David S. Miller -
Drop duplicate header delay.h from adf7242.c.
Signed-off-by: Geliang Tang
Acked-by: Stefan Schmidt
Signed-off-by: David S. Miller -
Drop duplicate header seq_file.h from ibmvnic.c.
Signed-off-by: Geliang Tang
Signed-off-by: David S. Miller -
We set "tgec->cfg" to NULL before passing it to kfree(). There is no
need to set it to NULL at all. Let's just delete it.Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller -
The ETHTOOL_GLINKSETTINGS command is deprecating the ETHTOOL_GSET
command and likewise it shouldn't require the CAP_NET_ADMIN capability.Signed-off-by: Miroslav Lichvar
Signed-off-by: David S. Miller -
In commit 35c55c9877f8 ("tipc: add neighbor monitoring framework") we
added a data area to the link monitor STATE messages under the
assumption that previous versions did not use any such data area.For versions older than Linux 4.3 this assumption is not correct. In
those version, all STATE messages sent out from a node inadvertently
contain a 16 byte data area containing a string; -a leftover from
previous RESET messages which were using this during the setup phase.
This string serves no purpose in STATE messages, and should no be there.Unfortunately, this data area is delivered to the link monitor
framework, where a sanity check catches that it is not a correct domain
record, and drops it. It also issues a rate limited warning about the
event.Since such events occur much more frequently than anticipated, we now
choose to remove the warning in order to not fill the kernel log with
useless contents. We also make the sanity check stricter, to further
reduce the risk that such data is inavertently admitted.Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller -
commit 817298102b0b ("tipc: fix link priority propagation") introduced a
compatibility problem between TIPC versions newer than Linux 4.6 and
those older than Linux 4.4. In versions later than 4.4, link STATE
messages only contain a non-zero link priority value when the sender
wants the receiver to change its priority. This has the effect that the
receiver resets itself in order to apply the new priority. This works
well, and is consistent with the said commit.However, in versions older than 4.4 a valid link priority is present in
all sent link STATE messages, leading to cyclic link establishment and
reset on the 4.6+ node.We fix this by adding a test that the received value should not only
be valid, but also differ from the current value in order to cause the
receiving link endpoint to reset.Reported-by: Amar Nv
Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller -
The mvneta driver advertises it supports IFF_UNICAST_FLT. However, it
actually does not. The hardware probably does support it, but there is
no code to configure the filter. As a quick and simple fix, remove the
flag. This will cause the core to fall back to promiscuous mode.Signed-off-by: Andrew Lunn
Fixes: b50b72de2f2f ("net: mvneta: enable features before registering the driver")
Signed-off-by: David S. Miller -
Pull parisc fixes from Helge Deller:
"On parisc we were still seeing occasional random segmentation faults
and memory corruption on SMP machines. Dave Anglin then looked again
at the TLB related code and found two issues in the PCI DMA and
generic TLB flush functions.Then, in our startup code we had some timing of the cache and TLB
functions to calculate a threshold when to use a complete TLB/cache
flush or just to flush a specific range. This code produced a race
with newly started CPUs and thus lead to occasional kernel crashes
(due to stale TLB/cache entries). The patch by Dave fixes this issue
by flushing the local caches before starting secondary CPUs and by
removing the race.The last problem fixed by this series is that we quite often suffered
from hung tasks and self-detected stalls on the CPUs. It was somehow
clear that this was related to the (in v4.7) newly introduced cr16
clocksource and the own implementation of sched_clock(). I replaced
the open-coded sched_clock() function and switched to the generic
sched_clock() implementation which seems to have fixed this isse as
well.All patches have been sucessfully tested on a variety of machines,
including our debian buildd servers.All patches (beside the small pr_cont fix) are tagged for stable
releases"* 'parisc-4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Also flush data TLB in flush_icache_page_asm
parisc: Fix race in pci-dma.c
parisc: Switch to generic sched_clock implementation
parisc: Fix races in parisc_setup_cache_timing()
parisc: Fix printk continuations in system detection -
Pull keys fixes from James Morris:
"From David:- Fix mpi_powm()'s handling of a number with a zero exponent
[CVE-2016-8650].Integrate my and Andrey's patches for mpi_powm() and use
mpi_resize() instead of RESIZE_IF_NEEDED() - the latter adds a
duplicate check into the execution path of a trivial case we
don't normally expect to be taken.- Fix double free in X.509 error handling"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]
X.509: Fix double free in x509_cert_parse() [ver #3] -
CONFIG_MODVERSIONS has been broken for pretty much the whole 4.9 series,
and quite frankly, nobody has cared very deeply. We absolutely know how
to fix it, and it's not _complicated_, but it's not exactly pretty
either.This oneliner fixes it without the ugliness, and allows for further
future cleanups."We've secretly replaced their regular MODVERSIONS with nothing at
all, let's see if they notice"Signed-off-by: Linus Torvalds
-
Pull ACPI fixes from Rafael Wysocki:
"Two ACPI fixes for 4.9-rc7.One of them reverts a recent ACPI commit that attempted to improve
reboot/power-off on some systems, but introduced problems elsewhere,
and the other one fixes kernel builds with the new WDAT watchdog
driver enabled in some configurations.Specifics:
- Revert the recent commit that caused the ACPI _PTS method to be
executed in the power-off/reboot code path (as per the
specification) in an attempt to improve things on some systems
(apparently expecting _PTS to be executed in that code path), but
broke power-off/reboot on at least one other machine (Rafael
Wysocki).- Fix kernel builds with the new WDAT watchdog driver enabled in some
configurations by explicitly selecting WATCHDOG_CORE when enabling
the WDAT watchdog driver (Mika Westerberg)"* tag 'acpi-4.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
watchdog: wdat_wdt: Select WATCHDOG_CORE
Revert "ACPI: Execute _PTS before system reboot" -
Following the kernel Bugzilla discussion during the Kernel Summit
(https://lwn.net/Articles/705245/), add bug tracking system location
entry type (B) to MAINTAINERS and populate it for several subsystems
known to be using the kernel BZ actively (and add the upstream BZ for
ACPICA too).Signed-off-by: Rafael J. Wysocki
Signed-off-by: Linus Torvalds -
This reverts commit 0317e6c0f1dc1ba86b8d9dccc010c5e77b8355fa.
Srinivas reported recently touchscreen and touchpad stopped working in
Haswell based machine in Linux 4.9-rc series with timeout errors from
i2c_designware:[ 16.508013] i2c_designware INT33C3:00: controller timed out
[ 16.508302] i2c_hid i2c-MSFT0001:02: failed to change power setting.
[ 17.532016] i2c_designware INT33C3:00: controller timed out
[ 18.556022] i2c_designware INT33C3:00: controller timed out
[ 18.556315] i2c_hid i2c-ATML1000:00: failed to retrieve report from device.I managed to reproduce similar errors on another Haswell based machine
where touchscreen initialization fails maybe in every 1/5 - 1/2 boots.
Since root cause for these errors is not clear yet and debugging is
ongoing it's better to revert this commit as we are near to release.Reported-by: Srinivas Pandruvada
Signed-off-by: Jarkko Nikula
Signed-off-by: Wolfram Sang
