Re: [PATCH] Documentation: Fix misconversion of #if
Em Tue, 16 Jan 2018 19:40:55 -0800 Matthew Wilcox escreveu: > From: Matthew Wilcox > > At some stage of the conversion pipeline, something thought that the > DocBook entity # should be rendered as NUM instead of #. > > Signed-off-by: Matthew Wilcox Reviewed-by: Mauro Carvalho Chehab > --- > Documentation/kernel-hacking/hacking.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/kernel-hacking/hacking.rst > b/Documentation/kernel-hacking/hacking.rst > index daf3883b2694..5c4d30e81b7f 100644 > --- a/Documentation/kernel-hacking/hacking.rst > +++ b/Documentation/kernel-hacking/hacking.rst > @@ -690,8 +690,8 @@ not provide the necessary runtime environment and the > include files are > not tested for it. It is still possible, but not recommended. If you > really want to do this, forget about exceptions at least. > > -NUMif > -- > +#if > +--- > > It is generally considered cleaner to use macros in header files (or at > the top of .c files) to abstract away functions rather than using \`#if' Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -mm 0/4] mm, memcg: introduce oom policies
On Tue, Jan 16, 2018 at 06:14:58PM -0800, David Rientjes wrote: > There are three significant concerns about the cgroup aware oom killer as > it is implemented in -mm: > > (1) allows users to evade the oom killer by creating subcontainers or > using other controllers since scoring is done per cgroup and not > hierarchically, > > (2) does not allow the user to influence the decisionmaking, such that > important subtrees cannot be preferred or biased, and > > (3) unfairly compares the root mem cgroup using completely different > criteria than leaf mem cgroups and allows wildly inaccurate results > if oom_score_adj is used. > > This patchset aims to fix (1) completely and, by doing so, introduces a > completely extensible user interface that can be expanded in the future. > > It eliminates the mount option for the cgroup aware oom killer entirely > since it is now enabled through the root mem cgroup's oom policy. > > It eliminates a pointless tunable, memory.oom_group, that unnecessarily > pollutes the mem cgroup v2 filesystem and is invalid when cgroup v2 is > mounted with the "groupoom" option. You're introducing a new oom_policy knob, which has two separate sets of possible values for the root and non-root cgroups. I don't think it aligns with the existing cgroup v2 design. For the root cgroup it works exactly as mount option, and both "none" and "cgroup" values have no meaning outside of the root cgroup. We can discuss if a knob on root cgroup is better than a mount option, or not (I don't think so), but it has nothing to do with oom policy as you define it for non-root cgroups. For non-root cgroups you're introducing "all" and "tree", and the _only_ difference is that in the "all" mode all processes will be killed, rather than the biggest in the "tree". I find these names confusing, in reality it's more "evaluate together and kill all" and "evaluate together and kill one". So, it's not really the fully hierarchical approach, which I thought, you were arguing for. You can easily do the same with adding the third value to the memory.groupoom knob, as I've suggested earlier (say, "disable, "kill" and "evaluate"), and will be much less confusing. Thanks! Roman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
Hello Dmitry, On Tue, Jan 16, 2018 at 03:16:25PM -0800, Dmitry Torokhov wrote: > Hi Marcus, > > On Sat, Jan 13, 2018 at 09:15:32PM +0100, Marcus Folkesson wrote: > > This driver let you plug in your RC controller to the adapter and > > use it as input device in various RC simulators. > > > > Signed-off-by: Marcus Folkesson > > --- > > v3: > > - Use RUDDER and MISC instead of TILT_X and TILT_Y > > - Drop kref and anchor > > - Rework URB handling > > - Add PM support > > How did you test the PM support? By default the autopm is disabled on > USB devices; you need to enable it by writing to sysfs (I believe you > need to 'echo "auto" > /sys/bus/usb//power/control) and see if > it gets autosuspended when not in use and resumed after you start > interacting with it. The test I've done is simply reading from the input device and then call `pm-suspend`. It works, suspend is called and reset_resume() will submit the URB again. Without the PM code, the application did not read any events upon resume. However, I found another tricky part. If I enable autosuspend (as you suggest) it will suspend when noone is using the device. Good. But when someone is opening the device, input_dev->users is counted up to 1 before resume() is called. Is this intended? This code (from resume()) will therefor allways submit the URB: if (input_dev->users && usb_submit_urb(pxrc->urb, GFP_NOIO) < 0) Then open() is called and fails because the urb is allready submitted. input_dev->users is only incremented in input.c:input_open_device() what I can tell? I will move the submitting code to reset_resume() instead. > > > v2: > > - Change module license to GPLv2 to match SPDX tag > > > > Documentation/input/devices/pxrc.rst | 57 +++ > > drivers/input/joystick/Kconfig | 9 + > > drivers/input/joystick/Makefile | 1 + > > drivers/input/joystick/pxrc.c| 320 > > +++ > > 4 files changed, 387 insertions(+) > > create mode 100644 Documentation/input/devices/pxrc.rst > > create mode 100644 drivers/input/joystick/pxrc.c > > > > diff --git a/Documentation/input/devices/pxrc.rst > > b/Documentation/input/devices/pxrc.rst > > new file mode 100644 > > index ..ca11f646bae8 > > --- /dev/null > > +++ b/Documentation/input/devices/pxrc.rst > > @@ -0,0 +1,57 @@ > > +=== > > +pxrc - PhoenixRC Flight Controller Adapter > > +=== > > + > > +:Author: Marcus Folkesson > > + > > +This driver let you use your own RC controller plugged into the > > +adapter that comes with PhoenixRC [1]_ or other compatible adapters. > > + > > +The adapter supports 7 analog channels and 1 digital input switch. > > + > > +Notes > > += > > + > > +Many RC controllers is able to configure which stick goes to which channel. > > +This is also configurable in most simulators, so a matching is not > > necessary. > > + > > +The driver is generating the following input event for analog channels: > > + > > ++-++ > > +| Channel | Event | > > ++=++ > > +| 1 | ABS_X | > > ++-++ > > +| 2 | ABS_Y | > > ++-++ > > +| 3 | ABS_RX| > > ++-++ > > +| 4 | ABS_RY| > > ++-++ > > +| 5 | ABS_RUDDER| > > ++-++ > > +| 6 | ABS_THROTTLE | > > ++-++ > > +| 7 | ABS_MISC | > > ++-++ > > + > > +The digital input switch is generated as an `BTN_A` event. > > + > > +Manual Testing > > +== > > + > > +To test this driver's functionality you may use `input-event` which is > > part of > > +the `input layer utilities` suite [2]_. > > + > > +For example:: > > + > > +> modprobe pxrc > > +> input-events > > + > > +To print all input events from input `devnr`. > > + > > +References > > +== > > + > > +.. [1] http://www.phoenix-sim.com/ > > +.. [2] https://www.kraxel.org/cgit/input/ > > diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig > > index f3c2f6ea8b44..18ab6dafff41 100644 > > --- a/drivers/input/joystick/Kconfig > > +++ b/drivers/input/joystick/Kconfig > > @@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF > > > > To drive rumble motor a dedicated power supply is required. > > > > +config JOYSTICK_PXRC > > + tristate "PhoenixRC Flight Controller Adapter" > > + depends on USB_ARCH_HAS_HCD > > + select USB > > + help > > + Say Y here if you want to use the PhoenixRC Flight Controller Adapter. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called pxrc. > > endif > > diff --git a/drivers/input/joystick/Makefile > > b/drivers/input/joystick/Makefile > > index 67651efda2e1.
[PATCH v2 2/2] fscrypt: update documentation for encrypted key support
Signed-off-by: André Draszik Cc: "Theodore Y. Ts'o" Cc: Jaegeuk Kim Cc: Jonathan Corbet Cc: linux-fscr...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Eric Biggers Cc: linux-doc@vger.kernel.org --- Documentation/filesystems/fscrypt.rst | 56 +++ 1 file changed, 51 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 776ddc655f79..852ac2900b66 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -368,11 +368,19 @@ Adding keys To provide a master key, userspace must add it to an appropriate keyring using the add_key() system call (see: ``Documentation/security/keys/core.rst``). The key type must be -"logon"; keys of this type are kept in kernel memory and cannot be -read back by userspace. The key description must be "fscrypt:" -followed by the 16-character lower case hex representation of the -``master_key_descriptor`` that was set in the encryption policy. The -key payload must conform to the following structure:: +either "logon" or "encrypted"; "logon" keys are kept in kernel +memory and cannot be read back by userspace while "encrypted" +keys can be rooted in a "trusted" key and thus are protected by +a TPM and cannot be read by userspace in unencrypted form. Note +that while an "encrypted" key can also be rooted in a "user" key, +any "encrypted" key rooted in a "user" key can effectively be +retrieved in the clear, hence only rooting the key in a "trusted" +key has any useful security properties! + +The key description must be "fscrypt:" followed by the 16-character +lower case hex representation of the ``master_key_descriptor`` that +was set in the encryption policy. For a "logon" key, key payload +must conform to the following structure:: #define FS_MAX_KEY_SIZE 64 @@ -386,6 +394,17 @@ key payload must conform to the following structure:: ``raw`` with ``size`` indicating its size in bytes. That is, the bytes ``raw[0..size-1]`` (inclusive) are the actual key. +When using an "encrypted" key, only the actual ``raw`` key from above +fscrypt_key structure is needed:: + +keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-name`` ``size``" ``ring`` +keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` + +Where:: + +master-key-name:= name of the trusted key this fscrypt master key + shall be rooted in + The key description prefix "fscrypt:" may alternatively be replaced with a filesystem-specific prefix such as "ext4:". However, the filesystem-specific prefixes are deprecated and should not be used in @@ -412,6 +431,33 @@ evicted. In the future there probably should be a way to provide keys directly to the filesystem instead, which would make the intended semantics clearer. +Complete Examples +-- + +Set fscrypt policy on an (empty) encrypted directory, /encrypted:: + +$ fscryptctl set_policy 1234567890123456 /encrypted + +Create an encrypted key "1234567890123456" of length 64 bytes with format +'fscrypt' and root it in a previously loaded trusted "kmk":: + +$ keyctl add encrypted "fscrypt:1234567890123456" "new default trusted:kmk 64" @u +839715473 + +$ keyctl print 839715473 +default trusted:kmk 64 e98a49dc11eb9312f46530879aac869300ee734035100f4ee +5441279369a4c9d83d6e59b8158d0a3de01790c0bb99af82e9603cb6977c7d1229338cda +80375aaf034678405a00c19806d6fb12490e39b1d7ca603c491b58a962345160e344ae51 +83483e066692d05f5ab3d8b9ea39cab0e + +$ keyctl pipe 839715473 > fscrypt.blob + +The directory policy will remain across reboots, so after a reboot the key +generated earlier will simply have to be loaded into the kernel keyring +again:: + +$ keyctl add encrypted fscrypt:1234567890123456 "load $(cat fscrypt.blob)" @u + Access semantics -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] encrypted-keys: document new fscrypt key format
Hi Eric, On Wed, 2018-01-10 at 20:48 -0800, Eric Biggers wrote: > Hi André, > > On Wed, Jan 10, 2018 at 12:44:18PM +, André Draszik wrote: > > diff --git a/Documentation/security/keys/fscrypt.rst > > b/Documentation/security/keys/fscrypt.rst > > new file mode 100644 > > index ..e4a29592513e > > --- /dev/null > > +++ b/Documentation/security/keys/fscrypt.rst > > @@ -0,0 +1,67 @@ > > + > > +Encrypted keys for the fscrypt subsystem > > + > > There is now documentation for fscrypt in > Documentation/filesystems/fscrypt.rst; > see in particular the "Adding keys" section. The documentation for any > new ways > to add keys should go in there. Done. > > > + > > +fscrypt allows file systems to implement transparent encryption and > > decryption > > +of files, similar to eCryptfs, using keys derived from a master key > > descriptor. > > Note that the master key *descriptor* refers to the hex string used in the > keyring key description. It is not the same as the master key itself, > which is > stored in the payload. The cryptography is done with the master key, not > with > the master key *descriptor*. Ups, thanks. > > [...] > > Please be very clear about exactly what security properties are achieved > by > using encrypted-keys. I've left out all of this in the updated documentation, as any such information should probably be in Documentation/security/keys/trusted- encrypted.rst in the first place. > [...] > > + > > +Example of encrypted key usage with the fscrypt subsystem: > > + > > +Create an encrypted key "1234567890123456" of length 64 bytes with > > format > > +'fscrypt' and save it using a previously loaded user key "test":: > > + > > +$ keyctl add encrypted fscrypt:1234567890123456 "new fscrypt > > user:test 64" @u > > +1023935199 > > + > > +$ keyctl print 1023935199 > > +fscrypt user:test 64 > > e5606689fdc25d78a787249f4069fb3b007e992f4b21d0eda60 > > +c97986fc2e3326b5542e2b32216fc5007d9fd19cd3cb6668fa9850e954d2ba25e1b > > 8a331 > > +1b0c1f20666c > > + > > +$ keyctl pipe 1023935199 > fscrypt.blob > > What is the point of having the kernel wrap a key with the "user" key > type? It > seems pointless; userspace could just do it instead. Yes... My real reasoning is being able to use an encrypted key, backed by a trusted TPM key. I've updated the examples. > [...] > I think it's really only "trusted" wrapping keys where this new feature > would > have any useful security properties. So the documentation needs to > explain > that, and use that in the examples. You're right. Done. Cheers, André -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable
Hello, David. On Tue, Jan 16, 2018 at 06:15:08PM -0800, David Rientjes wrote: > The behavior of killing an entire indivisible memory consumer, enabled > by memory.oom_group, is an oom policy itself. It specifies that all I thought we discussed this before but maybe I'm misremembering. There are two parts to the OOM policy. One is victim selection, the other is the action to take thereafter. The two are different and conflating the two don't work too well. For example, please consider what should be given to the delegatee when delegating a subtree, which often is a good excercise when designing these APIs. When a given workload is selected for OOM kill (IOW, selected to free some memory), whether the workload can handle individual process kills or not is the property of the workload itself. Some applications can safely handle some of its processes picked off and killed. Most others can't and want to be handled as a single unit, which makes it a property of the workload. That makes sense in the hierarchy too because whether one process or the whole workload is killed doesn't infringe upon the parent's authority over resources which in turn implies that there's nothing to worry about how the parent's groupoom setting should constrain the descendants. OOM victim selection policy is a different beast. As you've mentioned multiple times, especially if you're worrying about people abusing OOM policies by creating sub-cgroups and so on, the policy, first of all, shouldn't be delegatable and secondly should have meaningful hierarchical restrictions so that a policy that an ancestor chose can't be nullified by a descendant. I'm not necessarily against adding hierarchical victim selection policy tunables; however, I am skeptical whether static tunables on cgroup hierarchy (including selectable policies) can be made clean and versatile enough, especially because the resource hierarchy doesn't necessarily, or rather in most cases, match the OOM victim selection decision tree, but I'd be happy to be proven wrong. Without explicit configurations, the only thing the OOM killer needs to guarantee is that the system can make forward progress. We've always been tweaking victim selection with or without cgroup and absolutely shouldn't be locked into a specific heuristics. The heuristics is an implementaiton detail subject to improvements. To me, your patchset actually seems to demonstrate that these are separate issues. The goal of groupoom is just to kill logical units as cgroup hierarchy can inform the kernel of how workloads are composed in the userspace. If you want to improve victim selection, sure, please go ahead, but your argument that groupoom can't be merged because of victim selection policy doesn't make sense to me. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable
On Wed 17-01-18 07:41:55, Tejun Heo wrote: > Hello, David. > > On Tue, Jan 16, 2018 at 06:15:08PM -0800, David Rientjes wrote: > > The behavior of killing an entire indivisible memory consumer, enabled > > by memory.oom_group, is an oom policy itself. It specifies that all > > I thought we discussed this before but maybe I'm misremembering. > There are two parts to the OOM policy. One is victim selection, the > other is the action to take thereafter. Yes we have. Multiple times! The last time I've said the very same thing was yesterday http://lkml.kernel.org/r/20180116220907.gd17...@dhcp22.suse.cz > The two are different and conflating the two don't work too well. For > example, please consider what should be given to the delegatee when > delegating a subtree, which often is a good excercise when designing > these APIs. Absolutely agreed! And moreover, there are not all that many ways what to do as an action. You just kill a logical entity - be it a process or a logical group of processes. But you have way too many policies how to select that entity. Do you want to chose the youngest process/group because all the older ones have been computing real stuff and you would lose days of your cpu time? Or should those who pay more should be protected (aka give them static priorities), or you name it... I am sorry, I still didn't grasp the full semantic of the proposed soluton but the mere fact it is starting by conflating selection and the action is a no go and a wrong API. This is why I've said that what you (David) outlined yesterday is probably going to suffer from a much longer discussion and most likely to be not acceptable. Your patchset proves me correct... -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Documentation: rapidio: move sysfs interface to ABI
For users convenience and due to limited use of RapidIO I would prefer to keep all subsystem documentation in one place. Also, having text file in free format gives us ability to easily add explanations and examples which we cannot have in ABI documentation format. If converting this file into ABI doc is absolutely necessary: - please keep the original sysfs.txt with a single statement that directs reader to the ABI docs. - see comments below On Tuesday, Jan 9, 2018 at 6:21 AM, Aishwarya Pant wrote: > Subject: [PATCH] Documentation: rapidio: move sysfs interface to ABI > > Right now, the description of the rapidio sysfs interfaces is in > Documentation/rapidio/sysfs.txt. Since these are a part of the ABI, they > should be in Documentation/ABI along with the rest. > > Signed-off-by: Aishwarya Pant > --- > Documentation/ABI/testing/sysfs-bus-rapidio | 183 > ++ > Documentation/ABI/testing/sysfs-class-rapidio | 55 > Documentation/rapidio/sysfs.txt | 158 -- > 3 files changed, 238 insertions(+), 158 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-bus-rapidio > create mode 100644 Documentation/ABI/testing/sysfs-class-rapidio > delete mode 100644 Documentation/rapidio/sysfs.txt > > diff --git a/Documentation/ABI/testing/sysfs-bus-rapidio > b/Documentation/ABI/testing/sysfs-bus-rapidio > new file mode 100644 > index ..9b755776c1ab > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-rapidio > @@ -0,0 +1,183 @@ > +What:/sys/bus/rapidio/devices/00:e: > +What:/sys/bus/rapidio/devices/00:e:0002 > +What:/sys/bus/rapidio/devices/00:s:0001 > +Description: > + For each RapidIO device, the RapidIO subsystem creates files > in > + an individual subdirectory with the following name format of > + device_name "nn:d:", where: > + > + nn - two-digit hexadecimal ID of RapidIO network where the > + device resides > + d - device typr: 'e' - for endpoint or 's' - for switch Typo here > + - four-digit device destID for endpoints, or switchID for > + switches > + > + NOTE: An enumerating or discovering endpoint does not > create a > + sysfs entry for itself, this is why an endpoint with destID=1 is > + not shown in the list. > + The note above used without explanatory context changes the idea: it sounds like enumerator's destID is always 1. > +Attributes Common for All RapidIO Devices > +- > + > +What:/sys/bus/rapidio/devices/nn:d:/did > +Date:Nov, 2005 > +KernelVersion: v2.6.15 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns the device identifier > + > +What:/sys/bus/rapidio/devices/nn:d:/vid > +Date:Nov, 2005 > +KernelVersion: v2.6.15 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns the device vendor identifier > + > +What:/sys/bus/rapidio/devices/nn:d:/device_rev > +Date:Nov, 2005 > +KernelVersion: v2.6.15 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns the device revision level > + > +What:/sys/bus/rapidio/devices/nn:d:/asm_did > +Date:Nov, 2005 > +KernelVersion: v2.6.15 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns identifier for the assembly containing the device > + > +What:/sys/bus/rapidio/devices/nn:d:/asm_rev > +Date:Nov, 2005 > +KernelVersion: v2.6.15 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns revision level of the assembly containing the > + device > + > +What:/sys/bus/rapidio/devices/nn:d:/asm_vid > +Date:Nov, 2005 > +KernelVersion: v2.6.15 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns vendor identifier of the assembly containing the > + device > + The "destid" attribute must be here: it is common for all RapidIO devices. Must be note explaining a different role for switches. > +What:/sys/bus/rapidio/devices/nn:d:/lprev > +Date:Mar, 2011 > +KernelVersion: v2.6.39 > +Contact: Matt Porter , > + Alexandre Bounine > +Description: > + (RO) returns name of previous device (switch) on the path to > the > + device that that owns this attribute > + > +What:/sys/bus/rapidio/devices/nn:d:/modalias > +Date:Jul,
Re: [PATCH 3/3] encrypted-keys: document new fscrypt key format
On Wed, Jan 17, 2018 at 02:38:59PM +, André Draszik wrote: > > > [...] > > > > Please be very clear about exactly what security properties are achieved > > by > > using encrypted-keys. > > I've left out all of this in the updated documentation, as any such > information should probably be in Documentation/security/keys/trusted- > encrypted.rst in the first place. Where is this document going to be found / when will it be written? It seems really odd to be requesting a do code review when the specifications aren't available and/or haven't been written yet. I prefer to review the *design* first, as opposed to trying to both review the code and try to guess at the design and review my guess of the design at the same time - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
This driver let you plug in your RC controller to the adapter and
use it as input device in various RC simulators.
Signed-off-by: Marcus Folkesson
---
v4:
- Add call to usb_mark_last_busy() in irq
- Move code from pxrc_resume() to pxrc_reset_resume()
v3:
- Use RUDDER and MISC instead of TILT_X and TILT_Y
- Drop kref and anchor
- Rework URB handling
- Add PM support
v2:
- Change module license to GPLv2 to match SPDX tag
Documentation/input/devices/pxrc.rst | 57 +++
drivers/input/joystick/Kconfig | 9 +
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/pxrc.c| 318 +++
4 files changed, 385 insertions(+)
create mode 100644 Documentation/input/devices/pxrc.rst
create mode 100644 drivers/input/joystick/pxrc.c
diff --git a/Documentation/input/devices/pxrc.rst
b/Documentation/input/devices/pxrc.rst
new file mode 100644
index ..ca11f646bae8
--- /dev/null
+++ b/Documentation/input/devices/pxrc.rst
@@ -0,0 +1,57 @@
+===
+pxrc - PhoenixRC Flight Controller Adapter
+===
+
+:Author: Marcus Folkesson
+
+This driver let you use your own RC controller plugged into the
+adapter that comes with PhoenixRC [1]_ or other compatible adapters.
+
+The adapter supports 7 analog channels and 1 digital input switch.
+
+Notes
+=
+
+Many RC controllers is able to configure which stick goes to which channel.
+This is also configurable in most simulators, so a matching is not necessary.
+
+The driver is generating the following input event for analog channels:
+
++-++
+| Channel | Event |
++=++
+| 1 | ABS_X |
++-++
+| 2 | ABS_Y |
++-++
+| 3 | ABS_RX|
++-++
+| 4 | ABS_RY|
++-++
+| 5 | ABS_RUDDER|
++-++
+| 6 | ABS_THROTTLE |
++-++
+| 7 | ABS_MISC |
++-++
+
+The digital input switch is generated as an `BTN_A` event.
+
+Manual Testing
+==
+
+To test this driver's functionality you may use `input-event` which is part of
+the `input layer utilities` suite [2]_.
+
+For example::
+
+> modprobe pxrc
+> input-events
+
+To print all input events from input `devnr`.
+
+References
+==
+
+.. [1] http://www.phoenix-sim.com/
+.. [2] https://www.kraxel.org/cgit/input/
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index f3c2f6ea8b44..18ab6dafff41 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF
To drive rumble motor a dedicated power supply is required.
+config JOYSTICK_PXRC
+ tristate "PhoenixRC Flight Controller Adapter"
+ depends on USB_ARCH_HAS_HCD
+ select USB
+ help
+ Say Y here if you want to use the PhoenixRC Flight Controller Adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called pxrc.
endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 67651efda2e1..dd0492ebbed7 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_JOYSTICK_JOYDUMP)+= joydump.o
obj-$(CONFIG_JOYSTICK_MAGELLAN)+= magellan.o
obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
obj-$(CONFIG_JOYSTICK_PSXPAD_SPI) += psxpad-spi.o
+obj-$(CONFIG_JOYSTICK_PXRC)+= pxrc.o
obj-$(CONFIG_JOYSTICK_SIDEWINDER) += sidewinder.o
obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
obj-$(CONFIG_JOYSTICK_SPACEORB)+= spaceorb.o
diff --git a/drivers/input/joystick/pxrc.c b/drivers/input/joystick/pxrc.c
new file mode 100644
index ..216df4bf4484
--- /dev/null
+++ b/drivers/input/joystick/pxrc.c
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Phoenix RC Flight Controller Adapter
+ *
+ * Copyright (C) 2018 Marcus Folkesson
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PXRC_VENDOR_ID (0x1781)
+#define PXRC_PRODUCT_ID(0x0898)
+
+static const struct usb_device_id pxrc_table[] = {
+ { USB_DEVICE(PXRC_VENDOR_ID, PXRC_PRODUCT_ID) },
+ { }
+};
+MODULE_DEVICE_TABLE(usb, pxrc_table);
+
+struct pxrc {
+ struct input_dev*input;
+ struct usb_device *udev;
+ struct usb_interface*intf;
+ struct urb *urb;
+ __u8epaddr;
+ charphys[64];
+ unsigned char *data;
+ size_t
Re: [PATCH v4] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
On 01/17/2018 11:07 AM, Marcus Folkesson wrote: > This driver let you plug in your RC controller to the adapter and > use it as input device in various RC simulators. > > Signed-off-by: Marcus Folkesson > --- > diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig > index f3c2f6ea8b44..18ab6dafff41 100644 > --- a/drivers/input/joystick/Kconfig > +++ b/drivers/input/joystick/Kconfig > @@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF > > To drive rumble motor a dedicated power supply is required. > > +config JOYSTICK_PXRC > + tristate "PhoenixRC Flight Controller Adapter" > + depends on USB_ARCH_HAS_HCD > + select USB Drop the (first) depends and change "select USB" to "depends on USB". Argh, there are lots of input/ drivers that do that. That's bad/wrong. A driver should not select (enable) an entire subsystem. If the user had the subsystem disabled, it should stay that way. Dmitry, you can expect some patches... > + help > + Say Y here if you want to use the PhoenixRC Flight Controller Adapter. > + > + To compile this driver as a module, choose M here: the > + module will be called pxrc. > endif -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
Hi Randy! On Wed, Jan 17, 2018 at 11:13:43AM -0800, Randy Dunlap wrote: > On 01/17/2018 11:07 AM, Marcus Folkesson wrote: > > This driver let you plug in your RC controller to the adapter and > > use it as input device in various RC simulators. > > > > Signed-off-by: Marcus Folkesson > > --- > > > diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig > > index f3c2f6ea8b44..18ab6dafff41 100644 > > --- a/drivers/input/joystick/Kconfig > > +++ b/drivers/input/joystick/Kconfig > > @@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF > > > > To drive rumble motor a dedicated power supply is required. > > > > +config JOYSTICK_PXRC > > + tristate "PhoenixRC Flight Controller Adapter" > > + depends on USB_ARCH_HAS_HCD > > + select USB > > Drop the (first) depends and change "select USB" to "depends on USB". > > Argh, there are lots of input/ drivers that do that. That's bad/wrong. > A driver should not select (enable) an entire subsystem. If the user had > the subsystem disabled, it should stay that way. > > Dmitry, you can expect some patches... > Hah, of course it should be "depends on" :-) Other drivers fooled me... Should I fix the other drivers too when I'm on it, or do you? > > + help > > + Say Y here if you want to use the PhoenixRC Flight Controller Adapter. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called pxrc. > > endif > > -- > ~Randy Best regards Marcus Folkesson signature.asc Description: PGP signature
Re: [PATCH v4] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
On 01/17/2018 11:45 AM, Marcus Folkesson wrote: > Hi Randy! > > On Wed, Jan 17, 2018 at 11:13:43AM -0800, Randy Dunlap wrote: >> On 01/17/2018 11:07 AM, Marcus Folkesson wrote: >>> This driver let you plug in your RC controller to the adapter and >>> use it as input device in various RC simulators. >>> >>> Signed-off-by: Marcus Folkesson >>> --- >> >>> diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig >>> index f3c2f6ea8b44..18ab6dafff41 100644 >>> --- a/drivers/input/joystick/Kconfig >>> +++ b/drivers/input/joystick/Kconfig >>> @@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF >>> >>> To drive rumble motor a dedicated power supply is required. >>> >>> +config JOYSTICK_PXRC >>> + tristate "PhoenixRC Flight Controller Adapter" >>> + depends on USB_ARCH_HAS_HCD >>> + select USB >> >> Drop the (first) depends and change "select USB" to "depends on USB". >> >> Argh, there are lots of input/ drivers that do that. That's bad/wrong. >> A driver should not select (enable) an entire subsystem. If the user had >> the subsystem disabled, it should stay that way. >> >> Dmitry, you can expect some patches... >> > > Hah, of course it should be "depends on" :-) > Other drivers fooled me... > > Should I fix the other drivers too when I'm on it, or do you? Either way. If you are up for it, please go ahead. thanks, -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable
On Wed, 17 Jan 2018, Tejun Heo wrote: > Hello, David. > Hi Tejun! > > The behavior of killing an entire indivisible memory consumer, enabled > > by memory.oom_group, is an oom policy itself. It specifies that all > > I thought we discussed this before but maybe I'm misremembering. > There are two parts to the OOM policy. One is victim selection, the > other is the action to take thereafter. > > The two are different and conflating the two don't work too well. For > example, please consider what should be given to the delegatee when > delegating a subtree, which often is a good excercise when designing > these APIs. > > When a given workload is selected for OOM kill (IOW, selected to free > some memory), whether the workload can handle individual process kills > or not is the property of the workload itself. Some applications can > safely handle some of its processes picked off and killed. Most > others can't and want to be handled as a single unit, which makes it a > property of the workload. > Yes, this is a valid point. The policy of "tree" and "all" are identical policies and then the mechanism differs wrt to whether one process is killed or all eligible processes are killed, respectively. My motivation for this was to avoid having two different tunables, especially because later we'll need a way for userspace to influence the decisionmaking to protect (bias against) important subtrees. What would really be nice is cgroup.subtree_control-type behavior where we could effect a policy and a mechanism at the same time. It's not clear how that would be handled to allow only one policy and one mechanism, however, in a clean way. The simplest for the user would be a new file, to specify the mechanism and leave memory.oom_policy alone. Would another file really be warranted? Not sure. > That makes sense in the hierarchy too because whether one process or > the whole workload is killed doesn't infringe upon the parent's > authority over resources which in turn implies that there's nothing to > worry about how the parent's groupoom setting should constrain the > descendants. > > OOM victim selection policy is a different beast. As you've mentioned > multiple times, especially if you're worrying about people abusing OOM > policies by creating sub-cgroups and so on, the policy, first of all, > shouldn't be delegatable and secondly should have meaningful > hierarchical restrictions so that a policy that an ancestor chose > can't be nullified by a descendant. > The goal here was to require a policy of either "tree" or "all" that the user can't change. They are allowed to have their own oom policies internal to their subtree, however, for oom conditions in that subtree alone. However, if the common ancestor hits its limit, it is forced to either be "tree" or "all" and require hierarchical usage to be considered instead of localized usage. Either "tree" or "all" is appropriate, and this may be why you brought up the point about separating them out, i.e. the policy can be demanded by the common ancestor but the actual mechanism that the oom killer uses, kill either a single process or the full cgroup, is left to the user depending on their workload. That sounds reasonable and I can easily separate the two by introducing a new file, similar to memory.oom_group but in a more extensible way so that it is not simply a selection of either full cgroup kill or single process. > I'm not necessarily against adding hierarchical victim selection > policy tunables; however, I am skeptical whether static tunables on > cgroup hierarchy (including selectable policies) can be made clean and > versatile enough, especially because the resource hierarchy doesn't > necessarily, or rather in most cases, match the OOM victim selection > decision tree, but I'd be happy to be proven wrong. > Right, and I think that giving users control over their subtrees is a powerful tool and one that can lead to very effective use of the cgroup v2 hierarchy. Being able to circumvent the oom selection by creating child cgroups is certainly something that can trivially be prevented. The argument that users can currently divide their entire processes into several different smaller processes to circumvent today's heuristic doesn't mean we can't have "tree"-like comparisons between cgroups to address that issue itself since all processes charge to the tree itself. I became convinced of this when I saw the real-world usecases that would use such a feature on cgroup v2: we want to have hierarchical usage for comparison when full subtrees are dedicated to individual consumers, for example, and local mem cgroup usage for comparison when using hierarchies for top-level /admins and /students cgroups for which Michal provided an example. These can coexist on systems and it's clear that there needs to be a system-wide policy decision for the cgroup aware oom killer (the idea behind the current mou
Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable
On Wed, 17 Jan 2018, Michal Hocko wrote: > Absolutely agreed! And moreover, there are not all that many ways what > to do as an action. You just kill a logical entity - be it a process or > a logical group of processes. But you have way too many policies how > to select that entity. Do you want to chose the youngest process/group > because all the older ones have been computing real stuff and you would > lose days of your cpu time? Or should those who pay more should be > protected (aka give them static priorities), or you name it... > That's an argument for making the interface extensible, yes. > I am sorry, I still didn't grasp the full semantic of the proposed > soluton but the mere fact it is starting by conflating selection and the > action is a no go and a wrong API. This is why I've said that what you > (David) outlined yesterday is probably going to suffer from a much > longer discussion and most likely to be not acceptable. Your patchset > proves me correct... I'm very happy to change the API if there are better suggestions. That may end up just being an memory.oom_policy file, as this implements, and separating out a new memory.oom_action that isn't a boolean value to either do a full group kill or only a single process. Or it could be what I suggested in my mail to Tejun, such as "hierarchy killall" written to memory.oom_policy, which would specify a single policy and then an optional mechanism. With my proposed patchset, there would then be three policies: "none", "cgroup", and "tree" and one possible optional mechanism: "killall". -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -mm 0/4] mm, memcg: introduce oom policies
On Wed, 17 Jan 2018, Roman Gushchin wrote: > You're introducing a new oom_policy knob, which has two separate sets > of possible values for the root and non-root cgroups. I don't think > it aligns with the existing cgroup v2 design. > The root mem cgroup can use "none" or "cgroup" to either disable or enable, respectively, the cgroup aware oom killer. These are available to non root mem cgroups as well, with the addition of hierarchical usage comparison to prevent the ability to completely evade the oom killer by the user by creating sub cgroups. Just as we have files that are made available on the root cgroup and not others, I think it's fine to allow only certain policies on the root mem cgroup. As I wrote to Tejun, I'm fine with the policy being separated from the mechanism. That can be resolved in that email thread, but the overall point of this patchset is to allow hierarchical comparison on some subtrees and not on others. We can avoid the mount option in the same manner. > For the root cgroup it works exactly as mount option, and both "none" > and "cgroup" values have no meaning outside of the root cgroup. We can > discuss if a knob on root cgroup is better than a mount option, or not > (I don't think so), but it has nothing to do with oom policy as you > define it for non-root cgroups. > It certainly does have value outside of the root cgroup: for system oom conditions it is possible to choose the largest process, largest single cgroup, or largest subtree to kill from. For memcg oom conditions it's possible for a consumer in a subtree to define whether it wants the largest memory hogging process to be oom killed or the largest of its child sub cgroups. This would be needed for a job scheduler in its own subtree, for example, that creates its own subtrees to limit jobs scheduled by individual users who have the power over their subtree but not their limit. This is a real-world example. Michal also provided his own example concerning top-level /admins and /students. They want to use "cgroup" themselves and then /students/roman would be forced to "tree". Keep in mind that this patchset alone makes the interface extensible and addresses one of my big three concerns, but the comparison of the root mem cgroup compared to other individual cgroups and cgroups maintaining a subtree needs to be fixed separately so that we don't completely evade all of these oom policies by using /proc/pid/oom_score_adj in the root mem cgroup. That's a separate issue that needs to be addressed. My last concern, about userspace influence, can probably be addressed after this is merged by yet another tunable since it's vital that important cgroups can be protected. It does make sense for an important cgroup to be able to use 50% of memory without being oom killed, and that's impossible if cgroup v2 has been mounted with your mount option. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: Fix misconversion of #if
On Tue, 16 Jan 2018 19:40:55 -0800 Matthew Wilcox wrote: > At some stage of the conversion pipeline, something thought that the > DocBook entity # should be rendered as NUM instead of #. Haven't you heard? It's a new, improved form of C trigraph... :) Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] linux-next: DOC: HWPOISON: Fix path to debugfs in hwpoison.txt
On Thu, 11 Jan 2018 22:28:37 +0900 Masanari Iida wrote: > This patch fixes an incorrect path for debugfs in hwpoison.txt > > Signed-off-by: Masanari Iida Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] linux-next: docs-rst: Fix typos in kfigure.py
On Thu, 11 Jan 2018 20:00:28 +0900 Masanari Iida wrote: > This patch fixes some spelling typos found in kfigure.py > > Signed-off-by: Masanari Iida Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller
On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote: > This bus driver supports the GENI based i2c hardware controller in the > Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable > module supporting a wide range of serial interfaces including I2C. The > driver supports FIFO mode and DMA mode of transfer and switches modes > dynamically depending on the size of the transfer. > > Signed-off-by: Karthikeyan Ramasubramanian > Signed-off-by: Sagar Dharia > Signed-off-by: Girish Mahadevan > --- > drivers/i2c/busses/Kconfig | 10 + > drivers/i2c/busses/Makefile| 1 + > drivers/i2c/busses/i2c-qcom-geni.c | 656 > + > 3 files changed, 667 insertions(+) > create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 009345d..caef309 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -838,6 +838,16 @@ config I2C_PXA_SLAVE > is necessary for systems where the PXA may be a target on the > I2C bus. > > +config I2C_QCOM_GENI > + tristate "Qualcomm Technologies Inc.'s GENI based I2C controller" > + depends on ARCH_QCOM Just depend on the GENI wrapper as well. > + help > + If you say yes to this option, support will be included for the > + built-in I2C interface on the Qualcomm Technologies Inc.'s SoCs. > + > + This driver can also be built as a module. If so, the module > + will be called i2c-qcom-geni. > + > config I2C_QUP > tristate "Qualcomm QUP based I2C controller" > depends on ARCH_QCOM > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile > index 2ce8576..201fce1 100644 > --- a/drivers/i2c/busses/Makefile > +++ b/drivers/i2c/busses/Makefile > @@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_PNX) += i2c-pnx.o > obj-$(CONFIG_I2C_PUV3) += i2c-puv3.o > obj-$(CONFIG_I2C_PXA)+= i2c-pxa.o > obj-$(CONFIG_I2C_PXA_PCI)+= i2c-pxa-pci.o > +obj-$(CONFIG_I2C_QCOM_GENI) += i2c-qcom-geni.o > obj-$(CONFIG_I2C_QUP)+= i2c-qup.o > obj-$(CONFIG_I2C_RIIC) += i2c-riic.o > obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o > diff --git a/drivers/i2c/busses/i2c-qcom-geni.c > b/drivers/i2c/busses/i2c-qcom-geni.c > new file mode 100644 > index 000..59ad4da > --- /dev/null > +++ b/drivers/i2c/busses/i2c-qcom-geni.c > @@ -0,0 +1,656 @@ > +/* > + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * 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. > + * > + */ Use SPDX license header. > + > +#include > +#include Unused? > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define SE_I2C_TX_TRANS_LEN (0x26C) Drop the parenthesis, when not needed. > +#define SE_I2C_RX_TRANS_LEN (0x270) > +#define SE_I2C_SCL_COUNTERS (0x278) > +#define SE_GENI_IOS (0x908) > + > +#define SE_I2C_ERR (M_CMD_OVERRUN_EN | M_ILLEGAL_CMD_EN | M_CMD_FAILURE_EN > |\ > + M_GP_IRQ_1_EN | M_GP_IRQ_3_EN | M_GP_IRQ_4_EN) > +#define SE_I2C_ABORT (1U << 1) > +/* M_CMD OP codes for I2C */ > +#define I2C_WRITE(0x1) > +#define I2C_READ (0x2) > +#define I2C_WRITE_READ (0x3) > +#define I2C_ADDR_ONLY(0x4) > +#define I2C_BUS_CLEAR(0x6) > +#define I2C_STOP_ON_BUS (0x7) > +/* M_CMD params for I2C */ > +#define PRE_CMD_DELAY(BIT(0)) > +#define TIMESTAMP_BEFORE (BIT(1)) > +#define STOP_STRETCH (BIT(2)) > +#define TIMESTAMP_AFTER (BIT(3)) > +#define POST_COMMAND_DELAY (BIT(4)) > +#define IGNORE_ADD_NACK (BIT(6)) > +#define READ_FINISHED_WITH_ACK (BIT(7)) > +#define BYPASS_ADDR_PHASE(BIT(8)) > +#define SLV_ADDR_MSK (GENMASK(15, 9)) > +#define SLV_ADDR_SHFT(9) > + > +#define I2C_CORE2X_VOTE (1) > +#define GP_IRQ0 0 > +#define GP_IRQ1 1 > +#define GP_IRQ2 2 > +#define GP_IRQ3 3 > +#define GP_IRQ4 4 > +#define GP_IRQ5 5 > +#define GENI_OVERRUN 6 > +#define GENI_ILLEGAL_CMD 7 > +#define GENI_ABORT_DONE 8 > +#define GENI_TIMEOUT 9 > + > +#define I2C_NACK GP_IRQ1 > +#define I
[PATCH v2] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
This erratum is observed on the ThunderX2 GICv3 ITS. When a
MOVI command is used to change affinity of a LPI to a collection/cpu
on another node, the LPI is not delivered to the cpu.
An additional INV command is required after the MOVI to deliver
the LPI to the new destination.
If we add INV after MOVI, there is a chance that we lose LPIs which
are raised when the affinity is changed. So for now, adding workaround fix
to disable inter node affinity change.
Signed-off-by: Ganapatrao Kulkarni
---
v2: Added workaround to avoid inter node affinity change.
v1: Initial patch
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++
drivers/irqchip/irq-gic-v3-its.c | 21 -
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index fc1c884..fb27cb5 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,6 +63,7 @@ stable kernels.
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456
|
| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115
|
| Cavium | ThunderX SMMUv2 | #27704 | N/A
|
+| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174
|
| Cavium | ThunderX2 SMMUv3| #74 | N/A
|
| Cavium | ThunderX2 SMMUv3| #126| N/A
|
|| | |
|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c9a7e9e..0dbf3bd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -461,6 +461,16 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config CAVIUM_ERRATUM_174
+ bool "Cavium ThunderX2 erratum 174"
+ default y
+ help
+ Cavium ThunderX2 dual socket systems may loose interrupts
+ on affinity change to a cpu on other node.
+ This workaround fix avoids inter node affinity change.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025f..b0cb528 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -46,6 +46,7 @@
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
#define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
#define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
+#define ITS_FLAGS_WORKAROUND_CAVIUM_174(1ULL << 3)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
@@ -1102,7 +1103,8 @@ static int its_set_affinity(struct irq_data *d, const
struct cpumask *mask_val,
return -EINVAL;
/* lpi cannot be routed to a redistributor that is on a foreign node */
- if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
+ if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144 ||
+ its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
if (its_dev->its->numa_node >= 0) {
cpu_mask = cpumask_of_node(its_dev->its->numa_node);
if (!cpumask_intersects(mask_val, cpu_mask))
@@ -2904,6 +2906,15 @@ static int its_force_quiescent(void __iomem *base)
}
}
+static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
+{
+ struct its_node *its = data;
+
+ its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
+
+ return true;
+}
+
static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
{
struct its_node *its = data;
@@ -3031,6 +3042,14 @@ static const struct gic_quirk its_quirks[] = {
.init = its_enable_quirk_hip07_161600802,
},
#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_174
+ {
+ .desc = "ITS: Cavium ThunderX2 erratum 174",
+ .iidr = 0x13f,/* ThunderX2 pass A1/A2/B0 */
+ .mask = 0x,
+ .init = its_enable_quirk_cavium_174,
+ },
+#endif
{
}
};
--
2.9.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
