* Re: [PATCH v5 3/4] clk: lpc32xx: Set name of regmap_config
From: Vladimir Zapolskiy @ 2018-03-18 21:57 UTC (permalink / raw)
To: Jeffy Chen, linux-kernel, broonie, alexandre.belloni
Cc: Kate Stewart, Mark Rutland, Emil Renner Berthing, stephen lu,
Catalin Marinas, Michael Turquette, Will Deacon,
Alexandre Belloni, Joseph Lo, lee.jones, linux-clk,
Heiko Stuebner, Brian Norris, linux-rockchip, Matthias Kaehlcke,
linux-input, Arvind Yadav, Jerome Brunet, Guenter Roeck,
devicetree, Arnd Bergmann, Sylvain Lemieux, Rob Herring,
Thomas Gleixner
In-Reply-To: <20180312095142.30854-4-jeffy.chen@rock-chips.com>
Hi Jeffy,
On 03/12/2018 11:51 AM, Jeffy Chen wrote:
> We are now allowing to register debugfs without a valid device, and not
> having a valid name will end up using "dummy*" to create debugfs dir.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
>
> drivers/clk/nxp/clk-lpc32xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
> index f5d815f577e0..a2a0a7f3bc57 100644
> --- a/drivers/clk/nxp/clk-lpc32xx.c
> +++ b/drivers/clk/nxp/clk-lpc32xx.c
> @@ -67,6 +67,7 @@
> #define LPC32XX_USB_CLK_STS 0xF8
>
> static struct regmap_config lpc32xx_scb_regmap_config = {
> + .name = "lpc32xx-scb",
please rename it to "scb", LPC32xx SoC name is already known from the context.
When it's done, feel free to add to the next version my
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = 4,
>
Thank you for the change.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Rasmus Villemoes @ 2018-03-18 22:59 UTC (permalink / raw)
To: Linus Torvalds, Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, David Laight, Ian Abbott,
linux-input, linux-btrfs, Network Development,
Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <CA+55aFwFoTapX2niPiaET5kg7K85qxhav1_PoDDxY0o_VRA5Ag@mail.gmail.com>
On 2018-03-18 22:33, Linus Torvalds wrote:
> On Sun, Mar 18, 2018 at 2:13 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>> On 2018-03-17 19:52, Linus Torvalds wrote:
>>>
>>> Ok, so it really looks like that same "__builtin_constant_p() doesn't
>>> return a constant".
>>>
>>> Which is really odd, but there you have it.
>>
>> Not really. We do rely on builtin_constant_p not being folded too
>> quickly to a 0/1 answer, so that gcc still generates good code even if
>> the argument is only known to be constant at a late(r) optimization
>> stage (through inlining and all).
>
> Hmm. That makes sense. It just doesn't work for our case when we
> really want to choose the expression based on side effects or not.
>
>> So unlike types_compatible_p, which
>> can obviously be answered early during parsing, builtin_constant_p is
>> most of the time a yes/no/maybe/it's complicated thing.
>
> The silly thing is, the thing we *really* want to know _is_ actually
> easily accessible during the early parsing, exactly like
> __builtin_compatible_p(): it's not really that we care about the
> expressions being constant, as much as the "can this have side
> effects" question.
OK, I missed where this was made about side effects of x and y, but I
suppose the idea was to use
no_side_effects(x) && no_side_effects(y) ? trivial_max(x, y) :
old_max(x, y)
or the same thing spelled with b_c_e? Yes, I think that would work, if
we indeed had that way of checking an expression.
> We only really use __builtin_constant_p() as a (bad) approximation of
> that in this case, since it's the best we can do.
I don't think you should parenthesize bad, rather capitalize it. ({x++;
0;}) is constant in the eyes of __builtin_constant_p, but not
side-effect free. Sure, that's very contrived, but I can easily imagine
some max(f(foo), -1) call where f is sometimes an external function, but
for other .configs it's a static inline that always returns 0, but still
has some non-trivial side-effect before that. And this would all depend
on which optimizations gcc applies before it decides to evaluate
builtin_constant_p, so could be some fun debugging. Good thing that that
didn't work out...
> So the real use would be to say "can we use the simple direct macro
> that just happens to also fold into a nice integer constant
> expression" for __builtin_choose_expr().
>
> I tried to find something like that, but it really doesn't exist, even
> though I would actually have expected it to be a somewhat common
> concern for macro writers: write a macro that works in any arbitrary
> environment.
Yeah, I think the closest is a five year old suggestion
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612) to add a
__builtin_assert_no_side_effects, that could be used in macros that for
some reason cannot be implemented without evaluating some argument
multiple times. It would be more useful to have the predicate version,
which one could always turn into a build bug version. But we have
neither, unfortunately.
Rasmus
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Linus Torvalds @ 2018-03-18 23:36 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, David Laight, Ian Abbott,
linux-input, linux-btrfs, Network Development,
Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <38b6da49-1138-017e-7307-f39ff067d6d2@rasmusvillemoes.dk>
On Sun, Mar 18, 2018 at 3:59 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> OK, I missed where this was made about side effects of x and y
We never made it explicit, since all we really cared about in the end
is the constantness.
But yes:
> but I suppose the idea was to use
>
> no_side_effects(x) && no_side_effects(y) ? trivial_max(x, y) :
> old_max(x, y)
Exactly. Except with __builtin_choose_expr(), because we need the end
result to be seen as a integer constant expression, so that we can
then use it as an array size. So it needs that early parse-time
resolution.
>> We only really use __builtin_constant_p() as a (bad) approximation of
>> that in this case, since it's the best we can do.
>
> I don't think you should parenthesize bad, rather capitalize it. ({x++;
> 0;}) is constant in the eyes of __builtin_constant_p, but not
> side-effect free.
Hmm. Yeah, but probably don't much care for the kernel.
For example, we do things like this:
#define __swab64(x) \
(__builtin_constant_p((__u64)(x)) ? \
___constant_swab64(x) : \
__fswab64(x))
where that "___constant_swab64()" very much uses the same argument
over and over.
And we do that for related reasons - we really want to do the constant
folding at build time for some cases, and this was the only sane way
to do it. Eg code like
return (addr & htonl(0xff000000)) == htonl(0x7f000000);
wants to do the right thing, and long ago gcc didn't have builtins for
byte swapping, so we had to just do nasty horribly macros that DTRT
for constants.
But since the kernel is standalone, we don't need to really worry
about the *generic* case, we just need to worry about our own macros,
and if somebody does that example you show I guess we'll just have to
shun them ;)
Of course, our own macros are often macros from hell, exactly because
they often contain a lot of type-checking and/or type-(size)-based
polymorphism. But then we actually *want* gcc to simplify things, and
avoid side effects, just have potentially very complex expressions.
But we basically never have that kind of intentionally evil macros, so
we are willing to live with a bad substitute.
But yes, it would be better to have some more control over things, and
actually have a way to say "if X is a constant integer expression, do
transformation Y, otherwise call function y()".
Actually sparse started out with the idea in the background that it
could become not just a checker, but a "transformation tool". Partly
because of long gone historical issues (ie gcc people used to be very
anti-plugin due to licensing issues).
Of course, a more integrated and powerful preprocessor language is
almost always what we *really* wanted, but traditionally "powerful
preprocessor" has always meant "completely incomprehensible and badly
integrated preprocessor".
"cpp" may be a horrid language, but it's there and it's fast (when
integrated with the front-end, like everybody does now)
But sadly, cpp is really bad for the above kind of "if argument is
constant" kind of tricks. I suspect we'd use it a lot otherwise.
>> So the real use would be to say "can we use the simple direct macro
>> that just happens to also fold into a nice integer constant
>> expression" for __builtin_choose_expr().
>>
>> I tried to find something like that, but it really doesn't exist, even
>> though I would actually have expected it to be a somewhat common
>> concern for macro writers: write a macro that works in any arbitrary
>> environment.
>
> Yeah, I think the closest is a five year old suggestion
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612) to add a
> __builtin_assert_no_side_effects, that could be used in macros that for
> some reason cannot be implemented without evaluating some argument
> multiple times. It would be more useful to have the predicate version,
> which one could always turn into a build bug version. But we have
> neither, unfortunately.
Yeah, and since we're in the situation that *new* gcc versions work
for us anyway, and we only have issues with older gcc's (that sadly
people still use), even if there was a new cool feature we couldn't
use it.
Oh well. Thanks for the background.
Linus
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: lpc32xx: Set name of regmap_config
From: JeffyChen @ 2018-03-19 3:59 UTC (permalink / raw)
To: Vladimir Zapolskiy, linux-kernel, broonie, alexandre.belloni
Cc: Guenter Roeck, Arnd Bergmann, Joseph Lo, Rob Herring,
Catalin Marinas, lee.jones, Emil Renner Berthing, Heiko Stuebner,
Brian Norris, Thomas Gleixner, Philippe Ombredanne,
linux-rockchip, Kate Stewart, linux-input, Will Deacon,
Matthias Kaehlcke, devicetree, stephen lu, Greg Kroah-Hartman,
Arvind Yadav, linux-arm-kernel
In-Reply-To: <23a9cbf8-9b1d-f7ec-b980-a16c9b2c4d84@mleia.com>
Hi Vladimir,
On 03/19/2018 05:57 AM, Vladimir Zapolskiy wrote:
>> > static struct regmap_config lpc32xx_scb_regmap_config = {
>> >+ .name = "lpc32xx-scb",
> please rename it to "scb", LPC32xx SoC name is already known from the context.
>
> When it's done, feel free to add to the next version my
>
> Acked-by: Vladimir Zapolskiy<vz@mleia.com>
>
ok, will do, thanks:)
^ permalink raw reply
* RE: [PATCH] Input: alps - Demystify trackstick initialization for v3 and v6 protocols
From: Masaki Ota @ 2018-03-19 8:41 UTC (permalink / raw)
To: Pali Rohár
Cc: Dmitry Torokhov, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180316105811.t2nkwowqs66f6ji6@pali>
Hi, Pali,
v3/v6 devices are T3 type, and it can use only Method 2.
P36 (At this time GLIDEPOINT_T3 uses the Method 2 ....)
T3 has the potential that uses Method2, but I think it needs to change Firmware.
Best Regards,
Masaki Ota
-----Original Message-----
From: Pali Rohár [mailto:pali.rohar@gmail.com]
Sent: Friday, March 16, 2018 7:58 PM
To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: alps - Demystify trackstick initialization for v3 and v6 protocols
Great, thank you. Enabling that RAW/extended/SP4 mode is done by sequence E6, E6, E6, F3, C8, F3, 14 (written in page 35) and it matches what function alps_trackstick_enter_extended_mode_v3_v6() in my patch is doing. So is correct.
On page 36 I see that there is described Method 1 for reporting stick data which prevents cursor jumps. Seems that kernel uses Method 2.
Method 1 depends on some prioritization.
Do you have some information how to activate Method 1? Sometimes I observe that problem with "cursor jumps" and from Method 1 could prevent it. So I would like to try experimenting...
On Wednesday 14 March 2018 23:56:46 Masaki Ota wrote:
> Hi, Pali,
>
> I have added Appendix.
> According to this spec documents, SP raw mode is SP 4 byte mode.
> I think Extended mode meaning is almost all the same as Raw mode.
> The description of how to set is written in Page 35.
>
> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Thursday, March 15, 2018 7:58 AM
> To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>;
> linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Input: alps - Demystify trackstick initialization
> for v3 and v6 protocols
>
> Hi! Thank you for information.
>
> Your PS/2 Aux Port Control description seems to really matches. Just there is reverse order of bits. Bit 0 in description is highest, therefore matches BIT(7) macro.
>
> Bit 6 in description (BIT(1) in code) describes SP Extended Mode which alps.c enabled. And in that description is written:
>
> "If 1 SP is extended packet format (driver must set SP raw mode and GP absolute mode)."
>
> Do you have any idea what "SP raw mode" is? How to set it? For me it looks like it could be that extended mode of trackstick itself.
>
> "GP absolute mode" I guess is GlidePoint absolute mode, therefore
> enable
> 6 byte absolute mode for touchpad.
>
> And for Bit 7 (BIT(0)) is written:
>
> This bit is used with the PS/2 Aux port to use the Pass-Thru mode ( see appendix A ). Do you have some information about this appendix A?
>
> On Wednesday 14 March 2018 10:21:43 Masaki Ota wrote:
> > Hi, Pali,
> >
> > I just picked up the spec which relates with trackstic.
> >
> > Best Regards,
> > Masaki Ota
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Tuesday, March 13, 2018 8:14 AM
> > To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov
> > <dmitry.torokhov@gmail.com>
> > Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] Input: alps - Demystify trackstick
> > initialization for v3 and v6 protocols
> >
> > Masaki, if you have access to the internal ALPS v3 / Rushmore
> > documentation, I would like to have a review of this patch or
> > confirmation of those information :-)
>
> --
> Pali Rohár
> pali.rohar@gmail.com
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: David Laight @ 2018-03-19 9:43 UTC (permalink / raw)
To: 'Linus Torvalds', Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, Ian Abbott, linux-input,
linux-btrfs, Network Development, Linux Kernel Mailing List,
Kernel Hardening
In-Reply-To: <CA+55aFw0WC+S3TTE6x_vkLbRV6YLeR4-1S9LsBXhE+E2KZqBuA@mail.gmail.com>
From: linus971@gmail.com [mailto:linus971@gmail.com] On Behalf Of Linus Torvalds
> Sent: 18 March 2018 23:36
...
>
> Yeah, and since we're in the situation that *new* gcc versions work
> for us anyway, and we only have issues with older gcc's (that sadly
> people still use), even if there was a new cool feature we couldn't
> use it.
Is it necessary to have the full checks for old versions of gcc?
Even -Wvla could be predicated on very recent gcc - since we aren't
worried about whether gcc decides to generate a vla, but whether
the source requests one.
David
^ permalink raw reply
* Re: [PATCH v5 2/2] Remove false-positive VLAs when using max()
From: Andrey Ryabinin @ 2018-03-19 10:45 UTC (permalink / raw)
To: Kees Cook, Andrew Morton
Cc: Linus Torvalds, Josh Poimboeuf, Rasmus Villemoes, Randy Dunlap,
Miguel Ojeda, Ingo Molnar, David Laight, Ian Abbott, linux-input,
linux-btrfs, netdev, linux-kernel, kernel-hardening
In-Reply-To: <1521174359-46392-3-git-send-email-keescook@chromium.org>
On 03/16/2018 07:25 AM, Kees Cook wrote:
> As part of removing VLAs from the kernel[1], we want to build with -Wvla,
> but it is overly pessimistic and only accepts constant expressions for
> stack array sizes, instead of also constant values. The max() macro
> triggers the warning, so this refactors these uses of max() to use the
> new const_max() instead.
>
> [1] https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/input/touchscreen/cyttsp4_core.c | 2 +-
> fs/btrfs/tree-checker.c | 3 ++-
> lib/vsprintf.c | 5 +++--
> net/ipv4/proc.c | 8 ++++----
> net/ipv6/proc.c | 11 +++++------
> 5 files changed, 15 insertions(+), 14 deletions(-)
>
FWIW, the patch below is alternative way to deal with these (Note, I didn't test my patch, just demonstrating the idea).
It's quite simple, and should work on any gcc version.
This approach wouldn't work well for CONFIG dependent max values, especially in case of single constant
expression being dependent on several config options, but it seems we don't have any these.
drivers/input/touchscreen/cyttsp4_core.c | 3 ++-
fs/btrfs/tree-checker.c | 3 ++-
lib/vsprintf.c | 6 ++++--
net/ipv4/proc.c | 4 +++-
net/ipv6/proc.c | 6 ++++--
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
index 727c3232517c..ce546a3fad3d 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -868,7 +868,8 @@ static void cyttsp4_get_mt_touches(struct cyttsp4_mt_data *md, int num_cur_tch)
struct cyttsp4_touch tch;
int sig;
int i, j, t = 0;
- int ids[max(CY_TMA1036_MAX_TCH, CY_TMA4XX_MAX_TCH)];
+ int ids[CY_TMA4XX_MAX_TCH];
+ BUILD_BUG_ON(CY_TMA1036_MAX_TCH > CY_TMA4XX_MAX_TCH);
memset(ids, 0, si->si_ofs.tch_abs[CY_TCH_T].max * sizeof(int));
for (i = 0; i < num_cur_tch; i++) {
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index 8871286c1a91..ad4c2fea572f 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -346,7 +346,8 @@ static int check_dir_item(struct btrfs_fs_info *fs_info,
*/
if (key->type == BTRFS_DIR_ITEM_KEY ||
key->type == BTRFS_XATTR_ITEM_KEY) {
- char namebuf[max(BTRFS_NAME_LEN, XATTR_NAME_MAX)];
+ char namebuf[BTRFS_NAME_LEN];
+ BUILD_BUG_ON(XATTR_NAME_MAX > BTRFS_NAME_LEN);
read_extent_buffer(leaf, namebuf,
(unsigned long)(di + 1), name_len);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 942b5234a59b..fa081d684660 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -754,13 +754,15 @@ char *resource_string(char *buf, char *end, struct resource *res,
#define FLAG_BUF_SIZE (2 * sizeof(res->flags))
#define DECODED_BUF_SIZE sizeof("[mem - 64bit pref window disabled]")
#define RAW_BUF_SIZE sizeof("[mem - flags 0x]")
- char sym[max(2*RSRC_BUF_SIZE + DECODED_BUF_SIZE,
- 2*RSRC_BUF_SIZE + FLAG_BUF_SIZE + RAW_BUF_SIZE)];
+ char sym[2*RSRC_BUF_SIZE + DECODED_BUF_SIZE];
char *p = sym, *pend = sym + sizeof(sym);
int decode = (fmt[0] == 'R') ? 1 : 0;
const struct printf_spec *specp;
+ BUILD_BUG_ON((2*RSRC_BUF_SIZE + FLAG_BUF_SIZE + RAW_BUF_SIZE) >
+ (2*RSRC_BUF_SIZE + DECODED_BUF_SIZE));
+
*p++ = '[';
if (res->flags & IORESOURCE_IO) {
p = string(p, pend, "io ", str_spec);
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index d97e83b2dd33..9d08749de8d0 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -46,7 +46,7 @@
#include <net/sock.h>
#include <net/raw.h>
-#define TCPUDP_MIB_MAX max_t(u32, UDP_MIB_MAX, TCP_MIB_MAX)
+#define TCPUDP_MIB_MAX TCP_MIB_MAX
/*
* Report socket allocation statistics [mea@utu.fi]
@@ -404,6 +404,8 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
struct net *net = seq->private;
int i;
+ BUILD_BUG_ON(UDP_MIB_MAX > TCP_MIB_MAX);
+
memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
seq_puts(seq, "\nTcp:");
diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index 1678cf037688..3ad91dae7324 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -32,8 +32,7 @@
#define MAX4(a, b, c, d) \
max_t(u32, max_t(u32, a, b), max_t(u32, c, d))
-#define SNMP_MIB_MAX MAX4(UDP_MIB_MAX, TCP_MIB_MAX, \
- IPSTATS_MIB_MAX, ICMP_MIB_MAX)
+#define SNMP_MIB_MAX IPSTATS_MIB_MAX
static int sockstat6_seq_show(struct seq_file *seq, void *v)
{
@@ -198,6 +197,9 @@ static void snmp6_seq_show_item(struct seq_file *seq, void __percpu *pcpumib,
unsigned long buff[SNMP_MIB_MAX];
int i;
+ BUILD_BUG_ON(MAX4(UDP_MIB_MAX, TCP_MIB_MAX,
+ IPSTATS_MIB_MAX, ICMP_MIB_MAX) > SNMP_MIB_MAX);
+
if (pcpumib) {
memset(buff, 0, sizeof(unsigned long) * SNMP_MIB_MAX);
--
2.16.1
^ permalink raw reply related
* Re: [PATCH v5 0/4] new driver for Valve Steam Controller
From: Rodrigo Rivas Costa @ 2018-03-19 20:08 UTC (permalink / raw)
To: Pierre-Loup A. Griffais
Cc: Benjamin Tissoires, Clément VUCHENER, Jiri Kosina,
Cameron Gutman, lkml, linux-input
In-Reply-To: <1c75c511-eada-585e-297f-e90feb17ac8c@valvesoftware.com>
On Sat, Mar 17, 2018 at 02:54:07PM -0700, Pierre-Loup A. Griffais wrote:
>
>
> On 03/15/2018 02:06 PM, Rodrigo Rivas Costa wrote:
> > On Wed, Mar 14, 2018 at 05:39:25PM +0100, Benjamin Tissoires wrote:
> > > On Mon, Mar 12, 2018 at 9:51 PM, Rodrigo Rivas Costa
> > > <rodrigorivascosta@gmail.com> wrote:
> > > > On Mon, Mar 12, 2018 at 03:30:43PM +0100, Clément VUCHENER wrote:
> > > > > 2018-03-11 20:58 GMT+01:00 Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>:
> > > > > > This patchset implements a driver for Valve Steam Controller, based on a
> > > > > > reverse analysis by myself.
> > > > > >
> > > > > > Sorry, I've been out of town for a few weeks and couldn't keep up with this...
> > > > > >
> > > > > > @Pierre-Loup and @Clément, could you please have another look at this and
> > > > > > check if it is worthy? Benjamin will not commit it without an express ACK from
> > > > > > Valve. Of course he is right to be cautious, but I checked this driver with
> > > > > > the Steam Client and all seems to go just fine. I think that there is a lot of
> > > > > > Linux out of the desktop that could use this driver and cannot use the Steam
> > > > > > Client. Worst case scenario, this driver can now be blacklisted, but I hope
> > > > > > that will not be needed.
> > > > >
> > > > > I tested the driver with my 4.15 fedora kernel (I only built the
> > > > > module not the whole kernel) and I got double inputs (your driver
> > > > > input device + steam uinput device) when testing Shovel Knight with
> > > > > Steam Big Picture. It seems to work fine when the inputs are the same,
> > > > > but after changing the controller configuration in Steam, the issue
> > > > > became apparent.
> > > >
> > > > I assumed that when several joysticks are available, games would listen
> > > > to one one of them. It looks like I'm wrong, and some (many?) games will
> > > > listen to all available joysticks at the same time. Thus having two
> > > > logical joysticks that represent the same physical one is not good.
> > >
> > > Yeah, the general rule of thumb is "think of the worst thing that can
> > > happen, someone will do something worst".
> > >
> > > >
> > > > An easy solution would be that Steam Client grabs this driver
> > > > (ioctl(EVIOCGRAB)) when creating the uinput device. Another solution
> > > > would be that Steam Client blacklists this driver, of course.
> > >
> > > This is 2 solutions that rely on a userspace change, and this is not
> > > acceptable in its current form. What if people do not upgrade Steam
> > > client but upgrade their kernel? Well, Steam might be able to force
> > > people to always run the latest shiny available version, but for other
> > > games, you can't expect people to have a compatible version of the
> > > userspace stack.
> >
> > Well, if you don't have Steam then you don't have the double input in
> > the first place. Unless you are using a different user-mode driver, of
> > course.
> > >
> > > Also, "blacklisting the driver" from Steam client is something the OS
> > > can do, but not the client when you run on a different distribution.
> > > You need root for that, and I don't want to give root permissions to
> > > Steam (or to any user space client that shouldn't have root privileges
> > > for what it matters).
> >
> > Actually Steam needs a system installation that adds udev rules to grant
> > uaccess to /dev/uinput and the USB raw device for the controller.
> > Adding a /etc/modprobe.d/steam.conf should be possible, too. It would be
> > a bit inconvenient because you'll need a distro update of the steam
> > package, not just the usual user-mode-only auto-update.
>
> It's definitely a bit tricky; we've rolled out an update to our reference
> package whenever we've added support for new devices (the final Steam
> Controller, direct PS4 gamepad led/gyro access through HID, HTC Vive and its
> myriad of onboard devices, bootloaders of all these things for firmware
> updates, etc). Whenever we have to do that, the rollout never is as smooth
> as desired: many users aren't using our own package; even on the
> distributions we support directly. Then downstream distributions adopt these
> udev changes with various delays (sometimes never), and port them to their
> own mechanism of doing things, since everyone has their own idea of a robust
> security model. I wish local sessions always had proper access to HID
> devices connected to the physical computer the user is sitting at, but I
> realize that the basic gaming desktop is just one of many usecases distros
> out there have to support and it'd be unreasonable to expect them to focus
> exclusively on it.
I was afraid of something like that. Let's forget about that option for
the moment.
> > > > > And without Steam and your external tool, you get double inputs too. I
> > > > > tried RetroArch and it was unusable because of the keyboard inputs
> > > > > from the lizard mode (e.g. pressing B also presses Esc and quits
> > > > > RetroArch). Having to download and compile an external tool to make
> > > > > the driver work properly may be too difficult for the user. Your goal
> > > > > was to provide an alternative to user space drivers but now you
> > > > > actually depend on (a very simple) one.
> > > >
> > > > Yes, I noticed that. TBH, this driver without Steam Client or the
> > > > user-space tool is not very nice, precisely because you'll get constant
> > > > Escape and Enter presses, and most games react to those.
> > > >
> > > > Frankly speaking, I'm not sure how to proceed. I can think of the
> > > > following options:
> > > > 1.Steam Client installation could add a file to blacklist
> > > > hid-steam, just as it adds a few udev rules.
> > >
> > > But what about RetroArch? And what if you install Steam but want to
> > > play SDL games that could benefit from your driver?
> >
> > That is an issue of solution 1. I actually have the module blacklisted
> > in my PC, and run `sudo modprobe hid-steam` to use SDL.
> >
> > > > 2.The default CONFIG_HID_STEAM can be changed to "n". Maybe only
> > > > on the architectures for which there is a Steam Client available.
> > > > This way DIY projects will still be able to use it.
> > >
> > > But this will make the decision to include or not the driver in
> > > distributions harder. And if no distribution uses it, you won't have
> > > free tests, and you will be alone to maintain it. So that's not ideal
> > > either
> >
> > Could we set the default to 'y' in non-PC systems. It would be enabled
> > in my Raspbian, for example... better than nothing.
> > >
> > > > 3.This driver could be abandoned :-(. Just use Steam Client if possible or
> > > > any of the user-mode drivers available.
> > >
> > > This would be a waste for everybody as it's always better when we share.
> >
> > Indeed!
> >
> > I tried a new option:
> > 4. The driver detects whether the DEVUSB/HIDRAW device is in use, and
> > if that is the case it will disable itself. If the DEVUSB/HIDRAW is
> > not in use, then the driver will work normally. A bit hackish maybe
> > but it should work.
> >
> > I tried doing this option 4, but I'm unable to do it properly. I don't
> > even know if it is possible...
> >
> > > >
> > > > If we decide for 1 or 2, then the lizard mode could be disabled without
> > > > ill effects. We could even enable the gyro and all the other gadgets
> > > > without worring about current compatibility.
> > >
> > > To me, 1 is out of the question. The kernel can't expect a user space
> > > change especially if you are knowingly introducing a bug for the end
> > > user.
> > >
> > > 2 is still on the table IMO, and 3 would be a shame.
> > >
> > > I know we already discussed about sysfs and module parameters, but if
> > > the driver will conflict with a userspace stack, the only way would be
> > > to have a (dynamic) parameter "enhanced_mode" or
> > > "kernel_awesome_support" or whatever which would be a boolean, that
> > > defaults to false that Steam can eventually lookup if they want so in
> > > the future we can default it to true. When this parameter is set, the
> > > driver will create the inputs and toggle the various modes, while when
> > > it's toggled off, it'll clean up itself and keep the device as if it
> > > were connected to hid-generic. Bonus point, this removes the need for
> > > the simple user space tool that enables the mode.
> >
> > That is doable, but that sysfs/parameter can be changed by a non-root
> > user? I looked for a udev rule to grant access to those but found
> > nothing.
> >
> > IIUC, when this parameter is false the driver will do nothing, right?
> > The user will just need to change it to true to be able to use it, but
> > that will have to be done by root.
> >
> > I'll try doing this, but I'd appreciate your advice about what approach
> > would be better: sysfs? a module parameter? a cdev? or even a EV_MSC?
> >
> > > > At the end of the day, I think that it is up to Valve what to do.
> > >
> > > Again, Valve is a big player here, but do not underestimate other
> > > projects (like RetroArch mentioned above) because if you break their
> > > workflow, they will have the right to request a revert of the commit
> > > because it breaks some random user playing games in the far end of
> > > Antarctica (yes, penguins do love to play games :-P )
> >
> > And everybody loves penguins! If we take away Steam (say a RaspberryPi
> > as a canonical example) and disable the lizard mode, then this driver is
> > just a regular gamepad. RetroArch should be happy with that. Unless they
> > already have an user mode driver for the steam-controller, of course...
>
> Both of these things seem reasonable to me, with a few caveats:
>
> - If there's an opt-in mechanism available, it would be good to ensure we
> have a way to reliably query its state without requiring extra permissions.
> This way, if we know it's likely to affect Steam client functionality, we'll
> have the right mechanism to properly message the situation to users.
>
> - If you find a way for the client to be able to program an opt out when
> it's running that is not automatic (eg. by detecting the hidraw device being
> opened), we'd be happy to participate with that scheme assuming it doesn't
> require extra permissions. As soon as the API is figured out, we can include
> it in the client, just send me a heads-up. The one thing that I'd be
> cautious of is robust behavior against abnormal client termination. If it's
> a sysfs entry we have to poke, I'm worried that if the client crashes we
> might not always be able to opt the driver back out. It'd be nice if it was
> based on opening an fd instead, this way the kernel would robustly clean up
> after us and your driver would kick back in.
Ok, I've written the following scheme:
* I've added a member to struct steam_device: int hid_usage_count.
* Whenver I call hid_hw_open(), hid_usage_count is incremented.
* Whenver I call hid_hw_close(), hid_usage_count is decremented.
Now, with this little function:
static bool steam_is_only_client(struct steam_device *steam)
{
unsigned int count = steam->hdev->ll_open_count;
return count == steam->hid_usage_count;
}
I can check if the hidraw device is opened from user-space. It is nice
because it works not only for SteamClient, but any other user-space
hid driver. And it is resistent to crashes, too.
It is a bit hacky because I don't think ll_open_count is intended for
that, and it is usually protected by a mutex... The proper way, IMO,
would be to have a callback for when the hidraw is first opened/last
closed, but that does not exist, AFAICT.
But hey, it works. The mutexless access is not a big deal, because I
call this function on every input report, so I will get the right value
eventually.
Then if I am the only user, I can disable/enable the lizard mode when
opening/closing the input device. Moreover if hidraw is opened, then I
bypass the input events, and this gamepad goes idle, preventing the
double input problem. It's a bit tricky in the details, but I think I
got it right.
If you don't think this solution is too hacky, I'll post a reroll with
this code, in a few days. I still have to do a few more tests.
Now, what I would really want is a review by Valve of my set-lizard function:
static void steam_set_lizard_mode(struct steam_device *steam, bool enabled)
{
if (enabled) {
steam_send_report_byte(steam, 0x8e); //enable mouse
steam_send_report_byte(steam, 0x85); //enable esc, enter and cursor keys
} else {
steam_send_report_byte(steam, 0x81); //disable esc, enter and cursor keys
steam_write_register(steam, 0x08, 0x07); //disable mouse (cmd: 0x87)
}
}
While it works, I find its asymmetry quite uncanny. I'm afraid that some
of these are there for a side effect, this is not their real purpose.
Could you give me a hint about this?
> Note that there's a general desire on our side to create a reference
> userspace implementation that would more or less have the current
> functionality of the Steam client, but would be easily usable from other
> platforms where the client doesn't currentl run. Unfortunately it's quite a
> bit of work, so it's unclear what the timeframe would be, if it ever does
> happen.
Do you mean the piece of Steam Client that does input-mapping, but as a
portable program without the full client? That would be awesome! And if
open-sourced, even awesomer!!
Thank you all.
Rodrigo
> Thanks,
> - Pierre-Loup
>
> >
> > Best regards.
> > Rodrigo
> >
> > > Cheers,
> > > Benjamin
> > >
> > > > Best Regards.
> > > > Rodrigo.
> > > >
> > > > > Also the button and axis codes do not match the gamepad API doc
> > > > > (https://www.kernel.org/doc/Documentation/input/gamepad.txt).
> > > > >
> > > > > >
> > > > > > For full reference, I'm adding a full changelog of this patchset.
> > > > > >
> > > > > > Changes in v5:
> > > > > > * Fix license SPDX to GPL-2.0+.
> > > > > > * Minor stylistic changes (BIT(3) instead 0x08 and so on).
> > > > > >
> > > > > > Changes in v4:
> > > > > > * Add command to check the wireless connection status on probe, without
> > > > > > waiting for a message (thanks to Clément Vuchener for the tip).
> > > > > > * Removed the error code on redundant connection/disconnection messages. That
> > > > > > was harmless but polluted dmesg.
> > > > > > * Added buttons for touching the left-pad and right-pad.
> > > > > > * Fixed a misplaced #include from 2/4 to 1/4.
> > > > > >
> > > > > > Changes in v3:
> > > > > > * Use RCU to do the dynamic connec/disconnect of wireless devices.
> > > > > > * Remove entries in hid-quirks.c as they are no longer needed. This allows
> > > > > > this module to be blacklisted without side effects.
> > > > > > * Do not bypass the virtual keyboard/mouse HID devices to avoid breaking
> > > > > > existing use cases (lizard mode). A user-space tool to do that is
> > > > > > linked.
> > > > > > * Fully separated axes for joystick and left-pad. As it happens.
> > > > > > * Add fuzz values for left/right pad axes, they are a little wiggly.
> > > > > >
> > > > > > Changes in v2:
> > > > > > * Remove references to USB. Now the interesting interfaces are selected by
> > > > > > looking for the ones with feature reports.
> > > > > > * Feature reports buffers are allocated with hid_alloc_report_buf().
> > > > > > * Feature report length is checked, to avoid overflows in case of
> > > > > > corrupt/malicius USB devices.
> > > > > > * Resolution added to the ABS axes.
> > > > > > * A lot of minor cleanups.
> > > > > >
> > > > > > Rodrigo Rivas Costa (4):
> > > > > > HID: add driver for Valve Steam Controller
> > > > > > HID: steam: add serial number information.
> > > > > > HID: steam: command to check wireless connection
> > > > > > HID: steam: add battery device.
> > > > > >
> > > > > > drivers/hid/Kconfig | 8 +
> > > > > > drivers/hid/Makefile | 1 +
> > > > > > drivers/hid/hid-ids.h | 4 +
> > > > > > drivers/hid/hid-steam.c | 794 ++++++++++++++++++++++++++++++++++++++++++++++++
> > > > > > 4 files changed, 807 insertions(+)
> > > > > > create mode 100644 drivers/hid/hid-steam.c
> > > > > >
> > > > > > --
> > > > > > 2.16.2
> > > > > >
> >
>
^ permalink raw reply
* [PATCH 0/4] HID: alps: Fix some bugs and improve code around 't4_read_write_register()'
From: Christophe JAILLET @ 2018-03-19 20:53 UTC (permalink / raw)
To: masaki.ota, jikos, benjamin.tissoires
Cc: linux-input, linux-kernel, kernel-janitors, Christophe JAILLET
All is said in the subject and below.
These patches are untested. Especially, patch 1 slightly changes the behavior
of 't4_read_write_register()'.
This looks logical to me, but please, review it carefully.
Christophe JAILLET (4):
HID: alps: Report an error if we receive invalid data in
't4_read_write_register()'
HID: alps: Save a memory allocation in 't4_read_write_register()' when
writing data
HID: alps: Check errors returned by 't4_read_write_register()'
HID: alps: Fix some style in 't4_read_write_register()'
drivers/hid/hid-alps.c | 27 ++++++++++++++++++++++-----
1 file changed, 22 insertions(+), 5 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH 1/4] HID: alps: Report an error if we receive invalid data in 't4_read_write_register()'
From: Christophe JAILLET @ 2018-03-19 20:53 UTC (permalink / raw)
To: masaki.ota, jikos, benjamin.tissoires
Cc: linux-input, linux-kernel, kernel-janitors, Christophe JAILLET
In-Reply-To: <cover.1521492069.git.christophe.jaillet@wanadoo.fr>
If the data received is not what is expected, we should return an error.
Otherwise, we return 0 or a positive value which will be interpreted as
success, but '*read_val' has not been updated.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Untested
---
drivers/hid/hid-alps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index b1eeb4839bfc..925396fdf0d9 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -219,6 +219,8 @@ static int t4_read_write_register(struct hid_device *hdev, u32 address,
goto exit_readbuf;
}
+ ret = -EINVAL;
+
if (*(u32 *)&readbuf[6] != address) {
dev_err(&hdev->dev, "read register address error (%x,%x)\n",
*(u32 *)&readbuf[6], address);
--
2.14.1
^ permalink raw reply related
* [PATCH 2/4] HID: alps: Save a memory allocation in 't4_read_write_register()' when writing data
From: Christophe JAILLET @ 2018-03-19 20:53 UTC (permalink / raw)
To: masaki.ota, jikos, benjamin.tissoires
Cc: linux-input, linux-kernel, kernel-janitors, Christophe JAILLET
In-Reply-To: <cover.1521492069.git.christophe.jaillet@wanadoo.fr>
if 'read_flag' is false, there is no need to allocate and free memory.
We can simply avoid the memory allocation and pass NULL to kfree.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/hid/hid-alps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 925396fdf0d9..fe8a0624d5e4 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -171,7 +171,7 @@ static int t4_read_write_register(struct hid_device *hdev, u32 address,
int ret;
u16 check_sum;
u8 *input;
- u8 *readbuf;
+ u8 *readbuf = NULL;
input = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
if (!input)
@@ -204,8 +204,8 @@ static int t4_read_write_register(struct hid_device *hdev, u32 address,
goto exit;
}
- readbuf = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
if (read_flag) {
+ readbuf = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
if (!readbuf) {
ret = -ENOMEM;
goto exit;
--
2.14.1
^ permalink raw reply related
* [PATCH 3/4] HID: alps: Check errors returned by 't4_read_write_register()'
From: Christophe JAILLET @ 2018-03-19 20:53 UTC (permalink / raw)
To: masaki.ota, jikos, benjamin.tissoires
Cc: linux-input, linux-kernel, kernel-janitors, Christophe JAILLET
In-Reply-To: <cover.1521492069.git.christophe.jaillet@wanadoo.fr>
If only the first 't4_read_write_register()' call fails, the error code
will be overwritten and lost.
Directly report the error instead.
While at it, log some errors if 't4_read_write_register()' fails, as done
in the rest of the driver.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/hid/hid-alps.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index fe8a0624d5e4..137b963779c6 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -460,17 +460,35 @@ static int __maybe_unused alps_post_reset(struct hid_device *hdev)
case T4:
ret = t4_read_write_register(hdev, T4_PRM_FEED_CONFIG_1,
NULL, T4_I2C_ABS, false);
+ if (ret < 0) {
+ dev_err(&hdev->dev, "failed T4_PRM_FEED_CONFIG_1 (%d)\n",
+ ret);
+ goto exit;
+ }
+
ret = t4_read_write_register(hdev, T4_PRM_FEED_CONFIG_4,
NULL, T4_FEEDCFG4_ADVANCED_ABS_ENABLE, false);
+ if (ret < 0) {
+ dev_err(&hdev->dev, "failed T4_PRM_FEED_CONFIG_4 (%d)\n",
+ ret);
+ goto exit;
+ }
break;
case U1:
ret = u1_read_write_register(hdev,
ADDRESS_U1_DEV_CTRL_1, NULL,
U1_TP_ABS_MODE | U1_SP_ABS_MODE, false);
+ if (ret < 0) {
+ dev_err(&hdev->dev, "failed to change TP mode (%d)\n",
+ ret);
+ goto exit;
+ }
break;
default:
break;
}
+
+exit:
return ret;
}
--
2.14.1
^ permalink raw reply related
* [PATCH 4/4] HID: alps: Fix some style in 't4_read_write_register()'
From: Christophe JAILLET @ 2018-03-19 20:53 UTC (permalink / raw)
To: masaki.ota, jikos, benjamin.tissoires
Cc: linux-input, linux-kernel, kernel-janitors, Christophe JAILLET
In-Reply-To: <cover.1521492069.git.christophe.jaillet@wanadoo.fr>
Better indent the code to improve readability.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/hid/hid-alps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 137b963779c6..60d3950692d9 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -223,20 +223,20 @@ static int t4_read_write_register(struct hid_device *hdev, u32 address,
if (*(u32 *)&readbuf[6] != address) {
dev_err(&hdev->dev, "read register address error (%x,%x)\n",
- *(u32 *)&readbuf[6], address);
+ *(u32 *)&readbuf[6], address);
goto exit_readbuf;
}
if (*(u16 *)&readbuf[10] != 1) {
dev_err(&hdev->dev, "read register size error (%x)\n",
- *(u16 *)&readbuf[10]);
+ *(u16 *)&readbuf[10]);
goto exit_readbuf;
}
check_sum = t4_calc_check_sum(readbuf, 6, 7);
if (*(u16 *)&readbuf[13] != check_sum) {
dev_err(&hdev->dev, "read register checksum error (%x,%x)\n",
- *(u16 *)&readbuf[13], check_sum);
+ *(u16 *)&readbuf[13], check_sum);
goto exit_readbuf;
}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v5 0/4] new driver for Valve Steam Controller
From: Clément VUCHENER @ 2018-03-19 21:06 UTC (permalink / raw)
To: Rodrigo Rivas Costa
Cc: Pierre-Loup A. Griffais, Benjamin Tissoires, Jiri Kosina,
Cameron Gutman, lkml, linux-input
In-Reply-To: <20180319200813.GA18746@casa>
2018-03-19 21:08 GMT+01:00 Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>:
> On Sat, Mar 17, 2018 at 02:54:07PM -0700, Pierre-Loup A. Griffais wrote:
>
> Now, what I would really want is a review by Valve of my set-lizard function:
>
> static void steam_set_lizard_mode(struct steam_device *steam, bool enabled)
> {
> if (enabled) {
> steam_send_report_byte(steam, 0x8e); //enable mouse
> steam_send_report_byte(steam, 0x85); //enable esc, enter and cursor keys
> } else {
> steam_send_report_byte(steam, 0x81); //disable esc, enter and cursor keys
> steam_write_register(steam, 0x08, 0x07); //disable mouse (cmd: 0x87)
> }
> }
>
> While it works, I find its asymmetry quite uncanny. I'm afraid that some
> of these are there for a side effect, this is not their real purpose.
> Could you give me a hint about this?
>
If I remember correctly, you can also enable the mouse with "87 03 08
00 00". But that do not explain the asymmetry or why there are two
ways of doing it. I always found it weird that the "enable" value was
0x0000 and the "disable" value 0x0007.
^ permalink raw reply
* Re: [PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs
From: Alexandre Belloni @ 2018-03-19 23:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-kernel, linux-block, linux-ide, linux-input,
netdev, linux-wireless, linux-pwm, linux-rtc, linux-spi,
linux-usb, dri-devel, linux-fbdev, linux-watchdog, linux-fsdevel,
linux-mm
In-Reply-To: <20180314144614.1632190-1-arnd@arndb.de>
On 14/03/2018 at 15:43:46 +0100, Arnd Bergmann wrote:
> A lot of Kconfig symbols have architecture specific dependencies.
> In those cases that depend on architectures we have already removed,
> they can be omitted.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> block/bounce.c | 2 +-
> drivers/ide/Kconfig | 2 +-
> drivers/ide/ide-generic.c | 12 +-----------
> drivers/input/joystick/analog.c | 2 +-
> drivers/isdn/hisax/Kconfig | 10 +++++-----
> drivers/net/ethernet/davicom/Kconfig | 2 +-
> drivers/net/ethernet/smsc/Kconfig | 6 +++---
> drivers/net/wireless/cisco/Kconfig | 2 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/rtc/Kconfig | 2 +-
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> drivers/spi/Kconfig | 4 ++--
> drivers/usb/musb/Kconfig | 2 +-
> drivers/video/console/Kconfig | 3 +--
> drivers/watchdog/Kconfig | 6 ------
> drivers/watchdog/Makefile | 6 ------
> fs/Kconfig.binfmt | 5 ++---
> fs/minix/Kconfig | 2 +-
> include/linux/ide.h | 7 +------
> init/Kconfig | 5 ++---
> lib/Kconfig.debug | 13 +++++--------
> lib/test_user_copy.c | 2 --
> mm/Kconfig | 7 -------
> mm/percpu.c | 4 ----
> 23 files changed, 31 insertions(+), 77 deletions(-)
>
> diff --git a/block/bounce.c b/block/bounce.c
> index 6a3e68292273..dd0b93f2a871 100644
> --- a/block/bounce.c
> +++ b/block/bounce.c
> @@ -31,7 +31,7 @@
> static struct bio_set *bounce_bio_set, *bounce_bio_split;
> static mempool_t *page_pool, *isa_page_pool;
>
> -#if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
> +#if defined(CONFIG_HIGHMEM)
> static __init int init_emergency_pool(void)
> {
> #if defined(CONFIG_HIGHMEM) && !defined(CONFIG_MEMORY_HOTPLUG)
> diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
> index cf1fb3fb5d26..901b8833847f 100644
> --- a/drivers/ide/Kconfig
> +++ b/drivers/ide/Kconfig
> @@ -200,7 +200,7 @@ comment "IDE chipset support/bugfixes"
>
> config IDE_GENERIC
> tristate "generic/default IDE chipset support"
> - depends on ALPHA || X86 || IA64 || M32R || MIPS || ARCH_RPC
> + depends on ALPHA || X86 || IA64 || MIPS || ARCH_RPC
> default ARM && ARCH_RPC
> help
> This is the generic IDE driver. This driver attaches to the
> diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
> index 54d7c4685d23..80c0d69b83ac 100644
> --- a/drivers/ide/ide-generic.c
> +++ b/drivers/ide/ide-generic.c
> @@ -13,13 +13,10 @@
> #include <linux/ide.h>
> #include <linux/pci_ids.h>
>
> -/* FIXME: convert arm and m32r to use ide_platform host driver */
> +/* FIXME: convert arm to use ide_platform host driver */
> #ifdef CONFIG_ARM
> #include <asm/irq.h>
> #endif
> -#ifdef CONFIG_M32R
> -#include <asm/m32r.h>
> -#endif
>
> #define DRV_NAME "ide_generic"
>
> @@ -35,13 +32,6 @@ static const struct ide_port_info ide_generic_port_info = {
> #ifdef CONFIG_ARM
> static const u16 legacy_bases[] = { 0x1f0 };
> static const int legacy_irqs[] = { IRQ_HARDDISK };
> -#elif defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_MAPPI2) || \
> - defined(CONFIG_PLAT_OPSPUT)
> -static const u16 legacy_bases[] = { 0x1f0 };
> -static const int legacy_irqs[] = { PLD_IRQ_CFIREQ };
> -#elif defined(CONFIG_PLAT_MAPPI3)
> -static const u16 legacy_bases[] = { 0x1f0, 0x170 };
> -static const int legacy_irqs[] = { PLD_IRQ_CFIREQ, PLD_IRQ_IDEIREQ };
> #elif defined(CONFIG_ALPHA)
> static const u16 legacy_bases[] = { 0x1f0, 0x170, 0x1e8, 0x168 };
> static const int legacy_irqs[] = { 14, 15, 11, 10 };
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index be1b4921f22a..eefac7978f93 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
> #define GET_TIME(x) do { x = (unsigned int)rdtsc(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "TSC"
> -#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
> +#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
> #define GET_TIME(x) do { x = get_cycles(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "get_cycles"
> diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
> index eb83d94ab4fe..38cfc8baae19 100644
> --- a/drivers/isdn/hisax/Kconfig
> +++ b/drivers/isdn/hisax/Kconfig
> @@ -109,7 +109,7 @@ config HISAX_16_3
>
> config HISAX_TELESPCI
> bool "Teles PCI"
> - depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
> + depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
> help
> This enables HiSax support for the Teles PCI.
> See <file:Documentation/isdn/README.HiSax> on how to configure it.
> @@ -237,7 +237,7 @@ config HISAX_MIC
>
> config HISAX_NETJET
> bool "NETjet card"
> - depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE))
> + depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE))
> depends on VIRT_TO_BUS
> help
> This enables HiSax support for the NetJet from Traverse
> @@ -249,7 +249,7 @@ config HISAX_NETJET
>
> config HISAX_NETJET_U
> bool "NETspider U card"
> - depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE))
> + depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE))
> depends on VIRT_TO_BUS
> help
> This enables HiSax support for the Netspider U interface ISDN card
> @@ -318,7 +318,7 @@ config HISAX_GAZEL
>
> config HISAX_HFC_PCI
> bool "HFC PCI-Bus cards"
> - depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
> + depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
> help
> This enables HiSax support for the HFC-S PCI 2BDS0 based cards.
>
> @@ -343,7 +343,7 @@ config HISAX_HFC_SX
>
> config HISAX_ENTERNOW_PCI
> bool "Formula-n enter:now PCI card"
> - depends on HISAX_NETJET && PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
> + depends on HISAX_NETJET && PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS && !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
> help
> This enables HiSax support for the Formula-n enter:now PCI
> ISDN card.
> diff --git a/drivers/net/ethernet/davicom/Kconfig b/drivers/net/ethernet/davicom/Kconfig
> index 7ec2d74f94d3..680a6d983f37 100644
> --- a/drivers/net/ethernet/davicom/Kconfig
> +++ b/drivers/net/ethernet/davicom/Kconfig
> @@ -4,7 +4,7 @@
>
> config DM9000
> tristate "DM9000 support"
> - depends on ARM || BLACKFIN || MIPS || COLDFIRE || NIOS2
> + depends on ARM || MIPS || COLDFIRE || NIOS2
> select CRC32
> select MII
> ---help---
> diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
> index 948603e9b905..3da0c573d2ab 100644
> --- a/drivers/net/ethernet/smsc/Kconfig
> +++ b/drivers/net/ethernet/smsc/Kconfig
> @@ -5,8 +5,8 @@
> config NET_VENDOR_SMSC
> bool "SMC (SMSC)/Western Digital devices"
> default y
> - depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
> - ISA || M32R || MAC || MIPS || NIOS2 || PCI || \
> + depends on ARM || ARM64 || ATARI_ETHERNAT || COLDFIRE || \
> + ISA || MAC || MIPS || NIOS2 || PCI || \
> PCMCIA || SUPERH || XTENSA || H8300
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y.
> @@ -37,7 +37,7 @@ config SMC91X
> select CRC32
> select MII
> depends on !OF || GPIOLIB
> - depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
> + depends on ARM || ARM64 || ATARI_ETHERNAT || COLDFIRE || \
> M32R || MIPS || NIOS2 || SUPERH || XTENSA || H8300
> ---help---
> This is a driver for SMC's 91x series of Ethernet chipsets,
> diff --git a/drivers/net/wireless/cisco/Kconfig b/drivers/net/wireless/cisco/Kconfig
> index b22567dff893..8ed0b154bb33 100644
> --- a/drivers/net/wireless/cisco/Kconfig
> +++ b/drivers/net/wireless/cisco/Kconfig
> @@ -33,7 +33,7 @@ config AIRO
>
> config AIRO_CS
> tristate "Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards"
> - depends on CFG80211 && PCMCIA && (BROKEN || !M32R)
> + depends on CFG80211 && PCMCIA
> select WIRELESS_EXT
> select WEXT_SPY
> select WEXT_PRIV
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 763ee50ea57d..f16aad3bf5d6 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -43,7 +43,7 @@ config PWM_AB8500
>
> config PWM_ATMEL
> tristate "Atmel PWM support"
> - depends on ARCH_AT91 || AVR32
> + depends on ARCH_AT91
> help
> Generic PWM framework driver for Atmel SoC.
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index be5a3dc99c11..46af10ac45fc 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -868,7 +868,7 @@ comment "Platform RTC drivers"
>
> config RTC_DRV_CMOS
> tristate "PC-style 'CMOS'"
> - depends on X86 || ARM || M32R || PPC || MIPS || SPARC64
> + depends on X86 || ARM || PPC || MIPS || SPARC64
> default y if X86
> select RTC_MC146818_LIB
> help
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 603783976b81..103c13fcefa0 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -72,10 +72,10 @@ config SPI_ARMADA_3700
> config SPI_ATMEL
> tristate "Atmel SPI Controller"
> depends on HAS_DMA
> - depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
> + depends on ARCH_AT91 || COMPILE_TEST
> help
> This selects a driver for the Atmel SPI Controller, present on
> - many AT32 (AVR32) and AT91 (ARM) chips.
> + many AT91 ARM chips.
>
> config SPI_AU1550
> tristate "Au1550/Au1200/Au1300 SPI Controller"
> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
> index 5506a9c03c1f..e757afc1cfd0 100644
> --- a/drivers/usb/musb/Kconfig
> +++ b/drivers/usb/musb/Kconfig
> @@ -87,7 +87,7 @@ config USB_MUSB_DA8XX
> config USB_MUSB_TUSB6010
> tristate "TUSB6010"
> depends on HAS_IOMEM
> - depends on (ARCH_OMAP2PLUS || COMPILE_TEST) && !BLACKFIN
> + depends on ARCH_OMAP2PLUS || COMPILE_TEST
> depends on NOP_USB_XCEIV = USB_MUSB_HDRC # both built-in or both modules
>
> config USB_MUSB_OMAP2PLUS
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index 005ed87c8216..a9e398c144f8 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -6,8 +6,7 @@ menu "Console display driver support"
>
> config VGA_CONSOLE
> bool "VGA text console" if EXPERT || !X86
> - depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
> - !SUPERH && !BLACKFIN && !AVR32 && !CRIS && \
> + depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !SUPERH && \
> (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \
> !ARM64 && !ARC && !MICROBLAZE && !OPENRISC
> default y
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 0e19679348d1..79020ce95de2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -828,10 +828,6 @@ config BFIN_WDT
> To compile this driver as a module, choose M here: the
> module will be called bfin_wdt.
>
> -# CRIS Architecture
> -
> -# FRV Architecture
> -
> # X86 (i386 + ia64 + x86_64) Architecture
>
> config ACQUIRE_WDT
> @@ -1431,8 +1427,6 @@ config NIC7018_WDT
> To compile this driver as a module, choose M here: the module will be
> called nic7018_wdt.
>
> -# M32R Architecture
> -
> # M68K Architecture
>
> config M54xx_WATCHDOG
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0474d38aa854..1f9a0235f22c 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -94,10 +94,6 @@ obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
> # BLACKFIN Architecture
> obj-$(CONFIG_BFIN_WDT) += bfin_wdt.o
>
> -# CRIS Architecture
> -
> -# FRV Architecture
> -
> # X86 (i386 + ia64 + x86_64) Architecture
> obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
> obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o
> @@ -146,8 +142,6 @@ obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
> obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
>
> -# M32R Architecture
> -
> # M68K Architecture
> obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
>
> diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> index 58c2bbd385ad..57a27c42b5ac 100644
> --- a/fs/Kconfig.binfmt
> +++ b/fs/Kconfig.binfmt
> @@ -1,6 +1,6 @@
> config BINFMT_ELF
> bool "Kernel support for ELF binaries"
> - depends on MMU && (BROKEN || !FRV)
> + depends on MMU
> select ELFCORE
> default y
> ---help---
> @@ -35,7 +35,7 @@ config ARCH_BINFMT_ELF_STATE
> config BINFMT_ELF_FDPIC
> bool "Kernel support for FDPIC ELF binaries"
> default y if !BINFMT_ELF
> - depends on (ARM || FRV || BLACKFIN || (SUPERH32 && !MMU) || C6X)
> + depends on (ARM || (SUPERH32 && !MMU) || C6X)
> select ELFCORE
> help
> ELF FDPIC binaries are based on ELF, but allow the individual load
> @@ -90,7 +90,6 @@ config BINFMT_SCRIPT
> config BINFMT_FLAT
> bool "Kernel support for flat binaries"
> depends on !MMU || ARM || M68K
> - depends on !FRV || BROKEN
> help
> Support uClinux FLAT format binaries.
>
> diff --git a/fs/minix/Kconfig b/fs/minix/Kconfig
> index f2a0cfcef11d..bcd53a79156f 100644
> --- a/fs/minix/Kconfig
> +++ b/fs/minix/Kconfig
> @@ -18,7 +18,7 @@ config MINIX_FS
>
> config MINIX_FS_NATIVE_ENDIAN
> def_bool MINIX_FS
> - depends on M32R || MICROBLAZE || MIPS || S390 || SUPERH || SPARC || XTENSA || (M68K && !MMU)
> + depends on MICROBLAZE || MIPS || S390 || SUPERH || SPARC || XTENSA || (M68K && !MMU)
>
> config MINIX_FS_BIG_ENDIAN_16BIT_INDEXED
> def_bool MINIX_FS
> diff --git a/include/linux/ide.h b/include/linux/ide.h
> index 20d42c0d9fb6..1d6f16110eae 100644
> --- a/include/linux/ide.h
> +++ b/include/linux/ide.h
> @@ -25,15 +25,10 @@
> #include <asm/byteorder.h>
> #include <asm/io.h>
>
> -#if defined(CONFIG_CRIS) || defined(CONFIG_FRV)
> -# define SUPPORT_VLB_SYNC 0
> -#else
> -# define SUPPORT_VLB_SYNC 1
> -#endif
> -
> /*
> * Probably not wise to fiddle with these
> */
> +#define SUPPORT_VLB_SYNC 1
> #define IDE_DEFAULT_MAX_FAILURES 1
> #define ERROR_MAX 8 /* Max read/write errors per sector */
> #define ERROR_RESET 3 /* Reset controller every 4th retry */
> diff --git a/init/Kconfig b/init/Kconfig
> index a14bcc9724a2..2852692d7c9c 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -998,7 +998,6 @@ config RELAY
>
> config BLK_DEV_INITRD
> bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
> - depends on BROKEN || !FRV
> help
> The initial RAM filesystem is a ramfs which is loaded by the
> boot loader (loadlin or lilo) and that is mounted as root
> @@ -1108,7 +1107,7 @@ config MULTIUSER
>
> config SGETMASK_SYSCALL
> bool "sgetmask/ssetmask syscalls support" if EXPERT
> - def_bool PARISC || BLACKFIN || M68K || PPC || MIPS || X86 || SPARC || CRIS || MICROBLAZE || SUPERH
> + def_bool PARISC || M68K || PPC || MIPS || X86 || SPARC || MICROBLAZE || SUPERH
> ---help---
> sys_sgetmask and sys_ssetmask are obsolete system calls
> no longer supported in libc but still enabled by default in some
> @@ -1370,7 +1369,7 @@ config KALLSYMS_ABSOLUTE_PERCPU
> config KALLSYMS_BASE_RELATIVE
> bool
> depends on KALLSYMS
> - default !IA64 && !(TILE && 64BIT)
> + default !IA64
> help
> Instead of emitting them as absolute values in the native word size,
> emit the symbol references in the kallsyms table as 32-bit entries,
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 41ac9d294245..6927c6d8d185 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -165,7 +165,7 @@ config DEBUG_INFO_REDUCED
>
> config DEBUG_INFO_SPLIT
> bool "Produce split debuginfo in .dwo files"
> - depends on DEBUG_INFO && !FRV
> + depends on DEBUG_INFO
> help
> Generate debug info into separate .dwo files. This significantly
> reduces the build directory size for builds with DEBUG_INFO,
> @@ -354,10 +354,7 @@ config ARCH_WANT_FRAME_POINTERS
>
> config FRAME_POINTER
> bool "Compile the kernel with frame pointers"
> - depends on DEBUG_KERNEL && \
> - (CRIS || M68K || FRV || UML || \
> - SUPERH || BLACKFIN) || \
> - ARCH_WANT_FRAME_POINTERS
> + depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS
> default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
> help
> If you say Y here the resulting kernel image will be slightly
> @@ -1138,7 +1135,7 @@ config LOCKDEP
> bool
> depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
> select STACKTRACE
> - select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !SCORE && !X86
> + select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !X86
> select KALLSYMS
> select KALLSYMS_ALL
>
> @@ -1571,7 +1568,7 @@ config FAULT_INJECTION_STACKTRACE_FILTER
> depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
> depends on !X86_64
> select STACKTRACE
> - select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC && !SCORE && !X86
> + select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC && !X86
> help
> Provide stacktrace filter for fault-injection capabilities
>
> @@ -1969,7 +1966,7 @@ config STRICT_DEVMEM
> bool "Filter access to /dev/mem"
> depends on MMU && DEVMEM
> depends on ARCH_HAS_DEVMEM_IS_ALLOWED
> - default y if TILE || PPC || X86 || ARM64
> + default y if PPC || X86 || ARM64
> ---help---
> If this option is disabled, you allow userspace (root) access to all
> of memory, including kernel and userspace memory. Accidental
> diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
> index a6556f3364d1..e161f0498f42 100644
> --- a/lib/test_user_copy.c
> +++ b/lib/test_user_copy.c
> @@ -31,8 +31,6 @@
> * their capability at compile-time, we just have to opt-out certain archs.
> */
> #if BITS_PER_LONG == 64 || (!(defined(CONFIG_ARM) && !defined(MMU)) && \
> - !defined(CONFIG_BLACKFIN) && \
> - !defined(CONFIG_M32R) && \
> !defined(CONFIG_M68K) && \
> !defined(CONFIG_MICROBLAZE) && \
> !defined(CONFIG_NIOS2) && \
> diff --git a/mm/Kconfig b/mm/Kconfig
> index abefa573bcd8..d5004d82a1d6 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -278,13 +278,6 @@ config BOUNCE
> by default when ZONE_DMA or HIGHMEM is selected, but you
> may say n to override this.
>
> -# On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
> -# have more than 4GB of memory, but we don't currently use the IOTLB to present
> -# a 32-bit address to OHCI. So we need to use a bounce pool instead.
> -config NEED_BOUNCE_POOL
> - bool
> - default y if TILE && USB_OHCI_HCD
> -
> config NR_QUICK
> int
> depends on QUICKLIST
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 50e7fdf84055..79e3549cab0f 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2719,11 +2719,7 @@ void __init setup_per_cpu_areas(void)
>
> if (pcpu_setup_first_chunk(ai, fc) < 0)
> panic("Failed to initialize percpu areas.");
> -#ifdef CONFIG_CRIS
> -#warning "the CRIS architecture has physical and virtual addresses confused"
> -#else
> pcpu_free_alloc_info(ai);
> -#endif
> }
>
> #endif /* CONFIG_SMP */
> --
> 2.9.0
>
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Linus Torvalds @ 2018-03-19 23:29 UTC (permalink / raw)
To: David Laight
Cc: Rasmus Villemoes, Kees Cook, Al Viro, Florian Weimer,
Andrew Morton, Josh Poimboeuf, Randy Dunlap, Miguel Ojeda,
Ingo Molnar, Ian Abbott, linux-input, linux-btrfs,
Network Development, Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <0e94e9582bec4373b5e21c612be179ac@AcuMS.aculab.com>
On Mon, Mar 19, 2018 at 2:43 AM, David Laight <David.Laight@aculab.com> wrote:
>
> Is it necessary to have the full checks for old versions of gcc?
>
> Even -Wvla could be predicated on very recent gcc - since we aren't
> worried about whether gcc decides to generate a vla, but whether
> the source requests one.
You are correct. We could just ignore the issue with old gcc versions,
and disable -Wvla rather than worry about it.
Linus
^ permalink raw reply
* Re: [PATCH 04/14] platform/chrome: chromeos_laptop - add SPDX identifier
From: Benson Leung @ 2018-03-20 1:53 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, Benson Leung
Cc: Nick Dyer, Olof Johansson, linux-kernel, Benson Leung
In-Reply-To: <20180312190907.174301-5-dmitry.torokhov@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2147 bytes --]
On 03/12/2018 12:08 PM, Dmitry Torokhov wrote:
> Replace the original license statement with the SPDX identifier.
> Add also one line of description as recommended by the COPYING file.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Applied to my working branch for atmel_mxt_ts + chromeos_laptop.c for
v4.17. Thanks!
> ---
> drivers/platform/chrome/chromeos_laptop.c | 27 +++++------------------
> 1 file changed, 5 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/platform/chrome/chromeos_laptop.c b/drivers/platform/chrome/chromeos_laptop.c
> index d8599736a41a2..54a13c70e1d8f 100644
> --- a/drivers/platform/chrome/chromeos_laptop.c
> +++ b/drivers/platform/chrome/chromeos_laptop.c
> @@ -1,25 +1,8 @@
> -/*
> - * chromeos_laptop.c - Driver to instantiate Chromebook i2c/smbus devices.
> - *
> - * Author : Benson Leung <bleung@chromium.org>
> - *
> - * Copyright (C) 2012 Google, Inc.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> - *
> - */
> +// SPDX-License-Identifier: GPL-2.0+
> +// Driver to instantiate Chromebook i2c/smbus devices.
> +//
> +// Copyright (C) 2012 Google, Inc.
> +// Author: Benson Leung <bleung@chromium.org>
>
> #include <linux/dmi.h>
> #include <linux/i2c.h>
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 06/14] platform/chrome: chromeos_laptop - introduce pr_fmt()
From: Benson Leung @ 2018-03-20 2:03 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, Benson Leung
Cc: Nick Dyer, Olof Johansson, linux-kernel
In-Reply-To: <20180312190907.174301-7-dmitry.torokhov@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4341 bytes --]
On 03/12/2018 12:08 PM, Dmitry Torokhov wrote:
> Define pr_fmt() to standardize driver messages.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Applied to my working branch for atmel_mxt_ts + chromeos_laptop.c for
v4.17. Thanks!
> ---
> drivers/platform/chrome/chromeos_laptop.c | 31 ++++++++++-------------
> 1 file changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/platform/chrome/chromeos_laptop.c b/drivers/platform/chrome/chromeos_laptop.c
> index 0a43f1833de3f..08ce7a105e768 100644
> --- a/drivers/platform/chrome/chromeos_laptop.c
> +++ b/drivers/platform/chrome/chromeos_laptop.c
> @@ -4,6 +4,8 @@
> // Copyright (C) 2012 Google, Inc.
> // Author: Benson Leung <bleung@chromium.org>
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/dmi.h>
> #include <linux/i2c.h>
> #include <linux/platform_data/atmel_mxt_ts.h>
> @@ -139,15 +141,12 @@ static struct i2c_client *__add_probed_i2c_device(
> if (name) {
> dmi_dev = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD, name, NULL);
> if (!dmi_dev) {
> - pr_err("%s failed to dmi find device %s.\n",
> - __func__,
> - name);
> + pr_err("failed to dmi find device %s\n", name);
> return NULL;
> }
> dev_data = (struct dmi_dev_onboard *)dmi_dev->device_data;
> if (!dev_data) {
> - pr_err("%s failed to get data from dmi for %s.\n",
> - __func__, name);
> + pr_err("failed to get data from dmi for %s\n", name);
> return NULL;
> }
> info->irq = dev_data->instance;
> @@ -155,7 +154,7 @@ static struct i2c_client *__add_probed_i2c_device(
>
> adapter = i2c_get_adapter(bus);
> if (!adapter) {
> - pr_err("%s failed to get i2c adapter %d.\n", __func__, bus);
> + pr_err("failed to get i2c adapter %d\n", bus);
> return NULL;
> }
>
> @@ -174,19 +173,18 @@ static struct i2c_client *__add_probed_i2c_device(
> dummy = i2c_new_probed_device(adapter, &dummy_info,
> alt_addr_list, NULL);
> if (dummy) {
> - pr_debug("%s %d-%02x is probed at %02x\n",
> - __func__, bus, info->addr, dummy->addr);
> + pr_debug("%d-%02x is probed at %02x\n",
> + bus, info->addr, dummy->addr);
> i2c_unregister_device(dummy);
> client = i2c_new_device(adapter, info);
> }
> }
>
> if (!client)
> - pr_notice("%s failed to register device %d-%02x\n",
> - __func__, bus, info->addr);
> + pr_notice("failed to register device %d-%02x\n",
> + bus, info->addr);
> else
> - pr_debug("%s added i2c device %d-%02x\n",
> - __func__, bus, info->addr);
> + pr_debug("added i2c device %d-%02x\n", bus, info->addr);
>
> i2c_put_adapter(adapter);
> return client;
> @@ -227,7 +225,7 @@ static int find_i2c_adapter_num(enum i2c_adapter_type type)
> dev = bus_find_device(&i2c_bus_type, NULL, &lookup, __find_i2c_adap);
> if (!dev) {
> /* Adapters may appear later. Deferred probing will retry */
> - pr_notice("%s: i2c adapter %s not found on system.\n", __func__,
> + pr_notice("i2c adapter %s not found on system.\n",
> lookup.name);
> return -ENODEV;
> }
> @@ -349,7 +347,7 @@ static int setup_tsl2563_als(enum i2c_adapter_type type)
> static int __init chromeos_laptop_dmi_matched(const struct dmi_system_id *id)
> {
> cros_laptop = (void *)id->driver_data;
> - pr_debug("DMI Matched %s.\n", id->ident);
> + pr_debug("DMI Matched %s\n", id->ident);
>
> /* Indicate to dmi_scan that processing is done. */
> return 1;
> @@ -392,8 +390,7 @@ static int chromeos_laptop_probe(struct platform_device *pdev)
> ret = -EPROBE_DEFER;
> } else {
> /* Ran out of tries. */
> - pr_notice("%s: Ran out of tries for device.\n",
> - __func__);
> + pr_notice("ran out of tries for device.\n");
> i2c_dev->state = TIMEDOUT;
> }
> } else {
> @@ -600,7 +597,7 @@ static int __init chromeos_laptop_init(void)
> int ret;
>
> if (!dmi_check_system(chromeos_laptop_dmi_table)) {
> - pr_debug("%s unsupported system.\n", __func__);
> + pr_debug("unsupported system\n");
> return -ENODEV;
> }
>
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 07/14] platform/chrome: chromeos_laptop - factor out getting IRQ from DMI
From: Benson Leung @ 2018-03-20 2:14 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, Benson Leung
Cc: Nick Dyer, Olof Johansson, linux-kernel
In-Reply-To: <20180312190907.174301-8-dmitry.torokhov@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2645 bytes --]
On 03/12/2018 12:09 PM, Dmitry Torokhov wrote:
> This will make code instantiating I2C device a bit clearer.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Applied to my working branch for atmel_mxt_ts + chromeos_laptop.c for
v4.17. Thanks!
> ---
> drivers/platform/chrome/chromeos_laptop.c | 35 +++++++++++++++--------
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/platform/chrome/chromeos_laptop.c b/drivers/platform/chrome/chromeos_laptop.c
> index 08ce7a105e768..96e962ff38e87 100644
> --- a/drivers/platform/chrome/chromeos_laptop.c
> +++ b/drivers/platform/chrome/chromeos_laptop.c
> @@ -120,36 +120,47 @@ static struct i2c_board_info atmel_1664s_device = {
> .flags = I2C_CLIENT_WAKE,
> };
>
> +static int chromeos_laptop_get_irq_from_dmi(const char *dmi_name)
> +{
> + const struct dmi_device *dmi_dev;
> + const struct dmi_dev_onboard *dev_data;
> +
> + dmi_dev = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD, dmi_name, NULL);
> + if (!dmi_dev) {
> + pr_err("failed to find DMI device '%s'\n", dmi_name);
> + return -ENOENT;
> + }
> +
> + dev_data = dmi_dev->device_data;
> + if (!dev_data) {
> + pr_err("failed to get data from DMI for '%s'\n", dmi_name);
> + return -EINVAL;
> + }
> +
> + return dev_data->instance;
> +}
> +
> static struct i2c_client *__add_probed_i2c_device(
> const char *name,
> int bus,
> struct i2c_board_info *info,
> const unsigned short *alt_addr_list)
> {
> - const struct dmi_device *dmi_dev;
> - const struct dmi_dev_onboard *dev_data;
> struct i2c_adapter *adapter;
> struct i2c_client *client = NULL;
> const unsigned short addr_list[] = { info->addr, I2C_CLIENT_END };
>
> if (bus < 0)
> return NULL;
> +
> /*
> * If a name is specified, look for irq platform information stashed
> * in DMI_DEV_TYPE_DEV_ONBOARD by the Chrome OS custom system firmware.
> */
> if (name) {
> - dmi_dev = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD, name, NULL);
> - if (!dmi_dev) {
> - pr_err("failed to dmi find device %s\n", name);
> - return NULL;
> - }
> - dev_data = (struct dmi_dev_onboard *)dmi_dev->device_data;
> - if (!dev_data) {
> - pr_err("failed to get data from dmi for %s\n", name);
> + info->irq = chromeos_laptop_get_irq_from_dmi(name);
> + if (info->irq < 0)
> return NULL;
> - }
> - info->irq = dev_data->instance;
> }
>
> adapter = i2c_get_adapter(bus);
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Arnd Bergmann @ 2018-03-20 3:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Laight, Rasmus Villemoes, Kees Cook, Al Viro,
Florian Weimer, Andrew Morton, Josh Poimboeuf, Randy Dunlap,
Miguel Ojeda, Ingo Molnar, Ian Abbott, linux-input, linux-btrfs,
Network Development, Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <CA+55aFwZnkR5uA5Oe19Xzox=+Bcab-j6-+a=XGqS8yokDU3Dog@mail.gmail.com>
On Tue, Mar 20, 2018 at 7:29 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 19, 2018 at 2:43 AM, David Laight <David.Laight@aculab.com> wrote:
>>
>> Is it necessary to have the full checks for old versions of gcc?
>>
>> Even -Wvla could be predicated on very recent gcc - since we aren't
>> worried about whether gcc decides to generate a vla, but whether
>> the source requests one.
>
> You are correct. We could just ignore the issue with old gcc versions,
> and disable -Wvla rather than worry about it.
This version might also be an option:
diff --git a/Makefile b/Makefile
index 37fc475a2b92..49dd9f0fb76c 100644
--- a/Makefile
+++ b/Makefile
@@ -687,7 +687,8 @@ KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks,) \
endif
ifneq ($(CONFIG_FRAME_WARN),0)
-KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
+KBUILD_CFLAGS += $(call cc-option,-Wstack-usage=${CONFIG_FRAME_WARN}, \
+ -$(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN}))
endif
# This selects the stack protector compiler flag. Testing it is delayed
Wiht -Wstack-usage=, we should get a similar warning to -Wvla for frames that
contain real VLAs, but not when there is a VLA that ends up being a compile-time
constant size in the end. Wstack-usage was introduced in gcc-4.7, so
on older versions
it turns back into Wframe-larger-than=.
An example output would be
security/integrity/ima/ima_crypto.c: In function 'ima_calc_buffer_hash':
security/integrity/ima/ima_crypto.c:616:5: error: stack usage might be
unbounded [-Werror=stack-usage=]
Arnd
^ permalink raw reply related
* [PATCH 0/7] HID core and multitouch fixups
From: Benjamin Tissoires @ 2018-03-20 11:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, linux-input, linux-kernel, Benjamin Tissoires
Hi,
Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone
near the edges of the touchpad.
Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4
at the time.
Patches 5..7 are cleanups I realized while trying to merge hid-multitouch
into hid-core, so that other drivers could reuse the hid-mt logic (but it's
not that easy I must confess).
Cheers,
Benjamin
Benjamin Tissoires (7):
HID: multitouch: export a quirk for the button handling of touchpads
HID: multitouch: remove dead zones of Razer Blade Stealth
HID: use BIT macro instead of plain integers for flags
HID: use BIT() macro for quirks too
HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT
HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS
HID: core: reset the quirks before calling probe again
drivers/hid/hid-asus.c | 3 +-
drivers/hid/hid-core.c | 2 ++
drivers/hid/hid-input.c | 10 +++----
drivers/hid/hid-multitouch.c | 61 ++++++++++++++++-------------------------
drivers/hid/hid-uclogic.c | 1 -
include/linux/hid.h | 65 ++++++++++++++++++++++----------------------
6 files changed, 65 insertions(+), 77 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH 1/7] HID: multitouch: export a quirk for the button handling of touchpads
From: Benjamin Tissoires @ 2018-03-20 11:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20180320110451.16582-1-benjamin.tissoires@redhat.com>
Instead of using the class name, we better have a specific quirk for it
so other classes can make use of it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-multitouch.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index a144d3064829..fc80a9bf3e39 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -74,6 +74,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_TOUCH_SIZE_SCALING BIT(15)
#define MT_QUIRK_STICKY_FINGERS BIT(16)
#define MT_QUIRK_ASUS_CUSTOM_UP BIT(17)
+#define MT_QUIRK_WIN8_PTP_BUTTONS BIT(18)
#define MT_INPUTMODE_TOUCHSCREEN 0x02
#define MT_INPUTMODE_TOUCHPAD 0x03
@@ -241,7 +242,8 @@ static struct mt_class mt_classes[] = {
MT_QUIRK_IGNORE_DUPLICATES |
MT_QUIRK_HOVERING |
MT_QUIRK_CONTACT_CNT_ACCURATE |
- MT_QUIRK_STICKY_FINGERS },
+ MT_QUIRK_STICKY_FINGERS |
+ MT_QUIRK_WIN8_PTP_BUTTONS },
{ .name = MT_CLS_EXPORT_ALL_INPUTS,
.quirks = MT_QUIRK_ALWAYS_VALID |
MT_QUIRK_CONTACT_CNT_ACCURATE,
@@ -250,7 +252,8 @@ static struct mt_class mt_classes[] = {
.quirks = MT_QUIRK_ALWAYS_VALID |
MT_QUIRK_IGNORE_DUPLICATES |
MT_QUIRK_HOVERING |
- MT_QUIRK_CONTACT_CNT_ACCURATE,
+ MT_QUIRK_CONTACT_CNT_ACCURATE |
+ MT_QUIRK_WIN8_PTP_BUTTONS,
.export_all_inputs = true },
/*
@@ -660,8 +663,7 @@ static int mt_touch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
* MS PTP spec says that external buttons left and right have
* usages 2 and 3.
*/
- if ((cls->name == MT_CLS_WIN_8 ||
- cls->name == MT_CLS_WIN_8_DUAL) &&
+ if ((cls->quirks & MT_QUIRK_WIN8_PTP_BUTTONS) &&
field->application == HID_DG_TOUCHPAD &&
(usage->hid & HID_USAGE) > 1)
code--;
@@ -773,9 +775,7 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
*/
static void mt_sync_frame(struct mt_device *td, struct input_dev *input)
{
- __s32 cls = td->mtclass.name;
-
- if (cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL)
+ if (td->mtclass.quirks & MT_QUIRK_WIN8_PTP_BUTTONS)
input_event(input, EV_KEY, BTN_LEFT, td->left_button_state);
input_mt_sync_frame(input);
@@ -827,7 +827,6 @@ static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
bool first_packet)
{
struct mt_device *td = hid_get_drvdata(hid);
- __s32 cls = td->mtclass.name;
__s32 quirks = td->mtclass.quirks;
struct input_dev *input = field->hidinput->input;
@@ -905,7 +904,7 @@ static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
* non finger/touch events in the first_packet of
* a (possible) multi-packet frame.
*/
- if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+ if ((quirks & MT_QUIRK_WIN8_PTP_BUTTONS) &&
!first_packet)
return;
@@ -916,7 +915,7 @@ static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
* BTN_LEFT if either is pressed, so we or all values
* together and report the result in mt_sync_frame().
*/
- if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+ if ((quirks & MT_QUIRK_WIN8_PTP_BUTTONS) &&
usage->type == EV_KEY && usage->code == BTN_LEFT) {
td->left_button_state |= value;
return;
@@ -940,7 +939,6 @@ static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
static void mt_touch_report(struct hid_device *hid, struct hid_report *report)
{
struct mt_device *td = hid_get_drvdata(hid);
- __s32 cls = td->mtclass.name;
struct hid_field *field;
bool first_packet;
unsigned count;
@@ -969,7 +967,7 @@ static void mt_touch_report(struct hid_device *hid, struct hid_report *report)
* of a possible multi-packet frame be checking that the
* timestamp has changed.
*/
- if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+ if ((td->mtclass.quirks & MT_QUIRK_WIN8_PTP_BUTTONS) &&
td->num_received == 0 && td->prev_scantime != scantime)
td->num_expected = value;
/* A non 0 contact count always indicates a first packet */
--
2.14.3
^ permalink raw reply related
* [PATCH 2/7] HID: multitouch: remove dead zones of Razer Blade Stealth
From: Benjamin Tissoires @ 2018-03-20 11:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20180320110451.16582-1-benjamin.tissoires@redhat.com>
The Razer Blade Stealth detects palms too aggressively and this creates
a dead zone around the touchpad. Users like being able to use their
entire touchpad, so we should probably not filter out the "palm" events
from the device and report them as regular touches, leaving the palm
detection up to the upper stack
Link: https://bugs.freedesktop.org/show_bug.cgi?id=105409
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-multitouch.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index fc80a9bf3e39..520cb5e2c5c3 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -184,6 +184,7 @@ static void mt_post_parse(struct mt_device *td);
#define MT_CLS_ASUS 0x010b
#define MT_CLS_VTL 0x0110
#define MT_CLS_GOOGLE 0x0111
+#define MT_CLS_RAZER_BLADE_STEALTH 0x0112
#define MT_DEFAULT_MAXCONTACT 10
#define MT_MAX_MAXCONTACT 250
@@ -326,6 +327,13 @@ static struct mt_class mt_classes[] = {
MT_QUIRK_SLOT_IS_CONTACTID |
MT_QUIRK_HOVERING
},
+ { .name = MT_CLS_RAZER_BLADE_STEALTH,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_IGNORE_DUPLICATES |
+ MT_QUIRK_HOVERING |
+ MT_QUIRK_CONTACT_CNT_ACCURATE |
+ MT_QUIRK_WIN8_PTP_BUTTONS,
+ },
{ }
};
@@ -1792,6 +1800,11 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_QUANTA,
USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001) },
+ /* Razer touchpads */
+ { .driver_data = MT_CLS_RAZER_BLADE_STEALTH,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_SYNAPTICS, 0x8323) },
+
/* Stantum panels */
{ .driver_data = MT_CLS_CONFIDENCE,
MT_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM,
--
2.14.3
^ permalink raw reply related
* [PATCH 3/7] HID: use BIT macro instead of plain integers for flags
From: Benjamin Tissoires @ 2018-03-20 11:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20180320110451.16582-1-benjamin.tissoires@redhat.com>
This can lead to some hairy situation with the developer losing
a day or two realizing that 4 should be after 2, not 3.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
--
include/linux/hid.h | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index dfea5a656a1a..ea78336984d3 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -26,6 +26,7 @@
#define __HID_H
+#include <linux/bitops.h>
#include <linux/types.h>
#include <linux/slab.h>
#include <linux/list.h>
@@ -494,13 +495,13 @@ struct hid_output_fifo {
char *raw_report;
};
-#define HID_CLAIMED_INPUT 1
-#define HID_CLAIMED_HIDDEV 2
-#define HID_CLAIMED_HIDRAW 4
-#define HID_CLAIMED_DRIVER 8
+#define HID_CLAIMED_INPUT BIT(0)
+#define HID_CLAIMED_HIDDEV BIT(1)
+#define HID_CLAIMED_HIDRAW BIT(2)
+#define HID_CLAIMED_DRIVER BIT(3)
-#define HID_STAT_ADDED 1
-#define HID_STAT_PARSED 2
+#define HID_STAT_ADDED BIT(0)
+#define HID_STAT_PARSED BIT(1)
struct hid_input {
struct list_head list;
--
2.14.3
^ permalink raw reply related
* [PATCH 4/7] HID: use BIT() macro for quirks too
From: Benjamin Tissoires @ 2018-03-20 11:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20180320110451.16582-1-benjamin.tissoires@redhat.com>
This should prevent future mess ups fortunately.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
include/linux/hid.h | 52 ++++++++++++++++++++++++++--------------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index ea78336984d3..3ad758dc285c 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -311,13 +311,13 @@ struct hid_item {
* HID connect requests
*/
-#define HID_CONNECT_HIDINPUT 0x01
-#define HID_CONNECT_HIDINPUT_FORCE 0x02
-#define HID_CONNECT_HIDRAW 0x04
-#define HID_CONNECT_HIDDEV 0x08
-#define HID_CONNECT_HIDDEV_FORCE 0x10
-#define HID_CONNECT_FF 0x20
-#define HID_CONNECT_DRIVER 0x40
+#define HID_CONNECT_HIDINPUT BIT(0)
+#define HID_CONNECT_HIDINPUT_FORCE BIT(1)
+#define HID_CONNECT_HIDRAW BIT(2)
+#define HID_CONNECT_HIDDEV BIT(3)
+#define HID_CONNECT_HIDDEV_FORCE BIT(4)
+#define HID_CONNECT_FF BIT(5)
+#define HID_CONNECT_DRIVER BIT(6)
#define HID_CONNECT_DEFAULT (HID_CONNECT_HIDINPUT|HID_CONNECT_HIDRAW| \
HID_CONNECT_HIDDEV|HID_CONNECT_FF)
@@ -330,25 +330,25 @@ struct hid_item {
*/
#define MAX_USBHID_BOOT_QUIRKS 4
-#define HID_QUIRK_INVERT 0x00000001
-#define HID_QUIRK_NOTOUCH 0x00000002
-#define HID_QUIRK_IGNORE 0x00000004
-#define HID_QUIRK_NOGET 0x00000008
-#define HID_QUIRK_HIDDEV_FORCE 0x00000010
-#define HID_QUIRK_BADPAD 0x00000020
-#define HID_QUIRK_MULTI_INPUT 0x00000040
-#define HID_QUIRK_HIDINPUT_FORCE 0x00000080
-#define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
-/* 0x00000200 reserved for backward compatibility, was NO_INIT_INPUT_REPORTS */
-#define HID_QUIRK_ALWAYS_POLL 0x00000400
-#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
-#define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x00020000
-#define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x00040000
-#define HID_QUIRK_HAVE_SPECIAL_DRIVER 0x00080000
-#define HID_QUIRK_FULLSPEED_INTERVAL 0x10000000
-#define HID_QUIRK_NO_INIT_REPORTS 0x20000000
-#define HID_QUIRK_NO_IGNORE 0x40000000
-#define HID_QUIRK_NO_INPUT_SYNC 0x80000000
+#define HID_QUIRK_INVERT BIT(0)
+#define HID_QUIRK_NOTOUCH BIT(1)
+#define HID_QUIRK_IGNORE BIT(2)
+#define HID_QUIRK_NOGET BIT(3)
+#define HID_QUIRK_HIDDEV_FORCE BIT(4)
+#define HID_QUIRK_BADPAD BIT(5)
+#define HID_QUIRK_MULTI_INPUT BIT(6)
+#define HID_QUIRK_HIDINPUT_FORCE BIT(7)
+#define HID_QUIRK_NO_EMPTY_INPUT BIT(8)
+/* BIT(9) reserved for backward compatibility, was NO_INIT_INPUT_REPORTS */
+#define HID_QUIRK_ALWAYS_POLL BIT(10)
+#define HID_QUIRK_SKIP_OUTPUT_REPORTS BIT(16)
+#define HID_QUIRK_SKIP_OUTPUT_REPORT_ID BIT(17)
+#define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP BIT(18)
+#define HID_QUIRK_HAVE_SPECIAL_DRIVER BIT(19)
+#define HID_QUIRK_FULLSPEED_INTERVAL BIT(28)
+#define HID_QUIRK_NO_INIT_REPORTS BIT(29)
+#define HID_QUIRK_NO_IGNORE BIT(30)
+#define HID_QUIRK_NO_INPUT_SYNC BIT(31)
/*
* HID device groups
--
2.14.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox