* [PATCH 4.8 091/138] Input: i8042 - add XMG C504 to keyboard reset table
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Patrick Scheuring, Dmitry Torokhov
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.
The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
Therefore it also needs a keyboard reset to detect the Elantech touchpad.
Otherwise the touchpad appears to be dead.
With this patch the touchpad is detected:
$ dmesg | grep -E "(i8042|Elantech|elantech)"
[ 2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[ 2.680372] i8042: Attempting to reset device connected to KBD port
[ 2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[ 3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
[ 3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.
[ 3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[ 3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6
Signed-off-by: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -877,6 +877,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
},
},
+ {
+ /* Schenker XMG C504 - Elantech touchpad */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
+ },
+ },
{ }
};
^ permalink raw reply
* Re: [PATCH v1 2/2] depmod: ignore related modules in depmod_report_cycles
From: Yauheni Kaliuta @ 2016-11-09 11:23 UTC (permalink / raw)
To: Mian Yousaf Kaukab
Cc: linux-modules, bjorn.andersson, afaerber, lucas.de.marchi
In-Reply-To: <1478683053.4155.8.camel@suse.com>
Hi, Mian!
>>>>> On Wed, 09 Nov 2016 10:17:33 +0100, Mian Yousaf Kaukab wrote:
> On Wed, 2016-11-09 at 04:59 +0200, Yauheni Kaliuta wrote:
[...]
>> The problem is that the path is recorded "globally", not per vertex,
>> and "wrong" mod6 is compared in "loop == m".
> I agree and in the other thread Bjorn is mentioning kind of the same.
Ah, sorry, my bad: I just subscribed to the actual mailing list and Gmane
has the latest message from July.
--
WBR,
Yauheni Kaliuta
^ permalink raw reply
* [PATCH 4.8 093/138] firewire: net: fix fragmented datagram_size off-by-one
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Stefan Richter
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firewire/net.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -73,13 +73,13 @@ struct rfc2734_header {
#define fwnet_get_hdr_lf(h) (((h)->w0 & 0xc0000000) >> 30)
#define fwnet_get_hdr_ether_type(h) (((h)->w0 & 0x0000ffff))
-#define fwnet_get_hdr_dg_size(h) (((h)->w0 & 0x0fff0000) >> 16)
+#define fwnet_get_hdr_dg_size(h) ((((h)->w0 & 0x0fff0000) >> 16) + 1)
#define fwnet_get_hdr_fg_off(h) (((h)->w0 & 0x00000fff))
#define fwnet_get_hdr_dgl(h) (((h)->w1 & 0xffff0000) >> 16)
-#define fwnet_set_hdr_lf(lf) ((lf) << 30)
+#define fwnet_set_hdr_lf(lf) ((lf) << 30)
#define fwnet_set_hdr_ether_type(et) (et)
-#define fwnet_set_hdr_dg_size(dgs) ((dgs) << 16)
+#define fwnet_set_hdr_dg_size(dgs) (((dgs) - 1) << 16)
#define fwnet_set_hdr_fg_off(fgo) (fgo)
#define fwnet_set_hdr_dgl(dgl) ((dgl) << 16)
@@ -622,7 +622,7 @@ static int fwnet_incoming_packet(struct
fg_off = fwnet_get_hdr_fg_off(&hdr);
}
datagram_label = fwnet_get_hdr_dgl(&hdr);
- dg_size = fwnet_get_hdr_dg_size(&hdr); /* ??? + 1 */
+ dg_size = fwnet_get_hdr_dg_size(&hdr);
if (fg_off + len > dg_size)
return 0;
^ permalink raw reply
* [PATCH 4.8 092/138] firewire: net: guard against rx buffer overflows
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Eyal Itkin, Stefan Richter
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
commit 667121ace9dbafb368618dbabcf07901c962ddac upstream.
The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams. A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.
So, drop any packets carrying a fragment with offset + length larger
than datagram_size.
In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment
encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.
Reported-by: Eyal Itkin <eyal.itkin@gmail.com>
Reviewed-by: Eyal Itkin <eyal.itkin@gmail.com>
Fixes: CVE 2016-8633
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firewire/net.c | 51 +++++++++++++++++++++++++++++++++----------------
1 file changed, 35 insertions(+), 16 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -578,6 +578,9 @@ static int fwnet_incoming_packet(struct
int retval;
u16 ether_type;
+ if (len <= RFC2374_UNFRAG_HDR_SIZE)
+ return 0;
+
hdr.w0 = be32_to_cpu(buf[0]);
lf = fwnet_get_hdr_lf(&hdr);
if (lf == RFC2374_HDR_UNFRAG) {
@@ -602,7 +605,12 @@ static int fwnet_incoming_packet(struct
return fwnet_finish_incoming_packet(net, skb, source_node_id,
is_broadcast, ether_type);
}
+
/* A datagram fragment has been received, now the fun begins. */
+
+ if (len <= RFC2374_FRAG_HDR_SIZE)
+ return 0;
+
hdr.w1 = ntohl(buf[1]);
buf += 2;
len -= RFC2374_FRAG_HDR_SIZE;
@@ -616,6 +624,9 @@ static int fwnet_incoming_packet(struct
datagram_label = fwnet_get_hdr_dgl(&hdr);
dg_size = fwnet_get_hdr_dg_size(&hdr); /* ??? + 1 */
+ if (fg_off + len > dg_size)
+ return 0;
+
spin_lock_irqsave(&dev->lock, flags);
peer = fwnet_peer_find_by_node_id(dev, source_node_id, generation);
@@ -722,6 +733,22 @@ static void fwnet_receive_packet(struct
fw_send_response(card, r, rcode);
}
+static int gasp_source_id(__be32 *p)
+{
+ return be32_to_cpu(p[0]) >> 16;
+}
+
+static u32 gasp_specifier_id(__be32 *p)
+{
+ return (be32_to_cpu(p[0]) & 0xffff) << 8 |
+ (be32_to_cpu(p[1]) & 0xff000000) >> 24;
+}
+
+static u32 gasp_version(__be32 *p)
+{
+ return be32_to_cpu(p[1]) & 0xffffff;
+}
+
static void fwnet_receive_broadcast(struct fw_iso_context *context,
u32 cycle, size_t header_length, void *header, void *data)
{
@@ -731,9 +758,6 @@ static void fwnet_receive_broadcast(stru
__be32 *buf_ptr;
int retval;
u32 length;
- u16 source_node_id;
- u32 specifier_id;
- u32 ver;
unsigned long offset;
unsigned long flags;
@@ -750,22 +774,17 @@ static void fwnet_receive_broadcast(stru
spin_unlock_irqrestore(&dev->lock, flags);
- specifier_id = (be32_to_cpu(buf_ptr[0]) & 0xffff) << 8
- | (be32_to_cpu(buf_ptr[1]) & 0xff000000) >> 24;
- ver = be32_to_cpu(buf_ptr[1]) & 0xffffff;
- source_node_id = be32_to_cpu(buf_ptr[0]) >> 16;
-
- if (specifier_id == IANA_SPECIFIER_ID &&
- (ver == RFC2734_SW_VERSION
+ if (length > IEEE1394_GASP_HDR_SIZE &&
+ gasp_specifier_id(buf_ptr) == IANA_SPECIFIER_ID &&
+ (gasp_version(buf_ptr) == RFC2734_SW_VERSION
#if IS_ENABLED(CONFIG_IPV6)
- || ver == RFC3146_SW_VERSION
+ || gasp_version(buf_ptr) == RFC3146_SW_VERSION
#endif
- )) {
- buf_ptr += 2;
- length -= IEEE1394_GASP_HDR_SIZE;
- fwnet_incoming_packet(dev, buf_ptr, length, source_node_id,
+ ))
+ fwnet_incoming_packet(dev, buf_ptr + 2,
+ length - IEEE1394_GASP_HDR_SIZE,
+ gasp_source_id(buf_ptr),
context->card->generation, true);
- }
packet.payload_length = dev->rcv_buffer_size;
packet.interrupt = 1;
^ permalink raw reply
* [PATCH 4.8 059/138] vt: clear selection before resizing
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Scot Doyle
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Scot Doyle <lkml14@scotdoyle.com>
commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream.
When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.
[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -874,6 +874,9 @@ static int vc_do_resize(struct tty_struc
if (!newscreen)
return -ENOMEM;
+ if (vc == sel_cons)
+ clear_selection();
+
old_rows = vc->vc_rows;
old_row_size = vc->vc_size_row;
^ permalink raw reply
* [PATCH 4.8 061/138] xhci: add restart quirk for Intel Wildcatpoint PCH
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hasan Mahmood, Mathias Nyman
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit 4c39135aa412d2f1381e43802523da110ca7855c upstream.
xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
same quirks to prevent machines from spurious restart while
shutting them down.
Reported-by: Hasan Mahmood <hasan.mahm@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -45,6 +45,7 @@
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI 0x8c31
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI 0x9c31
+#define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI 0x9cb1
#define PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI 0x22b5
#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI 0xa12f
#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
@@ -153,7 +154,8 @@ static void xhci_pci_quirks(struct devic
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
- pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
+ (pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI)) {
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
}
^ permalink raw reply
* [PATCH 4.8 058/138] x86/smpboot: Init apic mapping before usage
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, prarit, ville.syrjala, michael.thayer,
knut.osmundsen, frank.mehnert, Borislav Petkov, Thomas Gleixner
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 1e90a13d0c3dc94512af1ccb2b6563e8297838fa upstream.
The recent changes, which forced the registration of the boot cpu on UP
systems, which do not have ACPI tables, have been fixed for systems w/o
local APIC, but left a wreckage for systems which have neither ACPI nor
mptables, but the CPU has an APIC, e.g. virtualbox.
The boot process crashes in prefill_possible_map() as it wants to register
the boot cpu, which needs to access the local apic, but the local APIC is
not yet mapped.
There is no reason why init_apic_mapping() can't be invoked before
prefill_possible_map(). So instead of playing another silly early mapping
game, as the ACPI/mptables code does, we just move init_apic_mapping()
before the call to prefill_possible_map().
In hindsight, I should have noticed that combination earlier.
Sorry for the churn (also in stable)!
Fixes: ff8560512b8d ("x86/boot/smp: Don't try to poke disabled/non-existent APIC")
Reported-and-debugged-by: Michal Necasek <michal.necasek@oracle.com>
Reported-and-tested-by: Wolfgang Bauer <wbauer@tmo.at>
Cc: prarit@redhat.com
Cc: ville.syrjala@linux.intel.com
Cc: michael.thayer@oracle.com
Cc: knut.osmundsen@oracle.com
Cc: frank.mehnert@oracle.com
Cc: Borislav Petkov <bp@alien8.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610282114380.5053@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/setup.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1222,11 +1222,16 @@ void __init setup_arch(char **cmdline_p)
if (smp_found_config)
get_smp_config();
+ /*
+ * Systems w/o ACPI and mptables might not have it mapped the local
+ * APIC yet, but prefill_possible_map() might need to access it.
+ */
+ init_apic_mappings();
+
prefill_possible_map();
init_cpu_to_node();
- init_apic_mappings();
io_apic_init_mappings();
kvm_guest_init();
^ permalink raw reply
* [PATCH] pinctrl: intel: Configure pin as GPIO input when used directly through irqchip
From: Mika Westerberg @ 2016-11-09 11:22 UTC (permalink / raw)
To: Linus Walleij; +Cc: Jarkko Nikula, Heikki Krogerus, linux-gpio, Mika Westerberg
If a pin is used directly through irqchip without requesting it first as
GPIO, it might be in wrong mode (for example input buffer disabled). This
means the user may never get any interrupts.
Fix this by configuring the pin as GPIO input when its type is first set in
irq_set_type().
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
Since we probably need to do this for cherryview and baytrail pinctrl
drivers as well, I'm thinking is this something that the GPIO core could do
automatically?
drivers/pinctrl/intel/pinctrl-intel.c | 46 +++++++++++++++++++++++------------
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 01443762e570..a1a5e2a77f9e 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -353,6 +353,23 @@ static int intel_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned function,
return 0;
}
+/* Called with pctrl->lock held */
+static void intel_gpio_set_gpio_mode(struct intel_pinctrl *pctrl,
+ void __iomem *padcfg0)
+{
+ u32 value;
+
+ /* Put the pad into GPIO mode */
+ value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
+ /* Disable SCI/SMI/NMI generation */
+ value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
+ value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
+ /* Disable TX buffer and enable RX (this will be input) */
+ value &= ~PADCFG0_GPIORXDIS;
+ value |= PADCFG0_GPIOTXDIS;
+ writel(value, padcfg0);
+}
+
static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin)
@@ -360,29 +377,26 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
void __iomem *padcfg0;
unsigned long flags;
- u32 value;
+ int ret = 0;
raw_spin_lock_irqsave(&pctrl->lock, flags);
if (!intel_pad_usable(pctrl, pin)) {
- raw_spin_unlock_irqrestore(&pctrl->lock, flags);
- return -EBUSY;
+ ret = -EBUSY;
+ goto out;
}
padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
- /* Put the pad into GPIO mode */
- value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
- /* Disable SCI/SMI/NMI generation */
- value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
- value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
- /* Disable TX buffer and enable RX (this will be input) */
- value &= ~PADCFG0_GPIORXDIS;
- value |= PADCFG0_GPIOTXDIS;
- writel(value, padcfg0);
+ if (!padcfg0) {
+ ret = -EINVAL;
+ goto out;
+ }
+ /* Set to GPIO input */
+ intel_gpio_set_gpio_mode(pctrl, padcfg0);
+out:
raw_spin_unlock_irqrestore(&pctrl->lock, flags);
-
- return 0;
+ return ret;
}
static int intel_gpio_set_direction(struct pinctrl_dev *pctldev,
@@ -762,8 +776,10 @@ static int intel_gpio_irq_type(struct irq_data *d, unsigned type)
raw_spin_lock_irqsave(&pctrl->lock, flags);
- value = readl(reg);
+ /* Make sure the pin is GPIO input */
+ intel_gpio_set_gpio_mode(pctrl, reg);
+ value = readl(reg);
value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
if ((type & IRQ_TYPE_EDGE_BOTH) == IRQ_TYPE_EDGE_BOTH) {
--
2.9.3
^ permalink raw reply related
* [PATCH 4.8 060/138] hv: do not lose pending heartbeat vmbus packets
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Long Li, K. Y. Srinivasan
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Long Li <longli@microsoft.com>
commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream.
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hv/hv_util.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -283,10 +283,14 @@ static void heartbeat_onchannelcallback(
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
- PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+ PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
^ permalink raw reply
* [PATCH 4.8 063/138] tty: limit terminal size to 4M chars
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Vyukov, David Rientjes,
One Thousand Gnomes, Jiri Slaby, Peter Hurley, syzkaller
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Vyukov <dvyukov@google.com>
commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream.
Size of kmalloc() in vc_do_resize() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Put a reasonable upper bound on terminal size to prevent WARNINGs.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
CC: David Rientjes <rientjes@google.com>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -870,6 +870,8 @@ static int vc_do_resize(struct tty_struc
if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
return 0;
+ if (new_screen_size > (4 << 20))
+ return -EINVAL;
newscreen = kmalloc(new_screen_size, GFP_USER);
if (!newscreen)
return -ENOMEM;
^ permalink raw reply
* Re: [RFC] fs: add userspace critical mounts event support
From: Andy Lutomirski @ 2016-11-09 11:21 UTC (permalink / raw)
To: Daniel Wagner
Cc: Luis R. Rodriguez, Linus Torvalds, Jiri Kosina, Johannes Berg,
Jouni Malinen, Seth Forshee, Tom Gundersen, Kay Sievers,
Bjorn Andersson, Daniel Wagner, Rafael J. Wysocki, Herbert, Marc,
Daniel Vetter, Rob Landley, Mimi Zohar, Felix Fietkau,
David Woodhouse, Roman Pen, Ming Lei, Andrew Morton, Michal Marek,
Greg KH, Linux Kernel Mailing List, Vikram Mulukutla,
Stephen Boyd, Mark Brown, Takashi Iwai, Christian Lamparter,
Hauke Mehrtens, Josh Boyer, Dmitry Torokhov, Jiri Slaby,
Wu Fengguang, Richard Purdie, Jeff Mahoney, Jacek Anaszewski,
Abhay_Salunke, Julia Lawall, Gilles.Muller, nicolas.palix,
David Howells, Alessandro Rubini, Kevin Cernekee, Kees Cook,
Jonathan Corbet, Thierry Martinez, linux-serial,
open list:DOCUMENTATION, linuxppc-dev, Josh Triplett,
Harald Hoyer
In-Reply-To: <cdd43459-346f-c8e9-e8fc-25bd81e9f0ea@bmw-carit.de>
On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
<daniel.wagner@bmw-carit.de> wrote:
> [CC: added Harald]
>
> As Harald pointed out over a beer yesterday evening, there is at least
> one more reason why UMH isn't obsolete. The ordering of the firmware loading
> might be of important. Say you want to greet the user with a splash screen
> really early on, the graphic card firmware should be loaded first. Also the
> automotive world has this fancy requirement that rear camera must be on the
> screen within 2 seconds. So controlling the firmware loading order is of
> importance (e.g. also do not overcommit the I/O bandwith not so important
> firmwares). A user space helper is able to prioritize the request
> accordingly the use case.
That seems like a valid problem, but I don't think that UMH adequately
solves it. Sure, loading firmware in the right order avoids a >2sec
delay due to firmware loading, but what happens when you have a slow
USB device that *doesn't* need firmware plugged in to your car's shiny
USB port when you start the car?
It seems to me that this use case requires explicit control over
device probing and, if that gets added, you get your firmware ordering
for free (just probe the important devices first).
--Andy
^ permalink raw reply
* Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable
From: Pavel Machek @ 2016-11-09 11:21 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: linux-leds, linux-kernel, Hans de Goede
In-Reply-To: <1478688226-4158-1-git-send-email-j.anaszewski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On Wed 2016-11-09 11:43:46, Jacek Anaszewski wrote:
> LED class heartbeat trigger allowed only for blinking with max_brightness
> value. This patch adds more flexibility by exploiting part of LED core
> software blink infrastructure.
>
> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [RFC] fs: add userspace critical mounts event support
From: Andy Lutomirski @ 2016-11-09 11:21 UTC (permalink / raw)
To: Daniel Wagner
Cc: Dmitry Torokhov, open list:DOCUMENTATION, Gilles.Muller,
Takashi Iwai, Daniel Wagner, Ming Lei, Stephen Boyd, Kay Sievers,
Bjorn Andersson, Tom Gundersen, Alessandro Rubini,
Christian Lamparter, Josh Boyer, Jonathan Corbet, Kevin Cernekee,
Jacek Anaszewski, Thierry Martinez, linux-serial, Daniel Vetter,
Mimi Zohar, David Woodhouse, Jeff Mahoney, Kees Cook, Jouni
In-Reply-To: <cdd43459-346f-c8e9-e8fc-25bd81e9f0ea@bmw-carit.de>
On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
<daniel.wagner@bmw-carit.de> wrote:
> [CC: added Harald]
>
> As Harald pointed out over a beer yesterday evening, there is at least
> one more reason why UMH isn't obsolete. The ordering of the firmware loading
> might be of important. Say you want to greet the user with a splash screen
> really early on, the graphic card firmware should be loaded first. Also the
> automotive world has this fancy requirement that rear camera must be on the
> screen within 2 seconds. So controlling the firmware loading order is of
> importance (e.g. also do not overcommit the I/O bandwith not so important
> firmwares). A user space helper is able to prioritize the request
> accordingly the use case.
That seems like a valid problem, but I don't think that UMH adequately
solves it. Sure, loading firmware in the right order avoids a >2sec
delay due to firmware loading, but what happens when you have a slow
USB device that *doesn't* need firmware plugged in to your car's shiny
USB port when you start the car?
It seems to me that this use case requires explicit control over
device probing and, if that gets added, you get your firmware ordering
for free (just probe the important devices first).
--Andy
^ permalink raw reply
* [PATCH 4.8 054/138] xhci: use default USB_RESUME_TIMEOUT when resuming ports.
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mathias Nyman
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 upstream.
USB2 host inititated resume, and system suspend bus resume
need to use the same USB_RESUME_TIMEOUT as elsewhere.
This resolves a device disconnect issue at system resume seen
on Intel Braswell and Apollolake, but is in no way limited to
those platforms.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1166,7 +1166,7 @@ int xhci_hub_control(struct usb_hcd *hcd
xhci_set_link_state(xhci, port_array, wIndex,
XDEV_RESUME);
spin_unlock_irqrestore(&xhci->lock, flags);
- msleep(20);
+ msleep(USB_RESUME_TIMEOUT);
spin_lock_irqsave(&xhci->lock, flags);
xhci_set_link_state(xhci, port_array, wIndex,
XDEV_U0);
@@ -1410,7 +1410,7 @@ int xhci_bus_resume(struct usb_hcd *hcd)
if (need_usb2_u3_exit) {
spin_unlock_irqrestore(&xhci->lock, flags);
- msleep(20);
+ msleep(USB_RESUME_TIMEOUT);
spin_lock_irqsave(&xhci->lock, flags);
}
^ permalink raw reply
* [PATCH 4.8 095/138] Revert "ath9k_hw: implement temperature compensation support for AR9003+"
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Felix Fietkau, Kalle Valo
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <nbd@nbd.name>
commit 304e5ac118cc351eb047b6c433a89e13ea7259cf upstream.
This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation
support for AR9003+"). Some users report that this commit causes a regression
in performance under some conditions.
Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 25 +++----------------------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
2 files changed, 3 insertions(+), 23 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -33,7 +33,6 @@ struct coeff {
enum ar9003_cal_types {
IQ_MISMATCH_CAL = BIT(0),
- TEMP_COMP_CAL = BIT(1),
};
static void ar9003_hw_setup_calibration(struct ath_hw *ah,
@@ -59,12 +58,6 @@ static void ar9003_hw_setup_calibration(
/* Kick-off cal */
REG_SET_BIT(ah, AR_PHY_TIMING4, AR_PHY_TIMING4_DO_CAL);
break;
- case TEMP_COMP_CAL:
- ath_dbg(common, CALIBRATE,
- "starting Temperature Compensation Calibration\n");
- REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_LOCAL);
- REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_START);
- break;
default:
ath_err(common, "Invalid calibration type\n");
break;
@@ -93,8 +86,7 @@ static bool ar9003_hw_per_calibration(st
/*
* Accumulate cal measures for active chains
*/
- if (cur_caldata->calCollect)
- cur_caldata->calCollect(ah);
+ cur_caldata->calCollect(ah);
ah->cal_samples++;
if (ah->cal_samples >= cur_caldata->calNumSamples) {
@@ -107,8 +99,7 @@ static bool ar9003_hw_per_calibration(st
/*
* Process accumulated data
*/
- if (cur_caldata->calPostProc)
- cur_caldata->calPostProc(ah, numChains);
+ cur_caldata->calPostProc(ah, numChains);
/* Calibration has finished. */
caldata->CalValid |= cur_caldata->calType;
@@ -323,16 +314,9 @@ static const struct ath9k_percal_data iq
ar9003_hw_iqcalibrate
};
-static const struct ath9k_percal_data temp_cal_single_sample = {
- TEMP_COMP_CAL,
- MIN_CAL_SAMPLES,
- PER_MAX_LOG_COUNT,
-};
-
static void ar9003_hw_init_cal_settings(struct ath_hw *ah)
{
ah->iq_caldata.calData = &iq_cal_single_sample;
- ah->temp_caldata.calData = &temp_cal_single_sample;
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
@@ -340,7 +324,7 @@ static void ar9003_hw_init_cal_settings(
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
- ah->supp_cals = IQ_MISMATCH_CAL | TEMP_COMP_CAL;
+ ah->supp_cals = IQ_MISMATCH_CAL;
}
#define OFF_UPPER_LT 24
@@ -1399,9 +1383,6 @@ static void ar9003_hw_init_cal_common(st
INIT_CAL(&ah->iq_caldata);
INSERT_CAL(ah, &ah->iq_caldata);
- INIT_CAL(&ah->temp_caldata);
- INSERT_CAL(ah, &ah->temp_caldata);
-
/* Initialize current pointer to first element in list */
ah->cal_list_curr = ah->cal_list;
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -830,7 +830,6 @@ struct ath_hw {
/* Calibration */
u32 supp_cals;
struct ath9k_cal_list iq_caldata;
- struct ath9k_cal_list temp_caldata;
struct ath9k_cal_list adcgain_caldata;
struct ath9k_cal_list adcdc_caldata;
struct ath9k_cal_list *cal_list;
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Mark Rutland @ 2016-11-09 11:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: zhichang.yuan, catalin.marinas, will.deacon, robh+dt, bhelgaas,
olof, arnd, linux-arm-kernel, lorenzo.pieralisi, linux-kernel,
linuxarm, devicetree, linux-pci, linux-serial, minyard,
liviu.dudau, zourongrong, john.garry, gabriele.paoloni,
zhichang.yuan02, kantyzc, xuwei5, marc.zyngier
In-Reply-To: <1478646779.7430.66.camel@kernel.crashing.org>
On Wed, Nov 09, 2016 at 10:12:59AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 11:49 +0000, Mark Rutland wrote:
> > I believe that we could theoretically have multiple independent LPC/ISA
> > busses, as is possible with PCI on !x86 systems. If the current ISA code
> > assumes a singleton bus, I think that's something that needs to be fixed
> > up more generically.
> >
> > I don't see why we should need any architecture-specific code here. Why
> > can we not fix up the ISA bus code in drivers/of/address.c such that it
> > handles multiple ISA bus instances, and translates all sub-device
> > addresses relative to the specific bus instance?
>
> What in that code prevents that today ?
It appears I was mistaken w.r.t. the singleton comment. We can already
translate MMIO->MMIO addresses per-instance (in the presence of a ranges
property).
The big change would be to handle !MMIO translations, for which we'd
need a runtime registry of ISA bus instance to find the relevant
accessor ops and instance-specific data.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] drm/i915: rename preliminary_hw_support to alpha_support
From: Daniel Vetter @ 2016-11-09 11:20 UTC (permalink / raw)
To: Jani Nikula
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
Vivi, Rodrigo
In-Reply-To: <87d1igl8rq.fsf@intel.com>
On Mon, Oct 31, 2016 at 07:37:29PM +0200, Jani Nikula wrote:
> On Mon, 31 Oct 2016, "Vivi, Rodrigo" <rodrigo.vivi@intel.com> wrote:
> > I was about to put my rv-b here. I do believe we need to find a better
> > name and the patch was clear and correct. And indeed in a good timing.
> >
> > However right before clicking the send button I had a vision that this
> > will bring another kind of confusion and miss leading.
> >
> > Traditionally this tag has been removed from new platforms around (but
> > not tight to) "PV millestone", few months away from "Alpha milestone".
> >
> > I understand that it is alpha quality from Alpha to PV, but people might
> > think that passing Alpha this is Beta or pre-PV and that the flag should
> > be removed right after alpha.
> > Also from PO to Alpha we cannot say it is alpha quality. It is just too
> > preliminary yet.
>
> I was mostly referring to what it looks on the outside, but it would be
> great if it also made sense internally.
Removing that tag should imo happen around alpha, not around PV. We simply
suck at delivering something working soon enough. Somehow it's really hard
to not regress in modesetting compared to the firmware driver :(
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> BR,
> Jani.
>
> >
> > Maybe we just remove the "_hw_" and improve the texts?
> >
> > Thanks,
> > Rodrigo.
> >
> >
> > On Mon, 2016-10-31 at 12:18 +0200, Jani Nikula wrote:
> >> The term "preliminary hardware support" has always caused confusion both
> >> among users and developers. It has always been about preliminary driver
> >> support for new hardware, and not so much about preliminary hardware. Of
> >> course, initially both the software and hardware are in early stages,
> >> but the distinction becomes more clear when the user picks up production
> >> hardware and an older kernel to go with it, with just the early support
> >> we had for the hardware at the time the kernel was released. The user
> >> has to specifically enable the alpha quality *driver* support for the
> >> hardware in that specific kernel version.
> >
> >
> >>
> >> Rename preliminary_hw_support to alpha_support to emphasize that the
> >> module parameter, config option, and flag are about software, not about
> >> hardware. Improve the language in help texts and debug logging as well.
> >>
> >> This appears to be a good time to do the change, as there are currently
> >> no platforms with preliminary^W alpha support.
> >>
> >> Cc: Rob Clark <robdclark@gmail.com>
> >> Cc: Dave Airlie <airlied@gmail.com>
> >> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >> ---
> >> drivers/gpu/drm/i915/Kconfig | 17 +++++++++++------
> >> drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> >> drivers/gpu/drm/i915/i915_params.c | 9 +++++----
> >> drivers/gpu/drm/i915/i915_params.h | 2 +-
> >> drivers/gpu/drm/i915/i915_pci.c | 7 ++++---
> >> 5 files changed, 23 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> >> index df96aed6975a..36941afba43f 100644
> >> --- a/drivers/gpu/drm/i915/Kconfig
> >> +++ b/drivers/gpu/drm/i915/Kconfig
> >> @@ -36,15 +36,20 @@ config DRM_I915
> >>
> >> If "M" is selected, the module will be called i915.
> >>
> >> -config DRM_I915_PRELIMINARY_HW_SUPPORT
> >> - bool "Enable preliminary support for prerelease Intel hardware by default"
> >> +config DRM_I915_ALPHA_SUPPORT
> >> + bool "Enable alpha quality support for new Intel hardware by default"
> >> depends on DRM_I915
> >> default n
> >> help
> >> - Choose this option if you have prerelease Intel hardware and want the
> >> - i915 driver to support it by default. You can enable such support at
> >> - runtime with the module option i915.preliminary_hw_support=1; this
> >> - option changes the default for that module option.
> >> + Choose this option if you have new Intel hardware and want to enable
> >> + the alpha quality i915 driver support for the hardware in this kernel
> >> + version. You can also enable the support at runtime using the module
> >> + parameter i915.alpha_support=1; this option changes the default for
> >> + that module parameter.
> >> +
> >> + It is recommended to upgrade to a kernel version with proper support
> >> + as soon as it is available. Generally fixes for platforms with alpha
> >> + support are not backported to older kernels.
> >>
> >> If in doubt, say "N".
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >> index 42a499681966..abddafba6220 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -668,7 +668,7 @@ struct intel_csr {
> >> func(is_skylake); \
> >> func(is_broxton); \
> >> func(is_kabylake); \
> >> - func(is_preliminary); \
> >> + func(is_alpha_support); \
> >> /* Keep has_* in alphabetical order */ \
> >> func(has_csr); \
> >> func(has_ddi); \
> >> @@ -2782,7 +2782,7 @@ struct drm_i915_cmd_table {
> >> #define IS_SKL_GT4(dev_priv) (IS_SKYLAKE(dev_priv) && \
> >> (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0030)
> >>
> >> -#define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
> >> +#define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> >>
> >> #define SKL_REVID_A0 0x0
> >> #define SKL_REVID_B0 0x1
> >> diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
> >> index 629e4334719c..d46ffe7086bc 100644
> >> --- a/drivers/gpu/drm/i915/i915_params.c
> >> +++ b/drivers/gpu/drm/i915/i915_params.c
> >> @@ -39,7 +39,7 @@ struct i915_params i915 __read_mostly = {
> >> .enable_hangcheck = true,
> >> .enable_ppgtt = -1,
> >> .enable_psr = -1,
> >> - .preliminary_hw_support = IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> >> + .alpha_support = IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT),
> >> .disable_power_well = -1,
> >> .enable_ips = 1,
> >> .fastboot = 0,
> >> @@ -145,9 +145,10 @@ MODULE_PARM_DESC(enable_psr, "Enable PSR "
> >> "(0=disabled, 1=enabled - link mode chosen per-platform, 2=force link-standby mode, 3=force link-off mode) "
> >> "Default: -1 (use per-chip default)");
> >>
> >> -module_param_named_unsafe(preliminary_hw_support, i915.preliminary_hw_support, int, 0400);
> >> -MODULE_PARM_DESC(preliminary_hw_support,
> >> - "Enable preliminary hardware support.");
> >> +module_param_named_unsafe(alpha_support, i915.alpha_support, int, 0400);
> >> +MODULE_PARM_DESC(alpha_support,
> >> + "Enable alpha quality driver support for latest hardware. "
> >> + "See also CONFIG_DRM_I915_ALPHA_SUPPORT.");
> >>
> >> module_param_named_unsafe(disable_power_well, i915.disable_power_well, int, 0400);
> >> MODULE_PARM_DESC(disable_power_well,
> >> diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
> >> index 94efc899c1ef..817ad959941e 100644
> >> --- a/drivers/gpu/drm/i915/i915_params.h
> >> +++ b/drivers/gpu/drm/i915/i915_params.h
> >> @@ -40,7 +40,7 @@ struct i915_params {
> >> int enable_ppgtt;
> >> int enable_execlists;
> >> int enable_psr;
> >> - unsigned int preliminary_hw_support;
> >> + unsigned int alpha_support;
> >> int disable_power_well;
> >> int enable_ips;
> >> int invert_brightness;
> >> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> >> index 31e6edd08dd0..cdf436fe4e24 100644
> >> --- a/drivers/gpu/drm/i915/i915_pci.c
> >> +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> @@ -436,9 +436,10 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> >> struct intel_device_info *intel_info =
> >> (struct intel_device_info *) ent->driver_data;
> >>
> >> - if (IS_PRELIMINARY_HW(intel_info) && !i915.preliminary_hw_support) {
> >> - DRM_INFO("This hardware requires preliminary hardware support.\n"
> >> - "See CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT, and/or modparam preliminary_hw_support\n");
> >> + if (IS_ALPHA_SUPPORT(intel_info) && !i915.alpha_support) {
> >> + DRM_INFO("The driver support for your hardware in this kernel version is alpha quality\n"
> >> + "See CONFIG_DRM_I915_ALPHA_SUPPORT or i915.alpha_support module parameter\n"
> >> + "to enable support in this kernel version, or check for kernel updates.\n");
> >> return -ENODEV;
> >> }
> >>
> >
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
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
* [PATCH 4.8 062/138] xhci: workaround for hosts missing CAS bit
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mathias Nyman
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit 346e99736c3ce328fd42d678343b70243aca5f36 upstream.
If a device is unplugged and replugged during Sx system suspend
some Intel xHC hosts will overwrite the CAS (Cold attach status) flag
and no device connection is noticed in resume.
A device in this state can be identified in resume if its link state
is in polling or compliance mode, and the current connect status is 0.
A device in this state needs to be warm reset.
Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8
Observed on Cherryview and Apollolake as they go into compliance mode
if LFPS times out during polling, and re-plugged devices are not
discovered at resume.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-hub.c | 37 +++++++++++++++++++++++++++++++++++++
drivers/usb/host/xhci-pci.c | 6 ++++++
drivers/usb/host/xhci.h | 3 +++
3 files changed, 46 insertions(+)
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1355,6 +1355,35 @@ int xhci_bus_suspend(struct usb_hcd *hcd
return 0;
}
+/*
+ * Workaround for missing Cold Attach Status (CAS) if device re-plugged in S3.
+ * warm reset a USB3 device stuck in polling or compliance mode after resume.
+ * See Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8
+ */
+static bool xhci_port_missing_cas_quirk(int port_index,
+ __le32 __iomem **port_array)
+{
+ u32 portsc;
+
+ portsc = readl(port_array[port_index]);
+
+ /* if any of these are set we are not stuck */
+ if (portsc & (PORT_CONNECT | PORT_CAS))
+ return false;
+
+ if (((portsc & PORT_PLS_MASK) != XDEV_POLLING) &&
+ ((portsc & PORT_PLS_MASK) != XDEV_COMP_MODE))
+ return false;
+
+ /* clear wakeup/change bits, and do a warm port reset */
+ portsc &= ~(PORT_RWC_BITS | PORT_CEC | PORT_WAKE_BITS);
+ portsc |= PORT_WR;
+ writel(portsc, port_array[port_index]);
+ /* flush write */
+ readl(port_array[port_index]);
+ return true;
+}
+
int xhci_bus_resume(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
@@ -1392,6 +1421,14 @@ int xhci_bus_resume(struct usb_hcd *hcd)
u32 temp;
temp = readl(port_array[port_index]);
+
+ /* warm reset CAS limited ports stuck in polling/compliance */
+ if ((xhci->quirks & XHCI_MISSING_CAS) &&
+ (hcd->speed >= HCD_USB3) &&
+ xhci_port_missing_cas_quirk(port_index, port_array)) {
+ xhci_dbg(xhci, "reset stuck port %d\n", port_index);
+ continue;
+ }
if (DEV_SUPERSPEED_ANY(temp))
temp &= ~(PORT_RWC_BITS | PORT_CEC | PORT_WAKE_BITS);
else
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -51,6 +51,7 @@
#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
#define PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI 0x0aa8
#define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
+#define PCI_DEVICE_ID_INTEL_APL_XHCI 0x5aa8
static const char hcd_name[] = "xhci_hcd";
@@ -171,6 +172,11 @@ static void xhci_pci_quirks(struct devic
pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) {
xhci->quirks |= XHCI_SSIC_PORT_UNUSED;
}
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI))
+ xhci->quirks |= XHCI_MISSING_CAS;
+
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_EJ168) {
xhci->quirks |= XHCI_RESET_ON_RESUME;
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -314,6 +314,8 @@ struct xhci_op_regs {
#define XDEV_U2 (0x2 << 5)
#define XDEV_U3 (0x3 << 5)
#define XDEV_INACTIVE (0x6 << 5)
+#define XDEV_POLLING (0x7 << 5)
+#define XDEV_COMP_MODE (0xa << 5)
#define XDEV_RESUME (0xf << 5)
/* true: port has power (see HCC_PPC) */
#define PORT_POWER (1 << 9)
@@ -1653,6 +1655,7 @@ struct xhci_hcd {
#define XHCI_MTK_HOST (1 << 21)
#define XHCI_SSIC_PORT_UNUSED (1 << 22)
#define XHCI_NO_64BIT_SUPPORT (1 << 23)
+#define XHCI_MISSING_CAS (1 << 24)
unsigned int num_active_eps;
unsigned int limit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
^ permalink raw reply
* [PATCH 4.8 104/138] drm/imx: ipuv3-plane: Switch EBA buffer only when we dont need modeset
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Liu Ying, Philipp Zabel
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Ying <gnuiyl@gmail.com>
commit 43daa01323da37a3692cabe1579ef5c2c4372e06 upstream.
We added active plane reconfiguration support by forcing a full modeset
operation. So, looking at old_plane_state->fb to determine whether we need to
switch EBA buffer(for hardware double buffering) in ipu_plane_atomic_set_base()
or not is no more correct. Instead, we should do that only when we don't need
modeset, otherwise, we initialize the two EBA buffers with the buffer address.
Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/imx/ipuv3-plane.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -108,6 +108,7 @@ static void ipu_plane_atomic_set_base(st
{
struct drm_plane *plane = &ipu_plane->base;
struct drm_plane_state *state = plane->state;
+ struct drm_crtc_state *crtc_state = state->crtc->state;
struct drm_framebuffer *fb = state->fb;
unsigned long eba, ubo, vbo;
int active;
@@ -149,7 +150,7 @@ static void ipu_plane_atomic_set_base(st
break;
}
- if (old_state->fb) {
+ if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Mark Rutland @ 2016-11-09 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478646779.7430.66.camel@kernel.crashing.org>
On Wed, Nov 09, 2016 at 10:12:59AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 11:49 +0000, Mark Rutland wrote:
> > I believe that we could theoretically have multiple independent LPC/ISA
> > busses, as is possible with PCI on !x86 systems. If the current ISA code
> > assumes a singleton bus, I think that's something that needs to be fixed
> > up more generically.
> >
> > I don't see why we should need any architecture-specific code here. Why
> > can we not fix up the ISA bus code in drivers/of/address.c such that it
> > handles multiple ISA bus instances, and translates all sub-device
> > addresses relative to the specific bus instance?
>
> What in that code prevents that today ?
It appears I was mistaken w.r.t. the singleton comment. We can already
translate MMIO->MMIO addresses per-instance (in the presence of a ranges
property).
The big change would be to handle !MMIO translations, for which we'd
need a runtime registry of ISA bus instance to find the relevant
accessor ops and instance-specific data.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] usb: dwc3: gadget: properly account queued requests
From: Felipe Balbi @ 2016-11-09 11:19 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: stable, Felipe Balbi
In-Reply-To: <147853738821771@kroah.com>
commit a9c3ca5fae6bf73770f0576eaf57d5f1305ef4b3 upstream.
Some requests could be accounted for multiple
times. Let's fix that so each and every requests is
accounted for only once.
Cc: <stable@vger.kernel.org> # v4.8
Fixes: 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for LST bit")
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
drivers/usb/dwc3/gadget.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68544618982e..fc2e7d3e8d28 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -789,6 +789,7 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
req->trb = trb;
req->trb_dma = dwc3_trb_dma_offset(dep, trb);
req->first_trb_index = dep->trb_enqueue;
+ dep->queued_requests++;
}
dwc3_ep_inc_enq(dep);
@@ -841,8 +842,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
trb->ctrl |= DWC3_TRB_CTRL_HWO;
- dep->queued_requests++;
-
trace_dwc3_prepare_trb(dep, trb);
}
@@ -1963,7 +1962,9 @@ static int __dwc3_cleanup_done_trbs(struct dwc3 *dwc, struct dwc3_ep *dep,
unsigned int s_pkt = 0;
unsigned int trb_status;
- dep->queued_requests--;
+ if (req->trb == trb)
+ dep->queued_requests--;
+
trace_dwc3_complete_trb(dep, trb);
/*
--
2.10.1
^ permalink raw reply related
* [PATCH 4.8 109/138] drm/nouveau/acpi: fix check for power resources support
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mika Westerberg, Peter Wu,
Dave Airlie
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Wu <peter@lekensteyn.nl>
commit b0a6af8b34c9ad20894aa46f85f4bf59d444f286 upstream.
Check whether the kernel really supports power resources for a device,
otherwise the power might not be removed when the device is runtime
suspended (DSM should still work in these cases where PR does not).
This is a workaround for a problem where ACPICA and Windows 10 differ in
behavior. ACPICA does not correctly enumerate power resources within a
conditional block (due to delayed execution of such blocks) and as a
result power_resources is set to false even if _PR3 exists.
Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
Reported-and-tested-by: Rick Kerkhof <rick.2889@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -240,7 +240,8 @@ static bool nouveau_pr3_present(struct p
if (!parent_adev)
return false;
- return acpi_has_method(parent_adev->handle, "_PR3");
+ return parent_adev->power.flags.power_resources &&
+ acpi_has_method(parent_adev->handle, "_PR3");
}
static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle *dhandle_out,
^ permalink raw reply
* Re: [Qemu-arm] [RFC PATCH v5 2/2] hw/intc/arm_gicv3_kvm: Implement get/put functions
From: Vijay Kilari @ 2016-11-09 11:19 UTC (permalink / raw)
To: Peter Maydell
Cc: Marc Zyngier, Pavel Fedin, QEMU Developers, Vijaya Kumar K,
qemu-arm, Paolo Bonzini, Richard Henderson
In-Reply-To: <CAFEAcA9Br4VqueBmj4jnacTh2tOOWCPMjW_NWYZt7uvQob9L2A@mail.gmail.com>
On Fri, Oct 7, 2016 at 9:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 20 September 2016 at 07:55, <vijay.kilari@gmail.com> wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> This actually implements pre_save and post_load methods for in-kernel
>> vGICv3.
>>
>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> Signed-off-by: Vijaya Kumamr K <Vijaya.Kumar@cavium.com>
>> [PMM:
>> * use decimal, not 0bnnn
>> * fixed typo in names of ICC_APR0R_EL1 and ICC_AP1R_EL1
>> * completely rearranged the get and put functions to read and write
>> the state in a natural order, rather than mixing distributor and
>> redistributor state together]
>> [Vijay:
>> * Update macro KVM_VGIC_ATTR
>> * Use 32 bit access for gicd and gicr
>> * GICD_IROUTER, GICD_TYPER, GICR_PROPBASER and GICR_PENDBASER reg
>> access are changed from 64-bit to 32-bit access
>> * s->edge_trigger stores only even bits value of an irq config.
>> Update translate_edge_trigger() accordingly.
>> * Add ICC_SRE_EL1 save and restore
>> * Initialized ICC registers during reset
>
> These sorts of [] changes should go above the sign-off
> of the person who did them, to indicate where in the
> chain they happened. Also, yours is missing the closing ].
>
>> ---
>> ---
>
>> +/* Translate from the in-kernel field for an IRQ value to/from the qemu
>> + * representation. Note that these are only expected to be used for
>> + * SPIs (that is, for interrupts whose state is in the distributor
>> + * rather than the redistributor).
>> + */
>> +typedef void (*vgic_translate_fn)(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel);
>> +
>> +static void translate_edge_trigger(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel)
>> +{
>> + /*
>> + * s->edge_trigger stores only even bits value of an irq config.
>> + * Consider only even bits and translate accordingly.
>> + */
>> + if (to_kernel) {
>> + *field = gicv3_gicd_edge_trigger_test(s, irq);
>> + *field = (*field << 1) & 3;
>> + } else {
>> + *field = (*field >> 1) & 1;
>> + gicv3_gicd_edge_trigger_replace(s, irq, *field);
>> + }
>> +}
>
> I would prefer that we just open-coded a for-loop for these,
> as then you can use half_shuffle32 and half_unshuffle32 to
> deal with the bits 32 at a time.
You mean to completely drop this translate_fn which is called from
kvm_dist_put/get() and have a direct function to handle edge_trigger?
>
>> +
>> +static void translate_priority(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel)
>> +{
>> + if (to_kernel) {
>> + *field = s->gicd_ipriority[irq];
>> + } else {
>> + s->gicd_ipriority[irq] = *field;
>> + }
>> +}
>
> Similarly, this would be better with open-coded for loops.
> Then we can dump the translate_fn machinery entirely.
>
>> +
>> +static void kvm_arm_gicv3_reset_reg(GICv3State *s)
>> +{
>> + int ncpu;
>> +
>> + for (ncpu = 0; ncpu < s->num_cpu; ncpu++) {
>> + GICv3CPUState *c = &s->cpu[ncpu];
>> +
>> + /* Initialize to actual HW supported configuration */
>> + kvm_gicc_access(s, ICC_CTLR_EL1, ncpu,
>> + &c->icc_ctlr_el1[GICV3_NS], false);
>> +
>> + c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS];
>> + c->icc_pmr_el1 = 0;
>> + c->icc_bpr[GICV3_G0] = GIC_MIN_BPR;
>> + c->icc_bpr[GICV3_G1] = GIC_MIN_BPR;
>> + c->icc_bpr[GICV3_G1NS] = GIC_MIN_BPR;
>> +
>> + c->icc_sre_el1 = 0x7;
>> + memset(c->icc_apr, 0, sizeof(c->icc_apr));
>> + memset(c->icc_igrpen, 0, sizeof(c->icc_igrpen));
>> + }
>
> This shouldn't be in this patch. If we need to fix reset we
> should do it as a separate patch.
>
> Also this isn't the right place, really, because the CPU interface
> registers need to be reset when the CPU is reset, not when
> the GIC device is reset.
To make GIC cpuif registers to reset upon cpu reset,
I propose to add Interface for gicv3_common class and
call this interface from arm_cpu_reset() similar to
ARMLinuxBootIf. This will be more generic way rather
than searching for gicv3 object and reset the registers
>
>> }
>
>> static void kvm_arm_gicv3_class_init(ObjectClass *klass, void *data)
>> diff --git a/include/hw/intc/arm_gicv3_common.h b/include/hw/intc/arm_gicv3_common.h
>> index 341a311..183c7f8 100644
>> --- a/include/hw/intc/arm_gicv3_common.h
>> +++ b/include/hw/intc/arm_gicv3_common.h
>> @@ -166,6 +166,7 @@ struct GICv3CPUState {
>> uint8_t gicr_ipriorityr[GIC_INTERNAL];
>>
>> /* CPU interface */
>> + uint64_t icc_sre_el1;
>
> Where has this come from? If we need to add a new field then it
This was part of review comment from Christoffer to add icc_sre_el1
save and restore
> needs to be in a different patch (and we need to make sure we
OK. I will spin a new patch
> add it to the VMState struct as well). But neither the emulated
> GIC nor the kernel will support writing any bits in this
> register as far as I'm aware, so it's always constant 0x7...
Kernel will not allow write on this. But make a check for SRE bit.
>
> thanks
> -- PMM
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH v5 2/2] hw/intc/arm_gicv3_kvm: Implement get/put functions
From: Vijay Kilari @ 2016-11-09 11:19 UTC (permalink / raw)
To: Peter Maydell
Cc: qemu-arm, Paolo Bonzini, Richard Henderson, Pavel Fedin,
Marc Zyngier, QEMU Developers, Vijaya Kumar K
In-Reply-To: <CAFEAcA9Br4VqueBmj4jnacTh2tOOWCPMjW_NWYZt7uvQob9L2A@mail.gmail.com>
On Fri, Oct 7, 2016 at 9:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 20 September 2016 at 07:55, <vijay.kilari@gmail.com> wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> This actually implements pre_save and post_load methods for in-kernel
>> vGICv3.
>>
>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> Signed-off-by: Vijaya Kumamr K <Vijaya.Kumar@cavium.com>
>> [PMM:
>> * use decimal, not 0bnnn
>> * fixed typo in names of ICC_APR0R_EL1 and ICC_AP1R_EL1
>> * completely rearranged the get and put functions to read and write
>> the state in a natural order, rather than mixing distributor and
>> redistributor state together]
>> [Vijay:
>> * Update macro KVM_VGIC_ATTR
>> * Use 32 bit access for gicd and gicr
>> * GICD_IROUTER, GICD_TYPER, GICR_PROPBASER and GICR_PENDBASER reg
>> access are changed from 64-bit to 32-bit access
>> * s->edge_trigger stores only even bits value of an irq config.
>> Update translate_edge_trigger() accordingly.
>> * Add ICC_SRE_EL1 save and restore
>> * Initialized ICC registers during reset
>
> These sorts of [] changes should go above the sign-off
> of the person who did them, to indicate where in the
> chain they happened. Also, yours is missing the closing ].
>
>> ---
>> ---
>
>> +/* Translate from the in-kernel field for an IRQ value to/from the qemu
>> + * representation. Note that these are only expected to be used for
>> + * SPIs (that is, for interrupts whose state is in the distributor
>> + * rather than the redistributor).
>> + */
>> +typedef void (*vgic_translate_fn)(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel);
>> +
>> +static void translate_edge_trigger(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel)
>> +{
>> + /*
>> + * s->edge_trigger stores only even bits value of an irq config.
>> + * Consider only even bits and translate accordingly.
>> + */
>> + if (to_kernel) {
>> + *field = gicv3_gicd_edge_trigger_test(s, irq);
>> + *field = (*field << 1) & 3;
>> + } else {
>> + *field = (*field >> 1) & 1;
>> + gicv3_gicd_edge_trigger_replace(s, irq, *field);
>> + }
>> +}
>
> I would prefer that we just open-coded a for-loop for these,
> as then you can use half_shuffle32 and half_unshuffle32 to
> deal with the bits 32 at a time.
You mean to completely drop this translate_fn which is called from
kvm_dist_put/get() and have a direct function to handle edge_trigger?
>
>> +
>> +static void translate_priority(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel)
>> +{
>> + if (to_kernel) {
>> + *field = s->gicd_ipriority[irq];
>> + } else {
>> + s->gicd_ipriority[irq] = *field;
>> + }
>> +}
>
> Similarly, this would be better with open-coded for loops.
> Then we can dump the translate_fn machinery entirely.
>
>> +
>> +static void kvm_arm_gicv3_reset_reg(GICv3State *s)
>> +{
>> + int ncpu;
>> +
>> + for (ncpu = 0; ncpu < s->num_cpu; ncpu++) {
>> + GICv3CPUState *c = &s->cpu[ncpu];
>> +
>> + /* Initialize to actual HW supported configuration */
>> + kvm_gicc_access(s, ICC_CTLR_EL1, ncpu,
>> + &c->icc_ctlr_el1[GICV3_NS], false);
>> +
>> + c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS];
>> + c->icc_pmr_el1 = 0;
>> + c->icc_bpr[GICV3_G0] = GIC_MIN_BPR;
>> + c->icc_bpr[GICV3_G1] = GIC_MIN_BPR;
>> + c->icc_bpr[GICV3_G1NS] = GIC_MIN_BPR;
>> +
>> + c->icc_sre_el1 = 0x7;
>> + memset(c->icc_apr, 0, sizeof(c->icc_apr));
>> + memset(c->icc_igrpen, 0, sizeof(c->icc_igrpen));
>> + }
>
> This shouldn't be in this patch. If we need to fix reset we
> should do it as a separate patch.
>
> Also this isn't the right place, really, because the CPU interface
> registers need to be reset when the CPU is reset, not when
> the GIC device is reset.
To make GIC cpuif registers to reset upon cpu reset,
I propose to add Interface for gicv3_common class and
call this interface from arm_cpu_reset() similar to
ARMLinuxBootIf. This will be more generic way rather
than searching for gicv3 object and reset the registers
>
>> }
>
>> static void kvm_arm_gicv3_class_init(ObjectClass *klass, void *data)
>> diff --git a/include/hw/intc/arm_gicv3_common.h b/include/hw/intc/arm_gicv3_common.h
>> index 341a311..183c7f8 100644
>> --- a/include/hw/intc/arm_gicv3_common.h
>> +++ b/include/hw/intc/arm_gicv3_common.h
>> @@ -166,6 +166,7 @@ struct GICv3CPUState {
>> uint8_t gicr_ipriorityr[GIC_INTERNAL];
>>
>> /* CPU interface */
>> + uint64_t icc_sre_el1;
>
> Where has this come from? If we need to add a new field then it
This was part of review comment from Christoffer to add icc_sre_el1
save and restore
> needs to be in a different patch (and we need to make sure we
OK. I will spin a new patch
> add it to the VMState struct as well). But neither the emulated
> GIC nor the kernel will support writing any bits in this
> register as far as I'm aware, so it's always constant 0x7...
Kernel will not allow write on this. But make a check for SRE bit.
>
> thanks
> -- PMM
^ 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.