Re: [PATCH] misc/pvpanic: resolve compile errors for arch=um
On Tue, Nov 27, 2018 at 03:47:28PM +0800, peng.h...@zte.com.cn wrote: > >> >On Fri, Nov 16, 2018 at 07:13:26PM +0800, Peng Hao wrote: > >> >> Resolve compile error for arch=um > >> >> pvpanic.c:(.text+0xb6): undefined reference to `devm_ioremap_resource' > >> >> > >> >> Signed-off-by: Peng Hao > >> >> --- > >> >> drivers/misc/Kconfig | 2 +- > >> >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> >What commit is this fixing? What broke and when did it break? > >> kbuildtestrobot reports this compile error for arch=um. > >> here is content: > >> " head: 24438e46268c721e14c5c888386af85c9e1c5db1 > >> commit: 77703e0b0326a1fb06b5cb5b468a633472c5a8e9 [10/26] misc/pvpanic : > >> break dependency on ACPI > > > >Ah, it is breaking because of your patch, not a patch in the kernel > >today. So please integrate this patch into your latest patch series > >when you redo your patches. > > > The series of patches has merged into "char-misc-next" > (https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/log/?h=char-misc-next), > Do I need to re-send the entire series of patches ? Ah, I didn't realize that. Ok, let me go dig this back up and add it to my tree, sorry for the noise... greg k-h
Re: [PATCH] staging: rtl8188eu: Fix off-by-one in core/rtw_mlme_ext.c
On Tue, Nov 27, 2018 at 07:29:07AM +, Yang Xiao wrote: > From: Young_X Please use your "full" name like you did in your from: line of your email > > The error at line 3267 was the result of an off-by-one error in > a for loop in line 3253. > If condition in line 3254 never satisfies, then the value of > pstat->aid is NUM_STA+1. This will lead to out-of-bound access > in line 3267. Why is this indented? No need for that. Can you fix that up and resend? thanks, greg k-h
Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE
Anshuman Khandual writes: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like > 'invalid node' from various places redirecting them to a common definition. > > Signed-off-by: Anshuman Khandual > --- > Changes in V2: > > - Added inclusion of 'numa.h' header at various places per Andrew > - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod > > Changes in V1: (https://lkml.org/lkml/2018/11/23/485) > > - Dropped OCFS2 changes per Joseph > - Dropped media/video drivers changes per Hans > > RFC - https://patchwork.kernel.org/patch/10678035/ > > Build tested this with multiple cross compiler options like alpha, sparc, > arm64, x86, powerpc, powerpc64le etc with their default config which might > not have compiled tested all driver related changes. I will appreciate > folks giving this a test in their respective build environment. > > All these places for replacement were found by running the following grep > patterns on the entire kernel code. Please let me know if this might have > missed some instances. This might also have replaced some false positives. > I will appreciate suggestions, inputs and review. > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" > > arch/alpha/include/asm/topology.h | 3 ++- > arch/ia64/kernel/numa.c | 2 +- > arch/ia64/mm/discontig.c | 6 +++--- > arch/ia64/sn/kernel/io_common.c | 3 ++- > arch/powerpc/include/asm/pci-bridge.h | 3 ++- > arch/powerpc/kernel/paca.c| 3 ++- > arch/powerpc/kernel/pci-common.c | 3 ++- > arch/powerpc/mm/numa.c| 14 +++--- > arch/powerpc/platforms/powernv/memtrace.c | 5 +++-- These powerpc changes all look fine. Acked-by: Michael Ellerman cheers
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote:
> +static struct attribute *fieldbus_attrs[] = {
> + &dev_attr_enabled.attr,
> + &dev_attr_card_name.attr,
> + &dev_attr_fieldbus_id.attr,
> + &dev_attr_read_area_size.attr,
> + &dev_attr_write_area_size.attr,
> + &dev_attr_online.attr,
> + &dev_attr_fieldbus_type.attr,
> + NULL,
> +};
> +
> +static umode_t fieldbus_is_visible(struct kobject *kobj, struct attribute
> *attr,
> + int n)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct fieldbus_dev *fb = dev_get_drvdata(dev);
> + umode_t mode = attr->mode;
> +
> + if (attr == &dev_attr_enabled.attr) {
> + mode = 0;
> + if (fb->enable_get)
> + mode |= 0444;
> + if (fb->simple_enable_set)
> + mode |= 0200;
> + }
> +
> + return mode;
> +}
> +
> +static const struct attribute_group fieldbus_group = {
> + .attrs = fieldbus_attrs,
> + .is_visible = fieldbus_is_visible,
> +};
> +__ATTRIBUTE_GROUPS(fieldbus);
Why not just use ATTRIBUTE_GROUPS()?
> +static int __fieldbus_dev_register(struct fieldbus_dev *fb)
> +{
> + dev_t devno;
> + int err;
> +
> + if (!fb)
> + return -EINVAL;
> + if (!fb->read_area || !fb->write_area || !fb->fieldbus_id_get)
> + return -EINVAL;
> + fb->id = ida_simple_get(&fieldbus_ida, 0, MAX_FIELDBUSES, GFP_KERNEL);
> + if (fb->id < 0)
> + return fb->id;
> + devno = MKDEV(MAJOR(fieldbus_devt), fb->id);
> + init_waitqueue_head(&fb->dc_wq);
> + cdev_init(&fb->cdev, &fieldbus_fops);
> + err = cdev_add(&fb->cdev, devno, 1);
> + if (err) {
> + pr_err("fieldbus_dev%d unable to add device %d:%d\n",
> + fb->id, MAJOR(fieldbus_devt), fb->id);
> + goto err_cdev;
> + }
Why do you have a static cdev?
> + fb->dev = device_create(&fieldbus_class, fb->parent, devno, fb,
> + "fieldbus_dev%d", fb->id);
> + if (IS_ERR(fb->dev)) {
> + err = PTR_ERR(fb->dev);
> + goto err_dev_create;
> + }
> + fb->online_sd = sysfs_get_dirent(fb->dev->kobj.sd, "online");
Ick, what? Why? Why are you messing around with a raw sysfs attribute?
Also, you are creating sysfs files and you are not documenting any of
them in Documentation/ABI/ which is not allowed. Please add that to
this patch for the next round.
thanks,
greg k-h
Re: [PATCH 2/2] gpio: mt7621: pass mediatek_gpio_bank_probe() failure up the stack
Nicholas Mc Guire 於 2018年11月21日 週三 上午10:13寫道：
>
> The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
> for the dev_err() messages). The probe function should return an error
> if one of the banks failed to initialize properly.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> ---
>
> Patch was compile tested with: omega2p_defconfig, SOC_MT7621=y,
> GPIOLIB=y, GPIO_MT7621=y
>
> Patch is against 4.20-rc3 (localversion-next is next-20181121)
>
> drivers/gpio/gpio-mt7621.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index 1ec95bc..68fca8b 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -297,6 +297,7 @@ mediatek_gpio_probe(struct platform_device *pdev)
> struct device_node *np = dev->of_node;
> struct mtk *mtk;
> int i;
> + int ret;
>
> mtk = devm_kzalloc(dev, sizeof(*mtk), GFP_KERNEL);
> if (!mtk)
> @@ -311,8 +312,11 @@ mediatek_gpio_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, mtk);
> mediatek_gpio_irq_chip.name = dev_name(dev);
>
> - for (i = 0; i < MTK_BANK_CNT; i++)
> - mediatek_gpio_bank_probe(dev, np, i);
> + for (i = 0; i < MTK_BANK_CNT; i++) {
> + ret = mediatek_gpio_bank_probe(dev, np, i);
> + if (!ret)
it should be if (ret < 0) ?
> + return ret;
> + }
>
> return 0;
> }
> --
> 2.1.4
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote: > Fieldbus device (client) adapters allow data exchange with a PLC aka. > "Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.) > > They are typically used when a Linux device wants to expose itself > as an actuator, motor, console light, switch, etc. over the fieldbus. > > This framework is designed to provide a generic interface to Fieldbus > Devices from both the Linux Kernel and the userspace. > > Signed-off-by: Sven Van Asbroeck Your "From:" line does not match this address or name at all, which means no one can apply this :( Please fix for your next round of patches. thanks, greg k-h
[PATCH V2] can: flexcan: implement can Runtime PM
From: Aisheng Dong
Flexcan will be disabled during suspend if no wakeup function required and
enabled after resume accordingly. During this period, we could explicitly
disable clocks.
Implement Runtime PM which will:
1) Keep device in suspend state (clocks disabled) if it's not openned.
2) Make Power Domain framework be able to shutdown the corresponding power
domain of this device.
Signed-off-by: Aisheng Dong
Signed-off-by: Joakim Zhang
---
ChangeLog:
V1->V2:
*rebased on patch "can: flexcan: add self wakeup support".
*add check when to do flexcan_clks_disable/enable() during
Runtime PM.
---
drivers/net/can/flexcan.c | 119 --
1 file changed, 77 insertions(+), 42 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index d12b2f7d2834..130a2cb04827 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -277,6 +278,7 @@ struct flexcan_priv {
u32 reg_imask1_default;
u32 reg_imask2_default;
+ struct device *dev;
struct clk *clk_ipg;
struct clk *clk_per;
const struct flexcan_devtype_data *devtype_data;
@@ -444,6 +446,27 @@ static inline void flexcan_error_irq_disable(const struct
flexcan_priv *priv)
priv->write(reg_ctrl, ®s->ctrl);
}
+static int flexcan_clks_enable(const struct flexcan_priv *priv)
+{
+ int err;
+
+ err = clk_prepare_enable(priv->clk_ipg);
+ if (err)
+ return err;
+
+ err = clk_prepare_enable(priv->clk_per);
+ if (err)
+ clk_disable_unprepare(priv->clk_ipg);
+
+ return err;
+}
+
+static void flexcan_clks_disable(const struct flexcan_priv *priv)
+{
+ clk_disable_unprepare(priv->clk_ipg);
+ clk_disable_unprepare(priv->clk_per);
+}
+
static inline int flexcan_transceiver_enable(const struct flexcan_priv *priv)
{
if (!priv->reg_xceiver)
@@ -570,19 +593,11 @@ static int flexcan_get_berr_counter(const struct
net_device *dev,
const struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = clk_prepare_enable(priv->clk_ipg);
- if (err)
- return err;
-
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
+ pm_runtime_get_sync(priv->dev);
err = __flexcan_get_berr_counter(dev, bec);
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
+ pm_runtime_put(priv->dev);
return err;
}
@@ -1215,17 +1230,13 @@ static int flexcan_open(struct net_device *dev)
struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = clk_prepare_enable(priv->clk_ipg);
+ err = pm_runtime_get_sync(priv->dev);
if (err)
return err;
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
-
err = open_candev(dev);
if (err)
- goto out_disable_per;
+ goto out_pm_runtime;
err = request_irq(dev->irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
if (err)
@@ -1288,10 +1299,8 @@ static int flexcan_open(struct net_device *dev)
free_irq(dev->irq, dev);
out_close:
close_candev(dev);
- out_disable_per:
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
+ out_pm_runtime:
+ pm_runtime_put(priv->dev);
return err;
}
@@ -1306,11 +1315,11 @@ static int flexcan_close(struct net_device *dev)
can_rx_offload_del(&priv->offload);
free_irq(dev->irq, dev);
- clk_disable_unprepare(priv->clk_per);
- clk_disable_unprepare(priv->clk_ipg);
close_candev(dev);
+ pm_runtime_put(priv->dev);
+
can_led_event(dev, CAN_LED_EVENT_STOP);
return 0;
@@ -1349,18 +1358,10 @@ static int register_flexcandev(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg, err;
- err = clk_prepare_enable(priv->clk_ipg);
- if (err)
- return err;
-
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
-
/* select "bus clock", chip must be disabled */
err = flexcan_chip_disable(priv);
if (err)
- goto out_disable_per;
+ return err;
reg = priv->read(®s->ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
priv->write(reg, ®s->ctrl);
@@ -1389,13 +1390,8 @@ static int register_flexcandev(struct net_device *dev)
err = register_candev(dev);
- /* disable core and turn off clocks */
out_chip_disable:
flexcan_chip_disable(priv);
- out_disable_per:
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote:
> Fieldbus device (client) adapters allow data exchange with a PLC aka.
> "Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.)
>
> They are typically used when a Linux device wants to expose itself
> as an actuator, motor, console light, switch, etc. over the fieldbus.
>
> This framework is designed to provide a generic interface to Fieldbus
> Devices from both the Linux Kernel and the userspace.
>
> Signed-off-by: Sven Van Asbroeck
License nit:
> --- /dev/null
> +++ b/drivers/fieldbus/dev_core.c
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: GPL-2.0
That's great, but then you write:
> +MODULE_LICENSE("GPL");
Which means "GPLv2+". So this MODULE_LICENSE() should be "GPL v2",
right?
thanks,
greg k-h
Re: [PATCH] xen/x86: add diagnostic printout to xen_mc_flush() in case of error
On 26/11/2018 21:11, Boris Ostrovsky wrote:
> On 11/23/18 11:24 AM, Juergen Gross wrote:
>> Failure of an element of a Xen multicall is signalled via a WARN()
>> only unless the kernel is compiled with MC_DEBUG. It is impossible to
>
> s/unless/if
>
>
>> know which element failed and why it did so.
>>
>> Change that by printing the related information even without MC_DEBUG,
>> even if maybe in some limited form (e.g. without information which
>> caller produced the failing element).
>>
>> Move the printing out of the switch statement in order to have the
>> same information for a single call.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> arch/x86/xen/multicalls.c | 35 ---
>> 1 file changed, 20 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
>> index 2bce7958ce8b..0766a08bdf45 100644
>> --- a/arch/x86/xen/multicalls.c
>> +++ b/arch/x86/xen/multicalls.c
>> @@ -69,6 +69,11 @@ void xen_mc_flush(void)
>>
>> trace_xen_mc_flush(b->mcidx, b->argidx, b->cbidx);
>>
>> +#if MC_DEBUG
>> +memcpy(b->debug, b->entries,
>> + b->mcidx * sizeof(struct multicall_entry));
>> +#endif
>> +
>> switch (b->mcidx) {
>> case 0:
>> /* no-op */
>> @@ -87,32 +92,34 @@ void xen_mc_flush(void)
>> break;
>>
>> default:
>> -#if MC_DEBUG
>> -memcpy(b->debug, b->entries,
>> - b->mcidx * sizeof(struct multicall_entry));
>> -#endif
>> -
>> if (HYPERVISOR_multicall(b->entries, b->mcidx) != 0)
>> BUG();
>> for (i = 0; i < b->mcidx; i++)
>> if (b->entries[i].result < 0)
>> ret++;
>> +}
>>
>> +if (WARN_ON(ret)) {
>> +pr_err("%d of %d multicall(s) failed: cpu %d\n",
>> + ret, b->mcidx, smp_processor_id());
>> +for (i = 0; i < b->mcidx; i++) {
>> +if (b->entries[i].result < 0) {
>> #if MC_DEBUG
>> -if (ret) {
>> -printk(KERN_ERR "%d multicall(s) failed: cpu %d\n",
>> - ret, smp_processor_id());
>> -dump_stack();
>> -for (i = 0; i < b->mcidx; i++) {
>> -printk(KERN_DEBUG " call %2d/%d: op=%lu
>> arg=[%lx] result=%ld\t%pF\n",
>> - i+1, b->mcidx,
>> +pr_err(" call %2d: op=%lu arg=[%lx]
>> result=%ld\t%pF\n",
>> + i + 1,
>> b->debug[i].op,
>> b->debug[i].args[0],
>> b->entries[i].result,
>> b->caller[i]);
>> +#else
>> +pr_err(" call %2d: op=%lu arg=[%lx]
>> result=%ld\n",
>> + i + 1,
>> + b->entries[i].op,
>> + b->entries[i].args[0],
>> + b->entries[i].result);
>> +#endif
>
> Doesn't (non-debug) hypervisor corrupt op and args?
No. Only debug hypervisor does so.
See my patch (and rather lengthy discussion) on xen-devel:
https://lists.xen.org/archives/html/xen-devel/2018-11/msg02714.html
>
> (Also, we don't really need to print anything when b->entries[i].result
> == 0)
Right. Did you miss the:
+ if (b->entries[i].result < 0) {
above?
Juergen
[PATCH] mtd: nand: Fix memory allocation in nanddev_bbt_init()
Fix the size of the buffer allocated to store the in-memory BBT.
This bug was previously hidden by a different bug, that was fixed in
d098093ba06e.
Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND
devices")
Cc:
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/bbt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/bbt.c b/drivers/mtd/nand/bbt.c
index 56cde38..c12497f 100644
--- a/drivers/mtd/nand/bbt.c
+++ b/drivers/mtd/nand/bbt.c
@@ -27,7 +27,8 @@ int nanddev_bbt_init(struct nand_device *nand)
unsigned int nwords = DIV_ROUND_UP(nblocks * bits_per_block,
BITS_PER_LONG);
- nand->bbt.cache = kzalloc(nwords, GFP_KERNEL);
+ nand->bbt.cache = kzalloc(nwords * (BITS_PER_LONG / BITS_PER_BYTE),
+ GFP_KERNEL);
if (!nand->bbt.cache)
return -ENOMEM;
--
2.7.4
Re: possible deadlock in ovl_write_iter
On Tue, Nov 27, 2018 at 9:06 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=120f390540
> kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
> dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10cad22540
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1381309340
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
>
> overlayfs: filesystem on './file0' not supported as upperdir
>
> ==
> WARNING: possible circular locking dependency detected
> 4.20.0-rc4+ #351 Not tainted
> --
> syz-executor338/5996 is trying to acquire lock:
> b59bb66d (&ovl_i_mutex_key[depth]){+.+.}, at: inode_lock
> include/linux/fs.h:757 [inline]
> b59bb66d (&ovl_i_mutex_key[depth]){+.+.}, at:
> ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
>
> but task is already holding lock:
> e0274330 (&pipe->mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
> [inline]
> e0274330 (&pipe->mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
> fs/pipe.c:70
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&pipe->mutex/1){+.+.}:
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> pipe_lock_nested fs/pipe.c:62 [inline]
> pipe_lock+0x6e/0x80 fs/pipe.c:70
> iter_file_splice_write+0x27d/0x1050 fs/splice.c:700
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x64a/0x1430 fs/splice.c:1147
> __do_sys_splice fs/splice.c:1414 [inline]
> __se_sys_splice fs/splice.c:1394 [inline]
> __x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#3){.+.+}:
> percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
> percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> __sb_start_write+0x214/0x370 fs/super.c:1387
> sb_start_write include/linux/fs.h:1597 [inline]
> mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> notify_change+0xbde/0x1110 fs/attr.c:334
> do_truncate+0x1bd/0x2d0 fs/open.c:63
> handle_truncate fs/namei.c:3008 [inline]
> do_last fs/namei.c:3424 [inline]
> path_openat+0x375f/0x5150 fs/namei.c:3534
> do_filp_open+0x255/0x380 fs/namei.c:3564
> do_sys_open+0x568/0x700 fs/open.c:1063
> __do_sys_openat fs/open.c:1090 [inline]
> __se_sys_openat fs/open.c:1084 [inline]
> __x64_sys_openat+0x9d/0x100 fs/open.c:1084
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (&ovl_i_mutex_key[depth]){+.+.}:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
> down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> inode_lock include/linux/fs.h:757 [inline]
> ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
> call_write_iter include/linux/fs.h:1857 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> __kernel_write+0x10c/0x370 fs/read_write.c:506
> write_pipe_buf+0x180/0x240 fs/splice.c:797
> splice_from_pipe_feed fs/splice.c:503 [inline]
> __splice_from_pipe+0x38b/0x7c0 fs/splice.c:627
> splice_from_pipe+0x1ec/0x340 fs/splice.c:662
> default_file_splice_write+0x3c/0x90 fs/splice.c:809
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x64a/0x1430 fs/splice.c:1147
> __do_sys_splice fs/splice.c:1414 [inline]
> __se_sys_splice fs/splice.c:1394 [inline]
> __x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Chain exists of:
>&ovl_i_mutex_key[depth] --> sb_writers#3 --> &pipe->mutex/1
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
>lock(&pipe->mutex/1);
> lock(sb_writers#3);
>
Re: [PATCH 2/2] misc: hx8837: add a HiMax HX8837 display controller driver
On Mon, Nov 12, 2018 at 03:39:29AM +0100, Lubomir Rintel wrote: > HiMax HX8837 is a display controller used on OLPC platforms. It controls > backlight and is able to capture and freeze a frame when the LCD controller > (and the rest of the plaform) is powered off. > > This driver is based on the same code as drivers/staging/olpc_dcon. > I modernized it to use managed GPIO, device-tree bindings, sysfs attribtue > groups, essentially fixing the staging driver's TODO. You are creating custom sysfs files, with no Documentation/ABI/ update for us to know what those files are or how they are used :( Why do you need custom sysfs files in the first place? Isn't there already an api for this type of device in the kernel? thanks, greg k-h
Re: [PATCH] s390: Remove obsolete bust_spinlock() implementation
On Fri, 23 Nov 2018 08:02:12 +0100
Heiko Carstens wrote:
> On Fri, Nov 23, 2018 at 11:17:48AM +0900, Sergey Senozhatsky wrote:
> > On (11/22/18 15:15), Petr Mladek wrote:
> > > The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> > > the s390-specific implementation because of the absence of CONFIG_VT.
> > > In fact, the only difference was calling console_unblank() instead of
> > > unblank_screen().
> > >
> > > The common implementation in lib/bust_spinlocks.c started to call
> > > unblank_screen() explicitly since the commit b61312d353da187
> > > ("oops handling: ensure that any oops is flushed to the mtdoops
> > > console").
> > >
> > > As a result, the custom implementation is not longer necessary.
> > > And we could get all the other improvements of the common
> > > implementation for free.
> >
> > I believe I sent a similar patch several weeks ago and it's
> > in s390 patch queue as of now, waiting for the next merge
> > window.
> >
> > lkml.kernel.org/r/20181025081108.GB26561@osiris
>
> Yes, it will be added soon to the features branch of the
> s390/linux.git repository on kernel.org and then hit linux-next.
The patch is now queued for the next merge window.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH 3/3] s390/mm: fix mis-accounting of pgtable_bytes
On Wed, Oct 31, 2018 at 01:36:23PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 31, 2018 at 11:09:44AM +0100, Heiko Carstens wrote:
> > On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> > > Thanks for testing. Unfortunately Heiko reported another issue yesterday
> > > with the patch applied. This time the other way around:
> > >
> > > BUG: non-zero pgtables_bytes on freeing mm: -16384
> > >
> > > I am trying to understand how this can happen. For now I would like to
> > > keep the patch on hold in case they need another change.
> >
> > FWIW, Kirill: is there a reason why this "BUG:" output is done with
> > pr_alert() and not with VM_BUG_ON() or one of the WARN*() variants?
> >
> > That would to get more information with DEBUG_VM and / or
> > panic_on_warn=1 set. At least for automated testing it would be nice
> > to have such triggers.
>
> Stack trace is not helpful there. It will always show the exit path which
> is useless.
So, even with the updated version of these patches I can flood dmesg
and the console with
BUG: non-zero pgtables_bytes on freeing mm: 16384
messages with this complex reproducer on s390:
echo "void main(void) {}" | gcc -m31 -xc -o compat - && ./compat
Besides that this needs to be fixed, I'd really like to see this
changed to either a printk_once() or a WARN_ON_ONCE() within
check_mm() so that an arbitrary user cannot flood the console.
E.g. something like the below. If there aren't any objections, I will
provide a proper patch with changelog, etc.
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff89c7b..d7aeec03c57f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -647,8 +647,8 @@ static void check_mm(struct mm_struct *mm)
}
if (mm_pgtables_bytes(mm))
- pr_alert("BUG: non-zero pgtables_bytes on freeing mm: %ld\n",
- mm_pgtables_bytes(mm));
+ printk_once(KERN_ALERT "BUG: non-zero pgtables_bytes on freeing
mm: %ld\n",
+ mm_pgtables_bytes(mm));
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
VM_BUG_ON_MM(mm->pmd_huge_pte, mm);
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Thomas Gleixner wrote: > That's racy and does not prevent the situation because the TIF flags are > updated befor the UPDATE bit is set. > So __speculation_ctrl_update() might see the new bits, but not > TIF_SPEC_UPDATE. Hm, right, scratch that. We'd need to do that before updating TIF_SPEC_IB in task_update_spec_tif(), but that has the opposite ordering issue. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] misc/pvpanic: resolve compile errors for arch=um
On Tue, Nov 27, 2018 at 08:27:03AM +0800, peng.h...@zte.com.cn wrote: > >On Fri, Nov 16, 2018 at 07:13:26PM +0800, Peng Hao wrote: > >> Resolve compile error for arch=um > >> pvpanic.c:(.text+0xb6): undefined reference to `devm_ioremap_resource' > >> > >> Signed-off-by: Peng Hao > >> --- > >> drivers/misc/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > >What commit is this fixing? What broke and when did it break? > kbuildtestrobot reports this compile error for arch=um. > here is content: > " head: 24438e46268c721e14c5c888386af85c9e1c5db1 > commit: 77703e0b0326a1fb06b5cb5b468a633472c5a8e9 [10/26] misc/pvpanic : break > dependency on ACPI Ah, it is breaking because of your patch, not a patch in the kernel today. So please integrate this patch into your latest patch series when you redo your patches. thanks, greg k-h
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
Jonathan Cameron 於 2018年11月25日 週日 下午9:23寫道： > > On Wed, 21 Nov 2018 13:13:40 +0800 > Jian-Hong Pan wrote: > > > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > > > Hi Jian, > > > > > > Not clear to me why should be + instead of *. > > > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > > time) [s] > > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample > > > sampling time) [ms] > > > > > > In your case you assume bootime is in milliseconds. > > > > Yes, I assume that according to the original comment. > > > > >Maybe we can change the comment and use 'number of samples ...'. > > > > Making the meaning more clear is better. > > > > However, does the bootime of the measurement need as the long time to > > be enabled? > > If the sampling rate is 1Hz and n is 2, then they will do msleep with > > 2000 ms for each st_sensors_read_info_raw. > > Superficially that seems correct as we need to be sure that a reading > has occurred. If you want it to be quicker than the ODR should be set > faster so that the reading shows up reasonably quickly. At 1Hz and > you want to drop 2 samples, it will indeed take 2 seconds. Now, I understand with the description. Thank you. Jian-Hong Pan > > > -Original Message- > > > From: linux-iio-ow...@vger.kernel.org > > > On Behalf Of Jian-Hong Pan > > > Sent: Sunday, November 18, 2018 10:12 PM > > > To: Jonathan Cameron ; Hartmut Knaack > > > ; Lars-Peter Clausen ; Peter > > > Meerwald-Stadler ; Dominique Martinet > > > > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > li...@endlessm.com; Jian-Hong Pan > > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > > > According to the description of st_sensor_settings and st_sensor_data > > > structures' comments: > > > - bootime: samples to discard when sensor passing from power-down to > > > power-up. > > > - odr: Output data rate of the sensor [Hz]. > > > > > > The sleep time should be > > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > > > Signed-off-by: Jian-Hong Pan > > > --- > > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > > index 26fbd1bd9413..6b87ea657a92 100644 > > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev > > > *indio_dev, > > > if (err < 0) > > > goto out; > > > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > > sdata->odr); > > > + msleep(sdata->sensor_settings->bootime + 1000 / > > > sdata->odr); > > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > > if (err < 0) > > > goto out; > > > -- > > > 2.11.0 > > > >
Re: [PATCH 1/2] gpio: mt7621: report failure of devm_kasprintf()
Nicholas Mc Guire 於 2018年11月21日 週三 上午10:13寫道：
>
> kasprintf() may return NULL on failure of internal allocation thus the
> assigned label is not safe if not explicitly checked. On error
> mediatek_gpio_bank_probe() returns negative values so -ENOMEM in the
> (unlikely) failure case should be fine here.
>
> Signed-off-by: Nicholas Mc Guire
Acked-by: Sean Wang
> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> ---
>
> V2: The dev_err() for the unlikely case of the devm_kasprintf()
> failing was removed on request from Bartosz Golaszewski
>
>
> Problem located with experimental coccinelle script
>
> Patch was compile tested with: omega2p_defconfig, SOC_MT7621=y,
> GPIOLIB=y, GPIO_MT7621=y
>
> Patch is against 4.20-rc3 (localversion-next is next-20181121)
>
> drivers/gpio/gpio-mt7621.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index d72af6f..1ec95bc 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -244,6 +244,8 @@ mediatek_gpio_bank_probe(struct device *dev,
> rg->chip.of_xlate = mediatek_gpio_xlate;
> rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d",
> dev_name(dev), bank);
> + if (!rg->chip.label)
> + return -ENOMEM;
>
> ret = devm_gpiochip_add_data(dev, &rg->chip, mtk);
> if (ret < 0) {
> --
> 2.1.4
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] x86/resctrl: Fix rdt_last_cmd_printf() usage and typos within
On Mon, 26 Nov 2018, Reinette Chatre wrote: > Use rdt_last_cmd_puts() instead of rdt_last_cmd_printf() when printing a > simple string. While doing so fix two typos that were recently > introduced into two of these simple strings. You're explaing what the patch is doing, but not why printf() is wrong. Thanks, tglx
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Mon, 26 Nov 2018, Thomas Gleixner wrote:
>
> How about the minimalistic aproach below? (only compile tested so far,
> applies on top of your latest WIP.x86/pti branch). The downside of course
> is wasting another TIF bit.
We need to waste another TIF bit in any case.
>*
>* This can only happen for SECCOMP mitigation. For PRCTL it's
>* always the current task.
> + *
> + * If we are updating non-current task, set a flag for it to always
> + * perform the MSR sync on a first context switch, to make sure
> + * the TIF_SPEC_IB above is not out of sync with the MSR value during
> + * task's runtime.
>*/
> if (tsk == current && update)
> speculation_ctrl_update_current();
> + else
> + set_tsk_thread_flag(tsk, TIF_SPEC_UPDATE);
> +
> }
>
> static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 3f5e351bdd37..78208234e63e 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -449,8 +449,20 @@ static __always_inline void
> __speculation_ctrl_update(unsigned long tifp,
>* otherwise avoid the MSR write.
>*/
> if (IS_ENABLED(CONFIG_SMP) &&
> - static_branch_unlikely(&switch_to_cond_stibp))
> + static_branch_unlikely(&switch_to_cond_stibp)) {
> updmsr |= !!(tif_diff & _TIF_SPEC_IB);
> + /*
> + * We need to update the MSR if remote task did set
> + * TIF_SPEC_UPDATE on us, and therefore MSR value and
> + * the TIF_SPEC_IB values might be out of sync.
> + *
> + * This can only happen if seccomp task has updated
> + * one of its remote threads.
> + */
> + if (IS_ENABLED(CONFIG_SECCOMP) && !updmsr &&
> + (tifn & TIF_SPEC_UPDATE))
> + updmsr = true;
> + }
>
> if (updmsr)
> spec_ctrl_update_msr(tifn);
> @@ -496,6 +508,8 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
> set_cpuid_faulting(!!(tifn & _TIF_NOCPUID));
>
> __speculation_ctrl_update(tifp, tifn);
> + if (IS_ENABLED(CONFIG_SECCOMP))
> + clear_tsk_thread_flag(next_p, TIF_SPEC_UPDATE);
That's racy and does not prevent the situation because the TIF flags are
updated befor the UPDATE bit is set. So __speculation_ctrl_update() might
see the new bits, but not TIF_SPEC_UPDATE. You really need shadow storage
to avoid that.
Thanks,
tglx
[PATCH v2] panic: Add options to print system info when panic happens
Kernel panic issues are always painful to debug, partially
because it's not easy to get enough information of the
context when panic happens.
And we have ramoops and kdump for that, while this commit
tries to provide a easier way to show the system info by adding
a cmdline parameter, referring some idea from sysrq handler.
Signed-off-by: Feng Tang
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Steven Rostedt
---
Changelog:
v2:
- change text "dump/DUMP" to "print/PRINT" which
is more accurate, suggested by Andrew Morton
- add code to print ftrace buffer
Documentation/admin-guide/kernel-parameters.txt | 8 +++
kernel/panic.c | 28 +
2 files changed, 36 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 19f4423..80c819a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3081,6 +3081,14 @@
timeout < 0: reboot immediately
Format:
+ panic_print=Bitmask for printing system info when panic happens.
+ User can chose combination of the following bits:
+ bit 0: print all tasks info
+ bit 1: print system memory info
+ bit 2: print timer info
+ bit 3: print locks info if CONFIG_LOCKDEP is on
+ bit 4: print ftrace buffer
+
panic_on_warn panic() instead of WARN(). Useful to cause kdump
on a WARN().
diff --git a/kernel/panic.c b/kernel/panic.c
index f6d549a..fb6ccd1 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -45,6 +45,13 @@ int panic_on_warn __read_mostly;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
EXPORT_SYMBOL_GPL(panic_timeout);
+#define PANIC_PRINT_TASK_INFO 0x0001
+#define PANIC_PRINT_MEM_INFO 0x0002
+#define PANIC_PRINT_TIMER_INFO 0x0004
+#define PANIC_PRINT_LOCK_INFO 0x0008
+#define PANIC_PRINT_FTRACE_INFO0x0010
+static unsigned long panic_print;
+
ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
EXPORT_SYMBOL(panic_notifier_list);
@@ -124,6 +131,24 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
}
EXPORT_SYMBOL(nmi_panic);
+static void panic_print_sys_info(void)
+{
+ if (panic_print & PANIC_PRINT_TASK_INFO)
+ show_state();
+
+ if (panic_print & PANIC_PRINT_MEM_INFO)
+ show_mem(0, NULL);
+
+ if (panic_print & PANIC_PRINT_TIMER_INFO)
+ sysrq_timer_list_show();
+
+ if (panic_print & PANIC_PRINT_LOCK_INFO)
+ debug_show_all_locks();
+
+ if (panic_print & PANIC_PRINT_FTRACE_INFO)
+ ftrace_dump(DUMP_ALL);
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -250,6 +275,8 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic();
+ panic_print_sys_info();
+
if (!panic_blink)
panic_blink = no_blink;
@@ -654,6 +681,7 @@ void refcount_error_report(struct pt_regs *regs, const char
*err)
#endif
core_param(panic, panic_timeout, int, 0644);
+core_param(panic_print, panic_print, ulong, 0644);
core_param(pause_on_oops, pause_on_oops, int, 0644);
core_param(panic_on_warn, panic_on_warn, int, 0644);
core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0644);
--
2.7.4
[PATCH] cgroup: remove unused member "cgrp_ancestor_id_storage" in struct cgroup_root
"cgrp_ancestor_id_storage" is not used, so let's clean it up.
Signed-off-by: Peng Wang
---
include/linux/cgroup-defs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5e1694fe035b..639a96576ef3 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -467,9 +467,6 @@ struct cgroup_root {
/* The root cgroup. Root is destroyed on its release. */
struct cgroup cgrp;
- /* for cgrp->ancestor_ids[0] */
- int cgrp_ancestor_id_storage;
-
/* Number of cgroups in the hierarchy, used only for /proc/cgroups */
atomic_t nr_cgrps;
--
2.19.1
Re: possible deadlock in ovl_write_iter
syzbot has found a reproducer for the following crash on:
HEAD commit:6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=120f390540
kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10cad22540
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1381309340
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
overlayfs: filesystem on './file0' not supported as upperdir
==
WARNING: possible circular locking dependency detected
4.20.0-rc4+ #351 Not tainted
--
syz-executor338/5996 is trying to acquire lock:
b59bb66d (&ovl_i_mutex_key[depth]){+.+.}, at: inode_lock
include/linux/fs.h:757 [inline]
b59bb66d (&ovl_i_mutex_key[depth]){+.+.}, at:
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
but task is already holding lock:
e0274330 (&pipe->mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
[inline]
e0274330 (&pipe->mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
fs/pipe.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&pipe->mutex/1){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
pipe_lock_nested fs/pipe.c:62 [inline]
pipe_lock+0x6e/0x80 fs/pipe.c:70
iter_file_splice_write+0x27d/0x1050 fs/splice.c:700
do_splice_from fs/splice.c:851 [inline]
do_splice+0x64a/0x1430 fs/splice.c:1147
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (sb_writers#3){.+.+}:
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x214/0x370 fs/super.c:1387
sb_start_write include/linux/fs.h:1597 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:360
ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
notify_change+0xbde/0x1110 fs/attr.c:334
do_truncate+0x1bd/0x2d0 fs/open.c:63
handle_truncate fs/namei.c:3008 [inline]
do_last fs/namei.c:3424 [inline]
path_openat+0x375f/0x5150 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_sys_openat fs/open.c:1090 [inline]
__se_sys_openat fs/open.c:1084 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1084
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&ovl_i_mutex_key[depth]){+.+.}:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
down_write+0x8a/0x130 kernel/locking/rwsem.c:70
inode_lock include/linux/fs.h:757 [inline]
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
write_pipe_buf+0x180/0x240 fs/splice.c:797
splice_from_pipe_feed fs/splice.c:503 [inline]
__splice_from_pipe+0x38b/0x7c0 fs/splice.c:627
splice_from_pipe+0x1ec/0x340 fs/splice.c:662
default_file_splice_write+0x3c/0x90 fs/splice.c:809
do_splice_from fs/splice.c:851 [inline]
do_splice+0x64a/0x1430 fs/splice.c:1147
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
&ovl_i_mutex_key[depth] --> sb_writers#3 --> &pipe->mutex/1
Possible unsafe locking scenario:
CPU0CPU1
lock(&pipe->mutex/1);
lock(sb_writers#3);
lock(&pipe->mutex/1);
lock(&ovl_i_mutex_key[depth]);
*** DEADLOCK ***
2 locks held by syz-executor338/5996:
#0: 024e7b73 (sb_writers#8){.+.+}, at: file_start_write
include/linux/fs.h:2810 [inline]
#0: 024e7b73 (sb_writers#8){.+.+}, at: do_splice+0xd
Re: [patch 20/24] x86/speculation: Split out TIF update
On Mon, 26 Nov 2018, Thomas Gleixner wrote:
> > Looks like seccomp thread can be running on a remote CPU when its
> > TIF_SPEC_IB flag gets updated.
> >
> > I wonder if this will cause STIBP to be always off in this scenario, when
> > two tasks with SPEC_IB flags running on a remote CPU have STIBP bit always
> > *off* in SPEC MSR.
> >
> > Let's say we have tasks A and B running on a remote CPU:
> >
> > task A: SPEC_IB flag is on
> >
> > task B: SPEC_IB flag is off but is currently running on remote CPU, SPEC
> > MSR's STIBP bit is off
> >
> > Now arch_seccomp_spec_mitigation is called, setting SPEC_IB flag on task B.
> > SPEC MSR becomes out of sync with running task B's SPEC_IB flag.
> >
> >
> > Task B context switches to task A. Because both tasks have SPEC_IB flag
> > set and the flag status is unchanged, SPEC MSR's STIBP bit is not
> > updated. SPEC MSR STIBP bit remains off if tasks A and B are the only
> > tasks running on the CPU.
> >
> > There is an equivalent scenario where the SPEC MSR's STIBP bit remains on
> > even though both running task A and B's SPEC_IB flags are turned off.
> >
> > Wonder if I may be missing something so the above scenario is not of
> > concern?
>
> The above is real.
Agreed.
> The question is whether we need to worry about it.
Well, update of seccomp filters (and therefore updating of the flags)
might happen at any time, long after the seccomp process has been started,
so it might be pretty spread across cores by that time. So I think it
indeed is a real scenario, although probably even harder for explicitly
target by an attacker.
> If so, then the right thing to do is to leave thread_info.flags alone
> and flip the bits in a shadow storage, e.g. thread_info.spec_flags and
> after updating that set something like TIF_SPEC_UPDATE and evaluate that
> bit on context switch and if set update the TIF flags. Too tired to code
> that now, but it's straight forward. I'll look at it on wednesday if
> nobody beats me to it.
Hm, the we'd have to implement the same split for things like checking of
the work masks etc. (because we'd have to be checking in both places),
right? That doesn't look particularly nice.
How about the minimalistic aproach below? (only compile tested so far,
applies on top of your latest WIP.x86/pti branch). The downside of course
is wasting another TIF bit.
Thanks.
From: Jiri Kosina
Subject: [PATCH] x86/speculation: Always properly update SPEC_CTRL MSR for
remote seccomp tasks
If seccomp task is setting (*) TIF_SPEC_IB of a task running on remote CPU, the
value of TIF_SPEC_IB becomes out-of-sync with the actual MSR value on that CPU.
This becomes a problem when such task then context switches to another task
that has TIF_SPEC_IB set, as in such case the value of SPEC_CTRL MSR is not
updated and the next task starts running with stale value of SPEC_CTRL,
potentially unprotected by STIBP.
Fix that by always unconditionally updating the MSR in case that
- next task's TIF_SPEC_IB has been remotely set by its another seccomp thread,
and
- TIF_SPEC_IB value of next is equal to the one of prev, and therefore
we are guaranteed to be in a situation where MSR update would be lost
(*) symmetrical situation happens with clearing of the flag
Reported-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/include/asm/thread_info.h | 4 +++-
arch/x86/kernel/cpu/bugs.c | 8
arch/x86/kernel/process.c | 16 +++-
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 6d201699c651..278f9036ca45 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -84,6 +84,7 @@ struct thread_info {
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
+#define TIF_SPEC_UPDATE10 /* SPEC_CTRL MSR sync needed on
CTXSW */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -112,6 +113,7 @@ struct thread_info {
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
+#define _TIF_SPEC_UPDATE (1 << TIF_SPEC_UPDATE)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -155,7 +157,7 @@ struct thread_info {
* Avoid calls to __switch_to_xtra() on UP as STIBP is not evaluated.
*/
#ifdef CONFIG_SMP
-# define _TIF_WORK_CTXSW (_TIF_WORK_CTXSW_BASE | _TIF_SPEC_IB)
+# define _TIF_WORK_CTXSW
Re: [PATCH v2 3/3] Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990
Hi Matthias,
On 2018-11-27 05:57, Matthias Kaehlcke wrote:
On Mon, Nov 26, 2018 at 04:09:50PM -0800, Matthias Kaehlcke wrote:
On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi
wrote:
> During initalization of wcn3990, we observed UART is reading some
> stray bytes on the Rx line. This is logging Frame reassembly errors
> on the serial console. This could be because of tristate of Tx line
> of wcn3990 during boot up.
>
> [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
>
> Now we enable a flag during bootup to stop executing proto receive
> function and clear it back once the initialization is done.
>
> Signed-off-by: Balakrishna Godavarthi
> Tested-by: Matthias Kaehlcke
> ---
> v2:
> * Updated commit text & comments.
> v1:
> * initial patch
> ---
> drivers/bluetooth/hci_qca.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index ed905ea1c58a..2f3d9e16ba5a 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -56,6 +56,7 @@
>
> /* Controller states */
> #define STATE_IN_BAND_SLEEP_ENABLED 1
> +#define STATE_DISCARD_RX 2
>
> #define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> #define IBS_TX_IDLE_TIMEOUT_MS2000
> @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu)
>} else {
>hu->init_speed = qcadev->init_speed;
>hu->oper_speed = qcadev->oper_speed;
> + set_bit(STATE_DISCARD_RX, &qca->flags);
>ret = qca_power_setup(hu, true);
>if (ret) {
>destroy_workqueue(qca->workqueue);
> @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void
*data, int count)
>if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
>return -EUNATCH;
>
> + /* We discard Rx data received while device is in booting
> + * stage, This is because of BT chip Tx line is in tristate.
> + * Due to this we read some garbage data on UART Rx.
> + */
> + if (test_bit(STATE_DISCARD_RX, &qca->flags))
> + return 0;
> +
>qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count,
> qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts));
>if (IS_ERR(qca->rx_skb)) {
> @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu)
>if (ret)
>return ret;
>
> + clear_bit(STATE_DISCARD_RX, &qca->flags);
>ret = qca_read_soc_version(hdev, &soc_ver);
>if (ret)
>return ret;
> @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = {
>
> static void qca_power_shutdown(struct hci_uart *hu)
> {
> + struct qca_data *qca = hu->priv;
> +
> + /* From this point we go into power off state,
> + * disable IBS and discard all the queued data.
> + */
> + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
Is IBS actually related to the frame reassembly errors or is this
addressing a different issue? In 100 iteratios of 'hciconfig up/down'
without clearing the flag I didn't observe any frame reassembly
errors.
Looks like this addresses the "Bluetooth: Received HCI_IBS_SLEEP_IND
in rx state 0" messages that are seen when the interface is brought up
on a system with firmware binaries (with IBS support?). Please spin
this out into a separate patch.
[Bala]: "Bluetooth: Received HCI_IBS_SLEEP_IND in rx state 0 is an
different issue.
i suspect that is due to mismatch of ibs timers over flow value
between wcn3990 & HOST.
clearing ibs is required, to stop ibs state machine while we do
hci close
this is intern help in resolving the frame reassembly errors
during close (in rare case observed)
anyways will send this a separate patch.
Thanks
Matthias
--
Regards
Balakrishna.
Re: [PATCH 2/7] node: Add heterogenous memory performance
On Wed, Nov 14, 2018 at 2:53 PM Keith Busch wrote: > > Heterogeneous memory systems provide memory nodes with latency > and bandwidth performance attributes that are different from other > nodes. Create an interface for the kernel to register these attributes > under the node that provides the memory. If the system provides this > information, applications can query the node attributes when deciding > which node to request memory. > > When multiple memory initiators exist, accessing the same memory target > from each may not perform the same as the other. The highest performing > initiator to a given target is considered to be a local initiator for > that target. The kernel provides performance attributes only for the > local initiators. > > The memory's compute node should be symlinked in sysfs as one of the > node's initiators. > > The following example shows the new sysfs hierarchy for a node exporting > performance attributes: > > # tree /sys/devices/system/node/nodeY/initiator_access > /sys/devices/system/node/nodeY/initiator_access > |-- read_bandwidth > |-- read_latency > |-- write_bandwidth > `-- write_latency With the expectation that there will be nodes that are initiator-only, target-only, or both I think this interface should indicate that. The 1:1 "local" designation of HMAT should not be directly encoded in the interface, it's just a shortcut for finding at least one initiator in the set that can realize the advertised performance. At least if the interface can enumerate the set of initiators then it becomes clear whether sysfs can answer a performance enumeration question or if the application needs to consult an interface with specific knowledge of a given initiator-target pairing. It seems a precursor to these patches is arranges for offline node devices to be created for the ACPI proximity domains that are offline-by default for reserved memory ranges.
Re: [PATCH] arm64: dts: sdm845: Add videocc node
Quoting Doug Anderson (2018-11-26 16:35:50)
> Hi,
>
> On Mon, Nov 5, 2018 at 2:35 AM Taniya Das wrote:
> >
> > This adds the video clock controller node to sdm845 based on the examples
> > in the bindings.
> >
> > Signed-off-by: Taniya Das
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index b72bdb0..91a281b 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1256,6 +1257,13 @@
> > #power-domain-cells = <1>;
> > };
> >
> > + videocc: clock-controller@ab0 {
> > + compatible = "qcom,sdm845-videocc";
> > + reg = <0xab0 0x1>;
> > + #clock-cells = <1>;
> > + #power-domain-cells = <1>;
>
> Any reason not to include "#reset-cells = <1>;" here? The bindings
> list it as optional but I see no reason why we should leave it off.
> The file "include/dt-bindings/clock/qcom,videocc-sdm845.h" seems to
> include some #defines for resets. Even though the driver doesn't seem
> like it supports it yet, it still should be fine to list it here.
We should update the binding to make it a required property. It doesn't
make any sense why that property would be optional given that the
hardware either has support for resets or it doesn't.
[no subject]
-- Good day, I am Mrs Ulrica Mica from Hungary but based in the United Kindom, i am hospitalized in London suffering from Acute Cancer.i want to sign a Donation of $6,800,000 Usd on orphans in your area,can you handle it?, because of the confidentiality of the subject, Please contact me back directly on this my email (ulrica.mi...@aol.com), I have sent this proposal several times without receiving any response from you, Your responds on my private email address will determined how serious you are. I am making this donation because my doctor have issued to me that the rate of the cancer that i have just some days to live. There i decided to donate all that i have to the orphans. Mrs Ulrica Mica London. United Kingdom
[PATCH v2] clk: qcom: Move to menuconfig and reduce lines
We duplicate the 'depends on' in almost every Kconfig here, and it's getting out of hand now that we have tens of options for various SoC drivers here. Let's clean it up a little by making a menuconfig for a submenu and adding an if wrapper around the driver section. Cc: Bjorn Andersson Cc: Taniya Das Signed-off-by: Stephen Boyd --- Changes from v1: * Don't remove full depends on lines when they have something else drivers/clk/qcom/Kconfig | 43 +--- 1 file changed, 9 insertions(+), 34 deletions(-) diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index a611531df115..cf1dec367192 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -9,16 +9,17 @@ config QCOM_GDSC config QCOM_RPMCC bool -config COMMON_CLK_QCOM +menuconfig COMMON_CLK_QCOM tristate "Support for Qualcomm's clock controllers" depends on OF depends on ARCH_QCOM || COMPILE_TEST select REGMAP_MMIO select RESET_CONTROLLER +if COMMON_CLK_QCOM + config QCOM_A53PLL tristate "MSM8916 A53 PLL" - depends on COMMON_CLK_QCOM default ARCH_QCOM help Support for the A53 PLL on MSM8916 devices. It provides @@ -28,7 +29,6 @@ config QCOM_A53PLL config QCOM_CLK_APCS_MSM8916 tristate "MSM8916 APCS Clock Controller" - depends on COMMON_CLK_QCOM depends on QCOM_APCS_IPC || COMPILE_TEST default ARCH_QCOM help @@ -39,7 +39,7 @@ config QCOM_CLK_APCS_MSM8916 config QCOM_CLK_RPM tristate "RPM based Clock Controller" - depends on COMMON_CLK_QCOM && MFD_QCOM_RPM + depends on MFD_QCOM_RPM select QCOM_RPMCC help The RPM (Resource Power Manager) is a dedicated hardware engine for @@ -52,7 +52,7 @@ config QCOM_CLK_RPM config QCOM_CLK_SMD_RPM tristate "RPM over SMD based Clock Controller" - depends on COMMON_CLK_QCOM && QCOM_SMD_RPM + depends on QCOM_SMD_RPM select QCOM_RPMCC help The RPM (Resource Power Manager) is a dedicated hardware engine for @@ -65,7 +65,7 @@ config QCOM_CLK_SMD_RPM config QCOM_CLK_RPMH tristate "RPMh Clock Driver" - depends on COMMON_CLK_QCOM && QCOM_RPMH + depends on QCOM_RPMH help RPMh manages shared resources on some Qualcomm Technologies, Inc. SoCs. It accepts requests from other hardware subsystems via RSC. @@ -75,7 +75,6 @@ config QCOM_CLK_RPMH config APQ_GCC_8084 tristate "APQ8084 Global Clock Controller" select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the global clock controller on apq8084 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -85,7 +84,6 @@ config APQ_MMCC_8084 tristate "APQ8084 Multimedia Clock Controller" select APQ_GCC_8084 select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the multimedia clock controller on apq8084 devices. Say Y if you want to support multimedia devices such as display, @@ -93,7 +91,6 @@ config APQ_MMCC_8084 config IPQ_GCC_4019 tristate "IPQ4019 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on ipq4019 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -101,7 +98,6 @@ config IPQ_GCC_4019 config IPQ_GCC_806X tristate "IPQ806x Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on ipq806x devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -110,7 +106,6 @@ config IPQ_GCC_806X config IPQ_LCC_806X tristate "IPQ806x LPASS Clock Controller" select IPQ_GCC_806X - depends on COMMON_CLK_QCOM help Support for the LPASS clock controller on ipq806x devices. Say Y if you want to use audio devices such as i2s, pcm, @@ -118,7 +113,6 @@ config IPQ_LCC_806X config IPQ_GCC_8074 tristate "IPQ8074 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for global clock controller on ipq8074 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -127,7 +121,6 @@ config IPQ_GCC_8074 config MSM_GCC_8660 tristate "MSM8660 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on msm8660 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -136,7 +129,6 @@ config MSM_GCC_8660 config MSM_GCC_8916 tristate "MSM8916 Global Clock Controller" select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the global clock controller on msm8916 devices. Say Y if you want to use devices such as UART, SPI i2c, USB, @@
Re: [PATCH v2 2/3] Bluetooth: hci_qca: Deassert RTS while baudrate change command
Hi Matthias,
On 2018-11-27 01:12, Matthias Kaehlcke wrote:
On Thu, Nov 22, 2018 at 05:45:11PM +0530, Balakrishna Godavarthi wrote:
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command with newer baudrate, On host side
we are still operating in 115200 bps which results of reading garbage
data. Here we are pulling RTS line, so that chip we will wait to send
data
to host until host change its baudrate.
Thanks for updating the commit message and provide more details!
Signed-off-by: Balakrishna Godavarthi
Tested-by: Matthias Kaehlcke
---
v2:
* updated commit text and comments.
v1:
* initial patch
---
drivers/bluetooth/hci_qca.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f5dd323c1967..ed905ea1c58a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
- struct qca_serdev *qcadev;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
if (baudrate > QCA_BAUDRATE_320)
@@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
return -ENOMEM;
}
- /* Disabling hardware flow control is mandatory while
-* sending change baudrate request to wcn3990 SoC.
-*/
- qcadev = serdev_device_get_drvdata(hu->serdev);
- if (qcadev->btsoc_type == QCA_WCN3990)
- hci_uart_set_flow_control(hu, true);
-
/* Assign commands to change baudrate and packet type. */
skb_put_data(skb, cmd, sizeof(cmd));
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
@@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
set_current_state(TASK_RUNNING);
- if (qcadev->btsoc_type == QCA_WCN3990)
- hci_uart_set_flow_control(hu, false);
-
return 0;
}
@@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type
speed_type)
{
unsigned int speed, qca_baudrate;
+ struct qca_serdev *qcadev;
int ret;
if (speed_type == QCA_INIT_SPEED) {
@@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu,
enum qca_speed_type speed_type)
if (!speed)
return 0;
+ /* Deassert RTS while changing the baudrate of chip and host.
+* This will stop chip to transmit it response with an newer
+* baudrate until we change the baudarte.
nit: baudrate
re-nit (to consider if you respin anyway): 'This prevents the chip
from transmitting its response with the new baudrate while the host
port is still operating at the old speed'?
(I'm not a native English speaker, probably there is still room for
improvement ;-)
[Bala]: will update.
Reviewed-by: Matthias Kaehlcke
--
Regards
Balakrishna.
Re: [PATCH] ptrace: take into account saved_sigmask in PTRACE_{GET,SET}SIGMASK
On Thu, Nov 22, 2018 at 12:47:52PM +0100, Oleg Nesterov wrote:
> On 11/19, Andrei Vagin wrote:
> >
> > case PTRACE_SETSIGMASK: {
> > sigset_t new_set;
> > @@ -962,6 +971,8 @@ int ptrace_request(struct task_struct *child, long
> > request,
> > child->blocked = new_set;
> > spin_unlock_irq(&child->sighand->siglock);
> >
> > + clear_tsk_restore_sigmask(child);
> > +
>
> I am not sure I understand this change...
>
> I forgot everything I knew about criu, but iiuc PTRACE_SETSIGMASK is used
> at "restore" time, doesn't this mean that TIF_RESTORE_SIGMASK/restore_sigmask
> can not be set?
PTRACE_SETSIGMASK isn't used on restore. On restore, criu generates
sigframe and calls sigreturn to restore registers, fpu state, sigmask
and resume a process. When the kernel constructs a signal frame, it
calls sigmask_to_save() to get a process signal mask. With this patch,
PTRACE_GETSIGMASK returns the same signal mask what is returned by
sigmask_to_save().
In CRIU, we don't need to set TIF_RESTORE_SIGMASK, because all processes
are dumped when they are in user-space.
>
> IOW, could you please explain how PTRACE_SETSIGMASK should be used, and why
> it doesn't do something like
>
CRIU uses PTRACE_SETSIGMASK when it injects a parasite code into a
target process. In this case, we have to be sure that when the process
is resumed by PTRACE_CONT, it will not start handling signals and
executing signal handlers.
> if (test_tsk_restore_sigmask(child))
> child->saved_sigmask = new_set;
> else
> child->blocked = new_set;
>
> which looks symmetrical to PTRACE_GETSIGMASK?
If we set child->saved_sigmask, the child can start handling signals
which are not set in child->blocked.
>
> Oleg.
>
RE: [PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
Forgot to mentioned: This patch is based on "[V4,3/5] arm64: dts: imx: add
imx8qxp support", https://patchwork.kernel.org/patch/10677311/
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年11月27日 14:19
> To: robh...@kernel.org; mark.rutl...@arm.com; Aisheng DONG
> ; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; shawn...@kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
>
> Add i.MX8QXP CPU thermal zone support.
>
> Signed-off-by: Anson Huang
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27
> +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index da99b6f..9155d45 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -9,6 +9,7 @@
> #include #include
> #include
> +#include
>
> #include "imx8-ca35.dtsi"
>
> @@ -85,6 +86,32 @@
> };
> };
>
> + tsens: thermal-sensor {
> + compatible = "nxp,imx8qxp-sc-thermal";
> + tsens-num = <1>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + thermal_zones: thermal-zones {
> + cpu-thermal0 {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = <&tsens 355>;
> + trips {
> + cpu_alert0: trip0 {
> + temperature = <107000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + cpu_crit0: trip1 {
> + temperature = <127000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> adma_subsys: bus@5900 {
> compatible = "simple-bus";
> #address-cells = <1>;
> --
> 2.7.4
Re: [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ
On Mon, Nov 26, 2018 at 08:56:50PM +, Michael Kelley wrote: > From: Greg KH Monday, November 26, 2018 11:57 AM > > > > > You created "null" hooks that do nothing, for no one in this patch > > > > series, why? > > > > > > > > > > hv_enable_vmbus_irq() and hv_disable_vmbus_irq() have non-null > > > implementations in the ARM64 code in patch 2 of this series. The > > > implementations are in the new file arch/arm64/hyperv/mshyperv.c. > > > Or am I misunderstanding your point? > > > > So you use a hook in an earlier patch and then add it in a later one? > > > > Shouldn't you do it the other way around? As it is, the earlier patch > > should not work properly, right? > > The earlier patch implements the hook on the ARM64 side but it is > unused -- it's not called. The later patch then calls it. Wouldn't the > other way around be backwards? Ah, it wasn't obvious that the previous patch added it at all, why not just make that addition part of this patch? > The general approach is for patches 1 and 2 of the series to provide > all the new code under arch/arm64 to enable Hyper-V. But the code > won't get called (or even built) with just these two patches because > CONFIG_HYPERV can't be selected. Patch 3 is separate because it > applies to architecture independent code and arch/x86 code -- I thought > there might be value in keeping the ARM64 and x86 patches distinct. > Patch 4 applies to architecture independent code, and enables the > ARM64 code in patches 1 and 2 to be compiled and run when > CONFIG_HYPERV is selected. > > If combining some of the patches in the series is a better approach, I'm > good with that. Ok, that makes more sense, if it is easier to get the ARM people to review this, that's fine. Doesn't seem like anyone did that yet :( sorry for the noise, greg k-h
[PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index da99b6f..9155d45 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "imx8-ca35.dtsi"
@@ -85,6 +86,32 @@
};
};
+ tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
adma_subsys: bus@5900 {
compatible = "simple-bus";
#address-cells = <1>;
--
2.7.4
[PATCH] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL by default. Signed-off-by: Anson Huang --- This patch is based on https://patchwork.kernel.org/patch/10677315/ arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d3aa3f7..6d224f7 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -376,6 +376,7 @@ CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=y CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_GEN3_THERMAL=y CONFIG_ARMADA_THERMAL=y -- 2.7.4
Re: KASAN: use-after-free Read in kvm_write_guest_offset_cached
On Tue, 27 Nov 2018 at 12:51, syzbot wrote: > > Hello, Is there beauty C codes? Regards, Wanpeng Li > > syzbot found the following crash on: > > HEAD commit:442b8cea2477 Add linux-next specific files for 20181109 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=174d326d40 > kernel config: https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8 > dashboard link: https://syzkaller.appspot.com/bug?extid=ff40b9bc4835ea83211c > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f5df7b40 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+ff40b9bc4835ea832...@syzkaller.appspotmail.com > > == > BUG: KASAN: use-after-free in mark_page_dirty_in_slot > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 [inline] > BUG: KASAN: use-after-free in kvm_write_guest_offset_cached+0x693/0x6b0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 > Read of size 8 at addr 8801b9363778 by task syz-executor1/30438 > > CPU: 1 PID: 30438 Comm: syz-executor1 Not tainted 4.20.0-rc1-next-20181109+ > #110 > 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+0x244/0x39d lib/dump_stack.c:113 > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > mark_page_dirty_in_slot arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 > [inline] > kvm_write_guest_offset_cached+0x693/0x6b0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 > kvm_steal_time_set_preempted arch/x86/kvm/x86.c:3241 [inline] > kvm_arch_vcpu_put+0x365/0x420 arch/x86/kvm/x86.c:3268 > kvm_sched_out+0x91/0xb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3993 > __fire_sched_out_preempt_notifiers kernel/sched/core.c:2503 [inline] > fire_sched_out_preempt_notifiers kernel/sched/core.c:2511 [inline] > prepare_task_switch kernel/sched/core.c:2617 [inline] > context_switch kernel/sched/core.c:2796 [inline] > __schedule+0x11ca/0x21d0 kernel/sched/core.c:3472 > preempt_schedule_irq+0xb9/0x140 kernel/sched/core.c:3699 > retint_kernel+0x1b/0x2d > RIP: 0010:search_memslots include/linux/kvm_host.h:955 [inline] > RIP: 0010:__gfn_to_memslot include/linux/kvm_host.h:976 [inline] > RIP: 0010:__kvm_gfn_to_hva_cache_init+0x2ed/0xd10 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1935 > Code: 3c 02 00 0f 85 0d 0a 00 00 4d 03 6c 24 08 48 89 df 4c 89 ee e8 04 16 > 78 00 4c 39 eb 0f 82 6e 01 00 00 45 31 ed e8 43 15 78 00 <44> 89 fe 44 89 > ef e8 c8 15 78 00 45 39 fd 0f 8d cf 00 00 00 e8 2a > RSP: 0018:8801cbfee970 EFLAGS: 0293 ORIG_RAX: ff13 > RAX: 8801b9a4c280 RBX: RCX: 8107942f > RDX: RSI: 8107936d RDI: 0006 > RBP: 8801cbfeeb60 R08: 8801b9a4c280 R09: ed00342bb209 > R10: ed00342bb209 R11: 8801a15d904b R12: 0017 > R13: 0017 R14: 0016 R15: 0017 > kvm_gfn_to_hva_cache_init+0x15a/0x340 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1963 > kvm_set_msr_common+0x1a0c/0x2670 arch/x86/kvm/x86.c:2549 > vmx_set_msr+0x759/0x1f90 arch/x86/kvm/vmx.c:4360 > kvm_set_msr+0x18a/0x370 arch/x86/kvm/x86.c:1324 > do_set_msr+0x10d/0x1a0 arch/x86/kvm/x86.c:1353 > __msr_io arch/x86/kvm/x86.c:2905 [inline] > msr_io+0x222/0x380 arch/x86/kvm/x86.c:2941 > kvm_arch_vcpu_ioctl+0x961/0x3b00 arch/x86/kvm/x86.c:3956 > kvm_vcpu_ioctl+0x278/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:509 [inline] > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl fs/ioctl.c:718 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457569 > Code: fd b3 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 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fc292e62c78 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 0003 RCX: 00457569 > RDX: 2280 RSI: 4008ae89 RDI: 0005 > RBP: 0072c040 R08: R09: > R10: R11: 0246 R12: 7fc292e636d4 > R13: 004bff9d R14: 004d0970 R15: > > Allocated by task 30427: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inlin
Re: [PATCH] watchdog: core: suppress "watchdog did not stop" message
On 11/26/18, 5:31 PM, "Jerry Hoemann" wrote: > Tao, > > If you're on a system running systemd, the default behavior is to > enable the watchdog during shutdown. This guards against shutdown hanging. > So this message will be routinely printed out during orderly shutdown. Thank you Jerry for the comments. I actually use a separate daemon process to kick the watchdog on my BMC system. The daemon monitors temperature sensors and other system states and kicks watchdog periodically: if the daemon gets stuck or exits, then the machine needs to reboot even if kernel/systemd is fine. Perhaps I need to look for a better/official way to manage the watchdog device.. BTW, I will be travelling abroad in the new few days and may not be able to reply emails timely. Thank you again for jumping in. Best regards, Tao Ren
Re: [PATCH v2 11/11] soc: mediatek: Add MT8183 scpsys support
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> Add scpsys driver for MT8183
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 227 +-
> 1 file changed, 226 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> b/drivers/soc/mediatek/mtk-scpsys.c
> index 80be2e05e4e0..aac76c45a681 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #define MTK_POLL_DELAY_US 10
> #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> @@ -397,7 +398,6 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> if (ret < 0)
> goto err_pwr_ack;
>
> -
Oh, this belongs in patch [04/11].
> val &= ~PWR_CLK_DIS_BIT;
> writel(val, ctl_addr);
>
> @@ -1179,6 +1179,217 @@ static const struct scp_subdomain
> scp_subdomain_mt8173[] = {
> {MT8173_POWER_DOMAIN_MFG_2D, MT8173_POWER_DOMAIN_MFG},
> };
>
> +/*
> + * MT8183 power domain support
> + */
> +
> +static const struct scp_domain_data scp_domain_data_mt8183[] = {
> + [MT8183_POWER_DOMAIN_AUDIO] = {
> + .name = "audio",
> + .sta_mask = PWR_STATUS_AUDIO,
> + .ctl_offs = 0x0314,
> + .sram_pdn_bits = GENMASK(11, 8),
> + .sram_pdn_ack_bits = GENMASK(15, 12),
> + .basic_clk_name = {"audio", "audio1", "audio2"},
> + },
> + [MT8183_POWER_DOMAIN_CONN] = {
> + .name = "conn",
> + .sta_mask = PWR_STATUS_CONN,
> + .ctl_offs = 0x032c,
> + .sram_pdn_bits = 0,
> + .sram_pdn_ack_bits = 0,
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(13) | BIT(14), BIT(13) | BIT(14)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
> + .name = "mfg_async",
> + .sta_mask = PWR_STATUS_MFG_ASYNC,
> + .ctl_offs = 0x0334,
> + .sram_pdn_bits = 0,
> + .sram_pdn_ack_bits = 0,
> + .basic_clk_name = {"mfg"},
> + },
> + [MT8183_POWER_DOMAIN_MFG] = {
> + .name = "mfg",
> + .sta_mask = PWR_STATUS_MFG,
> + .ctl_offs = 0x0338,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_CORE0] = {
> + .name = "mfg_core0",
> + .sta_mask = BIT(7),
> + .ctl_offs = 0x034c,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_CORE1] = {
> + .name = "mfg_core1",
> + .sta_mask = BIT(20),
> + .ctl_offs = 0x0310,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_2D] = {
> + .name = "mfg_2d",
> + .sta_mask = PWR_STATUS_MFG_2D,
> + .ctl_offs = 0x0348,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
> + BIT(19) | BIT(20) | BIT(21),
> + BIT(19) | BIT(20) | BIT(21)),
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(21) | BIT(22), BIT(21) | BIT(22)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_DISP] = {
> + .name = "disp",
> + .sta_mask = PWR_STATUS_DISP,
> + .ctl_offs = 0x030c,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + .basic_clk_name = {"mm"},
> + .subsys_clk_prefix = "mm",
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
> + BIT(16) | BIT(17), BIT(16) | BIT(17)),
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(10) | BIT(11), BIT(10) | BIT(11)),
> + BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
> + GENMASK(7, 0), GENMASK(7, 0)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_CAM] = {
> + .name = "cam",
> + .sta_mask = BIT(25),
> + .ctl_offs = 0x0344,
> + .sram_pdn_bits = GENMASK(9, 8),
> + .sram_pdn_ack_bits = GENMASK(13, 12),
> + .basic_clk_name = {"cam"},
> + .subsys_clk_prefix = "cam",
> + .bp_table
[PATCH 2/2] dt-bindings: thermal: add binding doc for i.MX system controller thermal driver
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
---
.../devicetree/bindings/thermal/imx-sc-thermal.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
new file mode 100644
index 000..2f5b0a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
@@ -0,0 +1,33 @@
+* Temperature Monitor (TEMPMON) on NXP i.MX SoCs with System Controller
+
+Required properties:
+- compatible : Must be "nxp,imx8qxp-sc-thermal";
+- tsens-num : Total number of thermal sensors supported;
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+
+Example:
+tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+};
+
+thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+};
--
2.7.4
[PATCH 1/2] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
drivers/thermal/Kconfig | 11 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 221 +++
3 files changed, 233 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 0e69edc..84e850c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -222,6 +222,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 610344e..1b13f6a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..2b34ce2
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ unsigned int resource_id;
+};
+
+struct imx_sc_thermal_data {
+ struct imx_sc_sensor *sensor;
+};
+
+struct imx_sc_msg_req_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct imx_sc_msg_resp_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_resp_misc_get_temp *resp;
+ struct imx_sc_msg_req_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr = &msg.hdr;
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.resource_id = sensor->resource_id;
+ msg.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, &msg, true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ resp = (struct imx_sc_msg_resp_misc_get_temp *)&msg;
+ *temp = resp->celsius * 1000 + resp->tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_register_sensor(struct platform_device *pdev,
+ struct imx_sc_sensor *sensor)
+{
+ struct thermal_zone_device *tzd;
+
+ tzd = devm_thermal_zone_of_sensor_register(&pdev->dev,
+ sensor->resource_id,
+ sensor,
+ &imx_sc_thermal_ops);
+ if (IS_ERR(tzd)) {
+ dev_err(&pdev->dev, "failed
Re: [PATCH v2 04/11] soc: mediatek: add new flow for mtcmos power.
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> From: Owen Chen
>
> Both MT8183 & MT6765 add more bus protect node than previous project,
> therefore we add two more register for setup bus protect, which reside
> at INFRA_CFG & SMI_COMMON.
>
> With the following change
> 1. bus protect need not only infracfg but smi_common registers involved
>to setup. Therefore we add a set/clr APIs with more customize arguments.
>
> The second change is that we also add subsys CG control flow before/after
> the bus protect/sram control, due to bus protect need SMI bus relative CGs
> enable to feed-back its ack, and some master's sram control need CG enable
> to on/off its resource sequentially.
>
> With the following change
> 1. turn on subsys CG before sram pwron and release bus protect.
> 2. turn off subsys CG after the process of set bus protect/receive
>ack/disable sram.
>
> The last change is for some power domains like vpu_core on MT8183 whose
> sram need to do clock and internal isolation while power on/off sram.
> We add a flag "sram_iso_ctrl" in scp_domain_data to judge if we need to
> do the extra sram isolation control or not.
>
> Signed-off-by: Owen Chen
> Signed-off-by: Mars Cheng
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/Makefile | 2 +-
> drivers/soc/mediatek/mtk-scpsys-ext.c | 99 +++
> drivers/soc/mediatek/mtk-scpsys.c | 379 +++-
> include/linux/soc/mediatek/scpsys-ext.h | 39 +++
> 4 files changed, 448 insertions(+), 71 deletions(-)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
> create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 12998b08819e..9dc6670c19cb 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> +obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys-ext.c
> b/drivers/soc/mediatek/mtk-scpsys-ext.c
> new file mode 100644
> index ..54df42db2a8f
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys-ext.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_POLL_DELAY_US 10
> +#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> +
> +static int set_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_set, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_set)
> + regmap_write(map, reg_set, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, mask);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, (val & ack_mask) == ack_mask,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +static int clear_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_clr, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_clr)
> + regmap_write(map, reg_clr, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, 0);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, !(val & ack_mask),
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_STEPS && bp_table[i].mask; i++) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = set_bus_protection(map,
> + bp_table[i].mask, bp_table[i].mask,
> + bp_table[i].set_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = MAX_STEPS - 1; i >= 0; i--) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
>
[PATCH v3 7/7] zram: writeback throttle
On small memory system, there are lots of write IO so if we use
flash device as swap, there would be serious flash wearout.
To overcome the problem, system developers need to design write
limitation strategy to guarantee flash health for entire product life.
This patch creates a new konb "writeback_limit" on zram. With that,
if current writeback IO count(/sys/block/zramX/io_stat) excceds
the limitation, zram stops further writeback until admin can reset
the limit.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 9 +
Documentation/blockdev/zram.txt| 2 +
drivers/block/zram/zram_drv.c | 47 +-
drivers/block/zram/zram_drv.h | 2 +
4 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 65fc33b2f53b..9d2339a485c8 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -121,3 +121,12 @@ Contact: Minchan Kim
The bd_stat file is read-only and represents backing device's
statistics (bd_count, bd_reads, bd_writes) in a format
similar to block layer statistics file format.
+
+What: /sys/block/zram/writeback_limit
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback_limit file is read-write and specifies the maximum
+ amount of writeback ZRAM can do. The limit could be changed
+ in run time and "0" means disable the limit.
+ No limit is the initial state.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 906df97527a7..64b61925e475 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -164,6 +164,8 @@ reset WOtrigger device reset
mem_used_max WOreset the `mem_used_max' counter (see later)
mem_limit WOspecifies the maximum amount of memory ZRAM can use
to store the compressed data
+writeback_limit WOspecifies the maximum amount of write IO zram can
+ write out to backing device as 4KB unit
max_comp_streams RWthe number of possible concurrent compress operations
comp_algorithmRWshow and change the compression algorithm
compact WOtrigger memory compaction
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 67168a6ecca6..58b025c5c83e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -330,6 +330,40 @@ static ssize_t idle_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
+
+static ssize_t writeback_limit_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ u64 val;
+ ssize_t ret = -EINVAL;
+
+ if (kstrtoull(buf, 10, &val))
+ return ret;
+
+ down_read(&zram->init_lock);
+ atomic64_set(&zram->stats.bd_wb_limit, val);
+ if (val == 0 || val > atomic64_read(&zram->stats.bd_writes))
+ zram->stop_writeback = false;
+ up_read(&zram->init_lock);
+ ret = len;
+
+ return ret;
+}
+
+static ssize_t writeback_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u64 val;
+ struct zram *zram = dev_to_zram(dev);
+
+ down_read(&zram->init_lock);
+ val = atomic64_read(&zram->stats.bd_wb_limit);
+ up_read(&zram->init_lock);
+
+ return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
+}
+
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
@@ -571,6 +605,7 @@ static ssize_t writeback_store(struct device *dev,
char mode_buf[8];
unsigned long mode = -1UL;
unsigned long blk_idx = 0;
+ u64 wb_count, wb_limit;
sz = strscpy(mode_buf, buf, sizeof(mode_buf));
if (sz <= 0)
@@ -612,6 +647,11 @@ static ssize_t writeback_store(struct device *dev,
bvec.bv_len = PAGE_SIZE;
bvec.bv_offset = 0;
+ if (zram->stop_writeback) {
+ ret = -EIO;
+ break;
+ }
+
if (!blk_idx) {
blk_idx = alloc_block_bdev(zram);
if (!blk_idx) {
@@ -670,7 +710,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
- atomic64_inc(&zram->stats.bd_writes);
+ wb_count = atomic64_inc_return(&zram->stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -694,6 +734,9 @@ static ssize_t writeback_store(struct device *dev,
[PATCH v3 2/7] zram: fix double free backing device
If blkdev_get fails, we shouldn't do blkdev_put. Otherwise,
kernel emits below log. This patch fixes it.
[ 31.073006] WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828
blkdev_put+0x105/0x120
[ 31.075104] Modules linked in:
[ 31.075898] CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453
[ 31.077484] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 31.079589] RIP: 0010:blkdev_put+0x105/0x120
[ 31.080606] Code: 48 c7 80 a0 00 00 00 00 00 00 00 48 c7 c7 40 e7 40 96 e8
6e 47 73 00 48 8b bb e0 00 00 00 e9 2c ff ff ff 0f 0b e9 75 ff ff ff <0f> 0b e9
5a ff ff ff 48 c7 80 a0 00 00 00 00 00 00 00 eb 87 0f 1f
[ 31.085080] RSP: 0018:b409005c7ed0 EFLAGS: 00010297
[ 31.086383] RAX: 9779fe5a8040 RBX: 9779fbc17300 RCX: b9fc37a4
[ 31.088105] RDX: 0001 RSI: RDI: 9640e740
[ 31.089850] RBP: 9779fbc17318 R08: 95499a89 R09: 0004
[ 31.091201] R10: b409005c7e50 R11: 7a9ef6088ff4d4a1 R12: 0083
[ 31.092276] R13: 9779fe607b98 R14: R15: 9779fe607a38
[ 31.093355] FS: 7fc118d9b840() GS:9779fc60()
knlGS:
[ 31.094582] CS: 0010 DS: ES: CR0: 80050033
[ 31.095541] CR2: 7fc11894b8dc CR3: 339f6001 CR4: 00160ef0
[ 31.096781] Call Trace:
[ 31.097212] __x64_sys_swapoff+0x46d/0x490
[ 31.097914] do_syscall_64+0x5a/0x190
[ 31.098550] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 31.099402] RIP: 0033:0x7fc11843ec27
[ 31.100013] Code: 73 01 c3 48 8b 0d 71 62 2c 00 f7 d8 64 89 01 48 83 c8 ff
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a8 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 41 62 2c 00 f7 d8 64 89 01 48
[ 31.103149] RSP: 002b:7ffdf69be648 EFLAGS: 0206 ORIG_RAX:
00a8
[ 31.104425] RAX: ffda RBX: 011d98c0 RCX: 7fc11843ec27
[ 31.105627] RDX: 0001 RSI: 0001 RDI: 011d98c0
[ 31.106847] RBP: 0001 R08: 7ffdf69be690 R09: 0001
[ 31.108038] R10: 02b1 R11: 0206 R12: 0001
[ 31.109231] R13: R14: R15:
[ 31.110433] irq event stamp: 4466
[ 31.111001] hardirqs last enabled at (4465): []
__free_pages_ok+0x1e3/0x490
[ 31.112437] hardirqs last disabled at (4466): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 31.113973] softirqs last enabled at (3420): []
__do_softirq+0x333/0x446
[ 31.115364] softirqs last disabled at (3407): []
irq_exit+0xd1/0xe0
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 21a7046958a3..d1459cc1159f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -387,8 +387,10 @@ static ssize_t backing_dev_store(struct device *dev,
bdev = bdgrab(I_BDEV(inode));
err = blkdev_get(bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL, zram);
- if (err < 0)
+ if (err < 0) {
+ bdev = NULL;
goto out;
+ }
nr_pages = i_size_read(inode) >> PAGE_SHIFT;
bitmap_sz = BITS_TO_LONGS(nr_pages) * sizeof(long);
--
2.20.0.rc0.387.gc7a69e6b6c-goog
[PATCH v3 4/7] zram: introduce ZRAM_IDLE flag
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo all > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by /sys/kernel/debug/zram/zram0/block_state.
30075.033841 ...i
30163.806904 s..i
30263.806919 ..hi
Once there is IO for the slot, the mark will be disappeared.
30075.033841 ...
30163.806904 s..i
30263.806919 ..hi
Therefore, 300th block is idle zpage. With this feature,
user can how many zram has idle pages which are waste of memory.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 +++
Documentation/blockdev/zram.txt| 10 ++--
drivers/block/zram/zram_drv.c | 57 --
drivers/block/zram/zram_drv.h | 1 +
4 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index c1513c756af1..04c9a5980bc7 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -98,3 +98,11 @@ Contact: Minchan Kim
The backing_dev file is read-write and set up backing
device for zram to write incompressible pages.
For using, user should enable CONFIG_ZRAM_WRITEBACK.
+
+What: /sys/block/zram/idle
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ idle file is write-only and mark zram slot as idle.
+ If system has mounted debugfs, user can see which slots
+ are idle via /sys/kernel/debug/zram/zram/block_state
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 3c1b5ab54bc0..f3bcd716d8a9 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -169,6 +169,7 @@ comp_algorithmRWshow and change the compression
algorithm
compact WOtrigger memory compaction
debug_statROthis file is used for zram debugging purposes
backing_dev RWset up backend storage for zram to write out
+idle WOmark allocated slot as idle
User space is advised to use the following files to read the device statistics.
@@ -251,16 +252,17 @@ pages of the process with*pagemap.
If you enable the feature, you could see block state via
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
- 30075.033841 .wh
- 30163.806904 s..
- 30263.806919 ..h
+ 30075.033841 .wh.
+ 30163.806904 s...
+ 30263.806919 ..hi
First column is zram's block index.
Second column is access time since the system was booted
Third column is state of the block.
(s: same page
w: written page to backing store
-h: huge page)
+h: huge page
+i: idle page)
First line of above example says 300th block is accessed at 75.033841sec
and the block's state is huge so it is written back to the backing
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4457d0395bfb..180613b478a6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -281,6 +281,47 @@ static ssize_t mem_used_max_store(struct device *dev,
return len;
}
+static ssize_t idle_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
+ int index;
+ char mode_buf[8];
+ ssize_t sz;
+
+ sz = strscpy(mode_buf, buf, sizeof(mode_buf));
+ if (sz <= 0)
+ return -EINVAL;
+
+ /* ignore trailing new line */
+ if (mode_buf[sz - 1] == '\n')
+ mode_buf[sz - 1] = 0x00;
+
+ if (strcmp(mode_buf, "all"))
+ return -EINVAL;
+
+ down_read(&zram->init_lock);
+ if (!init_done(zram)) {
+ up_read(&zram->init_lock);
+ return -EINVAL;
+ }
+
+ for (index = 0; index < nr_pages; index++) {
+ zram_slot_lock(zram, index);
+ if (!zram_allocated(zram, index))
+ goto next;
+
+ zram_set_flag(zram, index, ZRAM_IDLE);
+next:
+ zram_slot_unlock(zram, index);
+ }
+
+ up_read(&zram->init_lock);
+
+ return len;
+}
+
#ifdef CONFIG_ZRAM_WRITEBACK
static void reset_bdev(struct zram *zram)
{
@@ -638,6 +679,7 @@ static void zram_debugfs_destroy(void)
static void zram_accessed(struct zram *zram, u32 index)
{
+ zram_clear_flag(zram, index, ZRAM_IDLE);
zram->table[index].ac_time = ktime_get_boottime();
}
@@ -670,12 +712,13 @@ static ssize_t read_block_state(struct file *file, char
__user *buf,
ts = k
[PATCH v3 1/7] zram: fix lockdep warning of free block handling
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 254.521732] b1828693 (&(&zram->bitmap_lock)->rlock){+.?.}, at:
put_entry_bdev+0x1e/0x50
[ 254.521732] {SOFTIRQ-ON-W} state was registered at:
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] zram_make_request+0x755/0xdc9
[ 254.521732] generic_make_request+0x373/0x6a0
[ 254.521732] submit_bio+0x6c/0x140
[ 254.521732] __swap_writepage+0x3a8/0x480
[ 254.521732] shrink_page_list+0x1102/0x1a60
[ 254.521732] shrink_inactive_list+0x21b/0x3f0
[ 254.521732] shrink_node_memcg.constprop.99+0x4f8/0x7e0
[ 254.521732] shrink_node+0x7d/0x2f0
[ 254.521732] do_try_to_free_pages+0xe0/0x300
[ 254.521732] try_to_free_pages+0x116/0x2b0
[ 254.521732] __alloc_pages_slowpath+0x3f4/0xf80
[ 254.521732] __alloc_pages_nodemask+0x2a2/0x2f0
[ 254.521732] __handle_mm_fault+0x42e/0xb50
[ 254.521732] handle_mm_fault+0x55/0xb0
[ 254.521732] __do_page_fault+0x235/0x4b0
[ 254.521732] page_fault+0x1e/0x30
[ 254.521732] irq event stamp: 228412
[ 254.521732] hardirqs last enabled at (228412): []
__slab_free+0x3e6/0x600
[ 254.521732] hardirqs last disabled at (228411): []
__slab_free+0x1c5/0x600
[ 254.521732] softirqs last enabled at (228396): []
__do_softirq+0x31e/0x427
[ 254.521732] softirqs last disabled at (228403): []
irq_exit+0xd1/0xe0
[ 254.521732]
[ 254.521732] other info that might help us debug this:
[ 254.521732] Possible unsafe locking scenario:
[ 254.521732]
[ 254.521732]CPU0
[ 254.521732]
[ 254.521732] lock(&(&zram->bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] lock(&(&zram->bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] *** DEADLOCK ***
[ 254.521732]
[ 254.521732] no locks held by zram_verify/2095.
[ 254.521732]
[ 254.521732] stack backtrace:
[ 254.521732] CPU: 5 PID: 2095 Comm: zram_verify Not tainted 4.19.0+ #390
[ 254.521732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 254.521732] Call Trace:
[ 254.521732]
[ 254.521732] dump_stack+0x67/0x9b
[ 254.521732] print_usage_bug+0x1bd/0x1d3
[ 254.521732] mark_lock+0x4aa/0x540
[ 254.521732] ? check_usage_backwards+0x160/0x160
[ 254.521732] __lock_acquire+0x51d/0x1300
[ 254.521732] ? free_debug_processing+0x24e/0x400
[ 254.521732] ? bio_endio+0x6d/0x1a0
[ 254.521732] ? lockdep_hardirqs_on+0x9b/0x180
[ 254.521732] ? lock_acquire+0x90/0x180
[ 254.521732] lock_acquire+0x90/0x180
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] put_entry_bdev+0x1e/0x50
[ 254.521732] zram_free_page+0xf6/0x110
[ 254.521732] zram_slot_free_notify+0x42/0xa0
[ 254.521732] end_swap_bio_read+0x5b/0x170
[ 254.521732] blk_update_request+0x8f/0x340
[ 254.521732] scsi_end_request+0x2c/0x1e0
[ 254.521732] scsi_io_completion+0x98/0x650
[ 254.521732] blk_done_softirq+0x9e/0xd0
[ 254.521732] __do_softirq+0xcc/0x427
[ 254.521732] irq_exit+0xd1/0xe0
[ 254.521732] do_IRQ+0x93/0x120
[ 254.521732] common_interrupt+0xf/0xf
[ 254.521732]
With writeback feature, zram_slot_free_notify could be called
in softirq context by end_swap_bio_read. However, bitmap_lock
is not aware of that so lockdep yell out. Thanks.
get_entry_bdev
spin_lock(bitmap->lock);
irq
softirq
end_swap_bio_read
zram_slot_free_notify
zram_slot_lock <-- deadlock prone
zram_free_page
put_entry_bdev
spin_lock(bitmap->lock); <-- deadlock prone
With akpm's suggestion(i.e. bitmap operation is already atomic),
we could remove bitmap lock. It might fail to find a empty slot
if serious contention happens. However, it's not severe problem
because huge page writeback has already possiblity to fail if there
is severe memory pressure. Worst case is just keeping
the incompressible in memory, not storage.
The other problem is zram_slot_lock in zram_slot_slot_free_notify.
To make it safe is this patch introduces zram_slot_trylock where
zram_slot_free_notify uses it. Although it's rare to be contented,
this patch adds new debug stat "miss_free" to keep monitoring
how often it happens.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 38 +++
drivers/block/zram/zram_drv.h | 2 +-
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4879595200e1..21a7046958a3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -53,6 +53,11 @@ static size_t huge_class_size;
static void zram_free_page(struct zram *zram, size_t index);
+static int zram_slot_trylock(struct zram *zram, u32 index)
+{
+ return bit_spin
[PATCH v3 3/7] zram: refactoring flags and writeback stuff
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
drivers/block/zram/zram_drv.h | 8 +--
2 files changed, 44 insertions(+), 69 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index d1459cc1159f..4457d0395bfb 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -55,17 +55,17 @@ static void zram_free_page(struct zram *zram, size_t index);
static int zram_slot_trylock(struct zram *zram, u32 index)
{
- return bit_spin_trylock(ZRAM_LOCK, &zram->table[index].value);
+ return bit_spin_trylock(ZRAM_LOCK, &zram->table[index].flags);
}
static void zram_slot_lock(struct zram *zram, u32 index)
{
- bit_spin_lock(ZRAM_LOCK, &zram->table[index].value);
+ bit_spin_lock(ZRAM_LOCK, &zram->table[index].flags);
}
static void zram_slot_unlock(struct zram *zram, u32 index)
{
- bit_spin_unlock(ZRAM_LOCK, &zram->table[index].value);
+ bit_spin_unlock(ZRAM_LOCK, &zram->table[index].flags);
}
static inline bool init_done(struct zram *zram)
@@ -76,7 +76,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
zram->table[index].handle;
}
@@ -99,19 +99,19 @@ static void zram_set_handle(struct zram *zram, u32 index,
unsigned long handle)
static bool zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- return zram->table[index].value & BIT(flag);
+ return zram->table[index].flags & BIT(flag);
}
static void zram_set_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value |= BIT(flag);
+ zram->table[index].flags |= BIT(flag);
}
static void zram_clear_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value &= ~BIT(flag);
+ zram->table[index].flags &= ~BIT(flag);
}
static inline void zram_set_element(struct zram *zram, u32 index,
@@ -127,15 +127,15 @@ static unsigned long zram_get_element(struct zram *zram,
u32 index)
static size_t zram_get_obj_size(struct zram *zram, u32 index)
{
- return zram->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
+ return zram->table[index].flags & (BIT(ZRAM_FLAG_SHIFT) - 1);
}
static void zram_set_obj_size(struct zram *zram,
u32 index, size_t size)
{
- unsigned long flags = zram->table[index].value >> ZRAM_FLAG_SHIFT;
+ unsigned long flags = zram->table[index].flags >> ZRAM_FLAG_SHIFT;
- zram->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
+ zram->table[index].flags = (flags << ZRAM_FLAG_SHIFT) | size;
}
#if PAGE_SIZE != 4096
@@ -282,16 +282,11 @@ static ssize_t mem_used_max_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
-static bool zram_wb_enabled(struct zram *zram)
-{
- return zram->backing_dev;
-}
-
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
- if (!zram_wb_enabled(zram))
+ if (!zram->backing_dev)
return;
bdev = zram->bdev;
@@ -318,7 +313,7 @@ static ssize_t backing_dev_show(struct device *dev,
ssize_t ret;
down_read(&zram->init_lock);
- if (!zram_wb_enabled(zram)) {
+ if (!zram->backing_dev) {
memcpy(buf, "none\n", 5);
up_read(&zram->init_lock);
return 5;
@@ -447,7 +442,7 @@ static ssize_t backing_dev_store(struct device *dev,
return err;
}
-static unsigned long get_entry_bdev(struct zram *zram)
+static unsigned long alloc_block_bdev(struct zram *zram)
{
unsigned long blk_idx = 1;
retry:
@@ -462,11 +457,11 @@ static unsigned long get_entry_bdev(struct zram *zram)
return blk_idx;
}
-static void put_entry_bdev(struct zram *zram, unsigned long entry)
+static void free_block_bdev(struct zram *zram, unsigned long blk_idx)
{
int was_set;
- was_set = test_and_clear_bit(entry, zram->bitmap);
+ was_set = test_and_clear_bit(blk_idx, zram->bitmap);
WARN_ON_ONCE(!was_set);
}
@@ -579,7 +574,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio)
return -ENOMEM;
- entry = get_entry_bdev(zram);
+ entry = alloc_block_bdev(zram);
if (!entry) {
bio_put(bio);
return -ENOSPC;
@@ -590,7 +585,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio_add_page(bio, bvec->bv_page, bvec->bv_len,
[PATCH v3 6/7] zram: add bd_stat statistics
bd_stat represents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
Documentation/blockdev/zram.txt| 11
drivers/block/zram/zram_drv.c | 29 ++
drivers/block/zram/zram_drv.h | 5
4 files changed, 53 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index d1f80b077885..65fc33b2f53b 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -113,3 +113,11 @@ Contact: Minchan Kim
Description:
The writeback file is write-only and trigger idle and/or
huge page writeback to backing device.
+
+What: /sys/block/zram/bd_stat
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The bd_stat file is read-only and represents backing device's
+ statistics (bd_count, bd_reads, bd_writes) in a format
+ similar to block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 806cdaabac83..906df97527a7 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -221,6 +221,17 @@ The stat file represents device's mm statistics. It
consists of a single
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
+File /sys/block/zram/bd_stat
+
+The stat file represents device's backing device statistics. It consists of
+a single line of text and contains the following stats separated by whitespace:
+ bd_count size of data written in backing device.
+ Unit: 4K bytes
+ bd_reads the number of reads from backing device
+ Unit: 4K bytes
+ bd_writes the number of writes to backing device
+ Unit: 4K bytes
+
9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 6b5a886c8f32..67168a6ecca6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -502,6 +502,7 @@ static unsigned long alloc_block_bdev(struct zram *zram)
if (test_and_set_bit(blk_idx, zram->bitmap))
goto retry;
+ atomic64_inc(&zram->stats.bd_count);
return blk_idx;
}
@@ -511,6 +512,7 @@ static void free_block_bdev(struct zram *zram, unsigned
long blk_idx)
was_set = test_and_clear_bit(blk_idx, zram->bitmap);
WARN_ON_ONCE(!was_set);
+ atomic64_dec(&zram->stats.bd_count);
}
static void zram_page_end_io(struct bio *bio)
@@ -668,6 +670,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
+ atomic64_inc(&zram->stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -757,6 +760,7 @@ static int read_from_bdev_sync(struct zram *zram, struct
bio_vec *bvec,
static int read_from_bdev(struct zram *zram, struct bio_vec *bvec,
unsigned long entry, struct bio *parent, bool sync)
{
+ atomic64_inc(&zram->stats.bd_reads);
if (sync)
return read_from_bdev_sync(zram, bvec, entry, parent);
else
@@ -1013,6 +1017,25 @@ static ssize_t mm_stat_show(struct device *dev,
return ret;
}
+#ifdef CONFIG_ZRAM_WRITEBACK
+static ssize_t bd_stat_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+ ssize_t ret;
+
+ down_read(&zram->init_lock);
+ ret = scnprintf(buf, PAGE_SIZE,
+ "%8llu %8llu %8llu\n",
+ (u64)atomic64_read(&zram->stats.bd_count),
+ (u64)atomic64_read(&zram->stats.bd_reads),
+ (u64)atomic64_read(&zram->stats.bd_writes));
+ up_read(&zram->init_lock);
+
+ return ret;
+}
+#endif
+
static ssize_t debug_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1033,6 +1056,9 @@ static ssize_t debug_stat_show(struct device *dev,
static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
+#ifdef CONFIG_ZRAM_WRITEBACK
+static DEVICE_ATTR_RO(bd_stat);
+#endif
static DEVICE_ATTR_RO(debug_stat);
static void zram_meta_free(struct zram *zram, u64 disksize)
@@ -1759,6 +1785,9 @@ static struct attribute *zram_disk_attrs[] = {
#endif
&dev_attr_io_stat.attr,
&dev_attr_mm_stat.attr,
+#ifdef CONFIG_ZRAM_WRITEBACK
+ &dev_attr_bd_stat.attr,
+#endif
&dev_attr_debug_stat.attr,
NU
[PATCH v3 5/7] zram: support idle/huge page writeback
This patch supports new feature "zram idle/huge page writeback".
On zram-swap usecase, zram has usually many idle/huge swap pages.
It's pointless to keep in memory(ie, zram).
To solve the problem, this feature introduces idle/huge page
writeback to backing device so the goal is to save more memory
space on embedded system.
Normal sequence to use idle/huge page writeback feature is as follows,
while (1) {
# mark allocated zram slot to idle
echo all > /sys/block/zram0/idle
# leave system working for several hours
# Unless there is no access for some blocks on zram,
# they are still IDLE marked pages.
echo "idle" > /sys/block/zram0/writeback
or/and
echo "huge" > /sys/block/zram0/writeback
# write the IDLE or/and huge marked slot into backing device
# and free the memory.
}
By per discussion:
https://lore.kernel.org/lkml/20181122065926.GG3441@jagdpanzerIV/T/#u,
This patch removes direct incommpressibe page writeback feature
(d2afd25114f4, zram: write incompressible pages to backing device)
so we could regard it as regression because incompressible pages
doesn't go to backing storage automatically. Instead, usre should
do it via "echo huge" > /sys/block/zram/writeback" manually.
If we hear some regression, we could restore the function.
Reviewed-by: Joey Pabalinas
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 7 +
Documentation/blockdev/zram.txt| 28 ++-
drivers/block/zram/Kconfig | 5 +-
drivers/block/zram/zram_drv.c | 247 +++--
drivers/block/zram/zram_drv.h | 1 +
5 files changed, 209 insertions(+), 79 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 04c9a5980bc7..d1f80b077885 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -106,3 +106,10 @@ Contact: Minchan Kim
idle file is write-only and mark zram slot as idle.
If system has mounted debugfs, user can see which slots
are idle via /sys/kernel/debug/zram/zram/block_state
+
+What: /sys/block/zram/writeback
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback file is write-only and trigger idle and/or
+ huge page writeback to backing device.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index f3bcd716d8a9..806cdaabac83 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -238,11 +238,31 @@ The stat file represents device's mm statistics. It
consists of a single
= writeback
-With incompressible pages, there is no memory saving with zram.
-Instead, with CONFIG_ZRAM_WRITEBACK, zram can write incompressible page
+With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page
to backing storage rather than keeping it in memory.
-User should set up backing device via /sys/block/zramX/backing_dev
-before disksize setting.
+To use the feature, admin should set up backing device via
+
+ "echo /dev/sda5 > /sys/block/zramX/backing_dev"
+
+before disksize setting. It supports only partition at this moment.
+If admin want to use incompressible page writeback, they could do via
+
+ "echo huge > /sys/block/zramX/write"
+
+To use idle page writeback, first, user need to declare zram pages
+as idle.
+
+ "echo all > /sys/block/zramX/idle"
+
+From now on, any pages on zram are idle pages. The idle mark
+will be removed until someone request access of the block.
+IOW, unless there is access request, those pages are still idle pages.
+
+Admin can request writeback of those idle pages at right timing via
+
+ "echo idle > /sys/block/zramX/writeback"
+
+With the command, zram writeback idle pages from memory to the storage.
= memory tracking
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index fcd055457364..1ffc64770643 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -15,7 +15,7 @@ config ZRAM
See Documentation/blockdev/zram.txt for more information.
config ZRAM_WRITEBACK
- bool "Write back incompressible page to backing device"
+ bool "Write back incompressible or idle page to backing device"
depends on ZRAM
help
With incompressible page, there is no memory saving to keep it
@@ -23,6 +23,9 @@ config ZRAM_WRITEBACK
For this feature, admin should set up backing device via
/sys/block/zramX/backing_dev.
+With /sys/block/zramX/{idle,writeback}, application could ask
+idle page's writeback to the backing device to save in memory.
+
See Documentation/blockdev/zram.txt for more information.
config ZRAM_MEMORY_TRACKING
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
ind
[PATCH v3 0/7] zram idle page writeback
Inherently, swap device has many idle pages which are rare touched since it was allocated. It is never problem if we use storage device as swap. However, it's just waste for zram-swap. This patchset supports zram idle page writeback feature. * Admin can define what is idle page "no access since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Below first two patches are -stable material so it could go first separately with others in this series. zram: fix lockdep warning of free block handling zram: fix double free backing device * from v2 - use strscpy instead of strlcpy - Joey Pabalinas - remove irqlock for bitmap op - akpm - don't use page as stat unit - akpm * from v1 - add fix dobule free backing device - minchan - change writeback/idle interface - minchan - remove direct incompressible page writeback - sergey Minchan Kim (7): zram: fix lockdep warning of free block handling zram: fix double free backing device zram: refactoring flags and writeback stuff zram: introduce ZRAM_IDLE flag zram: support idle/huge page writeback zram: add bd_stat statistics zram: writeback throttle Documentation/ABI/testing/sysfs-block-zram | 32 ++ Documentation/blockdev/zram.txt| 51 ++- drivers/block/zram/Kconfig | 5 +- drivers/block/zram/zram_drv.c | 501 +++-- drivers/block/zram/zram_drv.h | 19 +- 5 files changed, 446 insertions(+), 162 deletions(-) -- 2.20.0.rc0.387.gc7a69e6b6c-goog
Re: [snd_hda_intel] snd_hda_intel causes high CPU lockup and system instability if mic disabled in BIOS on Lenovo P50
On Mon, 26 Nov 2018, Takashi Iwai wrote: On Mon, 26 Nov 2018 00:17:15 +0100, Alexander Kappner wrote: My Lenovo P50 laptop has a BIOS option to disable the microphone. When this option gets chosen, the snd_hda_intel driver causes high CPU load on a single kworker thread, spinning on "process_unsol_events", and system instability. This behavior occurs from the time that the snd_hda_intel module is loaded, irrespective of whether anything is attempting to access the mic. The sound output still works. When in this state, the module cannot be removed cleanly; attempting to remove it (even without rmmod -f) triggers an oops. I have attached two exemplary dmesg outputs. Strangely enough, the exact location of the oops varies, but further up the call chain, I always see process_unsol_events. When the mic is not disabled in the BIOS, the module works stable, regardless whether or not the mic is muted in ALSA. I wasn't able to pinpoint the root cause. Any pointers on where to start? Much appreciated. Could you load snd-hda-intel driver with probe_only=1 option, and give alsa-info.sh output (run it with --no-upload option)? This should leave only the codec probing without configuring, so we can see the codec widget contents and check the emulator. thanks, Takashi Hi Takashi, thank you for looking into this. Please see quoted below the output of alsa-info.sh (after "modprobe snd_hda_intel probe_only=1"). Best regards upload=true&script=true&cardinfo= !! !!ALSA Information Script v 0.4.64 !! !!Script ran on: Tue Nov 27 05:25:14 UTC 2018 !!Linux Distribution !!-- Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" ID=debian HOME_URL="http://www.debian.org/"; SUPPORT_URL="http://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; !!DMI Information !!--- Manufacturer: LENOVO Product Name: 20ENCTO1WW Product Version: ThinkPad P50 Firmware Version: N1EET62W (1.35 ) Board Vendor: LENOVO Board Name:20ENCTO1WW !!ACPI Device Status Information !!--- /sys/bus/acpi/devices/ACPI0003:00/status 15 /sys/bus/acpi/devices/LEN0068:00/status 15 /sys/bus/acpi/devices/LNXPOWER:00/status 1 /sys/bus/acpi/devices/LNXPOWER:01/status 1 /sys/bus/acpi/devices/LNXPOWER:02/status 1 /sys/bus/acpi/devices/LNXPOWER:03/status 1 /sys/bus/acpi/devices/LNXVIDEO:00/status 15 /sys/bus/acpi/devices/PNP0103:00/status 15 /sys/bus/acpi/devices/PNP0C0A:00/status 31 /sys/bus/acpi/devices/PNP0C0F:00/status 9 /sys/bus/acpi/devices/PNP0C0F:01/status 9 /sys/bus/acpi/devices/PNP0C0F:02/status 9 /sys/bus/acpi/devices/PNP0C0F:03/status 9 /sys/bus/acpi/devices/PNP0C0F:04/status 9 /sys/bus/acpi/devices/PNP0C0F:05/status 9 /sys/bus/acpi/devices/PNP0C0F:06/status 9 /sys/bus/acpi/devices/PNP0C0F:07/status 9 /sys/bus/acpi/devices/device:3e/status 15 !!Kernel Information !!-- Kernel release:4.19.0-rc4 Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k4.19.0-rc4 Library version:1.0.28 Utilities version: 1.0.28 !!Loaded ALSA modules !!--- !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - No !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc494 irq 151 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xc300 irq 17 !!PCI Soundcards installed in the system !!-- 00:1f.3 Audio device: Intel Corporation Device a170 (rev 31) 01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1f.3 0403: 8086:a170 (rev 31) Subsystem: 17aa:222e -- 01:00.1 0403: 10de:0fbc (rev a1) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 !!Loaded sound module options !!--- !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ID 298 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0298 Subsystem Id: 0x17aa222e Revision Id: 0x100103 No Modem Function Group found Default PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default
Re: [PATCH] fs: Make /proc/sys inodes be owned by global root.
Luis Chamberlain writes:
> On Mon, Nov 26, 2018 at 06:26:07PM +0100, Radoslaw Burny wrote:
>> Due to a recent commit (d151ddc00498 - fs: Update i_[ug]id_(read|write)
>> to translate relative to s_user_ns),
>
> Recent? This is commit is from 2014 and present upstream since v4.8.
> And the commit ID you mentioned in your commit log seems to be
> incorrect. I get:
>
> 81754357770ebd900801231e7bc8d151ddc00498a fs: Update i_[ug]id_(read|write) to
> translate relative to s_user_ns
>
>> inodes under /proc/sys have -1
>> written to their i_uid/i_gid members if a containing userns does not
>> have entries for root in the uid/gid_map.
>
> Thanks for the description of how to run into the issue described but
> is there also a practical use case today where this is happening? I ask
> as it would be good to know the severity of the issue in the real world
> today.
People trying to run containers without a root user in the container.
It atypical but something doable.
>> This wouldn't normally matter, because these values are not used for
>> access checks. However, a later change (0bd23d09b874 - Don't modify
>> inodes with a uid or gid unknown to the vfs) changes the kernel to
>> prevent opens for write if the i_uid/i_gid field in the inode is -1,
>> even if the /proc/sys-specific access checks would otherwise pass.
>>
>> This causes a problem: in a userns without root mapping, even the
>> namespace creator cannot write to e.g. /proc/sys/kernel/shmmax.
>> This change fixes the problem by overriding i_uid/i_gid back to
>> GLOBAL_ROOT_UID/GID.
>
> We really need Seth and Eric to provide guidance here as they were
> the ones devising this long ago, but to me your solution seems backward.
> Why allow any namespace to muck with /proc/sys/ seettings?
There are many per namespace sysctls. Most of them are in the
networking stack.
> Let's recall that this case was a corner case, and writeback was the
> biggest concern, and for that it was decided that you'd simply not get
> write access, and so its read only. Its not clear to me if things like
> proc were considered. For the regular file case the situation can be
> addressed with chown, however we can't chown proc files.
>
>> Tested: Used a repro program that creates a user namespace without any
>> mapping and stat'ed /proc/$PID/root/proc/sys/kernel/shmmax from outside.
>> Before the change, it shows uid/gid of 65534,
>
> I thought you said it would be uid/gid -1 without your patch?
It is INVALID_UID/INVALID_GID. It is an over simplifcation to call
them -1. As they are not a valid value and are never mapped in any
user namespace they are displayed as the overflow_uid or overflow_gid
which is 65534 by default.
>> with the change it's 0.
>
> Note that a good way to also test issues is with the lib/test_sysctl.c
> module and the tools/testing/selftests/sysctl/sysctl.sh script, so if
> you can device a test there, once we decide what to do that would be
> appreciated.
We spoke about this at LPC. And this is the correct behavioral change.
The problem is there is a default value for i_uid and i_gid that is
correct in the general case. That default value is not corect for
sysctl, because proc is weird. As the sysctl permission check in
test_perm are all against GLOBAL_ROOT_UID and GLOBAL_ROOT_GID we did not
notice that i_uid and i_gid were being set wrong.
So all this patch does is fix the default values i_uid and i_gid.
The commit comment seems worth cleaning up. But for the
content of the code.
I expect when I have a few moments I will pick this change up.
Reviewed-by: "Eric W. Biederman"
Eric
>> Signed-off-by: Radoslaw Burny
>> ---
>> fs/proc/proc_sysctl.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
>> index c5cbbdff3c3d..67379a389658 100644
>> --- a/fs/proc/proc_sysctl.c
>> +++ b/fs/proc/proc_sysctl.c
>> @@ -499,6 +499,10 @@ static struct inode *proc_sys_make_inode(struct
>> super_block *sb,
>>
>> if (root->set_ownership)
>> root->set_ownership(head, table, &inode->i_uid, &inode->i_gid);
>> +else {
>> +inode->i_uid = GLOBAL_ROOT_UID;
>> +inode->i_gid = GLOBAL_ROOT_GID;
>> +}
>>
>> out:
>> return inode;
>> --
>> 2.20.0.rc0.387.gc7a69e6b6c-goog
>>
RE: [PATCH 2/2] Drivers: hv: vmbus: offload the handling of channels to two workqueues
> -Original Message-
> From: Greg KH
> Sent: Monday, November 26, 2018 11:35 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen
> Hemminger ; Michael Kelley
> ; vkuznets ; Haiyang
> Zhang ; sta...@vger.kernel.org
> Subject: Re: [PATCH 2/2] Drivers: hv: vmbus: offload the handling of channels
> to two workqueues
>
> On Mon, Nov 26, 2018 at 02:29:57AM +, k...@linuxonhyperv.com wrote:
> > From: Dexuan Cui
> >
> > vmbus_process_offer() mustn't call channel->sc_creation_callback()
> > directly for sub-channels, because sc_creation_callback() ->
> > vmbus_open() may never get the host's response to the
> > OPEN_CHANNEL message (the host may rescind a channel at any time,
> > e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
> > may not wake up the vmbus_open() as it's blocked due to a non-zero
> > vmbus_connection.offer_in_progress, and finally we have a deadlock.
> >
> > The above is also true for primary channels, if the related device
> > drivers use sync probing mode by default.
> >
> > And, usually the handling of primary channels and sub-channels can
> > depend on each other, so we should offload them to different
> > workqueues to avoid possible deadlock, e.g. in sync-probing mode,
> > NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
> > rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
> > and waits for all the sub-channels to appear, but the latter
> > can't get the rtnl_lock and this blocks the handling of sub-channels.
> >
> > The patch can fix the multiple-NIC deadlock described above for
> > v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
> > of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
> > but don't enable async-probing for Hyper-V drivers (yet).
> >
> > The patch can also fix the hang issue in sub-channel's handling described
> > above for all versions of kernels, including v4.19 and v4.20-rc3.
> >
> > So the patch should be applied to all the existing kernels.
> >
> > Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> > Cc: sta...@vger.kernel.org
> > Cc: Stephen Hemminger
> > Cc: K. Y. Srinivasan
> > Cc: Haiyang Zhang
> > Signed-off-by: Dexuan Cui
> > Signed-off-by: K. Y. Srinivasan
> > ---
> > drivers/hv/channel_mgmt.c | 188 +-
>
> > drivers/hv/connection.c | 24 -
> > drivers/hv/hyperv_vmbus.h | 7 ++
> > include/linux/hyperv.h| 7 ++
> > 4 files changed, 161 insertions(+), 65 deletions(-)
>
> As Sasha pointed out, this patch does not even apply :(
Sorry about that. These patches applied cleanly on my tree (misc-next).
This series is to be applied on top of
patch 0001-Drivers-hv-vmbus-Remove-the-useless-API-vmbus_get_ou.patch
While the patch 0001-Drivers-hv-vmbus-Remove-the-useless-API-vmbus_get_ou.patch
has been committed to the char-misc-testing branch, it is not in the misc-linus
branch and
that is the reason for this problem.
Regards,
K. Y
>
Re: [PATCH v2 01/11] clk: mediatek: add new clkmux register API
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> From: Owen Chen
>
> On both MT8183 & MT6765, there add "set/clr" register for
> each clkmux setting, and one update register to trigger value change.
> It is designed to prevent read-modify-write racing issue.
> The sw design need to add a new API to handle this hw change with
> a new mtk_clk_mux/mtk_mux struct in new file "clk-mux.c", "clk-mux.h".
>
> Signed-off-by: Owen Chen
> Signed-off-by: Weiyi Lu
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-mux.c | 240 +
> drivers/clk/mediatek/clk-mux.h | 101 ++
> 3 files changed, 342 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/mediatek/clk-mux.c
> create mode 100644 drivers/clk/mediatek/clk-mux.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 844b55d2770d..b97980dbb738 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
> clk-apmixed.o clk-cpumux.o reset.o
> +obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
> clk-apmixed.o clk-cpumux.o reset.o clk-mux.o
> obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
> obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
> obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
> diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c
> new file mode 100644
> index ..8618e5fa2b30
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mux.c
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +#include "clk-mux.h"
> +
> +static inline struct mtk_clk_mux
> + *to_mtk_clk_mux(struct clk_hw *hw)
nit: this fits in one line
> +{
> + return container_of(hw, struct mtk_clk_mux, hw);
> +}
> +
> +static int mtk_clk_mux_enable(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = BIT(mux->gate_shift);
> +
> + return regmap_update_bits(mux->regmap, mux->mux_ofs, mask, 0);
> +}
> +
> +static void mtk_clk_mux_disable(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = BIT(mux->gate_shift);
> +
> + regmap_update_bits(mux->regmap, mux->mux_ofs, mask, mask);
> +}
> +
> +static int mtk_clk_mux_enable_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 val;
> +
> + val = BIT(mux->gate_shift);
> +
nit: No blank line here. Or at least be consistent with what
mtk_clk_mux_disable_setclr does below.
Also, put everything on one line:
u32 val = BIT(mux->gate_shift);
(or, again, at least be self-consistent)
> + return regmap_write(mux->regmap, mux->mux_clr_ofs, val);
> +}
> +
> +static void mtk_clk_mux_disable_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 val;
> +
> + val = BIT(mux->gate_shift);
> + regmap_write(mux->regmap, mux->mux_set_ofs, val);
> +}
> +
> +static int mtk_clk_mux_is_enabled(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 val;
> +
> + regmap_read(mux->regmap, mux->mux_ofs, &val);
> +
> + return (val & BIT(mux->gate_shift)) == 0;
> +}
> +
> +static u8 mtk_clk_mux_get_parent(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->mux_width - 1, 0);
> + u32 val;
> +
> + regmap_read(mux->regmap, mux->mux_ofs, &val);
> + val = (val >> mux->mux_shift) & mask;
> +
> + return val;
> +}
> +
> +static int mtk_clk_mux_set_parent_lock(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->mux_width - 1, 0);
> + u32 val;
> + unsigned long flags = 0;
> +
> + if (mux->lock)
> + spin_lock_irqsave(mux->lock, flags);
> + else
> + __acquire(mux->lock);
> +
> + regmap_read(mux->regmap, mux->mux_ofs, &val);
> + val = (val & mask) >> mux->mux_shift;
> +
> + if (val != index) {
> + val = index << mux->mux_shift;
> + regmap_update_bits(mux->regmap, mux->mux_ofs, mask, val);
> + }
> +
> + if (mux->lock)
> + spin_unlock_irqrestore(mux->lock, flags);
> + else
> + __release(mux->lock);
> +
> + return 0;
> +}
> +
> +static int mtk_clk_mux_set_parent_setclr_lock(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->mux_width - 1, 0);
> + u32 val, orig;
> + unsigned long flags = 0;
> +
> + if (mux->lock)
> +
Re: [PATCH 3/3] kvm: introduce manual dirty log reprotect
On 11/26/2018 08:54 AM, Paolo Bonzini wrote:
> There are two problems with KVM_GET_DIRTY_LOG. First, and less important,
> it can take kvm->mmu_lock for an extended period of time. Second, its user
> can actually see many false positives in some cases. The latter is due
> to a benign race like this:
>
> 1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
> them.
> 2. The guest modifies the pages, causing them to be marked ditry.
> 3. Userspace actually copies the pages.
> 4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
> they were not written to since (3).
>
> This is especially a problem for large guests, where the time between
> (1) and (3) can be substantial. This patch introduces a new
> capability which, when enabled, makes KVM_GET_DIRTY_LOG not
> write-protect the pages it returns. Instead, userspace has to
> explicitly clear the dirty log bits just before using the content
> of the page. The new KVM_CLEAR_DIRTY_LOG ioctl can operate on a
> 64-page granularity rather than requiring to sync a full memslot.
> This way the mmu_lock is taken for small amounts of time, and
> only a small amount of time will pass between write protection
> of pages and the sending of their content.
>
> Signed-off-by: Paolo Bonzini
> ---
> Documentation/virtual/kvm/api.txt | 65 +++
> arch/mips/kvm/mips.c | 23
> arch/x86/kvm/x86.c | 27 +
> include/linux/kvm_host.h | 5 +
> include/uapi/linux/kvm.h | 15 +++
> tools/testing/selftests/kvm/Makefile | 2 +
> tools/testing/selftests/kvm/clear_dirty_log_test.c | 2 +
> tools/testing/selftests/kvm/dirty_log_test.c | 19
> tools/testing/selftests/kvm/include/kvm_util.h | 2 +
> tools/testing/selftests/kvm/lib/kvm_util.c | 13 +++
> virt/kvm/arm/arm.c | 16 +++
> virt/kvm/kvm_main.c| 120
> ++---
> 12 files changed, 293 insertions(+), 16 deletions(-)
> create mode 100644 tools/testing/selftests/kvm/clear_dirty_log_test.c
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 1071c10cf1c7..859927fb0b9c 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -305,6 +305,9 @@ the address space for which you want to return the dirty
> bitmap.
> They must be less than the value that KVM_CHECK_EXTENSION returns for
> the KVM_CAP_MULTI_ADDRESS_SPACE capability.
>
> +The bits in the dirty bitmap are cleared before the ioctl returns, unless
> +KVM_CAP_MANUAL_DIRTY_LOG_PROTECT is enabled. For more information,
> +see the description of the capability.
>
> 4.9 KVM_SET_MEMORY_ALIAS
>
> @@ -3758,6 +3761,44 @@ Coalesced pio is based on coalesced mmio. There is
> little difference
> between coalesced mmio and pio except that coalesced pio records accesses
> to I/O ports.
>
> +4.117 KVM_CLEAR_DIRTY_LOG (vm ioctl)
> +
> +Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT
> +Architectures: x86
> +Type: vm ioctl
> +Parameters: struct kvm_dirty_log (in/out)
Shouldn't this be just (in) rather than (in/out)?
> +Returns: 0 on success, -1 on error
> +
> +/* for KVM_CLEAR_DIRTY_LOG */
> +struct kvm_clear_dirty_log {
> + __u32 slot;
> + __u32 num_pages;
> + __u64 first_page;
> + union {
> + void __user *dirty_bitmap; /* one bit per page */
> + __u64 padding;
> + };
> +};
> +
> +The ioctl write-protects pages in a memory slot according to the
> +bitmap that is passed in struct kvm_clear_dirty_log's dirty_bitmap
> +field. Bit 0 of the bitmap corresponds to page "first_page" in the
> +memory slot, and num_pages is the size in bits of the input bitmap.
> +Both first_page and num_pages must be a multiple of 64. For each
> +bit that is set in the input bitmap, the corresponding page is write
> +protected and marked "clean" in KVM's dirty bitmap.
There will not be any write protection when PML is enabled. To make it more
accurate, perhaps we could say something like "The ioctl clears the dirty
status of pages ..." and later "For each bit that is set in the input bitmap,
the corresponding page is marked clean in KVM's dirty bitmap and dirty tracking
is re-enabled for that page either via write-protection or via clearing the
Dirty bit in the PTE, depending on the dirty logging mode in use."
> +
> +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies
> +the address space for which you want to return the dirty bitmap.
> +They must be less than the value that KVM_CHECK_EXTENSION returns for
> +the KVM_CAP_MULTI_ADDRESS_SPACE capability.
> +
> +This ioctl is mostly useful when KVM_CAP_MANUAL_DIRTY_LOG_PROTECT
> +is enabled; for more information, see the description of the capability.
> +However, it can always be used
Re: [RFC PATCH] dt-bindings: opp: Extend qcom-opp bindings with properties needed for CPR
On 11/20/2018 9:44 PM, Niklas Cassel wrote: On Tue, Nov 20, 2018 at 09:42:05AM +0530, Rajendra Nayak wrote: On 11/9/2018 10:09 PM, Niklas Cassel wrote: On Mon, Nov 05, 2018 at 05:17:45PM -0600, Rob Herring wrote: On Mon, Oct 15, 2018 at 02:47:49PM +0200, Niklas Cassel wrote: Extend qcom-opp bindings with properties needed for Core Power Reduction (CPR). CPR is included in a great variety of Qualcomm SoC, e.g. msm8916 and msm8996, and was first introduced in msm8974. Signed-off-by: Niklas Cassel --- Hello Rob, Rajendra, Sorry for not replying sooner. Since Rob wanted the binding to be complete before merging, this is my proposal to extend the OPP binding with properties needed to support CPR (both for msm8916 and msm8996). I've discussed the proposal with Viresh, and this proposal seems better than what I previously suggested here: https://lore.kernel.org/lkml/20181005204424.ga29...@centauri.lan/ .../devicetree/bindings/opp/qcom-opp.txt | 19 +++ 1 file changed, 19 insertions(+) diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt index db4d970c7ec7..3ab5dd84de86 100644 --- a/Documentation/devicetree/bindings/opp/qcom-opp.txt +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt @@ -23,3 +23,22 @@ Required properties: representing a corner/level that's communicated with a remote microprocessor (usually called the RPM) which then translates it into a certain voltage on a voltage rail. I've lost the context here. Please send this all together. Will do, as soon as I've gotten your feedback on this mail. Niklas, are you still waiting for feedback on this mail from Rob? Yes. Rob, did you have any further feedback for Niklas based on his binding proposal? Rajendra, I realize that your patches have been ready for merging for a long time, and this fuse-level is quite complex, so the discussion has been taken longer than expected. Sorry for that. Hopefully Rob will reply soon, or perhaps he could agree to merge your binding as is, and I could extend it later, when we have reached a consensus. Or should we merge the qcom,level binding for now (since I though we agreed 'reg' is probably not the right fit for it) and then discuss further on how to describe the legacy platforms which require more details like fuse bindings? Note that the current platform (sdm845) only needs the qcom,level binding. What Niklas is proposing is for describing the older SoCs.
[PATCH] tty: serial: 8250_mtk: always resume the device in probe.
serial8250_register_8250_port calls uart_config_port, which calls
config_port on the port before it tries to power on the port. So we need
the port to be on before calling serial8250_register_8250_port. Change
the code to always do a runtime resume in probe before registering port,
and always do a runtime suspend in remove.
This basically reverts the change in commit 68e5fc4a255a ("tty: serial:
8250_mtk: use pm_runtime callbacks for enabling"), but still use
pm_runtime callbacks.
Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for
enabling")
Signed-off-by: Peter Shih
---
drivers/tty/serial/8250/8250_mtk.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_mtk.c
b/drivers/tty/serial/8250/8250_mtk.c
index dd5e1cede2b58..c3f933d10295e 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -213,17 +213,17 @@ static int mtk8250_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
- pm_runtime_enable(&pdev->dev);
- if (!pm_runtime_enabled(&pdev->dev)) {
- err = mtk8250_runtime_resume(&pdev->dev);
- if (err)
- return err;
- }
+ err = mtk8250_runtime_resume(&pdev->dev);
+ if (err)
+ return err;
data->line = serial8250_register_8250_port(&uart);
if (data->line < 0)
return data->line;
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
return 0;
}
@@ -234,13 +234,11 @@ static int mtk8250_remove(struct platform_device *pdev)
pm_runtime_get_sync(&pdev->dev);
serial8250_unregister_port(data->line);
+ mtk8250_runtime_suspend(&pdev->dev);
pm_runtime_disable(&pdev->dev);
pm_runtime_put_noidle(&pdev->dev);
- if (!pm_runtime_status_suspended(&pdev->dev))
- mtk8250_runtime_suspend(&pdev->dev);
-
return 0;
}
--
2.20.0.rc0.387.gc7a69e6b6c-goog
Re: [PATCH V2 0/5] PM / Domains: Allow performance state propagation
On 11/26/2018 1:39 PM, Viresh Kumar wrote: Hi, This series adds performance state propagation support in genpd core. The propagation happens from the sub-domains to their masters. More details can be found in the individual commit logs. This is tested on hikey960 by faking power domains in such a way that the CPU devices have two power domains and both of them have the same master domain. The CPU device, as well as its power domains have "required-opps" property set and the performance requirement from the CPU eventually configures all the domains (2 sub-domains and 1 master). I validated this using the rpmh powerdomain driver [1] where I had to model a relationship across cx and mx powerdomains, so that mx is always >= cx. Seems to work as expected, I will respin the rpmh powerdomain patches soon (Though its awaiting Rob's review/ack for the corner bindings) Tested-by: Rajendra Nayak [1] https://patchwork.ozlabs.org/cover/935289/ Based on opp/linux-next branch (which is 4.20-rc1 + multiple-power-domain-support-in-opp-core + some OPP fixes). v1->V2: - First patch (1/5) is new and an improvement to earlier stuff. - Move genpd_status_on() check to _genpd_reeval_performance_state() from _genpd_set_performance_state(). - Improve dev_pm_opp_xlate_performance_state() to handle 1:1 pstate mapping between genpd and its master and also to fix a problem while finding the dst_table. - Handle pstate=0 case properly. -- viresh Viresh Kumar (5): OPP: Improve _find_table_of_opp_np() OPP: Add dev_pm_opp_xlate_performance_state() helper PM / Domains: Save OPP table pointer in genpd PM / Domains: Factorize dev_pm_genpd_set_performance_state() PM / Domains: Propagate performance state updates drivers/base/power/domain.c | 211 +++- drivers/opp/core.c | 59 ++ drivers/opp/of.c| 14 ++- include/linux/pm_domain.h | 6 + include/linux/pm_opp.h | 7 ++ 5 files changed, 244 insertions(+), 53 deletions(-)
Re: [driver-core PATCH v6 7/9] driver core: Attach devices on CPU local to device node
On Thu, Nov 8, 2018 at 10:07 AM Alexander Duyck wrote: > > Call the asynchronous probe routines on a CPU local to the device node. By > doing this we should be able to improve our initialization time > significantly as we can avoid having to access the device from a remote > node which may introduce higher latency. > > For example, in the case of initializing memory for NVDIMM this can have a > significant impact as initialing 3TB on remote node can take up to 39 > seconds while initialing it on a local node only takes 23 seconds. It is > situations like this where we will see the biggest improvement. > > Reviewed-by: Bart Van Assche > Signed-off-by: Alexander Duyck Looks good, Reviewed-by: Dan Williams
KASAN: use-after-free Read in kvm_write_guest_offset_cached
Hello, syzbot found the following crash on: HEAD commit:442b8cea2477 Add linux-next specific files for 20181109 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=174d326d40 kernel config: https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8 dashboard link: https://syzkaller.appspot.com/bug?extid=ff40b9bc4835ea83211c compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f5df7b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ff40b9bc4835ea832...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in mark_page_dirty_in_slot arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 [inline] BUG: KASAN: use-after-free in kvm_write_guest_offset_cached+0x693/0x6b0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 Read of size 8 at addr 8801b9363778 by task syz-executor1/30438 CPU: 1 PID: 30438 Comm: syz-executor1 Not tainted 4.20.0-rc1-next-20181109+ #110 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+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 mark_page_dirty_in_slot arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 [inline] kvm_write_guest_offset_cached+0x693/0x6b0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 kvm_steal_time_set_preempted arch/x86/kvm/x86.c:3241 [inline] kvm_arch_vcpu_put+0x365/0x420 arch/x86/kvm/x86.c:3268 kvm_sched_out+0x91/0xb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3993 __fire_sched_out_preempt_notifiers kernel/sched/core.c:2503 [inline] fire_sched_out_preempt_notifiers kernel/sched/core.c:2511 [inline] prepare_task_switch kernel/sched/core.c:2617 [inline] context_switch kernel/sched/core.c:2796 [inline] __schedule+0x11ca/0x21d0 kernel/sched/core.c:3472 preempt_schedule_irq+0xb9/0x140 kernel/sched/core.c:3699 retint_kernel+0x1b/0x2d RIP: 0010:search_memslots include/linux/kvm_host.h:955 [inline] RIP: 0010:__gfn_to_memslot include/linux/kvm_host.h:976 [inline] RIP: 0010:__kvm_gfn_to_hva_cache_init+0x2ed/0xd10 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1935 Code: 3c 02 00 0f 85 0d 0a 00 00 4d 03 6c 24 08 48 89 df 4c 89 ee e8 04 16 78 00 4c 39 eb 0f 82 6e 01 00 00 45 31 ed e8 43 15 78 00 <44> 89 fe 44 89 ef e8 c8 15 78 00 45 39 fd 0f 8d cf 00 00 00 e8 2a RSP: 0018:8801cbfee970 EFLAGS: 0293 ORIG_RAX: ff13 RAX: 8801b9a4c280 RBX: RCX: 8107942f RDX: RSI: 8107936d RDI: 0006 RBP: 8801cbfeeb60 R08: 8801b9a4c280 R09: ed00342bb209 R10: ed00342bb209 R11: 8801a15d904b R12: 0017 R13: 0017 R14: 0016 R15: 0017 kvm_gfn_to_hva_cache_init+0x15a/0x340 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1963 kvm_set_msr_common+0x1a0c/0x2670 arch/x86/kvm/x86.c:2549 vmx_set_msr+0x759/0x1f90 arch/x86/kvm/vmx.c:4360 kvm_set_msr+0x18a/0x370 arch/x86/kvm/x86.c:1324 do_set_msr+0x10d/0x1a0 arch/x86/kvm/x86.c:1353 __msr_io arch/x86/kvm/x86.c:2905 [inline] msr_io+0x222/0x380 arch/x86/kvm/x86.c:2941 kvm_arch_vcpu_ioctl+0x961/0x3b00 arch/x86/kvm/x86.c:3956 kvm_vcpu_ioctl+0x278/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 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 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc292e62c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00457569 RDX: 2280 RSI: 4008ae89 RDI: 0005 RBP: 0072c040 R08: R09: R10: R11: 0246 R12: 7fc292e636d4 R13: 004bff9d R14: 004d0970 R15: Allocated by task 30427: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 __do_kmalloc_node mm/slab.c:3684 [inline] __kmalloc_node+0x50/0x70 mm/slab.c:3691 kmalloc_node include/linux/slab.h:589 [inline] kvmalloc_node+0xb9/0xf0 mm/util.c:416 kvmalloc include/linux/mm.h:577 [inline] kvzalloc include/li
linux-next: Tree for Nov 27
Hi all, Changes since 20181126: The selinux tree gained a conflict against the vfs tree. Non-merge commits (relative to Linus' tree): 4747 4948 files changed, 246866 insertions(+), 147684 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 286 trees (counting Linus' and 67 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 (6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging) Merging fixes/master (595c647d341e sparc: suppress the implicit-fallthrough warnings) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (6b04114f6fae arc: [devboards] Add support of NFSv3 ACL) Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE) Merging arm64-fixes/for-next/fixes (4f9f49646a57 arm64: cpufeature: Fix mismerge of CONFIG_ARM64_SSBD block) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (b2fed34a628d selftests/powerpc: Adjust wild_bctr to build with old binutils) Merging sparc/master (86322ba9571a arch/sparc: Use kzalloc_node) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (69500127424c Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging bpf/master (69500127424c Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace) Merging netfilter/master (89259088c1b7 netfilter: nfnetlink_cttimeout: fetch timeouts for udplite and gre, too) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4) Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces) Merging rdma-fixes/for-rc (24c3456c8d5e iser: set sector for ambiguous mr status errors) Merging sound-current/for-linus (c4cfcf6f4297 ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops) Merging sound-asoc-fixes/for-linus (8f47ccdd70fd Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3) Merging regulator-fixes/for-linus (84f59cf6d5fc Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (0ca420a3bddf Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (94ea01a6d9a6 PCI: Fix incorrect value returned from pcie_get_speed_cap()) Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align data[] to ARCH_KMALLOC_MINALIGN) Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb.current/usb-linus (effd14f66cc1 usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series) Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers) Merging usb-serial-fixes/usb-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (c88520db18ba phy: qcom-qusb2: Fix HSTX_TRIM tuning with fused valu
[PATCH v2 2/3] perf annotate: Create a annotate2 flag in struct symbol
We often use the symbol__annotate2() to annotate a specified symbol.
While annotating may take some time, so in order to avoid annotating
the same symbol repeatedly, the patch creates a new flag to indicate
the symbol has been annotated.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 1 +
tools/perf/util/symbol.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4b2b1b0..f69d8e1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -2798,6 +2798,7 @@ int symbol__annotate2(struct symbol *sym, struct map
*map, struct perf_evsel *ev
notes->nr_events = nr_pcnt;
annotation__update_column_widths(notes);
+ sym->annotate2 = true;
return 0;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d026d21..14d9d43 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -63,6 +63,7 @@ struct symbol {
u8 ignore:1;
u8 inlined:1;
u8 arch_sym;
+ boolannotate2;
charname[0];
};
--
2.7.4
[PATCH v2 0/3] perf report/annotate: Support average IPC and IPC coverage for function
Add supporting of displaying the average IPC and IPC coverage
percentage per function.
For example,
$ perf record -g -b ...
$ perf report -s symbol,ipc or
perf report -s symbol,ipc --stdio
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
...
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
...
v2:
---
1. Merge in Jiri's patch to support stdio mode
2. Add a new patch "perf annotate: Create a annotate2 flag
in struct symbol" which records if the symbol has been
annotated yet.
3. Minor update such as adding { } for multiline code in 'if'
condition.
Jin Yao (3):
perf annotate: Compute average IPC and IPC coverage per symbol
perf annotate: Create a annotate2 flag in struct symbol
perf report: Display average IPC and IPC coverage per symbol
tools/perf/Documentation/perf-report.txt | 1 +
tools/perf/builtin-report.c | 14 ---
tools/perf/util/annotate.c | 42 +---
tools/perf/util/annotate.h | 5
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 42
tools/perf/util/sort.h | 1 +
tools/perf/util/symbol.h | 1 +
8 files changed, 101 insertions(+), 6 deletions(-)
--
2.7.4
[PATCH v2 1/3] perf annotate: Compute average IPC and IPC coverage per symbol
Add support to perf report annotate view or perf annotate --stdio2 to
aggregate the IPC derived from timed LBRs per symbol. We compute the
average IPC and the IPC coverage percentage.
For example,
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
0.00 1.10 1 ↓ je 43
29: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_lock_wait_private
add$0x80,%rsp
0.00 3.0043: lea__ctype_b@GLIBC_2.2.5+0x38,%rdi
3.00 lea0xc(%rsp),%rsi
8.49 3.00 1 → callq __random_r
7.91 1.94 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
0.00 1.94 1 ↓ je 68
lock decl __abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne70
↓ jmp8a
0.00 2.0068: decl __abort_msg@@GLIBC_PRIVATE+0x8a0
21.56 2.00 1 ↓ je 8a
70: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_unlock_wake_private
add$0x80,%rsp
21.56 2.908a: movslq 0xc(%rsp),%rax
2.90 add$0x18,%rsp
9.03 2.90 1 ← retq
It shows for this symbol the average IPC is 2.30 and the IPC coverage
is 54.8%.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 41 ++---
tools/perf/util/annotate.h | 5 +
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 6936daf..4b2b1b0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1000,6 +1000,7 @@ static unsigned annotation__count_insn(struct annotation
*notes, u64 start, u64
static void annotation__count_and_fill(struct annotation *notes, u64 start,
u64 end, struct cyc_hist *ch)
{
unsigned n_insn;
+ unsigned int cover_insn = 0;
u64 offset;
n_insn = annotation__count_insn(notes, start, end);
@@ -1013,21 +1014,34 @@ static void annotation__count_and_fill(struct
annotation *notes, u64 start, u64
for (offset = start; offset <= end; offset++) {
struct annotation_line *al = notes->offsets[offset];
- if (al)
+ if (al && al->ipc == 0.0) {
al->ipc = ipc;
+ cover_insn++;
+ }
+ }
+
+ if (cover_insn) {
+ notes->hit_cycles += ch->cycles;
+ notes->hit_insn += n_insn * ch->num;
+ notes->cover_insn += cover_insn;
}
}
}
void annotation__compute_ipc(struct annotation *notes, size_t size)
{
- u64 offset;
+ s64 offset;
if (!notes->src || !notes->src->cycles_hist)
return;
+ notes->total_insn = annotation__count_insn(notes, 0, size - 1);
+ notes->hit_cycles = 0;
+ notes->hit_insn = 0;
+ notes->cover_insn = 0;
+
pthread_mutex_lock(¬es->lock);
- for (offset = 0; offset < size; ++offset) {
+ for (offset = size - 1; offset >= 0; --offset) {
struct cyc_hist *ch;
ch = ¬es->src->cycles_hist[offset];
@@ -2563,6 +2577,22 @@ static void disasm_line__write(struct disasm_line *dl,
struct annotation *notes,
disasm_line__scnprintf(dl, bf, size, !notes->options->use_offset);
}
+static void ipc_coverage_string(char *bf, int size, struct annotation *notes)
+{
+ double ipc = 0.0, coverage = 0.0;
+
+ if (notes->hit_cycles)
+ ipc = notes->hit_insn / ((double)notes->hit_cycles);
+
+ if (notes->total_insn) {
+ coverage = notes->cover_insn * 100.0 /
+ ((double)notes->total_insn);
+ }
+
+ scnprintf(bf, size, "(Average IPC: %.2f, IPC Coverage: %.1f%%)",
+ ipc, coverage);
+}
+
static void __annotation_line__write(struct annotation_line *al, struct
annotation *notes,
bool first_line, bool current_entry, bool
change_color, int width,
voi
[PATCH v2 3/3] perf report: Display average IPC and IPC coverage per symbol
Support displaying the average IPC and IPC coverage for symbol
in perf report TUI browser. We create a new sort-key 'ipc' for
that.
For example,
$ perf record -g -b ...
$ perf report -s symbol,ipc or
perf report -s ipc
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
Jiri Olsa provided the patch to support the
stdio mode. I merged Jiri's code in this patch.
$ perf report -s ipc --stdio
# Overhead Symbol IPC [IPC Coverage]
# ...
#
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
0.02% [k] run_timer_softirq 1.60 [ 57.2%]
v2:
---
Merge in Jiri's patch to support stdio mode
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-report.txt | 1 +
tools/perf/builtin-report.c | 14 ---
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 42
tools/perf/util/sort.h | 1 +
5 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 474a494..e7b8974 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -122,6 +122,7 @@ OPTIONS
- in_tx: branch in TSX transaction
- abort: TSX transaction abort.
- cycles: Cycles in basic block
+ - ipc: average ipc (instruction per cycle) of function
And default sort keys are changed to comm, dso_from, symbol_from, dso_to
and symbol_to, see '--branch-stack'.
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 257c9c1..a6756dc 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -85,6 +85,7 @@ struct report {
int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
struct branch_type_stat brtype_stat;
+ boolsymbol_ipc;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -129,7 +130,7 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
struct mem_info *mi;
struct branch_info *bi;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -174,7 +175,7 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
struct perf_evsel *evsel = iter->evsel;
int err;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -1284,6 +1285,13 @@ int cmd_report(int argc, const char **argv)
else
use_browser = 0;
+ if ((sort__mode == SORT_MODE__BRANCH) && sort_order &&
+ strstr(sort_order, "ipc")) {
+ if (!strstr(sort_order, "symbol"))
+ sort_order = "symbol,ipc";
+ report.symbol_ipc = true;
+ }
+
if (setup_sorting(session->evlist) < 0) {
if (sort_order)
parse_options_usage(report_usage, options, "s", 1);
@@ -1311,7 +1319,7 @@ int cmd_report(int argc, const char **argv)
* so don't allocate extra space that won't be used in the stdio
* implementation.
*/
- if (ui__has_annotation()) {
+ if (ui__has_annotation() || report.symbol_ipc) {
ret = symbol__annotation_init();
if (ret < 0)
goto error;
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 3badd7f..664b5ed 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -62,6 +62,7 @@ enum hist_column {
HISTC_TRACE,
HISTC_SYM_SIZE,
HISTC_DSO_SIZE,
+ HISTC_SYMBOL_IPC,
HISTC_NR_COLS, /* Last entry */
};
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index f96c005..cc8ada3 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -13,6 +13,7 @@
#include "strlist.h"
#include
#include "mem-events.h"
+#include "annotate.h"
#include
regex_tparent_regex;
@@ -422,6 +423,46 @@ struct sor
Re: [PATCH v9 3/4] dt-bindings: pps: pps-gpio PPS ECHO implementation
Hi Rob, Quoting Rob Herring : On Thu, Nov 22, 2018 at 3:49 AM Tom Burkart wrote: This patch implements the device tree changes required for the pps echo functionality for pps-gpio, that sysfs claims is available already. This patch was originally written by Lukas Senger as part of a masters thesis project and modified for inclusion into the linux kernel by Tom Burkart. Signed-off-by: Lukas Senger Signed-off-by: Tom Burkart --- Documentation/devicetree/bindings/pps/pps-gpio.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt index 1155d49c2699..e09f6f2405c5 100644 --- a/Documentation/devicetree/bindings/pps/pps-gpio.txt +++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt @@ -7,10 +7,15 @@ Required properties: - compatible: should be "pps-gpio" - gpios: one PPS GPIO in the format described by ../gpio/gpio.txt +Additional required properties for the PPS ECHO functionality: +- echo-gpios: one PPS ECHO GPIO in the format described by ../gpio/gpio.txt +- echo-active-ms: duration in ms of the active portion of the echo pulse + Optional properties: - assert-falling-edge: when present, assert is indicated by a falling edge (instead of by a rising edge) - capture-clear: when present, also capture the PPS clear event +- invert-pps-echo: when present, invert the PPS ECHO pulse Why do you need this? Can't you just make the echo gpio GPIO_ACTIVE_LOW? BTW, using the flag probably should have been done for 'assert-falling-edge' as well. The hardware I use expects a positive-going echo pulse, however, it was really easy to give users the option to have it inverted in case they use different hardware that expects a negative-going edge. I may well be needing this option myself if I find that the GPS I am using produces better results for negative-going edges than positive-going edges. Tom
Re: [PATCH] OPP: remove some duplicated includes
On 26-11-18, 08:18, Yangtao Li wrote: > Some header files are included twice.It's unnecessary, > so just remove them. > > Signed-off-by: Yangtao Li > --- > drivers/opp/core.c | 2 -- > drivers/opp/cpu.c | 1 - > drivers/opp/debugfs.c | 2 -- > drivers/opp/of.c| 1 - > drivers/opp/opp.h | 1 - > drivers/opp/ti-opp-supply.c | 1 - > 6 files changed, 8 deletions(-) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index 2c2df4e4fc14..31fc2cbb9d1f 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -15,9 +15,7 @@ > > #include > #include > -#include > #include > -#include > #include > #include > #include > diff --git a/drivers/opp/cpu.c b/drivers/opp/cpu.c > index ab6d07e78945..778ac771ce93 100644 > --- a/drivers/opp/cpu.c > +++ b/drivers/opp/cpu.c > @@ -15,7 +15,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/opp/debugfs.c b/drivers/opp/debugfs.c > index e6828e5f81b0..05670aeebecd 100644 > --- a/drivers/opp/debugfs.c > +++ b/drivers/opp/debugfs.c > @@ -11,8 +11,6 @@ > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > #include > -#include > -#include > #include > #include > #include > diff --git a/drivers/opp/of.c b/drivers/opp/of.c > index 5a4b47958073..ea510e350682 100644 > --- a/drivers/opp/of.c > +++ b/drivers/opp/of.c > @@ -15,7 +15,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h > index 9c6544b4f4f9..558c5e638d97 100644 > --- a/drivers/opp/opp.h > +++ b/drivers/opp/opp.h > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > > struct clk; > struct regulator; > diff --git a/drivers/opp/ti-opp-supply.c b/drivers/opp/ti-opp-supply.c > index 3f4fb4dbbe33..b1d7442960e3 100644 > --- a/drivers/opp/ti-opp-supply.c > +++ b/drivers/opp/ti-opp-supply.c > @@ -13,7 +13,6 @@ > #include > #include > #include > -#include > #include > #include > #include AFAICT, none of these files have included any of the files twice directly. Yes, they may have included some .h files (like opp.h) which may have included files like err.h, etc. But that is fine. Each file in kernel should normally include all its dependencies directly and should avoid depending on other .h files to do so. For example, kernel.h includes so many .h files, like types.h, etc. Should all files that include kernel.h stop including types.h directly? What will happen if kernel.h stops including types.h in future? Many other files will stop building, because they indirectly depended on kernel.h which is incorrect in my opinion. -- viresh
Re: [PATCH] initramfs: clean old path before creating a hardlink
On 11/27/2018 07:34 AM, Andrew Morton wrote:
On Fri, 16 Nov 2018 15:12:48 +0800 Li Zhijian wrote:
Previously, sys_link() will fail due to the new path is already existed.
this case ofen appears when we use a concated initrd, below is an
sample:
1) prepare a basic rootfs, it contains a regular files rc.local
lizhijian@:~/yocto-tiny-i386-2016-04-22$ cat etc/rc.local
#!/bin/sh
echo "Running /etc/rc.local..."
yocto-tiny-i386-2016-04-22$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n -9
>../rootfs.cgz
2) create a extra initrd which also includes a etc/rc.local
lizhijian@:~/lkp-x86_64/etc$ echo "append initrd" >rc.local
lizhijian@:~/lkp/lkp-x86_64/etc$ cat rc.local
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ ln rc.local rc.local.hardlink
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ stat rc.local rc.local.hardlink
File: 'rc.local'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
File: 'rc.local.hardlink'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
lizhijian@:~/lkp/lkp-x86_64$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n
-9 >../rc-local.cgz
lizhijian@:~/lkp/lkp-x86_64$ gzip -dc ../rc-local.cgz | cpio -t
.
etc
etc/rc.local.hardlink <<< it will be extracted first at this initrd
etc/rc.local
3) concate 2 initrds and boot
lizhijian@:~/lkp$ cat rootfs.cgz rc-local.cgz >concate-initrd.cgz
lizhijian@:~/lkp$ qemu-system-x86_64 -nographic -enable-kvm -cpu host -smp 1 -m 1024
-kernel ~/lkp/linux/arch/x86/boot/bzImage -append "console=ttyS0 earlyprint=ttyS0
ignore_loglevel" -initrd ./concate-initr.cgz -serial stdio -nodefaults
In this case, sys_link(2) will fail and return -EEXIST, so we can only
get the rc.local at rootfs.cgz instead of rc-local.cgz
I can't claim to understand this, but I believe you ;)
thank you.
IMO, people who use concatenated initrd(cat rootfs.cgz rc-local.cgz
>concatenated-initrd.cgz),
could expect that the later initrd(rc-local.cgz) can overwrite the previous
initrd(rootfs.cgz).
However the previous kernel can not ensure this.
How serious is this problem? Do you think a 4.20 merge is justified?
It's critical for our scenario where it always concatenates multiple initrds.
and our scenario often use the latest kernel, so 4.20+ is good to us.
Or a -stable backport? If so, why?
The forward declaration is unpleasing. Why not simply move the function?
Got it, i will update in V2
Thanks
--- a/init/initramfs.c~initramfs-clean-old-path-before-creating-a-hardlink-fix
+++ a/init/initramfs.c
@@ -291,7 +291,17 @@ static int __init do_reset(void)
return 1;
}
-static void __init clean_path(char *path, umode_t fmode);
+static void __init clean_path(char *path, umode_t fmode)
+{
+ struct kstat st;
+
+ if (!vfs_lstat(path, &st) && (st.mode ^ fmode) & S_IFMT) {
+ if (S_ISDIR(st.mode))
+ ksys_rmdir(path);
+ else
+ ksys_unlink(path);
+ }
+}
static int __init maybe_link(void)
{
@@ -305,18 +315,6 @@ static int __init maybe_link(void)
return 0;
}
-static void __init clean_path(char *path, umode_t fmode)
-{
- struct kstat st;
-
- if (!vfs_lstat(path, &st) && (st.mode ^ fmode) & S_IFMT) {
- if (S_ISDIR(st.mode))
- ksys_rmdir(path);
- else
- ksys_unlink(path);
- }
-}
-
static __initdata int wfd;
static int __init do_name(void)
_
.
Re: [PATCH V4 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT
On 26-11-18, 13:20, Daniel Lezcano wrote: > diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt > b/Documentation/devicetree/bindings/arm/cpu-capacity.txt > index 84262cd..f53a3c9 100644 > --- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt > +++ b/Documentation/devicetree/bindings/arm/cpu-capacity.txt > @@ -54,6 +54,12 @@ fall back to the default capacity value for every CPU. If > cpufreq is not > available, final capacities are calculated by directly using capacity-dmips- > mhz values (normalized w.r.t. the highest value found while parsing the DT). > > +If capacity-dmips-mhz is not specified or if the parsing fails, the > +default capacity value will be computed against the highest frequency. > +When all CPUs have the same OPP, they will have the same capacity > +value otherwise the capacity will be scaled down for CPUs having lower > +frequencies. I know you added this based on Quentin's feedback, but I wonder if this is really required and if it is improving anything at all. This is what the documentation says currently without this patch: " capacity-dmips-mhz is an optional cpu node [1] property: u32 value representing CPU capacity expressed in normalized DMIPS/MHz. At boot time, the maximum frequency available to the cpu is then used to calculate the capacity value internally used by the kernel. capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu node, it has to be specified for every other cpu nodes, or the system will fall back to the default capacity value for every CPU. If cpufreq is not available, final capacities are calculated by directly using capacity-dmips- mhz values (normalized w.r.t. the highest value found while parsing the DT). " So it already clearly says two things: - If all CPUs don't have this property, we fallback to default capacity for every CPU. - And the OS may also normalize the capacity based on the maximum frequency. What more do we want to add here ? -- viresh
Re: [PATCH v7 1/4] dt-bindings: pps: descriptor-based gpio, capture-clear addition
Hi Rob, Quoting Rob Herring : On Sat, Nov 17, 2018 at 6:35 PM tom burkart wrote: Quoting Rob Herring : > On Sat, Nov 17, 2018 at 4:35 AM tom burkart wrote: >> >> Quoting Rob Herring : >> >> > On Wed, Nov 14, 2018 at 11:54:29PM +1100, Tom Burkart wrote: >> >> This patch changes the devicetree bindings for the pps-gpio driver >> >> from the integer based ABI to the descriptor based ABI. >> > ? That has nothing to do with DT. >> >> I believe it does, as the change in ABI forces a rename in the DT >> naming convention. >> This is due to the descriptor based ABI appending "-gpio" or "-gpios" (see >> Documentation/gpio/base.txt.) >> Admittedly, I may have called it by the wrong name due to ignorance, >> my apologies. > > If what you say is correct, then you can't change this driver. You'll > break compatibility with any existing DT. > > Changing the binding reasoning should purely be that this is the > preferred form. Bindings must be independent from changing kernel > APIs. See comments from Philip Zabel. I misread the documentation and this has now been corrected in v8 of the patch. I hope that eliminates all comments made above. >> >> It also adds >> >> documentation for the device tree capture-clear option. The legacy >> >> device tree entry for the GPIO pin is supported. >> >> >> >> Signed-off-by: Tom Burkart >> >> --- >> >> Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++-- >> >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> >> >> diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt >> >> b/Documentation/devicetree/bindings/pps/pps-gpio.txt >> >> index 3683874832ae..6c9fc0998d94 100644 >> >> --- a/Documentation/devicetree/bindings/pps/pps-gpio.txt >> >> +++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt >> >> @@ -5,19 +5,23 @@ a GPIO pin. >> >> >> >> Required properties: >> >> - compatible: should be "pps-gpio" >> >> -- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt >> >> +- pps-gpios: one PPS GPIO in the format described by ../gpio/gpio.txt >> >> +Alternatively (DEPRECATED), instead of pps-gpios above, it may have: >> >> +- gpios: one PPS GPIO as above >> >> >> >> Optional properties: >> >> - assert-falling-edge: when present, assert is indicated by a >> falling edge >> >> (instead of by a rising edge) >> >> +- capture-clear: when present, also capture the PPS clear event >> > >> > Is this a h/w thing? or driver configuration? >> >> Driver configuration. Most of the code was present in the driver, yet >> it was not documented, or usable due to a two line (code) omission >> (the value was not being fetched from DT). > > So what determines how you want to configure this? If the user will > want to change it, then it should be a sysfs attr and exposed to > userspace. If it depends on h/w config for a board then it can be in > DT. Sorry, I misled you somewhat. If the PPS pulse active transition from the hardware is on the falling edge, this flag is required to get the OS to use that as the active transition. This would not change at the user's whim but rather it is dependent on connected hardware. This description sounds more like 'assert-falling-edge' than 'capture-clear'. I'm still not clear on what 'capture-clear' is. Ignoring my patch for a minute, the pps_gpio_irq_handler will only report a pps PPS_CAPTURECLEAR event if 'capture-clear' is set. As the current pps-gpio driver is not able to set this flag, it cannot ever report a PPS_CAPTURECLEAR event. My patch adds the ability to set this flag and adds the documentation to go with it. Admittedly, I do not require this functionality for what I want, but working with the code, I noticed the omission and decided to add it for someone else to use it, if they need it. I am happy to remove this out of my patch, if you feel this to be the best way forward. Tom
Re: [PATCH 2/2] perf report: Display average IPC and IPC coverage per symbol
On 11/26/2018 5:53 PM, Jiri Olsa wrote:
On Mon, Nov 26, 2018 at 05:40:54PM +0800, Jin Yao wrote:
SNIP
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index f96c005..94f62c8 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -13,6 +13,7 @@
#include "strlist.h"
#include
#include "mem-events.h"
+#include "annotate.h"
#include
regex_t parent_regex;
@@ -422,6 +423,47 @@ struct sort_entry sort_srcline_to = {
.se_width_idx = HISTC_SRCLINE_TO,
};
+static int hist_entry__sym_ipc_snprintf(struct hist_entry *he, char *bf,
+ size_t size, unsigned int width)
+{
+
+ struct symbol *sym = he->ms.sym;
+ struct map *map = he->ms.map;
+ struct perf_evsel *evsel = hists_to_evsel(he->hists);
+ struct annotation *notes;
+ double ipc = 0.0, coverage = 0.0;
+ char tmp[64];
+
+ if (!sym)
+ return repsep_snprintf(bf, size, "%-*s", width, "-");
+
+ if (!sym->annotated &&
+ symbol__annotate2(sym, map, evsel, &annotation__default_options,
+ NULL) < 0) {
+ return 0;
+ }
+
+ sym->annotated = true;
I don't like this being set in here.. please move it to
symbol__annotate2 or symbol__annotate, not sure which
one of these is the best fit
I have set this flag in symbol__annotate2 in v2.
+ notes = symbol__annotation(sym);
+
+ if (notes->hit_cycles)
+ ipc = notes->hit_insn / ((double)notes->hit_cycles);
+
+ if (notes->total_insn)
+ coverage = notes->cover_insn * 100.0 /
+ ((double)notes->total_insn);
missing { } for multiline code in 'if' condition
Fixed, thanks!
Thanks
Jin Yao
thanks,
jirka
Re: [PATCH 2/2] perf report: Display average IPC and IPC coverage per symbol
On 11/26/2018 5:52 PM, Jiri Olsa wrote:
On Mon, Nov 26, 2018 at 05:40:54PM +0800, Jin Yao wrote:
Support displaying the average IPC and IPC coverage for symbol
in perf report TUI browser. We create a new sort-key 'ipc' for
that.
For example,
$ perf record -g -b ...
$ perf report -s symbol,ipc or
perf report -s ipc
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
Note that, stdio mode doesn't support this feature.
the patch below allowed this for stdio
please merge it in, and feel free to change it as you see fit
jirka
Thanks so much! I have merged following code in v2.
Thanks
Jin Yao
---
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 9b75e118f609..a6756dc13285 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -85,6 +85,7 @@ struct report {
int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
struct branch_type_stat brtype_stat;
+ boolsymbol_ipc;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -129,7 +130,7 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
struct mem_info *mi;
struct branch_info *bi;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -174,7 +175,7 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
struct perf_evsel *evsel = iter->evsel;
int err;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -954,7 +955,6 @@ int cmd_report(int argc, const char **argv)
bool has_br_stack = false;
int branch_mode = -1;
bool branch_call_mode = false;
- bool symbol_ipc = false;
#define CALLCHAIN_DEFAULT_OPT "graph,0.5,caller,function,percent"
const char report_callchain_help[] = "Display call graph (stack
chain/backtrace):\n\n"
CALLCHAIN_REPORT_HELP
@@ -1289,7 +1289,7 @@ int cmd_report(int argc, const char **argv)
strstr(sort_order, "ipc")) {
if (!strstr(sort_order, "symbol"))
sort_order = "symbol,ipc";
- symbol_ipc = true;
+ report.symbol_ipc = true;
}
if (setup_sorting(session->evlist) < 0) {
@@ -1319,7 +1319,7 @@ int cmd_report(int argc, const char **argv)
* so don't allocate extra space that won't be used in the stdio
* implementation.
*/
- if (ui__has_annotation()) {
+ if (ui__has_annotation() || report.symbol_ipc) {
ret = symbol__annotation_init();
if (ret < 0)
goto error;
@@ -1339,9 +1339,6 @@ int cmd_report(int argc, const char **argv)
symbol_conf.sort_by_name = true;
}
annotation_config__init();
- } else if (symbol_ipc) {
- pr_err("Only TUI mode supports sort-key ipc\n");
- goto error;
}
if (symbol__init(&session->header.env) < 0)
Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Tue, Nov 27, 2018 at 03:53:57AM +0100, Elvira Khabirova wrote:
> On Mon, 26 Nov 2018 15:56:43 +0100, Oleg Nesterov wrote:
> > On 11/25, Elvira Khabirova wrote:
> > >
> > > + * These values are stored in task->ptrace_message by
> > > tracehook_report_syscall_*
> > > + * to describe current syscall-stop.
> > > + *
> > > + * Values for these constants are chosen so that they do not appear
> > > + * in task->ptrace_message by other means.
> > > + */
> > > +#define PTRACE_EVENTMSG_SYSCALL_ENTRY0x8000U
> > > +#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x9000U
> >
> > Stupid question, why not
> >
> > #define PTRACE_EVENT_SYSCALL_ENTRY 8
> > #define PTRACE_EVENT_SYSCALL_EXIT 9
> >
> > right after other PTRACE_EVENT_* constants?
>
> I thought about adding new events for syscall {entry,exit}.
> For tracers, using new events means setting new options and checking
> for new values after waitpid(). They will also have to switch from using
> PTRACE_SYSCALL to PTRACE_CONT.
> Right now (with this version of the patch) tracers can use
> PTRACE_GETEVENTMSG without doing any additional configuration.
> More importantly, adding these events would require much more complex
> modifications of kernel code than this patch does.
To be honest, we don't see any way of introducing PTRACE_EVENT_* support
in PTRACE_GET_SYSCALL_INFO without adding new fields to struct task_struct.
> The only benefit I see from adding these events instead of letting
> syscall-stops put a value in ptrace_message is an ability to subscribe
> to syscall entries, but not to exits, and vice-versa, and I don't think
> it is worth it.
--
ldv
signature.asc
Description: PGP signature
[PATCH v2 09/11] dt-bindings: soc: fix typo of MT8173 power dt-bindings
fix incorrect IC name that will affect the MT8183 power dt-bindings Signed-off-by: Weiyi Lu --- include/dt-bindings/power/mt8173-power.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/dt-bindings/power/mt8173-power.h b/include/dt-bindings/power/mt8173-power.h index 15d531aa6e78..ef4a7f944848 100644 --- a/include/dt-bindings/power/mt8173-power.h +++ b/include/dt-bindings/power/mt8173-power.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H -#define _DT_BINDINGS_POWER_MT8183_POWER_H +#ifndef _DT_BINDINGS_POWER_MT8173_POWER_H +#define _DT_BINDINGS_POWER_MT8173_POWER_H #define MT8173_POWER_DOMAIN_VDEC 0 #define MT8173_POWER_DOMAIN_VENC 1 @@ -13,4 +13,4 @@ #define MT8173_POWER_DOMAIN_MFG_2D 8 #define MT8173_POWER_DOMAIN_MFG9 -#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */ +#endif /* _DT_BINDINGS_POWER_MT8173_POWER_H */ -- 2.18.0
[PATCH v2 11/11] soc: mediatek: Add MT8183 scpsys support
Add scpsys driver for MT8183
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 227 +-
1 file changed, 226 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 80be2e05e4e0..aac76c45a681 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define MTK_POLL_DELAY_US 10
#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
@@ -397,7 +398,6 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
if (ret < 0)
goto err_pwr_ack;
-
val &= ~PWR_CLK_DIS_BIT;
writel(val, ctl_addr);
@@ -1179,6 +1179,217 @@ static const struct scp_subdomain
scp_subdomain_mt8173[] = {
{MT8173_POWER_DOMAIN_MFG_2D, MT8173_POWER_DOMAIN_MFG},
};
+/*
+ * MT8183 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt8183[] = {
+ [MT8183_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = PWR_STATUS_AUDIO,
+ .ctl_offs = 0x0314,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .basic_clk_name = {"audio", "audio1", "audio2"},
+ },
+ [MT8183_POWER_DOMAIN_CONN] = {
+ .name = "conn",
+ .sta_mask = PWR_STATUS_CONN,
+ .ctl_offs = 0x032c,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ BIT(13) | BIT(14), BIT(13) | BIT(14)),
+ },
+ },
+ [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
+ .name = "mfg_async",
+ .sta_mask = PWR_STATUS_MFG_ASYNC,
+ .ctl_offs = 0x0334,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .basic_clk_name = {"mfg"},
+ },
+ [MT8183_POWER_DOMAIN_MFG] = {
+ .name = "mfg",
+ .sta_mask = PWR_STATUS_MFG,
+ .ctl_offs = 0x0338,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_CORE0] = {
+ .name = "mfg_core0",
+ .sta_mask = BIT(7),
+ .ctl_offs = 0x034c,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_CORE1] = {
+ .name = "mfg_core1",
+ .sta_mask = BIT(20),
+ .ctl_offs = 0x0310,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_2D] = {
+ .name = "mfg_2d",
+ .sta_mask = PWR_STATUS_MFG_2D,
+ .ctl_offs = 0x0348,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
+ BIT(19) | BIT(20) | BIT(21),
+ BIT(19) | BIT(20) | BIT(21)),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ BIT(21) | BIT(22), BIT(21) | BIT(22)),
+ },
+ },
+ [MT8183_POWER_DOMAIN_DISP] = {
+ .name = "disp",
+ .sta_mask = PWR_STATUS_DISP,
+ .ctl_offs = 0x030c,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .basic_clk_name = {"mm"},
+ .subsys_clk_prefix = "mm",
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
+ BIT(16) | BIT(17), BIT(16) | BIT(17)),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ BIT(10) | BIT(11), BIT(10) | BIT(11)),
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ GENMASK(7, 0), GENMASK(7, 0)),
+ },
+ },
+ [MT8183_POWER_DOMAIN_CAM] = {
+ .name = "cam",
+ .sta_mask = BIT(25),
+ .ctl_offs = 0x0344,
+ .sram_pdn_bits = GENMASK(9, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .basic_clk_name = {"cam"},
+ .subsys_clk_prefix = "cam",
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ BIT(4) | BIT(5) | BIT(9) | BIT(13),
+ BIT(4) | BIT(5) | BIT(9) | BIT(13)),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ BIT(28), BIT(28)),
+
[PATCH v2 10/11] dt-bindings: soc: Add MT8183 power dt-bindings
Add power dt-bindings for MT8183. Signed-off-by: Weiyi Lu --- .../bindings/soc/mediatek/scpsys.txt | 14 ++ include/dt-bindings/power/mt8183-power.h | 26 +++ 2 files changed, 40 insertions(+) create mode 100644 include/dt-bindings/power/mt8183-power.h diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index d6fe16f094af..b4728ce81c43 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -14,6 +14,7 @@ power/power_domain.txt. It provides the power domains defined in - include/dt-bindings/power/mt2701-power.h - include/dt-bindings/power/mt2712-power.h - include/dt-bindings/power/mt7622-power.h +- include/dt-bindings/power/mt8183-power.h Required properties: - compatible: Should be one of: @@ -24,18 +25,31 @@ Required properties: - "mediatek,mt7623-scpsys", "mediatek,mt2701-scpsys": For MT7623 SoC - "mediatek,mt7623a-scpsys": For MT7623A SoC - "mediatek,mt8173-scpsys" + - "mediatek,mt8183-scpsys" - #power-domain-cells: Must be 1 - reg: Address range of the SCPSYS unit - infracfg: must contain a phandle to the infracfg controller - clock, clock-names: clocks according to the common clock binding. These are clocks which hardware needs to be enabled before enabling certain power domains. + The new clock type "BASIC" belongs to the type above. + As to the new clock type "SUBSYS" needs to be + enabled before releasing bus protection. Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif" Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec" Required clocks for MT6797: "mm", "mfg", "vdec" Required clocks for MT7622: "hif_sel" Required clocks for MT7622A: "ethif" Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" + Required clocks for MT8183: BASIC: "audio", "mfg", "mm", "cam", "isp", + "vpu", "vpu1", "vpu2", "vpu3" + SUBSYS: "mm-0", "mm-1", "mm-2", "mm-3", + "mm-4", "mm-5", "mm-6", "mm-7", + "mm-8", "mm-9", "isp-0", "isp-1", + "cam-0", "cam-1", "cam-2", "cam-3", + "cam-4", "cam-5", "cam-6", "vpu-0", + "vpu-1", "vpu-2", "vpu-3", "vpu-4", + "vpu-5" Optional properties: - vdec-supply: Power supply for the vdec power domain diff --git a/include/dt-bindings/power/mt8183-power.h b/include/dt-bindings/power/mt8183-power.h new file mode 100644 index ..5c0c8c7e3cd0 --- /dev/null +++ b/include/dt-bindings/power/mt8183-power.h @@ -0,0 +1,26 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2018 MediaTek Inc. + * Author: Weiyi Lu + */ + +#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H +#define _DT_BINDINGS_POWER_MT8183_POWER_H + +#define MT8183_POWER_DOMAIN_AUDIO 0 +#define MT8183_POWER_DOMAIN_CONN 1 +#define MT8183_POWER_DOMAIN_MFG_ASYNC 2 +#define MT8183_POWER_DOMAIN_MFG3 +#define MT8183_POWER_DOMAIN_MFG_CORE0 4 +#define MT8183_POWER_DOMAIN_MFG_CORE1 5 +#define MT8183_POWER_DOMAIN_MFG_2D 6 +#define MT8183_POWER_DOMAIN_DISP 7 +#define MT8183_POWER_DOMAIN_CAM8 +#define MT8183_POWER_DOMAIN_ISP9 +#define MT8183_POWER_DOMAIN_VDEC 10 +#define MT8183_POWER_DOMAIN_VENC 11 +#define MT8183_POWER_DOMAIN_VPU_TOP12 +#define MT8183_POWER_DOMAIN_VPU_CORE0 13 +#define MT8183_POWER_DOMAIN_VPU_CORE1 14 + +#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */ -- 2.18.0
[PATCH v2 03/11] clk: mediatek: Disable tuner_en before change PLL rate
From: Owen Chen
PLLs with tuner_en bit, such as APLL1, need to disable
tuner_en before apply new frequency settings, or the new frequency
settings (pcw) will not be applied.
The tuner_en bit will be disabled during changing PLL rate
and be restored after new settings applied.
Signed-off-by: Owen Chen
---
drivers/clk/mediatek/clk-pll.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 1db161aced31..81400601f107 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -27,7 +27,7 @@
#define CON0_BASE_EN BIT(0)
#define CON0_PWR_ONBIT(0)
#define CON0_ISO_ENBIT(1)
-#define CON0_PCW_CHG BIT(31)
+#define CON1_PCW_CHG BIT(31)
#define AUDPLL_TUNER_ENBIT(31)
@@ -97,9 +97,31 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll,
u32 pcw,
{
u32 con1, val;
int pll_en;
+ u32 tuner_en = 0;
+ u32 tuner_en_mask;
+ void __iomem *tuner_en_addr = NULL;
pll_en = readl(pll->base_addr + REG_CON0) & CON0_BASE_EN;
+ /* disable tuner */
+ if (pll->tuner_en_addr) {
+ tuner_en_addr = pll->tuner_en_addr;
+ tuner_en_mask = BIT(pll->data->tuner_en_bit);
+ } else if (pll->tuner_addr) {
+ tuner_en_addr = pll->tuner_addr;
+ tuner_en_mask = AUDPLL_TUNER_EN;
+ }
+
+ if (tuner_en_addr) {
+ val = readl(tuner_en_addr);
+ tuner_en = val & tuner_en_mask;
+
+ if (tuner_en) {
+ val &= ~tuner_en_mask;
+ writel(val, tuner_en_addr);
+ }
+ }
+
/* set postdiv */
val = readl(pll->pd_addr);
val &= ~(POSTDIV_MASK << pll->data->pd_shift);
@@ -120,12 +142,19 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll
*pll, u32 pcw,
con1 = readl(pll->base_addr + REG_CON1);
if (pll_en)
- con1 |= CON0_PCW_CHG;
+ con1 |= CON1_PCW_CHG;
writel(con1, pll->base_addr + REG_CON1);
if (pll->tuner_addr)
writel(con1 + 1, pll->tuner_addr);
+ /* restore tuner_en */
+ if (tuner_en_addr && tuner_en) {
+ val = readl(tuner_en_addr);
+ val |= tuner_en_mask;
+ writel(val, tuner_en_addr);
+ }
+
if (pll_en)
udelay(20);
}
--
2.18.0
[PATCH v2 00/11] Mediatek MT8183 clock and scpsys support
This series is based on v4.20-rc1 and most of changes are extracted from series below (clock/scpsys common changes for both MT8183 & MT6765) https://patchwork.kernel.org/patch/10528495/ (clock support of MT8183) https://patchwork.kernel.org/patch/10549891/ The whole series is composed of clock common changes for both MT8183 & MT6765 (PATCH 1-3), scpsys common changes for both MT8183 & MT6765 (PATCH 4), clock support of MT8183 (PATCH 5-8), and scpsys support of MT8183 (PATCH 9-11). changes since v1: - refine for better code quality. - some minor bug fix of clock part, like incorrect control address and missing clocks. Owen Chen (4): clk: mediatek: add new clkmux register API clk: mediatek: add new member to mtk_pll_data clk: mediatek: Disable tuner_en before change PLL rate soc: mediatek: add new flow for mtcmos power. Weiyi Lu (7): dt-bindings: ARM: Mediatek: Document bindings for MT8183 clk: mediatek: Add dt-bindings for MT8183 clocks clk: mediatek: Add flags support for mtk_gate data clk: mediatek: Add MT8183 clock support dt-bindings: soc: fix typo of MT8173 power dt-bindings dt-bindings: soc: Add MT8183 power dt-bindings soc: mediatek: Add MT8183 scpsys support .../arm/mediatek/mediatek,apmixedsys.txt |1 + .../bindings/arm/mediatek/mediatek,audsys.txt |1 + .../bindings/arm/mediatek/mediatek,camsys.txt | 22 + .../bindings/arm/mediatek/mediatek,imgsys.txt |1 + .../arm/mediatek/mediatek,infracfg.txt|1 + .../bindings/arm/mediatek/mediatek,ipu.txt| 43 + .../bindings/arm/mediatek/mediatek,mcucfg.txt |1 + .../bindings/arm/mediatek/mediatek,mfgcfg.txt |1 + .../bindings/arm/mediatek/mediatek,mmsys.txt |1 + .../arm/mediatek/mediatek,topckgen.txt|1 + .../arm/mediatek/mediatek,vdecsys.txt |1 + .../arm/mediatek/mediatek,vencsys.txt |1 + .../bindings/soc/mediatek/scpsys.txt | 14 + drivers/clk/mediatek/Kconfig | 75 + drivers/clk/mediatek/Makefile | 14 +- drivers/clk/mediatek/clk-gate.c |5 +- drivers/clk/mediatek/clk-gate.h | 17 +- drivers/clk/mediatek/clk-mt8183-audio.c | 102 ++ drivers/clk/mediatek/clk-mt8183-cam.c | 70 + drivers/clk/mediatek/clk-mt8183-img.c | 70 + drivers/clk/mediatek/clk-mt8183-ipu0.c| 63 + drivers/clk/mediatek/clk-mt8183-ipu1.c| 63 + drivers/clk/mediatek/clk-mt8183-ipu_adl.c | 61 + drivers/clk/mediatek/clk-mt8183-ipu_conn.c| 130 ++ drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 61 + drivers/clk/mediatek/clk-mt8183-mm.c | 118 ++ drivers/clk/mediatek/clk-mt8183-vdec.c| 74 + drivers/clk/mediatek/clk-mt8183-venc.c| 66 + drivers/clk/mediatek/clk-mt8183.c | 1305 + drivers/clk/mediatek/clk-mtk.c|3 +- drivers/clk/mediatek/clk-mtk.h|3 + drivers/clk/mediatek/clk-mux.c| 240 +++ drivers/clk/mediatek/clk-mux.h| 101 ++ drivers/clk/mediatek/clk-pll.c| 45 +- drivers/soc/mediatek/Makefile |2 +- drivers/soc/mediatek/mtk-scpsys-ext.c | 99 ++ drivers/soc/mediatek/mtk-scpsys.c | 604 +++- include/dt-bindings/clock/mt8183-clk.h| 422 ++ include/dt-bindings/power/mt8173-power.h |6 +- include/dt-bindings/power/mt8183-power.h | 26 + include/linux/soc/mediatek/scpsys-ext.h | 39 + 41 files changed, 3889 insertions(+), 84 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c create mode 100644 drivers/clk/mediatek/clk-mt8183.c create mode 100644 drivers/clk/mediatek/clk-mux.c create mode 100644 drivers/clk/mediatek/clk-mux.h create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c create mode 100644 include/dt-bindings/clock/mt8183-clk.h create mode 100644 include/dt-bindings/power/mt8183-power.h create mode 100644 include/linux/soc/mediatek/scpsys-ext.h -- 2.18.0
[PATCH v2 08/11] clk: mediatek: Add MT8183 clock support
Add MT8183 clock support, include topckgen, apmixedsys, infracfg, mcucfg and subsystem clocks. Signed-off-by: Weiyi Lu --- drivers/clk/mediatek/Kconfig | 75 ++ drivers/clk/mediatek/Makefile | 12 + drivers/clk/mediatek/clk-gate.h| 14 + drivers/clk/mediatek/clk-mt8183-audio.c| 102 ++ drivers/clk/mediatek/clk-mt8183-cam.c | 70 ++ drivers/clk/mediatek/clk-mt8183-img.c | 70 ++ drivers/clk/mediatek/clk-mt8183-ipu0.c | 63 + drivers/clk/mediatek/clk-mt8183-ipu1.c | 63 + drivers/clk/mediatek/clk-mt8183-ipu_adl.c | 61 + drivers/clk/mediatek/clk-mt8183-ipu_conn.c | 130 ++ drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 61 + drivers/clk/mediatek/clk-mt8183-mm.c | 118 ++ drivers/clk/mediatek/clk-mt8183-vdec.c | 74 ++ drivers/clk/mediatek/clk-mt8183-venc.c | 66 + drivers/clk/mediatek/clk-mt8183.c | 1305 15 files changed, 2284 insertions(+) create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c create mode 100644 drivers/clk/mediatek/clk-mt8183.c diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig index 3dd1dab92223..5d4fd67fa259 100644 --- a/drivers/clk/mediatek/Kconfig +++ b/drivers/clk/mediatek/Kconfig @@ -193,4 +193,79 @@ config COMMON_CLK_MT8173 default ARCH_MEDIATEK ---help--- This driver supports MediaTek MT8173 clocks. + +config COMMON_CLK_MT8183 + bool "Clock driver for MediaTek MT8183" + depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST + select COMMON_CLK_MEDIATEK + default ARCH_MEDIATEK && ARM64 + help + This driver supports MediaTek MT8183 basic clocks. + +config COMMON_CLK_MT8183_AUDIOSYS + bool "Clock driver for MediaTek MT8183 audiosys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 audiosys clocks. + +config COMMON_CLK_MT8183_CAMSYS + bool "Clock driver for MediaTek MT8183 camsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 camsys clocks. + +config COMMON_CLK_MT8183_IMGSYS + bool "Clock driver for MediaTek MT8183 imgsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 imgsys clocks. + +config COMMON_CLK_MT8183_IPU_CORE0 + bool "Clock driver for MediaTek MT8183 ipu_core0" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_core0 clocks. + +config COMMON_CLK_MT8183_IPU_CORE1 + bool "Clock driver for MediaTek MT8183 ipu_core1" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_core1 clocks. + +config COMMON_CLK_MT8183_IPU_ADL + bool "Clock driver for MediaTek MT8183 ipu_adl" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_adl clocks. + +config COMMON_CLK_MT8183_IPU_CONN + bool "Clock driver for MediaTek MT8183 ipu_conn" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_conn clocks. + +config COMMON_CLK_MT8183_MFGCFG + bool "Clock driver for MediaTek MT8183 mfgcfg" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 mfgcfg clocks. + +config COMMON_CLK_MT8183_MMSYS + bool "Clock driver for MediaTek MT8183 mmsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 mmsys clocks. + +config COMMON_CLK_MT8183_VDECSYS + bool "Clock driver for MediaTek MT8183 vdecsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 vdecsys clocks. + +config COMMON_CLK_MT8183_VENCSYS + bool "Clock driver for MediaTek MT8183 vencsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 vencsys clocks. + endmenu diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile index b97980dbb738..885faa74cd70 100644 --- a/drivers/clk/mediatek/Makefile +++ b/drivers/clk/mediatek/Makefile @@ -28,3 +28,15 @@ obj-$(CONFIG_COMMON_CLK_MT7622_HIFSYS) += clk-mt7622-hif.o obj-$(CONFIG_COMMON_CLK_MT7622_AUDSYS) += clk-mt7622-aud.o obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt817
[PATCH v2 02/11] clk: mediatek: add new member to mtk_pll_data
From: Owen Chen
1. pcwibits: The integer bits of pcw for plls is extend to 8 bits,
add a variable to indicate this change and
backward-compatible.
2. fmin: The pll freqency lower-bound is vary from 1GMhz to
1.5Ghz, add a variable to indicate platform-dependent.
Signed-off-by: Owen Chen
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-mtk.h | 2 ++
drivers/clk/mediatek/clk-pll.c | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index f83c2bbb677e..11b5517903d0 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -214,8 +214,10 @@ struct mtk_pll_data {
unsigned int flags;
const struct clk_ops *ops;
u32 rst_bar_mask;
+ unsigned long fmin;
unsigned long fmax;
int pcwbits;
+ int pcwibits;
uint32_t pcw_reg;
int pcw_shift;
const struct mtk_pll_div_table *div_table;
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index f54e4015b0b1..1db161aced31 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -32,6 +32,8 @@
#define AUDPLL_TUNER_ENBIT(31)
#define POSTDIV_MASK 0x7
+
+/* default 7 bits integer, can be overridden with pcwibits. */
#define INTEGER_BITS 7
/*
@@ -69,11 +71,13 @@ static unsigned long __mtk_pll_recalc_rate(struct
mtk_clk_pll *pll, u32 fin,
{
int pcwbits = pll->data->pcwbits;
int pcwfbits;
+ int ibits;
u64 vco;
u8 c = 0;
/* The fractional part of the PLL divider. */
- pcwfbits = pcwbits > INTEGER_BITS ? pcwbits - INTEGER_BITS : 0;
+ ibits = pll->data->pcwibits ? pll->data->pcwibits : INTEGER_BITS;
+ pcwfbits = pcwbits > ibits ? pcwbits - ibits : 0;
vco = (u64)fin * pcw;
@@ -138,9 +142,10 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll,
u32 pcw,
static void mtk_pll_calc_values(struct mtk_clk_pll *pll, u32 *pcw, u32
*postdiv,
u32 freq, u32 fin)
{
- unsigned long fmin = 1000 * MHZ;
+ unsigned long fmin = pll->data->fmin ? pll->data->fmin : (1000 * MHZ);
const struct mtk_pll_div_table *div_table = pll->data->div_table;
u64 _pcw;
+ int ibits;
u32 val;
if (freq > pll->data->fmax)
@@ -164,7 +169,8 @@ static void mtk_pll_calc_values(struct mtk_clk_pll *pll,
u32 *pcw, u32 *postdiv,
}
/* _pcw = freq * postdiv / fin * 2^pcwfbits */
- _pcw = ((u64)freq << val) << (pll->data->pcwbits - INTEGER_BITS);
+ ibits = pll->data->pcwibits ? pll->data->pcwibits : INTEGER_BITS;
+ _pcw = ((u64)freq << val) << (pll->data->pcwbits - ibits);
do_div(_pcw, fin);
*pcw = (u32)_pcw;
--
2.18.0
[PATCH v2 05/11] dt-bindings: ARM: Mediatek: Document bindings for MT8183
This patch adds the binding documentation for apmixedsys, audiosys,
camsys, imgsys, infracfg, mcucfg, mfgcfg, mmsys, topckgen, vdecsys,
vencsys and ipu for Mediatek MT8183.
Signed-off-by: Weiyi Lu
Reviewed-by: Rob Herring
---
.../arm/mediatek/mediatek,apmixedsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,audsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,camsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,imgsys.txt | 1 +
.../arm/mediatek/mediatek,infracfg.txt| 1 +
.../bindings/arm/mediatek/mediatek,ipu.txt| 43 +++
.../bindings/arm/mediatek/mediatek,mcucfg.txt | 1 +
.../bindings/arm/mediatek/mediatek,mfgcfg.txt | 1 +
.../bindings/arm/mediatek/mediatek,mmsys.txt | 1 +
.../arm/mediatek/mediatek,topckgen.txt| 1 +
.../arm/mediatek/mediatek,vdecsys.txt | 1 +
.../arm/mediatek/mediatek,vencsys.txt | 1 +
12 files changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index 4e4a3c0ab9ab..641f19e036a2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -13,6 +13,7 @@ Required Properties:
- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8173-apmixedsys"
+ - "mediatek,mt8183-apmixedsys", "syscon"
- #clock-cells: Must be 1
The apmixedsys controller uses the common clk binding from
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
index d1606b2c3e63..f3cef1a6d95c 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
@@ -9,6 +9,7 @@ Required Properties:
- "mediatek,mt2701-audsys", "syscon"
- "mediatek,mt7622-audsys", "syscon"
- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
+ - "mediatek,mt8183-audiosys", "syscon"
- #clock-cells: Must be 1
The AUDSYS controller uses the common clk binding from
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
new file mode 100644
index ..d8930f64aa98
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
@@ -0,0 +1,22 @@
+MediaTek CAMSYS controller
+
+
+The MediaTek camsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be one of:
+ - "mediatek,mt8183-camsys", "syscon"
+- #clock-cells: Must be 1
+
+The camsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+camsys: camsys@1a00 {
+ compatible = "mediatek,mt8183-camsys", "syscon";
+ reg = <0 0x1a00 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index 3f99672163e3..e3bc4a1e7a6e 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -11,6 +11,7 @@ Required Properties:
- "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
+ - "mediatek,mt8183-imgsys", "syscon"
- #clock-cells: Must be 1
The imgsys controller uses the common clk binding from
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index 89f4272a1441..44b2f3281c34 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -14,6 +14,7 @@ Required Properties:
- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
+ - "mediatek,mt8183-infracfg", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
new file mode 100644
index ..aabc8c5c8ed2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
@@ -0,0 +1,43
[PATCH v2 06/11] clk: mediatek: Add dt-bindings for MT8183 clocks
Add MT8183 clock dt-bindings, include topckgen, apmixedsys, infracfg, mcucfg and subsystem clocks. Signed-off-by: Weiyi Lu Reviewed-by: Rob Herring --- include/dt-bindings/clock/mt8183-clk.h | 422 + 1 file changed, 422 insertions(+) create mode 100644 include/dt-bindings/clock/mt8183-clk.h diff --git a/include/dt-bindings/clock/mt8183-clk.h b/include/dt-bindings/clock/mt8183-clk.h new file mode 100644 index ..0046506eb24c --- /dev/null +++ b/include/dt-bindings/clock/mt8183-clk.h @@ -0,0 +1,422 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2018 MediaTek Inc. + * Author: Weiyi Lu + */ + +#ifndef _DT_BINDINGS_CLK_MT8183_H +#define _DT_BINDINGS_CLK_MT8183_H + +/* APMIXED */ +#define CLK_APMIXED_ARMPLL_LL 0 +#define CLK_APMIXED_ARMPLL_L 1 +#define CLK_APMIXED_CCIPLL 2 +#define CLK_APMIXED_MAINPLL3 +#define CLK_APMIXED_UNIV2PLL 4 +#define CLK_APMIXED_MSDCPLL5 +#define CLK_APMIXED_MMPLL 6 +#define CLK_APMIXED_MFGPLL 7 +#define CLK_APMIXED_TVDPLL 8 +#define CLK_APMIXED_APLL1 9 +#define CLK_APMIXED_APLL2 10 +#define CLK_APMIXED_SSUSB_26M 11 +#define CLK_APMIXED_APPLL_26M 12 +#define CLK_APMIXED_MIPIC0_26M 13 +#define CLK_APMIXED_MDPLLGP_26M14 +#define CLK_APMIXED_MMSYS_26M 15 +#define CLK_APMIXED_UFS_26M16 +#define CLK_APMIXED_MIPIC1_26M 17 +#define CLK_APMIXED_MEMPLL_26M 18 +#define CLK_APMIXED_CLKSQ_LVPLL_26M19 +#define CLK_APMIXED_MIPID0_26M 20 +#define CLK_APMIXED_MIPID1_26M 21 +#define CLK_APMIXED_NR_CLK 22 + +/* TOPCKGEN */ +#define CLK_TOP_MUX_AXI0 +#define CLK_TOP_MUX_MM 1 +#define CLK_TOP_MUX_CAM2 +#define CLK_TOP_MUX_MFG3 +#define CLK_TOP_MUX_CAMTG 4 +#define CLK_TOP_MUX_UART 5 +#define CLK_TOP_MUX_SPI6 +#define CLK_TOP_MUX_MSDC50_0_HCLK 7 +#define CLK_TOP_MUX_MSDC50_0 8 +#define CLK_TOP_MUX_MSDC30_1 9 +#define CLK_TOP_MUX_MSDC30_2 10 +#define CLK_TOP_MUX_AUDIO 11 +#define CLK_TOP_MUX_AUD_INTBUS 12 +#define CLK_TOP_MUX_FPWRAP_ULPOSC 13 +#define CLK_TOP_MUX_SCP14 +#define CLK_TOP_MUX_ATB15 +#define CLK_TOP_MUX_SSPM 16 +#define CLK_TOP_MUX_DPI0 17 +#define CLK_TOP_MUX_SCAM 18 +#define CLK_TOP_MUX_AUD_1 19 +#define CLK_TOP_MUX_AUD_2 20 +#define CLK_TOP_MUX_DISP_PWM 21 +#define CLK_TOP_MUX_SSUSB_TOP_XHCI 22 +#define CLK_TOP_MUX_USB_TOP23 +#define CLK_TOP_MUX_SPM24 +#define CLK_TOP_MUX_I2C25 +#define CLK_TOP_MUX_F52M_MFG 26 +#define CLK_TOP_MUX_SENINF 27 +#define CLK_TOP_MUX_DXCC 28 +#define CLK_TOP_MUX_CAMTG2 29 +#define CLK_TOP_MUX_AUD_ENG1 30 +#define CLK_TOP_MUX_AUD_ENG2 31 +#define CLK_TOP_MUX_FAES_UFSFDE32 +#define CLK_TOP_MUX_FUFS 33 +#define CLK_TOP_MUX_IMG34 +#define CLK_TOP_MUX_DSP35 +#define CLK_TOP_MUX_DSP1 36 +#define CLK_TOP_MUX_DSP2 37 +#define CLK_TOP_MUX_IPU_IF 38 +#define CLK_TOP_MUX_CAMTG3 39 +#define CLK_TOP_MUX_CAMTG4 40 +#define CLK_TOP_MUX_PMICSPI41 +#define CLK_TOP_SYSPLL_CK 42 +#define CLK_TOP_SYSPLL_D2 43 +#define CLK_TOP_SYSPLL_D3 44 +#define CLK_TOP_SYSPLL_D5 45 +#define CLK_TOP_SYSPLL_D7 46 +#define CLK_TOP_SYSPLL_D2_D2 47 +#define CLK_TOP_SYSPLL_D2_D4 48 +#define CLK_TOP_SYSPLL_D2_D8 49 +#define CLK_TOP_SYSPLL_D2_D16 50 +#define CLK_TOP_SYSPLL_D3_D2 51 +#define CLK_TOP_SYSPLL_D3_D4 52 +#define CLK_TOP_SYSPLL_D3_D8 53 +#define CLK_TOP_SYSPLL_D5_D2 54 +#define CLK_TOP_SYSPLL_D5_D4 55 +#define CLK_TOP_SYSPLL_D7_D2 56 +#define CLK_TOP_SYSPLL_D7_D4 57 +#define CLK_TOP_UNIVPLL_CK 58 +#define CLK_TOP_UNIVPLL_D2 59 +#define CLK_TOP_UNIVPLL_D3 60 +#define CLK_TOP_UNIVPLL_D5 61 +#define CLK_TOP_UNIVPLL_D7 62 +#define CLK_TOP_UNIVPLL_D2_D2 63 +#define CLK_TOP_UNIVPLL_D2_D4 64 +#define CLK_TOP_UNIVPLL_D2_D8 65 +#define CLK_TOP_UNIVPLL_D3_D2 66 +#define CLK_TOP_UNIVPLL_D3_D4 67 +#define CLK_TOP_UNIVPLL_D3_D8 68 +#define CLK_TOP_UNIVPLL_D5_D2 69 +#define CLK_TOP_UNIVPLL_D5_D4 70 +#define CLK_TOP_UNIVPLL_D5_D8 71 +#define CLK_TOP_APLL1_CK 72 +#define CLK_TOP_APLL1_D2
[PATCH v2 01/11] clk: mediatek: add new clkmux register API
From: Owen Chen
On both MT8183 & MT6765, there add "set/clr" register for
each clkmux setting, and one update register to trigger value change.
It is designed to prevent read-modify-write racing issue.
The sw design need to add a new API to handle this hw change with
a new mtk_clk_mux/mtk_mux struct in new file "clk-mux.c", "clk-mux.h".
Signed-off-by: Owen Chen
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/Makefile | 2 +-
drivers/clk/mediatek/clk-mux.c | 240 +
drivers/clk/mediatek/clk-mux.h | 101 ++
3 files changed, 342 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/mediatek/clk-mux.c
create mode 100644 drivers/clk/mediatek/clk-mux.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 844b55d2770d..b97980dbb738 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
clk-apmixed.o clk-cpumux.o reset.o
+obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
clk-apmixed.o clk-cpumux.o reset.o clk-mux.o
obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c
new file mode 100644
index ..8618e5fa2b30
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mux.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Owen Chen
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-mux.h"
+
+static inline struct mtk_clk_mux
+ *to_mtk_clk_mux(struct clk_hw *hw)
+{
+ return container_of(hw, struct mtk_clk_mux, hw);
+}
+
+static int mtk_clk_mux_enable(struct clk_hw *hw)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 mask = BIT(mux->gate_shift);
+
+ return regmap_update_bits(mux->regmap, mux->mux_ofs, mask, 0);
+}
+
+static void mtk_clk_mux_disable(struct clk_hw *hw)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 mask = BIT(mux->gate_shift);
+
+ regmap_update_bits(mux->regmap, mux->mux_ofs, mask, mask);
+}
+
+static int mtk_clk_mux_enable_setclr(struct clk_hw *hw)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 val;
+
+ val = BIT(mux->gate_shift);
+
+ return regmap_write(mux->regmap, mux->mux_clr_ofs, val);
+}
+
+static void mtk_clk_mux_disable_setclr(struct clk_hw *hw)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 val;
+
+ val = BIT(mux->gate_shift);
+ regmap_write(mux->regmap, mux->mux_set_ofs, val);
+}
+
+static int mtk_clk_mux_is_enabled(struct clk_hw *hw)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 val;
+
+ regmap_read(mux->regmap, mux->mux_ofs, &val);
+
+ return (val & BIT(mux->gate_shift)) == 0;
+}
+
+static u8 mtk_clk_mux_get_parent(struct clk_hw *hw)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 mask = GENMASK(mux->mux_width - 1, 0);
+ u32 val;
+
+ regmap_read(mux->regmap, mux->mux_ofs, &val);
+ val = (val >> mux->mux_shift) & mask;
+
+ return val;
+}
+
+static int mtk_clk_mux_set_parent_lock(struct clk_hw *hw, u8 index)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 mask = GENMASK(mux->mux_width - 1, 0);
+ u32 val;
+ unsigned long flags = 0;
+
+ if (mux->lock)
+ spin_lock_irqsave(mux->lock, flags);
+ else
+ __acquire(mux->lock);
+
+ regmap_read(mux->regmap, mux->mux_ofs, &val);
+ val = (val & mask) >> mux->mux_shift;
+
+ if (val != index) {
+ val = index << mux->mux_shift;
+ regmap_update_bits(mux->regmap, mux->mux_ofs, mask, val);
+ }
+
+ if (mux->lock)
+ spin_unlock_irqrestore(mux->lock, flags);
+ else
+ __release(mux->lock);
+
+ return 0;
+}
+
+static int mtk_clk_mux_set_parent_setclr_lock(struct clk_hw *hw, u8 index)
+{
+ struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
+ u32 mask = GENMASK(mux->mux_width - 1, 0);
+ u32 val, orig;
+ unsigned long flags = 0;
+
+ if (mux->lock)
+ spin_lock_irqsave(mux->lock, flags);
+ else
+ __acquire(mux->lock);
+
+ regmap_read(mux->regmap, mux->mux_ofs, &orig);
+ val = (orig & ~(mask << mux->mux_shift)) | (index << mux->mux_shift);
+
+ if (val != orig) {
+ regmap_write(mux->regmap, mux->mux_clr_ofs,
+ mask << mux->mux_shift);
+ regmap_write(mux->regmap, mux->mux_set_ofs,
+ index << mux->mux_shift);
+
+ if (mux->upd_shift >= 0)
+ regmap_write(mux->regmap, mu
[PATCH v2 07/11] clk: mediatek: Add flags support for mtk_gate data
On some Mediatek platforms, there are critical clocks of
clock gate type.
To register clock gate with flags CLK_IS_CRITICAL,
we need to add the flags field in mtk_gate data and register APIs.
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-gate.c | 5 +++--
drivers/clk/mediatek/clk-gate.h | 3 ++-
drivers/clk/mediatek/clk-mtk.c | 3 ++-
drivers/clk/mediatek/clk-mtk.h | 1 +
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 934bf0e45e26..85daf826619a 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -157,7 +157,8 @@ struct clk *mtk_clk_register_gate(
int clr_ofs,
int sta_ofs,
u8 bit,
- const struct clk_ops *ops)
+ const struct clk_ops *ops,
+ unsigned long flags)
{
struct mtk_clk_gate *cg;
struct clk *clk;
@@ -168,7 +169,7 @@ struct clk *mtk_clk_register_gate(
return ERR_PTR(-ENOMEM);
init.name = name;
- init.flags = CLK_SET_RATE_PARENT;
+ init.flags = flags | CLK_SET_RATE_PARENT;
init.parent_names = parent_name ? &parent_name : NULL;
init.num_parents = parent_name ? 1 : 0;
init.ops = ops;
diff --git a/drivers/clk/mediatek/clk-gate.h b/drivers/clk/mediatek/clk-gate.h
index 72ef89b3ad7b..9f766dfe1d57 100644
--- a/drivers/clk/mediatek/clk-gate.h
+++ b/drivers/clk/mediatek/clk-gate.h
@@ -47,6 +47,7 @@ struct clk *mtk_clk_register_gate(
int clr_ofs,
int sta_ofs,
u8 bit,
- const struct clk_ops *ops);
+ const struct clk_ops *ops,
+ unsigned long flags);
#endif /* __DRV_CLK_GATE_H */
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 9c0ae4278a94..35359e5397c7 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -130,7 +130,8 @@ int mtk_clk_register_gates(struct device_node *node,
gate->regs->set_ofs,
gate->regs->clr_ofs,
gate->regs->sta_ofs,
- gate->shift, gate->ops);
+ gate->shift, gate->ops,
+ gate->flags);
if (IS_ERR(clk)) {
pr_err("Failed to register clk %s: %ld\n",
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 11b5517903d0..928905496c4b 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -158,6 +158,7 @@ struct mtk_gate {
const struct mtk_gate_regs *regs;
int shift;
const struct clk_ops *ops;
+ unsigned long flags;
};
int mtk_clk_register_gates(struct device_node *node,
--
2.18.0
[PATCH v2 00/11] Mediatek MT8183 clock and scpsys support
This series is based on v4.20-rc1 and most of changes are extracted from series below (clock/scpsys common changes for both MT8183 & MT6765) https://patchwork.kernel.org/patch/10528495/ (clock support of MT8183) https://patchwork.kernel.org/patch/10549891/ The whole series is composed of clock common changes for both MT8183 & MT6765 (PATCH 1-3), scpsys common changes for both MT8183 & MT6765 (PATCH 4), clock support of MT8183 (PATCH 5-8), and scpsys support of MT8183 (PATCH 9-11). changes since v1: - refine for better code quality. - some minor bug fix of clock part, like incorrect control address and missing clocks.
[PATCH v2 04/11] soc: mediatek: add new flow for mtcmos power.
From: Owen Chen
Both MT8183 & MT6765 add more bus protect node than previous project,
therefore we add two more register for setup bus protect, which reside
at INFRA_CFG & SMI_COMMON.
With the following change
1. bus protect need not only infracfg but smi_common registers involved
to setup. Therefore we add a set/clr APIs with more customize arguments.
The second change is that we also add subsys CG control flow before/after
the bus protect/sram control, due to bus protect need SMI bus relative CGs
enable to feed-back its ack, and some master's sram control need CG enable
to on/off its resource sequentially.
With the following change
1. turn on subsys CG before sram pwron and release bus protect.
2. turn off subsys CG after the process of set bus protect/receive
ack/disable sram.
The last change is for some power domains like vpu_core on MT8183 whose
sram need to do clock and internal isolation while power on/off sram.
We add a flag "sram_iso_ctrl" in scp_domain_data to judge if we need to
do the extra sram isolation control or not.
Signed-off-by: Owen Chen
Signed-off-by: Mars Cheng
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/Makefile | 2 +-
drivers/soc/mediatek/mtk-scpsys-ext.c | 99 +++
drivers/soc/mediatek/mtk-scpsys.c | 379 +++-
include/linux/soc/mediatek/scpsys-ext.h | 39 +++
4 files changed, 448 insertions(+), 71 deletions(-)
create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b08819e..9dc6670c19cb 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
+obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-scpsys-ext.c
b/drivers/soc/mediatek/mtk-scpsys-ext.c
new file mode 100644
index ..54df42db2a8f
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-scpsys-ext.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Owen Chen
+ */
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_POLL_DELAY_US 10
+#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
+
+static int set_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
+ u32 reg_set, u32 reg_sta, u32 reg_en)
+{
+ u32 val;
+
+ if (reg_set)
+ regmap_write(map, reg_set, mask);
+ else
+ regmap_update_bits(map, reg_en, mask, mask);
+
+ return regmap_read_poll_timeout(map, reg_sta,
+ val, (val & ack_mask) == ack_mask,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+}
+
+static int clear_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
+ u32 reg_clr, u32 reg_sta, u32 reg_en)
+{
+ u32 val;
+
+ if (reg_clr)
+ regmap_write(map, reg_clr, mask);
+ else
+ regmap_update_bits(map, reg_en, mask, 0);
+
+ return regmap_read_poll_timeout(map, reg_sta,
+ val, !(val & ack_mask),
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+}
+
+int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
+ struct regmap *infracfg, struct regmap *smi_common)
+{
+ int i;
+
+ for (i = 0; i < MAX_STEPS && bp_table[i].mask; i++) {
+ struct regmap *map;
+ int ret;
+
+ if (bp_table[i].type == IFR_TYPE)
+ map = infracfg;
+ else if (bp_table[i].type == SMI_TYPE)
+ map = smi_common;
+ else
+ return -EINVAL;
+
+ ret = set_bus_protection(map,
+ bp_table[i].mask, bp_table[i].mask,
+ bp_table[i].set_ofs, bp_table[i].sta_ofs,
+ bp_table[i].en_ofs);
+
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
+ struct regmap *infracfg, struct regmap *smi_common)
+{
+ int i;
+
+ for (i = MAX_STEPS - 1; i >= 0; i--) {
+ struct regmap *map;
+ int ret;
+
+ if (bp_table[i].type == IFR_TYPE)
+ map = infracfg;
+ else if (bp_table[i].type == SMI_TYPE)
+ map = smi_common;
+ else
+ return -EINVAL;
+
+ ret = clear_bus_protection(map,
+ bp_table[i].mask, bp_table[i].clr_ack_mask,
+ bp_table[i].clr_ofs, bp_table[i].sta_ofs,
+ bp_table[i].en_ofs);
+
+
Re: [PATCH 2/2] perf report: Display average IPC and IPC coverage per symbol
On 11/26/2018 5:55 PM, Jiri Olsa wrote:
On Mon, Nov 26, 2018 at 05:40:54PM +0800, Jin Yao wrote:
SNIP
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index f96c005..94f62c8 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -13,6 +13,7 @@
#include "strlist.h"
#include
#include "mem-events.h"
+#include "annotate.h"
#include
regex_t parent_regex;
@@ -422,6 +423,47 @@ struct sort_entry sort_srcline_to = {
.se_width_idx = HISTC_SRCLINE_TO,
};
+static int hist_entry__sym_ipc_snprintf(struct hist_entry *he, char *bf,
+ size_t size, unsigned int width)
+{
+
+ struct symbol *sym = he->ms.sym;
+ struct map *map = he->ms.map;
+ struct perf_evsel *evsel = hists_to_evsel(he->hists);
+ struct annotation *notes;
+ double ipc = 0.0, coverage = 0.0;
+ char tmp[64];
+
+ if (!sym)
+ return repsep_snprintf(bf, size, "%-*s", width, "-");
+
+ if (!sym->annotated &&
+ symbol__annotate2(sym, map, evsel, &annotation__default_options,
+ NULL) < 0) {
+ return 0;
+ }
this seems to make the sorting extra long, would you
please consider progress bar update for this?
should be added somewhere around hists sorting code
Hi Jiri,
Sorting doesn't take long time in my test but the session event
processing takes some time.
I just think maybe we need a new ops for stdio progress bar like what
the tui_progress__ops does now. That should be benefit for all stdio usages.
That may be another separate patch-set.
Thanks
Jin Yao
thanks,
jirka
Re: [PATCH 3/3] soc: qcom: Add AOSS QMP genpd provider
Hi Bjorn,
On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
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.
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/Kconfig | 8 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/aoss-qmp-pd.c | 135 +
3 files changed, 144 insertions(+)
create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index ba08fc00d7f5..e1eda3d59748 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -10,6 +10,14 @@ 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
+ help
+ This driver provides the means of controlling the AOSSs 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 d0d7fdc94d9a..ebfa414a5b77 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 ..467d0db4abfa
--- /dev/null
+++ b/drivers/soc/qcom/aoss-qmp-pd.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct qmp_pd {
+ struct qmp *qmp;
+
+ struct generic_pm_domain pd;
+
+ const char *name;
+};
+
+#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[96];
+ size_t n;
+
+ n = snprintf(buf, sizeof(buf), "{class: clock, res: %s, val: %d}",
+res->name, !!enable);
+ return qmp_send(res->qmp, buf, n);
+}
+
I was trying to get QDSS working with these patches and found one issue
in qmp_send of qmp_pd_clock_toggle.
The third return value should be sizeof(buf) instead of n because n just
returns len as 33 and the below check in qmp send will always fail and
trigger WARN_ON's.
if (WARN_ON(len % sizeof(u32))) {
dev_err(qmp->dev, "message not 32-bit aligned\n");
return -EINVAL;
}
Also I observed that multiple "ucore will not ack channel" messages with
len being returned n instead of buf size.
One more thing is do we really require *WARN_ON and dev_err* both
because it just spams the kernel logs, I think dev_err message is clear
enough to be able to understand the error condition.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2] panic: Avoid the extra noise dmesg
Hi Andrew,
On Mon, Nov 26, 2018 at 03:59:52PM -0800, Andrew Morton wrote:
> On Thu, 8 Nov 2018 21:05:03 +0800 Feng Tang wrote:
>
> > Sometimes when debugging kernel panic, we saw many extra noisy error
> > messages after the expected end:
> >
> > [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception
> > [ 35.749975] [ cut here ]
>
> What are these "noisy messages"? The above looks OK?
Yes, the above is the sane messages :) and contains the necessary context
info for debug.
The noisy messages are those following messages, I tried to capture one with
sysrq and paste it in the tail of this mail as it's big (for a 4 cores
machine)
> > When panic happens under console mode, the screen will first show the panic
> > call stack, but will immediately be overrided by noisy extra messages, like
> > this for every CPU except the panic one:
> >
> > WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198
> > set_task_cpu+0x183/0x190
> > Call Trace:
> >
> > try_to_wake_up
> > default_wake_function
> > autoremove_wake_function
> > __wake_up_common
> > __wake_up_common_lock
> > __wake_up
> > wake_up_klogd_work_func
> > irq_work_run_list
> > irq_work_tick
> > update_process_times
> > tick_sched_timer
> > __hrtimer_run_queues
> > hrtimer_interrupt
> > smp_apic_timer_interrupt
> > apic_timer_interrupt
>
> And this output looks OK as well.
Yes, this is fine also. What I mean is it will be a little noisy if each and
every CPU will dump similar info, which will make it hard to find the real panic
context if a user has no serial console but a LCD.
> > Which make debugging more difficult, as the original context is
> > lost on screen.
> >
> > Keeping the CPU IRQ disabled will void these messages, as we code
> > run to this point, the user has chosed not to reboot, nor do
> > some extra handling with panic notifier, not much point in
> > re-enabling the interrupt.
>
> And please have another attempt at the above paragraph?
Sorry for the unclear info, will try to sanitize it.
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -295,7 +295,6 @@ void panic(const char *fmt, ...)
> > }
> > #endif
> > pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
> > - local_irq_enable();
> > for (i = 0; ; i += PANIC_TIMER_STEP) {
> > touch_softlockup_watchdog();
> > if (i >= i_next) {
>
> The patch looks reasonable, but the description is just too hard for me
> to follow, sorry. Please spend a bit more time over that and resend?
Sure and thanks for your review!
- Feng
---
Panic log:
#echo c > /proc/sysrq-trigger
[ 62.918474] sysrq: SysRq : Trigger a crash
[ 62.918643] BUG: unable to handle kernel NULL pointer dereference at
[ 62.918906] PGD 67e36067 P4D 67e36067 PUD 6189f067 PMD 0
[ 62.919092] Oops: 0002 [#1] PREEMPT SMP
[ 62.919226] CPU: 3 PID: 336 Comm: bash Tainted: G U W
4.19.0-19.iot-lts2018-sos-g6b95688-dirty #44
[ 62.919563] RIP: 0010:sysrq_handle_crash+0x16/0x20
[ 62.919726] Code: d5 e8 8e c2 bc ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00
00 55 48 89 e5 e8 77 31 c3 ff c7 05 65 9e 16 01 01 00 00 00 0f ae f8 04 25
00 00 00 00 01 5d c3 55 48 89 e5 fb 66 0f 1f 44 00 00 e8
[ 62.920332] RSP: 0018:9939a5ed3d98 EFLAGS: 00010246
[ 62.920508] RAX: RBX: 0063 RCX:
[ 62.920744] RDX: RSI: ba47f75b RDI: 0063
[ 62.920979] RBP: 9939a5ed3d98 R08: R09: 0c2e
[ 62.921216] R10: R11: ba932f0d R12: 0003
[ 62.921457] R13: R14: ba6807e0 R15:
[ 62.921693] FS: 7f3d2fb94740() GS:9939b4b8()
knlGS:
[ 62.921959] CS: 0010 DS: ES: CR0: 80050033
[ 62.922150] CR2: CR3: 6185d000 CR4: 003406e0
[ 62.922385] Call Trace:
[ 62.922476] __handle_sysrq+0xef/0x140
[ 62.922605] write_sysrq_trigger+0x4c/0x50
[ 62.922746] proc_reg_write+0x40/0x70
[ 62.922874] __vfs_write+0x35/0x180
[ 62.922997] ? __this_cpu_preempt_check+0x13/0x20
[ 62.923156] vfs_write+0xc5/0x1c0
[ 62.923271] ksys_write+0x53/0xc0
[ 62.923388] ? __audit_syscall_exit+0x20d/0x2a0
[ 62.923541] __x64_sys_write+0x15/0x20
[ 62.923671] do_syscall_64+0x4e/0x100
[ 62.923800] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 62.923970] RIP: 0033:0x7f3d2fca0664
[ 62.924093] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00
00 00 00 48 8d 05 99 20 0e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
[ 62.924699] RSP: 002b:7ffcf9071e98 EFLAGS: 0246 ORIG_RAX:
0001
[ 62.924949] RAX: ffda RBX: 0002 RCX: 7f3d2fca0664
[ 62.925184] RDX:
Re: [RFC PATCH RESEND v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
On Tue, Nov 27, 2018 at 04:07:32AM +0100, Elvira Khabirova wrote: > On Mon, 26 Nov 2018 15:35:24 +0100, Oleg Nesterov wrote: > > On 11/25, Elvira Khabirova wrote: > > > > > > Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops. > > > The information returned is the same as for syscall-enter-stops. > > > > Oh, this is not nice ;) there must be a better option, I hope... Plus > > > > Can't ptrace_get_syscall() check > > > > child->exit_code == (PTRACE_EVENT_SECCOMP << 8) | SIGTRAP; > > > > to detect the PTRACE_EVENT_SECCOMP case? > > Nope; looks like exit_code is zeroed after wait(). It's explicitly reset to zero in wait_task_stopped() unless WNOWAIT wait option is set. When strace requests PTRACE_GET_SYSCALL_INFO after wait4(), child->exit_code is already set to zero. -- ldv signature.asc Description: PGP signature
[PATCH 1/2] selftests: firmware: remove use of non-standard diff -Z option
diff -Z is used to trim the trailing whitespace when comparing the
loaded firmware file with the source firmware file. However, per the
comment in the source code, -Z should not be necessary. In testing, the
input and output files are identical.
Additionally, -Z is not a standard option and is not available in
environments such as busybox. When -Z is not supported, diff fails with
a usage error, which is suppressed, but then causes read_firmwares() to
exit with a false failure message.
Signed-off-by: Dan Rue
---
tools/testing/selftests/firmware/fw_filesystem.sh | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh
b/tools/testing/selftests/firmware/fw_filesystem.sh
index a4320c4b44dc..466cf2f91ba0 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -155,11 +155,8 @@ read_firmwares()
{
for i in $(seq 0 3); do
config_set_read_fw_idx $i
- # Verify the contents are what we expect.
- # -Z required for now -- check for yourself, md5sum
- # on $FW and DIR/read_firmware will yield the same. Even
- # cmp agrees, so something is off.
- if ! diff -q -Z "$FW" $DIR/read_firmware 2>/dev/null ; then
+ # Verify the contents match
+ if ! diff -q "$FW" $DIR/read_firmware 2>/dev/null ; then
echo "request #$i: firmware was not loaded" >&2
exit 1
fi
@@ -171,7 +168,7 @@ read_firmwares_expect_nofile()
for i in $(seq 0 3); do
config_set_read_fw_idx $i
# Ensures contents differ
- if diff -q -Z "$FW" $DIR/read_firmware 2>/dev/null ; then
+ if diff -q "$FW" $DIR/read_firmware 2>/dev/null ; then
echo "request $i: file was not expected to match" >&2
exit 1
fi
--
2.19.1
Re: [PATCH] f2fs: read page index before freeing
On 2018/11/27 8:22, PanBian wrote: > On Mon, Nov 26, 2018 at 07:07:08PM +0800, Chao Yu wrote: >> On 2018/11/26 18:28, PanBian wrote: >>> On Mon, Nov 26, 2018 at 05:13:53PM +0800, Chao Yu wrote: Hi Pan, On 2018/11/22 18:58, Pan Bian wrote: > The function truncate_node frees the page with f2fs_put_page. However, > the page index is read after that. So, the patch reads the index before > freeing the page. I notice that you found another use-after-free bug in ext4, out of curiosity, I'd like to ask how do you find those bugs? by tool or code review? >>> >>> I found such bugs by the aid of a tool I wrote recently. I designed a >>> method >>> to automatically find paired alloc/free functions. With such functions, I >>> wrote two checkers, one to check mismatched alloc/free bugs, the other to >>> check use-after-free and double-free bugs. >> >> Excellent! Do you have any plan to open its source or announce it w/ binary >> to linux kernel developers, I think w/ it we can help to improve kernel's >> code quality efficiently. > > Yes. I am now writing a paper about the method. I will open the source code > as soon as I complete the paper and some optimizations. Cool, if there is any progress, please let f2fs guys know, thank you in advance. :) Thanks, > > Best, > Pan > > > . >
[PATCH 0/2] selftests: firmware: fw_filesystem fix for busybox
Fix fw_filesystem.sh to run in an automated environment under busybox. After this change, fw_run_tests.sh still fails at some point in fw_fallback.sh, with error "usermode helper disabled so ignoring test". This is coming from fw_lib.sh:verify_reqs() because $HAS_FW_LOADER_USER_HELPER is set to no. Dan Rue (2): selftests: firmware: remove use of non-standard diff -Z option selftests: firmware: add CONFIG_FW_LOADER_USER_HELPER_FALLBACK to config tools/testing/selftests/firmware/config | 1 + tools/testing/selftests/firmware/fw_filesystem.sh | 9 +++-- 2 files changed, 4 insertions(+), 6 deletions(-) -- 2.19.1
[PATCH 2/2] selftests: firmware: add CONFIG_FW_LOADER_USER_HELPER_FALLBACK to config
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y is required for fw_fallback.sh. Without it, fw_fallback.sh fails with 'usermode helper disabled so ignoring test'. Enable the config in selftest so that it gets built by default. Signed-off-by: Dan Rue --- tools/testing/selftests/firmware/config | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/firmware/config b/tools/testing/selftests/firmware/config index bf634dda0720..913a25a4a32b 100644 --- a/tools/testing/selftests/firmware/config +++ b/tools/testing/selftests/firmware/config @@ -1,5 +1,6 @@ CONFIG_TEST_FIRMWARE=y CONFIG_FW_LOADER=y CONFIG_FW_LOADER_USER_HELPER=y +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y -- 2.19.1
[PATCH -next] platform/x86: intel-ips: remove unnecessary checks in ips_debugfs_init
As Greg KH explained in:
https://lkml.org/lkml/2015/8/15/114
There no need to check the return value of debugfs_create_file/
debugfs_create_dir.
This also fix static code checker warnings:
drivers/platform/x86/intel_ips.c:1314
ips_debugfs_init() warn: passing zero to 'PTR_ERR'
drivers/platform/x86/intel_ips.c:1328
ips_debugfs_init() warn: passing zero to 'PTR_ERR'
Signed-off-by: YueHaibing
---
drivers/platform/x86/intel_ips.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c
index 225638a..5c5dc82 100644
--- a/drivers/platform/x86/intel_ips.c
+++ b/drivers/platform/x86/intel_ips.c
@@ -1310,32 +1310,17 @@ static void ips_debugfs_init(struct ips_driver *ips)
int i;
ips->debug_root = debugfs_create_dir("ips", NULL);
- if (!ips->debug_root) {
- dev_err(ips->dev, "failed to create debugfs entries: %ld\n",
- PTR_ERR(ips->debug_root));
- return;
- }
for (i = 0; i < ARRAY_SIZE(ips_debug_files); i++) {
- struct dentry *ent;
struct ips_debugfs_node *node = &ips_debug_files[i];
node->ips = ips;
- ent = debugfs_create_file(node->name, S_IFREG | S_IRUGO,
- ips->debug_root, node,
- &ips_debugfs_ops);
- if (!ent) {
- dev_err(ips->dev, "failed to create debug file: %ld\n",
- PTR_ERR(ent));
- goto err_cleanup;
- }
+ debugfs_create_file(node->name, S_IFREG | S_IRUGO,
+ ips->debug_root, node,
+ &ips_debugfs_ops);
}
return;
-
-err_cleanup:
- ips_debugfs_cleanup(ips);
- return;
}
#endif /* CONFIG_DEBUG_FS */
--
2.7.0
Re: [RFC PATCH RESEND v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
On Mon, 26 Nov 2018 15:35:24 +0100
Oleg Nesterov wrote:
> On 11/25, Elvira Khabirova wrote:
> >
> > Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
> > The information returned is the same as for syscall-enter-stops.
>
> Oh, this is not nice ;) there must be a better option, I hope... Plus
>
>
> Can't ptrace_get_syscall() check
>
> child->exit_code == (PTRACE_EVENT_SECCOMP << 8) | SIGTRAP;
>
> to detect the PTRACE_EVENT_SECCOMP case?
Nope; looks like exit_code is zeroed after wait().
> Oleg.
>
> > Signed-off-by: Elvira Khabirova
> > Signed-off-by: Dmitry V. Levin
> > ---
> > include/linux/ptrace.h| 1 +
> > include/linux/sched.h | 1 +
> > include/linux/tracehook.h | 1 +
> > kernel/ptrace.c | 7 +--
> > 4 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> > index 6c2ffed907f5..a993d0fde865 100644
> > --- a/include/linux/ptrace.h
> > +++ b/include/linux/ptrace.h
> > @@ -166,6 +166,7 @@ static inline void ptrace_event(int event, unsigned
> > long message)
> > {
> > if (unlikely(ptrace_event_enabled(current, event))) {
> > current->ptrace_message = message;
> > + current->ptrace_event = event;
> > ptrace_notify((event << 8) | SIGTRAP);
> > } else if (event == PTRACE_EVENT_EXEC) {
> > /* legacy EXEC report via SIGTRAP */
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index a51c13c2b1a0..86215fb654d6 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -964,6 +964,7 @@ struct task_struct {
> >
> > /* Ptrace state: */
> > unsigned long ptrace_message;
> > + int ptrace_event;
> > kernel_siginfo_t*last_siginfo;
> >
> > struct task_io_accounting ioac;
> > diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
> > index 633a83fe7051..5d2e5aa07a5c 100644
> > --- a/include/linux/tracehook.h
> > +++ b/include/linux/tracehook.h
> > @@ -66,6 +66,7 @@ static inline int ptrace_report_syscall(struct pt_regs
> > *regs,
> > return 0;
> >
> > current->ptrace_message = message;
> > + current->ptrace_event = 0;
> > ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
> >
> > /*
> > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> > index 92c47cd5ad84..74a37e74c7f1 100644
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -904,7 +904,9 @@ static int ptrace_get_syscall(struct task_struct *child,
> > unsigned long actual_size;
> > unsigned long write_size;
> >
> > - if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) {
> > + if ((child->ptrace_event == 0 &&
> > +child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) ||
> > + child->ptrace_event == PTRACE_EVENT_SECCOMP) {
> > int i;
> >
> > info.op = PTRACE_SYSCALL_INFO_ENTRY;
> > @@ -917,7 +919,8 @@ static int ptrace_get_syscall(struct task_struct *child,
> > for (i = 0; i < ARRAY_SIZE(args); i++)
> > info.entry.args[i] = args[i];
> > actual_size = offsetofend(struct ptrace_syscall_info, entry);
> > - } else if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
> > + } else if (child->ptrace_event == 0 &&
> > + child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
> > info.op = PTRACE_SYSCALL_INFO_EXIT;
> > info.arch = syscall_get_arch(child);
> > info.exit.rval = syscall_get_error(child, regs);
> > --
> > 2.19.1
> >
>
RE: [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files
> -Original Message- > From: Greg KH > Sent: Monday, November 26, 2018 11:18 AM > To: KY Srinivasan > Cc: will.dea...@arm.com; catalin.mari...@armm.com; > mark.rutl...@arm.com; marc.zyng...@arm.com; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; Stephen Hemminger ; > Michael Kelley ; vkuznets > ; Michael Kelley > Subject: Re: [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files > > On Thu, Nov 22, 2018 at 03:10:56AM +, k...@linuxonhyperv.com wrote: > > --- /dev/null > > +++ b/arch/arm64/include/asm/hyperv-tlfs.h > > @@ -0,0 +1,338 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > + > > +/* > > + * This file contains definitions from the Hyper-V Hypervisor Top-Level > > + * Functional Specification (TLFS): > > + * > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs. > microsoft.com%2Fen-us%2Fvirtualization%2Fhyper-v-on- > windows%2Freference%2Ftlfs&data=02%7C01%7Ckys%40microsoft.co > m%7Cce3a8662cbbc4afe157508d653d3eadf%7C72f988bf86f141af91ab2d7cd0 > 11db47%7C1%7C0%7C636788566988323167&sdata=VJHHMNbpOdAANd > DNUD3UMuR8SkbBGOew7uy%2B%2BUCS2sE%3D&reserved=0 > > "interesting" url :( > > Care to use a real one? Will fix and resend. K. Y > > thanks, > > greg k-h
[PATCH v7 0/3] Huawei laptops
This patch set is based on new audio LED triggers in branch topic/leds-trigger from git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Changes from v6: * Use audio LED triggers patch set * Use KEY_CONFIG (XF86Tools) instead of KEY_PROG1. In Windows, the key is used to launch Huawei PC manager. XF86Tools is used by default on most desktop environments i.e. Gnome. Ayman Bagabas (3): ALSA: hda: fix front speakers on Huawei MBXP. x86: add support for Huawei WMI hotkeys. ALSA: hda: add support for Huawei WMI micmute LED drivers/platform/x86/Kconfig | 15 ++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/huawei-wmi.c | 247 ++ sound/pci/hda/patch_realtek.c | 22 +++ 4 files changed, 285 insertions(+) create mode 100644 drivers/platform/x86/huawei-wmi.c -- 2.19.1
[PATCH v7 2/3] x86: add support for Huawei WMI hotkeys.
This driver adds support for missing hotkeys on some Huawei laptops.
Currently, only Huawei Matebook X and Matebook X Pro is supported.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 15 ++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/huawei-wmi.c | 247 ++
3 files changed, 263 insertions(+)
create mode 100644 drivers/platform/x86/huawei-wmi.c
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 87f70e8f4dd0..0f9db4275fb4 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1292,6 +1292,21 @@ config INTEL_ATOMISP2_PM
To compile this driver as a module, choose M here: the module
will be called intel_atomisp2_pm.
+config HUAWEI_WMI
+ tristate "Huawei WMI hotkeys driver"
+ depends on ACPI_WMI
+ depends on INPUT
+ select INPUT_SPARSEKMAP
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_AUDIO
+ help
+ This driver provides support for Huawei WMI hotkeys.
+ It enables the missing keys and adds support to the micmute
+ LED found on some of these laptops.
+
+ To compile this driver as a module, choose M here: the module
+ will be called huawei-wmi.
+
endif # X86_PLATFORM_DEVICES
config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 39ae94135406..d841c550e3cc 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
obj-$(CONFIG_HP_ACCEL) += hp_accel.o
obj-$(CONFIG_HP_WIRELESS) += hp-wireless.o
obj-$(CONFIG_HP_WMI) += hp-wmi.o
+obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
obj-$(CONFIG_GPD_POCKET_FAN) += gpd-pocket-fan.o
obj-$(CONFIG_TC1100_WMI) += tc1100-wmi.o
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
new file mode 100644
index ..b6157c5b7f4a
--- /dev/null
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Huawei WMI hotkeys
+ *
+ * Copyright (C) 2018 Ayman Bagabas
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Ayman Bagabas ");
+MODULE_DESCRIPTION("Huawei WMI hotkeys");
+MODULE_LICENSE("GPL v2");
+
+/*
+ * Huawei WMI Events GUIDs
+ */
+#define MBX_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+#define MBXP_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+
+MODULE_ALIAS("wmi:"MBX_EVENT_GUID);
+MODULE_ALIAS("wmi:"MBXP_EVENT_GUID);
+
+static const struct key_entry huawei_wmi_keymap[] __initconst = {
+ { KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
+ { KE_KEY,0x282, { KEY_BRIGHTNESSUP } },
+ { KE_KEY,0x284, { KEY_MUTE } },
+ { KE_KEY,0x285, { KEY_VOLUMEDOWN } },
+ { KE_KEY,0x286, { KEY_VOLUMEUP } },
+ { KE_KEY,0x287, { KEY_MICMUTE } },
+ { KE_KEY,0x289, { KEY_WLAN } },
+ // Huawei |M| button
+ { KE_KEY,0x28a, { KEY_CONFIG } },
+ // Keyboard light
+ { KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
+ { KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
+ { KE_IGNORE, 0x295, { KEY_KBDILLUMUP } },
+ { KE_END,0 }
+};
+
+static char *event_guid;
+static struct input_dev *inputdev;
+
+static int huawei_wmi_micmute_led_set(bool on)
+{
+ acpi_handle handle;
+ char *method;
+ union acpi_object args[3];
+ struct acpi_object_list arg_list = {
+ .pointer = args,
+ .count = ARRAY_SIZE(args),
+ };
+
+ handle = ACPI_HANDLE(&inputdev->dev);
+ args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
+ args[1].integer.value = 0x04;
+
+ if (acpi_has_method(handle, method = "\\_SB.PCI0.LPCB.EC0.SPIN")) {
+ args[0].integer.value = 0;
+ args[2].integer.value = on ? 1 : 0;
+ } else if (acpi_has_method(handle, method =
"\\_SB.PCI0.LPCB.EC0.WPIN")) {
+ args[0].integer.value = 1;
+ args[2].integer.value = on ? 0 : 1;
+ } else {
+ dev_err(&inputdev->dev, "Unable to find ACPI method\n");
+ return -ENOSYS;
+ }
+
+ acpi_evaluate_object(handle, method, &arg_list, NULL);
+
+ return 0;
+}
+
+static int micmute_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ int state = brightness != LED_OFF;
+ int err;
+
+ err = huawei_wmi_micmute_led_set(state);
+ return err < 0 ? err : 0;
+}
+
+static struct led_classdev micmute_led_cdev = {
+ .name = "huawei::micmute",
+ .max_brightness = 1,
+ .brightness_set_blocking = micmute_led_set,
+ .default_trigger = "audio-micmut
[PATCH v7 1/3] ALSA: hda: fix front speakers on Huawei MBXP.
This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.
Signed-off-by: Ayman Bagabas
Reviewed-by: Takashi Iwai
---
sound/pci/hda/patch_realtek.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 993d34c141c2..1326f32f4574 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5490,6 +5490,7 @@ enum {
ALC298_FIXUP_TPT470_DOCK,
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
+ ALC256_FIXUP_HUAWEI_MBXP_PINS,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
};
@@ -5761,6 +5762,22 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ {0x12, 0x90a60130},
+ {0x13, 0x4000},
+ {0x14, 0x90170110},
+ {0x18, 0x41f0},
+ {0x19, 0x04a11040},
+ {0x1a, 0x41f0},
+ {0x1b, 0x90170112},
+ {0x1d, 0x40759a05},
+ {0x1e, 0x41f0},
+ {0x21, 0x04211020},
+ { }
+ }
+ },
[ALC269_FIXUP_ASUS_X101_FUNC] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc269_fixup_x101_headset_mic,
@@ -6591,6 +6608,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
+ SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP",
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ",
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
#if 0
--
2.19.1
[PATCH v7 3/3] ALSA: hda: add support for Huawei WMI micmute LED
Some of Huawei laptops come with a LED in the micmute key. This patch
enables the use of micmute LED for these devices:
1. Matebook X (19e5:3200), (19e5:3201)
2. Matebook X Pro (19e5:3204)
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/patch_realtek.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1326f32f4574..9766fd249bdf 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5776,7 +5776,9 @@ static const struct hda_fixup alc269_fixups[] = {
{0x1e, 0x41f0},
{0x21, 0x04211020},
{ }
- }
+ },
+ .chained = true,
+ .chain_id = ALC255_FIXUP_MIC_MUTE_LED
},
[ALC269_FIXUP_ASUS_X101_FUNC] = {
.type = HDA_FIXUP_FUNC,
@@ -6608,6 +6610,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
+ SND_PCI_QUIRK(0x19e5, 0x3200, "Huawei MBX", ALC255_FIXUP_MIC_MUTE_LED),
+ SND_PCI_QUIRK(0x19e5, 0x3201, "Huawei MBX", ALC255_FIXUP_MIC_MUTE_LED),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP",
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ",
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
--
2.19.1
