Re: [PATCHv12 2/3] usb: USB Type-C connector class
On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote: > On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote: > > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote: > The Type-C specification states (in 4.5.2.2.11): > > "Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one shall > be > enabled by the port at any given time. Deciding which of these two mechanisms > is enabled is product design-specific." > > I read into this: > - The class code can not assume that either of those mechanisms are > implemented. Total agreement > - "product-design specific" means that the product designer determines which > of > the two mechanisms (if any) is enabled. While not explicitly stated, I would > assume this to be set either by hardware or via devicetree / ACPI, and not > from user space. I read this as spec-speak for "not our problem" > I don't mind to have user space control; all I am asking for is to have the > means for lower level code (which is the most likely entity to know about > product design) to be able to inform higher layers about its initial > preferences. We have this now, so I am happy. So am I. > Personally I don't really care about a module parameter; as mentioned above, > I would expect the preference, if it needs to be selectable, to be configured > with devicetree or ACPI properties (or by a platform driver which sets a > device > property). Well, as a distro for generic desktops and servers you will face an XHCI on PCI and UCSI telling you that your ports can express preferences. Now deal with it. And it must be said that such distros have over a decade of experience in acting as a master. The slave capability is less well developed. We'd like to be master. And if possible we'd like to avoid a later switch of roles, so the choice should be easily made in initrd. Regards Oliver
Re: [PATCH v2 04/12] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION
On Mon, Nov 28, 2016 at 03:21:54PM +0100, Michal Hocko wrote: > On Tue 08-11-16 08:31:49, Naoya Horiguchi wrote: > > Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration > > functionality to x86_64, which should be safer at the first step. > > Please make sure to describe why this has to be arch specific and what > are arches supposed to provide in order to enable this option. OK, the below will be added in the future version: Thp migration is an arch-specific feature because it depends on the arch-dependent behavior of non-present format of page table entry. What you need to enable this option in other archs are: - to define arch-specific transformation functions like __pmd_to_swp_entry() and __swp_entry_to_pmd(), - to make sure that arch-specific page table walking code can properly handle !pmd_present case (gup_pmd_range() is a good example), - (if your archs enables CONFIG_HAVE_ARCH_SOFT_DIRTY,) to define soft dirty routines like pmd_swp_mksoft_dirty. Thanks, Naoya Horiguchi
Re: [RFC PATCH] crypto: Add IV generation algorithms
On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote: > > No one is using it as of now. It was just a thought to pass context > information, instead of making it part of the context which is shared > among dm-crypt and geniv. OK in that case we should just get rid of it until it's actually needed. In any case, if there was a need for such information we should try to embed it into either the key (per-tfm) or the IV (per-request) as appropriate. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] lockdep: fix report formatting
On 29/11/16 01:24, Dmitry Vyukov wrote:
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") printk() requires KERN_CONT to continue log
messages. Lots of printk() in lockdep.c and print_ip_sym() don't
have it. As the result lockdep reports are completely messed.
Add missing KERN_CONT and inline print_ip_sym() where necessary.
Without this patch all scripts that parse kernel bug reports
are broken. So it makes sense to get this into 4.9.
I'm glad someone else is looking at this, I started working on a similar
patch but haven't quite finished it :)
Cc: aryabi...@virtuozzo.com
Cc: andreyk...@google.com
Cc: j...@perches.com
Cc: pet...@infradead.org
Cc: mi...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: syzkal...@googlegroups.com
Missing Signed-off-by.
FWIW I think the pr_cont() macro looks nicer than printk(KERN_CONT ...).
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
Re: [PATCH] video: imxfb: remove the macros for initializing the DMACR
On Mon, Nov 28, 2016 at 11:43:09PM +0100, Martin Kaiser wrote: > The current definitions of DMACR_HM() and DMACR_TM() are correct only > for imx1, they're wrong for imx21. > > The macros are meant for legacy board files only, they're not applicable > for boards using device tree. > > At the moment, there are no boards are using the macros. So it should be s/are using the/using these/ > safe to drop them rather than making them work for both imx1 and imx21, > which would require a change in the platform data struct. > > Signed-off-by: Martin Kaiser Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
On 29 November 2016 at 03:53, Ziji Hu wrote: > Hi Ulf, > > On 2016/11/28 23:16, Ulf Hansson wrote: >> On 28 November 2016 at 12:38, Ziji Hu wrote: >>> Hi Ulf, >>> >>> On 2016/11/28 19:13, Ulf Hansson wrote: > > As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), > to > send commands for testing current sampling point set in our host PHY. > > According to my test result, it shows that mmc_send_tuning() can only > support > tuning command (CMD21/CMD19). > As a result, we cannot use mmc_send_tuning() when card is in the > speed modes > which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and > SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in > those > speed modes. > > Could you please provide suggestions for the speed mode in which > tuning is > not available? > Normally the mmc host driver shouldn't have to care about what the card supports, as that is the responsibility of the mmc core to manage. The host should only need to implement the ->execute_tuning() ops, which gets called when the card supports tuning (CMD19/21). Does it make sense? >>>I think it is irrelevant to tuning procedure. >>> >>>Our host requires to adjust PHY setting after each time ios setting >>>(SDCLK/bus width/speed mode) is changed. >>>The simplified sequence is: >>>mmc change ios --> mmc_set_ios() --> ->set_ios() --> after >>> sdhci_set_ios(), >>>adjust PHY setting. >>>During PHY setting adjustment, out host driver has to send commands to >>>test current sampling point. Tuning is another independent step. >> >> For those speed modes (or other ios changes) that *don't* requires >> tuning, then what will you do when you send the command to confirm the >> change of PHY setting and it fails? >> >> My assumption is that you will fail anyway, by propagating the error >> to the mmc core. At least that what was my understanding from your >> earlier replies, right!? >> >> Then, I think there are no point having the host driver sending a >> command to confirm the PHY settings, as the mmc core will anyway >> discover if something goes wrong when the next command is sent. >> >> Please correct me if I am wrong! >> > >Sorry that I didn't make myself clear. > >Our host PHY delay line consists of hundreds of sampling points. >Each sampling point represents a different phase shift. > >In lower speed mode, our host driver will scan the delay line. >It will select and test multiple sampling points, other than testing >only single sampling point. > >If a sampling point fails to transfer cmd/data, our host driver will >move to test next sampling point, until we find out a group of successful >sampling points which can transfer cmd/data. At last we will select >a perfect one from them. Ahh, I see. Unfortunate, this is going to be very hard to implement properly. The main problem is that the host driver has *no* knowledge about the internal state of the card, as that is the responsibility of the mmc core to keep track of. If the host driver would send a command during every update of the "ios" setting, from ->set_ios(), for sure it would lead to commands being sent that are "forbidden" in the current internal state of the card. This would lead to that the card initialization sequence fails, because the card may move to an unknown internal state and the mmc core would have no knowledge about what happened. Hmm.. Can you specify, *exactly*, under which "ios updates" you need to verify updated PHY setting changes by sending a cmd/data? Also, please specify if it's enough to only test the CMD line or also DATA lines. Kind regards Uffe
Re: [RFC PATCH] crypto: Add IV generation algorithms
Hi Herbert, On 29 November 2016 at 12:58, Herbert Xu wrote: > But that begs the question, who is supposed to use crypto_geniv_set_ctx? > I thought it was dm-crypt but your patch doesn't contain any uses > of it at all. No one is using it as of now. It was just a thought to pass context information, instead of making it part of the context which is shared among dm-crypt and geniv. -Binoy
System Helpdesk
Erreichen Sie die Speichergrenze für Ihr Postfach. Bitte besuchen Sie den folgenden link, um die Wiederherstellung Ihrer E-Mail-Zugriff. http://www.emailcleanup001.tk/ System-Helpdesk
[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls
This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
On Qualcomm ARM64 platforms, the SMC call can return before it has
completed. If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.
The quirk stores off the session ID from the interrupted call in the
quirk structure so that it can be used by the caller.
This patch folds in a fix given by Sricharan R:
https://lkml.org/lkml/2016/9/28/272
Signed-off-by: Andy Gross
---
arch/arm64/kernel/smccc-call.S | 9 -
drivers/firmware/qcom_scm-64.c | 11 +--
include/linux/arm-smccc.h | 11 ---
3 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 7b0b3f6..8191fde 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -12,6 +12,7 @@
*
*/
#include
+#include
#include
.macro SMCCC instr
@@ -20,7 +21,13 @@
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
- ret
+ ldr x4, [sp, #8]
+ cbz x4, 1f /* no quirk structure */
+ ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
+ cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
+ b.ne1f
+ str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
+1: ret
.cfi_endproc
.endm
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index d164a9b..6e997a6 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -91,6 +91,7 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, u32
cmd_id,
dma_addr_t args_phys = 0;
void *args_virt = NULL;
size_t alloc_len;
+ struct arm_smccc_quirk quirk = {.id = ARM_SMCCC_QUIRK_QCOM_A6};
if (unlikely(arglen > N_REGISTER_ARGS)) {
alloc_len = N_EXT_QCOM_SCM_ARGS * sizeof(u64);
@@ -131,10 +132,16 @@ static int qcom_scm_call(struct device *dev, u32 svc_id,
u32 cmd_id,
qcom_smccc_convention,
ARM_SMCCC_OWNER_SIP, fn_id);
+ quirk.state.a6 = 0;
+
do {
arm_smccc_smc(cmd, desc->arginfo, desc->args[0],
- desc->args[1], desc->args[2], x5, 0, 0,
- res, NULL);
+ desc->args[1], desc->args[2], x5,
+ quirk.state.a6, 0, res, &quirk);
+
+ if (res->a0 == QCOM_SCM_INTERRUPTED)
+ cmd = res->a0;
+
} while (res->a0 == QCOM_SCM_INTERRUPTED);
mutex_unlock(&qcom_scm_lock);
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 74231b4c..0a239a0 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -14,9 +14,6 @@
#ifndef __LINUX_ARM_SMCCC_H
#define __LINUX_ARM_SMCCC_H
-#include
-#include
-
/*
* This file provides common defines for ARM SMC Calling Convention as
* specified in
@@ -60,6 +57,13 @@
#define ARM_SMCCC_OWNER_TRUSTED_OS 50
#define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
+#define ARM_SMCCC_QUIRK_NONE 0
+#define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register a6 */
+
+#ifndef __ASSEMBLY__
+
+#include
+#include
/**
* struct arm_smccc_res - Result from SMC/HVC call
* @a0-a3 result values from registers 0 to 3
@@ -115,4 +119,5 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, unsigned
long a1,
unsigned long a5, unsigned long a6, unsigned long a7,
struct arm_smccc_res *res);
+#endif /*__ASSEMBLY__*/
#endif /*__LINUX_ARM_SMCCC_H*/
--
1.9.1
[PATCH 0/2] Support ARM SMCC SoC vendor quirks
At least one SoC vendor (Qualcomm) requires additional processing done during ARM SMCCC calls. As such, an additional parameter to the arm_smccc_smc is required to be able to handle SoC specific quirks. The Qualcomm quirk is necessary due to the fact that the scm call can be interrupted on Qualcomm ARM64 platforms. When this occurs, the call must be restarted using information that was passed back during the original smc call. The first patch in this series adds a quirk structure and also adds a quirk paramter to arm_smccc_smc calls. All of the current users of the call are modified to accomodate the new API parameter. The second patch adds the Qualcomm quirk and also implements the Qualcomm firmware changes required to handle the restarting of the interrupted SMC call. The original patch set for the SMCCC session ID is located at: https://lkml.org/lkml/2016/8/20/7 Andy Gross (2): arm: kernel: Add SMC structure parameter firmware: qcom: scm: Fix interrupted SCM calls arch/arm/kernel/smccc-call.S | 3 ++- arch/arm/mach-artpec/board-artpec6.c | 2 +- arch/arm64/kernel/asm-offsets.c | 7 +-- arch/arm64/kernel/smccc-call.S | 12 ++-- drivers/clk/rockchip/clk-ddr.c | 6 +++--- drivers/devfreq/rk3399_dmc.c | 6 +++--- drivers/firmware/meson/meson_sm.c| 2 +- drivers/firmware/psci.c | 2 +- drivers/firmware/qcom_scm-64.c | 13 ++--- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- include/linux/arm-smccc.h| 29 - 11 files changed, 61 insertions(+), 23 deletions(-) -- 1.9.1
[PATCH 1/2] arm: kernel: Add SMC structure parameter
This patch adds a quirk parameter to the arm_smccc_smc call. The quirk structure allows for specialized SMC operations due to SoC specific requirements. This patch also fixes up all the current users of the arm_smccc_smc API. This patch and partial implementation was suggested by Will Deacon. Signed-off-by: Andy Gross --- arch/arm/kernel/smccc-call.S | 3 ++- arch/arm/mach-artpec/board-artpec6.c | 2 +- arch/arm64/kernel/asm-offsets.c | 7 +-- arch/arm64/kernel/smccc-call.S | 3 ++- drivers/clk/rockchip/clk-ddr.c | 6 +++--- drivers/devfreq/rk3399_dmc.c | 6 +++--- drivers/firmware/meson/meson_sm.c| 2 +- drivers/firmware/psci.c | 2 +- drivers/firmware/qcom_scm-64.c | 4 ++-- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- include/linux/arm-smccc.h| 18 -- 11 files changed, 37 insertions(+), 18 deletions(-) diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S index 37669e7..e77950a 100644 --- a/arch/arm/kernel/smccc-call.S +++ b/arch/arm/kernel/smccc-call.S @@ -47,7 +47,8 @@ UNWIND( .fnend) /* * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2, * unsigned long a3, unsigned long a4, unsigned long a5, - * unsigned long a6, unsigned long a7, struct arm_smccc_res *res) + * unsigned long a6, unsigned long a7, struct arm_smccc_res *res, + * struct arm_smccc_quirk *quirk) */ ENTRY(arm_smccc_smc) SMCCC SMCCC_SMC diff --git a/arch/arm/mach-artpec/board-artpec6.c b/arch/arm/mach-artpec/board-artpec6.c index a0b1979..3a4d330 100644 --- a/arch/arm/mach-artpec/board-artpec6.c +++ b/arch/arm/mach-artpec/board-artpec6.c @@ -50,7 +50,7 @@ static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg) struct arm_smccc_res res; arm_smccc_smc(SECURE_OP_L2C_WRITEREG, reg, val, 0, - 0, 0, 0, 0, &res); + 0, 0, 0, 0, &res, NULL); WARN_ON(res.a0); } diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 4a2f0f0..c58ddf8 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -140,8 +140,11 @@ int main(void) DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS, offsetof(struct sleep_stack_data, system_regs)); DEFINE(SLEEP_STACK_DATA_CALLEE_REGS, offsetof(struct sleep_stack_data, callee_saved_regs)); #endif - DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0)); - DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2)); + DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0)); + DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2)); + DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id)); + DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, state)); + BLANK(); DEFINE(HIBERN_PBE_ORIG, offsetof(struct pbe, orig_address)); DEFINE(HIBERN_PBE_ADDR, offsetof(struct pbe, address)); diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S index ae0496f..7b0b3f6 100644 --- a/arch/arm64/kernel/smccc-call.S +++ b/arch/arm64/kernel/smccc-call.S @@ -27,7 +27,8 @@ /* * void arm_smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2, * unsigned long a3, unsigned long a4, unsigned long a5, - * unsigned long a6, unsigned long a7, struct arm_smccc_res *res) + * unsigned long a6, unsigned long a7, struct arm_smccc_res *res, + * struct arm_smccc_quirk *quirk) */ ENTRY(arm_smccc_smc) SMCCC smc diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c index 8feba93..cbdc0f8 100644 --- a/drivers/clk/rockchip/clk-ddr.c +++ b/drivers/clk/rockchip/clk-ddr.c @@ -45,7 +45,7 @@ static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, unsigned long drate, spin_lock_irqsave(ddrclk->lock, flags); arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, drate, 0, ROCKCHIP_SIP_CONFIG_DRAM_SET_RATE, - 0, 0, 0, 0, &res); + 0, 0, 0, 0, &res, NULL); spin_unlock_irqrestore(ddrclk->lock, flags); return res.a0; @@ -59,7 +59,7 @@ static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, unsigned long drate, arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, 0, 0, ROCKCHIP_SIP_CONFIG_DRAM_GET_RATE, - 0, 0, 0, 0, &res); + 0, 0, 0, 0, &res, NULL); return res.a0; } @@ -72,7 +72,7 @@ static long rockchip_ddrclk_sip_round_rate(struct clk_hw *hw, arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, rate, 0, ROCKCHIP_SIP_CONFIG_DRAM_ROUND_RATE, - 0, 0, 0, 0, &res); + 0, 0, 0, 0, &res, NULL); return res.a0; } diff --git a/drivers/devfreq/rk3399_dmc.
Re: RFC: documentation of the autogroup feature [v2]
Hi Peter,
On 11/25/2016 10:49 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote:
>> So, part of what I was struggling with was what you meant by cfs-cgroup.
>> Do you mean the CFS bandwidth control features added in Linux 3.2?
>
> Nope, /me digs around for a bit... around here I suppose:
>
> 68318b8e0b61 ("Hook up group scheduler with control groups")
Thanks. The pieces are starting to fall into place now.
> 68318b8e0b61 v2.6.24-rc1~151
>
> But I really have no idea what that looked like.
>
> In any case, for the case of autogroup, the behaviour has always been,
> autogroups came quite late.
This ("the behavior has always been") isn't quite true. Yes, group
scheduling has been around since Linux 2.6.24, but in terms of the
semantics of the thread nice value, there was no visible change
then, *unless* explicit action was taken to create cgroups.
The arrival of autogroups in Linux 2.6.38 was different.
With this feature enabled (which is the default), task
groups were implicitly created *without the user needing to
do anything*. Thus, [two terminal windows] == [two task groups]
and in those two terminal windows, nice(1) on a CPU-bound
command in one terminal did nothing in terms of improving
CPU access for a CPU-bound tasks running on the other terminal
window.
Put more succinctly: in Linux 2.6.38, autogrouping broke nice(1)
for many use cases.
Once I came to that simple summary it was easy to find multiple
reports of problems from users:
http://serverfault.com/questions/405092/nice-level-not-working-on-linux
http://superuser.com/questions/805599/nice-has-no-effect-in-linux-unless-the-same-shell-is-used
https://www.reddit.com/r/linux/comments/1c4jew/nice_has_no_effect/
http://stackoverflow.com/questions/10342470/process-niceness-priority-setting-has-no-effect-on-linux
Someone else quickly pointed out to me another such report:
https://bbs.archlinux.org/viewtopic.php?id=149553
And when I quickly surveyed a few more or less savvy Linux users
in one room, most understood what nice does, but none of them knew
about the behavior change wrought by autogroup.
I haven't looked at all of the mails in the old threads that
discussed the implementation of this feature, but so far none of
those that I saw mentioned this behavior change. It's unfortunate
that it never even got documented.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [RFC PATCH] crypto: Add IV generation algorithms
On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote: > > Thank you for the reply. The dm-crypt changes are also included as > part of this patchset. It has been tested for functionality as well. > More information can be found in the cover letter including the test > procedure etc. > > https://lkml.org/lkml/2016/11/21/168 Sorry, I don't know how I missed that :) But that begs the question, who is supposed to use crypto_geniv_set_ctx? I thought it was dm-crypt but your patch doesn't contain any uses of it at all. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V4] i2c: mux: pca954x: Add ACPI support for pca954x
On 2016-11-29 08:04, Tin Huynh wrote:
> This patch enables ACPI support for mux-pca954x driver.
>
> Signed-off-by: Tin Huynh
>
> Change from v1 :
> -Don't shadow id variable.
> -Include sorted header.
> -Redefine acpi_device_id.
> -Add CONFIG_ACPI.
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.c | 27 ++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> Change from V3:
> -Readd CONFIG_ACPI.
>
> Change from V2:
> -Remove CONFIG_ACPI.
>
> Change from V1 :
> -Don't shadow id variable.
> -Include sorted header.
> -Redefine acpi_device_id.
> -Add CONFIG_ACPI.
>
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index 1091346..bdf4315 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -35,6 +35,7 @@
> * warranty of any kind, whether express or implied.
> */
>
> +#include
> #include
> #include
> #include
> @@ -120,6 +121,21 @@ struct pca954x {
> };
> MODULE_DEVICE_TABLE(i2c, pca954x_id);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id pca954x_acpi_ids[] = {
> + { .id = "PCA9540", .driver_data = pca_9540 },
> + { .id = "PCA9542", .driver_data = pca_9540 },
> + { .id = "PCA9543", .driver_data = pca_9543 },
> + { .id = "PCA9544", .driver_data = pca_9544 },
> + { .id = "PCA9545", .driver_data = pca_9545 },
> + { .id = "PCA9546", .driver_data = pca_9545 },
> + { .id = "PCA9547", .driver_data = pca_9547 },
> + { .id = "PCA9548", .driver_data = pca_9548 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, pca954x_acpi_ids);
> +#endif
> +
> #ifdef CONFIG_OF
> static const struct of_device_id pca954x_of_match[] = {
> { .compatible = "nxp,pca9540", .data = &chips[pca_9540] },
> @@ -245,8 +261,16 @@ static int pca954x_probe(struct i2c_client *client,
> match = of_match_device(of_match_ptr(pca954x_of_match), &client->dev);
> if (match)
> data->chip = of_device_get_match_data(&client->dev);
> - else
> + else if (id)
> data->chip = &chips[id->driver_data];
> + else {
> + const struct acpi_device_id *acpi_id;
> +
> + acpi_id = acpi_match_device(pca954x_acpi_ids, &client->dev);
You missed my note about this line in the v4 review, you need to use
ACPI_PTR(pca954x_acpi_ids) here as well (instead of #ifdef-ing the
whole block as you did in v3).
Cheers,
Peter
> + if (!acpi_id)
> + return -ENODEV;
> + data->chip = &chips[acpi_id->driver_data];
> + }
>
> data->last_chan = 0; /* force the first selection */
>
> @@ -321,6 +345,7 @@ static int pca954x_resume(struct device *dev)
> .name = "pca954x",
> .pm = &pca954x_pm,
> .of_match_table = of_match_ptr(pca954x_of_match),
> + .acpi_match_table = ACPI_PTR(pca954x_acpi_ids),
> },
> .probe = pca954x_probe,
> .remove = pca954x_remove,
>
Re: [PATCH V3] i2c: mux: pca954x: Add ACPI support for pca954x
Hi!
We're apparently misunderstanding each other, I meant only that last
#ifdef in the v2 review... Sorry for not being clearer, new attempt
below.
Cheers,
Peter
On 2016-11-29 04:46, tnhu...@apm.com wrote:
> From: Tin Huynh
>
> This patch enables ACPI support for mux-pca954x driver.
>
> Signed-off-by: Tin Huynh
>
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.c | 25 -
> 1 files changed, 24 insertions(+), 1 deletions(-)
>
> Change from V2:
> -Remove CONFIG_ACPI.
>
> Change from V1:
> -Don't shadow id variable.
> -Include sorted header.
> -Redefine acpi_device_id.
> -Add CONFIG_ACPI.
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index 1091346..f80191e 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -35,6 +35,7 @@
> * warranty of any kind, whether express or implied.
> */
>
> +#include
> #include
> #include
> #include
> @@ -120,6 +121,19 @@ struct pca954x {
> };
> MODULE_DEVICE_TABLE(i2c, pca954x_id);
>
#ifdef CONFIG_ACPI
> +static const struct acpi_device_id pca954x_acpi_ids[] = {
> + { .id = "PCA9540", .driver_data = pca_9540 },
> + { .id = "PCA9542", .driver_data = pca_9540 },
> + { .id = "PCA9543", .driver_data = pca_9543 },
> + { .id = "PCA9544", .driver_data = pca_9544 },
> + { .id = "PCA9545", .driver_data = pca_9545 },
> + { .id = "PCA9546", .driver_data = pca_9545 },
> + { .id = "PCA9547", .driver_data = pca_9547 },
> + { .id = "PCA9548", .driver_data = pca_9548 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, pca954x_acpi_ids);
#endif
> +
> #ifdef CONFIG_OF
> static const struct of_device_id pca954x_of_match[] = {
> { .compatible = "nxp,pca9540", .data = &chips[pca_9540] },
> @@ -245,8 +259,16 @@ static int pca954x_probe(struct i2c_client *client,
> match = of_match_device(of_match_ptr(pca954x_of_match), &client->dev);
> if (match)
> data->chip = of_device_get_match_data(&client->dev);
> - else
> + else if (id)
> data->chip = &chips[id->driver_data];
> + else {
> + const struct acpi_device_id *acpi_id;
> +
> + acpi_id = acpi_match_device(pca954x_acpi_ids, &client->dev);
acpi_id = acpi_match_device(ACPI_PTR(pca954x_acpi_ids),
&client->dev);
> + if (!acpi_id)
> + return -ENODEV;
> + data->chip = &chips[acpi_id->driver_data];
> + }
>
> data->last_chan = 0; /* force the first selection */
>
> @@ -321,6 +343,7 @@ static int pca954x_resume(struct device *dev)
> .name = "pca954x",
> .pm = &pca954x_pm,
> .of_match_table = of_match_ptr(pca954x_of_match),
> + .acpi_match_table = ACPI_PTR(pca954x_acpi_ids),
> },
> .probe = pca954x_probe,
> .remove = pca954x_remove,
>
Re: [PATCH 7/7] trace: Update documentation for mono, mono_raw and boot clock
* John Stultz wrote: > + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the > + fast monotonic clock, but also accounts for time spent in > + suspend. Since the clock access is designed for use in > + tracing in the suspend path, some side effects are possible > + if clock is accessed after the suspend time is accounted before > + the fast mono clock is updated. In this case, the clock update > + appears to happen slightly sooner than it normally would have. > + Also on 32-bit systems, its possible that the 64-bit boot offset > + sees a partial update. These effects are rare and post > + processing should be able to handle them. See comments on > + ktime_get_boot_fast_ns function for more information. s/its possible/it's possible s/comments on ktime_get_boost_fast_ns function/comments in the ktime_get_boost_fast_ns() function Thanks, Ingo
Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg
On Mon 28-11-16 12:19:07, Tejun Heo wrote: > Hello, > > On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote: > > > You'd certainly _hope_ that atomic allocations either have fallbacks > > > or are harmless if they fail, but I'd still rather see that > > > __GFP_NOWARN just to make that very much explicit. > > > > A global change to GFP_NOWAIT would of course mean that we should audit its > > users (there don't seem to be many), whether they are using it consciously > > and should not rather be using GFP_ATOMIC. > > A while ago, I thought about something like, say, GFP_MAYBE which is > combination of NOWAIT and NOWARN but couldn't really come up with > scenarios where one would want to use NOWAIT w/o NOWARN. If an > allocation is important enough to warn the user of its failure, it > better be dipping into the atomic reserve pool; otherwise, it doesn't > make sense to make noise. I do not think we really need a new flag for that and fully agree that GFP_NOWAIT warning about failure is rarely, if ever, useful. Historically we didn't use to distinguish atomic (with access to reserves) allocations from those which just do not want to trigger the reclaim resp. to sleep (aka optimistic allocation requests). But this has changed so I guess we can really do the following diff --git a/include/linux/gfp.h b/include/linux/gfp.h index f8041f9de31e..a53b5187b4da 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -246,7 +246,7 @@ struct vm_area_struct; #define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM) #define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS) #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT) -#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM) +#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM|__GFP_NOWARN) #define GFP_NOIO (__GFP_RECLAIM) #define GFP_NOFS (__GFP_RECLAIM | __GFP_IO) #define GFP_TEMPORARY (__GFP_RECLAIM | __GFP_IO | __GFP_FS | \ this will not catch users who are doing gfp & ~__GFP_DIRECT_RECLAIM but I would rather not make warn_alloc() even more cluttered with checks. -- Michal Hocko SUSE Labs
Re: [PATCH 4/7] time: alarmtimer: Add the tracepoints for alarmtimer
* John Stultz wrote: > From: Baolin Wang > > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. s/one alarm timer/an alarm timer > For example, when we debug the system supend/resume, if the > system is always resumed by RTC alarm, we can find out which > process set the alarm timer to resume system by below trace log: s/when we debug the system/when we debug system s/supend/suspend s/resume system/resume the system s/by below trace log/by the trace log below > From the trace log, we can find out the 'Binder:3292_2' process > set one alarm timer which resumes the system. s/set one alarm timer/set an alarm timer > Changes since v4: > - Initialize 'type' to -1 and rename it in alarmtimer_suspend(). > - Fix typo in subject line. > > Changes since v3: > - Remove the "ALARM_" prefix in the string. > - Add the ACK by Steven Rostedt. > > Changes since v2: > - Save time as s64 type. > - Remove 'process_name' parameter and add 'now' parameter. > - Rename the trace event name. > - Remove restart trace event. > - Other optimization. I find it really sad that a patch that has gone through 4 iterations still has so many typos and grammar errors in its changelog :-( Thanks, Ingo
Re: [PATCH 2/7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled
* John Stultz wrote:
> From: Chen Yu
>
> Previously we encountered some memory overflow issues due to
> the bogus sleep time brought by inconsistent rtc, which is
> triggered when pm_trace is enabled, and we have fixed it
> in recent kernel. However it's improper in the first place
> to call __timekeeping_inject_sleeptime() in case that pm_trace
> is enabled simply because that "hash" time value will wreckage
> the timekeeping subsystem.
s/
Previously we encountered memory overflow issues due to
bogus sleep time brought by an inconsistent RTC, which is
triggered when pm_trace is enabled, and we have fixed it
in recent kernels. However it's improper in the first place
to call __timekeeping_inject_sleeptime() in case pm_trace
is enabled simply because the "hash" time value will wreckage
the timekeeping subsystem.
Half a dozen typos ...
> This patch is originally written by Thomas, which would bypass
> the bogus rtc interval when pm_trace is enabled.
> Meanwhile, if system succeed to resume back with pm_trace set, the
> users are warned to adjust the bogus rtc either by 'ntpdate' or
> 'rdate', by resetting pm_trace_rtc_abused to false, otherwise above
> tools might not work as expected.
s/
This patch was originally written by Thomas, which would bypass
the bogus RTC interval when pm_trace is enabled.
Meanwhile, if the system succeeds to resume back with pm_trace set,
users are warned to adjust the bogus RTC either by 'ntpdate' or
'rdate', by resetting pm_trace_rtc_abused to false, otherwise above
tools might not work as expected.
> + /*
> + * If pm_trace abused the RTC as storage set the timespec to 0
> + * which tells the caller that this RTC value is bogus.
> + */
s/
/*
* If pm_trace abused the RTC as storage, set the timespec to 0,
* which tells the caller that this RTC value is bogus.
*/
> @@ -74,6 +75,9 @@
>
> #define DEVSEED (7919)
>
> +bool pm_trace_rtc_abused __read_mostly;
> +EXPORT_SYMBOL(pm_trace_rtc_abused);
EXPORT_SYMBOL_GPL()
> +static int pm_trace_notify(struct notifier_block *nb,
> + unsigned long mode, void *_unused)
Please no nonsensical linebreaks in the middle of an argument list.
> +{
> + switch (mode) {
> + case PM_POST_HIBERNATION:
> + case PM_POST_SUSPEND:
> + if (pm_trace_rtc_abused) {
> + pm_trace_rtc_abused = false;
> + pr_warn("Possible incorrect RTC due to pm_trace, please
> use 'ntpdate' or 'rdate' to reset.\n");
s/to reset./to reset it.
Thanks,
Ingo
[tip:x86/urgent] tools/decode_stacktrace.sh: Fix address line detection on x86
Commit-ID: 8e8d8725d46d93ceffd3e708d905bc101a1905b5
Gitweb: http://git.kernel.org/tip/8e8d8725d46d93ceffd3e708d905bc101a1905b5
Author: Josh Poimboeuf
AuthorDate: Mon, 28 Nov 2016 17:06:35 -0600
Committer: Ingo Molnar
CommitDate: Tue, 29 Nov 2016 08:10:05 +0100
tools/decode_stacktrace.sh: Fix address line detection on x86
Kirill reported that the decode_stacktrace.sh script was broken by the
following commit:
bb5e5ce545f2 ("x86/dumpstack: Remove kernel text addresses from stack dump")
Fix it by updating the per-line absolute address check to also check for
function-based address lines like the following:
write_sysrq_trigger+0x51/0x60
I didn't remove the check for absolute addresses because it's still
needed for ARM.
Reported-by: Kirill A. Shutemov
Tested-by: Kirill A. Shutemov
Signed-off-by: Josh Poimboeuf
Cc: Konstantin Khlebnikov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Thomas Gleixner
Fixes: bb5e5ce545f2 ("x86/dumpstack: Remove kernel text addresses from stack
dump")
Link: http://lkml.kernel.org/r/20161128230635.4n2ofgawltgexgcg@treble
Signed-off-by: Ingo Molnar
---
scripts/decode_stacktrace.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index c332684..5206d99 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -139,7 +139,8 @@ handle_line() {
while read line; do
# Let's see if we have an address in the line
- if [[ $line =~ \[\<([^]]+)\>\] ]]; then
+ if [[ $line =~ \[\<([^]]+)\>\] ]] ||
+ [[ $line =~ [^+\ ]+\+0x[0-9a-f]+/0x[0-9a-f]+ ]]; then
# Translate address to line numbers
handle_line "$line"
# Is it a code line?
Re: [PATCH] tty: nozomi: avoid sprintf buffer overflow
On 11/28/2016, 10:04 PM, Arnd Bergmann wrote:
> Testing with a gcc-7 snapshot produced an internal compiler error
> for this file:
>
> drivers/tty/nozomi.c: In function 'receive_flow_control':
> drivers/tty/nozomi.c:919:12: internal compiler error: in
> get_substring_ranges_for_loc, at input.c:1388
> static int receive_flow_control(struct nozomi *dc)
>
> I've reported this at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78569
> but also noticed that the code line contains a stack overflow, as it prints
> a string into a slightly shorter fixed-length 'tmp' variable.
>
> I don't see any point in the temporary variable, we can simply use
> pr_debug() to print the output directly. This change should not change
> any of the output but avoids both the stack overflow and the gcc
> crash.
>
> The stack overflow will not happen unless a module load parameter is
> also set to enable the debug messages.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/tty/nozomi.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/nozomi.c b/drivers/tty/nozomi.c
> index e2020a691058..17a182b28d52 100644
> --- a/drivers/tty/nozomi.c
> +++ b/drivers/tty/nozomi.c
> @@ -69,13 +69,8 @@
> #define NOZOMI_DEBUG_LEVEL 0x00
>
> #define P_BUF_SIZE 128
> -#define NFO(_err_flag_, args...) \
> -do { \
> - char tmp[P_BUF_SIZE]; \
> - snprintf(tmp, sizeof(tmp), ##args); \
> - printk(_err_flag_ "[%d] %s(): %s\n", __LINE__, \
> - __func__, tmp); \
> -} while (0)
> +#define NFO(_err_flag_, fmt, args...)
> \
> + pr_debug("[%d] %s(): " fmt "\n", __LINE__, __func__, ##args);
Could you also kill the now unused _err_flag_ parameter (including the
only user of NFO)?
(Or inline pr_debug directly into the only user and kill NFO completely?)
thanks,
--
js
suse labs
Re: [PATCH 4/4] thermal/intel_powerclamp: stop sched tick in forced idle
On Tue, 29 Nov 2016 07:21:14 +0800 kbuild test robot wrote: > Hi Jacob, > > [auto build test ERROR on soc-thermal/next] > [also build test ERROR on v4.9-rc7 next-20161128] > [if your patch is applied to the wrong git tree, please drop us a > note to help improve the system] > This patchset is applicable on top of another patch indicated in the cover letter. (https://lkml.org/lkml/2016/11/28/683) Thanks, Jacob > url: > https://github.com/0day-ci/linux/commits/Jacob-Pan/Misc-enhancements-to-intel_powerclamp/20161129-065523 > base: > https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git > next config: x86_64-randconfig-x015-201648 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the > attached .config to linux build tree make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/thermal/intel_powerclamp.c: In function > 'clamp_idle_injection_func': > >> drivers/thermal/intel_powerclamp.c:448:2: error: implicit > >> declaration of function > >> 'play_idle' [-Werror=implicit-function-declaration] > play_idle(jiffies_to_msecs(w_data->duration_jiffies)); > ^ >cc1: some warnings being treated as errors > > vim +/play_idle +448 drivers/thermal/intel_powerclamp.c > >442smp_mb(); >443} >444 >445if (should_skip) >446goto balance; >447 > > 448 > > play_idle(jiffies_to_msecs(w_data->duration_jiffies)); >449 >450balance: >451if (clamping && w_data->clamping && > cpu_online(w_data->cpu)) > > --- > 0-DAY kernel test infrastructureOpen Source > Technology Center > https://lists.01.org/pipermail/kbuild-all Intel > Corporation [Jacob Pan]
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
* Tim Chen wrote: > > + If unsure say Y here. > > > > If/when other architectures make use of this the Kconfig entry can be moved > > into > > the scheduler Kconfig - but for the time being it can stay in arch/x86/. > > > > Another variant would be to eliminate the Kconfig option altogether and > > make it a > > natural feature of SCHED_MC (like it is in the core scheduler). > > > > I am fine with renaming SCHED_ITMT to SCHED_MC_PRIO. Ok, could you please send a delta patch on top of tip:sched/core that does this and the other improvements? Thanks, Ingo
Re: [PATCH v2 10/12] mm: mempolicy: mbind and migrate_pages support thp migration
On Fri, Nov 25, 2016 at 05:57:20PM +0530, Anshuman Khandual wrote:
> On 11/08/2016 05:01 AM, Naoya Horiguchi wrote:
...
> > @@ -497,30 +541,15 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned
> > long addr,
> > struct page *page;
> > struct queue_pages *qp = walk->private;
> > unsigned long flags = qp->flags;
> > - int nid, ret;
> > + int ret;
> > pte_t *pte;
> > spinlock_t *ptl;
> >
> > - if (pmd_trans_huge(*pmd)) {
> > - ptl = pmd_lock(walk->mm, pmd);
> > - if (pmd_trans_huge(*pmd)) {
> > - page = pmd_page(*pmd);
> > - if (is_huge_zero_page(page)) {
> > - spin_unlock(ptl);
> > - __split_huge_pmd(vma, pmd, addr, false, NULL);
> > - } else {
> > - get_page(page);
> > - spin_unlock(ptl);
> > - lock_page(page);
> > - ret = split_huge_page(page);
> > - unlock_page(page);
> > - put_page(page);
> > - if (ret)
> > - return 0;
> > - }
> > - } else {
> > - spin_unlock(ptl);
> > - }
> > + ptl = pmd_trans_huge_lock(pmd, vma);
> > + if (ptl) {
> > + ret = queue_pages_pmd(pmd, ptl, addr, end, walk);
> > + if (ret)
> > + return 0;
> > }
>
> I wonder if we should introduce pte_entry function along with pmd_entry
> function as we are first looking for trans huge PMDs either for direct
> addition into the migration list or splitting it before looking for PTEs.
Most of pagewalk users don't define pte_entry because of performance reason
(to avoid the overhead of PTRS_PER_PMD function calls).
But that could be a nice cleanup if we have a workaround.
Thanks,
Naoya Horiguchi
Re: linux-next: build failure after merge of the crypto tree
On Tue, Nov 29, 2016 at 11:55:29AM +1100, Stephen Rothwell wrote:
> Hi Herbert,
>
> After merging the crypto tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> ERROR: "simd_skcipher_free" [arch/arm/crypto/aes-arm-ce.ko] undefined!
> ERROR: "simd_skcipher_create_compat" [arch/arm/crypto/aes-arm-ce.ko]
> undefined!
> ERROR: "simd_skcipher_free" [arch/arm/crypto/aes-arm-bs.ko] undefined!
> ERROR: "simd_skcipher_create_compat" [arch/arm/crypto/aes-arm-bs.ko]
> undefined!
>
> Caused by commits
>
> da40e7a4ba4d ("crypto: aes-ce - Convert to skcipher")
> 211f41af534a ("crypto: aesbs - Convert to skcipher")
>
> Missing dependencies?
>
> I have used the crypto tree from next-20161128 for today.
Indeed. This patch should fix the problem.
---8<---
Subject: crypto: arm/aes - Select SIMD in Kconfig
The skcipher conversion for ARM missed the select on CRYPTO_SIMD,
causing build failures if SIMD was not otherwise enabled.
Fixes: da40e7a4ba4d ("crypto: aes-ce - Convert to skcipher")
Fixes: 211f41af534a ("crypto: aesbs - Convert to skcipher")
Reported-by: Stephen Rothwell
Signed-off-by: Herbert Xu
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 27ed1b1..8134888 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -105,7 +105,7 @@ config CRYPTO_AES_ARM_CE
tristate "Accelerated AES using ARMv8 Crypto Extensions"
depends on KERNEL_MODE_NEON
select CRYPTO_ALGAPI
- select CRYPTO_ABLK_HELPER
+ select CRYPTO_SIMD
help
Use an implementation of AES in CBC, CTR and XTS modes that uses
ARMv8 Crypto Extensions
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 5f4a617..c5ce39c 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -48,14 +48,14 @@ config CRYPTO_AES_ARM64_CE_BLK
depends on ARM64 && KERNEL_MODE_NEON
select CRYPTO_BLKCIPHER
select CRYPTO_AES_ARM64_CE
- select CRYPTO_ABLK_HELPER
+ select CRYPTO_SIMD
config CRYPTO_AES_ARM64_NEON_BLK
tristate "AES in ECB/CBC/CTR/XTS modes using NEON instructions"
depends on ARM64 && KERNEL_MODE_NEON
select CRYPTO_BLKCIPHER
select CRYPTO_AES
- select CRYPTO_ABLK_HELPER
+ select CRYPTO_SIMD
config CRYPTO_CRC32_ARM64
tristate "CRC32 and CRC32C using optional ARMv8 instructions"
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH V4] i2c: mux: pca954x: Add ACPI support for pca954x
This patch enables ACPI support for mux-pca954x driver.
Signed-off-by: Tin Huynh
Change from v1 :
-Don't shadow id variable.
-Include sorted header.
-Redefine acpi_device_id.
-Add CONFIG_ACPI.
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
Change from V3:
-Readd CONFIG_ACPI.
Change from V2:
-Remove CONFIG_ACPI.
Change from V1 :
-Don't shadow id variable.
-Include sorted header.
-Redefine acpi_device_id.
-Add CONFIG_ACPI.
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 1091346..bdf4315 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -35,6 +35,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -120,6 +121,21 @@ struct pca954x {
};
MODULE_DEVICE_TABLE(i2c, pca954x_id);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id pca954x_acpi_ids[] = {
+ { .id = "PCA9540", .driver_data = pca_9540 },
+ { .id = "PCA9542", .driver_data = pca_9540 },
+ { .id = "PCA9543", .driver_data = pca_9543 },
+ { .id = "PCA9544", .driver_data = pca_9544 },
+ { .id = "PCA9545", .driver_data = pca_9545 },
+ { .id = "PCA9546", .driver_data = pca_9545 },
+ { .id = "PCA9547", .driver_data = pca_9547 },
+ { .id = "PCA9548", .driver_data = pca_9548 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, pca954x_acpi_ids);
+#endif
+
#ifdef CONFIG_OF
static const struct of_device_id pca954x_of_match[] = {
{ .compatible = "nxp,pca9540", .data = &chips[pca_9540] },
@@ -245,8 +261,16 @@ static int pca954x_probe(struct i2c_client *client,
match = of_match_device(of_match_ptr(pca954x_of_match), &client->dev);
if (match)
data->chip = of_device_get_match_data(&client->dev);
- else
+ else if (id)
data->chip = &chips[id->driver_data];
+ else {
+ const struct acpi_device_id *acpi_id;
+
+ acpi_id = acpi_match_device(pca954x_acpi_ids, &client->dev);
+ if (!acpi_id)
+ return -ENODEV;
+ data->chip = &chips[acpi_id->driver_data];
+ }
data->last_chan = 0; /* force the first selection */
@@ -321,6 +345,7 @@ static int pca954x_resume(struct device *dev)
.name = "pca954x",
.pm = &pca954x_pm,
.of_match_table = of_match_ptr(pca954x_of_match),
+ .acpi_match_table = ACPI_PTR(pca954x_acpi_ids),
},
.probe = pca954x_probe,
.remove = pca954x_remove,
--
1.7.1
[PATCH v5 2/2] idle: add support for tasks that inject idle
From: Peter Zijlstra
Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use
realtime tasks to take control of CPU then inject idle. There are two
issues with this approach:
1. Low efficiency: injected idle task is treated as busy so sched ticks
do not stop during injected idle period, the result of these
unwanted wakeups can be ~20% loss in power savings.
2. Idle accounting: injected idle time is presented to user as busy.
This patch addresses the issues by introducing a new PF_IDLE flag which
allows any given task to be treated as idle task while the flag is set.
Therefore, idle injection tasks can run through the normal flow of NOHZ
idle enter/exit to get the correct accounting as well as tick stop when
possible.
The implication is that idle task is then no longer limited to PID == 0.
Acked-by: Ingo Molnar
Signed-off-by: Peter Zijlstra
Signed-off-by: Jacob Pan
---
include/linux/cpu.h | 2 +
include/linux/sched.h | 3 +-
kernel/fork.c | 2 +-
kernel/sched/core.c | 1 +
kernel/sched/idle.c | 162 +++---
5 files changed, 107 insertions(+), 63 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index b886dc1..ac0efae 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -245,6 +245,8 @@ static inline void enable_nonboot_cpus(void) {}
int cpu_report_state(int cpu);
int cpu_check_up_prepare(int cpu);
void cpu_set_state_online(int cpu);
+void play_idle(unsigned long duration_ms);
+
#ifdef CONFIG_HOTPLUG_CPU
bool cpu_wait_death(unsigned int cpu, int seconds);
bool cpu_report_death(void);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e9c009d..a3d338e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2254,6 +2254,7 @@ static inline cputime_t task_gtime(struct task_struct *t)
/*
* Per process flags
*/
+#define PF_IDLE0x0002 /* I am an IDLE thread */
#define PF_EXITING 0x0004 /* getting shut down */
#define PF_EXITPIDONE 0x0008 /* pi exit done on shut down */
#define PF_VCPU0x0010 /* I'm a virtual CPU */
@@ -2611,7 +2612,7 @@ extern int sched_setattr(struct task_struct *,
*/
static inline bool is_idle_task(const struct task_struct *p)
{
- return p->pid == 0;
+ return !!(p->flags & PF_IDLE);
}
extern struct task_struct *curr_task(int cpu);
extern void ia64_set_curr_task(int cpu, struct task_struct *p);
diff --git a/kernel/fork.c b/kernel/fork.c
index 997ac1d..a8eb821 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1540,7 +1540,7 @@ static __latent_entropy struct task_struct *copy_process(
goto bad_fork_cleanup_count;
delayacct_tsk_init(p); /* Must remain after dup_task_struct() */
- p->flags &= ~(PF_SUPERPRIV | PF_WQ_WORKER);
+ p->flags &= ~(PF_SUPERPRIV | PF_WQ_WORKER | PF_IDLE);
p->flags |= PF_FORKNOEXEC;
INIT_LIST_HEAD(&p->children);
INIT_LIST_HEAD(&p->sibling);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 154fd68..c95fbcd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5279,6 +5279,7 @@ void init_idle(struct task_struct *idle, int cpu)
__sched_fork(0, idle);
idle->state = TASK_RUNNING;
idle->se.exec_start = sched_clock();
+ idle->flags |= PF_IDLE;
kasan_unpoison_task_stack(idle);
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 513e4df..6a4bae0 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -205,76 +205,65 @@ static void cpuidle_idle_call(void)
*
* Called with polling cleared.
*/
-static void cpu_idle_loop(void)
+static void do_idle(void)
{
- int cpu = smp_processor_id();
-
- while (1) {
- /*
-* If the arch has a polling bit, we maintain an invariant:
-*
-* Our polling bit is clear if we're not scheduled (i.e. if
-* rq->curr != rq->idle). This means that, if rq->idle has
-* the polling bit set, then setting need_resched is
-* guaranteed to cause the cpu to reschedule.
-*/
-
- __current_set_polling();
- quiet_vmstat();
- tick_nohz_idle_enter();
+ /*
+* If the arch has a polling bit, we maintain an invariant:
+*
+* Our polling bit is clear if we're not scheduled (i.e. if rq->curr !=
+* rq->idle). This means that, if rq->idle has the polling bit set,
+* then setting need_resched is guaranteed to cause the CPU to
+* reschedule.
+*/
- while (!need_resched()) {
- check_pgt_cache();
- rmb();
+ __current_set_polling();
+ tick_nohz_idle_enter();
- if (cpu_is_offline(cpu)) {
- cpuhp_report_idle_dead();
-
AMD Bulldozer topology regression since 4.6
Hello
Since Linux 4.6 (and still in 4.9-rc5 at least), both AMD Bulldozer
cores of a single dual-core compute unit report the same core_id:
$ cat /sys/devices/system/cpu/cpu{?,??}/topology/core_id
0
0
1
1
2
2
3
0
3
[...]
Before 4.5 (and for a very long time), the kernel reported different
core_ids:
0
1
2
3
4
5
6
7
0
[...]
This causes user-space tools (at least all that rely on hwloc for
topology discovery) to think the processor has dual-threaded cores
instead of dual-core compute-unit modules.
The cause is likely this patch, which seems to assume both cores of a
same compute-unit have the same ID, which is wrong?
commit 8196dab4fc159943df6baaac04973bb1accb7100
Author: Borislav Petkov
Date: Fri Mar 25 15:52:36 2016 +0100
x86/cpu: Get rid of compute_unit_id
It is cpu_core_id anyway.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1458917557-8757-3-git-send-email...@alien8.de
Signed-off-by: Thomas Gleixner
Thanks
Brice
[PATCH v5 1/2] cpuidle: allow setting deepest idle
When idle injection is used to cap power, we need to override
governor's choice of idle states. This patch allows caller to select
the deepest idle state on a CPU therefore achieve the maximum
potential power saving.
Signed-off-by: Jacob Pan
---
drivers/cpuidle/cpuidle.c | 13 -
include/linux/cpuidle.h | 7 ++-
kernel/sched/idle.c | 13 -
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c73207a..afc005b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -97,7 +97,17 @@ static int find_deepest_state(struct cpuidle_driver *drv,
return ret;
}
-#ifdef CONFIG_SUSPEND
+/* Set the current cpu to use the deepest idle state, override governors */
+void cpuidle_use_deepest_state(bool enable)
+{
+ struct cpuidle_device *dev;
+
+ preempt_disable();
+ dev = cpuidle_get_device();
+ dev->use_deepest_state = enable;
+ preempt_enable();
+}
+
/**
* cpuidle_find_deepest_state - Find the deepest available idle state.
* @drv: cpuidle driver for the given CPU.
@@ -109,6 +119,7 @@ int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
return find_deepest_state(drv, dev, UINT_MAX, 0, false);
}
+#ifdef CONFIG_SUSPEND
static void enter_freeze_proper(struct cpuidle_driver *drv,
struct cpuidle_device *dev, int index)
{
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index bb31373..63bf385 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -74,6 +74,7 @@ struct cpuidle_state {
struct cpuidle_device {
unsigned intregistered:1;
unsigned intenabled:1;
+ unsigned intuse_deepest_state:1;
unsigned intcpu;
int last_residency;
@@ -192,11 +193,12 @@ static inline struct cpuidle_driver
*cpuidle_get_cpu_driver(
static inline struct cpuidle_device *cpuidle_get_device(void) {return NULL; }
#endif
-#if defined(CONFIG_CPU_IDLE) && defined(CONFIG_SUSPEND)
+#ifdef CONFIG_CPU_IDLE
extern int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
struct cpuidle_device *dev);
extern int cpuidle_enter_freeze(struct cpuidle_driver *drv,
struct cpuidle_device *dev);
+extern void cpuidle_use_deepest_state(bool enable);
#else
static inline int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
struct cpuidle_device *dev)
@@ -204,6 +206,9 @@ static inline int cpuidle_find_deepest_state(struct
cpuidle_driver *drv,
static inline int cpuidle_enter_freeze(struct cpuidle_driver *drv,
struct cpuidle_device *dev)
{return -ENODEV; }
+static inline void cpuidle_use_deepest_state(bool enable)
+{
+}
#endif
/* kernel/sched/idle.c */
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 1d8718d..513e4df 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -164,11 +164,14 @@ static void cpuidle_idle_call(void)
* timekeeping to prevent timer interrupts from kicking us out of idle
* until a proper wakeup interrupt happens.
*/
- if (idle_should_freeze()) {
- entered_state = cpuidle_enter_freeze(drv, dev);
- if (entered_state > 0) {
- local_irq_enable();
- goto exit_idle;
+
+ if (idle_should_freeze() || dev->use_deepest_state) {
+ if (idle_should_freeze()) {
+ entered_state = cpuidle_enter_freeze(drv, dev);
+ if (entered_state > 0) {
+ local_irq_enable();
+ goto exit_idle;
+ }
}
next_state = cpuidle_find_deepest_state(drv, dev);
--
1.9.1
[PATCH v5 0/2] Stop sched tick in idle injection task
Changelog: v5: - Fix compile error in cpuidle patch reported by 0-day. - Reverse patch order for correct dependency. v4: - Misc comments from Ingo are addressed, including style fix, timeout handling, fork(). - Dropped powerclamp patch from this set, move to its own series. v3: - Rearrange idle.c change based on Rafael's suggestion. v2: - Moved duration timer from powerclamp driver to play_idle() - Unexport cpuidle_use_deepest_state - Indentation fix Idle injection drivers today use RT threads to run idle loop. There are efficiency and accounting issues with the current intel_powerclamp.c and acpi_pad.c. A while ago, I posted CFS based idle injection patch trying to address them: https://lkml.org/lkml/2015/11/13/576 Peter proposed another approach with the introduction of a PF_IDLE flag. This patchset is based on his original posting: https://lkml.org/lkml/2014/6/4/56 These patches apply on top of the kworker and cpu hotplug state machine changes made to Intel powerclamp driver. https://lkml.org/lkml/2016/10/17/362 Similar changes to ACPI PAD driver is developed along with other enhancements. It will be posted after this patchset is accepted. Jacob Pan (1): cpuidle: allow setting deepest idle Peter Zijlstra (1): idle: add support for tasks that inject idle drivers/cpuidle/cpuidle.c | 13 +++- include/linux/cpu.h | 2 + include/linux/cpuidle.h | 7 +- include/linux/sched.h | 3 +- kernel/fork.c | 2 +- kernel/sched/core.c | 1 + kernel/sched/idle.c | 175 +- 7 files changed, 133 insertions(+), 70 deletions(-) -- 1.9.1
Re: Re: [PATCH] Input: joystick: adi - change msleep to usleep_range for small msecs
On Mon, Nov 28, 2016 at 01:49:31PM +, Aniroop Mathur wrote:
> Hello Mr. Vojtech Pavlik,
>
> On 28 Nov 2016 17:23, "vojt...@ucw.cz" wrote:
> >
> > Hi.
> >
> > ADI_INIT_DELAY/ADI_DATA_DELAY doesn't have to be exact, and a longer
> > sleep doesn't matter. In the initilization sequence - first chunk of
> > your patch - a way too long delay could in theory make the device fail
> > to initialize. What's critical is that the mdelay() calls are precise.
> >
> > One day I'll open my box of old joystick and re-test these drivers to
> > see if they survived the years of kernel infrastructure updates ...
> >
> > Vojtech
> >
>
> Well, it seems to me that there is some kind of confusion, so I'd like to
> clarify things about this patch.
> As you have mentioned that in the initialization sequence, long delay could
> in theory make the device fail to initialize - This patch actually solves
> this problem.
> msleep is built on jiffies / legacy timers and usleep_range is built on top
> of hrtimers so the wakeup will be precise.
> Source - https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
>
> For example in initialization sequence, if we use msleep(4), then the process
> could sleep for much more than 4 ms, say 6 ms or 10 ms or more depending on
> machine architecture. Like on a machine with tick rate / HZ is defined to be
> 100 so msleep(4) will make the process to sleep for minimum 10 ms.
> Whereas usleep_range(4000, 4100) will make sure that the process do not sleep
> for more than 4100 us or 4.1 ms. So usleep_range is precise but msleep is
> not.
>
> Originally, I added you in this patch to request you if you could help to
> test this patch or provide contact points of individuals who could help
> to test this patch as we do not have the hardware available with us?
> Like this driver, we also need to test other joystick drivers as well like
> gf2k.c, analog.c, sidewinder.c and gameport driver ns558.c as all have
> similar problem.
> Original patch link - https://patchwork.kernel.org/patch/9446201/
> As we do not have hardware available, so we decided to split patch into
> individual drivers and request to person who could support to test this patch
>
> I have also applied the same patch in our driver whose hardware is available
> with me and I found that wake up time became precise indeed and so I
> decided to apply the same fix in other input subsystem drivers as well.
I do understand what you're trying to achieve. Both ADI_DATA_DELAY and
ADI_INIT_DELAY are specified as minimum delays. Waiting longer doesn't
cause any trouble, so the patch doesn't need to change that.
In the initialization sequence, it probably doesn't matter either
whether we wait longer, hence the distinction between msleep() and
mdelay() based on positive/negative numbers. The mdelay() needs to be
exact and the msleep() can be longer. How much longer before it disturbs
the init sequence I'm not sure, probably quite a bit.
The driver was written a long time before hrtimers existed and as such
it was written expecting that msleep() can take a longer time.
So your patch is most likely not needed, but I should find an ADI device
and see what happens if I make the sleeps in the init sequence much
longer.
It'd also be interesting to see if the mdelay()s could be replaced with
hrtimer-based delays instead, as that would be nicer to the system - if
they can be precise enough. Also, preemption and maybe interrupts should
be disabled around the mdelays I suppose - that was not an issue when
the drivers were written.
Vojtech
>
> Thank you!
>
> BR,
> Aniroop Mathur
>
> > On Mon, Nov 28, 2016 at 11:43:56AM +, Aniroop Mathur wrote:
> > > msleep(1~20) may not do what the caller intends, and will often sleep
> longer.
> > > (~20 ms actual sleep for any value given in the 1~20ms range)
> > > This is not the desired behaviour for many cases like device resume time,
> > > device suspend time, device enable time, data reading time, etc.
> > > Thus, change msleep to usleep_range for precise wakeups.
> > >
> > > Signed-off-by: Aniroop Mathur
> > > ---
> > > joystick/adi.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/joystick/adi.c b/joystick/adi.c
> > > index d09cefa..6799bd9 100644
> > > --- a/joystick/adi.c
> > > +++ b/joystick/adi.c
> > > @@ -47,8 +47,8 @@ MODULE_LICENSE("GPL");
> > >
> > > #define ADI_MAX_START200 /* Trigger to packet
> timeout [200us] */
> > > #define ADI_MAX_STROBE 40 /* Single bit timeout
> [40us] */
> > > -#define ADI_INIT_DELAY 10 /* Delay after init packet
> [10ms] */
> > > -#define ADI_DATA_DELAY 4 /* Delay after data packet
> [4ms] */
> > > +#define ADI_INIT_DELAY 1 /* Delay after init packet
> [10ms] */
> > > +#define ADI_DATA_DELAY 4000/* Delay after data pack
[PATCH v1 2/4] perf report: Create a new option "--inline"
It takes some time to look for inline stack for callgraph addresses.
So it provides a new option "--inline" to let user decide if enable
this feature.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-report.txt | 4
tools/perf/builtin-report.c | 2 ++
tools/perf/util/symbol.h | 3 ++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 2d17462..f1299a7 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -412,6 +412,10 @@ include::itrace.txt[]
--hierarchy::
Enable hierarchical output.
+--inline::
+ If a callgraph address belongs to an inlined function, the inline stack
+ will be printed.
+
include::callchain-overhead-calculation.txt[]
SEE ALSO
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 3dfbfff..ba2f627 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -830,6 +830,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_CALLBACK_DEFAULT(0, "stdio-color", NULL, "mode",
"'always' (default), 'never' or 'auto' only
applicable to --stdio mode",
stdio__config_color, "always"),
+ OPT_BOOLEAN(0, "inline", &symbol_conf.show_inline,
+ "Show inline functions"),
OPT_END()
};
struct perf_data_file file = {
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 1bcbefc..c312759 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -118,7 +118,8 @@ struct symbol_conf {
show_ref_callgraph,
hide_unresolved,
raw_trace,
- report_hierarchy;
+ report_hierarchy,
+ show_inline;
const char *vmlinux_name,
*kallsyms_name,
*source_prefix,
--
2.7.4
Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding
On 28-11-16, 10:27, Stephen Boyd wrote:
> On 11/23/2016 08:40 PM, Viresh Kumar wrote:
> > But even in these cases we wouldn't be using the voltage values within the
> > kernel as we will be giving only a performance state to the M3 core, right?
>
> Nope. In these cases we need to set a certain voltage and we do that by
> requesting it via the M3 core.
Don't we need something like this then ?
parent: power-controller@1234 {
compatible = "foo,power-controller";
reg = <0x1234 0x1000>;
#power-domain-cells = <0>;
domain-performance-states = <&perf_state0>;
};
perf_state0: performance_states {
pstate1: pstate@1 {
index = <1>;
/* Optional */
microvolt = <97 975000 985000>;
};
pstate2: pstate@2 {
index = <2>;
/* Optional */
microvolt = <97 975000 985000>;
};
pstate3: pstate@3 {
index = <3>;
/* Optional */
microvolt = <97 975000 985000>;
};
}
cpus {
cpu@0 {
...
power-domain = <&parent>;
operating-points-v2 = <&cpu0_opp_table>;
};
};
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp@10 {
opp-hz = /bits/ 64 <10>;
domain-performance-state = <&pstate1>;
};
opp@11 {
opp-hz = /bits/ 64 <11>;
domain-performance-state = <&pstate2>;
};
opp@12 {
opp-hz = /bits/ 64 <12>;
domain-performance-state = <&pstate3>;
};
};
--
viresh
[PATCH v1 3/4] perf report: Show inline stack in stdio mode
If the address belongs to an inlined function, the source information
back to the first non-inlined function will be printed.
For example:
0.05% test2test2 [.] main
|
---/home/jinyao/perf-dev/test/test2.c:27 (inline)
/home/jinyao/perf-dev/test/test2.c:35 (inline)
/home/jinyao/perf-dev/test/test2.c:45 (inline)
/home/jinyao/perf-dev/test/test2.c:61 (inline)
The tag "inline" indicates these items are the entries in inline stack.
Signed-off-by: Jin Yao
---
tools/perf/ui/stdio/hist.c | 56 +-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 668f4ae..e74eda0 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -400,6 +400,53 @@ static size_t hist_entry_callchain__fprintf(struct
hist_entry *he,
return 0;
}
+static size_t hist_entry_inline__fprintf(struct hist_entry *he,
+int left_margin,
+FILE *fp)
+{
+ struct dso *dso;
+ struct inline_node *node;
+ struct inline_list *ilist;
+ int ret = 0, i = 0;
+
+ if (he->ms.map == NULL)
+ return 0;
+
+ dso = he->ms.map->dso;
+ if (dso == NULL)
+ return 0;
+
+ if (dso->kernel != DSO_TYPE_USER)
+ return 0;
+
+ node = get_inline_node(dso, map__rip_2objdump(he->ms.map, he->ip));
+ if (node == NULL)
+ return 0;
+
+ ret += callchain__fprintf_left_margin(fp, left_margin);
+ ret += fprintf(fp, "|\n");
+ ret += callchain__fprintf_left_margin(fp, left_margin);
+ ret += fprintf(fp, "---");
+ left_margin += 3;
+
+ list_for_each_entry(ilist, &node->val, list) {
+ if (ilist->filename != NULL) {
+ if (i++ > 0)
+ ret = callchain__fprintf_left_margin(fp,
+ left_margin);
+ ret += fprintf(fp, "%s:%d (inline)",
+ ilist->filename, ilist->line_nr);
+ ret += fprintf(fp, "\n");
+ }
+ }
+
+ if (i > 0)
+ ret += fprintf(fp, "\n");
+
+ free_inline_node(node);
+ return ret;
+}
+
int __hist_entry__snprintf(struct hist_entry *he, struct perf_hpp *hpp,
struct perf_hpp_list *hpp_list)
{
@@ -529,6 +576,7 @@ static int hist_entry__fprintf(struct hist_entry *he,
size_t size,
bool use_callchain)
{
int ret;
+ int callchain_ret = 0;
struct perf_hpp hpp = {
.buf= bf,
.size = size,
@@ -547,7 +595,13 @@ static int hist_entry__fprintf(struct hist_entry *he,
size_t size,
ret = fprintf(fp, "%s\n", bf);
if (use_callchain)
- ret += hist_entry_callchain__fprintf(he, total_period, 0, fp);
+ callchain_ret = hist_entry_callchain__fprintf(he, total_period,
+ 0, fp);
+
+ if ((callchain_ret == 0) && symbol_conf.show_inline)
+ ret += hist_entry_inline__fprintf(he, 0, fp);
+ else
+ ret += callchain_ret;
return ret;
}
--
2.7.4
[PATCH v1 4/4] perf report: Show inline stack in browser mode
For example:
-0.05% test2test2 [.] main
/home/jinyao/perf-dev/test/test2.c:27 (inline)
/home/jinyao/perf-dev/test/test2.c:35 (inline)
/home/jinyao/perf-dev/test/test2.c:45 (inline)
/home/jinyao/perf-dev/test/test2.c:61 (inline)
Signed-off-by: Jin Yao
---
tools/perf/ui/browsers/hists.c | 98 --
tools/perf/util/hist.c | 5 +++
tools/perf/util/sort.h | 1 +
3 files changed, 100 insertions(+), 4 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 641b402..c8c3cae 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -362,6 +362,46 @@ static void hist_entry__init_have_children(struct
hist_entry *he)
he->init_have_children = true;
}
+static void hist_entry_init_inline_node(struct hist_entry *he)
+{
+ struct dso *dso;
+
+ if (he->inline_node)
+ return;
+
+ if (he->ms.map == NULL)
+ return;
+
+ dso = he->ms.map->dso;
+ if (dso == NULL)
+ return;
+
+ if (dso->kernel != DSO_TYPE_USER)
+ return;
+
+ he->inline_node = get_inline_node(dso,
+ map__rip_2objdump(he->ms.map, he->ip));
+
+ if (he->inline_node == NULL)
+ return;
+
+ he->has_children = true;
+}
+
+static int inline__count_rows(struct hist_entry *he)
+{
+ struct inline_node *node = he->inline_node;
+ struct inline_list *ilist;
+ int i = 0;
+
+ list_for_each_entry(ilist, &node->val, list) {
+ if (ilist->filename != NULL)
+ i++;
+ }
+
+ return i;
+}
+
static bool hist_browser__toggle_fold(struct hist_browser *browser)
{
struct hist_entry *he = browser->he_selection;
@@ -393,7 +433,11 @@ static bool hist_browser__toggle_fold(struct hist_browser
*browser)
if (he->unfolded) {
if (he->leaf)
- he->nr_rows =
callchain__count_rows(&he->sorted_chain);
+ if (he->inline_node)
+ he->nr_rows = inline__count_rows(he);
+ else
+ he->nr_rows = callchain__count_rows(
+ &he->sorted_chain);
else
he->nr_rows = hierarchy_count_rows(browser, he,
false);
@@ -1091,6 +1135,40 @@ static int hist_browser__show_callchain(struct
hist_browser *browser,
return printed;
}
+static int hist_browser__show_inline(struct hist_browser *browser,
+struct hist_entry *entry,
+unsigned short row)
+{
+ struct inline_node *node;
+ struct inline_list *ilist;
+ char buf[1024];
+ int color, width, first_row;
+
+ first_row = row;
+ node = entry->inline_node;
+ width = browser->b.width - (LEVEL_OFFSET_STEP + 2);
+
+ list_for_each_entry(ilist, &node->val, list) {
+ if (ilist->filename != NULL) {
+ color = HE_COLORSET_NORMAL;
+ if (ui_browser__is_current_entry(&browser->b, row))
+ color = HE_COLORSET_SELECTED;
+
+ scnprintf(buf, sizeof(buf), "%s:%d (inline)",
+ ilist->filename, ilist->line_nr);
+
+ ui_browser__set_color(&browser->b, color);
+ hist_browser__gotorc(browser, row, 0);
+ ui_browser__write_nstring(&browser->b, " ",
+ LEVEL_OFFSET_STEP + 2);
+ ui_browser__write_nstring(&browser->b, buf, width);
+ row++;
+ }
+ }
+
+ return row - first_row;
+}
+
struct hpp_arg {
struct ui_browser *b;
char folded_sign;
@@ -1204,6 +1282,11 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
folded_sign = hist_entry__folded(entry);
}
+ if (symbol_conf.show_inline && (!entry->has_children)) {
+ hist_entry_init_inline_node(entry);
+ folded_sign = hist_entry__folded(entry);
+ }
+
if (row_offset == 0) {
struct hpp_arg arg = {
.b = &browser->b,
@@ -1235,7 +1318,8 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
}
if (first) {
- if (symbol_conf.use_callchain) {
+ if (symbol_conf.use_callchain ||
+ symbol_conf.show_inline) {
ui_browser__printf(&browser->b, "%c ",
folded_sign);
width -=
[PATCH v1 0/4] perf report: Show inline stack
It would be useful for perf to support a mode to query the
inline stack for callgraph addresses. This would simplify
finding the right code in code that does a lot of inlining.
For example, the c code:
static inline void f3(void)
{
int i;
for (i = 0; i < 1000;) {
if(i%2)
i++;
else
i++;
}
printf("hello f3\n"); /* D */
}
/* < CALLCHAIN: f2 <- f1 > */
static inline void f2(void)
{
int i;
for (i = 0; i < 100; i++) {
f3(); /* C */
}
}
/* < CALLCHAIN: f1 <- main > */
static inline void f1(void)
{
int i;
for (i = 0; i < 100; i++) {
f2(); /* B */
}
}
/* < CALLCHAIN: main <- TOP > */
int main()
{
struct timeval tv;
time_t start, end;
gettimeofday(&tv, NULL);
start = end = tv.tv_sec;
while((end - start) < 5) {
f1(); /* A */
gettimeofday(&tv, NULL);
end = tv.tv_sec;
}
return 0;
}
The printed inline stack is:
0.05% test2test2 [.] main
|
---/home/perf-dev/lck-2867/test/test2.c:27 (inline)
/home/perf-dev/lck-2867/test/test2.c:35 (inline)
/home/perf-dev/lck-2867/test/test2.c:45 (inline)
/home/perf-dev/lck-2867/test/test2.c:61 (inline)
I tag A/B/C/D in above c code to indicate the source line,
actually the inline stack is equal to:
0.05% test2test2 [.] main
|
---D
C
B
A
Jin Yao (4):
perf report: Find the inline stack for a given address
perf report: Create a new option "--inline"
perf report: Show inline stack in stdio mode
perf report: Show inline stack in browser mode
tools/perf/Documentation/perf-report.txt | 4 +
tools/perf/builtin-report.c | 2 +
tools/perf/ui/browsers/hists.c | 98 ++-
tools/perf/ui/stdio/hist.c | 56 -
tools/perf/util/hist.c | 5 +
tools/perf/util/sort.h | 1 +
tools/perf/util/srcline.c| 206 ++-
tools/perf/util/symbol.h | 3 +-
tools/perf/util/util.h | 15 +++
9 files changed, 356 insertions(+), 34 deletions(-)
--
2.7.4
[PATCH v1 1/4] perf report: Find the inline stack for a given address
It would be useful for perf to support a mode to query the
inline stack for a given callgraph address. This would simplify
finding the right code in code that does a lot of inlining.
The srcline.c has contained the code which supports to translate
the address to filename:line_nr. This patch just extends the
function to let it support getting the inline stacks.
The results (filename:line_nr) would be saved in a list and
returned to the caller.
Signed-off-by: Jin Yao
---
tools/perf/util/srcline.c | 206 +++---
tools/perf/util/util.h| 15
2 files changed, 193 insertions(+), 28 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index b4db3f4..0145625 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -12,6 +12,39 @@
bool srcline_full_filename;
+static const char *dso_name_get(struct dso *dso)
+{
+ const char *dso_name;
+
+ if (dso->symsrc_filename)
+ dso_name = dso->symsrc_filename;
+ else
+ dso_name = dso->long_name;
+
+ if (dso_name[0] == '[')
+ return NULL;
+
+ if (!strncmp(dso_name, "/tmp/perf-", 10))
+ return NULL;
+
+ return dso_name;
+}
+
+static int ilist_apend(char *filename, int line_nr, struct inline_node *node)
+{
+ struct inline_list *ilist;
+
+ ilist = zalloc(sizeof(*ilist));
+ if (ilist == NULL)
+ return -1;
+
+ ilist->filename = filename;
+ ilist->line_nr = line_nr;
+ list_add_tail(&ilist->list, &node->val);
+
+ return 0;
+}
+
#ifdef HAVE_LIBBFD_SUPPORT
/*
@@ -153,7 +186,7 @@ static void addr2line_cleanup(struct a2l_data *a2l)
static int addr2line(const char *dso_name, u64 addr,
char **file, unsigned int *line, struct dso *dso,
-bool unwind_inlines)
+bool unwind_inlines, struct inline_node *node)
{
int ret = 0;
struct a2l_data *a2l = dso->a2l;
@@ -178,8 +211,14 @@ static int addr2line(const char *dso_name, u64 addr,
while (bfd_find_inliner_info(a2l->abfd, &a2l->filename,
&a2l->funcname, &a2l->line) &&
- cnt++ < MAX_INLINE_NEST)
- ;
+ cnt++ < MAX_INLINE_NEST) {
+
+ if (node != NULL) {
+ if (ilist_apend(strdup(a2l->filename),
+ a2l->line, node) != 0)
+ return 0;
+ }
+ }
}
if (a2l->found && a2l->filename) {
@@ -205,18 +244,68 @@ void dso__free_a2l(struct dso *dso)
dso->a2l = NULL;
}
+static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
+ struct dso *dso)
+{
+ char *file = NULL;
+ unsigned int line = 0;
+ struct inline_node *node;
+
+ node = zalloc(sizeof(*node));
+ if (node == NULL) {
+ perror("not enough memory for the inline node");
+ return NULL;
+ }
+
+ INIT_LIST_HEAD(&node->val);
+ node->addr = addr;
+
+ if (!addr2line(dso_name, addr, &file, &line, dso, TRUE, node)) {
+ free_inline_node(node);
+ return NULL;
+ }
+
+ if (list_empty(&node->val)) {
+ free_inline_node(node);
+ return NULL;
+ }
+
+ return node;
+}
+
#else /* HAVE_LIBBFD_SUPPORT */
+static int filename_split(const char *dso_name, char *filename,
+ unsigned int *line_nr)
+{
+ char *sep;
+
+ sep = strchr(filename, '\n');
+ if (sep)
+ *sep = '\0';
+
+ if (!strcmp(filename, "??:0"))
+ return -1;
+
+ sep = strchr(filename, ':');
+ if (sep) {
+ *sep++ = '\0';
+ *line_nr = strtoul(sep, NULL, 0);
+ }
+
+ return 0;
+}
+
static int addr2line(const char *dso_name, u64 addr,
char **file, unsigned int *line_nr,
struct dso *dso __maybe_unused,
-bool unwind_inlines __maybe_unused)
+bool unwind_inlines __maybe_unused,
+struct inline_node *node __maybe_unused)
{
FILE *fp;
char cmd[PATH_MAX];
char *filename = NULL;
size_t len;
- char *sep;
int ret = 0;
scnprintf(cmd, sizeof(cmd), "addr2line -e %s %016"PRIx64,
@@ -233,23 +322,14 @@ static int addr2line(const char *dso_name, u64 addr,
goto out;
}
- sep = strchr(filename, '\n');
- if (sep)
- *sep = '\0';
-
- if (!strcmp(filename, "??:0")) {
- pr_debug("no debugging info in %s\n", dso_name);
+ if (filename_split(dso_name, filename, line_nr) != 0) {
free(filename);
g
Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE
On 11/29/2016 02:42 AM, Dave Hansen wrote:
> On 11/22/2016 06:19 AM, Anshuman Khandual wrote:
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3715,7 +3715,7 @@ struct page *
>> .migratetype = gfpflags_to_migratetype(gfp_mask),
>> };
>>
>> -if (cpusets_enabled()) {
>> +if (cpusets_enabled() && !(alloc_mask & __GFP_THISNODE)) {
>> alloc_mask |= __GFP_HARDWALL;
>> alloc_flags |= ALLOC_CPUSET;
>> if (!ac.nodemask)
>
> This means now that any __GFP_THISNODE allocation can "escape" the
> cpuset. That seems like a pretty major change to how cpusets works. Do
> we know that *ALL* __GFP_THISNODE allocations are truly lacking in a
> cpuset context that can be enforced?
Right, I know its a very blunt change. With the cpuset based isolation
of coherent device node for the user space tasks leads to a side effect
that a driver or even kernel cannot allocate memory from the coherent
device node in the task's own context (ioctl() calls or similar). For
non task context allocation (work queues, interrupts, anything async
etc) this problem can be fixed by modifying kernel thread's task->mems
_allowed to include all nodes of the system including the coherent
device nodes. Though I have not figured out the details yet. Whats
your thoughts on this ? What we are looking for is a explicit and
definite way of allocating from the coherent device node inside the
kernel.
Re: [PATCH] Input: joystick: gf2k - change msleep to usleep_range for small msecs
On Tue, Nov 29, 2016 at 01:11:49AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device suspend time, device enable time, connection time, probe time,
> loops, retry logic, etc
> msleep is built on jiffies / legacy timers which are not precise whereas
> usleep_range is build on top of hrtimers so the wakeups are precise.
> Thus, change msleep to usleep_range for precise wakeups.
>
> For example:
> On a machine with tick rate / HZ as 100, msleep(4) will make the process to
> sleep for a minimum period of 10 ms whereas usleep_range(4000, 4100) will make
> sure that the process does not sleep for more than 4100 us or 4.1ms
And once more, patch not needed.
>
> Signed-off-by: Aniroop Mathur
> ---
> drivers/input/joystick/gf2k.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/joystick/gf2k.c b/drivers/input/joystick/gf2k.c
> index 0f519db..e9d5095 100644
> --- a/drivers/input/joystick/gf2k.c
> +++ b/drivers/input/joystick/gf2k.c
> @@ -42,7 +42,7 @@ MODULE_LICENSE("GPL");
>
> #define GF2K_START 400 /* The time we wait for the first bit
> [400 us] */
> #define GF2K_STROBE 40 /* The time we wait for the first bit
> [40 us] */
> -#define GF2K_TIMEOUT 4 /* Wait for everything to settle [4 ms]
> */
> +#define GF2K_TIMEOUT 4000/* Wait for everything to settle [4000
> us] */
> #define GF2K_LENGTH 80 /* Max number of triplets in a packet */
>
> /*
> @@ -138,7 +138,7 @@ static void gf2k_trigger_seq(struct gameport *gameport,
> short *seq)
> i = 0;
> do {
> gameport_trigger(gameport);
> - t = gameport_time(gameport, GF2K_TIMEOUT * 1000);
> + t = gameport_time(gameport, GF2K_TIMEOUT);
> while ((gameport_read(gameport) & 1) && t) t--;
> udelay(seq[i]);
> } while (seq[++i]);
> @@ -259,11 +259,11 @@ static int gf2k_connect(struct gameport *gameport,
> struct gameport_driver *drv)
>
> gf2k_trigger_seq(gameport, gf2k_seq_reset);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> gf2k_trigger_seq(gameport, gf2k_seq_digital);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> if (gf2k_read_packet(gameport, GF2K_LENGTH, data) < 12) {
> err = -ENODEV;
> --
> 2.6.2
>
--
Vojtech Pavlik
[PATCH] Staging: comedi: cb_pcidda: fixed a comment style issue
Fixed a coding style issue Signed-off-by: Elias Carter --- drivers/staging/comedi/drivers/cb_pcidda.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/cb_pcidda.c b/drivers/staging/comedi/drivers/cb_pcidda.c index ccb37d1..9874147 100644 --- a/drivers/staging/comedi/drivers/cb_pcidda.c +++ b/drivers/staging/comedi/drivers/cb_pcidda.c @@ -248,8 +248,8 @@ static void cb_pcidda_write_caldac(struct comedi_device *dev, cb_pcidda_serial_out(dev, value, num_caldac_bits); /* -* latch stream into appropriate caldac deselect reference dac -*/ + * latch stream into appropriate caldac deselect reference dac + */ cal2_bits = DESELECT_REF_DAC_BIT | DUMMY_BIT; /* deactivate caldacs (one caldac for every two channels) */ for (i = 0; i < max_num_caldacs; i++) -- 2.9.3
Re: [PATCH] Input: joystick: analog - change msleep to usleep_range for small msecs
On Tue, Nov 29, 2016 at 01:11:31AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device suspend time, device enable time, connection time, probe time,
> loops, retry logic, etc
> msleep is built on jiffies / legacy timers which are not precise whereas
> usleep_range is build on top of hrtimers so the wakeups are precise.
> Thus, change msleep to usleep_range for precise wakeups.
>
> For example:
> On a machine with tick rate / HZ as 100, msleep(3) will make the process to
> sleep for a minimum period of 10 ms whereas usleep_range(3000, 3100) will make
> sure that the process does not sleep for more than 3100 us or 3.1ms
Again, not needed, if the MAX_TIME sleeps are longer, nobody cares.
>
> Signed-off-by: Aniroop Mathur
> ---
> drivers/input/joystick/analog.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index 3d8ff09..2891704 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -88,7 +88,7 @@ MODULE_PARM_DESC(map, "Describes analog joysticks
> type/capabilities");
> #define ANALOG_EXTENSIONS0x7ff00
> #define ANALOG_GAMEPAD 0x8
>
> -#define ANALOG_MAX_TIME 3 /* 3 ms */
> +#define ANALOG_MAX_TIME 3000/* 3000 us */
> #define ANALOG_LOOP_TIME 2000/* 2 * loop */
> #define ANALOG_SAITEK_DELAY 200 /* 200 us */
> #define ANALOG_SAITEK_TIME 2000/* 2000 us */
> @@ -257,7 +257,7 @@ static int analog_cooked_read(struct analog_port *port)
> int i, j;
>
> loopout = (ANALOG_LOOP_TIME * port->loop) / 1000;
> - timeout = ANALOG_MAX_TIME * port->speed;
> + timeout = (ANALOG_MAX_TIME / 1000) * port->speed;
>
> local_irq_save(flags);
> gameport_trigger(gameport);
> @@ -625,20 +625,20 @@ static int analog_init_port(struct gameport *gameport,
> struct gameport_driver *d
>
> gameport_trigger(gameport);
> t = gameport_read(gameport);
> - msleep(ANALOG_MAX_TIME);
> + usleep_range(ANALOG_MAX_TIME, ANALOG_MAX_TIME + 100);
> port->mask = (gameport_read(gameport) ^ t) & t & 0xf;
> port->fuzz = (port->speed * ANALOG_FUZZ_MAGIC) / port->loop /
> 1000 + ANALOG_FUZZ_BITS;
>
> for (i = 0; i < ANALOG_INIT_RETRIES; i++) {
> if (!analog_cooked_read(port))
> break;
> - msleep(ANALOG_MAX_TIME);
> + usleep_range(ANALOG_MAX_TIME, ANALOG_MAX_TIME + 100);
> }
>
> u = v = 0;
>
> - msleep(ANALOG_MAX_TIME);
> - t = gameport_time(gameport, ANALOG_MAX_TIME * 1000);
> + usleep_range(ANALOG_MAX_TIME, ANALOG_MAX_TIME + 100);
> + t = gameport_time(gameport, ANALOG_MAX_TIME);
> gameport_trigger(gameport);
> while ((gameport_read(port->gameport) & port->mask) && (u < t))
> u++;
> --
> 2.6.2
>
--
Vojtech Pavlik
Re: [RFC][PATCH 2/5 v2] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:41 John Stultz wrote:
> In chasing down a previous issue with EDID probing from calling
> drm_helper_hpd_irq_event() from irq context, Laurent noticed
> that the DRM documentation suggests that
> drm_kms_helper_hotplug_event() should be used instead.
>
> Thus this patch replaces drm_helper_hpd_irq_event() with
> drm_kms_helper_hotplug_event().
>
> Cc: David Airlie
> Cc: Archit Taneja
> Cc: Wolfram Sang
> Cc: Lars-Peter Clausen
> Cc: Laurent Pinchart
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b38e743..2caca0c
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -406,7 +406,7 @@ static void adv7511_irq_work(struct work_struct *work)
> {
> struct adv7511 *adv7511 = container_of(work, struct adv7511,
irq_work);
>
> - drm_helper_hpd_irq_event(adv7511->connector.dev);
> + drm_kms_helper_hotplug_event(adv7511->connector.dev);
That's nice, but you must first update adv7511->connector.status (and as an
optimization only call drm_kms_helper_hotplug_event() if the status has
changed).
> }
--
Regards,
Laurent Pinchart
Re: [PATCH] Input: joystick: sidewinder - change msleep to usleep_range for small msecs
On Tue, Nov 29, 2016 at 01:08:22AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device suspend time, device enable time, connection time, probe time,
> loops, retry logic, etc
> msleep is built on jiffies / legacy timers which are not precise whereas
> usleep_range is build on top of hrtimers so the wakeups are precise.
> Thus, change msleep to usleep_range for precise wakeups.
>
> For example:
> On a machine with tick rate / HZ as 100, msleep(6) will make the process to
> sleep for a minimum period of 10 ms whereas usleep_range(6000, 6100) will make
> sure that the process does not sleep for more than 6100 us or 6.1ms
This patch seems clearly unnecessary. SW_TIMEOUT is 6ms or longer for
MS Sidewinder devices.
Vojtech
> Signed-off-by: Aniroop Mathur
> ---
> drivers/input/joystick/sidewinder.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/input/joystick/sidewinder.c
> b/drivers/input/joystick/sidewinder.c
> index 4a95b22..e5a1292 100644
> --- a/drivers/input/joystick/sidewinder.c
> +++ b/drivers/input/joystick/sidewinder.c
> @@ -50,7 +50,7 @@ MODULE_LICENSE("GPL");
>
> #define SW_START 600 /* The time we wait for the first bit [600 us]
> */
> #define SW_STROBE60 /* Max time per bit [60 us] */
> -#define SW_TIMEOUT 6 /* Wait for everything to settle [6 ms] */
> +#define SW_TIMEOUT 6000/* Wait for everything to settle [6000 us] */
> #define SW_KICK 45 /* Wait after A0 fall till kick [45 us]
> */
> #define SW_END 8 /* Number of bits before end of packet
> to kick */
> #define SW_FAIL 16 /* Number of packet read errors to fail
> and reinitialize */
> @@ -139,7 +139,7 @@ static int sw_read_packet(struct gameport *gameport,
> unsigned char *buf, int len
> unsigned char pending, u, v;
>
> i = -id;/* Don't care
> about data, only want ID */
> - timeout = id ? gameport_time(gameport, SW_TIMEOUT * 1000) : 0; /* Set
> up global timeout for ID packet */
> + timeout = id ? gameport_time(gameport, SW_TIMEOUT) : 0; /* Set up
> global timeout for ID packet */
> kick = id ? gameport_time(gameport, SW_KICK) : 0; /* Set up kick
> timeout for ID packet */
> start = gameport_time(gameport, SW_START);
> strobe = gameport_time(gameport, SW_STROBE);
> @@ -248,7 +248,7 @@ static void sw_init_digital(struct gameport *gameport)
> i = 0;
> do {
> gameport_trigger(gameport); /* Trigger */
> - t = gameport_time(gameport, SW_TIMEOUT * 1000);
> + t = gameport_time(gameport, SW_TIMEOUT);
> while ((gameport_read(gameport) & 1) && t) t--; /* Wait for
> axis to fall back to 0 */
> udelay(seq[i]); /*
> Delay magic time */
> } while (seq[++i]);
> @@ -483,13 +483,13 @@ static int sw_read(struct sw *sw)
> " - reinitializing joystick.\n", sw->gameport->phys);
>
> if (!i && sw->type == SW_ID_3DP) {
> /* 3D Pro can be in analog mode */
> - mdelay(3 * SW_TIMEOUT);
> + mdelay(3 * (SW_TIMEOUT / 1000));
> sw_init_digital(sw->gameport);
> }
>
> - mdelay(SW_TIMEOUT);
> + mdelay(SW_TIMEOUT / 1000);
> i = sw_read_packet(sw->gameport, buf, SW_LENGTH, 0);
> /* Read normal data packet */
> - mdelay(SW_TIMEOUT);
> + mdelay(SW_TIMEOUT / 1000);
> sw_read_packet(sw->gameport, buf, SW_LENGTH, i);
> /* Read ID packet, this initializes the stick */
>
> sw->fail = SW_FAIL;
> @@ -616,14 +616,14 @@ static int sw_connect(struct gameport *gameport, struct
> gameport_driver *drv)
> gameport->phys, gameport->io, gameport->speed);
>
> i = sw_read_packet(gameport, buf, SW_LENGTH, 0);/* Read
> normal packet */
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> dbg("Init 1: Mode %d. Length %d.", m , i);
>
> if (!i) { /* No
> data. 3d Pro analog mode? */
> sw_init_digital(gameport); /*
> Switch to digital */
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> i = sw_read_packet(gameport, buf, SW_LENGTH, 0);/*
> Retry reading packet */
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> dbg("Init 1b: Length %d.", i);
> if (!i) {
[PATCH] drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'
'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
Propagate the error code, instead of returning -ENOMEM unconditionally
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 443d1ed00de7..d1aee9860033 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -209,8 +209,8 @@ static int vmw_gb_context_init(struct vmw_private *dev_priv,
for (i = 0; i < SVGA_COTABLE_DX10_MAX; ++i) {
uctx->cotables[i] = vmw_cotable_alloc(dev_priv,
&uctx->res, i);
- if (unlikely(uctx->cotables[i] == NULL)) {
- ret = -ENOMEM;
+ if (unlikely(IS_ERR(uctx->cotables[i]))) {
+ ret = PTR_ERR(uctx->cotables[i]);
goto out_cotables;
}
}
--
2.9.3
RE: [PATCH v3] crypto: add virtio-crypto driver
>
> > > > +
> > > > +/* Note: kernel crypto API realization */
> > > > +static int virtio_crypto_ablkcipher_setkey(struct crypto_ablkcipher
> > > > *tfm,
> > > > +const uint8_t *key,
> > > > +unsigned int keylen)
> > > > +{
> > > > + struct virtio_crypto_ablkcipher_ctx *ctx =
> > crypto_ablkcipher_ctx(tfm);
> > > > + int ret;
> > > > +
> > > > + spin_lock(&ctx->lock);
> > > > +
> > > > + if (!ctx->vcrypto) {
> > > > + /* New key */
> > > > + int node = virtio_crypto_get_current_node();
> > > > + struct virtio_crypto *vcrypto =
> > > > + virtcrypto_get_dev_node(node);
> > > > + if (!vcrypto) {
> > > > + vcrypto = virtcrypto_devmgr_get_first();
> >
> > Is this the standard way to do this? How does this work with
> > multiple crypto devices (e.g. with different capabilities)?
> >
> Actually there is a simple schedule algorithms in virtcrypto_get_dev_node(),
> which return the device used fewest on the node.
>
> If we don't find a device in the node, select the first on as default.
> But I forgot to check the first devices whether the device has started here.
>
Oh, the virtcrypto_get_dev_node() had done this work, the calling of
virtcrypto_devmgr_get_first() here is superfluous. Will remove it.
Regards,
-Gonglei
Re: [PATCH v2 07/12] mm: thp: check pmd migration entry in common path
# sorry for late reply ...
On Fri, Nov 18, 2016 at 02:56:24AM +0300, Kirill A. Shutemov wrote:
> On Tue, Nov 08, 2016 at 08:31:52AM +0900, Naoya Horiguchi wrote:
> > If one of callers of page migration starts to handle thp, memory management
> > code
> > start to see pmd migration entry, so we need to prepare for it before
> > enabling.
> > This patch changes various code point which checks the status of given pmds
> > in
> > order to prevent race between thp migration and the pmd-related works.
> >
> > Signed-off-by: Naoya Horiguchi
> > ---
> > ChangeLog v1 -> v2:
> > - introduce pmd_related() (I know the naming is not good, but can't think up
> > no better name. Any suggesntion is welcomed.)
> > ---
> > arch/x86/mm/gup.c | 4 +--
> > fs/proc/task_mmu.c | 23 +++--
> > include/linux/huge_mm.h | 9 -
> > mm/gup.c| 10 --
> > mm/huge_memory.c| 88
> > -
> > mm/madvise.c| 2 +-
> > mm/memcontrol.c | 2 ++
> > mm/memory.c | 6 +++-
> > mm/mprotect.c | 2 ++
> > mm/mremap.c | 2 +-
> > 10 files changed, 114 insertions(+), 34 deletions(-)
> >
> > diff --git v4.9-rc2-mmotm-2016-10-27-18-27/arch/x86/mm/gup.c
> > v4.9-rc2-mmotm-2016-10-27-18-27_patched/arch/x86/mm/gup.c
> > index 0d4fb3e..78a153d 100644
> > --- v4.9-rc2-mmotm-2016-10-27-18-27/arch/x86/mm/gup.c
> > +++ v4.9-rc2-mmotm-2016-10-27-18-27_patched/arch/x86/mm/gup.c
> > @@ -222,9 +222,9 @@ static int gup_pmd_range(pud_t pud, unsigned long addr,
> > unsigned long end,
> > pmd_t pmd = *pmdp;
> >
> > next = pmd_addr_end(addr, end);
> > - if (pmd_none(pmd))
> > + if (!pmd_present(pmd))
> > return 0;
> > - if (unlikely(pmd_large(pmd) || !pmd_present(pmd))) {
> > + if (unlikely(pmd_large(pmd))) {
> > /*
> > * NUMA hinting faults need to be handled in the GUP
> > * slowpath for accounting purposes and so that they
> > diff --git v4.9-rc2-mmotm-2016-10-27-18-27/fs/proc/task_mmu.c
> > v4.9-rc2-mmotm-2016-10-27-18-27_patched/fs/proc/task_mmu.c
> > index 35b92d8..c1f9cf4 100644
> > --- v4.9-rc2-mmotm-2016-10-27-18-27/fs/proc/task_mmu.c
> > +++ v4.9-rc2-mmotm-2016-10-27-18-27_patched/fs/proc/task_mmu.c
> > @@ -596,7 +596,8 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long
> > addr, unsigned long end,
> >
> > ptl = pmd_trans_huge_lock(pmd, vma);
> > if (ptl) {
> > - smaps_pmd_entry(pmd, addr, walk);
> > + if (pmd_present(*pmd))
> > + smaps_pmd_entry(pmd, addr, walk);
> > spin_unlock(ptl);
> > return 0;
> > }
> > @@ -929,6 +930,9 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> > long addr,
> > goto out;
> > }
> >
> > + if (!pmd_present(*pmd))
> > + goto out;
> > +
>
> Hm. Looks like clear_soft_dirty_pmd() should handle !present. It doesn't.
>
> Ah.. Found it in 08/12.
>
> > page = pmd_page(*pmd);
> >
> > /* Clear accessed and referenced bits. */
> > @@ -1208,19 +1212,18 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned
> > long addr, unsigned long end,
> > if (ptl) {
> > u64 flags = 0, frame = 0;
> > pmd_t pmd = *pmdp;
> > + struct page *page;
> >
> > if ((vma->vm_flags & VM_SOFTDIRTY) || pmd_soft_dirty(pmd))
> > flags |= PM_SOFT_DIRTY;
> >
> > - /*
> > -* Currently pmd for thp is always present because thp
> > -* can not be swapped-out, migrated, or HWPOISONed
> > -* (split in such cases instead.)
> > -* This if-check is just to prepare for future implementation.
> > -*/
> > - if (pmd_present(pmd)) {
> > - struct page *page = pmd_page(pmd);
> > -
> > + if (is_pmd_migration_entry(pmd)) {
> > + swp_entry_t entry = pmd_to_swp_entry(pmd);
> > + frame = swp_type(entry) |
> > + (swp_offset(entry) << MAX_SWAPFILES_SHIFT);
> > + page = migration_entry_to_page(entry);
> > + } else if (pmd_present(pmd)) {
> > + page = pmd_page(pmd);
> > if (page_mapcount(page) == 1)
> > flags |= PM_MMAP_EXCLUSIVE;
> >
> > diff --git v4.9-rc2-mmotm-2016-10-27-18-27/include/linux/huge_mm.h
> > v4.9-rc2-mmotm-2016-10-27-18-27_patched/include/linux/huge_mm.h
> > index fcbca51..3c252cd 100644
> > --- v4.9-rc2-mmotm-2016-10-27-18-27/include/linux/huge_mm.h
> > +++ v4.9-rc2-mmotm-2016-10-27-18-27_patched/include/linux/huge_mm.h
> > @@ -125,12 +125,19 @@ extern void vma_adjust_trans_huge(struct
> > vm_area_struct *vma,
> > long adjus
Re: [RFC][PATCH 1/5 v2] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:40 John Stultz wrote:
> I was recently seeing issues with EDID probing, where
> the logic to wait for the EDID read bit to be set by the
> IRQ wasn't happening and the code would time out and fail.
>
> Digging deeper, I found this was due to the fact that
> IRQs were disabled as we were running in IRQ context from
> the HPD signal.
>
> Thus this patch changes the logic to handle the HPD signal
> via a work_struct so we can be out of irq context.
>
> With this patch, the EDID probing on hotplug does not time
> out.
>
> Cc: David Airlie
> Cc: Archit Taneja
> Cc: Wolfram Sang
> Cc: Lars-Peter Clausen
> Cc: Laurent Pinchart
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2: Reworked to properly fix the issue rather then
> just delaying for 200ms
>
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 ++
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 992d76c..2a1e722 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -317,6 +317,8 @@ struct adv7511 {
> bool edid_read;
>
> wait_queue_head_t wq;
> + struct work_struct irq_work;
> +
I'd call this hpd_work.
> struct drm_bridge bridge;
> struct drm_connector connector;
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8dba729..b38e743
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -402,6 +402,14 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
> return false;
> }
>
> +static void adv7511_irq_work(struct work_struct *work)
> +{
> + struct adv7511 *adv7511 = container_of(work, struct adv7511,
irq_work);
> +
> + drm_helper_hpd_irq_event(adv7511->connector.dev);
> +}
> +
> +
One blank line is enough.
Apart from that,
Reviewed-by: Laurent Pinchart
> static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
> {
> unsigned int irq0, irq1;
> @@ -419,7 +427,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd) regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder)
> - drm_helper_hpd_irq_event(adv7511->connector.dev);
> + schedule_work(&adv7511->irq_work);
>
> if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
> adv7511->edid_read = true;
> @@ -1006,6 +1014,8 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) goto err_i2c_unregister_edid;
> }
>
> + INIT_WORK(&adv7511->irq_work, adv7511_irq_work);
> +
> if (i2c->irq) {
> init_waitqueue_head(&adv7511->wq);
--
Regards,
Laurent Pinchart
[patch net v2] net: fec: cache statistics while device is down
Execution 'ethtool -S' on fec device that is down causes OOPS on Vybrid
board:
Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898200
pgd = ddecc000
[e0898200] *pgd=9e406811, *pte=400d1653, *ppte=400d1453
Internal error: : 1008 [#1] SMP ARM
...
Reason of OOPS is that fec_enet_get_ethtool_stats() accesses fec
registers while IPG clock is stopped by PM.
Fix that by caching statistics in fec_enet_private. Cache is initialized
at device probe time, and updated at statistics request time if device
is up, and also just before turning device off on down path.
Additional locking is not needed, since cached statistics is accessed
either before device is registered, or under rtnl_lock().
Signed-off-by: Nikita Yushchenko
---
Changes since v1:
- initialize cache at device probe time
drivers/net/ethernet/freescale/fec.h | 2 ++
drivers/net/ethernet/freescale/fec_main.c | 23 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h
b/drivers/net/ethernet/freescale/fec.h
index c865135f3cb9..5ea740b4cf14 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -574,6 +574,8 @@ struct fec_enet_private {
unsigned int reload_period;
int pps_enable;
unsigned int next_counter;
+
+ u64 ethtool_stats[0];
};
void fec_ptp_init(struct platform_device *pdev);
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 5aa9d4ded214..6a20c24a2003 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2313,14 +2313,24 @@ static const struct fec_stat {
{ "IEEE_rx_octets_ok", IEEE_R_OCTETS_OK },
};
-static void fec_enet_get_ethtool_stats(struct net_device *dev,
- struct ethtool_stats *stats, u64 *data)
+static void fec_enet_update_ethtool_stats(struct net_device *dev)
{
struct fec_enet_private *fep = netdev_priv(dev);
int i;
for (i = 0; i < ARRAY_SIZE(fec_stats); i++)
- data[i] = readl(fep->hwp + fec_stats[i].offset);
+ fep->ethtool_stats[i] = readl(fep->hwp + fec_stats[i].offset);
+}
+
+static void fec_enet_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct fec_enet_private *fep = netdev_priv(dev);
+
+ if (netif_running(dev))
+ fec_enet_update_ethtool_stats(dev);
+
+ memcpy(data, fep->ethtool_stats, ARRAY_SIZE(fec_stats) * sizeof(u64));
}
static void fec_enet_get_strings(struct net_device *netdev,
@@ -2874,6 +2884,8 @@ fec_enet_close(struct net_device *ndev)
if (fep->quirks & FEC_QUIRK_ERR006687)
imx6q_cpuidle_fec_irqs_unused();
+ fec_enet_update_ethtool_stats(ndev);
+
fec_enet_clk_enable(ndev, false);
pinctrl_pm_select_sleep_state(&fep->pdev->dev);
pm_runtime_mark_last_busy(&fep->pdev->dev);
@@ -3180,6 +3192,8 @@ static int fec_enet_init(struct net_device *ndev)
fec_restart(ndev);
+ fec_enet_update_ethtool_stats(ndev);
+
return 0;
}
@@ -3278,7 +3292,8 @@ fec_probe(struct platform_device *pdev)
fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs);
/* Init network device */
- ndev = alloc_etherdev_mqs(sizeof(struct fec_enet_private),
+ ndev = alloc_etherdev_mqs(sizeof(struct fec_enet_private) +
+ ARRAY_SIZE(fec_stats) * sizeof(u64),
num_tx_qs, num_rx_qs);
if (!ndev)
return -ENOMEM;
--
2.1.4
[PATCH V5 08/10] PM / OPP: Allow platform specific custom set_opp() callbacks
The generic set_opp() handler isn't sufficient for platforms with
complex DVFS. For example, some TI platforms have multiple regulators
for a CPU device. The order in which various supplies need to be
programmed is only known to the platform code and its best to leave it
to it.
This patch implements APIs to register platform specific set_opp()
callback.
Signed-off-by: Viresh Kumar
Tested-by: Dave Gerlach
---
V4->V5:
- s/custom OPP set rate/custom set OPP/
- set_opp() doesn't have a separate 'dev' argument now.
---
drivers/base/power/opp/core.c | 114 +-
drivers/base/power/opp/opp.h | 2 +
include/linux/pm_opp.h| 10
3 files changed, 125 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 3a0b9d993c42..ddd4915ffd4f 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -687,6 +687,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
{
struct opp_table *opp_table;
unsigned long freq, old_freq;
+ int (*set_opp)(struct dev_pm_set_opp_data *data);
struct dev_pm_opp *old_opp, *opp;
struct regulator **regulators;
struct dev_pm_set_opp_data *data;
@@ -751,6 +752,11 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
return _generic_set_opp_clk_only(dev, clk, old_freq, freq);
}
+ if (opp_table->set_opp)
+ set_opp = opp_table->set_opp;
+ else
+ set_opp = _generic_set_opp;
+
data = opp_table->set_opp_data;
data->regulators = regulators;
data->regulator_count = opp_table->regulator_count;
@@ -769,7 +775,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
rcu_read_unlock();
- return _generic_set_opp(data);
+ return set_opp(data);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_set_rate);
@@ -903,6 +909,9 @@ static void _remove_opp_table(struct opp_table *opp_table)
if (opp_table->regulators)
return;
+ if (opp_table->set_opp)
+ return;
+
/* Release clk */
if (!IS_ERR(opp_table->clk))
clk_put(opp_table->clk);
@@ -1578,6 +1587,109 @@ void dev_pm_opp_put_regulators(struct device *dev)
EXPORT_SYMBOL_GPL(dev_pm_opp_put_regulators);
/**
+ * dev_pm_opp_register_set_opp_helper() - Register custom set OPP helper
+ * @dev: Device for which the helper is getting registered.
+ * @set_opp: Custom set OPP helper.
+ *
+ * This is useful to support complex platforms (like platforms with multiple
+ * regulators per device), instead of the generic OPP set rate helper.
+ *
+ * This must be called before any OPPs are initialized for the device.
+ *
+ * Locking: The internal opp_table and opp structures are RCU protected.
+ * Hence this function internally uses RCU updater strategy with mutex locks
+ * to keep the integrity of the internal data structures. Callers should ensure
+ * that this function is *NOT* called under RCU protection or in contexts where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_register_set_opp_helper(struct device *dev,
+ int (*set_opp)(struct dev_pm_set_opp_data *data))
+{
+ struct opp_table *opp_table;
+ int ret;
+
+ if (!set_opp)
+ return -EINVAL;
+
+ mutex_lock(&opp_table_lock);
+
+ opp_table = _add_opp_table(dev);
+ if (!opp_table) {
+ ret = -ENOMEM;
+ goto unlock;
+ }
+
+ /* This should be called before OPPs are initialized */
+ if (WARN_ON(!list_empty(&opp_table->opp_list))) {
+ ret = -EBUSY;
+ goto err;
+ }
+
+ /* Already have custom set_opp helper */
+ if (WARN_ON(opp_table->set_opp)) {
+ ret = -EBUSY;
+ goto err;
+ }
+
+ opp_table->set_opp = set_opp;
+
+ mutex_unlock(&opp_table_lock);
+ return 0;
+
+err:
+ _remove_opp_table(opp_table);
+unlock:
+ mutex_unlock(&opp_table_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_register_set_opp_helper);
+
+/**
+ * dev_pm_opp_register_put_opp_helper() - Releases resources blocked for
+ *set_opp helper
+ * @dev: Device for which custom set_opp helper has to be cleared.
+ *
+ * Locking: The internal opp_table and opp structures are RCU protected.
+ * Hence this function internally uses RCU updater strategy with mutex locks
+ * to keep the integrity of the internal data structures. Callers should ensure
+ * that this function is *NOT* called under RCU protection or in contexts where
+ * mutex cannot be locked.
+ */
+void dev_pm_opp_register_put_opp_helper(struct device *dev)
+{
+ struct opp_table *opp_table;
+
+ mutex_lock(&opp_table_lock);
+
+ /* Check for existing table for 'dev' first */
+ opp_table = _find_opp_table(dev
[PATCH V5 04/10] PM / OPP: Manage supply's voltage/current in a separate structure
This is a preparatory step for multiple regulator per device support.
Move the voltage/current variables to a new structure.
Signed-off-by: Viresh Kumar
Tested-by: Dave Gerlach
Reviewed-by: Stephen Boyd
---
drivers/base/power/opp/core.c| 44 +---
drivers/base/power/opp/debugfs.c | 8
drivers/base/power/opp/of.c | 18
drivers/base/power/opp/opp.h | 11 +++---
include/linux/pm_opp.h | 16 +++
5 files changed, 55 insertions(+), 42 deletions(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 056527a3fb4e..8d6006151c9a 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -112,7 +112,7 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
if (IS_ERR_OR_NULL(tmp_opp))
pr_err("%s: Invalid parameters\n", __func__);
else
- v = tmp_opp->u_volt;
+ v = tmp_opp->supply.u_volt;
return v;
}
@@ -246,10 +246,10 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct
device *dev)
if (!opp->available)
continue;
- if (opp->u_volt_min < min_uV)
- min_uV = opp->u_volt_min;
- if (opp->u_volt_max > max_uV)
- max_uV = opp->u_volt_max;
+ if (opp->supply.u_volt_min < min_uV)
+ min_uV = opp->supply.u_volt_min;
+ if (opp->supply.u_volt_max > max_uV)
+ max_uV = opp->supply.u_volt_max;
}
rcu_read_unlock();
@@ -637,14 +637,14 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
if (IS_ERR(old_opp)) {
old_u_volt = 0;
} else {
- old_u_volt = old_opp->u_volt;
- old_u_volt_min = old_opp->u_volt_min;
- old_u_volt_max = old_opp->u_volt_max;
+ old_u_volt = old_opp->supply.u_volt;
+ old_u_volt_min = old_opp->supply.u_volt_min;
+ old_u_volt_max = old_opp->supply.u_volt_max;
}
- u_volt = opp->u_volt;
- u_volt_min = opp->u_volt_min;
- u_volt_max = opp->u_volt_max;
+ u_volt = opp->supply.u_volt;
+ u_volt_min = opp->supply.u_volt_min;
+ u_volt_max = opp->supply.u_volt_max;
reg = opp_table->regulator;
@@ -957,10 +957,11 @@ static bool _opp_supported_by_regulators(struct
dev_pm_opp *opp,
struct regulator *reg = opp_table->regulator;
if (!IS_ERR(reg) &&
- !regulator_is_supported_voltage(reg, opp->u_volt_min,
- opp->u_volt_max)) {
+ !regulator_is_supported_voltage(reg, opp->supply.u_volt_min,
+ opp->supply.u_volt_max)) {
pr_warn("%s: OPP minuV: %lu maxuV: %lu, not supported by
regulator\n",
- __func__, opp->u_volt_min, opp->u_volt_max);
+ __func__, opp->supply.u_volt_min,
+ opp->supply.u_volt_max);
return false;
}
@@ -993,11 +994,12 @@ int _opp_add(struct device *dev, struct dev_pm_opp
*new_opp,
/* Duplicate OPPs */
dev_warn(dev, "%s: duplicate OPPs detected. Existing: freq:
%lu, volt: %lu, enabled: %d. New: freq: %lu, volt: %lu, enabled: %d\n",
-__func__, opp->rate, opp->u_volt, opp->available,
-new_opp->rate, new_opp->u_volt, new_opp->available);
+__func__, opp->rate, opp->supply.u_volt,
+opp->available, new_opp->rate, new_opp->supply.u_volt,
+new_opp->available);
- return opp->available && new_opp->u_volt == opp->u_volt ?
- 0 : -EEXIST;
+ return opp->available &&
+ new_opp->supply.u_volt == opp->supply.u_volt ? 0 :
-EEXIST;
}
new_opp->opp_table = opp_table;
@@ -1064,9 +1066,9 @@ int _opp_add_v1(struct device *dev, unsigned long freq,
long u_volt,
/* populate the opp table */
new_opp->rate = freq;
tol = u_volt * opp_table->voltage_tolerance_v1 / 100;
- new_opp->u_volt = u_volt;
- new_opp->u_volt_min = u_volt - tol;
- new_opp->u_volt_max = u_volt + tol;
+ new_opp->supply.u_volt = u_volt;
+ new_opp->supply.u_volt_min = u_volt - tol;
+ new_opp->supply.u_volt_max = u_volt + tol;
new_opp->available = true;
new_opp->dynamic = dynamic;
diff --git a/drivers/base/power/opp/debugfs.c b/drivers/base/power/opp/debugfs.c
index ef1ae6b52042..c897676ca35f 100644
--- a/drivers/base/power/opp/debugfs.c
+++ b/drivers/base/power/opp/debugfs.c
@@ -63,16 +63,16 @@ int opp_debug_create_one(struct dev_pm_opp *opp, struct
opp_table *opp_table)
if (!debugfs_create_ulong("rate_hz",
[PATCH V5 06/10] PM / OPP: Add infrastructure to manage multiple regulators
This patch adds infrastructure to manage multiple regulators and updates
the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator().
This is preparatory work for adding full support for devices with
multiple regulators.
Signed-off-by: Viresh Kumar
Tested-by: Dave Gerlach
---
V4->V5:
- Don't allocate from within rcu locked section.
- s/+//
---
drivers/base/power/opp/core.c| 246 +++
drivers/base/power/opp/debugfs.c | 52 +++--
drivers/base/power/opp/of.c | 103 +++-
drivers/base/power/opp/opp.h | 10 +-
drivers/cpufreq/cpufreq-dt.c | 9 +-
include/linux/pm_opp.h | 8 +-
6 files changed, 301 insertions(+), 127 deletions(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 37fad2eb0f47..89a3fd720724 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -93,6 +93,8 @@ struct opp_table *_find_opp_table(struct device *dev)
* Return: voltage in micro volt corresponding to the opp, else
* return 0
*
+ * This is useful only for devices with single power supply.
+ *
* Locking: This function must be called under rcu_read_lock(). opp is a rcu
* protected pointer. This means that opp which could have been fetched by
* opp_find_freq_{exact,ceil,floor} functions is valid as long as we are
@@ -112,7 +114,7 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
if (IS_ERR_OR_NULL(tmp_opp))
pr_err("%s: Invalid parameters\n", __func__);
else
- v = tmp_opp->supply.u_volt;
+ v = tmp_opp->supplies[0].u_volt;
return v;
}
@@ -210,6 +212,24 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct
device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_clock_latency);
+static int _get_regulator_count(struct device *dev)
+{
+ struct opp_table *opp_table;
+ int count;
+
+ rcu_read_lock();
+
+ opp_table = _find_opp_table(dev);
+ if (!IS_ERR(opp_table))
+ count = opp_table->regulator_count;
+ else
+ count = 0;
+
+ rcu_read_unlock();
+
+ return count;
+}
+
/**
* dev_pm_opp_get_max_volt_latency() - Get max voltage latency in nanoseconds
* @dev: device for which we do this operation
@@ -222,34 +242,51 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct
device *dev)
{
struct opp_table *opp_table;
struct dev_pm_opp *opp;
- struct regulator *reg;
+ struct regulator *reg, **regulators;
unsigned long latency_ns = 0;
- unsigned long min_uV = ~0, max_uV = 0;
- int ret;
+ int ret, i, count;
+ struct {
+ unsigned long min;
+ unsigned long max;
+ } *uV;
+
+ count = _get_regulator_count(dev);
+
+ /* Regulator may not be required for the device */
+ if (!count)
+ return 0;
+
+ regulators = kmalloc_array(count, sizeof(*regulators), GFP_KERNEL);
+ if (!regulators)
+ return 0;
+
+ uV = kmalloc_array(count, sizeof(*uV), GFP_KERNEL);
+ if (!uV)
+ goto free_regulators;
rcu_read_lock();
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
rcu_read_unlock();
- return 0;
+ goto free_uV;
}
- reg = opp_table->regulator;
- if (IS_ERR(reg)) {
- /* Regulator may not be required for device */
- rcu_read_unlock();
- return 0;
- }
+ memcpy(regulators, opp_table->regulators, count * sizeof(*regulators));
- list_for_each_entry_rcu(opp, &opp_table->opp_list, node) {
- if (!opp->available)
- continue;
+ for (i = 0; i < count; i++) {
+ uV[i].min = ~0;
+ uV[i].max = 0;
- if (opp->supply.u_volt_min < min_uV)
- min_uV = opp->supply.u_volt_min;
- if (opp->supply.u_volt_max > max_uV)
- max_uV = opp->supply.u_volt_max;
+ list_for_each_entry_rcu(opp, &opp_table->opp_list, node) {
+ if (!opp->available)
+ continue;
+
+ if (opp->supplies[i].u_volt_min < uV[i].min)
+ uV[i].min = opp->supplies[i].u_volt_min;
+ if (opp->supplies[i].u_volt_max > uV[i].max)
+ uV[i].max = opp->supplies[i].u_volt_max;
+ }
}
rcu_read_unlock();
@@ -258,9 +295,16 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct
device *dev)
* The caller needs to ensure that opp_table (and hence the regulator)
* isn't freed, while we are executing this routine.
*/
- ret = regulator_set_voltage_time(reg, min_uV, max_uV);
- if (ret > 0)
- latency_ns = ret * 1000;
+
[PATCH] ipv6:ip6_xmit remove unnecessary np NULL check
From: Rohit Thapliyal
np NULL check doesn't seem required here as it shall never
be NULL anyways in inet6_sk(sk).
Signed-off-by: Rohit Thapliyal
Signed-off-by: Manjeet Pawar
Signed-off-by: David Miller
Reviewed-by: Akhilesh Kumar
---
v2->v3: Modified as per the suggestion from David Miller
ip6_xmit calls are made without checking NULL np
pointer, so no need to explicitly check NULL np in
ip6_xmit.
include/linux/ipv6.h | 2 +-
net/ipv6/ip6_output.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index a064997..6c9c604 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -299,7 +299,7 @@ struct tcp6_timewait_sock {
static inline struct ipv6_pinfo *inet6_sk(const struct sock *__sk)
{
- return sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
+ return inet_sk(__sk)->pinet6;
}
static inline struct raw6_sock *raw6_sk(const struct sock *sk)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 59eb4ed..f8c63ec 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -213,8 +213,7 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb,
struct flowi6 *fl6,
/*
* Fill in the IPv6 header
*/
- if (np)
- hlimit = np->hop_limit;
+ hlimit = np->hop_limit;
if (hlimit < 0)
hlimit = ip6_dst_hoplimit(dst);
--
1.9.1
[PATCH V5 07/10] PM / OPP: Separate out _generic_set_opp()
Later patches would add support for custom set_opp() callbacks. This
patch separates out the code for _generic_set_opp() handler in order to
prepare for that.
Signed-off-by: Viresh Kumar
Tested-by: Dave Gerlach
Reviewed-by: Stephen Boyd
---
V4->V5:
- Make 'dev' part of struct dev_pm_set_opp_data
- Fix commit log: s/opp_set_rate/set_opp
- Same in a comment as well
---
drivers/base/power/opp/core.c | 181 +-
drivers/base/power/opp/opp.h | 3 +
include/linux/pm_opp.h| 35
3 files changed, 166 insertions(+), 53 deletions(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 89a3fd720724..3a0b9d993c42 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -610,6 +610,69 @@ static int _set_opp_voltage(struct device *dev, struct
regulator *reg,
return ret;
}
+static inline int
+_generic_set_opp_clk_only(struct device *dev, struct clk *clk,
+ unsigned long old_freq, unsigned long freq)
+{
+ int ret;
+
+ ret = clk_set_rate(clk, freq);
+ if (ret) {
+ dev_err(dev, "%s: failed to set clock rate: %d\n", __func__,
+ ret);
+ }
+
+ return ret;
+}
+
+static int _generic_set_opp(struct dev_pm_set_opp_data *data)
+{
+ struct dev_pm_opp_supply *old_supply = data->old_opp.supplies;
+ struct dev_pm_opp_supply *new_supply = data->new_opp.supplies;
+ unsigned long old_freq = data->old_opp.rate, freq = data->new_opp.rate;
+ struct regulator *reg = data->regulators[0];
+ struct device *dev= data->dev;
+ int ret;
+
+ /* This function only supports single regulator per device */
+ if (WARN_ON(data->regulator_count > 1)) {
+ dev_err(dev, "multiple regulators are not supported\n");
+ return -EINVAL;
+ }
+
+ /* Scaling up? Scale voltage before frequency */
+ if (freq > old_freq) {
+ ret = _set_opp_voltage(dev, reg, new_supply);
+ if (ret)
+ goto restore_voltage;
+ }
+
+ /* Change frequency */
+ ret = _generic_set_opp_clk_only(dev, data->clk, old_freq, freq);
+ if (ret)
+ goto restore_voltage;
+
+ /* Scaling down? Scale voltage after frequency */
+ if (freq < old_freq) {
+ ret = _set_opp_voltage(dev, reg, new_supply);
+ if (ret)
+ goto restore_freq;
+ }
+
+ return 0;
+
+restore_freq:
+ if (_generic_set_opp_clk_only(dev, data->clk, freq, old_freq))
+ dev_err(dev, "%s: failed to restore old-freq (%lu Hz)\n",
+ __func__, old_freq);
+restore_voltage:
+ /* This shouldn't harm even if the voltages weren't updated earlier */
+ if (old_supply->u_volt)
+ _set_opp_voltage(dev, reg, old_supply);
+
+ return ret;
+}
+
/**
* dev_pm_opp_set_rate() - Configure new OPP based on frequency
* @dev:device for which we do this operation
@@ -623,12 +686,12 @@ static int _set_opp_voltage(struct device *dev, struct
regulator *reg,
int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
{
struct opp_table *opp_table;
+ unsigned long freq, old_freq;
struct dev_pm_opp *old_opp, *opp;
- struct regulator *reg = ERR_PTR(-ENXIO);
+ struct regulator **regulators;
+ struct dev_pm_set_opp_data *data;
struct clk *clk;
- unsigned long freq, old_freq;
- struct dev_pm_opp_supply old_supply, new_supply;
- int ret;
+ int ret, size;
if (unlikely(!target_freq)) {
dev_err(dev, "%s: Invalid target frequency %lu\n", __func__,
@@ -677,64 +740,36 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
return ret;
}
- if (opp_table->regulators) {
- /* This function only supports single regulator per device */
- if (WARN_ON(opp_table->regulator_count > 1)) {
- dev_err(dev, "multiple regulators not supported\n");
- rcu_read_unlock();
- return -EINVAL;
- }
+ dev_dbg(dev, "%s: switching OPP: %lu Hz --> %lu Hz\n", __func__,
+ old_freq, freq);
- reg = opp_table->regulators[0];
+ regulators = opp_table->regulators;
+
+ /* Only frequency scaling */
+ if (!regulators) {
+ rcu_read_unlock();
+ return _generic_set_opp_clk_only(dev, clk, old_freq, freq);
}
+ data = opp_table->set_opp_data;
+ data->regulators = regulators;
+ data->regulator_count = opp_table->regulator_count;
+ data->clk = clk;
+ data->dev = dev;
+
+ data->old_opp.rate = old_freq;
+ size = sizeof(*opp->supplies) * opp_table->regulator_count;
if (IS_ERR(old_opp))
-
[PATCH V5 10/10] PM / OPP: Don't assume platform doesn't have regulators
If the regulators aren't set explicitly by the platform, the OPP core
assumes that the platform doesn't have any regulator and uses the
clk-only callback.
If the platform failed to register a regulator with the core, then this
can turn out to be a dangerous assumption as the OPP core will try to
change clk without changing regulators.
Handle that properly by making sure that the DT didn't have any entries
for supply voltages as well.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/base/power/opp/core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 3c9f223709ab..f7a5fb4dbf11 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -748,7 +748,20 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
/* Only frequency scaling */
if (!regulators) {
+ unsigned long u_volt = opp->supplies[0].u_volt;
+
rcu_read_unlock();
+
+ /*
+* DT contained supply ratings? Consider platform failed to set
+* regulators.
+*/
+ if (unlikely(u_volt)) {
+ dev_err(dev, "%s: Regulator not registered with OPP
core\n",
+ __func__);
+ return -EINVAL;
+ }
+
return _generic_set_opp_clk_only(dev, clk, old_freq, freq);
}
--
2.7.1.410.g6faf27b
[PATCH V5 03/10] PM / OPP: Don't use OPP structure outside of rcu protected section
The OPP structure must not be used out of the rcu protected section.
Cache the values to be used in separate variables instead.
Cc: # v4.6+
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
Tested-by: Dave Gerlach
---
drivers/base/power/opp/core.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 4c7c6da7a989..056527a3fb4e 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -584,6 +584,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
struct clk *clk;
unsigned long freq, old_freq;
unsigned long u_volt, u_volt_min, u_volt_max;
+ unsigned long old_u_volt, old_u_volt_min, old_u_volt_max;
int ret;
if (unlikely(!target_freq)) {
@@ -633,6 +634,14 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
return ret;
}
+ if (IS_ERR(old_opp)) {
+ old_u_volt = 0;
+ } else {
+ old_u_volt = old_opp->u_volt;
+ old_u_volt_min = old_opp->u_volt_min;
+ old_u_volt_max = old_opp->u_volt_max;
+ }
+
u_volt = opp->u_volt;
u_volt_min = opp->u_volt_min;
u_volt_max = opp->u_volt_max;
@@ -677,9 +686,10 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
__func__, old_freq);
restore_voltage:
/* This shouldn't harm even if the voltages weren't updated earlier */
- if (!IS_ERR(old_opp))
- _set_opp_voltage(dev, reg, old_opp->u_volt,
-old_opp->u_volt_min, old_opp->u_volt_max);
+ if (old_u_volt) {
+ _set_opp_voltage(dev, reg, old_u_volt, old_u_volt_min,
+old_u_volt_max);
+ }
return ret;
}
--
2.7.1.410.g6faf27b
[PATCH V5 01/10] PM / OPP: Fix incorrect cpu-supply property in binding
The regulator bindings allow the "-supply" property to define a
single parent supply and not a list of parents.
Fix the wrong example code present in OPP bindings.
While at it also change the compatible string as Rob pointed out earlier
that none of A7 implementation have multiple supplies for the CPU core.
Signed-off-by: Viresh Kumar
Acked-by: Rob Herring
Reviewed-by: Stephen Boyd
---
Documentation/devicetree/bindings/opp/opp.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index ee91cbdd95ee..f0239f68d186 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -386,10 +386,12 @@ Example 4: Handling multiple regulators
/ {
cpus {
cpu@0 {
- compatible = "arm,cortex-a7";
+ compatible = "vendor,cpu-type";
...
- cpu-supply = <&cpu_supply0>, <&cpu_supply1>,
<&cpu_supply2>;
+ vcc0-supply = <&cpu_supply0>;
+ vcc1-supply = <&cpu_supply1>;
+ vcc2-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu0_opp_table>;
};
};
--
2.7.1.410.g6faf27b
[PATCH V5 02/10] PM / OPP: Reword binding supporting multiple regulators per device
On certain platforms (like TI), DVFS for a single device (CPU) requires configuring multiple power supplies. The OPP bindings already contains binding and example to explain this case, but it isn't sufficient. - There is no way for the code parsing these bindings to know which voltage values belong to which power supply. - It is not possible to know the order in which the supplies need to be configured while switching OPPs. This patch clarifies on those details by mentioning that such information is left for the implementation specific bindings to explain. They may want to hardcode such details or implement their own properties to get such information. All implementations using multiple regulators for their devices must provide a binding document explaining their implementation. Signed-off-by: Viresh Kumar Acked-by: Rob Herring Reviewed-by: Stephen Boyd --- Documentation/devicetree/bindings/opp/opp.txt | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index f0239f68d186..9f5ca4457b5f 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -86,8 +86,14 @@ properties. Single entry is for target voltage and three entries are for voltages. - Entries for multiple regulators must be present in the same order as - regulators are specified in device's DT node. + Entries for multiple regulators shall be provided in the same field separated + by angular brackets <>. The OPP binding doesn't provide any provisions to + relate the values to their power supplies or the order in which the supplies + need to be configured and that is left for the implementation specific + binding. + + Entries for all regulators shall be of the same size, i.e. either all use a + single value or triplets. - opp-microvolt-: Named opp-microvolt property. This is exactly similar to the above opp-microvolt property, but allows multiple voltage ranges to be @@ -104,10 +110,13 @@ properties. Should only be set if opp-microvolt is set for the OPP. - Entries for multiple regulators must be present in the same order as - regulators are specified in device's DT node. If this property isn't required - for few regulators, then this should be marked as zero for them. If it isn't - required for any regulator, then this property need not be present. + Entries for multiple regulators shall be provided in the same field separated + by angular brackets <>. If current values aren't required for a regulator, + then it shall be filled with 0. If current values aren't required for any of + the regulators, then this field is not required. The OPP binding doesn't + provide any provisions to relate the values to their power supplies or the + order in which the supplies need to be configured and that is left for the + implementation specific binding. - opp-microamp-: Named opp-microamp property. Similar to opp-microvolt- property, but for microamp instead. -- 2.7.1.410.g6faf27b
[PATCH V5 09/10] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators()
If a platform specific OPP driver has called this routine first and set
the regulators, then the second call from cpufreq-dt driver will hit the
WARN_ON(). Remove the WARN_ON(), but continue to return error in such
cases.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
Tested-by: Dave Gerlach
---
drivers/base/power/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index ddd4915ffd4f..3c9f223709ab 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -1484,7 +1484,7 @@ int dev_pm_opp_set_regulators(struct device *dev, const
char * const names[],
}
/* Already have regulators set */
- if (WARN_ON(opp_table->regulators)) {
+ if (opp_table->regulators) {
ret = -EBUSY;
goto err;
}
--
2.7.1.410.g6faf27b
[PATCH V5 05/10] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()
Pass the entire supply structure instead of all of its fields.
Signed-off-by: Viresh Kumar
Tested-by: Dave Gerlach
Reviewed-by: Stephen Boyd
---
drivers/base/power/opp/core.c | 44 +--
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 8d6006151c9a..37fad2eb0f47 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -542,8 +542,7 @@ static struct clk *_get_opp_clk(struct device *dev)
}
static int _set_opp_voltage(struct device *dev, struct regulator *reg,
- unsigned long u_volt, unsigned long u_volt_min,
- unsigned long u_volt_max)
+ struct dev_pm_opp_supply *supply)
{
int ret;
@@ -554,14 +553,15 @@ static int _set_opp_voltage(struct device *dev, struct
regulator *reg,
return 0;
}
- dev_dbg(dev, "%s: voltages (mV): %lu %lu %lu\n", __func__, u_volt_min,
- u_volt, u_volt_max);
+ dev_dbg(dev, "%s: voltages (mV): %lu %lu %lu\n", __func__,
+ supply->u_volt_min, supply->u_volt, supply->u_volt_max);
- ret = regulator_set_voltage_triplet(reg, u_volt_min, u_volt,
- u_volt_max);
+ ret = regulator_set_voltage_triplet(reg, supply->u_volt_min,
+ supply->u_volt, supply->u_volt_max);
if (ret)
dev_err(dev, "%s: failed to set voltage (%lu %lu %lu mV): %d\n",
- __func__, u_volt_min, u_volt, u_volt_max, ret);
+ __func__, supply->u_volt_min, supply->u_volt,
+ supply->u_volt_max, ret);
return ret;
}
@@ -583,8 +583,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
struct regulator *reg;
struct clk *clk;
unsigned long freq, old_freq;
- unsigned long u_volt, u_volt_min, u_volt_max;
- unsigned long old_u_volt, old_u_volt_min, old_u_volt_max;
+ struct dev_pm_opp_supply old_supply, new_supply;
int ret;
if (unlikely(!target_freq)) {
@@ -634,17 +633,12 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
return ret;
}
- if (IS_ERR(old_opp)) {
- old_u_volt = 0;
- } else {
- old_u_volt = old_opp->supply.u_volt;
- old_u_volt_min = old_opp->supply.u_volt_min;
- old_u_volt_max = old_opp->supply.u_volt_max;
- }
+ if (IS_ERR(old_opp))
+ old_supply.u_volt = 0;
+ else
+ memcpy(&old_supply, &old_opp->supply, sizeof(old_supply));
- u_volt = opp->supply.u_volt;
- u_volt_min = opp->supply.u_volt_min;
- u_volt_max = opp->supply.u_volt_max;
+ memcpy(&new_supply, &opp->supply, sizeof(new_supply));
reg = opp_table->regulator;
@@ -652,8 +646,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
/* Scaling up? Scale voltage before frequency */
if (freq > old_freq) {
- ret = _set_opp_voltage(dev, reg, u_volt, u_volt_min,
- u_volt_max);
+ ret = _set_opp_voltage(dev, reg, &new_supply);
if (ret)
goto restore_voltage;
}
@@ -672,8 +665,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
/* Scaling down? Scale voltage after frequency */
if (freq < old_freq) {
- ret = _set_opp_voltage(dev, reg, u_volt, u_volt_min,
- u_volt_max);
+ ret = _set_opp_voltage(dev, reg, &new_supply);
if (ret)
goto restore_freq;
}
@@ -686,10 +678,8 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
__func__, old_freq);
restore_voltage:
/* This shouldn't harm even if the voltages weren't updated earlier */
- if (old_u_volt) {
- _set_opp_voltage(dev, reg, old_u_volt, old_u_volt_min,
-old_u_volt_max);
- }
+ if (old_supply.u_volt)
+ _set_opp_voltage(dev, reg, &old_supply);
return ret;
}
--
2.7.1.410.g6faf27b
[PATCH V5 00/10] PM / OPP: Multiple regulator support
Hi, Some platforms (like TI) have complex DVFS configuration for CPU devices, where multiple regulators are required to be configured to change DVFS state of the device. This was explained well by Nishanth earlier [1]. One of the major complaints around multiple regulators case was that the DT isn't responsible in any way to represent the order in which multiple supplies need to be programmed, before or after a frequency change. It was considered in this patch and such information is left for the platform specific OPP driver now, which can register its own opp_set_rate() callback with the OPP core and the OPP core will then call it during DVFS. The patches are tested on Exynos5250 (Dual A15). I have hacked around DT and code to pass values for multiple regulators and verified that they are all properly read by the kernel (using debugfs interface). Dave Gerlach has already tested [2] it on the real TI platforms and it works well for him. This is rebased over: linux-next branch in the PM tree. V4->V5: - Stephen boyd had some minor review comments and gave his Reviewed-by tag for the rest. Only 2 patches don't have his RBY tag. - Individual patches contain the version history from V4 to V5. V3->V4: - Separate out cpu-supply fix in the binding in a separate patch (Mark). - Add more documentation to the binding to explain that the relation to the supplies and the order of programming them is left for the platform specific bindings and that every platform using multiple regulators for their devices needs to provide a separate binding document explaining their implementation (Mark). - @Rob and Stephen: I have kept your Acks for the bindings as the bindings only got a bit reworded (improved) since the time you guys Acked them. Please let me know if you want more improvement in the bindings now. - V4 for 10/10 was sent earlier, which added a missing rcu_read_unlock(). Nothing else changed in it. - Added some missing Kernel documentation comments V2->V3: - The last patch is new - Removed a debug leftover pr_info() message - Renamed few names as s/set_rate/set_opp - Removed a TODO comment (as it is done now with this series) - created struct for min_uV and max_uV - kerneldoc comments for structures in pm_opp.h - s/const char */const char * const - use kasprintf() - Some more minor reformatting - More Ack/RBY tags added V1->V2: - Ack from Rob for 1st patch - Moved the supplies structure to pm_opp.h (Dave) - Fixed an compilation warning. -- viresh [1] https://marc.info/?l=linux-pm&m=145684495832764&w=2 [2] https://marc.info/?l=linux-kernel&m=147924789305276&w=2 Viresh Kumar (10): PM / OPP: Fix incorrect cpu-supply property in binding PM / OPP: Reword binding supporting multiple regulators per device PM / OPP: Don't use OPP structure outside of rcu protected section PM / OPP: Manage supply's voltage/current in a separate structure PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage() PM / OPP: Add infrastructure to manage multiple regulators PM / OPP: Separate out _generic_set_opp() PM / OPP: Allow platform specific custom set_opp() callbacks PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators() PM / OPP: Don't assume platform doesn't have regulators Documentation/devicetree/bindings/opp/opp.txt | 27 +- drivers/base/power/opp/core.c | 536 -- drivers/base/power/opp/debugfs.c | 52 ++- drivers/base/power/opp/of.c | 105 +++-- drivers/base/power/opp/opp.h | 22 +- drivers/cpufreq/cpufreq-dt.c | 9 +- include/linux/pm_opp.h| 69 +++- 7 files changed, 634 insertions(+), 186 deletions(-) -- 2.7.1.410.g6faf27b
Re: [PATCH v3 0/3] powernv:stop: Use psscr_val,mask provided by firmware
On 10/11/16 18:54, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > This is the third iteration of the patchset to use the psscr_val and > psscr_mask provided by the firmware for each of the stop states. > > The previous version can be found here: > > [v2]: https://lkml.org/lkml/2016/10/27/143 > [v1]: https://lkml.org/lkml/2016/9/29/45 > > This version fixes a couple of bugs pertaining to strncpy and > initialization of the target-residency values of nap and sleep > which were pointed out by Paul and Oliver in the earlier version. > > Synopsis > == > In the current implementation, the code for ISA > v3.0 stop implementation has a couple of shortcomings. > > a) The code hand-codes the values for ESL,EC,TR,MTL bits of PSSCR and >uses only the RL field from the firmware. While this is not >incorrect, since the hand-coded values are legitimate, it is not a >very flexible design since the firmware has the capability to >communicate these values via the "ibm,cpu-idle-state-psscr" and >"ibm,cpu-idle-state-psscr-mask" properties. In case where the >firmware provides values for these fields that is different from >the hand-coded values, the current code will not work as intended. > > b) Due to issue a), the current code assumes that ESL=EC=1 for all the >stop states and hence the wakeup from the stop instruction will >happen at 0x100, the system-reset vector. However, the ISA v3.0 >allows the ESL=EC=0 behaviour where the corresponding stop-state >loses no state and wakes up from the subsequent instruction. The >current code doesn't handle this case. > Sounds reasonable Balbir Singh.
Re: linux-next: manual merge of the net-next tree with the net tree
On 11/29/2016 01:31 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/sched/cls_flower.c
between commit:
d936377414fa ("net, sched: respect rcu grace period on cls destruction")
from the net tree and commit:
13fa876ebd03 ("net/sched: cls_flower: merge filter delete/destroy common
code")
from the net-next 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.
Looks good to me, thanks!
[PATCH v4] fsl/usb: Workarourd for USB erratum-A005697
The EHCI specification states the following in the SUSP bit description:
In the Suspend state, the port is sensitive to resume detection.
Note that the bit status does not change until the port is suspended and
that there may be a delay in suspending a port if there is a transaction
currently in progress on the USB.
However, in NXP USBDR controller, the PORTSCx[SUSP] bit changes immediately
when the application sets it and not when the port is actually suspended.
So the application must wait for at least 10 milliseconds after a port
indicates that it is suspended, to make sure this port has entered
suspended state before initiating this port resume using the Force Port
Resume bit. This bit is for NXP controller, not EHCI compatible.
Signed-off-by: Changming Huang
Signed-off-by: Ramneek Mehresh
---
Changes in v4:
- release spinlock before sleeping
Changes in v3:
- add 10ms delay in function ehci_hub_control
- fix typos
Changes in v2:
- move sleep out of spin-lock
- add more comment for this workaround
drivers/usb/host/ehci-fsl.c |3 +++
drivers/usb/host/ehci-hub.c | 14 ++
drivers/usb/host/ehci.h |8
drivers/usb/host/fsl-mph-dr-of.c |2 ++
include/linux/fsl_devices.h |1 +
5 files changed, 28 insertions(+)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 9f5ffb6..91701cc 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -286,6 +286,9 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->has_fsl_erratum_a005275 == 1)
ehci->has_fsl_hs_errata = 1;
+ if (pdata->has_fsl_erratum_a005697 == 1)
+ ehci->has_fsl_susp_errata = 1;
+
if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
(pdata->operating_mode == FSL_USB2_DR_OTG))
if (ehci_fsl_setup_phy(hcd, pdata->phy_mode, 0))
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 74f62d6..df169c8 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -310,6 +310,14 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
}
spin_unlock_irq(&ehci->lock);
+ if (changed && ehci_has_fsl_susp_errata(ehci))
+ /*
+* Wait for at least 10 millisecondes to ensure the controller
+* enter the suspend status before initiating a port resume
+* using the Force Port Resume bit (Not-EHCI compatible).
+*/
+ usleep_range(1, 2);
+
if ((changed && ehci->has_tdi_phy_lpm) || fs_idle_delay) {
/*
* Wait for HCD to enter low-power mode or for the bus
@@ -1200,6 +1208,12 @@ int ehci_hub_control(
wIndex, (temp1 & HOSTPC_PHCD) ?
"succeeded" : "failed");
}
+ if (ehci_has_fsl_susp_errata(ehci)) {
+ /* 10ms for HCD enter suspend */
+ spin_unlock_irqrestore(&ehci->lock, flags);
+ usleep_range(1, 2);
+ spin_lock_irqsave(&ehci->lock, flags);
+ }
set_bit(wIndex, &ehci->suspended_ports);
break;
case USB_PORT_FEAT_POWER:
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 3f3b74a..a8e3617 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -219,6 +219,7 @@ struct ehci_hcd { /* one per controller */
unsignedno_selective_suspend:1;
unsignedhas_fsl_port_bug:1; /* FreeScale */
unsignedhas_fsl_hs_errata:1;/* Freescale HS quirk */
+ unsignedhas_fsl_susp_errata:1; /* NXP SUSP quirk */
unsignedbig_endian_mmio:1;
unsignedbig_endian_desc:1;
unsignedbig_endian_capbase:1;
@@ -710,6 +711,13 @@ struct ehci_tt {
#endif
/*
+ * Some Freescale/NXP processors have an erratum (USB A-005697)
+ * in which we need to wait for 10ms for bus to enter suspend mode
+ * after setting SUSP bit.
+ */
+#define ehci_has_fsl_susp_errata(e)((e)->has_fsl_susp_errata)
+
+/*
* While most USB host controllers implement their registers in
* little-endian format, a minority (celleb companion chip) implement
* them in big endian format.
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index f07ccb2..e90ddb5 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -226,6 +226,8 @@ static int fsl_usb2_mph_dr_of_probe(struct platform_device
*ofdev)
of_property_read_bool(np, "fsl,usb-erratum-a007792");
pdata->has_fsl_erratum_a005275 =
of_proper
Re: [PATCH v3 3/3] powernv: Pass PSSCR value and mask to power9_idle_stop
Hi Michael, On Wed, Nov 23, 2016 at 08:51:10PM +1100, Michael Ellerman wrote: > "Gautham R. Shenoy" writes: > > > From: "Gautham R. Shenoy" > > > > The power9_idle_stop method currently takes only the requested stop > > level as a parameter and picks up the rest of the PSSCR bits from a > > hand-coded macro. This is not a very flexible design, especially when > > the firmware has the capability to communicate the psscr value and the > > mask associated with a particular stop state via device tree. > > > > This patch modifies the power9_idle_stop API to take as parameters the > > PSSCR value and the PSSCR mask corresponding to the stop state that > > needs to be set. These PSSCR value and mask are respectively obtained > > by parsing the "ibm,cpu-idle-state-psscr" and > > "ibm,cpu-idle-state-psscr-mask" fields from the device tree. > > > > In addition to this, the patch adds support for handling stop states > > for which ESL and EC bits in the PSSCR are zero. As per the > > architecture, a wakeup from these stop states resumes execution from > > the subsequent instruction as opposed to waking up at the System > > Vector. > > > > The older firmware sets only the Requested Level (RL) field in the > > psscr and psscr-mask exposed in the device tree. For older firmware > > where psscr-mask=0xf, this patch will set the default sane values that > > the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and > > TR). > > So we're using psscr-mas=0xf as a signal that we're running on old > firmware. > > That's OK I think, but please send a patch to document it in the device > tree binding. > > And call it out below in the code. Sure will do this! Thanks for reviewing the code. > > cheers > -- Thanks and Regards gautham.
Re: [PATCH v3 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.
Hi Michael, On Wed, Nov 23, 2016 at 08:49:08PM +1100, Michael Ellerman wrote: > "Gautham R. Shenoy" writes: > > > diff --git a/drivers/cpuidle/cpuidle-powernv.c > > b/drivers/cpuidle/cpuidle-powernv.c > > index 7fe442c..9240e08 100644 > > --- a/drivers/cpuidle/cpuidle-powernv.c > > +++ b/drivers/cpuidle/cpuidle-powernv.c > > @@ -243,28 +262,31 @@ static int powernv_add_idle_states(void) > > */ > > if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS) > > continue; > > + /* > > +* Firmware passes residency and latency values in ns. > > +* cpuidle expects it in us. > > +*/ > > + exit_latency = ((unsigned int)latency_ns[i]) / 1000; > > + target_residency = (!rc) ? ((unsigned int)residency_ns[i]) : 0; > > + target_residency /= 1000; > > Urk. > > Can you just do it normally: > > if (rc == 0) > target_residency = (unsigned int)residency_ns[i] / 1000; Wrote this in a non-standard manner since the normal way would exceed 80 chars. > > I also don't see why you need the cast? It is a remnant from the previous code. But I see your point, the cast is redundant, and removing it will make it possible to implement this in the normal manner without checkpatch warning about it. > > cheers > -- Thanks and Regards gautham.
Re: net: deadlock on genl_mutex
On Mon, 2016-11-28 at 22:59 -0700, subas...@codeaurora.org wrote: > > > > Issue was reported yesterday and is under investigation. > > > > > > http://marc.info/?l=linux-netdev&m=148014004331663&w=2 > > > > > > Thanks ! > > Hi Dmitry > > Can you try the patch below with your reproducer? I haven't seen similar > crashes reported after this (or even with Eric's patch). > > https://patchwork.ozlabs.org/patch/699937/ Yeah, I will post my patch on top of this one.
Re: [PATCH 3/5] migrate: Add copy_page_mt to use multi-threaded page migration.
On 11/28/2016 08:33 PM, Zi Yan wrote:
> On 24 Nov 2016, at 4:26, Anshuman Khandual wrote:
>
>> On 11/22/2016 09:55 PM, Zi Yan wrote:
>>> From: Zi Yan
>>>
>>> From: Zi Yan
>>
>> Please fix these.
>>
>>>
>>> Internally, copy_page_mt splits a page into multiple threads
>>> and send them as jobs to system_highpri_wq.
>>
>> The function should be renamed as copy_page_multithread() or at
>> the least copy_page_mthread() to make more sense. The commit
>> message needs to more comprehensive and detailed.
>>
>
> Sure.
>
>>>
>>> Signed-off-by: Zi Yan
>>> Signed-off-by: Zi Yan
>>> ---
>>> include/linux/highmem.h | 2 ++
>>> kernel/sysctl.c | 1 +
>>> mm/Makefile | 2 ++
>>> mm/copy_page.c | 96
>>> +
>>> 4 files changed, 101 insertions(+)
>>> create mode 100644 mm/copy_page.c
>>>
>>> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
>>> index bb3f329..519e575 100644
>>> --- a/include/linux/highmem.h
>>> +++ b/include/linux/highmem.h
>>> @@ -236,6 +236,8 @@ static inline void copy_user_highpage(struct page *to,
>>> struct page *from,
>>>
>>> #endif
>>>
>>> +int copy_page_mt(struct page *to, struct page *from, int nr_pages);
>>> +
>>> static inline void copy_highpage(struct page *to, struct page *from)
>>> {
>>> char *vfrom, *vto;
>>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>>> index 706309f..d54ce12 100644
>>> --- a/kernel/sysctl.c
>>> +++ b/kernel/sysctl.c
>>> @@ -97,6 +97,7 @@
>>>
>>> #if defined(CONFIG_SYSCTL)
>>>
>>> +
>>
>> I guess this is a stray code change.
>>
>>> /* External variables not in a header file. */
>>> extern int suid_dumpable;
>>> #ifdef CONFIG_COREDUMP
>>> diff --git a/mm/Makefile b/mm/Makefile
>>> index 295bd7a..467305b 100644
>>> --- a/mm/Makefile
>>> +++ b/mm/Makefile
>>> @@ -41,6 +41,8 @@ obj-y := filemap.o mempool.o
>>> oom_kill.o \
>>>
>>> obj-y += init-mm.o
>>>
>>> +obj-y += copy_page.o
>>
>> Its getting compiled all the time. Dont you want to make it part of
>> of a new config option which will cover for all these code for multi
>> thread copy ?
>
> I can do that.
>
>>> +
>>> ifdef CONFIG_NO_BOOTMEM
>>> obj-y += nobootmem.o
>>> else
>>> diff --git a/mm/copy_page.c b/mm/copy_page.c
>>> new file mode 100644
>>> index 000..ca7ce6c
>>> --- /dev/null
>>> +++ b/mm/copy_page.c
>>> @@ -0,0 +1,96 @@
>>> +/*
>>> + * Parallel page copy routine.
>>> + *
>>> + * Zi Yan
>>> + *
>>> + */
>>
>> No, this is too less. Please see other files inside mm directory as
>> example.
>>
>
> Sure, I will add more description here.
>
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +
>>> +const unsigned int limit_mt_num = 4;
>>
>> From where this number 4 came from ? At the very least it should be
>> configured from either a sysctl variable or from a sysfs file, so
>> that user will have control on number of threads used for copy. But
>> going forward this should be derived out a arch specific call back
>> which then analyzes NUMA topology and scheduler loads to figure out
>> on how many threads should be used for optimum performance of page
>> copy.
>
> I will expose this to sysctl.
When you do, if the user specifies a number, take it after some basic
sanity checks but if the user specifies "default" then we should fall
back to arch specific call back to figure out how many of them should
be used.
>
> For finding optimum performance, can we do a boot time microbenchmark
> to find the thread number?
Hmm, not sure that much of measurement is required. I wonder any other
part of kernel does this kind of thing ? Arch call back should be able
to tell you based on already established facts. IMHO that should be
enough.
>
> For scheduler loads, can we traverse all online CPUs and use idle CPUs
> by checking idle_cpu()?
Arch call back should return a nodemask pointing out exactly which CPUs
should be used for the copy purpose. The nodemask should be calculated
based on established facts of multi threaded performance, NUMA affinity
(based on source and destination pages we are trying to migrate) and
scheduler run queue states. But this function has to be fast enough
without eating into the benefits of multi threaded copy. idle_cpu()
check should be a very good starting point.
>
>
>>> +
>>> +/* multi-threaded copy page
>>> */
>>> +
>>
>> Please use standard exported function description semantics while
>> describing this new function. I think its a good function to be
>> exported as a symbol as well.
>>
>>> +struct copy_page_info {
>>
>> s/copy_page_info/mthread_copy_struct/
>>
>>> + struct work_struct copy_page_work;
>>> + char *to;
>>> + char *from;
>>
>> Swap the order of 'to' and 'from'.
>>
>>> + unsigned long chunk_size;
>>
>> Just 'size' should be fine.
>>
>>> +};
>>> +
>>> +static void copy_page_routine(char *vto, char *vfrom,
>>
>> s/copy_page_routine/mthre
Re: net: deadlock on genl_mutex
Issue was reported yesterday and is under investigation. http://marc.info/?l=linux-netdev&m=148014004331663&w=2 Thanks ! Hi Dmitry Can you try the patch below with your reproducer? I haven't seen similar crashes reported after this (or even with Eric's patch). https://patchwork.ozlabs.org/patch/699937/ -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2] net: macb: Write only necessary bits in NCR in macb reset
In macb_reset_hw, use read-modify-write to disable RX and TX.
Existing settings, for ex. management port enable,
are being cleared in the current implementation.
Also certain reserved bits are read only.
Hence it is better to use read-modify-write.
Use the same method for clearing statistics as well.
Signed-off-by: Harini Katakam
---
v2:
Make ctrl type as u32
Improve commit description
---
drivers/net/ethernet/cadence/macb.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 0e489bb..2ce3407 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1744,14 +1744,18 @@ static void macb_reset_hw(struct macb *bp)
{
struct macb_queue *queue;
unsigned int q;
+ u32 ctrl;
/* Disable RX and TX (XXX: Should we halt the transmission
* more gracefully?)
*/
- macb_writel(bp, NCR, 0);
+ ctrl = macb_readl(bp, NCR);
+ ctrl &= ~(MACB_BIT(RE) | MACB_BIT(TE));
+ macb_writel(bp, NCR, ctrl);
/* Clear the stats registers (XXX: Update stats first?) */
- macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
+ ctrl |= MACB_BIT(CLRSTAT);
+ macb_writel(bp, NCR, ctrl);
/* Clear all status flags */
macb_writel(bp, TSR, -1);
--
2.7.4
Re: [PATCH v2] vfs: fix put_compat_statfs64() does not handle errors
sorry, ping for comments~
On 15 November 2016 at 17:19, Li Wang wrote:
> put_compat_statfs64() does NOT return -1 and setting errno to EOVERFLOW
> when some variables(like: f_bsize) overflowed in the returned struct.
>
> The reason is that the ubuf->f_blocks is __u64 type, it couldn't be
> 4bits as the judgement in put_comat_statfs64(). Here correct the
> __u32 variables(in struct compat_statfs64) for comparison.
>
> reproducer:
> step1. mount hugetlbfs with two different pagesize on ppc64 arch.
>
> $ hugeadm --pool-pages-max 16M:0
> $ hugeadm --create-mount
> $ mount | grep -i hugetlbfs
> none on /var/lib/hugetlbfs/pagesize-16MB type hugetlbfs
> (rw,relatime,seclabel,pagesize=16777216)
> none on /var/lib/hugetlbfs/pagesize-16GB type hugetlbfs
> (rw,relatime,seclabel,pagesize=17179869184)
>
> step2. compile & run this C program.
>
> $ cat statfs64_test.c
>
> #define _LARGEFILE64_SOURCE
> #include
> #include
> #include
>
> int main()
> {
> struct statfs64 sb;
> int err;
>
> err = syscall(SYS_statfs64, "/var/lib/hugetlbfs/pagesize-16GB",
> sizeof(sb), &sb);
> if (err)
> return -1;
>
> printf("sizeof f_bsize = %d, f_bsize=%ld\n", sizeof(sb.f_bsize),
> sb.f_bsize);
>
> return 0;
> }
>
> $ gcc -m32 statfs64_test.c
> $ ./a.out
> sizeof f_bsize = 4, f_bsize=0
>
> Signed-off-by: Li Wang
> ---
> fs/compat.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/compat.c b/fs/compat.c
> index bd064a2..543b48c 100644
> --- a/fs/compat.c
> +++ b/fs/compat.c
> @@ -253,9 +253,9 @@ static int put_compat_statfs(struct compat_statfs __user
> *ubuf, struct kstatfs *
>
> static int put_compat_statfs64(struct compat_statfs64 __user *ubuf, struct
> kstatfs *kbuf)
> {
> - if (sizeof ubuf->f_blocks == 4) {
> - if ((kbuf->f_blocks | kbuf->f_bfree | kbuf->f_bavail |
> -kbuf->f_bsize | kbuf->f_frsize) & 0xULL)
> + if (sizeof(ubuf->f_bsize) == 4) {
> + if ((kbuf->f_type | kbuf->f_bsize | kbuf->f_namelen |
> +kbuf->f_frsize | kbuf->f_flags) & 0xULL)
> return -EOVERFLOW;
> /* f_files and f_ffree may be -1; it's okay
> * to stuff that into 32 bits */
> --
> 1.8.3.1
>
--
Regards,
Li Wang
Email: wangli.a...@gmail.com
Re: perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start
On Mon, Nov 28, 2016 at 04:40:21PM -0800, Paul E. McKenney wrote:
> On Mon, Nov 28, 2016 at 03:54:11PM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 24, 2016 at 12:33:48PM -0500, Vince Weaver wrote:
> > >
> > > This is on a skylake machine, linus git as of yesterday after the various
> > > kasan-related fixes went in. Not sure if there were any that hadn't hit
> > > upstream yet.
> > >
> > > Anyway I can't tell from this one what the actual trigger is. After this
> > > mess the fuzzer process was locked, udev started complaining, and it
> > > eventually died completely after a few hours of repeated messages like
> > > this.
> > >
> > > [38898.373183] INFO: rcu_sched self-detected stall on CPU
> > > [38898.378452] 7-...: (5249 ticks this GP) idle=727/141/0
> > > softirq=3141908/3141908 fqs=2625
> > > [38898.381211] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > [38898.381214] 0-...: (1 GPs behind) idle=05f/141/2
> > > softirq=3285458/3285459 fqs=2625
> > > [38898.381217] 7-...: (5249 ticks this GP) idle=727/141/0
> > > softirq=3141908/3141908 fqs=2625
> > > [38898.381218] (detected by 1, t=5252 jiffies, g=3685053, c=3685052,
> > > q=32)
> > > [38898.381244]
> > > ==
> > > [38898.381247] BUG: KASAN: stack-out-of-bounds in
> > > __unwind_start+0x1a2/0x1c0 at addr 8801e9727c28
> > > [38898.381248] Read of size 8 by task swapper/1/0
> > > [38898.381250] page:ea0007a5c9c0 count:0 mapcount:0 mapping:
> > > (null) index:0x0
> > > [38898.381251] flags: 0x280()
> > > [38898.381251] page dumped because: kasan: bad access detected
> > > [38898.381328] Memory state around the buggy address:
> > > [38898.381330] 8801e9727b00: 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 00 00 00
> > > [38898.381331] 8801e9727b80: 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 00 00 00
> > > [38898.381332] >8801e9727c00: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f3
> > > f3 f3 f3
> > > [38898.381333] ^
> > > [38898.381334] 8801e9727c80: 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 00 00 f1
> > > [38898.381335] 8801e9727d00: f1 f1 f1 00 00 00 f4 f2 f2 f2 f2 00 00
> > > 00 00 f3
> > > [38898.381335]
> > > ==
> > > [38898.510702] (t=5284 jiffies g=3685053 c=3685052 q=32)
> > >
> > > (That's all, the report above repeats but no useful things like a
> > > backtrace are ever printed)
> >
> > After looking at the RCU stall detection code, I think the KASAN error
> > and missing stack dump aren't very surprising. RCU calls the scheduler
> > dump_cpu_task() function, which seems inherently problematic: it tries
> > to dump the stack of a task while it's running on another CPU.
> >
> > There are some issues with that:
> >
> > 1) There's no way to find the starting frame of a currently running task
> >from another CPU.
> >
> >In fact, I'm wondering how dump_cpu_task() ever worked at all? It
> >seems like you'd have to get lucky that the sp/bp registers stored by
> >the last call to schedule() happen to point to a currently valid
> >stack frame.
> >
> > 2) Even if there were a way to find the starting frame, it's racy
> >because the target task could be overwriting the stack while we're
> >reading it.
> >
> > 3) IRQ/exception stack dumps would be missing anyway because the stack
> >dump code only looks at the current CPU's interrupt stacks.
> >
> > Maybe dump_cpu_task() should instead run the stack dump directly from
> > the target CPU, e.g. with trigger_single_cpu_backtrace() or
> > smp_call_function_single()?
> >
> > Paul, Peter, Ingo, any thoughts?
>
> We used to do that, but the resulting NMIs were problematic on some
> platforms. Perhaps things have gotten better?
Did a little digging on git blame and found the following commit (which
seems to be the cause of the KASAN warning and missing stack dump):
bc1dce514e9b ("rcu: Don't use NMIs to dump other CPUs' stacks")
I presume this commit is still needed because of the NMI printk deadlock
issues which were discussed at Kernel Summit. I guess those issues need
to be sorted out before the above commit can be reverted.
--
Josh
Re: [PATCH v3 1/5] thermal: rockchip: improve conversion error messages
Hi,
On Mon, Nov 28, 2016 at 05:51:55PM -0800, Eduardo Valentin wrote:
> On Mon, Nov 28, 2016 at 07:12:00PM +0800, Caesar Wang wrote:
> > From: Brian Norris
> >
> > These error messages don't give much information about what went wrong.
> > It would be nice, for one, to see what invalid temperature was being
> > requested when conversion fails. It's also good to return an error when
> > we can't handle a conversion properly.
> >
> > While we're at it, fix the grammar too.
> >
> > Signed-off-by: Brian Norris
> > Signed-off-by: Caesar Wang
> >
> > ---
> >
> > Changes in v3: None
> > Changes in v2: None
> > Changes in v1:
> > - The original Brian posted on https://patchwork.kernel.org/patch/9437686
> > Note: it'd probably be even nicer to know which sensor this was, but we've
> > kinda abstracted that one away by this point...
> >
> > drivers/thermal/rockchip_thermal.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/rockchip_thermal.c
> > b/drivers/thermal/rockchip_thermal.c
> > index b811b0f..26c247c 100644
> > --- a/drivers/thermal/rockchip_thermal.c
> > +++ b/drivers/thermal/rockchip_thermal.c
> > @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct
> > chip_tsadc_table table,
> > }
> >
> > exit:
> > - pr_err("Invalid the conversion, error=%d\n", error);
> > + pr_err("%s: invalid temperature, temp=%d error=%d\n",
> > + __func__, temp, error);
> > return error;
> > }
> >
> > @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct
> > chip_tsadc_table table, u32 code,
> > }
> > break;
> > default:
> > - pr_err("Invalid the conversion table\n");
> > + pr_err("%s: invalid conversion table, mode=%d\n",
> > + __func__, table.mode);
>
> Given that we are improving messages, would it be more informative to
> say that you have an invalid table mode?
I considered the mode and ID listing to go hand in hand, so it was the
whole table that is wrong. But it is just as well to say the "table
mode" is wrong.
Maybe even better: "%s: unknown table mode: %d\n".
And I guess same answer for patch 4, where you had the same question.
Brian
> > + return -EINVAL;
> > }
> >
> > /*
> > --
> > 2.7.4
> >
Re: [patch net] net: fec: cache statistics while device is down
> > > >+ fec_enet_update_ethtool_stats(ndev); > >+ > If user never open the interface, ethtool_stats[] always is 0 that are not > expected. > So, it also should be called at . fec_enet_init() ? I don't think that zero stats is wrong for never-opened interface. However a call at init path won't hurt, so I'll add it, just to clear the question. Nikita
[PATCH V3] PM / OPP: Don't remove the first cpu in the mask before removing others
Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.
This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.
But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.
In order to fix that up properly, we need to revisit APIs like
dev_pm_opp_set_regulator() and make them talk in terms of cookies
provided by the OPP core. But such a solution will be hard to backport
to stable kernels.
This patch attempts to fix this problem (in a Hacky way) by specially
handling the first cpu in the mask. A FIXME is also added to make sure
that this Hack doesn't get unnoticed later on.
Cc: # v4.4+
Signed-off-by: Viresh Kumar
---
V2->V3:
- Fix $Subject, which carried text from V1.
V1->V2:
- A completely different approach, more of hack so that backport to
stable kernels can be done easily.
- A more comprehensive solution is required to fix the design flaws.
drivers/base/power/opp/cpu.c | 50 +++-
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 8c3434bdb26d..5d1b0f98bcb0 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -118,26 +118,46 @@ void dev_pm_opp_free_cpufreq_table(struct device *dev,
EXPORT_SYMBOL_GPL(dev_pm_opp_free_cpufreq_table);
#endif /* CONFIG_CPU_FREQ */
+void _cpu_remove_table(unsigned int cpu, bool of)
+{
+ struct device *cpu_dev = get_cpu_device(cpu);
+
+ if (!cpu_dev) {
+ pr_err("%s: failed to get cpu%d device\n", __func__, cpu);
+ return;
+ }
+
+ if (of)
+ dev_pm_opp_of_remove_table(cpu_dev);
+ else
+ dev_pm_opp_remove_table(cpu_dev);
+}
+
void _dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask, bool of)
{
- struct device *cpu_dev;
- int cpu;
+ struct cpumask tmpmask;
+ int cpu, first_cpu;
WARN_ON(cpumask_empty(cpumask));
- for_each_cpu(cpu, cpumask) {
- cpu_dev = get_cpu_device(cpu);
- if (!cpu_dev) {
- pr_err("%s: failed to get cpu%d device\n", __func__,
- cpu);
- continue;
- }
-
- if (of)
- dev_pm_opp_of_remove_table(cpu_dev);
- else
- dev_pm_opp_remove_table(cpu_dev);
- }
+ /*
+* The first cpu in the cpumask is important as that is used to create
+* the opp-table initially and routines like dev_pm_opp_put_regulator()
+* will expect the list-dev for the first CPU to be present while such
+* routines are called, otherwise we will fail to find the opp-table for
+* such devices.
+*
+* FIXME: Cleanup this mess and implement cookie based solutions instead
+* of working on the device pointer.
+*/
+ first_cpu = cpumask_first(cpumask);
+ cpumask_copy(&tmpmask, cpumask);
+ cpumask_clear_cpu(first_cpu, &tmpmask);
+
+ for_each_cpu(cpu, &tmpmask)
+ _cpu_remove_table(cpu, of);
+
+ _cpu_remove_table(first_cpu, of);
}
/**
--
2.7.1.410.g6faf27b
Re: [PATCH v2 0/3] increase TSCADC clock to 24MHz and fix ti,charge-delay to represent in nS
On Friday 25 November 2016 03:29 PM, Lee Jones wrote: > On Fri, 25 Nov 2016, Mugunthan V N wrote: > >> Hi Dmitry Torokhov, >> >> On Thursday 10 November 2016 10:05 PM, Mugunthan V N wrote: >>> This patch series enables ADC to be clocked at 24MHz as the >>> TI AM335x ADC driver has already adopted to use DMA to transfer >>> ADC samples. Now ADC can generated upto 800K Samples per second >>> with the patch [1] on AM335x BBB and AM437x GP EVM. >>> >>> when ADC ref clock is set at 24MHz, I am seeing some issue with >>> touch screen pointer as the pointer jumps to random locations >>> with free draw application. The issue is due to increase in ADC >>> clock and charge delay for the touchscreen ADC line duration >>> reduced. >>> >>> So the notation of ti,charge-delay in terms of ADC clock is >>> wrong, it has to be represented in time and driver has to convert >>> the charge delay time to ADC clocks based on what ADC clock >>> frequency is set. >>> >>> Measured the performance with the iio_generic_buffer with the >>> patch [2] applied >>> >>> Verified the touch screen on AM335x GP EVM and AM335x BBB LCD7 >>> cape with [3] dts for display and touch screen to work. >>> >> >> Since there are acks from DT and MFD maintainers, can you pull the patch >> series if you do not have any more comments. > > Cant do anything without *all* Acks. > Hi Dmitry Torokhov, Can you provide your inputs on the patch series. Regards Mugunthan V N
Re: [PATCH V2] PM / OPP: Allow inactive opp_device to be present in dev list
On 29-11-16, 11:04, Viresh Kumar wrote: Too stupid of me to not update the $subject. Sorry for the noise, will resend it shortly after making sure all text is fine. -- viresh
[PATCH V2] PM / OPP: Allow inactive opp_device to be present in dev list
Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.
This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.
But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.
In order to fix that up properly, we need to revisit APIs like
dev_pm_opp_set_regulator() and make them talk in terms of cookies
provided by the OPP core. But such a solution will be hard to backport
to stable kernels.
This patch attempts to fix this problem (in a Hacky way) by specially
handling the first cpu in the mask. A FIXME is also added to make sure
that this Hack doesn't get unnoticed later on.
Cc: # v4.4+
Signed-off-by: Viresh Kumar
---
V1->V2:
- A completely different approach, more of hack so that backport to
stable kernels can be done easily.
- A more comprehensive solution is required to fix the design flaws.
drivers/base/power/opp/cpu.c | 50 +++-
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 8c3434bdb26d..5d1b0f98bcb0 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -118,26 +118,46 @@ void dev_pm_opp_free_cpufreq_table(struct device *dev,
EXPORT_SYMBOL_GPL(dev_pm_opp_free_cpufreq_table);
#endif /* CONFIG_CPU_FREQ */
+void _cpu_remove_table(unsigned int cpu, bool of)
+{
+ struct device *cpu_dev = get_cpu_device(cpu);
+
+ if (!cpu_dev) {
+ pr_err("%s: failed to get cpu%d device\n", __func__, cpu);
+ return;
+ }
+
+ if (of)
+ dev_pm_opp_of_remove_table(cpu_dev);
+ else
+ dev_pm_opp_remove_table(cpu_dev);
+}
+
void _dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask, bool of)
{
- struct device *cpu_dev;
- int cpu;
+ struct cpumask tmpmask;
+ int cpu, first_cpu;
WARN_ON(cpumask_empty(cpumask));
- for_each_cpu(cpu, cpumask) {
- cpu_dev = get_cpu_device(cpu);
- if (!cpu_dev) {
- pr_err("%s: failed to get cpu%d device\n", __func__,
- cpu);
- continue;
- }
-
- if (of)
- dev_pm_opp_of_remove_table(cpu_dev);
- else
- dev_pm_opp_remove_table(cpu_dev);
- }
+ /*
+* The first cpu in the cpumask is important as that is used to create
+* the opp-table initially and routines like dev_pm_opp_put_regulator()
+* will expect the list-dev for the first CPU to be present while such
+* routines are called, otherwise we will fail to find the opp-table for
+* such devices.
+*
+* FIXME: Cleanup this mess and implement cookie based solutions instead
+* of working on the device pointer.
+*/
+ first_cpu = cpumask_first(cpumask);
+ cpumask_copy(&tmpmask, cpumask);
+ cpumask_clear_cpu(first_cpu, &tmpmask);
+
+ for_each_cpu(cpu, &tmpmask)
+ _cpu_remove_table(cpu, of);
+
+ _cpu_remove_table(first_cpu, of);
}
/**
--
2.7.1.410.g6faf27b
[PATCH update] mremap: move_ptes: check pte dirty after its removal
Linus found there still is a race in mremap after commit 5d1904204c99
("mremap: fix race between mremap() and page cleanning").
As described by Linus:
the issue is that another thread might make the pte be dirty (in
the hardware walker, so no locking of ours make any difference)
*after* we checked whether it was dirty, but *before* we removed it
from the page tables.
Fix it by moving the check after we removed it from the page table.
Suggested-by: Linus Torvalds
Signed-off-by: Aaron Lu
---
mm/huge_memory.c | 4 ++--
mm/mremap.c | 8 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index eff3de359d50..d4a6e4001512 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1456,9 +1456,9 @@ bool move_huge_pmd(struct vm_area_struct *vma, unsigned
long old_addr,
new_ptl = pmd_lockptr(mm, new_pmd);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
- if (pmd_present(*old_pmd) && pmd_dirty(*old_pmd))
- force_flush = true;
pmd = pmdp_huge_get_and_clear(mm, old_addr, old_pmd);
+ if (pmd_present(pmd) && pmd_dirty(pmd))
+ force_flush = true;
VM_BUG_ON(!pmd_none(*new_pmd));
if (pmd_move_must_withdraw(new_ptl, old_ptl) &&
diff --git a/mm/mremap.c b/mm/mremap.c
index 6ccecc03f56a..53df7ec8d2ba 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -149,14 +149,18 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t
*old_pmd,
if (pte_none(*old_pte))
continue;
+ pte = ptep_get_and_clear(mm, old_addr, old_pte);
/*
* We are remapping a dirty PTE, make sure to
* flush TLB before we drop the PTL for the
* old PTE or we may race with page_mkclean().
+*
+* This check has to be done after we removed the
+* old PTE from page tables or another thread may
+* dirty it after the check and before the removal.
*/
- if (pte_present(*old_pte) && pte_dirty(*old_pte))
+ if (pte_present(pte) && pte_dirty(pte))
force_flush = true;
- pte = ptep_get_and_clear(mm, old_addr, old_pte);
pte = move_pte(pte, new_vma->vm_page_prot, old_addr, new_addr);
pte = move_soft_dirty_pte(pte);
set_pte_at(mm, new_addr, new_pte, pte);
--
2.5.5
Re: [PATCH v2 3/4] dt-bindings: phy: Add support for QMP phy
Hi,
On Tue, Nov 29, 2016 at 4:25 AM, Stephen Boyd wrote:
> On 11/22, Vivek Gautam wrote:
>> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> new file mode 100644
>> index 000..ffb173b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,74 @@
>> +Qualcomm QMP PHY
>> +
>> +
>> +QMP phy controller supports physical layer functionality for a number of
>> +controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
>> +
>> +Required properties:
>> + - compatible: compatible list, contains:
>> +"qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
>> +"qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
>> + - reg: list of offset and length pair of the PHY register sets.
>> + at index 0: offset and length of register set for PHY common
>> + serdes block.
>> + from index 1 - N: offset and length of register set for each lane,
>> + for N number of phy lanes (ports).
>> + - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
>> + - #phy-cells: must be 1
>> +- Cell after phy phandle should be the port (lane) number.
>> + - clocks: a list of phandles and clock-specifier pairs,
>> +one for each entry in clock-names.
>> + - clock-names: must be "cfg_ahb" for phy config clock,
>> + "aux" for phy aux clock,
>> + "ref_clk" for 19.2 MHz ref clk,
>> + "ref_clk_src" for reference clock source,
>
> We typically leave "clk" out of clk names because it's redundant.
Right, will drop 'clk' from these names.
>
>> + "pipe" for pipe clock specific to
>> + each port/lane (Optional).
>
> The pipe clocks are orphaned right now. We should add an output
> clock from the phy to go into the controller and back into the
> phy if I recall correctly. The phy should be a clock provider
> itself so it can output the pipe clock source into GCC and back
> into the phy and controller.
>
>> + - resets: a list of phandles and reset controller specifier pairs,
>> +one for each entry in reset-names.
>> + - reset-names: must be "phy" for reset of phy block,
>> + "common" for phy common block reset,
>> + "cfg" for phy's ahb cfg block reset (Optional).
>> + "port" for reset specific to
>> + each port/lane (Optional).
>> + - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
>> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll
>> block.
>> +
>> +Optional properties:
>> + - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
>> + pll block.
>> +
>> +Example:
>> + pcie_phy: pciephy@34000 {
>
> pcie-phy or just phy as the node name?
How about just 'phy'? The label pcie_phy anyways explains the use.
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/4] dt-bindings: phy: Add support for QUSB2 phy
Hi Stephen, On Tue, Nov 29, 2016 at 4:19 AM, Stephen Boyd wrote: Thanks for reviewing the patch-series. > On 11/22, Vivek Gautam wrote: >> diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> new file mode 100644 >> index 000..38c8b30 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> @@ -0,0 +1,55 @@ >> +Optional properties: >> + - nvmem-cells: a list of phandles to nvmem cells that contain fused >> + tuning parameters for qusb2 phy, one for each entry >> + in nvmem-cell-names. >> + - nvmem-cell-names: must be "tune2_hstx_trim_efuse" for cell containing > > Do we really need efuse in the name? Seems redundant given this > is already an nvmem. Correct, we don't need 'efuse' in the name. Thanks for pointing out. Best Regards Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/4] dt-bindings: phy: Add support for QUSB2 phy
Hi Rob,
On Mon, Nov 28, 2016 at 7:49 PM, Rob Herring wrote:
Thanks for reviewing the patch.
> On Tue, Nov 22, 2016 at 05:32:40PM +0530, Vivek Gautam wrote:
>> Qualcomm chipsets have QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller.
>> Adding dt binding information for the same.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>>
>> Changes since v1:
>> - New patch, forked out of the original driver patch:
>>"phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
>> - Updated dt bindings to remove 'hstx-trim-bit-offset' and
>>'hstx-trim-bit-len' bindings.
>>
>> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 55
>> ++
>> 1 file changed, 55 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> new file mode 100644
>> index 000..38c8b30
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> @@ -0,0 +1,55 @@
>> +Qualcomm QUSB2 phy controller
>> +=
>> +
>> +QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
>> +
>> +Required properties:
>> + - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
>> + - reg: offset and length of the PHY register set.
>> + - #phy-cells: must be 0.
>> +
>> + - clocks: a list of phandles and clock-specifier pairs,
>> +one for each entry in clock-names.
>> + - clock-names: must be "cfg_ahb" for phy config clock,
>> + "ref_clk" for 19.2 MHz ref clk,
>> + "ref_clk_src" reference clock source.
>> + "iface" for phy interface clock (Optional).
>> +
>> + - vdd-phy-supply: Phandle to a regulator supply to PHY core block.
>> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll
>> block.
>> + - vdda-phy-dpdm: Phandle to 3.1V regulator supply to Dp/Dm port signals.
>
> Needs '-supply'
sure, will add.
>
>> +
>> + - resets: a list of phandles and reset controller specifier pairs,
>> +one for each entry in reset-names.
>> + - reset-names: must be "phy" for reset of phy block.
>> +
>> +Optional properties:
>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>> + tuning parameters for qusb2 phy, one for each entry
>> + in nvmem-cell-names.
>> + - nvmem-cell-names: must be "tune2_hstx_trim_efuse" for cell containing
>> + HS Tx trim value.
>> +
>> + - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
>> +
>> +Example:
>> + hsphy: qusb2phy@7411000 {
>
> usb-phy@...
Or may be just 'phy' for the node name, and then label could be 'usb_hs_phy'?
[...]
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] openvswitch: add sanity check in queue_userspace_packet.
On Mon, Nov 28, 2016 at 8:36 PM, Haishuang Yan
wrote:
> kernel will crash in oops if genlmsg_put return NULL,
> so add the sanity check.
>
> Signed-off-by: Haishuang Yan
> ---
> net/openvswitch/datapath.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 2d4c4d3..ceb1b1e 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -474,6 +474,10 @@ static int queue_userspace_packet(struct datapath *dp,
> struct sk_buff *skb,
>
> upcall = genlmsg_put(user_skb, 0, 0, &dp_packet_genl_family,
> 0, upcall_info->cmd);
> + if (!upcall) {
> + err = -EMSGSIZE;
> + goto out;
> + }
user_skb has already enough space allocated, so there is no need to
check upcall pointer.
Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
On 28-11-16, 18:46, Stephen Boyd wrote:
> Anyway, rant over, how about handing out the opp table pointer to
> the caller so they can pass it back in when they call the put
> side? That should fix the same problem if I understand correctly.
Hmm, so the problem is that all below routines (and their callers) need to get
updated:
int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
unsigned int count);
void dev_pm_opp_put_supported_hw(struct device *dev);
int dev_pm_opp_set_prop_name(struct device *dev, const char *name);
void dev_pm_opp_put_prop_name(struct device *dev);
struct opp_table *dev_pm_opp_set_regulator(struct device *dev, const char
*name);
void dev_pm_opp_put_regulator(struct opp_table *opp_table);
And that will make it difficult to get it back to stable kernels, specially
because they were all added in different kernel releases after 4.4.
And we also need to fix them properly, with something like a cookie instead of a
plain opp_table pointer.
I suggest this patch for the time being, with a big FIXME in it, so that we can
get it to stable kernels.
-8<-
diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 8c3434bdb26d..2e96efdb10b2 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -118,26 +118,45 @@ void dev_pm_opp_free_cpufreq_table(struct device *dev,
EXPORT_SYMBOL_GPL(dev_pm_opp_free_cpufreq_table);
#endif /* CONFIG_CPU_FREQ */
+void _cpu_remove_table(unsigned int cpu, bool of)
+{
+ struct device *cpu_dev = get_cpu_device(cpu);
+
+ if (!cpu_dev) {
+ pr_err("%s: failed to get cpu%d device\n", __func__, cpu);
+ return;
+ }
+
+ if (of)
+ dev_pm_opp_of_remove_table(cpu_dev);
+ else
+ dev_pm_opp_remove_table(cpu_dev);
+}
+
void _dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask, bool of)
{
struct device *cpu_dev;
- int cpu;
+ int cpu, first_cpu;
WARN_ON(cpumask_empty(cpumask));
- for_each_cpu(cpu, cpumask) {
- cpu_dev = get_cpu_device(cpu);
- if (!cpu_dev) {
- pr_err("%s: failed to get cpu%d device\n", __func__,
- cpu);
- continue;
- }
-
- if (of)
- dev_pm_opp_of_remove_table(cpu_dev);
- else
- dev_pm_opp_remove_table(cpu_dev);
- }
+ /*
+* The first cpu in the cpumask is important as that is used to create
+* the opp-table initially and routines like dev_pm_opp_put_regulator()
+* will expect the list-dev for the first CPU to be present while such
+* routines are called, otherwise we will fail to find the opp-table for
+* such devices.
+*
+* FIXME: Cleanup this mess and implement cookie based solutions instead
+* of working on the device pointer.
+*/
+ first_cpu = cpumask_first(cpumask);
+ cpumask_clear_cpu(first_cpu, cpumask);
+
+ for_each_cpu(cpu, cpumask)
+ _cpu_remove_table(cpu, of);
+
+ _cpu_remove_table(first_cpu, of);
}
/**
--
viresh
Re: [PATCH 1/5] mm: migrate: Add mode parameter to support additional page copy routines.
On 11/28/2016 08:43 PM, Zi Yan wrote: > On 24 Nov 2016, at 18:56, Balbir Singh wrote: > >> > On 23/11/16 03:25, Zi Yan wrote: >>> >> From: Zi Yan >>> >> >>> >> From: Zi Yan >>> >> >>> >> migrate_page_copy() and copy_huge_page() are affected. >>> >> >>> >> Signed-off-by: Zi Yan >>> >> Signed-off-by: Zi Yan >>> >> --- >>> >> fs/aio.c| 2 +- >>> >> fs/hugetlbfs/inode.c| 2 +- >>> >> fs/ubifs/file.c | 2 +- >>> >> include/linux/migrate.h | 6 -- >>> >> mm/migrate.c| 14 -- >>> >> 5 files changed, 15 insertions(+), 11 deletions(-) >>> >> >>> >> diff --git a/fs/aio.c b/fs/aio.c >>> >> index 428484f..a67c764 100644 >>> >> --- a/fs/aio.c >>> >> +++ b/fs/aio.c >>> >> @@ -418,7 +418,7 @@ static int aio_migratepage(struct address_space >>> >> *mapping, struct page *new, >>> >> * events from being lost. >>> >> */ >>> >> spin_lock_irqsave(&ctx->completion_lock, flags); >>> >> -migrate_page_copy(new, old); >>> >> +migrate_page_copy(new, old, 0); >> > >> > Can we have a useful enum instead of 0, its harder to read and understand >> > 0 > How about MIGRATE_SINGLETHREAD = 0 ? Right, should be an enum declaration for all kind of single page copy process. Now we have just two. We dont have to mention number of threads in the multi threaded one. MIGRATE_SINGLETHREAD MIGRATE_MULTITHREAD
linux-next: Tree for Nov 29
Hi all, Changes since 20161128: The net-next tree gained conflicts against the net tree. The crypto tree gained a build failure so I used the version from next-20161128. The akpm-current tree still had its build failure for which I added a supplied patch. Non-merge commits (relative to Linus' tree): 8411 8329 files changed, 486291 insertions(+), 183081 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 244 trees (counting Linus' and 34 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (e5517c2a5a49 Linux 4.9-rc7) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to arm64 producing host-arch debs) Merging arc-current/for-curr (e5517c2a5a49 Linux 4.9-rc7) Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to definitions") Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (984d7a1ec67c powerpc/mm: Fixup kernel read only mapping) Merging sparc/master (16f46050e709 dbri: Fix compiler warning) Merging net/master (2dbb4c05d048 bpf/samples: Fix PT_REGS_IP on s390x and use it) Merging ipsec/master (6b2264878155 flowcache: Increase threshold for refusing new allocations) Merging netfilter/master (5173bc679dec netfilter: nat: fix crash when conntrack entry is re-used) Merging ipvs/master (9b6c14d51bd2 net: tcp response should set oif only if it is L3 master) Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 32-byte SSIDs) Merging mac80211/master (9590112241ba tipc: fix link statistics counter errors) Merging sound-current/for-linus (b5337cfe067e ALSA: hda/ca0132 - Add quirk for Alienware 15 R2 2016) Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)) Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5) Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3) Merging usb.current/usb-linus (e5517c2a5a49 Linux 4.9-rc7) Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong parenthesis in ffs_func_req_match()) Merging usb-serial-fixes/usb-linus (2ab13292d7a3 USB: serial: cp210x: add ID for the Zone DPMX) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu) Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5) Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5) Merging input-current/for-linus (e9fb7cc63801 Input: psmouse - disable automatic probing of BYD touchpads) Merging crypto-current/master (c8467f7a3620 crypto: scatterwalk - Remove unnecessary aliasing check in map_and_copy) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merging vfio-fixes/for-linus (05692d7005a3 vfio/pci: Fix integer overflows, bitmask check) Merging kselftest-fixes/fixes (1001354ca341 Linux 4.9-rc1) Merging backlight-fixes/for-b
[RFC][PATCH 4/5 v2] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally
In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.
This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
Cc: Laurent Pinchart
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2: Split into two patches to make change more clear
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9f8dffd..1948968 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -325,7 +325,7 @@ static void adv7511_set_link_config(struct adv7511 *adv7511,
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
}
-static void adv7511_power_on(struct adv7511 *adv7511)
+static void __adv7511_power_on(struct adv7511 *adv7511)
{
adv7511->current_edid_segment = -1;
@@ -359,24 +359,30 @@ static void adv7511_power_on(struct adv7511 *adv7511)
* Most of the registers are reset during power down or when HPD is low.
*/
regcache_sync(adv7511->regmap);
+}
+static void adv7511_power_on(struct adv7511 *adv7511)
+{
+ __adv7511_power_on(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_on(adv7511);
-
adv7511->powered = true;
}
-static void adv7511_power_off(struct adv7511 *adv7511)
+static void __adv7511_power_off(struct adv7511 *adv7511)
{
/* TODO: setup additional power down modes */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
ADV7511_POWER_POWER_DOWN,
ADV7511_POWER_POWER_DOWN);
regcache_mark_dirty(adv7511->regmap);
+}
+static void adv7511_power_off(struct adv7511 *adv7511)
+{
+ __adv7511_power_off(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_off(adv7511);
-
adv7511->powered = false;
}
--
2.7.4
[RFC][PATCH 5/5 v2] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors
on HiKey.
Investigating further, it seems some of the register state
in the regmap cache is somehow getting lost. Using the logic
in __adv7511_power_on/off() which syncs and dirtys the cache
avoids this issue.
Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls.
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
Cc: Laurent Pinchart
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2: Split into two patches to make the change more clear.
Also provided more rational as to why the change is
important.
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 1948968..487b33d 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -559,24 +559,13 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
unsigned int count;
/* Reading the EDID only works if the device is powered */
- if (!adv7511->powered) {
- regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
- ADV7511_POWER_POWER_DOWN, 0);
- if (adv7511->i2c_main->irq) {
- regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
-ADV7511_INT0_EDID_READY);
- regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
-ADV7511_INT1_DDC_ERROR);
- }
- adv7511->current_edid_segment = -1;
- }
+ if (!adv7511->powered)
+ __adv7511_power_on(adv7511);
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
if (!adv7511->powered)
- regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
- ADV7511_POWER_POWER_DOWN,
- ADV7511_POWER_POWER_DOWN);
+ __adv7511_power_off(adv7511);
kfree(adv7511->edid);
adv7511->edid = edid;
--
2.7.4
[RFC][PATCH 2/5 v2] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.
Thus this patch replaces drm_helper_hpd_irq_event() with
drm_kms_helper_hotplug_event().
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
Cc: Laurent Pinchart
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index b38e743..2caca0c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -406,7 +406,7 @@ static void adv7511_irq_work(struct work_struct *work)
{
struct adv7511 *adv7511 = container_of(work, struct adv7511, irq_work);
- drm_helper_hpd_irq_event(adv7511->connector.dev);
+ drm_kms_helper_hotplug_event(adv7511->connector.dev);
}
--
2.7.4
[RFC][PATCH 0/5 v2] adv7511 EDID probing improvements
Wanted to send out v2 of this patch set improving the EDID probing on the adv7511 used on HiKey. The first three patches are fixups that are hopefully straight forward, integrating feedback I got from Laurant. One of the previous patches that Laurant had concerns about, I broke into two patches, which are the last two in this series. The core issue seems to be something going wrong with the regmap cache state for the ADV7511_REG_EDID_I2C_ADDR (0x43) register which results in i2c_transfer errors if we don't do the regcache_sync/_mark_dirty() calls. I suspect there might be a better solution there, so suggestions will be very welcome. Thoughts and feedback would be appreciated! thanks -john Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-de...@lists.freedesktop.org Archit Taneja (1): drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection John Stultz (4): drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event() drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 ++ drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 49 2 files changed, 31 insertions(+), 20 deletions(-) -- 2.7.4
[RFC][PATCH 1/5 v2] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.
Digging deeper, I found this was due to the fact that
IRQs were disabled as we were running in IRQ context from
the HPD signal.
Thus this patch changes the logic to handle the HPD signal
via a work_struct so we can be out of irq context.
With this patch, the EDID probing on hotplug does not time
out.
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
Cc: Laurent Pinchart
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2: Reworked to properly fix the issue rather then
just delaying for 200ms
drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 ++
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 992d76c..2a1e722 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -317,6 +317,8 @@ struct adv7511 {
bool edid_read;
wait_queue_head_t wq;
+ struct work_struct irq_work;
+
struct drm_bridge bridge;
struct drm_connector connector;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8dba729..b38e743 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -402,6 +402,14 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
return false;
}
+static void adv7511_irq_work(struct work_struct *work)
+{
+ struct adv7511 *adv7511 = container_of(work, struct adv7511, irq_work);
+
+ drm_helper_hpd_irq_event(adv7511->connector.dev);
+}
+
+
static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
{
unsigned int irq0, irq1;
@@ -419,7 +427,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
bool process_hpd)
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder)
- drm_helper_hpd_irq_event(adv7511->connector.dev);
+ schedule_work(&adv7511->irq_work);
if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
adv7511->edid_read = true;
@@ -1006,6 +1014,8 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
goto err_i2c_unregister_edid;
}
+ INIT_WORK(&adv7511->irq_work, adv7511_irq_work);
+
if (i2c->irq) {
init_waitqueue_head(&adv7511->wq);
--
2.7.4
[RFC][PATCH 3/5 v2] drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection
From: Archit Taneja On some adv7511 implementations, we can get some spurious disconnect signals which can cause monitor probing to fail. This patch enables HPD (hot plug detect) interrupt support which allows the monitor to be properly re-initialized when the spurious disconnect signal goes away. This also enables proper hotplug support. Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-de...@lists.freedesktop.org Acked-by: Laurent Pinchart Originally-by: Archit Taneja [jstultz: Added proper commit message] Signed-off-by: John Stultz --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 2caca0c..9f8dffd 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -338,7 +338,7 @@ static void adv7511_power_on(struct adv7511 *adv7511) * Still, let's be safe and stick to the documentation. */ regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0), -ADV7511_INT0_EDID_READY); +ADV7511_INT0_EDID_READY | ADV7511_INT0_HPD); regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1), ADV7511_INT1_DDC_ERROR); } @@ -833,6 +833,10 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge) if (adv->type == ADV7533) ret = adv7533_attach_dsi(adv); + if (adv->i2c_main->irq) + regmap_write(adv->regmap, ADV7511_REG_INT_ENABLE(0), + ADV7511_INT0_HPD); + return ret; } -- 2.7.4
Re: [RFC PATCH] crypto: Add IV generation algorithms
On 28 November 2016 at 18:17, Herbert Xu wrote:
> On Mon, Nov 21, 2016 at 03:40:09PM +0530, Binoy Jayan wrote:
>> Currently, the iv generation algorithms are implemented in dm-crypt.c.
>> The goal is to move these algorithms from the dm layer to the kernel
>> crypto layer by implementing them as template ciphers so they can be used
>> in relation with algorithms like aes, and with multiple modes like cbc,
>> ecb etc. As part of this patchset, the iv-generation code is moved from the
>> dm layer to the crypto layer. The dm-layer can later be optimized to
>> encrypt larger block sizes in a single call to the crypto engine. The iv
>> generation algorithms implemented in geniv.c includes plain, plain64,
>> essiv, benbi, null, lmk and tcw. These templates are to be configured
>> and has to be invoked as:
>>
>> crypto_alloc_skcipher("plain(cbc(aes))", 0, 0);
>> crypto_alloc_skcipher("essiv(cbc(aes))", 0, 0);
>> ...
>>
>> from the dm layer.
>>
>> Signed-off-by: Binoy Jayan
>
> Thanks a lot for working on this!
>
>> +static int crypto_geniv_set_ctx(struct crypto_skcipher *cipher,
>> + void *newctx, unsigned int len)
>> +{
>> + struct geniv_ctx *ctx = crypto_skcipher_ctx(cipher);
>> + /*
>> + * TODO:
>> + * Do we really need this API or can we append the context
>> + * 'struct geniv_ctx' to the cipher from dm-crypt and use
>> + * the same here.
>> + */
>> + memcpy(ctx, (char *) newctx, len);
>> + return geniv_setkey_init_ctx(&ctx->data);
>> +}
>
> I think we should be able to do without adding another API for this.
> Can we instead put the information into the key and/or the IV?
>
> Also it would really help if you could attach a patch for dm-crypt
> that goes along with this (it doesn't have to be complete or
> functional, just showing how this is meant to be used)
Hi Herbert,
Thank you for the reply. The dm-crypt changes are also included as
part of this patchset. It has been tested for functionality as well.
More information can be found in the cover letter including the test
procedure etc.
https://lkml.org/lkml/2016/11/21/168
Thanks,
Binoy
[PATCH] openvswitch: add sanity check in queue_userspace_packet.
kernel will crash in oops if genlmsg_put return NULL,
so add the sanity check.
Signed-off-by: Haishuang Yan
---
net/openvswitch/datapath.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 2d4c4d3..ceb1b1e 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -474,6 +474,10 @@ static int queue_userspace_packet(struct datapath *dp,
struct sk_buff *skb,
upcall = genlmsg_put(user_skb, 0, 0, &dp_packet_genl_family,
0, upcall_info->cmd);
+ if (!upcall) {
+ err = -EMSGSIZE;
+ goto out;
+ }
upcall->dp_ifindex = dp_ifindex;
err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false, user_skb);
--
1.8.3.1
Re: [PATCH 2/3] iio: st_accel: Support sensor i2c probe using acpi
On Sun, 2016-11-27 at 11:14 +, Jonathan Cameron wrote:
> On 24/11/16 14:26, Linus Walleij wrote:
> > On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> > wrote:
> >
> > > Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
> > > strings are not avaialable on ACPI based systems.
> > >
> > > Signed-off-by: Shrirang Bagul
> >
> > (...)
> >
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id st_accel_acpi_match[] = {
> > > + {"SMO8A90", LNG2DM},
> > > + { },
> > > +};
> >
> > Why is ACPI only supporting one out of 14 devices?
> >
> > Surely there are some out-of-tree ACPI platforms using one
> > or more of the others?
> >
> > Apart from that it looks nice.
>
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
>
> Anyone know where the ACPI names come from? Is there some big
> list somewhere to prevent clashes?
>
> Jonathan
I'll take a look at the HW in our lab and send patches to identify more st_accel
sensors used mostly on Dell laptops.
Shrirang
> >
> > Yours,
> > Linus Walleij
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
Re: [PATCH 3/3] iio: st_pressure: Support i2c probe using acpi
On Sun, 2016-11-27 at 11:12 +, Jonathan Cameron wrote:
> On 24/11/16 14:28, Linus Walleij wrote:
> > On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> > wrote:
> >
> > > Compatible strings are not available on ACPI based systems. This patch
> > > adds
> > > support to use DSDT information read from platform BIOS instead for
> > > probing
> > > st pressure sensors.
> > >
> > > Signed-off-by: Shrirang Bagul
> >
> > (...)
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id st_press_acpi_match[] = {
> > > + {"SNO9210", LPS22HB},
> > > + { },
> > > +};
> >
> > Same comment. One sensor only supported by ACPI really?
>
> As demonstrated by this one, they are often registered under effectively
> random names!
> Digging out those random names and associating them with a particular chip is
> always
> going to be a non trivial job.
>
> Hence I'm happy to take these as they stand. We can add more entries when we
> come
> across them.
> >
> > Take a wider look.
Yes, I will.
>
> Shirang has done a good job identifying this one and sending it upstream.
> Be nice Linus and don't try to get him to do all the hard work ;)
>
> As such applied to the togreg branch of iio.git. Will be pushed out as testing
> for
> the autobuilders to play with it.
>
> Note there will be some weeks before I push this out as togreg (given merge
> window
> is about to open) so plenty of time for others to take a look!
>
> Thanks,
>
> Jonathan
Thank you Jonathan. I'll follow-up on Linus's suggestion and try and identify
more of these sensors on some of the hardware we have in the lab. and try to add
support for some more devices.
Thanks,
Shrirang
> >
> > Yours,
> > Linus Walleij
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
[PATCH V1] leds: pca963x: Add ACPI support
This patch enables ACPI support for leds-pca963x driver.
Signed-off-by: Tin Huynh
---
drivers/leds/leds-pca963x.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
index 407eba1..be51a12 100644
--- a/drivers/leds/leds-pca963x.c
+++ b/drivers/leds/leds-pca963x.c
@@ -25,6 +25,7 @@
* or by adding the 'nxp,hw-blink' property to the DTS.
*/
+#include
#include
#include
#include
@@ -95,6 +96,15 @@ struct pca963x_chipdef {
};
MODULE_DEVICE_TABLE(i2c, pca963x_id);
+static const struct acpi_device_id pca963x_acpi_ids[] = {
+ { "PCA9632", pca9633 },
+ { "PCA9633", pca9633 },
+ { "PCA9634", pca9634 },
+ { "PCA9635", pca9635 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, pca963x_acpi_ids);
+
struct pca963x_led;
struct pca963x {
@@ -322,7 +332,16 @@ static int pca963x_probe(struct i2c_client *client,
struct pca963x_chipdef *chip;
int i, err;
- chip = &pca963x_chipdefs[id->driver_data];
+ if (id) {
+ chip = &pca963x_chipdefs[id->driver_data];
+ } else {
+ const struct acpi_device_id *acpi_id;
+
+ acpi_id = acpi_match_device(pca963x_acpi_ids, &client->dev);
+ if (!acpi_id)
+ return -ENODEV;
+ chip = &pca963x_chipdefs[acpi_id->driver_data];
+ }
pdata = dev_get_platdata(&client->dev);
if (!pdata) {
@@ -426,6 +445,7 @@ static int pca963x_remove(struct i2c_client *client)
.driver = {
.name = "leds-pca963x",
.of_match_table = of_match_ptr(of_pca963x_match),
+ .acpi_match_table = ACPI_PTR(pca963x_acpi_ids),
},
.probe = pca963x_probe,
.remove = pca963x_remove,
--
1.7.1
Re: [RFC PATCH 1/2] net: macb: Add MDIO driver for accessing multiple PHY devices
Hi Andrew,
On Mon, Nov 28, 2016 at 10:03 PM, Andrew Lunn wrote:
> On Mon, Nov 28, 2016 at 03:19:14PM +0530, Harini Katakam wrote:
>> This patch is to add support for the hardware with multiple ethernet
>> MAC controllers and a single MDIO bus connected to multiple PHY devices.
>> MDIO lines are connected to any one of the ethernet MAC controllers and
>> all the PHY devices will be accessed using the PHY maintenance interface
>> in that MAC controller. This handling along with PHY functionality is
>> moved to macb_mdio.c
>>
>> Signed-off-by: Punnaiah Choudary Kalluri
>> Signed-off-by: Harini Katakam
>> ---
>> drivers/net/ethernet/cadence/Makefile| 2 +-
>> drivers/net/ethernet/cadence/macb.c | 169 +++-
>> drivers/net/ethernet/cadence/macb.h | 2 +
>> drivers/net/ethernet/cadence/macb_mdio.c | 266
>> +++
>> 4 files changed, 294 insertions(+), 145 deletions(-)
>> create mode 100644 drivers/net/ethernet/cadence/macb_mdio.c
>>
>> + bus->irq = devm_kzalloc(&pdev->dev, sizeof(int) * PHY_MAX_ADDR,
>> + GFP_KERNEL);
>
> This looks wrong, or at least old. It used to be a pointer to an array,
> but it is now an actual array.
Sorry, this was a mistake.
I changed this after rebase, will update in next version.
>
>> +static const struct of_device_id macb_mdio_dt_ids[] = {
>> + { .compatible = "cdns,macb-mdio" },
>> +
>> +};
>
>
> I've not looked hard enough to know, but can you keep backwards
> compatibility? Won't old device tree's assume the mdio bus is always
> present? Now you need an explicit node otherwise there will not be an
> mdio bus?
Yes, an explicit MDIO bus is required. But I'm not sure
how to maintain backward compatibility (without using this separate
macb_mdio) and have different MACs use the same MDIO bus
with separate PHYs.
Regards,
Harini
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Mon, Nov 28, 2016 at 5:15 PM, Ben Hutchings wrote: >> >> The modversions stuff may just be too painful to bother with. Very few >> people probably use it, and the ones that do likely don't have any >> overriding reason why. > [...] > > Debian has some strong reasons: Honestly, I'd just like to see actual real patches from people who care about this. The reason I disabled it entirely was simply that the discussions had been going on forever, but nobody actually seemed to care enough to just fix the damn thing. There was all the _noise_ about "look, here's a patch", but nothing got sent to maintainers and actually actively pushed as a "this fixes a regression". At some point I just get fed up and say "this isn't worth the hot air and endless pointless blathering". What is the actual exact failure with MODVERSIONS today? IOW, if you just remove the "broken", is it actually broken, and why? Because it does work for me, I just got really tired of hearing about it, and assuming it's just some broken toolchain or other case that I just don't hit. So somebody send me a minimal patch that is (a) tested (b) explains it (c) obvious and I'll happily re-enable modversions. Linus
Re: [PATCHv4] shmem: avoid huge pages for small files
On Mon, 14 Nov 2016, Kirill A. Shutemov wrote:
> On Fri, Nov 11, 2016 at 01:41:11PM -0800, Hugh Dickins wrote:
> >
> > Certainly the new condition is easier to understand than the old condition:
> > which is a plus, even though it's hackish (I do dislike hobbling the first
> > extent, when it's an incomplete last extent which deserves to be hobbled -
> > easier said than implemented of course).
>
> Well, it's just heuristic that I found useful. I don't see a reason to
> make more complex if it works.
You like it because it allocates huge pages to some extents,
but not to all extents. I dislike it because it allocates
huge pages to the wrong extents.
You did much the same three or four years ago, in your THP-on-ramfs
series: I admired your resourcefulness, in getting the little files
to fit in memory; but it was not a solution I wanted to see again.
Consider copying a 2097153-byte file into such a filesystem: the first
2MB would be allocated with 4kB pages, the final byte with a 2MB page;
but it looks like I already pointed that out, and we just disagree.
This patch does not convince me at all: I expect you will come up with
some better strategy in a month or two, and I'd rather wait for that
than keep messing around with what we have. But if you can persuade
the filesystem guys that this heuristic would be a sensible mount
option for them, then in the end I shall not want tmpfs to diverge.
>
> > But isn't the new condition (with its ||) always weaker than the old
> > condition (with its &&)? Whereas I thought you were trying to change
> > it to be less keen to allocate hugepages, not more.
>
> I tried to make it less keen to allocate hugepages comparing to
> huge=always.
>
> Current huge=within_size is fairly restrictive: we don't allocate huge
> pages to grow the file. For shmem, it means we would allocate huge pages
> if user did truncate(2) to set file size, before touching data in it
> (shared memory APIs do this). This policy would be more useful for
> filesystem with backing storage.
>
> The patch relaxes condition: only require file size >= HPAGE_PMD_SIZE.
>
> > What the condition ought to say, I don't know: I got too confused,
> > and depressed by my confusion, so I'm just handing it back to you.
> >
> > And then there's the SHMEM_HUGE_WITHIN_SIZE case in shmem_huge_enabled()
> > (for khugepaged), which you have explicitly not changed in this patch:
> > looks strange to me, is it doing the right thing?
>
> I missed that.
>
> -8<-
> From b2158fdd8523e3e35a548857a1cb02fe6bcd1ea4 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Mon, 17 Oct 2016 14:44:47 +0300
> Subject: [PATCH] shmem: avoid huge pages for small files
>
> Huge pages are detrimental for small file: they causes noticible
> overhead on both allocation performance and memory footprint.
>
> This patch aimed to address this issue by avoiding huge pages until
> file grown to size of huge page if the filesystem mounted with
> huge=within_size option.
>
> This would cover most of the cases where huge pages causes slowdown
> comparing to small pages.
>
> Later we can consider huge=within_size as the default for tmpfs.
I'm sceptical of that, and I do not think this implementation will
make a sensible default.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> Documentation/vm/transhuge.txt | 8 ++--
> mm/shmem.c | 12 +++-
> 2 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> index 2ec6adb5a4ce..7703e9c241ca 100644
> --- a/Documentation/vm/transhuge.txt
> +++ b/Documentation/vm/transhuge.txt
> @@ -206,13 +206,17 @@ You can control hugepage allocation policy in tmpfs
> with mount option
> "huge=". It can have following values:
>
>- "always":
> -Attempt to allocate huge pages every time we need a new page;
> +Attempt to allocate huge pages every time we need a new page.
> +This option can lead to significant overhead if filesystem is used to
> +store small files.
Good, yes, that part I fully agree with.
>
>- "never":
> Do not allocate huge pages;
>
>- "within_size":
> -Only allocate huge page if it will be fully within i_size.
> +Only allocate huge page if size of the file more than size of huge
> +page. This helps to avoid overhead for small files.
> +
> Also respect fadvise()/madvise() hints;
>
>- "advise:
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ad7813d73ea7..ef8fdadd0626 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1677,14 +1677,11 @@ static int shmem_getpage_gfp(struct inode *inode,
> pgoff_t index,
> goto alloc_huge;
> switch (sbinfo->huge) {
> loff_t i_size;
> - pgoff_t off;
> case SHMEM_HUGE_NEVER:
> goto alloc_nohuge;
> case SHMEM_HUGE_WITHIN_SIZE:
> - off = ro
Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
On 28-11-16, 18:46, Stephen Boyd wrote:
> That's a lot of lines for something that we want to backport to
> stable kernels!
Hmm, I agree.
> The whole dev_list design seems fairly broken to me. Another
> solution would be to iterate the cpumask in reverse, but there
> doesn't seem to be a construct for that and adding one is
> probably not worth the effort.
>
> Adding yet another member to the structure and doing accounting
> in different places seems to be papering over the problem as
> well. Now we want to have "inactive" devices in the list? That
> seems like a problem for cpufreq to solve. It can decide to not
> call OPP APIs when the cpu device isn't actually physically
> removed if it wants to.
>
> It also exposes the OPP API's strong reliance on struct device
> for everything. Really we shouldn't be storing device pointers in
> the OPP core at all because we're not treating them like the
> reference counted objects they are. The dev_list should go
> probably go away and be replaced with some sort of counter. It
> would also be nice if struct device had a pointer to the OPP
> table(s) for a device so the lookup is direct.
If the struct device gets a pointer to the opp-table, then yes we can kill the
dev-list completely. I will work on cleaning up OPP core a bit later on.
> BTW, _dev_pm_opp_remove_table() calls _find_opp_dev() twice, once
> to find the opp_table for a device and then to find the
> opp_device inside the table that was used to match up the table
> in the first place. Madness!
>
> Anyway, rant over, how about handing out the opp table pointer to
> the caller so they can pass it back in when they call the put
> side? That should fix the same problem if I understand correctly.
Yes, that can be a solution for the time being.
> We should think about changing the API further so that callers
> have to "get" the OPP table cookie for their device and then pass
> that pointer to the dev_pm_*_set() APIs instead of passing a
> struct device pointer. That would save lots of cycles searching
> for something we already had.
Hmm, we need to do some cleanup soon I believe. Also note that we want to kill
the RCU thing :)
> -static inline void dev_pm_opp_put_regulator(struct device *dev) {}
> +static inline void dev_pm_opp_put_regulator(struct opp_table *opp_table) {}
We need to modify few more things as well. I will send a patch for that soon.
--
viresh
