Re: [PATCH net-next v3 00/12] net: Introduce ndo_get_port_parent_id()
On Tue, Feb 05, 2019 at 03:53:14PM -0800, Florian Fainelli wrote: > Hi all, > > Based on discussion with Ido and feedback from Jakub there are clearly > two classes of users that implement SWITCHDEV_ATTR_ID_PORT_PARENT_ID: > > - PF/VF drivers which typically only implement return the port's parent > ID, yet have to implement switchdev_port_attr_get() just for that > > - Ethernet switch drivers: mlxsw, ocelot, DSA, etc. which implement more > attributes which we want to be able to eventually veto in the context > of the caller, thus making them candidates for using a blocking notifier > chain Florian, patches look good to me. I'm going to build a kernel with these patches and run some tests. Will report later today. Thanks
Re: [PATCH] device: Fix comment for driver_data in struct device
On 05.02.19 at 14:23, Andy Shevchenko wrote: On Tue, Feb 05, 2019 at 01:19:52PM +0100, David Engraf wrote: dev_set_drvdata/dev_get_drvdata is used to access driver_data in struct device. The original comment might be slight confusing, though we all know the concept of getters and setters. Okay you're right. I was a bit confused about the syntax. Thanks - David void*platform_data; /* Platform specific data, device core doesn't touch it */ void*driver_data; /* Driver data, set and get with - dev_set/get_drvdata */ + dev_set_drvdata/dev_get_drvdata */ struct dev_links_info links; struct dev_pm_info power; struct dev_pm_domain*pm_domain; -- 2.17.1
[PATCH -mm 2/2] proc: use ramfs for executable generation
tmpfs is under CONFIG_TMPFS which can be disabled.
ramfs is always enabled.
Signed-off-by: Alexey Dobriyan
---
fold into proc-test-proc-maps-smaps-smaps_rollup-statm.patch
tools/testing/selftests/proc/proc-pid-vm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/tools/testing/selftests/proc/proc-pid-vm.c
+++ b/tools/testing/selftests/proc/proc-pid-vm.c
@@ -20,7 +20,6 @@
* Test /proc/$PID/smaps_rollup
* Test /proc/$PID/statm
*
- * FIXME require CONFIG_TMPFS which can be disabled
* FIXME test other values from "smaps"
* FIXME support other archs
*/
@@ -58,7 +57,7 @@ static void make_private_tmp(void)
if (mount(NULL, "/", NULL, MS_PRIVATE|MS_REC, NULL) == -1) {
exit(1);
}
- if (mount(NULL, "/tmp", "tmpfs", 0, NULL) == -1) {
+ if (mount(NULL, "/tmp", "ramfs", 0, NULL) == -1) {
exit(1);
}
}
Re: [PATCH] dma-direct: Export dma_direct_alloc() and dma_direct_free()
Hi Thierry, On 2019-02-05 23:29, Thierry Reding wrote: > On Tue, Feb 05, 2019 at 07:02:18PM +0100, Christoph Hellwig wrote: >> On Tue, Feb 05, 2019 at 06:56:11PM +0100, Thierry Reding wrote: >>> Sure, here you go: >>> >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/host1x/cdma.c#n106 >> Yes, I think we I can come up with a nicer helper for that. > One thing I could also try is to remove direct IOMMU API usage at least > from the host1x driver. I think this might work nowadays. > > For Tegra DRM we still need direct IOMMU API usage because we need to be > able to map into an IOMMU domain without knowing the struct device * > that we're mapping for (it could be needed by any of up to four display > controllers). For host1x we always only have one struct device *, so the > DMA mapping API should be good enough. In case of Tegra DRM you may try to use Exynos DRM approach. Exynos DRM also consists of more than one DMA capable device and uses one common IOMMU address space for them. It is achieved by attaching all those devices to the IOMMU domain of the first CRTC device that has been registered. Then that device is used for DMA-mapping calls. It is not very elegant, but works fine and allows to use standard DMA-mapping calls. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
[PATCH -mm 1/2] proc: exit correctly in /proc/*/maps test
If open() or writev() fails, test will hang waiting for child test
process.
Signed-off-by: Alexey Dobriyan
---
fold into proc-test-proc-maps-smaps-smaps_rollup-statm.patch
tools/testing/selftests/proc/proc-pid-vm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tools/testing/selftests/proc/proc-pid-vm.c
+++ b/tools/testing/selftests/proc/proc-pid-vm.c
@@ -189,11 +189,11 @@ static int make_exe(const uint8_t *payload, size_t len)
fd = openat(AT_FDCWD, "/tmp", O_WRONLY|O_EXCL|O_TMPFILE, 0700);
if (fd == -1) {
- return 1;
+ exit(1);
}
if (writev(fd, iov, 3) != sizeof(struct elf64_hdr) + sizeof(struct
elf64_phdr) + len) {
- return 1;
+ exit(1);
}
/* Avoid ETXTBSY on exec. */
Re: [PATCH v10 0/4] Media Device Allocator API
On 2/5/19 7:10 PM, shuah wrote:
> On 2/1/19 2:21 AM, Hans Verkuil wrote:
>> On 2/1/19 1:46 AM, shuah wrote:
>>> Hi Hans,
>>>
>>> On 1/30/19 12:42 AM, Hans Verkuil wrote:
On 1/30/19 2:50 AM, shuah wrote:
> On 1/29/19 2:43 AM, Hans Verkuil wrote:
>> On 1/29/19 12:48 AM, shuah wrote:
>>> Hi Hans,
>>>
>>> On 1/28/19 5:03 AM, Hans Verkuil wrote:
Hi Shuah,
On 1/24/19 9:32 PM, Shuah Khan wrote:
> Media Device Allocator API to allows multiple drivers share a media
> device.
> This API solves a very common use-case for media devices where one
> physical
> device (an USB stick) provides both audio and video. When such media
> device
> exposes a standard USB Audio class, a proprietary Video class, two or
> more
> independent drivers will share a single physical USB bridge. In such
> cases,
> it is necessary to coordinate access to the shared resource.
>
> Using this API, drivers can allocate a media device with the shared
> struct
> device as the key. Once the media device is allocated by a driver,
> other
> drivers can get a reference to it. The media device is released when
> all
> the references are released.
>
> - This patch series is tested on 5.0-rc3 and addresses comments on
> v9 series from Hans Verkuil.
> - v9 was tested on 4.20-rc6.
> - Tested sharing resources with kaffeine, vlc, xawtv, tvtime, and
> arecord. When analog is streaming, digital and audio user-space
> applications detect that the tuner is busy and exit. When
> digital
> is streaming, analog and audio applications detect that the
> tuner is
> busy and exit. When arecord is owns the tuner, digital and
> analog
> detect that the tuner is busy and exit.
I've been doing some testing with my au0828, and I am confused about
one
thing, probably because it has been too long ago since I last looked
into
this in detail:
>>>
>>> Great.
>>>
Why can't I change the tuner frequency if arecord (and only arecord) is
streaming audio? If arecord is streaming, then it is recording the
audio
from the analog TV tuner, right? So changing the analog TV frequency
should be fine.
>>>
>>> Changing analog TV frequency would be s_frequency. The way it works is
>>> any s_* calls would require holding the pipeline. In Analog TV case, it
>>> would mean holding both audio and video pipelines for any changes
>>> including TV.
>>>
>>> As I recall, we discussed this design and the decision was to make all
>>> s_* calls interfaces to hold the tuner. A special exception is g_tuner
>>> in case of au0828. au0828 initializes the tuner from s_* interfaces and
>>> its g_tuner interfaces. Allowing s_frequency to proceed will disrupt the
>>> arecord audio stream.
>>>
>>> Query (q_*) works just fine without holding the pipeline. I limited the
>>> analog holds to just the ones that are required. The current set is
>>> required to avoid audio stream disruptions.
>>
>> So I am not sure about that ('avoid audio stream disruptions'): if I
>> stream video AND use arecord, then I can just set the frequency while
>> streaming. Doesn't that interrupt audio as well? And are you sure
>> changing
>> the tuner frequency actually disrupts audio? And if audio is disrupted,
>> are we talking about a glitch or is audio permanently disrupted?
>
> I think it is a glitch. I will run some tests and let you know.
>>
>> That's basically the inconsistent behavior I noticed: just running
>> arecord
>> will prevent me from changing the frequency, but if I run arecord and
>> stream
>> video, then it is suddenly OK to change the frequency.
>
> How are you changing frequency? I want to duplicate what you are doing.
v4l2-ctl -f
>>>
>>> I am not seeing the inconsistent behavior. Here are my results.
>>>
>>> 1. Started acecord and while it is running:
>>>
>>> arecord -M -D plughw:2,0 -c2 -f S16_LE -t wav foo.wav
>>> Recording WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
>>>
>>> 2. Ran v4l2-ctl -f as follows:
>>>
>>> v4l2-ctl -f 700
>>> VIDIOC_G_TUNER: failed: Device or resource busy
>>> VIDIOC_S_FREQUENCY: failed: Device or resource busy
>>>
>>> Based on the current implementation, it failed with resource
>>> busy as expected.
>>>
>>> 3. Started v4l2-ctl as follows:
>>>
>>> v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0
>>> VIDIOC_STREAMON: failed: Device or resource busy
>>
>> Why is this? You have one analog tuner and it delivers independent audio
>> and video
[PATCH] ramfs: support O_TMPFILE
Signed-off-by: Alexey Dobriyan
---
fs/ramfs/inode.c | 12
1 file changed, 12 insertions(+)
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -145,6 +145,17 @@ static int ramfs_symlink(struct inode * dir, struct dentry
*dentry, const char *
return error;
}
+static int ramfs_tmpfile(struct inode *dir, struct dentry *dentry, umode_t
mode)
+{
+ struct inode *inode;
+
+ inode = ramfs_get_inode(dir->i_sb, dir, mode, 0);
+ if (!inode)
+ return -ENOSPC;
+ d_tmpfile(dentry, inode);
+ return 0;
+}
+
static const struct inode_operations ramfs_dir_inode_operations = {
.create = ramfs_create,
.lookup = simple_lookup,
@@ -155,6 +166,7 @@ static const struct inode_operations
ramfs_dir_inode_operations = {
.rmdir = simple_rmdir,
.mknod = ramfs_mknod,
.rename = simple_rename,
+ .tmpfile= ramfs_tmpfile,
};
/*
Re: [PATCH v3 1/4] staging: iio: ad7780: add gain & filter gpio support
Peter, this email was marked as spam for me (and probably others) because of this DKIM signature: DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pmeerw.net; s=mail; where the problem is that when the message goes through the vger.kernel.org mailing list machinery, the header whitespace will be modified. As a result, the DKIM signature no longer matched, and at least gmail will consider the email to be spam. That's arguably a bug in the vger mail server setup, but equally arguably the "c=simple/simple" model of hashing in DKIM is just broken, and shouldn't be used. Whitespace in SMTP headers is simply not meaningful, and checking whitespace in them (like simple/simple does) is misguided. If you have control over the DKIM setup of pmeerw.net, may I suggest changing the DKIM setup to use "c=relaxed/relaxed", which doesn't invalidate the signature just for whitespace changes in the headers, and which is the proper DKIM model to use. The simple canonicalization really is too simple-minded for email. Linus On Tue, Feb 5, 2019 at 7:58 PM Peter Meerwald-Stadler wrote: > > On Tue, 5 Feb 2019, Renato Lui Geh wrote: > > > Previously, the AD7780 driver only supported gpio for the 'powerdown' > > pin. This commit adds suppport for the 'gain' and 'filter' pin. > > comments below [...]
Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
On Tue, Feb 05, 2019 at 11:19:04AM -0800, Joe Perches wrote:
> On Tue, 2019-02-05 at 11:14 -0800, David Miller wrote:
> > From: Joe Perches
> > Date: Tue, 05 Feb 2019 10:42:54 -0800
> >
> > > On Mon, 2019-02-04 at 19:20 -0800, David Miller wrote:
> > >> From: Thierry Reding
> > >> Date: Mon, 4 Feb 2019 17:42:13 +0100
> > >>
> > >> > @@ -7316,7 +7325,7 @@ static int rtl_get_ether_clk(struct
> > >> > rtl8169_private *tp)
> > >> > static int rtl_init_one(struct pci_dev *pdev, const struct
> > >> > pci_device_id *ent)
> > >> > {
> > >> > const struct rtl_cfg_info *cfg = rtl_cfg_infos +
> > >> > ent->driver_data;
> > >> > - u8 mac_addr[ETH_ALEN] __aligned(4) = {};
> > >> > + u8 mac_addr[ETH_ALEN] = {};
> > >> > struct rtl8169_private *tp;
> > >>
> > >> I agree with Heiner, you have to provide at least 2 byte alignment for
> > >> this
> > >> buffer due to the reasons he stated.
> > >
> > > It's declared after a pointer so it is already is 2 byte aligned.
> > >
> > > A lot of drivers wouldn't work otherwise.
> >
> > That's assuming a lot about what the compiler will do when nit allocates
> > local variables to the stack.
>
> It's also assuming what a compiler will do when
> it defines a struct.
This is not a structure member, it's a local variable. I'm not aware of
any C norm requirement for ordering of local variables on the stack.
After all, some of them might not be on the stack at all and use only
registers or be optimized out completely.
Michal Kubecek
[PATCH 2/2] [-mm only] mm/shuffle: Default enable all shuffling
Per Andrew's request arrange for all memory allocation shuffling code to
be enabled by default.
The page_alloc.shuffle command line parameter can still be used to
disable shuffling at boot, but the kernel will default enable the
shuffling if the command line option is not specified.
Signed-off-by: Dan Williams
---
init/Kconfig |4 ++--
mm/shuffle.c |4 ++--
mm/shuffle.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index cfa199f3e9be..12557e12be4c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1697,7 +1697,7 @@ config SLAB_MERGE_DEFAULT
command line.
config SLAB_FREELIST_RANDOM
- default n
+ default y
depends on SLAB || SLUB
bool "SLAB freelist randomization"
help
@@ -1716,7 +1716,7 @@ config SLAB_FREELIST_HARDENED
config SHUFFLE_PAGE_ALLOCATOR
bool "Page allocator randomization"
- default SLAB_FREELIST_RANDOM && ACPI_NUMA
+ default y
help
Randomization of the page allocator improves the average
utilization of a direct-mapped memory-side-cache. See section
diff --git a/mm/shuffle.c b/mm/shuffle.c
index 3ce12481b1dc..a979b48be469 100644
--- a/mm/shuffle.c
+++ b/mm/shuffle.c
@@ -9,8 +9,8 @@
#include "internal.h"
#include "shuffle.h"
-DEFINE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
-static unsigned long shuffle_state __ro_after_init;
+DEFINE_STATIC_KEY_TRUE(page_alloc_shuffle_key);
+static unsigned long shuffle_state __ro_after_init = 1 << SHUFFLE_ENABLE;
/*
* Depending on the architecture, module parameter parsing may run
diff --git a/mm/shuffle.h b/mm/shuffle.h
index fc1e327ae22d..466a5620e0aa 100644
--- a/mm/shuffle.h
+++ b/mm/shuffle.h
@@ -19,7 +19,7 @@ enum mm_shuffle_ctl {
#define SHUFFLE_ORDER (MAX_ORDER-1)
#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
-DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
+DECLARE_STATIC_KEY_TRUE(page_alloc_shuffle_key);
extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
extern void __shuffle_free_memory(pg_data_t *pgdat);
static inline void shuffle_free_memory(pg_data_t *pgdat)
[PATCH 0/2] mm/shuffle: Fix + default enable
Andrew, Please fold patch1 into: mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization.patch Patch2, as marked, is the "always-on" shuffle patch for -mm only. --- Dan Williams (2): mm/shuffle: Fix shuffle enable [-mm only] mm/shuffle: Default enable all shuffling init/Kconfig |4 ++-- mm/shuffle.c | 20 +--- mm/shuffle.h |2 +- 3 files changed, 20 insertions(+), 6 deletions(-)
[PATCH 1/2] mm/shuffle: Fix shuffle enable
The removal of shuffle_store() in v10 of the patch series was prompted
by the review feedback to convert page_alloc_shuffle() to __memint. I
obviously booted a stale kernel build in my tests because
shuffle_store() is indeed required:
BUG: unable to handle kernel NULL pointer dereference at
#PF error: [INSTR]
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1+ #2867
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
RIP: 0010: (null)
Code: Bad RIP value.
RSP: :82603e78 EFLAGS: 00010046
RAX: RBX: RCX: cccd
RDX: 8261d7c0 RSI: 8244c010 RDI: 88843ffe1aaa
RBP: 88843ffe1aac R08: 83486978 R09:
R10: 82603e80 R11: 0048 R12: 88843ffe1a97
R13: 88843ffe1aaa R14: 8244c010 R15: 016d
FS: () GS:88811be0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ffd6 CR3: 02614000 CR4: 000606b0
Call Trace:
? parse_args+0x170/0x360
? set_init_arg+0x55/0x55
? start_kernel+0x1d8/0x4c4
? set_init_arg+0x55/0x55
? secondary_startup_64+0xa4/0xb0
Reintroduce it and mark it __meminit. Given the sysfs attribute is not
writable it will never be called after init.
Signed-off-by: Dan Williams
---
mm/shuffle.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/mm/shuffle.c b/mm/shuffle.c
index 19bbf3e37fb6..3ce12481b1dc 100644
--- a/mm/shuffle.c
+++ b/mm/shuffle.c
@@ -38,7 +38,21 @@ extern int shuffle_show(char *buffer, const struct
kernel_param *kp)
return sprintf(buffer, "%c\n", test_bit(SHUFFLE_ENABLE, _state)
? 'Y' : 'N');
}
-module_param_call(shuffle, NULL, shuffle_show, _param, 0400);
+
+static __meminit int shuffle_store(const char *val,
+ const struct kernel_param *kp)
+{
+ int rc = param_set_bool(val, kp);
+
+ if (rc < 0)
+ return rc;
+ if (shuffle_param)
+ page_alloc_shuffle(SHUFFLE_ENABLE);
+ else
+ page_alloc_shuffle(SHUFFLE_FORCE_DISABLE);
+ return 0;
+}
+module_param_call(shuffle, shuffle_store, shuffle_show, _param, 0400);
/*
* For two pages to be swapped in the shuffle, they must be free (on a
pull-request: wireless-drivers-next 2019-02-06
Hi Dave, here's a pull request to net-next for 5.1, more info below. Please let me know if there are any problems. Kalle The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-02-06 for you to fetch changes up to 030b43671ae88f827a415ad35700705ffc10d10d: wireless: prefix header search paths with $(srctree)/ (2019-02-01 14:42:25 +0200) wireless-drivers-next patches for 5.1 First set of patches for 5.1. Lots of new features in various drivers but nothing really special standing out. Major changes: brcmfmac * DMI nvram filename quirk for PoV TAB-P1006W-232 tablet rsi * support for hardware scan offload iwlwifi * support for Target Wakeup Time (TWT) -- a feature that allows the AP to specify when individual stations can access the medium * support for mac80211 AMSDU handling * some new PCI IDs * relicense the pcie submodule to dual GPL/BSD * reworked the TOF/CSI (channel estimation matrix) implementation * Some product name updates in the human-readable strings mt76 * energy detect regulatory compliance fixes * preparation for MT7603 support * channel switch announcement support mwifiex * support for sd8977 chipset qtnfmac * support for 4addr mode * convert to SPDX license identifiers Andrei Otcheretianski (1): iwlwifi: mvm: Disconnect on large beacon loss Andrey Shevchenko (1): qtnfmac: support EBUSY errcode for QLINK protocol Bernd Edlinger (5): rtl8723ae: Take the FW LPS mode handling out rtl8723ae: Dont use old data for input gain control rtl8723ae: Re-introduce the adaptive rate control rtlwifi: Don't clear num_rx_inperiod too early rt2x00: Work around a firmware bug with shared keys Colin Ian King (8): ray_cs: fix array out-of-bounds access mt76: make const array 'data' static, shrinks object size iwlwifi: pcie: make array 'prop' static, shrinks object size iwlwifi: fix spelling mistake "registrating" -> "registering" libertas: fix indentation issue cw1200: fix indentation issues rtlwifi: rtl818x: fix indentation issue wlcore: clean up an indentation issue David Spinadel (1): iwlwifi: mvm: Change FW channel info API Emmanuel Grumbach (4): iwlwifi: mvm: advertise support for TWT in the Extended Capability IE iwlwifi: mvm: rely on mac80211 to configure TWT support iwlwifi: mvm: fix firmware statistics usage iwlwifi: mvm: freeze management TXQ timer when station goes to sleep Felix Fietkau (12): mt76: add size check for additional rx fragments mt76: throttle transmission of buffered multicast packets mt76: request tx status for powersave released EOSP packet mt76: fix tx status reporting for non-probing frames mt76: set IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR flag mt76: move mt76x02_get_txpower to mt76 core mt76: move mt76x02_phy_get_min_avg_rssi to mt76 core mt76: fix rssi ewma tracking mt76: fix signedness of rx status signal field mt76: add channel switch announcement support mt76: fix per-chain signal strength reporting mt76: avoid scheduling tx queues for powersave stations Greg Kroah-Hartman (15): iwlegacy: no need to check return value of debugfs_create functions wlcore: no need to check return value of debugfs_create functions wl1251: no need to check return value of debugfs_create functions wl12xx: no need to check return value of debugfs_create functions wl18xx: no need to check return value of debugfs_create functions rtlwifi: no need to check return value of debugfs_create functions qtnfmac: no need to check return value of debugfs_create functions cw1200: no need to check return value of debugfs_create functions b43: no need to check return value of debugfs_create functions b43legacy: no need to check return value of debugfs_create functions brcmsmac: no need to check return value of debugfs_create functions rsi: no need to check return value of debugfs_create functions rt2x00: no need to check return value of debugfs_create functions libertas: no need to check return value of debugfs_create functions mwifiex: no need to check return value of debugfs_create functions Gustavo A. R. Silva (1): qtnfmac: use struct_size() in kzalloc() Hans de Goede (2): brcmfmac: Add DMI nvram filename quirk for PoV TAB-P1006W-232 tablet brcmfmac: Use firmware_request_nowarn for the clm_blob Hauke Mehrtens (1): mt76: Add missing include of linux/module.h Hemantkumar Suthar (1): mwifiex: add support for sd8977
[PATCH] mips: loongson64: remove unreachable(), fix loongson_poweroff().
On my Yeeloong 8089, I noticed the machine fails to shutdown
properly, and often, the function mach_prepare_reboot() is
unexpectedly executed, thus the machine reboots instead. A
wait loop is needed to ensure the system is in a well-defined
state before going down.
In commit 997e93d4df16 ("MIPS: Hang more efficiently on
halt/powerdown/restart"), a general superset of the wait loop for all
platforms is already provided, so we don't need to implement our own.
This commit simply removes the unreachable() compiler marco after
mach_prepare_reboot(), thus allowing the execution of machine_hang().
My test shows that the machine is now able to shutdown successfully.
Please note that there are two different bugs preventing the machine
from shutting down, another work-in-progress commit is needed to
fix a lockup in cpufreq / i8259 driver, please read Reference, this
commit does not fix that bug.
Reference: https://lkml.org/lkml/2019/2/5/908
Signed-off-by: Yifeng Li
---
arch/mips/loongson64/common/reset.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/mips/loongson64/common/reset.c
b/arch/mips/loongson64/common/reset.c
index a60715e11306..b26892ce871c 100644
--- a/arch/mips/loongson64/common/reset.c
+++ b/arch/mips/loongson64/common/reset.c
@@ -59,7 +59,12 @@ static void loongson_poweroff(void)
{
#ifndef CONFIG_LEFI_FIRMWARE_INTERFACE
mach_prepare_shutdown();
- unreachable();
+
+ /*
+* It needs a wait loop here, but mips/kernel/reset.c already calls
+* a generic delay loop, machine_hang(), so simply return.
+*/
+ return;
#else
void (*fw_poweroff)(void) = (void *)loongson_sysconf.poweroff_addr;
--
2.20.1
Re: [PATCH v2] dma-direct: do not allocate a single page from CMA area
On Tue, Feb 05, 2019 at 03:05:30PM -0800, Nicolin Chen wrote:
> > And my other concern is that this skips allocating from the per-device
> > pool, which drivers might rely on.
>
> Actually Robin had the same concern at v1 and suggested that we could
> always use DMA_ATTR_FORCE_CONTIGUOUS to enforce into per-device pool.
That is both against the documented behavior of DMA_ATTR_FORCE_CONTIGUOUS
and doesn't help existing drivers that specify their CMA area in DT.
> > To be honest I'm not sure there is
> > much of a point in the per-device CMA pool vs the traditional per-device
> > coherent pool, but I'd rather change that behavior in a clearly documented
> > commit with intentions rather as a side effect from a random optimization.
>
> Hmm..sorry, I don't really follow this suggestion. Is it possible for
> you to make it clear that what should I do for the change?
Something like this (plus proper comments):
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index b2a87905846d..789d734f0f77 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -192,10 +192,19 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
struct page *dma_alloc_from_contiguous(struct device *dev, size_t count,
unsigned int align, bool no_warn)
{
+ struct cma *cma;
+
if (align > CONFIG_CMA_ALIGNMENT)
align = CONFIG_CMA_ALIGNMENT;
- return cma_alloc(dev_get_cma_area(dev), count, align, no_warn);
+ if (dev && dev->cma_area)
+ cma = dev->cma_area;
+ else if (count > PAGE_SIZE)
+ cma = dma_contiguous_default_area;
+ else
+ return NULL;
+
+ return cma_alloc(cma, count, align, no_warn);
}
/**
Re: [PATCH v3 0/2] Bluetooth: Add NULL check for tiocmget() and tiocmset()
Hi Myungho, >>> tiocmget() and tiocmset() operations are optional and some tty drivers >>> like pty miss the operations. Add NULL checks to prevent from >>> dereference. >>> >>> Myungho Jung (2): >>> Bluetooth: hci_ath: Add NULL check for tiocmget() and tiocmset() in >>> ath_setup() >>> Bluetooth: hci_ldisc: Add NULL check for tiocmget() and tiocmset() in >>> hci_uart_set_flow_control() >>> >>> drivers/bluetooth/hci_ath.c | 6 ++ >>> drivers/bluetooth/hci_ldisc.c | 4 >>> 2 files changed, 10 insertions(+) >> >> why are we not enforcing the availability of these in the hci_uart_tty_open? > > Are the operations required on any HCI UART drivers? For now, I found only 5 > drivers (ath, bcm, intel, mrvl, and qca) are explicitly calling them. So, I'm > not sure whether it breaks any existing code with other drivers if returning > error in open(). the H:4 spec requires setting flow control. In some cases this is done by the hciattach or btattach utility, but it still means that it is required. So failing on TTYs that don’t support it is just fine. Regards Marcel
Re: [PATCH] dma-direct: Export dma_direct_alloc() and dma_direct_free()
On Tue, Feb 05, 2019 at 11:29:12PM +0100, Thierry Reding wrote: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/host1x/cdma.c#n106 > > > > Yes, I think we I can come up with a nicer helper for that. > > One thing I could also try is to remove direct IOMMU API usage at least > from the host1x driver. I think this might work nowadays. > > For Tegra DRM we still need direct IOMMU API usage because we need to be > able to map into an IOMMU domain without knowing the struct device * > that we're mapping for (it could be needed by any of up to four display > controllers). For host1x we always only have one struct device *, so the > DMA mapping API should be good enough. If you can convert it to plain DMA API usage, please do. I did look into an IOMMU API memory allocator, and while we can do it easily for coherent devices, we need some arch hooks for non-coherent device support. With a pending series from me we have those for arm64, but 32-bit arm support will require a lot more work first.
Re: [PATCH] usb: gadget: function: f_uac1 add interface assoc desc
liangshengjun writes: > Add f_uac1 interface association descriptor, make f_uac1 link other > function(like f_uvc) is possible. > > Signed-off-by: Liang Shengjun doesn't apply. Also, remember to break commit log lines at 72 columns -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: dwc3: Enable GBit Ethernet on Odroid XU4
hi, Jochen Sprickerhof writes: > Note that it only works with USB_XHCI_PLATFORM=y. Also it needs a hard > reset when coming from an unpatched kernel. > > This was included in the original patch in > https://patchwork.kernel.org/patch/9992809/ but got dropped when > accepted in d8c80bb3b55b phy: exynos5-usbdrd: Calibrate LOS levels for > exynos5420/5800. > > Old behaviour: > > $ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M > > New behaviour: > > $ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M > > Tested on Debian unstable using u-boot-exynos (2018.11+dfsg-2) and Linux > 4.19.14. > > Signed-off-by: Jochen Sprickerhof > --- > > Hi, > > I'm not sure why this it only works with the driver compiled into the > kernel nor why it needs a hard reset or why it was the line was dropped > when the patch was accepted. Would be great to get some feedback of the > authors. > > Cheers Jochen > > drivers/usb/dwc3/core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index a1b126f90261..0008bccc30aa 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -1169,7 +1169,8 @@ static int dwc3_core_init_mode(struct dwc3 *dwc) > dev_err(dev, "failed to initialize host\n"); > return ret; > } > - phy_calibrate(dwc->usb2_generic_phy); > + if (dwc->usb2_generic_phy) > + phy_calibrate(dwc->usb2_generic_phy); I can't see why this is necessary. What's really going on? Why is this branch helping? -- balbi signature.asc Description: PGP signature
Re: [PATCH] omap3: give off mode enable a more prominent place
On Mon, 4 Feb 2019 10:43:17 -0800 Tony Lindgren wrote: > * Andreas Kemnade [190204 18:33]: > > On Mon, 4 Feb 2019 07:56:04 -0800 > > Tony Lindgren wrote: > > > > > * Andreas Kemnade [190202 06:01]: > > > > Enabling off mode was only reachable deeply hidden > > > > in the debugfs. As powersaving is an important feature, > > > > move the option out of its shady place. > > > > > > How about let's enable always if we have the twl4030 > > > configured to allow it? You can just check if the dts has > > > "ti,twl4030-power-idle" or "ti,twl4030-power-idle-osc-off" > > > properties set. > > > > > > In order to enable deeper idle states, the user space still > > > needs to idle the UARTs and possibly other hardware blocking > > > idle. So we should be safe there. > > > > > Let us not mix up runtime pm and system pm. The uarts need > > to be idled for runtime suspend, but they are off/ret for > > system suspend without userspace intervention, so allowing off mode > > will have an influence even without uart runtime suspend, > > and also probably for other powerdomains (non-core/per). > > So we still need to be sure to handle at least some erratas and > > context save/restore correctly. > > True that's a good point. > > > Your Idea seems to be in pseudocode > > if (powersaving_wanted) > > enable_off_mode() > > > > I had something in mind like > > if (system_is_trusted_to_handle_offmode() > > enable_off_mode() > > For omap3, the properties for "ti,twl4030-power-idle" or > "ti,twl4030-power-idle-osc-off" mean just that. > Hmm, system = software + hardware. At least that I had in mind when writing this text. So for the software part: I guess off mode is on our all test schedule, so it should be reliable. dt describes the hardware, so there should be any MODE7 quirks defined if they are required and the proper pmic setting. But wait... twl4030-power.c is to a big part about switching regulators on and off. But how does that connect to hwmods going to ret or off mode? That is imho slightly another topic. Ok, looking a bit closer, there is the sys_off_mode line which needs to be used. So we have to derive that from the devicetree. > The PMIC is wired and configured for off mode, and those > properties should not be set unless the system is truly capable > of entering off mode. If not set, we should not enable off > idle by default. > > Otherwise the boards should be already using just > "ti,twl4030-power" or "ti,twl4030-power-reset". > We have also ti,twl4030-power-omap3-sdp, ti,twl4030-power-omap3-ldp, ti,twl4030-power-omap3-evm so we have to maintain a list, especially if we want to allow another pmic. But since it is about connecting the soc to the pmic, we could also add a flag in the dtb on the soc side, so we are prepared if someone uses another pmic. It feels a bit strange to query something from devicetree for another device. Regards, Andreas PS: I hope my omap-gta04.dtsi-related patches have made their way into your review queue and are not starving in a generic lkml fallback folder pgpyUvzamSqb6.pgp Description: OpenPGP digital signature
Re: [RFC v2] usb: xhci: add Immediate Data Transfer support
Hi,
Nicolas Saenz Julienne writes:
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 40fa25c4d041..a4efbe62a1a3 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3272,8 +3272,15 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> field |= TRB_IOC;
> more_trbs_coming = false;
> td->last_trb = ring->enqueue;
> +
> + if (xhci_urb_suitable_for_idt(urb)) {
> + memcpy(_addr, urb->transfer_buffer,
> +trb_buff_len);
> + field |= TRB_IDT;
> + }
> }
>
> +
trailing change
> @@ -3411,6 +3418,12 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> if (urb->transfer_buffer_length > 0) {
> u32 length_field, remainder;
>
> + if (xhci_urb_suitable_for_idt(urb)) {
> + memcpy(>transfer_dma, urb->transfer_buffer,
> +urb->transfer_buffer_length);
> + field |= TRB_IDT;
> + }
> +
> remainder = xhci_td_remainder(xhci, 0,
> urb->transfer_buffer_length,
> urb->transfer_buffer_length,
> @@ -3420,6 +3433,7 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> TRB_INTR_TARGET(0);
> if (setup->bRequestType & USB_DIR_IN)
> field |= TRB_DIR_IN;
> +
trailing change
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 005e65922608..dec62f7f5dc8 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1238,6 +1238,21 @@ EXPORT_SYMBOL_GPL(xhci_resume);
>
> /*-*/
>
> +/*
> + * Bypass the DMA mapping if URB is suitable for Immediate Transfer (IDT),
> + * we'll copy the actual data into the TRB address register. This is limited
> to
> + * transfers up to 8 bytes on output endpoints of any kind with
> wMaxPacketSize
> + * >= 8 bytes.
> + */
> +static int xhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
> + gfp_t mem_flags)
> +{
> + if (xhci_urb_suitable_for_idt(urb))
> + return 0;
> +
> + return usb_hcd_map_urb_for_dma(hcd, urb, mem_flags);
> +}
don't you need a matching unmap_urb_for_dma()??
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 652dc36e3012..9d77b0901ab7 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1295,6 +1295,8 @@ enum xhci_setup_dev {
> #define TRB_IOC (1<<5)
> /* The buffer pointer contains immediate data */
> #define TRB_IDT (1<<6)
> +/* TDs smaller than this might use IDT */
Technically, "TDs at most this" since you're 8 itself is an allowed
size.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v3 0/2] Bluetooth: Add NULL check for tiocmget() and tiocmset()
On Tue, Feb 05, 2019 at 02:55:50PM +0100, Marcel Holtmann wrote: > Hi Myungho, > > > tiocmget() and tiocmset() operations are optional and some tty drivers > > like pty miss the operations. Add NULL checks to prevent from > > dereference. > > > > Myungho Jung (2): > > Bluetooth: hci_ath: Add NULL check for tiocmget() and tiocmset() in > >ath_setup() > > Bluetooth: hci_ldisc: Add NULL check for tiocmget() and tiocmset() in > >hci_uart_set_flow_control() > > > > drivers/bluetooth/hci_ath.c | 6 ++ > > drivers/bluetooth/hci_ldisc.c | 4 > > 2 files changed, 10 insertions(+) > > why are we not enforcing the availability of these in the hci_uart_tty_open? > > Regards > > Marcel > Hi Marcel, Are the operations required on any HCI UART drivers? For now, I found only 5 drivers (ath, bcm, intel, mrvl, and qca) are explicitly calling them. So, I'm not sure whether it breaks any existing code with other drivers if returning error in open(). Thanks, Myungho
Re: [PATCH V4 8/9] jump_label: Batch updates if arch supports it
On Mon, 4 Feb 2019 20:59:01 +0100
Daniel Bristot de Oliveira wrote:
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -407,6 +407,7 @@ bool jump_label_can_update_check(struct jump_entry
> *entry, bool init)
> return 0;
> }
>
> +#ifndef HAVE_JUMP_LABEL_BATCH
> static void __jump_label_update(struct static_key *key,
> struct jump_entry *entry,
> struct jump_entry *stop,
> @@ -419,6 +420,34 @@ static void __jump_label_update(struct static_key *key,
> }
> }
> }
> +#else
> +static void __jump_label_update(struct static_key *key,
> + struct jump_entry *entry,
> + struct jump_entry *stop,
> + bool init)
> +{
> + for_each_label_entry(key, entry, stop) {
> +
> + if (!jump_label_can_update_check(entry, init))
> + continue;
> +
> + if (arch_jump_label_transform_queue(entry,
> + jump_label_type(entry)))
> + continue;
> +
> + /*
> + * Queue's overflow: Apply the current queue, and then
> + * queue again. If it stills not possible to queue, BUG!
> + */
> + arch_jump_label_transform_apply();
> + if (!arch_jump_label_transform_queue(entry,
> + jump_label_type(entry))) {
> + BUG();
Please do not relay on BUG(), since in both case (applied or not),
jump_label is not critical for normal operation. I think you should use
WARN_ONCE() here and lock the jump_label so that root user can report it
to us :)
Thank you,
--
Masami Hiramatsu
Re: [PATCH] rtc: rs5c372: Fix reading from rtc when the oscillator got interrupted.
Hi Alexandre,
thanks a lot!!
On 05.02.19 22:55, Alexandre Belloni wrote:
> Hi,
>
> On 11/01/2019 13:15:39+, oliver.r...@wago.com wrote:
>> When the oscillator of the rtc gets interrupted,
>> e.g. due to an empty battery, reading from the rtc will now return an error
>> and the oscillator bit will be cleared, once the rtc is successfully reset.
>>
>> Signed-off-by: Oliver Rohe
>> ---
>> drivers/rtc/rtc-rs5c372.c | 60
>> ---
>> 1 file changed, 52 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
>> index ff35dce..91d1475 100644
>> --- a/drivers/rtc/rtc-rs5c372.c
>> +++ b/drivers/rtc/rtc-rs5c372.c
>> @@ -52,8 +52,10 @@
>> # define RS5C_CTRL1_CT4 (4 << 0)/* 1 Hz level irq */
>> #define RS5C_REG_CTRL2 15
>> # define RS5C372_CTRL2_24 (1 << 5)
>> -# define R2x2x_CTRL2_XSTP (1 << 5)/* only if R2x2x */
>> -# define RS5C_CTRL2_XSTP (1 << 4)/* only if !R2x2x */
>> +# define RS5C_CTRL2_XSTP (1 << 4)/* only if !R2x2x */
>
> This should probably use tabs instead of spaces
:)
>> +# define R2x2x_CTRL2_VDET (1 << 6)/* only if R2x2x */
>> +# define R2x2x_CTRL2_XSTP (1 << 5)/* only if R2x2x */
>> +# define R2x2x_CTRL2_PON (1 << 4)/* only if R2x2x */
>> # define RS5C_CTRL2_CTFG (1 << 2)
>> # define RS5C_CTRL2_AAFG (1 << 1)/* or WAFG */
>> # define RS5C_CTRL2_BAFG (1 << 0)/* or DAFG */
>> @@ -212,10 +214,31 @@ static int rs5c372_rtc_read_time(struct device *dev,
>> struct rtc_time *tm)
>> struct i2c_client *client = to_i2c_client(dev);
>> struct rs5c372 *rs5c = i2c_get_clientdata(client);
>> int status = rs5c_get_regs(rs5c);
>> +unsigned char ctrl2 = rs5c->regs[RS5C_REG_CTRL2];
>>
>> if (status < 0)
>> return status;
>>
>> +switch (rs5c->type) {
>> +case rtc_r2025sd:
>> +case rtc_r2221tl:
>> +if (ctrl2 & R2x2x_CTRL2_VDET)
>> +dev_warn(>dev, "rtc battery voltage drop below
>> threshold detected.\n");
>
> VDET doesn't mean anything specific regarding timekeeping so I wouldn't warn
> here.
VDET means in case the chip is powered by a battery, that is about to die
sometime soon, it gives you heads up.
>
>> +if (ctrl2 & R2x2x_CTRL2_PON)
>> +dev_warn(>dev, "rtc battery voltage drop to
>> zero detected.\n");
>
> You should return -EINVAL directly here
The PON implies the XSTP bit, so I only return from there, just to print all
the warning messages, but I can return directly from here if you want.
>
>> +if ((rs5c->type == rtc_r2025sd && !(ctrl2 & R2x2x_CTRL2_XSTP))
>> ||
>> +(rs5c->type == rtc_r2221tl && (ctrl2 & R2x2x_CTRL2_XSTP)))
>> {
>> +dev_warn(>dev, "rtc oscillator interruption
>> detected. Please reset the rtc clock.\n");
>> +return -EIO;
>
> -EINVAL is the correct error code here.
Ok
>
>> +}
>> +break;
>> +default:
>> +if (ctrl2 & RS5C_CTRL2_XSTP) {
>> +dev_warn(>dev, "rtc oscillator interruption
>> detected. Please reset the rtc clock.\n");
>> +return -EIO;
>
> and here.
OK
>
>
[PATCH v2] kernfs: Allocating memory for kernfs_iattrs with kmem_cache.
Creating a new cache for kernfs_iattrs.
Currently, memory is allocated with kzalloc() which
always gives aligned memory. On ARM, this is 64 byte aligned.
To avoid the wastage of memory in aligning the size requested,
a new cache for kernfs_iattrs is created.
Size of struct kernfs_iattrs is 80 Bytes.
On ARM, it will come in kmalloc-128 slab.
and it will come in kmalloc-192 slab if debug info is enabled.
Extra bytes taken 48 bytes.
Total number of objects created : 4096
Total saving = 48*4096 = 192 KB
After creating new slab(When debug info is enabled) :
sh-3.2# cat /proc/slabinfo
...
kernfs_iattrs_cache 4069 4096128 321 : tunables000 :
slabdata128128 0
...
All testing has been done on ARM target.
Signed-off-by: Ayush Mittal
Signed-off-by: Vaneet Narang
---
v1 -> v2: Changed slab creation flag.
fs/kernfs/dir.c | 2 +-
fs/kernfs/inode.c | 2 +-
fs/kernfs/kernfs-internal.h | 2 +-
fs/kernfs/mount.c | 7 ++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 4ca0b5c..b84d635 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -536,8 +536,8 @@ void kernfs_put(struct kernfs_node *kn)
security_release_secctx(kn->iattr->ia_secdata,
kn->iattr->ia_secdata_len);
simple_xattrs_free(>iattr->xattrs);
+ kmem_cache_free(kernfs_iattrs_cache, kn->iattr);
}
- kfree(kn->iattr);
spin_lock(_idr_lock);
idr_remove(>ino_idr, kn->id.ino);
spin_unlock(_idr_lock);
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index 80cebcd..0c1fd94 100644
--- a/fs/kernfs/inode.c
+++ b/fs/kernfs/inode.c
@@ -42,7 +42,7 @@ static struct kernfs_iattrs *kernfs_iattrs(struct kernfs_node
*kn)
if (kn->iattr)
goto out_unlock;
- kn->iattr = kzalloc(sizeof(struct kernfs_iattrs), GFP_KERNEL);
+ kn->iattr = kmem_cache_zalloc(kernfs_iattrs_cache, GFP_KERNEL);
if (!kn->iattr)
goto out_unlock;
iattrs = >iattr->ia_iattr;
diff --git a/fs/kernfs/kernfs-internal.h b/fs/kernfs/kernfs-internal.h
index 3d83b11..dba810c 100644
--- a/fs/kernfs/kernfs-internal.h
+++ b/fs/kernfs/kernfs-internal.h
@@ -78,7 +78,7 @@ static inline struct kernfs_node *kernfs_dentry_node(struct
dentry *dentry)
}
extern const struct super_operations kernfs_sops;
-extern struct kmem_cache *kernfs_node_cache;
+extern struct kmem_cache *kernfs_node_cache, *kernfs_iattrs_cache;
/*
* inode.c
diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index fdf527b..450eb38 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -20,7 +20,7 @@
#include "kernfs-internal.h"
-struct kmem_cache *kernfs_node_cache;
+struct kmem_cache *kernfs_node_cache, *kernfs_iattrs_cache;
static int kernfs_sop_remount_fs(struct super_block *sb, int *flags, char
*data)
{
@@ -417,4 +417,9 @@ void __init kernfs_init(void)
0,
SLAB_PANIC | SLAB_TYPESAFE_BY_RCU,
NULL);
+
+ /* Creates slab cache for kernfs inode attributes */
+ kernfs_iattrs_cache = kmem_cache_create("kernfs_iattrs_cache",
+ sizeof(struct kernfs_iattrs),
+ 0, SLAB_PANIC, NULL);
}
--
1.9.1
Re: linux-next: tracebacks in workqueue.c/__flush_work()
(Adding linux-arch ML.)
Rusty Russell wrote:
> Tetsuo Handa writes:
> > (Adding Chris Metcalf and Rusty Russell.)
> >
> > If NR_CPUS == 1 due to CONFIG_SMP=n, for_each_cpu(cpu, _work) loop does
> > not
> > evaluate "struct cpumask has_work" modified by cpumask_set_cpu(cpu,
> > _work) at
> > previous for_each_online_cpu() loop. Guenter Roeck found a problem among
> > three
> > commits listed below.
> >
> > Commit 5fbc461636c32efd ("mm: make lru_add_drain_all() selective")
> > expects that has_work is evaluated by for_each_cpu().
> >
> > Commit 2d3854a37e8b767a ("cpumask: introduce new API, without changing
> > anything")
> > assumes that for_each_cpu() does not need to evaluate has_work.
> >
> > Commit 4d43d395fed12463 ("workqueue: Try to catch flush_work() without
> > INIT_WORK().")
> > expects that has_work is evaluated by for_each_cpu().
> >
> > What should we do? Do we explicitly evaluate has_work if NR_CPUS == 1 ?
>
> No, fix the API to be least-surprise. Fix 2d3854a37e8b767a too.
>
> Doing anything else would be horrible, IMHO.
>
Fixing 2d3854a37e8b767a might involve subtle changes. If we do
--
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 147bdec..1ec5321 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -129,7 +129,7 @@ static inline unsigned int cpumask_check(unsigned int cpu)
return cpu;
}
-#if NR_CPUS == 1
+#if NR_CPUS == 1 && 0
/* Uniprocessor. Assume all masks are "1". */
static inline unsigned int cpumask_first(const struct cpumask *srcp)
{
diff --git a/lib/Makefile b/lib/Makefile
index e1b59da..da6f99c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -28,7 +28,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
lib-$(CONFIG_PRINTK) += dump_stack.o
lib-$(CONFIG_MMU) += ioremap.o
-lib-$(CONFIG_SMP) += cpumask.o
+lib-y += cpumask.o
lib-y += kobject.o klist.o
obj-y += lockref.o
--
then we get e.g. a build failure like below.
--
arch/x86/kernel/cpu/cacheinfo.o: In function `_populate_cache_leaves':
cacheinfo.c:(.text+0xb20): undefined reference to `cpu_llc_shared_map'
cacheinfo.c:(.text+0xb48): undefined reference to `cpu_llc_shared_map'
cacheinfo.c:(.text+0xb64): undefined reference to `cpu_llc_shared_map'
make: *** [vmlinux] Error 1
--
This build failure is caused due to the
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map);
line which cpu_llc_shared_mask() depends on is in arch/x86/kernel/smpboot.c
and the
obj-$(CONFIG_SMP) += smpboot.o
line is in arch/x86/kernel/Makefile . We could try
--
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index c4d1023..bf95da3 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -23,6 +23,10 @@
#include "cpu.h"
+#ifndef CONFIG_SMP
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map);
+#endif
+
#define LVL_1_INST 1
#define LVL_1_DATA 2
#define LVL_2 3
--
or
--
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index c4d1023..b8a22b6 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -886,6 +886,7 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int
index,
* to derive shared_cpu_map.
*/
if (index == 3) {
+#ifdef CONFIG_SMP
for_each_cpu(i, cpu_llc_shared_mask(cpu)) {
this_cpu_ci = get_cpu_cacheinfo(i);
if (!this_cpu_ci->info_list)
@@ -898,6 +899,7 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int
index,
_leaf->shared_cpu_map);
}
}
+#endif
} else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
unsigned int apicid, nshared, first, last;
--
but I don't know whether this is a correct fix, for for_each_cpu() currently
always executes the loop because for_each_cpu() does not evaluate
cpu_llc_shared_mask(cpu) argument. But if cpu_llc_shared_mask(cpu) argument
is evaluated by for_each_cpu(), and given that nobody updates cpu_llc_shared_map
if CONFIG_SMP=n, I guess that this for_each_cpu() becomes a no-op loop. I can't
evaluate whether this change is safe, and there might be similar code in other
architectures.
Re: [PATCH V4 9/9] x86/jump_label: Batch jump label updates
Hi Daniel,
On Mon, 4 Feb 2019 20:59:02 +0100
Daniel Bristot de Oliveira wrote:
> Currently, the jump label of a static key is transformed via the arch
> specific function:
>
> void arch_jump_label_transform(struct jump_entry *entry,
>enum jump_label_type type)
>
> The new approach (batch mode) uses two arch functions, the first has the
> same arguments of the arch_jump_label_transform(), and is the function:
>
> void arch_jump_label_transform_queue(struct jump_entry *entry,
>enum jump_label_type type)
This function actually returns "int" value.
Also, it seems the function returns 0 for failure and 1 for success,
but usually we guess "int" returns -errno or 0 for success.
So could you update the inferface to return -ENOSPC for vector
overflow, and -EINVAL for invalid entry?
Thank you,
>
> Rather than transforming the code, it adds the jump_entry in a queue of
> entries to be updated. This functions returns 1 in the case of a
> successful enqueue of an entry. If it returns 0, the caller must to
> apply the queue and then try to queue again, for instance, because the
> queue is full.
>
> This function expects the caller to sort the entries by the address before
> enqueueuing then. This is already done by the arch independent code, though.
>
> After queuing all jump_entries, the function:
>
> void arch_jump_label_transform_apply(void)
>
> Applies the changes in the queue.
>
> Signed-off-by: Daniel Bristot de Oliveira
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Greg Kroah-Hartman
> Cc: Masami Hiramatsu
> Cc: "Steven Rostedt (VMware)"
> Cc: Jiri Kosina
> Cc: Josh Poimboeuf
> Cc: "Peter Zijlstra (Intel)"
> Cc: Chris von Recklinghausen
> Cc: Jason Baron
> Cc: Scott Wood
> Cc: Marcelo Tosatti
> Cc: Clark Williams
> Cc: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/x86/include/asm/jump_label.h | 2 +
> arch/x86/kernel/jump_label.c | 88 +++
> 2 files changed, 90 insertions(+)
>
> diff --git a/arch/x86/include/asm/jump_label.h
> b/arch/x86/include/asm/jump_label.h
> index 65191ce8e1cf..06c3cc22a058 100644
> --- a/arch/x86/include/asm/jump_label.h
> +++ b/arch/x86/include/asm/jump_label.h
> @@ -2,6 +2,8 @@
> #ifndef _ASM_X86_JUMP_LABEL_H
> #define _ASM_X86_JUMP_LABEL_H
>
> +#define HAVE_JUMP_LABEL_BATCH
> +
> #define JUMP_LABEL_NOP_SIZE 5
>
> #ifdef CONFIG_X86_64
> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> index 2ef687db5a87..3c81cf8f06ca 100644
> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> union jump_code_union {
> char code[JUMP_LABEL_NOP_SIZE];
> @@ -130,6 +131,93 @@ void arch_jump_label_transform(struct jump_entry *entry,
> mutex_unlock(_mutex);
> }
>
> +struct text_to_poke *entry_vector;
> +unsigned int entry_vector_max_elem __read_mostly;
> +unsigned int entry_vector_nr_elem;
> +
> +void arch_jump_label_init(void)
> +{
> + entry_vector = (void *) __get_free_page(GFP_KERNEL);
> +
> + if (WARN_ON_ONCE(!entry_vector))
> + return;
> +
> + entry_vector_max_elem = PAGE_SIZE / sizeof(struct text_to_poke);
> + return;
> +}
> +
> +int arch_jump_label_transform_queue(struct jump_entry *entry,
> + enum jump_label_type type)
> +{
> + void *entry_code;
> + struct text_to_poke *tp;
> +
> + /*
> + * Batch mode disabled before being able to allocate memory:
> + * Fallback to the non-batching mode.
> + */
> + if (unlikely(!entry_vector_max_elem)) {
> + if (!slab_is_available() || early_boot_irqs_disabled)
> + goto fallback;
> +
> + arch_jump_label_init();
> + }
> +
> + /*
> + * No more space in the vector, tell upper layer to apply
> + * the queue before continuing.
> + */
> + if (entry_vector_nr_elem == entry_vector_max_elem)
> + return 0;
> +
> + tp = _vector[entry_vector_nr_elem];
> +
> + entry_code = (void *)jump_entry_code(entry);
> +
> + /*
> + * The int3 handler will do a bsearch in the queue, so we need entries
> + * to be sorted. We can survive an unsorted list by rejecting the entry,
> + * forcing the generic jump_label code to apply the queue. Warning once,
> + * to raise the attention to the case of an unsorted entry that is
> + * better not happen, because, in the worst case we will perform in the
> + * same way as we do without batching - with some more overhead.
> + */
> + if (entry_vector_nr_elem > 0) {
> + int prev_idx = entry_vector_nr_elem - 1;
> + struct text_to_poke *prev_tp = _vector[prev_idx];
> +
> + if (WARN_ON_ONCE(prev_tp->addr > entry_code))
> +
Re: [PATCH 5/5] arm: dts: axpxx: add charge led node
On 2/5/19 6:16 PM, Chen-Yu Tsai wrote:
On Thu, Jan 31, 2019 at 4:25 PM Stefan Mavrodiev wrote:
Add dt node for axp20x-led driver controlling CHGLED.
Default status is disabled, since it may be not used.
Signed-off-by: Stefan Mavrodiev
Please include a cover letter for such a patch series.
Sorry, I will.
Also, do any boards actually use this? I know the Pine64 does, but the
LED is left to the user to populate. I would really like to have an in
kernel user of this function, so that we can verify it.
All boards made by Olimex has this led populated. The development and the
testing of the driver was done on A64-OLinuXino board.
Should I make another patch, enabling the LED for the mention board?
Best regards,
Stefan Mavrodiev
ChenYu
---
arch/arm/boot/dts/axp209.dtsi | 5 +
arch/arm/boot/dts/axp22x.dtsi | 5 +
arch/arm/boot/dts/axp81x.dtsi | 5 +
3 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 0d9ff12bdf28..f972b6f3ecd0 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -69,6 +69,11 @@
#gpio-cells = <2>;
};
+ axp_led: led {
+ compatible = "x-powers,axp20x-led";
+ status = "disabled";
+ };
+
battery_power_supply: battery-power-supply {
compatible = "x-powers,axp209-battery-power-supply";
status = "disabled";
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 65a07a67aca9..92a0b64252b1 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -62,6 +62,11 @@
#io-channel-cells = <1>;
};
+ axp_led: led {
+ compatible = "x-powers,axp20x-led";
+ status = "disabled";
+ };
+
battery_power_supply: battery-power-supply {
compatible = "x-powers,axp221-battery-power-supply";
status = "disabled";
diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
index bd83962d3627..22e243cc40d5 100644
--- a/arch/arm/boot/dts/axp81x.dtsi
+++ b/arch/arm/boot/dts/axp81x.dtsi
@@ -74,6 +74,11 @@
};
};
+ axp_led: led {
+ compatible = "x-powers,axp20x-led";
+ status = "disabled";
+ };
+
battery_power_supply: battery-power-supply {
compatible = "x-powers,axp813-battery-power-supply";
status = "disabled";
--
2.17.1
linux-next: Tree for Feb 6
Hi all, Changes since 20190205: The mips tree gained conflicts against the mips-fixes tree. The opp tree gained a conflict against the pm tree. The drm-intel tree gained a conflict against the drm tree. The akpm-current tree gained a conflict against the powerpc-fixes tree. Non-merge commits (relative to Linus' tree): 5801 6493 files changed, 242140 insertions(+), 152493 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (8834f5600cf3 Linux 5.0-rc5) Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (6db2983cd806 kallsyms: Handle too long symbols in kallsyms.c) Merging arc-current/for-curr (3e45ea2a074f ARCv2: entry: exception prologue freeing up reg improvement) Merging arm-current/fixes (1b5ba3507842 ARM: 8824/1: fix a migrating irq bug when hotplug cpu) Merging arm64-fixes/for-next/fixes (f7daa9c8fd19 arm64: hibernate: Clean the __hyp_text to PoC after resume) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (5a3840a470c4 powerpc/papr_scm: Use the correct bind address) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (f09bef61f1ed Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (0429f237ce08 Merge branch 's390-qeth-fixes') Merging ipsec/master (09db51241118 esp: Skip TX bytes accounting when sending from a request socket) Merging netfilter/master (947e492c0fc2 netfilter: nft_compat: don't use refcount_inc on newly allocated entry) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (8c22d81d5535 MAINTAINERS: add entry for redpine wireless driver) Merging mac80211/master (9cb445c01642 mac80211: mesh: do mesh rhashtable walks with BHs disabled) Merging rdma-fixes/for-rc (48396e80fb65 RDMA/srp: Rework SCSI device reset handling) Merging sound-current/for-linus (3bff2407fbd2 ALSA: usb-audio: Add support for new T+A USB DAC) Merging sound-asoc-fixes/for-linus (72a52a2e9596 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (3a3a75eaefb1 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (2186097e00f9 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f14bcc0add3a Revert "PCI: armada8k: Add support for gpio controlled reset signal") Merging driver-core.current/driver-core-linus (36991ca68db9 blk-mq: protect debugfs_create_files() from failures) Merging tty.current/tty-linus (fedb5760648a serial: fix race between flush_to_ldisc and tty_open) Merging usb.current/usb-linus (a07ddce4df80 usb: typec: tcpm: Correct the PPS out_volt calculation) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (f17b5f06cb92 Linux 5.0-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (d6d768a0ec3c usb:
[PATCH] KVM: export and iif KVM is supported
I do not see any consistency about headers_install of
and .
According to my analysis of Linux 5.0-rc5, there are 3 groups:
[1] Both and are exported
alpha, arm, hexagon, mips, powerpc, s390, sparc, x86
[2] is exported, but is not
arc, arm64, c6x, h8300, ia64, m68k, microblaze, nios2, openrisc
[3] Neither nor is exported
csky, nds32, riscv
This does not match to the actual KVM support. At least, [2] is
half-baked.
Nor do arch maintainers look like they care about this. For example,
commit 0add53713b1c ("microblaze: Add missing kvm_para.h to Kbuild")
exported to user-space in order to fix an in-kernel
build error.
We have two ways to make this consistent:
[A] export both and for all
architectures, irrespective of the KVM support
[B] Match the header export of and
to the KVM support
My first attempt was [A] because the code looks better, but Paolo
showed preference in [B].
https://patchwork.kernel.org/patch/10794919/
So, this commit is the implementation of [B].
For most architectures, was moved to the kernel-space.
I changed include/uapi/linux/Kbuild so that it checks generated
asm/kvm_para.h as well as check-in ones.
After this commit, there will be two groups:
[1] Both and are exported
arm arm64 mips powerpc s390 x86
[2] Neither nor is exported
alpha arc c6x csky h8300 hexagon ia64 m68k microblaze nds32 nios2
openrisc parisc riscv sh sparc unicore32 xtensa
Signed-off-by: Masahiro Yamada
---
The alternative solution [A] is available at:
https://patchwork.kernel.org/patch/10794919/
Comparing the code diff, I personally prefer [A]...
arch/alpha/include/asm/Kbuild| 1 +
arch/alpha/include/uapi/asm/kvm_para.h | 2 --
arch/arc/include/asm/Kbuild | 1 +
arch/arc/include/uapi/asm/Kbuild | 1 -
arch/arm/include/uapi/asm/Kbuild | 1 +
arch/arm/include/uapi/asm/kvm_para.h | 2 --
arch/c6x/include/asm/Kbuild | 1 +
arch/c6x/include/uapi/asm/Kbuild | 1 -
arch/h8300/include/asm/Kbuild| 1 +
arch/h8300/include/uapi/asm/Kbuild | 1 -
arch/hexagon/include/asm/Kbuild | 1 +
arch/hexagon/include/uapi/asm/kvm_para.h | 2 --
arch/ia64/include/asm/Kbuild | 1 +
arch/ia64/include/uapi/asm/Kbuild| 1 -
arch/m68k/include/asm/Kbuild | 1 +
arch/m68k/include/uapi/asm/Kbuild| 1 -
arch/microblaze/include/asm/Kbuild | 1 +
arch/microblaze/include/uapi/asm/Kbuild | 1 -
arch/mips/include/uapi/asm/Kbuild| 1 +
arch/mips/include/uapi/asm/kvm_para.h| 5 -
arch/nios2/include/asm/Kbuild| 1 +
arch/nios2/include/uapi/asm/Kbuild | 1 -
arch/openrisc/include/asm/Kbuild | 1 +
arch/openrisc/include/uapi/asm/Kbuild| 1 -
arch/parisc/include/asm/Kbuild | 1 +
arch/parisc/include/uapi/asm/Kbuild | 1 -
arch/s390/include/uapi/asm/Kbuild| 1 +
arch/s390/include/uapi/asm/kvm_para.h| 8
arch/sh/include/asm/Kbuild | 1 +
arch/sh/include/uapi/asm/Kbuild | 1 -
arch/sparc/include/asm/Kbuild| 1 +
arch/sparc/include/uapi/asm/kvm_para.h | 2 --
arch/unicore32/include/asm/Kbuild| 1 +
arch/unicore32/include/uapi/asm/Kbuild | 1 -
arch/xtensa/include/asm/Kbuild | 1 +
arch/xtensa/include/uapi/asm/Kbuild | 1 -
include/uapi/linux/Kbuild| 2 ++
37 files changed, 20 insertions(+), 33 deletions(-)
delete mode 100644 arch/alpha/include/uapi/asm/kvm_para.h
delete mode 100644 arch/arm/include/uapi/asm/kvm_para.h
delete mode 100644 arch/hexagon/include/uapi/asm/kvm_para.h
delete mode 100644 arch/mips/include/uapi/asm/kvm_para.h
delete mode 100644 arch/s390/include/uapi/asm/kvm_para.h
delete mode 100644 arch/sparc/include/uapi/asm/kvm_para.h
diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index dc0ab28..70b7833 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch/alpha/include/asm/Kbuild
@@ -6,6 +6,7 @@ generic-y += exec.h
generic-y += export.h
generic-y += fb.h
generic-y += irq_work.h
+generic-y += kvm_para.h
generic-y += mcs_spinlock.h
generic-y += mm-arch-hooks.h
generic-y += preempt.h
diff --git a/arch/alpha/include/uapi/asm/kvm_para.h
b/arch/alpha/include/uapi/asm/kvm_para.h
deleted file mode 100644
index baacc49..000
--- a/arch/alpha/include/uapi/asm/kvm_para.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#include
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index caa2702..6e165e1 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -10,6 +10,7 @@ generic-y += hardirq.h
generic-y += hw_irq.h
generic-y += irq_regs.h
generic-y += irq_work.h
+generic-y += kvm_para.h
generic-y += local.h
generic-y += local64.h
generic-y += mcs_spinlock.h
diff --git a/arch/arc/include/uapi/asm/Kbuild b/arch/arc/include/uapi/asm/Kbuild
index
Re: [PATCH v2 2/2] media: docs-rst: Document memory-to-memory video encoder interface
On Thu, Jan 31, 2019 at 12:06 AM Nicolas Dufresne wrote: > > Le vendredi 25 janvier 2019 à 12:59 +0900, Tomasz Figa a écrit : > > On Fri, Jan 25, 2019 at 5:14 AM Nicolas Dufresne > > wrote: > > > Le mercredi 23 janvier 2019 à 14:04 +0100, Hans Verkuil a écrit : > > > > > > Does this return the same set of formats as in the 'Querying > > > > > > Capabilities' phase? > > > > > > > > > > > > > > > > It's actually an interesting question. At this point we wouldn't have > > > > > the OUTPUT resolution set yet, so that would be the same set as in the > > > > > initial query. If we set the resolution (with some arbitrary > > > > > pixelformat), it may become a subset... > > > > > > > > But doesn't setting the capture format also set the resolution? > > > > > > > > To quote from the text above: > > > > > > > > "The encoder will derive a new ``OUTPUT`` format from the ``CAPTURE`` > > > > format > > > > being set, including resolution, colorimetry parameters, etc." > > > > > > > > So you set the capture format with a resolution (you know that), then > > > > ENUM_FMT will return the subset for that codec and resolution. > > > > > > > > But see also the comment at the end of this email. > > > > > > I'm thinking that the fact that there is no "unset" value for pixel > > > format creates a certain ambiguity. Maybe we could create a new pixel > > > format, and all CODEC driver could have that set by default ? Then we > > > can just fail STREAMON if that format is set. > > > > The state on the CAPTURE queue is actually not "unset". The queue is > > simply not ready (yet) and any operations on it will error out. > > My point was that it's just awkward to have this "not ready" state, in > which you cannot go back. And in which the enum-format will ignore the > format configured on the other side. > > What I wanted to say is that this special case is not really needed. > Yeah, I think we may actually end up going in that direction, as you probably noticed in the discussion over the "venus: dec: make decoder compliant with stateful codec API" patch [1]. [1] https://patchwork.kernel.org/patch/10768539/#22462703 > > > > Once the application sets the coded resolution on the OUTPUT queue or > > the decoder parses the stream information, the CAPTURE queue becomes > > ready and one can do the ioctls on it. > > > > > That being said, in GStreamer, I have split each elements per CODEC, > > > and now only enumerate the information "per-codec". That makes me think > > > this "global" enumeration was just a miss-use of the API / me learning > > > to use it. Not having to implement this rather complex thing in the > > > driver would be nice. Notably, the new Amlogic driver does not have > > > this "Querying Capabilities" phase, and with latest GStreamer works > > > just fine. > > > > What do you mean by "doesn't have"? Does it lack an implementation of > > VIDIOC_ENUM_FMT and VIDIOC_ENUM_FRAMESIZES? > > What it does is that it sets a default value for the codec format, so > if you just open the device and do enum_fmt/framesizes, you get that is > possible for the default codec that was selected. And I thin it's > entirely correct, doing ENUM_FMT(capture) without doing an > S_FMT(output) can easily be documented as undefined behaviour. Okay. > > For proper enumeration would be: > > for formats on OUTPUT device: > S_FMT(OUTPUT): > for formats on CAPTURE device: > ... > > (the pseudo for look represent an enum operation) And that's how it's defined in v3. There is no default state without any codec selected. Best regards, Tomasz
Re: [PATCH v2 1/2] media: docs-rst: Document memory-to-memory video decoder interface
On Wed, Jan 30, 2019 at 1:02 PM Nicolas Dufresne wrote: > > Le vendredi 25 janvier 2019 à 12:27 +0900, Tomasz Figa a écrit : > > On Fri, Jan 25, 2019 at 4:55 AM Nicolas Dufresne > > wrote: > > > Le jeudi 24 janvier 2019 à 18:06 +0900, Tomasz Figa a écrit : > > > > > Actually I just realized the last point might not even be achievable > > > > > for some of the decoders (s5p-mfc, mtk-vcodec), as they don't report > > > > > which frame originates from which bitstream buffer and the driver just > > > > > picks the most recently consumed OUTPUT buffer to copy the timestamp > > > > > from. (s5p-mfc actually "forgets" to set the timestamp in some cases > > > > > too...) > > > > > > > > > > I need to think a bit more about this. > > > > > > > > Actually I misread the code. Both s5p-mfc and mtk-vcodec seem to > > > > correctly match the buffers. > > > > > > Ok good, since otherwise it would have been a regression in MFC driver. > > > This timestamp passing thing could in theory be made optional though, > > > it lives under some COPY_TIMESTAMP kind of flag. What that means though > > > is that a driver without such a capability would need to signal dropped > > > frames using some other mean. > > > > > > In userspace, the main use is to match the produced frame against a > > > userspace specific list of frames. At least this seems to be the case > > > in Gst and Chromium, since the userspace list contains a superset of > > > the metadata found in the v4l2_buffer. > > > > > > Now, using the produced timestamp, userspace can deduce frame that the > > > driver should have produced but didn't (could be a deadline case codec, > > > or simply the frames where corrupted). It's quite normal for a codec to > > > just keep parsing until it finally find something it can decode. > > > > > > That's at least one way to do it, but there is other possible > > > mechanism. The sequence number could be used, or even producing buffers > > > with the ERROR flag set. What matters is just to give userspace a way > > > to clear these frames, which would simply grow userspace memory usage > > > over time. > > > > Is it just me or we were missing some consistent error handling then? > > > > I feel like the drivers should definitely return the bitstream buffers > > with the ERROR flag, if there is a decode failure of data in the > > buffer. Still, that could become more complicated if there is more > > than 1 frame in that piece of bitstream, but only 1 frame is corrupted > > (or whatever). > > I agree, but it might be more difficult then it looks (even FFMPEG does > not do that). I believe the code that is processing the bitstream in > stateful codecs is mostly unrelated from the code actually doing the > decoding. So what might happen is that the decoding part will never > actually allocate a buffer for the skipped / corrupted part of the > bitstream. Also, the notion of a skipped frame is not always evident in > when parsing H264 or HEVC NALs. There is still a full page of text just > to explain how to detect that start of a new frame. Right. I don't think we can guarantee that we can always correlate the errors with exact buffers and so I phrased the paragraph about errors in v3 in a bit more conservative way: See the snapshot hosted by Hans (thanks!): https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-decoder.html#decoding > > Yet, it would be interesting to study the firmwares we have and see > what they provide that would help making decode errors more explicit. > Agreed. > > > > Another case is when the bitstream, even if corrupted, is still enough > > to produce some output. My intuition tells me that such CAPTURE buffer > > should be then returned with the ERROR flag. That wouldn't still be > > enough for any more sophisticated userspace error concealment, but > > could still let the userspace know to perhaps drop the frame. > > You mean if a frame was concealed (typically the frame was decoded from > a closed by reference instead of the expected reference). That is > something signalled by FFPEG. We should document this possibility. I > actually have something implemented in GStreamer. Basically if we have > the ERROR flag with a payload size smaller then expected, I drop the > frame and produce a drop event message, while if I have a frame with > ERROR flag but of the right payload size, I assume it is corrupted, and > simply flag it as corrupted, leaving to the application the decision to > display it or not. This is a case that used to happen with some UVC > cameras (though some have been fixed, and the UVC camera should drop > smaller payload size buffers now). I think it's a behavior that makes the most sense indeed. Technically one could also consider the case of 0 < bytesused < sizeimage, which could mean that only a part of the frame is in the buffer. An application could try to blend it with previous frame using some concealing algorithms. I haven't seen an app that could do such thing, though. Best
linux-next: manual merge of the akpm-current tree with the powerpc-fixes tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/mm/pgtable-book3s64.c
between commit:
579b9239c1f3 ("powerpc/radix: Fix kernel crash with mremap()")
from the powerpc-fixes tree and commit:
41bde21e85a7 ("arch/powerpc/mm: Nest MMU workaround for mprotect RW upgrade")
from the akpm-current 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.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/mm/pgtable-book3s64.c
index ecd31569a120,9f154efed1ae..c11c60056669
--- a/arch/powerpc/mm/pgtable-book3s64.c
+++ b/arch/powerpc/mm/pgtable-book3s64.c
@@@ -401,24 -398,27 +398,49 @@@ void arch_report_meminfo(struct seq_fil
}
#endif /* CONFIG_PROC_FS */
+/*
+ * For hash translation mode, we use the deposited table to store hash slot
+ * information and they are stored at PTRS_PER_PMD offset from related pmd
+ * location. Hence a pmd move requires deposit and withdraw.
+ *
+ * For radix translation with split pmd ptl, we store the deposited table in
the
+ * pmd page. Hence if we have different pmd page we need to withdraw during
pmd
+ * move.
+ *
+ * With hash we use deposited table always irrespective of anon or not.
+ * With radix we use deposited table only for anonymous mapping.
+ */
+int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+ struct spinlock *old_pmd_ptl,
+ struct vm_area_struct *vma)
+{
+ if (radix_enabled())
+ return (new_pmd_ptl != old_pmd_ptl) && vma_is_anonymous(vma);
+
+ return true;
+}
++
+ pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
+pte_t *ptep)
+ {
+ unsigned long pte_val;
+
+ /*
+* Clear the _PAGE_PRESENT so that no hardware parallel update is
+* possible. Also keep the pte_present true so that we don't take
+* wrong fault.
+*/
+ pte_val = pte_update(vma->vm_mm, addr, ptep, _PAGE_PRESENT,
_PAGE_INVALID, 0);
+
+ return __pte(pte_val);
+
+ }
+
+ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
+pte_t *ptep, pte_t old_pte, pte_t pte)
+ {
+ if (radix_enabled())
+ return radix__ptep_modify_prot_commit(vma, addr,
+ ptep, old_pte, pte);
+ set_pte_at(vma->vm_mm, addr, ptep, pte);
+ }
pgp9FdgnZvBgs.pgp
Description: OpenPGP digital signature
[PATCH 1/6] vmw_balloon: bump version number
Following recent changes.
Signed-off-by: Nadav Amit
---
drivers/misc/vmw_balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index f8240b87df22..7294f305753f 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -34,7 +34,7 @@
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
-MODULE_VERSION("1.5.0.0-k");
+MODULE_VERSION("1.6.0.0-k");
MODULE_ALIAS("dmi:*:svnVMware*:*");
MODULE_ALIAS("vmware_vmmemctl");
MODULE_LICENSE("GPL");
--
2.17.1
[PATCH v6 5/8] soc: qcom: Add AOSS QMP communication driver
The AOSS QMP driver is used to communicate with the AOSS for certain
side-channel requests, that are not enabled through the RPMh interface.
The communication is a very simple synchronous mechanism of messages
being written in message RAM and a doorbell in the AOSS is rung. As the
AOSS has processed the message length is cleared and an interrupt is
fired by the AOSS as acknowledgment.
Reviewed-by: Arun Kumar Neelakantam
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- Remove wait for event when checking magic
- Kick after signaling channel up
- Fail probe if registration of child device fails
- Fix ordering in remove
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/aoss-qmp.c | 326 ++
include/linux/soc/qcom/aoss-qmp.h | 14 ++
4 files changed, 350 insertions(+)
create mode 100644 drivers/soc/qcom/aoss-qmp.c
create mode 100644 include/linux/soc/qcom/aoss-qmp.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 1ee298f6bf17..28ab19bf8c98 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,15 @@
#
menu "Qualcomm SoC drivers"
+config QCOM_AOSS_QMP
+ tristate "Qualcomm AOSS Messaging Driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on MAILBOX
+ help
+ This driver provides the means for communicating with the
+ micro-controller in the AOSS, using QMP, to control certain resource
+ that are not exposed through RPMh.
+
config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..2c04d27fbf9e 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
CFLAGS_rpmh-rsc.o := -I$(src)
+obj-$(CONFIG_QCOM_AOSS_QMP) += aoss-qmp.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
diff --git a/drivers/soc/qcom/aoss-qmp.c b/drivers/soc/qcom/aoss-qmp.c
new file mode 100644
index ..cc8bda975756
--- /dev/null
+++ b/drivers/soc/qcom/aoss-qmp.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define QMP_DESC_MAGIC 0x0
+#define QMP_DESC_VERSION 0x4
+#define QMP_DESC_FEATURES 0x8
+
+/* AOP-side offsets */
+#define QMP_DESC_UCORE_LINK_STATE 0xc
+#define QMP_DESC_UCORE_LINK_STATE_ACK 0x10
+#define QMP_DESC_UCORE_CH_STATE0x14
+#define QMP_DESC_UCORE_CH_STATE_ACK0x18
+#define QMP_DESC_UCORE_MBOX_SIZE 0x1c
+#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
+
+/* Linux-side offsets */
+#define QMP_DESC_MCORE_LINK_STATE 0x24
+#define QMP_DESC_MCORE_LINK_STATE_ACK 0x28
+#define QMP_DESC_MCORE_CH_STATE0x2c
+#define QMP_DESC_MCORE_CH_STATE_ACK0x30
+#define QMP_DESC_MCORE_MBOX_SIZE 0x34
+#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
+
+#define QMP_STATE_UP 0x
+#define QMP_STATE_DOWN 0x
+
+#define QMP_MAGIC 0x4d41494c
+#define QMP_VERSION1
+
+/**
+ * struct qmp - driver state for QMP implementation
+ * @msgram: iomem referencing the message RAM used for communication
+ * @dev: reference to QMP device
+ * @mbox_client: mailbox client used to ring the doorbell on transmit
+ * @mbox_chan: mailbox channel used to ring the doorbell on transmit
+ * @offset: offset within @msgram where messages should be written
+ * @size: maximum size of the messages to be transmitted
+ * @event: wait_queue for synchronization with the IRQ
+ * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
+ * @pd_pdev: platform device for the power-domain child device
+ */
+struct qmp {
+ void __iomem *msgram;
+ struct device *dev;
+
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ size_t offset;
+ size_t size;
+
+ wait_queue_head_t event;
+
+ struct mutex tx_lock;
+
+ struct platform_device *pd_pdev;
+};
+
+static void qmp_kick(struct qmp *qmp)
+{
+ mbox_send_message(qmp->mbox_chan, NULL);
+ mbox_client_txdone(qmp->mbox_chan, 0);
+}
+
+static bool qmp_magic_valid(struct qmp *qmp)
+{
+ return readl(qmp->msgram + QMP_DESC_MAGIC) == QMP_MAGIC;
+}
+
+static bool qmp_link_acked(struct qmp *qmp)
+{
+ return readl(qmp->msgram + QMP_DESC_MCORE_LINK_STATE_ACK) ==
QMP_STATE_UP;
+}
+
+static bool qmp_mcore_channel_acked(struct qmp *qmp)
+{
+ return readl(qmp->msgram + QMP_DESC_MCORE_CH_STATE_ACK) == QMP_STATE_UP;
+}
+
+static bool qmp_ucore_channel_up(struct qmp *qmp)
+{
+ return readl(qmp->msgram + QMP_DESC_UCORE_CH_STATE) == QMP_STATE_UP;
+}
+
+static int qmp_open(struct qmp *qmp)
+{
+ int ret;
+
[PATCH 0/6] vmw_balloon: 64-bit limit support, compaction, shrinker
Various enhancements for VMware balloon, some of which are remainder from a previous patch-set. Patch 1: Aumps the version number, following recent changes Patch 2: Adds support for 64-bit memory limit Patches 3-4: Support for compaction Patch 5: Support for memory shrinker - disabled by default Patch 6: Split refused pages to improve performance Since the 3rd patch requires Michael Tsirkin ack, which has not arrived in the last couple of times the patch was sent, please consider applying patches 1-2 for 5.1. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: linux...@kvack.org Cc: virtualizat...@lists.linux-foundation.org Nadav Amit (5): vmw_balloon: bump version number mm/balloon_compaction: list interfaces vmw_balloon: compaction support vmw_balloon: add memory shrinker vmw_balloon: split refused pages Xavier Deguillard (1): vmw_balloon: support 64-bit memory limit drivers/misc/Kconfig | 1 + drivers/misc/vmw_balloon.c | 511 ++--- include/linux/balloon_compaction.h | 4 + mm/balloon_compaction.c| 139 +--- 4 files changed, 566 insertions(+), 89 deletions(-) -- 2.17.1
[PATCH v6 7/8] arm64: dts: qcom: Add AOSS QMP node
The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.
Tested-by: Sibi Sankar
Reviewed-by: Sibi Sankar
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- None
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 12efbdb1fa2e..560c16616ee6 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2080,6 +2081,15 @@
#reset-cells = <1>;
};
+ aoss_qmp: qmp@c30 {
+ compatible = "qcom,sdm845-aoss-qmp";
+ reg = <0 0x0c30 0 0x10>;
+ interrupts = ;
+ mboxes = <_shared 0>;
+
+ #power-domain-cells = <1>;
+ };
+
spmi_bus: spmi@c44 {
compatible = "qcom,spmi-pmic-arb";
reg = <0 0x0c44 0 0x1100>,
--
2.18.0
[PATCH v6 3/8] arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes
Add the Audio DSP (ADSP) and Compute DSP (CDSP) nodes for TrustZone
based remoteproc, supporting booting these cores on e.g. the MTP, and
enable the same for the MTP.
Tested-by: Sibi Sankar
Reviewed-by: Sibi Sankar
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- None
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 8
arch/arm64/boot/dts/qcom/sdm845.dtsi| 58 +
2 files changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 89071463a84a..2e78638eb73b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -48,6 +48,10 @@
};
};
+_pas {
+ status = "okay";
+};
+
_rsc {
pm8998-rpmh-regulators {
compatible = "qcom,pm8998-rpmh-regulators";
@@ -344,6 +348,10 @@
};
};
+_pas {
+ status = "okay";
+};
+
{
protected-clocks = ,
,
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index a33d27b3a389..12efbdb1fa2e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -324,6 +324,64 @@
};
};
+ adsp_pas: remoteproc-adsp {
+ compatible = "qcom,sdm845-adsp-pas";
+
+ interrupts-extended = < GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = < RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ memory-region = <_mem>;
+
+ qcom,smem-states = <_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts = ;
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ mboxes = <_shared 8>;
+ };
+ };
+
+ cdsp_pas: remoteproc-cdsp {
+ compatible = "qcom,sdm845-cdsp-pas";
+
+ interrupts-extended = < GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = < RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ memory-region = <_mem>;
+
+ qcom,smem-states = <_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts = ;
+ label = "turing";
+ qcom,remote-pid = <5>;
+ mboxes = <_shared 4>;
+ };
+ };
+
tcsr_mutex: hwlock {
compatible = "qcom,tcsr-mutex";
syscon = <_mutex_regs 0 0x1000>;
--
2.18.0
[PATCH v6 00/8] Qualcomm AOSS QMP driver and modem dts
Update the reserved memory map for SDM845, add the ADSP and CDSP nodes, introduce a communication driver for the AOSS and a PD driver for this and finally add the modem remoteproc driver. Bjorn Andersson (7): arm64: dts: qcom: sdm845: Update reserved memory map arm64: dts: qcom: sdm845: Define rmtfs memory arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes dt-bindings: soc: qcom: Add AOSS QMP binding soc: qcom: Add AOSS QMP communication driver soc: qcom: Add AOSS QMP genpd provider arm64: dts: qcom: Add AOSS QMP node Sibi Sankar (1): arm64: dts: qcom: sdm845: Add Q6V5 MSS node .../bindings/soc/qcom/qcom,aoss-qmp.txt | 76 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 8 + arch/arm64/boot/dts/qcom/sdm845.dtsi | 209 ++- drivers/soc/qcom/Kconfig | 18 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/aoss-qmp-pd.c| 158 + drivers/soc/qcom/aoss-qmp.c | 326 ++ include/dt-bindings/power/qcom-aoss-qmp.h | 15 + include/linux/soc/qcom/aoss-qmp.h | 14 + 9 files changed, 819 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c create mode 100644 drivers/soc/qcom/aoss-qmp.c create mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h create mode 100644 include/linux/soc/qcom/aoss-qmp.h -- 2.18.0
[PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
From: Sibi Sankar
This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
Signed-off-by: Sibi Sankar
Reviewed-by: Douglas Anderson
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- None
arch/arm64/boot/dts/qcom/sdm845.dtsi | 58
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 560c16616ee6..5c41f6fe3e1b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1612,6 +1612,64 @@
};
};
+ mss_pil: remoteproc@408 {
+ compatible = "qcom,sdm845-mss-pil";
+ reg = <0 0x0408 0 0x408>, <0 0x0418 0 0x48>;
+ reg-names = "qdsp6", "rmb";
+
+ interrupts-extended =
+ < GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack",
+ "shutdown-ack";
+
+ clocks = < GCC_MSS_CFG_AHB_CLK>,
+< GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+< GCC_BOOT_ROM_AHB_CLK>,
+< GCC_MSS_GPLL0_DIV_CLK_SRC>,
+< GCC_MSS_SNOC_AXI_CLK>,
+< GCC_MSS_MFAB_AXIS_CLK>,
+< GCC_PRNG_AHB_CLK>,
+< RPMH_CXO_CLK>;
+ clock-names = "iface", "bus", "mem", "gpll0_mss",
+ "snoc_axi", "mnoc_axi", "prng", "xo";
+
+ qcom,smem-states = <_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ resets = <_reset AOSS_CC_MSS_RESTART>,
+<_reset PDC_MODEM_SYNC_RESET>;
+ reset-names = "mss_restart", "pdc_reset";
+
+ qcom,halt-regs = <_mutex_regs 0x23000 0x25000
0x24000>;
+
+ power-domains = <_qmp AOSS_QMP_LS_MODEM>,
+ < SDM845_CX>,
+ < SDM845_MX>,
+ < SDM845_MSS>;
+ power-domain-names = "load_state", "cx", "mx", "mss";
+
+ mba {
+ memory-region = <_region>;
+ };
+
+ mpss {
+ memory-region = <_region>;
+ };
+
+ glink-edge {
+ interrupts = ;
+ label = "modem";
+ qcom,remote-pid = <1>;
+ mboxes = <_shared 12>;
+ };
+ };
+
gpucc: clock-controller@509 {
compatible = "qcom,sdm845-gpucc";
reg = <0 0x0509 0 0x9000>;
--
2.18.0
[PATCH v6 2/8] arm64: dts: qcom: sdm845: Define rmtfs memory
Define the rmtfs memory node. As the memory region specified in version
10 of the memory map is only 1MB a chunk of unallocated memory is
chosen.
Tested-by: Sibi Sankar
Reviewed-by: Sibi Sankar
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- Corrected unit address
arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 16a060063882..a33d27b3a389 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -103,6 +103,15 @@
no-map;
};
+ rmtfs_mem: memory@88f0 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0 0x88f0 0 0x20>;
+ no-map;
+
+ qcom,client-id = <1>;
+ qcom,vmid = <15>;
+ };
+
qseecom_mem: memory@8ab0 {
reg = <0 0x8ab0 0 0x140>;
no-map;
--
2.18.0
[PATCH v6 4/8] dt-bindings: soc: qcom: Add AOSS QMP binding
Add binding for the QMP based side-channel communication mechanism to
the AOSS, which is used to control resources not exposed through the
RPMh interface.
Reviewed-by: Rob Herring
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- None
.../bindings/soc/qcom/qcom,aoss-qmp.txt | 76 +++
include/dt-bindings/power/qcom-aoss-qmp.h | 15
2 files changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
create mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
new file mode 100644
index ..9ce6c42192ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
@@ -0,0 +1,76 @@
+Qualcomm Always-On Subsystem side channel binding
+
+This binding describes the hardware component responsible for side channel
+requests to the always-on subsystem (AOSS), used for certain power management
+requests that is not handled by the standard RPMh interface. Each client in the
+SoC has it's own block of message RAM and IRQ for communication with the AOSS.
+The protocol used to communicate in the message RAM is known as Qualcomm
+Messagin Protocol (QMP)
+
+The AOSS side channel exposes control over a set of resources, used to control
+a set of debug related clocks and to affect the low power state of resources
+related to the secondary subsystems. These resources are exposed as a set of
+power-domains.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,sdm845-aoss-qmp"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: the base address and size of the message RAM for this
+ client's communication with the AOSS
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: should specify the AOSS message IRQ for this client
+
+- mboxes:
+ Usage: required
+ Value type:
+ Definition: reference to the mailbox representing the outgoing doorbell
+ in APCS for this client, as described in mailbox/mailbox.txt
+
+- #power-domain-cells:
+ Usage: optional
+ Value type:
+ Definition: must be 1
+ The provided power-domains are:
+ QDSS clock-domain (0), CDSP state (1), LPASS state (2),
+ modem state (3), SLPI state (4), SPSS state (5) and Venus
+ state (6).
+
+= SUBNODES
+The AOSS side channel also provides the controls for three cooling devices,
+these are expressed as subnodes of the QMP node. The name of the node is used
+to identify the resource and must therefor be "cx", "mx" or "ebi".
+
+- #cooling-cells:
+ Usage: optional
+ Value type:
+ Definition: must be 2
+
+= EXAMPLE
+
+The following example represents the AOSS side-channel message RAM and the
+mechanism exposing the power-domains, as found in SDM845.
+
+ aoss_qmp: qmp@c30 {
+ compatible = "qcom,sdm845-aoss-qmp";
+ reg = <0x0c30 0x10>;
+ interrupts = ;
+ mboxes = <_shared 0>;
+
+ #power-domain-cells = <1>;
+
+ cx_cdev: cx {
+ #cooling-cells = <2>;
+ };
+
+ mx_cdev: mx {
+ #cooling-cells = <2>;
+ };
+ };
diff --git a/include/dt-bindings/power/qcom-aoss-qmp.h
b/include/dt-bindings/power/qcom-aoss-qmp.h
new file mode 100644
index ..7d8ac1a4f90c
--- /dev/null
+++ b/include/dt-bindings/power/qcom-aoss-qmp.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Linaro Ltd. */
+
+#ifndef __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H
+#define __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H
+
+#define AOSS_QMP_QDSS_CLK 0
+#define AOSS_QMP_LS_CDSP 1
+#define AOSS_QMP_LS_LPASS 2
+#define AOSS_QMP_LS_MODEM 3
+#define AOSS_QMP_LS_SLPI 4
+#define AOSS_QMP_LS_SPSS 5
+#define AOSS_QMP_LS_VENUS 6
+
+#endif
--
2.18.0
[PATCH v6 1/8] arm64: dts: qcom: sdm845: Update reserved memory map
Update existing and add missing regions to the reserved memory map, as
described in version 10.
Reviewed-by: Sibi Sankar
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- Replaced a few 0x0 with 0
- Corrected size of tz_mem
arch/arm64/boot/dts/qcom/sdm845.dtsi | 74 +---
1 file changed, 67 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index ade2f385507c..16a060063882 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -72,29 +72,69 @@
#size-cells = <2>;
ranges;
- memory@85fc {
+ hyp_mem: memory@8570 {
+ reg = <0 0x8570 0 0x60>;
+ no-map;
+ };
+
+ xbl_mem: memory@85e0 {
+ reg = <0 0x85e0 0 0x10>;
+ no-map;
+ };
+
+ aop_mem: memory@85fc {
reg = <0 0x85fc 0 0x2>;
no-map;
};
- memory@85fe {
+ aop_cmd_db_mem: memory@85fe {
compatible = "qcom,cmd-db";
- reg = <0x0 0x85fe 0x0 0x2>;
+ reg = <0x0 0x85fe 0 0x2>;
no-map;
};
smem_mem: memory@8600 {
- reg = <0x0 0x8600 0x0 0x20>;
+ reg = <0x0 0x8600 0 0x20>;
no-map;
};
- memory@8620 {
+ tz_mem: memory@8620 {
reg = <0 0x8620 0 0x2d0>;
no-map;
};
- wlan_msa_mem: memory@9670 {
- reg = <0 0x9670 0 0x10>;
+ qseecom_mem: memory@8ab0 {
+ reg = <0 0x8ab0 0 0x140>;
+ no-map;
+ };
+
+ camera_mem: memory@8bf0 {
+ reg = <0 0x8bf0 0 0x50>;
+ no-map;
+ };
+
+ ipa_fw_mem: memory@8c40 {
+ reg = <0 0x8c40 0 0x1>;
+ no-map;
+ };
+
+ ipa_gsi_mem: memory@8c41 {
+ reg = <0 0x8c41 0 0x5000>;
+ no-map;
+ };
+
+ gpu_mem: memory@8c415000 {
+ reg = <0 0x8c415000 0 0x2000>;
+ no-map;
+ };
+
+ adsp_mem: memory@8c50 {
+ reg = <0 0x8c50 0 0x1a0>;
+ no-map;
+ };
+
+ wlan_msa_mem: memory@8df0 {
+ reg = <0 0x8df0 0 0x10>;
no-map;
};
@@ -103,10 +143,30 @@
no-map;
};
+ venus_mem: memory@9580 {
+ reg = <0 0x9580 0 0x50>;
+ no-map;
+ };
+
+ cdsp_mem: memory@95d0 {
+ reg = <0 0x95d0 0 0x80>;
+ no-map;
+ };
+
mba_region: memory@9650 {
reg = <0 0x9650 0 0x20>;
no-map;
};
+
+ slpi_mem: memory@9670 {
+ reg = <0 0x9670 0 0x140>;
+ no-map;
+ };
+
+ spss_mem: memory@97b0 {
+ reg = <0 0x97b0 0 0x10>;
+ no-map;
+ };
};
cpus {
--
2.18.0
[PATCH v6 6/8] soc: qcom: Add AOSS QMP genpd provider
The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.
Tested-by: Sibi Sankar
Tested-by: Sai Prakash Ranjan
Reviewed-by: Sibi Sankar
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- Clear outgoing buffer, to avoid sending unitialized stack content to AOP
- Fix domain initialization
- Clean up domains on failure and remove
drivers/soc/qcom/Kconfig | 9 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/aoss-qmp-pd.c | 158 +
3 files changed, 168 insertions(+)
create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 28ab19bf8c98..893b56b70957 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -12,6 +12,15 @@ config QCOM_AOSS_QMP
micro-controller in the AOSS, using QMP, to control certain resource
that are not exposed through RPMh.
+config QCOM_AOSS_QMP_PD
+ tristate "Qualcomm AOSS Messaging Power Domain driver"
+ depends on QCOM_AOSS_QMP
+ select PM_GENERIC_DOMAINS
+ help
+ This driver provides the means of controlling the AOSS's handling of
+ low-power state for resources related to the remoteproc subsystems as
+ well as controlling the debug clocks.
+
config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 2c04d27fbf9e..16913e73fddf 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
CFLAGS_rpmh-rsc.o := -I$(src)
obj-$(CONFIG_QCOM_AOSS_QMP) += aoss-qmp.o
+obj-$(CONFIG_QCOM_AOSS_QMP_PD) += aoss-qmp-pd.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
diff --git a/drivers/soc/qcom/aoss-qmp-pd.c b/drivers/soc/qcom/aoss-qmp-pd.c
new file mode 100644
index ..a375abcbe9c7
--- /dev/null
+++ b/drivers/soc/qcom/aoss-qmp-pd.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+
+/* Requests are expected to be 96 bytes long */
+#define AOSS_QMP_PD_MSG_LEN96
+
+struct qmp_pd {
+ struct qmp *qmp;
+ struct generic_pm_domain pd;
+};
+
+#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
+
+struct qmp_pd_resource {
+ const char *name;
+ int (*on)(struct generic_pm_domain *domain);
+ int (*off)(struct generic_pm_domain *domain);
+};
+
+static int qmp_pd_clock_toggle(struct qmp_pd *res, bool enable)
+{
+ char buf[AOSS_QMP_PD_MSG_LEN];
+
+ memset(buf, 0, sizeof(buf));
+ snprintf(buf, sizeof(buf), "{class: clock, res: %s, val: %d}",
+res->pd.name, enable);
+ return qmp_send(res->qmp, buf, sizeof(buf));
+}
+
+static int qmp_pd_clock_on(struct generic_pm_domain *domain)
+{
+ return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), true);
+}
+
+static int qmp_pd_clock_off(struct generic_pm_domain *domain)
+{
+ return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), false);
+}
+
+static int qmp_pd_image_toggle(struct qmp_pd *res, bool enable)
+{
+ char buf[AOSS_QMP_PD_MSG_LEN];
+
+ memset(buf, 0, sizeof(buf));
+ snprintf(buf, sizeof(buf),
+"{class: image, res: load_state, name: %s, val: %s}",
+res->pd.name, enable ? "on" : "off");
+ return qmp_send(res->qmp, buf, sizeof(buf));
+}
+
+static int qmp_pd_image_on(struct generic_pm_domain *domain)
+{
+ return qmp_pd_image_toggle(to_qmp_pd_resource(domain), true);
+}
+
+static int qmp_pd_image_off(struct generic_pm_domain *domain)
+{
+ return qmp_pd_image_toggle(to_qmp_pd_resource(domain), false);
+}
+
+static const struct qmp_pd_resource sdm845_resources[] = {
+ [AOSS_QMP_QDSS_CLK] = { "qdss", qmp_pd_clock_on, qmp_pd_clock_off },
+ [AOSS_QMP_LS_CDSP] = { "cdsp", qmp_pd_image_on, qmp_pd_image_off },
+ [AOSS_QMP_LS_LPASS] = { "adsp", qmp_pd_image_on, qmp_pd_image_off },
+ [AOSS_QMP_LS_MODEM] = { "modem", qmp_pd_image_on, qmp_pd_image_off },
+ [AOSS_QMP_LS_SLPI] = { "slpi", qmp_pd_image_on, qmp_pd_image_off },
+ [AOSS_QMP_LS_SPSS] = { "spss", qmp_pd_image_on, qmp_pd_image_off },
+ [AOSS_QMP_LS_VENUS] = { "venus", qmp_pd_image_on, qmp_pd_image_off },
+};
+
+static int qmp_pd_probe(struct platform_device *pdev)
+{
+ struct genpd_onecell_data *data;
+ struct device *parent = pdev->dev.parent;
+ struct qmp_pd *res;
+ struct qmp *qmp;
+ size_t num = ARRAY_SIZE(sdm845_resources);
+ int ret;
+ int i;
+
+ qmp = dev_get_drvdata(pdev->dev.parent);
+ if
KASAN: slab-out-of-bounds Read in ip_send_unicast_reply
Hello, syzbot found the following crash on: HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=11a6994b40 kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76 dashboard link: https://syzkaller.appspot.com/bug?extid=f1741fbf71635c029556 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f1741fbf71635c029...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in sock_net include/net/sock.h:2403 [inline] BUG: KASAN: slab-out-of-bounds in ip_send_unicast_reply+0x14a6/0x1800 net/ipv4/ip_output.c:1569 Read of size 8 at addr 888097d4c5ac by task syz-executor4/19801 CPU: 0 PID: 19801 Comm: syz-executor4 Not tainted 4.20.0+ #3 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report mm/kasan/report.c:412 [inline] kasan_report.cold+0x8c/0x2ba mm/kasan/report.c:396 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 sock_net include/net/sock.h:2403 [inline] ip_send_unicast_reply+0x14a6/0x1800 net/ipv4/ip_output.c:1569 tcp_v4_send_reset+0x1496/0x2ad0 net/ipv4/tcp_ipv4.c:775 tcp_v4_rcv+0x1e17/0x3c40 net/ipv4/tcp_ipv4.c:1936 ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208 ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234 NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_local_deliver+0x1f0/0x740 net/ipv4/ip_input.c:255 dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1f4/0x2f0 net/ipv4/ip_input.c:414 NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_rcv+0xed/0x620 net/ipv4/ip_input.c:523 __netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973 __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083 process_backlog+0x206/0x750 net/core/dev.c:5923 napi_poll net/core/dev.c:6346 [inline] net_rx_action+0x76d/0x1930 net/core/dev.c:6412 __do_softirq+0x30b/0xb11 kernel/softirq.c:292 do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027 do_softirq.part.0+0x11a/0x170 kernel/softirq.c:337 do_softirq kernel/softirq.c:329 [inline] __local_bh_enable_ip+0x211/0x270 kernel/softirq.c:189 local_bh_enable include/linux/bottom_half.h:32 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:696 [inline] ip_finish_output2+0xa88/0x1a00 net/ipv4/ip_output.c:231 ip_finish_output+0x7e4/0xf60 net/ipv4/ip_output.c:317 NF_HOOK_COND include/linux/netfilter.h:278 [inline] ip_output+0x226/0x880 net/ipv4/ip_output.c:405 dst_output include/net/dst.h:444 [inline] ip_local_out+0xc4/0x1b0 net/ipv4/ip_output.c:124 __ip_queue_xmit+0x99a/0x1ee0 net/ipv4/ip_output.c:505 ip_queue_xmit+0x5a/0x70 include/net/ip.h:198 __tcp_transmit_skb+0x1add/0x3af0 net/ipv4/tcp_output.c:1160 tcp_transmit_skb net/ipv4/tcp_output.c:1176 [inline] tcp_connect+0x33ca/0x4770 net/ipv4/tcp_output.c:3535 kobject: 'rx-0' (70ecd47e): kobject_uevent_env tcp_v4_connect+0x1598/0x1da0 net/ipv4/tcp_ipv4.c:315 __inet_stream_connect+0x9a3/0x11b0 net/ipv4/af_inet.c:655 kobject: 'rx-0' (70ecd47e): fill_kobj_path: path = '/devices/virtual/net/gretap0/queues/rx-0' kobject: 'tx-0' (301d47dc): kobject_add_internal: parent: 'queues', set: 'queues' inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:719 __sys_connect+0x357/0x490 net/socket.c:1664 kobject: 'tx-0' (301d47dc): kobject_uevent_env __do_sys_connect net/socket.c:1675 [inline] __se_sys_connect net/socket.c:1672 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:1672 kobject: 'tx-0' (301d47dc): fill_kobj_path: path = '/devices/virtual/net/gretap0/queues/tx-0' do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 kobject: 'batman_adv' (ab8b79c4): kobject_add_internal: parent: 'gretap0', set: '' entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f116f5d1c78 EFLAGS: 0246 ORIG_RAX: 002a kobject: 'erspan0' (1f020f96): kobject_add_internal: parent: 'net', set: 'devices' RAX: ffda RBX: 0003 RCX: 00457ec9 RDX: 0010 RSI: 20ccb000 RDI: 0007 RBP: 0073bfa0 R08: R09: R10: R11: 0246 R12:
KASAN: use-after-free Read in tcp_sk_exit
Hello, syzbot found the following crash on: HEAD commit:33a0efa4baec devlink: Use DIV_ROUND_UP_ULL in DEVLINK_HEAL.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=14e2e55f40 kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68 dashboard link: https://syzkaller.appspot.com/bug?extid=f797267da5e5012d0920 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f797267da5e5012d0...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in inet_ctl_sock_destroy include/net/inet_common.h:56 [inline] BUG: KASAN: use-after-free in tcp_sk_exit+0x203/0x230 net/ipv4/tcp_ipv4.c:2588 Read of size 8 at addr 888064de4378 by task kworker/u4:3/131 CPU: 0 PID: 131 Comm: kworker/u4:3 Not tainted 5.0.0-rc3+ #17 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 inet_ctl_sock_destroy include/net/inet_common.h:56 [inline] tcp_sk_exit+0x203/0x230 net/ipv4/tcp_ipv4.c:2588 ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153 cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551 process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153 worker_thread+0x143/0x14a0 kernel/workqueue.c:2296 kthread+0x357/0x430 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Allocated by task 5864: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_kmalloc mm/kasan/common.c:496 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469 kasan_kmalloc mm/kasan/common.c:504 [inline] kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:411 kmem_cache_alloc+0x12d/0x710 mm/slab.c:3543 getname_flags fs/namei.c:140 [inline] getname_flags+0xd6/0x5b0 fs/namei.c:129 getname+0x1a/0x20 fs/namei.c:211 do_sys_open+0x3a5/0x7c0 fs/open.c:1057 __do_sys_open fs/open.c:1081 [inline] __se_sys_open fs/open.c:1076 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1076 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5864: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458 kasan_slab_free+0xe/0x10 mm/kasan/common.c:466 __cache_free mm/slab.c:3487 [inline] kmem_cache_free+0x86/0x260 mm/slab.c:3749 putname+0xef/0x130 fs/namei.c:261 do_sys_open+0x3f4/0x7c0 fs/open.c:1072 __do_sys_open fs/open.c:1081 [inline] __se_sys_open fs/open.c:1076 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1076 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 888064de4180 which belongs to the cache names_cache of size 4096 The buggy address is located 504 bytes inside of 4096-byte region [888064de4180, 888064de5180) The buggy address belongs to the page: page:ea0001937900 count:1 mapcount:0 mapping:88821bc45380 index:0x0 compound_mapcount: 0 flags: 0x1fffc010200(slab|head) raw: 01fffc010200 ea0001931108 ea0001796b88 88821bc45380 raw: 888064de4180 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 888064de4200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 888064de4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 888064de4300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 888064de4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 888064de4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
BUG: spinlock bad magic in __queue_work
Hello, syzbot found the following crash on: HEAD commit:962c382d482a Merge tag 'mac80211-next-for-davem-2019-02-01.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=169299f8c0 kernel config: https://syzkaller.appspot.com/x/.config?x=33ad02b9305759c3 dashboard link: https://syzkaller.appspot.com/bug?extid=636bcaf4b481f6b7343c compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+636bcaf4b481f6b73...@syzkaller.appspotmail.com netlink: 8 bytes leftover after parsing attributes in process `syz-executor5'. BUG: spinlock bad magic on CPU#0, syz-executor0/1737 lock: 0x8880ae82c7e0, .magic: , .owner: %us workers=%d/1902867055, .owner_cpu: 0 CPU: 0 PID: 1737 Comm: syz-executor0 Not tainted 5.0.0-rc4+ #40 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 spin_dump.cold+0x81/0xe6 kernel/locking/spinlock_debug.c:67 spin_bug kernel/locking/spinlock_debug.c:75 [inline] debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x231/0x2e0 kernel/locking/spinlock_debug.c:112 __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline] _raw_spin_lock+0x37/0x40 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] __queue_work+0x23d/0x1180 kernel/workqueue.c:1417 __queue_delayed_work+0x1d6/0x270 kernel/workqueue.c:1522 mod_delayed_work_on+0xd8/0x200 kernel/workqueue.c:1596 mod_delayed_work include/linux/workqueue.h:542 [inline] addrconf_mod_dad_work+0x3f/0xa0 net/ipv6/addrconf.c:328 addrconf_dad_start+0x76/0xb0 net/ipv6/addrconf.c:4011 addrconf_add_linklocal+0x28c/0x3c0 net/ipv6/addrconf.c:3190 addrconf_addr_gen+0x34d/0x3a0 net/ipv6/addrconf.c:3313 addrconf_dev_config+0x1ea/0x2c0 net/ipv6/addrconf.c:3356 addrconf_notify+0x3c5/0x2280 net/ipv6/addrconf.c:3591 kobject: 'loop4' (f520b29a): kobject_uevent_env kobject: 'loop4' (f520b29a): fill_kobj_path: path = '/devices/virtual/block/loop4' notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739 call_netdevice_notifiers_extack net/core/dev.c:1751 [inline] call_netdevice_notifiers net/core/dev.c:1765 [inline] dev_open net/core/dev.c:1436 [inline] dev_open+0x143/0x160 net/core/dev.c:1424 ipmr_new_tunnel+0x3d3/0x4d0 net/ipv4/ipmr.c:511 vif_add+0x1bd/0xed0 net/ipv4/ipmr.c:873 ip_mroute_setsockopt+0xd05/0xe10 net/ipv4/ipmr.c:1453 do_ip_setsockopt.isra.0+0x3036/0x3e00 net/ipv4/ip_sockglue.c:638 ip_setsockopt+0x49/0x100 net/ipv4/ip_sockglue.c:1246 raw_setsockopt+0xe0/0x100 net/ipv4/raw.c:860 sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3016 __sys_setsockopt+0x180/0x280 net/socket.c:1902 __do_sys_setsockopt net/socket.c:1913 [inline] __se_sys_setsockopt net/socket.c:1910 [inline] __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457e39 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fbac2bcec78 EFLAGS: 0246 ORIG_RAX: 0036 RAX: ffda RBX: 0005 RCX: 00457e39 RDX: 00ca RSI: RDI: 0004 RBP: 0073bfa0 R08: 0010 R09: R10: 2000 R11: 0246 R12: 7fbac2bcf6d4 R13: 004c5c09 R14: 004da070 R15: netlink: 8 bytes leftover after parsing attributes in process `syz-executor5'. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
[PATCH -next] x86_64: tidy up KASAN_EXTRA
The commit 585a4c1f9978 ("kasan: remove use after scope bugs
detection.") removed KASAN_EXTRA, so tidy up leftovers.
Signed-off-by: Qian Cai
---
arch/x86/include/asm/page_64_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 0ce558a8150d..8f657286d599 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -7,11 +7,7 @@
#endif
#ifdef CONFIG_KASAN
-#ifdef CONFIG_KASAN_EXTRA
-#define KASAN_STACK_ORDER 2
-#else
#define KASAN_STACK_ORDER 1
-#endif
#else
#define KASAN_STACK_ORDER 0
#endif
--
2.17.2 (Apple Git-113)
Re: [PATCH 1/2] cpufreq: qcom-hw: Register an Energy Model
On 05-02-19, 09:52, Matthias Kaehlcke wrote: > Try and register an Energy Model from qcom-cpufreq-hw to allow > interested sub-systems like the task scheduler to use the provided > information. > > Signed-off-by: Matthias Kaehlcke > --- > drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c > b/drivers/cpufreq/qcom-cpufreq-hw.c > index d83939a1b3d4c..a16b9dca7ea3b 100644 > --- a/drivers/cpufreq/qcom-cpufreq-hw.c > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c > @@ -205,6 +205,8 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy > *policy) > goto error; > } > > + dev_pm_opp_of_register_em(policy->cpus); > + > policy->fast_switch_possible = true; > > return 0; Applied both. Thanks. -- viresh
Re: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return
Balbir Singh writes:
> On Tue, Feb 5, 2019 at 10:24 PM Michael Ellerman wrote:
>> Balbir Singh writes:
>> > On Sat, Feb 2, 2019 at 12:14 PM Balbir Singh wrote:
>> >> On Tue, Jan 22, 2019 at 10:57:21AM -0500, Joe Lawrence wrote:
>> >> > From: Nicolai Stange
>> >> >
>> >> > The ppc64 specific implementation of the reliable stacktracer,
>> >> > save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
>> >> > trace" whenever it finds an exception frame on the stack. Stack frames
>> >> > are classified as exception frames if the STACK_FRAME_REGS_MARKER magic,
>> >> > as written by exception prologues, is found at a particular location.
>> >> >
>> >> > However, as observed by Joe Lawrence, it is possible in practice that
>> >> > non-exception stack frames can alias with prior exception frames and
>> >> > thus,
>> >> > that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER
>> >> > on
>> >> > the stack. It in turn falsely reports an unreliable stacktrace and
>> >> > blocks
>> >> > any live patching transition to finish. Said condition lasts until the
>> >> > stack frame is overwritten/initialized by function call or other means.
>> >> >
>> >> > In principle, we could mitigate this by making the exception frame
>> >> > classification condition in save_stack_trace_tsk_reliable() stronger:
>> >> > in addition to testing for STACK_FRAME_REGS_MARKER, we could also take
>> >> > into
>> >> > account that for all exceptions executing on the kernel stack
>> >> > - their stack frames's backlink pointers always match what is saved
>> >> > in their pt_regs instance's ->gpr[1] slot and that
>> >> > - their exception frame size equals STACK_INT_FRAME_SIZE, a value
>> >> > uncommonly large for non-exception frames.
>> >> >
>> >> > However, while these are currently true, relying on them would make the
>> >> > reliable stacktrace implementation more sensitive towards future
>> >> > changes in
>> >> > the exception entry code. Note that false negatives, i.e. not detecting
>> >> > exception frames, would silently break the live patching consistency
>> >> > model.
>> >> >
>> >> > Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
>> >> > rely on STACK_FRAME_REGS_MARKER as well.
>> >> >
>> >> > Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER
>> >> > for those exceptions running on the "normal" kernel stack and returning
>> >> > to kernelspace: because the topmost frame is ignored by the reliable
>> >> > stack
>> >> > tracer anyway, returns to userspace don't need to take care of clearing
>> >> > the marker.
>> >> >
>> >> > Furthermore, as I don't have the ability to test this on Book 3E or
>> >> > 32 bits, limit the change to Book 3S and 64 bits.
>> >> >
>> >> > Finally, make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on
>> >> > PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended
>> >> > on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies
>> >> > PPC_BOOK3S_64, there's no functional change here.
>> >> >
>> >> > Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack
>> >> > tracing for the consistency model")
>> >> > Reported-by: Joe Lawrence
>> >> > Signed-off-by: Nicolai Stange
>> >> > Signed-off-by: Joe Lawrence
>> >> > ---
>> >> > arch/powerpc/Kconfig | 2 +-
>> >> > arch/powerpc/kernel/entry_64.S | 7 +++
>> >> > 2 files changed, 8 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> >> > index 2890d36eb531..73bf87b1d274 100644
>> >> > --- a/arch/powerpc/Kconfig
>> >> > +++ b/arch/powerpc/Kconfig
>> >> > @@ -220,7 +220,7 @@ config PPC
>> >> > select HAVE_PERF_USER_STACK_DUMP
>> >> > select HAVE_RCU_TABLE_FREE if SMP
>> >> > select HAVE_REGS_AND_STACK_ACCESS_API
>> >> > - select HAVE_RELIABLE_STACKTRACE if PPC64 &&
>> >> > CPU_LITTLE_ENDIAN
>> >> > + select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 &&
>> >> > CPU_LITTLE_ENDIAN
>> >> > select HAVE_SYSCALL_TRACEPOINTS
>> >> > select HAVE_VIRT_CPU_ACCOUNTING
>> >> > select HAVE_IRQ_TIME_ACCOUNTING
>> >> > diff --git a/arch/powerpc/kernel/entry_64.S
>> >> > b/arch/powerpc/kernel/entry_64.S
>> >> > index 435927f549c4..a2c168b395d2 100644
>> >> > --- a/arch/powerpc/kernel/entry_64.S
>> >> > +++ b/arch/powerpc/kernel/entry_64.S
>> >> > @@ -1002,6 +1002,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>> >> > ld r2,_NIP(r1)
>> >> > mtspr SPRN_SRR0,r2
>> >> >
>> >> > + /*
>> >> > + * Leaving a stale exception_marker on the stack can confuse
>> >> > + * the reliable stack unwinder later on. Clear it.
>> >> > + */
>> >> > + li r2,0
>> >> > + std r2,STACK_FRAME_OVERHEAD-16(r1)
>> >> > +
>> >>
>> >> Could you please double check, r4 is already 0 at this point
>> >> IIUC. So the change might be a simple
>> >>
>> >> std r4,STACK_FRAME_OVERHEAD-16(r1)
>> >>
Re: BUG: optimized kprobes illegal instructions in v4.19 stable kernels
On Tue, 5 Feb 2019 15:06:10 + Kees Cook wrote: > On Mon, Feb 4, 2019 at 7:15 PM Mathieu Desnoyers > wrote: > > > > Hi, > > > > I notice this commit as a possible culprit of the illegal instructions my > > lttng > > users are noticing on arm32 when using kprobes on a v4.19.13 Linux kernel > > in a Yocto environment [1]. They were able to reproduce the issue with perf > > as well. > > > > commit e46daee53bb50bde38805f1823a182979724c229 > > Author: Kees Cook > > Date: Tue Oct 30 22:12:56 2018 +0100 > > > > ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE > > > > I *think* the intent there was to do > > > > - memcpy(code, _template_entry, > > + memcpy(code, (unsigned long *)_template_entry, > > > > But if you look at the commit, the "&" seems to have been stripped away, > > which happens to change the behavior significantly. > > Yeah, this was a typo on my part. :( Ah, I thought it had been fixed as same as x86. On x86, all optprobe_template_* are defined as kprobe_opcode_t [], but on arm, it still be kprobe_opcode_t. Hmm, but I think we should use kprobe_opcode_t [] or char[] as asm/sections.h does. OK, I'll prepare for the change. Thank you, > > > Has this change ever been runtime-tested ? > > I thought I had, given the details from the original bug report, but > clearly it didn't exercise it. > > Thanks for fixing this! > > -Kees > > > > > It has been backported to: > > - 4.19 stable as commit 3fe0c68aea21 > > - 4.14 stable as commit f9e0bc710347 > > > > Thanks, > > > > Mathieu > > > > [1] https://bugs.lttng.org/issues/1174 > > > > -- > > Mathieu Desnoyers > > EfficiOS Inc. > > http://www.efficios.com > > > > -- > Kees Cook -- Masami Hiramatsu
Re: [PATCH 1/1] Fix: arm: kprobes: optimized kprobes illegal instruction
On Tue, 5 Feb 2019 10:37:40 -0500
Mathieu Desnoyers wrote:
> commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
> FORTIFY_SOURCE") introduced a regression in optimized kprobes. It
> triggers "invalid instruction" oopses when using kprobes instrumentation
> through lttng and perf. This commit was introduced in kernel v4.20, and
> has been backported to stable kernels 4.19 and 4.14.
>
> This crash was also reported by Hongzhi Song on the redhat bugzilla
> where the patch was originally introduced.
Thank you for fixing this.
Acked-by: Masami Hiramatsu
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1639397
> Link: https://bugs.lttng.org/issues/1174
> Link:
> https://lore.kernel.org/lkml/342740659.2887.1549307721609.javamail.zim...@efficios.com
> Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
> FORTIFY_SOURCE")
> Signed-off-by: Mathieu Desnoyers
> Reported-by: Robert Berger
> Tested-by: Robert Berger
> Acked-by: Kees Cook
> CC: Robert Berger
> CC: Masami Hiramatsu
> CC: William Cohen
> CC: Laura Abbott
> CC: Kees Cook
> CC: Russell King
> CC: # v4.14+
> CC: linux-arm-ker...@lists.infradead.org
> CC: patc...@armlinux.org.uk
> ---
> KernelVersion: 5.0.0-rc5
> arch/arm/probes/kprobes/opt-arm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/probes/kprobes/opt-arm.c
> b/arch/arm/probes/kprobes/opt-arm.c
> index 2c118a6ab358..0dc23fc227ed 100644
> --- a/arch/arm/probes/kprobes/opt-arm.c
> +++ b/arch/arm/probes/kprobes/opt-arm.c
> @@ -247,7 +247,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
> *op, struct kprobe *or
> }
>
> /* Copy arch-dep-instance from template. */
> - memcpy(code, (unsigned char *)optprobe_template_entry,
> + memcpy(code, (unsigned long *)_template_entry,
> TMPL_END_IDX * sizeof(kprobe_opcode_t));
>
> /* Adjust buffer according to instruction. */
> --
> 2.11.0
>
--
Masami Hiramatsu
Re: linux-next: Fixes tag needs some work in the scsi-fixes tree
Hi Vaibhav, On Wed, 06 Feb 2019 09:25:12 +0530 Vaibhav Jain wrote: > > Martin, should I resend the patch with this fixed ? I wouldn't bother, it is a really picky report (I almost didn't send it) :-) Consider it just a reminder for next time. -- Cheers, Stephen Rothwell pgpwFIft3qTrz.pgp Description: OpenPGP digital signature
Re: linux-next: Fixes tag needs some work in the scsi-fixes tree
Stephen Rothwell writes:
> Hi Martin,
>
> In commit
>
> bb61b843ffd4 ("scsi: cxlflash: Prevent deadlock when adapter probe fails")
>
> Fixes tag
>
> Fixes: c21e0bbfc485("cxlflash: Base support for IBM CXL Flash Adapter")
>
> has these problem(s):
>
> - missing space between the SHA1 and the subject
Thanks for catching this Stephen. I am surprised that the checkpatch.pl
script didnt catch this.
Martin, should I resend the patch with this fixed ?
Thanks,
--
Vaibhav Jain
Linux Technology Center, IBM India Pvt. Ltd.
Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
On Tue, 2019-02-05 at 20:25 -0700, Paul Zimmerman wrote: > GCC does not lay out stack variables in the same order that they are > declared. True. Most stack variables could be assigned to a register. cheers, Joe
[PATCH -next] mm/compaction: no stuck in __reset_isolation_pfn()
The commit c68d77911c23 ("mm, compaction: be selective about what
pageblocks to clear skip hints") introduced an infinite loop if a pfn is
invalid, it will loop again without increasing page counters. It can be
reproduced by running LTP tests on an arm64 server.
# oom01 (swapping)
# hugemmap01
tst_test.c:1096: INFO: Timeout per run is 0h 05m 00s
mem.c:814: INFO: set nr_hugepages to 128
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Cannot kill test processes!
Congratulation, likely test hit a kernel bug.
Also, triggers soft lockups.
[ 456.232228] watchdog: BUG: soft lockup - CPU#122 stuck for 22s!
[kswapd0:1375]
[ 456.273354] pstate: 8049 (Nzcv daif +PAN -UAO)
[ 456.278143] pc : pfn_valid+0x54/0xdc
[ 456.281713] lr : __reset_isolation_pfn+0x3a8/0x584
[ 456.369358] Call trace:
[ 456.371798] pfn_valid+0x54/0xdc
[ 456.375019] __reset_isolation_pfn+0x3a8/0x584
[ 456.379455] __reset_isolation_suitable+0x1bc/0x280
[ 456.384325] reset_isolation_suitable+0xb8/0xe0
[ 456.388847] kswapd+0xd08/0x1048
[ 456.392067] kthread+0x2f4/0x30c
[ 456.395289] ret_from_fork+0x10/0x18
Fixes: c68d77911c23 ("mm, compaction: be selective about what pageblocks to
clear skip hints")
Signed-off-by: Qian Cai
---
mm/compaction.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 03804ab412f3..1cc871da3fda 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -282,17 +282,16 @@ __reset_isolation_pfn(struct zone *zone, unsigned long
pfn, bool check_source,
end_page = pfn_to_page(pfn);
do {
- if (!pfn_valid_within(pfn))
- continue;
-
- if (check_source && PageLRU(page)) {
- clear_pageblock_skip(page);
- return true;
- }
+ if (pfn_valid_within(pfn)) {
+ if (check_source && PageLRU(page)) {
+ clear_pageblock_skip(page);
+ return true;
+ }
- if (check_target && PageBuddy(page)) {
- clear_pageblock_skip(page);
- return true;
+ if (check_target && PageBuddy(page)) {
+ clear_pageblock_skip(page);
+ return true;
+ }
}
page += (1 << PAGE_ALLOC_COSTLY_ORDER);
--
2.17.2 (Apple Git-113)
Re: KASAN: use-after-free Read in __wake_up_common_lock
On 02/05/2019 07:28 PM, Dmitry Vyukov wrote: > On Wed, Jan 30, 2019 at 10:02 PM syzbot > wrote: >> >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:62967898789d Merge git://git.kernel.org/pub/scm/linux/kern.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=10f0bf08c0 >> kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 >> dashboard link: https://syzkaller.appspot.com/bug?extid=fb065bc06d3d4054be6f >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) >> >> Unfortunately, I don't have any reproducer for this crash yet. >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+fb065bc06d3d4054b...@syzkaller.appspotmail.com > > I assume this is also fixed by: > > #syz fix: mISDN: fix a race in dev_expire_timer() Yes this looks very probable, thanks.
[PATCH 0/9] ARM: sun9i: a80: Enable GMAC
Hi everyone, On the Allwinner A80, the PIO pin controller includes configuration registers to set the I/O voltage. These must match the actual voltage provided externally. A mismatch results in signals not being passed through. With the new PIO pin-bank regulator supply support in place, we can tack on support for setting up these registers. This in turn allows us to enable the GMAC, which runs at a reduced 2.5V for RGMII, instead of the standard 3.0V or 3.3V. Please have a look. Regards ChenYu Chen-Yu Tsai (9): pinctrl: sunxi: Support I/O bias voltage setting on A80 ARM: dts: sun9i: a80-optimus: Add node for AXP809's unused dc1sw regulator ARM: dts: sun9i: a80-optimus: Add GPIO pin-bank regulator supplies ARM: dts: sun9i: cubieboard4: Add GPIO pin-bank regulator supplies ARM: dts: sun9i: Add GMAC clock node ARM: dts: sun9i: Add A80 GMAC gigabit ethernet controller node ARM: dts: sun9i: Add A80 GMAC RGMII pinmux setting ARM: dts: sun9i: a80-optimus: Enable GMAC ARM: dts: sun9i: cubieboard4: Enable GMAC arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 44 +- arch/arm/boot/dts/sun9i-a80-optimus.dts | 44 +- arch/arm/boot/dts/sun9i-a80.dtsi| 65 + drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c | 1 + drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 1 + drivers/pinctrl/sunxi/pinctrl-sunxi.c | 41 + drivers/pinctrl/sunxi/pinctrl-sunxi.h | 12 7 files changed, 202 insertions(+), 6 deletions(-) -- 2.20.1
[PATCH 3/9] ARM: dts: sun9i: a80-optimus: Add GPIO pin-bank regulator supplies
The A80 Optimus has the PMIC providing voltage to all the pin-bank
supply rails from its various regulator outputs. All pin-banks that
have supply rails are accounted for. PN pin-bank does not have a
supply rail.
Also remove any "regulator-always-on" properties from regulators that
were only marked to provide pin-bank power.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-optimus.dts | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 1ee2792b3a27..9c25176e69dc 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -172,10 +172,26 @@
clocks = <_rtc 0>;
};
+ {
+ vcc-pa-supply = <_ldo_io1>;
+ vcc-pb-supply = <_aldo2>;
+ vcc-pc-supply = <_dcdc1>;
+ vcc-pd-supply = <_dcdc1>;
+ vcc-pe-supply = <_eldo2>;
+ vcc-pf-supply = <_dcdc1>;
+ vcc-pg-supply = <_ldo_io0>;
+ vcc-ph-supply = <_dcdc1>;
+};
+
_ir {
status = "okay";
};
+_pio {
+ vcc-pl-supply = <_dldo2>;
+ vcc-pm-supply = <_eldo3>;
+};
+
_rsb {
status = "okay";
@@ -264,7 +280,6 @@
};
reg_dldo2: dldo2 {
- regulator-always-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-name = "vcc-pl";
@@ -283,14 +298,12 @@
};
reg_eldo3: eldo3 {
- regulator-always-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-name = "vcc-pm-codec-io1";
};
reg_ldo_io0: ldo_io0 {
- regulator-always-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-name = "vcc-pg";
--
2.20.1
[PATCH 7/9] ARM: dts: sun9i: Add A80 GMAC RGMII pinmux setting
The GMAC (gigabit ethernet controller) supports RGMII to connect to
the ethernet PHY, for gigabit network speeds.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index f0c7acf2d0a4..6fb292e0b662 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -1000,6 +1000,19 @@
#size-cells = <0>;
#gpio-cells = <3>;
+ gmac_rgmii_pins: gmac-rgmii-pins {
+ allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+"PA4", "PA5", "PA7", "PA8",
+"PA9", "PA10", "PA12", "PA13",
+"PA15", "PA16", "PA17";
+ allwinner,function = "gmac";
+ /*
+* data lines in RGMII mode use DDR mode
+* and need a higher signal drive strength
+*/
+ drive-strength = <40>;
+ };
+
i2c3_pins: i2c3-pins {
pins = "PG10", "PG11";
function = "i2c3";
--
2.20.1
[PATCH 5/9] ARM: dts: sun9i: Add GMAC clock node
The A80 has the same DWMAC hardware as on earlier Allwinner SoCs. The
accompanying GMAC clock register has been moved into the "System
Control" area.
Add a clock node for it.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index d9532fb1ef65..724ca3b850c8 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -183,6 +183,37 @@
clock-output-names = "osc32k";
};
+ /*
+* The following two are dummy clocks, placeholders
+* used in the gmac_tx clock. The gmac driver will
+* choose one parent depending on the PHY interface
+* mode, using clk_set_rate auto-reparenting.
+*
+* The actual TX clock rate is not controlled by the
+* gmac_tx clock.
+*/
+ mii_phy_tx_clk: mii_phy_tx_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ clock-output-names = "mii_phy_tx";
+ };
+
+ gmac_int_tx_clk: gmac_int_tx_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_int_tx";
+ };
+
+ gmac_tx_clk: clk@800030 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x00800030 0x4>;
+ clocks = <_phy_tx_clk>, <_int_tx_clk>;
+ clock-output-names = "gmac_tx";
+ };
+
cpus_clk: clk@8001410 {
compatible = "allwinner,sun9i-a80-cpus-clk";
reg = <0x08001410 0x4>;
--
2.20.1
[PATCH 9/9] ARM: dts: sun9i: cubieboard4: Enable GMAC
The Cubieboard4 has a Realtek RTL8211E ethernet PHY which uses RGMII to
talk to the MAC. The PHY is powered by 2 regulators: cldo1 for the PHY's
core logic and gpio1-ldo for I/O. The latter also powers the SoC side
pins. As there is no binding to model a second regulator supply for the
PHY, it is omitted. It is however properly modeled for the PIO.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 0daab9b374e6..28c034928d67 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -133,6 +133,19 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgmii_pins>;
+ phy = <>;
+ phy-mode = "rgmii";
+ phy-supply = <_cldo1>;
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -402,6 +415,14 @@
*/
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /*
+* The PHY requires 20ms after all voltages
+* are applied until core logic is ready and
+* 30ms after the reset pin is de-asserted.
+* Set a 100ms delay to account for PMIC
+* ramp time and board traces.
+*/
+ regulator-enable-ramp-delay = <10>;
regulator-name = "vcc-gmac-phy";
};
--
2.20.1
[PATCH 2/9] ARM: dts: sun9i: a80-optimus: Add node for AXP809's unused dc1sw regulator
The DC1SW output from the AXP809 is unused. Unused regulators should
still be listed so as to be considered to be fully constrained.
Fixes: aa4a27bc819e ("ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC
device node and regulators")
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-optimus.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 58a199b0e494..1ee2792b3a27 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -213,6 +213,10 @@
regulator-name = "vdd-cpus-09-usbh";
};
+ dc1sw {
+ /* unused */
+ };
+
reg_dcdc1: dcdc1 {
regulator-always-on;
regulator-min-microvolt = <300>;
--
2.20.1
[PATCH 8/9] ARM: dts: sun9i: a80-optimus: Enable GMAC
The A80 Optimus has a Realtek RTL8211E ethernet PHY which uses RGMII to
talk to the MAC. The PHY is powered by 2 regulators: cldo1 for the PHY's
core logic and gpio1-ldo for I/O. The latter also powers the SoC side
pins. As there is no binding to model a second regulator supply for the
PHY, it is omitted. It is however properly modeled for the PIO.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-optimus.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 9c25176e69dc..864715ec3cb0 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -120,6 +120,19 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgmii_pins>;
+ phy = <>;
+ phy-mode = "rgmii";
+ phy-supply = <_cldo1>;
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -391,6 +404,14 @@
*/
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /*
+* The PHY requires 20ms after all voltages
+* are applied until core logic is ready and
+* 30ms after the reset pin is de-asserted.
+* Set a 100ms delay to account for PMIC
+* ramp time and board traces.
+*/
+ regulator-enable-ramp-delay = <10>;
regulator-name = "vcc-gmac-phy";
};
--
2.20.1
[PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80
The A80 SoC has configuration registers for I/O bias voltage. Incorrect
settings would make the affected peripherals inoperable in some cases,
such as Ethernet RGMII signals biased at 2.5V with the settings still
at 3.3V. However low speed signals such as MDIO on the same group of
pins seem to be unaffected.
Previously there was no way to know what the actual voltage used was,
short of hard-coding a value in the device tree. With the new pin bank
regulator supply support in place, the driver can now query the
regulator for its voltage, and if it's valid (as opposed to being the
dummy regulator), set the bias voltage setting accordingly.
Add a quirk to denote the presence of the configuration registers, and
a function to set the correct setting based on the voltage read back
from the regulator.
This is only done when the regulator is first acquired and enabled.
While it would be nice to have a notifier on the regulator so that when
the voltage changes, the driver can update the setting, in practice no
board currently supports dynamic changing of the I/O voltages.
Signed-off-by: Chen-Yu Tsai
---
drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c | 1 +
drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 1 +
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 41 +
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 12 ++
4 files changed, 55 insertions(+)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
index c63086c98335..e05dd9a5551d 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
@@ -153,6 +153,7 @@ static const struct sunxi_pinctrl_desc
sun9i_a80_r_pinctrl_data = {
.pin_base = PL_BASE,
.irq_banks = 2,
.disable_strict_mode = true,
+ .has_io_bias_cfg = true,
};
static int sun9i_a80_r_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
index 5553c0eb0f41..da37d594a13d 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
@@ -722,6 +722,7 @@ static const struct sunxi_pinctrl_desc
sun9i_a80_pinctrl_data = {
.npins = ARRAY_SIZE(sun9i_a80_pins),
.irq_banks = 5,
.disable_strict_mode = true,
+ .has_io_bias_cfg = true,
};
static int sun9i_a80_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 0e7fa69e93df..8dd25caea2cf 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -603,6 +603,45 @@ static const struct pinconf_ops sunxi_pconf_ops = {
.pin_config_group_set = sunxi_pconf_group_set,
};
+static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
+unsigned pin,
+struct regulator *supply)
+{
+ u32 val, reg;
+ int uV;
+
+ if (!pctl->desc->has_io_bias_cfg)
+ return 0;
+
+ uV = regulator_get_voltage(supply);
+ if (uV < 0)
+ return uV;
+
+ /* Might be dummy regulator with no voltage set */
+ if (uV == 0)
+ return 0;
+
+ /* Configured value must be equal or greater to actual voltage */
+ if (uV <= 180)
+ val = 0x0; /* 1.8V */
+ else if (uV <= 250)
+ val = 0x6; /* 2.5V */
+ else if (uV <= 280)
+ val = 0x9; /* 2.8V */
+ else if (uV <= 300)
+ val = 0xA; /* 3.0V */
+ else
+ val = 0xD; /* 3.3V */
+
+ pin -= pctl->desc->pin_base;
+
+ reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
+ reg &= ~IO_BIAS_MASK;
+ writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
+
+ return 0;
+}
+
static int sunxi_pmx_get_funcs_cnt(struct pinctrl_dev *pctldev)
{
struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
@@ -725,6 +764,8 @@ static int sunxi_pmx_request(struct pinctrl_dev *pctldev,
unsigned offset)
goto out;
}
+ sunxi_pinctrl_set_io_bias_cfg(pctl, offset, reg);
+
s_reg->regulator = reg;
refcount_set(_reg->refcount, 1);
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 034c0317c8d6..ee15ab067b5f 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -79,6 +79,10 @@
#define IRQ_LEVEL_LOW 0x03
#define IRQ_EDGE_BOTH 0x04
+#define GRP_CFG_REG0x300
+
+#define IO_BIAS_MASK GENMASK(3, 0)
+
#define SUN4I_FUNC_INPUT 0
#define SUN4I_FUNC_IRQ 6
@@ -113,6 +117,7 @@ struct sunxi_pinctrl_desc {
const unsigned int *irq_bank_map;
boolirq_read_needs_mux;
bool
[PATCH 6/9] ARM: dts: sun9i: Add A80 GMAC gigabit ethernet controller node
The A80 has the same GMAC found on the A31 SoC.
Add a device node, and an alias for it.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 724ca3b850c8..f0c7acf2d0a4 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -56,6 +56,10 @@
#size-cells = <2>;
interrupt-parent = <>;
+ aliases {
+ ethernet0 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -314,6 +318,23 @@
};
};
+ gmac: ethernet@83 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x0083 0x1054>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ clocks = < CLK_BUS_GMAC>, <_tx_clk>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ resets = < RST_BUS_GMAC>;
+ reset-names = "stmmaceth";
+ snps,pbl = <2>;
+ snps,fixed-burst;
+ snps,force_sf_dma_mode;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
ehci0: usb@a0 {
compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
reg = <0x00a0 0x100>;
--
2.20.1
[PATCH 4/9] ARM: dts: sun9i: cubieboard4: Add GPIO pin-bank regulator supplies
The Cubieboard 4 has the PMIC providing voltage to all the pin-bank
supply rails from its various regulator outputs. All pin-banks that
have supply rails are accounted for. PN pin-bank does not have a
supply rail.
Also remove any "regulator-always-on" properties from regulators that
were only marked to provide pin-bank power.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 23 ++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 85da85faf869..0daab9b374e6 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -183,10 +183,26 @@
clocks = <_rtc 0>;
};
+ {
+ vcc-pa-supply = <_ldo_io1>;
+ vcc-pb-supply = <_aldo2>;
+ vcc-pc-supply = <_dcdc1>;
+ vcc-pd-supply = <_dc1sw>;
+ vcc-pe-supply = <_eldo2>;
+ vcc-pf-supply = <_dcdc1>;
+ vcc-pg-supply = <_ldo_io0>;
+ vcc-ph-supply = <_dcdc1>;
+};
+
_ir {
status = "okay";
};
+_pio {
+ vcc-pl-supply = <_dldo2>;
+ vcc-pm-supply = <_eldo3>;
+};
+
_rsb {
status = "okay";
@@ -217,6 +233,10 @@
/* unused */
};
+ reg_dc1sw: dc1sw {
+ regulator-name = "vcc-pd";
+ };
+
reg_dc5ldo: dc5ldo {
regulator-always-on;
regulator-min-microvolt = <80>;
@@ -271,7 +291,6 @@
};
reg_dldo2: dldo2 {
- regulator-always-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-name = "vcc-pl";
@@ -290,14 +309,12 @@
};
reg_eldo3: eldo3 {
- regulator-always-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-name = "vcc-pm-codec-io1";
};
reg_ldo_io0: ldo_io0 {
- regulator-always-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-name = "vcc-pg";
--
2.20.1
[PATCH] phy: Variable "val" in function miphy_osc_is_ready() could be uninitialized
In function miphy_osc_is_ready(), local variable "val"
could be uninitalized. if function regmap_read() returns
-EINVAL. However, this value is used in if statement.
This is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/phy/st/phy-miphy28lp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/st/phy-miphy28lp.c b/drivers/phy/st/phy-miphy28lp.c
index 213e2e15339c..40c7c0a611a0 100644
--- a/drivers/phy/st/phy-miphy28lp.c
+++ b/drivers/phy/st/phy-miphy28lp.c
@@ -835,7 +835,8 @@ static int miphy_osc_is_ready(struct miphy28lp_phy
*miphy_phy)
{
struct miphy28lp_dev *miphy_dev = miphy_phy->phydev;
unsigned long finish = jiffies + 5 * HZ;
- u32 val;
+ u32 val = 0;
+ int ret;
if (!miphy_phy->osc_rdy)
return 0;
@@ -844,8 +845,10 @@ static int miphy_osc_is_ready(struct miphy28lp_phy
*miphy_phy)
return -EINVAL;
do {
- regmap_read(miphy_dev->regmap,
+ ret = regmap_read(miphy_dev->regmap,
miphy_phy->syscfg_reg[SYSCFG_STATUS], );
+ if (ret)
+ return ret;
if ((val & MIPHY_OSC_RDY) != MIPHY_OSC_RDY)
cpu_relax();
--
2.17.1
Re: KASAN: use-after-free Read in __wake_up_common_lock
On Wed, Jan 30, 2019 at 10:02 PM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:62967898789d Merge git://git.kernel.org/pub/scm/linux/kern.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=10f0bf08c0 > kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > dashboard link: https://syzkaller.appspot.com/bug?extid=fb065bc06d3d4054be6f > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+fb065bc06d3d4054b...@syzkaller.appspotmail.com I assume this is also fixed by: #syz fix: mISDN: fix a race in dev_expire_timer() > QAT: Invalid ioctl > == > BUG: KASAN: use-after-free in debug_spin_lock_before > kernel/locking/spinlock_debug.c:83 [inline] > BUG: KASAN: use-after-free in do_raw_spin_lock+0x303/0x360 > kernel/locking/spinlock_debug.c:112 > Read of size 4 at addr 88808738e92c by task syz-executor1/8644 > > CPU: 1 PID: 8644 Comm: syz-executor1 Not tainted 5.0.0-rc4+ #50 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 > __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:134 > debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] > do_raw_spin_lock+0x303/0x360 kernel/locking/spinlock_debug.c:112 > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] > _raw_spin_lock_irqsave+0x9d/0xcd kernel/locking/spinlock.c:152 > __wake_up_common_lock+0x19b/0x390 kernel/sched/wait.c:120 > __wake_up+0xe/0x10 kernel/sched/wait.c:145 > dev_expire_timer+0x14b/0x570 drivers/isdn/mISDN/timerdev.c:174 > call_timer_fn+0x254/0x900 kernel/time/timer.c:1325 > expire_timers kernel/time/timer.c:1362 [inline] > __run_timers+0x6fc/0xd50 kernel/time/timer.c:1681 > IPVS: ftp: loaded support on port[0] = 21 > run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694 > __do_softirq+0x30b/0xb11 kernel/softirq.c:292 > invoke_softirq kernel/softirq.c:373 [inline] > irq_exit+0x180/0x1d0 kernel/softirq.c:413 > exiting_irq arch/x86/include/asm/apic.h:536 [inline] > smp_apic_timer_interrupt+0x1b7/0x760 arch/x86/kernel/apic/apic.c:1062 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 > > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:766 > [inline] > RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 > [inline] > RIP: 0010:_raw_spin_unlock_irqrestore+0x95/0xe0 > kernel/locking/spinlock.c:184 > Code: 48 c7 c0 30 82 92 89 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c > 10 00 75 39 48 83 3d 12 d0 9d 01 00 74 24 48 89 df 57 9d <0f> 1f 44 00 00 > bf 01 00 00 00 e8 dc 75 63 f9 65 8b 05 95 3b 0d 78 > RSP: 0018:888050a7f360 EFLAGS: 0282 ORIG_RAX: ff13 > RAX: 11325046 RBX: 0282 RCX: > RDX: dc00 RSI: 0001 RDI: 0282 > RBP: 888050a7f370 R08: 888088b9e000 R09: > R10: R11: R12: 8b72b128 > R13: 888088b9e000 R14: 000d7480 R15: 8b72b128 > __debug_object_init+0x1c0/0x12d0 lib/debugobjects.c:418 > debug_object_init+0x16/0x20 lib/debugobjects.c:431 > __init_work+0x50/0x60 kernel/workqueue.c:504 > call_usermodehelper_setup+0x133/0x410 kernel/umh.c:389 > call_modprobe kernel/kmod.c:94 [inline] > __request_module+0x4f5/0xeea kernel/kmod.c:171 > crypto_larval_lookup crypto/api.c:237 [inline] > crypto_alg_mod_lookup+0x54e/0x6d0 crypto/api.c:280 > QAT: Invalid ioctl > crypto_find_alg crypto/api.c:504 [inline] > crypto_alloc_tfm+0xd9/0x2f0 crypto/api.c:537 > crypto_alloc_skcipher+0x2d/0x40 crypto/skcipher.c:945 > cryptd_alloc_skcipher+0x121/0x270 crypto/cryptd.c:1226 > IPVS: ftp: loaded support on port[0] = 21 > simd_skcipher_init+0x6c/0x1c0 crypto/simd.c:119 > crypto_skcipher_init_tfm+0x299/0x8c0 crypto/skcipher.c:862 > crypto_create_tfm+0xec/0x310 crypto/api.c:471 > crypto_alloc_tfm+0x104/0x2f0 crypto/api.c:543 > crypto_alloc_skcipher+0x2d/0x40 crypto/skcipher.c:945 > QAT: Invalid ioctl > skcipher_bind+0x26/0x30 crypto/algif_skcipher.c:310 > alg_bind+0x25d/0x570 crypto/af_alg.c:183 > __sys_bind+0x30b/0x420 net/socket.c:1483 > __do_sys_bind net/socket.c:1494 [inline] > __se_sys_bind net/socket.c:1492 [inline] > __x64_sys_bind+0x73/0xb0 net/socket.c:1492 > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x458089 > Code: 6d b7 fb ff c3 66 2e 0f 1f
Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
On Tue, 05 Feb 2019 18:52:18 -0800, Joe Perches wrote: > On Tue, 2019-02-05 at 19:27 -0700, Paul Zimmerman wrote: >> On Tue, 2019-02-05, Joe Perches wrote: >>> On Tue, 2019-02-05 at 12:04 -0800, Eric Dumazet wrote: >>> > On 02/05/2019 10:42 AM, Joe Perches wrote: >>> > > It's declared after a pointer so it is already is 2 byte aligned. >>> > > >>> > > A lot of drivers wouldn't work otherwise. >>> > >>> > Maybe these drivers are only used on arches where this does not matter. >>> >>> Possible. >>> >>> I had only grepped through the sources looking for >>> declarations using: >>> >>> $ git grep -B1 '\[ETH_ALEN\];' -- '*.c' | grep -A1 '\*' >>> >>> It's quite a few files in net/ too btw. >>> >>> I still think adding __align() is unnecessary here unless >>> it follows something like a bool or a u8. >> >> Um, guys, this is practically C-101. >> >> From C99, 6.7.2.1: >> >> > 13/ Within a structure object, the non-bit-field members and the units in >> > which bit-fields reside have addresses that increase in the order in which >> > they are declared. A pointer to a structure object, suitably converted, >> > points to its initial member (or if that member is a bit-field, then to the >> > unit in which it resides), and vice versa. There may be unnamed padding >> > within a structure object, but not at its beginning. >> >> AFAIK there is no such language in the spec regarding variable layout on >> the stack. So Joe, you are totally off-base here. > > We're not talking about the spec, see the void * arithmetic > bit, we're talking about what gcc and clang actually do. Sorry, I see I was a bit unclear. In an earlier message, which I neglected to quote, you said: > It's declared after a pointer so it is already is 2 byte aligned. > A lot of drivers wouldn't work otherwise. But it's declared after a pointer *on the stack* (local variable), not in a structure. I was trying to say that there is nothing in the C spec that says that local variables have any kind of ordering guarantee, unlike struct members. And I have never seen any kernel code that relies on the ordering of local variables to work correctly. I used to work a lot with low-level C/assembly code, and I know for a fact that GCC does not lay out stack variables in the same order that they are declared. -- Paul
[PATCH] phy: Variable "val" in function miphy_osc_is_ready() could be uninitialized
In function miphy_osc_is_ready(), local variable "val"
could be uninitalized. if function regmap_read() returns
-EINVAL. However, this value is used in if statement.
This is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/phy/st/phy-miphy28lp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/st/phy-miphy28lp.c b/drivers/phy/st/phy-miphy28lp.c
index 213e2e15339c..40c7c0a611a0 100644
--- a/drivers/phy/st/phy-miphy28lp.c
+++ b/drivers/phy/st/phy-miphy28lp.c
@@ -835,7 +835,8 @@ static int miphy_osc_is_ready(struct miphy28lp_phy
*miphy_phy)
{
struct miphy28lp_dev *miphy_dev = miphy_phy->phydev;
unsigned long finish = jiffies + 5 * HZ;
- u32 val;
+ u32 val = 0;
+ int ret;
if (!miphy_phy->osc_rdy)
return 0;
@@ -844,8 +845,10 @@ static int miphy_osc_is_ready(struct miphy28lp_phy
*miphy_phy)
return -EINVAL;
do {
- regmap_read(miphy_dev->regmap,
+ ret = regmap_read(miphy_dev->regmap,
miphy_phy->syscfg_reg[SYSCFG_STATUS], );
+ if (ret)
+ return ret;
if ((val & MIPHY_OSC_RDY) != MIPHY_OSC_RDY)
cpu_relax();
--
2.17.1
Re: [PATCH v2] exec: don't force_sigsegv processes with a pending fatal signal
On Tue, Feb 05, 2019 at 01:11:19PM -0800, Andrew Morton wrote:
> On Mon, 4 Feb 2019 18:53:08 -0800 Ivan Delalande wrote:
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -1660,7 +1660,12 @@ int search_binary_handler(struct linux_binprm *bprm)
> > if (retval < 0 && !bprm->mm) {
> > /* we got to flush_old_exec() and failed after it */
> > read_unlock(_lock);
> > - force_sigsegv(SIGSEGV, current);
> > + if (!fatal_signal_pending(current)) {
> > + if (print_fatal_signals)
> > + pr_info("load_binary() failed: %d\n",
> > + retval);
>
> Should we be using print_fatal_signal() here?
I don't think so, the force_sigsegv() already ensures it will be called
from get_signal() when the signal is handled, and so the process
information will be printed then.
> > + force_sigsegv(SIGSEGV, current);
> > + }
> > return retval;
> > }
> > if (retval != -ENOEXEC || !bprm->file) {
Thanks,
--
Ivan Delalande
Arista Networks
Re: [PATCH] powerpc/powernv/npu: Remove redundant change_pte() hook
On Tue, Feb 5, 2019 at 2:52 PM Alistair Popple wrote: > > On Thursday, 31 January 2019 12:11:06 PM AEDT Andrea Arcangeli wrote: > > On Thu, Jan 31, 2019 at 06:30:22PM +0800, Peter Xu wrote: > > > The change_pte() notifier was designed to use as a quick path to > > > update secondary MMU PTEs on write permission changes or PFN changes. > > > For KVM, it could reduce the vm-exits when vcpu faults on the pages > > > that was touched up by KSM. It's not used to do cache invalidations, > > > for example, if we see the notifier will be called before the real PTE > > > update after all (please see set_pte_at_notify that set_pte_at was > > > called later). > > Thanks for the fixup. I didn't realise that invalidate_range() always gets > called but I now see that is the case so this change looks good to me as well. > > Reviewed-by: Alistair Popple > I checked the three callers of set_pte_at_notify and the assumption seems correct Reviewed-by: Balbir Singh
Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
On Tue, 2019-02-05 at 19:27 -0700, Paul Zimmerman wrote: > On Tue, 2019-02-05, Joe Perches wrote: > > On Tue, 2019-02-05 at 12:04 -0800, Eric Dumazet wrote: > > > On 02/05/2019 10:42 AM, Joe Perches wrote: > > > > It's declared after a pointer so it is already is 2 byte aligned. > > > > > > > > A lot of drivers wouldn't work otherwise. > > > > > > Maybe these drivers are only used on arches where this does not matter. > > > > Possible. > > > > I had only grepped through the sources looking for > > declarations using: > > > > $ git grep -B1 '\[ETH_ALEN\];' -- '*.c' | grep -A1 '\*' > > > > It's quite a few files in net/ too btw. > > > > I still think adding __align() is unnecessary here unless > > it follows something like a bool or a u8. > > Um, guys, this is practically C-101. > > From C99, 6.7.2.1: > > > 13/ Within a structure object, the non-bit-field members and the units in > > which bit-fields reside have addresses that increase in the order in which > > they are declared. A pointer to a structure object, suitably converted, > > points to its initial member (or if that member is a bit-field, then to the > > unit in which it resides), and vice versa. There may be unnamed padding > > within a structure object, but not at its beginning. > > AFAIK there is no such language in the spec regarding variable layout on > the stack. So Joe, you are totally off-base here. We're not talking about the spec, see the void * arithmetic bit, we're talking about what gcc and clang actually do. This spec regarding variable layout structure members could also apply to any of the unpacked protocol headers like in include/uapi/linux/ip.h (struct iphdr for instance) So, it's not me that's off here. I do understand the c90 spec pretty well. Eric's comment about stack layout randomization certainly applies. Perhaps it's reasonable to add some __aligned() to the appropriate [ETH_ALEN] declarations.
Re: [PATCH] psi: fix aggregation idle shut-off
Hi Andrew,
On Mon, Jan 28, 2019 at 3:06 PM Andrew Morton wrote:
>
> On Wed, 16 Jan 2019 14:35:01 -0500 Johannes Weiner wrote:
>
> > psi has provisions to shut off the periodic aggregation worker when
> > there is a period of no task activity - and thus no data that needs
> > aggregating. However, while developing psi monitoring, Suren noticed
> > that the aggregation clock currently won't stay shut off for good.
> >
> > Debugging this revealed a flaw in the idle design: an aggregation run
> > will see no task activity and decide to go to sleep; shortly
> > thereafter, the kworker thread that executed the aggregation will go
> > idle and cause a scheduling change, during which the psi callback will
> > kick the !pending worker again. This will ping-pong forever, and is
> > equivalent to having no shut-off logic at all (but with more code!)
> >
> > Fix this by exempting aggregation workers from psi's clock waking
> > logic when the state change is them going to sleep. To do this, tag
> > workers with the last work function they executed, and if in psi we
> > see a worker going to sleep after aggregating psi data, we will not
> > reschedule the aggregation work item.
> >
> > What if the worker is also executing other items before or after?
> >
> > Any psi state times that were incurred by work items preceding the
> > aggregation work will have been collected from the per-cpu buckets
> > during the aggregation itself. If there are work items following the
> > aggregation work, the worker's last_func tag will be overwritten and
> > the aggregator will be kept alive to process this genuine new activity.
> >
> > If the aggregation work is the last thing the worker does, and we
> > decide to go idle, the brief period of non-idle time incurred between
> > the aggregation run and the kworker's dequeue will be stranded in the
> > per-cpu buckets until the clock is woken by later activity. But that
> > should not be a problem. The buckets can hold 4s worth of time, and
> > future activity will wake the clock with a 2s delay, giving us 2s
> > worth of data we can leave behind when disabling aggregation. If it
> > takes a worker more than two seconds to go idle after it finishes its
> > last work item, we likely have bigger problems in the system, and
> > won't notice one sample that was averaged with a bogus per-CPU weight.
> >
> > --- a/kernel/sched/psi.c
> > +++ b/kernel/sched/psi.c
> > @@ -480,9 +481,6 @@ static void psi_group_change(struct psi_group *group,
> > int cpu,
> > groupc->tasks[t]++;
> >
> > write_seqcount_end(>seq);
> > -
> > - if (!delayed_work_pending(>clock_work))
> > - schedule_delayed_work(>clock_work, PSI_FREQ);
> > }
> >
> > static struct psi_group *iterate_groups(struct task_struct *task, void
> > **iter)
>
> This breaks Suren's "psi: introduce psi monitor":
>
> --- kernel/sched/psi.c~psi-introduce-psi-monitor
> +++ kernel/sched/psi.c
> @@ -752,8 +1012,25 @@ static void psi_group_change(struct psi_
>
> write_seqcount_end(>seq);
>
> - if (!delayed_work_pending(>clock_work))
> - schedule_delayed_work(>clock_work, PSI_FREQ);
> + /*
> +* Polling flag resets to 0 at the max rate of once per update window
> +* (at least 500ms interval). smp_wmb is required after group->polling
> +* 0-to-1 transition to order groupc->times and group->polling writes
> +* because stall detection logic in the slowpath relies on
> groupc->times
> +* changing before group->polling. Explicit smp_wmb is missing because
> +* cmpxchg() implies smp_mb.
> +*/
> + if ((state_mask & group->trigger_mask) &&
> + atomic_cmpxchg(>polling, 0, 1) == 0) {
> + /*
> +* Start polling immediately even if the work is already
> +* scheduled
> +*/
> + mod_delayed_work(system_wq, >clock_work, 1);
> + } else {
> + if (!delayed_work_pending(>clock_work))
> + schedule_delayed_work(>clock_work, PSI_FREQ);
> + }
> }
>
> and I'm too lazy to go in and figure out how to fix it.
>
> If we're sure about "psi: fix aggregation idle shut-off" (and I am not)
> then can I ask for a redo of "psi: introduce psi monitor"?
I resolved the conflict with "psi: introduce psi monitor" patch and
posted v4 at
https://lore.kernel.org/lkml/20190206023446.177362-1-sur...@google.com,
however please be advised that it also includes additional cleanup
changes yet to be reviewed.
The first 4 patches in this series are already in linux-next, so this
one should apply cleanly there. Please let me know if it creates any
other issues.
Thanks,
Suren.
Re: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return
On Tue, Feb 5, 2019 at 10:24 PM Michael Ellerman wrote:
>
> Balbir Singh writes:
> > On Sat, Feb 2, 2019 at 12:14 PM Balbir Singh wrote:
> >>
> >> On Tue, Jan 22, 2019 at 10:57:21AM -0500, Joe Lawrence wrote:
> >> > From: Nicolai Stange
> >> >
> >> > The ppc64 specific implementation of the reliable stacktracer,
> >> > save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
> >> > trace" whenever it finds an exception frame on the stack. Stack frames
> >> > are classified as exception frames if the STACK_FRAME_REGS_MARKER magic,
> >> > as written by exception prologues, is found at a particular location.
> >> >
> >> > However, as observed by Joe Lawrence, it is possible in practice that
> >> > non-exception stack frames can alias with prior exception frames and
> >> > thus,
> >> > that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER on
> >> > the stack. It in turn falsely reports an unreliable stacktrace and blocks
> >> > any live patching transition to finish. Said condition lasts until the
> >> > stack frame is overwritten/initialized by function call or other means.
> >> >
> >> > In principle, we could mitigate this by making the exception frame
> >> > classification condition in save_stack_trace_tsk_reliable() stronger:
> >> > in addition to testing for STACK_FRAME_REGS_MARKER, we could also take
> >> > into
> >> > account that for all exceptions executing on the kernel stack
> >> > - their stack frames's backlink pointers always match what is saved
> >> > in their pt_regs instance's ->gpr[1] slot and that
> >> > - their exception frame size equals STACK_INT_FRAME_SIZE, a value
> >> > uncommonly large for non-exception frames.
> >> >
> >> > However, while these are currently true, relying on them would make the
> >> > reliable stacktrace implementation more sensitive towards future changes
> >> > in
> >> > the exception entry code. Note that false negatives, i.e. not detecting
> >> > exception frames, would silently break the live patching consistency
> >> > model.
> >> >
> >> > Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
> >> > rely on STACK_FRAME_REGS_MARKER as well.
> >> >
> >> > Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER
> >> > for those exceptions running on the "normal" kernel stack and returning
> >> > to kernelspace: because the topmost frame is ignored by the reliable
> >> > stack
> >> > tracer anyway, returns to userspace don't need to take care of clearing
> >> > the marker.
> >> >
> >> > Furthermore, as I don't have the ability to test this on Book 3E or
> >> > 32 bits, limit the change to Book 3S and 64 bits.
> >> >
> >> > Finally, make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on
> >> > PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended
> >> > on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies
> >> > PPC_BOOK3S_64, there's no functional change here.
> >> >
> >> > Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack
> >> > tracing for the consistency model")
> >> > Reported-by: Joe Lawrence
> >> > Signed-off-by: Nicolai Stange
> >> > Signed-off-by: Joe Lawrence
> >> > ---
> >> > arch/powerpc/Kconfig | 2 +-
> >> > arch/powerpc/kernel/entry_64.S | 7 +++
> >> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> >> > index 2890d36eb531..73bf87b1d274 100644
> >> > --- a/arch/powerpc/Kconfig
> >> > +++ b/arch/powerpc/Kconfig
> >> > @@ -220,7 +220,7 @@ config PPC
> >> > select HAVE_PERF_USER_STACK_DUMP
> >> > select HAVE_RCU_TABLE_FREE if SMP
> >> > select HAVE_REGS_AND_STACK_ACCESS_API
> >> > - select HAVE_RELIABLE_STACKTRACE if PPC64 &&
> >> > CPU_LITTLE_ENDIAN
> >> > + select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 &&
> >> > CPU_LITTLE_ENDIAN
> >> > select HAVE_SYSCALL_TRACEPOINTS
> >> > select HAVE_VIRT_CPU_ACCOUNTING
> >> > select HAVE_IRQ_TIME_ACCOUNTING
> >> > diff --git a/arch/powerpc/kernel/entry_64.S
> >> > b/arch/powerpc/kernel/entry_64.S
> >> > index 435927f549c4..a2c168b395d2 100644
> >> > --- a/arch/powerpc/kernel/entry_64.S
> >> > +++ b/arch/powerpc/kernel/entry_64.S
> >> > @@ -1002,6 +1002,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> >> > ld r2,_NIP(r1)
> >> > mtspr SPRN_SRR0,r2
> >> >
> >> > + /*
> >> > + * Leaving a stale exception_marker on the stack can confuse
> >> > + * the reliable stack unwinder later on. Clear it.
> >> > + */
> >> > + li r2,0
> >> > + std r2,STACK_FRAME_OVERHEAD-16(r1)
> >> > +
> >>
> >> Could you please double check, r4 is already 0 at this point
> >> IIUC. So the change might be a simple
> >>
> >> std r4,STACK_FRAME_OVERHEAD-16(r1)
> >>
> >
> > r4 is not 0, sorry for the noise
>
>
Isn't it?
It is, I seem to be reading the wrong bits and confused myself, had to
re-read
[PATCH v4 1/1] psi: introduce psi monitor
Psi monitor aims to provide a low-latency short-term pressure detection mechanism configurable by users. It allows users to monitor psi metrics growth and trigger events whenever a metric raises above user-defined threshold within user-defined time window. Time window and threshold are both expressed in usecs. Multiple psi resources with different thresholds and window sizes can be monitored concurrently. Psi monitors activate when system enters stall state for the monitored psi metric and deactivate upon exit from the stall state. While system is in the stall state psi signal growth is monitored at a rate of 10 times per tracking window. Min window size is 500ms, therefore the min monitoring interval is 50ms. Max window size is 10s with monitoring interval of 1s. When activated psi monitor stays active for at least the duration of one tracking window to avoid repeated activations/deactivations when psi signal is bouncing. Notifications to the users are rate-limited to one per tracking window. Signed-off-by: Suren Baghdasaryan Signed-off-by: Johannes Weiner --- This is respin of: https://lwn.net/ml/linux-kernel/20190124211518.244221-1-surenb%40google.com/ First 4 patches in the series are in linux-next: 1. fs: kernfs: add poll file operation https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6a78cef7ad8a1734477a1352dd04a97f1dc58a70 2. kernel: cgroup: add poll file operation https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c88177361203be291a49956b6c9d5ec164ea24b2 3. psi: introduce state_mask to represent stalled psi states https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=9d8a0c4a7f1c197de9c12bd53ef45fb6d273374e 4. psi: rename psi fields in preparation for psi trigger addition https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ef9bb049a4db519152a8664088f7ce34bbee5ac This patch can be cleanly applied either over linux-next tree (tag: next-20190201) or over linux-stable v5.0-rc4 after applying abovementioned 4 patches. Changes in v4: - Resolved conflict with "psi: fix aggregation idle shut-off" patch, as per Andrew Morton - Replaced smp_mb__after_atomic() with smp_mb() for proper ordering, as per Peter - Moved now=sched_clock() in psi_update_work() after mutex acquisition, as per Peter - Expanded comments to explain why smp_mb() is needed in psi_update_work, as per Peter - Fixed g->polling operation order in the diagram above psi_update_work(), as per Johannes - Merged psi_trigger_parse() into psi_trigger_create(), as per Johannes - Replaced list_del_init with list_del in psi_trigger_destroy(), as per Minchan - Replaced return value in get_recent_times and collect_percpu_times to return-by-parameter, as per Minchan - Renamed window_init into window_reset and reused it, as per Minchan - Replaced kzalloc with kmalloc, as per Minchan - Added explanation in psi.txt for min/max window size choices, as per Minchan - Misc variable name cleanups, as per Minchan and Johannes Documentation/accounting/psi.txt | 107 ++ include/linux/psi.h | 8 + include/linux/psi_types.h| 59 kernel/cgroup/cgroup.c | 95 +- kernel/sched/psi.c | 559 +-- 5 files changed, 794 insertions(+), 34 deletions(-) diff --git a/Documentation/accounting/psi.txt b/Documentation/accounting/psi.txt index b8ca28b60215..4fb40fe94828 100644 --- a/Documentation/accounting/psi.txt +++ b/Documentation/accounting/psi.txt @@ -63,6 +63,110 @@ tracked and exported as well, to allow detection of latency spikes which wouldn't necessarily make a dent in the time averages, or to average trends over custom time frames. +Monitoring for pressure thresholds +== + +Users can register triggers and use poll() to be woken up when resource +pressure exceeds certain thresholds. + +A trigger describes the maximum cumulative stall time over a specific +time window, e.g. 100ms of total stall time within any 500ms window to +generate a wakeup event. + +To register a trigger user has to open psi interface file under +/proc/pressure/ representing the resource to be monitored and write the +desired threshold and time window. The open file descriptor should be +used to wait for trigger events using select(), poll() or epoll(). +The following format is used: + + + +For example writing "some 15 100" into /proc/pressure/memory +would add 150ms threshold for partial memory stall measured within +1sec time window. Writing "full 5 100" into /proc/pressure/io +would add 50ms threshold for full io stall measured within 1sec time window. + +Triggers can be set on more than one psi metric and more than one trigger +for the same psi metric can be specified. However for each trigger a separate +file descriptor is required to be able to poll it separately from others, +therefore for each trigger a separate open()
Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
On Tue, 2019-02-05, Joe Perches wrote: > On Tue, 2019-02-05 at 12:04 -0800, Eric Dumazet wrote: >> >> On 02/05/2019 10:42 AM, Joe Perches wrote: >> > It's declared after a pointer so it is already is 2 byte aligned. >> > >> > A lot of drivers wouldn't work otherwise. >> >> Maybe these drivers are only used on arches where this does not matter. > > Possible. > > I had only grepped through the sources looking for > declarations using: > > $ git grep -B1 '\[ETH_ALEN\];' -- '*.c' | grep -A1 '\*' > > It's quite a few files in net/ too btw. > > I still think adding __align() is unnecessary here unless > it follows something like a bool or a u8. Um, guys, this is practically C-101. >From C99, 6.7.2.1: > 13/ Within a structure object, the non-bit-field members and the units in > which bit-fields reside have addresses that increase in the order in which > they are declared. A pointer to a structure object, suitably converted, > points to its initial member (or if that member is a bit-field, then to the > unit in which it resides), and vice versa. There may be unnamed padding > within a structure object, but not at its beginning. AFAIK there is no such language in the spec regarding variable layout on the stack. So Joe, you are totally off-base here. -- Paul
Re: [PATCH] checkpatch: Verify SPDX comment style
On Tue, 2019-02-05 at 14:21 -0800, Andrew Morton wrote:
> On Thu, 10 Jan 2019 16:05:11 -0800 Joe Perches wrote:
>
> > Using SPDX commenting style // or /* is specified for
> > various file types in Documentation/process/license-rules.rst
> > so add an appropriate test for .[chsS] files because many
> > proposed file additions and patches do not use the correct style.
>
> Dan's
> http://lkml.kernel.org/r/154899811738.3165233.12325692939590944259.st...@dwillia2-desk3.amr.corp.intel.com
> is giving me
>
> WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
> #500: FILE: mm/shuffle.h:1:
> +// SPDX-License-Identifier: GPL-2.0
>
> and switching it to /* */ doesn't fix. This happens with or without
> this patch applied. What to do?
Umm, fix checkpatch?
---
scripts/checkpatch.pl | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 37f81fe93c01..216480ae29d1 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3053,21 +3053,21 @@ sub process {
# check SPDX comment style for .[chsS] files
if ($realfile =~ /\.[chsS]$/ &&
$rawline =~ /SPDX-License-Identifier:/ &&
- $rawline !~ /^\+\s*\Q$comment\E\s*/) {
+ $rawline !~ m@^\+\s*\Q$comment\E\s*@) {
WARN("SPDX_LICENSE_TAG",
"Improper SPDX comment style for
'$realfile', please use '$comment' instead\n" . $herecurr);
}
if ($comment !~ /^$/ &&
- $rawline !~ /^\+\Q$comment\E
SPDX-License-Identifier: /) {
-WARN("SPDX_LICENSE_TAG",
- "Missing or malformed
SPDX-License-Identifier tag in line $checklicenseline\n" . $herecurr);
+ $rawline !~ m@^\+\Q$comment\E
SPDX-License-Identifier: @) {
+ WARN("SPDX_LICENSE_TAG",
+"Missing or malformed
SPDX-License-Identifier tag in line $checklicenseline\n" . $herecurr);
} elsif ($rawline =~ /(SPDX-License-Identifier:
.*)/) {
-my $spdx_license = $1;
-if
(!is_SPDX_License_valid($spdx_license)) {
- WARN("SPDX_LICENSE_TAG",
- "'$spdx_license' is not
supported in LICENSES/...\n" . $herecurr);
-}
+ my $spdx_license = $1;
+ if
(!is_SPDX_License_valid($spdx_license)) {
+ WARN("SPDX_LICENSE_TAG",
+"'$spdx_license' is not
supported in LICENSES/...\n" . $herecurr);
+ }
}
}
}
[PATCH] phy: rockchip-typec: Variable "val" of function rockchip_usb3_phy_power_on() could be uninitialized
In function rockchip_usb3_phy_power_on(), local variable
"val" could be uninitialized if function regmap_read()
returns -EINVAL. However, this value is directly used in
later context. This is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/phy/rockchip/phy-rockchip-typec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index a958c9bced01..b1e24418cb2d 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -716,7 +716,10 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
/* wait TCPHY for pipe ready */
for (timeout = 0; timeout < 100; timeout++) {
- regmap_read(tcphy->grf_regs, reg->offset, );
+ ret = regmap_read(tcphy->grf_regs, reg->offset, );
+ if (ret)
+ goto unlock_ret;
+
if (!(val & BIT(reg->enable_bit))) {
tcphy->mode |= new_mode & (MODE_DFP_USB | MODE_UFP_USB);
goto unlock_ret;
--
2.17.1
Re: libelf-0.175 breaks objtool
On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote: > Just a FYI. > > After a recent upgrade in debian testing, I was not able to build the > kernel. I have a custom build of gcc, so I thought it was strange that > I was getting something like this (took this from the web, as I don't > have the error anymore with the work around, and currently doing a full > build): > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for > section .debug_info > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for > section .debug_info > objdump: kernel/.tmp_signal.o: file format not recognized > > CC arch/x86/kernel/platform-quirks.o > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status > for section .debug_info > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status > for section .debug_info > objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for > section .debug_info > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for > section .debug_info > objdump: mm/.tmp_swap_slots.o: file format not recognized > I installed debian testing on a VM, which has libelf 0.175-2, but I can't recreate. Can you share your config? -- Josh
Re: [PATCH RESEND] PCI: Check for USB xHCI class for HAPS platform
On Tue, Feb 05, 2019 at 05:01:18PM -0800, John Youn wrote: > On 02/05/2019 03:32 PM, Bjorn Helgaas wrote: > > On Tue, Feb 05, 2019 at 01:04:28PM -0800, Thinh Nguyen wrote: > > > The Synopsys HAPS USB controller has a VID PID (16c3,abcd) that matches > > > to an existing PCIe controller. This quirk is intended for USB HAPS > > > devices only. To fix this, check for the PCI class USB xHCI to prevent > > > matching the PCIe controllers. > > > > So there are at least three different parts with the same Vendor & > > Device ID ([16c3:abcd]): > > > >1) Synopsys HAPS USB3 controller > >2) Synopsys PCIe IP in the NXP i.MX6QP (reported by Lukas) > >3) Synopsys PCIe IP in the NXP i.MX7D (reported by Trent) > > > > I don't know if Synopsys is to blame for 2 & 3, or if NXP was expected > > to change the Vendor ID when incorporating the Synopsys IP into the > > i.MX designs. But even leaving the default Device ID of the PCIe IP > > the same as another Synopsys device was probably a bad idea. > > Hi Bjorn, > > From talking with our PCIe folks, our best guess is a vendor > misconfiguration. The PCIe IP ships with a different PID by default > and does not collide with USB. If that's true, your vendor was very unlucky in choosing 0xabcd. They also have a pretty serious misunderstanding of how PCI IDs work, which will cause you major headaches if they continue allocating Device IDs from the Synopsys space. In this particular case it's probably not a disaster because the i.MX6QP and i.MX7D devices are both bridges (Root Ports, I think), and we don't currently have any drivers that claim those by ID. The portdrv claims them by Class Code. > > dwc3-haps claims by Vendor & Device ID; it doesn't look at the Class > > Code. What happens when it tries to claim the PCIe IP in i.MX? > > We can add the class code to dwc3-haps to account for this. I think that'd be a good idea. I think portdrv will claim the Root Port first, before dwc3-haps has a chance, so the driver core won't even call dwc3_haps_probe(). But if you unset CONFIG_PCIEPORTBUS or boot with "pcie_ports=compat", I bet dwc3-haps *will* claim it, and things will fail a little less gracefully. Bjorn
[PATCH] phy: Variable "caldone" in function rockchip_emmc_phy_power() could be uninitialized
In function rockchip_emmc_phy_power(), local variable "caldone"
could be uninitialized if function regmap_read() returns -EINVAL.
However, it will be used directly in the later context, which
is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/phy/rockchip/phy-rockchip-emmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f18e9b2..ca921ae08309 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -85,11 +85,12 @@ struct rockchip_emmc_phy {
static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
{
struct rockchip_emmc_phy *rk_phy = phy_get_drvdata(phy);
- unsigned int caldone;
+ unsigned int caldone = 0;
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
unsigned long timeout;
+ int err;
/*
* Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -164,9 +165,14 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool
on_off)
* wait 5us for calpad busy trimming
*/
udelay(5);
- regmap_read(rk_phy->reg_base,
+ err = regmap_read(rk_phy->reg_base,
rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
);
+ if (err) {
+ pr_err("Failed to read status.\n");
+ return err;
+ }
+
caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
if (caldone != PHYCTRL_CALDONE_DONE) {
pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
--
2.17.1
[PATCH v4 2/3] Input: add new vibrator driver for various MSM SOCs
This patch adds a new vibrator driver that supports various Qualcomm
MSM SOCs. Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
Changes since v3:
- Made msm_vibrator_write a function instead of a macro.
- Check for -EPROBE_DEFER for gpio and clk for consistency with the
regulator.
- Check for NULL return value from devm_ioremap() instead of using
IS_ERR()
- Don't set dev.parent
- Use platform_get_drvdata() in suspend and resume
drivers/input/misc/Kconfig| 10 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/msm-vibrator.c | 282 ++
3 files changed, 293 insertions(+)
create mode 100644 drivers/input/misc/msm-vibrator.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2be9bc5..e39aef84f357 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -117,6 +117,16 @@ config INPUT_E3X0_BUTTON
To compile this driver as a module, choose M here: the
module will be called e3x0_button.
+config INPUT_MSM_VIBRATOR
+ tristate "Qualcomm MSM vibrator driver"
+ select INPUT_FF_MEMLESS
+ help
+ Support for the vibrator that is found on various Qualcomm MSM
+ SOCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called msm_vibrator.
+
config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1ff68f..96a6419cb1f2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
obj-$(CONFIG_INPUT_MMA8450)+= mma8450.o
+obj-$(CONFIG_INPUT_MSM_VIBRATOR) += msm-vibrator.o
obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
diff --git a/drivers/input/misc/msm-vibrator.c
b/drivers/input/misc/msm-vibrator.c
new file mode 100644
index ..c06941021447
--- /dev/null
+++ b/drivers/input/misc/msm-vibrator.c
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm MSM vibrator driver
+ *
+ * Copyright (c) 2018 Brian Masney
+ *
+ * Based on qcom,pwm-vibrator.c from:
+ * Copyright (c) 2018 Jonathan Marek
+ *
+ * Based on msm_pwm_vibrator.c from downstream Android sources:
+ * Copyright (C) 2009-2014 LGE, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_CMD_RCGR 0x00
+#define REG_CFG_RCGR 0x04
+#define REG_M 0x08
+#define REG_N 0x0C
+#define REG_D 0x10
+#define REG_CBCR 0x24
+#define MMSS_CC_M_DEFAULT 1
+
+struct msm_vibrator {
+ struct input_dev *input;
+ struct mutex mutex;
+ struct work_struct worker;
+ void __iomem *base;
+ struct regulator *vcc;
+ struct clk *clk;
+ struct gpio_desc *enable_gpio;
+ u16 magnitude;
+ bool enabled;
+};
+
+static void msm_vibrator_write(struct msm_vibrator *vibrator, int offset,
+ u32 value)
+{
+ writel(value, vibrator->base + offset);
+}
+
+static int msm_vibrator_start(struct msm_vibrator *vibrator)
+{
+ int d_reg_val, ret = 0;
+
+ mutex_lock(>mutex);
+
+ if (!vibrator->enabled) {
+ ret = clk_set_rate(vibrator->clk, 24000);
+ if (ret) {
+ dev_err(>input->dev,
+ "Failed to set clock rate: %d\n", ret);
+ goto unlock;
+ }
+
+ ret = clk_prepare_enable(vibrator->clk);
+ if (ret) {
+ dev_err(>input->dev,
+ "Failed to enable clock: %d\n", ret);
+ goto unlock;
+ }
+
+ ret = regulator_enable(vibrator->vcc);
+ if (ret) {
+ dev_err(>input->dev,
+ "Failed to enable regulator: %d\n", ret);
+ clk_disable(vibrator->clk);
+ goto unlock;
+ }
+
+ gpiod_set_value_cansleep(vibrator->enable_gpio, 1);
+
+ vibrator->enabled = true;
+ }
+
+ d_reg_val = 127 - ((126 * vibrator->magnitude) / 0x);
+ msm_vibrator_write(vibrator, REG_CFG_RCGR,
+ (2 << 12) | /* dual edge mode */
+ (0 << 8) | /* cxo */
+ (7 << 0));
+ msm_vibrator_write(vibrator, REG_M, 1);
+ msm_vibrator_write(vibrator, REG_N, 128);
+
[PATCH v4 3/3] ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for vibrator
This patch adds device device tree bindings for the vibrator found on
the LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
Changes since v3:
- None
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b3b04736a159..1fd9f429f34a 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
/ {
model = "LGE MSM 8974 HAMMERHEAD";
@@ -306,6 +307,36 @@
input-enable;
};
};
+
+ vibrator_pin: vibrator {
+ pwm {
+ pins = "gpio27";
+ function = "gp1_clk";
+
+ drive-strength = <6>;
+ bias-disable;
+ };
+
+ enable {
+ pins = "gpio60";
+ function = "gpio";
+ };
+ };
+ };
+
+ vibrator@fd8c3450 {
+ compatible = "qcom,msm8974-vibrator";
+ reg = <0xfd8c3450 0x400>;
+
+ vcc-supply = <_l19>;
+
+ clocks = < CAMSS_GP1_CLK>;
+ clock-names = "pwm";
+
+ enable-gpios = < 60 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
};
sdhci@f9824900 {
--
2.17.2
Re: [PATCH v5 05/10] soc: qcom: Add AOSS QMP communication driver
On Fri 01 Feb 15:36 PST 2019, Doug Anderson wrote:
> Hi,
>
> On Wed, Jan 30, 2019 at 4:40 PM Bjorn Andersson
> wrote:
> > +++ b/drivers/soc/qcom/aoss-qmp.c
> > @@ -0,0 +1,317 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018, Linaro Ltd
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define QMP_DESC_MAGIC 0x0
> > +#define QMP_DESC_VERSION 0x4
> > +#define QMP_DESC_FEATURES 0x8
> > +
> > +#define QMP_DESC_UCORE_LINK_STATE 0xc
> > +#define QMP_DESC_UCORE_LINK_STATE_ACK 0x10
> > +#define QMP_DESC_UCORE_CH_STATE0x14
> > +#define QMP_DESC_UCORE_CH_STATE_ACK0x18
> > +#define QMP_DESC_UCORE_MBOX_SIZE 0x1c
> > +#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
> > +
> > +#define QMP_DESC_MCORE_LINK_STATE 0x24
> > +#define QMP_DESC_MCORE_LINK_STATE_ACK 0x28
> > +#define QMP_DESC_MCORE_CH_STATE0x2c
> > +#define QMP_DESC_MCORE_CH_STATE_ACK0x30
> > +#define QMP_DESC_MCORE_MBOX_SIZE 0x34
> > +#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
>
> I sure wish something in this file told me what a mcore and a ucore
> were. The only thing I can think of is that an "m" core is two "u"
> cores flipped upside down and placed really close to each other.
> ...if we had 6 upside down "u" cores we'd have an "mmm" core. Mmm,
> core.
>
I had to look at the code again to figure out which side was which, so
I'll add a comment here to indicate which is which.
>
> > +static int qmp_open(struct qmp *qmp)
> > +{
> > + int ret;
> > + u32 val;
> > +
> > + ret = wait_event_timeout(qmp->event, qmp_magic_valid(qmp), HZ);
>
> I'm a totally noob here, but I'm curious: what kicks this event? Do
> we just assume that an IRQ is pending already when the probe()
> function is called? Maybe you could add a comment?
>
> ...or maybe you never actually get an IRQ here and just rely on the
> magic value being right at boot in which case we should just check
> qmp_magic_valid()
>
> ...or maybe you never actually get an IRQ here and this is equivalent
> to msleep(1000) followed by a check of qmp_magic_valid()?
>
This must be me misinterpreting the downstream driver, the magic is
already in place when we enter here.
>
> > + if (!ret) {
> > + dev_err(qmp->dev, "QMP magic doesn't match\n");
> > + return -ETIMEDOUT;
> > + }
> > +
> > + val = readl(qmp->msgram + QMP_DESC_VERSION);
> > + if (val != QMP_VERSION) {
> > + dev_err(qmp->dev, "unsupported QMP version %d\n", val);
> > + return -EINVAL;
> > + }
> > +
> > + qmp->offset = readl(qmp->msgram + QMP_DESC_MCORE_MBOX_OFFSET);
> > + qmp->size = readl(qmp->msgram + QMP_DESC_MCORE_MBOX_SIZE);
> > + if (!qmp->size) {
> > + dev_err(qmp->dev, "invalid mailbox size 0x%zx\n",
> > qmp->size);
>
> nitty nit: Can you do "%#zx" to avoid the need for the 0x?
>
Didn't know I could do that, but that said this is conditional on
!qmp->size, so I'm dropping the 0x0 from the error...
>
> > + return -EINVAL;
> > + }
> > +
> > + /* Ack remote core's link state */
> > + val = readl(qmp->msgram + QMP_DESC_UCORE_LINK_STATE);
> > + writel(val, qmp->msgram + QMP_DESC_UCORE_LINK_STATE_ACK);
> > +
> > + /* Set local core's link state to up */
> > + writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_MCORE_LINK_STATE);
> > +
> > + qmp_kick(qmp);
> > +
> > + ret = wait_event_timeout(qmp->event, qmp_link_acked(qmp), HZ);
> > + if (!ret) {
> > + dev_err(qmp->dev, "ucore didn't ack link\n");
> > + goto timeout_close_link;
> > + }
> > +
> > + writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_MCORE_CH_STATE);
> > +
> > + ret = wait_event_timeout(qmp->event, qmp_ucore_channel_up(qmp), HZ);
>
> Again maybe a noob question, but what kicks the interrupt here? Is
> the other side looping waiting to see us write "QMP_STATE_UP" into
> "QMP_DESC_MCORE_CH_STATE" and then it sends us another interrupt?
> ...or are we just getting lucky that the condition is right to begin
> with?
>
I guess it does, but I think there is a kick inbetween here in the
downstream driver, I'll add one for good measure.
>
> > + if (!ret) {
> > + dev_err(qmp->dev, "ucore didn't open channel\n");
> > + goto timeout_close_channel;
> > + }
> > +
> > + /* Ack remote core's channel state */
> > + val = readl(qmp->msgram + QMP_DESC_UCORE_CH_STATE);
> > + writel(val, qmp->msgram + QMP_DESC_UCORE_CH_STATE_ACK);
>
> nit: the readl() is silly here. Just before this you called
> qmp_ucore_channel_up() and that confirmed that the value you're
> getting here is exactly equal to "QMP_STATE_UP". Just write that.
>
Right
>
> > +static int qmp_probe(struct platform_device *pdev)
> > +{
>
[PATCH v4 0/3] ARM: qcom: add vibrator support for various MSM SOCs
This patch set adds support for the vibrator found on various Qualcomm MSM SOCs. This is based on work from: Jonathan Marek from qcom,pwm-vibrator.c in the PostmarketOS repo: https://gitlab.com/postmarketOS/linux-postmarketos/commit/7647fb36cb1cbd060f8b52087a68ab93583292b5 Jongrak Kwon and Devin Kim from msm_pwm_vibrator.c in the downstream Android 3.4.0 sources: https://android.googlesource.com/kernel/msm/+/android-msm-lenok-3.10-lollipop-wear-release/drivers/misc/msm_pwm_vibrator.c Driver was tested on a LG Nexus 5 (hammerhead) phone using rumble-test: https://git.collabora.com/cgit/user/sre/rumble-test.git/plain/rumble-test.c Changes since v3 - Patch 2 is the only one that changed based on feedback from Dmitry Torokhov. See notes on that patch for details. Changes since v2 - Moved from pwm to input subsystem based on feedback from https://lore.kernel.org/lkml/20181012114749.GC31561@ulmo/. I previously wired this into the input system via pwm-vibra. Changes since v1 - Update device tree binding document based on feedback from Rob Herring. - Changed the driver description to: Qualcomm PWM driver for the MSM vibrator. Brian Masney (3): dt-bindings: Input: new bindings for MSM vibrator Input: add new vibrator driver for various MSM SOCs ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for vibrator .../bindings/input/msm-vibrator.txt | 36 +++ .../qcom-msm8974-lge-nexus5-hammerhead.dts| 31 ++ drivers/input/misc/Kconfig| 10 + drivers/input/misc/Makefile | 1 + drivers/input/misc/msm-vibrator.c | 282 ++ 5 files changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/msm-vibrator.txt create mode 100644 drivers/input/misc/msm-vibrator.c -- 2.17.2
[PATCH v4 1/3] dt-bindings: Input: new bindings for MSM vibrator
This patch adds the device tree bindings for the vibrator found on
various Qualcomm MSM SOCs.
Signed-off-by: Brian Masney
Reviewed-by: Rob Herring
---
Changes since v3:
- None
.../bindings/input/msm-vibrator.txt | 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/msm-vibrator.txt
diff --git a/Documentation/devicetree/bindings/input/msm-vibrator.txt
b/Documentation/devicetree/bindings/input/msm-vibrator.txt
new file mode 100644
index ..8dcf014ef2e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/msm-vibrator.txt
@@ -0,0 +1,36 @@
+* Device tree bindings for the Qualcomm MSM vibrator
+
+Required properties:
+
+ - compatible: Should be one of
+ "qcom,msm8226-vibrator"
+ "qcom,msm8974-vibrator"
+ - reg: the base address and length of the IO memory for the registers.
+ - pinctrl-names: set to default.
+ - pinctrl-0: phandles pointing to pin configuration nodes. See
+ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+ - clock-names: set to pwm
+ - clocks: phandle of the clock. See
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+ - enable-gpios: GPIO that enables the vibrator.
+
+Optional properties:
+
+ - vcc-supply: phandle to the regulator that provides power to the sensor.
+
+Example from a LG Nexus 5 (hammerhead) phone:
+
+vibrator@fd8c3450 {
+ reg = <0xfd8c3450 0x400>;
+ compatible = "qcom,msm8974-vibrator";
+
+ vcc-supply = <_l19>;
+
+ clocks = < CAMSS_GP1_CLK>;
+ clock-names = "pwm";
+
+ enable-gpios = < 60 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+};
--
2.17.2
Re: [REGRESSION 4.20-rc1] 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")
> OK, thanks. This looks slightly different from the Loongson problem: > > - In Loongson, we don't get stuck in RCU, but in > cpufreq_dbs_governor_stop -> irq_work_sync(). > > - I run non-preemptible kernel, and my system still gets stuck. > > What is common is that it's UP with i8259 PIC. > > A. Now it's an interesting case. Because on my machine, the problem I encountered seems to be the identical one of the original thread, disabling preempting can effectively solve the lockup. Also, my issue is not only occuring on 4.20-rc1, but also on earlier kernels, with a lower probability. But on your machine, you have another non-identical, but closely- related issue. It seems the timing-dependent lockup of i8259 PIC can be triggered in different ways. The conclusion is clear though, there's a real lockup condition in i8259 PIC driver, and it's causing real issues. Aaro, have you tried submitting your i8259 patch to the mainline? Despite your concerns about its underlying cause, I think a fix should be submitted. If there are no objections from the maintainers, I suggest submitting it to the mainline upstream, and send it to linux-stable, requesting it to be applied on 3.16, 4.4, 4.9, 4.14, 4.19, 4.20 stable branches. If you are busy, I can help submitting. Tom Li
Re: linux-next: tracebacks in workqueue.c/__flush_work()
Tetsuo Handa writes:
> (Adding Chris Metcalf and Rusty Russell.)
>
> If NR_CPUS == 1 due to CONFIG_SMP=n, for_each_cpu(cpu, _work) loop does
> not
> evaluate "struct cpumask has_work" modified by cpumask_set_cpu(cpu,
> _work) at
> previous for_each_online_cpu() loop. Guenter Roeck found a problem among three
> commits listed below.
>
> Commit 5fbc461636c32efd ("mm: make lru_add_drain_all() selective")
> expects that has_work is evaluated by for_each_cpu().
>
> Commit 2d3854a37e8b767a ("cpumask: introduce new API, without changing
> anything")
> assumes that for_each_cpu() does not need to evaluate has_work.
>
> Commit 4d43d395fed12463 ("workqueue: Try to catch flush_work() without
> INIT_WORK().")
> expects that has_work is evaluated by for_each_cpu().
>
> What should we do? Do we explicitly evaluate has_mask if NR_CPUS == 1 ?
No, fix the API to be least-surprise. Fix 2d3854a37e8b767a too.
Doing anything else would be horrible, IMHO.
Cheers,
Rusty.
Re: [PATCH v1] binderfs: remove separate device_initcall()
On Wed, Jan 30, 2019 at 4:25 PM Christian Brauner wrote:
>
> binderfs should not have a separate device_initcall(). When a kernel is
> compiled with CONFIG_ANDROID_BINDERFS register the filesystem alongside
> CONFIG_ANDROID_IPC. This use-case is especially sensible when users specify
> CONFIG_ANDROID_IPC=y, CONFIG_ANDROID_BINDERFS=y and
> ANDROID_BINDER_DEVICES="".
> When CONFIG_ANDROID_BINDERFS=n then this always succeeds so there's no
> regression potential for legacy workloads.
>
> Signed-off-by: Christian Brauner
Acked-by: Todd Kjos
>
> ---
> /* Changelog */
> - ensure that device_name is set to NULL so kfree() doesn't freak out
> ---
> drivers/android/binder.c | 7 ++-
> drivers/android/binder_internal.h | 9 +
> drivers/android/binderfs.c| 4 +---
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 57cf259de600..4d2b2ad1ee0e 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -5854,9 +5854,10 @@ static int __init init_binder_device(const char *name)
> static int __init binder_init(void)
> {
> int ret;
> - char *device_name, *device_names, *device_tmp;
> + char *device_name, *device_tmp;
> struct binder_device *device;
> struct hlist_node *tmp;
> + char *device_names = NULL;
>
> ret = binder_alloc_shrinker_init();
> if (ret)
> @@ -5917,6 +5918,10 @@ static int __init binder_init(void)
> }
> }
>
> + ret = init_binderfs();
> + if (ret)
> + goto err_init_binder_device_failed;
> +
> return ret;
>
> err_init_binder_device_failed:
> diff --git a/drivers/android/binder_internal.h
> b/drivers/android/binder_internal.h
> index 7fb97f503ef2..045b3e42d98b 100644
> --- a/drivers/android/binder_internal.h
> +++ b/drivers/android/binder_internal.h
> @@ -46,4 +46,13 @@ static inline bool is_binderfs_device(const struct inode
> *inode)
> }
> #endif
>
> +#ifdef CONFIG_ANDROID_BINDERFS
> +extern int __init init_binderfs(void);
> +#else
> +static inline int __init init_binderfs(void)
> +{
> + return 0;
> +}
> +#endif
> +
> #endif /* _LINUX_BINDER_INTERNAL_H */
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 7a550104a722..e773f45d19d9 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -550,7 +550,7 @@ static struct file_system_type binder_fs_type = {
> .fs_flags = FS_USERNS_MOUNT,
> };
>
> -static int __init init_binderfs(void)
> +int __init init_binderfs(void)
> {
> int ret;
>
> @@ -568,5 +568,3 @@ static int __init init_binderfs(void)
>
> return ret;
> }
> -
> -device_initcall(init_binderfs);
> --
> 2.20.1
>
Re: [PATCH RESEND] PCI: Check for USB xHCI class for HAPS platform
On 02/05/2019 03:32 PM, Bjorn Helgaas wrote: [+cc Richard, Lucas] On Tue, Feb 05, 2019 at 01:04:28PM -0800, Thinh Nguyen wrote: The Synopsys HAPS USB controller has a VID PID (16c3,abcd) that matches to an existing PCIe controller. This quirk is intended for USB HAPS devices only. To fix this, check for the PCI class USB xHCI to prevent matching the PCIe controllers. So there are at least three different parts with the same Vendor & Device ID ([16c3:abcd]): 1) Synopsys HAPS USB3 controller 2) Synopsys PCIe IP in the NXP i.MX6QP (reported by Lukas) 3) Synopsys PCIe IP in the NXP i.MX7D (reported by Trent) I don't know if Synopsys is to blame for 2 & 3, or if NXP was expected to change the Vendor ID when incorporating the Synopsys IP into the i.MX designs. But even leaving the default Device ID of the PCIe IP the same as another Synopsys device was probably a bad idea. Hi Bjorn, From talking with our PCIe folks, our best guess is a vendor misconfiguration. The PCIe IP ships with a different PID by default and does not collide with USB. dwc3-haps claims by Vendor & Device ID; it doesn't look at the Class Code. What happens when it tries to claim the PCIe IP in i.MX? We can add the class code to dwc3-haps to account for this. John
RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
> From: Dan Williams > Sent: Tuesday, February 5, 2019 9:12 AM > On Tue, Feb 5, 2019 at 8:53 AM Dexuan Cui wrote: > > > > > From: Dan Williams > > > Sent: Sunday, February 3, 2019 11:14 AM > > > > ... > > > > As I understand, the essence of the issue is: Hyper-V emulates the > > > > label mechanism (i.e. it supports _LSI and LSR), but doesn't do it > > > > right (i.e. it doesn't support _LSW). > > > > > > > > To manage the namespaces, Linux can choose to use label or not. > > > > > > > > If _LSI/_LSR are supported, Linux assumes _LSW is supported as well > > > > and chooses to use label (i.e. the label mode), but since Hyper-V > > > > doesn't > > > > support _LSW, Linux fails to change the namespace configuration. > > > > > > No, that's not quite right. The reason Linux does not see the fsdax > > > mode configuration is due to the missing "address abstraction GUID" in > > > the label produced the default Hyper-V configuration. > > Hi Dan, > > Do you mean NVDIMM_DAX_GUID? > > Correct. FYI: in create_namespace_pmem(), label0->abstraction_guid is guid_null in the case of Hyper-V NVDIMM. It looks Hyper-V does't use the guid. > > > In label-less mode there is no "address abstraction GUID" to validate so > > > it falls back to just using the info-block directly. > > In the case of not using label storage area, as I understand the info-block > > resides in regular data storage area. Can you please tell me where exactly > > the info-block is and how its location is decided? > > And I suppose the info-block contains the NVDIMM_DAX_GUID? > > The info-block always lives in the data-storage area, even with > labels. It's placed at namespace base address + 4K. > > When labels are present the label gives the namespace a uuid and the > info-block "parent uuid" field must match that value. Without labels > the "parent uuid" field is unused / filled with zero's. Also with v1.2 > labels the address abstraction uuid must match the info-block type. Thanks for elaborating on this! It looks the label mechanism is for advanced usages, e.g., a PMEM namespace can consist of multiple NVDIMMs, or a namespace only uses part of the capacity of a NVDIMM, or a NVDIMM contains both PMEM and Block-Mode namespaces. For a simple usage, e.g. if a NVDIMM only contains one PMEM namespace which consumes all the storage space of the NVDIMM, it looks the namespace can be normally used with the help of the info-block, and we don't really need the label. IMO this is the case of Hyper-V, i.e. we don't use the label at all, since _LSW is not implemented. > > I'm asking because I found I lose ~500MBytes of the 32GBytes Hyper-V > > NVDIMM device, when the namespace is in fsdax mode. When it's in > > raw mode, I'm able to use all of the 32GB space. > > Yes. A portion of the capacity is reserved for page structures. Got it. It looks the size of the info-block (and the related padding?) is 2MB, and "the overhead is 64-bytes per 4K (16GB per 1TB) on x86", so the total overhead in my 32GB case is: 2MB + 32GB/(4096/64) = 514MB. Thanks for sharing the link! Now I realized we can use the -M parameter to not store the page metadata in the NVDIMM: -M; --map= A pmem namespace in “fsdax” or “devdax” mode requires allocation of per-page metadata. The allocation can be drawn from either: “mem”: typical system memory “dev”: persistent memory reserved from the namespace Thanks, --Dexuan
Re: [PATCH v3 2/3] Input: add new vibrator driver for various MSM SOCs
On Tue, Feb 05, 2019 at 11:42:46AM -0800, Dmitry Torokhov wrote:
> > + dev_err(>dev, "Failed to lookup pwm clock: %ld\n",
> > + PTR_ERR(vibrator->clk));
> > + return PTR_ERR(vibrator->clk);
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res) {
> > + dev_err(>dev, "Failed to get platform resource\n");
> > + return -ENODEV;
> > + }
> > +
> > + vibrator->base = devm_ioremap(>dev, res->start,
> > +resource_size(res));
> > + if (IS_ERR(vibrator->base)) {
>
> devm_ioremap() returns NULL on error. You either need to check for NULL
> or see of you can use devm_ioremap_resource().
I originally tried to use devm_ioremap_resource() but the call to
devm_request_mem_region() would fail. I'll go with the NULL check here
for devm_ioremap().
Thanks for the review!
Brian
Re: [PATCH 4/7] thermal: mediatek: add thermal controller offset
On Fri, Feb 01, 2019 at 03:38:10PM +0800, michael@mediatek.com wrote:
> From: Michael Kao
>
> One thermal controller can read four sensors at most,
> so we need to add controller_offset for the project with
> more than four sensors to reuse the same register settings.
>
> Signed-off-by: Michael Kao
> ---
> drivers/thermal/mtk_thermal.c | 79
> +--
> 1 file changed, 54 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 45c6587..e5cf3f4 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -105,6 +105,9 @@
> /* The number of sensing points per bank */
> #define MT8173_NUM_SENSORS_PER_ZONE 4
>
> +/* The number of controller in the MT8173 */
> +#define MT8173_NUM_CONTROLLER1
> +
> /* The calibration coefficient of sensor */
> #define MT8173_CALIBRATION 165
>
> @@ -150,6 +153,9 @@ enum {
> /* The number of sensing points per bank */
> #define MT2701_NUM_SENSORS_PER_ZONE 3
>
> +/* The number of controller in the MT2701 */
> +#define MT2701_NUM_CONTROLLER1
> +
> /* The calibration coefficient of sensor */
> #define MT2701_CALIBRATION 165
>
> @@ -168,6 +174,9 @@ enum {
> /* The number of sensing points per bank */
> #define MT2712_NUM_SENSORS_PER_ZONE 4
>
> +/* The number of controller in the MT2712 */
> +#define MT2712_NUM_CONTROLLER1
> +
> /* The calibration coefficient of sensor */
> #define MT2712_CALIBRATION 165
>
> @@ -176,6 +185,7 @@ enum {
> #define MT7622_NUM_ZONES 1
> #define MT7622_NUM_SENSORS_PER_ZONE 1
> #define MT7622_TS1 0
> +#define MT7622_NUM_CONTROLLER1
>
> /* The calibration coefficient of sensor */
> #define MT7622_CALIBRATION 165
> @@ -201,6 +211,8 @@ struct mtk_thermal_data {
> const int *msr;
> const int *adcpnp;
> const int cali_val;
> + const int num_controller;
> + const int *controller_offset;
> struct thermal_bank_cfg bank_data[];
> };
>
> @@ -240,6 +252,7 @@ struct mtk_thermal {
> };
>
> static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
> +static const int mt8173_tc_offset[MT8173_NUM_CONTROLLER] = { 0x0, };
>
> static const int mt8173_vts_index[MT8173_NUM_SENSORS] = {
> VTS1, VTS2, VTS3, VTS4, VTSABB
> @@ -259,6 +272,7 @@ struct mtk_thermal {
> };
>
> static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
> +static const int mt2701_tc_offset[MT2701_NUM_CONTROLLER] = { 0x0, };
>
> static const int mt2701_vts_index[MT2701_NUM_SENSORS] = {
> VTS1, VTS2, VTS3
> @@ -278,6 +292,7 @@ struct mtk_thermal {
> };
>
> static const int mt2712_mux_values[MT2712_NUM_SENSORS] = { 0, 1, 2, 3 };
> +static const int mt2712_tc_offset[MT2712_NUM_CONTROLLER] = { 0x0, };
>
> static const int mt2712_vts_index[MT2712_NUM_SENSORS] = {
> VTS1, VTS2, VTS3, VTS4
> @@ -289,6 +304,7 @@ struct mtk_thermal {
> static const int mt7622_adcpnp[MT7622_NUM_SENSORS_PER_ZONE] = {
> TEMP_ADCPNP0, };
> static const int mt7622_mux_values[MT7622_NUM_SENSORS] = { 0, };
> static const int mt7622_vts_index[MT7622_NUM_SENSORS] = { VTS1 };
> +static const int mt7622_tc_offset[MT7622_NUM_CONTROLLER] = { 0x0, };
>
> /**
> * The MT8173 thermal controller has four banks. Each bank can read up to
> @@ -309,6 +325,8 @@ struct mtk_thermal {
> .num_sensors = MT8173_NUM_SENSORS,
> .vts_index = mt8173_vts_index,
> .cali_val = MT8173_CALIBRATION,
> + .num_controller = MT8173_NUM_CONTROLLER,
> + .controller_offset = mt8173_tc_offset,
> .bank_data = {
> {
> .num_sensors = 2,
> @@ -345,6 +363,8 @@ struct mtk_thermal {
> .num_sensors = MT2701_NUM_SENSORS,
> .vts_index = mt2701_vts_index,
> .cali_val = MT2701_CALIBRATION,
> + .num_controller = MT2701_NUM_CONTROLLER,
> + .controller_offset = mt2701_tc_offset,
> .bank_data = {
> {
> .num_sensors = 3,
> @@ -372,6 +392,8 @@ struct mtk_thermal {
> .num_sensors = MT2712_NUM_SENSORS,
> .vts_index = mt2712_vts_index,
> .cali_val = MT2712_CALIBRATION,
> + .num_controller = MT2712_NUM_CONTROLLER,
> + .controller_offset = mt2712_tc_offset,
> .bank_data = {
> {
> .num_sensors = 4,
> @@ -393,6 +415,8 @@ struct mtk_thermal {
> .num_sensors = MT7622_NUM_SENSORS,
> .vts_index = mt7622_vts_index,
> .cali_val = MT7622_CALIBRATION,
> + .num_controller = MT7622_NUM_CONTROLLER,
> + .controller_offset = mt7622_tc_offset,
> .bank_data = {
> {
> .num_sensors = 1,
> @@ -523,19 +547,23 @@ static int mtk_read_temp(void *data, int *temperature)
> };
>
> static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
> - u32
Re: compile error at sun6i_video
Hi Sakari Cc Niklas Thank you for your feedback > > /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c: > > In function 'sun6i_video_start_streaming': > > /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:141:29: > > error: passing argument 1 of 'media_pipeline_start' from incompatible > > pointer type [-Werror=incompatible-pointer-types] > > ret = media_pipeline_start(>vdev.entity, >vdev.pipe); > > ^~~ (snip) > Do you have the patches Niklas's v4l2/mux (or my vc) branch in your tree? > They change a few things on the way and drivers need to be converted. > Drivers that have been added since the patches were written do need to be > converted as well, and I suppose the sun6i_video driver is one of them. I could find your branch at LinuxTV, and merged vc branch, but unfortunately it can't solve compile issue. I could understand its background. It is OK for me if it will be solved on the next version. I will skip it so far. Thank you for your help Best regards --- Kuninori Morimoto
Re: [PATCH 3/7] thermal: mediatek: add calibration item
On Mon, Feb 04, 2019 at 06:31:41PM +0100, Matthias Brugger wrote:
>
>
> On 01/02/2019 08:38, michael@mediatek.com wrote:
> > From: Michael Kao
> >
> > Add calibration item in thermal_data to support
> > the project with different calibration coefficient.
> >
> > Signed-off-by: Michael Kao
> > ---
> > drivers/thermal/mtk_thermal.c | 19 ++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> > index 07f8ad7..45c6587 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -105,6 +105,9 @@
> > /* The number of sensing points per bank */
> > #define MT8173_NUM_SENSORS_PER_ZONE4
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT8173_CALIBRATION 165
> > +
>
> Calibration value is the same for all SoCs (including mt8183), we can define
> it
> once and use it in all mtk_thermal structs.
Well, on patch 7 we have:
+#define MT8183_CALIBRATION 153
>
> Regards,
> Matthias
>
>
> > /*
> > * Layout of the fuses providing the calibration data
> > * These macros could be used for MT8173, MT2701, and MT2712.
> > @@ -147,6 +150,9 @@ enum {
> > /* The number of sensing points per bank */
> > #define MT2701_NUM_SENSORS_PER_ZONE3
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT2701_CALIBRATION 165
> > +
> > /* MT2712 thermal sensors */
> > #define MT2712_TS1 0
> > #define MT2712_TS2 1
> > @@ -162,12 +168,18 @@ enum {
> > /* The number of sensing points per bank */
> > #define MT2712_NUM_SENSORS_PER_ZONE4
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT2712_CALIBRATION 165
> > +
> > #define MT7622_TEMP_AUXADC_CHANNEL 11
> > #define MT7622_NUM_SENSORS 1
> > #define MT7622_NUM_ZONES 1
> > #define MT7622_NUM_SENSORS_PER_ZONE1
> > #define MT7622_TS1 0
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT7622_CALIBRATION 165
> > +
> > struct mtk_thermal;
> >
> > struct thermal_bank_cfg {
> > @@ -188,6 +200,7 @@ struct mtk_thermal_data {
> > const int *sensor_mux_values;
> > const int *msr;
> > const int *adcpnp;
> > + const int cali_val;
> > struct thermal_bank_cfg bank_data[];
> > };
> >
> > @@ -295,6 +308,7 @@ struct mtk_thermal {
> > .num_banks = MT8173_NUM_ZONES,
> > .num_sensors = MT8173_NUM_SENSORS,
> > .vts_index = mt8173_vts_index,
> > + .cali_val = MT8173_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 2,
> > @@ -330,6 +344,7 @@ struct mtk_thermal {
> > .num_banks = 1,
> > .num_sensors = MT2701_NUM_SENSORS,
> > .vts_index = mt2701_vts_index,
> > + .cali_val = MT2701_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 3,
> > @@ -356,6 +371,7 @@ struct mtk_thermal {
> > .num_banks = 1,
> > .num_sensors = MT2712_NUM_SENSORS,
> > .vts_index = mt2712_vts_index,
> > + .cali_val = MT2712_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 4,
> > @@ -376,6 +392,7 @@ struct mtk_thermal {
> > .num_banks = MT7622_NUM_ZONES,
> > .num_sensors = MT7622_NUM_SENSORS,
> > .vts_index = mt7622_vts_index,
> > + .cali_val = MT7622_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 1,
> > @@ -402,7 +419,7 @@ static int raw_to_mcelsius(struct mtk_thermal *mt, int
> > sensno, s32 raw)
> > raw &= 0xfff;
> >
> > tmp = 203450520 << 3;
> > - tmp /= 165 + mt->o_slope;
> > + tmp /= mt->conf->cali_val + mt->o_slope;
> > tmp /= 1 + mt->adc_ge;
> > tmp *= raw - mt->vts[sensno] - 3350;
> > tmp >>= 3;
> >
Re: [PATCH] Input: gpio-keys - Add shutdown callback
On Tue, Feb 05, 2019 at 02:02:49PM -0800, Florian Fainelli wrote: > On 2/1/19 11:24 AM, Florian Fainelli wrote: > > On some platforms (e.g.: ARCH_BRCMSTB) it is possible to enter > > "poweroff" while leaving some wake-up sources enabled such as key > > presses in order to allow for the system to wake-up. > > > > Wire up a .shutdown() callback which calls into the existing > > gpio_keys_suspend() since the logic is essentially the same. > > > > Signed-off-by: Florian Fainelli > > --- > > drivers/input/keyboard/gpio_keys.c | 10 ++ > > 1 file changed, 10 insertions(+) > > Any feedback on this? OK, I'll take it. Hopefully it won't affect existing systems as the change is unconditional. Thanks. -- Dmitry
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_pci.c
between commit:
fcd70cd36b9b ("drm: Split out drm_probe_helper.h")
from the drm tree and commit:
5f5c139d6900 ("drm/i915: Allocate active tracking nodes from a slabcache")
from the drm-intel 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.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/i915_pci.c
index 5d05572c9ff4,36fa6f1905fc..
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@@ -26,8 -26,7 +26,9 @@@
#include
#include
+#include
+
+ #include "i915_active.h"
#include "i915_drv.h"
#include "i915_selftest.h"
pgp6pa0xjnJb2.pgp
Description: OpenPGP digital signature
[PATCH 03/32] timens: Introduce CLOCK_MONOTONIC offsets
From: Andrei Vagin
Add monotonic time virtualisation for time namespace.
Introduce timespec for monotionic clock into timens offsets and wire
clock_gettime() syscall.
Signed-off-by: Andrei Vagin
Co-developed-by: Dmitry Safonov
Signed-off-by: Dmitry Safonov
---
include/linux/time_namespace.h | 11 ++
include/linux/timens_offsets.h | 1 +
kernel/time/posix-timers.c | 10 +
kernel/time/posix-timers.h | 1 +
kernel/time_namespace.c| 38 ++
5 files changed, 61 insertions(+)
diff --git a/include/linux/time_namespace.h b/include/linux/time_namespace.h
index b6985aa87479..f1807d7f524d 100644
--- a/include/linux/time_namespace.h
+++ b/include/linux/time_namespace.h
@@ -41,6 +41,9 @@ static inline void put_time_ns(struct time_namespace *ns)
}
+extern void timens_clock_to_host(int clockid, struct timespec64 *val);
+extern void timens_clock_from_host(int clockid, struct timespec64 *val);
+
#else
static inline struct time_namespace *get_time_ns(struct time_namespace *ns)
{
@@ -65,6 +68,14 @@ static inline int timens_on_fork(struct nsproxy *nsproxy,
struct task_struct *ts
return 0;
}
+static inline void timens_clock_to_host(int clockid, struct timespec64 *val)
+{
+}
+
+static inline void timens_clock_from_host(int clockid, struct timespec64 *val)
+{
+}
+
#endif
#endif /* _LINUX_TIMENS_H */
diff --git a/include/linux/timens_offsets.h b/include/linux/timens_offsets.h
index 7d7cb68ea778..248b0c0bb92a 100644
--- a/include/linux/timens_offsets.h
+++ b/include/linux/timens_offsets.h
@@ -3,6 +3,7 @@
#define _LINUX_TIME_OFFSETS_H
struct timens_offsets {
+ struct timespec64 monotonic_time_offset;
};
#endif
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 0e84bb72a3da..b6d5145858a3 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "timekeeping.h"
#include "posix-timers.h"
@@ -1041,6 +1042,9 @@ SYSCALL_DEFINE2(clock_gettime, const clockid_t,
which_clock,
error = kc->clock_get(which_clock, _tp);
+ if (!error && kc->clock_timens_adjust)
+ timens_clock_from_host(which_clock, _tp);
+
if (!error && put_timespec64(_tp, tp))
error = -EFAULT;
@@ -1117,6 +1121,9 @@ COMPAT_SYSCALL_DEFINE2(clock_gettime, clockid_t,
which_clock,
err = kc->clock_get(which_clock, );
+ if (!err && kc->clock_timens_adjust)
+ timens_clock_from_host(which_clock, );
+
if (!err && put_old_timespec32(, tp))
err = -EFAULT;
@@ -1259,6 +1266,7 @@ static const struct k_clock clock_realtime = {
static const struct k_clock clock_monotonic = {
.clock_getres = posix_get_hrtimer_res,
.clock_get = posix_ktime_get_ts,
+ .clock_timens_adjust= true,
.nsleep = common_nsleep,
.timer_create = common_timer_create,
.timer_set = common_timer_set,
@@ -1274,6 +1282,7 @@ static const struct k_clock clock_monotonic = {
static const struct k_clock clock_monotonic_raw = {
.clock_getres = posix_get_hrtimer_res,
.clock_get = posix_get_monotonic_raw,
+ .clock_timens_adjust= true,
};
static const struct k_clock clock_realtime_coarse = {
@@ -1284,6 +1293,7 @@ static const struct k_clock clock_realtime_coarse = {
static const struct k_clock clock_monotonic_coarse = {
.clock_getres = posix_get_coarse_res,
.clock_get = posix_get_monotonic_coarse,
+ .clock_timens_adjust= true,
};
static const struct k_clock clock_tai = {
diff --git a/kernel/time/posix-timers.h b/kernel/time/posix-timers.h
index ddb21145211a..1cf306bde639 100644
--- a/kernel/time/posix-timers.h
+++ b/kernel/time/posix-timers.h
@@ -24,6 +24,7 @@ struct k_clock {
int (*timer_try_to_cancel)(struct k_itimer *timr);
void(*timer_arm)(struct k_itimer *timr, ktime_t expires,
bool absolute, bool sigev_none);
+ boolclock_timens_adjust;
};
extern const struct k_clock clock_posix_cpu;
diff --git a/kernel/time_namespace.c b/kernel/time_namespace.c
index 4828447721ec..57694be9e9db 100644
--- a/kernel/time_namespace.c
+++ b/kernel/time_namespace.c
@@ -191,6 +191,44 @@ static struct user_namespace *timens_owner(struct
ns_common *ns)
return to_time_ns(ns)->user_ns;
}
+static void clock_timens_fixup(int clockid, struct timespec64 *val, bool to_ns)
+{
+ struct timens_offsets *ns_offsets = current->nsproxy->time_ns->offsets;
+ struct timespec64 *offsets = NULL;
+
+ if (!ns_offsets)
+ return;
+
+ if (val->tv_sec == 0 && val->tv_nsec == 0)
+ return;
+
+ switch (clockid) {
+ case CLOCK_MONOTONIC:
+ case CLOCK_MONOTONIC_RAW:
+ case
