* Re: [PATCH] can: xilinx_can: clean up indentation issue
From: Michal Simek @ 2019-06-20 11:55 UTC (permalink / raw)
To: Colin King, Wolfgang Grandegger, Marc Kleine-Budde,
David S . Miller, Michal Simek, linux-can, netdev,
linux-arm-kernel
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190619164518.5683-1-colin.king@canonical.com>
On 19. 06. 19 18:45, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> A statement is indented one level too deep, fix this.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/can/xilinx_can.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 63203ff452b5..a3940141555c 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -924,7 +924,7 @@ static void xcan_err_interrupt(struct net_device *ndev, u32 isr)
> cf->data[3] = CAN_ERR_PROT_LOC_CRC_SEQ;
> }
> }
> - priv->can.can_stats.bus_error++;
> + priv->can.can_stats.bus_error++;
> }
>
> if (skb) {
>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] can: xilinx_can: clean up indentation issue
From: Michal Simek @ 2019-06-20 11:55 UTC (permalink / raw)
To: Colin King, Wolfgang Grandegger, Marc Kleine-Budde,
David S . Miller, Michal Simek, linux-can, netdev,
linux-arm-kernel
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190619164518.5683-1-colin.king@canonical.com>
On 19. 06. 19 18:45, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> A statement is indented one level too deep, fix this.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/can/xilinx_can.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 63203ff452b5..a3940141555c 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -924,7 +924,7 @@ static void xcan_err_interrupt(struct net_device *ndev, u32 isr)
> cf->data[3] = CAN_ERR_PROT_LOC_CRC_SEQ;
> }
> }
> - priv->can.can_stats.bus_error++;
> + priv->can.can_stats.bus_error++;
> }
>
> if (skb) {
>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] can: xilinx_can: clean up indentation issue
From: Michal Simek @ 2019-06-20 11:55 UTC (permalink / raw)
To: Colin King, Wolfgang Grandegger, Marc Kleine-Budde,
David S . Miller, Michal Simek, linux-can, netdev,
linux-arm-kernel
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190619164518.5683-1-colin.king@canonical.com>
On 19. 06. 19 18:45, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> A statement is indented one level too deep, fix this.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/can/xilinx_can.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 63203ff452b5..a3940141555c 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -924,7 +924,7 @@ static void xcan_err_interrupt(struct net_device *ndev, u32 isr)
> cf->data[3] = CAN_ERR_PROT_LOC_CRC_SEQ;
> }
> }
> - priv->can.can_stats.bus_error++;
> + priv->can.can_stats.bus_error++;
> }
>
> if (skb) {
>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
^ permalink raw reply
* [PATCH libnftnl v2] src: libnftnl: add support for matching IPv4 options
From: Stephen Suryaputra @ 2019-06-20 11:54 UTC (permalink / raw)
To: netfilter-devel; +Cc: Stephen Suryaputra
This is the libnftnl change for the overall changes with this
description:
Add capability to have rules matching IPv4 options. This is developed
mainly to support dropping of IP packets with loose and/or strict source
route route options.
v2: Remove statements about supporting other options to reflect what are
supported in the kernel.
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
---
include/linux/netfilter/nf_tables.h | 2 ++
src/expr/exthdr.c | 5 +++++
2 files changed, 7 insertions(+)
diff --git a/include/linux/netfilter/nf_tables.h b/include/linux/netfilter/nf_tables.h
index fd38cdc..a5e9bf3 100644
--- a/include/linux/netfilter/nf_tables.h
+++ b/include/linux/netfilter/nf_tables.h
@@ -729,10 +729,12 @@ enum nft_exthdr_flags {
*
* @NFT_EXTHDR_OP_IPV6: match against ipv6 extension headers
* @NFT_EXTHDR_OP_TCP: match against tcp options
+ * @NFT_EXTHDR_OP_IPV4: match against ipv4 options
*/
enum nft_exthdr_op {
NFT_EXTHDR_OP_IPV6,
NFT_EXTHDR_OP_TCPOPT,
+ NFT_EXTHDR_OP_IPV4,
__NFT_EXTHDR_OP_MAX
};
#define NFT_EXTHDR_OP_MAX (__NFT_EXTHDR_OP_MAX - 1)
diff --git a/src/expr/exthdr.c b/src/expr/exthdr.c
index bef453e..e5f714b 100644
--- a/src/expr/exthdr.c
+++ b/src/expr/exthdr.c
@@ -200,6 +200,9 @@ static const char *op2str(uint8_t op)
case NFT_EXTHDR_OP_TCPOPT:
return " tcpopt";
case NFT_EXTHDR_OP_IPV6:
+ return " ipv6";
+ case NFT_EXTHDR_OP_IPV4:
+ return " ipv4";
default:
return "";
}
@@ -209,6 +212,8 @@ static inline int str2exthdr_op(const char* str)
{
if (!strcmp(str, "tcpopt"))
return NFT_EXTHDR_OP_TCPOPT;
+ if (!strcmp(str, "ipv4"))
+ return NFT_EXTHDR_OP_IPV4;
/* if str == "ipv6" or anything else */
return NFT_EXTHDR_OP_IPV6;
--
2.17.1
^ permalink raw reply related
* [U-Boot] [PATCH 0/5] Virtex2 FPGA enhancements
From: Michal Simek @ 2019-06-20 11:55 UTC (permalink / raw)
To: u-boot
In-Reply-To: <dfbc75e6-d317-7e21-c225-c5f377a1a371@sedsystems.ca>
On 19. 06. 19 17:43, Robert Hancock wrote:
> On 2019-06-19 6:10 a.m., Michal Simek wrote:
>> On 18. 06. 19 17:47, Robert Hancock wrote:
>>> These changes add support for slave serial mode, in addition to the
>>> existing slave SelectMAP mode, for programming Xilinx Virtex2 (and later)
>>> FPGAs, as well as fixing up code style and an issue with the programming
>>> sequence.
>>>
>>> Robert Hancock (5):
>>> fpga: virtex2: cosmetic: Cleanup code style
>>> fpga: virtex2: added Kconfig option
>>> fpga: virtex2: Split out image writing from pre/post operations
>>> fpga: virtex2: Add additional clock cycles after DONE assertion
>>> fpga: virtex2: Add slave serial programming support
>>>
>>> drivers/fpga/Kconfig | 8 +
>>> drivers/fpga/virtex2.c | 503 +++++++++++++++++++++++++++++--------------------
>>> include/virtex2.h | 13 +-
>>> 3 files changed, 313 insertions(+), 211 deletions(-)
>>>
>>
>> I have not a problem with this code but my question is what's your plan
>> about it? Right now none is really calling/building this code.
>> Are you going to push any platform which will enable this driver?
>
> This is being used on an internal platform that hasn't been upstreamed
> yet. There is some more cleanup that needs to happen in the board code
> before that can happen but I think we could potentially do that.
>
> However, now that there is a Kconfig option for this it would be a lot
> easier for those code to be built for other platforms that will use it.
It will be useful to have this code available because of fpga functions
needs to be implemented based on your connection. Do you have this in
any internal repo or also available in your u-boot clone somewhere like
github?
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] regulator: qcom_spmi: Fix math of spmi_regulator_set_voltage_time_sel
From: Mark Brown @ 2019-06-20 11:54 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: bjorn.andersson, lgirdwood, jorge.ramirez-ortiz, linux-arm-msm,
linux-kernel
In-Reply-To: <20190619185636.10831-1-jeffrey.l.hugo@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
On Wed, Jun 19, 2019 at 11:56:36AM -0700, Jeffrey Hugo wrote:
> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver")
> Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Reported-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
I remember pointing this out during reviews as well...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation
From: Ard Biesheuvel @ 2019-06-20 11:54 UTC (permalink / raw)
To: Milan Broz
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Herbert Xu,
Eric Biggers, device-mapper development, linux-fscrypt,
Gilad Ben-Yossef
In-Reply-To: <459f5760-3a1c-719d-2b44-824ba6283dd7@gmail.com>
On Thu, 20 Jun 2019 at 13:22, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 19/06/2019 18:29, Ard Biesheuvel wrote:
> > This series creates an ESSIV template that produces a skcipher or AEAD
> > transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
> > (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
> > encapsulated sync or async skcipher/aead by passing through all operations,
> > while using the cipher/shash pair to transform the input IV into an ESSIV
> > output IV.
> >
> > This matches what both users of ESSIV in the kernel do, and so it is proposed
> > as a replacement for those, in patches #2 and #4.
> >
> > This code has been tested using the fscrypt test suggested by Eric
> > (generic/549), as well as the mode-test script suggested by Milan for
> > the dm-crypt case. I also tested the aead case in a virtual machine,
> > but it definitely needs some wider testing from the dm-crypt experts.
> >
> > Changes since v2:
> > - fixed a couple of bugs that snuck in after I'd done the bulk of my
> > testing
> > - some cosmetic tweaks to the ESSIV template skcipher setkey function
> > to align it with the aead one
> > - add a test case for essiv(cbc(aes),aes,sha256)
> > - add an accelerated implementation for arm64 that combines the IV
> > derivation and the actual en/decryption in a single asm routine
>
> I run tests for the whole patchset, including some older scripts and seems
> it works for dm-crypt now.
>
Thanks Milan, that is really helpful.
Does this include configurations that combine authenc with essiv?
> For the new CRYPTO_ESSIV option - dm-crypt must unconditionally
> select it (we rely on all IV generators availability in userspace),
> but that's already done in patch 4.
>
Indeed.
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen/arm: fix build after 2e35cdf
From: Andrew Cooper @ 2019-06-20 11:54 UTC (permalink / raw)
To: Volodymyr Babchuk, Stefano Stabellini
Cc: xen-devel@lists.xenproject.org, Julien Grall
In-Reply-To: <87pnn87c0t.fsf@epam.com>
On 20/06/2019 12:05, Volodymyr Babchuk wrote:
>> Volodmir, FYI I reproduced the issue using Ubuntu Trusty gcc
>> 4.8.4-2ubuntu1~14.04.3.
> Oh, I see. This is the quite old version of GCC. I'm using
> aarch64-poky-linux-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
> which is also old, but at least it tracks variables initialization
> better.
This was spotted by CI https://travis-ci.org/andyhhp/xen/jobs/547896353
and is a supported of GCC which Xen supports.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation
From: Ard Biesheuvel @ 2019-06-20 11:54 UTC (permalink / raw)
To: Milan Broz
Cc: Herbert Xu, Eric Biggers, linux-fscrypt, Gilad Ben-Yossef,
device-mapper development,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE
In-Reply-To: <459f5760-3a1c-719d-2b44-824ba6283dd7@gmail.com>
On Thu, 20 Jun 2019 at 13:22, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 19/06/2019 18:29, Ard Biesheuvel wrote:
> > This series creates an ESSIV template that produces a skcipher or AEAD
> > transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
> > (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
> > encapsulated sync or async skcipher/aead by passing through all operations,
> > while using the cipher/shash pair to transform the input IV into an ESSIV
> > output IV.
> >
> > This matches what both users of ESSIV in the kernel do, and so it is proposed
> > as a replacement for those, in patches #2 and #4.
> >
> > This code has been tested using the fscrypt test suggested by Eric
> > (generic/549), as well as the mode-test script suggested by Milan for
> > the dm-crypt case. I also tested the aead case in a virtual machine,
> > but it definitely needs some wider testing from the dm-crypt experts.
> >
> > Changes since v2:
> > - fixed a couple of bugs that snuck in after I'd done the bulk of my
> > testing
> > - some cosmetic tweaks to the ESSIV template skcipher setkey function
> > to align it with the aead one
> > - add a test case for essiv(cbc(aes),aes,sha256)
> > - add an accelerated implementation for arm64 that combines the IV
> > derivation and the actual en/decryption in a single asm routine
>
> I run tests for the whole patchset, including some older scripts and seems
> it works for dm-crypt now.
>
Thanks Milan, that is really helpful.
Does this include configurations that combine authenc with essiv?
> For the new CRYPTO_ESSIV option - dm-crypt must unconditionally
> select it (we rely on all IV generators availability in userspace),
> but that's already done in patch 4.
>
Indeed.
^ permalink raw reply
* Re: Question about pinctrl_pm_select_xxx()
From: Mark Brown @ 2019-06-20 11:54 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Linux-ALSA
In-Reply-To: <87v9x1rt8o.wl-kuninori.morimoto.gx@renesas.com>
[-- Attachment #1.1: Type: text/plain, Size: 257 bytes --]
On Thu, Jun 20, 2019 at 09:35:06AM +0900, Kuninori Morimoto wrote:
> Thus, calling it from DAI only is very enough, I think.
I'd expect that only the DAI should have pins so probably yes, but we
can't guarantee that this won't break anything in practice.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC 0/2] Support for buttons on newer MS Surface devices
From: Maximilian Luz @ 2019-06-20 11:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux Kernel Mailing List, linux-input, Platform Driver,
Dmitry Torokhov, Hans de Goede, Chen Yu, Darren Hart,
Andy Shevchenko
In-Reply-To: <CAHp75Vcf79a2_3VGfju237omDjmnhCYN18u+=m_n-tjxZUxt4A@mail.gmail.com>
On 6/20/19 7:53 AM, Andy Shevchenko wrote:
> No top post, please.
Sorry, will do better!
> And yes, submit it as a series. Also Cc to Benjamin Tissoires.
Done.
Thank you,
Maximilian
^ permalink raw reply
* [Buildroot] [PATCH 2/3] package/busybox: convert S10mdev to the canonical init script format
From: Andy Shevchenko @ 2019-06-20 11:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5e25ef4f-97c0-0f0e-9fdb-de4c4300086b@railnova.eu>
On Thu, Jun 20, 2019 at 01:39:32PM +0200, Titouan Christophe wrote:
> On 6/20/19 12:44 PM, Titouan Christophe wrote:
> > Hello Andy,
> >
> > On 6/20/19 12:10 PM, Andy Shevchenko wrote:
> > > On Wed, Jun 19, 2019 at 06:42:56PM +0200, Titouan Christophe wrote:
> > > > Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
> > >
> > > > -??? find /sys/ -name modalias -print0 | xargs -0 sort -u | tr
> > > > '\n' '\0' | \
> > > > -??????? xargs -0 modprobe -abq
> > >
> > > > +??? find /sys/ -name modalias -print0 | \
> > > > +??????? xargs -0 sort -u | \
> > > > +??????? tr '\n' '\0' | \
> > > > +??????? xargs -0 modprobe -abq
> > >
> > > How this indentation change related to the topic?
> > >
> >
> > This is a preparatory patch to convert this script to the canonical init
> > script format, as suggested by Arnout (see
> > http://lists.busybox.net/pipermail/buildroot/2019-May/251199.html)
>
>
> sorry I did not pay attention to the fact that you were only commenting on
> this particular hunk. I did reindent this command chain for better
> readability (in my opinion); I can rework that part to better suit the
> codestyle, if any.
It should be a separate patch explaining why you are doing that, but not in this one.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [Qemu-devel] [PATCH] deprecate -mem-path fallback to anonymous RAM
From: Igor Mammedov @ 2019-06-20 11:41 UTC (permalink / raw)
To: qemu-devel; +Cc: libvir-list, ehabkost
Fallback might affect guest or worse whole host performance
or functionality if backing file were used to share guest RAM
with another process.
Patch deprecates fallback so that we could remove it in future
and ensure that QEMU will provide expected behavior and fail if
it can't use user provided backing file.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
---
PS:
Patch is written on top of
[PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution
to avoid conflicts in qemu-deprecated.texi
numa.c | 4 ++--
qemu-deprecated.texi | 8 ++++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/numa.c b/numa.c
index 91a29138a2..53d67b8ad9 100644
--- a/numa.c
+++ b/numa.c
@@ -494,8 +494,8 @@ static void allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
if (mem_prealloc) {
exit(1);
}
- error_report("falling back to regular RAM allocation.");
-
+ warn_report("falling back to regular RAM allocation. "
+ "Fallback to RAM allocation is deprecated.");
/* Legacy behavior: if allocation failed, fall back to
* regular RAM allocation.
*/
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 2fe9b72121..2193705644 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -112,6 +112,14 @@ QEMU using implicit generic or board specific splitting rule.
Use @option{memdev} with @var{memory-backend-ram} backend or @option{mem} (if
it's supported by used machine type) to define mapping explictly instead.
+@subsection -mem-path fallback to RAM (since 4.1)
+Currently if system memory allocation from file pointed by @option{mem-path}
+fails, QEMU fallbacks to allocating from anonymous RAM. Which might result
+in unpredictable behavior since provided backing file wasn't used. In future
+QEMU will not fallback and fail to start up, so user could fix his/her QEMU/host
+configuration or explicitly use -m without -mem-path if system memory allocated
+from anonymous RAM suits usecase.
+
@section QEMU Machine Protocol (QMP) commands
@subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
--
2.18.1
^ permalink raw reply related
* [dpdk-dev] DPDK Release Status Meeting 20/6/2019
From: Ferruh Yigit @ 2019-06-20 11:52 UTC (permalink / raw)
To: dpdk-dev
Cc: John McNamara, Stokes, Ian, Thomas Monjalon, Jerin Jacob,
Akhil, Goyal, Cristian Dumitrescu, Qian Xu, Yongseok Koh,
Maxime Coquelin, Qi Zhang, Shahaf Shuler, Pablo de Lara
Minutes 20 June 2019
--------------------
Agenda:
* Release Dates
* Subtrees
* OvS
* Opens
Participants:
* Intel
* Marvell
* Mellanox
* NXP
* Red Hat
Release Dates
-------------
* v19.08 dates:
* RC1 date pushed to *Monday 08 July*
* Release Thurs 01 August 2019
* Reminder to send roadmaps for the release, it helps planning
* Intel and Arm already shared the roadmap
* Marvell will have new PMDs and will provide a roadmap
* Mellanox will send the roadmap soon
* v19.11 dates:
* Proposal/V1 Friday 06 September 2019
* Integration/Merge/RC1 Friday 11 October 2019
* Release Friday 08 November 2019
Subtrees
--------
* main
* Will do a sub-trees merge today/tomorrow
* next-net
* Merging patches, more to go
* Will be ready for pull from main at the end of today
* Marvell proposed to have a net vendor sub-tree, which will be pulled by
next-net. Thanks for it, this will help on next-net work load
* For next-net-intel, Xiaolong will cover Qi during holiday
* next-virtio
* Will send a pull request today
* next-crypto
* Will get ipsec patches
* bbdev patches are in backlog, comments sent
* next-eventdev
* Merging patches
* Waiting for new versions of patches
* Stable trees
* Kevin will be on holiday, Luca will cover him for 18.11.x
* v17.11.7 work will start, target is to have rc in two weeks
OvS
---
* Travis patch to track branches integrated
* OvS 2.9/2.10 validating 17.11.6, will help to know 17.11.7 plans
* OvS 2.12, v1: 1 July, feature freeze mid July, release mid August
Opens
-----
* Please fix Coverity issues
* Ferruh to check build errors in daily build log
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply
* [Qemu-devel] [PATCH v5 0/2] ati-vga: Implement DDC and EDID info from monitor
From: BALATON Zoltan @ 2019-06-20 10:55 UTC (permalink / raw)
To: qemu-devel; +Cc: Corey Minyard, Gerd Hoffmann
Version 5 Works with ATI MacOS NDRV, MorphOS and Linux radeonfb so
hopefully this is good enough for now (each of these access
DDC bits slightly differently).
Version 4 try to fix an ASan warning about leaking bitbang_i2c.
Version 3 keeps bitbang_i2c.h and moves it to include/hw/i2c/
otherwise same as version 2.
BALATON Zoltan (2):
i2c: Move bitbang_i2c.h to include/hw/i2c/
ati-vga: Implement DDC and EDID info from monitor
hw/display/Kconfig | 2 ++
hw/display/ati.c | 60 ++++++++++++++++++++++++++++++++++--
hw/display/ati_int.h | 5 +++
hw/display/ati_regs.h | 2 ++
hw/i2c/bitbang_i2c.c | 2 +-
hw/i2c/ppc4xx_i2c.c | 1 -
hw/i2c/versatile_i2c.c | 2 +-
{hw => include/hw}/i2c/bitbang_i2c.h | 2 ++
include/hw/i2c/i2c.h | 2 --
include/hw/i2c/ppc4xx_i2c.h | 2 +-
10 files changed, 72 insertions(+), 8 deletions(-)
rename {hw => include/hw}/i2c/bitbang_i2c.h (80%)
--
2.13.7
^ permalink raw reply
* [PATCH nfnext v4] netfilter: add support for matching IPv4 options
From: Stephen Suryaputra @ 2019-06-20 11:51 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, Stephen Suryaputra
This is the kernel change for the overall changes with this description:
Add capability to have rules matching IPv4 options. This is developed
mainly to support dropping of IP packets with loose and/or strict source
route route options.
v2: Fix style issues. Make this work with NFPROTO_INET (inet tables),
NFPROTO_BRIDGE and the NFPROTO_NETDEV families. Check skb->protocol.
Remove ability to input IP header offset for ipv4_find_option()
function (all per Pablo Neira Ayuso).
v3: Remove unused ipv4_find_option() arguments (per Pablo Neira Ayuso).
v4: Change the code to not follow ipv6_find_hdr() and just do what are
needed to support source-route, record route and router alert (per
Pablo Neira Ayuso). Fix bugs that are introduced while addressing
review comments.
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
---
include/uapi/linux/netfilter/nf_tables.h | 2 +
net/ipv4/ip_options.c | 1 +
net/netfilter/nft_exthdr.c | 111 +++++++++++++++++++++++
3 files changed, 114 insertions(+)
diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 505393c6e959..168d741f42c5 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -730,10 +730,12 @@ enum nft_exthdr_flags {
*
* @NFT_EXTHDR_OP_IPV6: match against ipv6 extension headers
* @NFT_EXTHDR_OP_TCP: match against tcp options
+ * @NFT_EXTHDR_OP_IPV4: match against ipv4 options
*/
enum nft_exthdr_op {
NFT_EXTHDR_OP_IPV6,
NFT_EXTHDR_OP_TCPOPT,
+ NFT_EXTHDR_OP_IPV4,
__NFT_EXTHDR_OP_MAX
};
#define NFT_EXTHDR_OP_MAX (__NFT_EXTHDR_OP_MAX - 1)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 3db31bb9df50..ddaa01ec2bce 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -473,6 +473,7 @@ int __ip_options_compile(struct net *net,
*info = htonl((pp_ptr-iph)<<24);
return -EINVAL;
}
+EXPORT_SYMBOL(__ip_options_compile);
int ip_options_compile(struct net *net,
struct ip_options *opt, struct sk_buff *skb)
diff --git a/net/netfilter/nft_exthdr.c b/net/netfilter/nft_exthdr.c
index a940c9fd9045..703269359dba 100644
--- a/net/netfilter/nft_exthdr.c
+++ b/net/netfilter/nft_exthdr.c
@@ -62,6 +62,103 @@ static void nft_exthdr_ipv6_eval(const struct nft_expr *expr,
regs->verdict.code = NFT_BREAK;
}
+/* find the offset to specified option.
+ *
+ * If target header is found, its offset is set in *offset and return option
+ * number. Otherwise, return negative error.
+ *
+ * If the first fragment doesn't contain the End of Options it is considered
+ * invalid.
+ */
+static int ipv4_find_option(struct net *net, struct sk_buff *skb,
+ unsigned int *offset, int target)
+{
+ unsigned char optbuf[sizeof(struct ip_options) + 40];
+ struct ip_options *opt = (struct ip_options *)optbuf;
+ struct iphdr *iph, _iph;
+ unsigned int start;
+ bool found = false;
+ __be32 info;
+ int optlen;
+
+ iph = skb_header_pointer(skb, 0, sizeof(_iph), &_iph);
+ if (!iph || iph->version != 4)
+ return -EBADMSG;
+ start = sizeof(struct iphdr);
+
+ optlen = iph->ihl * 4 - (int)sizeof(struct iphdr);
+ if (optlen <= 0)
+ return -ENOENT;
+
+ memset(opt, 0, sizeof(struct ip_options));
+ /* Copy the options since __ip_options_compile() modifies
+ * the options.
+ */
+ if (skb_copy_bits(skb, start, opt->__data, optlen))
+ return -EBADMSG;
+ opt->optlen = optlen;
+
+ if (__ip_options_compile(net, opt, NULL, &info))
+ return -EBADMSG;
+
+ switch (target) {
+ case IPOPT_SSRR:
+ case IPOPT_LSRR:
+ if (!opt->srr)
+ break;
+ found = target == IPOPT_SSRR ? opt->is_strictroute :
+ !opt->is_strictroute;
+ if (found)
+ *offset = opt->srr + start;
+ break;
+ case IPOPT_RR:
+ if (!opt->rr)
+ break;
+ *offset = opt->rr + start;
+ found = true;
+ break;
+ case IPOPT_RA:
+ if (!opt->router_alert)
+ break;
+ *offset = opt->router_alert + start;
+ found = true;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+ return found ? target : -ENOENT;
+}
+
+static void nft_exthdr_ipv4_eval(const struct nft_expr *expr,
+ struct nft_regs *regs,
+ const struct nft_pktinfo *pkt)
+{
+ struct nft_exthdr *priv = nft_expr_priv(expr);
+ u32 *dest = ®s->data[priv->dreg];
+ struct sk_buff *skb = pkt->skb;
+ unsigned int offset;
+ int err;
+
+ if (skb->protocol != htons(ETH_P_IP))
+ goto err;
+
+ err = ipv4_find_option(nft_net(pkt), skb, &offset, priv->type);
+ if (priv->flags & NFT_EXTHDR_F_PRESENT) {
+ *dest = (err >= 0);
+ return;
+ } else if (err < 0) {
+ goto err;
+ }
+ offset += priv->offset;
+
+ dest[priv->len / NFT_REG32_SIZE] = 0;
+ if (skb_copy_bits(pkt->skb, offset, dest, priv->len) < 0)
+ goto err;
+ return;
+err:
+ regs->verdict.code = NFT_BREAK;
+}
+
static void *
nft_tcp_header_pointer(const struct nft_pktinfo *pkt,
unsigned int len, void *buffer, unsigned int *tcphdr_len)
@@ -360,6 +457,14 @@ static const struct nft_expr_ops nft_exthdr_ipv6_ops = {
.dump = nft_exthdr_dump,
};
+static const struct nft_expr_ops nft_exthdr_ipv4_ops = {
+ .type = &nft_exthdr_type,
+ .size = NFT_EXPR_SIZE(sizeof(struct nft_exthdr)),
+ .eval = nft_exthdr_ipv4_eval,
+ .init = nft_exthdr_init,
+ .dump = nft_exthdr_dump,
+};
+
static const struct nft_expr_ops nft_exthdr_tcp_ops = {
.type = &nft_exthdr_type,
.size = NFT_EXPR_SIZE(sizeof(struct nft_exthdr)),
@@ -400,6 +505,12 @@ nft_exthdr_select_ops(const struct nft_ctx *ctx,
if (tb[NFTA_EXTHDR_DREG])
return &nft_exthdr_ipv6_ops;
break;
+ case NFT_EXTHDR_OP_IPV4:
+ if (ctx->family != NFPROTO_IPV6) {
+ if (tb[NFTA_EXTHDR_DREG])
+ return &nft_exthdr_ipv4_ops;
+ }
+ break;
}
return ERR_PTR(-EOPNOTSUPP);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] spi/acpi: fix incorrect ACPI parent check
From: Ard Biesheuvel @ 2019-06-20 11:51 UTC (permalink / raw)
To: Mark Brown
Cc: Mika Westerberg, Jarkko Nikula, linux-spi, kbuild test robot,
Dan Carpenter, Andy Shevchenko, Masahisa Kojima,
Rafael J. Wysocki, ACPI Devel Maling List, Lukas Wunner
In-Reply-To: <20190620111905.GA5316@sirena.org.uk>
On Thu, 20 Jun 2019 at 13:19, Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jun 20, 2019 at 01:41:28PM +0300, Mika Westerberg wrote:
> > On Thu, Jun 20, 2019 at 12:33:41PM +0200, Ard Biesheuvel wrote:
>
> > IMHO it's better to do:
>
> > memset(&lookup, 0, sizeof(lookup));
> > lookup.ctlr = ctlr;
> > lookup.irq = -1;
>
> > this also initializes chip_select and possibly other fields that get
> > added to the lookup structure later.
>
> I agree.
Sure, I will spin it like that once Jarkko confirms that this fixes his problem.
^ permalink raw reply
* [PATCH 2/2] input: soc_button_array for newer surface devices
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
Benjamin Tissoires, Maximilian Luz
In-Reply-To: <20190620115056.4169-1-luzmaximilian@gmail.com>
Power and volume button support for 5th and 6th genration Microsoft
Surface devices via soc_button_array.
Note that these devices use the same MSHW0040 device as on the Surface
Pro 4, however the implementation is different (GPIOs vs. ACPI
notifications). Thus some checking is required to ensure we only load
this driver on the correct devices.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
---
drivers/input/misc/soc_button_array.c | 134 +++++++++++++++++++++++---
1 file changed, 122 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 5e59f8e57f8e..157f53a2bd51 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -25,6 +25,17 @@ struct soc_button_info {
bool wakeup;
};
+/**
+ * struct soc_device_data - driver data for different device types
+ * @button_info: specifications of buttons, if NULL specification is assumed to
+ * be present in _DSD
+ * @check: device-specific check (NULL means all will be accepted)
+ */
+struct soc_device_data {
+ struct soc_button_info *button_info;
+ int (*check)(struct device *dev);
+};
+
/*
* Some of the buttons like volume up/down are auto repeat, while others
* are not. To support both, we register two platform devices, and put
@@ -310,6 +321,7 @@ static int soc_button_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
const struct acpi_device_id *id;
+ struct soc_device_data *device_data;
struct soc_button_info *button_info;
struct soc_button_data *priv;
struct platform_device *pd;
@@ -320,18 +332,20 @@ static int soc_button_probe(struct platform_device *pdev)
if (!id)
return -ENODEV;
- if (!id->driver_data) {
+ device_data = (struct soc_device_data *)id->driver_data;
+ if (device_data && device_data->check) {
+ error = device_data->check(dev);
+ if (error)
+ return error;
+ }
+
+ if (device_data && device_data->button_info) {
+ button_info = (struct soc_button_info *)
+ device_data->button_info;
+ } else {
button_info = soc_button_get_button_info(dev);
if (IS_ERR(button_info))
return PTR_ERR(button_info);
- } else {
- button_info = (struct soc_button_info *)id->driver_data;
- }
-
- error = gpiod_count(dev, NULL);
- if (error < 0) {
- dev_dbg(dev, "no GPIO attached, ignoring...\n");
- return -ENODEV;
}
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -357,12 +371,32 @@ static int soc_button_probe(struct platform_device *pdev)
if (!priv->children[0] && !priv->children[1])
return -ENODEV;
- if (!id->driver_data)
+ if (!device_data || !device_data->button_info)
devm_kfree(dev, button_info);
return 0;
}
+
+static int soc_device_check_generic(struct device *dev)
+{
+ int gpios;
+
+ gpios = gpiod_count(dev, NULL);
+ if (gpios < 0) {
+ dev_dbg(dev, "no GPIO attached, ignoring...\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static struct soc_device_data soc_device_ACPI0011 = {
+ .button_info = NULL,
+ .check = soc_device_check_generic,
+};
+
+
/*
* Definition of buttons on the tablet. The ACPI index of each button
* is defined in section 2.8.7.2 of "Windows ACPI Design Guide for SoC
@@ -377,9 +411,85 @@ static struct soc_button_info soc_button_PNP0C40[] = {
{ }
};
+static struct soc_device_data soc_device_PNP0C40 = {
+ .button_info = soc_button_PNP0C40,
+ .check = soc_device_check_generic,
+};
+
+
+/*
+ * Special device check for Surface Book 2 and Surface Pro (2017).
+ * Both, the Surface Pro 4 (surfacepro3_button.c) and the above mentioned
+ * devices use MSHW0040 for power and volume buttons, however the way they
+ * have to be addressed differs. Make sure that we only load this drivers
+ * for the correct devices by checking the OEM Platform Revision provided by
+ * the _DSM method.
+ */
+#define MSHW0040_DSM_REVISION 0x01
+#define MSHW0040_DSM_GET_OMPR 0x02 // get OEM Platform Revision
+static const guid_t MSHW0040_DSM_UUID =
+ GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
+ 0x49, 0x80, 0x35);
+
+static int soc_device_check_MSHW0040(struct device *dev)
+{
+ acpi_handle handle = ACPI_HANDLE(dev);
+ union acpi_object *result;
+ u64 oem_platform_rev = 0;
+ int gpios;
+
+ // get OEM platform revision
+ result = acpi_evaluate_dsm_typed(handle, &MSHW0040_DSM_UUID,
+ MSHW0040_DSM_REVISION,
+ MSHW0040_DSM_GET_OMPR, NULL,
+ ACPI_TYPE_INTEGER);
+
+ if (result) {
+ oem_platform_rev = result->integer.value;
+ ACPI_FREE(result);
+ }
+
+ if (oem_platform_rev == 0)
+ return -ENODEV;
+
+ dev_dbg(dev, "OEM Platform Revision %llu\n", oem_platform_rev);
+
+ /*
+ * We are _really_ expecting GPIOs here. If we do not get any, this
+ * means the GPIO driver has not been loaded yet (which can happen).
+ * Try again later.
+ */
+ gpios = gpiod_count(dev, NULL);
+ if (gpios < 0)
+ return -EAGAIN;
+
+ return 0;
+}
+
+/*
+ * Button infos for Microsoft Surface Book 2 and Surface Pro (2017).
+ * Obtained from DSDT/testing.
+ */
+static struct soc_button_info soc_button_MSHW0040[] = {
+ { "power", 0, EV_KEY, KEY_POWER, false, true },
+ { "volume_up", 2, EV_KEY, KEY_VOLUMEUP, true, false },
+ { "volume_down", 4, EV_KEY, KEY_VOLUMEDOWN, true, false },
+ { }
+};
+
+static struct soc_device_data soc_device_MSHW0040 = {
+ .button_info = soc_button_MSHW0040,
+ .check = soc_device_check_MSHW0040,
+};
+
+
static const struct acpi_device_id soc_button_acpi_match[] = {
- { "PNP0C40", (unsigned long)soc_button_PNP0C40 },
- { "ACPI0011", 0 },
+ { "PNP0C40", (unsigned long)&soc_device_PNP0C40 },
+ { "ACPI0011", (unsigned long)&soc_device_ACPI0011 },
+
+ /* Microsoft Surface Devices (5th and 6th generation) */
+ { "MSHW0040", (unsigned long)&soc_device_MSHW0040 },
+
{ }
};
--
2.22.0
^ permalink raw reply related
* Re: [Qemu-devel] [SeaBIOS] [PATCH v3 4/4] geometry: Apply LCHS values for boot devices
From: Gerd Hoffmann @ 2019-06-20 11:47 UTC (permalink / raw)
To: Sam Eiderman
Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz,
kevin, liran.alon, karl.heubaum
In-Reply-To: <ECC27FB9-1975-4C78-9584-BC82BB7FA34B@oracle.com>
On Thu, Jun 20, 2019 at 11:52:01AM +0300, Sam Eiderman wrote:
>
>
> > On 20 Jun 2019, at 8:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> >> +static int
> >> +overriden_lchs_supplied(struct drive_s *drive)
> >> +{
> >> + return drive->lchs.cylinder || drive->lchs.head || drive->lchs.sector;
> >> +}
> >
> >> + case TRANSLATION_MACHINE:
> >
> > Hmm, why this name? Doesn't look intuitive to me.
>
> TRANSLATION_HOST?
>
> >
> >> + desc = "overriden";
> >
> > I'd name that "host-supplied" or "fw-cfg”.
>
> “host-supplied”?
>
> >
> >> + cylinders = drive->lchs.cylinder;
> >> + heads = drive->lchs.head;
> >> + if (heads > 255)
> >> + heads = 255;
> >
> > I suggest to move these sanity checks to overriden_lchs_supplied(), then
> > ignore the override altogether when heads or sectors is out of range
> > instead of trying to fixup things.
>
> Sounds reasonable.
> I’ll rename to host_lchs_supplied()?
>
> WDYT?
looks all good to me.
cheers,
Gerd
^ permalink raw reply
* [PATCH 1/2] platform: Fix device check for surfacepro3_button
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
Benjamin Tissoires, Maximilian Luz
In-Reply-To: <20190620115056.4169-1-luzmaximilian@gmail.com>
Do not use the surfacepro3_button driver on newer Microsoft Surface
models, only use it on the Surface Pro 3 and 4. Newer models (5th, 6th
and possibly future generations) use the same device as the Surface Pro
4 to represent their volume and power buttons (MSHW0040), but their
acutal implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
---
drivers/platform/x86/surfacepro3_button.c | 38 +++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/platform/x86/surfacepro3_button.c b/drivers/platform/x86/surfacepro3_button.c
index 47c6d000465a..0e2c7dfafd9f 100644
--- a/drivers/platform/x86/surfacepro3_button.c
+++ b/drivers/platform/x86/surfacepro3_button.c
@@ -20,6 +20,12 @@
#define SURFACE_BUTTON_OBJ_NAME "VGBI"
#define SURFACE_BUTTON_DEVICE_NAME "Surface Pro 3/4 Buttons"
+#define MSHW0040_DSM_REVISION 0x01
+#define MSHW0040_DSM_GET_OMPR 0x02 // get OEM Platform Revision
+static const guid_t MSHW0040_DSM_UUID =
+ GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
+ 0x49, 0x80, 0x35);
+
#define SURFACE_BUTTON_NOTIFY_TABLET_MODE 0xc8
#define SURFACE_BUTTON_NOTIFY_PRESS_POWER 0xc6
@@ -142,6 +148,34 @@ static int surface_button_resume(struct device *dev)
}
#endif
+/*
+ * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same device
+ * ID (MSHW0040) for the power/volume buttons. Make sure this is the right
+ * device by checking for the _DSM method and OEM Platform Revision.
+ */
+static int surface_button_check_MSHW0040(struct acpi_device *dev)
+{
+ acpi_handle handle = dev->handle;
+ union acpi_object *result;
+ u64 oem_platform_rev = 0;
+
+ // get OEM platform revision
+ result = acpi_evaluate_dsm_typed(handle, &MSHW0040_DSM_UUID,
+ MSHW0040_DSM_REVISION,
+ MSHW0040_DSM_GET_OMPR,
+ NULL, ACPI_TYPE_INTEGER);
+
+ if (result) {
+ oem_platform_rev = result->integer.value;
+ ACPI_FREE(result);
+ }
+
+ dev_dbg(&dev->dev, "OEM Platform Revision %llu\n", oem_platform_rev);
+
+ return oem_platform_rev == 0 ? 0 : -ENODEV;
+}
+
+
static int surface_button_add(struct acpi_device *device)
{
struct surface_button *button;
@@ -154,6 +188,10 @@ static int surface_button_add(struct acpi_device *device)
strlen(SURFACE_BUTTON_OBJ_NAME)))
return -ENODEV;
+ error = surface_button_check_MSHW0040(device);
+ if (error)
+ return error;
+
button = kzalloc(sizeof(struct surface_button), GFP_KERNEL);
if (!button)
return -ENOMEM;
--
2.22.0
^ permalink raw reply related
* [PATCH 0/2] Support for buttons on newer MS Surface devices
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
Benjamin Tissoires, Maximilian Luz
This series adds suport for power and volume buttons on 5th and 6th
generation Microsoft Surface devices. Specifically, it adds support for
the power-button on the Surface Laptop 1 and Laptop 2, as well as
support for power- and (on-device) volume-buttons on the Surface Pro 5
(2017), Pro 6, and Book 2.
These devices use the same MSHW0040 device as on the Surface Pro 4,
however, whereas the Pro 4 uses an ACPI notify handler, the newer
devices use GPIO interrupts to signal these events.
The first patch of this series ensures that the surfacepro3_button
driver, used for MSHW0040 on the Pro 4, does not probe for the newer
devices. The second patch adapts soc_button_array to implement the
actual button support.
I think the changes to soc_button_array in the second patch warrant a
thorough review. I've tried to make things a bit more generic to be able
to integrate arbitrary ACPI GPIO power-/volume-button devices more
easily, I'm not sure if there may be reasons against this.
These patches have also been tested on various Surface devices via the
github.com/jakeday/linux-surface patchset.
Maximilian Luz (2):
platform: Fix device check for surfacepro3_button
input: soc_button_array for newer surface devices
drivers/input/misc/soc_button_array.c | 134 ++++++++++++++++++++--
drivers/platform/x86/surfacepro3_button.c | 38 ++++++
2 files changed, 160 insertions(+), 12 deletions(-)
--
2.22.0
^ permalink raw reply
* [PATCH net] vxlan: do not destroy fdb if register_netdevice() is failed
From: Taehee Yoo @ 2019-06-20 11:51 UTC (permalink / raw)
To: davem, netdev; +Cc: ap420073
__vxlan_dev_create() destroys FDB using specific pointer which indicates
a fdb when error occurs.
But that pointer should not be used when register_netdevice() fails because
register_netdevice() internally destroys fdb when error occurs.
In order to avoid un-registered dev's notification, fdb destroying routine
checks dev's register status before notification.
Test command
ip link add bonding_masters type vxlan id 0 group 239.1.1.1 \
dev enp0s9 dstport 4789
Splat looks like:
[ 130.396714] kasan: CONFIG_KASAN_INLINE enabled
[ 130.397649] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ 130.398939] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 130.399829] CPU: 0 PID: 991 Comm: ip Not tainted 5.2.0-rc3+ #41
[ 130.401581] RIP: 0010:vxlan_fdb_destroy+0x120/0x220 [vxlan]
[ 130.402280] Code: df 48 8b 2b 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 06 01 00 00 4c 8b 63 08 48 b8 00 00 00 00d
[ 130.404578] RSP: 0018:ffff8880cfac7080 EFLAGS: 00010a02
[ 130.405235] RAX: dffffc0000000000 RBX: ffff8880d0613348 RCX: 0000000000000000
[ 130.406172] RDX: 1bd5a00000000040 RSI: ffff8880d0613348 RDI: ffff8880d0613350
[ 130.407056] RBP: 0000000000000000 R08: fffffbfff4378005 R09: 0000000000000000
[ 130.408011] R10: 00000000ffffffef R11: 0000000000000000 R12: dead000000000200
[ 130.408921] R13: ffff8880cfac71d8 R14: ffff8880b5d8cda0 R15: ffff8880b5d8cda0
[ 130.409811] FS: 00007f9ef157e0c0(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000
[ 130.410805] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 130.411515] CR2: 0000560fe8118d54 CR3: 00000000bc684006 CR4: 00000000000606f0
[ 130.412385] Call Trace:
[ 130.412708] __vxlan_dev_create+0x3a9/0x7d0 [vxlan]
[ 130.413314] ? vxlan_changelink+0x780/0x780 [vxlan]
[ 130.413919] ? rcu_read_unlock+0x60/0x60 [vxlan]
[ 130.414497] ? __kasan_kmalloc.constprop.3+0xa0/0xd0
[ 130.415112] vxlan_newlink+0x99/0xf0 [vxlan]
[ 130.415640] ? __vxlan_dev_create+0x7d0/0x7d0 [vxlan]
[ 130.416270] ? __netlink_ns_capable+0xc3/0xf0
[ 130.416806] __rtnl_newlink+0xb9f/0x11b0
[ ... ]
Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
drivers/net/vxlan.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 4c9bc29fe3d5..0bc07e3232c4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -861,7 +861,7 @@ static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
netdev_dbg(vxlan->dev, "delete %pM\n", f->eth_addr);
--vxlan->addrcnt;
- if (do_notify)
+ if (do_notify && vxlan->dev->reg_state >= NETREG_REGISTERED)
list_for_each_entry(rd, &f->remotes, list)
vxlan_fdb_notify(vxlan, f, rd, RTM_DELNEIGH,
swdev_notify, NULL);
@@ -3542,7 +3542,6 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_dev *vxlan = netdev_priv(dev);
struct vxlan_fdb *f = NULL;
- bool unregister = false;
int err;
err = vxlan_dev_configure(net, dev, conf, false, extack);
@@ -3567,8 +3566,7 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
err = register_netdevice(dev);
if (err)
- goto errout;
- unregister = true;
+ return err;
err = rtnl_configure_link(dev, NULL);
if (err)
@@ -3592,8 +3590,7 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
*/
if (f)
vxlan_fdb_destroy(vxlan, f, false, false);
- if (unregister)
- unregister_netdevice(dev);
+ unregister_netdevice(dev);
return err;
}
--
2.17.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/4] package: remove 'v' prefix from github-fetched packages
From: Victor Huesca @ 2019-06-20 11:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <35a7118e-cdf1-b29e-bceb-6c02ecef187e@mind.be>
On 19/06/2019 22:50, Arnout Vandecappelle wrote:
> Hi Victor,
>
> The good news is, I applied to master :-)
Glad to here that :D
> On 12/06/2019 08:42, Victor Huesca wrote:
>> On Github, a large number of projects name their tag vXYZ (i.e v3.0,
>> v0.1, etc.). In some packages we do:
>>
>> <pkg>_VERSION = v0.3
>> <pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
>>
>> And in some other packages we do:
>>
>> <pkg>_VERSION = 0.3
>> <pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
>>
>> I.e in one case we consider the version to be v0.3, in the other case
>> we consider 0.3 to be the version.
>>
>> The problem with v0.3 is that when used in conjunction with
>> release-monitoring.org, it doesn't work very well, because
>> release-monitoring.org has the concept of "version prefix" and using
>> that they drop the "v" prefix for the version.
>
> Note: I double-checked: apparently, release-monitoring really *never* has a v
> in front of the version. There are a few other things though, e.g. DIRECTFB_
As Thomas pointed out, packages that have a prefix in release-monitoring
are most likely to be wrong -- their may be some exception but I did not
see any up to now.
As a result we should modify their entry in release-monitoring rather
than adjust the buildroot version to the latter.
>> This commit only addresses the (common) case of github packages where
>> the prefix is simply 'v'. Other cases will be handled by separate
>> commits.
>
> As explained below, I have not applied this patch completely.
>
> But first, some general remarks about this patch, with an eye of improvements
> in your future contributions.
>
> First of all, this is an excellent commit message, good work on that!
>
> I guess this patch was created (at least partially) with some scripting. In
> such a case, it is a good idea to show the script(s) you used in the commit
> message. That way, it is possible for someone else to reproduce at least the
> mechanical part. Ideally, there would be three scripts: one to do the change,
> one to check if everything was changed, and one to do a test if things are still
> working after the change.
>
> For example, I used this script to test:
>
> git show --numstat | awk '{ print $3; }' | sed -n '/^package\//s///p' | \
> cut -d / -f 1 | uniq | \
> sed -e '/^\(faketime\|mfgtools\|ninja\|tegrarcm\)/s/^/host-/' \
> -e 's/$/-legal-info/' | xargs make
>
>
> Also, a huge patch like this is difficult to review. As shown below, review
> *is* still necessary, even for (mostly?) mechanical patches. Of course,
> splitting it per package is not an option. What you could have done, however, is
> to split it in commits with a diffstat of roughly +100-100. So in this case,
> split it in packages a-i, j-q, r-z. That makes it a little bit more grokkable.
Thank you for this advice :-)
I indeed used some scripts to automate the process of changing the
version and test these changes. I'll try to include the useful one the
next time I use one of them.
> [snip]
>> diff --git a/package/json-for-modern-cpp/json-for-modern-cpp.mk b/package/json-for-modern-cpp/json-for-modern-cpp.mk
>> index 09dbf30839..b3b029a5d0 100644
>> --- a/package/json-for-modern-cpp/json-for-modern-cpp.mk
>> +++ b/package/json-for-modern-cpp/json-for-modern-cpp.mk
>> @@ -4,9 +4,9 @@
>> #
>> ################################################################################
>>
>> -JSON_FOR_MODERN_CPP_VERSION = v3.6.1
>> -JSON_FOR_MODERN_CPP_SOURCE = json-$(JSON_FOR_MODERN_CPP_VERSION).tar.gz
>> -JSON_FOR_MODERN_CPP_SITE = $(call github,nlohmann,json,$(JSON_FOR_MODERN_CPP_VERSION))
>> +JSON_FOR_MODERN_CPP_VERSION = 3.6.1
>> +JSON_FOR_MODERN_CPP_SOURCE = json-v$(JSON_FOR_MODERN_CPP_VERSION).tar.gz
>
> I see what you did here: since there already was a _SOURCE definition, you
> changed it (instead of keeping the default value). However, I don't think that's
> the right thing to do. There really is no reason to not use the default _SOURCE
> for this package, AFAICS.
>
> In any case, because this one is special, it belongs to a separate patch so we
> can discuss it.
Ok, I had the same conclusion but I thought it was best to fist fix the
'v' prefix and then remove the unnecessary _SOURCE.
>> +JSON_FOR_MODERN_CPP_SITE = $(call github,nlohmann,json,v$(JSON_FOR_MODERN_CPP_VERSION))
>> JSON_FOR_MODERN_CPP_LICENSE = MIT
>> JSON_FOR_MODERN_CPP_LICENSE_FILES = LICENSE.MIT
>> JSON_FOR_MODERN_CPP_INSTALL_STAGING = YES
>
> [snip]
>> diff --git a/package/libpagekite/libpagekite.hash b/package/libpagekite/libpagekite.hash
>> index 262adc7aab..9923ae8771 100644
>> --- a/package/libpagekite/libpagekite.hash
>> +++ b/package/libpagekite/libpagekite.hash
>> @@ -1,7 +1,7 @@
>> # Locally calculated
>> -sha256 df95bfe95c04b6908e835e13444c1c1883765926f1265e0d2223c42d3c59a4c2 libpagekite-v0.91.171102.tar.gz
>> +sha256 df95bfe95c04b6908e835e13444c1c1883765926f1265e0d2223c42d3c59a4c2 libpagekite-0.91.171102.tar.gz
>>
>> # License files, locally calculated
>> sha256 ba443b9c9d4273d06aae3e147e9ad1ec199cc9c23455f486a039536d47f57eed doc/COPYING.md
>> sha256 4a271d0bb6bb6e0bac880efddb46da73e6df3dcf0d9ca08a945a232f8ab882ef doc/LICENSE-2.0.txt
>> -sha256 8e0f770cabe772d67d36469f6bf413afd2dcfa6ac37acfc65f770cf3a134106d doc/AGPLv3.txt
>> +sha256 8e0f770cabe772d67d36469f6bf413afd2dcfa6ac37acfc65f770cf3a134106d doc/AGPL3.txt
>
> That doesn't seem right...
Exact my script was a bit to aggressive on hash files, I fixed a lot of
these unwanted change but it looks like I forgot one of them.
> [snip]
>> diff --git a/package/python-scapy3k/python-scapy3k.hash b/package/python-scapy3k/python-scapy3k.hash
>> index 36d5dfed3c..57a636dd35 100644
>> --- a/package/python-scapy3k/python-scapy3k.hash
>> +++ b/package/python-scapy3k/python-scapy3k.hash
>> @@ -1,2 +1,2 @@
>> # Locally computed:
>> -sha256 a4c68ef2f787d82a3aec8640cac8dbab6f5b9e31ae4d89a1877efbb9150a9e25 python-scapy3k-v0.18.tar.gz
>> +sha256 a4c68ef2f787d82a3aec8640cac8dbab6f5b9e31ae4d89a1877efbb9150a9e25 python-scapy3k-0.18.tar.gz
>
> This one gave a hash mismatch. I don't know what's happening exactly and I was
> lazy, so I just reverted this one as well.
Now that you mention this one, it reminds me that I had noticed this
mismatch and added it in my todo-list... which I did not.
> Probably the github tarball has changed for some reason. We don't notice this
> because we can still download from sources.buildroot.org with the correct hash.
> However, the tarball without v doesn't exist there, so now it really fails.
>
> Since the name *also* changes, we can easily fix the changed hash in this case:
> "old" buildroot installs will still be able to download the old tarball (which
> is different) from sources.buildroot.org. "new" buildroot installs will download
> the new tarball from github, and eventually that one will also end up on
> sources.buildroot.org.
>
> However, we first should check why the hash has changed, i.e. what the
> differences between the two tarballs are.
I will investigate that and include it in a future patch.
>> diff --git a/package/softether/softether.mk b/package/softether/softether.mk
>> index 1a31abd4bd..a7a10c79c8 100644
>> --- a/package/softether/softether.mk
>> +++ b/package/softether/softether.mk
>> @@ -4,8 +4,8 @@
>> #
>> ################################################################################
>>
>> -SOFTETHER_VERSION = v4.28-9669-beta
>> -SOFTETHER_SITE = $(call github,SoftEtherVPN,SoftEtherVPN_stable,$(SOFTETHER_VERSION))
>> +SOFTETHER_VERSION = 4.28-9669-beta
>> +SOFTETHER_SITE = $(call github,SoftEtherVPN,SoftEtherVPN,v$(SOFTETHER_VERSION))
>> SOFTETHER_LICENSE = GPL-2.0
>> SOFTETHER_LICENSE_FILES = LICENSE
>> SOFTETHER_DEPENDENCIES = host-pkgconf host-softether libopenssl readline
>
> This one doesn't exist anyore on github (I guess the tag has been removed), we
> always download it from sources.buildroot.org. So here, I think the workaround
> (except for bumping the version) is to set SOFTETHER_SOURCE to the old name, so
> the download from sources.buildroot.org still works. Alternatively, we can ask
> Peter to copy the tarball to the new name before this one is applied.
If we update the _SOURCE, a simple hardlink should be enough if space
disk usage is a concern.
> In conclusion, the following packages have *not* been updated: flatbuffers,
> json-for-modern-cpp, libpagekite, python-scapy3k, softether. There might also be
> new packages that are not yet included in this patch, so please check that.
>
> It would also be nice if we had some formal way of checking that new packages
> do this correctly. Actually, it would be good if pkg-stats could generate a
> report in a human-readable format so it could be used as part of the review flow
> to check if the mapping with release-monitoring is OK (plus all the other things
> pkg-stats evaluates).
It would be great :)
Regards,
Victor
--
Victor Huesca, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 2/2] input: soc_button_array for newer surface devices
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
Benjamin Tissoires, Maximilian Luz
In-Reply-To: <20190620115056.4169-1-luzmaximilian@gmail.com>
Power and volume button support for 5th and 6th genration Microsoft
Surface devices via soc_button_array.
Note that these devices use the same MSHW0040 device as on the Surface
Pro 4, however the implementation is different (GPIOs vs. ACPI
notifications). Thus some checking is required to ensure we only load
this driver on the correct devices.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
---
drivers/input/misc/soc_button_array.c | 134 +++++++++++++++++++++++---
1 file changed, 122 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 5e59f8e57f8e..157f53a2bd51 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -25,6 +25,17 @@ struct soc_button_info {
bool wakeup;
};
+/**
+ * struct soc_device_data - driver data for different device types
+ * @button_info: specifications of buttons, if NULL specification is assumed to
+ * be present in _DSD
+ * @check: device-specific check (NULL means all will be accepted)
+ */
+struct soc_device_data {
+ struct soc_button_info *button_info;
+ int (*check)(struct device *dev);
+};
+
/*
* Some of the buttons like volume up/down are auto repeat, while others
* are not. To support both, we register two platform devices, and put
@@ -310,6 +321,7 @@ static int soc_button_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
const struct acpi_device_id *id;
+ struct soc_device_data *device_data;
struct soc_button_info *button_info;
struct soc_button_data *priv;
struct platform_device *pd;
@@ -320,18 +332,20 @@ static int soc_button_probe(struct platform_device *pdev)
if (!id)
return -ENODEV;
- if (!id->driver_data) {
+ device_data = (struct soc_device_data *)id->driver_data;
+ if (device_data && device_data->check) {
+ error = device_data->check(dev);
+ if (error)
+ return error;
+ }
+
+ if (device_data && device_data->button_info) {
+ button_info = (struct soc_button_info *)
+ device_data->button_info;
+ } else {
button_info = soc_button_get_button_info(dev);
if (IS_ERR(button_info))
return PTR_ERR(button_info);
- } else {
- button_info = (struct soc_button_info *)id->driver_data;
- }
-
- error = gpiod_count(dev, NULL);
- if (error < 0) {
- dev_dbg(dev, "no GPIO attached, ignoring...\n");
- return -ENODEV;
}
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -357,12 +371,32 @@ static int soc_button_probe(struct platform_device *pdev)
if (!priv->children[0] && !priv->children[1])
return -ENODEV;
- if (!id->driver_data)
+ if (!device_data || !device_data->button_info)
devm_kfree(dev, button_info);
return 0;
}
+
+static int soc_device_check_generic(struct device *dev)
+{
+ int gpios;
+
+ gpios = gpiod_count(dev, NULL);
+ if (gpios < 0) {
+ dev_dbg(dev, "no GPIO attached, ignoring...\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static struct soc_device_data soc_device_ACPI0011 = {
+ .button_info = NULL,
+ .check = soc_device_check_generic,
+};
+
+
/*
* Definition of buttons on the tablet. The ACPI index of each button
* is defined in section 2.8.7.2 of "Windows ACPI Design Guide for SoC
@@ -377,9 +411,85 @@ static struct soc_button_info soc_button_PNP0C40[] = {
{ }
};
+static struct soc_device_data soc_device_PNP0C40 = {
+ .button_info = soc_button_PNP0C40,
+ .check = soc_device_check_generic,
+};
+
+
+/*
+ * Special device check for Surface Book 2 and Surface Pro (2017).
+ * Both, the Surface Pro 4 (surfacepro3_button.c) and the above mentioned
+ * devices use MSHW0040 for power and volume buttons, however the way they
+ * have to be addressed differs. Make sure that we only load this drivers
+ * for the correct devices by checking the OEM Platform Revision provided by
+ * the _DSM method.
+ */
+#define MSHW0040_DSM_REVISION 0x01
+#define MSHW0040_DSM_GET_OMPR 0x02 // get OEM Platform Revision
+static const guid_t MSHW0040_DSM_UUID =
+ GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
+ 0x49, 0x80, 0x35);
+
+static int soc_device_check_MSHW0040(struct device *dev)
+{
+ acpi_handle handle = ACPI_HANDLE(dev);
+ union acpi_object *result;
+ u64 oem_platform_rev = 0;
+ int gpios;
+
+ // get OEM platform revision
+ result = acpi_evaluate_dsm_typed(handle, &MSHW0040_DSM_UUID,
+ MSHW0040_DSM_REVISION,
+ MSHW0040_DSM_GET_OMPR, NULL,
+ ACPI_TYPE_INTEGER);
+
+ if (result) {
+ oem_platform_rev = result->integer.value;
+ ACPI_FREE(result);
+ }
+
+ if (oem_platform_rev == 0)
+ return -ENODEV;
+
+ dev_dbg(dev, "OEM Platform Revision %llu\n", oem_platform_rev);
+
+ /*
+ * We are _really_ expecting GPIOs here. If we do not get any, this
+ * means the GPIO driver has not been loaded yet (which can happen).
+ * Try again later.
+ */
+ gpios = gpiod_count(dev, NULL);
+ if (gpios < 0)
+ return -EAGAIN;
+
+ return 0;
+}
+
+/*
+ * Button infos for Microsoft Surface Book 2 and Surface Pro (2017).
+ * Obtained from DSDT/testing.
+ */
+static struct soc_button_info soc_button_MSHW0040[] = {
+ { "power", 0, EV_KEY, KEY_POWER, false, true },
+ { "volume_up", 2, EV_KEY, KEY_VOLUMEUP, true, false },
+ { "volume_down", 4, EV_KEY, KEY_VOLUMEDOWN, true, false },
+ { }
+};
+
+static struct soc_device_data soc_device_MSHW0040 = {
+ .button_info = soc_button_MSHW0040,
+ .check = soc_device_check_MSHW0040,
+};
+
+
static const struct acpi_device_id soc_button_acpi_match[] = {
- { "PNP0C40", (unsigned long)soc_button_PNP0C40 },
- { "ACPI0011", 0 },
+ { "PNP0C40", (unsigned long)&soc_device_PNP0C40 },
+ { "ACPI0011", (unsigned long)&soc_device_ACPI0011 },
+
+ /* Microsoft Surface Devices (5th and 6th generation) */
+ { "MSHW0040", (unsigned long)&soc_device_MSHW0040 },
+
{ }
};
--
2.22.0
^ permalink raw reply related
* [PATCH 1/2] platform: Fix device check for surfacepro3_button
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
Benjamin Tissoires, Maximilian Luz
In-Reply-To: <20190620115056.4169-1-luzmaximilian@gmail.com>
Do not use the surfacepro3_button driver on newer Microsoft Surface
models, only use it on the Surface Pro 3 and 4. Newer models (5th, 6th
and possibly future generations) use the same device as the Surface Pro
4 to represent their volume and power buttons (MSHW0040), but their
acutal implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
---
drivers/platform/x86/surfacepro3_button.c | 38 +++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/platform/x86/surfacepro3_button.c b/drivers/platform/x86/surfacepro3_button.c
index 47c6d000465a..0e2c7dfafd9f 100644
--- a/drivers/platform/x86/surfacepro3_button.c
+++ b/drivers/platform/x86/surfacepro3_button.c
@@ -20,6 +20,12 @@
#define SURFACE_BUTTON_OBJ_NAME "VGBI"
#define SURFACE_BUTTON_DEVICE_NAME "Surface Pro 3/4 Buttons"
+#define MSHW0040_DSM_REVISION 0x01
+#define MSHW0040_DSM_GET_OMPR 0x02 // get OEM Platform Revision
+static const guid_t MSHW0040_DSM_UUID =
+ GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
+ 0x49, 0x80, 0x35);
+
#define SURFACE_BUTTON_NOTIFY_TABLET_MODE 0xc8
#define SURFACE_BUTTON_NOTIFY_PRESS_POWER 0xc6
@@ -142,6 +148,34 @@ static int surface_button_resume(struct device *dev)
}
#endif
+/*
+ * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same device
+ * ID (MSHW0040) for the power/volume buttons. Make sure this is the right
+ * device by checking for the _DSM method and OEM Platform Revision.
+ */
+static int surface_button_check_MSHW0040(struct acpi_device *dev)
+{
+ acpi_handle handle = dev->handle;
+ union acpi_object *result;
+ u64 oem_platform_rev = 0;
+
+ // get OEM platform revision
+ result = acpi_evaluate_dsm_typed(handle, &MSHW0040_DSM_UUID,
+ MSHW0040_DSM_REVISION,
+ MSHW0040_DSM_GET_OMPR,
+ NULL, ACPI_TYPE_INTEGER);
+
+ if (result) {
+ oem_platform_rev = result->integer.value;
+ ACPI_FREE(result);
+ }
+
+ dev_dbg(&dev->dev, "OEM Platform Revision %llu\n", oem_platform_rev);
+
+ return oem_platform_rev == 0 ? 0 : -ENODEV;
+}
+
+
static int surface_button_add(struct acpi_device *device)
{
struct surface_button *button;
@@ -154,6 +188,10 @@ static int surface_button_add(struct acpi_device *device)
strlen(SURFACE_BUTTON_OBJ_NAME)))
return -ENODEV;
+ error = surface_button_check_MSHW0040(device);
+ if (error)
+ return error;
+
button = kzalloc(sizeof(struct surface_button), GFP_KERNEL);
if (!button)
return -ENOMEM;
--
2.22.0
^ permalink raw reply related
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.