Re: [Jfs-discussion] [PATCH] jfs: Add missing NULL pointer check in __get_metapage
On 10/30/2017 11:13 PM, Dave Kleikamp wrote:
> On 10/25/2017 02:50 AM, Juerg Haefliger wrote:
>> Is this a patch you might consider?
>
> Sorry it's taken me so long to respond.
>
> I don't think this is the right fix. A failed allocation will still
> result in a null pointer dereference by the caller, __get_metapage(). I
> think the check needs to be put there. Like this:
>
> --- a/fs/jfs/jfs_metapage.c
> +++ b/fs/jfs/jfs_metapage.c
> @@ -663,6 +663,8 @@ struct metapage *__get_metapage(struct inode *inode,
> unsigned long lblock,
> } else {
> INCREMENT(mpStat.pagealloc);
> mp = alloc_metapage(GFP_NOFS);
> + if (!mp)
> + goto unlock;
> mp->page = page;
> mp->sb = inode->i_sb;
> mp->flag = 0;
I don't understand. This is part of the patch that I sent.
>
> Furthermore, it looks like all the callers of __get_metapage() check for
> a null return, so I'm not sure we need to handle the error at this
> point. I might have to look a bit harder at that, since there are many
> callers.
I don't understand this either :-) Yes, the callers do check for a null
pointer but things blow up (in __get_metapage) before that check without
the above fix.
...Juerg
>
> Thanks,
> Shaggy
>
>>
>> Thanks
>> ...Juerg
>>
>>
>> On 10/04/2017 10:24 AM, Juerg Haefliger wrote:
>>> alloc_metapage can return a NULL pointer so check for that. And also emit
>>> an error message if that happens.
>>>
>>> Signed-off-by: Juerg Haefliger
>>> ---
>>> fs/jfs/jfs_metapage.c | 20 +---
>>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
>>> index 1c4b9ad4d7ab..00f21af66872 100644
>>> --- a/fs/jfs/jfs_metapage.c
>>> +++ b/fs/jfs/jfs_metapage.c
>>> @@ -187,14 +187,18 @@ static inline struct metapage *alloc_metapage(gfp_t
>>> gfp_mask)
>>> {
>>> struct metapage *mp = mempool_alloc(metapage_mempool, gfp_mask);
>>>
>>> - if (mp) {
>>> - mp->lid = 0;
>>> - mp->lsn = 0;
>>> - mp->data = NULL;
>>> - mp->clsn = 0;
>>> - mp->log = NULL;
>>> - init_waitqueue_head(&mp->wait);
>>> + if (!mp) {
>>> + jfs_err("mempool_alloc failed!\n");
>>> + return NULL;
>>> }
>>> +
>>> + mp->lid = 0;
>>> + mp->lsn = 0;
>>> + mp->data = NULL;
>>> + mp->clsn = 0;
>>> + mp->log = NULL;
>>> + init_waitqueue_head(&mp->wait);
>>> +
>>> return mp;
>>> }
>>>
>>> @@ -663,6 +667,8 @@ struct metapage *__get_metapage(struct inode *inode,
>>> unsigned long lblock,
>>> } else {
>>> INCREMENT(mpStat.pagealloc);
>>> mp = alloc_metapage(GFP_NOFS);
>>> + if (!mp)
>>> + goto unlock;
>>> mp->page = page;
>>> mp->sb = inode->i_sb;
>>> mp->flag = 0;
>>>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] net: hns3: remove a couple of redundant assignments
From: Colin King Date: Wed, 1 Nov 2017 10:17:15 + > From: Colin Ian King > > The assignment to kinfo is redundant as this is a duplicate of > the initialiation of kinfo a few lines earlier, so it can be > removed. The assignment to v_tc_info is never read, so this > variable is redundant and can be removed completely. Cleans > up two clang warnings: > > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c:433:34: > warning: Value stored to 'kinfo' during its initialization is never read > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c:775:3: > warning: Value stored to 'v_tc_info' is never read > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH v2 1/2] futex: futex_wake_op, do not fail on invalid op
Hi,
is this OK/going to be applied to 4.14 yet or postponed to 4.15-rc?
On 10/23/2017, 01:41 PM, Jiri Slaby wrote:
> In 30d6e0a4190d ("futex: Remove duplicated code and fix undefined
> behaviour"), I let FUTEX_WAKE_OP to fail on invalid op. Namely when
> op should be considered as shift and the shift is out of range (< 0 or
>> 31).
>
> But strace's test suite does this madness:
> futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xa0caffee);
> futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xbadfaced);
> futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0x);
>
> When I pick the first 0xa0caffee, it decodes as:
> 0x8000 & 0xa0caffee: oparg is shift
> 0x7000 & 0xa0caffee: op is FUTEX_OP_OR
> 0x0f00 & 0xa0caffee: cmp is FUTEX_OP_CMP_EQ
> 0x00fff000 & 0xa0caffee: oparg is sign-extended 0xcaf = -849
> 0x0fff & 0xa0caffee: cmparg is sign-extended 0xfee = -18
>
> That means the op tries to do this:
> (futex |= (1 << (-849))) == -18
> which is completely bogus. The new check of op in the code is:
> if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
> if (oparg < 0 || oparg > 31)
> return -EINVAL;
> oparg = 1 << oparg;
> }
>
> which results obviously in the "Invalid argument" errno:
> 8<8<8<8<8<
> FAIL: futex
> ===
>
> futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xa0caffee) = -1:
> Invalid argument
> futex.test: failed test: ../futex failed with code 1
> 8<8<8<8<8<
>
> So let us soften the failure to print only a (ratelimited) message,
> crop the value and continue as if it were right. When userspace keeps
> up, we can switch this to return -EINVAL again.
>
> [v2]
> Do not return 0 immediatelly, proceed with the cropped value.
>
> Fixes: 30d6e0a4190d ("futex: Remove duplicated code and fix undefined
> behaviour")
> Signed-off-by: Jiri Slaby
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Darren Hart
> Cc: Linus Torvalds
> ---
> kernel/futex.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 0518a0bfc746..0d638f008bb1 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -1570,8 +1570,16 @@ static int futex_atomic_op_inuser(unsigned int
> encoded_op, u32 __user *uaddr)
> int oldval, ret;
>
> if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
> - if (oparg < 0 || oparg > 31)
> - return -EINVAL;
> + if (oparg < 0 || oparg > 31) {
> + char comm[sizeof(current->comm)];
> + /*
> + * kill this print and return -EINVAL when userspace
> + * is sane again
> + */
> + pr_info_ratelimited("futex_wake_op: %s tries to shift
> op by %d; fix this program\n",
> + get_task_comm(comm, current), oparg);
> + oparg &= 31;
> + }
> oparg = 1 << oparg;
> }
>
>
--
js
suse labs
Re: [PATCH] liquidio: remove redundant setting of inst_processed to zero
From: Colin King Date: Wed, 1 Nov 2017 09:09:13 + > From: Colin Ian King > > The zero value assigned to inst_processed at the end of each > iteration of the do-while loop is overwritten on the next iteration > and hence it is a redundant assignment and can be removed. Cleans > up clang warning: > > drivers/net/ethernet/cavium/liquidio/request_manager.c:480:3: > warning: Value stored to 'inst_processed' is never read > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH] net: dl2k: remove redundant re-assignment to np
From: Colin King Date: Wed, 1 Nov 2017 08:57:37 + > From: Colin Ian King > > The pointer np is initialized and then re-assigned the same value > a few lines later. Remove the redundant duplicated assignment. Cleans > up clang warning: > > drivers/net/ethernet/dlink/dl2k.c:314:25: warning: Value stored to > 'np' during its initialization is never read > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH] wan: wanxl: remove redundant assignment to stat
From: Colin King Date: Wed, 1 Nov 2017 08:49:45 + > From: Colin Ian King > > stat set to zero and the value is never read, instead stat is > set again in the do-loop. Hence the setting to zero is redundant > and can be removed. Cleans up clang warning: > > drivers/net/wan/wanxl.c:737:2: warning: Value stored to 'stat' > is never read > > Signed-off-by: Colin Ian King Applied.
linux-next: build failure after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
arch/powerpc/kernel/irq.o: In function `.replay_system_reset':
irq.c:(.text+0x10): undefined reference to `.ppc_save_regs'
Caused by commit
78adf6c214f0 ("powerpc/64s: Implement system reset idle wakeup reason")
I have applied the following fix patch:
From: Stephen Rothwell
Date: Thu, 2 Nov 2017 17:45:18 +1100
Subject: [PATCH] powerpc/64s: ppc_save_regs is now needed for all 64s builds
Fixes: 78adf6c214f0 ("powerpc/64s: Implement system reset idle wakeup reason")
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 91960f83039c..34b6e729f38c 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -128,7 +128,7 @@ obj64-$(CONFIG_PPC_TRANSACTIONAL_MEM) += tm.o
obj-$(CONFIG_PPC64)+= $(obj64-y)
obj-$(CONFIG_PPC32)+= $(obj32-y)
-ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC_CORE),)
+ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC_CORE)(CONFIG_PPC_BOOK3S),)
obj-y += ppc_save_regs.o
endif
--
2.14.1
--
Cheers,
Stephen Rothwell
Re: [PATCH v2 0/2] KVM: MMU: fix kvm_is_mmio_pfn()
On 10/31/17 19:48 +0800, Haozhong Zhang wrote: > [I just copy the commit message from patch 2] > > Some reserved pages, such as those from NVDIMM DAX devices, are > not for MMIO, and can be mapped with cached memory type for better > performance. However, the above check misconceives those pages as > MMIO. Because KVM maps MMIO pages with UC memory type, the > performance of guest accesses to those pages would be harmed. > Therefore, we check the host memory type by lookup_memtype() in > addition and only treat UC/UC- pages as MMIO. > > Changes in v2: > * Switch to lookup_memtype() to get host memory type. > * Rewrite the comment in KVM MMU patch. > * Remove v1 patch 2, which is not necessary in v2. > > Haozhong Zhang (2): > x86/mm: expose lookup_memtype() > KVM: MMU: consider host cache mode in MMIO page check > > arch/x86/include/asm/pat.h | 2 ++ > arch/x86/kvm/mmu.c | 30 +++--- > arch/x86/mm/pat.c | 3 ++- > 3 files changed, 31 insertions(+), 4 deletions(-) > > -- > 2.14.1 > Hi Paolo, This patchset fixed a performance drop issue when using NVDIMM on KVM, so I think it's nice to have in 4.14. Can you help to review it? Thanks, Haozhong
Re: [PATCH 2/2] clk: qcom: Modify RCG shared ops to support freq_tbl without XO entry
On 10/31, Amit Nischal wrote: > There could be some clock sources where there is no entry corresponding > XO in their frequency table, for such sources rcg2_shared_ops would > wrongly configure the RCG registers during enable/disable, which leads > to mismatch between the hardware and software rate so modify the shared > ops to handle such cases. > > Signed-off-by: Amit Nischal The shared rcg ops were orphaned and then deleted recently. Please bring this topic back up again when you have code that uses these ops. We can bring the code back in the proper way then. Also, don't hard-code 19.2MHz into the code as the CXO frequency. We've experienced that change in the past, so hard-coding those things just doesn't work. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: qcom: Remove unused RCG ops
On 08/24, Georgi Djakov wrote: > The RCGs ops for shared branches are not used now, so remove it. > > Signed-off-by: Georgi Djakov > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3] clk: at91: utmi: set the mainck rate
On 09/06, Ludovic Desroches wrote: > By default, it is assumed that the UTMI clock is generated from a 12 MHz > reference clock (MAINCK). If it's not the case, the FREQ field of the > SFR_UTMICKTRIM has to be updated to generate the UTMI clock in the > proper way. > > The UTMI clock has a fixed rate of 480 MHz. In fact, there is no > multiplier we can configure. The multiplier is managed internally, > depending on the reference clock frequency, to achieve the target of > 480 MHz. > > Signed-off-by: Ludovic Desroches > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs
On 09/01, Stephen Boyd wrote: > Sometimes we only have one of_clk_del_provider() call in driver > error and remove paths, because we're missing a > devm_of_clk_add_hw_provider() API. Introduce the API so we can > convert drivers to use this and potentially reduce the amount of > code needed to remove providers in drivers. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/2] clk: qcom: common: Migrate to devm_* APIs for resets and clk providers
On 09/01, Stephen Boyd wrote: > Now that we have devm APIs for the reset controller and of clk hw > provider APIs we can remove the custom code here. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/2] hwmon: (w83773g) Add documentation
Add documentation for the w83773g driver. Signed-off-by: Lei YU --- Documentation/hwmon/w83773g | 28 1 file changed, 28 insertions(+) create mode 100644 Documentation/hwmon/w83773g diff --git a/Documentation/hwmon/w83773g b/Documentation/hwmon/w83773g new file mode 100644 index 000..da28731 --- /dev/null +++ b/Documentation/hwmon/w83773g @@ -0,0 +1,28 @@ +Kernel driver w83773g + + +Supported chips: + * Nuvoton W83773G +Prefix: 'w83773g' +Addresses scanned: I2C 0x4c and 0x4d +Datasheet: https://www.nuvoton.com/resource-files/W83773G_SG_DatasheetV1_2.pdf + +Authors: + Lei YU + +Description +--- + +This driver implements support for Nuvoton W83773G temperature sensor +chip. This chip implements one local and two remote sensors. +Temperature is measured in degrees Celsius. +The chip is wired over I2C/SMBus and specified over a temperature +range of -40 to +125 degrees Celsius (for local sensor) and -40 to +127 +degrees Celsius (for remote sensors). +Resolution for both the local and remote channels is 0.125 degree C. + +The chip supports only temperature measurement. The driver exports +the temperature values via the following sysfs files: + +temp[1-3]_input +temp[2-3]_fault -- 1.9.1
[PATCH 0/2] Add W83773G hwmon sensor driver and doc
Nuvoton W83773G is a hardware monitoring chip, which integrates two remote and one local temperature sensors. Lei YU (2): drivers: hwmon: Add W83773G driver hwmon: (w83773g) Add documentation Documentation/hwmon/w83773g | 28 + drivers/hwmon/Kconfig | 11 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/w83773g.c | 276 4 files changed, 316 insertions(+) create mode 100644 Documentation/hwmon/w83773g create mode 100644 drivers/hwmon/w83773g.c -- 1.9.1
[PATCH 1/2] drivers: hwmon: Add W83773G driver
Nuvoton W83773G is a hardware monitor IC providing one local
temperature and two remote temperature sensors.
Signed-off-by: Lei YU
---
drivers/hwmon/Kconfig | 11 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/w83773g.c | 276
3 files changed, 288 insertions(+)
create mode 100644 drivers/hwmon/w83773g.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index d654314..d148b70 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1710,6 +1710,17 @@ config SENSORS_VT8231
This driver can also be built as a module. If so, the module
will be called vt8231.
+config SENSORS_W83773G
+ tristate "Nuvoton W83773G"
+ depends on I2C
+ select HWMON_VID
+ help
+ If you say yes here you get support for the Nuvoton W83773G hardware
+ monitoring chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called w83773g.
+
config SENSORS_W83781D
tristate "Winbond W83781D, W83782D, W83783S, Asus AS99127F"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index c84d978..0649ad8 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_SENSORS_ATK0110) += asus_atk0110.o
# asb100, then w83781d go first, as they can override other drivers' addresses.
obj-$(CONFIG_SENSORS_ASB100) += asb100.o
obj-$(CONFIG_SENSORS_W83627HF) += w83627hf.o
+obj-$(CONFIG_SENSORS_W83773G) += w83773g.o
obj-$(CONFIG_SENSORS_W83792D) += w83792d.o
obj-$(CONFIG_SENSORS_W83793) += w83793.o
obj-$(CONFIG_SENSORS_W83795) += w83795.o
diff --git a/drivers/hwmon/w83773g.c b/drivers/hwmon/w83773g.c
new file mode 100644
index 000..16d5fa0
--- /dev/null
+++ b/drivers/hwmon/w83773g.c
@@ -0,0 +1,276 @@
+/*
+ * Copyright (C) 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+/*
+ * Driver for the Nuvoton W83773G SMBus temperature sensor IC.
+ * Supported models: W83773G
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Addresses to scan */
+static const unsigned short normal_i2c[] = { 0x4c, 0x4d, I2C_CLIENT_END };
+
+enum chips { w83773g };
+
+/* The W83773 registers */
+#define W83773_CONVERSION_RATE_REG_READ 0x04
+#define W83773_CONVERSION_RATE_REG_WRITE 0x0A
+#define W83773_MANUFACTURER_ID_REG 0xFE
+#define W83773_LOCAL_TEMP 0x00
+
+static const u8 W83773_STATUS[2] = { 0x02, 0x17 };
+
+static const u8 W83773_TEMP_LSB[2] = { 0x10, 0x25 };
+static const u8 W83773_TEMP_MSB[2] = { 0x01, 0x24 };
+
+static const u8 W83773_OFFSET_LSB[2] = { 0x12, 0x16 };
+static const u8 W83773_OFFSET_MSB[2] = { 0x11, 0x15 };
+
+/* Manufacturer / Device ID's */
+#define W83773_MANUFACTURER_ID 0x5c
+
+
+/* this is the number of sensors in the device */
+static const struct i2c_device_id w83773_id[] = {
+ { "w83773g", 3 },
+ { }
+};
+
+MODULE_DEVICE_TABLE(i2c, w83773_id);
+
+static const struct of_device_id w83773_of_match[] = {
+ {
+ .compatible = "nuvoton,w83773g",
+ .data = (void *)3
+ },
+
+ { },
+};
+MODULE_DEVICE_TABLE(of, w83773_of_match);
+
+/*
+ * W83773G has 3 temp sensors:
+ * Channel 0 is the local sensor
+ * Channel 1-2 are two remote sensors
+ */
+struct w83773_data {
+ struct i2c_client *client;
+ struct mutex update_lock;
+ u32 temp_config[4];
+ struct hwmon_channel_info temp_info;
+ const struct hwmon_channel_info *info[2];
+ struct hwmon_chip_info chip;
+ bool valid;
+ unsigned long last_updated;
+ int channels;
+ s8 temp_local;
+ s8 status[2];
+ s8 temp_hb[2];
+ s8 temp_lb[2];
+ s8 offset_hb[2];
+ s8 offset_lb[2];
+};
+
+static long temp_of_local(s8 reg)
+{
+ return reg * 1000;
+}
+
+static long temp_of_remote(s8 hb, s8 lb, s8 offset_hb, s8 offset_lb)
+{
+ return (hb + offset_hb) * 1000 + ((u8)(lb + offset_lb) >> 5) * 125;
+}
+
+
+static struct w83773_data *w83773_update_device(struct device *dev)
+{
+ struct w83773_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ int i;
+
+ mutex_lock(&data->update_lock);
+
+ if (time_after(jiffies, data->last_updated + 2 * HZ) || !data->valid) {
+ data->temp_local = i2c_smbus_read_byte_data(client,
W83773_LOCAL_TEMP);
+ for (i = 0; i < data->channels - 1; i++) {
+ data->status[i] = i2c_smbus_read_byte_data(client,
W83773_STATUS[i]);
+ data->temp_hb[i] = i2c_smbus_read_byte_data(client,
W83773_TEMP_MSB[i]);
+ data->tem
[PATCH] mm: page_ext: allocate page extension though first PFN is invalid
online_page_ext and page_ext_init allocate page_ext for each section, but
they do not allocate if the first PFN is !pfn_present(pfn) or
!pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext
checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN,
__set_page_owner will try to get page_ext through lookup_page_ext.
Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value
0. This incurrs invalid address access.
This is the panic example when PFN 0x10 is not valid but PFN 0x13FC00
is being used for page_ext. section->page_ext is NULL, get_entry returned
invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00.
<1>[ 11.618085] Unable to handle kernel paging request at virtual address
01dfa014
<1>[ 11.618140] pgd = ffc0c6dc9000
<1>[ 11.618174] [01dfa014] *pgd=, *pud=
<4>[ 11.618240] [ cut here ]
<2>[ 11.618278] Kernel BUG at ff80082371e0 [verbose debug info
unavailable]
<0>[ 11.618338] Internal error: Oops: 9645 [#1] PREEMPT SMP
<4>[ 11.618381] Modules linked in:
<4>[ 11.618524] task: ffc0c6ec9180 task.stack: ffc0c6f4
<4>[ 11.618569] PC is at __set_page_owner+0x48/0x78
<4>[ 11.618607] LR is at __set_page_owner+0x44/0x78
<4>[ 11.626025] [] __set_page_owner+0x48/0x78
<4>[ 11.626071] [] get_page_from_freelist+0x880/0x8e8
<4>[ 11.626118] [] __alloc_pages_nodemask+0x14c/0xc48
<4>[ 11.626165] [] __do_page_cache_readahead+0xdc/0x264
<4>[ 11.626214] [] filemap_fault+0x2ac/0x550
<4>[ 11.626259] [] ext4_filemap_fault+0x3c/0x58
<4>[ 11.626305] [] __do_fault+0x80/0x120
<4>[ 11.626347] [] handle_mm_fault+0x704/0xbb0
<4>[ 11.626393] [] do_page_fault+0x2e8/0x394
<4>[ 11.626437] [] do_mem_abort+0x88/0x124
Though the first page is not valid, page_ext could be useful for other
pages in the section. But checking all PFNs in a section may be time
consuming job. Let's check each (section count / 16) PFN, then prepare
page_ext if any PFN is present or valid. And remove the CONFIG_DEBUG_VM in
lookup_page_ext to avoid panic.
Signed-off-by: Jaewon Kim
---
mm/page_ext.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 32f18911deda..bf9c99beb312 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -124,7 +124,6 @@ struct page_ext *lookup_page_ext(struct page *page)
struct page_ext *base;
base = NODE_DATA(page_to_nid(page))->node_page_ext;
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -133,7 +132,6 @@ struct page_ext *lookup_page_ext(struct page *page)
*/
if (unlikely(!base))
return NULL;
-#endif
index = pfn - round_down(node_start_pfn(page_to_nid(page)),
MAX_ORDER_NR_PAGES);
return get_entry(base, index);
@@ -198,7 +196,6 @@ struct page_ext *lookup_page_ext(struct page *page)
{
unsigned long pfn = page_to_pfn(page);
struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -207,7 +204,6 @@ struct page_ext *lookup_page_ext(struct page *page)
*/
if (!section->page_ext)
return NULL;
-#endif
return get_entry(section->page_ext, pfn);
}
@@ -312,7 +308,17 @@ static int __meminit online_page_ext(unsigned long
start_pfn,
}
for (pfn = start; !fail && pfn < end; pfn += PAGES_PER_SECTION) {
- if (!pfn_present(pfn))
+ unsigned long t_pfn = pfn;
+ bool present = false;
+
+ while (t_pfn < ALIGN(pfn + 1, PAGES_PER_SECTION)) {
+ if (pfn_present(t_pfn)) {
+ present = true;
+ break;
+ }
+ t_pfn = ALIGN(pfn + 1, PAGES_PER_SECTION >> 4);
+ }
+ if (!present)
continue;
fail = init_section_page_ext(pfn, nid);
}
@@ -391,8 +397,17 @@ void __init page_ext_init(void)
*/
for (pfn = start_pfn; pfn < end_pfn;
pfn = ALIGN(pfn + 1, PAGES_PER_SECTION)) {
-
- if (!pfn_valid(pfn))
+ unsigned long t_pfn = pfn;
+ bool valid = false;
+
+ while (t_pfn < ALIGN(pfn + 1, PAGES_PER_SECTION)) {
+ if (pfn_valid(t_pfn)) {
+ valid = true;
+ break;
+ }
+ t_pfn = ALIGN(pfn + 1, PAGES_PER_SECTION >> 4
Re: [PATCH] clk: mxs: make clk_ops const
On 08/22, Bhumika Goyal wrote: > Make these const as they are only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: mmp: make clk_ops const
On 08/22, Bhumika Goyal wrote: > Make these const as they are only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: imx: make clk_ops const
On 08/22, Bhumika Goyal wrote: > Make these const as they are only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: sirf: make clk_ops const
On 08/22, Bhumika Goyal wrote: > Make these const as they are only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: hisilicon: make clk_ops const
On 08/22, Bhumika Goyal wrote: > Make these const as they are only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: make clk_init_data const
On 08/18, Bhumika Goyal wrote: > Make these const as they are only stored in the init field of a clk_hw > structure, which is const. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: spear: make clk_ops const
On 08/22, Bhumika Goyal wrote: > Make these const as they are only stored in the const field of a > clk_init_data structure. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] CLK: SPEAr: make structure field and function argument as const
On 10/17, Bhumika Goyal wrote: > Make the masks field of clk_aux structure const as it do not modify the > fields of the aux_clk_masks structure it points to. > > Make the struct aux_clk_masks *aux argument of the function > clk_register_aux as const as the argument is only stored in the masks > field of a clk_aux structure which is now made const. > > Signed-off-by: Bhumika Goyal > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 3.10 054/139] direct-io: Prevent NULL pointer access in submit_page_section
Hi Andreas,
On Wed, Nov 01, 2017 at 11:43:26PM +0100, Andreas Gruenbacher wrote:
> > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > index e17d919..85485c1 100644
> > --- a/fs/direct-io.c
> > +++ b/fs/direct-io.c
> > @@ -760,6 +760,8 @@ out:
> > if (sdio->boundary) {
> > ret = dio_send_cur_page(dio, sdio, map_bh);
> > dio_bio_submit(dio, sdio);
> > + if (sdio->bio)
> > + dio_bio_submit(dio, sdio);
> > page_cache_release(sdio->cur_page);
> > sdio->cur_page = NULL;
> > }
>
> this is incorrect; please compare with the upstream commit.
Oh crap, sorry! I had to fix it by hand and I messed up fixing
the conflict! I've just dropped the first dio_bio_submit() so
that only the conditional one remains now.
Thanks for reporting it!
Willy
---
commit d75e8540fd8bedc8ee8d11941a7aed3a86735c47
Author: Andreas Gruenbacher
Date: Mon Oct 9 11:13:18 2017 +0200
direct-io: Prevent NULL pointer access in submit_page_section
commit 899f0429c7d3eed886406cd72182bee3b96aa1f9 upstream.
In the code added to function submit_page_section by commit b1058b981,
sdio->bio can currently be NULL when calling dio_bio_submit. This then
leads to a NULL pointer access in dio_bio_submit, so check for a NULL
bio in submit_page_section before trying to submit it instead.
Fixes xfstest generic/250 on gfs2.
Cc: sta...@vger.kernel.org # v3.10+
Signed-off-by: Andreas Gruenbacher
Reviewed-by: Jan Kara
Signed-off-by: Al Viro
Signed-off-by: Willy Tarreau
diff --git a/fs/direct-io.c b/fs/direct-io.c
index e17d919..4007749 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -759,7 +759,8 @@ out:
*/
if (sdio->boundary) {
ret = dio_send_cur_page(dio, sdio, map_bh);
- dio_bio_submit(dio, sdio);
+ if (sdio->bio)
+ dio_bio_submit(dio, sdio);
page_cache_release(sdio->cur_page);
sdio->cur_page = NULL;
}
Re: [PATCH] clk: uniphier: fix clock data for PXs3
On 10/13, Masahiro Yamada wrote:
> Fix reg offsets of USB clocks.
>
> Fixes: 736de651a836 ("clk: uniphier: add PXs3 clock data")
> Signed-off-by: Masahiro Yamada
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 3.10 000/139] 3.10.108-stable review
Hi Guenter, On Wed, Nov 01, 2017 at 06:21:13PM -0700, Guenter Roeck wrote: > drivers/s390/scsi/zfcp_scsi.c: In function 'zfcp_task_mgmt_function': > drivers/s390/scsi/zfcp_scsi.c:298:4: error: too many arguments to function > 'zfcp_dbf_scsi_devreset' > drivers/s390/scsi/zfcp_dbf.h:408:6: note: declared here > drivers/s390/scsi/zfcp_scsi.c:309:3: error: too many arguments to function > 'zfcp_dbf_scsi_devreset' > drivers/s390/scsi/zfcp_dbf.h:408:6: note: declared here Ah, I was too happy all of them applied well :-) I'm seeing that Greg dropped ",NULL" in 3.18 and that other call places only have the first 3 args. Now fixed. Thank you! Willy
[PATCH v5 2/2] Input: add support for the Samsung S6SY761 touchscreen
The S6SY761 touchscreen is a capicitive multi-touch controller for mobile use. It's connected with i2c at the address 0x48. This commit provides a basic version of the driver which can handle only initialization, touch events and power states. The controller is controlled by a firmware which, in the version I currently have, doesn't provide all the possible functionalities mentioned in the datasheet. Signed-off-by: Andi Shyti --- drivers/input/touchscreen/Kconfig | 11 + drivers/input/touchscreen/Makefile | 1 + drivers/input/touchscreen/s6sy761.c | 548 3 files changed, 560 insertions(+) create mode 100644 drivers/input/touchscreen/s6sy761.c diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 64b30fe273fd..1405c08a529f 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -383,6 +383,17 @@ config TOUCHSCREEN_S3C2410 To compile this driver as a module, choose M here: the module will be called s3c2410_ts. +config TOUCHSCREEN_S6SY761 + tristate "Samsung S6SY761 Touchscreen driver" + depends on I2C + help + Say Y if you have the Samsung S6SY761 driver + + If unsure, say N + + To compile this driver as module, choose M here: the + module will be called s6sy761. + config TOUCHSCREEN_GUNZE tristate "Gunze AHL-51S touchscreen" select SERIO diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 6badce87037b..4f63439211fd 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -64,6 +64,7 @@ obj-$(CONFIG_TOUCHSCREEN_PENMOUNT)+= penmount.o obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o obj-$(CONFIG_TOUCHSCREEN_RM_TS)+= raydium_i2c_ts.o obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o +obj-$(CONFIG_TOUCHSCREEN_S6SY761) += s6sy761.o obj-$(CONFIG_TOUCHSCREEN_SILEAD) += silead.o obj-$(CONFIG_TOUCHSCREEN_SIS_I2C) += sis_i2c.o obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o diff --git a/drivers/input/touchscreen/s6sy761.c b/drivers/input/touchscreen/s6sy761.c new file mode 100644 index ..33097e7459df --- /dev/null +++ b/drivers/input/touchscreen/s6sy761.c @@ -0,0 +1,548 @@ +/* + * Copyright (c) 2017 Samsung Electronics Co., Ltd. + * Author: Andi Shyti + * + * 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. + * + * Samsung S6SY761 Touchscreen device driver + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* commands */ +#define S6SY761_SENSE_ON 0x10 +#define S6SY761_SENSE_OFF 0x11 +#define S6SY761_TOUCH_FUNCTION 0x30 /* R/W for get/set */ +#define S6SY761_FIRMWARE_INTEGRITY 0x21 +#define S6SY761_PANEL_ID 0x23 +#define S6SY761_DEVICE_ID 0x52 +#define S6SY761_BOOT_STATUS0x55 +#define S6SY761_READ_ONE_EVENT 0x60 +#define S6SY761_READ_ALL_EVENT 0x61 +#define S6SY761_CLEAR_EVENT_STACK 0x62 +#define S6SY761_APPLICATION_MODE 0xe4 + +/* events */ +#define S6SY761_EVENT_INFO 0x02 +#define S6SY761_EVENT_VENDOR_INFO 0x07 + +/* info */ +#define S6SY761_INFO_BOOT_COMPLETE 0x00 + +/* firmware status */ +#define S6SY761_FW_OK 0x80 + +/* + * the functionalities are put as a reference + * as in the device I am using none of them + * works therefore not used in this driver yet. + */ +/* touchscreen functionalities */ +#define S6SY761_MASK_TOUCH BIT(0) +#define S6SY761_MASK_HOVER BIT(1) +#define S6SY761_MASK_COVER BIT(2) +#define S6SY761_MASK_GLOVE BIT(3) +#define S6SY761_MASK_STYLUSBIT(4) +#define S6SY761_MASK_PALM BIT(5) +#define S6SY761_MASK_WET BIT(6) +#define S6SY761_MASK_PROXIMITY BIT(7) + +/* boot status (BS) */ +#define S6SY761_BS_BOOT_LOADER 0x10 +#define S6SY761_BS_APPLICATION 0x20 + +/* event id */ +#define S6SY761_EVENT_ID_COORDINATE0x00 +#define S6SY761_EVENT_ID_STATUS0x01 + +/* event register masks */ +#define S6SY761_MASK_TOUCH_STATE 0xc0 /* byte 0 */ +#define S6SY761_MASK_TID 0x3c +#define S6SY761_MASK_EID 0x03 +#define S6SY761_MASK_X 0xf0 /* byte 3 */ +#define S6SY761_MASK_Y 0x0f +#define S6SY761_MASK_Z 0x3f /* byte 6 */ +#define S6SY761_MASK_LEFT_EVENTS 0x3f /* byte 7 */ +#define S6SY761_MASK_TOUCH_TYPE0xc0 /* MSB in byte 6, LSB in byte 7 */ + +/* event touch state values */ +#define S6SY761_TS_NONE0x00 +#define S6SY761_TS_PRESS 0x01 +#define S6SY761_TS_M
[PATCH v5 1/2] dt-bindings: Input: add Samsung S6SY761 touchscreen binding file
Add the binding file for the Samsung capacitive multi-touch
touchscreen S6SY761.
Signed-off-by: Andi Shyti
Acked-by: Rob Herring
---
.../bindings/input/touchscreen/samsung,s6sy761.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
new file mode 100644
index ..d9b7c2ff611e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
@@ -0,0 +1,34 @@
+* Samsung S6SY761 touchscreen controller
+
+Required properties:
+- compatible : must be "samsung,s6sy761"
+- reg : I2C slave address, (e.g. 0x48)
+- interrupt-parent : the phandle to the interrupt controller which provides
+ the interrupt
+- interrupts : interrupt specification
+- avdd-supply : analogic power supply
+- vdd-supply : power supply
+
+Optional properties:
+- touchscreen-size-x : see touchscreen.txt. This property is embedded in the
+ device. If defined it forces a different x resolution.
+- touchscreen-size-y : see touchscreen.txt. This property is embedded in the
+ device. If defined it forces a different y resolution.
+
+Example:
+
+i2c@ {
+
+ /* ... */
+
+ touchscreen@48 {
+ compatible = "samsung,s6sy761";
+ reg = <0x48>;
+ interrupt-parent = <&gpa1>;
+ interrupts = <1 IRQ_TYPE_NONE>;
+ avdd-supply = <&ldo30_reg>;
+ vdd-supply = <&ldo31_reg>;
+ touchscreen-size-x = <4096>;
+ touchscreen-size-y = <4096>;
+ };
+};
--
2.14.2
[PATCH v5 0/2] add support for the Samsung S6SY761 touchscreen
Hi, This patchset adds support for the Samsung s6sy761 touchscreen. Thanks, Andi v4 - v5 - The previous patch has been split in two parts as requested by Rob and added his ack in the dt-binding patch. - I tried to fix all the reviews from Dmitry[*] - other random cleanups [*] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1523520.html v3 - v4 - fixed a mismatch on the module name v2 - v3 - added security check on an unsigned value which can (unlikely) get a "negative" value - in the probe function the interrupt is requested after the input device registration in order to avoid checking in the interrupt handler whether the input device has been registered - removed the 'prev_pm_state' variable. Its original meaning was to restore the state of the device when coming back from sleep mode, but because I removed in patch v2 the low power mode, now the device works only in two modes and therefore 'prev_pm_state' is not required any longer. v1 - v2 - remove the low power functionality as it doesn't bring any benefit - use get_unaligned_be16 instead of the form 'a << 8 | b' - use max_t instead of '? :' - use managed 'devm_device_add_group()' Andi Shyti (2): dt-bindings: Input: add Samsung S6SY761 touchscreen binding file Input: add support for the Samsung S6SY761 touchscreen .../bindings/input/touchscreen/samsung,s6sy761.txt | 34 ++ drivers/input/touchscreen/Kconfig | 11 + drivers/input/touchscreen/Makefile | 1 + drivers/input/touchscreen/s6sy761.c| 548 + 4 files changed, 594 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt create mode 100644 drivers/input/touchscreen/s6sy761.c -- 2.14.2
Re: [PATCH v2] clk: sunxi: fix build warning
On 10/24, Corentin Labbe wrote:
> This patch fix the following build warning:
> drivers/clk/sunxi/clk-factors.c:279:14: warning: variable 'name' set but not
> used [-Wunused-but-set-variable]
>
> Fixes: 4cbeaebb8af1 ("clk: sunxi: factors: Add unregister function")
>
> Acked-by: Maxime Ripard
> Signed-off-by: Corentin Labbe
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 009/102] clk: sunxi: explicitly request exclusive reset control
On 07/19, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
>
> No functional changes.
>
> Cc: "Emilio López"
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Philipp Zabel
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
linux-next: manual merge of the kspp tree with the kvm tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
virt/kvm/kvm_main.c
between commit:
46bea48ac241 ("kvm, mm: account kvm related kmem slabs to kmemcg")
from the kvm tree and commit:
67ac5ee34976 ("kvm: whitelist struct kvm_vcpu_arch")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc virt/kvm/kvm_main.c
index fe080f5152b6,1075d7338807..
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@@ -4006,8 -4009,11 +4006,12 @@@ int kvm_init(void *opaque, unsigned vcp
/* A kmem cache lets us meet the alignment requirements of fx_save. */
if (!vcpu_align)
vcpu_align = __alignof__(struct kvm_vcpu);
- kvm_vcpu_cache = kmem_cache_create("kvm_vcpu", vcpu_size, vcpu_align,
- SLAB_ACCOUNT, NULL);
+ kvm_vcpu_cache =
+ kmem_cache_create_usercopy("kvm_vcpu", vcpu_size, vcpu_align,
- 0, offsetof(struct kvm_vcpu, arch),
++ SLAB_ACCOUNT,
++ offsetof(struct kvm_vcpu, arch),
+ sizeof_field(struct kvm_vcpu, arch),
+ NULL);
if (!kvm_vcpu_cache) {
r = -ENOMEM;
goto out_free_3;
[PATCH v3] pids: introduce find_get_task_by_vpid helper
There are several functions that do find_task_by_vpid() followed by
get_task_struct(). We can use a helper function instead.
Signed-off-by: Mike Rapoport
Acked-by: Oleg Nesterov
---
v3: update arch/ia64/kernel/perfmon.c and security/yama/yama_lsm.c that
were missing in the previous versions
v2: remove futex_find_get_task() and ptrace_get_task_struct() as Oleg
suggested
arch/ia64/kernel/perfmon.c | 13 +++--
include/linux/sched.h | 5 +
kernel/futex.c | 20 +---
kernel/pid.c | 13 +
kernel/ptrace.c| 27 ++-
kernel/taskstats.c | 6 +-
mm/process_vm_access.c | 6 +-
security/yama/yama_lsm.c | 11 +++
8 files changed, 33 insertions(+), 68 deletions(-)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 09f86ebfcc7b..496b3f87ffab 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2610,17 +2610,10 @@ pfm_get_task(pfm_context_t *ctx, pid_t pid, struct
task_struct **task)
if (pid < 2) return -EPERM;
if (pid != task_pid_vnr(current)) {
-
- read_lock(&tasklist_lock);
-
- p = find_task_by_vpid(pid);
-
/* make sure task cannot go away while we operate on it */
- if (p) get_task_struct(p);
-
- read_unlock(&tasklist_lock);
-
- if (p == NULL) return -ESRCH;
+ p = find_get_task_by_vpid(pid);
+ if (!p)
+ return -ESRCH;
}
ret = pfm_task_incompatible(ctx, p);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 26a7df4e558c..4c3af5255fcf 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1484,6 +1484,11 @@ static inline struct thread_info
*task_thread_info(struct task_struct *task)
extern struct task_struct *find_task_by_vpid(pid_t nr);
extern struct task_struct *find_task_by_pid_ns(pid_t nr, struct pid_namespace
*ns);
+/*
+ * find a task by its virtual pid and get the task struct
+ */
+extern struct task_struct *find_get_task_by_vpid(pid_t nr);
+
extern int wake_up_state(struct task_struct *tsk, unsigned int state);
extern int wake_up_process(struct task_struct *tsk);
extern void wake_up_new_task(struct task_struct *tsk);
diff --git a/kernel/futex.c b/kernel/futex.c
index 0518a0bfc746..e2a160549a0c 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -862,24 +862,6 @@ static void put_pi_state(struct futex_pi_state *pi_state)
}
}
-/*
- * Look up the task based on what TID userspace gave us.
- * We dont trust it.
- */
-static struct task_struct *futex_find_get_task(pid_t pid)
-{
- struct task_struct *p;
-
- rcu_read_lock();
- p = find_task_by_vpid(pid);
- if (p)
- get_task_struct(p);
-
- rcu_read_unlock();
-
- return p;
-}
-
#ifdef CONFIG_FUTEX_PI
/*
@@ -1166,7 +1148,7 @@ static int attach_to_pi_owner(u32 uval, union futex_key
*key,
*/
if (!pid)
return -ESRCH;
- p = futex_find_get_task(pid);
+ p = find_get_task_by_vpid(pid);
if (!p)
return -ESRCH;
diff --git a/kernel/pid.c b/kernel/pid.c
index 020dedbdf066..ead086b0ef8e 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -462,6 +462,19 @@ struct task_struct *find_task_by_vpid(pid_t vnr)
return find_task_by_pid_ns(vnr, task_active_pid_ns(current));
}
+struct task_struct *find_get_task_by_vpid(pid_t nr)
+{
+ struct task_struct *task;
+
+ rcu_read_lock();
+ task = find_task_by_vpid(nr);
+ if (task)
+ get_task_struct(task);
+ rcu_read_unlock();
+
+ return task;
+}
+
struct pid *get_task_pid(struct task_struct *task, enum pid_type type)
{
struct pid *pid;
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 84b1367935e4..6f3de14313f5 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -1099,21 +1099,6 @@ int ptrace_request(struct task_struct *child, long
request,
return ret;
}
-static struct task_struct *ptrace_get_task_struct(pid_t pid)
-{
- struct task_struct *child;
-
- rcu_read_lock();
- child = find_task_by_vpid(pid);
- if (child)
- get_task_struct(child);
- rcu_read_unlock();
-
- if (!child)
- return ERR_PTR(-ESRCH);
- return child;
-}
-
#ifndef arch_ptrace_attach
#define arch_ptrace_attach(child) do { } while (0)
#endif
@@ -1131,9 +1116,9 @@ SYSCALL_DEFINE4(ptrace, long, request, long, pid,
unsigned long, addr,
goto out;
}
- child = ptrace_get_task_struct(pid);
- if (IS_ERR(child)) {
- ret = PTR_ERR(child);
+ child = find_get_task_by_vpid(pid);
+ if (!child) {
+ ret = -ESRCH;
goto out;
}
@@ -1278,9 +1263,9 @@ COMPAT_SYSCALL_DEFINE4(ptrace, compat_long_t, request,
compat_long_t, pid
Re: [PATCH -mm -V3] mm, swap: Fix false error message in __swp_swapcount()
On Thu, Nov 02, 2017 at 01:42:25PM +0800, Huang, Ying wrote:
> From: Huang Ying
>
> When a page fault occurs for a swap entry, the physical swap readahead
> (not the VMA base swap readahead) may readahead several swap entries
> after the fault swap entry. The readahead algorithm calculates some
> of the swap entries to readahead via increasing the offset of the
> fault swap entry without checking whether they are beyond the end of
> the swap device and it relys on the __swp_swapcount() and
> swapcache_prepare() to check it. Although __swp_swapcount() checks
> for the swap entry passed in, it will complain with the error message
> as follow for the expected invalid swap entry. This may make the end
> users confused.
>
> swap_info_get: Bad swap offset entry 0200f8a7
>
> To fix the false error message, the swap entry checking is added in
> swapin_readahead() to avoid to pass the out-of-bound swap entries and
> the swap entry reserved for the swap header to __swp_swapcount() and
> swapcache_prepare().
>
> Cc: Tim Chen
> Cc: Michal Hocko
> Cc: # 4.11-4.13
> Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots")
> Reported-by: Christian Kujau
> Suggested-by: Minchan Kim
> Signed-off-by: "Huang, Ying"
Acked-by: Minchan Kim
Re: [PATCH v6 2/9] KVM: arm/arm64: vgic-its: Fix vgic_its_restore_collection_table returned value
On Thu, Oct 26, 2017 at 05:23:04PM +0200, Eric Auger wrote: > vgic_its_restore_cte returns +1 if the collection table entry > is valid and properly decoded. As a consequence, if the > collection table is fully filled with valid data that are > decoded without error, vgic_its_restore_collection_table() > returns +1. This is wrong. > > Let's return 0 in that case. > Acked-by: Christoffer Dall > Fixes: ea1ad53e1e31a3 (KVM: arm64: vgic-its: Collection table save/restore) > Signed-off-by: Eric Auger > > --- > > v5 -> v6: > - use the same trick as vgic_its_restore_itt and > vgic_its_restore_device_tables > > v4 -> v5: > - added Christoffer R-b > > v2 -> v3: creation > --- > virt/kvm/arm/vgic/vgic-its.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index d27a301..8230ffe 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -2268,6 +2268,10 @@ static int vgic_its_restore_collection_table(struct > vgic_its *its) > gpa += cte_esz; > read += cte_esz; > } > + > + if (ret > 0) > + return 0; > + > return ret; > } > > -- > 2.5.5 >
[PATCH -mm -V3] mm, swap: Fix false error message in __swp_swapcount()
From: Huang Ying
When a page fault occurs for a swap entry, the physical swap readahead
(not the VMA base swap readahead) may readahead several swap entries
after the fault swap entry. The readahead algorithm calculates some
of the swap entries to readahead via increasing the offset of the
fault swap entry without checking whether they are beyond the end of
the swap device and it relys on the __swp_swapcount() and
swapcache_prepare() to check it. Although __swp_swapcount() checks
for the swap entry passed in, it will complain with the error message
as follow for the expected invalid swap entry. This may make the end
users confused.
swap_info_get: Bad swap offset entry 0200f8a7
To fix the false error message, the swap entry checking is added in
swapin_readahead() to avoid to pass the out-of-bound swap entries and
the swap entry reserved for the swap header to __swp_swapcount() and
swapcache_prepare().
Cc: Tim Chen
Cc: Michal Hocko
Cc: # 4.11-4.13
Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots")
Reported-by: Christian Kujau
Suggested-by: Minchan Kim
Signed-off-by: "Huang, Ying"
---
mm/swap_state.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 6c017ced11e6..6c33ebd193a9 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -558,6 +558,7 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t
gfp_mask,
unsigned long offset = entry_offset;
unsigned long start_offset, end_offset;
unsigned long mask;
+ struct swap_info_struct *si = swp_swap_info(entry);
struct blk_plug plug;
bool do_poll = true, page_allocated;
@@ -571,6 +572,8 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t
gfp_mask,
end_offset = offset | mask;
if (!start_offset) /* First page is swap header. */
start_offset++;
+ if (end_offset >= si->max)
+ end_offset = si->max - 1;
blk_start_plug(&plug);
for (offset = start_offset; offset <= end_offset ; offset++) {
--
2.14.2
Re: [PATCH 0/3] Make core_pattern support namespace
ping 在 2017年08月02日 14:37, Cao Shufeng 写道: This patchset includes following function points: 1: Let usermodehelper function possible to set pid namespace done by: [PATCH_v4.1_1/3] Make call_usermodehelper_exec possible to set namespaces 2: Let pipe_type core_pattern write dump into container's rootfs done by: [PATCH_v4.1_2/3] Limit dump_pipe program's permission to init for container 3: Make separate core_pattern setting for each container done by: [PATCH_v4.1_3/3] Make core_pattern support namespace 4: Compatibility with current system also included in: [PATCH_v4.1_3/3] Make core_pattern support namespace If container hadn't change core_pattern setting, it will keep same setting with host. Test: 1: Pass a test script for each function of this patchset ## TEST IN HOST ## [root@kerneldev dumptest]# ./test_host Set file core_pattern: OK ./test_host: line 41: 2366 Segmentation fault (core dumped) "$SCRI= PT_BASE_DIR"/make_dump Checking dumpfile: OK Set file core_pattern: OK ./test_host: line 41: 2369 Segmentation fault (core dumped) "$SCRI= PT_BASE_DIR"/make_dump Checking dump_pipe triggered: OK Checking rootfs: OK Checking dumpfile: OK Checking namespace: OK Checking process list: OK Checking capabilities: OK ## TEST IN GUEST ## # ./test Segmentation fault (core dumped) Checking dump_pipe triggered: OK Checking rootfs: OK Checking dumpfile: OK Checking namespace: OK Checking process list: OK Checking cg pids: OK Checking capabilities: OK [ 64.940734] make_dump[2432]: segfault at 0 ip 0040049d sp 000= 07ffc4af025f0 error 6 in make_dump[40+a6000] # 2: Pass other test(which is not easy to do in script) by hand. Changelog v3.1-v4: 1. remove extra fork pointed out by: Andrei Vagin 2: Rebase on top of v4.9-rc8. 3: Rebase on top of v4.12. Changelog v3-v3.1: 1. Switch "pwd" of pipe program to container's root fs. 2. Rebase on top of v4.9-rc1. Changelog v2->v3: 1: Fix problem of setting pid namespace, pointed out by: Andrei Vagin Changelog v1(RFC)->v2: 1: Add [PATCH 2/2] which was todo in [RFC v1]. 2: Pass a test script for each function. 3: Rebase on top of v4.7. Suggested-by: Eric W. Biederman Suggested-by: KOSAKI Motohiro Signed-off-by: Cao Shufeng Cao Shufeng (3): Make call_usermodehelper_exec possible to set namespaces Limit dump_pipe program's permission to init for container Make core_pattern support namespace fs/coredump.c | 150 +++--- include/linux/binfmts.h | 2 + include/linux/kmod.h | 5 ++ include/linux/pid_namespace.h | 3 + init/do_mounts_initrd.c | 3 +- kernel/kmod.c | 56 +--- kernel/pid.c | 2 + kernel/pid_namespace.c| 2 + kernel/sysctl.c | 50 -- lib/kobject_uevent.c | 3 +- security/keys/request_key.c | 4 +- 11 files changed, 253 insertions(+), 27 deletions(-)
Re: linux-next: build failure after merge of the gpio tree
Hi Stephen,
2017-11-02 14:20 GMT+09:00 Stephen Rothwell :
> Hi Linus,
>
> After merging the gpio tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpio/gpio-uniphier.c:324:14: error: initialization from incompatible
> pointer type [-Werror=incompatible-pointer-types]
> .activate = uniphier_gpio_irq_domain_activate,
> ^
>
> Caused by commit
>
> dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
>
> interacting with commit
>
> 72491643469a ("genirq/irqdomain: Update irq_domain_ops.activate()
> signature")
>
> from the tip tree
>
> I added the following merge fix patch:
>
> From: Stephen Rothwell
> Date: Thu, 2 Nov 2017 16:10:46 +1100
> Subject: [PATCH] gpio: uniphier: merge fix for "Update
> irq_domain_ops.activate() signature"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpio/gpio-uniphier.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
> index d62cea4ed6b7..d0069202ade3 100644
> --- a/drivers/gpio/gpio-uniphier.c
> +++ b/drivers/gpio/gpio-uniphier.c
> @@ -300,13 +300,15 @@ static int uniphier_gpio_irq_domain_alloc(struct
> irq_domain *domain,
> return irq_domain_alloc_irqs_parent(domain, virq, 1, &parent_fwspec);
> }
>
> -static void uniphier_gpio_irq_domain_activate(struct irq_domain *domain,
> - struct irq_data *data)
> +static int uniphier_gpio_irq_domain_activate(struct irq_domain *domain,
> + struct irq_data *data,
> + bool early)
Thanks for fixing this!
Basically it it OK, but you do not need to wrap the line.
I prefer the following style since the second line fit in 79 cols.
static int uniphier_gpio_irq_domain_activate(struct irq_domain *domain,
struct irq_data *data, bool early)
> struct uniphier_gpio_priv *priv = domain->host_data;
> struct gpio_chip *chip = &priv->chip;
>
> gpiochip_lock_as_irq(chip, data->hwirq + UNIPHIER_GPIO_IRQ_OFFSET);
> + return 0;
> }
>
> static void uniphier_gpio_irq_domain_deactivate(struct irq_domain *domain,
> --
> 2.14.1
>
> --
> Cheers,
> Stephen Rothwell
--
Best Regards
Masahiro Yamada
Re: [PATCH v6 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property
On 10/27, Oleksij Rempel wrote: > Signed-off-by: Oleksij Rempel > Acked-by: Rob Herring > --- Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] perf mmap: Fix perf backward recording
Hi Kan, On Wed, Nov 01, 2017 at 04:22:53PM +, Liang, Kan wrote: > > On 2017/11/1 21:57, Liang, Kan wrote: > > >> On 2017/11/1 20:00, Namhyung Kim wrote: > > >>> On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > > > There are only four test cases which set overwrite, > > > sw-clock,task-exit, mmap-basic, backward-ring-buffer. > > > Only backward-ring-buffer is 'backward overwrite'. > > > The rest three are all 'forward overwrite'. We just need to set > > > write_backward to convert them to 'backward overwrite'. > > > I think it's not hard to clean up. > > > > If we add a new rule that overwrite ring buffers are always backward then it > > is not hard to cleanup. However, the support of forward overwrite ring > > buffer has a long history and the code is not written by me. I'd like to > > check if > > there is some reason to keep support this configuration? > > > > As my observation, currently, there are no perf tools which support > 'forward overwrite'. > There are only three test cases (sw-clock, task-exit, mmap-basic) which > is set to 'forward overwrite'. I don’t see any reason it cannot be changed to > 'backward overwrite' > > Arnaldo? Jirka? Kim? > > What do you think? I think sw-clock, task-exit and mmap-basic test cases can be changed to use the forward non-overwrite mode. The forward overwrite might be used by externel applications accessing the ring buffer directly but not needed for perf tools IMHO. Let's keep the code simpler as much as possible. Thanks, Namhyung
Re: [RFC PATCH] clk: move of_clk_get_parent_count() declaration to
On 10/29, Masahiro Yamada wrote: > 2017-10-13 8:17 GMT+09:00 Stephen Boyd : > > > USB has a > > similar case, which I think Shawn Guo/Dong Aisheng was trying to > > add an OF based bulk clk_get() API called of_clk_bulk_get() > > for[1]. If this get all clks API works there too then we should > > use it. If it can be non-DT specific, even better. > > > > [1] > > http://lkml.kernel.org/r/1506415441-4435-1-git-send-email-aisheng.d...@nxp.com > > OK, we can implement it based on Shawn/Dong's work. > > My concern is clk-bulk.c still needs to include #, > but it is a bit odd since clk-bulk.c is a helper for clk consumers. > > Understood. I'm not concerned though, it's one place where this happens, not in a bunch of random drivers. What exactly do you need from clk-provider.h in clk-bulk.c though? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH resend] Documentation: Update of broken link
The link of devicetree.org was broken. Site has been moved to elinux.org. Signed-off-by: Claudia Meitinger --- Documentation/devicetree/usage-model.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt index 33a8aaac..d7248c2f 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt @@ -8,7 +8,7 @@ This article describes how Linux uses the device tree. An overview of the device tree data format can be found on the device tree usage page at devicetree.org[1]. -[1] http://devicetree.org/Device_Tree_Usage +[1] https://elinux.org/Device_Tree_Usage The "Open Firmware Device Tree", or simply Device Tree (DT), is a data structure and language for describing hardware. More specifically, it -- 2.11.0
PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)
Hi, On my Asus C201 laptop (rk3288) the HDMI has been behaving weirdly after Linux upgrade. ~50% of the time after a hotplug, there is a vertical pink bar on the left of the display area and audio is not working at all. According to the sink device the display size is 1282x720 which seems pretty wrong (normal and working situation is 1280x720). I posted photos of non-working versus working states here: https://imgur.com/a/qhAZG Unplugging and plugging the cable again will correct the issue (it seems to, for the most part, alternate between working and not-working states, although not always). It always works on power up with the cable initially connected. This is a regression from 4.11, where hotplug works perfectly every time. I attached dmesg output (gzipped) from 4.14-rc7 (I booted up and re-plugged the cable twice, which triggered non-working state and then back to working state -- although seems no messages are logged from these hotplugs). I am working to bisect this, might take a while. Partial progress follows... Let me know of anything else I should try. Thanks, Nick git bisect start # bad: [0b07194bb55ed836c2cc7c22e866b87a14681984] Linux 4.14-rc7 git bisect bad 0b07194bb55ed836c2cc7c22e866b87a14681984 # bad: [fa394784e74b918f44fca1e6a1f826cf818350d2] Linux 4.12.14 git bisect bad fa394784e74b918f44fca1e6a1f826cf818350d2 # good: [bd1a9eb6a755e1cb342725a11242251d2bfad567] Linux 4.11.12 git bisect good bd1a9eb6a755e1cb342725a11242251d2bfad567 # good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11 git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12 # bad: [8f28472a739e8e39adc6e64ee5b460df039f0e4f] Merge tag 'usb-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect bad 8f28472a739e8e39adc6e64ee5b460df039f0e4f aidos-4.14-rc7.log.gz Description: GNU Zip compressed data
linux-next: build failure after merge of the gpio tree
Hi Linus,
After merging the gpio tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpio/gpio-uniphier.c:324:14: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.activate = uniphier_gpio_irq_domain_activate,
^
Caused by commit
dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
interacting with commit
72491643469a ("genirq/irqdomain: Update irq_domain_ops.activate() signature")
from the tip tree
I added the following merge fix patch:
From: Stephen Rothwell
Date: Thu, 2 Nov 2017 16:10:46 +1100
Subject: [PATCH] gpio: uniphier: merge fix for "Update
irq_domain_ops.activate() signature"
Signed-off-by: Stephen Rothwell
---
drivers/gpio/gpio-uniphier.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index d62cea4ed6b7..d0069202ade3 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -300,13 +300,15 @@ static int uniphier_gpio_irq_domain_alloc(struct
irq_domain *domain,
return irq_domain_alloc_irqs_parent(domain, virq, 1, &parent_fwspec);
}
-static void uniphier_gpio_irq_domain_activate(struct irq_domain *domain,
- struct irq_data *data)
+static int uniphier_gpio_irq_domain_activate(struct irq_domain *domain,
+ struct irq_data *data,
+ bool early)
{
struct uniphier_gpio_priv *priv = domain->host_data;
struct gpio_chip *chip = &priv->chip;
gpiochip_lock_as_irq(chip, data->hwirq + UNIPHIER_GPIO_IRQ_OFFSET);
+ return 0;
}
static void uniphier_gpio_irq_domain_deactivate(struct irq_domain *domain,
--
2.14.1
--
Cheers,
Stephen Rothwell
[PATCH] regulator: qcom_spmi: Include offset when translating voltages
This driver converts voltages from a non-linear range in hardware
to a linear range in software and vice versa. During the
conversion, we exclude certain voltages that are invalid to use
because the software interface is more flexible than reality.
For example, the FTSMPS2P5 regulators have a voltage range from
8uV to 1355000uV that software could support, but we only
want to use the range of 35uV to 1355000uV. If we don't
account for the hw selectors between 8uV and 35uV we'll
pick a hw selector of 0 to mean 35uV when it really means
8uV. This can cause us to program voltages into the hardware
that are significantly lower than what we're expecting.
And when we read it back from the hardware we'll have the same
problem, voltages that are in the invalid band will end up being
calculated as some software selector that represents a larger
voltage than what is programmed and the user will be confused.
Fix all this by properly offsetting the software selector and hw
selector when converting from one number space to another.
Fixes: 1b5b19689278 ("regulator: qcom_spmi: Only use selector based regulator
ops")
Signed-off-by: Stephen Boyd
---
drivers/regulator/qcom_spmi-regulator.c | 39 -
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/qcom_spmi-regulator.c
b/drivers/regulator/qcom_spmi-regulator.c
index 16c5f84e06a7..c372b244f3da 100644
--- a/drivers/regulator/qcom_spmi-regulator.c
+++ b/drivers/regulator/qcom_spmi-regulator.c
@@ -593,13 +593,20 @@ static int spmi_sw_selector_to_hw(struct spmi_regulator
*vreg,
u8 *voltage_sel)
{
const struct spmi_voltage_range *range, *end;
+ unsigned offset;
range = vreg->set_points->range;
end = range + vreg->set_points->count;
for (; range < end; range++) {
if (selector < range->n_voltages) {
- *voltage_sel = selector;
+ /*
+* hardware selectors between set point min and real
+* min are invalid so we ignore them
+*/
+ offset = range->set_point_min_uV - range->min_uV;
+ offset /= range->step_uV;
+ *voltage_sel = selector + offset;
*range_sel = range->range_sel;
return 0;
}
@@ -613,15 +620,35 @@ static int spmi_sw_selector_to_hw(struct spmi_regulator
*vreg,
static int spmi_hw_selector_to_sw(struct spmi_regulator *vreg, u8 hw_sel,
const struct spmi_voltage_range *range)
{
- int sw_sel = hw_sel;
+ unsigned sw_sel = 0;
+ unsigned offset, max_hw_sel;
const struct spmi_voltage_range *r = vreg->set_points->range;
-
- while (r != range) {
+ const struct spmi_voltage_range *end = r + vreg->set_points->count;
+
+ for (; r < end; r++) {
+ if (r == range && range->n_voltages) {
+ /*
+* hardware selectors between set point min and real
+* min and between set point max and real max are
+* invalid so we return an error if they're
+* programmed into the hardware
+*/
+ offset = range->set_point_min_uV - range->min_uV;
+ offset /= range->step_uV;
+ if (hw_sel < offset)
+ return -EINVAL;
+
+ max_hw_sel = range->set_point_max_uV - range->min_uV;
+ max_hw_sel /= range->step_uV;
+ if (hw_sel > max_hw_sel)
+ return -EINVAL;
+
+ return sw_sel + hw_sel - offset;
+ }
sw_sel += r->n_voltages;
- r++;
}
- return sw_sel;
+ return -EINVAL;
}
static const struct spmi_voltage_range *
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
linux-next: manual merge of the gpio tree with the tip tree
Hi Linus,
Today's linux-next merge of the gpio tree got a conflict in:
include/linux/bitops.h
between commit:
cbe96375025e ("bitops: Add clear/set_bit32() to linux/bitops.h")
from the tip tree and commit:
5307e2ad69ab ("bitops: Introduce assign_bit()")
from the gpio tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/bitops.h
index 15a5bcfcd0a2,9a874deee6e2..
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@@ -227,32 -227,30 +227,56 @@@ static inline unsigned long __ffs64(u6
return __ffs((unsigned long)word);
}
+/*
+ * clear_bit32 - Clear a bit in memory for u32 array
+ * @nr: Bit to clear
+ * @addr: u32 * address of bitmap
+ *
+ * Same as clear_bit, but avoids needing casts for u32 arrays.
+ */
+
+static __always_inline void clear_bit32(long nr, volatile u32 *addr)
+{
+ clear_bit(nr, (volatile unsigned long *)addr);
+}
+
+/*
+ * set_bit32 - Set a bit in memory for u32 array
+ * @nr: Bit to clear
+ * @addr: u32 * address of bitmap
+ *
+ * Same as set_bit, but avoids needing casts for u32 arrays.
+ */
+
+static __always_inline void set_bit32(long nr, volatile u32 *addr)
+{
+ set_bit(nr, (volatile unsigned long *)addr);
+}
+
+ /**
+ * assign_bit - Assign value to a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ * @value: the value to assign
+ */
+ static __always_inline void assign_bit(long nr, volatile unsigned long *addr,
+ bool value)
+ {
+ if (value)
+ set_bit(nr, addr);
+ else
+ clear_bit(nr, addr);
+ }
+
+ static __always_inline void __assign_bit(long nr, volatile unsigned long
*addr,
+bool value)
+ {
+ if (value)
+ __set_bit(nr, addr);
+ else
+ __clear_bit(nr, addr);
+ }
+
#ifdef __KERNEL__
#ifndef set_mask_bits
Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
On 01-11-17, 14:43, Stephen Boyd wrote: > On 11/01, Rob Herring wrote: > > On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar > > wrote: > > > On 31 October 2017 at 16:02, Rob Herring wrote: > > >> Why not a new property for magic values? opp-magic? Don't we want to > > >> know when we have magic values? > > > > > > I have kept a separate property since beginning (domain-performance-state) > > > and moved to using these magic values in the existing field because of the > > > suggestion Kevin gave earlier. > > > > > > https://marc.info/?l=linux-kernel&m=149306082218001&w=2 > > > > > > I am not sure what to do now :) > > > > Okay, I guess reusing the properties is fine. > > > > We call them corners on qcom platforms. Any reason we can't keep > using that name? I'd rather not have to keep telling people that > these fake values in some misnamed property is actually a corner. Surely not "corners", as these are platform and OS independent bindings we are talking about here. Even the kernel code shouldn't generally do that. Though your platform specific genpd driver can :) -- viresh
Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
On 01-11-17, 15:39, Rob Herring wrote: > On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar wrote: > > On 31 October 2017 at 16:02, Rob Herring wrote: > >> Why not a new property for magic values? opp-magic? Don't we want to > >> know when we have magic values? > > > > I have kept a separate property since beginning (domain-performance-state) > > and moved to using these magic values in the existing field because of the > > suggestion Kevin gave earlier. > > > > https://marc.info/?l=linux-kernel&m=149306082218001&w=2 > > > > I am not sure what to do now :) > > Okay, I guess reusing the properties is fine. Okay, great. > >> Wouldn't magic values in opp-hz get propagated to user space? > > > > The OPP core puts them in debugfs just to know how the OPPs are > > set. Otherwise, I am not sure that the power domain core/drivers would > > be exposing that to user space. > > I was thinking thru the cpufreq interface, but I guess this is not for cpus. Oh no. That's not the target here for sure. -- viresh
USB is not resumed(disconnected) after suspend to disk
Hi all, I am trying to support suspend to disk(hibernate) on Hikey with 4.4 kernel. During suspend, I could see the usb devices getting reset and I can access them properly. Message can be seen as below: usb 1-1: reset high-speed USB device number 2 using dwc2 usb 1-1.2: reset high-speed USB device number 3 using dwc2 usb 1-1.2.4: reset high-speed USB device number 4 using dwc2 But after resume, usb gets disconnected and I could not access it anymore: usb 1-1: USB disconnect, device number 2 usb 1-1.2: USB disconnect, device number 3 usb 1-1.2.4: USB disconnect, device number 4 However "dwc2 f72c.usb" gets setup properly. I guess it is OTG. I have connected only keyboard to USB Type-A. OTG is not connected. Is the dwc2_suspend() and dwc2_resume() functions support only suspend to mem? Is there any hack such that we can forcefully reset the USB(dwc2) on resume in dwc2_resume() code path. I tried adding usb_reset_device() to dwc2_resume() path but that gave a panic as expected. I tried to skip suspend in dwc2_suspend(), but still the usb disconnects. I added "dwc2_lowlevel_hw_init" to resume path just to check but still no use. Is the power to hub lost or clock is not set properly or something because I could not understand what is the problem. Below is some more dmesg log: ivid@ivid:~# dmesg | grep usb [0.408019] usbcore: registered new interface driver usbfs [0.408099] usbcore: registered new interface driver hub [0.408224] usbcore: registered new device driver usb [0.486321] usbcore: registered new interface driver asix [0.486403] usbcore: registered new interface driver ax88179_178a [0.486583] dwc2 f72c.usb: Configuration mismatch. Forcing host mode [0.487491] usbcore: registered new interface driver usb-storage [0.581006] usbcore: registered new interface driver usbhid [0.581052] usbhid: USB HID core driver [2.054331] dwc2 f72c.usb: Configuration mismatch. Forcing host mode [2.059779] f72c.usb supply vusb_d not found, using dummy regulator [2.065133] f72c.usb supply vusb_a not found, using dummy regulator [2.939845] dwc2 f72c.usb: DWC OTG Controller [2.943587] dwc2 f72c.usb: new USB bus registered, assigned bus number 1 [2.951537] dwc2 f72c.usb: irq 37, io mem 0x [3.342725] usb 1-1: new high-speed USB device number 2 using dwc2 Below are some additional debug logs. * During suspend: dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -104 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f72c.usb: Called usb_hcd_giveback_urb() dwc2 f72c.usb: urb->status = -2 dwc2 f72c.usb: DWC OTG HCD URB Dequeue dwc2 f
Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Thu, Nov 2, 2017 at 8:57 AM, Bjorn Andersson
wrote:
> On Wed 01 Nov 20:02 PDT 2017, Jassi Brar wrote:
>
>> On Thu, Nov 2, 2017 at 3:47 AM, Bjorn Andersson
>> wrote:
>> > On Wed 01 Nov 11:15 PDT 2017, Sudeep Holla wrote:
>> >>
>> >> 80 writel_relaxed(msg->cmd, mb->mbox_base +
>> >> MAILBOX_A2B_CMD(chans->idx));
>> >> 81 writel_relaxed(msg->rx_size, mb->mbox_base +
>> >>
>> >> 82MAILBOX_A2B_DAT(chans->idx));
>> >>
>> >> 83
>> >
>> > This is just terrible, using the void *mssg to pass a struct which is
>> > interpreted by the controller removes any form of abstraction provided
>> > by the framework.
>> >
>> > In my view the void *mssg should point to the data to be written in the
>> > mailbox register, and hence might be of different size - but only of
>> > native type.
>> >
>> Please note the terrible 'rx_size' is not a software option - the
>> hardware has a DAT register so the driver rightfully allows a client
>> to write a value in that as well.
>
> Okay, so the interface exposed by the mailbox driver is not { cmd,
> rx_size } but rather __le32 data[2], or perhaps a generic { cmd, data }.
> That sounds more generic.
>
>
> I think it would be good to replace the totally opaque void * with some
> sort of structured data type and having the framework ensure that
> clients and controllers are compatible. That would, by design, allow for
> reuse between controllers and clients.
>
> Perhaps something like:
>
> enum mbox_msg_type {
> MBOX_MSG_TYPE_NULL,
> MBOX_MSG_TYPE_U32,
> MBOX_MSG_TYPE_CMD_DATA,
> };
>
> struct mbox_msg {
> enum mbox_msg_type type;
>
> union {
> u32 u;
> struct {
> u32 cmd;
> u32 data;
> } cd;
> };
> };
>
> And have the controller register for a specific "type", so the framework
> could validate that the type of data being passed matches the hardware.
>
> Have you had any thoughts around this before?
>
Yes. Different controllers have different capabilities... some have
32bits data register, some have 4x32bits deep fifos and some 8x32bits
deep while some traverse descriptor rings. Even with all these
termed 'standard' options, the clients still have to understand the
underlying controller and what the remote expects it to behave and do
very platform specific tasks. So mailbox clients are inherently
difficult to be reusable on other platforms.
cheers
Re: [PATCH V2] of: platform: Create dummy routines for !CONFIG_OF_ADDRESS
On 01-11-17, 16:14, Rob Herring wrote: > On Sat, Oct 28, 2017 at 03:56:46PM +0530, Viresh Kumar wrote: > > Few routines don't have their dummy counterparts which results in build > > failures where these routines are used without CONFIG_OF_ADDRESS > > enabled. > > > > Fix those by defining the dummy versions. > > > > Signed-off-by: Viresh Kumar > > --- > > V2: > > - Rebased again latest rc and resolved conflicts. > > - No comments received on V1. > > What's your user? It was the previous version of boot constraint core, though I have moved to another helper now. https://marc.info/?l=linux-kernel&m=150157976217258&w=2 Wouldn't it be better to define them anyway? -- viresh
linux-next: build warnings after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/staging/rtlwifi/base.c: In function 'rtl_watch_dog_timer_callback':
drivers/staging/rtlwifi/base.c:2167:23: warning: unused variable 'hw'
[-Wunused-variable]
struct ieee80211_hw *hw = rtlpriv->hw;
^
drivers/staging/rtl8723bs/hal/hal_btcoex.c: In function 'hal_btcoex_Initialize':
drivers/staging/rtl8723bs/hal/hal_btcoex.c:1415:5: warning: unused variable
'ret2' [-Wunused-variable]
u8 ret2;
^
drivers/staging/rtl8723bs/hal/hal_btcoex.c:1414:5: warning: unused variable
'ret1' [-Wunused-variable]
u8 ret1;
^
Introduced by commits
f8af6a323368 ("staging: rtlwifi: Convert timers to use timer_setup()")
95b3b4238581 ("staging: rtl8723bs: remove ternary operators in assignmet
statments")
--
Cheers,
Stephen Rothwell
linux-next: manual merge of the staging tree with the v4l-dvb tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
between commit:
309167b966b6 ("media: staging: atomisp: cleanup out of memory messages")
from the v4l-dvb tree and commit:
63342e75e661 ("Staging: media: atomisp: Use kmalloc_array instead of kmalloc")
from the staging tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
index 9e957514108e,5232327f5d9c..
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
@@@ -721,10 -725,12 +721,10 @@@ static int alloc_private_pages(struct h
pgnr = bo->pgnr;
- bo->page_obj = kmalloc(sizeof(struct hmm_page_object) * pgnr,
+ bo->page_obj = kmalloc_array(pgnr, sizeof(struct hmm_page_object),
GFP_KERNEL);
- if (unlikely(!bo->page_obj)) {
- dev_err(atomisp_dev, "out of memory for bo->page_obj\n");
+ if (unlikely(!bo->page_obj))
return -ENOMEM;
- }
i = 0;
alloc_pgnr = 0;
@@@ -984,13 -990,16 +984,13 @@@ static int alloc_user_pages(struct hmm_
struct vm_area_struct *vma;
struct page **pages;
- pages = kmalloc(sizeof(struct page *) * bo->pgnr, GFP_KERNEL);
+ pages = kmalloc_array(bo->pgnr, sizeof(struct page *), GFP_KERNEL);
- if (unlikely(!pages)) {
- dev_err(atomisp_dev, "out of memory for pages...\n");
+ if (unlikely(!pages))
return -ENOMEM;
- }
- bo->page_obj = kmalloc(sizeof(struct hmm_page_object) * bo->pgnr,
+ bo->page_obj = kmalloc_array(bo->pgnr, sizeof(struct hmm_page_object),
GFP_KERNEL);
if (unlikely(!bo->page_obj)) {
- dev_err(atomisp_dev, "out of memory for bo->page_obj...\n");
kfree(pages);
return -ENOMEM;
}
@@@ -1350,9 -1363,10 +1350,9 @@@ void *hmm_bo_vmap(struct hmm_buffer_obj
bo->status &= ~(HMM_BO_VMAPED | HMM_BO_VMAPED_CACHED);
}
- pages = kmalloc(sizeof(*pages) * bo->pgnr, GFP_KERNEL);
+ pages = kmalloc_array(bo->pgnr, sizeof(*pages), GFP_KERNEL);
if (unlikely(!pages)) {
mutex_unlock(&bo->mutex);
- dev_err(atomisp_dev, "out of memory for pages...\n");
return NULL;
}
Re: 答复: [PATCH] mm: extend reuse_swap_page range as much as possible
On Thu, Nov 02, 2017 at 02:09:57AM +, zhouxianrong wrote: > writes: > > > From: zhouxianrong > > > > origanlly reuse_swap_page requires that the sum of page's mapcount and > > swapcount less than or equal to one. > > in this case we can reuse this page and avoid COW currently. > > > > now reuse_swap_page requires only that page's mapcount less than or > > equal to one and the page is not dirty in swap cache. in this case we > > do not care its swap count. > > > > the page without dirty in swap cache means that it has been written to > > swap device successfully for reclaim before and then read again on a > > swap fault. in this case the page can be reused even though its swap > > count is greater than one and postpone the COW on other successive > > accesses to the swap cache page later rather than now. > > > > i did this patch test in kernel 4.4.23 with arm64 and none huge > > memory. it work fine. > > Why do you need this? You saved copying one page from memory to memory > (COW) now, at the cost of reading a page from disk to memory later? > > yes, accessing later does not always happen, there is probability for it, so > postpone COW now. So, it's trade-off. It means we need some number with some scenarios to prove it's better than as-is. It would help to drive reviewers/maintainer. Thanks.
linux-next: manual merge of the char-misc tree with the tip tree
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/misc/lkdtm_core.c
between commit:
8776fe75dc0e ("lkdtm, kprobes: Convert from jprobes to kprobes")
from the tip tree and commits:
31c5c870a112 ("lkdtm: Convert from jprobe to kprobe")
75f98b7ab748 ("lkdtm: Constify the crashtypes table")
from the char-misc tree.
[8776fe75dc0e and 31c5c870a112 are the same patch]
I fixed it up (I just usted the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
linux-next: build warnings after merge of the usb tree
Hi Greg,
After merging the usb tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:
In file included from include/linux/printk.h:327:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:15,
from arch/x86/include/asm/bug.h:81,
from include/linux/bug.h:4,
from include/linux/scatterlist.h:6,
from include/linux/dmapool.h:14,
from drivers/usb/mtu3/mtu3_qmu.c:30:
drivers/usb/mtu3/mtu3_qmu.c: In function 'mtu3_prepare_tx_gpd':
drivers/usb/mtu3/mtu3_qmu.c:261:25: warning: format '%p' expects argument of
type 'void *', but argument 7 has type 'dma_addr_t {aka long long unsigned
int}' [-Wformat=]
dev_dbg(mep->mtu->dev, "TX-EP%d queue gpd=%p, enq=%p, qdma=%pad\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro
'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^
drivers/usb/mtu3/mtu3_qmu.c:261:2: note: in expansion of macro 'dev_dbg'
dev_dbg(mep->mtu->dev, "TX-EP%d queue gpd=%p, enq=%p, qdma=%pad\n",
^
drivers/usb/mtu3/mtu3_qmu.c: In function 'mtu3_prepare_rx_gpd':
drivers/usb/mtu3/mtu3_qmu.c:300:25: warning: format '%p' expects argument of
type 'void *', but argument 7 has type 'dma_addr_t {aka long long unsigned
int}' [-Wformat=]
dev_dbg(mep->mtu->dev, "RX-EP%d queue gpd=%p, enq=%p, qdma=%pad\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro
'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^
drivers/usb/mtu3/mtu3_qmu.c:300:2: note: in expansion of macro 'dev_dbg'
dev_dbg(mep->mtu->dev, "RX-EP%d queue gpd=%p, enq=%p, qdma=%pad\n",
^
Introduced by commit
1a46dfea0841 ("usb: mtu3: support 36-bit DMA address")
--
Cheers,
Stephen Rothwell
linux-next: build warning after merge of the usb tree
Hi Greg, After merging the usb tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/mt2701-evb.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b00 or bad phandle (referred from /ethernet@1b10:resets[0]) arch/arm/boot/dts/mt7623n-rfb-nand.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b00 or bad phandle (referred from /ethernet@1b10:resets[0]) arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b00 or bad phandle (referred from /ethernet@1b10:resets[0]) -- Cheers, Stephen Rothwell
Re: [PATCH] dma-buf: Cleanup comments on dma_buf_map_attachment()
On Wed, Nov 1, 2017 at 10:06 AM, Liviu Dudau wrote: > Mappings need to be unmapped by calling dma_buf_unmap_attachment() and > not by calling again dma_buf_map_attachment(). Also fix some spelling > mistakes. > > Signed-off-by: Liviu Dudau Reviewed-by: Alex Deucher > --- > drivers/dma-buf/dma-buf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index bc1cb284111cb..1792385405f0e 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -351,13 +351,13 @@ static inline int is_dma_buf_file(struct file *file) > * > * 2. Userspace passes this file-descriptors to all drivers it wants this > buffer > *to share with: First the filedescriptor is converted to a &dma_buf > using > - *dma_buf_get(). The the buffer is attached to the device using > + *dma_buf_get(). Then the buffer is attached to the device using > *dma_buf_attach(). > * > *Up to this stage the exporter is still free to migrate or reallocate > the > *backing storage. > * > - * 3. Once the buffer is attached to all devices userspace can inniate DMA > + * 3. Once the buffer is attached to all devices userspace can initiate DMA > *access to the shared buffer. In the kernel this is done by calling > *dma_buf_map_attachment() and dma_buf_unmap_attachment(). > * > @@ -617,7 +617,7 @@ EXPORT_SYMBOL_GPL(dma_buf_detach); > * Returns sg_table containing the scatterlist to be returned; returns > ERR_PTR > * on error. May return -EINTR if it is interrupted by a signal. > * > - * A mapping must be unmapped again using dma_buf_map_attachment(). Note that > + * A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that > * the underlying backing storage is pinned for as long as a mapping exists, > * therefore users/importers should not hold onto a mapping for undue > amounts of > * time. > -- > 2.14.3 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the ipmi tree with the modules tree
Hi Corey,
Today's linux-next merge of the ipmi tree got a conflict in:
drivers/char/ipmi/ipmi_si_intf.c
between commit:
e4dca7b7aa08 ("treewide: Fix function prototypes for module_param_call()")
from the modules tree and commit:
44814ec982d2 ("ipmi_si: Move the hotmod handling to another file.")
from the ipmi tree.
I fixed it up (I used the ipmi tree version of the file and added the
following merge fix patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
From: Stephen Rothwell
Date: Thu, 2 Nov 2017 14:55:01 +1100
Subject: [PATCH] ipmi_si: merge fix for "treewide: Fix function prototypes for
module_param_call()"
Signed-off-by: Stephen Rothwell
---
drivers/char/ipmi/ipmi_si_hotmod.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_hotmod.c
b/drivers/char/ipmi/ipmi_si_hotmod.c
index da5716159974..fc03b9be2f3d 100644
--- a/drivers/char/ipmi/ipmi_si_hotmod.c
+++ b/drivers/char/ipmi/ipmi_si_hotmod.c
@@ -10,7 +10,7 @@
#define PFX "ipmi_hotmod: "
-static int hotmod_handler(const char *val, struct kernel_param *kp);
+static int hotmod_handler(const char *val, const struct kernel_param *kp);
module_param_call(hotmod, hotmod_handler, NULL, NULL, 0200);
MODULE_PARM_DESC(hotmod, "Add and remove interfaces. See"
@@ -97,7 +97,7 @@ static int check_hotmod_int_op(const char *curr, const char
*option,
return 0;
}
-static int hotmod_handler(const char *val, struct kernel_param *kp)
+static int hotmod_handler(const char *val, const struct kernel_param *kp)
{
char *str = kstrdup(val, GFP_KERNEL);
int rv;
--
2.14.1
--
Cheers,
Stephen Rothwell
[PATCH] PCI: Fail pci_map_rom if the PCI ROM is invalid
From: Changbin Du
If we detected a invalid PCI ROM (e.g. Invalid PCI ROM header signature),
we should unmap it immediately and fail. It doesn't make any sense that
return a mapped area with size of 0.
I have seen this case on Intel GVTg vGPU, which have no vbios. It will
not cause a real problem, but we should skip it as early as possible.
Signed-off-by: Changbin Du
---
drivers/pci/rom.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index b6edb18..1f5e6af 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -147,12 +147,8 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
return NULL;
rom = ioremap(start, *size);
- if (!rom) {
- /* restore enable if ioremap fails */
- if (!(res->flags & IORESOURCE_ROM_ENABLE))
- pci_disable_rom(pdev);
- return NULL;
- }
+ if (!rom)
+ goto err_ioremap;
/*
* Try to find the true size of the ROM since sometimes the PCI window
@@ -160,7 +156,18 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
* True size is important if the ROM is going to be copied.
*/
*size = pci_get_rom_size(pdev, rom, *size);
+ if (!*size)
+ goto invalid_rom;
+
return rom;
+
+invalid_rom:
+ iounmap(rom);
+err_ioremap:
+ /* restore enable if ioremap fails */
+ if (!(res->flags & IORESOURCE_ROM_ENABLE))
+ pci_disable_rom(pdev);
+ return NULL;
}
EXPORT_SYMBOL(pci_map_rom);
--
2.7.4
[PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe
The ASPEED SoC must deassert a reset in order to use the PWM/tach
peripheral.
Signed-off-by: Joel Stanley
---
v2:
- Correct horrible mistakes
- Boot tested and hwmon sysfs files checked
---
drivers/hwmon/aspeed-pwm-tacho.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
index 63a95e23ca81..77bb7a4bbed4 100644
--- a/drivers/hwmon/aspeed-pwm-tacho.c
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -181,6 +182,7 @@ struct aspeed_cooling_device {
struct aspeed_pwm_tacho_data {
struct regmap *regmap;
+ struct reset_control *rst;
unsigned long clk_freq;
bool pwm_present[8];
bool fan_tach_present[16];
@@ -931,6 +933,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device
*pdev)
&aspeed_pwm_tacho_regmap_config);
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
+
+ priv->rst = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(priv->rst)) {
+ dev_err(dev,
+ "missing or invalid reset controller device tree
entry");
+ return PTR_ERR(priv->rst);
+ }
+ reset_control_deassert(priv->rst);
+
regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
@@ -960,6 +971,15 @@ static int aspeed_pwm_tacho_probe(struct platform_device
*pdev)
return PTR_ERR_OR_ZERO(hwmon);
}
+static int aspeed_pwm_tacho_remove(struct platform_device *pdev)
+{
+ struct aspeed_pwm_tacho_data *priv = platform_get_drvdata(pdev);
+
+ reset_control_assert(priv->rst);
+
+ return 0;
+}
+
static const struct of_device_id of_pwm_tacho_match_table[] = {
{ .compatible = "aspeed,ast2400-pwm-tacho", },
{ .compatible = "aspeed,ast2500-pwm-tacho", },
@@ -969,6 +989,7 @@ MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
static struct platform_driver aspeed_pwm_tacho_driver = {
.probe = aspeed_pwm_tacho_probe,
+ .remove = aspeed_pwm_tacho_remove,
.driver = {
.name = "aspeed_pwm_tacho",
.of_match_table = of_pwm_tacho_match_table,
--
2.14.1
[PATCH v2 3/3] dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node
The device tree bindings are updated to document the resets phandle, and
the example is updated to match what is expected for both the reset and
clock phandle.
Note that the bindings should have always had the reset controller, as
the hardware is unusable without it.
Signed-off-by: Joel Stanley
---
.../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
index 367c8203213b..3ac02988a1a5 100644
--- a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -22,8 +22,9 @@ Required properties for pwm-tacho node:
- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
"aspeed,ast2500-pwm-tacho" for AST2500.
-- clocks : a fixed clock providing input clock frequency(PWM
- and Fan Tach clock)
+- clocks : phandle to clock provider with the clock number in the second cell
+
+- resets : phandle to reset controller with the reset number in the second cell
fan subnode format:
===
@@ -48,19 +49,14 @@ Required properties for each child node:
Examples:
-pwm_tacho_fixed_clk: fixedclk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <2400>;
-};
-
pwm_tacho: pwmtachocontroller@1e786000 {
#address-cells = <1>;
#size-cells = <1>;
#cooling-cells = <2>;
reg = <0x1E786000 0x1000>;
compatible = "aspeed,ast2500-pwm-tacho";
- clocks = <&pwm_tacho_fixed_clk>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
--
2.14.1
[PATCH v2 0/3] hwmon: Add reset support to aspeed-pwm-tach
Gunter, This adds reset controller support to the ASPEED pwm/tach driver. The reset controller and clock driver is currently under review, so to test those patches must be merged in to fully test these changes[1]. To address your concerns from v1: This driver was not usable as-is upstream. I believe the developer(s) tested and deployed it in the OpenBMC kernel tree which has some hacks in mach-aspeed to release all of the resets. The other way they could have tested it is by booting an OpenBMC kernel, which releases the resets, and then testing the upstream kernel without performing a power cycle as the resets are not reasserted on reboot. I realise it is not ideal to be changing already merged bindings. I don't plan on it becoming a habit. There is no BIOS or other ROM that runs before Linux on a BMC to release the resets. We do have u-boot, but that does not modify the pwm reset. I haven't added a Kconfig dependency on the RESET_CONTROLLER as the driver can build without it, and when the ASPEED clk/reset driver is merged, the platform will always have that option selected. I've given this version a day of testing on hardware I have access to. [1] https://lwn.net/Articles/737697/ Joel Stanley (3): hwmon: (aspeed-pwm-tacho) Sort headers hwmon: (aspeed-pwm-tacho) Deassert reset in probe dt-bindings: hwmon: aspeed-pwm-tacho: Add reset node .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 14 --- drivers/hwmon/aspeed-pwm-tacho.c | 27 +++--- 2 files changed, 29 insertions(+), 12 deletions(-) -- 2.14.1
[PATCH v2 1/3] hwmon: (aspeed-pwm-tacho) Sort headers
Sort the headers in preperation for future changes. Signed-off-by: Joel Stanley --- drivers/hwmon/aspeed-pwm-tacho.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c index f914e5f41048..63a95e23ca81 100644 --- a/drivers/hwmon/aspeed-pwm-tacho.c +++ b/drivers/hwmon/aspeed-pwm-tacho.c @@ -7,19 +7,19 @@ */ #include +#include #include #include -#include #include #include #include #include #include -#include #include +#include #include -#include #include +#include #include /* ASPEED PWM & FAN Tach Register Definition */ -- 2.14.1
Re: [PATCH net-next V2 1/3] tun: abstract flow steering logic
On 2017年11月02日 11:45, Michael S. Tsirkin wrote: On Thu, Nov 02, 2017 at 11:43:48AM +0800, Jason Wang wrote: On 2017年11月02日 09:11, Willem de Bruijn wrote: On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: tun now use flow caches based automatic queue steering method. This may not suffice all user cases. To extend it to be able to use more flow steering policy, this patch abstracts flow steering logic into tun_steering_ops, then we can declare and use different methods in the future. Signed-off-by: Jason Wang --- drivers/net/tun.c | 85 +-- 1 file changed, 63 insertions(+), 22 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index ea29da9..bff6259 100644 The previous RFC enabled support for multiple pluggable steering policies. But as all can be implemented in BPF and we only plan to support an eBPF policy besides the legacy one, this patch is no longer needed. We can save a few indirect function calls. But we should at least support two kinds of steering policy, so this is still needed? And I'm not quite sure we can implement all kinds of policies through BPF e.g RSS or we may want to offload the queue selection to underlayer switch or nic . Thanks I think a simple if condition is preferable for now, too. Let's wait until we get some 3/4 of these. That's a solution but we may need if in at least four places. If this is ok, I will do it in next version. Thanks
Re: [PATCH net-next V2 3/3] tun: add eBPF based queue selection method
On 2017年11月01日 21:59, Michael S. Tsirkin wrote:
On Wed, Nov 01, 2017 at 09:02:03PM +0800, Jason Wang wrote:
On 2017年11月01日 00:45, Michael S. Tsirkin wrote:
+static void __tun_set_steering_ebpf(struct tun_struct *tun,
+ struct bpf_prog *new)
+{
+ struct bpf_prog *old;
+
+ old = rtnl_dereference(tun->steering_prog);
+ rcu_assign_pointer(tun->steering_prog, new);
+
+ if (old) {
+ synchronize_net();
+ bpf_prog_destroy(old);
+ }
+}
+
Is this really called under rtnl?
Yes it is __tun_chr_ioctl() will call rtnl_lock().
Is the call from tun_free_netdev under rtnl too?
Looks not, need hold rtnl_lock() in tun_free_netdev in next version.
If no then rtnl_dereference
is wrong. If yes I'm not sure you can call synchronize_net
under rtnl.
Are you worrying about the long wait? Looking at synchronize_net(), it does:
void synchronize_net(void)
{
might_sleep();
if (rtnl_is_locked())
synchronize_rcu_expedited();
else
synchronize_rcu();
}
EXPORT_SYMBOL(synchronize_net);
Thanks
Not the wait - expedited is not a good thing to allow unpriveledged
userspace to do, it interrupts all VMs running on the same box.
Good point.
We could use a callback though the docs warn userspace can use that
to cause a DOS and needs to be limited.
Will do this in next version.
Thanks
Re: [PATCH net-next V2 1/3] tun: abstract flow steering logic
On Thu, Nov 02, 2017 at 11:43:48AM +0800, Jason Wang wrote: > > > On 2017年11月02日 09:11, Willem de Bruijn wrote: > > On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: > > > tun now use flow caches based automatic queue steering method. This > > > may not suffice all user cases. To extend it to be able to use more > > > flow steering policy, this patch abstracts flow steering logic into > > > tun_steering_ops, then we can declare and use different methods in > > > the future. > > > Signed-off-by: Jason Wang > > > --- > > > drivers/net/tun.c | 85 > > > +-- > > > 1 file changed, 63 insertions(+), 22 deletions(-) > > > > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > > > index ea29da9..bff6259 100644 > > The previous RFC enabled support for multiple pluggable steering > > policies. But as all can be implemented in BPF and we only plan to > > support an eBPF policy besides the legacy one, this patch is no longer > > needed. We can save a few indirect function calls. > > But we should at least support two kinds of steering policy, so this is > still needed? > > And I'm not quite sure we can implement all kinds of policies through BPF > e.g RSS or we may want to offload the queue selection to underlayer switch > or nic . > > Thanks I think a simple if condition is preferable for now, too. Let's wait until we get some 3/4 of these. -- MST
Re: [PATCH net-next V2 1/3] tun: abstract flow steering logic
On 2017年11月02日 09:11, Willem de Bruijn wrote: On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: tun now use flow caches based automatic queue steering method. This may not suffice all user cases. To extend it to be able to use more flow steering policy, this patch abstracts flow steering logic into tun_steering_ops, then we can declare and use different methods in the future. Signed-off-by: Jason Wang --- drivers/net/tun.c | 85 +-- 1 file changed, 63 insertions(+), 22 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index ea29da9..bff6259 100644 The previous RFC enabled support for multiple pluggable steering policies. But as all can be implemented in BPF and we only plan to support an eBPF policy besides the legacy one, this patch is no longer needed. We can save a few indirect function calls. But we should at least support two kinds of steering policy, so this is still needed? And I'm not quite sure we can implement all kinds of policies through BPF e.g RSS or we may want to offload the queue selection to underlayer switch or nic . Thanks
Re: [PATCH] timer: Add parenthesis around timer_setup() macro arguments
Hi Kees, On Wed, 1 Nov 2017 20:04:05 -0700 Kees Cook wrote: > > On Wed, Nov 1, 2017 at 7:33 PM, Stephen Rothwell > wrote: > > Hi Kees, > > > > On Wed, 1 Nov 2017 07:32:50 -0700 Kees Cook wrote: > >> > >> In the case where expressions are passed as macro arguments, the LOCKDEP > >> version of the timer macros need enclosing parenthesis. > >> > >> Reported-by: Stephen Rothwell > >> Signed-off-by: Kees Cook > > > > I have applied that patch to linux-next today pending it appearing in > > the tip tree. > > Thanks! It should be there in tip/timers/core as of several hours ago. Yeah, but there is some testing done before it is included the auto-latest branch, which is what I fetch for linux-next. -- Cheers, Stephen Rothwell
linux-next: build failure after merge of the workqueues tree
Hi Tejun,
After merging the workqueues tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
kernel/workqueue.c: In function 'workqueue_init_early':
kernel/workqueue.c:5561:56: error: 'cpu_isolated_map' undeclared (first use in
this function)
cpumask_andnot(wq_unbound_cpumask, cpu_possible_mask, cpu_isolated_map);
^
Caused by commit
b5149873a0c2 ("workqueue: respect isolated cpus when queueing an unbound
work")
interacting with commit
edb9382175c3 ("sched/isolation: Move isolcpus= handling to the housekeeping
code")
from the tip tree.
I am not sure how to fix this, so I have reverted b5149873a0c2 for today.
--
Cheers,
Stephen Rothwell
Re: [PATCH net-next 3/9] net: hns3: Refactor the initialization of command queue
Hi, Lipeng
On 2017/11/1 22:47, Lipeng wrote:
> From: qumingguang
>
> There is no necessary to reallocate the descriptor and remap the descriptor
> memory in reset process, But there is still some other action exit in both
exit -> exist
> reset process and initialization process.
>
> To reuse the common interface of reset process and initialization process,
of -> in
> This patch moved out the descriptor allocate and memory maping from
This -> this, moved -> moves
> interface cmdq_init.
>
> Signed-off-by: qumingguang
> Signed-off-by: Lipeng
> ---
> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 39
> +-
> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 1 +
> .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 9 -
> 3 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> index 60960e5..ff13d18 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> @@ -62,7 +62,7 @@ static void hclge_free_cmd_desc(struct hclge_cmq_ring *ring)
> ring->desc = NULL;
> }
>
> -static int hclge_init_cmd_queue(struct hclge_dev *hdev, int ring_type)
> +static int hclge_alloc_cmd_queue(struct hclge_dev *hdev, int ring_type)
> {
> struct hclge_hw *hw = &hdev->hw;
> struct hclge_cmq_ring *ring =
> @@ -79,9 +79,6 @@ static int hclge_init_cmd_queue(struct hclge_dev *hdev, int
> ring_type)
> return ret;
> }
>
> - ring->next_to_clean = 0;
> - ring->next_to_use = 0;
> -
> return 0;
> }
>
> @@ -302,37 +299,52 @@ static enum hclge_cmd_status
> hclge_cmd_query_firmware_version(
> return ret;
> }
>
> -int hclge_cmd_init(struct hclge_dev *hdev)
> +int hclge_cmd_queue_init(struct hclge_dev *hdev)
> {
> - u32 version;
> int ret;
>
> /* Setup the queue entries for use cmd queue */
> hdev->hw.cmq.csq.desc_num = HCLGE_NIC_CMQ_DESC_NUM;
> hdev->hw.cmq.crq.desc_num = HCLGE_NIC_CMQ_DESC_NUM;
>
> - /* Setup the lock for command queue */
> - spin_lock_init(&hdev->hw.cmq.csq.lock);
> - spin_lock_init(&hdev->hw.cmq.crq.lock);
> -
> /* Setup Tx write back timeout */
> hdev->hw.cmq.tx_timeout = HCLGE_CMDQ_TX_TIMEOUT;
>
> /* Setup queue rings */
> - ret = hclge_init_cmd_queue(hdev, HCLGE_TYPE_CSQ);
> + ret = hclge_alloc_cmd_queue(hdev, HCLGE_TYPE_CSQ);
> if (ret) {
> dev_err(&hdev->pdev->dev,
> "CSQ ring setup error %d\n", ret);
> return ret;
> }
>
> - ret = hclge_init_cmd_queue(hdev, HCLGE_TYPE_CRQ);
> + ret = hclge_alloc_cmd_queue(hdev, HCLGE_TYPE_CRQ);
> if (ret) {
> dev_err(&hdev->pdev->dev,
> "CRQ ring setup error %d\n", ret);
> goto err_csq;
> }
>
> + return 0;
> +err_csq:
> + hclge_free_cmd_desc(&hdev->hw.cmq.csq);
> + return ret;
> +}
> +
> +int hclge_cmd_init(struct hclge_dev *hdev)
> +{
> + u32 version;
> + int ret;
> +
> + hdev->hw.cmq.csq.next_to_clean = 0;
> + hdev->hw.cmq.csq.next_to_use = 0;
> + hdev->hw.cmq.crq.next_to_clean = 0;
> + hdev->hw.cmq.crq.next_to_use = 0;
> +
> + /* Setup the lock for command queue */
> + spin_lock_init(&hdev->hw.cmq.csq.lock);
> + spin_lock_init(&hdev->hw.cmq.crq.lock);
> +
> hclge_cmd_init_regs(&hdev->hw);
>
> ret = hclge_cmd_query_firmware_version(&hdev->hw, &version);
> @@ -346,9 +358,6 @@ int hclge_cmd_init(struct hclge_dev *hdev)
> dev_info(&hdev->pdev->dev, "The firmware version is %08x\n", version);
>
> return 0;
> -err_csq:
> - hclge_free_cmd_desc(&hdev->hw.cmq.csq);
> - return ret;
> }
>
> static void hclge_destroy_queue(struct hclge_cmq_ring *ring)
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
> index b437334..6bdc216 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
> @@ -750,4 +750,5 @@ enum hclge_cmd_status hclge_cmd_mdio_read(struct hclge_hw
> *hw,
> struct hclge_desc *desc);
>
> void hclge_destroy_cmd_queue(struct hclge_hw *hw);
> +int hclge_cmd_queue_init(struct hclge_dev *hdev);
> #endif
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index 4ef4592..a7686fe 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -4446,7 +4446,14 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev
> *ae_dev)
> goto err_pci_init;
> }
>
> - /* Command queue initialize */
> + /* Firmware comman
Re: Regression: commit da029c11e6b1 broke toybox xargs.
On Wed, Nov 1, 2017 at 4:34 PM, Rob Landley wrote:
> Toybox has been trying to figure out how big an xargs is allowed to be
> for a while:
>
> http://lists.landley.net/pipermail/toybox-landley.net/2017-October/009186.html
>
> We're trying to avoid the case where you can run something from the
> command line, but not through xargs. In theory this limit is
> sysconf(_SC_ARG_MAX) which on bionic and glibc returns 1/4 RLIMIT_STACK
> (in accordance with the prophecy fs/exec.c function
> get_arg_page()), but that turns out to be too simple. There's also a
> 131071 byte limit on each _individual_ argument, which I think I've
> tracked down to fs/exec.c function setup_arg_pages() doing:
>
> stack_expand = 131072UL; /* randomly 32*4k (or 2*64k) pages *
>
> And then it worked under ubuntu 14.04 but not current kernels. Why?
> Because the above commit from Kees Cook broke it, by taking this:
>
> include/uapi/linux/resource.h:
> /*
> * Limit the stack by to some sane default: root can always
> * increase this limit if needed.. 8MB seems reasonable.
> */
> #define _STK_LIM(8*1024*1024)
>
> And hardwiring in a random adjustment as a "640k ought to be enough for
> anybody" constant on TOP of the existing RLIMIT_STACK/4 check. Without
> even adjusting the "oh of course root can make this bigger, this is just
> a default value" comment where it's #defined.
>
> Look, if you want to cap RLIMIT_STACK for suid binaries, go for it. The
> existing code will notice and adapt. But this new commit is crazy and
> arbitrary and introduces more random version dependencies (how is
> sysconf() supposed to know the value, an #if/else staircase based on
> kernel version in every libc)?
>
> Please revert it,
Hi Linus,
This is a report of userspace breakage due to:
commit da029c11e6b1 ("exec: Limit arg stack to at most 75% of _STK_LIM")
As a reminder to earlier discussions[1], it had been suggested that
this be setuid only, but you had asked that this be globally applied:
On Mon, Jul 10, 2017 at 11:24 AM, Linus Torvalds
wrote:
> But honestly, a security limit that isn't tested in normal working is
> not a security limit at all, it's just theory and likely bullshit. So
> I'd much rather *not* make it suid-specific if at all possible. That
> way it has some chance in hell of actually getting tested.
We're going to need to revisit this. One alternative that was
suggested by Andy was to do a late "how much stack space was used?"
check after arg processing was finished. This could be attached to a
secureexec test to limit the checks for pathological conditions only
to setuid processes.
Rob, thanks for the report! Can you confirm that reverting the above
commit fixes the problem? There is also
commit 98da7d08850f ("fs/exec.c: account for argv/envp pointers")
which changes the calculation slightly too. If _SC_ARG_MAX is
hardcoded in bionic and glibc as 1/4 RLIMIT_STACK, we may need to
adjust this commit as well, since it will be a problem for giant
argument lists of very short strings.
Thanks,
-Kees
[1] https://lkml.org/lkml/2017/7/10/633
--
Kees Cook
Pixel Security
Re: [PATCH 4/7] MIPS: Octeon: Add Free Pointer Unit (FPA) support.
Le 11/01/17 à 17:36, David Daney a écrit : > From: Carlos Munoz > > From the hardware user manual: "The FPA is a unit that maintains > pools of pointers to free L2/DRAM memory. To provide QoS, the pools > are referenced indirectly through 1024 auras. Both core software > and hardware units allocate and free pointers." This looks like a possibly similar implement to what drivers/net/ethernet/marvell/mvneta_bm.c, can you see if you can make any use of genpool_* and include/net/hwbm.h here as well? -- Florian
Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Wed 01 Nov 20:02 PDT 2017, Jassi Brar wrote:
> On Thu, Nov 2, 2017 at 3:47 AM, Bjorn Andersson
> wrote:
> > On Wed 01 Nov 11:15 PDT 2017, Sudeep Holla wrote:
> >>
> >> 80 writel_relaxed(msg->cmd, mb->mbox_base +
> >> MAILBOX_A2B_CMD(chans->idx));
> >> 81 writel_relaxed(msg->rx_size, mb->mbox_base +
> >>
> >> 82MAILBOX_A2B_DAT(chans->idx));
> >>
> >> 83
> >
> > This is just terrible, using the void *mssg to pass a struct which is
> > interpreted by the controller removes any form of abstraction provided
> > by the framework.
> >
> > In my view the void *mssg should point to the data to be written in the
> > mailbox register, and hence might be of different size - but only of
> > native type.
> >
> Please note the terrible 'rx_size' is not a software option - the
> hardware has a DAT register so the driver rightfully allows a client
> to write a value in that as well.
Okay, so the interface exposed by the mailbox driver is not { cmd,
rx_size } but rather __le32 data[2], or perhaps a generic { cmd, data }.
That sounds more generic.
I think it would be good to replace the totally opaque void * with some
sort of structured data type and having the framework ensure that
clients and controllers are compatible. That would, by design, allow for
reuse between controllers and clients.
Perhaps something like:
enum mbox_msg_type {
MBOX_MSG_TYPE_NULL,
MBOX_MSG_TYPE_U32,
MBOX_MSG_TYPE_CMD_DATA,
};
struct mbox_msg {
enum mbox_msg_type type;
union {
u32 u;
struct {
u32 cmd;
u32 data;
} cd;
};
};
And have the controller register for a specific "type", so the framework
could validate that the type of data being passed matches the hardware.
Have you had any thoughts around this before?
Regards,
Bjorn
Re: [alsa-devel] [PATCH 08/14] soundwire: Add Slave status handling helpers
On Wed, Nov 01, 2017 at 04:10:08PM -0500, Pierre-Louis Bossart wrote: > On 11/1/17 4:08 AM, Vinod Koul wrote: > >On Wed, Nov 01, 2017 at 02:49:15AM +0530, Pierre-Louis Bossart wrote: > >>> > >>>BUT given that we have seen stuff i am inclined to add a counter, we cant > >>>have more than 11 device so that's a sane value to use :) > >> > >>Yep. Keep in mind however that there could be theoretical corner cases: if a > >>device is enumerated, loses sync and becomes attached again while you deal > >>with others, you'd have more than 11 iterations. > > > >Not really as that would be another interrupt and another status report. > > You are in a loop where you keep reading the devId registers, and that > really has nothing to do with interrupts or status report. The point was > that the number of times you read may be higher that the number of devices > with a device being handled several times. > As mentioned above you need to limit this loop to a sane value. Oh yes, I was thinking from status point of view which triggers this but yes we keep reading so your point is valid. Lets add 2x buffer for that. -- ~Vinod
Re: [PATCH net-next V2 3/3] tun: add eBPF based queue selection method
On 2017年11月02日 03:12, Alexei Starovoitov wrote:
On Wed, Nov 01, 2017 at 03:59:48PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 01, 2017 at 09:02:03PM +0800, Jason Wang wrote:
On 2017年11月01日 00:45, Michael S. Tsirkin wrote:
+static void __tun_set_steering_ebpf(struct tun_struct *tun,
+ struct bpf_prog *new)
+{
+ struct bpf_prog *old;
+
+ old = rtnl_dereference(tun->steering_prog);
+ rcu_assign_pointer(tun->steering_prog, new);
+
+ if (old) {
+ synchronize_net();
+ bpf_prog_destroy(old);
+ }
+}
+
Is this really called under rtnl?
Yes it is __tun_chr_ioctl() will call rtnl_lock().
Is the call from tun_free_netdev under rtnl too?
If no then rtnl_dereference
is wrong. If yes I'm not sure you can call synchronize_net
under rtnl.
Are you worrying about the long wait? Looking at synchronize_net(), it does:
void synchronize_net(void)
{
might_sleep();
if (rtnl_is_locked())
synchronize_rcu_expedited();
else
synchronize_rcu();
}
EXPORT_SYMBOL(synchronize_net);
Thanks
Not the wait - expedited is not a good thing to allow unpriveledged
userspace to do, it interrupts all VMs running on the same box.
We could use a callback though the docs warn userspace can use that
to cause a DOS and needs to be limited.
the whole __tun_set_steering_ebpf() looks odd to me.
There is tun_attach_filter/tun_detach_filter pattern
that works for classic BPF. Why for eBPF this strange
synchronize_net() is there?
I'm not sure I get the question. eBPF here is used to do queue
selection, so we could not reuse socket filter (tun_detach_filter use
call_rcu()). cBPF could be used here, but I'm not quite sure it's worth
to support it. And I agree we should use call_rcu() here.
Hope this answer your question.
Thanks
Re: [PATCH net-next] vhost_net: conditionally enable tx polling
On 2017年11月01日 23:03, Michael S. Tsirkin wrote:
On Wed, Nov 01, 2017 at 08:51:36PM +0800, Jason Wang wrote:
On 2017年11月01日 00:36, Michael S. Tsirkin wrote:
On Tue, Oct 31, 2017 at 06:27:20PM +0800, Jason Wang wrote:
We always poll tx for socket, this is sub optimal since:
- we only want to be notified when sndbuf is available
- this will slightly increase the waitqueue traversing time and more
important, vhost could not benefit from commit
commit 9e641bdcfa4e
("net-tun: restructure tun_do_read for better sleep/wakeup efficiency")
even if we've stopped rx polling during handle_rx() since tx poll
were still left in the waitqueue.
Pktgen from a remote host to VM over mlx4 shows 5.5% improvements on
rx PPS. (from 1.27Mpps to 1.34Mpps)
Cc: Wei Xu
Cc: Matthew Rosato
Signed-off-by: Jason Wang
---
Now that vhost_poll_stop happens on data path
a lot, I'd say
if (poll->wqh)
there should be unlikely().
It has been there since 8241a1e466cd ("vhost_net: stop polling socket during
rx processing"). So it will be used for rx path too which unlikely() does
not work as well as the case in tx.
Worth testing, does not have to block this patch.
Ok.
drivers/vhost/net.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 68677d9..286c3e4 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -471,6 +471,7 @@ static void handle_tx(struct vhost_net *net)
goto out;
vhost_disable_notify(&net->dev, vq);
+ vhost_net_disable_vq(net, vq);
hdr_size = nvq->vhost_hlen;
zcopy = nvq->ubufs;
@@ -556,6 +557,8 @@ static void handle_tx(struct vhost_net *net)
% UIO_MAXIOV;
}
vhost_discard_vq_desc(vq, 1);
+ if (err == -EAGAIN)
+ vhost_net_enable_vq(net, vq);
break;
}
if (err != len)
I would probably just enable it unconditionally here. Why not?
I thought we only care about the case of tun_sock_write_space() and for the
errors other than -EAGAIN, they have nothing to do with polling.
We could thinkably get ENOMEM I guess. If we miss a code things
get stuck - It's just easier not to add extra code IMHO.
ENOBUFS actually. I agree to remove the specific checking of -EAGAIN here.
@@ -1145,9 +1148,11 @@ static long vhost_net_set_backend(struct vhost_net *n,
unsigned index, int fd)
r = vhost_vq_init_access(vq);
if (r)
goto err_used;
- r = vhost_net_enable_vq(n, vq);
- if (r)
- goto err_used;
+ if (index == VHOST_NET_VQ_RX) {
+ r = vhost_net_enable_vq(n, vq);
+ if (r)
+ goto err_used;
+ }
oldubufs = nvq->ubufs;
nvq->ubufs = ubufs;
This last chunk seems questionable. If queue has stuff in it
when we connect the backend, we'll miss a wakeup.
I suspect this can happen during migration.
Unless qemu pass a tap which s already had pending tx packets.
I can remove this chuck, but if guest does not transmit any packet, rx can't
benefit from this.
Thanks
Not sure I understand the last sentence. vhost will stay
polling the socket - why is that a problem?
No function problem at all. If guest does not transmit any packet, the
patch does not have any effect.
Will remove this chunk in next version.
Thanks
--
2.7.4
___
Virtualization mailing list
virtualizat...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [PATCH 2/2] Documentation: fsl: dspi: Add a compatible string for ls1088a DSPI
Hi Rob, Thanks a lot for the ack! > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: 2017年11月2日 8:14 > To: Z.q. Hou > Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org; linux-...@vger.kernel.org; broo...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Prabhakar Kushwaha > > Subject: Re: [PATCH 2/2] Documentation: fsl: dspi: Add a compatible string for > ls1088a DSPI > > On Wed, Nov 01, 2017 at 11:40:15AM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > Add a new compatible string "fsl,ls1088a-dspi". > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 + > > 1 file changed, 1 insertion(+) > > "dt-bindings: spi: " for the subject. Otherwise, I'll recompose the subject in next version. > > Acked-by: Rob Herring Thanks, Zhiqiang
Re: [PATCH] sh: remove pointless select of KBUILD_DEFCONFIG
SH developers, No comment? Looks like the SH maintainers are no more picking up any patches. If nobody takes care of this patch, I will apply it to Kbuild tree. 2017-10-04 18:33 GMT+09:00 Masahiro Yamada : > KBUILD_DEFCONFIG := shx3_defconfig > > is never used in a sensible way. KBUILD_DEFCONFIG specifies the > defconfig file used by "make defconfig", but CONFIG_SUPERH32 is > never set when building config targets. > > Signed-off-by: Masahiro Yamada > --- > > arch/sh/Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/sh/Makefile b/arch/sh/Makefile > index 280bbff..c937ec0 100644 > --- a/arch/sh/Makefile > +++ b/arch/sh/Makefile > @@ -96,6 +96,7 @@ defaultimage-$(CONFIG_SH_7619_SOLUTION_ENGINE):= > vmlinux > # Set some sensible Kbuild defaults > boot := arch/sh/boot > KBUILD_IMAGE := $(boot)/$(defaultimage-y) > +KBUILD_DEFCONFIG := cayman_defconfig > > # > # Choosing incompatible machines durings configuration will result in > @@ -105,14 +106,12 @@ ifdef CONFIG_SUPERH32 > UTS_MACHINE:= sh > BITS := 32 > LDFLAGS_vmlinux+= -e _stext > -KBUILD_DEFCONFIG := shx3_defconfig > else > UTS_MACHINE:= sh64 > BITS := 64 > LDFLAGS_vmlinux+= --defsym > phys_stext=_stext-$(CONFIG_PAGE_OFFSET) \ >--defsym phys_stext_shmedia=phys_stext+1 \ >-e phys_stext_shmedia > -KBUILD_DEFCONFIG := cayman_defconfig > endif > > ifdef CONFIG_CPU_LITTLE_ENDIAN > -- > 2.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH] timer: Add parenthesis around timer_setup() macro arguments
On Wed, Nov 1, 2017 at 7:33 PM, Stephen Rothwell wrote: > Hi Kees, > > On Wed, 1 Nov 2017 07:32:50 -0700 Kees Cook wrote: >> >> In the case where expressions are passed as macro arguments, the LOCKDEP >> version of the timer macros need enclosing parenthesis. >> >> Reported-by: Stephen Rothwell >> Signed-off-by: Kees Cook > > I have applied that patch to linux-next today pending it appearing in > the tip tree. Thanks! It should be there in tip/timers/core as of several hours ago. -Kees -- Kees Cook Pixel Security
[f2fs-dev] [PATCH] f2fs: save a multiplication for last_nid calculation
Use a slightly easier way to calculate last_nid. Signed-off-by: Fan li --- fs/f2fs/node.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 7834097..55ab330 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -2642,7 +2642,7 @@ static inline void load_free_nid_bitmap(struct f2fs_sb_info *sbi) __set_bit_le(i, nm_i->nat_block_bitmap); nid = i * NAT_ENTRY_PER_BLOCK; - last_nid = (i + 1) * NAT_ENTRY_PER_BLOCK; + last_nid = nid + NAT_ENTRY_PER_BLOCK; spin_lock(&NM_I(sbi)->nid_list_lock); for (; nid < last_nid; nid++) -- 2.7.4
Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Thu, Nov 2, 2017 at 3:47 AM, Bjorn Andersson wrote: > On Wed 01 Nov 11:15 PDT 2017, Sudeep Holla wrote: >> >> 80 writel_relaxed(msg->cmd, mb->mbox_base + >> MAILBOX_A2B_CMD(chans->idx)); >> 81 writel_relaxed(msg->rx_size, mb->mbox_base + >> >> 82MAILBOX_A2B_DAT(chans->idx)); >> >> 83 > > This is just terrible, using the void *mssg to pass a struct which is > interpreted by the controller removes any form of abstraction provided > by the framework. > > In my view the void *mssg should point to the data to be written in the > mailbox register, and hence might be of different size - but only of > native type. > Please note the terrible 'rx_size' is not a software option - the hardware has a DAT register so the driver rightfully allows a client to write a value in that as well.
Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Thu, Nov 2, 2017 at 3:42 AM, Bjorn Andersson
wrote:
> On Wed 01 Nov 11:03 PDT 2017, Jassi Brar wrote:
>> On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla wrote:
> [..]
>> >
>> > This is rough idea I have on extending mailbox interface to support
>> > the doorbell requirements.
>> >
>> What doorbell requirements does the api not support?
>> QComm's APCS IPC is what you call a "doorbell" controller and is
>> already supported by the API. It could run SCMI even easier than MHU
>> (your controller).
>>
>
> I agree; from a mbox consumer perspective a doorbell should be a mailbox
> channel that when signalled will ring the bell, i.e. the message is not
> significant and should not be provided by the client.
>
> If the message is significant and is not derived from the mailbox
> channel (e.g. channel id -> bit in register) it is not a mailbox
> doorbell, it's s regular mailbox used as a doorbell.
>
>
> The potential improvement I see in the Qualcomm case is to wrap the
> mbox_send_message(chan, NULL); mbox_client_txdone(chan, 0); calls in one
> simple "mbox_ring_door_bell(chan)" - but I haven't investigated the
> validity of this as a generic function.
>
If you remember I already suggested we can use the existing api to
define a convenient helper ->
https://www.spinics.net/lists/linux-soc/msg01781.html
mailbox_client.h
***
void mbox_ring_doorbell(struct mbox_chan *chan, void *mssg)
{
(void)mbox_send_message(chan, mssg);
mbox_client_txdone(chan, 0);
}
instead of adding a new api and modifying each driver.
Cheers!
linux-next: build warnings after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:
net/dccp/probe.c: In function 'dccpprobe_init':
net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated
[-Wdeprecated-declarations]
ret = register_jprobe(&dccp_send_probe);
^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:471:32: note: declared here
static inline int __deprecated register_jprobe(struct jprobe *p)
^
net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated
[-Wdeprecated-declarations]
ret = register_jprobe(&dccp_send_probe);
^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:471:32: note: declared here
static inline int __deprecated register_jprobe(struct jprobe *p)
^
net/dccp/probe.c: In function 'dccpprobe_exit':
net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated
[-Wdeprecated-declarations]
unregister_jprobe(&dccp_send_probe);
^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:479:33: note: declared here
static inline void __deprecated unregister_jprobe(struct jprobe *p)
^
net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated
[-Wdeprecated-declarations]
ret = register_jprobe(&tcp_jprobe);
^
In file included from net/ipv4/tcp_probe.c:24:0:
include/linux/kprobes.h:471:32: note: declared here
static inline int __deprecated register_jprobe(struct jprobe *p)
^
net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated
[-Wdeprecated-declarations]
unregister_jprobe(&tcp_jprobe);
^
In file included from net/ipv4/tcp_probe.c:24:0:
include/linux/kprobes.h:479:33: note: declared here
static inline void __deprecated unregister_jprobe(struct jprobe *p)
^
net/sctp/probe.c: In function 'sctp_setup_jprobe':
net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated
[-Wdeprecated-declarations]
int ret = register_jprobe(&sctp_recv_probe);
^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:471:32: note: declared here
static inline int __deprecated register_jprobe(struct jprobe *p)
^
net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated
[-Wdeprecated-declarations]
ret = register_jprobe(&sctp_recv_probe);
^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:471:32: note: declared here
static inline int __deprecated register_jprobe(struct jprobe *p)
^
net/sctp/probe.c: In function 'sctpprobe_exit':
net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated
[-Wdeprecated-declarations]
unregister_jprobe(&sctp_recv_probe);
^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:479:33: note: declared here
static inline void __deprecated unregister_jprobe(struct jprobe *p)
^
Introduced by commit
590c84593045 ("kprobes: Disable the jprobes APIs")
These days we normally don't deprecate things, just remove them. But we
do that *after* fixing up all the usages in the tree, please.
--
Cheers,
Stephen Rothwell
RE: [f2fs-dev] [PATCH] f2fs: modify the procedure of scan free nid
> -Original Message-
> From: Chao Yu [mailto:c...@kernel.org]
> Sent: Wednesday, November 01, 2017 8:47 PM
> To: Fan Li; 'Jaegeuk Kim'
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: modify the procedure of scan free nid
>
> On 2017/11/1 18:03, Fan Li wrote:
> >
> >
> >> -Original Message-
> >> From: Chao Yu [mailto:c...@kernel.org]
> >> Sent: Tuesday, October 31, 2017 10:32 PM
> >> To: Fan Li; 'Jaegeuk Kim'
> >> Cc: linux-kernel@vger.kernel.org;
> >> linux-f2fs-de...@lists.sourceforge.net
> >> Subject: Re: [f2fs-dev] [PATCH] f2fs: modify the procedure of scan
> >> free nid
> >>
> >> On 2017/10/31 21:37, Fan Li wrote:
> >>> In current version, we preserve 8 pages of nat blocks as free nids,
> >>> build bitmaps for it and use them to allocate nids until its number
> >>> drops below NAT_ENTRY_PER_BLOCK.
> >>>
> >>> After that, we have a problem, scan_free_nid_bits will scan the same
> >>> 8 pages trying to find more free nids, but in most cases the free
> >>> nids in these bitmaps are already in free list, scan them won't get
> >>> us any new nids.
> >>> Further more, after scan_free_nid_bits, the search is over if
> >>> nid_cnt[FREE_NID] != 0.
> >>> It causes that we scan the same pages over and over again, yet no
> >>> new free nids are found until nid_cnt[FREE_NID]==0.
> >>>
> >>> This patch mark the range where new free nids could exist and keep
> >>> scan for free nids until nid_cnt[FREE_NID] >= NAT_ENTRY_PER_BLOCK.
> >>> The new vairable first_scan_block marks the start of the range, it's
> >>> initialized with NEW_ADDR, which means all free nids before
> >>> next_scan_nid are already in free list; and use next_scan_nid as the
> >>> end of the range since all free nids which are scanned must be
> >>> smaller next_scan_nid.
> >>>
> >>>
> >>> Signed-off-by: Fan li
> >>> ---
> >>> fs/f2fs/f2fs.h | 1 +
> >>> fs/f2fs/node.c | 30 ++
> >>> 2 files changed, 27 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index e0ef31c..ae1cf91
> >>> 100644
> >>> --- a/fs/f2fs/f2fs.h
> >>> +++ b/fs/f2fs/f2fs.h
> >>> @@ -705,6 +705,7 @@ struct f2fs_nm_info {
> >>> nid_t max_nid; /* maximum possible node ids */
> >>> nid_t available_nids; /* # of available node ids */
> >>> nid_t next_scan_nid;/* the next nid to be scanned */
> >>> + block_t first_scan_block; /* the first NAT block to be scanned */
> >>
> >> As we are traveling bitmap, so how about using smaller granularity for
> >> tracking last-scanned-position. like:
> >>
> >> unsigned next_bitmap_pos; ?
> >>
> > Yes, I think it's a good idea, but original code scans nids by blocks,
> > if I change that, I need to change some other details too, and before that,
> > I want to make sure this idea of patch is right.
> > I also have some ideas about it, if that's OK, I tend to submit other
> > patches to implement them.
> >
> >>> unsigned int ram_thresh;/* control the memory footprint */
> >>> unsigned int ra_nid_pages; /* # of nid pages to be readaheaded */
> >>> unsigned int dirty_nats_ratio; /* control dirty nats ratio threshold */
> >>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 3d0d1be..7834097
> >>> 100644
> >>> --- a/fs/f2fs/node.c
> >>> +++ b/fs/f2fs/node.c
> >>> @@ -1950,10 +1950,23 @@ static void scan_free_nid_bits(struct
> >>> f2fs_sb_info *sbi)
> >>> struct curseg_info *curseg = CURSEG_I(sbi, CURSEG_HOT_DATA);
> >>> struct f2fs_journal *journal = curseg->journal;
> >>> unsigned int i, idx;
> >>> + unsigned int max_blocks = NAT_BLOCK_OFFSET(nm_i->next_scan_nid);
> >>>
> >>> - down_read(&nm_i->nat_tree_lock);
> >>> + /* every free nid in blocks scanned previously is in the free list */
> >>> + if (nm_i->first_scan_block == NEW_ADDR)
> >>
> >> How about using nm_i->max_nid as no more free nids in bitmap?
> >>
> > For now, I use the block as the unit of variable first_scan_block, for
> > the same reason above, I tend to change it in another patch.
> >
> >>> + return;
> >>>
> >>> - for (i = 0; i < nm_i->nat_blocks; i++) {
> >>> + /*
> >>> + * TODO: "next_scan_nid == 0" means after searching every nat block,
> >>> + * we still can't find enough free nids, there may not be any
> >>> + * more nid left to be found, we should stop at somewhere
> >>> + * instead of going through these all over again.
> >>> + */
>
> How about trying avoid todo thing in our patch, if our new feature is not so
> complicate or big.
>
Sure, I will delete this.
> >>> + if (max_blocks == 0)
> >>> + max_blocks = nm_i->nat_blocks;
> >>> +
> >>> + down_read(&nm_i->nat_tree_lock);
> >>> + for (i = nm_i->first_scan_block; i < max_blocks; i++) {
> >>
> >> Free nids could be set free after nodes were truncated & checkpoint,
> >> if we start from first_scan_block, we will miss some free
> > nids.
> >>
> > This is the part I
Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Wed, Nov 1, 2017 at 11:45 PM, Sudeep Holla wrote:
>
>
> On 01/11/17 18:03, Jassi Brar wrote:
>> On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla wrote:
>>
>>>
>>> Such controllers don't need to transmit any data, they just transmit
>>> the signal. In such controllers the data pointer passed to
>>> mbox_send_message is passed to client via it's tx_prepare callback.
>>> Controller doesn't need any data to be passed from the client.
>>>
>> Some controllers need a non-zero value written to a register in order
>> to trigger the signal.
>
> You are right, just right non-zero or whatever controller value to
> trigger the interrupt to remote.
>
>> That register is visible to the remote. While the data/packet is setup
>> during tx_prepare() callback.
>
> Agreed.
>
>> You are overlooking this class of doorbell controllers.
>>
>
> Not sure what do you mean by that ?
>
Such doorbell controllers can't use send_signal(chan) because they
need that non-zero value from client to send over the shared register.
You are assuming every protocol implements just one command.
>>>
>>> This is rough idea I have on extending mailbox interface to support
>>> the doorbell requirements.
>>>
>> What doorbell requirements does the api not support?
>> QComm's APCS IPC is what you call a "doorbell" controller and is
>> already supported by the API. It could run SCMI even easier than MHU
>> (your controller).
>>
>
> Again agreed. But see below for reason to create this API.
>
>>> The new API send_signal will eliminate the
>>> issue Jassi has explained in earlier discussion with respect to generic
>>> message format using Rockchip example.
>>>
>> Sorry I don't see how.
>> Please explain how can send_signal() api be used by, say, rockchip to
>> support SCMI?
>>
>
> 80 writel_relaxed(msg->cmd, mb->mbox_base +
> MAILBOX_A2B_CMD(chans->idx));
> 81 writel_relaxed(msg->rx_size, mb->mbox_base +
>
> 82MAILBOX_A2B_DAT(chans->idx));
>
> 83
>
> will be replaced with
>
> writel(whatever_value_to trigger_signal, MAILBOX_A2B_CMD(chans->idx));
>
> in its send_signal function.
>
1) Where does the "whatever_value_to_trigger_signal" come from?
That has to come from client. You can not dictate the channel
transfers a fixed u32 value over its lifetime. SCMI may use one
command code but other protocols use more.
2) Using 'rx_size' is not a software choice made in the driver. The
_hardware_ has two registers shared with remote side - a CMD and a
DATA register. So the driver (written agnostic to any particular
client) would naturally expect the command+data from the client to be
programmed in to CMD and DAT registers.
>> I am not convinced we should clone an api just so that a client driver
>> becomes simpler. Esp when it shifts, and not avoid, the additional
>> code (to support the client) onto the provider side.
>>
>
> It doesn't tie the data format with particular mailbox controller.
> send_data has void *data and the interpretation is controller specific.
> send_signal on the other handle can implemented by the controllers which
> knows how and can trigger the specific signal to the remote.
>
Yeah that's what I said - you want to make a client simpler by pushing
the code requirement onto the provider side.
For example, you mean we modify the provider rockchip-mailbox.c by implementing
rockchip_send_signal(chan)
{
struct rockchip_mbox_msg msg;
msg.cmd = chan->idx; //only one command supported by the channel !!!
msg.rx_size = 0;
rockchip_send_data(chan, (void*) &msg);
}
whereas I suggest this SCMI specific code should be part of
transport/mapping shim layer of SCMI.
[PATCH v2] pstore: add lz4hc and 842 compression support
From: Geliang Tang
Currently, pstore has supported three compression algorithms: zlib,
lzo and lz4. This patch added two more compression algorithms: lz4hc
and 842.
Signed-off-by: Geliang Tang
---
Changes in v2:
fix checkpatch.pl WARNING:
please write a paragraph that describes the config symbol fully
---
fs/pstore/Kconfig| 25 ++
fs/pstore/platform.c | 128 +--
2 files changed, 138 insertions(+), 15 deletions(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index b42e5bd..cf97a3e 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -39,6 +39,31 @@ config PSTORE_LZ4_COMPRESS
select LZ4_DECOMPRESS
help
This option enables LZ4 compression algorithm support.
+
+config PSTORE_LZ4HC_COMPRESS
+ bool "LZ4HC"
+ select LZ4HC_COMPRESS
+ select LZ4_DECOMPRESS
+ help
+ This option enables LZ4 high compression mode algorithm.
+
+ Currently, pstore has supported five compression algorithms:
+ zlib, lzo, lz4, lz4hc and 842.
+
+ The default compression algorithm is zlib.
+
+config PSTORE_842_COMPRESS
+ bool "842"
+ select 842_COMPRESS
+ select 842_DECOMPRESS
+ help
+ This option enables 842 compression algorithm support.
+
+ Currently, pstore has supported five compression algorithms:
+ zlib, lzo, lz4, lz4hc and 842.
+
+ The default compression algorithm is zlib.
+
endchoice
config PSTORE_CONSOLE
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index ec7199e..def0210 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -34,9 +34,12 @@
#ifdef CONFIG_PSTORE_LZO_COMPRESS
#include
#endif
-#ifdef CONFIG_PSTORE_LZ4_COMPRESS
+#if defined(CONFIG_PSTORE_LZ4_COMPRESS) ||
defined(CONFIG_PSTORE_LZ4HC_COMPRESS)
#include
#endif
+#ifdef CONFIG_PSTORE_842_COMPRESS
+#include
+#endif
#include
#include
#include
@@ -337,20 +340,7 @@ static const struct pstore_zbackend backend_lzo = {
};
#endif
-#ifdef CONFIG_PSTORE_LZ4_COMPRESS
-static int compress_lz4(const void *in, void *out, size_t inlen, size_t outlen)
-{
- int ret;
-
- ret = LZ4_compress_default(in, out, inlen, outlen, workspace);
- if (!ret) {
- pr_err("LZ4_compress_default error; compression failed!\n");
- return -EIO;
- }
-
- return ret;
-}
-
+#if defined(CONFIG_PSTORE_LZ4_COMPRESS) ||
defined(CONFIG_PSTORE_LZ4HC_COMPRESS)
static int decompress_lz4(void *in, void *out, size_t inlen, size_t outlen)
{
int ret;
@@ -392,6 +382,21 @@ static void free_lz4(void)
big_oops_buf = NULL;
big_oops_buf_sz = 0;
}
+#endif
+
+#ifdef CONFIG_PSTORE_LZ4_COMPRESS
+static int compress_lz4(const void *in, void *out, size_t inlen, size_t outlen)
+{
+ int ret;
+
+ ret = LZ4_compress_default(in, out, inlen, outlen, workspace);
+ if (!ret) {
+ pr_err("LZ4_compress_default error; compression failed!\n");
+ return -EIO;
+ }
+
+ return ret;
+}
static const struct pstore_zbackend backend_lz4 = {
.compress = compress_lz4,
@@ -402,6 +407,95 @@ static const struct pstore_zbackend backend_lz4 = {
};
#endif
+#ifdef CONFIG_PSTORE_LZ4HC_COMPRESS
+static int compress_lz4hc(const void *in, void *out,
+ size_t inlen, size_t outlen)
+{
+ int ret;
+
+ ret = LZ4_compress_HC(in, out, inlen, outlen,
+ LZ4HC_DEFAULT_CLEVEL, workspace);
+ if (!ret) {
+ pr_err("LZ4_compress_HC error; compression failed!\n");
+ return -EIO;
+ }
+
+ return ret;
+}
+
+static const struct pstore_zbackend backend_lz4hc = {
+ .compress = compress_lz4hc,
+ .decompress = decompress_lz4,
+ .allocate = allocate_lz4,
+ .free = free_lz4,
+ .name = "lz4hc",
+};
+#endif
+
+#ifdef CONFIG_PSTORE_842_COMPRESS
+static int compress_842(const void *in, void *out, size_t inlen, size_t outlen)
+{
+ int ret;
+ unsigned int len;
+
+ ret = sw842_compress(in, inlen, out, &len, workspace);
+ if (!ret) {
+ pr_err("sw842_compress error; compression failed!\n");
+ return -EIO;
+ }
+ outlen = len;
+
+ return ret;
+}
+
+static int decompress_842(void *in, void *out, size_t inlen, size_t outlen)
+{
+ int ret;
+ unsigned int len;
+
+ ret = sw842_decompress(in, inlen, out, &len);
+ if (ret < 0) {
+ pr_err("sw842_decompress error, ret = %d!\n", ret);
+ return -EIO;
+ }
+ outlen = len;
+
+ return ret;
+}
+
+static void allocate_842(void)
+{
+ big_oops_buf_sz = psinfo->bufsize * 2;
+ big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
+ if (big_oops_buf) {
+ workspace = kmalloc(SW842_MEM_COMPRESS, GFP_KERNEL);
+
Re: Confirm Reciept Of This Mail
Season Greetings To You; Are you interested in taking up a representative position (Account Receivable Agent) for Meiwa Corporation co.Ltd, who is currently looking on contracting both Companies and Individuals who are based in Canada and USA irrespectively Please Note: * This is a part time contract offer that requires not too much of your time daily. * This position is open to all regardless of your Profession, Occupation and Position. * This position comes with Monthly stipends and good commission. Do Advise for more details if interested in taking up this offer Kindly Reply Back ASAP. Best Regard HR Manager - Opprinnelig melding - Fra: Meiwa Corporation co.Ltd Til: marius arnesen Sendt: Thu, 02 Nov 2017 03:18:17 +0100 (CET) Emne: Confirm Reciept Of This Mail
Re: [PATCH] timer: Add parenthesis around timer_setup() macro arguments
Hi Kees, On Wed, 1 Nov 2017 07:32:50 -0700 Kees Cook wrote: > > In the case where expressions are passed as macro arguments, the LOCKDEP > version of the timer macros need enclosing parenthesis. > > Reported-by: Stephen Rothwell > Signed-off-by: Kees Cook I have applied that patch to linux-next today pending it appearing in the tip tree. -- Cheers, Stephen Rothwell
Re: MAINTAINERS has a AS3645A LED FLASH duplicated section in -next
Hi Joe, On Thursday, 2 November 2017 03:54:29 EET Joe Perches wrote: > MAINTAINERS is not supposed to have duplicated sections. > Can you both please resolve this? Sure. Sakari, your plan was to drop drivers/media/i2c/as3645a.c if I recall correctly. Do you still want to proceed with that, or should we just rename one of the entries in MAINTAINERS ? > AS3645A LED FLASH CONTROLLER DRIVER > M:Sakari Ailus > L:linux-l...@vger.kernel.org > S:Maintained > F:drivers/leds/leds-as3645a.c > > AS3645A LED FLASH CONTROLLER DRIVER > M:Laurent Pinchart > L:linux-me...@vger.kernel.org > T:git git://linuxtv.org/media_tree.git > S:Maintained > F:drivers/media/i2c/as3645a.c > F:include/media/i2c/as3645a.h -- Regards, Laurent Pinchart
Re: [PATCH] selftests: remove obsolete kconfig fragment for cpu-hotplug
On 2017年11月02日 06:59, Shuah Khan wrote: On 11/01/2017 04:52 PM, Thomas Gleixner wrote: On Wed, 1 Nov 2017, Shuah Khan wrote: On 10/17/2017 08:10 PM, lei.y...@windriver.com wrote: From: Lei Yang Kconfig CONFIG_CPU_NOTIFIER_ERROR_INJECT has been removed since kernel 4.10 check commit: commit 530e9b76ae8f863dfdef4a6ad0b38613d32e8c3f Author: Thomas Gleixner Date: Wed Dec 21 20:19:53 2016 +0100 cpu/hotplug: Remove obsolete cpu hotplug register/unregister functions hotcpu_notifier(), cpu_notifier(), __hotcpu_notifier(), __cpu_notifier(), register_hotcpu_notifier(), register_cpu_notifier(), __register_hotcpu_notifier(), __register_cpu_notifier(), unregister_hotcpu_notifier(), unregister_cpu_notifier(), __unregister_hotcpu_notifier(), __unregister_cpu_notifier() Signed-off-by: Lei Yang --- tools/testing/selftests/cpu-hotplug/config | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/cpu-hotplug/config b/tools/testing/selftests/cpu-hotplug/config index e6ab090..d4aca2a 100644 --- a/tools/testing/selftests/cpu-hotplug/config +++ b/tools/testing/selftests/cpu-hotplug/config @@ -1,2 +1 @@ CONFIG_NOTIFIER_ERROR_INJECTION=y -CONFIG_CPU_NOTIFIER_ERROR_INJECT=m Yes. It is removed from the kernel. However, selftests from the latest release do get run routinely on older stable releases. Dropping the config will impact coverage on older releases. Thomas/Greg, Any ideas on what we should do about this. On one hand it is a good idea to remove it, however my concern is coverage on older releases. Can you check the kernel version on which you are running and do it runtime conditionally? I have been avoiding adding kernel version checks to tests. Maybe this is one exception since the functionality is obsoleted. I think the baseline is that we only assure kselftest works on the release it belongs to, for example, removing this config for the version above 4.10, keep it in old release. but looks it doesn't work like this way. I think We can't assure latest kselftest works still well on a very older releases yes, for some features it's common for each release. but we have some features that are only available in newer release. even for the common features, it's difficult to make sure it still works well for each release. maintenance is a big effort if we use something like version check. you never know what changes will make for general feature in the future release although it's common right now. Lei In any case, just removing the config isn't the complete solution. I will have to think about this some. thanks, -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
printk discussions at KS
As I was not there, and I know about as much as anyone about printk internals, can you please post a recap of what was discussed, technical and other, about printk improvements at the kernel-summit? If there was a pdf/powerpoint, that'd be nice to post too. Thanks and cheers, Joe
linux-next: manual merge of the integrity tree with the security tree
Hi all,
Today's linux-next merge of the integrity tree got a conflict in:
MAINTAINERS
between commit:
e28aa8aeab43 ("MAINTAINERS: remove David Safford as maintainer for
encrypted+trusted keys")
from the security tree and commit:
46d6c35e6882 ("MAINTAINERS: update the IMA, EVM, trusted-keys, encrypted-keys
entries")
from the integrity tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index df4a2519b306,80023acd6a7c..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -7680,7 -7623,8 +7677,7 @@@ F: kernel/kexec
KEYS-ENCRYPTED
M:Mimi Zohar
- L:linux-security-mod...@vger.kernel.org
-M:David Safford
+ L:linux-integr...@vger.kernel.org
L:keyri...@vger.kernel.org
S:Supported
F:Documentation/security/keys/trusted-encrypted.rst
@@@ -7688,8 -7632,9 +7685,8 @@@ F: include/keys/encrypted-type.
F:security/keys/encrypted-keys/
KEYS-TRUSTED
-M:David Safford
M:Mimi Zohar
- L:linux-security-mod...@vger.kernel.org
+ L:linux-integr...@vger.kernel.org
L:keyri...@vger.kernel.org
S:Supported
F:Documentation/security/keys/trusted-encrypted.rst
MAINTAINERS has a AS3645A LED FLASH duplicated section in -next
MAINTAINERS is not supposed to have duplicated sections. Can you both please resolve this? AS3645A LED FLASH CONTROLLER DRIVER M: Sakari Ailus L: linux-l...@vger.kernel.org S: Maintained F: drivers/leds/leds-as3645a.c AS3645A LED FLASH CONTROLLER DRIVER M: Laurent Pinchart L: linux-me...@vger.kernel.org T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/i2c/as3645a.c F: include/media/i2c/as3645a.h
( Compensation Reinbursement )
View the enclosed file for your Compensation Reinbursement Code Payment.pdf Description: Adobe PDF document
Re: linux-next: build warning after merge of the mmc tree
Hi,
On Wed, Nov 1, 2017 at 6:36 PM, Stephen Rothwell wrote:
> Hi Ulf,
>
> After merging the mmc tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/linux/irqflags.h:14:0,
> from arch/arm/include/asm/bitops.h:27,
> from include/linux/bitops.h:37,
> from include/linux/kernel.h:10,
> from include/asm-generic/bug.h:15,
> from arch/arm/include/asm/bug.h:59,
> from include/linux/bug.h:4,
> from include/linux/thread_info.h:11,
> from include/asm-generic/current.h:4,
> from ./arch/arm/include/generated/asm/current.h:1,
> from include/linux/sched.h:11,
> from include/linux/blkdev.h:4,
> from drivers/mmc/host/dw_mmc.c:14:
> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_set_drto':
> include/linux/typecheck.h:11:18: warning: comparison of distinct pointer
> types lacks a cast
> (void)(&__dummy == &__dummy2); \
> ^
> include/linux/spinlock.h:221:3: note: in expansion of macro 'typecheck'
>typecheck(unsigned long, flags); \
>^
> include/linux/spinlock.h:346:2: note: in expansion of macro
> 'raw_spin_lock_irqsave'
> raw_spin_lock_irqsave(spinlock_check(lock), flags); \
> ^
> drivers/mmc/host/dw_mmc.c:1953:2: note: in expansion of macro
> 'spin_lock_irqsave'
> spin_lock_irqsave(&host->irq_lock, irqflags);
> ^
>
> Introduced by commit
>
> 80a2a5a7745b ("mmc: dw_mmc: Cleanup the DTO timer like the CTO one")
Yes, the 0-day bot already complained about this. The short answer is
that Ulf kindly volunteered to manually fix up my patch series where I
had introduced a variable in the wrong patch. ...but in doing so he
introduced a small bug.
It should be very easy to fix. Just need to change irqflags from
"unsigned int" to "unsigned long".
-Doug
Re: [PATCH] mm: extend reuse_swap_page range as much as possible
writes:
> From: zhouxianrong
>
> origanlly reuse_swap_page requires that the sum of page's
> mapcount and swapcount less than or equal to one.
> in this case we can reuse this page and avoid COW currently.
>
> now reuse_swap_page requires only that page's mapcount
> less than or equal to one and the page is not dirty in
> swap cache. in this case we do not care its swap count.
>
> the page without dirty in swap cache means that it has
> been written to swap device successfully for reclaim before
> and then read again on a swap fault. in this case the page
> can be reused even though its swap count is greater than one
> and postpone the COW on other successive accesses to the swap
> cache page later rather than now.
>
> i did this patch test in kernel 4.4.23 with arm64 and none huge
> memory. it work fine.
Why do you need this? You saved copying one page from memory to memory
(COW) now, at the cost of reading a page from disk to memory later?
Best Regards,
Huang, Ying
> Signed-off-by: zhouxianrong
> ---
> mm/swapfile.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index bf91dc9..c21cf07 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1543,22 +1543,27 @@ static int page_trans_huge_map_swapcount(struct page
> *page, int *total_mapcount,
> bool reuse_swap_page(struct page *page, int *total_map_swapcount)
> {
> int count, total_mapcount, total_swapcount;
> + int dirty;
>
> VM_BUG_ON_PAGE(!PageLocked(page), page);
> if (unlikely(PageKsm(page)))
> return false;
> + dirty = PageDirty(page);
> count = page_trans_huge_map_swapcount(page, &total_mapcount,
> &total_swapcount);
> if (total_map_swapcount)
> *total_map_swapcount = total_mapcount + total_swapcount;
> - if (count == 1 && PageSwapCache(page) &&
> + if ((total_mapcount <= 1 && !dirty) ||
> + (count == 1 && PageSwapCache(page) &&
> (likely(!PageTransCompound(page)) ||
>/* The remaining swap count will be freed soon */
> - total_swapcount == page_swapcount(page))) {
> + total_swapcount == page_swapcount(page {
> if (!PageWriteback(page)) {
> page = compound_head(page);
> delete_from_swap_cache(page);
> SetPageDirty(page);
> + if (!dirty)
> + return true;
> } else {
> swp_entry_t entry;
> struct swap_info_struct *p;
RE: [PATCH v10 0/4] this patchset is to remove PPCisms for QEIC
On Wed, 1 Nov 2017, Thomas Gleixner wrote: > -Original Message- > From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Thursday, November 02, 2017 1:10 AM > To: Qiang Zhao > Cc: Michael Ellerman ; Jason Cooper > ; Marc Zyngier ; > o...@buserror.net; linuxppc-...@lists.ozlabs.org; Xiaobo Xie > ; linux-kernel@vger.kernel.org > Subject: RE: [PATCH v10 0/4] this patchset is to remove PPCisms for QEIC > > On Wed, 1 Nov 2017, Qiang Zhao wrote: > > Michael Ellerman wrote > > > > > > Qiang Zhao writes: > > > > > > > Hi all, > > > > > > > > Could anybody review this patchset and take action on them? Thank you! > > > > > > Who maintains this? I don't actually know, it's not powerpc code, or is > > > it? > > > > Yes, it's not powerpc code, it is irqchip code, maintained by Thomas, Jason > > and > Marc according to MAINTAINERS file. > > > > Hi Thomas, Jason and Marc, > > > > Could you keep an eye on this patchset? Thank you! > > It's on my radar, but I have zero capacity at the moment. Hopefully Marc can > spare a few cycles. > > Thanks, > > tglx Thank you! Best Regards Qiang Zhao
