Re: [PATCH] HID: rmi: use HID_QUIRK_NO_INPUT_SYNC
On Fri, 25 May 2018, Benjamin Tissoires wrote: > When we receive a RMI4 report, we should not unconditionally send an > input_sync event. Instead, we should let the rmi4 transport layer do it > for us. > > This fixes a situation where we might receive X in a report and the rest > in a subsequent one. And this messes up user space. > > Link: https://bugs.freedesktop.org/show_bug.cgi?id=100436 > > Signed-off-by: Benjamin Tissoires > --- > > Hi, > > Oscar, do you mind if we add your "Tested-by: Oscar Morante "? > > Andrew, can you check for any sides effects please? I have now added Oscar's Tested-by: line and queued in for-4.18/rmi. In case any sideeffects are discovered, I'll either not include for-4.18/rmi in the push to Linus, or we'll do incremental fixups on top (depending on the nature of the side-effects :) ). Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] HID: multitouch: fix calculation of last slot field in multi-touch reports
On Tue, 29 May 2018, Ben Chan wrote:
> According to [1] and also seemingly agreed by [2], the Scan Time usage
> (0x0D 0x56) is a report level usage, not a contact level usage.
>
> However, the hid-multitouch driver currently includes HID_DG_SCANTIME
> when calculating `td->last_slot_field', which may lead to
> mt_complete_slot() being prematurely called in certain cases (e.g. when
> each touch input report includes more than one contact and the Scan Time
> usage appears before any contact logical collection).
>
> This patch fixes the issue by skipping mt_store_field() on
> HID_DG_SCANTIME, similar to how HID_DG_CONTACTCOUNT and
> HID_DG_CONTACTMAX are handled.
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections#windows-precision-touchpad-input-reports
> [2] https://patchwork.kernel.org/patch/1742181/
>
> Fixes: 29cc309d8bf19 ("HID: hid-multitouch: forward MSC_TIMESTAMP")
> Signed-off-by: Ben Chan
Applied, thanks Ben.
--
Jiri Kosina
SUSE Labs
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 29, 2018 at 10:33 PM, Greg KH wrote:
> On Tue, May 29, 2018 at 10:14:35PM -0700, John Stultz wrote:
>> On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
>> > On 2018년 05월 09일 08:17, John Stultz wrote:
>> >> Hey folks,
>> >> I wanted to bring up an issue we've recently tripped over, which was
>> >> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
>> >> devfreq(X) for sysfs").
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
>> >>
>> >> That patch replaced paths like:
>> >>/sys/class/devfreq/ddr_devfreq/min_freq
>> >> and
>> >> /sys/class/devfreq/e82c.mali/min_freq
>> >>
>> >> With
>> >> /sys/class/devfreq/devfreq(0)/min_freq
>> >> and
>> >> /sys/class/devfreq/devfreq(1)/min_freq
>> >>
>> >>
>> >> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
>> >> on).
>> >
>> > Firstly, I'm sorry to make some problem on userland.
>> >
>> >>
>> >> I wanted to try to ask to understand more about the rational for this
>> >> patch, as it doesn't make much sense to me, particularly as now it is
>> >> less obvious as to which path is for which device - and more
>> >> worrisome it could change depending on initialization order.
>> >
>> > Some linux framework used the their own prefix under "/sys/class/"
>> > for device such as input/pwm/hwmon/regulator and so on.
>> > (But, some linux framework used the device name directly without any
>> > changes)
>> >
>> > I thought that devfreq better to use use the consistent name.
>> > If user wanted to access the specific device with device name,
>> > the user can access the path of '/sys/devices/platform/...'.
>> >
>> > [Example on Exynos5433-based TM2 board]
>> > root@localhost:~# ls -al /sys/class/devfreq
>> > total 0
>> > drwxr-xr-x 2 root root 0 Jul 26 04:49 .
>> > drwxr-xr-x 50 root root 0 Jan 1 1970 ..
>> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
>> > ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
>> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
>> > ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
>> > (skip)
>> >
>> > - User can access the devfreq device with specific device name.
>> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
>> > /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
>> >
>> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
>> > available_frequencies devicemin_freq subsystemuevent
>> > available_governorsgovernor polling_interval target_freq
>> > cur_freq max_freq power trans_stat
>> >
>> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
>> > min_freq
>> > 16000
>> >
>>
>> Sorry to not get back to you sooner on this. Was on vacation then this
>> discussion got buried in my inbox.
>>
>> I do agree that it the consistency with other subsystems is an
>> improvement, but it still doesn't help our situation that userspace
>> applications can't consistently work between kernel versions, as even
>> if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
>> path rather then the /sys/class/devfreq/ path, in older kernels the
>> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
>
> Ick, that's not ok. The sys/class/ path should always work for old and
> new. If not, it's broken and should be reverted.
>
> And it seems like it still works, just that the "names" are now
> different in the class path, of the device, right? And that should be
> fine, what is breaking when a device name changes?
Well, code that is looking for:
/sys/class/devfreq/ddr_devfreq/min_freq
won't work with newer kernels unless its changed to look for:
/sys/class/devfreq/devfreq0/min_freq
(assuming the ddr_devfreq driver loaded before the mali one :)
>> I agree we need a name attribute so folks can tell the difference
>> between devices.
>>
>> I'm also not too much of a stickler that the old ABI broke, as long as
>> we have some solution that works across kernels. So I'd request that
>> you at least make older -stable kernels (4.4 and 4.9) behavior
>> consistent with upstream.
>
> No, I don't want to backport api changes like that as then users of
> those kernels that were working just fine break :)
>
> So I think mainline needs to revert this.
The trouble is that the break happened awhile back (4.10) so if we
revert its likely to break any new users since then.
That's why I suggested we find some way to have both paths work. But I
don't know enough sysfs tricks to have a good suggestion on how to
easily do so.
thanks
-john
RE: [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
On 30 May 2018 at 2:07PM Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote: >On 30 May 2018 at 07:58, Ingo Molnar wrote: >> >> * nixiaoming wrote: >> >>> mark_rodata_ro is only called by the function mark_readonly >>> when CONFIG_STRICT_KERNEL_RWX=y >>> >>> if CONFIG_STRICT_KERNEL_RWX is not set >>> a compile warning may be triggered: unused function > >> >> NAK, this is very ugly and the changelog doesn't appear to be true: the build >> warning does not trigger in the default build, correct? >> > >I don't see how the build warning could trigger at all, given that >mark_rodata_ro() has external linkage. > Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=x86_64 the build warning does not trigger in the default build, but it should be more appropriate to add CONFIG control to the code.
Re: [PATCH] HID: steam: select CONFIG_POWER_SUPPLY
On Fri, 25 May 2018, Arnd Bergmann wrote:
> Using the power supply APIs requires selecting the appropriate
> Kconfig symbol, otherwise we get this build failure:
>
> drivers/hid/hid-steam.o: In function `steam_unregister':
> hid-steam.c:(.text+0x1cc): undefined reference to `power_supply_unregister'
> drivers/hid/hid-steam.o: In function `steam_battery_get_property':
> hid-steam.c:(.text+0x2d2): undefined reference to `power_supply_get_drvdata'
> drivers/hid/hid-steam.o: In function `steam_raw_event':
> hid-steam.c:(.text+0xcba): undefined reference to `power_supply_changed'
> drivers/hid/hid-steam.o: In function `steam_register':
> hid-steam.c:(.text+0x13e3): undefined reference to `power_supply_register'
> hid-steam.c:(.text+0x13fe): undefined reference to `power_supply_powers'
>
> Fixes: f82719790751 ("HID: steam: add battery device.")
> Signed-off-by: Arnd Bergmann
Applied, thanks.
--
Jiri Kosina
SUSE Labs
Re: heads up: moving intel-pt-decoder/Build header checks to check_headers.sh
On 29/05/18 16:48, Arnaldo Carvalho de Melo wrote: > Hi Adrian, > > We've made tools/perf/check-headers.sh the mechanism to check > for drift on kernel file copies we have in tools/, and it assumes that > if we have tools/a/b/c/d, then it came from a/b/c/d in the kernel > sources, e.g. a copy of the kernel's arch/x86/lib/x86-opcode-map.txt > would be in tools/arch/x86/lib/x86-opcode-map.txt. > > That is not the case with the intel-pt-decoder, so I'm thinking > about moving those files to comply with the model used for other copies, > as having it in util/intel-pt-decoder/ isn't strictly required, i.e. > those files could conceivably be used for other purposes besides > decoding intel-pt traces, say for disassembly/annotate, that albeit not > planned (at least by me) for the near future, would be something > interesting to investigate doing. > > IIRC Ingo was the one to point me out this, and now I saw the > warning about it being different flying by in the middle of the build, > differently from what is done by check-headers.sh, that is to show > everything that drifted in one single block, at the start of the build. > > So unless you have a strong objection to this, I'll continue > investigation about how do do it with tools/perf/check-headers.sh, I have no objection but currently it is (theoretically) possible to compile Intel PT decoding support into perf script and perf report for any architecture. i.e. decoding Intel PT from a perf.data file does not depend on the build architecture.
[PATCH] perf util: Add more PMU fields for perf script python
When doing pmu sampling and then running a script with
perf script -s script.py, the process_event function gets
dictionary with some fields from the perf ring buffer
(like ip, sym, callchain etc).
But we miss quite a few fields we report now, for example,
LBRs,data source,weight,transaction,iregs,uregs,and etc.
This patch reports these fields for perf script python
processing.
New created elements:
-
brstack (from sample->branch_stack, raw value):
from, to, mispred, predicted, in_tx, abort, cycles.
brstacksym (from sample->branch_stack, converted string):
from, to, pred, in_tx, abort
datasrc (from sample->datasrc, raw value)
datasrc_decode (from sample->datasrc, decoded string)
iregs (from attr->sample_regs_intr, converted reg name)
uregs (from attr->sample_regs_user, converted reg name)
weight (from sample->weight, raw value)
transaction (from sample->transaction, raw value)
Signed-off-by: Jin Yao
---
.../util/scripting-engines/trace-event-python.c| 212 -
1 file changed, 211 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
b/tools/perf/util/scripting-engines/trace-event-python.c
index 7f8afac..01abb4a 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -48,6 +48,7 @@
#include "cpumap.h"
#include "print_binary.h"
#include "stat.h"
+#include "mem-events.h"
#if PY_MAJOR_VERSION < 3
#define _PyUnicode_FromString(arg) \
@@ -448,6 +449,151 @@ static PyObject *python_process_callchain(struct
perf_sample *sample,
return pylist;
}
+static PyObject *python_process_brstack(struct perf_sample *sample)
+{
+ struct branch_stack *br = sample->branch_stack;
+ PyObject *pylist;
+ u64 i;
+
+ pylist = PyList_New(0);
+ if (!pylist)
+ Py_FatalError("couldn't create Python list");
+
+ if (!(br && br->nr))
+ goto exit;
+
+ for (i = 0; i < br->nr; i++) {
+ PyObject *pyelem;
+
+ pyelem = PyDict_New();
+ if (!pyelem)
+ Py_FatalError("couldn't create Python dictionary");
+
+ pydict_set_item_string_decref(pyelem, "from",
+ PyLong_FromUnsignedLongLong(br->entries[i].from));
+ pydict_set_item_string_decref(pyelem, "to",
+ PyLong_FromUnsignedLongLong(br->entries[i].to));
+ pydict_set_item_string_decref(pyelem, "mispred",
+ PyLong_FromUnsignedLongLong(br->entries[i].flags.mispred));
+ pydict_set_item_string_decref(pyelem, "predicted",
+
PyLong_FromUnsignedLongLong(br->entries[i].flags.predicted));
+ pydict_set_item_string_decref(pyelem, "in_tx",
+ PyLong_FromUnsignedLongLong(br->entries[i].flags.in_tx));
+ pydict_set_item_string_decref(pyelem, "abort",
+ PyLong_FromUnsignedLongLong(br->entries[i].flags.abort));
+ pydict_set_item_string_decref(pyelem, "cycles",
+ PyLong_FromUnsignedLongLong(br->entries[i].flags.cycles));
+
+ PyList_Append(pylist, pyelem);
+ Py_DECREF(pyelem);
+ }
+
+exit:
+ return pylist;
+}
+
+static unsigned long get_offset(struct symbol *sym, struct addr_location *al)
+{
+ unsigned long offset;
+
+ if (al->addr < sym->end)
+ offset = al->addr - sym->start;
+ else
+ offset = al->addr - al->map->start - sym->start;
+
+ return offset;
+}
+
+static int get_symoff(struct symbol *sym, struct addr_location *al,
+ bool print_off, char *bf, int size)
+{
+ unsigned long offset;
+
+ if (!sym || !sym->name)
+ return scnprintf(bf, size, "%s", "[unknown]");
+
+ if (!print_off)
+ return scnprintf(bf, size, "%s", sym->name);
+
+ offset = get_offset(sym, al);
+
+ return scnprintf(bf, size, "%s+0x%x", sym->name, offset);
+}
+
+static int get_br_mspred(struct branch_flags *flags, char *bf, int size)
+{
+ if (!flags->mispred && !flags->predicted)
+ return scnprintf(bf, size, "%s", "-");
+
+ if (flags->mispred)
+ return scnprintf(bf, size, "%s", "M");
+
+ return scnprintf(bf, size, "%s", "P");
+}
+
+static PyObject *python_process_brstacksym(struct perf_sample *sample,
+ struct thread *thread)
+{
+ struct branch_stack *br = sample->branch_stack;
+ PyObject *pylist;
+ u64 i;
+ char bf[512];
+ struct addr_location al;
+
+ pylist = PyList_New(0);
+ if (!pylist)
+ Py_FatalError("couldn't create Python list");
+
+ if (!(br && br->nr))
+ goto exit;
+
+ for (i = 0; i < br->nr; i++) {
+ PyObject *pyelem;
+
+ pyelem = PyDi
Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
Hi Sean, >> >> [ ... ] > > [ ... ] > >>> I post it as plain text as below >>> >>> >>> Bluetooth monitor ver 5.37 >>> = Note: Linux version 4.16.0-rc1+ (aarch64) >>> 0.641494 >>> = Note: Bluetooth subsystem version 2.22 >>> 0.641502 >>> = New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] >>> 0.641505 >>> * Unknown packet (code 14 len 30) >>> 0.641509 >>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..bl >>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00uetoothd.. >>> * Unknown packet (code 14 len 30) >>> 0.641592 >>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..bt >>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00mon... >>> * Unknown packet (code 16 len 7)[hci0] >>> 6.536771 >>> 01 00 00 00 05 00 01 ... >>> = Open Index: 00:00:46:76:22:01 [hci0] >>> 6.717019 >>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.)[hci0] >>> 6.717030 >> >> can you try with the latest BlueZ 5.49 or git version. Seems it actually >> stumbles over the extra packet here. Fun fact is that I can not get a >> backtrace to pin-point the issue in btmon and why it crashes. >> > > I had less experience updating user land BlueZ, but I can try it as possible > and see whether Unknown packets still are present at newest version BlueZ. > Hopefully I don't misunderstand your point here. please use the latest btmon and check if it can read your trace. HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999 >>> 02 01 01 00 00 . HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991 >>> 02 01 01 00 00
Re: [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration
On 2018-05-30 05:58, Masahiro Yamada wrote:
Hi.
2018-05-30 4:30 GMT+09:00 Boris Brezillon
:
On Sat, 26 May 2018 10:42:47 +0200
Miquel Raynal wrote:
Hi Abhishek,
On Fri, 25 May 2018 17:51:29 +0530, Abhishek Sahu
wrote:
> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
> match, maximize ECC settings") provides generic helpers which
> drivers can use for setting up ECC parameters.
>
> Since same board can have different ECC strength nand chips so
> following is the logic for setting up ECC strength and ECC step
> size, which can be used by most of the drivers.
>
> 1. If both ECC step size and ECC strength are already set
>(usually by DT) then just check whether this setting
>is supported by NAND controller.
> 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>supported by NAND controller.
> 3. Otherwise, try to match the ECC step size and ECC strength closest
>to the chip's requirement. If available OOB size can't fit the chip
>requirement then select maximum ECC strength which can be fit with
>available OOB size.
>
> This patch introduces nand_ecc_choose_conf function which calls the
> required helper functions for the above logic. The drivers can use
> this single function instead of calling the 3 helper functions
> individually.
>
> CC: Masahiro Yamada
> Signed-off-by: Abhishek Sahu
> ---
> * Changes from v2:
>
> 1. Renamed function to nand_ecc_choose_conf.
> 2. Minor code reorganization to remove warning and 2 function calls
> for nand_maximize_ecc.
>
> * Changes from v1:
> NEW PATCH
>
> drivers/mtd/nand/raw/nand_base.c | 42
> drivers/mtd/nand/raw/nand_base.c | 31 +++
> include/linux/mtd/rawnand.h | 3 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
b/drivers/mtd/nand/raw/nand_base.c
> index 72f3a89..e52019d 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -6249,6 +6249,37 @@ int nand_maximize_ecc(struct nand_chip *chip,
> }
> EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>
> +/**
> + * nand_ecc_choose_conf - Set the ECC strength and ECC step size
> + * @chip: nand chip info structure
> + * @caps: ECC engine caps info structure
> + * @oobavail: OOB size that the ECC engine can use
> + *
> + * Choose the ECC configuration according to following logic
> + *
> + * 1. If both ECC step size and ECC strength are already set (usually by DT)
> + *then check if it is supported by this controller.
> + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
> + * 3. Otherwise, try to match the ECC step size and ECC strength closest
> + *to the chip's requirement. If available OOB size can't fit the chip
> + *requirement then fallback to the maximum ECC step size and ECC
strength.
> + *
> + * On success, the chosen ECC settings are set.
> + */
> +int nand_ecc_choose_conf(struct nand_chip *chip,
> +const struct nand_ecc_caps *caps, int oobavail)
> +{
> + if (chip->ecc.size && chip->ecc.strength)
> + return nand_check_ecc_caps(chip, caps, oobavail);
> +
> + if (!(chip->ecc.options & NAND_ECC_MAXIMIZE) &&
> + !nand_match_ecc_req(chip, caps, oobavail))
> + return 0;
> +
> + return nand_maximize_ecc(chip, caps, oobavail);
I personally don't mind if nand_maximize_ecc() is called twice in
the function if it clarifies the logic. Maybe the following will be
more clear for the user?
if (chip->ecc.size && chip->ecc.strength)
return nand_check_ecc_caps(chip, caps, oobavail);
if (chip->ecc.options & NAND_ECC_MAXIMIZE)
return nand_maximize_ecc(chip, caps, oobavail);
if (!nand_match_ecc_req(chip, caps, oobavail))
return 0;
return nand_maximize_ecc(chip, caps, oobavail);
I personally don't mind, and it seems Masahiro wanted to keep the
logic
he had used in the denali driver.
Also, I'm not sure we should just error out when
nand_check_ecc_caps()
fails. What about something more robust, like:
int ret;
if (chip->ecc.size && chip->ecc.strength) {
ret = nand_check_ecc_caps(chip, caps, oobavail);
if (ret)
goto maximize_ecc;
Nope. When someone asked for a specific ECC config by passing the
nand-ecc-xxx props we should apply it or return an erro if it's not
supported. People passing those props should now what the ECC engine
supports and pick one valid values.
return 0;
}
if (chip->ecc.options & NAND_ECC_MAXIMIZE)
goto maximize_ecc;
ret = nand_match_ecc_req(chip, caps, oobavail);
if (ret)
goto maximize_ecc;
return 0;
maximize_ecc:
return nand_maximize_ecc(chip, caps, oobavail);
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/
Re: [PATCH] Bluetooth: btusb: Add additional device ID for RTL8822BE
Hi Artiom, > The Asus ROG GL702ZC laptop contains a Realtek RTL8822BE device with > an associated BT chip using a USB ID of 13d3:3526. This ID is added > to the driver. please include the /sys/kernel/debug/usb/devices portion for this device in the commit messages. Regards Marcel
Re: [PATCH] Bluetooth: hci_qca: Fix "Sleep inside atomic section" warning
Hi Thierry, > This patch fixes the following warning during boot: > > do not call blocking ops when !TASK_RUNNING; state=1 set at > [<(ptrval)>] qca_setup+0x194/0x750 [hci_uart] > WARNING: CPU: 2 PID: 1878 at kernel/sched/core.c:6135 > __might_sleep+0x7c/0x88 > > In qca_set_baudrate(), the current task state is set to > TASK_UNINTERRUPTIBLE before going to sleep for 300ms. It was then > restored to TASK_INTERRUPTIBLE. This patch sets the current task state > back to TASK_RUNNING instead. > > Signed-off-by: Thierry Escande > --- > drivers/bluetooth/hci_qca.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to bluetooth-next tree. > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index f05382b5a65d..51790dd02afb 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -910,7 +910,7 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t > baudrate) >*/ > set_current_state(TASK_UNINTERRUPTIBLE); > schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS)); > - set_current_state(TASK_INTERRUPTIBLE); > + set_current_state(TASK_RUNNING); > However wouldn’t it better to use msleep or similar instead of open coding it with schedule_timeout? Regards Marcel
[PATCH v2] mm: condense scan_control
Use smaller scan_control fields for order, priority, and reclaim_idx.
Convert fields from int => s8. All easily fit within a byte:
* allocation order range: 0..MAX_ORDER(64?)
* priority range: 0..12(DEF_PRIORITY)
* reclaim_idx range: 0..6(__MAX_NR_ZONES)
Since commit 6538b8ea886e ("x86_64: expand kernel stack to 16K") x86_64
stack overflows are not an issue. But it's inefficient to use ints.
Use s8 (signed byte) rather than u8 to allow for loops like:
do {
...
} while (--sc.priority >= 0);
Add BUILD_BUG_ON to verify that s8 is capable of storing max values.
This reduces sizeof(struct scan_control):
* 96 => 80 bytes (x86_64)
* 68 => 56 bytes (i386)
scan_control structure field order is changed to utilize padding.
After this patch there is 1 bit of scan_control padding.
Signed-off-by: Greg Thelen
Suggested-by: Matthew Wilcox
---
mm/vmscan.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9b697323a88c..42731faea306 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -65,12 +65,6 @@ struct scan_control {
/* How many pages shrink_list() should reclaim */
unsigned long nr_to_reclaim;
- /* This context's GFP mask */
- gfp_t gfp_mask;
-
- /* Allocation order */
- int order;
-
/*
* Nodemask of nodes allowed by the caller. If NULL, all nodes
* are scanned.
@@ -83,12 +77,6 @@ struct scan_control {
*/
struct mem_cgroup *target_mem_cgroup;
- /* Scan (total_size >> priority) pages at once */
- int priority;
-
- /* The highest zone to isolate pages for reclaim from */
- enum zone_type reclaim_idx;
-
/* Writepage batching in laptop mode; RECLAIM_WRITE */
unsigned int may_writepage:1;
@@ -111,6 +99,18 @@ struct scan_control {
/* One of the zones is ready for compaction */
unsigned int compaction_ready:1;
+ /* Allocation order */
+ s8 order;
+
+ /* Scan (total_size >> priority) pages at once */
+ s8 priority;
+
+ /* The highest zone to isolate pages for reclaim from */
+ s8 reclaim_idx;
+
+ /* This context's GFP mask */
+ gfp_t gfp_mask;
+
/* Incremented by the number of inactive pages that were scanned */
unsigned long nr_scanned;
@@ -3047,6 +3047,14 @@ unsigned long try_to_free_pages(struct zonelist
*zonelist, int order,
.may_swap = 1,
};
+ /*
+* scan_control uses s8 fields for order, priority, and reclaim_idx.
+* Confirm they are large enough for max values.
+*/
+ BUILD_BUG_ON(MAX_ORDER > S8_MAX);
+ BUILD_BUG_ON(DEF_PRIORITY > S8_MAX);
+ BUILD_BUG_ON(MAX_NR_ZONES > S8_MAX);
+
/*
* Do not enter reclaim if fatal signal was delivered while throttled.
* 1 is returned so that the page allocator does not OOM kill at this
--
2.17.0.921.gf22659ad46-goog
Re: [PATCH] mm: convert scan_control.priority int => byte
Matthew Wilcox wrote:
> On Mon, May 28, 2018 at 07:40:25PM -0700, Greg Thelen wrote:
>> Reclaim priorities range from 0..12(DEF_PRIORITY).
>> scan_control.priority is a 4 byte int, which is overkill.
>>
>> Since commit 6538b8ea886e ("x86_64: expand kernel stack to 16K") x86_64
>> stack overflows are not an issue. But it's inefficient to use 4 bytes
>> for priority.
>
> If you're looking to shave a few more bytes, allocation order can fit
> in a u8 too (can't be more than 6 bits, and realistically won't be more
> than 4 bits). reclaim_idx likewise will fit in a u8, and actually won't
> be more than 3 bits.
Nod. Good tip. Included in ("[PATCH v2] mm: condense scan_control").
> I am sceptical that nr_to_reclaim should really be an unsigned long; I
> don't think we should be trying to free 4 billion pages in a single call.
> nr_scanned might be over 4 billion (!) but nr_reclaimed can probably
> shrink to unsigned int along with nr_to_reclaim.
Agreed. For patch simplicity, I'll pass on this for now.
Re: [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
On 30 May 2018 at 07:58, Ingo Molnar wrote:
>
> * nixiaoming wrote:
>
>> mark_rodata_ro is only called by the function mark_readonly
>> when CONFIG_STRICT_KERNEL_RWX=y
>>
>> if CONFIG_STRICT_KERNEL_RWX is not set
>> a compile warning may be triggered: unused function
>>
>> Signed-off-by: nixiaoming
>> ---
>> arch/x86/mm/init_32.c | 2 ++
>> arch/x86/mm/init_64.c | 2 ++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
>> index c893c6a..121c567 100644
>> --- a/arch/x86/mm/init_32.c
>> +++ b/arch/x86/mm/init_32.c
>> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
>> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
>> }
>>
>> +#ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void)
>> {
>> unsigned long start = PFN_ALIGN(_text);
>> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
>> if (__supported_pte_mask & _PAGE_NX)
>> debug_checkwx();
>> }
>> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>> index 0a40060..1b7a1a7 100644
>> --- a/arch/x86/mm/init_64.c
>> +++ b/arch/x86/mm/init_64.c
>> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
>> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
>> }
>>
>> +#ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void)
>> {
>> unsigned long start = PFN_ALIGN(_text);
>> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
>>*/
>> pti_clone_kernel_text();
>> }
>> +#endif
>
> NAK, this is very ugly and the changelog doesn't appear to be true: the build
> warning does not trigger in the default build, correct?
>
I don't see how the build warning could trigger at all, given that
mark_rodata_ro() has external linkage.
Re: [PATCH] x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec()
Hi Dan,
On Fri, May 25, 2018 at 10:21:08AM -0700, Dan Williams wrote:
> Mark notes that gcc optimization passes have the potential to elide
> necessary invocations of this instruction sequence, so include an
> optimization barrier.
>
> > I think that either way, we have a potential problem if the compiler
> > generates a branch dependent on the result of validate_index_nospec().
> >
> > In that case, we could end up with codegen approximating:
> >
> > bool safe = false;
> >
> > if (idx < bound) {
> > idx = array_index_nospec(idx, bound);
> > safe = true;
> > }
> >
> > // this branch can be mispredicted
> > if (safe) {
> > foo = array[idx];
> > }
> >
> > ... and thus we lose the nospec protection.
>
> I see GCC do this at -O0, but so far I haven't tricked it into doing
> this at -O1 or above.
>
> Regardless, I worry this is fragile -- GCC *can* generate code as per
> the above, even if it's unlikely to.
I certainly believe that we want the volatile.
However, just to be clear, the barrier doesn't prevent the above example, since
we don't currently have a mechanism to prevent the compiler splitting basic
blocks and inserting additional branches between those blocks.
I've written up a rationale for the volatile below, if you want something for
the commit message. There's a minor comment on the patch after that.
The volatile will inhibit *some* cases where the compiler could lift the
array_index_nospec() call out of a branch, e.g. where there are multiple
invocations of array_index_nospec() with the same arguments:
if (idx < foo) {
idx1 = array_idx_nospec(idx, foo)
do_something(idx1);
}
< some other code >
if (idx < foo) {
idx2 = array_idx_nospec(idx, foo);
do_something_else(idx2);
}
... since the compiler can determine that the two invocations yield the same
result, and reuse the first result (likely the same register as idx was in
originally) for the second branch, effectively re-writing the above as:
if (idx < foo) {
idx = array_idx_nospec(idx, foo);
do_something(idx);
}
< some other code >
if (idx < foo) {
do_something_else(idx);
}
... if we don't take the first branch, then speculatively take the second, we
lose the nospec protection.
There's more info on volatile asm in the GCC docs:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile
> Cc:
> Fixes: babdde2698d4 ("x86: Implement array_index_mask_nospec")
> Cc: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: Linus Torvalds
> Cc: Ingo Molnar
> Reported-by: Mark Rutland
> Signed-off-by: Dan Williams
> ---
> arch/x86/include/asm/barrier.h |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index 042b5e892ed1..41f7435c84a7 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -38,10 +38,11 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> {
> unsigned long mask;
>
> - asm ("cmp %1,%2; sbb %0,%0;"
> + asm volatile ("cmp %1,%2; sbb %0,%0;"
> :"=r" (mask)
> :"g"(size),"r" (index)
> :"cc");
> + barrier();
> return mask;
> }
What does the barrier() prevent?
I don't think that inhibits the insertion of branches, and AFAIK the volatile
is sufficient to prevent elision of identical array_idx_nospec() calls.
I don't have an objection to it, regardless.
So long as the example is updated in the commit message, feel free to add:
Acked-by: Mark Rutland
Thanks,
Mark.
[PATCH] ia64: pgtable.h: fix a comment typo
Signed-off-by: Li Qiang --- arch/ia64/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h index 165827774bea..2cccfbb23c2d 100644 --- a/arch/ia64/include/asm/pgtable.h +++ b/arch/ia64/include/asm/pgtable.h @@ -336,7 +336,7 @@ static inline void set_pte(pte_t *ptep, pte_t pteval) if (pte_present_exec_user(pteval) && (!pte_present(*ptep) || pte_pfn(*ptep) != pte_pfn(pteval))) - /* load_module() calles flush_icache_range() explicitly*/ + /* load_module() calls flush_icache_range() explicitly*/ __ia64_sync_icache_dcache(pteval); *ptep = pteval; } -- 2.11.0
[GIT PULL] two more s390 bug fixes for 4.17
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
Two bug fixes for 4.17
* A missing -msoft-float for the compile of the kexec purgatory
* A fix for the dasd driver to avoid the double use of a field in
the 'struct request'
Philipp Rudo (1):
s390/purgatory: Fix endless interrupt loop
Sebastian Ott (1):
s390/dasd: use blk_mq_rq_from_pdu for per request data
arch/s390/purgatory/Makefile | 2 +-
drivers/s390/block/dasd.c| 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/s390/purgatory/Makefile b/arch/s390/purgatory/Makefile
index e9525bc..1ace023 100644
--- a/arch/s390/purgatory/Makefile
+++ b/arch/s390/purgatory/Makefile
@@ -21,7 +21,7 @@ LDFLAGS_purgatory.ro += -z nodefaultlib
KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes
KBUILD_CFLAGS += -Wno-pointer-sign -Wno-sign-compare
KBUILD_CFLAGS += -fno-zero-initialized-in-bss -fno-builtin -ffreestanding
-KBUILD_CFLAGS += -c -MD -Os -m64
+KBUILD_CFLAGS += -c -MD -Os -m64 -msoft-float
KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 04143c0..02c03e4 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -3034,7 +3034,8 @@ static blk_status_t do_dasd_request(struct blk_mq_hw_ctx
*hctx,
cqr->callback_data = req;
cqr->status = DASD_CQR_FILLED;
cqr->dq = dq;
- req->completion_data = cqr;
+ *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr;
+
blk_mq_start_request(req);
spin_lock(&block->queue_lock);
list_add_tail(&cqr->blocklist, &block->ccw_queue);
@@ -3058,12 +3059,13 @@ static blk_status_t do_dasd_request(struct
blk_mq_hw_ctx *hctx,
*/
enum blk_eh_timer_return dasd_times_out(struct request *req, bool reserved)
{
- struct dasd_ccw_req *cqr = req->completion_data;
struct dasd_block *block = req->q->queuedata;
struct dasd_device *device;
+ struct dasd_ccw_req *cqr;
unsigned long flags;
int rc = 0;
+ cqr = *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req));
if (!cqr)
return BLK_EH_NOT_HANDLED;
@@ -3169,6 +3171,7 @@ static int dasd_alloc_queue(struct dasd_block *block)
int rc;
block->tag_set.ops = &dasd_mq_ops;
+ block->tag_set.cmd_size = sizeof(struct dasd_ccw_req *);
block->tag_set.nr_hw_queues = DASD_NR_HW_QUEUES;
block->tag_set.queue_depth = DASD_MAX_LCU_DEV * DASD_REQ_PER_DEV;
block->tag_set.flags = BLK_MQ_F_SHOULD_MERGE;
Re: [reset-control] How to initialize hardware state with the shared reset line?
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> wrote:
>>> > Hi.
>>> >
>>> >
>>> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
>>> > :
>>> > > Hi,
>>> > >
>>> > > On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>>> > > wrote:
>>> > > [snip]
>>> > > > I may be missing something, but
>>> > > > one solution might be reset hogging on the
>>> > > > reset provider side. This allows us to describe
>>> > > > the initial state of reset lines in the reset controller.
>>> > > >
>>> > > > The idea for "reset-hog" is similar to:
>>> > > > - "gpio-hog" defined in
>>> > > >Documentation/devicetree/bindings/gpio/gpio.txt
>>> > > > - "assigned-clocks" defined in
>>> > > >Documetation/devicetree/bindings/clock/clock-bindings.txt
>>> > > >
>>> > > >
>>> > > >
>>> > > > For example,
>>> > > >
>>> > > >reset-controller {
>>> > > >
>>> > > >
>>> > > > line_a {
>>> > > > reset-hog;
>>> > > > resets = <1>;
>>> > > > reset-assert;
>>> > > > };
>>> > > >}
>>> > > >
>>> > > >
>>> > > > When the reset controller is registered,
>>> > > > the reset ID '1' is asserted.
>>> > > >
>>> > > >
>>> > > > So, all reset consumers that share the reset line '1'
>>> > > > will start from the asserted state
>>> > > > (i.e. defined state machine state).
>>> > >
>>> > > I wonder if a "reset hog" can be board specific:
>>> > > - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>>> > > example uses it to take the USB hub out of reset)
>>> > > - assigned-clock-parents (and the like) can also be board specific (I
>>> > > made up a use-case since I don't know of any actual examples: board A
>>> > > uses an external XTAL while board B uses some other internal
>>> > > clock-source because it doesn't have an external XTAL)
>>> > >
>>> > > however, can reset lines be board specific? or in other words: do we
>>> > > need to describe them in device-tree?
>>> >
>>> > Indeed.
>>> >
>>> > I did not come up with board-specific cases.
>>> >
>>> > The problem we are discussing is SoC-specific,
>>> > and reset-controller drivers are definitely SoC-specific.
>>> >
>>> > So, I think the initial state can be coded in drivers instead of DT.
>>>
>>> OK, let's also hear Philipp's (reset framework maintainer) opinion on this
>>
>> I'd like to know if there are other SoC families besides Amlogic Meson
>> that potentially could have this problem and about how many of the
>> resets that are documented in include/dt-bindings/reset/amlogic,meson*
>> we are actually talking. Are all of those initially deasserted and none
>> of the connected peripherals have power-on reset mechanisms?
> I cannot speak for other SoC families besides Amlogic
> Meson8/Meson8b/Meson8m2 and GX (disclaimer: I am a community
> contributor, I don't have access to Amlogic's internal datasheets - my
> knowledge is based on their public datasheets, their GPL kernel/u-boot
> sources and trial and error)
>
> it seems that at least "some" (but I don't know the exact number)
> resets are de-asserted by the bootloader
> Amlogic's u-boot for example also enables all gate clocks by default
>
> I CC'ed the Amlogic mailing list because I'm not sure if everyone
> working on that SoC family is watching the linux-arm-kernel mailing
> list
>
>>> > > we could extend struct reset_controller_dev (= reset controller
>>> > > driver) if they are not board specific:
>>> > > - either assert all reset lines by default except if they are listed
>>> > > in a new field (may break backwards compatibility, requires testing of
>>> > > all reset controller drivers)
>>> >
>>> > This is quite simple, but I am afraid there are some cases where the
>>> > forcible
>>> > reset-assert is not preferred.
>>> >
>>> > For example, the earlycon. When we use earlycon, we would expect it has
>>> > been
>>> > initialized by a boot-loader, or something.
>>> > If it is reset-asserted on the while, the console output
>>> > will not be good.
>>>
>>> indeed, so let's skip this idea
>>
>> Maybe we should at first add initial reset assertion to the Meson driver
>> on a case by case bases?
> this seems simple enough to test it - we can still generalize this
> later on (either by adding support to the reset framework, DT bindings
> or something else)
>
>> We can't add required reset hog DT bindings to the Meson reset
>> controller anyway without breaking DT backwards compatibility.
>>
>>> > > - specify a list of reset lines and their desired state (or to keep it
>>> > > easy: specify a list of reset lines that should be asserted)
>>> > > (I must admit that this is basically your idea but the definition is
>>> > > moved from device-tree to the reset controller driver)
>>> >
>>> > Yes, I think the l
Re: [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
* nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly
> when CONFIG_STRICT_KERNEL_RWX=y
>
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
>
> Signed-off-by: nixiaoming
> ---
> arch/x86/mm/init_32.c | 2 ++
> arch/x86/mm/init_64.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c893c6a..121c567 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
> if (__supported_pte_mask & _PAGE_NX)
> debug_checkwx();
> }
> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 0a40060..1b7a1a7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
>*/
> pti_clone_kernel_text();
> }
> +#endif
NAK, this is very ugly and the changelog doesn't appear to be true: the build
warning does not trigger in the default build, correct?
Thanks,
Ingo
Re: [GIT PULL rcu/next] Additional RCU commit for 4.18
* Paul E. McKenney wrote: > Hello, Ingo, > > This additional v4.18 pull request contains a single commit that fell > through the cracks: > > 1.Provide early rcu_cpu_starting() callback for the benefit of the > x86/mtrr code, which needs RCU to be available on incoming CPUs > earlier than has been the case in the past. > > http://lkml.kernel.org/r/20180525191802.ga7...@linux.vnet.ibm.com > > All of these changes have been subjected to 0day Test Robot and -next > testing, and are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > for-mingo > > for you to fetch changes up to f64c6013a2029316ea552f99823d116ee5f5f955: > > rcu/x86: Provide early rcu_cpu_starting() callback (2018-05-22 16:12:26 > -0700) > > > Peter Zijlstra (1): > rcu/x86: Provide early rcu_cpu_starting() callback > > arch/x86/kernel/cpu/mtrr/main.c | 4 > include/linux/rcupdate.h| 1 - > include/linux/rcutiny.h | 1 + > include/linux/rcutree.h | 1 + > kernel/rcu/tree.c | 9 + > 5 files changed, 15 insertions(+), 1 deletion(-) Pulled, thanks a lot Paul! Ingo
Re: [PATCH 3.18 093/185] microblaze: switch to NO_BOOTMEM
On 29.5.2018 16:34, Rob Herring wrote: > On Mon, May 28, 2018 at 5:02 AM, Greg Kroah-Hartman > wrote: >> 3.18-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> From: Rob Herring >> >> [ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542 ] >> >> Microblaze doesn't set CONFIG_NO_BOOTMEM and so memblock_virt_alloc() >> doesn't work for CONFIG_HAVE_MEMBLOCK && !CONFIG_NO_BOOTMEM. > > Unless Michal feels differently, I don't think this should go in > stable. The DT change that broke microblaze is only in 4.16 . yes. It is not needed. Thanks, Michal
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 29, 2018 at 10:14:35PM -0700, John Stultz wrote:
> On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> > On 2018년 05월 09일 08:17, John Stultz wrote:
> >> Hey folks,
> >> I wanted to bring up an issue we've recently tripped over, which was
> >> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
> >> devfreq(X) for sysfs").
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
> >>
> >> That patch replaced paths like:
> >>/sys/class/devfreq/ddr_devfreq/min_freq
> >> and
> >> /sys/class/devfreq/e82c.mali/min_freq
> >>
> >> With
> >> /sys/class/devfreq/devfreq(0)/min_freq
> >> and
> >> /sys/class/devfreq/devfreq(1)/min_freq
> >>
> >>
> >> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
> >> on).
> >
> > Firstly, I'm sorry to make some problem on userland.
> >
> >>
> >> I wanted to try to ask to understand more about the rational for this
> >> patch, as it doesn't make much sense to me, particularly as now it is
> >> less obvious as to which path is for which device - and more
> >> worrisome it could change depending on initialization order.
> >
> > Some linux framework used the their own prefix under "/sys/class/"
> > for device such as input/pwm/hwmon/regulator and so on.
> > (But, some linux framework used the device name directly without any
> > changes)
> >
> > I thought that devfreq better to use use the consistent name.
> > If user wanted to access the specific device with device name,
> > the user can access the path of '/sys/devices/platform/...'.
> >
> > [Example on Exynos5433-based TM2 board]
> > root@localhost:~# ls -al /sys/class/devfreq
> > total 0
> > drwxr-xr-x 2 root root 0 Jul 26 04:49 .
> > drwxr-xr-x 50 root root 0 Jan 1 1970 ..
> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
> > ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
> > ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
> > (skip)
> >
> > - User can access the devfreq device with specific device name.
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
> > /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
> >
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
> > available_frequencies devicemin_freq subsystemuevent
> > available_governorsgovernor polling_interval target_freq
> > cur_freq max_freq power trans_stat
> >
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
> > min_freq
> > 16000
> >
>
> Sorry to not get back to you sooner on this. Was on vacation then this
> discussion got buried in my inbox.
>
> I do agree that it the consistency with other subsystems is an
> improvement, but it still doesn't help our situation that userspace
> applications can't consistently work between kernel versions, as even
> if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
> path rather then the /sys/class/devfreq/ path, in older kernels the
> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
Ick, that's not ok. The sys/class/ path should always work for old and
new. If not, it's broken and should be reverted.
And it seems like it still works, just that the "names" are now
different in the class path, of the device, right? And that should be
fine, what is breaking when a device name changes?
> > But, there is one of my mistake. The /sys/class/devfreq/devfreq(X)
> > doesn't have the 'name' attribute. So, the user cannot find the required
> > device. It is my mistake. I'll add the 'name' attribute as following:
> > - /sys/class/devfreq/devfreqX/name
>
> I agree that would be an improvement.
>
> >> Unfortunately, this wasn't noticed very quickly, as the patch has been
> >> upstream now for some time. But I wanted to better understand why
> >> this change was made, and see if we might consider reverting it, or
> >> alternatively consider provide multiple sysfs links (both dev_name and
> >> devfreq(N)) so that we can preserve compatibility?
> >
> > Unfortunately, there are no frameworks which provide the both dev_name and
> > [defined prefix](N) link under /sys/class/. I'm not sure this way.
> >
> > As you comment, devfreq(number) is not fixed as the initialization order.
> > After adding the 'name' attribute, the user can find the specific device.
> >
> > How about using the 'name' attribute to find the device
> > after adding new 'name' attribute when access device through /sys/class?
>
> I agree we need a name attribute so folks can tell the difference
> between devices.
>
> I'm also not too much of a stickler that the old ABI broke, as long as
> we have some solution that works across kernels. So I'd request that
> you at least make older -stable kernels (4.4 and 4.9) behavior
> consistent with upstream.
No, I don't want to backport api changes
Re: [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
Hi, On Tue, May 22, 2018 at 7:43 PM, David Collins wrote: > + * @ever_enabled: Boolean indicating that the regulator has been > + * explicitly enabled at least once. Voltage > + * requests should be cached when this flag is > not > + * set. Do you really need this extra boolean? Can't you just check if "enabled" is still "-EINVAL"? If it is then you don't pass the voltage along. ...this would mean that you'd also need to send the voltage vote when the regulator core tries to disable unused regulators at the end of bootup, but that should be OK right? If we never touched a regulator anywhere at probe time and we're about to vote to disable it, we know there's nobody requiring it to still be on. We can vote for the voltage now without fear of messing up a vote that the BIOS left in place. In theory this should also allow you to assert your vote about the voltage of a regulator that has never been enabled, which (if I understand correctly) you consider to be a feature. --- Other than that comment, everything else here looks good to go if Mark is good with it. As per the previous threads there are some things that I don't like a ton, but I feel it is between you and Mark to decide if you're good with it. A summary of those issues are: 1. I still believe that when we disable a regulator in Linux we should tell RPMh that we vote for the lowest voltage. ...but if Mark is happy with the way the driver works now I won't push it. 2. As per my comments in the bindings patch, I still believe that "qcom,drms-mode-max-microamps" belongs in the core. Again, up to Mark. 3. As per my comments in the bindings patch, I still believe that we're just adding lots of noise to the DT most of the time by specifying both "qcom,regulator-drms-modes" and "regulator-allowed-modes". Again, up to Mark. -Doug
Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi, On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote: > On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote: >> On Wed, May 23, 2018 at 8:40 AM, Mark Brown wrote: > >> > It's got to be valid to think about the voltage of a disabled regulator >> > since drivers want to be able make sure that the regulator gets enabled >> > with a sensible config. With most hardware this is really easy since >> > you can just look at the status reported by the hardware but the RPM >> > makes this hard since there's so much write only stuff in there. > >> I should be more clear. Certainly it should be valid to set the >> voltage before enabling it so, as you said, the regulator turns on at >> the right voltage. I'm saying that it's weird (to me) to expect that >> setting the voltage for a regulator that a client thinks is disabled >> will affect any real voltages in the system until the regulator is >> enabled. In RPMh apparently setting a voltage of a regulator you >> think is disabled can affect the regulator output if another client >> (unbeknownst to you) happens to have it enabled. > > Yes, that's definitely not what's expected but it's unfortunately what > the firmware chose to implement so we may well be stuck with it > unfortunately. We're not really stuck with it if we do what I was suggesting. I was suggesting that every time we disable the regulator in Linux we have Linux vote for the lowest voltage it's comfortable with. Linux keeps track of the true voltage that the driver wants and will always change its vote back to that before enabling. Thus (assuming Linux is OK with 1.2 V - 1.4 V for a rail): Modem: want 1.3 V and enabled. => Modem votes for 1.3 V => Modem votes for enabled. => At least one vote for enabled? Yes => Highest voltage vote: 1.3V => True output: 1.3V Linux: want 1.4 V and enabled. => Linux votes for 1.4 V => Linux votes for enabled => At least one vote for enabled? Yes => Highest voltage vote: 1.4V => True output: 1.4V Linux: want disabled => Linux votes for disabled => Linux votes for 1.2 V (keeps 1.4 V in local var) => At least one vote for enabled? Yes => Highest voltage vote: 1.3V => True output: 1.3V Linux: want enabled => Linux votes for 1.4 V (from local var) => Linux votes for enabled => At least one vote for enabled? Yes => Highest voltage vote: 1.4V => True output: 1.4V ...but I'll leave it to you if you think this is a big deal. If you're happy with how David's driver works without my suggestion then I won't push it. -Doug
Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> +
> +Examples
> +
> +
> +#include
> +
> +&apps_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
> +
> + smps2 {
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <110>;
> + };
> +
> + pm8998_s5: smps5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <204>;
> + };
> +
> + ldo7 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> + regulator-allowed-modes =
> ++RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + qcom,regulator-drms-modes =
> ++RPMH_REGULATOR_MODE_HPM>;
> + qcom,drms-mode-max-microamps = <1 100>;
Things look pretty good to me now. I'm still hesitant about the whole
need to list the modes twice (once using the unordered
"regulator-allowed-modes" and once to match up against the ordered
"qcom,drms-mode-max-microamps"). I'm also still of the opinion that
the whole "drms-mode-max-microamps" ought to be a standard property
(not a qcom specific one) and handled in the regulator core.
However, for both of these things I leave it to the discretion of Mark
to choose what he wants. Thus assuming Mark is OK with these two
things, feel free to add my Reviewed-by.
-Doug
[PATCH] drivers: of: of_reserved_mem: detect count overflow or range overlap
During development, number of reserved memory region could be increased
and a new region could be unwantedly overlapped. In that case the new
region may work well but one of exisiting region could be affected so
that it would not be defined properly. It may require time consuming
work to find reason that there is a newly added region.
If a newly added region invoke kernel panic, it will be helpful. This
patch records if there is count overflow or range overlap, and invoke
panic if that case.
These are test example based on v4.9.
Case 1 - out of region count
<3>[0.00] [0:swapper:0] OF: reserved mem: not enough space
all defined regions.
<0>[1.688695] [6: swapper/0:1] Kernel panic - not syncing:
overflow on reserved memory, check the latest change
<4>[1.688743] [6: swapper/0:1] CPU: 6 PID: 1 Comm: swapper/0 Not
tainted 4.9.65+ #10
<4>[1.688836] [6: swapper/0:1] Call trace:
<4>[1.688869] [6: swapper/0:1] []
dump_backtrace+0x0/0x248
<4>[1.688913] [6: swapper/0:1] []
show_stack+0x18/0x28
<4>[1.688958] [6: swapper/0:1] []
dump_stack+0x98/0xc0
<4>[1.689001] [6: swapper/0:1] []
panic+0x1e0/0x404
<4>[1.689046] [6: swapper/0:1] []
check_reserved_mem+0x40/0x50
<4>[1.689091] [6: swapper/0:1] []
do_one_initcall+0x54/0x214
<4>[1.689138] [6: swapper/0:1] []
kernel_init_freeable+0x198/0x24c
<4>[1.689187] [6: swapper/0:1] []
kernel_init+0x18/0x144
<4>[1.689229] [6: swapper/0:1] []
ret_from_fork+0x10/0x40
Case 2 - overlapped region
<3>[0.00] [0:swapper:0] OF: reserved mem: OVERLAP DETECTED!
<0>[2.309331] [2: swapper/0:1] Kernel panic - not syncing:
reserved memory overlap, check the latest change
<4>[2.309398] [2: swapper/0:1] CPU: 2 PID: 1 Comm: swapper/0 Not
tainted 4.9.65+ #14
<4>[2.309508] [2: swapper/0:1] Call trace:
<4>[2.309546] [2: swapper/0:1] []
dump_backtrace+0x0/0x248
<4>[2.309599] [2: swapper/0:1] []
show_stack+0x18/0x28
<4>[2.309652] [2: swapper/0:1] []
dump_stack+0x98/0xc0
<4>[2.309701] [2: swapper/0:1] []
panic+0x1e0/0x404
<4>[2.309751] [2: swapper/0:1] []
check_reserved_mem+0x4c/0x50
<4>[2.309802] [2: swapper/0:1] []
do_one_initcall+0x54/0x214
<4>[2.309856] [2: swapper/0:1] []
kernel_init_freeable+0x198/0x24c
<4>[2.309913] [2: swapper/0:1] []
kernel_init+0x18/0x144
<4>[2.309961] [2: swapper/0:1] []
ret_from_fork+0x10/0x40
Signed-off-by: Jaewon Kim
---
drivers/of/of_reserved_mem.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 9a4f4246231d..e97d5c5dcc9a 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -65,6 +65,7 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
#endif
+static bool rmem_overflow;
/**
* res_mem_save_node() - save fdt node for second pass initialization
*/
@@ -75,6 +76,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node,
const char *uname,
if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
pr_err("not enough space all defined regions.\n");
+ rmem_overflow = true;
return;
}
@@ -221,6 +223,7 @@ static int __init __rmem_cmp(const void *a, const void *b)
return 0;
}
+static bool rmem_overlap;
static void __init __rmem_check_for_overlap(void)
{
int i;
@@ -245,6 +248,7 @@ static void __init __rmem_check_for_overlap(void)
pr_err("OVERLAP DETECTED!\n%s (%pa--%pa) overlaps with
%s (%pa--%pa)\n",
this->name, &this->base, &this_end,
next->name, &next->base, &next_end);
+ rmem_overlap = true;
}
}
}
@@ -419,3 +423,13 @@ struct reserved_mem *of_reserved_mem_lookup(struct
device_node *np)
return NULL;
}
EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
+
+static int check_reserved_mem(void)
+{
+ if (rmem_overflow)
+ panic("overflow on reserved memory, check the latest change");
+ if (rmem_overlap)
+ panic("overlap on reserved memory, check the latest change");
+ return 0;
+}
+late_initcall(check_reserved_mem);
--
2.13.0
Re: [PATCH] ext4: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers I'll note that the ext4 superblock fields are *not* guaranteed to be NULL terminated. Code that references them must, and do, deal with this appropriately. See for example: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/e2p/ls.c#n436 GCC-8 may whine about it, but the whine is, in fact, not correct. It's making assumptions about all strings being null terminated, which is often, but not always, the case. Cheers, - Ted
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> On 2018년 05월 09일 08:17, John Stultz wrote:
>> Hey folks,
>> I wanted to bring up an issue we've recently tripped over, which was
>> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
>> devfreq(X) for sysfs").
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
>>
>> That patch replaced paths like:
>>/sys/class/devfreq/ddr_devfreq/min_freq
>> and
>> /sys/class/devfreq/e82c.mali/min_freq
>>
>> With
>> /sys/class/devfreq/devfreq(0)/min_freq
>> and
>> /sys/class/devfreq/devfreq(1)/min_freq
>>
>>
>> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
>> on).
>
> Firstly, I'm sorry to make some problem on userland.
>
>>
>> I wanted to try to ask to understand more about the rational for this
>> patch, as it doesn't make much sense to me, particularly as now it is
>> less obvious as to which path is for which device - and more
>> worrisome it could change depending on initialization order.
>
> Some linux framework used the their own prefix under "/sys/class/"
> for device such as input/pwm/hwmon/regulator and so on.
> (But, some linux framework used the device name directly without any changes)
>
> I thought that devfreq better to use use the consistent name.
> If user wanted to access the specific device with device name,
> the user can access the path of '/sys/devices/platform/...'.
>
> [Example on Exynos5433-based TM2 board]
> root@localhost:~# ls -al /sys/class/devfreq
> total 0
> drwxr-xr-x 2 root root 0 Jul 26 04:49 .
> drwxr-xr-x 50 root root 0 Jan 1 1970 ..
> lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
> ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
> lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
> ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
> (skip)
>
> - User can access the devfreq device with specific device name.
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
>
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
> available_frequencies devicemin_freq subsystemuevent
> available_governorsgovernor polling_interval target_freq
> cur_freq max_freq power trans_stat
>
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
> min_freq
> 16000
>
Sorry to not get back to you sooner on this. Was on vacation then this
discussion got buried in my inbox.
I do agree that it the consistency with other subsystems is an
improvement, but it still doesn't help our situation that userspace
applications can't consistently work between kernel versions, as even
if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
path rather then the /sys/class/devfreq/ path, in older kernels the
/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
> But, there is one of my mistake. The /sys/class/devfreq/devfreq(X)
> doesn't have the 'name' attribute. So, the user cannot find the required
> device. It is my mistake. I'll add the 'name' attribute as following:
> - /sys/class/devfreq/devfreqX/name
I agree that would be an improvement.
>> Unfortunately, this wasn't noticed very quickly, as the patch has been
>> upstream now for some time. But I wanted to better understand why
>> this change was made, and see if we might consider reverting it, or
>> alternatively consider provide multiple sysfs links (both dev_name and
>> devfreq(N)) so that we can preserve compatibility?
>
> Unfortunately, there are no frameworks which provide the both dev_name and
> [defined prefix](N) link under /sys/class/. I'm not sure this way.
>
> As you comment, devfreq(number) is not fixed as the initialization order.
> After adding the 'name' attribute, the user can find the specific device.
>
> How about using the 'name' attribute to find the device
> after adding new 'name' attribute when access device through /sys/class?
I agree we need a name attribute so folks can tell the difference
between devices.
I'm also not too much of a stickler that the old ABI broke, as long as
we have some solution that works across kernels. So I'd request that
you at least make older -stable kernels (4.4 and 4.9) behavior
consistent with upstream.
thanks
-john
Re: linux-next: manual merge of the irqchip tree with the arm-soc tree
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
Hi Marc
On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>
> On 29/05/18 08:41, Alexandre Torgue wrote:
>>
>> Hi Stephen
>>
>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>
>>> Hi all,
>>>
>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>
>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>
>>> between commit:
>>>
>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to
>>> stm32mp157c")
>>>
>>> from the arm-soc tree and commit:
>>>
>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for
>>> stm32mp157c")
>>>
>>> from the irqchip tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your
>>> tree
>>> is submitted for merging. You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any
>>> particularly
>>> complex conflicts.
>>>
>>
>> Thanks for the fix (I will reorder nodes in a future patch). My
>> opinion
>> is that all STM32 DT patches should come through my STM32 tree. It is
>> my
>> role to fix this kind of conflicts. I thought it was a common rule
>> (driver patches go to sub-system maintainer tree and DT to the Machine
>> maintainer). For incoming next-series which contain DT+driver patches
>> I
>> will indicate clearly that I take DT patch. I'm right ?
>
> Happy to oblige. Can you make sure you sync up with Ludovic and define
> what you want to do?
Sorry I don't understand your reply. I just say that for series
containing DT patches + drivers patches, to my point of view it is more
safe that driver patches are taken by sub-system maintainer (you in this
case) and that I take DT patches in my tree.
>>>
>>> And I'm happy to let you deal with these patches. I'm just asking you
>>> sync with Ludovic to split the series on whichever boundary you wish to
>>> enforce.
>>
>> ok
>>
>>>
> In the meantime, I'm dropping the series altogether.
>
Why? We could keep it as Stephen fixed the merge issue.
>>>
>>> Well, you seem to have a strong opinion about who deals with what. I'll
>>> let Ludovic repost what you and him decide should go via the irqchip
>>> tree.
>>
>>
>> It's not a "strong" opinion just my point of view and maybe not the good
>> one. I thought that's the way of working was like I explained. If you prefer
>> 2 series (one for driver patches and another one for DT patches) I will be
>> happy with that.
>>
>> Ludovic, what is your opinion ?
>
>
> Hi everybody
>
> For this serie, I think we could keep like that with
> Stephen fix. New stm32 irqchip will be integrated (thanks Marc)
> with no conflict with usb (thanks Stephen).
>
> For next series, we may split driver and DT to avoid misunderstanding.
The general rule that we try to use is to always merge DT through the
arm-soc tree, even if the driver gets merged through the subsystem
tree. There should be no harm in doing this for new drivers (i.e. a
new driver won't regress if the DT update is missing, it just won't
probe/configure). And that way we can keep the conflicts internal to
our tree (ideally to the SoC maintainer tree) and not cause overhead
for other maintainers and Stephen.
So yes, for the future please do not submit the DT updates with the
drivers, or at the very least be very clear when you post them that
you don't want the driver maintainer to apply them.
-Olof
linux-next: manual merge of the regulator tree with the arm-soc tree
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
from the regulator tree.
I fixed it up (see below - it may be better done) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276,759fa18f6ab4..
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -203,10 -203,8 +203,10 @@@ static struct resource latch2_resources
},
};
- #define LATCH2_LABEL "latch2"
++#define LATCH2_LABEL "ams-delta-latch2"
+
static struct bgpio_pdata latch2_pdata = {
- .label = "ams-delta-latch2",
+ .label = LATCH2_LABEL,
.base = AMS_DELTA_LATCH2_GPIO_BASE,
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
@@@ -303,6 -288,16 +302,15 @@@ static struct platform_device modem_nre
},
};
+ static struct gpiod_lookup_table modem_nreset_gpiod_table = {
+ .dev_id = "reg-fixed-voltage",
+ .table = {
- /* The AMS_DELTA_GPIO_PIN_MODEM_NRESET is at offset 12 */
- GPIO_LOOKUP("ams-delta-latch2", 12,
++ GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_MODEM_NRESET,
+ "enable", GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
struct modem_private_data {
struct regulator *regulator;
};
@@@ -658,15 -581,7 +666,15 @@@ static int __init late_init(void
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+ /*
+ * As soon as devices have been registered, assign their dev_names
+ * to respective GPIO lookup tables before they are added.
+ */
+ ams_delta_lcd_gpio_table.dev_id = dev_name(&ams_delta_lcd_device.dev);
+ ams_delta_nand_gpio_table.dev_id = dev_name(&ams_delta_nand_device.dev);
+
+ gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
-
+ gpiod_add_lookup_table(&modem_nreset_gpiod_table);
err = platform_device_register(&modem_nreset_device);
if (err) {
pr_err("Couldn't register the modem regulator device\n");
pgps02iybZDpN.pgp
Description: OpenPGP digital signature
[PATCH] ANDROID: binder: rename parameter to resolve name collision.
From: Kuang Rufan
both bind.c & binder_alloc.c define the same kernel parameter 'debug_mask',
rename the one in binder_alloc.c to 'alloc_debug_mask'.
Signed-off-by: Kuang Rufan
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 5a426c877dfb..3850dab493d4 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -42,7 +42,7 @@ enum {
};
static uint32_t binder_alloc_debug_mask;
-module_param_named(debug_mask, binder_alloc_debug_mask,
+module_param_named(alloc_debug_mask, binder_alloc_debug_mask,
uint, 0644);
#define binder_alloc_debug(mask, x...) \
--
2.15.1 (Apple Git-101)
Re: [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
On Tue, May 29, 2018 at 04:10:24PM +, Kani, Toshi wrote: > Can you explain why you think allocating a page here is a major problem? Because a larger allocation is more likely to fail. And if you fail the allocation, you also fail to free more pages, which _is_ a problem. So better avoid any allocations in code paths that are about freeing memory. > If we just revert, please apply patch 1/3 first. This patch address the > BUG_ON issue on PAE. This is a real issue that needs a fix ASAP. It does not address the problem of dirty page-walk caches on x86-64. > The page-directory cache issue on x64, which is addressed by patch 3/3, > is a theoretical issue that I could not hit by putting ioremap() calls > into a loop for a whole day. Nobody hit this issue, either. How do you know you didn't hit that issue? It might cause silent data corruption, which might not be easily detected. > The simple revert patch Joerg posted a while ago causes > pmd_free_pte_page() to fail on x64. This causes multiple pmd mappings > to fall into pte mappings on my test systems. This can be seen as a > degradation, and I am afraid that it is more harmful than good. The plain revert just removes all the issues with the dirty TLB that the original patch introduced and prevents huge mappings from being established when there have been smaller mappings before. This is not ideal, but at least its is consistent and does not leak pages and leaves no dirty TLBs. So this is the easiest and most reliable fix for this stage in the release process. Regards, Joerg
Re: [PATCH] PCI: Add pci=safemode option
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote: > On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote: > > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote: > >> Adding pci=safemode kernel command line parameter to turn off all PCI > >> Express service driver as well as all optional PCIe features such as LTR, > >> Extended tags, Relaxed Ordering etc. > >> > >> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be > >> reconfigured with by the kernel in case BIOS hands off a broken > >> configuration. > > > > Why not fix the BIOS? That's what sane platforms do :) > > > >> > >> Signed-off-by: Sinan Kaya > >> --- > >> Documentation/admin-guide/kernel-parameters.txt | 2 ++ > >> drivers/pci/pci.c | 7 +++ > >> drivers/pci/pci.h | 2 ++ > >> drivers/pci/pcie/portdrv_core.c | 2 +- > >> drivers/pci/probe.c | 6 ++ > >> 5 files changed, 18 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/admin-guide/kernel-parameters.txt > >> b/Documentation/admin-guide/kernel-parameters.txt > >> index 641ec9c..247adbb 100644 > >> --- a/Documentation/admin-guide/kernel-parameters.txt > >> +++ b/Documentation/admin-guide/kernel-parameters.txt > >> @@ -3153,6 +3153,8 @@ > >>noari do not use PCIe ARI. > >>noats [PCIE, Intel-IOMMU, AMD-IOMMU] > >>do not use PCIe ATS (and IOMMU device IOTLB). > >> + safemodeturns of all optinal PCI features. Useful > >> + for bringup/troubleshooting. > > > > s/optinal/optional/ ? > > sure. > > > > > And you should explain what exactly in PCI is "optional". Who defines > > this and where is that list and what can go wrong if those options are > > not enabled? > > Bjorn and I discussed the need for such a "safe" mode feature when you > want to bring up PCI for a platform. You want to turn off everything as > a starter and just stick to bare minimum. > > I can add a few words describing them. The goal of this option is to keep > base PCI features with MSI only. Things like PME, AER, ASPM, Extended > Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode > is certainly not intended for production environments. Ok, then you should say that here, or somewhere, so that people know this. Otherwise people will see that "hey this lets my hardware boot!" and then never change it :( > I can taint the kernel as a suggestion. I would not worry about that. > I defined minimum as just booting a device and to be able to do DMA traffic > only with 0 optimization Ok, again, just document this really well, so that people do not have questions and start wondering why their devices barely seem to work. thanks, greg k-h
RE: [kbuild-all] include/linux/syscalls.h:211:18: error: 'sys_sparc_remap_file_pages' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, l
>
> Hi Al,
>
> FYI, the error/warning still remains.
hi AI, kindly ignore this, the warning below may be caused by gcc-8.1 upgrade.
we will double check to reduce noises.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 0044cdeb731313f20b63cb5644de7588731de32b
> commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
> sparc_remap_file_pages() to SYSCALL_DEFINE
> date: 2 months ago
> config: sparc-defconfig (attached as .config)
> compiler: sparc-linux-gcc (GCC) 8.1.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-
> tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout a0d32ad366bb4235267380b341fcae8307f51044
> # save the attached .config to linux build tree
> make.cross ARCH=sparc
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between
> functions of
> incompatible types 'long int(long unsigned int, long unsigned int, long
> unsigned
> int, long unsigned int, long unsigned int, long unsigned int)' and 'long
> int(long int,
> long int, long int, long int, long int, long int)'
> [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:201:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
> 'SYSCALL_DEFINE6'
> SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> ^~~
>include/linux/syscalls.h:215:18: note: aliased declaration here
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:201:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
> 'SYSCALL_DEFINE6'
> SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> ^~~
>include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
> functions of incompatible types 'long int(char *, int)' and 'long int(long
> int, long
> int)' [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:197:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
> 'SYSCALL_DEFINE2'
> SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
> ^~~
>include/linux/syscalls.h:215:18: note: aliased declaration here
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:197:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
> 'SYSCALL_DEFINE2'
> SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
> ^~~
>include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
> functions
> of incompatible types 'long int(int, const struct sigaction *, struct
> sigaction *, void
> *, size_t)' {aka 'long int(int, const struct sigaction *, struct sigaction
> *, void *,
> unsigned int)'} and 'long int(long int, long int, long int, long int,
> long int)' [-
> Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:200:36:
Re: [PATCH] perf hists browser: Fix stale hist_entry__tui_annotate() declaration
Hi Arnaldo,
On Wed, May 30, 2018 at 12:49:27PM +0800, Leo Yan wrote:
> Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
> from tool to browser") has added extra parameter for functions, but it
> missed to update hist_entry__tui_annotate() declaration for
> !HAVE_SLANG_SUPPORT configuration so this results in regression for perf
> tool building failure.
>
> This patch is to update hist_entry__tui_annotate() declaration for
> new added argument '*annotation_opts'.
Seems to me this fixing should be merged into the patch "perf hists
browser: Pass annotation_options from tool to browser" because I
encountered this issue on perf/core branch. Just remind for this.
Thanks,
Leo Yan
> Signed-off-by: Leo Yan
> ---
> tools/perf/util/hist.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
> index 5f30758..cafafbf 100644
> --- a/tools/perf/util/hist.h
> +++ b/tools/perf/util/hist.h
> @@ -460,7 +460,8 @@ static inline int map_symbol__tui_annotate(struct
> map_symbol *ms __maybe_unused,
>
> static inline int hist_entry__tui_annotate(struct hist_entry *he
> __maybe_unused,
> struct perf_evsel *evsel
> __maybe_unused,
> -struct hist_browser_timer *hbt
> __maybe_unused)
> +struct hist_browser_timer *hbt
> __maybe_unused,
> +struct annotation_options
> *annotation_opts __maybe_unused)
> {
> return 0;
> }
> --
> 2.7.4
>
Re: [PATCH 2/2] cpufreq: Use static SRCU initializer
On 25-05-18, 12:19, Sebastian Andrzej Siewior wrote:
> Use the static SRCU initializer for `cpufreq_transition_notifier_list'.
> This avoids the init_cpufreq_transition_notifier_list() initcall. Its
> only purpose is to initialize the SRCU notifier once during boot and set
> another variable which is used as an indicator whether the init was
> perfromed before cpufreq_register_notifier() was used.
>
> Cc: "Rafael J. Wysocki"
> CC: Viresh Kumar
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/cpufreq/cpufreq.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 075d18f6ba7a..3f7b502cfb1e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -89,16 +89,7 @@ static void cpufreq_governor_limits(struct cpufreq_policy
> *policy);
> * The mutex locks both lists.
> */
> static BLOCKING_NOTIFIER_HEAD(cpufreq_policy_notifier_list);
> -static struct srcu_notifier_head cpufreq_transition_notifier_list;
> -
> -static bool init_cpufreq_transition_notifier_list_called;
> -static int __init init_cpufreq_transition_notifier_list(void)
> -{
> - srcu_init_notifier_head(&cpufreq_transition_notifier_list);
> - init_cpufreq_transition_notifier_list_called = true;
> - return 0;
> -}
> -pure_initcall(init_cpufreq_transition_notifier_list);
> +SRCU_NOTIFIER_HEAD_STATIC(cpufreq_transition_notifier_list);
>
> static int off __read_mostly;
> static int cpufreq_disabled(void)
> @@ -1764,8 +1755,6 @@ int cpufreq_register_notifier(struct notifier_block
> *nb, unsigned int list)
> if (cpufreq_disabled())
> return -EINVAL;
>
> - WARN_ON(!init_cpufreq_transition_notifier_list_called);
> -
> switch (list) {
> case CPUFREQ_TRANSITION_NOTIFIER:
> mutex_lock(&cpufreq_fast_switch_lock);
Acked-by: Viresh Kumar
--
viresh
include/linux/syscalls.h:211:18: error: 'sys_sparc_remap_file_pages' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned i
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
sparc_remap_file_pages() to SYSCALL_DEFINE
date: 2 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a0d32ad366bb4235267380b341fcae8307f51044
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
of incompatible types 'long int(long unsigned int, long unsigned int, long
unsigned int, long unsigned int, long unsigned int, long unsigned int)' and
'long int(long int, long int, long int, long int, long int, long int)'
[-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
functions of incompatible types 'long int(char *, int)' and 'long int(long int,
long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction, int, sig,
^~~
[PATCH] perf hists browser: Fix stale hist_entry__tui_annotate() declaration
Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
from tool to browser") has added extra parameter for functions, but it
missed to update hist_entry__tui_annotate() declaration for
!HAVE_SLANG_SUPPORT configuration so this results in regression for perf
tool building failure.
This patch is to update hist_entry__tui_annotate() declaration for
new added argument '*annotation_opts'.
Signed-off-by: Leo Yan
---
tools/perf/util/hist.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 5f30758..cafafbf 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -460,7 +460,8 @@ static inline int map_symbol__tui_annotate(struct
map_symbol *ms __maybe_unused,
static inline int hist_entry__tui_annotate(struct hist_entry *he
__maybe_unused,
struct perf_evsel *evsel
__maybe_unused,
- struct hist_browser_timer *hbt
__maybe_unused)
+ struct hist_browser_timer *hbt
__maybe_unused,
+ struct annotation_options
*annotation_opts __maybe_unused)
{
return 0;
}
--
2.7.4
[PATCH] arm64: mm: mark tramp_pg_dir read-only
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process can
then modify kernel text directly through this mapping. In this
way, an arbitrary write can be converted to multiple arbitrary
writes.
Signed-off-by: YaoJun
---
arch/arm64/mm/mmu.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..ac4b22c7e435 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ update_mapping_prot(__pa_symbol(tramp_pg_dir),
+ (unsigned long)tramp_pg_dir,
+ PGD_SIZE, PAGE_KERNEL_RO);
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
--
2.17.0
Re: [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
On 29-05-18, 15:18, Krzysztof Kozlowski wrote: > Thanks for the patch. > > In case of Exynos, the booting CPU always has these information in DT > and the booting CPU cannot be changed (chosen by firmware/hardware > configuration). But can the booting CPU be offlined ? If yes, then this is how things are broken right now. Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert cpufreq driver and that will try to find these properties in CPU1. > Therefore there is no real risk of falling although > for correctness of DT your change makes sense. > > It is too late for this cycle for me so I'll pick it up after merge window. > Alternatively, arm-soc guys can pick it up directly with my tag: > Reviewed-by: Krzysztof Kozlowski No worries, you can pick it up later on. -- viresh
Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts
On Tue, May 29, 2018 at 09:34:35PM -0500, Eric W. Biederman wrote: > Dave Chinner writes: > > > Yeah, the are some fairly big process and policy things that > > need to be decided here. Not just at the kernel level, but at > > distro and app infrastructure level too. > > > > I was originally sceptical of supporting kernel filesystems via > > lkl, but the desire for unprivileged mounts has not gone away > > and so I'm less worried about accessing filesystems that way > > than I am of letting the kernel parse untrusted images from > > untrusted users... > > There is also the more readily available libguestfs which doesn't > support as many filesystems but does seem available in most linux > distributions already. It already has a fuse option available > with guestmount. I may have to dig in there and see how to make > it available without using fusermount. That only provides host access to filesystems mounted inside guest VMs, right? AFAIA, libguestfs is not providing a FUSE implementation that mounts and parses raw XFS images. e.g it barely understands anything XFS, and that which it does is via running and screen-scraping the output of XFS's userspace management tools... > > I'm not sure what the correct forum for this is - wasn't this > > something the Plumbers conference was supposed to facilitate? > > Yes. If we all need to be in a room and talk about things. > It is early enough in the planning for Plumers that we could > definitely schedule a talk or a BOF for this. Ok. I have no idea if I'll be at plumbers - it's an awful long way from where I am Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH] PCI: move early dump functionality from x86 arch into the common code
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 --
arch/x86/pci/early.c| 50 -
drivers/pci/pci.c | 4 ++
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 19 ++
8 files changed, 25 insertions(+), 66 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index c247612..4459270 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,7 +2986,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios[X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h
b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8
offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..e20d449 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -51,53 +51,3 @@ void write_pci_config_16(u8 bus, u8 slot, u8 func, u8
offset, u16 val)
outw(val, 0xcfc + (offset&2));
}
-int early_pci_allowed(void)
-{
- return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
- PCI_PROBE_CONF1;
-}
-
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci :%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256,
false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0x)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
-
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a dedicated module for the shared code and export corresponding
> symbols for other kernel modules.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/Makefile | 1 +
> drivers/xen/balloon.c | 71 ++
> drivers/xen/mem-reservation.c | 134 ++
> include/xen/mem_reservation.h | 29
> 4 files changed, 170 insertions(+), 65 deletions(-)
> create mode 100644 drivers/xen/mem-reservation.c
> create mode 100644 include/xen/mem_reservation.h
Can you please name this include/xen/mem-reservation.h ?
>
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 451e833f5931..3c87b0c3aca6 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o
> obj-$(CONFIG_X86)+= fallback.o
> obj-y+= grant-table.o features.o balloon.o manage.o preempt.o time.o
> +obj-y+= mem-reservation.o
> obj-y+= events/
> obj-y+= xenbus/
>
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 065f0b607373..57b482d67a3a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -71,6 +71,7 @@
> #include
> #include
> #include
> +#include
>
> static int xen_hotplug_unpopulated;
>
> @@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
> balloon_process);
> #define GFP_BALLOON \
> (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
>
> -static void scrub_page(struct page *page)
> -{
> -#ifdef CONFIG_XEN_SCRUB_PAGES
> - clear_highpage(page);
> -#endif
> -}
> -
> /* balloon_append: add the given page to the balloon. */
> static void __balloon_append(struct page *page)
> {
> @@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> int rc;
> unsigned long i;
> struct page *page;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> nr_pages = ARRAY_SIZE(frame_list);
> @@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_next_page(page);
> }
>
> - set_xen_guest_handle(reservation.extent_start, frame_list);
> - reservation.nr_extents = nr_pages;
> - rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
> + rc = xenmem_reservation_increase(nr_pages, frame_list);
> if (rc <= 0)
> return BP_EAGAIN;
>
> @@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_retrieve(false);
> BUG_ON(page == NULL);
>
> -#ifdef CONFIG_XEN_HAVE_PVMMU
> - /*
> - * We don't support PV MMU when Linux and Xen is using
> - * different page granularity.
> - */
> - BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
> -
> - if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> - unsigned long pfn = page_to_pfn(page);
> -
> - set_phys_to_machine(pfn, frame_list[i]);
> -
> - /* Link back into the page tables if not highmem. */
> - if (!PageHighMem(page)) {
> - int ret;
> - ret = HYPERVISOR_update_va_mapping(
> - (unsigned long)__va(pfn <<
> PAGE_SHIFT),
> - mfn_pte(frame_list[i],
> PAGE_KERNEL),
> - 0);
> - BUG_ON(ret);
> - }
> - }
> -#endif
> + xenmem_reservation_va_mapping_update(1, &page, &frame_list[i]);
>
> /* Relinquish the page back to the allocator. */
> free_reserved_page(page);
> @@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> unsigned long i;
> struct page *page, *tmp;
> int ret;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
> LIST_HEAD(pages);
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> @@ -553,7 +513,7 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> break;
> }
> adjust_ma
Re: [PATCH] PCI: Add pci=safemode option
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote: > Adding pci=safemode kernel command line parameter to turn off all PCI > Express service driver as well as all optional PCIe features such as LTR, > Extended tags, Relaxed Ordering etc. > > Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be > reconfigured with by the kernel in case BIOS hands off a broken > configuration. Why not fix the BIOS? That's what sane platforms do :) > > Signed-off-by: Sinan Kaya > --- > Documentation/admin-guide/kernel-parameters.txt | 2 ++ > drivers/pci/pci.c | 7 +++ > drivers/pci/pci.h | 2 ++ > drivers/pci/pcie/portdrv_core.c | 2 +- > drivers/pci/probe.c | 6 ++ > 5 files changed, 18 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 641ec9c..247adbb 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -3153,6 +3153,8 @@ > noari do not use PCIe ARI. > noats [PCIE, Intel-IOMMU, AMD-IOMMU] > do not use PCIe ATS (and IOMMU device IOTLB). > + safemodeturns of all optinal PCI features. Useful > + for bringup/troubleshooting. s/optinal/optional/ ? And you should explain what exactly in PCI is "optional". Who defines this and where is that list and what can go wrong if those options are not enabled? In looking at your patch, I can't determine that at all, so there's no way that someone just looking at this sentence will be able to understand. thanks, greg k-h
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigne
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ee076e81fc14ca79334d02970cea66604f183a14
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>> include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
>> of incompatible types 'long int(long unsigned int, long unsigned int, long
>> unsigned int, long unsigned int, long unsigned int, long unsigned int)'
>> and 'long int(long int, long int, long int, long int, long int, long
>> int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
>> include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
>> functions of incompatible types 'long int(char *, int)' and 'long int(long
>> int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction,
Re: [PATCH v6 4/4] vsprintf: Add command line option debug_boot_weak_hash
On Mon, May 28, 2018 at 10:40:43AM -0700, Randy Dunlap wrote: > On 05/27/2018 06:46 PM, Tobin C. Harding wrote: > > Currently printing [hashed] pointers requires enough entropy to be > > available. Early in the boot sequence this may not be the case > > resulting in a dummy string '(ptrval)' being printed. This > > makes debugging the early boot sequence difficult. We can relax the > > requirement to use cryptographically secure hashing during debugging. > > This enables debugging while keeping development/production kernel > > behaviour the same. > > > > If new command line option debug_boot_weak_hash is enabled use > > cryptographically insecure hashing and hash pointer value immediately. > > > > Cc: Anna-Maria Gleixner > > Cc: Steven Rostedt > > Cc: Randy Dunlap > > Signed-off-by: Tobin C. Harding > > --- > > Documentation/admin-guide/kernel-parameters.txt | 9 + > > lib/vsprintf.c | 20 > > 2 files changed, 29 insertions(+) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > b/Documentation/admin-guide/kernel-parameters.txt > > index f2040d46f095..8a86d895343e 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -753,6 +753,15 @@ > > > > debug [KNL] Enable kernel debugging (events log level). > > > > Hi, > This is much more readable than the previous version. Thanks. Thanks for following up with this one Randy. Tobin
Re: [PATCH 4.16 000/272] 4.16.13-stable review
On Tue, May 29, 2018 at 01:52:12PM -0600, Shuah Khan wrote: > On 05/28/2018 04:00 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.16.13 release. > > There are 272 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed May 30 10:01:02 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.16.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 54 +--
> include/xen/grant_table.h | 3 +++
> 2 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 27be107d6480..d7488226e1f2 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
> }
> EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
>
> -/**
> - * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> - * @nr_pages: number of pages to alloc
> - * @pages: returns the pages
> - */
> -int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +int gnttab_pages_set_private(int nr_pages, struct page **pages)
> {
> int i;
> - int ret;
> -
> - ret = alloc_xenballooned_pages(nr_pages, pages);
> - if (ret < 0)
> - return ret;
>
> for (i = 0; i < nr_pages; i++) {
> #if BITS_PER_LONG < 64
> struct xen_page_foreign *foreign;
>
> foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
> - if (!foreign) {
> - gnttab_free_pages(nr_pages, pages);
> + if (!foreign)
> return -ENOMEM;
> - }
> +
> set_page_private(pages[i], (unsigned long)foreign);
> #endif
> SetPagePrivate(pages[i]);
> @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page
> **pages)
>
> return 0;
> }
> -EXPORT_SYMBOL(gnttab_alloc_pages);
> +EXPORT_SYMBOL(gnttab_pages_set_private);
EXPORT_SYMBOL_GPL()
>
> /**
> - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
> - * @nr_pages; number of pages to free
> - * @pages: the pages
> + * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> + * @nr_pages: number of pages to alloc
> + * @pages: returns the pages
> */
> -void gnttab_free_pages(int nr_pages, struct page **pages)
> +int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +{
> + int ret;
> +
> + ret = alloc_xenballooned_pages(nr_pages, pages);
> + if (ret < 0)
> + return ret;
> +
> + ret = gnttab_pages_set_private(nr_pages, pages);
> + if (ret < 0)
> + gnttab_free_pages(nr_pages, pages);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(gnttab_alloc_pages);
> +
> +void gnttab_pages_clear_private(int nr_pages, struct page **pages)
> {
> int i;
>
> @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
> ClearPagePrivate(pages[i]);
> }
> }
> +}
> +EXPORT_SYMBOL(gnttab_pages_clear_private);
EXPORT_SYMBOL_GPL()
Juergen
Re: [PATCH 3/3] f2fs: clean up symbol namespace
Hi Chao,
Thank you for the work.
I resolved some conflicts and modified some function names.
Please take a look at this.
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/dir.c| 6 +++---
fs/f2fs/f2fs.h | 10 +-
fs/f2fs/file.c | 2 +-
fs/f2fs/gc.c | 4 ++--
fs/f2fs/namei.c | 4 ++--
fs/f2fs/recovery.c | 2 +-
7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 078c2d5c5b2e..8eb184c3de84 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -24,7 +24,7 @@
#include
static struct kmem_cache *ino_entry_slab;
-struct kmem_cache *inode_entry_slab;
+struct kmem_cache *f2fs_inode_entry_slab;
void f2fs_stop_checkpoint(struct f2fs_sb_info *sbi, bool end_io)
{
@@ -1490,9 +1490,9 @@ int __init f2fs_create_checkpoint_caches(void)
sizeof(struct ino_entry));
if (!ino_entry_slab)
return -ENOMEM;
- inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
+ f2fs_inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
sizeof(struct inode_entry));
- if (!inode_entry_slab) {
+ if (!f2fs_inode_entry_slab) {
kmem_cache_destroy(ino_entry_slab);
return -ENOMEM;
}
@@ -1502,5 +1502,5 @@ int __init f2fs_create_checkpoint_caches(void)
void f2fs_destroy_checkpoint_caches(void)
{
kmem_cache_destroy(ino_entry_slab);
- kmem_cache_destroy(inode_entry_slab);
+ kmem_cache_destroy(f2fs_inode_entry_slab);
}
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index eedfa2a13786..7f955c4e86a4 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -586,7 +586,7 @@ int f2fs_add_regular_entry(struct inode *dir, const struct
qstr *new_name,
return err;
}
-int __f2fs_do_add_link(struct inode *dir, struct fscrypt_name *fname,
+int f2fs_add_dentry(struct inode *dir, struct fscrypt_name *fname,
struct inode *inode, nid_t ino, umode_t mode)
{
struct qstr new_name;
@@ -610,7 +610,7 @@ int __f2fs_do_add_link(struct inode *dir, struct
fscrypt_name *fname,
* Caller should grab and release a rwsem by calling f2fs_lock_op() and
* f2fs_unlock_op().
*/
-int __f2fs_add_link(struct inode *dir, const struct qstr *name,
+int f2fs_do_add_link(struct inode *dir, const struct qstr *name,
struct inode *inode, nid_t ino, umode_t mode)
{
struct fscrypt_name fname;
@@ -639,7 +639,7 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
*name,
} else if (IS_ERR(page)) {
err = PTR_ERR(page);
} else {
- err = __f2fs_do_add_link(dir, &fname, inode, ino, mode);
+ err = f2fs_add_dentry(dir, &fname, inode, ino, mode);
}
fscrypt_free_filename(&fname);
return err;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ba1063ed39eb..f167d01443fe 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2626,7 +2626,7 @@ static inline int get_inline_xattr_addrs(struct inode
*inode)
return F2FS_I(inode)->i_inline_xattr_size;
}
-#define get_inode_mode(i) \
+#define f2fs_get_inode_mode(i) \
((is_inode_flag_set(i, FI_ACL_MODE)) ? \
(F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
@@ -2744,9 +2744,9 @@ void f2fs_update_dentry(nid_t ino, umode_t mode, struct
f2fs_dentry_ptr *d,
int f2fs_add_regular_entry(struct inode *dir, const struct qstr *new_name,
const struct qstr *orig_name,
struct inode *inode, nid_t ino, umode_t mode);
-int __f2fs_do_add_link(struct inode *dir, struct fscrypt_name *fname,
+int f2fs_add_dentry(struct inode *dir, struct fscrypt_name *fname,
struct inode *inode, nid_t ino, umode_t mode);
-int __f2fs_add_link(struct inode *dir, const struct qstr *name,
+int f2fs_do_add_link(struct inode *dir, const struct qstr *name,
struct inode *inode, nid_t ino, umode_t mode);
void f2fs_delete_entry(struct f2fs_dir_entry *dentry, struct page *page,
struct inode *dir, struct inode *inode);
@@ -2755,7 +2755,7 @@ bool f2fs_empty_dir(struct inode *dir);
static inline int f2fs_add_link(struct dentry *dentry, struct inode *inode)
{
- return __f2fs_add_link(d_inode(dentry->d_parent), &dentry->d_name,
+ return f2fs_do_add_link(d_inode(dentry->d_parent), &dentry->d_name,
inode, inode->i_ino, inode->i_mode);
}
@@ -3190,7 +3190,7 @@ extern const struct inode_operations
f2fs_dir_inode_operations;
extern const struct inode_operations f2fs_symlink_inode_operations;
extern const struct inode_operations f2fs_encrypted_symlink_inode_operations;
extern const struct inode_operations f2fs_special_inode_operations;
-extern struct kmem_cache *inode_entry_slab;
+ex
Re: Status of aspeed-bmc-opp-firestone (IBM S822LC)
Hi Paul, On Wed, 30 May 2018, at 00:23, Paul Menzel wrote: > Dear Joel, dear Linux folks, > > > We have an IBM S822LC system (Firestone(?)). Building of OpenBMC > currently fails, as the not everything was ported from dev-4.10 to > dev-4.13 [1], and therefore a file cannot be found. > > Looking at upstream Linux, there are BMCs for Power 8 systems, like > Palmetto, included. > > ``` > $ ls arch/arm/boot/dts/aspeed-bmc-opp-* > arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts > arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts > arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts > ``` > > Does somebody know, why Firestone was not upstreamed? Is somebody > working on upstreaming it? If not, do you have scripts to port such > work? Manually cherry-picking stuff in this case is hard, as there are a > lot of conflicts. Firestone was never really maintained. We hacked around with it for a bit, but nothing concrete really came of it. As far as I'm aware, no-one is working on upstreaming it. Also, I don't think there were any scripts used in the process, so it's going to be some drudge work to get things running. Sorry that I don't have a more positive answer. Maybe someone else knows better. Cheers, Andrew
[PATCH] usb: dwc2: gadget: fix missing process for isoc descriptor dma mode
If it's the first request to queue, and we are using descriptor dma mode
for isoc transfer, we only need to add the request to the queue, and it
will be processed in the future nak interrupt handler.
Signed-off-by: Zeng Tao
---
drivers/usb/dwc2/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index f0d9ccf..48e3a48c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1365,6 +1365,9 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep, struct
usb_request *req,
return 0;
}
+ if (using_desc_dma(hs))
+ return 0;
+
/* Update current frame number value. */
hs->frame_number = dwc2_hsotg_read_frameno(hs);
while (dwc2_gadget_target_frame_elapsed(hs_ep)) {
--
2.7.4
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/29/2018 11:44 PM, Eric Dumazet wrote:
>
> And I will add this simple fix, this really should address your initial
> concern much better.
>
> @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem,
> int order,
> {
> struct page *page;
>
> + if (order)
> + gfp_mask |= __GFP_NORETRY;
and also gfp_mask &= ~__GFP_DIRECT_RECLAIM
> page = alloc_pages_node(node, gfp_mask, order);
> if (!page) {
> page = alloc_pages(gfp_mask, order);
>
RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 11:18 AM > > On Wed, 30 May 2018 01:41:43 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, May 30, 2018 4:09 AM > > > > > > On Fri, 20 Apr 2018 16:42:51 -0700 > > > Jacob Pan wrote: > > > > > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > > > Jean-Philippe Brucker wrote: > > > > > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > > > > > [...] > > > > > > > + /* Assign guest PASID table pointer and size order */ > > > > > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > > > > > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > > > > > > > > > > > Where does this IOMMU API interface define that base_ptr is 4K > > > > > > aligned or the format of the PASID table? Are these all > > > > > > standardized or do they vary by host IOMMU? If they're standards, > > > > > > maybe we could note that and the spec which defines them when > we > > > > > > declare base_ptr. If they're IOMMU specific then I don't > > > > > > understand how we'll match a user provided PASID table to the > > > > > > requirements and format of the host IOMMU. Thanks, > > > > > > > > > > On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a > > > guest > > > > > under a vSMMU might pass a pointer that's not aligned on 4k. > > > > > > > > > PASID table pointer for VT-d is 4K aligned. > > > > > Maybe this information could be part of the data passed to > userspace > > > > > about IOMMU table formats and features? They're not part of this > > > > > series, but I think we wanted to communicate IOMMU-specific > features > > > > > via sysfs. > > > > > > > > > Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU > > > > can match IOMMU model and features. > > > > > > Digging this up again since v5 still has this issue. The IOMMU API is > > > a kernel internal abstraction of the IOMMU. sysfs is a userspace > > > interface. Are we suggesting that the /only/ way to make use of the > > > internal IOMMU API here is to have a user provided opaque pasid table > > > that we can't even do minimal compatibility sanity testing on and we > > > simply hope that hardware covers all the fault conditions without > > > taking the host down with it? I guess we have to assume the latter > > > since the user has full control of the table, but I have a hard time > > > getting past lack of internal ability to use the interface and no > > > ability to provide even the slimmest sanity testing. Thanks, > > > > > > > checking size, alignment, ... is OK, which I think is already considered > > by vendor IOMMU driver. However sanity testing table format might > > be difficult. The initial table provided by guest is likely just all ZEROs. > > whatever format violation may be caught only when a PASID entry > > is updated... > > There's sanity testing the actual contents of the table, which I agree > would be difficult and would likely require some sort of shadowing at > additional overhead, but what about even basic consistency checking? > For example, is it possible that due to hardware variations a user > might generate a table which works on some systems but not others? > What > if two table formats are sufficiently similar that the IOMMU driver > puts an incompatible table in place but it continuously generates > faults, how do we debug that? As an intermediary in this whole process > I'd really rather be able to identify that the user claims to be > providing a TypeA table but the IOMMU only supports TypeB, so clearly > this won't work. I don't see that we have that capability. Thanks, > I remember we ever discussed to define some vendor/model ID, which can be retrieved by user space and then passed back when doing table binding. Then above simple model matching check can be done accordingly. It is actually a basic requirement when using virtio-iommu, same driver expecting to work on all vendor IOMMUs. However I don't remember whether/where that logic is implemented in this series (especially when there are two tracks moving in parallel). I'll leave to Jacob/Jean to further comment. Thanks Kevin
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/29/2018 11:34 PM, Eric Dumazet wrote:
> I will test :
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index
> 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097
> 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -43,12 +43,13 @@
> #include "fw.h"
>
> /*
> - * We allocate in page size (default 4KB on many archs) chunks to avoid high
> - * order memory allocations in fragmented/high usage memory situation.
> + * We allocate in as big chunks as we can, up to a maximum of 256 KB
> + * per chunk. Note that the chunks are not necessarily in contiguous
> + * physical memory.
> */
> enum {
> - MLX4_ICM_ALLOC_SIZE = PAGE_SIZE,
> - MLX4_TABLE_CHUNK_SIZE = PAGE_SIZE,
> + MLX4_ICM_ALLOC_SIZE = 1 << 18,
> + MLX4_TABLE_CHUNK_SIZE = 1 << 18
> };
>
> static void mlx4_free_icm_pages(struct mlx4_dev *dev, struct mlx4_icm_chunk
> *chunk)
>
And I will add this simple fix, this really should address your initial concern
much better.
@@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem, int
order,
{
struct page *page;
+ if (order)
+ gfp_mask |= __GFP_NORETRY;
page = alloc_pages_node(node, gfp_mask, order);
if (!page) {
page = alloc_pages(gfp_mask, order);
Re: [net] vhost: Use kzalloc() to allocate vhost_msg_node
On 05/29/2018 08:01 PM, Michael S. Tsirkin wrote:
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.
Signed-off-by: Kevin Easton
Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com
Is this patch going anywhere ?
The patch fixes CVE-2018-1118. It would be useful to understand if and when
this problem is going to be fixed.
Thanks,
Guenter
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e9..1b84dcff 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
/* Create a new message. */
struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
{
- struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
+ struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
node->vq = vq;
As I pointed out, we don't need to init the whole structure. The proper
fix is thus (I think) below.
Could you use your testing infrastructure to confirm this fixes the issue?
Sorry, I don't have the means to test the fix.
Guenter
Thanks!
Signed-off-by: Michael S. Tsirkin
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e941224..58d9aec90afb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct
vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(&node->msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
Re: [PATCH] mm: Change return type to vm_fault_t
On Tue, May 29, 2018 at 11:04 PM, Matthew Wilcox wrote:
> On Tue, May 29, 2018 at 09:25:05PM +0530, Souptick Joarder wrote:
>> On Tue, May 29, 2018 at 8:20 PM, Matthew Wilcox wrote:
>> > On Tue, May 29, 2018 at 08:01:26PM +0530, Souptick Joarder wrote:
>> >> Use new return type vm_fault_t for fault handler. For
>> >> now, this is just documenting that the function returns
>> >> a VM_FAULT value rather than an errno. Once all instances
>> >> are converted, vm_fault_t will become a distinct type.
>> >
>> > I don't believe you've checked this with sparse.
>> >
>> >> @@ -802,7 +802,8 @@ int fixup_user_fault(struct task_struct *tsk, struct
>> >> mm_struct *mm,
>> >>bool *unlocked)
>> >> {
>> >> struct vm_area_struct *vma;
>> >> - int ret, major = 0;
>> >> + int major = 0;
>> >> + vm_fault_t ret;
>> >>
>> >> if (unlocked)
>> >> fault_flags |= FAULT_FLAG_ALLOW_RETRY;
>> >
>> > ...
>> > major |= ret & VM_FAULT_MAJOR;
>> >
>> > That should be throwing a warning.
>>
>> Sorry, but I verified again and didn't see similar warnings.
>>
>> steps followed -
>>
>> apply the patch
>> make c=2 -j4 ( build for x86_64)
>> looking for warnings in files because of this patch.
>>
>> The only error I am seeing "error: undefined identifier '__COUNTER__' "
>> which is pointing to BUG(). There are few warnings but those are not
>> related to this patch.
>>
>> In my test tree the final patch to create new vm_fault_t type is
>> already applied.
>>
>> Do you want me to verify in some other way ?
>
> I see:
>
> mm/gup.c:817:15: warning: invalid assignment: |=
> mm/gup.c:817:15:left side has type int
> mm/gup.c:817:15:right side has type restricted vm_fault_t
>
> are you building with 'c=2' or 'C=2'?
Building with C=2.
Do I need to enable any separate FLAG ?
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/25/2018 10:23 AM, David Miller wrote: > From: Qing Huang > Date: Wed, 23 May 2018 16:22:46 -0700 > >> When a system is under memory presure (high usage with fragments), >> the original 256KB ICM chunk allocations will likely trigger kernel >> memory management to enter slow path doing memory compact/migration >> ops in order to complete high order memory allocations. >> >> When that happens, user processes calling uverb APIs may get stuck >> for more than 120s easily even though there are a lot of free pages >> in smaller chunks available in the system. >> >> Syslog: >> ... >> Dec 10 09:04:51 slcc03db02 kernel: [397078.572732] INFO: task >> oracle_205573_e:205573 blocked for more than 120 seconds. >> ... >> >> With 4KB ICM chunk size on x86_64 arch, the above issue is fixed. >> >> However in order to support smaller ICM chunk size, we need to fix >> another issue in large size kcalloc allocations. >> >> E.g. >> Setting log_num_mtt=30 requires 1G mtt entries. With the 4KB ICM chunk >> size, each ICM chunk can only hold 512 mtt entries (8 bytes for each mtt >> entry). So we need a 16MB allocation for a table->icm pointer array to >> hold 2M pointers which can easily cause kcalloc to fail. >> >> The solution is to use kvzalloc to replace kcalloc which will fall back >> to vmalloc automatically if kmalloc fails. >> >> Signed-off-by: Qing Huang >> Acked-by: Daniel Jurgens >> Reviewed-by: Zhu Yanjun > > Applied, thanks. > I must say this patch causes regressions here. KASAN is not happy. It looks that you guys did not really looked at mlx4_alloc_icm() This function is properly handling high order allocations with fallbacks to order-0 pages under high memory pressure. BUG: KASAN: slab-out-of-bounds in to_rdma_ah_attr+0x808/0x9e0 [mlx4_ib] Read of size 4 at addr 8817df584f68 by task qp_listing_test/92585 CPU: 38 PID: 92585 Comm: qp_listing_test Tainted: G O Call Trace: [] dump_stack+0x4d/0x72 [] print_address_description+0x6f/0x260 [] kasan_report+0x257/0x370 [] __asan_report_load4_noabort+0x19/0x20 [] to_rdma_ah_attr+0x808/0x9e0 [mlx4_ib] [] mlx4_ib_query_qp+0x1213/0x1660 [mlx4_ib] [] qpstat_print_qp+0x13b/0x500 [ib_uverbs] [] qpstat_seq_show+0x4a/0xb0 [ib_uverbs] [] seq_read+0xa9c/0x1230 [] proc_reg_read+0xc1/0x180 [] __vfs_read+0xe8/0x730 [] vfs_read+0xf7/0x300 [] SyS_read+0xd2/0x1b0 [] do_syscall_64+0x186/0x420 [] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7f851a7bb30d RSP: 002b:7ffd09a758c0 EFLAGS: 0293 ORIG_RAX: RAX: ffda RBX: 7f84ff959440 RCX: 7f851a7bb30d RDX: 0003fc00 RSI: 7f84ff60a000 RDI: 000b RBP: 7ffd09a75900 R08: R09: R10: 0022 R11: 0293 R12: R13: 0003 R14: 0003 R15: 7f84ff60a000 Allocated by task 4488: save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x101/0x5e0 ib_register_device+0xc03/0x1250 [ib_core] mlx4_ib_add+0x27d6/0x4dd0 [mlx4_ib] mlx4_add_device+0xa9/0x340 [mlx4_core] mlx4_register_interface+0x16e/0x390 [mlx4_core] xhci_pci_remove+0x7a/0x180 [xhci_pci] do_one_initcall+0xa0/0x230 do_init_module+0x1b9/0x5a4 load_module+0x63e6/0x94c0 SYSC_init_module+0x1a4/0x1c0 SyS_init_module+0xe/0x10 do_syscall_64+0x186/0x420 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Freed by task 0: (stack is not available) The buggy address belongs to the object at 8817df584f40 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 8 bytes to the right of 32-byte region [8817df584f40, 8817df584f60) The buggy address belongs to the page: page:ea005f7d6100 count:1 mapcount:0 mapping:8817df584000 index:0x8817df584fc1 flags: 0x8800100(slab) raw: 08800100 8817df584000 8817df584fc1 0001003f raw: ea005f3ac0a0 ea005c476760 8817fec00900 883ff78d26c0 page dumped because: kasan: bad access detected page->mem_cgroup:883ff78d26c0 Memory state around the buggy address: 8817df584e00: 00 03 fc fc fc fc fc fc 00 03 fc fc fc fc fc fc 8817df584e80: 00 00 00 04 fc fc fc fc 00 00 00 fc fc fc fc fc >8817df584f00: fb fb fb fb fc fc fc fc 00 00 00 00 fc fc fc fc ^ 8817df584f80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc 8817df585000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb I will test : diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c index 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097 100644 --- a/drivers/net/ethernet/mellanox/mlx4/icm.c +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c @@ -43,12 +43,13 @@ #include "fw.h" /* - * We allocate in page size (default 4KB on many archs) chunks to avoid high - * order memory allocations in fragmented/high usage memory situation. + * We allocate in as big c
RE: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64 When reading the code, I feel it is more appropriate to add macro control here. -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Tuesday, May 29, 2018 11:45 PM To: Nixiaoming Cc: catalin.mari...@arm.com; ard.biesheu...@linaro.org; marc.zyng...@arm.com; james.mo...@arm.com; kristina.martse...@arm.com; steve.cap...@arm.com; t...@linutronix.de; mi...@redhat.com; h...@zytor.com; a...@linux-foundation.org; vba...@suse.cz; mho...@suse.com; dave.han...@linux.intel.com; dan.j.willi...@intel.com; kirill.shute...@linux.intel.com; zhang@linux.alibaba.com; schwidef...@de.ibm.com; heiko.carst...@de.ibm.com; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; x...@kernel.org; linux-s...@vger.kernel.org Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote: > mark_rodata_ro is only called by the function mark_readonly when > CONFIG_STRICT_KERNEL_RWX=y, > if CONFIG_STRICT_KERNEL_RWX is not set > a compile warning may be triggered: unused function How are you achieving this configuration? In our Kconfig we select this unconditionally. Will
Re: scsi/qla2xxx: BUG_ON(blk_queued_rq(req) is triggered in blk_finish_request
Hi Himanshu
Thanks for your kindly response.
On 05/30/2018 01:44 AM, Madhani, Himanshu wrote:
> Thanks for the information. I was out for couple days. Still working through
> my emails.
>
> Without core dump shared with us, things become hard to debug. We'll take a
> look at this data.
>
> Also, if you have any reproducer test case, Can you share that with us so
> that we can try to trigger It internally and see if we have better luck
> debugging that.
This issue occurred in customer's environment twice till now, there is no
reproduce steps.
If you have time, would you please look at our analysis to see whether it is
reasonable ?
The kernel is not newest, but there should be the same issue in mainline with
scsi + block legacy
The key point here is:
when the aborted command returns in irq context, it will invoke scsi_done, then
blk_complete_request.
however, the scsi recovery context could clear the ATOM_COMPLETE and requeue
the request before irq
context get it.
Thanks
Jianchao
>
> On 5/28/18, 6:11 PM, "jianchao.wang" wrote:
>
> Hi Himanshu
>
> do you need any other information ?
>
> Thanks
> Jianchao
>
> On 05/25/2018 02:48 PM, jianchao.wang wrote:
> > Hi Himanshu
> >
> > I'm afraid I cannot provide you the vmcore file, it is from our
> customer.
> > If any information needed in the vmcore, I could provide with you.
> >
> > In this scene, there are two contexts:
> > 1. the irq context, scsi_done() from qla2x00_sp_compl()
> > 2. the kworker context, scmd_eh_abort_handler which invokes the
> > qla2xxx_eh_abort()
> >
> > Let's see the irq context.
> > scsi_done() will invoke the blk_complete_request().
> > In common case, the REQ_ATOM_COMPLETE should have been set by
> > blk_rq_check_expired() when the request was confirmed timeout. So
> > __blk_complete_request() will not be invoked.
> >
> > On the other hand, in the kworker context, scmd_eh_abort_handler() will
> do some
> > other things on this aborted request.
> >
> > rtn = scsi_try_to_abort_cmd(sdev->host->hostt, scmd);
> > if (rtn == SUCCESS) {
> > set_host_byte(scmd, DID_TIME_OUT)
> > if (scsi_host_eh_past_deadline(sdev->host)) {
> >
> > } else if (!scsi_noretry_cmd(scmd) &&
> > (++scmd->retries <= scmd->allowed)) {
> > scsi_queue_insert(scmd, SCSI_MLQUEUE_EH_RETRY)
> > }
> >
> > }
> > The host type of the result will set to DID_TIME_OUT.
> scsi_noretry_cmd() will
> > return false and scsi_queue_insert() will be invoked, finally the
> > blk_requeue_request().
> >
> > blk_requeue_request() will clear the REQ_ATOM_COMPLETE and queue the
> request on
> > request_queue->queue_head.
> >
> > There could be a race between these two contexts:
> > what if the blk_clear_rq_complete() in kworker context is invoked
> before the
> > blk_mark_rq_complete() in irq context ?
> >
> > BLK_SOFTIRQ will be raised by __blk_complete_request() in irq context.
> Then the
> > scsi_softirq_done() will be invoked. At the moment, the request has been
> > requeued by kworker context and scsi_cmnd->result is set 0. On the cpu
> of the
> > irq context, the blk_finish_request() will be invoked finally, and
> panic comes
> > up due to BUG_ON(blk_queued_rq(req)
> >
> > Here is the dmesg log.
> > [4937745.180213] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.180655] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 0 2002.
> > [4937745.181059] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.181514] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 0 2002.
> > [4937745.181636] [ cut here ]
> > [4937745.181900] kernel BUG at block/blk-core.c:2601!
> > [4937745.182095] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.182338] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.183046] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.183213] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.183844] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.184038] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.184919] invalid opcode: [#1] SMP
> > [4937745.185173] Modules linked in: ...
> > [4937745.188237] CPU: 18 PID: 0 Comm: swapper/18 Not tainted
> 4.1.12-61.1.9.el6uek.x86_64 #2
> > [4937745.188691] Hardware name: Oracle Corporation SUN BLADE X4-2B
> /BD,ASSY,PCB,X4-2B , BIOS 28010200 01/16/2014
>
Re: [git pull] Input updates for v4.17-rc7
On Tue, May 29, 2018 at 6:38 PM Dmitry Torokhov wrote: > We are switching a bunch of > Lenovo devices with Synaptics touchpads from PS/2 emulation over to > native RMI/SMbus. > Given that all commits are marked for stable there is no point delaying > them till next release. Hmm. The elan driver stack overrun isn't mentioned, but seems more fundamental fix than the other changes that just add a few new PnP ID's... Linus
[PATCH] PCI: Add pci=safemode option
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case BIOS hands off a broken
configuration.
Signed-off-by: Sinan Kaya
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
drivers/pci/pci.c | 7 +++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/portdrv_core.c | 2 +-
drivers/pci/probe.c | 6 ++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 641ec9c..247adbb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3153,6 +3153,8 @@
noari do not use PCIe ARI.
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
+ safemodeturns of all optinal PCI features. Useful
+ for bringup/troubleshooting.
pcie_scan_all Scan all possible PCIe devices. Otherwise we
only look for one device below a PCIe downstream
port.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d27f771..11f0282 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, disables most of the optional PCI features */
+bool pci_safe_mode;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5845,6 +5848,10 @@ static int __init pci_setup(char *str)
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "safemode", 8)) {
+ pr_info("PCI: safe mode with minimum
features\n");
+ pci_safe_mode = true;
+ pcie_bus_config = PCIE_BUS_SAFE;
} else if (!strncmp(str, "noats", 5)) {
pr_info("PCIe: ATS is disabled\n");
pcie_ats_disabled = true;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..4517bcd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -8,6 +8,8 @@
extern const unsigned char pcie_link_speed[];
+extern bool pci_safe_mode;
+
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index a5b3b3a..9fe4ed6 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -311,7 +311,7 @@ int pcie_port_device_register(struct pci_dev *dev)
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
- if (!capabilities)
+ if (!capabilities || pci_safe_mode)
return 0;
pci_set_master(dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..295b79c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2047,6 +2047,9 @@ static void pci_configure_device(struct pci_dev *dev)
struct hotplug_params hpp;
int ret;
+ if (pci_safe_mode)
+ return;
+
pci_configure_mps(dev);
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
@@ -2213,6 +2216,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Setup MSI caps & disable MSI/MSI-X interrupts */
pci_msi_setup_pci_dev(dev);
+ if (pci_safe_mode)
+ return;
+
/* Buffers for saving PCIe and PCI-X capabilities */
pci_allocate_cap_save_buffers(dev);
--
2.7.4
[PATCH 1/3] mfd: cros: add charger port count command definition
A new more command has been added to the ChromeOS embedded controller
that allows to get the number of charger port count. Unlike
EC_CMD_USB_PD_PORTS, this new command also includes the dedicated
port if present.
This command will be used to expose the dedicated charger port
in the ChromeOS charger driver.
Signed-off-by: Fabien Parent
---
include/linux/mfd/cros_ec_commands.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 0d926492ac3a..e3187f8bdb7e 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -3005,6 +3005,16 @@ struct ec_params_usb_pd_info_request {
uint8_t port;
} __packed;
+/*
+ * This command will return the number of USB PD charge port + the number
+ * of dedicated port present.
+ * EC_CMD_USB_PD_PORTS does NOT include the dedicated ports
+ */
+#define EC_CMD_CHARGE_PORT_COUNT 0x0105
+struct ec_response_charge_port_count {
+ uint8_t port_count;
+} __packed;
+
/* Read USB-PD Device discovery info */
#define EC_CMD_USB_PD_DISCOVERY 0x0113
struct ec_params_usb_pd_discovery_entry {
--
2.17.0
[PATCH 2/3] power: supply: cros: add support for dedicated port
ChromeOS devices can have one optional dedicated port.
The Dedicated port is unique and similar to the USB PD ports
except that it doesn't support as many properties.
The presence of a dedicated port is determined from whether the
EC's charger port count is equal to 'number of USB PD port' + 1.
The dedicated port ID is always the last valid port ID.
This commit keeps compatibility with Embedded Controllers that do not
support the new EC_CMD_CHARGE_PORT_COUNT command by setting
the number of charger port to be equal to the number of USB PD port
when this command fails.
Signed-off-by: Fabien Parent
---
drivers/power/supply/cros_usbpd-charger.c | 115 +++---
1 file changed, 101 insertions(+), 14 deletions(-)
diff --git a/drivers/power/supply/cros_usbpd-charger.c
b/drivers/power/supply/cros_usbpd-charger.c
index 3a0c96fd1bc1..808688a6586c 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -12,8 +12,12 @@
#include
#include
-#define CHARGER_DIR_NAME "CROS_USBPD_CHARGER%d"
-#define CHARGER_DIR_NAME_LENGTHsizeof(CHARGER_DIR_NAME)
+#define CHARGER_USBPD_DIR_NAME "CROS_USBPD_CHARGER%d"
+#define CHARGER_DEDICATED_DIR_NAME "CROS_DEDICATED_CHARGER"
+#define CHARGER_DIR_NAME_LENGTH(sizeof(CHARGER_USBPD_DIR_NAME)
>= \
+sizeof(CHARGER_DEDICATED_DIR_NAME) ? \
+sizeof(CHARGER_USBPD_DIR_NAME) : \
+sizeof(CHARGER_DEDICATED_DIR_NAME))
#define CHARGER_CACHE_UPDATE_DELAY msecs_to_jiffies(500)
#define CHARGER_MANUFACTURER_MODEL_LENGTH 32
@@ -42,6 +46,7 @@ struct charger_data {
struct cros_ec_dev *ec_dev;
struct cros_ec_device *ec_device;
int num_charger_ports;
+ int num_usbpd_ports;
int num_registered_psy;
struct port_data *ports[EC_USB_PD_MAX_PORTS];
struct notifier_block notifier;
@@ -58,6 +63,12 @@ static enum power_supply_property cros_usbpd_charger_props[]
= {
POWER_SUPPLY_PROP_USB_TYPE
};
+static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+};
+
static enum power_supply_usb_type cros_usbpd_charger_usb_types[] = {
POWER_SUPPLY_USB_TYPE_UNKNOWN,
POWER_SUPPLY_USB_TYPE_SDP,
@@ -69,6 +80,11 @@ static enum power_supply_usb_type
cros_usbpd_charger_usb_types[] = {
POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID
};
+static bool cros_usbpd_charger_port_is_dedicated(struct port_data *port)
+{
+ return port->port_number >= port->charger->num_usbpd_ports;
+}
+
static int cros_usbpd_charger_ec_command(struct charger_data *charger,
unsigned int version,
unsigned int command,
@@ -102,6 +118,23 @@ static int cros_usbpd_charger_ec_command(struct
charger_data *charger,
}
static int cros_usbpd_charger_get_num_ports(struct charger_data *charger)
+{
+ struct ec_response_charge_port_count resp;
+ int ret;
+
+ ret = cros_usbpd_charger_ec_command(charger, 0,
+ EC_CMD_CHARGE_PORT_COUNT,
+ NULL, 0, &resp, sizeof(resp));
+ if (ret < 0) {
+ dev_err(charger->dev,
+ "Unable to get the number of ports (err:0x%x)\n", ret);
+ return ret;
+ }
+
+ return resp.port_count;
+}
+
+static int cros_usbpd_charger_get_usbpd_num_ports(struct charger_data *charger)
{
struct ec_response_usb_pd_ports resp;
int ret;
@@ -246,7 +279,10 @@ static int cros_usbpd_charger_get_power_info(struct
port_data *port)
port->psy_usb_type = POWER_SUPPLY_USB_TYPE_SDP;
}
- port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
+ if (cros_usbpd_charger_port_is_dedicated(port))
+ port->psy_desc.type = POWER_SUPPLY_TYPE_MAINS;
+ else
+ port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
dev_dbg(dev,
"Port %d: type=%d vmax=%d vnow=%d cmax=%d clim=%d pmax=%d\n",
@@ -281,7 +317,8 @@ static int cros_usbpd_charger_get_port_status(struct
port_data *port,
if (ret < 0)
return ret;
- ret = cros_usbpd_charger_get_discovery_info(port);
+ if (!cros_usbpd_charger_port_is_dedicated(port))
+ ret = cros_usbpd_charger_get_discovery_info(port);
port->last_update = jiffies;
return ret;
@@ -425,17 +462,56 @@ static int cros_usbpd_charger_probe(struct
platform_device *pd)
platform_set_drvdata(pd, charger);
+ /*
+* We need to know the number of USB PD ports in order to know whether
+* there is a dedicated port. The dedicated port wil
Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function
On Wed, 30 May 2018 01:41:43 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Wednesday, May 30, 2018 4:09 AM > > > > On Fri, 20 Apr 2018 16:42:51 -0700 > > Jacob Pan wrote: > > > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > > Jean-Philippe Brucker wrote: > > > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > > > > [...] > > > > > > + /* Assign guest PASID table pointer and size order */ > > > > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > > > > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > > > > > > > > > Where does this IOMMU API interface define that base_ptr is 4K > > > > > aligned or the format of the PASID table? Are these all > > > > > standardized or do they vary by host IOMMU? If they're standards, > > > > > maybe we could note that and the spec which defines them when we > > > > > declare base_ptr. If they're IOMMU specific then I don't > > > > > understand how we'll match a user provided PASID table to the > > > > > requirements and format of the host IOMMU. Thanks, > > > > > > > > On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a > > guest > > > > under a vSMMU might pass a pointer that's not aligned on 4k. > > > > > > > PASID table pointer for VT-d is 4K aligned. > > > > Maybe this information could be part of the data passed to userspace > > > > about IOMMU table formats and features? They're not part of this > > > > series, but I think we wanted to communicate IOMMU-specific features > > > > via sysfs. > > > > > > > Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU > > > can match IOMMU model and features. > > > > Digging this up again since v5 still has this issue. The IOMMU API is > > a kernel internal abstraction of the IOMMU. sysfs is a userspace > > interface. Are we suggesting that the /only/ way to make use of the > > internal IOMMU API here is to have a user provided opaque pasid table > > that we can't even do minimal compatibility sanity testing on and we > > simply hope that hardware covers all the fault conditions without > > taking the host down with it? I guess we have to assume the latter > > since the user has full control of the table, but I have a hard time > > getting past lack of internal ability to use the interface and no > > ability to provide even the slimmest sanity testing. Thanks, > > > > checking size, alignment, ... is OK, which I think is already considered > by vendor IOMMU driver. However sanity testing table format might > be difficult. The initial table provided by guest is likely just all ZEROs. > whatever format violation may be caught only when a PASID entry > is updated... There's sanity testing the actual contents of the table, which I agree would be difficult and would likely require some sort of shadowing at additional overhead, but what about even basic consistency checking? For example, is it possible that due to hardware variations a user might generate a table which works on some systems but not others? What if two table formats are sufficiently similar that the IOMMU driver puts an incompatible table in place but it continuously generates faults, how do we debug that? As an intermediary in this whole process I'd really rather be able to identify that the user claims to be providing a TypeA table but the IOMMU only supports TypeB, so clearly this won't work. I don't see that we have that capability. Thanks, Alex
[PATCH 3/3] power: supply: cros: add property to detect connected ports
When a port is connected but acting as a source, its 'online' and
'status' properties are identical to a port that is not connected. This
makes it tedious for userspace to know for sure whether a port is
connected or not.
This commit adds a new property 'present' to reflect whether a port
is connected or not.
Signed-off-by: Fabien Parent
---
drivers/power/supply/cros_usbpd-charger.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/power/supply/cros_usbpd-charger.c
b/drivers/power/supply/cros_usbpd-charger.c
index 808688a6586c..d44ab35670ab 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -32,6 +32,7 @@ struct port_data {
struct power_supply_desc psy_desc;
int psy_usb_type;
int psy_online;
+ int psy_present;
int psy_status;
int psy_current_max;
int psy_voltage_max_design;
@@ -54,6 +55,7 @@ struct charger_data {
static enum power_supply_property cros_usbpd_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CURRENT_MAX,
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
@@ -65,6 +67,7 @@ static enum power_supply_property cros_usbpd_charger_props[]
= {
static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
@@ -205,18 +208,22 @@ static int cros_usbpd_charger_get_power_info(struct
port_data *port)
case USB_PD_PORT_POWER_DISCONNECTED:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 0;
+ port->psy_present = 0;
break;
case USB_PD_PORT_POWER_SOURCE:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 0;
+ port->psy_present = 1;
break;
case USB_PD_PORT_POWER_SINK:
port->psy_status = POWER_SUPPLY_STATUS_CHARGING;
port->psy_online = 1;
+ port->psy_present = 1;
break;
case USB_PD_PORT_POWER_SINK_NOT_CHARGING:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 1;
+ port->psy_present = 1;
break;
default:
dev_err(dev, "Unknown role %d\n", resp.role);
@@ -362,6 +369,7 @@ static int cros_usbpd_charger_get_prop(struct power_supply
*psy,
*/
if (ec_device->mkbp_event_supported || port->psy_online)
break;
+ case POWER_SUPPLY_PROP_PRESENT:
case POWER_SUPPLY_PROP_CURRENT_MAX:
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
@@ -380,6 +388,9 @@ static int cros_usbpd_charger_get_prop(struct power_supply
*psy,
case POWER_SUPPLY_PROP_ONLINE:
val->intval = port->psy_online;
break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = port->psy_present;
+ break;
case POWER_SUPPLY_PROP_STATUS:
val->intval = port->psy_status;
break;
--
2.17.0
[PATCH 0/3] power: supply: cros: add support for dedicated port and expose connected ports
Dear all, This patch series adds support for an optional dedicated port to the ChromeOS power supply driver and adds a new property that expose when a power supply is connected. The series was tested on ChromeOS "Fizz" hardware. This patch series depends on the following patch serie which adds the ChromeOS power supply driver: * https://lkml.org/lkml/2018/5/2/585 [PATCH v4 0/3] mfd/power: cros_ec: add support for USBPD charger driver The ChromeOS power supply driver also depends on the following patches to be applied: * https://lkml.org/lkml/2018/4/23/602 ([PATCH v8 0/6] typec: tcpm: Add sink side support for PPS) * https://lkml.org/lkml/2018/4/18/229 ([RESEND PATCH v5 4/7] mfd: cros_ec_dev: Register cros-ec-rtc driver as a subdevice.) Best Regards, Fabien Fabien Parent (3): mfd: cros: add charger port count command definition power: supply: cros: add support for dedicated port power: supply: cros: add property to detect connected ports drivers/power/supply/cros_usbpd-charger.c | 129 +++--- include/linux/mfd/cros_ec_commands.h | 10 ++ 2 files changed, 124 insertions(+), 15 deletions(-) -- 2.17.0
Re: [PATCH V2 2/2] block: kyber: make kyber more friendly with merging
Hi Omar
Thanks for your kindly and detailed comment.
That's really appreciated. :)
On 05/30/2018 02:55 AM, Omar Sandoval wrote:
> On Wed, May 23, 2018 at 02:33:22PM +0800, Jianchao Wang wrote:
>> Currently, kyber is very unfriendly with merging. kyber depends
>> on ctx rq_list to do merging, however, most of time, it will not
>> leave any requests in ctx rq_list. This is because even if tokens
>> of one domain is used up, kyber will try to dispatch requests
>> from other domain and flush the rq_list there.
>>
>> To improve this, we setup kyber_ctx_queue (kcq) which is similar
>> with ctx, but it has rq_lists for different domain and build same
>> mapping between kcq and khd as the ctx & hctx. Then we could merge,
>> insert and dispatch for different domains separately. At the same
>> time, only flush the rq_list of kcq when get domain token successfully.
>> Then if one domain token is used up, the requests could be left in
>> the rq_list of that domain and maybe merged with following io.
>>
>> Following is my test result on machine with 8 cores and NVMe card
>> INTEL SSDPEKKR128G7
>>
>> fio size=256m ioengine=libaio iodepth=64 direct=1 numjobs=8
>> seq/random
>> +--+---+
>> |patch?| bw(MB/s) | iops| slat(usec) |clat(usec) | merge |
>> +--+
>> | w/o | 606/612 | 151k/153k | 6.89/7.03 | 3349.21/3305.40 | 0/0 |
>> +--+
>> | w/ | 1083/616 | 277k/154k | 4.93/6.95 | 1830.62/3279.95 | 223k/3k |
>> +--+
>> When set numjobs to 16, the bw and iops could reach 1662MB/s and 425k
>> on my platform.
>>
>> Signed-off-by: Jianchao Wang
>> Tested-by: Holger Hoffstätte
>
> Thanks, the per-hctx kqcs make much more sense. This is pretty cool! A
> few nitpicks below.
>
>> ---
>> block/kyber-iosched.c | 197
>> +-
>> 1 file changed, 162 insertions(+), 35 deletions(-)
>>
>> diff --git a/block/kyber-iosched.c b/block/kyber-iosched.c
>> index 0d6d25e3..7ca1364 100644
>> --- a/block/kyber-iosched.c
>> +++ b/block/kyber-iosched.c
>> @@ -72,6 +72,15 @@ static const unsigned int kyber_batch_size[] = {
>> [KYBER_OTHER] = 8,
>> };
>>
>> +struct kyber_ctx_queue {
>
> I'm not crazy about this name, but I can't really think of anything
> better, so this will have to do.
Yes, me too
>
>> +/*
>> + * Copied from blk_mq_ctx->index_hw
>> + */
>> +unsigned int index;
>
> We can just calculate this as kcq - khd->kcqs in the one place we use
> it.
except for this, we could also use req->mq_ctx->index_hw which has been
used to get kcq.
>
>> +spinlock_t lock;
>> +struct list_head rq_list[KYBER_NUM_DOMAINS];
>> +} cacheline_aligned_in_smp;
>> +
>> struct kyber_queue_data {
>> struct request_queue *q;
>>
>> @@ -99,6 +108,8 @@ struct kyber_hctx_data {
>> struct list_head rqs[KYBER_NUM_DOMAINS];
>> unsigned int cur_domain;
>> unsigned int batching;
>> +struct kyber_ctx_queue *kcqs;
>> +struct sbitmap kcq_map[KYBER_NUM_DOMAINS];
>> wait_queue_entry_t domain_wait[KYBER_NUM_DOMAINS];
>> struct sbq_wait_state *domain_ws[KYBER_NUM_DOMAINS];
>> atomic_t wait_index[KYBER_NUM_DOMAINS];
>> @@ -107,10 +118,8 @@ struct kyber_hctx_data {
>> static int kyber_domain_wake(wait_queue_entry_t *wait, unsigned mode, int
>> flags,
>> void *key);
>>
>> -static int rq_sched_domain(const struct request *rq)
>> +static int kyber_sched_domain(unsigned int op)
>
> Please make this return an unsigned int since that's what we use for
> sched_domain everywhere except the stats bucket function.
Yes, done
>
>> {
>> -unsigned int op = rq->cmd_flags;
>> -
>> if ((op & REQ_OP_MASK) == REQ_OP_READ)
>> return KYBER_READ;
>> else if ((op & REQ_OP_MASK) == REQ_OP_WRITE && op_is_sync(op))
>> @@ -284,6 +293,11 @@ static unsigned int kyber_sched_tags_shift(struct
>> kyber_queue_data *kqd)
>> return kqd->q->queue_hw_ctx[0]->sched_tags->bitmap_tags.sb.shift;
>> }
>>
>> +static int kyber_bucket_fn(const struct request *rq)
>> +{
>> +return kyber_sched_domain(rq->cmd_flags);
>> +}
>> +
>> static struct kyber_queue_data *kyber_queue_data_alloc(struct request_queue
>> *q)
>> {
>> struct kyber_queue_data *kqd;
>> @@ -297,11 +311,10 @@ static struct kyber_queue_data
>> *kyber_queue_data_alloc(struct request_queue *q)
>> goto err;
>> kqd->q = q;
>>
>> -kqd->cb = blk_stat_alloc_callback(kyber_stat_timer_fn, rq_sched_domain,
>> +kqd->cb = blk_stat_alloc_callback(kyber_stat_timer_fn, kyber_bucket_fn,
>>KYBER_NUM_DOMAINS, kqd);
>> if (!kqd->cb)
>> goto err_kqd;
>> -
> > Unrelated whitespace change.
Done
>
>>
[PATCH net] net/sonic: Use dma_mapping_error()
With CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the
message, "DMA-API: device driver failed to check map error".
Add the missing dma_mapping_error() call.
Cc: Thomas Bogendoerfer
Signed-off-by: Finn Thain
---
drivers/net/ethernet/natsemi/sonic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/natsemi/sonic.c
b/drivers/net/ethernet/natsemi/sonic.c
index 7ed08486ae23..c805dcbebd02 100644
--- a/drivers/net/ethernet/natsemi/sonic.c
+++ b/drivers/net/ethernet/natsemi/sonic.c
@@ -84,7 +84,7 @@ static int sonic_open(struct net_device *dev)
for (i = 0; i < SONIC_NUM_RRS; i++) {
dma_addr_t laddr = dma_map_single(lp->device,
skb_put(lp->rx_skb[i], SONIC_RBSIZE),
SONIC_RBSIZE,
DMA_FROM_DEVICE);
- if (!laddr) {
+ if (dma_mapping_error(lp->device, laddr)) {
while(i > 0) { /* free any that were mapped
successfully */
i--;
dma_unmap_single(lp->device, lp->rx_laddr[i],
SONIC_RBSIZE, DMA_FROM_DEVICE);
--
2.16.1
[PATCH] usbip: usbip_detach: fix to check for invalid ports
usbip detach doesn't check for invalid ports and ports that are already
detached. It attempts to remove state file(s) without validating the port
and sends detach request to the driver for ports that are already detached.
Add check for invalid ports (port > maxports) and ports that are already
detached (status == VDEV_ST_NULL). Don't remove state files and don't send
detach request for invalid ports and ports that are already detached.
Add error and information messages that make sense.
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/usb/usbip/src/usbip_detach.c | 39 +-
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/tools/usb/usbip/src/usbip_detach.c
b/tools/usb/usbip/src/usbip_detach.c
index 6a8db858caa5..777f7286a0c5 100644
--- a/tools/usb/usbip/src/usbip_detach.c
+++ b/tools/usb/usbip/src/usbip_detach.c
@@ -46,6 +46,9 @@ static int detach_port(char *port)
int ret = 0;
uint8_t portnum;
char path[PATH_MAX+1];
+ int i;
+ struct usbip_imported_device *idev;
+ int found = 0;
unsigned int port_len = strlen(port);
@@ -55,28 +58,46 @@ static int detach_port(char *port)
return -1;
}
- /* check max port */
-
portnum = atoi(port);
- /* remove the port state file */
-
- snprintf(path, PATH_MAX, VHCI_STATE_PATH"/port%d", portnum);
-
- remove(path);
- rmdir(VHCI_STATE_PATH);
-
ret = usbip_vhci_driver_open();
if (ret < 0) {
err("open vhci_driver");
return -1;
}
+ /* check for invalid port */
+ for (i = 0; i < vhci_driver->nports; i++) {
+ idev = &vhci_driver->idev[i];
+
+ if (idev->port == portnum) {
+ found = 1;
+ if (idev->status != VDEV_ST_NULL)
+ break;
+ info("Port %d is already detached!\n", idev->port);
+ goto call_driver_close;
+ }
+ }
+
+ if (!found) {
+ err("Invalid port %s > maxports %d",
+ port, vhci_driver->nports);
+ goto call_driver_close;
+ }
+
+ /* remove the port state file */
+ snprintf(path, PATH_MAX, VHCI_STATE_PATH"/port%d", portnum);
+
+ remove(path);
+ rmdir(VHCI_STATE_PATH);
+
ret = usbip_vhci_detach_device(portnum);
if (ret < 0) {
ret = -1;
+ err("Port %d detach request failed!\n", portnum);
goto call_driver_close;
}
+ info("Port %d is now detached!\n", portnum);
call_driver_close:
usbip_vhci_driver_close();
--
2.14.1
Re: [net] vhost: Use kzalloc() to allocate vhost_msg_node
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
> On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
> > The struct vhost_msg within struct vhost_msg_node is copied to userspace,
> > so it should be allocated with kzalloc() to ensure all structure padding
> > is zeroed.
> >
> > Signed-off-by: Kevin Easton
> > Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com
>
> Is this patch going anywhere ?
>
> The patch fixes CVE-2018-1118. It would be useful to understand if and when
> this problem is going to be fixed.
>
> Thanks,
> Guenter
> > ---
> > drivers/vhost/vhost.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index f3bd8e9..1b84dcff 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
> > /* Create a new message. */
> > struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
> > {
> > - struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> > + struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
> > if (!node)
> > return NULL;
> > node->vq = vq;
As I pointed out, we don't need to init the whole structure. The proper
fix is thus (I think) below.
Could you use your testing infrastructure to confirm this fixes the issue?
Thanks!
Signed-off-by: Michael S. Tsirkin
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e941224..58d9aec90afb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct
vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(&node->msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
Bjorn, On 5/25/2018 3:10 PM, Bjorn Helgaas wrote: > On Fri, May 25, 2018 at 09:30:59AM -0400, Sinan Kaya wrote: >> On 5/24/2018 2:35 PM, Bjorn Helgaas wrote: >>> That sounds like a reasonable idea, and it is definitely another can >>> of worms. I looked briefly at some of the .shutdown() cases: >> >> should we throw it into 4.18 and see what happens? > > It wouldn't solve this particular problem because hpsa *does* have a > .shutdown() method. The problem is that it doesn't work -- it's > supposed to stop DMA and interrupts but it apparently doesn't. > > I think we need to fix hpsa first. > I don't know if you followed my latest V3 patch but I found a way to put these two together to reach to an, IMO, more acceptable solution. Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: Why is the length of max mount option a page size??
Jungsub Shin: > Do you mean using symlinks or bind mount to reduce length of mount > options?? I can remove "~/tca_agent/image_layer_dir" string. But the > other character means unique ID of layer and i can't compress it or > replace it to another string. This is not fundamental solution. Docker=20 Can't it be a solution? # mount -o bind /long/path0 /br0 # mount -o bind /long/path1 /br1 ::: # mount -t aufs -o br=/br0:/br1:... none /mntpnt or # ln -s /long/path0 /br0 # ln -s /long/path1 /br1 ::: # mount -t aufs -o br=/br0:/br1:... none /mntpnt J. R. Okajima
[PATCH v15 1/2] cpufreq: Add Kryo CPU scaling driver
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin
Acked-by: Viresh Kumar
Reviewed-by: Amit Kucheria
Tested-by: Amit Kucheria
---
MAINTAINERS | 7 ++
drivers/cpufreq/Kconfig.arm | 11 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 212 +++
5 files changed, 234 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ba0adcb..648e0c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11687,6 +11687,13 @@ F:
Documentation/devicetree/bindings/media/qcom,camss.txt
F: Documentation/media/v4l-drivers/qcom_camss.rst
F: drivers/media/platform/qcom/camss-8x16/
+QUALCOMM CPUFREQ DRIVER MSM8996/APQ8096
+M: Ilia Lin
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
+F: drivers/cpufreq/qcom-cpufreq-kryo.c
+
QUALCOMM EMAC GIGABIT ETHERNET DRIVER
M: Timur Tabi
L: net...@vger.kernel.org
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..86e87bb 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,17 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on ARM64
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO)+= qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 000..d049fe4
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MSM_ID_SMEM137
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ if (IS_
[PATCH v15 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
This change adds documentation for the DT bindings.
The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2"
with following parameters:
- nvmem-cells (NVMEM area containig the speedbin information)
- opp-supported-hw: A single 32 bit bitmap value,
representing compatible HW:
0: MSM8996 V3, speedbin 0
1: MSM8996 V3, speedbin 1
2: MSM8996 V3, speedbin 2
3: unused
4: MSM8996 SG, speedbin 0
5: MSM8996 SG, speedbin 1
6: MSM8996 SG, speedbin 2
7-31: unused
Signed-off-by: Ilia Lin
Reviewed-by: Rob Herring
Reviewed-by: Amit Kucheria
Tested-by: Amit Kucheria
Acked-by: Viresh Kumar
---
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +
1 file changed, 680 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
new file mode 100644
index 000..c2127b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
@@ -0,0 +1,680 @@
+Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+===
+
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
+that have KRYO processors, the CPU ferequencies subset and voltage value
+of each OPP varies based on the silicon variant in use.
+Qualcomm Technologies, Inc. Process Voltage Scaling Tables
+defines the voltage and frequency value based on the msm-id in SMEM
+and speedbin blown in the efuse combination.
+The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+to provide the OPP framework with required information (existing HW bitmap).
+This is used to determine the voltage and frequency value for each OPP of
+operating-points-v2 table when it is parsed by the OPP framework.
+
+Required properties:
+
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
+ efuse registers that has information about the
+ speedbin that is used to select the right frequency/voltage
+ value pair.
+ Please refer the for nvmem-cells
+ bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
+ and also examples below.
+
+In every OPP node:
+- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
+ Bitmap:
+ 0: MSM8996 V3, speedbin 0
+ 1: MSM8996 V3, speedbin 1
+ 2: MSM8996 V3, speedbin 2
+ 3: unused
+ 4: MSM8996 SG, speedbin 0
+ 5: MSM8996 SG, speedbin 1
+ 6: MSM8996 SG, speedbin 2
+ 7-31: unused
+
+Example 1:
+-
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x100>;
+
[PATCH v15 0/2] Kryo CPU scaling driver
[v15] * Addressed the kbuild error [v14] * Addressed comment from Sudeep about DT compatible * Added MAINTAINERS entry [v13] * Addressed comment from Sudeep about DT compatible check on init [v12] * Addressed comments from Sudeep and Viresh about the single init [v11] * Addressed comment from Russel about device_node reference * Addressed comment from Sudeep about the late_initcall * Transformed init into probe to take care of deferals [v10] * Split the series into domains * Addressed comments from Viresh and Sudeep about logical CPU numbering. The qcom-cpufreq-kryo driver is aimed to support different SOC versions. The driver reads eFuse information and chooses the required OPP subset by passing the OPP supported-hw parameter. The series depends on the series from Viresh: https://patchwork.kernel.org/patch/10418139/ The previous spin was here: https://patchwork.kernel.org/patch/10427315/ Ilia Lin (2): cpufreq: Add Kryo CPU scaling driver dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu .../devicetree/bindings/opp/kryo-cpufreq.txt | 680 + MAINTAINERS| 7 + drivers/cpufreq/Kconfig.arm| 11 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 3 + drivers/cpufreq/qcom-cpufreq-kryo.c| 212 +++ 6 files changed, 914 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c -- 1.9.1
[PATCH] PCI: mediatek: Add system pm support for MT2712
From: Honghui Zhang
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internel control register will be reset after system resume. The PCIe
link should be re-established and the related control register values should
be re-set after system resume.
Signed-off-by: Honghui Zhang
CC: Ryder Lee
---
drivers/pci/host/pcie-mediatek.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index dabf1086..60f98d92 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -132,12 +132,14 @@ struct mtk_pcie_port;
/**
* struct mtk_pcie_soc - differentiate between host generations
* @need_fix_class_id: whether this host's class ID needed to be fixed or not
+ * @pm_support: whether the host's MTCMOS will be off when suspend
* @ops: pointer to configuration access functions
* @startup: pointer to controller setting functions
* @setup_irq: pointer to initialize IRQ functions
*/
struct mtk_pcie_soc {
bool need_fix_class_id;
+ bool pm_support;
struct pci_ops *ops;
int (*startup)(struct mtk_pcie_port *port);
int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
@@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
}
+static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mtk_pcie *pcie;
+ struct mtk_pcie_port *port;
+ const struct mtk_pcie_soc *soc;
+
+ pdev = to_platform_device(dev);
+ pcie = platform_get_drvdata(pdev);
+ soc = pcie->soc;
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ clk_disable_unprepare(port->ahb_ck);
+ clk_disable_unprepare(port->sys_ck);
+ phy_power_off(port->phy);
+ }
+
+ return 0;
+}
+
+static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mtk_pcie *pcie;
+ struct mtk_pcie_port *port;
+ const struct mtk_pcie_soc *soc;
+ int ret;
+
+ pdev = to_platform_device(dev);
+ pcie = platform_get_drvdata(pdev);
+ soc = pcie->soc;
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ ret = phy_power_on(port->phy);
+ if (ret) {
+ dev_err(dev, "could not power on phy\n");
+ return ret;
+ }
+ ret = clk_prepare_enable(port->sys_ck);
+ if (ret) {
+ dev_err(dev, "enable sys clock error\n");
+ phy_power_off(port->phy);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(port->ahb_ck);
+ if (ret) {
+ dev_err(dev, "enable ahb clock error\n");
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ return ret;
+ }
+
+ ret = soc->startup(port);
+ if (ret) {
+ dev_err(dev, "pcie linkup failed\n");
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ clk_disable_unprepare(port->ahb_ck);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ mtk_pcie_enable_msi(port);
+ }
+
+ return 0;
+}
+
+const struct dev_pm_ops mtk_pcie_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = &mtk_pcie_ops,
.startup = mtk_pcie_startup_port,
};
static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
+ .pm_support = true,
.ops = &mtk_pcie_ops_v2,
.startup = mtk_pcie_startup_port_v2,
.setup_irq = mtk_pcie_setup_irq,
@@ -1211,6 +1292,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+ .pm = &mtk_pcie_pm_ops,
},
};
builtin_platform_driver(mtk_pcie_driver);
--
2.6.4
Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts
Dave Chinner writes: > Yeah, the are some fairly big process and policy things that need > to be decided here. Not just at the kernel level, but at distro and > app infrastructure level too. > > I was originally sceptical of supporting kernel filesystems via lkl, > but the desire for unprivileged mounts has not gone away and so I'm > less worried about accessing filesystems that way than I am of > letting the kernel parse untrusted images from untrusted users... There is also the more readily available libguestfs which doesn't support as many filesystems but does seem available in most linux distributions already. It already has a fuse option available with guestmount. I may have to dig in there and see how to make it available without using fusermount. > I'm not sure what the correct forum for this is - wasn't this > something the Plumbers conference was supposed to facilitate? Yes. If we all need to be in a room and talk about things. It is early enough in the planning for Plumers that we could definitely schedule a talk or a BOF for this. >> Is fusefs-lkl valuable for testing filesystems? If xfs-tests were to >> have a mode that used that used the fuse protocol for testing and >> fuzzing filesystems without the full weight of the kernel in the middle >> that might encourage people to suppor this kind of things as well. > > Getting lkl-fuse to run under fstests would be a great way to ensure > we have some level of confidence that it will do the right thing and > users can expect that it won't eat their data. I think this would > need to be a part of a recommendation for wider deploy of such a > solution... Good thought. I will have to give that a look. That does sound like a good practical test. Eric
Re: [PATCH RESEND] time: Fix sleeptime injection for non-stop clocksource & persistent clock
On Tue, May 29, 2018 at 2:49 AM, Mukesh Ojha wrote:
> Currently, for both non-stop clocksource and persistent clock
> there is a corner case, when a driver failed to go suspend mode
> rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
> returned 'false' due to which we can see mismatch in time between
> system clock and other timers.
>
> Success case:
> {sleeptime_injected=true}
> rtc_suspend() => timekeeping_suspend() => timekeeping_resume() =>
> rtc_resume()
>
> Failure case:
> {failure in sleep path} {sleeptime_injected=false}
> rtc_suspend() =>rtc_resume()
>
> Signed-off-by: Mukesh Ojha
I'm not sure this patch makes sense yet (since I don't really see how
its used - mind cc'ing me on the patch that makes use of this?)
And more problematic, the patch doesn't seem to apply to mainline.
Could you respin and resend?
thanks
-john
Hello
My name is Lisa i saw your email today when i was searching for someone i can trust and let know more about me and i became interested in you, i will also like to know you the more, I believe we can move from here! I am waiting for your mail. and I have vital information you need to know. Please, write me directly in my private mail so that i will be able to reply back to you ( lisajohnson...@gmail.com ) Lisa
Re: [PATCH] nvme: prefer strlcpy to strncpy
On Tue, May 29, 2018 at 1:11 AM, Christoph Hellwig wrote: > On Mon, May 28, 2018 at 11:49:18PM -0700, Nick Desaulniers wrote: >> Fixes a stringop-truncation warning from gcc-8. > > What would that warning be? Maybe it actually is genuinly useful, > and switching to strlcpy just papers over it.. Eric also pointed out to me that strlcpy will not initialize the rest of dest with zeros if size is less than the length of src.
Re: [PATCH] ext4: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:21 PM, Nick Desaulniers
wrote:
> Fixes a stringop-truncation warning from gcc-8.
>
> Signed-off-by: Nick Desaulniers
> ---
> fs/ext4/super.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index eb104e8..d47c85f 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -323,11 +323,11 @@ static void __save_error_info(struct super_block *sb,
> const char *func,
> return;
> es->s_state |= cpu_to_le16(EXT4_ERROR_FS);
> es->s_last_error_time = cpu_to_le32(get_seconds());
> - strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
> + strlcpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
> es->s_last_error_line = cpu_to_le32(line);
> if (!es->s_first_error_time) {
> es->s_first_error_time = es->s_last_error_time;
> - strncpy(es->s_first_error_func, func,
> + strlcpy(es->s_first_error_func, func,
> sizeof(es->s_first_error_func));
> es->s_first_error_line = cpu_to_le32(line);
> es->s_first_error_ino = es->s_last_error_ino;
> --
> 2.7.4
>
Eric points out this will leave the rest of dest uninitialized if size
is less than length of src.
Re: [PATCH] blk-wbt: tracing: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:31 PM, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers > --- > include/trace/events/wbt.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/trace/events/wbt.h b/include/trace/events/wbt.h > index b048694..305252d 100644 > --- a/include/trace/events/wbt.h > +++ b/include/trace/events/wbt.h > @@ -33,7 +33,7 @@ TRACE_EVENT(wbt_stat, > ), > > TP_fast_assign( > - strncpy(__entry->name, dev_name(bdi->dev), 32); > + strlcpy(__entry->name, dev_name(bdi->dev), 32); > __entry->rmean = stat[0].mean; > __entry->rmin = stat[0].min; > __entry->rmax = stat[0].max; > @@ -67,7 +67,7 @@ TRACE_EVENT(wbt_lat, > ), > > TP_fast_assign( > - strncpy(__entry->name, dev_name(bdi->dev), 32); > + strlcpy(__entry->name, dev_name(bdi->dev), 32); > __entry->lat = div_u64(lat, 1000); > ), > > @@ -103,7 +103,7 @@ TRACE_EVENT(wbt_step, > ), > > TP_fast_assign( > - strncpy(__entry->name, dev_name(bdi->dev), 32); > + strlcpy(__entry->name, dev_name(bdi->dev), 32); > __entry->msg= msg; > __entry->step = step; > __entry->window = div_u64(window, 1000); > @@ -138,7 +138,7 @@ TRACE_EVENT(wbt_timer, > ), > > TP_fast_assign( > - strncpy(__entry->name, dev_name(bdi->dev), 32); > + strlcpy(__entry->name, dev_name(bdi->dev), 32); > __entry->status = status; > __entry->step = step; > __entry->inflight = inflight; > -- > 2.7.4 > Eric points out this doesn't initialize the rest of dest if src is less than size.
Re: [PATCH] writeback: tracing: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:37 PM, Nick Desaulniers
wrote:
> Fixes a stringop-truncation warning from gcc-8.
>
> Signed-off-by: Nick Desaulniers
> ---
> include/trace/events/writeback.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/include/trace/events/writeback.h
> b/include/trace/events/writeback.h
> index 32db72c..cfaf57d 100644
> --- a/include/trace/events/writeback.h
> +++ b/include/trace/events/writeback.h
> @@ -66,7 +66,7 @@ TRACE_EVENT(writeback_dirty_page,
> ),
>
> TP_fast_assign(
> - strncpy(__entry->name,
> + strlcpy(__entry->name,
> mapping ? dev_name(inode_to_bdi(mapping->host)->dev)
> : "(unknown)", 32);
> __entry->ino = mapping ? mapping->host->i_ino : 0;
> __entry->index = page->index;
> @@ -96,7 +96,7 @@ DECLARE_EVENT_CLASS(writeback_dirty_inode_template,
> struct backing_dev_info *bdi = inode_to_bdi(inode);
>
> /* may be called for files on pseudo FSes w/ unregistered bdi
> */
> - strncpy(__entry->name,
> + strlcpy(__entry->name,
> bdi->dev ? dev_name(bdi->dev) : "(unknown)", 32);
> __entry->ino= inode->i_ino;
> __entry->state = inode->i_state;
> @@ -176,7 +176,7 @@ DECLARE_EVENT_CLASS(writeback_write_inode_template,
> ),
>
> TP_fast_assign(
> - strncpy(__entry->name,
> + strlcpy(__entry->name,
> dev_name(inode_to_bdi(inode)->dev), 32);
> __entry->ino= inode->i_ino;
> __entry->sync_mode = wbc->sync_mode;
> @@ -220,7 +220,7 @@ DECLARE_EVENT_CLASS(writeback_work_class,
> __field(unsigned int, cgroup_ino)
> ),
> TP_fast_assign(
> - strncpy(__entry->name,
> + strlcpy(__entry->name,
> wb->bdi->dev ? dev_name(wb->bdi->dev) : "(unknown)",
> 32);
> __entry->nr_pages = work->nr_pages;
> __entry->sb_dev = work->sb ? work->sb->s_dev : 0;
> @@ -274,7 +274,7 @@ DECLARE_EVENT_CLASS(writeback_class,
> __field(unsigned int, cgroup_ino)
> ),
> TP_fast_assign(
> - strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
> + strlcpy(__entry->name, dev_name(wb->bdi->dev), 32);
> __entry->cgroup_ino = __trace_wb_assign_cgroup(wb);
> ),
> TP_printk("bdi %s: cgroup_ino=%u",
> @@ -296,7 +296,7 @@ TRACE_EVENT(writeback_bdi_register,
> __array(char, name, 32)
> ),
> TP_fast_assign(
> - strncpy(__entry->name, dev_name(bdi->dev), 32);
> + strlcpy(__entry->name, dev_name(bdi->dev), 32);
> ),
> TP_printk("bdi %s",
> __entry->name
> @@ -321,7 +321,7 @@ DECLARE_EVENT_CLASS(wbc_class,
> ),
>
> TP_fast_assign(
> - strncpy(__entry->name, dev_name(bdi->dev), 32);
> + strlcpy(__entry->name, dev_name(bdi->dev), 32);
> __entry->nr_to_write= wbc->nr_to_write;
> __entry->pages_skipped = wbc->pages_skipped;
> __entry->sync_mode = wbc->sync_mode;
> @@ -372,7 +372,7 @@ TRACE_EVENT(writeback_queue_io,
> ),
> TP_fast_assign(
> unsigned long *older_than_this = work->older_than_this;
> - strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
> + strlcpy(__entry->name, dev_name(wb->bdi->dev), 32);
> __entry->older = older_than_this ? *older_than_this : 0;
> __entry->age= older_than_this ?
> (jiffies - *older_than_this) * 1000 / HZ :
> -1;
> @@ -583,7 +583,7 @@ TRACE_EVENT(writeback_sb_inodes_requeue,
> ),
>
> TP_fast_assign(
> - strncpy(__entry->name,
> + strlcpy(__entry->name,
> dev_name(inode_to_bdi(inode)->dev), 32);
> __entry->ino= inode->i_ino;
> __entry->state = inode->i_state;
> @@ -657,7 +657,7 @@ DECLARE_EVENT_CLASS(writeback_single_inode_template,
> ),
>
> TP_fast_assign(
> - strncpy(__entry->name,
> + strlcpy(__entry->name,
> dev_name(inode_to_bdi(inode)->dev), 32);
> __entry->ino= inode->i_ino;
> __entry->state = inode->i_state;
> --
> 2.7.4
>
Eric points out this wont initialize the rest of the dest if src if
less than size.
Re: [PATCH] tracing: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:03 PM, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers > --- > kernel/trace/trace_events_hist.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace_events_hist.c > b/kernel/trace/trace_events_hist.c > index b9061ed..b53a6c0 100644 > --- a/kernel/trace/trace_events_hist.c > +++ b/kernel/trace/trace_events_hist.c > @@ -393,7 +393,7 @@ static void hist_err_event(char *str, char *system, char > *event, char *var) > else if (system) > snprintf(err, MAX_FILTER_STR_VAL, "%s.%s", system, event); > else > - strncpy(err, var, MAX_FILTER_STR_VAL); > + strlcpy(err, var, MAX_FILTER_STR_VAL); > > hist_err(str, err); > } > -- > 2.7.4 > Eric points out this wont initialize the rest of err with zeros.
[PATCH] mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()
Swapping load on huge=always tmpfs (with khugepaged tuned up to be very
eager, but I'm not sure that is relevant) soon hung uninterruptibly,
waiting for page lock in shmem_getpage_gfp()'s find_lock_entry(), most
often when "cp -a" was trying to write to a smallish file. Debug showed
that the page in question was not locked, and page->mapping NULL by now,
but page->index consistent with having been in a huge page before.
Reproduced in minutes on a 4.15 kernel, even with 4.17's 605ca5ede764
("mm/huge_memory.c: reorder operations in __split_huge_page_tail()")
added in; but took hours to reproduce on a 4.17 kernel (no idea why).
The culprit proved to be the __ClearPageDirty() on tails beyond i_size
in __split_huge_page(): the non-atomic __bitoperation may have been safe
when 4.8's baa355fd3314 ("thp: file pages support for split_huge_page()")
introduced it, but liable to erase PageWaiters after 4.10's 62906027091f
("mm: add PageWaiters indicating tasks are waiting for a page bit").
Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a
page bit")
Signed-off-by: Hugh Dickins
---
It's not a 4.17-rc regression that this fixes, so no great need to slip
this into 4.17 at the last moment - though it makes a good companion to
Konstantin's 605ca5ede764. I think they both should go to stable, but
since Konstantin's already went into rc1 without that tag, we shall
have to recommend Konstantin's to GregKH out-of-band.
mm/huge_memory.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.17-rc7/mm/huge_memory.c 2018-04-26 10:48:36.019288258 -0700
+++ linux/mm/huge_memory.c 2018-05-29 18:14:52.095512715 -0700
@@ -2431,7 +2431,7 @@ static void __split_huge_page(struct pag
__split_huge_page_tail(head, i, lruvec, list);
/* Some pages can be beyond i_size: drop them from page cache */
if (head[i].index >= end) {
- __ClearPageDirty(head + i);
+ ClearPageDirty(head + i);
__delete_from_page_cache(head + i, NULL);
if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head))
shmem_uncharge(head->mapping->host, 1);
Re: [PATCH V3 1/2] PCI: Try to clean up resources via remove if shutdown doesn't exist
On 05/28/2018 02:21 PM, Sinan Kaya wrote:
> It is up to a driver to implement shutdown() callback. If shutdown()
> callback is not implemented, PCI device can have pending interrupt and
> even do DMA transactions while the system is going down.
>
> If kexec is in use, this can damage the newly booting kexec kernel
> or even prevent it from booting altogether. Fallback to calling the
> remove() callback if shutdown() isn't implemented for a given driver.
>
> Signed-off-by: Sinan Kaya
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> Cc: sta...@vger.kernel.org
> Reported-by: Ryan Finnie
Tested successfully on DL360 Gen9 and DL380 Gen9.
Tested-by: Ryan Finnie
Re: linux-next: build failure after merge of the kbuild tree
2018-05-30 10:29 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > After merging the kbuild tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > make was continually spawning test compiles. > > I used the kbuild tree from next-20180529 for today. > > A (partial) strace seemed to show that it was testing for compiler flags > (some more than once). > My bad - I need to insert some patches from Nicholas Piggin. I will fix it for tomorrows' release. Thanks for the report! -- Best Regards Masahiro Yamada
RE: [PATCH] soc: imx: gpcv2: correct PGC offset
Hi, Leonard Anson Huang Best Regards! > -Original Message- > From: Leonard Crestez > Sent: Tuesday, May 29, 2018 10:03 PM > To: Anson Huang ; shawn...@kernel.org; Andrey > Smirnov > Cc: dl-linux-imx ; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org; s.ha...@pengutronix.de; > ker...@pengutronix.de; Fabio Estevam ; Abel Vesa > ; Richard Liu > Subject: Re: [PATCH] soc: imx: gpcv2: correct PGC offset > > On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote: > > Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the value > > on Reference Manual are incorrect. > > > > The correct offset should be as below: > > > > -#define PGC_MIPI 4 > > -#define PGC_PCIE 5 > > -#define PGC_USB_HSIC 8 > > +#define PGC_MIPI 16 > > +#define PGC_PCIE 17 > > +#define PGC_USB_HSIC 20 > > #define GPC_PGC_CTRL(n)(0x800 + (n) * 0x40) > > #define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc) > > This gpcv2 driver is currently only used for PCI, it probably only works > because > domains happen to be turned on by default? I think so. > > On imx7d upstream platform suspend is not yet supported but even doing > device-level suspend causes a hang on resume somewhere in PCI on first read. > This patch fixes that immediate hang. I just added the imx7d platform suspend/resume support using psci in u-boot, patches are sent out for review. I did notice PCI resume cause system hang, the root cause is PCI controller registers can NOT be accessed after resume, and the PCI PHY PLL is NOT locked when issue happen, the PCI driver should implement suspend/resume and redo the init flow after resume, since its power VDD1P0D are OFF after suspend. I saw you sent out patch to fix it, thanks. Anson. > > After suspend/resume lspci is broken (device doesn't properly resume), that > probably requires more imx pci patches and unrelated to pgc. > > -- > Regards, > Leonard
[PATCH V2] soc: imx: gpcv2: correct PGC offset
Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the values in the Reference Manual (Rev. 1, 01/2018 and the older ones) are incorrect. The correct offset values should be as below: 0x800 ~ 0x83F: PGC for core0 of A7 platform; 0x840 ~ 0x87F: PGC for core1 of A7 platform; 0x880 ~ 0x8BF: PGC for SCU of A7 platform; 0xA00 ~ 0xA3F: PGC for fastmix/megamix; 0xC00 ~ 0xC3F: PGC for MIPI PHY; 0xC40 ~ 0xC7F: PGC for PCIe_PHY; 0xC80 ~ 0xCBF: PGC for USB OTG1 PHY; 0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY; 0xD00 ~ 0xD3F: PGC for USB HSIC PHY; Signed-off-by: Anson Huang Acked-by: Andrey Smirnov --- changes since V1: add comment in code to make it more readable; improve the commit message. drivers/soc/imx/gpcv2.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c index f4e3bd4..6ef18cf 100644 --- a/drivers/soc/imx/gpcv2.c +++ b/drivers/soc/imx/gpcv2.c @@ -39,10 +39,15 @@ #define GPC_M4_PU_PDN_FLG 0x1bc - -#define PGC_MIPI 4 -#define PGC_PCIE 5 -#define PGC_USB_HSIC 8 +/* + * The PGC offset values in Reference Manual + * (Rev. 1, 01/2018 and the older ones) GPC chapter's + * GPC_PGC memory map are incorrect, below offset + * values are from design RTL. + */ +#define PGC_MIPI 16 +#define PGC_PCIE 17 +#define PGC_USB_HSIC 20 #define GPC_PGC_CTRL(n)(0x800 + (n) * 0x40) #define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc) -- 2.7.4
linux-next: build failure after merge of the kbuild tree
Hi Masahiro, After merging the kbuild tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: make was continually spawning test compiles. I used the kbuild tree from next-20180529 for today. A (partial) strace seemed to show that it was testing for compiler flags (some more than once). -- Cheers, Stephen Rothwell pgpPvPbVmnscs.pgp Description: OpenPGP digital signature
Re: [PATCH v3] vmw_balloon: fixing double free when batching mode is off
Nadav Amit wrote:
> Ping. Please consider it for inclusion for rc4.
>
> Nadav Amit wrote:
>
>> From: Gil Kupfer
>>
>> The balloon.page field is used for two different purposes if batching is
>> on or off. If batching is on, the field point to the page which is used
>> to communicate with with the hypervisor. If it is off, balloon.page
>> points to the page that is about to be (un)locked.
>>
>> Unfortunately, this dual-purpose of the field introduced a bug: when the
>> balloon is popped (e.g., when the machine is reset or the balloon driver
>> is explicitly removed), the balloon driver frees, unconditionally, the
>> page that is held in balloon.page. As a result, if batching is
>> disabled, this leads to double freeing the last page that is sent to the
>> hypervisor.
>>
>> The following error occurs during rmmod when kernel checkers are on, and
>> the balloon is not empty:
>>
>> [ 42.307653] [ cut here ]
>> [ 42.307657] Kernel BUG at ba1e4b28 [verbose debug info
>> unavailable]
>> [ 42.307720] invalid opcode: [#1] SMP DEBUG_PAGEALLOC
>> [ 42.312512] Modules linked in: vmw_vsock_vmci_transport vsock ppdev
>> joydev vmw_balloon(-) input_leds serio_raw vmw_vmci parport_pc shpchp
>> parport i2c_piix4 nfit mac_hid autofs4 vmwgfx drm_kms_helper hid_generic
>> syscopyarea sysfillrect usbhid sysimgblt fb_sys_fops hid ttm mptspi
>> scsi_transport_spi ahci mptscsih drm psmouse vmxnet3 libahci mptbase
>> pata_acpi
>> [ 42.312766] CPU: 10 PID: 1527 Comm: rmmod Not tainted 4.12.0+ #5
>> [ 42.312803] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
>> Desktop Reference Platform, BIOS 6.00 09/30/2016
>> [ 42.313042] task: 9bf9680f8000 task.stack: bfefc1638000
>> [ 42.313290] RIP: 0010:__free_pages+0x38/0x40
>> [ 42.313510] RSP: 0018:bfefc163be98 EFLAGS: 00010246
>> [ 42.313731] RAX: 003e RBX: c02b9720 RCX:
>> 0006
>> [ 42.313972] RDX: RSI: RDI:
>> 9bf97e08e0a0
>> [ 42.314201] RBP: bfefc163be98 R08: R09:
>>
>> [ 42.314435] R10: R11: R12:
>> c02b97e4
>> [ 42.314505] R13: c02b9748 R14: c02b9728 R15:
>> 0200
>> [ 42.314550] FS: 7f3af5fec700() GS:9bf97e08()
>> knlGS:
>> [ 42.314599] CS: 0010 DS: ES: CR0: 80050033
>> [ 42.314635] CR2: 7f44f6f4ab24 CR3: 0003a7d12000 CR4:
>> 06e0
>> [ 42.314864] Call Trace:
>> [ 42.315774] vmballoon_pop+0x102/0x130 [vmw_balloon]
>> [ 42.315816] vmballoon_exit+0x42/0xd64 [vmw_balloon]
>> [ 42.315853] SyS_delete_module+0x1e2/0x250
>> [ 42.315891] entry_SYSCALL_64_fastpath+0x23/0xc2
>> [ 42.315924] RIP: 0033:0x7f3af5b0e8e7
>> [ 42.315949] RSP: 002b:7fffe6ce0148 EFLAGS: 0206 ORIG_RAX:
>> 00b0
>> [ 42.315996] RAX: ffda RBX: 55be676401e0 RCX:
>> 7f3af5b0e8e7
>> [ 42.316951] RDX: 000a RSI: 0800 RDI:
>> 55be67640248
>> [ 42.317887] RBP: 0003 R08: R09:
>> 1999
>> [ 42.318845] R10: 0883 R11: 0206 R12:
>> 7fffe6cdf130
>> [ 42.319755] R13: R14: R15:
>> 55be676401e0
>> [ 42.320606] Code: c0 74 1c f0 ff 4f 1c 74 02 5d c3 85 f6 74 07 e8 0f d8
>> ff ff 5d c3 31 f6 e8 c6 fb ff ff 5d c3 48 c7 c6 c8 0f c5 ba e8 58 be 02 00
>> <0f> 0b 66 0f 1f 44 00 00 66 66 66 66 90 48 85 ff 75 01 c3 55 48
>> [ 42.323462] RIP: __free_pages+0x38/0x40 RSP: bfefc163be98
>> [ 42.325735] ---[ end trace 872e008e33f81508 ]---
>>
>> To solve the bug, we eliminate the dual purpose of balloon.page.
>>
>> Fixes: f220a80f0c2e ("VMware balloon: add batching to the vmw_balloon.")
>> Cc: sta...@vger.kernel.org
>> Reported-by: Oleksandr Natalenko
>> Signed-off-by: Gil Kupfer
>> Signed-off-by: Nadav Amit
>> Reviewed-by: Xavier Deguillard
>> ---
>> drivers/misc/vmw_balloon.c | 23 +++
>> 1 file changed, 7 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
>> index 9047c0a529b2..efd733472a35 100644
>> --- a/drivers/misc/vmw_balloon.c
>> +++ b/drivers/misc/vmw_balloon.c
>> @@ -576,15 +576,9 @@ static void vmballoon_pop(struct vmballoon *b)
>> }
>> }
>>
>> -if (b->batch_page) {
>> -vunmap(b->batch_page);
>> -b->batch_page = NULL;
>> -}
>> -
>> -if (b->page) {
>> -__free_page(b->page);
>> -b->page = NULL;
>> -}
>> +/* Clearing the batch_page unconditionally has no adverse effect */
>> +free_page((unsigned long)b->batch_page);
>> +b->batch_page = NULL;
>> }
>>
>> /*
>> @@ -991,16 +985,13 @@ static const struct vmballoon_ops
>> vmballoon_batched_ops = {
>>
>> static bool vmballoon_init_batching(stru
RE: [PATCH] soc: imx: gpcv2: correct PGC offset
Hi, Andrey Anson Huang Best Regards! > -Original Message- > From: Andrey Smirnov [mailto:andrew.smir...@gmail.com] > Sent: Wednesday, May 30, 2018 7:11 AM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Sascha Hauer ; Fabio > Estevam ; dl-linux-imx ; > linux-arm-kernel ; linux-kernel > > Subject: Re: [PATCH] soc: imx: gpcv2: correct PGC offset > > On Tue, May 29, 2018 at 1:02 AM, Anson Huang > wrote: > > Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the value > > on Reference Manual are incorrect. > > > > Nit: I'd s/the value on/the values in the/ here. > > > The correct offset should be as below: > > > > 0x800 ~ 0x83F: PGC for core0 of A7 platform; > > 0x840 ~ 0x87F: PGC for core1 of A7 platform; > > 0x880 ~ 0x8BF: PGC for SCU of A7 platform; > > 0xA00 ~ 0xA3F: PGC for fastmix/megamix; > > 0xC00 ~ 0xC3F: PGC for MIPI PHY; > > 0xC40 ~ 0xC7F: PGC for PCIe_PHY; > > 0xC80 ~ 0xCBF: PGC for USB OTG1 PHY; > > 0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY; > > 0xD00 ~ 0xD3F: PGC for USB HSIC PHY; > > > > Signed-off-by: Anson Huang > > --- > > drivers/soc/imx/gpcv2.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c index > > afc7ecc..132c946 100644 > > --- a/drivers/soc/imx/gpcv2.c > > +++ b/drivers/soc/imx/gpcv2.c > > @@ -40,9 +40,9 @@ > > #define GPC_M4_PU_PDN_FLG 0x1bc > > > > > > -#define PGC_MIPI 4 > > -#define PGC_PCIE 5 > > -#define PGC_USB_HSIC 8 > > +#define PGC_MIPI 16 > > +#define PGC_PCIE 17 > > +#define PGC_USB_HSIC 20 > > As a suggestion, please add a comment explicitly saying that those values > might differ from what some version of the RM might specify. > Explanation in commit message is great, but seeing a note in the code might > save quite a bit of digging for someone who is reading the code, double > checking those values and thinking that they might be wrong. > > Other than that: > > Acked-by: Andrey Smirnov > > Thanks, > Andrey Smirnov Thanks, I will improve them in V2 patch. Anson.
Re: [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
On Wed, May 30, 2018 at 12:58 AM, Ray Jui wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
do {
status = ...;
for_each_set_bit() {
...
}
} while (status);
would look slightly better for my opinion.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] mdio-mux-gpio: Remove VLA usage
On Tue, May 29, 2018 at 03:59:01PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the values buffer during the callback instead of putting it
> on the stack.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook
> ---
> drivers/net/phy/mdio-mux-gpio.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
> index 082ffef0dec4..e4f4ed50 100644
> --- a/drivers/net/phy/mdio-mux-gpio.c
> +++ b/drivers/net/phy/mdio-mux-gpio.c
> @@ -26,18 +26,23 @@ static int mdio_mux_gpio_switch_fn(int current_child, int
> desired_child,
> void *data)
> {
> struct mdio_mux_gpio_state *s = data;
> - int values[s->gpios->ndescs];
> + int *values;
> unsigned int n;
>
> if (current_child == desired_child)
> return 0;
>
> + values = kmalloc_array(s->gpios->ndescs, sizeof(*values), GFP_KERNEL);
> + if (!values)
> + return -ENOMEM;
> +
> for (n = 0; n < s->gpios->ndescs; n++)
> values[n] = (desired_child >> n) & 1;
>
> gpiod_set_array_value_cansleep(s->gpios->ndescs, s->gpios->desc,
> values);
>
> + kfree(values);
> return 0;
> }
Hi Kees
This is the 'hot path' for this driver, and you are making it more
expensive.
Please allocate the memory once in mdio_mux_gpio_probe and make it
part of mdio_mux_gpio_state.
Thanks
Andrew
Re: [PATCH] autofs: make autofs4 and autofs mutually exclusive
On Tue, 2018-05-29 at 11:46 +0200, Arnd Bergmann wrote:
> The autofs4 implementation is just a redirect to autofs now, but that
> also means we can't have both built into the same kernel:
>
> fs/autofs/inode.o: In function `autofs_new_ino':
> inode.c:(.text+0x1b8): multiple definition of `autofs_new_ino'
> fs/autofs/inode.o:inode.c:(.text+0x1b8): first defined here
> fs/autofs/inode.o: In function `autofs_clean_ino':
> inode.c:(.text+0x288): multiple definition of `autofs_clean_ino'
>
> There is also a problem with trying to build both in parallel, which
> leads to two 'make' processes writing to the same fs/autofs/.*.o.cmd
> file, causing corruption that manifests like
>
> fs/autofs4/../autofs/.expire.o.cmd:679: *** missing separator. Stop.
>
> Making AUTOFS4_FS depend on AUTOFS_FS being disabled should avoid all
> configurations that run into either issue.
Thanks Arnd and this adds support that my analysis of build
problems is accurate.
I posted a similar patch on May 21 which also added a NOTE to
fs/autofs4/Kconfig saying pretty much what you've said.
https://patchwork.kernel.org/patch/10413823/
I recommend using my patch so that anyone that's surprised by the
.config change has a chance of finding an explanation somewhere, ;)
Not only is the change needed, but to preserve bisection it needs
to be folded into the original patch titled:
autofs: create autofs Kconfig and Makefile
otherwise build test robots will still see this problem between
build testing after "autofs: create autofs Kconfig and Makefile"
and before this change is applied.
Folding in the change is my current recommendation to Andrew.
Hopefully that will fix the problem.
Any further thoughts are of course welcome.
>
> Fixes: mmotm ("autofs: update fs/autofs4/Makefile")
> Signed-off-by: Arnd Bergmann
> ---
> fs/autofs4/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/autofs4/Kconfig b/fs/autofs4/Kconfig
> index 53bc592a250d..eccf673c6c8c 100644
> --- a/fs/autofs4/Kconfig
> +++ b/fs/autofs4/Kconfig
> @@ -1,5 +1,6 @@
> config AUTOFS4_FS
> tristate "Kernel automounter version 4 support (also supports v3 and
> v5)"
> + depends on AUTOFS_FS=n
> default n
> help
> The automounter is a tool to automatically mount remote file
> systems
Re: [PATCH] KVM: VMX: Optimize tscdeadline timer latency
On Wed, 30 May 2018 at 01:08, Paolo Bonzini wrote:
> On 29/05/2018 16:31, Radim Krčmář wrote:
> > 2018-05-29 16:23+0200, Radim Krčmář:
> >> 2018-05-29 14:53+0800, Wanpeng Li:
> >>> From: Wanpeng Li
> >>>
> >>> 'Commit d0659d946be0 ("KVM: x86: add option to advance tscdeadline
> >>> hrtimer expiration")' advances the tscdeadline (the timer is emulated
> >>> by hrtimer) expiration in order that the latency which is incurred
> >>> by hypervisor (apic_timer_fn -> vmentry) can be avoided. This patch
> >>> adds the advance tscdeadline expiration support to which the
tscdeadline
> >>> timer is emulated by VMX preemption timer to reduce the hypervisor
> >>> lantency (handle_preemption_timer -> vmentry). clockevents
infrastruture
> >>> can program minimum delay if hrtimer feeds a expiration in the past,
> >>> we set delta_tsc to 1(which will be converted to 0 before vmentry)
> >>> which can lead to an immediately vmexit when delta_tsc is not bigger
> >>> than advance ns.
> >>>
> >>> This patch can reduce ~63% latency (~4450 cycles to ~1660 cycles on
> >>> a haswell desktop) for kvm-unit-tests/tscdeadline_latency when testing
> >>> busy waits.
> >>>
> >>> Cc: Paolo Bonzini
> >>> Cc: Radim Krčmář
> >>> Signed-off-by: Wanpeng Li
> >>> ---
> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> >>> @@ -12444,6 +12444,12 @@ static int vmx_set_hv_timer(struct kvm_vcpu
*vcpu, u64 guest_deadline_tsc)
> >>> tscl = rdtsc();
> >>> guest_tscl = kvm_read_l1_tsc(vcpu, tscl);
> >>> delta_tsc = max(guest_deadline_tsc, guest_tscl) - guest_tscl;
> >>> + lapic_timer_advance_cycles = nsec_to_cycles(vcpu,
lapic_timer_advance_ns);
> >>> + if (delta_tsc > lapic_timer_advance_cycles)
> >>> + delta_tsc -= lapic_timer_advance_cycles;
> >>> + else
> >>> + delta_tsc = 1;
> >>
> >> Why don't we just "return 1" to say that the timer has expired?
> >
> > This case might be rare, so setting delta_tsc = 0 would be safer.
> Queued with this change. Indeed this case matches vmx_arm_hv_timer so
> it's preferrable.
Agreed, thanks.
Regards,
Wanpeng Li
Re: [PATCH v5 00/31] kconfig: move compiler capability tests to Kconfig
2018-05-28 21:23 GMT+09:00 Masahiro Yamada :
> 2018-05-28 18:21 GMT+09:00 Masahiro Yamada :
>>
>> [Introduction]
>>
>> The motivation of this work is to move the compiler option tests to
>> Kconfig from Makefile. A number of kernel features require the
>> compiler support. Enabling such features blindly in Kconfig ends up
>> with a lot of nasty build-time testing in Makefiles. If a chosen
>> feature turns out unsupported by the compiler, what the build system
>> can do is either to disable it (silently!) or to forcibly break the
>> build, despite Kconfig has let the user to enable it. By moving the
>> compiler capability tests to Kconfig, Kconfig entries will be visible
>> only when they are available.
>>
>> [Major Changes in V5]
>>
>> V5 removed the complexity unnecessary for Kconfig.
>>
>> - In order to make the implementation simpler, I drop the lazy
>>argument expansion.
>>In V5, parameters are expanded before passed to a function.
>>(the same behavior as v3)
>>
>> - Replace 'warning', 'error' functions with 'warning-if',
>>'error-if' functions. The new functions are effective
>>only when the condition part is 'y'.
>>
>> - In V4, '$' must be followed by '$' or '('.
>>'$$' meant an escaped '$'.
>>
>>V4 caused a build error for ARC architecture due to the
>>following line:
>>https://github.com/torvalds/linux/blob/v4.17-rc4/arch/arc/Kconfig#L252
>>
>>Of course, we could rephrase "D$" to "D cache", but
>>I treaked the grammar a little bit.
>>
>>Kconfig decided to not support single-letter variable as in "$X".
>>Nor curly braces as in "${CC}" are not supported.
>>This means variable/function references in Kconfig always start
>>with "$(".
>>We can use '$' not followed by '(' as-is.
>>We do not need the "$$" escape sequence.
>>If necessary, we can use a trick to print '$(' verbatim. See below.
>>
>> - Fix a wrong behavior of simply expanded variables.
>>V4 expanded simply expanded variables when used, but it should not.
>>
>>For example,
>>
>>dollar := $
>>X := 1
>>Y := $(dollar)(X)
>>$(info,$(Y))
>>
>>V5 prints '$(X)', not '1'.
>>
>> - Remove a space after a comma is $( ) context.
>>Actually, spaces do not matter in most cases.
>>
>>You can write either
>>
>> $(cc-option,-fstack-protector)
>>
>>or
>>
>> $(cc-option, -fstack-protector)
>>
>>In fact, both style co-exist in our Makefiles too.
>>However, there are some cases where they do matter.
>>
>>I remove spaces after commas for consistency.
>>If you are unsure, no-space-after-comma is always safe.
>>
>> [Major Changes in V4]
>>
>> - In V4, I slightly change the syntax of a function call.
>>I chose grammatical consistency and simplicity.
>>Anyway, Kconfig is deviating from Make behavior already.
>>
>>In v3, a function call looked like this:
>>
>> $(func-name arg1,arg2,arg3)
>>
>>In v4, a function is invoked like follows:
>>
>> $(func-name,arg1,arg2,arg3)
>>
>>The difference is that the function name and the first argument
>>are separated by a comma.
>>
>> - V3 supported single-letter variable like $X.
>>V4 dropped it because we do not need multiple ways to do the
>>same thing.
>>You must always enclose a variable name like $(X).
>>
>> - Support lazy argument expansion. This is necessary for implementing
>>'if', 'and', 'or' functions as in Make.
>>
>> - Add more built-in functions:
>>'if', 'error', 'filename', 'lineno'
>>
>> - Error out if a recursive variable references itself eventually.
>>For example, X = $(X)
>>ends up with a circular expansion. It must be terminated
>>since the expansion would continue eternally.
>>
>> - Update Documentation and unit-tests, accordingly.
>>
>> [Major Changes in V3]
>>
>> This version looks more like Make.
>>
>> - Use = operator instead of 'macro' keyword
>> to define a user-defined function.
>>
>> - 'Recursively expanded variable' is implemented as a side-effect.
>> A variable is a function with zero argument.
>>
>> - Support simply expanded variable which is defined by := operator
>>
>> - Support += operator.
>> Probably, this feature will be useful to accumulate compiler flags.
>> At least, Clang needs some prerequisite flags such as triplet
>> to test other compiler flags.
>>
>> - Support $(info ...) and $(warning ...) built-in functions,
>> which were useful while I was debugging this.
>>
>> - Add documentation
>>
>> - Add unit tests
>>
>> - Collect helpers to scripts/Kconfig.include
>>
>> [Old Versions]
>>
>> V4: https://lkml.org/lkml/2018/5/17/97
>> V3: https://lkml.org/lkml/2018/4/13/37
>> V2: https://lkml.org/lkml/2018/2/16/610
>> V1: https://lkml.org/lkml/2018/2/16/610
>> RFC: https://lkml.org/lkml/2018/2/8/429
>>
>>
>> Masahiro Yamada (31):
>> kbuild: remove kbuild cache
>> kbuild: remove CONFIG_CROSS_COMPILE support
>> kconfig: referen
Re: [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration
Hi.
2018-05-30 4:30 GMT+09:00 Boris Brezillon :
> On Sat, 26 May 2018 10:42:47 +0200
> Miquel Raynal wrote:
>
>> Hi Abhishek,
>>
>> On Fri, 25 May 2018 17:51:29 +0530, Abhishek Sahu
>> wrote:
>>
>> > commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
>> > match, maximize ECC settings") provides generic helpers which
>> > drivers can use for setting up ECC parameters.
>> >
>> > Since same board can have different ECC strength nand chips so
>> > following is the logic for setting up ECC strength and ECC step
>> > size, which can be used by most of the drivers.
>> >
>> > 1. If both ECC step size and ECC strength are already set
>> >(usually by DT) then just check whether this setting
>> >is supported by NAND controller.
>> > 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>> >supported by NAND controller.
>> > 3. Otherwise, try to match the ECC step size and ECC strength closest
>> >to the chip's requirement. If available OOB size can't fit the chip
>> >requirement then select maximum ECC strength which can be fit with
>> >available OOB size.
>> >
>> > This patch introduces nand_ecc_choose_conf function which calls the
>> > required helper functions for the above logic. The drivers can use
>> > this single function instead of calling the 3 helper functions
>> > individually.
>> >
>> > CC: Masahiro Yamada
>> > Signed-off-by: Abhishek Sahu
>> > ---
>> > * Changes from v2:
>> >
>> > 1. Renamed function to nand_ecc_choose_conf.
>> > 2. Minor code reorganization to remove warning and 2 function calls
>> > for nand_maximize_ecc.
>> >
>> > * Changes from v1:
>> > NEW PATCH
>> >
>> > drivers/mtd/nand/raw/nand_base.c | 42
>> >
>> > drivers/mtd/nand/raw/nand_base.c | 31 +++
>> > include/linux/mtd/rawnand.h | 3 +++
>> > 2 files changed, 34 insertions(+)
>> >
>> > diff --git a/drivers/mtd/nand/raw/nand_base.c
>> > b/drivers/mtd/nand/raw/nand_base.c
>> > index 72f3a89..e52019d 100644
>> > --- a/drivers/mtd/nand/raw/nand_base.c
>> > +++ b/drivers/mtd/nand/raw/nand_base.c
>> > @@ -6249,6 +6249,37 @@ int nand_maximize_ecc(struct nand_chip *chip,
>> > }
>> > EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>> >
>> > +/**
>> > + * nand_ecc_choose_conf - Set the ECC strength and ECC step size
>> > + * @chip: nand chip info structure
>> > + * @caps: ECC engine caps info structure
>> > + * @oobavail: OOB size that the ECC engine can use
>> > + *
>> > + * Choose the ECC configuration according to following logic
>> > + *
>> > + * 1. If both ECC step size and ECC strength are already set (usually by
>> > DT)
>> > + *then check if it is supported by this controller.
>> > + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
>> > + * 3. Otherwise, try to match the ECC step size and ECC strength closest
>> > + *to the chip's requirement. If available OOB size can't fit the chip
>> > + *requirement then fallback to the maximum ECC step size and ECC
>> > strength.
>> > + *
>> > + * On success, the chosen ECC settings are set.
>> > + */
>> > +int nand_ecc_choose_conf(struct nand_chip *chip,
>> > +const struct nand_ecc_caps *caps, int oobavail)
>> > +{
>> > + if (chip->ecc.size && chip->ecc.strength)
>> > + return nand_check_ecc_caps(chip, caps, oobavail);
>> > +
>> > + if (!(chip->ecc.options & NAND_ECC_MAXIMIZE) &&
>> > + !nand_match_ecc_req(chip, caps, oobavail))
>> > + return 0;
>> > +
>> > + return nand_maximize_ecc(chip, caps, oobavail);
>>
>> I personally don't mind if nand_maximize_ecc() is called twice in
>> the function if it clarifies the logic. Maybe the following will be
>> more clear for the user?
>>
>> if (chip->ecc.size && chip->ecc.strength)
>> return nand_check_ecc_caps(chip, caps, oobavail);
>>
>> if (chip->ecc.options & NAND_ECC_MAXIMIZE)
>> return nand_maximize_ecc(chip, caps, oobavail);
>>
>> if (!nand_match_ecc_req(chip, caps, oobavail))
>> return 0;
>>
>> return nand_maximize_ecc(chip, caps, oobavail);
>
> I personally don't mind, and it seems Masahiro wanted to keep the logic
> he had used in the denali driver.
>
>>
>> Also, I'm not sure we should just error out when nand_check_ecc_caps()
>> fails. What about something more robust, like:
>>
>> int ret;
>>
>> if (chip->ecc.size && chip->ecc.strength) {
>> ret = nand_check_ecc_caps(chip, caps, oobavail);
>> if (ret)
>> goto maximize_ecc;
>
> Nope. When someone asked for a specific ECC config by passing the
> nand-ecc-xxx props we should apply it or return an erro if it's not
> supported. People passing those props should now what the ECC engine
> supports and pick one valid values.
>
>>
>> return 0;
>> }
>>
>> if (chip->ecc.options & NAND_ECC_MAXIMIZE)
>> goto maximize_ecc;
>>
>>
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi Geert, On 28/05/18 20:15, Geert Uytterhoeven wrote: On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote: On Mon, 28 May 2018, Michael Schmitz wrote: Am 27.05.2018 um 17:49 schrieb Finn Thain: On Sun, 27 May 2018, Michael Schmitz wrote: That should have fixed the warning already ... It's still not fixed (hence my "acked-by" for Geunter's patch). Odd - does link order still matter even though the arch_setup_dev_archdata() function from the core platform code is declared as a weak symbol? I'll see what I can find out on elgar ... Any one of the numerous patches/rfcs/suggestions that I sent will avoid the WARN splat. When I said "it's still not fixed", what I meant to say was, "it's still not fixed in mainline and no proposed fix was accepted to the best of my knowledge". Indeed. Do we have a consensus on the way forward? The merge window for v4.18 will open soon. For whatever it is worth I thought Finn's patch was the best approach (https://lkml.org/lkml/2018/5/17/333, "m68k: Set default dma mask for platform device"). We seem to be hitting quite a few places (within m68k) that otherwise need individual fixes. There is no immediate need to revert existing changes that have already been applied if we use this now either (like my FEC fix, commit f61e64310b75 "m68k: set dma and coherent masks for platform FEC ethernets"). Regards Greg
