[PATCH v27 10/12] selftests/landlock: Add user space tests

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

Test all Landlock system calls, ptrace hooks semantic and filesystem
access-control.

Test coverage for security/landlock/ is 94.1% of lines.  The code not
covered only deals with internal kernel errors (e.g. memory allocation)
and race conditions.

Cc: James Morris 
Cc: Jann Horn 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Cc: Shuah Khan 
Signed-off-by: Mickaël Salaün 
Reviewed-by: Vincent Dagonneau 
---

Changes since v26:
* Add layout1_bind tests to check inherited bind mount accesses.
* Add layout2_overlay tests to check non-inherited overlayfs accesses.
* Fix final cleanup which was reordered because of kselftest_harness
  changes.
* Update layout1.inherit_subset test according to the
  check_access_path_layer() change.
* Implement TEST_F_FORK() to be able to use FIXTURE_TEARDOWN() to clean
  up layouts even if the test (child) lost access rights or failed.
  Remove now useless layout*.cleanup .
* Update syscall names.
* Clean up FIXTURE_SETUP(layout1).
* Clean up file layou management:
  - Replace specific create_dir_and_file() with generic
create_directory() and create_file().
  - Replace specific delete_dir_and_file() with generic remove_path().
  - Rename and move cleanup_*() to remove_*() to improve readability.
  - Use EXPECT_*() for all FIXTURE_TEARDOWN() code.

Changes since v25:
* Add a new test to check that Landlock ruleset file descriptors
  received through UNIX sockets are usable.  Contributed by Vincent
  Dagonneau.
* Improve hierarchy.trace tests to not hang when testing on a kernel
  that don't support Landlock.
* Replace EXPECT_EQ(0, close(*)) with ASSERT_EQ(0, close(*)).
* Guard WEXITSTATUS() use with WIFEXITED() in ptrace tests.
* Use pipe2(2) with O_CLOEXEC.
* Remove useless errno set for syscall wrappers, and related useless checks.
* Rename test.
* Add Microsoft copyright for layout1.interleaved_masked_accesses .

Changes since v24:
* Revert the ruleset_overlap test from v24: check that access righs are
  ORed together when building a ruleset.  Keep the extra checks
  added with v24.
* Revert inherit_subset test from v24: use the automatic ORing of
  access rights for the same file.
* Update interleaved_masked_accesses test (added with v24) to stop when
  all layers allowed at least one time an inode in the path walk.
* Extend interleaved_masked_accesses test with new tricky interleaved
  layers which would not work as intended with (allow or deny) bitmask
  layer implementations.
* Simplify and rename test_path*() to test_open*() to make easier the
  diagnostic in case of unattended errors.
* Replace most call to open(2) with a call to test_open(), which
  reduces the number of lines and make tests more readable.
* Fix erroneous check in inherit_superset.

Changes since v23:
* Add an interleaved_masked_accesses test to check corner cases for
  interleaved layered ruleset combinations.
* Update ruleset_overlap and inherit_subset tests to follow the new
  intersect access rights behavior.
* Extend the inherit_superset test to check that layers are handled as
  expected in the superset use case, which complete the inherit_subset
  checks.
* Fix comment (spotted by Vincent Dagonneau).

Changes since v22:
* Extend and add a new test to better check rules applied to the root
  directory: rule_over_root_allow_then_deny, rule_over_root_deny.
* Change the signature of test_path*() to make the calls clearer.

Changes since v21:
* Remove layout1.chroot test and update layout1.unhandled_access to not
  rely on LANDLOCK_ACCESS_FS_CHROOT.
* Clean up comments.

Changes since v20:
* Update with new syscalls and type names.
* Use the full syscall interfaces: explicitely set the "flags" field to
  zero.
* Update the empty_path_beneath_attr test to check for EFAULT.
* Update and merge tests for the simplified copy_min_struct_from_user().
* Clean up makefile.
* Rename some types and variables in a more consistent way.

Changes since v19:
* Update with the new Landlock syscalls.
* Fix device creation.
* Check the new landlock_attr_features members: last_rule_type and
  last_target_type .
* Constify variables.

Changes since v18:
* Replace ruleset_rw.inval with layout1.inval to avoid inexistent test
  layout.
* Use the new FIXTURE_VARIANT for ptrace_test: makes the tests more
  readable and usable.
* Add ARRAY_SIZE() macro to please checkpatch.

Changes since v17:
* Add new test for mknod with a zero mode.
* Use memset(3) to initialize attr_features in base_test.

Changes since v16:
* Add new unpriv_enforce_without_no_new_privs test: check that ruleset
  enforcing is forbiden without no_new_privs and CAP_SYS_ADMIN.
* Drop capabilities when useful.
* Check the new size_attr_features field from struct
  landlock_attr_features.
* Update the empty_or_same_ruleset test to check complementary empty
  ruleset.
* Update base_test according to the new attribute structures and fix the
  inconsistent_attr test accordingly.
* Switch syscall attribute pointer and size arguments.
* Rename test

Re: [PATCH] scripts: LOL what a patch! change Linus to Linux

2021-01-21 Thread Randy Dunlap
On 1/21/21 6:30 AM, Bhaskar Chowdhury wrote:
> s/Linus/Linux/
> 
> ...how dare I?? :)
> 
> Signed-off-by: Bhaskar Chowdhury 

Hi,

You missed a second occurrence of that a few lines later.

However, it is correct as is. It means the kernel tree
that Linus maintains -- sometimes known as mainline.

> ---
>  scripts/patch-kernel | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/patch-kernel b/scripts/patch-kernel
> index 033d5916797d..314e80c252c0 100755
> --- a/scripts/patch-kernel
> +++ b/scripts/patch-kernel
> @@ -7,7 +7,7 @@
>  # e.g.
>  #   scripts/patch-kernel . ..
>  #  Update the kernel tree in the current directory using patches in the
> -#  directory above to the latest Linus kernel
> +#  directory above to the latest Linux kernel
>  #   scripts/patch-kernel . .. -ac
>  #  Get the latest Linux kernel and patch it with the latest ac patch
>  #   scripts/patch-kernel . .. 2.4.9
> --
> 2.30.0
> 


-- 
~Randy
"He closes his eyes and drops the goggles.  You can't get hurt
by looking at a bitmap.  Or can you?"
(Neal Stephenson: Snow Crash)


Re: [PATCH] diffconfig: use python3 instead of python in Shebang line

2021-01-21 Thread Scott Branden
Hi Andy,

On 2021-01-21 12:35 p.m., Andy Shevchenko wrote:
> On Thu, Jan 21, 2021 at 10:31 PM Andy Shevchenko
>  wrote:
>> On Thu, Jan 21, 2021 at 10:28 PM Masahiro Yamada  
>> wrote:
>>> On Fri, Jan 22, 2021 at 2:17 AM Scott Branden
>>>  wrote:
 Use python3 instead of python in diffconfig Shebang line.
 python2 was sunset January 1, 2000 and environments do not need
 to support python any more.
>>> Just from curiosity, what problem is this solving?
>>>
>>> Is there a distribution where 'python' does not exist,
>>> but 'python3' does ?
>> Yes. Called surprise surprise Debian
>> An it's a rare case when I agree with them.
> For the record, you seems haven't noticed:
> https://lkml.org/lkml/2020/12/9/446
It doesn't look like your change made it into 5.11-rc but I think it should be 
added?



Re: [PATCH v3 03/21] dt-bindings: pinctrl: Add Allwinner H616 compatible strings

2021-01-21 Thread Linus Walleij
On Mon, Jan 18, 2021 at 3:09 AM Andre Przywara  wrote:

> A new SoC, a new compatible string.
> Also we were too miserly with just allowing seven interrupt banks.
>
> Signed-off-by: Andre Przywara 

Patch applied to the pinctrl tree.

Yours,
Linus Walleij


Re: [PATCH 1/6] tty: implement write_iter

2021-01-21 Thread Linus Torvalds
On Thu, Jan 21, 2021 at 11:43 AM Greg Kroah-Hartman
 wrote:
>
> This works, thanks for these.  I'll wait for Jiri to review them before
> applying them to my branches...

Let's hope Jiri sees them, since he had some email issue earlier..

I'll add his suse address here too.

   Linus


Re: [PATCH v2 6/7] platform: x86: Add intel_skl_int3472 driver

2021-01-21 Thread Daniel Scally
Hi both

On 20/01/2021 11:44, Andy Shevchenko wrote:
> On Wed, Jan 20, 2021 at 06:18:53AM +0200, Laurent Pinchart wrote:
>> On Tue, Jan 19, 2021 at 07:43:15PM +0200, Andy Shevchenko wrote:
>>> On Tue, Jan 19, 2021 at 06:36:31PM +0200, Laurent Pinchart wrote:
 On Tue, Jan 19, 2021 at 11:33:58AM +0200, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
>> On 18/01/2021 21:19, Daniel Scally wrote:
> ...
>
> See my previous reply. TL;DR: you have to modify clk-gpio.c to export 
> couple of
> methods to be able to use it as a library.
 That seems really overkill given the very simple implementation of the
 clock provided here.
>>> Less code in the end is called an overkill? Hmm...
>>> I think since we in Linux it's better to utilize what it provides. Do you 
>>> want
>>> me to prepare a patch to show that there is no overkill at all?
>> The amount of code we would save it very small. It's not necessarily a
>> bad idea, but I think such an improvement could be made on top, it
>> shouldn't block this series.
> Okay, let's wait what Dan will say on this.
> I can probably help to achieve this improvement sooner than later.


Well; turns out that we missed an operation we really need to add
(clk_recalc_rate) which in our case needs to read a fixed value stored
in a buffer in ACPI; most of the code is shared with an existing
function in the driver so it's not much extra to add, but I think it
kinda precludes using clk-gpio for this anyway

>> (also, Laurent, if we did it this way we wouldn't be able to also handle
>> the led-indicator GPIO here without some fairly major rework)
> LED indicators are done as LED class devices (see plenty of examples in 
> PDx86
> drivers: drivers/platform/x86/)
 How do you expose the link between the sensor and its indicator LED to
 userspace ? Isn't it better to handle it in the kernel to avoid rogue
 userspace turning the camera on without notifying the user ?
>>> I didn't get this. It's completely a LED handling driver business. We may
>>> expose it to user space or not, but it's orthogonal to the usage of LED 
>>> class
>>> IIUC. Am I mistaken here?
>> If it stays internal to the kernel and is solely controlled from the
>> int3472 driver, there's no need to involve the LED class. If we want to
>> expose the privacy LED to userspace then the LED framework is the way to
>> go, but we will also need to find a way to expose the link between the
>> camera sensor and the LED to userspace. If there are two privacy LEDs,
>> one for the front sensor and one for the back sensor, userspace will
>> need to know which is which.
> I see. For now we probably can keep GPIO LED implementation internally.
>


Re: [PATCH v4] x86/mce: Avoid infinite loop for copy from user recovery

2021-01-21 Thread Luck, Tony
On Wed, Jan 20, 2021 at 01:18:12PM +0100, Borislav Petkov wrote:
> On Tue, Jan 19, 2021 at 03:57:59PM -0800, Luck, Tony wrote:
> > But the real validation folks took my patch and found that it has
> > destabilized cases 1 & 2 (and case 3 also chokes if you repeat a few
> > more times). System either hangs or panics. Generally before 100
> > injection/conumption cycles.
> 
> Hmm, that mce_count increment and check stuff might turn out to be
> fragile in the face of a race condition. But I don't see it...

I can't see what the race is either.  As far as I can see the flow
looks like this (for a machine check in user mode)

user-mode

do_machine_check() [in atomic context on IST etc.]

queue_task_work()
increments current->mce_count
first (only) call saves address etc. and calls 
task_work_add()
return from machine check

Plausibly we might context switch to another process here. We could even
resume on a different CPU.

do_task_work() [in process context]

kill_me_maybe()
sets mce_count back to zero, ready for another 
#MC
memory_failure()
send SIGBUS

The kernel get_user() case is similar, but may take extra machine checks before
before calling code decides get_user() really is going to keep saying -EFAULT.


But, on a whim, I changed the type of mce_count from "int" to "atomic_t" and
fixeed up the increment & clear to use atomic_inc_return() and atomic_set().
See updated patch below.

I can't see why this should have made any difference. But the "int" version
crashes in a few dozen machine checks. The "atomic_t" version has run many
thousands of machine checks (10213 in the current boot according to 
/proc/interrupts)
with no issues.

-Tony

>From d1b003f1de92f87c8dc53dd710fd79ad6e277364 Mon Sep 17 00:00:00 2001
From: Tony Luck 
Date: Wed, 20 Jan 2021 12:40:50 -0800
Subject: [PATCH] x86/mce: Avoid infinite loop for copy from user recovery

Recovery action when get_user() triggers a machine check uses the fixup
path to make get_user() return -EFAULT.  Also queue_task_work() sets up
so that kill_me_maybe() will be called on return to user mode to send a
SIGBUS to the current process.

But there are places in the kernel where the code assumes that this
EFAULT return was simply because of a page fault. The code takes some
action to fix that, and then retries the access. This results in a second
machine check.

While processing this second machine check queue_task_work() is called
again. But since this uses the same callback_head structure that
was used in the first call, the net result is an entry on the
current->task_works list that points to itself. When task_work_run()
is called it loops forever in this code:

do {
next = work->next;
work->func(work);
work = next;
cond_resched();
} while (work);

Add a counter (current->mce_count) to keep track of repeated machine checks
before task_work() is called. First machine check saves the address information
and calls task_work_add(). Subsequent machine checks before that task_work
call back is executed check that the address is in the same page as the first
machine check (since the callback will offline exactly one page).

Expected worst case is two machine checks before moving on (e.g. one user
access with page faults disabled, then a repeat to the same addrsss with
page faults enabled). Just in case there is some code that loops forever
enforce a limit of 10.

Signed-off-by: Tony Luck 
---
 arch/x86/kernel/cpu/mce/core.c | 35 +++---
 include/linux/sched.h  |  1 +
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 13d3f1cbda17..4a8660058b67 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1238,6 +1238,9 @@ static void __mc_scan_banks(struct mce *m, struct pt_regs 
*regs, struct mce *fin
 
 static void kill_me_now(struct callback_head *ch)
 {
+   struct task_struct *p = container_of(ch, struct task_struct, 
mce_kill_me);
+
+   atomic_set(&p->mce_count, 0);
force_sig(SIGBUS);
 }
 
@@ -1246,6 +1249,7 @@ static void kill_me_maybe(struct callback_head *cb)
struct task_struct *p = container_of(cb, struct task_struct, 
mce_kill_me);
int flags = MF_ACTION_REQUIRED;
 
+   atomic_set(&p->mce_count, 0);
pr_err("Uncorrected hardware memory error in user-access at %llx", 
p->mce_addr);
 
if (!p->mce_ripv)
@@ -1266,12 +1270,29 @@ static void kill_me_maybe(struct callback_head *cb)
}
 }
 
-static void queue_task_work(struct mce *m, int kill_current_task)
+static void queue_task_work

[PATCH v1 2/2] isa: Make the remove callback for isa drivers return void

2021-01-21 Thread Uwe Kleine-König
The driver core ignores the return value of the remove callback, so
don't give isa drivers the chance to provide a value.

Adapt all isa_drivers with a remove callbacks accordingly; they all
return 0 unconditionally anyhow.

Signed-off-by: Uwe Kleine-König 
---
 drivers/base/isa.c   | 2 +-
 drivers/i2c/busses/i2c-elektor.c | 4 +---
 drivers/i2c/busses/i2c-pca-isa.c | 4 +---
 drivers/input/touchscreen/htcpen.c   | 4 +---
 drivers/media/radio/radio-sf16fmr2.c | 4 +---
 drivers/net/can/sja1000/tscan1.c | 4 +---
 drivers/net/ethernet/3com/3c509.c| 3 +--
 drivers/scsi/advansys.c  | 3 +--
 drivers/scsi/aha1542.c   | 3 +--
 drivers/scsi/fdomain_isa.c   | 3 +--
 drivers/scsi/g_NCR5380.c | 3 +--
 drivers/watchdog/pcwd.c  | 4 +---
 include/linux/isa.h  | 2 +-
 sound/isa/ad1848/ad1848.c| 3 +--
 sound/isa/adlib.c| 3 +--
 sound/isa/cmi8328.c  | 3 +--
 sound/isa/cmi8330.c  | 3 +--
 sound/isa/cs423x/cs4231.c| 3 +--
 sound/isa/cs423x/cs4236.c| 3 +--
 sound/isa/es1688/es1688.c| 3 +--
 sound/isa/es18xx.c   | 3 +--
 sound/isa/galaxy/galaxy.c| 3 +--
 sound/isa/gus/gusclassic.c   | 3 +--
 sound/isa/gus/gusextreme.c   | 3 +--
 sound/isa/gus/gusmax.c   | 3 +--
 sound/isa/gus/interwave.c| 3 +--
 sound/isa/msnd/msnd_pinnacle.c   | 3 +--
 sound/isa/opl3sa2.c  | 3 +--
 sound/isa/opti9xx/miro.c | 3 +--
 sound/isa/opti9xx/opti92x-ad1848.c   | 3 +--
 sound/isa/sb/jazz16.c| 3 +--
 sound/isa/sb/sb16.c  | 3 +--
 sound/isa/sb/sb8.c   | 3 +--
 sound/isa/sc6000.c   | 3 +--
 sound/isa/sscape.c   | 3 +--
 sound/isa/wavefront/wavefront.c  | 3 +--
 36 files changed, 36 insertions(+), 76 deletions(-)

diff --git a/drivers/base/isa.c b/drivers/base/isa.c
index 2772f5d1948a..aa4737667026 100644
--- a/drivers/base/isa.c
+++ b/drivers/base/isa.c
@@ -51,7 +51,7 @@ static int isa_bus_remove(struct device *dev)
struct isa_driver *isa_driver = dev->platform_data;
 
if (isa_driver && isa_driver->remove)
-   return isa_driver->remove(dev, to_isa_dev(dev)->id);
+   isa_driver->remove(dev, to_isa_dev(dev)->id);
 
return 0;
 }
diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
index 140426db28df..b72a3c3ef2ab 100644
--- a/drivers/i2c/busses/i2c-elektor.c
+++ b/drivers/i2c/busses/i2c-elektor.c
@@ -282,7 +282,7 @@ static int elektor_probe(struct device *dev, unsigned int 
id)
return -ENODEV;
 }
 
-static int elektor_remove(struct device *dev, unsigned int id)
+static void elektor_remove(struct device *dev, unsigned int id)
 {
i2c_del_adapter(&pcf_isa_ops);
 
@@ -298,8 +298,6 @@ static int elektor_remove(struct device *dev, unsigned int 
id)
iounmap(base_iomem);
release_mem_region(base, 2);
}
-
-   return 0;
 }
 
 static struct isa_driver i2c_elektor_driver = {
diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
index f27bc1e55385..85e8cf58e8bf 100644
--- a/drivers/i2c/busses/i2c-pca-isa.c
+++ b/drivers/i2c/busses/i2c-pca-isa.c
@@ -161,7 +161,7 @@ static int pca_isa_probe(struct device *dev, unsigned int 
id)
return -ENODEV;
 }
 
-static int pca_isa_remove(struct device *dev, unsigned int id)
+static void pca_isa_remove(struct device *dev, unsigned int id)
 {
i2c_del_adapter(&pca_isa_ops);
 
@@ -170,8 +170,6 @@ static int pca_isa_remove(struct device *dev, unsigned int 
id)
free_irq(irq, &pca_isa_ops);
}
release_region(base, IO_SIZE);
-
-   return 0;
 }
 
 static struct isa_driver pca_isa_driver = {
diff --git a/drivers/input/touchscreen/htcpen.c 
b/drivers/input/touchscreen/htcpen.c
index 2f261a34f9c2..056ba76087e8 100644
--- a/drivers/input/touchscreen/htcpen.c
+++ b/drivers/input/touchscreen/htcpen.c
@@ -171,7 +171,7 @@ static int htcpen_isa_probe(struct device *dev, unsigned 
int id)
return err;
 }
 
-static int htcpen_isa_remove(struct device *dev, unsigned int id)
+static void htcpen_isa_remove(struct device *dev, unsigned int id)
 {
struct input_dev *htcpen_dev = dev_get_drvdata(dev);
 
@@ -182,8 +182,6 @@ static int htcpen_isa_remove(struct device *dev, unsigned 
int id)
release_region(HTCPEN_PORT_INDEX, 2);
release_region(HTCPEN_PORT_INIT, 1);
release_region(HTCPEN_PORT_IRQ_CLEAR, 1);
-
-   return 0;
 }
 
 #ifdef CONFIG_PM
diff --git a/drivers/media/radio/radio-sf16fmr2.c 
b/drivers/media/radio/radio-sf16fmr2.c
index 0388894cfe41..d0dde55b7930 100644
--- a/drivers/media/radio/radio-sf16fmr2.c
+++ b/drivers/media/radio/radio-sf16fmr2.c
@@ -293,11 +293,9 @@ static void fmr2_remove(struct fmr2 *fmr2)
kfree(fmr

[PATCH v1 0/2] isa: Make the remove callback for isa drivers return void

2021-01-21 Thread Uwe Kleine-König
Hello,

as described in the commit log of the 2nd patch returning an error code
from a bus' remove callback doesn't make any difference as the driver
core ignores it and still considers the device removed.

So change the remove callback to return void to not give driver authors
an incentive to believe they could return an error.

There is only a single isa driver in the tree (assuming I didn't miss
any) that has a remove callback that can return a non zero return code.
This is "fixed" in the first patch, to make the second patch more
obviously correct.

Best regards
Uwe

Uwe Kleine-König (2):
  watchdog: pcwd: drop always-false if from remove callback
  isa: Make the remove callback for isa drivers return void

 drivers/base/isa.c   | 2 +-
 drivers/i2c/busses/i2c-elektor.c | 4 +---
 drivers/i2c/busses/i2c-pca-isa.c | 4 +---
 drivers/input/touchscreen/htcpen.c   | 4 +---
 drivers/media/radio/radio-sf16fmr2.c | 4 +---
 drivers/net/can/sja1000/tscan1.c | 4 +---
 drivers/net/ethernet/3com/3c509.c| 3 +--
 drivers/scsi/advansys.c  | 3 +--
 drivers/scsi/aha1542.c   | 3 +--
 drivers/scsi/fdomain_isa.c   | 3 +--
 drivers/scsi/g_NCR5380.c | 3 +--
 drivers/watchdog/pcwd.c  | 7 +--
 include/linux/isa.h  | 2 +-
 sound/isa/ad1848/ad1848.c| 3 +--
 sound/isa/adlib.c| 3 +--
 sound/isa/cmi8328.c  | 3 +--
 sound/isa/cmi8330.c  | 3 +--
 sound/isa/cs423x/cs4231.c| 3 +--
 sound/isa/cs423x/cs4236.c| 3 +--
 sound/isa/es1688/es1688.c| 3 +--
 sound/isa/es18xx.c   | 3 +--
 sound/isa/galaxy/galaxy.c| 3 +--
 sound/isa/gus/gusclassic.c   | 3 +--
 sound/isa/gus/gusextreme.c   | 3 +--
 sound/isa/gus/gusmax.c   | 3 +--
 sound/isa/gus/interwave.c| 3 +--
 sound/isa/msnd/msnd_pinnacle.c   | 3 +--
 sound/isa/opl3sa2.c  | 3 +--
 sound/isa/opti9xx/miro.c | 3 +--
 sound/isa/opti9xx/opti92x-ad1848.c   | 3 +--
 sound/isa/sb/jazz16.c| 3 +--
 sound/isa/sb/sb16.c  | 3 +--
 sound/isa/sb/sb8.c   | 3 +--
 sound/isa/sc6000.c   | 3 +--
 sound/isa/sscape.c   | 3 +--
 sound/isa/wavefront/wavefront.c  | 3 +--
 36 files changed, 36 insertions(+), 79 deletions(-)


base-commit: 5a158981aafa7f29709034b17bd007b15cb29983
-- 
2.29.2


[PATCH v1 1/2] watchdog: pcwd: drop always-false if from remove callback

2021-01-21 Thread Uwe Kleine-König
If pcwd_isa_probe() succeeded pcwd_private.io_addr cannot be NULL. (And
if pcwd_isa_probe() failed, pcwd_isa_remove() isn't called.)

Signed-off-by: Uwe Kleine-König 
---
 drivers/watchdog/pcwd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/watchdog/pcwd.c b/drivers/watchdog/pcwd.c
index e86fa7f8351d..b95cd38f3ceb 100644
--- a/drivers/watchdog/pcwd.c
+++ b/drivers/watchdog/pcwd.c
@@ -956,9 +956,6 @@ static int pcwd_isa_remove(struct device *dev, unsigned int 
id)
if (debug >= DEBUG)
pr_debug("pcwd_isa_remove id=%d\n", id);
 
-   if (!pcwd_private.io_addr)
-   return 1;
-
/*  Disable the board  */
if (!nowayout)
pcwd_stop();
-- 
2.29.2



linux-next: Fixes tag needs some work in the jc_docs tree

2021-01-21 Thread Stephen Rothwell
Hi all,

In commit

  cf9cadf16b19 ("docs/admin-guide: cgroup-v2: typos and spaces")

Fixes tag

  Fixes: 5f9a4f4a70960

has these problem(s):

  - missing subject

Maybe you meant

Fixes: 5f9a4f4a7096 ("mm: memcontrol: add the missing numa_stat interface for 
cgroup v2")

-- 
Cheers,
Stephen Rothwell


pgptNU2oaIpLQ.pgp
Description: OpenPGP digital signature


Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi_devices

2021-01-21 Thread Daniel Scally


On 21/01/2021 18:08, Rafael J. Wysocki wrote:
> On Thu, Jan 21, 2021 at 5:34 PM Daniel Scally  wrote:
>>
>> On 21/01/2021 14:39, Rafael J. Wysocki wrote:
>>> On Thu, Jan 21, 2021 at 1:04 PM Daniel Scally  wrote:
 On 21/01/2021 11:58, Rafael J. Wysocki wrote:
> On Thu, Jan 21, 2021 at 10:47 AM Daniel Scally  
> wrote:
>> Hi Rafael
>>
>> On 19/01/2021 13:15, Rafael J. Wysocki wrote:
>>> On Mon, Jan 18, 2021 at 9:51 PM Daniel Scally  
>>> wrote:
 On 18/01/2021 16:14, Rafael J. Wysocki wrote:
> On Mon, Jan 18, 2021 at 1:37 AM Daniel Scally  
> wrote:
>> In some ACPI tables we encounter, devices use the _DEP method to 
>> assert
>> a dependence on other ACPI devices as opposed to the OpRegions that 
>> the
>> specification intends. We need to be able to find those devices 
>> "from"
>> the dependee, so add a function to parse all ACPI Devices and check 
>> if
>> the include the handle of the dependee device in their _DEP buffer.
> What exactly do you need this for?
 So, in our DSDT we have devices with _HID INT3472, plus sensors which
 refer to those INT3472's in their _DEP method. The driver binds to the
 INT3472 device, we need to find the sensors dependent on them.

>>> Well, this is an interesting concept. :-)
>>>
>>> Why does _DEP need to be used for that?  Isn't there any other way to
>>> look up the dependent sensors?
>>>
> Would it be practical to look up the suppliers in acpi_dep_list 
> instead?
>
> Note that supplier drivers may remove entries from there, but does
> that matter for your use case?
 Ah - that may work, yes. Thank you, let me test that.
>>> Even if that doesn't work right away, but it can be made work, I would
>>> very much prefer that to the driver parsing _DEP for every device in
>>> the namespace by itself.
>> This does work; do you prefer it in scan.c, or in utils.c (in which case
>> with acpi_dep_list declared as external var in internal.h)?
> Let's put it in scan.c for now, because there is the lock protecting
> the list in there too.
>
> How do you want to implement this?  Something like "walk the list and
> run a callback for the matching entries" or do you have something else
> in mind?
 Something like this (though with a mutex_lock()). It could be simplified
 by dropping the prev stuff, but we have seen INT3472 devices with
 multiple sensors declaring themselves dependent on the same device


 struct acpi_device *
 acpi_dev_get_next_dependent_dev(struct acpi_device *supplier,
 struct acpi_device *prev)
 {
 struct acpi_dep_data *dep;
 struct acpi_device *adev;
 int ret;

 if (!supplier)
 return ERR_PTR(-EINVAL);

 if (prev) {
 /*
  * We need to find the previous device in the list, so we know
  * where to start iterating from.
  */
 list_for_each_entry(dep, &acpi_dep_list, node)
 if (dep->consumer == prev->handle &&
 dep->supplier == supplier->handle)
 break;

 dep = list_next_entry(dep, node);
 } else {
 dep = list_first_entry(&acpi_dep_list, struct acpi_dep_data,
node);
 }


 list_for_each_entry_from(dep, &acpi_dep_list, node) {
 if (dep->supplier == supplier->handle) {
 ret = acpi_bus_get_device(dep->consumer, &adev);
 if (ret)
 return ERR_PTR(ret);

 return adev;
 }
 }

 return NULL;
 }
>>> That would work I think, but would it be practical to modify
>>> acpi_walk_dep_device_list() so that it runs a callback for every
>>> consumer found instead of or in addition to the "delete from the list
>>> and free the entry" operation?
>>
>> I think that this would work fine, if that's the way you want to go.
>> We'd just need to move everything inside the if (dep->supplier ==
>> handle) block to a new callback, and for my purposes I think also add a
>> way to stop parsing the list from the callback (so like have the
>> callbacks return int and stop parsing on a non-zero return). Do you want
>> to expose that ability to pass a callback outside of ACPI?
> Yes.
>
>> Or just export helpers to call each of the callbacks (one to fetch the next
>> dependent device, one to decrement the unmet dependencies counter)
> If you can run a callback for every matching entry, you don't really
> need to have a callback to return the next matching entry.  You can do
> stuff for all of them in one go

Well it my case it's more to return a pointer to the dep->consumer's
acpi_device for a matching ent

Re: [PATCH V2] opp: Prepare for ->set_opp() helper to work without regulators

2021-01-21 Thread Dmitry Osipenko
21.01.2021 14:30, Viresh Kumar пишет:
> @@ -1952,9 +1930,16 @@ void dev_pm_opp_put_regulators(struct opp_table 
> *opp_table)
>   for (i = opp_table->regulator_count - 1; i >= 0; i--)
>   regulator_put(opp_table->regulators[i]);
>  
> - _free_set_opp_data(opp_table);
> + mutex_lock(&opp_table->lock);
> + if (opp_table->set_opp_data) {
> + opp_table->set_opp_data->old_opp.supplies = NULL;
> + opp_table->set_opp_data->new_opp.supplies = NULL;
> + }
> + mutex_unlock(&opp_table->lock);
>  
> + kfree(opp_table->sod_supplies);
>   kfree(opp_table->regulators);
> + opp_table->sod_supplies = NULL;
>   opp_table->regulators = NULL;
>   opp_table->regulator_count = -1;

The sod_supplies should be unset under the lock.


[PATCH v27 01/12] landlock: Add object management

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

A Landlock object enables to identify a kernel object (e.g. an inode).
A Landlock rule is a set of access rights allowed on an object.  Rules
are grouped in rulesets that may be tied to a set of processes (i.e.
subjects) to enforce a scoped access-control (i.e. a domain).

Because Landlock's goal is to empower any process (especially
unprivileged ones) to sandbox themselves, we cannot rely on a
system-wide object identification such as file extended attributes.
Indeed, we need innocuous, composable and modular access-controls.

The main challenge with these constraints is to identify kernel objects
while this identification is useful (i.e. when a security policy makes
use of this object).  But this identification data should be freed once
no policy is using it.  This ephemeral tagging should not and may not be
written in the filesystem.  We then need to manage the lifetime of a
rule according to the lifetime of its objects.  To avoid a global lock,
this implementation make use of RCU and counters to safely reference
objects.

A following commit uses this generic object management for inodes.

Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Signed-off-by: Mickaël Salaün 
Reviewed-by: Jann Horn 
---

Changes since v26:
* Update Kconfig for landlock_enforce_ruleset_self(2).
* Fix spelling.

Changes since v24:
* Fix typo in comment (spotted by Jann Horn).
* Add Reviewed-by: Jann Horn 

Changes since v23:
* Update landlock_create_object() to return error codes instead of NULL.
  This help error handling in callers.
* When using make oldconfig with a previous configuration already
  including the CONFIG_LSM variable, no question is asked to update its
  content.  Update the Kconfig help to warn about LSM stacking
  configuration.
* Constify variable (spotted by Vincent Dagonneau).

Changes since v22:
* Fix spelling (spotted by Jann Horn).

Changes since v21:
* Update Kconfig help.
* Clean up comments.

Changes since v18:
* Account objects to kmemcg.

Changes since v14:
* Simplify the object, rule and ruleset management at the expense of a
  less aggressive memory freeing (contributed by Jann Horn, with
  additional modifications):
  - Remove object->list aggregating the rules tied to an object.
  - Remove landlock_get_object(), landlock_drop_object(),
{get,put}_object_cleaner() and landlock_rule_is_disabled().
  - Rewrite landlock_put_object() to use a more simple mechanism
(no tricky RCU).
  - Replace enum landlock_object_type and landlock_release_object() with
landlock_object_underops->release()
  - Adjust unions and Sparse annotations.
  Cf. 
https://lore.kernel.org/lkml/cag48ez21ben0wl1bbmtiiu8j9jp5iewthowz4turuj+ki0y...@mail.gmail.com/
* Merge struct landlock_rule into landlock_ruleset_elem to simplify the
  rule management.
* Constify variables.
* Improve kernel documentation.
* Cosmetic variable renames.
* Remove the "default" in the Kconfig (suggested by Jann Horn).
* Only use refcount_inc() through getter helpers.
* Update Kconfig description.

Changes since v13:
* New dedicated implementation, removing the need for eBPF.

Previous changes:
https://lore.kernel.org/lkml/20190721213116.23476-6-...@digikod.net/
---
 MAINTAINERS| 10 +
 security/Kconfig   |  1 +
 security/Makefile  |  2 +
 security/landlock/Kconfig  | 21 +
 security/landlock/Makefile |  3 ++
 security/landlock/object.c | 67 
 security/landlock/object.h | 91 ++
 7 files changed, 195 insertions(+)
 create mode 100644 security/landlock/Kconfig
 create mode 100644 security/landlock/Makefile
 create mode 100644 security/landlock/object.c
 create mode 100644 security/landlock/object.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 00836f6452f0..74406a6bc6ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9936,6 +9936,16 @@ F:   net/core/sock_map.c
 F: net/ipv4/tcp_bpf.c
 F: net/ipv4/udp_bpf.c
 
+LANDLOCK SECURITY MODULE
+M: Mickaël Salaün 
+L: linux-security-mod...@vger.kernel.org
+S: Supported
+W: https://landlock.io
+T: git https://github.com/landlock-lsm/linux.git
+F: security/landlock/
+K: landlock
+K: LANDLOCK
+
 LANTIQ / INTEL Ethernet drivers
 M: Hauke Mehrtens 
 L: net...@vger.kernel.org
diff --git a/security/Kconfig b/security/Kconfig
index 7561f6f99f1d..15a4342b5d01 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -238,6 +238,7 @@ source "security/loadpin/Kconfig"
 source "security/yama/Kconfig"
 source "security/safesetid/Kconfig"
 source "security/lockdown/Kconfig"
+source "security/landlock/Kconfig"
 
 source "security/integrity/Kconfig"
 
diff --git a/security/Makefile b/security/Makefile
index 3baf435de541..c688f4907a1b 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -13,6 +13,7 @@ subdir-$(CONFIG_SECURITY_LOADPIN) += loadpin
 subdir-$(CONFIG_SECURITY_SAFESETID)+= safesetid
 subdir-$(CONFIG_SECURITY_LOCKDOWN_LSM)

[PATCH v27 08/12] landlock: Add syscall implementations

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

These 3 system calls are designed to be used by unprivileged processes
to sandbox themselves:
* landlock_create_ruleset(2): Creates a ruleset and returns its file
  descriptor.
* landlock_add_rule(2): Adds a rule (e.g. file hierarchy access) to a
  ruleset, identified by the dedicated file descriptor.
* landlock_enforce_ruleset_self(2): Enforces a ruleset on the current
  thread and its future children (similar to seccomp).  This syscall has
  the same usage restrictions as seccomp(2): the caller must have the
  no_new_privs attribute set or have CAP_SYS_ADMIN in the current user
  namespace.

All these syscalls have a "flags" argument (not currently used) to
enable extensibility.

Here are the motivations for these new syscalls:
* A sandboxed process may not have access to file systems, including
  /dev, /sys or /proc, but it should still be able to add more
  restrictions to itself.
* Neither prctl(2) nor seccomp(2) (which was used in a previous version)
  fit well with the current definition of a Landlock security policy.

All passed structs (attributes) are checked at build time to ensure that
they don't contain holes and that they are aligned the same way for each
architecture.

See the user and kernel documentation for more details (provided by a
following commit):
* Documentation/userspace-api/landlock.rst
* Documentation/security/landlock.rst

Cc: Arnd Bergmann 
Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Signed-off-by: Mickaël Salaün 
Reviewed-by: Jann Horn 
---

Changes since v26:
* Rename landlock_enforce_ruleset_current(2) to
  landlock_enforce_ruleset_self(2).  "current" makes sense for a kernel
  developer, but much less from a user space developer stand point.
  "self" is widely used to refer to the current task (e.g. /proc/self).
  "current" may refer to temporal properties, which could be added later
  to this syscall flags (cf. /proc/self/attr/{current,exec}).
* Simplify build_check_abi().
* Rename syscall.c to syscalls.c .
* Use less ambiguous comments.
* Fix spelling.

Changes since v25:
* Revert build_check_abi() as non-inline to trigger a warning if it is
  not called.
* Use the new limit names.

Changes since v24:
* Add Reviewed-by: Jann Horn 
* Set build_check_abi() as inline.

Changes since v23:
* Rewrite get_ruleset_from_fd() to please the 0-DAY CI Kernel Test
  Service that reported an uninitialized variable (false positive):
  
https://lore.kernel.org/linux-security-module/202011101854.zgbwwusk-...@intel.com/
  Anyway, it is cleaner like this.
* Add a comment about E2BIG which can be returned by
  landlock_enforce_ruleset_current(2) when there is no more room for
  another stacked ruleset (i.e. domain).

Changes since v22:
* Replace security_capable() with ns_capable_noaudit() (suggested by
  Jann Horn) and explicitly return EPERM.
* Fix landlock_enforce_ruleset_current(2)'s out_put_creds (spotted by
  Jann Horn).
* Add __always_inline to copy_min_struct_from_user() to make its
  BUILD_BUG_ON() checks reliable (suggested by Jann Horn).
* Simplify path assignation in get_path_from_fd() (suggested by Jann
  Horn).
* Fix spelling (spotted by Jann Horn).

Changes since v21:
* Fix and improve comments.

Changes since v20:
* Remove two arguments to landlock_enforce_ruleset(2) (requested by Arnd
  Bergmann) and rename it to landlock_enforce_ruleset_current(2): remove
  the enum landlock_target_type and the target file descriptor (not used
  for now).  A ruleset can only be enforced on the current thread.
* Remove the size argument in landlock_add_rule() (requested by Arnd
  Bergmann).
* Remove landlock_get_features(2) (suggested by Arnd Bergmann).
* Simplify and rename copy_struct_if_any_from_user() to
  copy_min_struct_from_user().
* Rename "options" to "flags" to allign with current syscalls.
* Rename some types and variables in a more consistent way.
* Fix missing type declarations in syscalls.h .

Changes since v19:
* Replace the landlock(2) syscall with 4 syscalls (one for each
  command): landlock_get_features(2), landlock_create_ruleset(2),
  landlock_add_rule(2) and landlock_enforce_ruleset(2) (suggested by
  Arnd Bergmann).
  https://lore.kernel.org/lkml/56d15841-e2c1-2d58-59b8-3a6a09b23...@digikod.net/
* Return EOPNOTSUPP (instead of ENOPKG) when Landlock is disabled.
* Add two new fields to landlock_attr_features to fit with the new
  syscalls: last_rule_type and last_target_type.  This enable to easily
  identify which types are supported.
* Pack landlock_attr_path_beneath struct because of the removed
  ruleset_fd.
* Update documentation and fix spelling.

Changes since v18:
* Remove useless include.
* Remove LLATTR_SIZE() which was only used to shorten lines. Cf. commit
  bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning").

Changes since v17:
* Synchronize syscall declaration.
* Fix comment.

Changes since v16:
* Add a size_attr_features field to struct landlock_attr_features for
  self-introspection, and move the access

[PATCH v27 11/12] samples/landlock: Add a sandbox manager example

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

Add a basic sandbox tool to launch a command which can only access a
list of file hierarchies in a read-only or read-write way.

Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Signed-off-by: Mickaël Salaün 
Reviewed-by: Jann Horn 
---

Changes since v25:
* Improve comments and fix help (suggested by Jann Horn).
* Add a safeguard for errno check (suggested by Jann Horn).
* Allows users to not use all possible restrictions (e.g. use LL_FS_RO
  without LL_FS_RW).
* Update syscall names.
* Improve Makefile:
  - Replace hostprogs/always-y with userprogs-always-y, available since
commit faabed295ccc ("kbuild: introduce hostprogs-always-y and
userprogs-always-y").
  - Depends on CC_CAN_LINK.
* Add Reviewed-by Jann Horn.

Changes since v25:
* Remove useless errno set in the syscall wrappers.
* Cosmetic variable renames.

Changes since v23:
* Re-add hints to help users understand the required kernel
  configuration.  This was removed with the removal of
  landlock_get_features(2).

Changes since v21:
* Remove LANDLOCK_ACCESS_FS_CHROOT.
* Clean up help.

Changes since v20:
* Update with new syscalls and type names.
* Update errno check for EOPNOTSUPP.
* Use the full syscall interfaces: explicitely set the "flags" field to
  zero.

Changes since v19:
* Update with the new Landlock syscalls.
* Comply with commit 5f2fb52fac15 ("kbuild: rename hostprogs-y/always to
  hostprogs/always-y").

Changes since v16:
* Switch syscall attribute pointer and size arguments.

Changes since v15:
* Update access right names.
* Properly assign access right to files according to the new related
  syscall restriction.
* Replace "select" with "depends on" HEADERS_INSTALL (suggested by Randy
  Dunlap).

Changes since v14:
* Fix Kconfig dependency.
* Remove access rights that may be required for FD-only requests:
  mmap, truncate, getattr, lock, chmod, chown, chgrp, ioctl.
* Fix useless hardcoded syscall number.
* Use execvpe().
* Follow symlinks.
* Extend help with common file paths.
* Constify variables.
* Clean up comments.
* Improve error message.

Changes since v11:
* Add back the filesystem sandbox manager and update it to work with the
  new Landlock syscall.

Previous changes:
https://lore.kernel.org/lkml/20190721213116.23476-9-...@digikod.net/
---
 samples/Kconfig  |   7 +
 samples/Makefile |   1 +
 samples/landlock/.gitignore  |   1 +
 samples/landlock/Makefile|  13 ++
 samples/landlock/sandboxer.c | 239 +++
 5 files changed, 261 insertions(+)
 create mode 100644 samples/landlock/.gitignore
 create mode 100644 samples/landlock/Makefile
 create mode 100644 samples/landlock/sandboxer.c

diff --git a/samples/Kconfig b/samples/Kconfig
index 0ed6e4d71d87..d25d0e508153 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -124,6 +124,13 @@ config SAMPLE_HIDRAW
bool "hidraw sample"
depends on CC_CAN_LINK && HEADERS_INSTALL
 
+config SAMPLE_LANDLOCK
+   bool "Build Landlock sample code"
+   depends on CC_CAN_LINK && HEADERS_INSTALL
+   help
+ Build a simple Landlock sandbox manager able to launch a process
+ restricted by a user-defined filesystem access control policy.
+
 config SAMPLE_PIDFD
bool "pidfd sample"
depends on CC_CAN_LINK && HEADERS_INSTALL
diff --git a/samples/Makefile b/samples/Makefile
index c3392a595e4b..087e0988ccc5 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SAMPLE_KDB)  += kdb/
 obj-$(CONFIG_SAMPLE_KFIFO) += kfifo/
 obj-$(CONFIG_SAMPLE_KOBJECT)   += kobject/
 obj-$(CONFIG_SAMPLE_KPROBES)   += kprobes/
+subdir-$(CONFIG_SAMPLE_LANDLOCK)   += landlock
 obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch/
 subdir-$(CONFIG_SAMPLE_PIDFD)  += pidfd
 obj-$(CONFIG_SAMPLE_QMI_CLIENT)+= qmi/
diff --git a/samples/landlock/.gitignore b/samples/landlock/.gitignore
new file mode 100644
index ..f43668b2d318
--- /dev/null
+++ b/samples/landlock/.gitignore
@@ -0,0 +1 @@
+/sandboxer
diff --git a/samples/landlock/Makefile b/samples/landlock/Makefile
new file mode 100644
index ..5d601e51c2eb
--- /dev/null
+++ b/samples/landlock/Makefile
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: BSD-3-Clause
+
+userprogs-always-y := sandboxer
+
+userccflags += -I usr/include
+
+.PHONY: all clean
+
+all:
+   $(MAKE) -C ../.. samples/landlock/
+
+clean:
+   $(MAKE) -C ../.. M=samples/landlock/ clean
diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
new file mode 100644
index ..9ee45129869a
--- /dev/null
+++ b/samples/landlock/sandboxer.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Simple Landlock sandbox manager able to launch a process restricted by a
+ * user-defined filesystem access control policy.
+ *
+ * Copyright © 2017-2020 Mickaël Salaün 
+ * Copyright © 2020 ANSSI
+ */
+
+#define _GNU_SOURCE
+#in

[PATCH v27 06/12] fs,security: Add sb_delete hook

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

The sb_delete security hook is called when shutting down a superblock,
which may be useful to release kernel objects tied to the superblock's
lifetime (e.g. inodes).

This new hook is needed by Landlock to release (ephemerally) tagged
struct inodes.  This comes from the unprivileged nature of Landlock
described in the next commit.

Cc: Al Viro 
Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Signed-off-by: Mickaël Salaün 
Reviewed-by: Jann Horn 
---

Changes since v22:
* Add Reviewed-by: Jann Horn 

Changes since v17:
* Initial patch to replace the direct call to landlock_release_inodes()
  (requested by James Morris).
  https://lore.kernel.org/lkml/alpine.lrh.2.21.2005150536440.7...@namei.org/
---
 fs/super.c| 1 +
 include/linux/lsm_hook_defs.h | 1 +
 include/linux/lsm_hooks.h | 2 ++
 include/linux/security.h  | 4 
 security/security.c   | 5 +
 5 files changed, 13 insertions(+)

diff --git a/fs/super.c b/fs/super.c
index 2c6cdea2ab2d..c3c5178cde65 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -454,6 +454,7 @@ void generic_shutdown_super(struct super_block *sb)
evict_inodes(sb);
/* only nonzero refcount inodes can have marks */
fsnotify_sb_delete(sb);
+   security_sb_delete(sb);
 
if (sb->s_dio_done_wq) {
destroy_workqueue(sb->s_dio_done_wq);
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 7aaa753b8608..32472b3849bc 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -59,6 +59,7 @@ LSM_HOOK(int, 0, fs_context_dup, struct fs_context *fc,
 LSM_HOOK(int, -ENOPARAM, fs_context_parse_param, struct fs_context *fc,
 struct fs_parameter *param)
 LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb)
+LSM_HOOK(void, LSM_RET_VOID, sb_delete, struct super_block *sb)
 LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb)
 LSM_HOOK(void, LSM_RET_VOID, sb_free_mnt_opts, void *mnt_opts)
 LSM_HOOK(int, 0, sb_eat_lsm_opts, char *orig, void **mnt_opts)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 970106d98306..e339b201f79b 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -108,6 +108,8 @@
  * allocated.
  * @sb contains the super_block structure to be modified.
  * Return 0 if operation was successful.
+ * @sb_delete:
+ * Release objects tied to a superblock (e.g. inodes).
  * @sb_free_security:
  * Deallocate and clear the sb->s_security field.
  * @sb contains the super_block structure to be modified.
diff --git a/include/linux/security.h b/include/linux/security.h
index c35ea0ffccd9..c41a94e29b62 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -288,6 +288,7 @@ void security_bprm_committed_creds(struct linux_binprm 
*bprm);
 int security_fs_context_dup(struct fs_context *fc, struct fs_context *src_fc);
 int security_fs_context_parse_param(struct fs_context *fc, struct fs_parameter 
*param);
 int security_sb_alloc(struct super_block *sb);
+void security_sb_delete(struct super_block *sb);
 void security_sb_free(struct super_block *sb);
 void security_free_mnt_opts(void **mnt_opts);
 int security_sb_eat_lsm_opts(char *options, void **mnt_opts);
@@ -620,6 +621,9 @@ static inline int security_sb_alloc(struct super_block *sb)
return 0;
 }
 
+static inline void security_sb_delete(struct super_block *sb)
+{ }
+
 static inline void security_sb_free(struct super_block *sb)
 { }
 
diff --git a/security/security.c b/security/security.c
index 9f979d4afe6c..1b4a73b2549a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -900,6 +900,11 @@ int security_sb_alloc(struct super_block *sb)
return rc;
 }
 
+void security_sb_delete(struct super_block *sb)
+{
+   call_void_hook(sb_delete, sb);
+}
+
 void security_sb_free(struct super_block *sb)
 {
call_void_hook(sb_free_security, sb);
-- 
2.30.0



[PATCH v27 09/12] arch: Wire up Landlock syscalls

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

Wire up the following system calls for all architectures:
* landlock_create_ruleset(2)
* landlock_add_rule(2)
* landlock_enforce_ruleset_self(2)

Cc: Arnd Bergmann 
Cc: James Morris 
Cc: Jann Horn 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Signed-off-by: Mickaël Salaün 
---

Changes since v26:
* Rename landlock_enforce_ruleset_current(2) to
  landlock_enforce_ruleset_self(2).

Changes since v25:
* Rebase and leave space for the new epoll_pwait2(2) and memfd_secret(2)
  from -next.

Changes since v21:
* Rebase and leave space for watch_mount(2) from -next.

Changes since v20:
* Remove landlock_get_features(2).
* Decrease syscall numbers to stick to process_madvise(2) in -next.
* Rename landlock_enforce_ruleset(2) to
  landlock_enforce_ruleset_current(2).

Changes since v19:
* Increase syscall numbers by 4 to leave space for new ones (in
  linux-next): watch_mount(2), watch_sb(2), fsinfo(2) and
  process_madvise(2) (requested by Arnd Bergmann).
* Replace the previous multiplexor landlock(2) with 4 syscalls:
  landlock_get_features(2), landlock_create_ruleset(2),
  landlock_add_rule(2) and landlock_enforce_ruleset(2).

Changes since v18:
* Increase the syscall number because of the new faccessat2(2).

Changes since v14:
* Add all architectures.

Changes since v13:
* New implementation.
---
 arch/alpha/kernel/syscalls/syscall.tbl  | 3 +++
 arch/arm/tools/syscall.tbl  | 3 +++
 arch/arm64/include/asm/unistd.h | 2 +-
 arch/arm64/include/asm/unistd32.h   | 6 ++
 arch/ia64/kernel/syscalls/syscall.tbl   | 3 +++
 arch/m68k/kernel/syscalls/syscall.tbl   | 3 +++
 arch/microblaze/kernel/syscalls/syscall.tbl | 3 +++
 arch/mips/kernel/syscalls/syscall_n32.tbl   | 3 +++
 arch/mips/kernel/syscalls/syscall_n64.tbl   | 3 +++
 arch/mips/kernel/syscalls/syscall_o32.tbl   | 3 +++
 arch/parisc/kernel/syscalls/syscall.tbl | 3 +++
 arch/powerpc/kernel/syscalls/syscall.tbl| 3 +++
 arch/s390/kernel/syscalls/syscall.tbl   | 3 +++
 arch/sh/kernel/syscalls/syscall.tbl | 3 +++
 arch/sparc/kernel/syscalls/syscall.tbl  | 3 +++
 arch/x86/entry/syscalls/syscall_32.tbl  | 3 +++
 arch/x86/entry/syscalls/syscall_64.tbl  | 3 +++
 arch/xtensa/kernel/syscalls/syscall.tbl | 3 +++
 include/uapi/asm-generic/unistd.h   | 8 +++-
 19 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/arch/alpha/kernel/syscalls/syscall.tbl 
b/arch/alpha/kernel/syscalls/syscall.tbl
index a6617067dbe6..6f8cc83c6baf 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -481,3 +481,6 @@
 549common  faccessat2  sys_faccessat2
 550common  process_madvise sys_process_madvise
 551common  epoll_pwait2sys_epoll_pwait2
+554common  landlock_create_ruleset 
sys_landlock_create_ruleset
+555common  landlock_add_rule   
sys_landlock_add_rule
+556common  landlock_enforce_ruleset_self   
sys_landlock_enforce_ruleset_self
diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
index 20e1170e2e0a..2f0134374fa1 100644
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@ -455,3 +455,6 @@
 439common  faccessat2  sys_faccessat2
 440common  process_madvise sys_process_madvise
 441common  epoll_pwait2sys_epoll_pwait2
+444common  landlock_create_ruleset 
sys_landlock_create_ruleset
+445common  landlock_add_rule   
sys_landlock_add_rule
+446common  landlock_enforce_ruleset_self   
sys_landlock_enforce_ruleset_self
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 86a9d7b3eabe..727bfc3be99b 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -38,7 +38,7 @@
 #define __ARM_NR_compat_set_tls(__ARM_NR_COMPAT_BASE + 5)
 #define __ARM_NR_COMPAT_END(__ARM_NR_COMPAT_BASE + 0x800)
 
-#define __NR_compat_syscalls   442
+#define __NR_compat_syscalls   447
 #endif
 
 #define __ARCH_WANT_SYS_CLONE
diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index cccfbbefbf95..d58ae4b29dd1 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -891,6 +891,12 @@ __SYSCALL(__NR_faccessat2, sys_faccessat2)
 __SYSCALL(__NR_process_madvise, sys_process_madvise)
 #define __NR_epoll_pwait2 441
 __SYSCALL(__NR_epoll_pwait2, compat_sys_epoll_pwait2)
+#define __NR_landlock_create_ruleset 444
+__SYSCALL(__NR_landlock_create_ruleset, sys_landlock_create_ruleset)
+#define __NR_landlock_add_rule 445
+__SYSCALL(__NR_landlock_add_rule, sys_landlock_add_rule)
+#define __NR_landlock_enforce_ruleset_self 446
+__SYSCALL(__NR_landlock_enforce_ruleset_self, 
sys_landlock_enforce_ruleset_self)
 
 /*
  * Please add new compat

[PATCH v27 03/12] landlock: Set up the security framework and manage credentials

2021-01-21 Thread Mickaël Salaün
From: Mickaël Salaün 

Process's credentials point to a Landlock domain, which is underneath
implemented with a ruleset.  In the following commits, this domain is
used to check and enforce the ptrace and filesystem security policies.
A domain is inherited from a parent to its child the same way a thread
inherits a seccomp policy.

Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Signed-off-by: Mickaël Salaün 
Reviewed-by: Jann Horn 
---

Changes since v25:
* Rename function to landlock_add_cred_hooks().

Changes since v23:
* Add an early check for the current domain in hook_cred_free() to avoid
  superfluous call.
* Cosmetic cleanup to make the code more readable.

Changes since v22:
* Add Reviewed-by: Jann Horn 

Changes since v21:
* Fix copyright dates.

Changes since v17:
* Constify returned domain pointers from landlock_get_current_domain()
  and landlock_get_task_domain() helpers.

Changes since v15:
* Optimize landlocked() for current thread.
* Display the greeting message when everything is initialized.

Changes since v14:
* Uses pr_fmt from common.h .
* Constify variables.
* Remove useless NULL initialization.

Changes since v13:
* totally get ride of the seccomp dependency
* only keep credential management and LSM setup.

Previous changes:
https://lore.kernel.org/lkml/20191104172146.30797-4-...@digikod.net/
---
 security/Kconfig   | 10 +++
 security/landlock/Makefile |  3 +-
 security/landlock/common.h | 20 +
 security/landlock/cred.c   | 46 ++
 security/landlock/cred.h   | 58 ++
 security/landlock/setup.c  | 31 
 security/landlock/setup.h  | 16 +++
 7 files changed, 178 insertions(+), 6 deletions(-)
 create mode 100644 security/landlock/common.h
 create mode 100644 security/landlock/cred.c
 create mode 100644 security/landlock/cred.h
 create mode 100644 security/landlock/setup.c
 create mode 100644 security/landlock/setup.h

diff --git a/security/Kconfig b/security/Kconfig
index 15a4342b5d01..0ced7fd33e4d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -278,11 +278,11 @@ endchoice
 
 config LSM
string "Ordered list of enabled LSMs"
-   default 
"lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" 
if DEFAULT_SECURITY_SMACK
-   default 
"lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" 
if DEFAULT_SECURITY_APPARMOR
-   default "lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if 
DEFAULT_SECURITY_TOMOYO
-   default "lockdown,yama,loadpin,safesetid,integrity,bpf" if 
DEFAULT_SECURITY_DAC
-   default 
"lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
+   default 
"landlock,lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf"
 if DEFAULT_SECURITY_SMACK
+   default 
"landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf"
 if DEFAULT_SECURITY_APPARMOR
+   default "landlock,lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" 
if DEFAULT_SECURITY_TOMOYO
+   default "landlock,lockdown,yama,loadpin,safesetid,integrity,bpf" if 
DEFAULT_SECURITY_DAC
+   default 
"landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
help
  A comma-separated list of LSMs, in initialization order.
  Any LSMs left off this list will be ignored. This can be
diff --git a/security/landlock/Makefile b/security/landlock/Makefile
index d846eba445bb..041ea242e627 100644
--- a/security/landlock/Makefile
+++ b/security/landlock/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_SECURITY_LANDLOCK) := landlock.o
 
-landlock-y := object.o ruleset.o
+landlock-y := setup.o object.o ruleset.o \
+   cred.o
diff --git a/security/landlock/common.h b/security/landlock/common.h
new file mode 100644
index ..5dc0fe15707d
--- /dev/null
+++ b/security/landlock/common.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Landlock LSM - Common constants and helpers
+ *
+ * Copyright © 2016-2020 Mickaël Salaün 
+ * Copyright © 2018-2020 ANSSI
+ */
+
+#ifndef _SECURITY_LANDLOCK_COMMON_H
+#define _SECURITY_LANDLOCK_COMMON_H
+
+#define LANDLOCK_NAME "landlock"
+
+#ifdef pr_fmt
+#undef pr_fmt
+#endif
+
+#define pr_fmt(fmt) LANDLOCK_NAME ": " fmt
+
+#endif /* _SECURITY_LANDLOCK_COMMON_H */
diff --git a/security/landlock/cred.c b/security/landlock/cred.c
new file mode 100644
index ..6725af24c684
--- /dev/null
+++ b/security/landlock/cred.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Landlock LSM - Credential hooks
+ *
+ * Copyright © 2017-2020 Mickaël Salaün 
+ * Copyright © 2018-2020 ANSSI
+ */
+
+#include 
+#include 
+
+#include "common.h"
+#include "cred.h"
+#include "ruleset.h"
+#include "setup.h"
+
+static int hook_cred_prepare(struct cred *const new,
+   const struct cred *const old, const gfp_t gfp)
+{
+   struct

[PATCH v27 00/12] Landlock LSM

2021-01-21 Thread Mickaël Salaün
Hi,

This patch series adjusts the semantic of file hierarchy access-control
per layer to get a more pragmatic and compatible approach.  I updated
the documentation to explain how layers, bind mounts and overlayfs are
handled by Landlock.  A syscall is also renamed to make it less
ambiguous for future evolution.  Last but not least, the test file
layout cleanups are more resilient, and a lot of tests are added to
cover bind mounts and overlayfs, which are fully supported.

The SLOC count is 1292 for security/landlock/ and 2425 for
tools/testing/selftest/landlock/ .  Test coverage for security/landlock/
is 94.7% of lines.  The code not covered only deals with internal kernel
errors (e.g. memory allocation) and race conditions.  This series is
being fuzzed by syzkaller, and patches are on their way:
https://github.com/google/syzkaller/pull/2380

The compiled documentation is available here:
https://landlock.io/linux-doc/landlock-v27/userspace-api/landlock.html

This series can be applied on top of v5.11-rc4 .  This can be tested
with CONFIG_SECURITY_LANDLOCK, CONFIG_SAMPLE_LANDLOCK and by prepending
"landlock," to CONFIG_LSM.  This patch series can be found in a Git
repository here:
https://github.com/landlock-lsm/linux/commits/landlock-v27
This patch series seems ready for upstream and I would really appreciate
final reviews.


# Landlock LSM

The goal of Landlock is to enable to restrict ambient rights (e.g.
global filesystem access) for a set of processes.  Because Landlock is a
stackable LSM [1], it makes possible to create safe security sandboxes
as new security layers in addition to the existing system-wide
access-controls. This kind of sandbox is expected to help mitigate the
security impact of bugs or unexpected/malicious behaviors in user-space
applications. Landlock empowers any process, including unprivileged
ones, to securely restrict themselves.

Landlock is inspired by seccomp-bpf but instead of filtering syscalls
and their raw arguments, a Landlock rule can restrict the use of kernel
objects like file hierarchies, according to the kernel semantic.
Landlock also takes inspiration from other OS sandbox mechanisms: XNU
Sandbox, FreeBSD Capsicum or OpenBSD Pledge/Unveil.

In this current form, Landlock misses some access-control features.
This enables to minimize this patch series and ease review.  This series
still addresses multiple use cases, especially with the combined use of
seccomp-bpf: applications with built-in sandboxing, init systems,
security sandbox tools and security-oriented APIs [2].

Previous version:
https://lore.kernel.org/lkml/20201209192839.1396820-1-...@digikod.net/

[1] 
https://lore.kernel.org/lkml/50db058a-7dde-441b-a7f9-f6837fe8b...@schaufler-ca.com/
[2] 
https://lore.kernel.org/lkml/f646e1c7-33cf-333f-070c-0a40ad046...@digikod.net/


Casey Schaufler (1):
  LSM: Infrastructure management of the superblock

Mickaël Salaün (11):
  landlock: Add object management
  landlock: Add ruleset and domain management
  landlock: Set up the security framework and manage credentials
  landlock: Add ptrace restrictions
  fs,security: Add sb_delete hook
  landlock: Support filesystem access-control
  landlock: Add syscall implementations
  arch: Wire up Landlock syscalls
  selftests/landlock: Add user space tests
  samples/landlock: Add a sandbox manager example
  landlock: Add user and kernel documentation

 Documentation/security/index.rst  |1 +
 Documentation/security/landlock.rst   |   79 +
 Documentation/userspace-api/index.rst |1 +
 Documentation/userspace-api/landlock.rst  |  306 ++
 MAINTAINERS   |   13 +
 arch/Kconfig  |7 +
 arch/alpha/kernel/syscalls/syscall.tbl|3 +
 arch/arm/tools/syscall.tbl|3 +
 arch/arm64/include/asm/unistd.h   |2 +-
 arch/arm64/include/asm/unistd32.h |6 +
 arch/ia64/kernel/syscalls/syscall.tbl |3 +
 arch/m68k/kernel/syscalls/syscall.tbl |3 +
 arch/microblaze/kernel/syscalls/syscall.tbl   |3 +
 arch/mips/kernel/syscalls/syscall_n32.tbl |3 +
 arch/mips/kernel/syscalls/syscall_n64.tbl |3 +
 arch/mips/kernel/syscalls/syscall_o32.tbl |3 +
 arch/parisc/kernel/syscalls/syscall.tbl   |3 +
 arch/powerpc/kernel/syscalls/syscall.tbl  |3 +
 arch/s390/kernel/syscalls/syscall.tbl |3 +
 arch/sh/kernel/syscalls/syscall.tbl   |3 +
 arch/sparc/kernel/syscalls/syscall.tbl|3 +
 arch/um/Kconfig   |1 +
 arch/x86/entry/syscalls/syscall_32.tbl|3 +
 arch/x86/entry/syscalls/syscall_64.tbl|3 +
 arch/xtensa/kernel/syscalls/syscall.tbl   |3 +
 fs/super.c|1 +
 include/linux/lsm_hook_defs.h |1 +
 include/linux/lsm_hooks.h |3 +
 include/linux/security.h   

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

2021-01-21 Thread Alex Williamson
On Wed, 20 Jan 2021 14:21:59 +0100
Niklas Schnelle  wrote:

> On 1/19/21 9:02 PM, Matthew Rosato wrote:
> > Some s390 PCI devices (e.g. ISM) perform I/O operations that have very  
> .. snip ...
> > +
> > +static size_t vfio_pci_zdev_io_rw(struct vfio_pci_device *vdev,
> > + char __user *buf, size_t count,
> > + loff_t *ppos, bool iswrite)
> > +{  
> ... snip ...
> > +   /*
> > +* For now, the largest allowed block I/O is advertised as PAGE_SIZE,
> > +* and cannot exceed a page boundary - so a single page is enough.  The
> > +* guest should have validated this but let's double-check that the
> > +* request will not cross a page boundary.
> > +*/
> > +   if (((region->req.gaddr & ~PAGE_MASK)
> > +   + region->req.len - 1) & PAGE_MASK) {
> > +   return -EIO;
> > +   }
> > +
> > +   mutex_lock(&zdev->lock);  
> 
> I plan on using the zdev->lock for preventing concurrent zPCI devices
> removal/configuration state changes between zPCI availability/error
> events and enable_slot()/disable_slot() and 
> /sys/bus/pci/devices//recover.
> 
> With that use in place using it here causes a deadlock when doing 
> "echo 0 > /sys/bus/pci/slots//power from the host for an ISM device
> attached to a guest.
> 
> This is because the (soft) hot unplug will cause vfio to notify QEMU, which
> sends a deconfiguration request to the guest, which then tries to
> gracefully shutdown the device. During that shutdown the device will
> be accessed, running into this code path which then blocks on
> the lock held by the disable_slot() code which waits on vfio
> releasing the device.
> 
> Alex may correct me if I'm wrong but I think instead vfio should
> be holding the PCI device lock via pci_device_lock(pdev).

There be dragons in device_lock, which is why we have all the crude
try-lock semantics in reset paths.  Don't use it trivially.  Device
lock is not necessary here otherwise, the device is bound to a driver
and has an open userspace file descriptor through which the user is
performing this access.  The device can't be removed without unbinding
the driver, which can't happen while the user still has open files to
it.  Thanks,

Alex



Re: [ANNOUNCE] v5.11-rc4-rt1

2021-01-21 Thread Pavel Machek
Hi!

> I'm pleased to announce the v5.11-rc4-rt1 patch set. 
> 
> Changes since v5.10.8-rt24:
> 
>   - Updated to v5.11-rc4
> 
> Known issues
>  - kdb/kgdb can easily deadlock.
>  - kmsg dumpers expecting not to be called in parallel can clobber
>their temp buffer.
>  - netconsole triggers WARN.

I noticed... lot of code using in_interrupt() to decide what to do is
making it to 5.10-stable at the moment (and I guess that means
vanilla, too).

I have recollection that that is not okay thing to do. Am I right?

Examples: 8abec36d1274bbd5ae8f36f3658b9abb3db56c31,
d68b29584c25dbacd01ed44a3e45abb35353f1de.

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature


Re: [RESEND PATCH v3 0/2] ata: ahci_brcm: Fix use of BCM7216 reset controller

2021-01-21 Thread Florian Fainelli



On 1/14/2021 12:46 PM, Florian Fainelli wrote:
> On 1/5/21 1:22 PM, Florian Fainelli wrote:
>> On 12/23/20 4:05 PM, Florian Fainelli wrote:
>>>
>>>
>>> On 12/16/2020 1:41 PM, Jim Quinlan wrote:
 v3 -- discard commit from v2; instead rely on the new function
   reset_control_rearm provided in a recent commit [1] applied
   to reset/next.
-- New commit to correct pcie-brcmstb.c usage of a reset controller
   to use reset/rearm verses deassert/assert.

 v2 -- refactor rescal-reset driver to implement assert/deassert rather than
   reset because the reset call only fires once per lifetime and we need
   to reset after every resume from S2 or S3.
-- Split the use of "ahci" and "rescal" controllers in separate fields
   to keep things simple.

 v1 -- original


 [1] Applied commit "reset: make shared pulsed reset controls 
 re-triggerable"
 found at git://git.pengutronix.de/git/pza/linux.git
 branch reset/shared-retrigger
>>>
>>> The changes in that branch above have now landed in Linus' tree with:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=557acb3d2cd9c82de19f944f6cc967a347735385
>>>
>>> It would be good if we could get both patches applied via the same tree
>>> or within the same cycle to avoid having either PCIe or SATA broken on
>>> these platforms.
>>
>> Ping? Can someone apply those patches if you are happy with them? Thank you.
> 
> Ping? Can we review and ideally also apply these patches? Thanks

Is there something going on preventing these patches from being reviewed
and/or applied?
-- 
Florian


Re: [PATCH] ata: ahci_brcm: Add back regulators management

2021-01-21 Thread Florian Fainelli



On 1/14/2021 12:46 PM, Florian Fainelli wrote:
> On 12/23/20 2:41 PM, Florian Fainelli wrote:
>> While reworking the resources management and departing from using
>> ahci_platform_enable_resources() which did not allow a proper step
>> separation like we need, we unfortunately lost the ability to control
>> AHCI regulators. This broke some Broadcom STB systems that do expect
>> regulators to be turned on to link up with attached hard drives.
>>
>> Fixes: c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management")
>> Signed-off-by: Florian Fainelli 
>> ---
>> Jens,
>>
>> This is based on your for-next branch, let me know if you need me to
>> rebase to a different branch. Thanks!
> 
> Jens, this is a bug fix so it would be nice to get this applied at some> 
> point. Thank you

Jens, can you apply this patch or let me know if you need me to change
something? Thanks
-- 
Florian


Re: [PATCH] diffconfig: use python3 instead of python in Shebang line

2021-01-21 Thread Scott Branden
Hi Masahiro,

On 2021-01-21 12:25 p.m., Masahiro Yamada wrote:
> On Fri, Jan 22, 2021 at 2:17 AM Scott Branden
>  wrote:
>> Use python3 instead of python in diffconfig Shebang line.
>> python2 was sunset January 1, 2000 and environments do not need
>> to support python any more.
>>
>> Fixes: b24413180f56 ("tweewide: Fix most Shebang lines")
>> Signed-off-by: Scott Branden 
>> ---
>>  scripts/diffconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/diffconfig b/scripts/diffconfig
>> index 627eba5849b5..d5da5fa05d1d 100755
>> --- a/scripts/diffconfig
>> +++ b/scripts/diffconfig
>> @@ -1,4 +1,4 @@
>> -#!/usr/bin/env python
>> +#!/usr/bin/env python3
>>  # SPDX-License-Identifier: GPL-2.0
>>  #
>>  # diffconfig - a tool to compare .config files.
>> --
>> 2.17.1
>>
> Just from curiosity, what problem is this solving?
It is solving the problem that python is long past its life:
https://www.python.org/doc/sunset-python-2/

The 5.11-rc kernel diffconfig doesn't work now due
to the /usr/bin/python change to /usr/bin/env python.

Could we please ensure this makes it into 5.11 and/or
maintains the FIxes tag if it does not?
>
> Is there a distribution where 'python' does not exist,
> but 'python3' does ?
Yes, Python is finally being removed from some distributions
and has already been done so from my yocto builds where
I detected the problem.
>
Thanks,
Scott


Re: [PATCH v17 08/26] x86/mm: Introduce _PAGE_COW

2021-01-21 Thread Yu, Yu-cheng

On 1/21/2021 12:26 PM, Dave Hansen wrote:

Usually, the compiler is better at making code efficient than humans.  I
find that coding it in the most human-readable way is best unless I
*know* the compiler is unable to generate god code.


"good code", even.

I really want a "god code" compiler, though. :)

With my version of GCC, the shifting implementation creates five 
instructions, all operate on registers only.  The other implementation 
also creates five instructions, but introduces one jump and one memory 
access.  But, you are right, being readable is also important.  Maybe we 
can tweak it a little or create something similar to those in bitops.


--
Yu-cheng


[PATCH net v2 0/2] fix and move definitions of MRP data structures

2021-01-21 Thread Rasmus Villemoes
v2: update commit log of the patch to include comments on 32 bit
alignment; include second patch moving the structs out of uapi.

Rasmus Villemoes (2):
  net: mrp: fix definitions of MRP test packets
  net: mrp: move struct definitions out of uapi

 include/uapi/linux/mrp_bridge.h | 86 -
 net/bridge/br_private_mrp.h | 29 +++
 2 files changed, 29 insertions(+), 86 deletions(-)

-- 
2.23.0



Re: [PATCH v17 08/26] x86/mm: Introduce _PAGE_COW

2021-01-21 Thread Borislav Petkov
On Thu, Jan 21, 2021 at 12:16:23PM -0800, Yu, Yu-cheng wrote:
> It clears _PAGE_DIRTY and sets _PAGE_COW.  That is,
> 
> if (pte.pte & _PAGE_DIRTY) {
>   pte.pte &= ~_PAGE_DIRTY;
>   pte.pte |= _PAGE_COW;
> }
> 
> So, shifting makes resulting code more efficient.

Efficient for what? Is this a hot path?

If not, I'd take readable code any day of the week.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


[PATCH net v2 1/2] net: mrp: fix definitions of MRP test packets

2021-01-21 Thread Rasmus Villemoes
Wireshark says that the MRP test packets cannot be decoded - and the
reason for that is that there's a two-byte hole filled with garbage
between the "transitions" and "timestamp" members.

So Wireshark decodes the two garbage bytes and the top two bytes of
the timestamp written by the kernel as the timestamp value (which thus
fluctuates wildly), and interprets the lower two bytes of the
timestamp as a new (type, length) pair, which is of course broken.

Even though this makes the timestamp field in the struct unaligned, it
actually makes it end up on a 32 bit boundary in the frame as mandated
by the standard, since it is preceded by a two byte TLV header.

The struct definitions live under include/uapi/, but they are not
really part of any kernel<->userspace API/ABI, so fixing the
definitions by adding the packed attribute should not cause any
compatibility issues.

Signed-off-by: Rasmus Villemoes 
---
 include/uapi/linux/mrp_bridge.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/mrp_bridge.h b/include/uapi/linux/mrp_bridge.h
index 6aeb13ef0b1e..d1d0cf65916d 100644
--- a/include/uapi/linux/mrp_bridge.h
+++ b/include/uapi/linux/mrp_bridge.h
@@ -96,7 +96,7 @@ struct br_mrp_ring_test_hdr {
__be16 state;
__be16 transitions;
__be32 timestamp;
-};
+} __attribute__((__packed__));
 
 struct br_mrp_ring_topo_hdr {
__be16 prio;
@@ -141,7 +141,7 @@ struct br_mrp_in_test_hdr {
__be16 state;
__be16 transitions;
__be32 timestamp;
-};
+} __attribute__((__packed__));
 
 struct br_mrp_in_topo_hdr {
__u8 sa[ETH_ALEN];
-- 
2.23.0



[PATCH net v2 2/2] net: mrp: move struct definitions out of uapi

2021-01-21 Thread Rasmus Villemoes
None of these are actually used in the kernel/userspace interface -
there's a userspace component of implementing MRP, and userspace will
need to construct certain frames to put on the wire, but there's no
reason the kernel should provide the relevant definitions in a UAPI
header.

In fact, most of these structs are unused in the kernel, so only keep
the few that are actually referenced in the kernel code, and move them
to the br_private_mrp.h header.

Signed-off-by: Rasmus Villemoes 
---
 include/uapi/linux/mrp_bridge.h | 86 -
 net/bridge/br_private_mrp.h | 29 +++
 2 files changed, 29 insertions(+), 86 deletions(-)

diff --git a/include/uapi/linux/mrp_bridge.h b/include/uapi/linux/mrp_bridge.h
index d1d0cf65916d..f090acd4f6c4 100644
--- a/include/uapi/linux/mrp_bridge.h
+++ b/include/uapi/linux/mrp_bridge.h
@@ -70,90 +70,4 @@ enum br_mrp_sub_tlv_header_type {
BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR = 0x3,
 };
 
-struct br_mrp_tlv_hdr {
-   __u8 type;
-   __u8 length;
-};
-
-struct br_mrp_sub_tlv_hdr {
-   __u8 type;
-   __u8 length;
-};
-
-struct br_mrp_end_hdr {
-   struct br_mrp_tlv_hdr hdr;
-};
-
-struct br_mrp_common_hdr {
-   __be16 seq_id;
-   __u8 domain[MRP_DOMAIN_UUID_LENGTH];
-};
-
-struct br_mrp_ring_test_hdr {
-   __be16 prio;
-   __u8 sa[ETH_ALEN];
-   __be16 port_role;
-   __be16 state;
-   __be16 transitions;
-   __be32 timestamp;
-} __attribute__((__packed__));
-
-struct br_mrp_ring_topo_hdr {
-   __be16 prio;
-   __u8 sa[ETH_ALEN];
-   __be16 interval;
-};
-
-struct br_mrp_ring_link_hdr {
-   __u8 sa[ETH_ALEN];
-   __be16 port_role;
-   __be16 interval;
-   __be16 blocked;
-};
-
-struct br_mrp_sub_opt_hdr {
-   __u8 type;
-   __u8 manufacture_data[MRP_MANUFACTURE_DATA_LENGTH];
-};
-
-struct br_mrp_test_mgr_nack_hdr {
-   __be16 prio;
-   __u8 sa[ETH_ALEN];
-   __be16 other_prio;
-   __u8 other_sa[ETH_ALEN];
-};
-
-struct br_mrp_test_prop_hdr {
-   __be16 prio;
-   __u8 sa[ETH_ALEN];
-   __be16 other_prio;
-   __u8 other_sa[ETH_ALEN];
-};
-
-struct br_mrp_oui_hdr {
-   __u8 oui[MRP_OUI_LENGTH];
-};
-
-struct br_mrp_in_test_hdr {
-   __be16 id;
-   __u8 sa[ETH_ALEN];
-   __be16 port_role;
-   __be16 state;
-   __be16 transitions;
-   __be32 timestamp;
-} __attribute__((__packed__));
-
-struct br_mrp_in_topo_hdr {
-   __u8 sa[ETH_ALEN];
-   __be16 id;
-   __be16 interval;
-};
-
-struct br_mrp_in_link_hdr {
-   __u8 sa[ETH_ALEN];
-   __be16 port_role;
-   __be16 id;
-   __be16 interval;
-};
-
 #endif
diff --git a/net/bridge/br_private_mrp.h b/net/bridge/br_private_mrp.h
index af0e9eff6549..3f80a0a79a32 100644
--- a/net/bridge/br_private_mrp.h
+++ b/net/bridge/br_private_mrp.h
@@ -88,4 +88,33 @@ int br_mrp_switchdev_send_in_test(struct net_bridge *br, 
struct br_mrp *mrp,
 int br_mrp_ring_port_open(struct net_device *dev, u8 loc);
 int br_mrp_in_port_open(struct net_device *dev, u8 loc);
 
+/* MRP protocol data units */
+struct br_mrp_tlv_hdr {
+   __u8 type;
+   __u8 length;
+};
+
+struct br_mrp_common_hdr {
+   __be16 seq_id;
+   __u8 domain[MRP_DOMAIN_UUID_LENGTH];
+};
+
+struct br_mrp_ring_test_hdr {
+   __be16 prio;
+   __u8 sa[ETH_ALEN];
+   __be16 port_role;
+   __be16 state;
+   __be16 transitions;
+   __be32 timestamp;
+} __attribute__((__packed__));
+
+struct br_mrp_in_test_hdr {
+   __be16 id;
+   __u8 sa[ETH_ALEN];
+   __be16 port_role;
+   __be16 state;
+   __be16 transitions;
+   __be32 timestamp;
+} __attribute__((__packed__));
+
 #endif /* _BR_PRIVATE_MRP_H */
-- 
2.23.0



Re: [PATCH -V9 2/3] NOT kernel/man2/set_mempolicy.2: Add mode flag MPOL_F_NUMA_BALANCING

2021-01-21 Thread Alejandro Colomar (man-pages)
Hi Huang Ying,

On 1/20/21 7:12 AM, Huang Ying wrote:
> Signed-off-by: "Huang, Ying" 
> Cc: "Alejandro Colomar" 

Sorry, for the confusion.
I have a different email for reading lists.
I use alx.manpages@ for everything,
and alx.mailinglists@ just for reading lists, but sometimes,
when I answer emails not sent to me,
I forget to change the reply address,
and you see that address (which I intended to be readonly).

Please, use alx.manpa...@gmail.com,
or your mail might get lost between many list emails ;)

> ---
>  man2/set_mempolicy.2 | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/man2/set_mempolicy.2 b/man2/set_mempolicy.2
> index 68011eecb..fa64a1820 100644
> --- a/man2/set_mempolicy.2
> +++ b/man2/set_mempolicy.2
> @@ -113,6 +113,22 @@ A nonempty
>  .I nodemask
>  specifies node IDs that are relative to the set of
>  node IDs allowed by the process's current cpuset.
> +.TP
> +.BR MPOL_F_NUMA_BALANCING " (since Linux 5.12)"
> +When
> +.I mode
> +is
> +.BR MPOL_BIND ,
> +enable the kernel NUMA balancing for the task if it is supported by
> +the kernel.
> +If the flag isn't supported by the kernel, or is used with
> +.I mode
> +other than
> +.BR MPOL_BIND ,
> +return \-1 and
> +.I errno
> +is set to
> +.BR EINVAL .

The wording here is a bit weird:
[return // is set].  It would be better as
[return // set] or [returns // sets] or [is returned // is set].

The same page, has:

[
RETURN VALUE
   On success, set_mempolicy() returns 0; on error, -1 is  re‐
   turned and errno is set to indicate the error.
]

so I'd use the latter for consistency.

>  .PP
>  .I nodemask
>  points to a bit mask of node IDs that contains up to
> @@ -293,6 +309,12 @@ argument specified both
>  .B MPOL_F_STATIC_NODES
>  and
>  .BR MPOL_F_RELATIVE_NODES .
> +Or, the
> +.B MPOL_F_NUMA_BALANCING
> +isn't supported by the kernel, or is used with
> +.I mode
> +other than
> +.BR MPOL_BIND .
>  .TP
>  .B ENOMEM
>  Insufficient kernel memory was available.
> 

Other than that, it's good for me.

Thanks,

Alex

Just a reminder for myself (please ignore it):
- Break EINVAL into multiple paragraphs.
- (Maybe) reorder lists to be in alphabetical order.

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/


Re: [PATCH 2/6] bitmap: move some macros from linux/bitmap.h to linux/bitops.h

2021-01-21 Thread Yury Norov
On Thu, Jan 21, 2021 at 2:18 AM Andy Shevchenko
 wrote:
>
> On Wed, Jan 20, 2021 at 04:06:26PM -0800, Yury Norov wrote:
> > In the following patches of the series they are used by
> > find_bit subsystem.
>
> s/subsystem/API/
>
> ...
>
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@ -7,6 +7,17 @@
> >
> >  #include 
> >
> > +#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 
> > 1)))
> > +#define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 
> > 1)))
>
> Hmm... Naming here is not in the bitops namespace.
> I would expect BITS rather than BITMAP for these two.
>
> So, we have at least the following options:
>  - split to a separate header, like bitmap_macros.h
>  - s/BITMAP/BITS/ and either define BITMAP_* as respective BITS_* or rename it
>everywhere in bitmap.*
>  - your variant
>  - ...???...

We have GENMASK in linux/bits.h. I think we should use it here and
drop local ones.
It will also cover the case of  OFFSET macro that you suggested in
your comment to
patch #5.


Re: [PATCH v1] trace: Fix race in trace_open and buffer resize call

2021-01-21 Thread Steven Rostedt
On Thu, 21 Jan 2021 23:15:22 +0300
Denis Efremov  wrote:

> On 1/21/21 10:09 PM, Steven Rostedt wrote:
> > On Thu, 21 Jan 2021 17:30:40 +0300
> > Denis Efremov  wrote:
> >   
> >> Hi,
> >>
> >> This patch (CVE-2020-27825) was tagged with
> >> Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding 
> >> synchronize_rcu for each CPU")
> >>
> >> I'm not an expert here but it seems like b23d7a5f4a07a only refactored
> >> ring_buffer_reset_cpu() by introducing reset_disabled_cpu_buffer() without
> >> significant changes. Hence, 
> >> mutex_lock(&buffer->mutex)/mutex_unlock(&buffer->mutex)
> >> can be backported further than b23d7a5f4a07a~ and to all LTS kernels. Is
> >> b23d7a5f4a07a the actual cause of the bug?
> >>  
> > 
> > Ug, that looks to be a mistake. Looking back at the thread about this:
> > 
> >   
> > https://lore.kernel.org/linux-arm-msm/20200915141304.41fa7...@gandalf.local.home/
> >   
> 
> I see from the link that it was planned to backport the patch to LTS kernels:
> 
> > Actually we are seeing issue in older kernel like 4.19/4.14/5.4 and there 
> > below patch was not 
> > present in stable branches:
> > Commit b23d7a5f4a07 ("ring-buffer: speed up buffer resets by avoiding 
> > synchronize_rcu for each CPU")  
> 
> The point is that it's not backported yet. Maybe because of Fixes tag. I've 
> discovered
> this while trying to formalize CVE-2020-27825 bug in cvehound
> https://github.com/evdenis/cvehound/blob/master/cvehound/cve/CVE-2020-27825.cocci
> 
> I think that the backport to the 4.4+ should be something like:
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 547a3a5ac57b..2171b377bbc1 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -4295,6 +4295,8 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, 
> int cpu)
>   if (!cpumask_test_cpu(cpu, buffer->cpumask))
>   return;
>  
> + mutex_lock(&buffer->mutex);
> +
>   atomic_inc(&buffer->resize_disabled);
>   atomic_inc(&cpu_buffer->record_disabled);
>  
> @@ -4317,6 +4319,8 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, 
> int cpu)
>  
>   atomic_dec(&cpu_buffer->record_disabled);
>   atomic_dec(&buffer->resize_disabled);
> +
> + mutex_unlock(&buffer->mutex);
>  }
>  EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
>  

That could possibly work.

-- Steve



linux-next: Fixes tag needs some work in the qcom tree

2021-01-21 Thread Stephen Rothwell
Hi all,

In commit

  d4863ef399a2 ("arm64: dts: qcom: sdm845-db845c: Fix reset-pin of ov8856 node")

Fixes tag

  Fixes: d4919a44564b ("arm64: dts: qcom: sdm845-db845c: Add ov8856 & ov7251

has these problem(s):

  - Subject has leading but no trailing parentheses
  - Subject has leading but no trailing quotes

Pleas do not split Fixes tags over more than one line.  Also, keep all
the commit message tags together at the end of the message.

-- 
Cheers,
Stephen Rothwell


pgp7rgB4AYRv3.pgp
Description: OpenPGP digital signature


[PATCH 15/29] csky: Fixup update_mmu_cache called with user io mapping

2021-01-21 Thread guoren
From: Guo Ren 

The function update_mmu_cache could be called by user-io mapping.
There is no space of struct page in mem_map for the pte. Just
ignore the user-io mmaping in update_mmu_cache.

Signed-off-by: Guo Ren 
---
 arch/csky/abiv2/cacheflush.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/csky/abiv2/cacheflush.c b/arch/csky/abiv2/cacheflush.c
index 790f1ebfba44..39c51399dd81 100644
--- a/arch/csky/abiv2/cacheflush.c
+++ b/arch/csky/abiv2/cacheflush.c
@@ -12,6 +12,9 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned 
long address,
unsigned long addr;
struct page *page;
 
+   if (!pfn_valid(pte_pfn(*pte)))
+   return;
+
page = pfn_to_page(pte_pfn(*pte));
if (page == ZERO_PAGE(0))
return;
-- 
2.17.1



Re: [tip: x86/entry] x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y

2021-01-21 Thread Ingo Molnar


* tip-bot2 for Andrea Righi  wrote:

> The following commit has been merged into the x86/entry branch of tip:
> 
> Commit-ID: e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
> Gitweb:
> https://git.kernel.org/tip/e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
> Author:Andrea Righi 
> AuthorDate:Thu, 14 Jan 2021 12:48:35 +01:00
> Committer: Ingo Molnar 
> CommitterDate: Thu, 21 Jan 2021 08:11:52 +01:00
> 
> x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y
> 
> With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_64.o is just an
> empty object file.
> 
> With the newer binutils (tested with 2.35.90.20210113-1ubuntu1) the GNU
> assembler doesn't generate a symbol table for empty object files and
> objtool fails with the following error when a valid symbol table cannot
> be found:
> 
>   arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table
> 
> To prevent this from happening, build thunk_$(BITS).o only if
> CONFIG_PREEMPTION is enabled.
> 
>   BugLink: https://bugs.launchpad.net/bugs/1911359
> 
> Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft")
> Signed-off-by: Andrea Righi 
> Signed-off-by: Ingo Molnar 
> Cc: Borislav Petkov 
> Link: https://lore.kernel.org/r/YAAvk0UQelq0Ae7+@xps-13-7390

Hm, this fails to build on UML defconfig:

 
/home/mingo/gcc/cross/lib/gcc/x86_64-linux/9.3.1/../../../../x86_64-linux/bin/ld:
 arch/x86/um/../entry/thunk_64.o: in function `preempt_schedule_thunk':
 /home/mingo/tip.cross/arch/x86/um/../entry/thunk_64.S:34: undefined reference 
to `preempt_schedule'
 
/home/mingo/gcc/cross/lib/gcc/x86_64-linux/9.3.1/../../../../x86_64-linux/bin/ld:
 arch/x86/um/../entry/thunk_64.o: in function `preempt_schedule_notrace_thunk':
 /home/mingo/tip.cross/arch/x86/um/../entry/thunk_64.S:35: undefined reference 
to `preempt_schedule_notrace'

Thanks,

Ingo


Re: [PATCH 0/2] irqchip: Remove obsolete drivers

2021-01-21 Thread Marc Zyngier
On Wed, 20 Jan 2021 14:30:06 +0100, Arnd Bergmann wrote:
> A few Arm platforms are getting removed in v5.12, this removes
> the corresponding irqchip drivers.
> 
> Link: 
> https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/
> 
> 
> Arnd Bergmann (2):
>   irqchip: remove sigma tango driver
>   irqchip: remove sirfsoc driver
> 
> [...]

Applied to irq/irqchip-5.12, thanks!

[1/2] irqchip: remove sigma tango driver
  commit: 00e772c4929257b11b51d47e4645f67826ded0fc
[2/2] irqchip: remove sirfsoc driver
  commit: 5c1ea0d842b1e73ae04870527ec29d5479c35041

Cheers,

M.
-- 
Without deviation from the norm, progress is not possible.




Re: [PATCH v5 00/10] sunxi: Support IRQ wakeup from deep sleep

2021-01-21 Thread Marc Zyngier
On Sun, 17 Jan 2021 23:50:30 -0600, Samuel Holland wrote:
> Allwinner sun6i/sun8i/sun50i SoCs (A31 and newer) have two interrupt
> controllers: GIC and R_INTC. GIC does not support wakeup. R_INTC handles
> the external NMI pin, and provides 32+ IRQs to the ARISC. The first 16
> of these correspond 1:1 to a block of GIC IRQs starting with the NMI.
> The last 13-16 multiplex the first (up to) 128 GIC SPIs.
> 
> This series replaces the existing chained irqchip driver that could only
> control the NMI, with a stacked irqchip driver that also provides wakeup
> capability for those multiplexed SPI IRQs. The idea is to preconfigure
> the ARISC's IRQ controller, and then the ARISC firmware knows to wake up
> as soon as it receives an IRQ. It can also decide how deep it can
> suspend based on the enabled wakeup IRQs.
> 
> [...]

Applied to irq/irqchip-5.12, thanks!

[01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi
commit: ad6b47cdef760410311f41876b21eb0c6fda4717
[02/10] dt-bindings: irq: sun6i-r: Add a compatible for the H3
commit: 6436eb4417094ea3308b33d8392fc02a1068dc78
[03/10] irqchip/sun6i-r: Use a stacked irqchip driver
commit: 4e34614636b31747b190488240a95647c227021f
[04/10] irqchip/sun6i-r: Add wakeup support
commit: 7ab365f6cd6de1e2b0cb1e1e3873dbf68e6f1003

Please route the dts patches via the soc tree. Also, I had to
manually fix the first patch as it wouldn't apply on top of
5.11-rc4 (which tree has it been diffed against?). Please
check that the resolution is correct.

Cheers,

M.
-- 
Without deviation from the norm, progress is not possible.




Re: [PATCH] diffconfig: use python3 instead of python in Shebang line

2021-01-21 Thread Andy Shevchenko
On Thu, Jan 21, 2021 at 10:31 PM Andy Shevchenko
 wrote:
>
> On Thu, Jan 21, 2021 at 10:28 PM Masahiro Yamada  wrote:
> >
> > On Fri, Jan 22, 2021 at 2:17 AM Scott Branden
> >  wrote:
> > >
> > > Use python3 instead of python in diffconfig Shebang line.
> > > python2 was sunset January 1, 2000 and environments do not need
> > > to support python any more.
>
> > Just from curiosity, what problem is this solving?
> >
> > Is there a distribution where 'python' does not exist,
> > but 'python3' does ?
>
> Yes. Called surprise surprise Debian
> An it's a rare case when I agree with them.

For the record, you seems haven't noticed:
https://lkml.org/lkml/2020/12/9/446

-- 
With Best Regards,
Andy Shevchenko


[PATCH RESEND] pinctrl: mediatek: Fix trigger type setting follow for unexpected interrupt

2021-01-21 Thread Hailong Fan
When flipping the polarity will be generated interrupt under certain
circumstances, but GPIO external signal has not changed.
Then, mask the interrupt before polarity setting, and clear the
unexpected interrupt after trigger type setting completed.

Signed-off-by: Hailong Fan 
---
Resend since some server reject.
---
 drivers/pinctrl/mediatek/mtk-eint.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/mtk-eint.c 
b/drivers/pinctrl/mediatek/mtk-eint.c
index 22736f60c16c..3acda6bb401e 100644
--- a/drivers/pinctrl/mediatek/mtk-eint.c
+++ b/drivers/pinctrl/mediatek/mtk-eint.c
@@ -157,6 +157,7 @@ static void mtk_eint_ack(struct irq_data *d)
 static int mtk_eint_set_type(struct irq_data *d, unsigned int type)
 {
struct mtk_eint *eint = irq_data_get_irq_chip_data(d);
+   unsigned int unmask;
u32 mask = BIT(d->hwirq & 0x1f);
void __iomem *reg;
 
@@ -173,6 +174,13 @@ static int mtk_eint_set_type(struct irq_data *d, unsigned 
int type)
else
eint->dual_edge[d->hwirq] = 0;
 
+   if (!mtk_eint_get_mask(eint, d->hwirq)) {
+   mtk_eint_mask(d);
+   unmask = 1;
+   } else {
+   unmask = 0;
+   }
+
if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING)) {
reg = mtk_eint_get_offset(eint, d->hwirq, eint->regs->pol_clr);
writel(mask, reg);
@@ -189,8 +197,9 @@ static int mtk_eint_set_type(struct irq_data *d, unsigned 
int type)
writel(mask, reg);
}
 
-   if (eint->dual_edge[d->hwirq])
-   mtk_eint_flip_edge(eint, d->hwirq);
+   mtk_eint_ack(d);
+   if (unmask == 1)
+   mtk_eint_unmask(d);
 
return 0;
 }
-- 
2.18.0



Re: [PATCH v3] mhi: use irq_flags if controller driver configures it

2021-01-21 Thread Manivannan Sadhasivam
On Wed, Jan 13, 2021 at 09:40:19AM +0200, Kalle Valo wrote:
> Manivannan Sadhasivam  writes:
> 
> > On Mon, Jan 04, 2021 at 06:11:28PM +0800, Carl Huang wrote:
> >> If controller driver has specified the irq_flags, mhi uses this specified
> >> irq_flags. Otherwise, mhi uses default irq_flags.
> >> 
> >> The purpose of this change is to support one MSI vector for QCA6390.
> >> MHI will use one same MSI vector too in this scenario.
> >> 
> >> In case of one MSI vector, IRQ_NO_BALANCING is needed when irq handler
> >> is requested. The reason is if irq migration happens, the msi_data may
> >> change too. However, the msi_data is already programmed to QCA6390
> >> hardware during initialization phase. This msi_data inconsistence will
> >> result in crash in kernel.
> >> 
> >> Another issue is in case of one MSI vector, IRQF_NO_SUSPEND will trigger
> >> WARNINGS because QCA6390 wants to disable the IRQ during the suspend.
> >> 
> >> To avoid above two issues, QCA6390 driver specifies the irq_flags in case
> >> of one MSI vector when mhi_register_controller is called.
> >> 
> >> Signed-off-by: Carl Huang 
> >> Reviewed-by: Manivannan Sadhasivam 
> >
> > Applied to mhi-next!
> 
> Would it be possible again to have an immutable branch for this commit?
> We need it for implementing one MHI support to ath11k[1] required by
> Dell XPS 13 9310 laptops, which a lot of people are waiting. Otherwise I
> can only apply the feature for v5.13, which will be released on July.
> 

Dropped this patch from mhi-next and applied to mhi-ath11k-immutable branch:
https://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git/log/?h=mhi-ath11k-immutable

This branch will also be merged into mhi-next.

Thanks,
Mani


[PATCH 09/29] csky: Fixup PTE global for 2.5:1.5 virtual memory

2021-01-21 Thread guoren
From: Guo Ren 

Fixup commit c2d1adfa9a24 "csky: Add memory layout 2.5G(user):1.5G
(kernel)". That patch broke the global bit in PTE.

C-SKY TLB's entry contain two pages:
vpn, vpn + 1 -> ppn0, ppn1

All PPN's attributes contain global bit and final global is PPN0.G
& PPN1.G. So we must keep PPN0.G and PPN1.G same in one TLB's
entry.

Signed-off-by: Guo Ren 
---
 arch/csky/include/asm/pgtable.h | 2 +-
 arch/csky/mm/init.c | 8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/csky/include/asm/pgtable.h b/arch/csky/include/asm/pgtable.h
index 6ec97af0d1ff..2485db84dba8 100644
--- a/arch/csky/include/asm/pgtable.h
+++ b/arch/csky/include/asm/pgtable.h
@@ -34,7 +34,7 @@
 
 #define pmd_page(pmd)  (pfn_to_page(pmd_phys(pmd) >> PAGE_SHIFT))
 #define pte_clear(mm, addr, ptep)  set_pte((ptep), \
-   (((unsigned int) addr & PAGE_OFFSET) ? __pte(_PAGE_GLOBAL) : __pte(0)))
+   (((unsigned int) addr >= PAGE_OFFSET) ? __pte(_PAGE_GLOBAL) : __pte(0)))
 #define pte_none(pte)  (!(pte_val(pte) & ~_PAGE_GLOBAL))
 #define pte_present(pte)   (pte_val(pte) & _PAGE_PRESENT)
 #define pte_pfn(x) ((unsigned long)((x).pte_low >> PAGE_SHIFT))
diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c
index 7742f1441a67..8170d7ce116b 100644
--- a/arch/csky/mm/init.c
+++ b/arch/csky/mm/init.c
@@ -30,9 +30,12 @@
 #include 
 #include 
 
+#define PTRS_KERN_TABLE \
+   ((PTRS_PER_PGD - USER_PTRS_PER_PGD) * PTRS_PER_PTE)
+
 pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
 pte_t invalid_pte_table[PTRS_PER_PTE] __page_aligned_bss;
-pte_t kernel_pte_tables[(PTRS_PER_PGD - USER_PTRS_PER_PGD)*PTRS_PER_PTE] 
__page_aligned_bss;
+pte_t kernel_pte_tables[PTRS_KERN_TABLE] __page_aligned_bss;
 
 EXPORT_SYMBOL(invalid_pte_table);
 unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]
@@ -149,6 +152,9 @@ void __init mmu_init(unsigned long min_pfn, unsigned long 
max_pfn)
swapper_pg_dir[i].pgd =
__pa(kernel_pte_tables + (PTRS_PER_PTE * (i - 
USER_PTRS_PER_PGD)));
 
+   for (i = 0; i < PTRS_KERN_TABLE; i++)
+   set_pte(&kernel_pte_tables[i], __pte(_PAGE_GLOBAL));
+
for (i = min_pfn; i < max_pfn; i++)
set_pte(&kernel_pte_tables[i - PFN_DOWN(va_pa_offset)], 
pfn_pte(i, PAGE_KERNEL));
 
-- 
2.17.1



[PATCH v2 4/6] touchscreen/wacom_i2c: Clean up the query device fields

2021-01-21 Thread Alistair Francis
Improve the query device fields to be more verbose.

Signed-off-by: Alistair Francis 
---
 drivers/input/touchscreen/wacom_i2c.c | 73 +++
 1 file changed, 52 insertions(+), 21 deletions(-)

diff --git a/drivers/input/touchscreen/wacom_i2c.c 
b/drivers/input/touchscreen/wacom_i2c.c
index 5f0b80d52ad5..a22570adc939 100644
--- a/drivers/input/touchscreen/wacom_i2c.c
+++ b/drivers/input/touchscreen/wacom_i2c.c
@@ -13,15 +13,32 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#define WACOM_CMD_QUERY0   0x04
-#define WACOM_CMD_QUERY1   0x00
-#define WACOM_CMD_QUERY2   0x33
-#define WACOM_CMD_QUERY3   0x02
-#define WACOM_CMD_THROW0   0x05
-#define WACOM_CMD_THROW1   0x00
+// Registers
+#define WACOM_COMMAND_LSB   0x04
+#define WACOM_COMMAND_MSB   0x00
+
+#define WACOM_DATA_LSB  0x05
+#define WACOM_DATA_MSB  0x00
+
+// Report types
+#define REPORT_FEATURE  0x30
+
+// Requests / operations
+#define OPCODE_GET_REPORT   0x02
+
+// Power settings
+#define POWER_ON0x00
+#define POWER_SLEEP 0x01
+
+// Input report ids
+#define WACOM_PEN_DATA_REPORT   2
+#define WACOM_SHINONOME_REPORT  26
+
+#define WACOM_QUERY_REPORT 3
 #define WACOM_QUERY_SIZE   22
 
 struct wacom_features {
@@ -45,34 +62,44 @@ struct wacom_i2c {
 };
 
 static int wacom_query_device(struct i2c_client *client,
- struct wacom_features *features)
+ struct wacom_features *features)
 {
int ret;
-   u8 cmd1[] = { WACOM_CMD_QUERY0, WACOM_CMD_QUERY1,
-   WACOM_CMD_QUERY2, WACOM_CMD_QUERY3 };
-   u8 cmd2[] = { WACOM_CMD_THROW0, WACOM_CMD_THROW1 };
u8 data[WACOM_QUERY_SIZE];
+   struct reset_control *rstc;
+
+   u8 get_query_data_cmd[] = {
+   WACOM_COMMAND_LSB,
+   WACOM_COMMAND_MSB,
+   REPORT_FEATURE | WACOM_QUERY_REPORT,
+   OPCODE_GET_REPORT,
+   WACOM_DATA_LSB,
+   WACOM_DATA_MSB,
+   };
+
struct i2c_msg msgs[] = {
+   // Request reading of feature ReportID: 3 (Pen Query Data)
{
.addr = client->addr,
.flags = 0,
-   .len = sizeof(cmd1),
-   .buf = cmd1,
-   },
-   {
-   .addr = client->addr,
-   .flags = 0,
-   .len = sizeof(cmd2),
-   .buf = cmd2,
+   .len = sizeof(get_query_data_cmd),
+   .buf = get_query_data_cmd,
},
+   // Read 21 bytes
{
.addr = client->addr,
.flags = I2C_M_RD,
-   .len = sizeof(data),
+   .len = WACOM_QUERY_SIZE - 1,
.buf = data,
},
};
 
+   rstc = devm_reset_control_get_optional_exclusive(&client->dev, NULL);
+   if (IS_ERR(rstc))
+   dev_err(&client->dev, "Failed to get reset control before 
init\n");
+   else
+   reset_control_reset(rstc);
+
ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
if (ret < 0)
return ret;
@@ -89,9 +116,13 @@ static int wacom_query_device(struct i2c_client *client,
features->tilt_y_max = get_unaligned_le16(&data[19]);
 
dev_dbg(&client->dev,
-   "x_max:%d, y_max:%d, pressure:%d, fw:%d\n",
+   "x_max:%d, y_max:%d, pressure:%d, fw:%d, "
+   "distance: %d, phys distance: %d, "
+   "tilt_x_max: %d, tilt_y_max: %d\n",
features->x_max, features->y_max,
-   features->pressure_max, features->fw_version);
+   features->pressure_max, features->fw_version,
+   features->distance_max, features->distance_physical_max,
+   features->tilt_x_max, features->tilt_y_max);
 
return 0;
 }
-- 
2.29.2



module loader dead code removal and cleanusp

2021-01-21 Thread Christoph Hellwig
Hi all,

this series removes support for long term unused export types and
cleans up various loose ends in the module loader.

Diffstat:
 arch/arm/configs/bcm2835_defconfig  |1 
 arch/arm/configs/mxs_defconfig  |1 
 arch/mips/configs/nlm_xlp_defconfig |1 
 arch/mips/configs/nlm_xlr_defconfig |1 
 arch/parisc/configs/generic-32bit_defconfig |1 
 arch/parisc/configs/generic-64bit_defconfig |1 
 arch/powerpc/configs/ppc6xx_defconfig   |1 
 arch/powerpc/platforms/powernv/pci-cxl.c|   22 -
 arch/s390/configs/debug_defconfig   |1 
 arch/s390/configs/defconfig |1 
 arch/sh/configs/edosk7760_defconfig |1 
 arch/sh/configs/sdk7780_defconfig   |1 
 arch/x86/configs/i386_defconfig |1 
 arch/x86/configs/x86_64_defconfig   |1 
 arch/x86/tools/relocs.c |4 
 drivers/gpu/drm/drm_crtc_helper_internal.h  |   10 
 drivers/gpu/drm/drm_fb_helper.c |   21 -
 drivers/gpu/drm/drm_kms_helper_common.c |   26 +-
 include/asm-generic/vmlinux.lds.h   |   42 ---
 include/linux/export.h  |9 
 include/linux/kallsyms.h|   17 -
 include/linux/module.h  |   42 ---
 init/Kconfig|   17 -
 kernel/kallsyms.c   |8 
 kernel/livepatch/core.c |   61 +
 kernel/module.c |  319 ++--
 kernel/trace/trace_kprobe.c |4 
 lib/bug.c   |3 
 scripts/checkpatch.pl   |6 
 scripts/mod/modpost.c   |   50 
 scripts/mod/modpost.h   |3 
 scripts/module.lds.S|6 
 tools/include/linux/export.h|3 
 33 files changed, 181 insertions(+), 505 deletions(-)


[PATCH] media: pwc: Fix the URB buffer allocation

2021-01-21 Thread Takashi Iwai
The URB buffer allocation of pwc driver involves with the
dma_map_single(), and it needs to pass the right device.  Currently it
passes usb_device.dev, but it's no real device that manages the DMA.
Since the passed device has no DMA mask set up, now the pwc driver
hits the WARN_ON_ONCE() check in dma_map_page_attrs() (that was
introduced in 5.10), resulting in an error at URB allocations.
Eventually this ended up with the black output.

This patch fixes the bug by passing the proper device, the bus
controller, to make the URB allocation and map working again.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1181133
Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/media/usb/pwc/pwc-if.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 61869636ec61..d771160bb168 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -461,7 +461,7 @@ static int pwc_isoc_init(struct pwc_device *pdev)
urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint);
urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
urb->transfer_buffer_length = ISO_BUFFER_SIZE;
-   urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev,
+   urb->transfer_buffer = 
pwc_alloc_urb_buffer(udev->bus->controller,

urb->transfer_buffer_length,
&urb->transfer_dma);
if (urb->transfer_buffer == NULL) {
@@ -524,7 +524,7 @@ static void pwc_iso_free(struct pwc_device *pdev)
if (urb) {
PWC_DEBUG_MEMORY("Freeing URB\n");
if (urb->transfer_buffer)
-   pwc_free_urb_buffer(&urb->dev->dev,
+   pwc_free_urb_buffer(urb->dev->bus->controller,
urb->transfer_buffer_length,
urb->transfer_buffer,
urb->transfer_dma);
-- 
2.26.2



Re: [PATCH] perf metricgroup: Fix system PMU metrics

2021-01-21 Thread Arnaldo Carvalho de Melo
Em Wed, Jan 20, 2021 at 09:15:54AM +, John Garry escreveu:
> On 20/01/2021 05:15, Joakim Zhang wrote:
> > For this patch: Tested-by: Joakim Zhang 

> > Hi John, Jolsa,

> > Is there any way to avoid breaking exist metric expressions? If not, it 
> > will always happened after metricgroup changes.
 
> They are not normally broken like that. Normally we test beforehand, but
> these cases were missed here by me. However if you were testing them
> previously, then it would be expected that you had tested them again for the
> final patchset which was merged.
 
> Anyway, we can look to add metric tests for these.
 
> @Arnaldo, I will send separate formal patch for this today.

Hi John, can you please take a look at my tmp.perf/urgent branch and see
if all is well, i.e. the versions of these patches are the ones that
should be merged and that all the patches discussed are there?

For your convenience:

https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=tmp.perf/urgent

Thanks,

- Arnaldo


Re: [PATCH] regulator: core: avoid regulator_resolve_supply() race condition

2021-01-21 Thread Marek Szyprowski
Hi Mark,

On 21.01.2021 16:44, Mark Brown wrote:
> On Thu, Jan 21, 2021 at 10:41:59AM +0100, Marek Szyprowski wrote:
>> On 18.01.2021 21:49, Mark Brown wrote:
>>> Does this help (completely untested):
>> Sadly nope. I get same warning:
> Try this instead:
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 3ae5ccd9277d..31503776dbd7 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1823,17 +1823,6 @@ static int regulator_resolve_supply(struct 
> regulator_dev *rdev)
>   if (rdev->supply)
>   return 0;
>   
> - /*
> -  * Recheck rdev->supply with rdev->mutex lock held to avoid a race
> -  * between rdev->supply null check and setting rdev->supply in
> -  * set_supply() from concurrent tasks.
> -  */
> - regulator_lock(rdev);
> -
> - /* Supply just resolved by a concurrent task? */
> - if (rdev->supply)
> - goto out;
> -
>   r = regulator_dev_lookup(dev, rdev->supply_name);
>   if (IS_ERR(r)) {
>   ret = PTR_ERR(r);
> @@ -1885,12 +1874,29 @@ static int regulator_resolve_supply(struct 
> regulator_dev *rdev)
>   goto out;
>   }
>   
> + /*
> +  * Recheck rdev->supply with rdev->mutex lock held to avoid a race
> +  * between rdev->supply null check and setting rdev->supply in
> +  * set_supply() from concurrent tasks.
> +  */
> + regulator_lock(rdev);
> +
> + /* Supply just resolved by a concurrent task? */
> + if (rdev->supply) {
> + regulator_unlock(rdev);
> + put_device(&r->dev);
> + return ret;
> + }
> +
>   ret = set_supply(rdev, r);
>   if (ret < 0) {
> + regulator_unlock(rdev);
>   put_device(&r->dev);
> - goto out;
> + return ret;
>   }
>   
> + regulator_unlock(rdev);
> +
>   /*
>* In set_machine_constraints() we may have turned this regulator on
>* but we couldn't propagate to the supply if it hadn't been resolved
> @@ -1901,12 +1907,11 @@ static int regulator_resolve_supply(struct 
> regulator_dev *rdev)
>   if (ret < 0) {
>   _regulator_put(rdev->supply);
>   rdev->supply = NULL;
> - goto out;
> + goto out_rdev_lock;

drivers/regulator/core.c:1910:4: error: label ‘out_rdev_lock’ used but 
not defined

>   }
>   }
>   
>   out:
> - regulator_unlock(rdev);
>   return ret;
>   }
>   

It looks that it finally fixes the locking issue, with the above goto 
removed completely to fix build. Feel free to add:

Reported-by: Marek Szyprowski 

Tested-by: Marek Szyprowski 

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



Re: [PATCH] diffconfig: use python3 instead of python in Shebang line

2021-01-21 Thread Andy Shevchenko
On Thu, Jan 21, 2021 at 10:28 PM Masahiro Yamada  wrote:
>
> On Fri, Jan 22, 2021 at 2:17 AM Scott Branden
>  wrote:
> >
> > Use python3 instead of python in diffconfig Shebang line.
> > python2 was sunset January 1, 2000 and environments do not need
> > to support python any more.

> Just from curiosity, what problem is this solving?
>
> Is there a distribution where 'python' does not exist,
> but 'python3' does ?

Yes. Called surprise surprise Debian
An it's a rare case when I agree with them.


-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH v3 00/12] OPP API fixes and improvements

2021-01-21 Thread Dmitry Osipenko
21.01.2021 10:51, Viresh Kumar пишет:
> On 20-01-21, 18:41, Dmitry Osipenko wrote:
>> 19.01.2021 20:35, Dmitry Osipenko пишет:
>>> 18.01.2021 14:46, Viresh Kumar пишет:
 On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Hi,
>
> This series fixes problems and adds features to OPP API that are required
> for implementation of a power domain driver for NVIDIA Tegra SoCs.
>
> It is a continuation of [1], where Viresh Kumar asked to factor OPP
> patches into a separate series. I factored out the patches into this
> series, addressed the previous review comments and re-based patches
> on top of [2], which replaced some of my patches that added 
> resource-managed
> helpers.
>
> [1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=221130
> [2] 
> https://lore.kernel.org/linux-pm/20210101165507.19486-1-tiny.win...@gmail.com/

 Hi Dmitry,

 I have applied 9 out of 12 patches already. Thanks.

>>>
>>> Thanks, I checked that everything is applied properly using today's
>>> linux-next.
>>>
>>
>> Turned out that one minor issue was actually introduced, the
>> devm_pm_opp_attach_genpd() lost the export. I'll make a patch to fix this.
> 
> I have fixed the original patch for that.
> 

Okay, thank you.


Re: [PATCH 04/24] kvm: x86/mmu: change TDP MMU yield function returns to match cond_resched

2021-01-21 Thread Paolo Bonzini

On 20/01/21 19:38, Sean Christopherson wrote:

Currently the TDP MMU yield / cond_resched functions either return
nothing or return true if the TLBs were not flushed. These are confusing
semantics, especially when making control flow decisions in calling
functions.

To clean things up, change both functions to have the same
return value semantics as cond_resched: true if the thread yielded,
false if it did not. If the function yielded in the_flush_  version,
then the TLBs will have been flushed.


My fault here.  The return value was meant to simplify the assignments 
below.  But it's clearer to return true if the cond_resched happened, 
indeed.




 
 		if (can_yield)

-   flush_needed = tdp_mmu_iter_flush_cond_resched(kvm, 
&iter);
+   flush_needed = !tdp_mmu_iter_flush_cond_resched(kvm,
+   &iter);


As with the existing code, I'd let this poke out.  Alternatively, this could be
written as:

flush_needed = !can_yield ||
   !tdp_mmu_iter_flush_cond_resched(kvm, &iter);



Yeah, no new line here.

Paolo



Re: [PATCH] rcu: Release per-cpu krcp page cache when CPU going offline

2021-01-21 Thread Uladzislau Rezki
Hello, Qiang,

> On Thu, Jan 21, 2021 at 02:49:49PM +0800, qiang.zh...@windriver.com wrote:
> > From: Zqiang 
> > 
> > If CPUs go offline, the corresponding krcp's page cache can
> > not be use util the CPU come back online, or maybe the CPU
> > will never go online again, this commit therefore free krcp's
> > page cache when CPUs go offline.
> > 
> > Signed-off-by: Zqiang 
> 
Do you consider it as an issue? We have 5 pages per CPU, that is 20480 bytes. 

--
Vlad Rezki


Re: [PATCH 07/13] opp: Allow _generic_set_opp_clk_only() to work for non-freq devices

2021-01-21 Thread Dmitry Osipenko
21.01.2021 14:17, Viresh Kumar пишет:
> In order to avoid conditional statements at the caller site, this patch
> updates _generic_set_opp_clk_only() to work for devices that don't
> change frequency (like power domains, etc.). Return 0 if the clk pointer
> passed to this routine is not valid.
> 
> Signed-off-by: Viresh Kumar 
> ---
...

Hello Viresh,

Thank you very much for yours effort! I gave a quick test to this series
and instantly found one small issue in this patch.

> + /* We may reach here for devices which don't change frequency */
> + if (unlikely(!clk))

I replaced dev_pm_opp_set_voltage() with dev_pm_opp_set_opp() in the
Tegra PD driver and got a crash, which happens because the above line
should be:

if (IS_ERR(clk))

The opp_table->clk is initialized to ERR_PTR(-ENOENT) if device doesn't
have a clock, like a power domain device in my case.

Everything works good after fixing this patch. I'll keep testing and
will be taking a closer look at the rest of the patches over this weekend.

For the record, here is a backtrace of the crash:

Unable to handle kernel NULL pointer dereference at virtual address 0016
...
(clk_set_rate) from (_set_opp)
(_set_opp) from (dev_pm_opp_set_opp)
(dev_pm_opp_set_opp) from (tegra_genpd_set_performance_state)
(tegra_genpd_set_performance_state) from (_genpd_set_performance_state)
(_genpd_set_performance_state) from (dev_pm_genpd_set_performance_state)
(dev_pm_genpd_set_performance_state) from (_set_required_opp)
(_set_required_opp) from (_set_opp)
(_set_opp) from (dev_pm_opp_set_rate)
(dev_pm_opp_set_rate) from (host1x_runtime_resume)
(host1x_runtime_resume) from (genpd_runtime_resume)
(genpd_runtime_resume) from (__rpm_callback)
(__rpm_callback) from (rpm_callback)
(rpm_callback) from (rpm_resume)
(rpm_resume) from (__pm_runtime_resume)
(__pm_runtime_resume) from (host1x_probe)
(host1x_probe) from (platform_probe)
(platform_probe) from (really_probe)
(really_probe) from (driver_probe_device)
(driver_probe_device) from (device_driver_attach)
(device_driver_attach) from (__driver_attach)
(__driver_attach) from (bus_for_each_dev)
(bus_for_each_dev) from (bus_add_driver)
(bus_add_driver) from (driver_register)
(driver_register) from (__platform_register_drivers)
(__platform_register_drivers) from (host1x_module_init)
(host1x_module_init) from (do_one_initcall)
(do_one_initcall) from (kernel_init_freeable)
(kernel_init_freeable) from (kernel_init)


Re: [PATCH v17 08/26] x86/mm: Introduce _PAGE_COW

2021-01-21 Thread Dave Hansen
> Usually, the compiler is better at making code efficient than humans.  I
> find that coding it in the most human-readable way is best unless I
> *know* the compiler is unable to generate god code.

"good code", even.

I really want a "god code" compiler, though. :)



Re: [PATCH] diffconfig: use python3 instead of python in Shebang line

2021-01-21 Thread Masahiro Yamada
On Fri, Jan 22, 2021 at 2:17 AM Scott Branden
 wrote:
>
> Use python3 instead of python in diffconfig Shebang line.
> python2 was sunset January 1, 2000 and environments do not need
> to support python any more.
>
> Fixes: b24413180f56 ("tweewide: Fix most Shebang lines")
> Signed-off-by: Scott Branden 
> ---
>  scripts/diffconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/diffconfig b/scripts/diffconfig
> index 627eba5849b5..d5da5fa05d1d 100755
> --- a/scripts/diffconfig
> +++ b/scripts/diffconfig
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python
> +#!/usr/bin/env python3
>  # SPDX-License-Identifier: GPL-2.0
>  #
>  # diffconfig - a tool to compare .config files.
> --
> 2.17.1
>

Just from curiosity, what problem is this solving?

Is there a distribution where 'python' does not exist,
but 'python3' does ?


-- 
Best Regards
Masahiro Yamada


Trying to get Sound Blaster Extigy to work under Kbuntu 20.10 kernel 5.8.0-38

2021-01-21 Thread Łukasz Czuja

Hi,

I don't know if its best place to ask for a little help in what I think 
are errors in linux audio driver, however I thought I ask for some 
assistance.


I found a very old Creative Sound Blaster Extigy device and connected it 
to my Acer Aspire e5-571g laptop. I was hopeful it would give me a 5.1 
surround sound from an USB 1.1 (full speed) connection which: pacmd 
list-cards command shows :


    index: 2
    name: 


    driver: <*module-alsa-card.c*>
    owner module: 32
    properties:
    alsa.card = "2"
    alsa.card_name = "Sound Blaster Extigy"
    alsa.long_card_name = "Creative Technology Ltd. Sound 
Blaster Extigy at usb-:00:14.0-3, *full speed*"

    alsa.driver_name = "*snd_usb_audio*"
    device.bus_path = "pci-:00:14.0-usb-0:3:1.0"
    sysfs.path = 
"/devices/pci:00/:00:14.0/usb2/2-3/2-3:1.0/sound/card2"
    udev.id = 
"usb-Creative_Technology_Ltd._Sound_Blaster_Extigy-00"

    device.bus = "usb"
    device.vendor.id = "041e"
    device.vendor.name = "Creative Technology, Ltd"
    device.product.id = "3000"
    device.product.name = "SoundBlaster Extigy"
    device.serial = 
"Creative_Technology_Ltd._Sound_Blaster_Extigy"

    device.string = "2"
    device.description = "SoundBlaster Extigy"
    module-udev-detect.discovered = "1"
    device.icon_name = "audio-card-usb"
    profiles:
    input:stereo-fallback: Wejście Stereo (priority 51, 
available: unknown)
    input:multichannel-input: Wejście Wielokanałowe 
(priority 1, available: unknown)
*output:analog-stereo*: Wyjście Analogowe stereo (priority 6500, 
available: unknown)
    output:analog-stereo+input:stereo-fallback: Wyjście 
Analogowe stereo + Wejście Stereo (priority 6551, available: unknown)
    output:analog-stereo+input:multichannel-input: Wyjście 
Analogowe stereo + Wejście Wielokanałowe (priority 6501, available: unknown)
    output:analog-surround-21: Wyjście Analogowe 
przestrzenne 2.1 (priority 1300, available: unknown)
    output:analog-surround-21+input:stereo-fallback: 
Wyjście Analogowe przestrzenne 2.1 + Wejście Stereo (priority 1351, 
available: unknown)
output:analog-surround-21+input:multichannel-input: Wyjście Analogowe 
przestrzenne 2.1 + Wejście Wielokanałowe (priority 1301, available: unknown)
    output:analog-surround-41: Wyjście Analogowe 
przestrzenne 4.1 (priority 1300, available: unknown)
    output:analog-surround-41+input:stereo-fallback: 
Wyjście Analogowe przestrzenne 4.1 + Wejście Stereo (priority 1351, 
available: unknown)
output:analog-surround-41+input:multichannel-input: Wyjście Analogowe 
przestrzenne 4.1 + Wejście Wielokanałowe (priority 1301, available: unknown)
    output:analog-surround-50: Wyjście Analogowe 
przestrzenne 5.0 (priority 1200, available: unknown)
    output:analog-surround-50+input:stereo-fallback: 
Wyjście Analogowe przestrzenne 5.0 + Wejście Stereo (priority 1251, 
available: unknown)
output:analog-surround-50+input:multichannel-input: Wyjście Analogowe 
przestrzenne 5.0 + Wejście Wielokanałowe (priority 1201, available: unknown)
*output:analog-surround-51*: Wyjście Analogowe przestrzenne 5.1 
(priority 1300, available: unknown)
    output:analog-surround-51+input:stereo-fallback: 
Wyjście Analogowe przestrzenne 5.1 + Wejście Stereo (priority 1351, 
available: unknown)
output:analog-surround-51+input:multichannel-input: Wyjście Analogowe 
przestrzenne 5.1 + Wejście Wielokanałowe (priority 1301, available: unknown)
*output:iec958-stereo*: Wyjście Cyfrowe stereo (IEC958) (priority 5500, 
available: unknown)
    output:iec958-stereo+input:stereo-fallback: Wyjście 
Cyfrowe stereo (IEC958) + Wejście Stereo (priority 5551, available: unknown)
    output:iec958-stereo+input:multichannel-input: Wyjście 
Cyfrowe stereo (IEC958) + Wejście Wielokanałowe (priority 5501, 
available: unknown)

    off: Wyłączone (priority 0, available: unknown)
    active profile: 
    sinks:
alsa_output.usb-Creative_Technology_Ltd._Sound_Blaster_Extigy-00.analog-stereo/#2: 
SoundBlaster Extigy Analogowe stereo

    sources:
alsa_output.usb-Creative_Technology_Ltd._Sound_Blaster_Extigy-00.analog-stereo.monitor/#6: 
Monitor of SoundBlaster Extigy Analogowe stereo
alsa_input.usb-Creative_Technology_Ltd._Sound_Blaster_Extigy-00.stereo-fallback/#7: 
SoundBlaster Extigy Stereo

    ports:
    analog-input-mic: Microphone (priority 8700, latency 
offset 0 usec, available: unknown)

    properties:
    device.icon_name = "audio-input-microphone"
    analog-input-linein: Line In (priority 8100, latency 
offset 0 usec, 

Re: [PATCH v2] perf script: Fix overrun issue for dynamically-allocated pmu type number

2021-01-21 Thread Arnaldo Carvalho de Melo
Em Wed, Jan 20, 2021 at 10:50:04PM +0100, Jiri Olsa escreveu:
> On Wed, Dec 09, 2020 at 08:58:28AM +0800, Jin Yao wrote:
> > After:
> >  swapper 0 [000] 1397040.402011: 272384   
> > cpu-clock:  9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> >  swapper 0 [000] 1397040.402011:   5396  
> > uncore_imc/data_reads/:
> >  swapper 0 [000] 1397040.402011:967 
> > uncore_imc/data_writes/:
> >  swapper 0 [000] 1397040.402259: 249153   
> > cpu-clock:  9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> >  swapper 0 [000] 1397040.402259:   7231  
> > uncore_imc/data_reads/:
> >  swapper 0 [000] 1397040.402259:   1297 
> > uncore_imc/data_writes/:
> >  swapper 0 [000] 1397040.402508: 249108   
> > cpu-clock:  9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> >  swapper 0 [000] 1397040.402508:   5333  
> > uncore_imc/data_reads/:
> >  swapper 0 [000] 1397040.402508:   1008 
> > uncore_imc/data_writes/:
> > 
> > Signed-off-by: Jin Yao 
> > ---
> > v2:
> >   Remove Fixes tag because this issue has always been here, not caused by
> >   1405720d4f26 ("perf script: Add 'synth' event type for synthesized 
> > events").
> >   No functional change in v2. 
> 
> Acked-by: Jiri Olsa 

Thanks, applied.

- Arnaldo


Re: [PATCH v17 08/26] x86/mm: Introduce _PAGE_COW

2021-01-21 Thread Dave Hansen
On 1/21/21 12:16 PM, Yu, Yu-cheng wrote:
> 
>>> @@ -343,6 +349,16 @@ static inline pte_t pte_mkold(pte_t pte)
>>>     static inline pte_t pte_wrprotect(pte_t pte)
>>>   {
>>> +    /*
>>> + * Blindly clearing _PAGE_RW might accidentally create
>>> + * a shadow stack PTE (RW=0, Dirty=1).  Move the hardware
>>> + * dirty value to the software bit.
>>> + */
>>> +    if (cpu_feature_enabled(X86_FEATURE_SHSTK)) {
>>> +    pte.pte |= (pte.pte & _PAGE_DIRTY) >> _PAGE_BIT_DIRTY <<
>>> _PAGE_BIT_COW;
>>
>> Why the unreadable shifting when you can simply do:
>>
>>  if (pte.pte & _PAGE_DIRTY)
>>  pte.pte |= _PAGE_COW;
>>
>> ?
> 
> It clears _PAGE_DIRTY and sets _PAGE_COW.  That is,
> 
> if (pte.pte & _PAGE_DIRTY) {
> pte.pte &= ~_PAGE_DIRTY;
> pte.pte |= _PAGE_COW;
> }
> 
> So, shifting makes resulting code more efficient.

Are you sure?

Usually, the compiler is better at making code efficient than humans.  I
find that coding it in the most human-readable way is best unless I
*know* the compiler is unable to generate god code.


[PATCH 01/13] powerpc/powernv: remove get_cxl_module

2021-01-21 Thread Christoph Hellwig
The static inline get_cxl_module function is entirely unused,
remove it.

Signed-off-by: Christoph Hellwig 
---
 arch/powerpc/platforms/powernv/pci-cxl.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-cxl.c 
b/arch/powerpc/platforms/powernv/pci-cxl.c
index 8c739c94ed28d6..53172862d23bd3 100644
--- a/arch/powerpc/platforms/powernv/pci-cxl.c
+++ b/arch/powerpc/platforms/powernv/pci-cxl.c
@@ -150,25 +150,3 @@ int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned 
int hwirq,
return 0;
 }
 EXPORT_SYMBOL(pnv_cxl_ioda_msi_setup);
-
-#if IS_MODULE(CONFIG_CXL)
-static inline int get_cxl_module(void)
-{
-   struct module *cxl_module;
-
-   mutex_lock(&module_mutex);
-
-   cxl_module = find_module("cxl");
-   if (cxl_module)
-   __module_get(cxl_module);
-
-   mutex_unlock(&module_mutex);
-
-   if (!cxl_module)
-   return -ENODEV;
-
-   return 0;
-}
-#else
-static inline int get_cxl_module(void) { return 0; }
-#endif
-- 
2.29.2



[PATCH 02/13] module: add a module_loaded helper

2021-01-21 Thread Christoph Hellwig
Add a helper that takes modules_mutex and uses find_module to check if a
given module is loaded.  This provides a better abstraction for the two
callers, and allows to unexport modules_mutex and find_module.

Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/drm_fb_helper.c |  7 +--
 include/linux/module.h  |  3 +++
 kernel/module.c | 14 --
 kernel/trace/trace_kprobe.c |  4 +---
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4b81195106875d..ce6d63ca75c32a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2508,13 +2508,8 @@ int __init drm_fb_helper_modinit(void)
 {
 #if defined(CONFIG_FRAMEBUFFER_CONSOLE_MODULE) && !defined(CONFIG_EXPERT)
const char name[] = "fbcon";
-   struct module *fbcon;
 
-   mutex_lock(&module_mutex);
-   fbcon = find_module(name);
-   mutex_unlock(&module_mutex);
-
-   if (!fbcon)
+   if (!module_loaded(name))
request_module_nowait(name);
 #endif
return 0;
diff --git a/include/linux/module.h b/include/linux/module.h
index 7a0bcb5b1ffccd..b4654f8a408134 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -589,6 +589,9 @@ static inline bool within_module(unsigned long addr, const 
struct module *mod)
 /* Search for module by name: must hold module_mutex. */
 struct module *find_module(const char *name);
 
+/* Check if a module is loaded. */
+bool module_loaded(const char *name);
+
 struct symsearch {
const struct kernel_symbol *start, *stop;
const s32 *crcs;
diff --git a/kernel/module.c b/kernel/module.c
index 4bf30e4b3eaaa1..619ea682e64cd1 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -88,7 +88,6 @@
  * (delete and add uses RCU list operations).
  */
 DEFINE_MUTEX(module_mutex);
-EXPORT_SYMBOL_GPL(module_mutex);
 static LIST_HEAD(modules);
 
 /* Work queue for freeing init sections in success case */
@@ -672,7 +671,18 @@ struct module *find_module(const char *name)
module_assert_mutex();
return find_module_all(name, strlen(name), false);
 }
-EXPORT_SYMBOL_GPL(find_module);
+
+bool module_loaded(const char *name)
+{
+   bool ret;
+
+   mutex_lock(&module_mutex);
+   ret = !!find_module(name);
+   mutex_unlock(&module_mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(module_loaded);
 
 #ifdef CONFIG_SMP
 
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index e6fba1798771b4..c2e453f88bce70 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -124,9 +124,7 @@ static nokprobe_inline bool 
trace_kprobe_module_exist(struct trace_kprobe *tk)
if (!p)
return true;
*p = '\0';
-   mutex_lock(&module_mutex);
-   ret = !!find_module(tk->symbol);
-   mutex_unlock(&module_mutex);
+   ret = module_loaded(tk->symbol);
*p = ':';
 
return ret;
-- 
2.29.2



Re: [PATCH v17 08/26] x86/mm: Introduce _PAGE_COW

2021-01-21 Thread Yu, Yu-cheng

On 1/21/2021 10:44 AM, Borislav Petkov wrote:

On Tue, Dec 29, 2020 at 01:30:35PM -0800, Yu-cheng Yu wrote:

[...]

@@ -343,6 +349,16 @@ static inline pte_t pte_mkold(pte_t pte)
  
  static inline pte_t pte_wrprotect(pte_t pte)

  {
+   /*
+* Blindly clearing _PAGE_RW might accidentally create
+* a shadow stack PTE (RW=0, Dirty=1).  Move the hardware
+* dirty value to the software bit.
+*/
+   if (cpu_feature_enabled(X86_FEATURE_SHSTK)) {
+   pte.pte |= (pte.pte & _PAGE_DIRTY) >> _PAGE_BIT_DIRTY << 
_PAGE_BIT_COW;


Why the unreadable shifting when you can simply do:

 if (pte.pte & _PAGE_DIRTY)
 pte.pte |= _PAGE_COW;

?


It clears _PAGE_DIRTY and sets _PAGE_COW.  That is,

if (pte.pte & _PAGE_DIRTY) {
pte.pte &= ~_PAGE_DIRTY;
pte.pte |= _PAGE_COW;
}

So, shifting makes resulting code more efficient.


@@ -434,16 +469,40 @@ static inline pmd_t pmd_mkold(pmd_t pmd)
  
  static inline pmd_t pmd_mkclean(pmd_t pmd)

  {
-   return pmd_clear_flags(pmd, _PAGE_DIRTY);
+   return pmd_clear_flags(pmd, _PAGE_DIRTY_BITS);
  }
  
  static inline pmd_t pmd_wrprotect(pmd_t pmd)

  {
+   /*
+* Blindly clearing _PAGE_RW might accidentally create
+* a shadow stack PMD (RW=0, Dirty=1).  Move the hardware
+* dirty value to the software bit.
+*/
+   if (cpu_feature_enabled(X86_FEATURE_SHSTK)) {
+   pmdval_t v = native_pmd_val(pmd);
+
+   v |= (v & _PAGE_DIRTY) >> _PAGE_BIT_DIRTY << _PAGE_BIT_COW;


As above.


@@ -488,17 +554,35 @@ static inline pud_t pud_mkold(pud_t pud)
  
  static inline pud_t pud_mkclean(pud_t pud)

  {
-   return pud_clear_flags(pud, _PAGE_DIRTY);
+   return pud_clear_flags(pud, _PAGE_DIRTY_BITS);
  }
  
  static inline pud_t pud_wrprotect(pud_t pud)

  {
+   /*
+* Blindly clearing _PAGE_RW might accidentally create
+* a shadow stack PUD (RW=0, Dirty=1).  Move the hardware
+* dirty value to the software bit.
+*/
+   if (cpu_feature_enabled(X86_FEATURE_SHSTK)) {
+   pudval_t v = native_pud_val(pud);
+
+   v |= (v & _PAGE_DIRTY) >> _PAGE_BIT_DIRTY << _PAGE_BIT_COW;


Ditto.


@@ -1131,6 +1222,12 @@ extern int pmdp_clear_flush_young(struct vm_area_struct 
*vma,
  #define pmd_write pmd_write
  static inline int pmd_write(pmd_t pmd)
  {
+   /*
+* If _PAGE_DIRTY is set, then the PMD must either have _PAGE_RW or
+* be a shadow stack PMD, which is logically writable.
+*/
+   if (cpu_feature_enabled(X86_FEATURE_SHSTK))
+   return pmd_flags(pmd) & (_PAGE_RW | _PAGE_DIRTY);


else



return pmd_flags(pmd) & _PAGE_RW;
  }
 


Re: [PATCH 15/24] kvm: mmu: Wrap mmu_lock cond_resched and needbreak

2021-01-21 Thread Paolo Bonzini

On 21/01/21 01:19, Sean Christopherson wrote:
IMO, moving the lock to arch-specific code is bad for KVM. The 
architectures' MMUs already diverge pretty horribly, and once things 
diverge it's really hard to go the other direction. And this change, 
along with all of the wrappers, thrash a lot of code and add a fair 
amount of indirection without any real benefit to the other 
architectures. What if we simply make the common mmu_lock a union? The 
rwlock_t is probably a bit bigger, but that's a few bytes for an entire 
VM. And maybe this would entice/inspire other architectures to move to a 
similar MMU model.
I agree.  Most architectures don't do the lockless tricks that x86 do, 
and being able to lock for read would be better than nothing.  For 
example, I took a look at ARM and stage2_update_leaf_attrs could be 
changed to operate in cmpxchg-like style while holding the rwlock for read.


Paolo



diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index f3b1013fb22c..bbc8efd4af62 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -451,7 +451,10 @@ struct kvm_memslots {
 };

 struct kvm {
-   spinlock_t mmu_lock;
+   union {
+   rwlock_t mmu_rwlock;
+   spinlock_t mmu_lock;
+   };
struct mutex slots_lock;
struct mm_struct *mm; /* userspace tied to this vm */
struct kvm_memslots __rcu *memslots[KVM_ADDRESS_SPACE_NUM];




Re: [PATCH net 1/4] net: dsa: mv88e6xxx: Remove bogus Kconfig dependency.

2021-01-21 Thread Brandon Streiff

On 1/20/2021 10:06 PM, Richard Cochran wrote:

The mv88e6xxx is a DSA driver, and it implements DSA style time
stamping of PTP frames.  It has no need of the expensive option to
enable PHY time stamping.  Remove the bogus dependency.

Signed-off-by: Richard Cochran 
Fixes: 2fa8d3af4bad ("net: dsa: mv88e6xxx: expose switch time as a PTP hardware 
clock")

Ah, I must have thought I needed skb_defer_rx_timestamp in mv88e6xxx,
but instead DSA gained its own timestamp path so mv88e6xxx turned out
to not need that at all, and I never went back and dropped the Kconfig
dependency. Whoops. Yup, I don't think we don't need it here.

Acked-by: Brandon Streiff 


Re: [PATCH] hugetlbfs: make hugepage size conversion more readable

2021-01-21 Thread Mike Kravetz
On 1/20/21 1:23 AM, Miaohe Lin wrote:
> The calculation 1U << (h->order + PAGE_SHIFT - 10) is actually equal to
> (PAGE_SHIFT << (h->order)) >> 10. So we can make it more readable by
> replace it with huge_page_size(h) / SZ_1K.
> 
> Signed-off-by: Miaohe Lin 
> ---
>  fs/hugetlbfs/inode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 25c1857ff45d..f94b8f6553fa 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -1519,8 +1519,8 @@ static struct vfsmount *__init 
> mount_one_hugetlbfs(struct hstate *h)
>   put_fs_context(fc);
>   }
>   if (IS_ERR(mnt))
> - pr_err("Cannot mount internal hugetlbfs for page size %uK",
> -1U << (h->order + PAGE_SHIFT - 10));
> + pr_err("Cannot mount internal hugetlbfs for page size %luK",
> +huge_page_size(h) / SZ_1K);

I appreciate the effort to make the code more readable.  The existing
calculation does take a minute to understand.  However, it is correct and
anyone modifying the code should be able to understand.

With my compiler, your proposed change adds an additional instruction to
the routine mount_one_hugetlbfs.  I know this is not significant, but still
it does increase the kernel size for a change that is of questionable value.

In the kernel, size in KB is often calculated as (size << (PAGE_SHIFT - 10)).
If you change the calculation in the hugetlb code to be:

huge_page_size(h) << (PAGE_SHIFT - 10)

my compiler will actually reduce the size of the routine by one instruction.
-- 
Mike Kravetz

>   return mnt;
>  }
>  
> 


Re: [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after unistd cleanup

2021-01-21 Thread Willy Tarreau
On Thu, Jan 21, 2021 at 11:54:32AM -0800, Paul E. McKenney wrote:
> > > It would be great if this could be applied soon so that it's possible to
> > > use the rcutorture scripts without applying local hacks.
> > 
> > Makes sense. I was wondering, should we mark them for stable ? I don't
> > know if anyone relies on these tests to validate stable kernels in
> > fact.
> 
> I added Fixes tags that should make this happen, and they are now visible
> at -rcu branch "dev".  Could you please check them for me?

I've just rerun all previous tests from my history and all of them are
OK. Please note however that I only did the manual build test, not through
the whole kvm.sh script, but a diff shows that the involved files are byte
for byte identical to those that Valentin and Mark tested, so for me that's
OK as well.

By the way, thank you for having completed the commit messages, I hope you
didn't spend too much time on this.

Cheers,
Willy


[net-next PATCH 1/7] octeontx2-af: forward error correction configuration

2021-01-21 Thread Hariprasad Kelam
From: Christina Jacob 

CGX block supports forward error correction modes baseR
and RS. This patch adds support to set encoding mode
and to read corrected/uncorrected block counters

Adds new mailbox handlers set_fec to configure encoding modes
and fec_stats to read counters and also increase mbox timeout
to accomdate firmware command response timeout.

Along with new CGX_CMD_SET_FEC command add other commands to
sync with kernel enum list with firmware.

Signed-off-by: Christina Jacob 
Signed-off-by: Sunil Goutham 
Signed-off-by: Hariprasad Kelam 
---
 drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 74 ++
 drivers/net/ethernet/marvell/octeontx2/af/cgx.h|  7 ++
 .../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h  | 17 -
 drivers/net/ethernet/marvell/octeontx2/af/mbox.h   | 22 ++-
 .../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 33 ++
 5 files changed, 151 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c 
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index 84a9123..5489dab 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -340,6 +340,58 @@ int cgx_get_tx_stats(void *cgxd, int lmac_id, int idx, u64 
*tx_stat)
return 0;
 }
 
+static int cgx_set_fec_stats_count(struct cgx_link_user_info *linfo)
+{
+   if (linfo->fec) {
+   switch (linfo->lmac_type_id) {
+   case LMAC_MODE_SGMII:
+   case LMAC_MODE_XAUI:
+   case LMAC_MODE_RXAUI:
+   case LMAC_MODE_QSGMII:
+   return 0;
+   case LMAC_MODE_10G_R:
+   case LMAC_MODE_25G_R:
+   case LMAC_MODE_100G_R:
+   case LMAC_MODE_USXGMII:
+   return 1;
+   case LMAC_MODE_40G_R:
+   return 4;
+   case LMAC_MODE_50G_R:
+   if (linfo->fec == OTX2_FEC_BASER)
+   return 2;
+   else
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp)
+{
+   int stats, fec_stats_count = 0;
+   int corr_reg, uncorr_reg;
+   struct cgx *cgx = cgxd;
+
+   if (!cgx || lmac_id >= cgx->lmac_count)
+   return -ENODEV;
+   fec_stats_count =
+   cgx_set_fec_stats_count(&cgx->lmac_idmap[lmac_id]->link_info);
+   if (cgx->lmac_idmap[lmac_id]->link_info.fec == OTX2_FEC_BASER) {
+   corr_reg = CGXX_SPUX_LNX_FEC_CORR_BLOCKS;
+   uncorr_reg = CGXX_SPUX_LNX_FEC_UNCORR_BLOCKS;
+   } else {
+   corr_reg = CGXX_SPUX_RSFEC_CORR;
+   uncorr_reg = CGXX_SPUX_RSFEC_UNCORR;
+   }
+   for (stats = 0; stats < fec_stats_count; stats++) {
+   rsp->fec_corr_blks +=
+   cgx_read(cgx, lmac_id, corr_reg + (stats * 8));
+   rsp->fec_uncorr_blks +=
+   cgx_read(cgx, lmac_id, uncorr_reg + (stats * 8));
+   }
+   return 0;
+}
+
 int cgx_lmac_rx_tx_enable(void *cgxd, int lmac_id, bool enable)
 {
struct cgx *cgx = cgxd;
@@ -615,6 +667,7 @@ static inline void link_status_user_format(u64 lstat,
linfo->link_up = FIELD_GET(RESP_LINKSTAT_UP, lstat);
linfo->full_duplex = FIELD_GET(RESP_LINKSTAT_FDUPLEX, lstat);
linfo->speed = cgx_speed_mbps[FIELD_GET(RESP_LINKSTAT_SPEED, lstat)];
+   linfo->fec = FIELD_GET(RESP_LINKSTAT_FEC, lstat);
linfo->lmac_type_id = cgx_get_lmac_type(cgx, lmac_id);
lmac_string = cgx_lmactype_string[linfo->lmac_type_id];
strncpy(linfo->lmac_type, lmac_string, LMACTYPE_STR_LEN - 1);
@@ -785,6 +838,27 @@ int cgx_get_fwdata_base(u64 *base)
return err;
 }
 
+int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
+{
+   u64 req = 0, resp;
+   struct cgx *cgx;
+   int err = 0;
+
+   cgx = cgx_get_pdata(cgx_id);
+   if (!cgx)
+   return -ENXIO;
+
+   req = FIELD_SET(CMDREG_ID, CGX_CMD_SET_FEC, req);
+   req = FIELD_SET(CMDSETFEC, fec, req);
+   err = cgx_fwi_cmd_generic(req, &resp, cgx, lmac_id);
+   if (!err) {
+   cgx->lmac_idmap[lmac_id]->link_info.fec =
+   FIELD_GET(RESP_LINKSTAT_FEC, resp);
+   return cgx->lmac_idmap[lmac_id]->link_info.fec;
+   }
+   return err;
+}
+
 static int cgx_fwi_link_change(struct cgx *cgx, int lmac_id, bool enable)
 {
u64 req = 0;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h 
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index bcfc3e5..1824e95 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -56,6 +56,11 @@
 #define CGXX_SCRATCH1_REG  0x1058
 #define CGX_CONST  0x2000
 #define CGXX_SPUX_C

Re: [PATCH] lightnvm: fix memory leak when submit fails

2021-01-21 Thread Matias Bjørling

On 21/01/2021 20.49, Heiner Litz wrote:

there are a couple more, but again I would understand if those are
deemed not important enough to keep it.

device emulation of (non-ZNS) SSD block device


That'll soon be available. We will be open-sourcing a new device mapper 
(dm-zap), which implements an indirection layer that enables ZNS SSDs to 
be exposed as a conventional block device.



die control: yes endurance groups would help but I am not aware of any
vendor supporting it
It is out there. Although, is this still important in 2021? OCSSD was 
made back in the days where media program/erase suspend wasn't commonly 
available and SSD controller were more simple. With today's media and 
SSD controllers, it is hard to compete without leaving media throughput 
on the table. If needed, splitting a drive into a few partitions should 
be sufficient for many many types of workloads.

finer-grained control: 1000's of open blocks vs. a handful of
concurrently open zones


It is dependent on the implementation - ZNS SSDs also supports 1000's of 
open zones.


Wrt to available OCSSD hardware - there isn't, to my knowledge, proper 
implementations available, where media reliability is taken into account.


Generally for the OCSSD hardware implementations, their UBER is 
extremely low, and as such RAID or similar schemes must be implemented 
on the host. pblk does not implement this, so at best, one should not 
store data if one wants to get it back at some point. It also makes for 
an unfair SSD comparison, as there is much more to an SSD than what 
OCSSD + pblk implements. At worst, it'll lead to false understanding of 
the challenges of making SSDs, and at best, work can be used as the 
foundation for doing an actual SSD implementation.



OOB area: helpful for L2P recovery


It is known as LBA metadata in NVMe. It is commonly available in many of 
today's SSD.


I understand your point that there is a lot of flexibility, but my 
counter point is that there isn't anything in OCSSD, that is not 
implementable or commonly available using today's NVMe concepts. 
Furthermore, the known OCSSD research platforms can easily be updated to 
expose the OCSSD characteristics through standardized NVMe concepts. 
That would probably make for a good research paper.





Re: [PATCH v1] trace: Fix race in trace_open and buffer resize call

2021-01-21 Thread Denis Efremov



On 1/21/21 10:09 PM, Steven Rostedt wrote:
> On Thu, 21 Jan 2021 17:30:40 +0300
> Denis Efremov  wrote:
> 
>> Hi,
>>
>> This patch (CVE-2020-27825) was tagged with
>> Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding 
>> synchronize_rcu for each CPU")
>>
>> I'm not an expert here but it seems like b23d7a5f4a07a only refactored
>> ring_buffer_reset_cpu() by introducing reset_disabled_cpu_buffer() without
>> significant changes. Hence, 
>> mutex_lock(&buffer->mutex)/mutex_unlock(&buffer->mutex)
>> can be backported further than b23d7a5f4a07a~ and to all LTS kernels. Is
>> b23d7a5f4a07a the actual cause of the bug?
>>
> 
> Ug, that looks to be a mistake. Looking back at the thread about this:
> 
>   
> https://lore.kernel.org/linux-arm-msm/20200915141304.41fa7...@gandalf.local.home/

I see from the link that it was planned to backport the patch to LTS kernels:

> Actually we are seeing issue in older kernel like 4.19/4.14/5.4 and there 
> below patch was not 
> present in stable branches:
> Commit b23d7a5f4a07 ("ring-buffer: speed up buffer resets by avoiding 
> synchronize_rcu for each CPU")

The point is that it's not backported yet. Maybe because of Fixes tag. I've 
discovered
this while trying to formalize CVE-2020-27825 bug in cvehound
https://github.com/evdenis/cvehound/blob/master/cvehound/cve/CVE-2020-27825.cocci

I think that the backport to the 4.4+ should be something like:

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 547a3a5ac57b..2171b377bbc1 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4295,6 +4295,8 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, 
int cpu)
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return;
 
+   mutex_lock(&buffer->mutex);
+
atomic_inc(&buffer->resize_disabled);
atomic_inc(&cpu_buffer->record_disabled);
 
@@ -4317,6 +4319,8 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, 
int cpu)
 
atomic_dec(&cpu_buffer->record_disabled);
atomic_dec(&buffer->resize_disabled);
+
+   mutex_unlock(&buffer->mutex);
 }
 EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
 

Thanks,
Denis







[net-next PATCH 4/7] octeontx2-af: Physical link configuration support

2021-01-21 Thread Hariprasad Kelam
From: Christina Jacob 

CGX LMAC, the physical interface support link configuration parameters
like speed, auto negotiation, duplex  etc. Firmware saves these into
memory region shared between firmware and this driver.

This patch adds mailbox handler set_link_mode, fw_data_get to
configure and read these parameters.

Signed-off-by: Christina Jacob 
Signed-off-by: Sunil Goutham 
Signed-off-by: Hariprasad Kelam 
---
 drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 60 +-
 drivers/net/ethernet/marvell/octeontx2/af/cgx.h|  2 +
 .../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h  | 18 ++-
 drivers/net/ethernet/marvell/octeontx2/af/mbox.h   | 21 
 .../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 19 +++
 5 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c 
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index b3ae84c..42ee67e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -658,6 +658,39 @@ static inline void cgx_link_usertable_init(void)
cgx_lmactype_string[LMAC_MODE_USXGMII] = "USXGMII";
 }
 
+static inline int cgx_link_usertable_index_map(int speed)
+{
+   switch (speed) {
+   case SPEED_10:
+   return CGX_LINK_10M;
+   case SPEED_100:
+   return CGX_LINK_100M;
+   case SPEED_1000:
+   return CGX_LINK_1G;
+   case SPEED_2500:
+   return CGX_LINK_2HG;
+   case SPEED_5000:
+   return CGX_LINK_5G;
+   case SPEED_1:
+   return CGX_LINK_10G;
+   case SPEED_2:
+   return CGX_LINK_20G;
+   case SPEED_25000:
+   return CGX_LINK_25G;
+   case SPEED_4:
+   return CGX_LINK_40G;
+   case SPEED_5:
+   return CGX_LINK_50G;
+   case 8:
+   return CGX_LINK_80G;
+   case SPEED_10:
+   return CGX_LINK_100G;
+   case SPEED_UNKNOWN:
+   return CGX_LINK_NONE;
+   }
+   return CGX_LINK_NONE;
+}
+
 static inline void link_status_user_format(u64 lstat,
   struct cgx_link_user_info *linfo,
   struct cgx *cgx, u8 lmac_id)
@@ -667,6 +700,7 @@ static inline void link_status_user_format(u64 lstat,
linfo->link_up = FIELD_GET(RESP_LINKSTAT_UP, lstat);
linfo->full_duplex = FIELD_GET(RESP_LINKSTAT_FDUPLEX, lstat);
linfo->speed = cgx_speed_mbps[FIELD_GET(RESP_LINKSTAT_SPEED, lstat)];
+   linfo->an = FIELD_GET(RESP_LINKSTAT_AN, lstat);
linfo->fec = FIELD_GET(RESP_LINKSTAT_FEC, lstat);
linfo->lmac_type_id = cgx_get_lmac_type(cgx, lmac_id);
lmac_string = cgx_lmactype_string[linfo->lmac_type_id];
@@ -695,6 +729,9 @@ static inline void cgx_link_change_handler(u64 lstat,
lmac->link_info = event.link_uinfo;
linfo = &lmac->link_info;
 
+   if (err_type == CGX_ERR_SPEED_CHANGE_INVALID)
+   return;
+
/* Ensure callback doesn't get unregistered until we finish it */
spin_lock(&lmac->event_cb_lock);
 
@@ -723,7 +760,8 @@ static inline bool cgx_cmdresp_is_linkevent(u64 event)
 
id = FIELD_GET(EVTREG_ID, event);
if (id == CGX_CMD_LINK_BRING_UP ||
-   id == CGX_CMD_LINK_BRING_DOWN)
+   id == CGX_CMD_LINK_BRING_DOWN ||
+   id == CGX_CMD_MODE_CHANGE)
return true;
else
return false;
@@ -838,6 +876,26 @@ int cgx_get_fwdata_base(u64 *base)
return err;
 }
 
+int cgx_set_link_mode(void *cgxd, struct cgx_set_link_mode_args args,
+ int cgx_id, int lmac_id)
+{
+   struct cgx *cgx = cgxd;
+   u64 req = 0, resp;
+   int err = 0;
+
+   if (!cgx)
+   return -ENODEV;
+
+   req = FIELD_SET(CMDREG_ID, CGX_CMD_MODE_CHANGE, req);
+   req = FIELD_SET(CMDMODECHANGE_SPEED,
+   cgx_link_usertable_index_map(args.speed), req);
+   req = FIELD_SET(CMDMODECHANGE_DUPLEX, args.duplex, req);
+   req = FIELD_SET(CMDMODECHANGE_AN, args.an, req);
+   req = FIELD_SET(CMDMODECHANGE_PORT, args.ports, req);
+   req = FIELD_SET(CMDMODECHANGE_FLAGS, args.flags, req);
+   err = cgx_fwi_cmd_generic(req, &resp, cgx, lmac_id);
+   return err;
+}
 int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
 {
u64 req = 0, resp;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h 
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index c5294b7..b458ad0 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -155,5 +155,7 @@ u8 cgx_lmac_get_p2x(int cgx_id, int lmac_id);
 int cgx_set_fec(u64 fec, int cgx_id, int lmac_id);
 int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp);
 int cgx_get_phy_fec_stats(void *cgxd, int lmac_id)

[PATCH v2 3/6] touchscreen/wacom_i2c: Add support for distance and tilt x/y

2021-01-21 Thread Alistair Francis
This is based on the out of tree rM2 driver.

Signed-off-by: Alistair Francis 
---
 drivers/input/touchscreen/wacom_i2c.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/wacom_i2c.c 
b/drivers/input/touchscreen/wacom_i2c.c
index ec6e0aff8deb..5f0b80d52ad5 100644
--- a/drivers/input/touchscreen/wacom_i2c.c
+++ b/drivers/input/touchscreen/wacom_i2c.c
@@ -22,12 +22,16 @@
 #define WACOM_CMD_QUERY3   0x02
 #define WACOM_CMD_THROW0   0x05
 #define WACOM_CMD_THROW1   0x00
-#define WACOM_QUERY_SIZE   19
+#define WACOM_QUERY_SIZE   22
 
 struct wacom_features {
int x_max;
int y_max;
int pressure_max;
+   int distance_max;
+   int distance_physical_max;
+   int tilt_x_max;
+   int tilt_y_max;
char fw_version;
 };
 
@@ -79,6 +83,10 @@ static int wacom_query_device(struct i2c_client *client,
features->y_max = get_unaligned_le16(&data[5]);
features->pressure_max = get_unaligned_le16(&data[11]);
features->fw_version = get_unaligned_le16(&data[13]);
+   features->distance_max = data[15];
+   features->distance_physical_max = data[16];
+   features->tilt_x_max = get_unaligned_le16(&data[17]);
+   features->tilt_y_max = get_unaligned_le16(&data[19]);
 
dev_dbg(&client->dev,
"x_max:%d, y_max:%d, pressure:%d, fw:%d\n",
@@ -95,6 +103,7 @@ static irqreturn_t wacom_i2c_irq(int irq, void *dev_id)
u8 *data = wac_i2c->data;
unsigned int x, y, pressure;
unsigned char tsw, f1, f2, ers;
+   short tilt_x, tilt_y, distance;
int error;
 
error = i2c_master_recv(wac_i2c->client,
@@ -109,6 +118,11 @@ static irqreturn_t wacom_i2c_irq(int irq, void *dev_id)
x = le16_to_cpup((__le16 *)&data[4]);
y = le16_to_cpup((__le16 *)&data[6]);
pressure = le16_to_cpup((__le16 *)&data[8]);
+   distance = data[10];
+
+   /* Signed */
+   tilt_x = le16_to_cpup((__le16 *)&data[11]);
+   tilt_y = le16_to_cpup((__le16 *)&data[13]);
 
if (!wac_i2c->prox)
wac_i2c->tool = (data[3] & 0x0c) ?
@@ -123,6 +137,9 @@ static irqreturn_t wacom_i2c_irq(int irq, void *dev_id)
input_report_abs(input, ABS_X, x);
input_report_abs(input, ABS_Y, y);
input_report_abs(input, ABS_PRESSURE, pressure);
+   input_report_abs(input, ABS_DISTANCE, distance);
+   input_report_abs(input, ABS_TILT_X, tilt_x);
+   input_report_abs(input, ABS_TILT_Y, tilt_y);
input_sync(input);
 
 out:
@@ -195,7 +212,11 @@ static int wacom_i2c_probe(struct i2c_client *client,
input_set_abs_params(input, ABS_Y, 0, features.y_max, 0, 0);
input_set_abs_params(input, ABS_PRESSURE,
 0, features.pressure_max, 0, 0);
-
+   input_set_abs_params(input, ABS_DISTANCE, 0, features.distance_max, 0, 
0);
+   input_set_abs_params(input, ABS_TILT_X, -features.tilt_x_max,
+features.tilt_x_max, 0, 0);
+   input_set_abs_params(input, ABS_TILT_Y, -features.tilt_y_max,
+features.tilt_y_max, 0, 0);
input_set_drvdata(input, wac_i2c);
 
error = request_threaded_irq(client->irq, NULL, wacom_i2c_irq,
-- 
2.29.2



[net-next PATCH 6/7] octeontx2-pf: ethtool physical link status

2021-01-21 Thread Hariprasad Kelam
From: Christina Jacob 

Register get_link_ksettings callback to get link status information
from the driver. As virtual function (vf) shares same physical link
same API is used for both the drivers and for loop back drivers
simply returns the fixed values as its does not have physical link.

ethtool eth3
Settings for eth3:
Supported ports: [ ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
1baseKR/Full
1000baseX/Full
Supports auto-negotiation: No
Supported FEC modes: BaseR RS
Advertised link modes:  Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: None

ethtool lbk0
Settings for lbk0:
Speed: 10Mb/s
Duplex: Full

Signed-off-by: Christina Jacob 
Signed-off-by: Sunil Goutham 
Signed-off-by: Hariprasad Kelam 
---
 .../ethernet/marvell/octeontx2/nic/otx2_ethtool.c  | 157 +
 1 file changed, 157 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c 
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index 9cec341..ef79ecf 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -32,6 +32,7 @@ struct otx2_stat {
.index = offsetof(struct otx2_dev_stats, stat) / sizeof(u64), \
 }
 
+#define OTX2_ETHTOOL_SUPPORTED_MODES 0x638CCBF //11000111000110011001011
 static const struct otx2_stat otx2_dev_stats[] = {
OTX2_DEV_STAT(rx_ucast_frames),
OTX2_DEV_STAT(rx_bcast_frames),
@@ -992,6 +993,147 @@ end:  mutex_unlock(&mbox->lock);
return err;
 }
 
+static void otx2_get_fec_info(u64 index, int mode, struct 
ethtool_link_ksettings
+ *link_ksettings)
+{
+   switch (index) {
+   case OTX2_FEC_NONE:
+   if (mode)
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_NONE);
+   else
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_NONE);
+   break;
+   case OTX2_FEC_BASER:
+   if (mode)
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_BASER);
+   else
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_BASER);
+   break;
+   case OTX2_FEC_RS:
+   if (mode)
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_RS);
+   else
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_RS);
+   break;
+   case OTX2_FEC_BASER | OTX2_FEC_RS:
+   if (mode) {
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_BASER);
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_RS);
+   } else {
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_BASER);
+   ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_RS);
+   }
+
+   break;
+   }
+}
+
+static void otx2_get_link_mode_info(u64 index, int mode,
+   struct ethtool_link_ksettings
+   *link_ksettings)
+{
+   u64 ethtool_link_mode = 0;
+   int bit_position = 0;
+   u64 link_modes = 0;
+
+   int cgx_link_mode[29] = {0,
+   

Re: [PATCH 2/2] Documentation: arm: marvell: Add link to public Armada 37xx Hardware Spec

2021-01-21 Thread Andrew Lunn
On Thu, Jan 21, 2021 at 08:34:18PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár 

Reviewed-by: Andrew Lunn 

Andrew


[PATCH 04/13] livepatch: move klp_find_object_module to module.c

2021-01-21 Thread Christoph Hellwig
To uncouple the livepatch code from module loader internals move a
slightly refactored version of klp_find_object_module to module.c
This allows to mark find_module static and removes one of the last
users of module_mutex outside of module.c.

Signed-off-by: Christoph Hellwig 
---
 include/linux/module.h  |  3 +--
 kernel/livepatch/core.c | 39 +--
 kernel/module.c | 17 -
 3 files changed, 30 insertions(+), 29 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index b4654f8a408134..8588482bde4116 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -586,8 +586,7 @@ static inline bool within_module(unsigned long addr, const 
struct module *mod)
return within_module_init(addr, mod) || within_module_core(addr, mod);
 }
 
-/* Search for module by name: must hold module_mutex. */
-struct module *find_module(const char *name);
+struct module *find_klp_module(const char *name);
 
 /* Check if a module is loaded. */
 bool module_loaded(const char *name);
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index a7f625dc24add3..878759baadd81c 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -49,30 +49,6 @@ static bool klp_is_module(struct klp_object *obj)
return obj->name;
 }
 
-/* sets obj->mod if object is not vmlinux and module is found */
-static void klp_find_object_module(struct klp_object *obj)
-{
-   struct module *mod;
-
-   mutex_lock(&module_mutex);
-   /*
-* We do not want to block removal of patched modules and therefore
-* we do not take a reference here. The patches are removed by
-* klp_module_going() instead.
-*/
-   mod = find_module(obj->name);
-   /*
-* Do not mess work of klp_module_coming() and klp_module_going().
-* Note that the patch might still be needed before klp_module_going()
-* is called. Module functions can be called even in the GOING state
-* until mod->exit() finishes. This is especially important for
-* patches that modify semantic of the functions.
-*/
-   if (mod && mod->klp_alive)
-   obj->mod = mod;
-   mutex_unlock(&module_mutex);
-}
-
 static bool klp_initialized(void)
 {
return !!klp_root_kobj;
@@ -820,14 +796,25 @@ static int klp_init_object(struct klp_patch *patch, 
struct klp_object *obj)
const char *name;
 
obj->patched = false;
-   obj->mod = NULL;
 
if (klp_is_module(obj)) {
if (strlen(obj->name) >= MODULE_NAME_LEN)
return -EINVAL;
name = obj->name;
 
-   klp_find_object_module(obj);
+   /*
+* We do not want to block removal of patched modules and
+* therefore we do not take a reference here. The patches are
+* removed by klp_module_going() instead.
+* 
+* Do not mess work of klp_module_coming() and
+* klp_module_going().  Note that the patch might still be
+* needed before klp_module_going() is called.  Module functions
+* can be called even in the GOING state until mod->exit()
+* finishes.  This is especially important for patches that
+* modify semantic of the functions.
+*/
+   obj->mod = find_klp_module(obj->name);
} else {
name = "vmlinux";
}
diff --git a/kernel/module.c b/kernel/module.c
index 619ea682e64cd1..299cbac0775cf2 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -666,7 +666,7 @@ static struct module *find_module_all(const char *name, 
size_t len,
return NULL;
 }
 
-struct module *find_module(const char *name)
+static struct module *find_module(const char *name)
 {
module_assert_mutex();
return find_module_all(name, strlen(name), false);
@@ -684,6 +684,21 @@ bool module_loaded(const char *name)
 }
 EXPORT_SYMBOL_GPL(module_loaded);
 
+#ifdef CONFIG_LIVEPATCH
+struct module *find_klp_module(const char *name)
+{
+   struct module *mod;
+
+   mutex_lock(&module_mutex);
+   mod = find_module(name);
+   if (mod && !mod->klp_alive)
+   mod = NULL;
+   mutex_unlock(&module_mutex);
+
+   return mod;
+}
+#endif /* CONFIG_LIVEPATCH */
+
 #ifdef CONFIG_SMP
 
 static inline void __percpu *mod_percpu(struct module *mod)
-- 
2.29.2



Re: [PATCH 1/2] Documentation: arm: Fix marvell file name

2021-01-21 Thread Andrew Lunn
On Thu, Jan 21, 2021 at 08:34:17PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár 

Fixes: dc7a12bdfccd ("docs: arm: convert docs to ReST and rename to *.rst")
Reviewed-by: Andrew Lunn 

Andrew


Re: [PATCH net-next 0/2] Add devlink health reporters for NIX block

2021-01-21 Thread patchwork-bot+netdevbpf
Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Tue, 19 Jan 2021 15:31:18 +0530 you wrote:
> Devlink health reporters are added for the NIX block.
> 
> Address Jakub's comment to add devlink support for error reporting.
> https://www.spinics.net/lists/netdev/msg670712.html
> 
> This series is in continuation to
> https://www.spinics.net/lists/netdev/msg707798.html
> 
> [...]

Here is the summary with links:
  - [net-next,1/2] octeontx2-af: Add devlink health reporters for NIX
https://git.kernel.org/netdev/net-next/c/5ed66306eab6
  - [net-next,2/2] docs: octeontx2: Add Documentation for NIX health reporters
https://git.kernel.org/netdev/net-next/c/d41b3365bda7

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




Re: [RFC][PATCH 00/25] Network fs helper library & fscache kiocb API

2021-01-21 Thread David Howells
J. Bruce Fields  wrote:

> > J. Bruce Fields  wrote:
> > 
> > > > Fixing this requires a much bigger overhaul of cachefiles than this 
> > > > patchset
> > > > performs.
> > > 
> > > That sounds like "sometimes you may get file corruption and there's
> > > nothing you can do about it".  But I know people actually use fscache,
> > > so it must be reliable at least for some use cases.
> > 
> > Yes.  That's true for the upstream code because that uses bmap.
> 
> Sorry, when you say "that's true", what part are you referring to?

Sometimes, theoretically, you may get file corruption due to this.

> > I'm switching
> > to use SEEK_HOLE/SEEK_DATA to get rid of the bmap usage, but it doesn't 
> > change
> > the issue.
> > 
> > > Is it that those "bridging" blocks only show up in certain corner cases
> > > that users can arrange to avoid?  Or that it's OK as long as you use
> > > certain specific file systems whose behavior goes beyond what's
> > > technically required by the bamp or seek interfaces?
> > 
> > That's a question for the xfs, ext4 and btrfs maintainers, and may vary
> > between kernel versions and fsck or filesystem packing utility versions.
> 
> So, I'm still confused: there must be some case where we know fscache
> actually works reliably and doesn't corrupt your data, right?

Using ext2/3, for example.  I don't know under what circumstances xfs, ext4
and btrfs might insert/remove blocks of zeros, but I'm told it can happen.

David



Re: [PATCH] ARM: brcmstb: Add debug UART entry for 72116

2021-01-21 Thread Florian Fainelli



On 1/20/2021 12:01 PM, Florian Fainelli wrote:
> 72116 has the same memory map as 7255 and the same physical address for
> the UART, alias the definition accordingly.
> 
> Signed-off-by: Florian Fainelli 

Applied to soc/next, thanks!
-- 
Florian


[PATCH 05/13] kallsyms: refactor {,module_}kallsyms_on_each_symbol

2021-01-21 Thread Christoph Hellwig
Require an explicit cll to module_kallsyms_on_each_symbol to look
for symbols in modules instead of the call from kallsyms_on_each_symbol,
and acquire module_mutex inside of module_kallsyms_on_each_symbol instead
of leaving that up to the caller.

Signed-off-by: Christoph Hellwig 
---
 kernel/kallsyms.c   | 6 +-
 kernel/livepatch/core.c | 6 +-
 kernel/module.c | 8 
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index fe9de067771c34..a0d3f0865916f9 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -177,6 +177,10 @@ unsigned long kallsyms_lookup_name(const char *name)
return module_kallsyms_lookup_name(name);
 }
 
+/*
+ * Iterate over all symbols in vmlinux.  For symbols from modules use
+ * module_kallsyms_on_each_symbol instead.
+ */
 int kallsyms_on_each_symbol(int (*fn)(void *, const char *, struct module *,
  unsigned long),
void *data)
@@ -192,7 +196,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, 
struct module *,
if (ret != 0)
return ret;
}
-   return module_kallsyms_on_each_symbol(fn, data);
+   return 0;
 }
 
 static unsigned long get_symbol_pos(unsigned long addr,
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 878759baadd81c..8063b9089bd2f8 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -135,12 +135,8 @@ static int klp_find_object_symbol(const char *objname, 
const char *name,
.pos = sympos,
};
 
-   mutex_lock(&module_mutex);
-   if (objname)
+   if (objname || !kallsyms_on_each_symbol(klp_find_callback, &args))
module_kallsyms_on_each_symbol(klp_find_callback, &args);
-   else
-   kallsyms_on_each_symbol(klp_find_callback, &args);
-   mutex_unlock(&module_mutex);
 
/*
 * Ensure an address was found. If sympos is 0, ensure symbol is unique;
diff --git a/kernel/module.c b/kernel/module.c
index 299cbac0775cf2..885feec64c1b6f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4407,8 +4407,7 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, 
const char *,
unsigned int i;
int ret;
 
-   module_assert_mutex();
-
+   mutex_lock(&module_mutex);
list_for_each_entry(mod, &modules, list) {
/* We hold module_mutex: no need for rcu_dereference_sched */
struct mod_kallsyms *kallsyms = mod->kallsyms;
@@ -4424,10 +4423,11 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, 
const char *,
ret = fn(data, kallsyms_symbol_name(kallsyms, i),
 mod, kallsyms_symbol_value(sym));
if (ret != 0)
-   return ret;
+   break;
}
}
-   return 0;
+   mutex_unlock(&module_mutex);
+   return ret;
 }
 #endif /* CONFIG_KALLSYMS */
 
-- 
2.29.2



Re: [PATCH] ACPI/IORT: Do not blindly trust DMA masks from firmware

2021-01-21 Thread Robin Murphy

On 2021-01-21 19:16, Moritz Fischer wrote:

Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.

iort_dma_setup() would query the root complex' IORT entry for a DMA
mask, and use that over the one the device has been configured with
earlier.

Ideally we want to use the minimum mask of what the IORT contains for
the root complex and what the device was configured with, but never 0.

Fixes: 5ac65e8c8941 ("ACPI/IORT: Support address size limit for root complexes")
Signed-off-by: Moritz Fischer 
---
Hi all,

not sure I'm doing this right, but I think the current behavior (while a
corner case) seems to also fail for 32 bit devices if the IORT specifies
64 bit. It works on my test system now with a 32 bit device.


I suppose it could go wrong if it's an old driver that doesn't 
explicitly set its own masks and assumes they will always be 32-bit. 
Technically we'd consider that the driver's fault these days, but 
there's a lot of legacy around still.



Open to suggestions for better solutions (and maybe the
nc_dma_get_range() should have the same sanity check?)


Honestly the more I come back to this, the more I think we should give 
up trying to be clever and just leave the default masks alone beyond the 
initial "is anything set up at all?" sanity checks. Setting the bus 
limit is what really matters these days, and should be sufficient to 
encode any genuine restriction. There's certainly no real need to widen 
the default masks above 32 bits just because firmware suggests so, since 
the driver should definitely be calling dma_set_mask() and friends later 
if it's >32-bit capable anyway.



Thanks,
Moritz

---
  drivers/acpi/arm64/iort.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index d4eac6d7e9fb..c48eabf8c121 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1126,6 +1126,11 @@ static int rc_dma_get_range(struct device *dev, u64 
*size)
  
  	rc = (struct acpi_iort_root_complex *)node->node_data;
  
+	if (!rc->memory_address_limit) {

+   dev_warn(dev, "Root complex has broken memory_address_limit\n");


Probably warrants a FW_BUG in there.


+   return -EINVAL;
+   }
+
*size = rc->memory_address_limit >= 64 ? U64_MAX :
1ULLbus_dma_limit = end;
-   dev->coherent_dma_mask = mask;
-   *dev->dma_mask = mask;
+   dev->bus_dma_limit = min_not_zero(dev->bus_dma_limit, end);


This doesn't need to change, since the default bus limit is 0 anyway 
(and that means "no limit").



+   dev->coherent_dma_mask = min_not_zero(dev->coherent_dma_mask, 
mask);
+   *dev->dma_mask = min_not_zero(*dev->dma_mask, mask);


AFAICS the only way an empty mask could get here now is from 
nc_dma_get_range(), so I'd rather see a consistent warning there than 
just silently start working around that too.


Of course IORT doesn't say these fields are optional (other than the 
lack of a root complex limit in older table versions), so we're giving 
bad firmware a pass to never be fixed, ho hum...


Thanks,
Robin.


}
  
  	*dma_addr = dmaaddr;




Re: [PATCH v2 2/5] hugetlb: convert page_huge_active() HPageMigratable flag

2021-01-21 Thread Oscar Salvador
On Wed, Jan 20, 2021 at 01:48:05PM -0800, Mike Kravetz wrote:
> >> This comment addresses both this patch and the next one.
> >>
> >> Instead of putting the SetHPageMigratable flag spread over the
> >> allocation paths, would it make more sense to place it in
> >> alloc_huge_page before returning the page?
> >> Then we could opencode SetHPageMigratableIfSupported right there.
> > 
> > and in putback_active_hugepage.
> 
> 
> Hi Oscar,
> 
> In Muchun's series of hugetlb bug fixes, Michal asked the same question.
> 
> https://lore.kernel.org/linux-mm/7e69a55c-d501-6b42-8225-a677f09fb...@oracle.com/
> 
> The 'short answer' is that the this would allow a page to be migrated
> after allocation but before the page fault code adds it to the page
> cache or page tables.  This actually caused bugs in the past.

Oh, I see. I jumped late into that patchset so I missed some early messages.
Thanks for explaining this again.

-- 
Oscar Salvador
SUSE L3


Re: linux-next: Tree for Jan 21 (mmc/host/sdhci-of-aspeed-test.c)

2021-01-21 Thread Randy Dunlap
On 1/20/21 11:28 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210120:
> 


Hi,
I suppose that I have some config combo that has not been tested.


on i386:
CONFIG_MMC_SDHCI_OF_ASPEED=m
CONFIG_MMC_SDHCI_OF_ASPEED_TEST=y

Full randconfig file is attached.


In file included from ../drivers/mmc/host/sdhci-of-aspeed.c:11:0:
../include/linux/module.h:132:42: error: redefinition of ‘__inittest’
  static inline initcall_t __maybe_unused __inittest(void)  \
  ^
../include/kunit/test.h:306:2: note: in expansion of macro ‘module_init’
  module_init(kunit_test_suites_init);\
  ^~~
../include/kunit/test.h:319:2: note: in expansion of macro 
‘kunit_test_suites_for_module’
  kunit_test_suites_for_module(unique_array);  \
  ^~~~
../include/kunit/test.h:342:2: note: in expansion of macro ‘__kunit_test_suites’
  __kunit_test_suites(__UNIQUE_ID(array),\
  ^~~
../include/kunit/test.h:346:33: note: in expansion of macro ‘kunit_test_suites’
 #define kunit_test_suite(suite) kunit_test_suites(&suite)
 ^
../drivers/mmc/host/sdhci-of-aspeed-test.c:98:1: note: in expansion of macro 
‘kunit_test_suite’
 kunit_test_suite(aspeed_sdhci_test_suite);
 ^~~~
../include/linux/module.h:132:42: note: previous definition of ‘__inittest’ was 
here
  static inline initcall_t __maybe_unused __inittest(void)  \
  ^
../drivers/mmc/host/sdhci-of-aspeed.c:573:1: note: in expansion of macro 
‘module_init’
 module_init(aspeed_sdc_init);
 ^~~
../include/linux/module.h:134:6: error: redefinition of ‘init_module’
  int init_module(void) __copy(initfn) __attribute__((alias(#initfn)));
  ^
../include/kunit/test.h:306:2: note: in expansion of macro ‘module_init’
  module_init(kunit_test_suites_init);\
  ^~~
../include/kunit/test.h:319:2: note: in expansion of macro 
‘kunit_test_suites_for_module’
  kunit_test_suites_for_module(unique_array);  \
  ^~~~
../include/kunit/test.h:342:2: note: in expansion of macro ‘__kunit_test_suites’
  __kunit_test_suites(__UNIQUE_ID(array),\
  ^~~
../include/kunit/test.h:346:33: note: in expansion of macro ‘kunit_test_suites’
 #define kunit_test_suite(suite) kunit_test_suites(&suite)
 ^
../drivers/mmc/host/sdhci-of-aspeed-test.c:98:1: note: in expansion of macro 
‘kunit_test_suite’
 kunit_test_suite(aspeed_sdhci_test_suite);
 ^~~~
../include/linux/module.h:134:6: note: previous definition of ‘init_module’ was 
here
  int init_module(void) __copy(initfn) __attribute__((alias(#initfn)));
  ^
../drivers/mmc/host/sdhci-of-aspeed.c:573:1: note: in expansion of macro 
‘module_init’
 module_init(aspeed_sdc_init);
 ^~~
../include/linux/module.h:138:42: error: redefinition of ‘__exittest’
  static inline exitcall_t __maybe_unused __exittest(void)  \
  ^
../include/kunit/test.h:312:2: note: in expansion of macro ‘module_exit’
  module_exit(kunit_test_suites_exit)
  ^~~
../include/kunit/test.h:319:2: note: in expansion of macro 
‘kunit_test_suites_for_module’
  kunit_test_suites_for_module(unique_array);  \
  ^~~~
../include/kunit/test.h:342:2: note: in expansion of macro ‘__kunit_test_suites’
  __kunit_test_suites(__UNIQUE_ID(array),\
  ^~~
../include/kunit/test.h:346:33: note: in expansion of macro ‘kunit_test_suites’
 #define kunit_test_suite(suite) kunit_test_suites(&suite)
 ^
../drivers/mmc/host/sdhci-of-aspeed-test.c:98:1: note: in expansion of macro 
‘kunit_test_suite’
 kunit_test_suite(aspeed_sdhci_test_suite);
 ^~~~
../include/linux/module.h:138:42: note: previous definition of ‘__exittest’ was 
here
  static inline exitcall_t __maybe_unused __exittest(void)  \
  ^
../drivers/mmc/host/sdhci-of-aspeed.c:580:1: note: in expansion of macro 
‘module_exit’
 module_exit(aspeed_sdc_exit);
 ^~~
../include/linux/module.h:140:7: error: redefinition of ‘cleanup_module’
  void cleanup_module(void) __copy(exitfn) __attribute__((alias(#exitfn)));
   ^
../include/kunit/test.h:312:2: note: in expansion of macro ‘module_exit’
  module_exit(kunit_test_suites_exit)
  ^~~
../include/kunit/test.h:319:2: note: in expansion of macro 
‘kunit_test_suites_for_module’
  kunit_test_suites_for_module(unique_array);  \
  ^~~~
../include/kunit/test.h:342:2: note: in expansion of macro ‘__kunit_test_suites’
  __kunit_test_suites(__UNIQUE_ID(array),\
  ^~~
../include/kunit/test.h:346:33: note: in expansion of macro ‘kunit_test_suites’
 #define kunit_test_suite(suite) kunit_test_suites(&suite)
 ^~

Re: [PATCH v7 0/6] Intel MAX10 BMC Secure Update Driver

2021-01-21 Thread Russ Weight



On 1/19/21 12:49 PM, Tom Rix wrote:
> On 1/5/21 3:08 PM, Russ Weight wrote:
>
> ...
>
>>  .../testing/sysfs-driver-intel-m10-bmc-secure |  61 ++
>>  MAINTAINERS   |   2 +
>>  drivers/fpga/Kconfig  |  11 +
>>  drivers/fpga/Makefile |   3 +
>>  drivers/fpga/intel-m10-bmc-secure.c   | 543 ++
>>  include/linux/mfd/intel-m10-bmc.h |  85 +++
> I am having trouble pulling this into my testing branch where i am tracking 
> some other changes to intel-m10-bmc.h
>
> https://lore.kernel.org/lkml/20210114231648.199685-1-russell.h.wei...@intel.com/
>
> https://lore.kernel.org/lkml/160628-12748-3-git-send-email-yilun...@intel.com/
>
> so I am wondering if it makes sense to split the intel-m10-bmc.h change out 
> of this patchset and sent as a single patch to mfd subsystem ?  The change is 
> a bunch of #defines that don't do anything on their own, but will conflict 
> with other similar additions to the h file.
If I rebase my working branch onto the latest linux-next, I don't see any 
issues. But if I apply the patches to the latest linux-next (git am), then I 
do. Clearly I need to fix up this patch and resend. If there are no objections, 
I'll split this patch out as an individual patch for the next submission.

- Russ
>
> Tom
>
>>  6 files changed, 705 insertions(+)
>>  create mode 100644 
>> Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure
>>  create mode 100644 drivers/fpga/intel-m10-bmc-secure.c
>>



Re: [PATCH] arch/Kconfig: update a broken file reference

2021-01-21 Thread Jonathan Corbet
On Tue, 19 Jan 2021 10:53:26 +0100
Lukas Bulwahn  wrote:

> Commit adab66b71abf ("Revert: "ring-buffer: Remove 
> HAVE_64BIT_ALIGNED_ACCESS"")
> added the config HAVE_64BIT_ALIGNED_ACCESS back into arch/Kconfig with this
> revert. In the meantime, commit c9b54d6f362c ("docs: move other kAPI
> documents to core-api") changed ./Documentation/unaligned-memory-access.txt
> to ./Documentation/core-api/unaligned-memory-access.rst.
> 
> Fortunately, ./scripts/documentation-file-ref-check detects this and warns
> about this broken reference.
> 
> Update the file reference in arch/Kconfig.
> 
> Fixes: adab66b71abf ("Revert: "ring-buffer: Remove 
> HAVE_64BIT_ALIGNED_ACCESS"")
> Signed-off-by: Lukas Bulwahn 
> ---
> applies cleanly on current master and next-20210118
> 
> Steven, could you pick this fix to your commit or, at least, ack it so that
> Jonathan can pick it?

I've gone ahead and applied it, thanks.

jon


Re: [PATCH] swap: Check nrexceptional of swap cache before being freed

2021-01-21 Thread Matthew Wilcox
On Wed, Jan 20, 2021 at 03:27:11PM +0800, Huang Ying wrote:
> To catch the error in updating the swap cache shadow entries or their count.

I just resent a patch that removes nrexceptional tracking.

Can you use !mapping_empty() instead?

>  void exit_swap_address_space(unsigned int type)
>  {
> - kvfree(swapper_spaces[type]);
> + int i;
> + struct address_space *spaces = swapper_spaces[type];
> +
> + for (i = 0; i < nr_swapper_spaces[type]; i++)
> + VM_BUG_ON(spaces[i].nrexceptional);
> + kvfree(spaces);
>   nr_swapper_spaces[type] = 0;
>   swapper_spaces[type] = NULL;
>  }
> -- 
> 2.29.2
> 
> 


RE: [PATCH] drm/ast: Update the sequence of Clearing Fast-reset

2021-01-21 Thread Kuo-Hsiang Chou
-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de] 
Sent: Thursday, January 21, 2021 3:56 PM
To: Kuo-Hsiang Chou ; 
dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/ast: Update the sequence of Clearing Fast-reset

Hi

Am 18.01.21 um 09:57 schrieb KuoHsiang Chou:
> [Bug][AST2500]
> If SCU00 is not unlocked, just enter its password again.
> It is unnecessary to clear AHB lock condition and restore WDT default 
> setting again, before Fast-reset clearing.
> 
> Signed-off-by: KuoHsiang Chou 

Is this a separate issue? This patch looks like a fix for the previous patch. 
[1] Can you add this change to v3 of the other patch?

Hi, 
Based on the result of driver released, this patch is a fix for previous one 
[1], so that I will merge this two patches into a single one as v3 of [1]. 
Thanks!

Regards,
Kuo-Hsiang Chou

Best regards
Thomas

[1]
https://lore.kernel.org/dri-devel/20210112075811.9354-1-kuohsiang_c...@aspeedtech.com/

> ---
>   drivers/gpu/drm/ast/ast_post.c | 5 +
>   1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_post.c 
> b/drivers/gpu/drm/ast/ast_post.c index 1f0007daa005..4f194c5fd2c2 
> 100644
> --- a/drivers/gpu/drm/ast/ast_post.c
> +++ b/drivers/gpu/drm/ast/ast_post.c
> @@ -2030,7 +2030,6 @@ void ast_patch_ahb_2500(struct ast_private *ast)
>   {
>   u32 data;
> 
> -patch_ahb_lock:
>   /* Clear bus lock condition */
>   ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
>   ast_moutdwm(ast, 0x1e600084, 0x0001); @@ -2044,11 +2043,9 @@ 
> void ast_patch_ahb_2500(struct ast_private *ast)
>   ast_moutdwm(ast, 0x1E78500c, 0x0033);
>   udelay(1000);
>   }
> - ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
>   do {
> + ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
>   data = ast_mindwm(ast, 0x1e6e2000);
> - if (data == 0x)
> - goto patch_ahb_lock;
>   }   while (data != 1);
>   ast_moutdwm(ast, 0x1e6e207c, 0x0800);   /* clear fast reset */
>   }
> --
> 2.18.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



[PATCH] selinux: measure state and policy capabilities

2021-01-21 Thread Lakshmi Ramasubramanian
SELinux stores the configuration state and the policy capabilities
in kernel memory.  Changes to this data at runtime would have an impact
on the security guarantees provided by SELinux.  Measuring SELinux
configuration state and policy capabilities through IMA subsystem
provides a tamper-resistant way for an attestation service to remotely
validate the runtime state.

Measure the configuration state and policy capabilities by calling
the IMA hook ima_measure_critical_data().

To enable SELinux data measurement, the following steps are required:

 1, Add "ima_policy=critical_data" to the kernel command line arguments
to enable measuring SELinux data at boot time.
For example,
  BOOT_IMAGE=/boot/vmlinuz-5.11.0-rc3+ 
root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux 
ima_policy=critical_data

 2, Add the following rule to /etc/ima/ima-policy
   measure func=CRITICAL_DATA label=selinux

Sample measurement of SELinux state and policy capabilities:

10 2122...65d8 ima-buf sha256:13c2...1292 selinux-state 696e...303b

To verify the measurement check the following:

Execute the following command to extract the measured data
from the IMA log for SELinux configuration (selinux-state).

  grep "selinux-state" 
/sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut 
-d' ' -f 6 | xxd -r -p

The output should be a list of key-value pairs. For example,
 
initialized=1;enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;

To verify the measured data with the current SELinux state:

 => enabled should be set to 1 if /sys/fs/selinux folder exists,
0 otherwise

For other entries, compare the integer value in the files
 => /sys/fs/selinux/enforce
 => /sys/fs/selinux/checkreqprot
And, each of the policy capabilities files under
 => /sys/fs/selinux/policy_capabilities

Note that the actual verification would be against an expected state
and done on a system other than the measured system, typically
requiring "initialized=1; enabled=1;enforcing=1;checkreqprot=0;" for
a secure state and then whatever policy capabilities are actually set
in the expected policy (which can be extracted from the policy itself
via seinfo, for example).

Signed-off-by: Lakshmi Ramasubramanian 
Suggested-by: Stephen Smalley 
---
This patch is based on
commit e58bb688f2e4 "Merge branch 'measure-critical-data' into next-integrity"
in "next-integrity-testing" branch

 security/selinux/hooks.c |  5 +++
 security/selinux/ima.c   | 68 
 security/selinux/selinuxfs.c | 10 ++
 3 files changed, 83 insertions(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 644b17ec9e63..879a0d90615d 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -103,6 +103,7 @@
 #include "netlabel.h"
 #include "audit.h"
 #include "avc_ss.h"
+#include "ima.h"
 
 struct selinux_state selinux_state;
 
@@ -7407,6 +7408,10 @@ int selinux_disable(struct selinux_state *state)
 
selinux_mark_disabled(state);
 
+   mutex_lock(&state->policy_mutex);
+   selinux_ima_measure_state(state);
+   mutex_unlock(&state->policy_mutex);
+
pr_info("SELinux:  Disabled at runtime.\n");
 
/*
diff --git a/security/selinux/ima.c b/security/selinux/ima.c
index 03715893ff97..e65d462d2d30 100644
--- a/security/selinux/ima.c
+++ b/security/selinux/ima.c
@@ -12,6 +12,60 @@
 #include "security.h"
 #include "ima.h"
 
+/*
+ * read_selinux_state - Read selinux configuration settings
+ *
+ * @state_str: Return the configuration settings.
+ * @state_str_len: Size of the configuration settings string
+ * @state: selinux_state
+ *
+ * Return 0 on success, error code on failure
+ */
+static int read_selinux_state(char **state_str, int *state_str_len,
+ struct selinux_state *state)
+{
+   char *buf;
+   int i, buf_len, curr;
+   bool initialized = selinux_initialized(state);
+   bool enabled = !selinux_disabled(state);
+   bool enforcing = enforcing_enabled(state);
+   bool checkreqprot = checkreqprot_get(state);
+
+   buf_len = snprintf(NULL, 0, "%s=%d;%s=%d;%s=%d;%s=%d;",
+  "initialized", initialized,
+  "enabled", enabled,
+  "enforcing", enforcing,
+  "checkreqprot", checkreqprot);
+
+   for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) {
+   buf_len += snprintf(NULL, 0, "%s=%d;",
+   selinux_policycap_names[i],
+   state->policycap[i]);
+   }
+   ++buf_len;
+
+   buf = kzalloc(buf_len, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   curr = scnprintf(buf, buf_len, "%s=%d;%s=%d;%s=%d;%s=%d;",
+"initialized", in

Re: [PATCH v6 1/2] fpga: dfl: add the userspace I/O device support for DFL devices

2021-01-21 Thread Moritz Fischer
Hi Tom,

On Thu, Jan 21, 2021 at 06:30:20AM -0800, Tom Rix wrote:
> 
> On 1/17/21 8:22 AM, Moritz Fischer wrote:
> > Greg,
> >
> > On Sun, Jan 17, 2021 at 04:45:04PM +0100, Greg KH wrote:
> >> On Wed, Jan 13, 2021 at 09:54:07AM +0800, Xu Yilun wrote:
> >>> This patch supports the DFL drivers be written in userspace. This is
> >>> realized by exposing the userspace I/O device interfaces.
> >>>
> >>> The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
> >>> platform device with the DFL device's resources, and let the generic UIO
> >>> platform device driver provide support to userspace access to kernel
> >>> interrupts and memory locations.
> >> Why doesn't the existing uio driver work for this, why do you need a new
> >> one?
> >>
> >>> ---
> >>>  drivers/fpga/Kconfig| 10 +
> >>>  drivers/fpga/Makefile   |  1 +
> >>>  drivers/fpga/dfl-uio-pdev.c | 93 
> >>> +
> >> uio drivers traditionally go in drivers/uio/ and start with "uio", so
> >> shouldn't this be drivers/uio/uio_dfl_pdev.c to match the same naming
> >> scheme?
> > I had considered suggesting that, but ultimately this driver only
> > creates a 'uio_pdrv_genirq' platform device, so it didn't seem like a
> > good fit.
> >> But again, you need to explain in detail, why the existing uio driver
> >> doesn't work properly, or why you can't just add a few lines to an
> >> existing one.
> > Ultimately there are three options I see:
> > 1) Do what Xu does, which is re-use the 'uio_pdrv_genirq' uio driver by
> >   creating a platform device for it as sub-device of the dfl device that
> >   we bind to uio_pdrv_genirq
> > 2) Add a module_dfl_driver part to drivers/uio/uio_pdrv_genirq.c and
> >   corresponding id table
> > 3) Create a new uio_dfl_genirq kind of driver that uses the dfl bus and
> >   that would make sense to then put into drivers/uio. (This would
> >   duplicate code in uio_pdrv_genirq to some extend)
> >
> > Overall I think in terms of code re-use I think Xu's choice might be
> > less new code as it simply wraps the uio platform device driver, and
> > allows for defining the resources passed to the UIO driver to be defined
> > by hardware through a DFL.
> >
> > I've seen the pattern that Xu proposed used in other places like the
> > macb network driver where you'd have macb_main (the platform driver) and
> > macb_pci that wraps it for a pci usage.
> >
> > - Moritz
> 
> Thinking of this problem more generally.
> 
> Every fpga will have a handful of sub devices.
> 
> Do we want to carry them in the fpga subsystem or carry them in the other 
> subsystems ?

Yeah no we really don't. I think that was the point of the whole DFL
bus :)
> 
> Consider the short term reviewing and long term maintenance of the sub 
> devices by the subsystem maintainers.
> 
> It easier for them if the sub devices are in the other subsystems.

Agreed.
> 
> 
> Applying this to specifically for dfl_uio.
> 
> No one from the uio subsystem reviewing this change is a problem.

Greg will.
> I think this change needs to go to the uio subsystem.

Yeah I've thought about this some for the last few days, maybe it's
easier that way.

Tbh, there's so little code here even if we went with option 3 above
it's probably fairly short. It would set a better prcedent.

Xu, how do you feel about giving that a spin? See if option 3 will be
way more code.

- Moritz



[PATCH v5 3/7] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property

2021-01-21 Thread AngeloGioacchino Del Regno
From: Manivannan Sadhasivam 

Add devicetree documentation for 'qcom,freq-domain' property specific
to Qualcomm CPUs. This property is used to reference the CPUFREQ node
along with Domain ID (0/1).

Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: AngeloGioacchino Del Regno 

---
 Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml 
b/Documentation/devicetree/bindings/arm/cpus.yaml
index 14cd727d3c4b..1d60975df23a 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -290,6 +290,12 @@ properties:
 
   * arm/msm/qcom,kpss-acc.txt
 
+  qcom,freq-domain:
+$ref: '/schemas/types.yaml#/definitions/phandle-array'
+description: |
+  CPUs supporting freq-domain must set their "qcom,freq-domain" property
+  with phandle to a cpufreq_hw node followed by the Domain ID(0/1).
+
   rockchip,pmu:
 $ref: '/schemas/types.yaml#/definitions/phandle'
 description: |
-- 
2.30.0



Re: [PATCH] perf metricgroup: Fix for metrics containing duration_time

2021-01-21 Thread Arnaldo Carvalho de Melo
Em Wed, Jan 20, 2021 at 10:35:35PM +0100, Jiri Olsa escreveu:
> On Thu, Jan 21, 2021 at 12:18:38AM +0800, John Garry wrote:
> > Metrics containing duration_time cause a segfault:
> > 
> > $./perf stat -v -M L1D_Cache_Fill_BW sleep 1
> > Using CPUID GenuineIntel-6-3D-4
> > metric expr 64 * l1d.replacement / 10 / duration_time for 
> > L1D_Cache_Fill_BW
> > found event duration_time
> > found event l1d.replacement
> > adding {l1d.replacement}:W,duration_time
> > l1d.replacement -> cpu/umask=0x1,(null)=0x1e8483,event=0x51/
> > Segmentation fault
> > 
> > In commit c2337d67199a ("perf metricgroup: Fix metrics using aliases
> > covering multiple PMUs"), the logic in find_evsel_group() when iter'ing
> > events was changed to not only select events in same group, but also for
> > aliased PMUs.
> > 
> > Checking whether events were for aliased PMUs was done by comparing the
> > event PMU name. This was not safe for duration_time event, which has no
> > associated PMU (and no PMU name), so fix by checking if the event PMU name
> > is set also.
> > 
> > Fixes: c2337d67199a ("perf metricgroup: Fix metrics using aliases covering 
> > multiple PMUs")
> > Reported-by: Joakim Zhang 
> > Signed-off-by: John Garry 
> 
> Tested/Acked-by: Jiri Olsa 

Thanks, applied.

- Arnaldo

 
> thanks,
> jirka
> 
> > 
> > diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> > index 2e60ee170abc..e6d3452031e5 100644
> > --- a/tools/perf/util/metricgroup.c
> > +++ b/tools/perf/util/metricgroup.c
> > @@ -162,6 +162,14 @@ static bool contains_event(struct evsel 
> > **metric_events, int num_events,
> > return false;
> >  }
> >  
> > +static bool evsel_same_pmu(struct evsel *ev1, struct evsel *ev2)
> > +{
> > +   if (!ev1->pmu_name || !ev2->pmu_name)
> > +   return false;
> > +
> > +   return !strcmp(ev1->pmu_name, ev2->pmu_name);
> > +}
> > +
> >  /**
> >   * Find a group of events in perf_evlist that correspond to those from a 
> > parsed
> >   * metric expression. Note, as find_evsel_group is called in the same 
> > order as
> > @@ -280,8 +288,7 @@ static struct evsel *find_evsel_group(struct evlist 
> > *perf_evlist,
> >  */
> > if (!has_constraint &&
> > ev->leader != metric_events[i]->leader &&
> > -   !strcmp(ev->leader->pmu_name,
> > -   metric_events[i]->leader->pmu_name))
> > +   evsel_same_pmu(ev->leader, 
> > metric_events[i]->leader))
> > break;
> > if (!strcmp(metric_events[i]->name, ev->name)) {
> > set_bit(ev->idx, evlist_used);
> > -- 
> > 2.26.2
> > 
> 

-- 

- Arnaldo


[PATCH v5 0/7] cpufreq-qcom-hw: Implement full OSM programming

2021-01-21 Thread AngeloGioacchino Del Regno
  **
  ** NOTE: To "view the full picture", please look at the following
  ** patch series:
  ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355
  **  This is a subset of that series.
  **

Changes in v5:
- Fixed OPP table API abuse, in conjunction with the CPR3 driver
- Some minor cleanups

Changes in v4:
- Huge patch series has been split for better reviewability,
  as suggested by Bjorn
- Rebased code on top of 266991721c15 ("cpufreq: qcom-hw: enable boost
  support")

Changes in v3:
- Fixed a test robot build failure for ARCH=arm
- Fixed dt_binding_check YAML doc issues

Changes in v2:
- Rebased dt-binding on top of Manivannan's patches
- Added MSM8998 to cpufreq-dt-platdev blacklist
- Implemented dynamic Memory Accelerator corners support, needed
  by MSM8998
- Implemented ACD programming, needed by MSM8998

Tested on the following smartphones:
- Sony Xperia XA2(SDM630)
- Sony Xperia XA2 Ultra  (SDM630)
- Sony Xperia 10 (SDM630)
- Sony Xperia XZ Premium (MSM8998)
- F(x)Tec Pro 1  (MSM8998)

>From SDM845 onwards, SAW, CPRh and OSM are getting setup by the
bootloader/TZ *before* booting the OS, so then all the OS has to do
is to request a specific performance state to the OSM hardware and
forget about all the rest, which is anyway protected by the hypervisor
(so there's no access anyway);

BUT:

In MSM/APQ 8998, SDM/SDA 630/636/660 (and other variants), there is no
setup of any of these puzzle pieces, and they're also (basically) fully
accessible, which means that the OS must do it in order to get in the
same state as the newer ones and to get the entire scaling hardware to
start rolling.

AngeloGioacchino Del Regno (5):
  cpufreq: blacklist SDM630/636/660 in cpufreq-dt-platdev
  cpufreq: blacklist MSM8998 in cpufreq-dt-platdev
  cpufreq: qcom-hw: Implement CPRh aware OSM programming
  cpufreq: qcom-hw: Allow getting the maximum transition latency for
OPPs
  dt-bindings: cpufreq: qcom-hw: Add bindings for 8998

Manivannan Sadhasivam (2):
  dt-bindings: arm: cpus: Document 'qcom,freq-domain' property
  dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings

 .../devicetree/bindings/arm/cpus.yaml |6 +
 .../bindings/cpufreq/cpufreq-qcom-hw.txt  |  172 ---
 .../bindings/cpufreq/cpufreq-qcom-hw.yaml |  242 
 drivers/cpufreq/cpufreq-dt-platdev.c  |4 +
 drivers/cpufreq/qcom-cpufreq-hw.c | 1251 -
 5 files changed, 1471 insertions(+), 204 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml

-- 
2.30.0



Re: [GIT PULL] printk regression fixes for 5.11-rc5

2021-01-21 Thread pr-tracker-bot
The pull request you sent on Thu, 21 Jan 2021 17:04:01 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git 
> tags/printk-for-5.11-printk-rework-fixup

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2561bbbe2e959c966e21ee23de91b9bd4bbf98af

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


Re: [GIT PULL] gpio: fixes for v5.11-rc5

2021-01-21 Thread pr-tracker-bot
The pull request you sent on Thu, 21 Jan 2021 10:52:46 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git 
> tags/gpio-fixes-for-v5.11-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d7631e4378f26c8e1ba1ad372888e89e69678709

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


[PATCH] x86/apic/x2apic: Fix parallel handling of cluster_mask

2021-01-21 Thread David Woodhouse
From: David Woodhouse 

For each CPU being brought up, the alloc_clustermask() function
allocates a new struct cluster_mask just in case it's needed. Then the
target CPU actually runs, and in init_x2apic_ldr() it either uses a
cluster_mask from a previous CPU in the same cluster, or consumes the
"spare" one and sets the global pointer to NULL.

That isn't going to parallelise stunningly well.

Ditch the global variable, let alloc_clustermask() install the struct
*directly* in the per_cpu data for the CPU being brought up. As an
optimisation, actually make it do so for *all* present CPUs in the same
cluster, which means only one iteration over for_each_present_cpu()
instead of doing so repeatedly, once for each CPU.

This was a harmless "bug" while CPU bringup wasn't actually happening in
parallel. It's about to become less harmless...

Fixes: 023a611748fd5 ("x86/apic/x2apic: Simplify cluster management")
Signed-off-by: David Woodhouse 
---
 arch/x86/kernel/apic/x2apic_cluster.c | 82 ---
 1 file changed, 49 insertions(+), 33 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_cluster.c 
b/arch/x86/kernel/apic/x2apic_cluster.c
index b0889c48a2ac..ee5a9a438780 100644
--- a/arch/x86/kernel/apic/x2apic_cluster.c
+++ b/arch/x86/kernel/apic/x2apic_cluster.c
@@ -18,7 +18,6 @@ struct cluster_mask {
 static DEFINE_PER_CPU(u32, x86_cpu_to_logical_apicid);
 static DEFINE_PER_CPU(cpumask_var_t, ipi_mask);
 static DEFINE_PER_CPU(struct cluster_mask *, cluster_masks);
-static struct cluster_mask *cluster_hotplug_mask;
 
 static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
 {
@@ -98,54 +97,71 @@ static u32 x2apic_calc_apicid(unsigned int cpu)
 static void init_x2apic_ldr(void)
 {
struct cluster_mask *cmsk = this_cpu_read(cluster_masks);
-   u32 cluster, apicid = apic_read(APIC_LDR);
-   unsigned int cpu;
 
-   this_cpu_write(x86_cpu_to_logical_apicid, apicid);
+   BUG_ON(!cmsk);
 
-   if (cmsk)
-   goto update;
-
-   cluster = apicid >> 16;
-   for_each_online_cpu(cpu) {
-   cmsk = per_cpu(cluster_masks, cpu);
-   /* Matching cluster found. Link and update it. */
-   if (cmsk && cmsk->clusterid == cluster)
-   goto update;
-   }
-   cmsk = cluster_hotplug_mask;
-   cmsk->clusterid = cluster;
-   cluster_hotplug_mask = NULL;
-update:
-   this_cpu_write(cluster_masks, cmsk);
cpumask_set_cpu(smp_processor_id(), &cmsk->mask);
 }
 
-static int alloc_clustermask(unsigned int cpu, int node)
+static int alloc_clustermask(unsigned int cpu, u32 cluster, int node)
 {
+   struct cluster_mask *cmsk = NULL;
+   unsigned int cpu_i;
+   u32 apicid;
+
if (per_cpu(cluster_masks, cpu))
return 0;
-   /*
-* If a hotplug spare mask exists, check whether it's on the right
-* node. If not, free it and allocate a new one.
+
+   /* For the hotplug case, don't always allocate a new one */
+   for_each_present_cpu(cpu_i) {
+   apicid = apic->cpu_present_to_apicid(cpu_i);
+   if (apicid != BAD_APICID && apicid >> 4 == cluster) {
+   cmsk = per_cpu(cluster_masks, cpu_i);
+   if (cmsk)
+   break;
+   }
+   }
+   if (!cmsk) {
+   cmsk = kzalloc_node(sizeof(*cmsk), GFP_KERNEL, node);
+   }
+   if (!cmsk)
+   return -ENOMEM;
+
+   cmsk->node = node;
+   cmsk->clusterid = cluster;
+
+   per_cpu(cluster_masks, cpu) = cmsk;
+
+/*
+* As an optimisation during boot, set the cluster_mask for *all*
+* present CPUs at once, to prevent *each* of them having to iterate
+* over the others to find the existing cluster_mask.
 */
-   if (cluster_hotplug_mask) {
-   if (cluster_hotplug_mask->node == node)
-   return 0;
-   kfree(cluster_hotplug_mask);
+   if (system_state < SYSTEM_RUNNING) {
+   for_each_present_cpu(cpu) {
+   u32 apicid = apic->cpu_present_to_apicid(cpu);
+   if (apicid != BAD_APICID && apicid >> 4 == cluster) {
+   struct cluster_mask **cpu_cmsk = 
&per_cpu(cluster_masks, cpu);
+   if (*cpu_cmsk)
+   BUG_ON(*cpu_cmsk != cmsk);
+   else
+   *cpu_cmsk = cmsk;
+   }
+   }
}
 
-   cluster_hotplug_mask = kzalloc_node(sizeof(*cluster_hotplug_mask),
-   GFP_KERNEL, node);
-   if (!cluster_hotplug_mask)
-   return -ENOMEM;
-   cluster_hotplug_mask->node = node;
return 0;
 }
 
 static int x2apic_prepare_cpu(unsigned int cpu)
 {
-   if (alloc_clustermask(cpu, cp

Re: [PATCH] xfs: set inode size after creating symlink

2021-01-21 Thread Brian Foster
On Thu, Jan 21, 2021 at 09:19:12AM -0600, Jeffrey Mitchell wrote:
> When XFS creates a new symlink, it writes its size to disk but not to the
> VFS inode. This causes i_size_read() to return 0 for that symlink until
> it is re-read from disk, for example when the system is rebooted.
> 
> I found this inconsistency while protecting directories with eCryptFS.
> The command "stat path/to/symlink/in/ecryptfs" will report "Size: 0" if
> the symlink was created after the last reboot on an XFS root.
> 
> Call i_size_write() in xfs_symlink()
> 
> Signed-off-by: Jeffrey Mitchell 
> ---

Reviewed-by: Brian Foster 

>  fs/xfs/xfs_symlink.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
> index 1f43fd7f3209..c835827ae389 100644
> --- a/fs/xfs/xfs_symlink.c
> +++ b/fs/xfs/xfs_symlink.c
> @@ -300,6 +300,7 @@ xfs_symlink(
>   }
>   ASSERT(pathlen == 0);
>   }
> + i_size_write(VFS_I(ip), ip->i_d.di_size);
>  
>   /*
>* Create the directory entry for the symlink.
> -- 
> 2.25.1
> 



Re: [PATCH v2] ARM: dts: sun7i: a20: bananapro: Fix ethernet node

2021-01-21 Thread Jernej Škrabec
Dne četrtek, 21. januar 2021 ob 18:08:36 CET je Hermann Lauer napisal(a):
> BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high
> packet loss rates. The realtek phy driver overrides the settings of the
> pull ups for the delays, so fix this for Banana Pro.
> 
> Signed-off-by: Hermann Lauer 

Much better. Now the only thing missing is "Fixes" tag, which references 
commit which introduced the issue. Probably this will be the commit which 
added ethernet node. This tag is important for deciding which commits should 
be backported to stable releases. Take a look in v1 for M2U fixes tag.

Btw, each version should have changelog under "---" line, so maintainers and 
reviewers know what changed.

Best regards,
Jernej




Re: [PATCH] perf stat: Add Topdown metrics events as default events

2021-01-21 Thread Arnaldo Carvalho de Melo
Em Thu, Jan 21, 2021 at 05:37:52AM -0800, kan.li...@linux.intel.com escreveu:
> From: Kan Liang 
> 
> The Topdown Microarchitecture Analysis (TMA) Method is a structured
> analysis methodology to identify critical performance bottlenecks in
> out-of-order processors. From the Ice Lake and later platforms, the
> Topdown information can be retrieved from the dedicated "metrics"
> register, which isn't impacted by other events. Also, the Topdown
> metrics support both per thread/process and per core measuring.
> Adding Topdown metrics events as default events can enrich the default
> measuring information, and would not cost any extra multiplexing.
> 
> Introduce arch_evlist__add_default_attrs() to allow architecture
> specific default events. Add the Topdown metrics events in the X86
> specific arch_evlist__add_default_attrs(). Other architectures can
> add their own default events later separately.
> 
> With the patch,
> 
>  $perf stat sleep 1
> 
>  Performance counter stats for 'sleep 1':
> 
>0.82 msec task-clock:u  #0.001 CPUs utilized
>   0  context-switches:u#0.000 K/sec
>   0  cpu-migrations:u  #0.000 K/sec
>  61  page-faults:u #0.074 M/sec
> 319,941  cycles:u  #0.388 GHz
> 242,802  instructions:u#0.76  insn per cycle
>  54,380  branches:u#   66.028 M/sec
>   4,043  branch-misses:u   #7.43% of all branches
>   1,585,555  slots:u   # 1925.189 M/sec
> 238,941  topdown-retiring:u# 15.0% retiring
> 410,378  topdown-bad-spec:u# 25.8% bad speculation
> 634,222  topdown-fe-bound:u# 39.9% frontend bound
> 304,675  topdown-be-bound:u# 19.2% backend bound

Shouldn't we be adding this to one of the -d levels?

But you say that this is essentially for free, so you check if this
extra register is in place and if it is, hey, its for free, add it, is
that the rationale?

I.e. it doesn't cause any impact to what we were getting before, so we
should default to use free stuff?

- Arnaldo
 
>1.001791625 seconds time elapsed
> 
>0.0 seconds user
>0.001572000 seconds sys
> 
> Signed-off-by: Kan Liang 
> ---
>  tools/perf/arch/x86/util/Build|  1 +
>  tools/perf/arch/x86/util/evlist.c | 15 +++
>  tools/perf/builtin-stat.c |  3 +++
>  tools/perf/util/evlist.c  |  5 +
>  tools/perf/util/evlist.h  |  2 ++
>  5 files changed, 26 insertions(+)
>  create mode 100644 tools/perf/arch/x86/util/evlist.c
> 
> diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
> index 347c39b960eb..ce1ec92fecdc 100644
> --- a/tools/perf/arch/x86/util/Build
> +++ b/tools/perf/arch/x86/util/Build
> @@ -6,6 +6,7 @@ perf-y += perf_regs.o
>  perf-y += topdown.o
>  perf-y += machine.o
>  perf-y += event.o
> +perf-y += evlist.o
>  
>  perf-$(CONFIG_DWARF) += dwarf-regs.o
>  perf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
> diff --git a/tools/perf/arch/x86/util/evlist.c 
> b/tools/perf/arch/x86/util/evlist.c
> new file mode 100644
> index ..8c6732cc7794
> --- /dev/null
> +++ b/tools/perf/arch/x86/util/evlist.c
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include 
> +#include "util/pmu.h"
> +#include "util/evlist.h"
> +#include "util/parse-events.h"
> +
> +#define TOPDOWN_L1_EVENTS
> "{slots,topdown-retiring,topdown-bad-spec,topdown-fe-bound,topdown-be-bound}"
> +
> +int arch_evlist__add_default_attrs(struct evlist *evlist)
> +{
> + if (!pmu_have_event("cpu", "slots"))
> + return 0;
> +
> + return parse_events(evlist, TOPDOWN_L1_EVENTS, NULL);
> +}
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 3c054b8d4677..abcdabaf1701 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -1827,6 +1827,9 @@ static int add_default_attributes(void)
>   }
>   if (evlist__add_default_attrs(evsel_list, default_attrs1) < 0)
>   return -1;
> +
> + if (arch_evlist__add_default_attrs(evsel_list) < 0)
> + return -1;
>   }
>  
>   /* Detailed events get appended to the event list: */
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 05363a7247c4..b38589d8c027 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -303,6 +303,11 @@ int __evlist__add_default_attrs(struct evlist *evlist, 
> struct perf_event_attr *a
>   return evlist__add_attrs(evlist, attrs, nr_attrs);
>  }
>  
> +__weak int arch_evlist__add_default_attrs(struct evlist *evlist 
> __maybe_unused)
> +{
> + return 0;
> +}
> +
>  struct evsel *evlist__find_tracepoint_by_id(struct evlist *evlist, int id)
>  {
>   struct evsel *evsel;
> diff -

Re: [PATCH -v3 0/9] sched: Fix hot-unplug regression

2021-01-21 Thread Paul E. McKenney
On Thu, Jan 21, 2021 at 11:17:02AM +0100, Peter Zijlstra wrote:
> Hi,
> 
> Some cautious optimism lets me post v3 of these patches. They (knock on wood)
> fix the regression introduced by commit:
> 
>   1cf12e08bc4d ("sched/hotplug: Consolidate task migration on CPU unplug")
> 
> These patches survived overnight runs for both me and Valentin, but I'll let 
> it
> run for at least another 12 hours before committing these patches.
> 
> New in this version is patch #7.
> 
> Much thanks to Valentin for his continued support and debugging efforts.

Thank you all!!!  I have started testing these on top of -rcu.

Thanx, Paul


[PATCH v5 7/7] dt-bindings: cpufreq: qcom-hw: Add bindings for 8998

2021-01-21 Thread AngeloGioacchino Del Regno
The OSM programming addition has been done under the
qcom,cpufreq-hw-8998 compatible name: specify the requirement
of two additional register spaces for this functionality.
This implementation, with the same compatible, has been
tested on MSM8998 and SDM630.

Signed-off-by: AngeloGioacchino Del Regno 

---
 .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 66 +++
 1 file changed, 52 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
index bc81b6203e27..17fd6a6cefb0 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
@@ -18,6 +18,10 @@ description: |
 properties:
   compatible:
 oneOf:
+  - description: Non-secure v1 of CPUFREQ HW
+items:
+  - const: qcom,cpufreq-hw-8998
+
   - description: v1 of CPUFREQ HW
 items:
   - const: qcom,cpufreq-hw
@@ -28,21 +32,9 @@ properties:
   - qcom,sm8250-cpufreq-epss
   - const: qcom,cpufreq-epss
 
-  reg:
-minItems: 2
-maxItems: 3
-items:
-  - description: Frequency domain 0 register region
-  - description: Frequency domain 1 register region
-  - description: Frequency domain 2 register region
+  reg: {}
 
-  reg-names:
-minItems: 2
-maxItems: 3
-items:
-  - const: freq-domain0
-  - const: freq-domain1
-  - const: freq-domain2
+  reg-names: {}
 
   clocks:
 items:
@@ -57,6 +49,52 @@ properties:
   '#freq-domain-cells':
 const: 1
 
+if:
+  properties:
+compatible:
+  contains:
+const: qcom,cpufreq-hw-8998
+then:
+  properties:
+reg:
+  minItems: 2
+  maxItems: 6
+  items:
+- description: Frequency domain 0 register region
+- description: Operating State Manager domain 0 register region
+- description: Frequency domain 1 register region
+- description: Operating State Manager domain 1 register region
+- description: PLL ACD domain 0 register region (if ACD programming 
required)
+- description: PLL ACD domain 1 register region (if ACD programming 
required)
+
+reg-names:
+  minItems: 2
+  maxItems: 6
+  items:
+- const: "osm-domain0"
+- const: "freq-domain0"
+- const: "osm-domain1"
+- const: "freq-domain1"
+- const: "osm-acd0"
+- const: "osm-acd1"
+
+else:
+  properties:
+reg:
+  minItems: 2
+  maxItems: 3
+  items:
+- description: Frequency domain 0 register region
+- description: Frequency domain 1 register region
+- description: Frequency domain 2 register region
+reg-names:
+  minItems: 2
+  maxItems: 3
+  items:
+- const: "freq-domain0"
+- const: "freq-domain1"
+- const: "freq-domain2"
+
 required:
   - compatible
   - reg
-- 
2.30.0



[PATCH v5 6/7] cpufreq: qcom-hw: Allow getting the maximum transition latency for OPPs

2021-01-21 Thread AngeloGioacchino Del Regno
In order to fine-tune the frequency scaling from various governors,
allow to set a maximum transition latency from OPPs, which may be
different depending on the SoC.

Signed-off-by: AngeloGioacchino Del Regno 

---
 drivers/cpufreq/qcom-cpufreq-hw.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
index 9a213a3046bb..d2b913582197 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -1405,6 +1405,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy 
*policy)
void __iomem *base;
struct qcom_cpufreq_data *data;
const char *fdom_resname;
+   unsigned int transition_latency;
int cpu_count, index, ret;
 
cpu_dev = get_cpu_device(policy->cpu);
@@ -1482,6 +1483,12 @@ static int qcom_cpufreq_hw_cpu_init(struct 
cpufreq_policy *policy)
goto error;
}
 
+   transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
+   if (!transition_latency)
+   transition_latency = CPUFREQ_ETERNAL;
+
+   policy->cpuinfo.transition_latency = transition_latency;
+
dev_pm_opp_of_register_em(cpu_dev, policy->cpus);
 
return 0;
-- 
2.30.0



Re: [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after unistd cleanup

2021-01-21 Thread Paul E. McKenney
On Thu, Jan 21, 2021 at 03:18:09PM +0100, Willy Tarreau wrote:
> On Thu, Jan 21, 2021 at 11:11:17AM +, Mark Rutland wrote:
> > So FWIW:
> > 
> > Tested-by: Mark Rutland  [arm64]

Thank you all!

> Perfect, thanks! Paul, may I let you copy-paste the tested-by yourself ?
> If you prefer I'm fine with resending a series to you, I just don't want
> to needlessly spam you :-)

Done, with Valentin's and Mark's Tested-by.

> > It would be great if this could be applied soon so that it's possible to
> > use the rcutorture scripts without applying local hacks.
> 
> Makes sense. I was wondering, should we mark them for stable ? I don't
> know if anyone relies on these tests to validate stable kernels in
> fact.

I added Fixes tags that should make this happen, and they are now visible
at -rcu branch "dev".  Could you please check them for me?

c261145 tools/nolibc: Add the definition for dup()
79f220e tools/nolibc: Make dup2() rely on dup3() when available
c0c7c10 tools/nolibc: Make getpgrp() fall back to getpgid(0)
be60ca4 tools/nolibc: Implement fork() based on clone()
5b1c827 tools/nolibc: Implement poll() based on ppoll()
70ca7ae tools/nolibc: Get timeval, timespec and timezone from linux/time.h
f65d711 tools/nolibc: Remove incorrect definitions of __ARCH_WANT_*
35635d7 tools/nolibc: Emit detailed error for missing alternate syscall number 
definitions
3c6ce7a tools/nolibc: Fix position of -lgcc in the documented example
26cec81 tools/rcutorture: Fix position of -lgcc in mkinitrd.sh

> > Willy, thanks for sorting this out, especially so quickly!
> 
> You're welcome, and thanks to you for the detailed report and explanations.

Again, thank you all!

On getting this upstream quickly, if all goes well I expect to include
this in my pull request for the upcoming merge window.

Thanx, Paul


[PATCH v5 4/7] dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings

2021-01-21 Thread AngeloGioacchino Del Regno
From: Manivannan Sadhasivam 

Convert Qualcomm cpufreq devicetree binding to YAML.

Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: AngeloGioacchino Del Regno 

---
 .../bindings/cpufreq/cpufreq-qcom-hw.txt  | 172 ---
 .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 204 ++
 2 files changed, 204 insertions(+), 172 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
deleted file mode 100644
index 9299028ee712..
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
+++ /dev/null
@@ -1,172 +0,0 @@
-Qualcomm Technologies, Inc. CPUFREQ Bindings
-
-CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
-SoCs to manage frequency in hardware. It is capable of controlling frequency
-for multiple clusters.
-
-Properties:
-- compatible
-   Usage:  required
-   Value type: 
-   Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss".
-
-- clocks
-   Usage:  required
-   Value type:  From common clock binding.
-   Definition: clock handle for XO clock and GPLL0 clock.
-
-- clock-names
-   Usage:  required
-   Value type:  From common clock binding.
-   Definition: must be "xo", "alternate".
-
-- reg
-   Usage:  required
-   Value type: 
-   Definition: Addresses and sizes for the memory of the HW bases in
-   each frequency domain.
-- reg-names
-   Usage:  Optional
-   Value type: 
-   Definition: Frequency domain name i.e.
-   "freq-domain0", "freq-domain1".
-
-- #freq-domain-cells:
-   Usage:  required.
-   Definition: Number of cells in a freqency domain specifier.
-
-* Property qcom,freq-domain
-Devices supporting freq-domain must set their "qcom,freq-domain" property with
-phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node.
-
-
-Example:
-
-Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch
-DCVS state together.
-
-/ {
-   cpus {
-   #address-cells = <2>;
-   #size-cells = <0>;
-
-   CPU0: cpu@0 {
-   device_type = "cpu";
-   compatible = "qcom,kryo385";
-   reg = <0x0 0x0>;
-   enable-method = "psci";
-   next-level-cache = <&L2_0>;
-   qcom,freq-domain = <&cpufreq_hw 0>;
-   L2_0: l2-cache {
-   compatible = "cache";
-   next-level-cache = <&L3_0>;
-   L3_0: l3-cache {
- compatible = "cache";
-   };
-   };
-   };
-
-   CPU1: cpu@100 {
-   device_type = "cpu";
-   compatible = "qcom,kryo385";
-   reg = <0x0 0x100>;
-   enable-method = "psci";
-   next-level-cache = <&L2_100>;
-   qcom,freq-domain = <&cpufreq_hw 0>;
-   L2_100: l2-cache {
-   compatible = "cache";
-   next-level-cache = <&L3_0>;
-   };
-   };
-
-   CPU2: cpu@200 {
-   device_type = "cpu";
-   compatible = "qcom,kryo385";
-   reg = <0x0 0x200>;
-   enable-method = "psci";
-   next-level-cache = <&L2_200>;
-   qcom,freq-domain = <&cpufreq_hw 0>;
-   L2_200: l2-cache {
-   compatible = "cache";
-   next-level-cache = <&L3_0>;
-   };
-   };
-
-   CPU3: cpu@300 {
-   device_type = "cpu";
-   compatible = "qcom,kryo385";
-   reg = <0x0 0x300>;
-   enable-method = "psci";
-   next-level-cache = <&L2_300>;
-   qcom,freq-domain = <&cpufreq_hw 0>;
-   L2_300: l2-cache {
-   compatible = "cache";
-   next-level-cache = <&L3_0>;
-   };
-   };
-
-   CPU4: cpu@400 {
-   device_type = "cpu";
-   compatible = "qcom,kryo385";
-   reg = <0x0 0x400>;
-   enable-method = "psci";
-   next-level-cache =

<    1   2   3   4   5   6   7   8   9   10   >