Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 09/01/2014 10:11 PM, Jiri Olsa wrote: > On Mon, Sep 01, 2014 at 09:27:17AM +0300, Adrian Hunter wrote: >> On 08/30/2014 11:53 AM, Jiri Olsa wrote: >>> On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: > On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: >> On 16/07/2014 5:25 p.m., Jiri Olsa wrote: >>> On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. >>> >>> I understand the need for default config, but could you please elaborate >>> why do we want to parse 'pmu//' as an event string string? >> >> Currently the parser requires the slashes to identify a PMU event >> as opposed to a hardware or other kind of event. > > right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' >>> >>> so the consequence of default arguments is that you can >>> specify event just by the pmu name, like: >>> -e intel_pt// >>> >>> which means (with default attributes): >>> -e intel_pt/tsc=1,noretcomp=0/ >>> >>> I guess I wanted to hear more elaboration why is this better >>> than the current way we have by defining an alias, like: >>> >>> krava alias: "tsc=1,noretcomp=0" >>> >>> -e intel_pt/krava/ >>> >>> which gives the same result >> >> The default value must be provided by perf tools not the kernel e.g. >> an older version of perf tools will not be aware of new hardware >> features that the kernel may know about. If the kernel enables >> new features by default then the tool may fail. Thus the default >> value has to be under the control of the tools not the kernel, so >> a sysfs alias will not work. >> > > I dont follow, could u provide some example? Imagine that the 'tsc' term did not exist. Intel PT trace data would not contain TSC packets, and the decoder would not know how to decode them. Then imagine that a new version of the hardware adds 'tsc'. It is such a useful feature that we want it by default, but older versions of the tools don't know how to decode it, so the kernel cannot turn it on by default. > > why the tool needs to understand.. it will just take the alias > and apply/use it? The alias follows the format logic, which tells > how to apply values on perf_event_attr.. and the kernel knows best > what's supported in its version.. It is similar to why the kernel does not select mmap2 by default. The kernel doesn't know whether the tool supports it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using
[Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using] On 01/09/2014 (Mon 10:01) H. Peter Anvin wrote: > On 09/01/2014 09:08 AM, Paul Gortmaker wrote: > >>> > >> diff --git a/init/Kconfig b/init/Kconfig > >> index ac033c3..f301cc8 100644 > >> --- a/init/Kconfig > >> +++ b/init/Kconfig > >> @@ -23,6 +23,12 @@ config CONSTRUCTORS > >> config IRQ_WORK > >>bool > >> > >> +config CPU_LITTLE_ENDIAN > >> + bool > >> + > >> +config CPU_BIG_ENDIAN > >> + bool > > > > Perhaps you should take a cursory look at what already exists in tree > > before blindly trying to add more to it? > > > > $ git grep CPU_BIG_ENDIAN | wc -l > > 88 > > > > The whole point of this patchset is to make these already widely-used > options universal across the tree. OK, but that was not at _all_ what I thought when looking at this... Instead I saw a well intentioned, but perhaps not fully thought out attempt at fixing a largely irrelevant randconfig/allmodconfig of a 1990's vintage ISDN driver coming from that x86-only era, built against an architecture that will never use or support it (microblaze). In today's world, we'd probably not accept a new ethernet driver or filesystem if it was incapable of handling both BE and LE (exception being SoC ethernet physically bound to one specific CPU, of course.) So the justification given in the commit log for expanding the scope to better deal with the stuff found in ISDN and the like was questionable. Secondly, I don't think it is well known that Kbuild will tolerate multiply defined symbols of the exact same name, and since that isn't mentioned in the commit log (as documented and/or tested), I envisioned this breaking powerpc and other arch who already define one (or both) of these two. I found multi-define _is_ documented as supported in Documentation/kbuild but I still wonder how much it is used and how well it handles things like in powerpc, where one of them (LE?) also lists a "select ... " line and help text under the bool. So if we want to do this, I'd suggest a commit log that really gets to the intended point; something along the lines of: -- Currently we have some architectures defining their own bool for CPU_LITTLE_ENDIAN and/or CPU_BIG_ENDIAN. As of 3.17-rc3 we have: CPU_BIG_ENDIAN: arc, arm, arm64, c6x, mips, powerpc, sh CPU_LITTLE_ENDIAN: m32r, mips, powerpc, sh Note that the scope does not cover all arch, which reduces the utility value of these items in generic and/or arch independent code, as neither may be defined, making tests on their values inconclusive. To fix the above, the goal is to make both items present in an arch independent Kconfig. We can do this immediately without having to simultaneously touch the existing arch bool definitions because... This change was tested on a powerpc LE config since it has help text and a select line, and the behaviour of both before and after the change was found to be ... -- Also, having the suggested change Cc'd to linux-arch would be sensible, I think. And one might want to make it a series, showing the follow on arch specific commits you have planned that "select" an endian, since the maintainers may want evidence it will be carried to completion and they also may have something additional to say (as in the case of arch/arm where there is already CPU_ENDIAN_BE8 and CPU_ENDIAN_BE32 Kconfig items). Paul. -- > > -hpa > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] x86, fpu: copy_process's FPU paths cleanups
On Wed, Aug 27, 2014 at 11:51 AM, Oleg Nesterov wrote: > Hello, > > Who can review this? And where should I send FPU changes? > > And it seems that nobody cares about 2 fixes I sent before. > Linus, I understand that you won't take them into v3.17, but > perhaps you can ack/nack them explicitly? It seems that nobody > can do this. > > Oleg. > > arch/x86/include/asm/fpu-internal.h |2 +- > arch/x86/kernel/process.c | 16 +--- > arch/x86/kernel/process_32.c|2 -- > arch/x86/kernel/process_64.c|1 - > 4 files changed, 10 insertions(+), 11 deletions(-) These 4 patches also look good to me. Reviewed-by: Suresh Siddha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netlink: Safer deletion of sk_bind_node
From: Harish Jenny K N Date: Mon, 1 Sep 2014 12:38:29 +0530 Firstly, you really need to fix your outgoing email so that your email address appears in your From: header properly. > From: Harish Jenny K N > > Unable to handle kernel NULL pointer dereference at virtual address > > (netlink_release+0x0/0x2a0) from [<8034e78c>] (sock_release+0x28/0xa4) > (sock_release+0x0/0xa4) from [<8034e830>] (sock_close+0x28/0x34) > (sock_close+0x0/0x34) from [<800f3490>] (__fput+0xf0/0x1ec) > (__fput+0x0/0x1ec) from [<800f3634>] (fput+0x10/0x14) > (fput+0x0/0x14) from [<80040a64>] (task_work_run+0xb8/0xd8) > (task_work_run+0x0/0xd8) from [<800113a0>] (do_work_pending+0xb0/0xc4) > (do_work_pending+0x0/0xc4) from [<8000d960>] (work_pending+0xc/0x20) > Call flow of the inline and static functions > netlink_release > -netlink_remove > -__sk_del_bind_node > --__hlist_del > > Signed-off-by: Harish Jenny K N This doesn't tell us anything about how this situation can be arrived at. When subscriptions changes, we delete the node with the table lock held if subscriptions goes to zero. We only try to delete the node when subscriptions was zero. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, fpu: __restore_xstate_sig()->math_state_restore() needs preempt_disable()
On Mon, Aug 25, 2014 at 11:08 AM, Oleg Nesterov wrote:
>
> Add preempt_disable() + preempt_enable() around math_state_restore() in
> __restore_xstate_sig(). Otherwise __switch_to() after __thread_fpu_begin()
> can overwrite fpu->state we are going to restore.
>
> Signed-off-by: Oleg Nesterov
> Cc: sta...@vger.kernel.org
> ---
> arch/x86/kernel/xsave.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
> index 453343c..c52eb9c 100644
> --- a/arch/x86/kernel/xsave.c
> +++ b/arch/x86/kernel/xsave.c
> @@ -397,8 +397,11 @@ int __restore_xstate_sig(void __user *buf, void __user
> *buf_fx, int size)
> set_used_math();
> }
>
> - if (use_eager_fpu())
> + if (use_eager_fpu()) {
> + preempt_disable();
> math_state_restore();
> + preempt_enable();
> + }
>
> return err;
> } else {
>
oops. looks good to me.
Reviewed-by: Suresh Siddha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] cpufreq: kirkwood: use the powersave multiplexer
On 2 September 2014 00:17, Mike Turquette wrote: > @@ -150,7 +146,7 @@ static int kirkwood_cpufreq_probe(struct platform_device > *pdev) > err = PTR_ERR(priv.powersave_clk); > goto out_ddr; > } > - clk_prepare(priv.powersave_clk); > + clk_prepare_enable(priv.powersave_clk); Shouldn't this be done in a separate patch? Or is this really related? > > of_node_put(np); > np = NULL; Other than that: Acked-by: Viresh Kumar Yeah, you can take it through clock tree.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SMP BUG?] the return value of is_smp() is bug?
On 2014-09-01, Wang Long wrote: > > Hi,all > > In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y > in .config file. the secondary core can not boot. > > when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file, > the secondary core can boot. > > But this does not happen in kernel 3.10 lts kernel, Whether the > CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot. > > Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in > kernel3.17-rc2 ? Update qemu to at least 2.0. qemu of older version fails to smp-boot Linux 3.12+ with CONFIG_SMP_ON_UP enabled. -Leon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: intel_pstate: Remove unneeded variable
On 1 September 2014 17:53, Gabriele Mazzotta wrote:
> It should have been removed with commit d1b6848590af
> ("cpufreq / intel_pstate: Optimize intel_pstate_set_policy")
>
> Signed-off-by: Gabriele Mazzotta
> ---
> drivers/cpufreq/intel_pstate.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index e396ad3..0668b38 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -708,10 +708,6 @@ static unsigned int intel_pstate_get(unsigned int
> cpu_num)
>
> static int intel_pstate_set_policy(struct cpufreq_policy *policy)
> {
> - struct cpudata *cpu;
> -
> - cpu = all_cpu_data[policy->cpu];
> -
> if (!policy->cpuinfo.max_freq)
> return -ENODEV;
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net v5 4/4] tg3: Fix tx_pending checks for tg3_tso_bug
From: Benjamin Poirier Date: Fri, 29 Aug 2014 13:46:31 -0700 > This puts us in the exceptional situation that a single skb that > triggers tg3_tso_bug() may require the entire tx ring. This is really silly. If you get fed crap, linearize the SKB, end of story. Don't try to be clever, and absolutely do not adjust gso_max_segs on the fly as it was never ever designed to change dynamically and asynchronously to the code paths which use it to size outgoing TCP segments. Nothing else needs adjusting, just linearize when you run into a packet that can't fit into the TX ring because of these weird restrictions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/5] regulator: RK808: Remove pdata from the regulator
Chris,
On Mon, Sep 1, 2014 at 2:47 AM, Chris Zhong wrote:
> Signed-off-by: Chris Zhong
>
> ---
>
> Changes in v7:
> - remove pdata struct from header file, add rk808_regulator struct
>
> Changes in v6:
> - remove the redundant code
>
> Changes in v5:
> - re-edit base on Mark's branch
>
> Changes in v4:
> - use >dev replace rk808->dev
>
> Changes in v3: None
> Changes in v2:
> Adviced by Mark Browm:
> - change of_find_node_by_name to find_child_by_name
> - use RK808_NUM_REGULATORS as the name of the constant
> - create a pdata when missing platform data
> - use the rk808_reg name to supply_regulator name
> - replace regulator_register with devm_regulator_register
> - some other problem with coding style
>
> drivers/regulator/rk808-regulator.c | 52
> ++-
> 1 file changed, 20 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/regulator/rk808-regulator.c
> b/drivers/regulator/rk808-regulator.c
> index 0d11df1..4d543a9 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -3,9 +3,6 @@
> *
> * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> *
> - * Author: Chris Zhong
> - * Author: Zhang Qing
> - *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms and conditions of the GNU General Public License,
> * version 2, as published by the Free Software Foundation.
> @@ -14,28 +11,25 @@
> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> * more details.
> - *
> */
>
> #include
> -#include
> #include
> -#include
> -#include
> #include
> -#include
> #include
> #include
> #include
> -#include
> -#include
> -/*
> - * Field Definitions.
> - */
> +
> +/* Field Definitions */
> #define RK808_BUCK_VSEL_MASK 0x3f
> #define RK808_BUCK4_VSEL_MASK 0xf
> #define RK808_LDO_VSEL_MASK0x1f
>
> +struct rk808_regulator {
> + struct regulator_init_data *rk808_init_data[RK808_NUM_REGULATORS];
> + struct device_node *of_node[RK808_NUM_REGULATORS];
> +};
> +
> static const int buck_set_vol_base_addr[] = {
> RK808_BUCK1_ON_VSEL_REG,
> RK808_BUCK2_ON_VSEL_REG,
> @@ -50,10 +44,6 @@ static const int buck_contr_base_addr[] = {
> RK808_BUCK4_CONFIG_REG,
> };
>
> -#define rk808_BUCK_SET_VOL_REG(x) (buck_set_vol_base_addr[x])
> -#define rk808_BUCK_CONTR_REG(x) (buck_contr_base_addr[x])
> -#define rk808_LDO_SET_VOL_REG(x) (ldo_set_vol_base_addr[x])
> -
> static const int ldo_set_vol_base_addr[] = {
> RK808_LDO1_ON_VSEL_REG,
> RK808_LDO2_ON_VSEL_REG,
> @@ -65,9 +55,7 @@ static const int ldo_set_vol_base_addr[] = {
> RK808_LDO8_ON_VSEL_REG,
> };
>
> -/*
> - * rk808 voltage number
> - */
> +/* rk808 voltage number */
> static const struct regulator_linear_range rk808_buck_voltage_ranges[] = {
> REGULATOR_LINEAR_RANGE(70, 0, 63, 12500),
> };
> @@ -295,7 +283,7 @@ static struct of_regulator_match rk808_reg_matches[] = {
> };
>
> static int rk808_regulator_dts(struct i2c_client *client,
> - struct rk808_board *pdata)
> + struct rk808_regulator *rk808_regulator)
> {
> struct device_node *np, *reg_np;
> int i, ret;
> @@ -323,8 +311,9 @@ static int rk808_regulator_dts(struct i2c_client *client,
> !rk808_reg_matches[i].of_node)
> continue;
>
> - pdata->rk808_init_data[i] = rk808_reg_matches[i].init_data;
> - pdata->of_node[i] = rk808_reg_matches[i].of_node;
> + rk808_regulator->rk808_init_data[i] =
> + rk808_reg_matches[i].init_data;
> + rk808_regulator->of_node[i] = rk808_reg_matches[i].of_node;
> }
>
> return 0;
> @@ -334,26 +323,25 @@ static int rk808_regulator_probe(struct platform_device
> *pdev)
> {
> struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
> struct i2c_client *client = rk808->i2c;
> - struct rk808_board *pdata = dev_get_platdata(>dev);
> + struct rk808_regulator *rk808_regulator;
> struct regulator_config config = {};
> struct regulator_dev *rk808_rdev;
> struct regulator_init_data *reg_data;
> int i = 0;
> int ret = 0;
>
> - if (!pdata) {
> - pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata)
> - return -ENOMEM;
> - }
> + rk808_regulator = devm_kzalloc(>dev, sizeof(*rk808_regulator),
> + GFP_KERNEL);
> + if (!rk808_regulator)
> + return -ENOMEM;
Totally remove rk808_regulator_dts() function. Totally remove
"rk808_regulator" local variable (and allocation, and typedef). Then
you can just use "rk808_reg_matches" in the "for" loop in
[uas/3.16.1] panic in uas_data_cmplt()
Dear all: The kernel version is 3.16.1-1-ARCH Today I keep getting this panic when booting up. http://i.imgur.com/0Rx93Kr.jpg It might be that the UAS device was in some strange state, because that after I unplugged and power-cycled the UAS, everything went normal again. Does anyone know what's the root cause of this issue? Or could anyone provide some instruction on how to debug this issue? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On 2 September 2014 14:05, Theodore Ts'o wrote: > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no > longer see the my Dell 30" monitor when it is connected via the > docking station using a Displayport connector. This worked using 3.16 > kernel. > > If I connect to the monitor using the mini-display, by passing the > docking station, things work fine (but of course it's annoying not to > be able to use the docking station). > > Is this a known problem? This is not the first time that we've had > regressions with this docking station. It's vaguely reminsicent of > > https://bugs.freedesktop.org/show_bug.cgi?id=71267 > > Except the system isn't hanging; it's just not seeing the monitor at all. Have you the Dell 30" set to Displayport 1.2 enabled mode? If so, then see if disabling that in the monitor menus helps. This is probably due to the fact we now attempt to talk to new DP devices with the protocol they provide. So previously the monitor exposed DP 1.2 and we just didn't care, now if it exposes it we attempt to talk to it. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci/probe: Enable CRS for Intel Haswell root ports
[+cc Linus (author of ad7edfe04908), Matthew (author of 07ff9220908c
from full history), Yinghai (author of 2f5d8e4ff947), Richard]
On Thu, Aug 28, 2014 at 3:55 PM, Rajat Jain wrote:
> The PCIe root port of the Intel Haswell CPU, has a behavior to endlessly
> retry the configuration cycles, if an endpoint responds with a CRS
> (Configuration Request Retry Status), and the "CRS Software Visibility"
> flag is not set at the root port. This results in a CPU hang, when the
> kernel tries to enumerate the device that responds with CRS.
Help me understand this. I thought a config read of Vendor ID would see:
- 0x if no device is present, or
- 0x0001 if the device is present but not ready yet, and the OS
should retry the read. This only happens when Software Visibility is
enabled.
- Normal Vendor ID if device is present and ready. If Software
Visibility is disabled (as it is in Linux today) and the endpoint
responds with CRS, the Root Complex may retry the config read
invisibly to software.
I suppose these retries are causing your hang, but since the device is
actually present, I would think the CPU would see a read that took a
very long time to complete, but that did eventually complete. Is this
causing a CPU timeout? Is the endpoint broken and returning CRS
endlessly?
> Please note that this root port behavior (of endless retries) is still
> compliant with PCIe spec as the spec leaves the behavior open to
> implementation, on how many retries to do if "CRS visibility flag" is
> not enabled and it receives a CRS. (Intel has chosen to retry indefinitely)
>
> Ref1:
> https://www.pcisig.com/specifications/pciexpress/ECN_CRS_Software_Visibility_No27.pdf
>
> Ref2:
> PCIe spec V3.0, pg119, pg127 for "Configuration Request Retry Status"
>
> Following CPUs are affected:
> http://ark.intel.com/products/codename/42174/Haswell#@All
>
> Thus we need to enable the CRS visibility flag for such root ports. The
> commit ad7edfe04908 ("[PCI] Do not enable CRS Software Visibility by
> default") suggests to maintain a whitelist of the systems for which CRS
> should be enabled. This patch does the same.
I'm not a fan of adding a whitelist for devices that work correctly.
I don't think that's a maintainable solution. Since we haven't had
many systems yet that care about CRS, some kind of "enable CRS on
machines newer than X" might work.
>From Linus' email (https://lkml.org/lkml/2007/12/27/92), the only
detailed data I found was from Ciaran McCreesh
(https://lkml.org/lkml/2007/10/29/500). That case is interesting
because RootCap claims CRSVisible is not supported, but RootCtl claims
it is enabled:
00:04.0 PCI bridge: ATI Technologies Inc Unknown device 7934
(prog-if 00 [Normal decode])
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Capabilities: [58] Express (v1) Root Port (Slot+), MSI 00
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
CRSVisible+
RootCap: CRSVisible-
02:00.0 Ethernet controller: Unknown device 0001:8168 (rev 01)
The Linux code removed by ad7edfe04908 doesn't bother to check the
RootCap bit; it simply tries to set the RootCtl enable. Per spec,
that would be safe because the RootCtl enable bit should be hardwired
to 0 if the Root Port doesn't implement the capability, but I can
imagine a hardware bug where CRSVisible is partly implemented and the
designer assumes it won't be used because he doesn't advertise that
it's supported.
I think you should add that RootCap test to your patch. It would be
very interesting to test that on some of these machines where we found
problems.
> Note: Looking at the spec and reading about the CRS, IMHO the "CRS
> visibility" looks like a good thing to me that should always be enabled
> on the root ports that support it. And may be we should always enable
> it if supported and maintain a blacklist of devices on which should be
> disabled (because of known issues).
>
> How I stumbled upon this and tested the fix:
>
> Root port: PCI bridge: Intel Corporation Device 2f02 (rev 01)
>
> I have a PCIe endpoint (a PLX 8713 NT bridge) that will keep on responding
> with CRS for a long time when the kernel tries to enumerate the
> endpoint, trying to indicate that the device is not yet ready. This is
> because it needs some configuration over I2C in order to complete its
> reset sequence. This results in a CPU hang during enumeration.
Is the I2C configuration something the OS needs to do? If so, I
suppose we will always get CRS after reset, and we'll always have to
wait for a timeout, then do that I2C configuration, then somehow try
to re-enumerate the device? That seems like a broken usage model. I
guess maybe the I2C configurator could initiate a rescan to sort of
patch things up, but it still seems wrong that we have the timeout and
generate a warning.
> I used this setup to fix and test this issue. After enabling the CRS
> visibility flag at the root port, I see that CPU moves on as expected
>
[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel. If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station). Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of https://bugs.freedesktop.org/show_bug.cgi?id=71267 Except the system isn't hanging; it's just not seeing the monitor at all. Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/01/2014 06:19 PM, Peter Zijlstra wrote: > On Mon, Sep 01, 2014 at 12:04:34PM +0200, Peter Zijlstra wrote: >> > On Mon, Sep 01, 2014 at 12:52:19PM +0300, Michael S. Tsirkin wrote: >>> > > On Mon, Sep 01, 2014 at 11:31:59AM +0200, Peter Zijlstra wrote: > > > On Fri, Aug 22, 2014 at 07:01:05AM +0200, Mike Galbraith wrote: >> > > > > > +++ b/include/net/busy_poll.h >> > > > > > @@ -109,7 +109,8 @@ static inline bool sk_busy_loop(struct >> > > > > > sock *sk, int nonblock) >> > > > > >cpu_relax(); >> > > > > > >> > > > > >} while (!nonblock && >> > > > > > skb_queue_empty(>sk_receive_queue) && >> > > > > > - !need_resched() && >> > > > > > !busy_loop_timeout(end_time)); >> > > > > > + !need_resched() && >> > > > > > !busy_loop_timeout(end_time) && >> > > > > > + nr_running_this_cpu() < 2); >> > > > > > > > > > > > So as has been said by now; this is horrible. > > > > > > We should not export nr_running like this ever. Your usage of < 2 > > > implies this can be hit with nr_running == 0, and therefore you can > > > also > > > hit it with nr_running == 1 where the one is not network related and > > > you > > > get random delays. > > > > > > Worse still, you have BH (and thereby preemption) disabled, you > > > should > > > not _ever_ have undefined and indefinite waits like that. > > > > > > You also destroy any hope of dropping into lower power states; even > > > when > > > there's never going to be a packet ever again, also bad. >>> > > >>> > > Hmm this patch sometimes makes us exit from the busy loop *earlier*. >>> > > How can this interfere with dropping into lower power states? >> > >> > Ah.. jetlag.. :/ I read it like it owuld indefinitely spin if there was >> > only the 'one' task, not avoid the spin unless there was the one task. >> > >> > The nr_running thing is still horrible, but let me reread this patch >> > description to see if it explains why that is a good thing. > OK I suppose that more or less makes sense, the contextual behaviour is > of course tedious in that it makes behaviour less predictable. The > 'other' tasks might not want to generate data and you then destroy > throughput by not spinning. The patch try to make sure: - the the performance of busy read was not worse than it was disabled in any cases. - the performance improvement of a single socket was not achieved by sacrificing the total performance (all other processes) of the system If 'other' tasks are also CPU or I/O intensive jobs, we switch to do them so the total performance were kept or even increased, and the performance of current process were guaranteed not worse than when busy read was disabled (or even better since it may still do busy read sometimes when it was the only runnable process). If 'other' task are not intensive, they just do little work and sleep soon, then the busy read can still work in most of the time during the future reads, we may still get obvious improvements. > I'm not entirely sure I see how its all supposed to work though; the > various poll functions call sk_busy_poll() and do_select() also loops. > > The patch only kills the sk_busy_poll() loop, but then do_select() will > still loop and not sleep, so how is this helping? Yes, the patch only help for processes who did a blocking reads (busy read). For select(), maybe we can do the same thing but need more test and thoughts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/5] RTC: RK808: add RTC driver for RK808
Chris,
On Mon, Sep 1, 2014 at 2:43 AM, Chris Zhong wrote:
> Adding RTC driver for supporting RTC device present inside RK808 PMIC.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Zhang Qing
>
> ---
>
> Changes in v7:
> Adviced by doug
> - read rtc time from shadowed registers
> Adviced by Dmitry
> - use CONFIG_PM_SLEEP replace CONFIG_PM
> - use SIMPLE_DEV_PM_OPS replace dev_pm_ops
> - fix dev_warn
> - coding style
> Adviced by Heiko
> - remove rtc_ctl
>
> Changes in v6:
> Adviced by doug
> - move RTC_READSEL setting into probe
>
> Changes in v5:
> - fixed a bug about set_time failed
>
> Changes in v4:
> - use >dev replace rk808->dev
>
> Changes in v3: None
> Changes in v2:
> Adviced by javier.martinez
> - Add a separate clock driver, rather than in RTC driver
>
> drivers/rtc/Kconfig | 10 ++
> drivers/rtc/Makefile|1 +
> drivers/rtc/rtc-rk808.c | 419
> +++
> 3 files changed, 430 insertions(+)
> create mode 100644 drivers/rtc/rtc-rk808.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a168e96..aeab9d9 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
> This driver can also be built as a module. If so, the module
> will be called rtc-max77686.
>
> +config RTC_DRV_RK808
> + tristate "Rockchip RK808 RTC"
> + depends on MFD_RK808
> + help
> + If you say yes here you will get support for the
> + RTC of RK808 PMIC.
> +
> + This driver can also be built as a module. If so, the module
> + will be called rk808-rtc.
> +
> config RTC_DRV_RS5C372
> tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
> help
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 56f061c..91fe4647 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3) += rtc-puv3.o
> obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
> obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
> obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
> +obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
> obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
> obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
> obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
> diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
> new file mode 100644
> index 000..3de78e8
> --- /dev/null
> +++ b/drivers/rtc/rtc-rk808.c
> @@ -0,0 +1,419 @@
> +/*
> + * RTC driver for Rockchip RK808
> + *
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* RTC_CTRL_REG bitfields */
> +#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
> +
> +/* RK808 has a shadowed register for saving a "frozen" RTC time.
> + * When user setting "GET_TIME" to 1, the time will save in this shadowed
> + * register. If set "READSEL" to 1, user read rtc time register, actually
> + * get the time of that moment. If we need the real time, clr this bit.
> + */
> +#define BIT_RTC_CTRL_REG_RTC_GET_TIME BIT(6)
> +#define BIT_RTC_CTRL_REG_RTC_READSEL_M BIT(7)
> +#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_M BIT(3)
> +#define RTC_STATUS_MASK0xFE
> +
> +#define SECONDS_REG_MSK0x7F
> +#define MINUTES_REG_MAK0x7F
> +#define HOURS_REG_MSK 0x3F
> +#define DAYS_REG_MSK 0x3F
> +#define MONTHS_REG_MSK 0x1F
> +#define YEARS_REG_MSK 0xFF
> +#define WEEKS_REG_MSK 0x7
> +
> +/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
> +
> +#define NUM_TIME_REGS (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
> +#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
> +
> +struct rk808_rtc {
> + struct rk808 *rk808;
> + struct rtc_device *rtc;
> + int irq;
> +};
> +
> +/* Read current time and date in RTC */
> +static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
> +{
> + struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
> + struct rk808 *rk808 = rk808_rtc->rk808;
> + u8 rtc_data[NUM_TIME_REGS];
> + int ret;
> +
> + ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
> +BIT_RTC_CTRL_REG_RTC_GET_TIME,
> +BIT_RTC_CTRL_REG_RTC_GET_TIME);
> + if (ret) {
> + dev_err(dev,
[RESEND PATCH] arm64: dts: add symlink
Add symlink to include/dt-bindings from arch/arm64/boot/dts/include/ to
match the ones in ARM architectures so that preprocessed device
tree files can include various useful constant definitions.
See commit c58299aa8754 ("kbuild: create an "include chroot" for DT bindings")
merged in v3.10-rc1 for details.
CC: Catalin Marinas
Signed-off-by: Pankaj Dubey
---
Resubmitting this change as now it will be required for Samsung ARM64
based SoC.
Initial discussion can be found at here
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/228225.html
arch/arm64/boot/dts/include/dt-bindings |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 12 arch/arm64/boot/dts/include/dt-bindings
diff --git a/arch/arm64/boot/dts/include/dt-bindings
b/arch/arm64/boot/dts/include/dt-bindings
new file mode 12
index 000..68ae388
--- /dev/null
+++ b/arch/arm64/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/5] dt-bindings: Add RK808 device tree bindings document
Chris,
On Mon, Sep 1, 2014 at 2:07 AM, Chris Zhong wrote:
> Add device tree bindings documentation and a header file
> for rockchip's RK808 pmic.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Zhang Qing
>
> ---
>
> Changes in v7:
> Advices by Mark Rutland
> - modify description about clock-cells
> - update the example
>
> Changes in v6:
> Advices by Mark Rutland
> - add description about clock-cells
> Advices by Doug
> - modify description about regulator
> - remove pinctrl description
>
> Changes in v5:
> Advices by Mark Brown
> - add description about regulator valid name.
> - add a header file "rockchip,rk808".
>
> Changes in v4:
> Advices by Doug
> - add a "#clock-cells" propertiy
> - update the example
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/rk808.txt | 166
> +++
> include/dt-bindings/clock/rockchip,rk808.h | 11 ++
> 2 files changed, 177 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
> create mode 100644 include/dt-bindings/clock/rockchip,rk808.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt
> b/Documentation/devicetree/bindings/mfd/rk808.txt
> new file mode 100644
> index 000..f8932ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/rk808.txt
> @@ -0,0 +1,166 @@
> +RK808 Power Management Integrated Circuit
> +
> +Required properties:
> +- compatible: "rockchip,rk808"
> +- reg: I2C slave address
> +- interrupt-parent: The parent interrupt controller.
> +- interrupts: the interrupt outputs of the controller.
> +- #clock-cells: from common clock binding; shall be set to 1 (multiple clock
> + outputs)
I think Mark Rutland was looking for something like:
- #clock-cells: from common clock binding; shall be set to 1 (multiple clock
outputs). See for clock IDs.
> +Optional properties:
> +- clock-output-names: From common clock binding to override the
> + default output clock name
> +- rockchip,system-power-controller: Telling whether or not this pmic is
> controlling
> + the system power.
> +
> +Regulators: All the regulators of RK808 to be instantiated shall be
> +listed in a child node named 'regulators'. Each regulator is represented
> +by a child node of the 'regulators' node.
> +
> + regulator-name {
> + /* standard regulator bindings here */
> + };
> +
> +Following regulators of the RK808 PMIC block are supported. Note that
> +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or
> LDO
> +number as described in RK808 datasheet.
> +
> + - DCDC_REGn
> + - valid values for n are 1 to 4.
> + - LDO_REGn
> + - valid values for n are 1 to 8.
> + - SWITCH_REGn
> + - valid values for n are 1 to 2
> +
> +Standard regulator bindings are used inside regulator subnodes. Check
> + Documentation/devicetree/bindings/regulator/regulator.txt
> +for more details
> +
> +Example:
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + clock-output-names = "xin32k", "rk808-clkout2";
> + interrupt-parent = <>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_int>;
> + reg = <0x1b>;
> + rockchip,system-power-controller;
> + wakeup-source;
> + #clock-cells = <1>;
> +
> + vcc8-supply = <_18>;
> + vcc9-supply = <_io>;
> + vcc10-supply = <_io>;
> + vcc12-supply = <_io>;
> + vddio-supply = <_pmu>;
Technically the "-supply" section shouldn't be here. I plan to add
support for input supplies once you've landed your series. See
Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.
On 2014/8/13 0:25, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
>
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
>
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Arnd Bergmann
> Signed-off-by: Liviu Dudau
> ---
> drivers/of/address.c | 95
> ++
> include/linux/of_address.h | 2 +
> 2 files changed, 97 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..4dab700 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /* Max address size we deal with */
> @@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev,
> int index, u64 *size,
> }
> EXPORT_SYMBOL(of_get_address);
>
> +#ifdef PCI_IOBASE
> +struct io_range {
> + struct list_head list;
> + phys_addr_t start;
> + resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +static DEFINE_SPINLOCK(io_range_lock);
> +#endif
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifdef PCI_IOBASE
> + struct io_range *range;
> + resource_size_t allocated_size = 0;
> +
> + /* check if the range hasn't been previously recorded */
> + spin_lock(_range_lock);
> + list_for_each_entry(range, _range_list, list) {
> + if (addr >= range->start && addr + size <= range->start + size)
> + return 0;
> + allocated_size += range->size;
> + }
> + spin_unlock(_range_lock);
> +
> + /* range not registed yet, check for available space */
> + if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> + /* if it's too big check if 64K space can be reserved */
> + if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
> + return -E2BIG;
> +
> + size = SZ_64K;
> + pr_warn("Requested IO range too big, new size set to 64K\n");
> + }
> +
> + /* add the range to the list */
> + range = kzalloc(sizeof(*range), GFP_KERNEL);
> + if (!range)
> + return -ENOMEM;
> +
> + range->start = addr;
> + range->size = size;
> +
> + list_add_tail(>list, _range_list);
Need spin_lock() here ?
> +#endif
> +
> + return 0;
> +}
> +
> +phys_addr_t pci_pio_to_address(unsigned long pio)
> +{
> + phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> +
> +#ifdef PCI_IOBASE
> + struct io_range *range;
> + resource_size_t allocated_size = 0;
> +
> + if (pio > IO_SPACE_LIMIT)
> + return address;
> +
> + spin_lock(_range_lock);
> + list_for_each_entry(range, _range_list, list) {
> + if (pio >= allocated_size && pio < allocated_size +
> range->size) {
> + address = range->start + pio - allocated_size;
> + break;
> + }
> + allocated_size += range->size;
> + }
> + spin_unlock(_range_lock);
> +#endif
> +
> + return address;
> +}
> +
> unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> +#ifdef PCI_IOBASE
> + struct io_range *res;
> + resource_size_t offset = 0;
> +
> + list_for_each_entry(res, _range_list, list) {
And here.
> + if (address >= res->start &&
> + address < res->start + res->size) {
> + return res->start - address + offset;
> + }
> + offset += res->size;
> + }
> +
> + return (unsigned long)-1;
> +#else
> if (address > IO_SPACE_LIMIT)
> return (unsigned long)-1;
>
> return (unsigned long) address;
> +#endif
> }
>
> static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878..28e6836 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device,
> int index);
> extern const __be32 *of_get_address(struct device_node *dev, int index,
>
Re: [PATCH v7 1/5] dt-bindings: Add RK808 device tree bindings document
Chris,
On Mon, Sep 1, 2014 at 2:07 AM, Chris Zhong wrote:
> Add device tree bindings documentation and a header file
> for rockchip's RK808 pmic.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Zhang Qing
>
> ---
>
> Changes in v7:
> Advices by Mark Rutland
> - modify description about clock-cells
> - update the example
>
> Changes in v6:
> Advices by Mark Rutland
> - add description about clock-cells
> Advices by Doug
> - modify description about regulator
> - remove pinctrl description
>
> Changes in v5:
> Advices by Mark Brown
> - add description about regulator valid name.
> - add a header file "rockchip,rk808".
>
> Changes in v4:
> Advices by Doug
> - add a "#clock-cells" propertiy
> - update the example
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/rk808.txt | 166
> +++
> include/dt-bindings/clock/rockchip,rk808.h | 11 ++
> 2 files changed, 177 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
> create mode 100644 include/dt-bindings/clock/rockchip,rk808.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt
> b/Documentation/devicetree/bindings/mfd/rk808.txt
> new file mode 100644
> index 000..f8932ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/rk808.txt
> @@ -0,0 +1,166 @@
> +RK808 Power Management Integrated Circuit
> +
> +Required properties:
> +- compatible: "rockchip,rk808"
> +- reg: I2C slave address
> +- interrupt-parent: The parent interrupt controller.
> +- interrupts: the interrupt outputs of the controller.
> +- #clock-cells: from common clock binding; shall be set to 1 (multiple clock
> + outputs)
I think Mark Rutland was looking for something like:
- #clock-cells: from common clock binding; shall be set to 1 (multiple clock
outputs). See for clock IDs.
> +Optional properties:
> +- clock-output-names: From common clock binding to override the
> + default output clock name
> +- rockchip,system-power-controller: Telling whether or not this pmic is
> controlling
> + the system power.
> +
> +Regulators: All the regulators of RK808 to be instantiated shall be
> +listed in a child node named 'regulators'. Each regulator is represented
> +by a child node of the 'regulators' node.
> +
> + regulator-name {
> + /* standard regulator bindings here */
> + };
> +
> +Following regulators of the RK808 PMIC block are supported. Note that
> +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or
> LDO
> +number as described in RK808 datasheet.
> +
> + - DCDC_REGn
> + - valid values for n are 1 to 4.
> + - LDO_REGn
> + - valid values for n are 1 to 8.
> + - SWITCH_REGn
> + - valid values for n are 1 to 2
> +
> +Standard regulator bindings are used inside regulator subnodes. Check
> + Documentation/devicetree/bindings/regulator/regulator.txt
> +for more details
> +
> +Example:
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + clock-output-names = "xin32k", "rk808-clkout2";
> + interrupt-parent = <>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_int>;
> + reg = <0x1b>;
> + rockchip,system-power-controller;
> + wakeup-source;
> + #clock-cells = <1>;
> +
> + vcc8-supply = <_18>;
> + vcc9-supply = <_io>;
> + vcc10-supply = <_io>;
> + vcc12-supply = <_io>;
> + vddio-supply = <_pmu>;
Technically the "-supply" section shouldn't be here. I plan to add
support for input supplies once you've landed your series. See
Re: [PATCH net-next] r8152: rename rx_buf_sz
From: Hayes Wang Date: Tue, 2 Sep 2014 10:27:52 +0800 > The variable "rx_buf_sz" is used by both tx and rx buffers. Replace > it with "agg_buf_sz". > > Signed-off-by: Hayes Wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/5] dt-bindings: Add RK808 device tree bindings document
Chris,
On Mon, Sep 1, 2014 at 2:07 AM, Chris Zhong wrote:
> Add device tree bindings documentation and a header file
> for rockchip's RK808 pmic.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Zhang Qing
>
> ---
>
> Changes in v7:
> Advices by Mark Rutland
> - modify description about clock-cells
> - update the example
>
> Changes in v6:
> Advices by Mark Rutland
> - add description about clock-cells
> Advices by Doug
> - modify description about regulator
> - remove pinctrl description
>
> Changes in v5:
> Advices by Mark Brown
> - add description about regulator valid name.
> - add a header file "rockchip,rk808".
>
> Changes in v4:
> Advices by Doug
> - add a "#clock-cells" propertiy
> - update the example
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/rk808.txt | 166
> +++
> include/dt-bindings/clock/rockchip,rk808.h | 11 ++
> 2 files changed, 177 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
> create mode 100644 include/dt-bindings/clock/rockchip,rk808.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt
> b/Documentation/devicetree/bindings/mfd/rk808.txt
> new file mode 100644
> index 000..f8932ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/rk808.txt
> @@ -0,0 +1,166 @@
> +RK808 Power Management Integrated Circuit
> +
> +Required properties:
> +- compatible: "rockchip,rk808"
> +- reg: I2C slave address
> +- interrupt-parent: The parent interrupt controller.
> +- interrupts: the interrupt outputs of the controller.
> +- #clock-cells: from common clock binding; shall be set to 1 (multiple clock
> + outputs)
I think Mark Rutland was looking for something like:
- #clock-cells: from common clock binding; shall be set to 1 (multiple clock
outputs). See for clock IDs.
> +Optional properties:
> +- clock-output-names: From common clock binding to override the
> + default output clock name
> +- rockchip,system-power-controller: Telling whether or not this pmic is
> controlling
> + the system power.
> +
> +Regulators: All the regulators of RK808 to be instantiated shall be
> +listed in a child node named 'regulators'. Each regulator is represented
> +by a child node of the 'regulators' node.
> +
> + regulator-name {
> + /* standard regulator bindings here */
> + };
> +
> +Following regulators of the RK808 PMIC block are supported. Note that
> +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or
> LDO
> +number as described in RK808 datasheet.
> +
> + - DCDC_REGn
> + - valid values for n are 1 to 4.
> + - LDO_REGn
> + - valid values for n are 1 to 8.
> + - SWITCH_REGn
> + - valid values for n are 1 to 2
> +
> +Standard regulator bindings are used inside regulator subnodes. Check
> + Documentation/devicetree/bindings/regulator/regulator.txt
> +for more details
> +
> +Example:
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + clock-output-names = "xin32k", "rk808-clkout2";
> + interrupt-parent = <>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_int>;
> + reg = <0x1b>;
> + rockchip,system-power-controller;
> + wakeup-source;
> + #clock-cells = <1>;
> +
> + vcc8-supply = <_18>;
> + vcc9-supply = <_io>;
> + vcc10-supply = <_io>;
> + vcc12-supply = <_io>;
> + vddio-supply = <_pmu>;
Technically the "-supply" section shouldn't be here. I plan to add
support for input supplies once you've landed your series. See
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/01/2014 06:04 PM, Peter Zijlstra wrote: > On Mon, Sep 01, 2014 at 12:52:19PM +0300, Michael S. Tsirkin wrote: >> On Mon, Sep 01, 2014 at 11:31:59AM +0200, Peter Zijlstra wrote: >>> On Fri, Aug 22, 2014 at 07:01:05AM +0200, Mike Galbraith wrote: > +++ b/include/net/busy_poll.h > @@ -109,7 +109,8 @@ static inline bool sk_busy_loop(struct sock *sk, int > nonblock) > cpu_relax(); > > } while (!nonblock && skb_queue_empty(>sk_receive_queue) && > - !need_resched() && !busy_loop_timeout(end_time)); > + !need_resched() && !busy_loop_timeout(end_time) && > + nr_running_this_cpu() < 2); > >>> So as has been said by now; this is horrible. >>> >>> We should not export nr_running like this ever. Your usage of < 2 >>> implies this can be hit with nr_running == 0, and therefore you can also >>> hit it with nr_running == 1 where the one is not network related and you >>> get random delays. >>> >>> Worse still, you have BH (and thereby preemption) disabled, you should >>> not _ever_ have undefined and indefinite waits like that. >>> >>> You also destroy any hope of dropping into lower power states; even when >>> there's never going to be a packet ever again, also bad. >> Hmm this patch sometimes makes us exit from the busy loop *earlier*. >> How can this interfere with dropping into lower power states? > Ah.. jetlag.. :/ I read it like it owuld indefinitely spin if there was > only the 'one' task, not avoid the spin unless there was the one task. > > The nr_running thing is still horrible, but let me reread this patch > description to see if it explains why that is a good thing. I see, how about just exporting a boolean helper like current_can_busy_loop() and take care all of the conditions (pending bhs and rcu callbacks, runnable processes) in scheduler code itself? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv1 1/7] ASoC: simple-card: Merge single and muti DAI link code.
> > On Mon, Sep 01, 2014 at 03:34:12PM +0200, Andrew Lunn wrote: > > On Mon, Sep 01, 2014 at 12:29:35PM +0800, Xiubo Li wrote: > > > This patch merge single DAI link and muti-DAI links code together, > > > and simply the simple-card driver code. > > > It would be good to note that this breaks the Binary API with DT > > blobs. Old blobs will not work with this new C code. > > That's not on, we need to maintian compatibility with the old DTs unless > there's a very strong reason not to. Revising the binding is one option > for doing this, keeping the old binding in place and making a v2 binding > with the new functionality. Yes, agree. Actually, the current code is a bit more complicated that we should keep in mind of two styles of single DAI link and muti-DAI links. And the binding document and code are a little unreadable. For others must read the simple card code carefully to add one DT node. Thanks, BRs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: net: NET_XGENE should depend on HAS_DMA
From: Geert Uytterhoeven Date: Fri, 29 Aug 2014 18:21:41 +0200 > If NO_DMA=y: ... > Signed-off-by: Geert Uytterhoeven Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/01/2014 02:55 PM, Eliezer Tamir wrote: > On 26/08/2014 10:16, Jason Wang wrote: >> On 08/25/2014 09:16 PM, Eliezer Tamir wrote: >>> Here are my 2 cents: >>> I think Ingo's suggestion of only yielding to tasks with same or higher >>> priority makes sense. >> I'm not sure I get your meaning. Do you mean calling yield_to() directly >> in sk_busy_loop? > Think about the case where two processes are busy polling on the > same CPU and the same device queue. Since busy polling processes > incoming packets on the queue from any process, this scenario works > well currently, I see, but looks like we can simply do this by exiting the busy loop when ndo_busy_poll() finds something but not for current socket? > and will not work at all when polling yields to other > processes that are of the same priority that are running on the same > CPU. So yielding has its limitation, we need let scheduler to do the choice instead. > > As a side note, there is a lot of room for improvement when two > processes on the same CPU want to busy poll on different device > queues. > The RFC code I published for epoll support showed one possible > way of solving this, but I'm sure that there are other possibilities. > > Maybe the networking subsystem should maintain a list of device > queues that need busypolling and have a thread that would poll > all of them when there's nothing better to do. Not sure whether this method will scale considering thousands of sockets and processes. > > I'm aware of similar work on busy polling on NVMe devices, so > maybe there should be a global busypoll thread for all devices > that support it. > > BTW, I have someone inside Intel that wants to test future patches. Feel > free to send me patches for testing, even if they are not ready for > publishing yet. > > Cheers, > Eliezer Ok, will do it, thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/01/2014 02:39 PM, Eliezer Tamir wrote: > On 29/08/2014 06:08, Jason Wang wrote: >> > Yes, but rx busy polling only works in process context and does not >> > disable bh, so it may be not an issue. > sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled. > > -Eliezer True, so we need probably also exit the loop when there are pending bhs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error
On Tue, Sep 02, 2014 at 10:25:55AM +0800, Axel Lin wrote: > 2014-09-02 10:11 GMT+08:00 Greg Kroah-Hartman : > > On Tue, Sep 02, 2014 at 09:47:37AM +0800, Axel Lin wrote: > >> 2014-08-03 10:36 GMT+08:00 Axel Lin : > >> > This driver uses GENERIC_IRQ_CHIP, so it needs to select > >> > GENERIC_IRQ_CHIP to > >> > avoid build error. > >> > > >> > Fixes below build errors: > >> > ERROR: "irq_alloc_domain_generic_chips" > >> > [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > >> > ERROR: "irq_gc_mask_clr_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > >> > undefined! > >> > ERROR: "irq_gc_mask_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > >> > undefined! > >> > ERROR: "irq_generic_chip_ops" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > >> > undefined! > >> > ERROR: "irq_gc_ack_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > >> > ERROR: "irq_get_domain_generic_chip" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > >> > undefined! > >> > make[1]: *** [__modpost] Error 1 > >> > make: *** [modules] Error 2 > >> > >> Hi Greg, > >> > >> I still hit this build error in today's linuex-next tree with below config: > >> ARCH_MULTIPLATFORM && !SOC_IMX5 && !SOC_IMX6Q && !SOC_IMX6SL > >> > >> This driver just moved from staging to gpu. > >> So it's not clear to me who will pick up this patch. > >> Can you pick up this patch? > > > > As the code isn't in the staging tree, why shouldn't it go through the > > drivers/gpu/* maintainer? > > scripts/get_maintainer.pl > sent/0001-gpu-ipu-v3-select-GENERIC_IRQ_CHIP-to-fix-build-erro.patch > Greg Kroah-Hartman (commit_signer:1/1=100%) > Lucas Stach (commit_signer:1/1=100%) > Philipp Zabel > (commit_signer:1/1=100%,authored:1/1=100%,added_lines:7/7=100%) > linux-kernel@vger.kernel.org (open list) > > I checked the MAINTAINERS file, > I can only find the maintainer for some subfolders of drivers/gpu but no entry > for drivers/gpu/ipu-v3. > So I'm not sure who is the maintainer for drivers/gpu/ipu-v3. Who moved the file out of staging? I don't think it was me... I think it is Philipp, who sent the patches through the drm tree, so try those developers. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] net: mvberlin_eth: add an Ethernet driver for Marvell Berlin
From: Antoine Tenart
Date: Fri, 29 Aug 2014 15:50:59 +0200
> +struct rx_desc {
> + u16 buf_size; /* Buffer size */
> + u16 byte_cnt; /* Descriptor buffer byte count */
...
> + u16 byte_cnt; /* buffer byte count*/
> + u16 l4i_chk;/* CPU provided TCP checksum*/
I'm really suspcious that you're ordering these two members differently
than that used by the mv643xx_eth driver.
Looking at a diff of the two drivers, most of the transmit and recieve paths
are largely the same.
WRT. register differences, adding indirection to handle that is a no-brainer
because the cost of the register access itself will absolutely dwarf whatever
it costs to do an indirect call or whatever to implement the register access.
I really think you should look into sharing code more seriously.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
Hi, On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote: > On 08/29/2014 06:12 PM, Tony Lindgren wrote: > > Looks like the paste bug is there for sure, doing off idle and pasting > > 240 characters to the console can hang the UART RX after few attempts, > > and pasting 16 charactes won't show up at all if the system is idling. > > So you may want to play with that too a bit :) > > One character wakes it up. After that you can send 16, 64 and you see > them. Right away. No delay. > > If you send "a lot" data in one-go it takes approx 152 characters until > the first one is displayed properly at 115200,8N1. That is approx 13ms. > Could it take that long to get up and be ready? I noticed the same behaviour when I tested the runtime PM stuff on my N900 with the existing serial-omap driver and I also assumed, that the chip needs that long to get up. > Comparing it with serial-omap I see the same thing: I takes approx the > same amount of data until the first one is displayed. After a lot of > "long" writes which wake the chip up from idle I manage to freeze both, > the serial-omap driver and mine driver. > > One thing that is probably a dumb idea is that printk in > omap_8250_mdr1_errataset(). > Would it be possible that when I hit a printk in the resume path that I > may deadlock and box will freeze? -- Sebastian signature.asc Description: Digital signature
RE: Regression: Wake up from Suspend to RAM crashes ToshibaSatellitelaptop to black screen
> From: Zhang Rui [mailto:rui.zh...@intel.com] > Sent: Monday, September 01, 2014 4:09 PM [...] > Hi, Hayes, > > We got a regression report complaining that wakeup from Suspend to RAM > crashes, please refer to > https://bugzilla.kernel.org/show_bug.cgi?id=82741 > > and it seems that it is introduced by commit > b51ecea852b712618796d9eab8428a7d5f1f106f. I couldn't reproduce the issue on my PC. It would be better if I could borrow the platform to debug. Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/panel: update innolux n116bge timings
There are several different models of N116BGE. According to the commit
that added innolux_n116bge_mode [0], this N116BGE is for the eDP variety.
[0] commit 0a2288c06aab73c966e82045c8f20b0e713baf2a
Author: Thierry Reding
Date: Thu Jul 3 14:02:59 2014 +0200
drm/panel: simple: Add Innolux N116BGE panel support
The clock and htotal values from add by that patch are out of spec according to
the datasheets I have seen for the eDP N116BGE (-EA2 and -EB2).
This patch changes the values to the "Typ" values on the datasheet.
Signed-off-by: Daniel Kurtz
---
Thierry,
It is possible that your timings were correct for the panel you are using on
the norrin reference board. In that case I'm happy to upload a new patch
that creates a new panel entry. However, I'm pretty sure we are using the
same N116BGE.
drivers/gpu/drm/panel/panel-simple.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..776764a 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -519,15 +519,15 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
};
static const struct drm_display_mode innolux_n116bge_mode = {
- .clock = 71000,
+ .clock = 76420,
.hdisplay = 1366,
- .hsync_start = 1366 + 64,
- .hsync_end = 1366 + 64 + 6,
- .htotal = 1366 + 64 + 6 + 64,
+ .hsync_start = 1366 + 136,
+ .hsync_end = 1366 + 136 + 30,
+ .htotal = 1366 + 136 + 30 + 60,
.vdisplay = 768,
.vsync_start = 768 + 8,
- .vsync_end = 768 + 8 + 4,
- .vtotal = 768 + 8 + 4 + 8,
+ .vsync_end = 768 + 8 + 12,
+ .vtotal = 768 + 8 + 12 + 12,
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: calxedaxgmac: fix driver dependencies
On Mon, Sep 1, 2014 at 10:39 AM, Bartlomiej Zolnierkiewicz wrote: > Calxeda 1G/10G XGMAC Ethernet support should be available only on > Calxeda ECX-1000/2000 (Highbank/Midway) platforms. > > Signed-off-by: Bartlomiej Zolnierkiewicz > Acked-by: Kyungmin Park > Cc: Rob Herring > --- > drivers/net/ethernet/calxeda/Kconfig |1 + > 1 file changed, 1 insertion(+) > > Index: b/drivers/net/ethernet/calxeda/Kconfig > === > --- a/drivers/net/ethernet/calxeda/Kconfig 2014-07-30 14:31:12.159522474 > +0200 > +++ b/drivers/net/ethernet/calxeda/Kconfig 2014-09-01 17:33:49.232810483 > +0200 > @@ -1,6 +1,7 @@ > config NET_CALXEDA_XGMAC > tristate "Calxeda 1G/10G XGMAC Ethernet driver" > depends on HAS_IOMEM && HAS_DMA > + depends on ARCH_HIGHBANK || COMPILE_TEST Opinions differ on whether drivers should be restricted in this way. There is no actual dependency requiring ARCH_HIGHBANK. So I leave it to David. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] r8152: rename rx_buf_sz
The variable "rx_buf_sz" is used by both tx and rx buffers. Replace
it with "agg_buf_sz".
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cc64dc0..80b0179 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -607,9 +607,9 @@ enum tx_csum_stat {
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
*/
static const int multicast_filter_limit = 32;
-static unsigned int rx_buf_sz = 16384;
+static unsigned int agg_buf_sz = 16384;
-#define RTL_LIMITED_TSO_SIZE (rx_buf_sz - sizeof(struct tx_desc) - \
+#define RTL_LIMITED_TSO_SIZE (agg_buf_sz - sizeof(struct tx_desc) - \
VLAN_ETH_HLEN - VLAN_HLEN)
static
@@ -1248,13 +1248,13 @@ static int alloc_all_mem(struct r8152 *tp)
skb_queue_head_init(>tx_queue);
for (i = 0; i < RTL8152_MAX_RX; i++) {
- buf = kmalloc_node(rx_buf_sz, GFP_KERNEL, node);
+ buf = kmalloc_node(agg_buf_sz, GFP_KERNEL, node);
if (!buf)
goto err1;
if (buf != rx_agg_align(buf)) {
kfree(buf);
- buf = kmalloc_node(rx_buf_sz + RX_ALIGN, GFP_KERNEL,
+ buf = kmalloc_node(agg_buf_sz + RX_ALIGN, GFP_KERNEL,
node);
if (!buf)
goto err1;
@@ -1274,13 +1274,13 @@ static int alloc_all_mem(struct r8152 *tp)
}
for (i = 0; i < RTL8152_MAX_TX; i++) {
- buf = kmalloc_node(rx_buf_sz, GFP_KERNEL, node);
+ buf = kmalloc_node(agg_buf_sz, GFP_KERNEL, node);
if (!buf)
goto err1;
if (buf != tx_agg_align(buf)) {
kfree(buf);
- buf = kmalloc_node(rx_buf_sz + TX_ALIGN, GFP_KERNEL,
+ buf = kmalloc_node(agg_buf_sz + TX_ALIGN, GFP_KERNEL,
node);
if (!buf)
goto err1;
@@ -1518,7 +1518,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
tx_data = agg->head;
agg->skb_num = 0;
agg->skb_len = 0;
- remain = rx_buf_sz;
+ remain = agg_buf_sz;
while (remain >= ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
@@ -1565,7 +1565,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
dev_kfree_skb_any(skb);
- remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
+ remain = agg_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
}
if (!skb_queue_empty(_head)) {
@@ -1771,7 +1771,7 @@ static
int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
- agg->head, rx_buf_sz,
+ agg->head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
return usb_submit_urb(agg->urb, mem_flags);
@@ -1915,8 +1915,8 @@ static void set_tx_qlen(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
- tp->tx_qlen = rx_buf_sz / (netdev->mtu + VLAN_ETH_HLEN + VLAN_HLEN +
- sizeof(struct tx_desc));
+ tp->tx_qlen = agg_buf_sz / (netdev->mtu + VLAN_ETH_HLEN + VLAN_HLEN +
+ sizeof(struct tx_desc));
}
static inline u8 rtl8152_get_speed(struct r8152 *tp)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error
2014-09-02 10:11 GMT+08:00 Greg Kroah-Hartman : > On Tue, Sep 02, 2014 at 09:47:37AM +0800, Axel Lin wrote: >> 2014-08-03 10:36 GMT+08:00 Axel Lin : >> > This driver uses GENERIC_IRQ_CHIP, so it needs to select GENERIC_IRQ_CHIP >> > to >> > avoid build error. >> > >> > Fixes below build errors: >> > ERROR: "irq_alloc_domain_generic_chips" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] >> > undefined! >> > ERROR: "irq_gc_mask_clr_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! >> > ERROR: "irq_gc_mask_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! >> > ERROR: "irq_generic_chip_ops" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! >> > ERROR: "irq_gc_ack_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! >> > ERROR: "irq_get_domain_generic_chip" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] >> > undefined! >> > make[1]: *** [__modpost] Error 1 >> > make: *** [modules] Error 2 >> >> Hi Greg, >> >> I still hit this build error in today's linuex-next tree with below config: >> ARCH_MULTIPLATFORM && !SOC_IMX5 && !SOC_IMX6Q && !SOC_IMX6SL >> >> This driver just moved from staging to gpu. >> So it's not clear to me who will pick up this patch. >> Can you pick up this patch? > > As the code isn't in the staging tree, why shouldn't it go through the > drivers/gpu/* maintainer? scripts/get_maintainer.pl sent/0001-gpu-ipu-v3-select-GENERIC_IRQ_CHIP-to-fix-build-erro.patch Greg Kroah-Hartman (commit_signer:1/1=100%) Lucas Stach (commit_signer:1/1=100%) Philipp Zabel (commit_signer:1/1=100%,authored:1/1=100%,added_lines:7/7=100%) linux-kernel@vger.kernel.org (open list) I checked the MAINTAINERS file, I can only find the maintainer for some subfolders of drivers/gpu but no entry for drivers/gpu/ipu-v3. So I'm not sure who is the maintainer for drivers/gpu/ipu-v3. Thanks, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4: fix comments about get_blocks
On Mon, Sep 01, 2014 at 10:16:02PM +0900, Seunghun Lee wrote: > get_blocks is renamed to get_block. > > Signed-off-by: Seunghun Lee Applied, thanks. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error
On Tue, Sep 02, 2014 at 09:47:37AM +0800, Axel Lin wrote: > 2014-08-03 10:36 GMT+08:00 Axel Lin : > > This driver uses GENERIC_IRQ_CHIP, so it needs to select GENERIC_IRQ_CHIP to > > avoid build error. > > > > Fixes below build errors: > > ERROR: "irq_alloc_domain_generic_chips" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > > undefined! > > ERROR: "irq_gc_mask_clr_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > > ERROR: "irq_gc_mask_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > > ERROR: "irq_generic_chip_ops" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > > ERROR: "irq_gc_ack_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > > ERROR: "irq_get_domain_generic_chip" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > > undefined! > > make[1]: *** [__modpost] Error 1 > > make: *** [modules] Error 2 > > Hi Greg, > > I still hit this build error in today's linuex-next tree with below config: > ARCH_MULTIPLATFORM && !SOC_IMX5 && !SOC_IMX6Q && !SOC_IMX6SL > > This driver just moved from staging to gpu. > So it's not clear to me who will pick up this patch. > Can you pick up this patch? As the code isn't in the staging tree, why shouldn't it go through the drivers/gpu/* maintainer? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND 0/5] PCIe, AER: Misc cleanup
On Wed, Aug 13, 2014 at 09:52:36PM -0400, Chen, Gong wrote: > Date: Wed, 13 Aug 2014 21:52:36 -0400 > From: "Chen, Gong" > To: Bjorn Helgaas > Cc: Randy Dunlap , Borislav Petkov , > Tony Luck , "linux-...@vger.kernel.org" > , "linux-kernel@vger.kernel.org" > > Subject: Re: [RESEND 0/5] PCIe, AER: Misc cleanup > User-Agent: Mutt/1.5.23 (2014-03-12) > > On Wed, Aug 13, 2014 at 07:52:45AM -0600, Bjorn Helgaas wrote: > > I haven't responded because I've been on vacation for the past three > > weeks. If there's no change in the patches themselves, and if they > > are still in http://patchwork.ozlabs.org/project/linux-pci/list, the > > only thing reposting them does is make more work for me. > > > There is one difference existed in Patch 1. I add more explanation in > the comments as Boris suggested. Hi, Bjorn Any comments? signature.asc Description: Digital signature
Re: [PATCH 1/2] gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error
2014-08-03 10:36 GMT+08:00 Axel Lin : > This driver uses GENERIC_IRQ_CHIP, so it needs to select GENERIC_IRQ_CHIP to > avoid build error. > > Fixes below build errors: > ERROR: "irq_alloc_domain_generic_chips" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > undefined! > ERROR: "irq_gc_mask_clr_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > ERROR: "irq_gc_mask_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > ERROR: "irq_generic_chip_ops" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > ERROR: "irq_gc_ack_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined! > ERROR: "irq_get_domain_generic_chip" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] > undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 Hi Greg, I still hit this build error in today's linuex-next tree with below config: ARCH_MULTIPLATFORM && !SOC_IMX5 && !SOC_IMX6Q && !SOC_IMX6SL This driver just moved from staging to gpu. So it's not clear to me who will pick up this patch. Can you pick up this patch? Thanks, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using
On 09/02/2014 01:01 AM, H. Peter Anvin wrote: > On 09/01/2014 09:08 AM, Paul Gortmaker wrote: >>> diff --git a/init/Kconfig b/init/Kconfig >>> index ac033c3..f301cc8 100644 >>> --- a/init/Kconfig >>> +++ b/init/Kconfig >>> @@ -23,6 +23,12 @@ config CONSTRUCTORS >>> config IRQ_WORK >>> bool >>> >>> +config CPU_LITTLE_ENDIAN >>> + bool >>> + >>> +config CPU_BIG_ENDIAN >>> + bool >> >> Perhaps you should take a cursory look at what already exists in tree >> before blindly trying to add more to it? >> >> $ git grep CPU_BIG_ENDIAN | wc -l >> 88 >> > > The whole point of this patchset is to make these already widely-used > options universal across the tree. > Yeah, maybe the patch comments need be improved (mention about what you said above) to avoid other members' misunderstanding. If it is necessary (complete the comments), please let me know (I shall send patch v2 for it). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] Regression in drm-intel caused by d91a2cb8e510
On Mon, 1 Sep 2014, Damien Lespiau wrote: > On Mon, Sep 01, 2014 at 04:19:23PM -0400, Alan Stern wrote: > > Daniel: > > > > I'm encountering a problem with the drm-intel-nightly branch in your > > drm-intel repository. The symptom is that when I boot my laptop, at > > some point during the start-up procedure the screen goes totally blank, > > as though the backlight were turned off, and it remains that way. I > > can't tell if the backlight really is off -- it may be that there's > > just nothing being displayed -- and playing with the screen-brightness > > function keys doesn't help. > > > > Git bisect located the source of the problem as commit d91a2cb8e510 > > (drm/i915: Add 180 degree primary plane rotation support). The problem > > occurs when I boot a kernel built from that commit, and it doesn't > > occur when I boot a kernel built from the preceding commit > > (19ac737dc3c3). > > > > If necessary, I can get debugging info by logging in over a network > > connection. Tell me what you need. > > It seems like Ville and Mika already caught a similar bug today, could > you give Ville's patch a go (available on the intel-gfx): > > drm/i915: Don't call intel_plane_restore() when the prop value didn't change Yes, that patch fixed the problem. Thank you. Tested-by: Alan Stern Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: page_alloc: Default to node-ordering on 64-bit NUMA machines
(2014/09/01 21:55), Mel Gorman wrote: Zones are allocated by the page allocator in either node or zone order. Node ordering is preferred in terms of locality and is applied automatically in one of three cases. 1. If a node has only low memory 2. If DMA/DMA32 is a high percentage of memory 3. If low memory on a single node is greater than 70% of the node size Otherwise zone ordering is used to preserve low memory. Unfortunately a consequence of this is that a machine with balanced NUMA nodes will experience different performance characteristics depending on which node they happen to start from. The point of zone ordering is to protect lower nodes for devices that require DMA/DMA32 memory. When NUMA was first introduced, this was critical as 32-bit NUMA machines commonly suffered from low memory exhaustion problems. On 64-bit machines the primary concern is devices that are 32-bit only which is less severe than the low memory exhaustion problem on 32-bit NUMA. It seems there are really few devices that depends on it. AGP -- I assume this is getting more rare but even then I think the allocations happen early in boot time where lowmem pressure is less of a problem DRM -- If the device is 32-bit only then there may be low pressure. I didn't evaluate these in detail but it looks like some of these are mobile graphics card. Not many NUMA laptops out there. DRM folk should know better though. Some TV cards -- Much demand for 32-bit capable TV cards on NUMA machines? B43 wireless card -- again not really a NUMA thing. I cannot find a good reason to incur a performance penalty on all 64-bit NUMA machines in case someone throws a brain damanged TV or graphics card in there. This patch defaults to node-ordering on 64-bit NUMA machines. I was tempted to make it default everywhere but I understand that some embedded arches may be using 32-bit NUMA where I cannot predict the consequences. The performance impact depends on the workload and the characteristics of the machine and the machine I tested on had a large Normal zone on node 0 so the impact is within the noise for the majority of tests. The allocation stats show more allocation requests were from DMA32 and local node. Running SpecJBB with multiple JVMs and automatic NUMA balancing disabled the results were specjbb 3.17.0-rc23.17.0-rc2 vanillanodeorder-v1r1 Min1 29534.00 ( 0.00%) 30020.00 ( 1.65%) Min10115717.00 ( 0.00%)134038.00 ( 15.83%) Min19109718.00 ( 0.00%)114186.00 ( 4.07%) Min28104459.00 ( 0.00%)103639.00 ( -0.78%) Min37 98245.00 ( 0.00%)103756.00 ( 5.61%) Min46 97198.00 ( 0.00%) 96197.00 ( -1.03%) Mean 1 30953.25 ( 0.00%) 31917.75 ( 3.12%) Mean 10124432.50 ( 0.00%)140904.00 ( 13.24%) Mean 19116033.50 ( 0.00%)119294.75 ( 2.81%) Mean 28108365.25 ( 0.00%)106879.50 ( -1.37%) Mean 37102984.75 ( 0.00%)106924.25 ( 3.83%) Mean 46100783.25 ( 0.00%)105368.50 ( 4.55%) Stddev 1 1260.38 ( 0.00%) 1109.66 ( 11.96%) Stddev 10 7434.03 ( 0.00%) 5171.91 ( 30.43%) Stddev 19 8453.84 ( 0.00%) 5309.59 ( 37.19%) Stddev 28 4184.55 ( 0.00%) 2906.63 ( 30.54%) Stddev 37 5409.49 ( 0.00%) 3192.12 ( 40.99%) Stddev 46 4521.95 ( 0.00%) 7392.52 (-63.48%) Max1 32738.00 ( 0.00%) 32719.00 ( -0.06%) Max10136039.00 ( 0.00%)148614.00 ( 9.24%) Max19130566.00 ( 0.00%)127418.00 ( -2.41%) Max28115404.00 ( 0.00%)111254.00 ( -3.60%) Max37112118.00 ( 0.00%)111732.00 ( -0.34%) Max46108541.00 ( 0.00%)116849.00 ( 7.65%) TPut 1 123813.00 ( 0.00%)127671.00 ( 3.12%) TPut 10497730.00 ( 0.00%)563616.00 ( 13.24%) TPut 19464134.00 ( 0.00%)477179.00 ( 2.81%) TPut 28433461.00 ( 0.00%)427518.00 ( -1.37%) TPut 37411939.00 ( 0.00%)427697.00 ( 3.83%) TPut 46403133.00 ( 0.00%)421474.00 ( 4.55%) 3.17.0-rc2 3.17.0-rc2 vanillanodeorder-v1r1 DMA allocs 0 0 DMA32 allocs57 1491992 Normal allocs 3254356630026383 Movable allocs 0 0 Direct pages scanned 0 0 Kswapd pages scanned 0 0 Kswapd pages reclaimed 0 0 Direct pages reclaimed 0 0 Kswapd efficiency 100%100% Kswapd velocity 0.000 0.000 Direct efficiency 100%100% Direct velocity 0.000 0.000 Percentage direct scans 0% 0% Zone normal velocity 0.000 0.000 Zone dma32 velocity
Re: [PATCH] netlink: Safer deletion of sk_bind_node
Harish Jenny K N writes: > From: Harish Jenny K N > > Unable to handle kernel NULL pointer dereference at virtual address > > (netlink_release+0x0/0x2a0) from [<8034e78c>] (sock_release+0x28/0xa4) > (sock_release+0x0/0xa4) from [<8034e830>] (sock_close+0x28/0x34) > (sock_close+0x0/0x34) from [<800f3490>] (__fput+0xf0/0x1ec) > (__fput+0x0/0x1ec) from [<800f3634>] (fput+0x10/0x14) > (fput+0x0/0x14) from [<80040a64>] (task_work_run+0xb8/0xd8) > (task_work_run+0x0/0xd8) from [<800113a0>] (do_work_pending+0xb0/0xc4) > (do_work_pending+0x0/0xc4) from [<8000d960>] (work_pending+0xc/0x20) > Call flow of the inline and static functions > netlink_release > -netlink_remove > -__sk_del_bind_node > --__hlist_del Is there any reason __sk_del_bind_node should not be changed instead? If not there should be a description of what makes netlink's use of __sk_del_bind_node special Eric p.s. Your name was in your from line, but not your email address making it hard to reply to you. > Signed-off-by: Harish Jenny K N > --- > net/netlink/af_netlink.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c > index c416725..21a6b32 100644 > --- a/net/netlink/af_netlink.c > +++ b/net/netlink/af_netlink.c > @@ -1103,7 +1103,7 @@ static void netlink_remove(struct sock *sk) > > netlink_table_grab(); > if (nlk_sk(sk)->subscriptions) > - __sk_del_bind_node(sk); > + hlist_del_init(>sk_bind_node); > netlink_table_ungrab(); > } > > @@ -1382,7 +1382,7 @@ netlink_update_subscriptions(struct sock *sk, unsigned > int subscriptions) > struct netlink_sock *nlk = nlk_sk(sk); > > if (nlk->subscriptions && !subscriptions) > - __sk_del_bind_node(sk); > + hlist_del_init(>sk_bind_node); > else if (!nlk->subscriptions && subscriptions) > sk_add_bind_node(sk, _table[sk->sk_protocol].mc_list); > nlk->subscriptions = subscriptions; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless 2014-08-28
From: "John W. Linville" Date: Thu, 28 Aug 2014 14:17:14 -0400 > Please pull this batch of fixes intended for the 3.17 stream. > > For the Bluetooth/6LowPAN/802.15.4 bits, Johan says: > > 'It contains a connection reference counting fix for LE where a > connection might stay up even though it should get disconnected. > > The other 802.15.4 6LoWPAN related patches were sent to the bluetooth > tree by Alexander Aring and described as follows by him: > > " > these patches contains patches for the bluetooth branch. > > This series includes memory leak fixes and an errno value fix. > Also there are two patches for sending and receiving 1280 6LoWPAN > packets, which makes the IEEE 802.15.4 6LoWPAN stack more RFC > compliant. > "' > > Along with that... > > Alexey Khoroshilov fixes a use-after-free bug on at76c50x-usb. > > Hauke Mehrtens adds a PCI ID to bcma. > > Himangi Saraogi fixes a silly "A || A" test in rtlwifi. > > Larry Finger adds a device ID to rtl8192cu. > > Maks Naumov fixes a strncmp argument in ath9k. > > Álvaro Fernández Rojas adds a PCI ID to ssb. > > Please let me know if there are problems! Pulled, thanks a lot John. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: For review: user_namespace(7) man page
"Michael Kerrisk (man-pages)" writes:
> On 08/30/2014 11:53 PM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>> For various reasons, my work on the namespaces man pages
>>> fell off the table a while back. Nevertheless, the pages have
>>> been close to completion for a while now, and I recently restarted,
>>> in an effort to finish them. As you also noted to me f2f, there have
>>> been recently been some small namespace changes that you may affect
>>> the content of the pages. Therefore, I'll take the opportunity to
>>> send the namespace-related pages out for further (final?) review.
>>>
>>> So, here, I start with the user_namespaces(7) page, which is shown
>>> in rendered form below, with source attached to this mail. I'll
>>> send various other pages in follow-on mails.
>>>
>>> Review comments/suggestions for improvements / bug fixes welcome.
>>>
>>> Cheers,
>>>
>>> Michael
>>>
>>> ==
>>>
>>> NAME
>>>user_namespaces - overview of Linux user_namespaces
>>>
>>> DESCRIPTION
>>>For an overview of namespaces, see namespaces(7).
>>>
>>>User namespaces isolate security-related identifiers and
>>>attributes, in particular, user IDs and group IDs (see creden‐
>>>tials(7), the root directory, keys (see keyctl(2)), and capabili‐
>>>ties (see capabilities(7)). A process's user and group IDs can
>>>be different inside and outside a user namespace. In particular,
>>>a process can have a normal unprivileged user ID outside a user
>>>namespace while at the same time having a user ID of 0 inside the
>>>namespace; in other words, the process has full privileges for
>>>operations inside the user namespace, but is unprivileged for
>>>operations outside the namespace.
>>>
>>>Nested namespaces, namespace membership
>>>User namespaces can be nested; that is, each user namespace—
>>>except the initial ("root") namespace—has a parent user names‐
>>>pace, and can have zero or more child user namespaces. The par‐
>>>ent user namespace is the user namespace of the process that cre‐
>>>ates the user namespace via a call to unshare(2) or clone(2) with
>>>the CLONE_NEWUSER flag.
>>>
>>>The kernel imposes (since version 3.11) a limit of 32 nested lev‐
>>>els of user namespaces. Calls to unshare(2) or clone(2) that
>>>would cause this limit to be exceeded fail with the error EUSERS.
>>>
>>>Each process is a member of exactly one user namespace. A
>>>process created via fork(2) or clone(2) without the CLONE_NEWUSER
>>>flag is a member of the same user namespace as its parent.
>>>A
>>^ single-threaded
>>
>> Because of chroot and other things multi-threaded processes are not
>> allowed to join a user namespace. For the documentation just saying
>> single-threaded sounds like enough here.
>
> Thanks. Fixed.
>
>>>process can join another user namespace with setns(2) if it has
>>>the CAP_SYS_ADMIN in that namespace; upon doing so, it gains a
>>>full set of capabilities in that namespace.
>>>
>>>A call to clone(2) or unshare(2) with the CLONE_NEWUSER flag
>>>makes the new child process (for clone(2)) or the caller (for
>>>unshare(2)) a member of the new user namespace created by the
>>>call.
>>>
>>>Capabilities
>>>The child process created by clone(2) with the CLONE_NEWUSER flag
>>>starts out with a complete set of capabilities in the new user
>>>namespace. Likewise, a process that creates a new user namespace
>>>using unshare(2) or joins an existing user namespace using
>>>setns(2) gains a full set of capabilities in that namespace. On
>>>the other hand, that process has no capabilities in the parent
>>>(in the case of clone(2)) or previous (in the case of unshare(2)
>>>and setns(2)) user namespace, even if the new namespace is cre‐
>>>ated or joined by the root user (i.e., a process with user ID 0
>>>in the root namespace).
>>>
>>>Note that a call to execve(2) will cause a process to lose any
>>>capabilities that it has, unless it has a user ID of 0 within the
>>>namespace. See the discussion of user and group ID mappings,
>>>below.
>>>
>>>A call to clone(2), unshare(2), or setns(2) using the
>>>CLONE_NEWUSER flag sets the "securebits" flags (see capabili‐
>>>ties(7)) to their default values (all flags disabled) in the
>>>child (for clone(2)) or caller (for unshare(2), or setns(2)).
>>>Note that because the caller no longer has capabilities in its
>>>original user namespace after a call to setns(2), it is not pos‐
>>>sible for a process to reset its
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland wrote:
> On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors. It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker
>> ---
>> Documentation/devicetree/bindings/mips/gic.txt | 50
>> ++
>> 1 file changed, 50 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>> b/Documentation/devicetree/bindings/mips/gic.txt
>> new file mode 100644
>> index 000..725f1ef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> @@ -0,0 +1,50 @@
>> +MIPS Global Interrupt Controller (GIC)
>> +
>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> +It also supports a timer and software-generated interrupts which can be
>> +used as IPIs.
>> +
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
>
> I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> there's not a patch to add it elsewhere, would you mind providing one
> with this series?
Sure. As James points out, "img" could also be used but I chose "mti"
since the CPU interrupt controller also uses "mti" and I believe the
GIC IP was developed before the acquisition by Imagination (though I'm
not sure if that actually matters).
>> +- reg : Base address and length of the GIC registers.
>> +- interrupts : Core interrupts to which the GIC may route external
>> interrupts.
>
> How many?
Up to 6, one for each of the possible core hardware interrupts (i.e.
interrupt vectors 2 - 7). Which ones are available to the GIC depend
on the system, for example Malta has an i8259 PIC hooked up to CPU
interrupt vector 2, so that vector should not be used by the GIC.
> In any order?
They can technically be in any order, but when in strictly
increasing/decreasing order they can be used along with the 3rd cell
(described below) to prioritize interrupts.
>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> + interrupt specifier. Should be 3.
>> + - The first cell is the GIC interrupt number.
>> + - The second cell encodes the interrupt flags.
>> +See for a list of valid
>> +flags.
>
> Are all the flags valid for this interrupt controller?
Yes.
>> + - The optional third cell indicates which CPU interrupt vector the GIC
>> +interrupt should be routed to. It is a 0-based index into the list of
>> +GIC-to-CPU interrupts specified in the "interrupts" property described
>> +above. For example, a '2' in this cell will route the interrupt to the
>> +3rd core interrupt listed in 'interrupts'. If omitted, the interrupt
>> will
>> +be routed to the 1st core interrupt.
>
> I don't follow why this should be in the DT. Why is this necessary?
Since the GIC can route external interrupts to any of the CPU hardware
interrupt vectors, it can be used to assign priorities to external
interrupts. If the CPU is in vectored interrupt mode, the highest
numbered interrupt vector (7) has the highest priority. An example:
gic: interrupt-controller@1bdc {
...
interrupts = <3>, <4>;
...
};
uart {
...
interrupt-parent = <>;
interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
...
};
i2c {
...
interrupt-parent = <>;
interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
...
};
Since the third cell for the UART is '1', it maps to CPU interrupt
vector 4 and thus has a higher priority than the I2C (whose third cell
is 0, mapping to CPU interrupt vector 3).
Perhaps, though, this is an instance of software policy being
specified in device-tree. Other options would be to a) evenly
distribute the GIC external interrupts across the CPU interrupt
vectors available to the GIC, or b) just map all GIC external
interrupts to a single interrupt vector.
> I also don't follow how this can be ommitted, given interrupt-cells is
> required to be three by the wording above.
If it's absent, the interrupt will be routed to the first CPU
interrupt vector in the list. It's equivalent to the third cell being
0.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: rk808: Fix n_voltages for DCDC4
The min_sel is 0, max_sel is 15, so n_voltages should be 16.
Signed-off-by: Axel Lin
---
drivers/regulator/rk808-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index 0d11df1..0da8867 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -146,7 +146,7 @@ static const struct regulator_desc rk808_reg[] = {
.id = RK808_ID_DCDC4,
.ops = _reg_ops,
.type = REGULATOR_VOLTAGE,
- .n_voltages = 17,
+ .n_voltages = 16,
.linear_ranges = rk808_buck4_voltage_ranges,
.n_linear_ranges = ARRAY_SIZE(rk808_buck4_voltage_ranges),
.vsel_reg = RK808_BUCK4_ON_VSEL_REG,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] Tegra124 CL-DVFS / DFLL clocksource, plus cpufreq
Quoting Tuomas Tynkkynen (2014-08-20 14:04:28)
> v4 changes:
> DFLL:
> - fix wrong register accessors used for the DFLL_OUTPUT_CFG register
> - I decided to leave the dfll_i2c_{readl,writel} separate since the
> correct barrier function still needs to be called
> - fix PMIC I2C voltage register address being uninitialized
> cpufreq:
> - back to 'depends on GENERIC_CPUFREQ_CPU0' from 'select
> GENERIC_CPUFREQ_CPU0'
> - leads to new patch to update the defconfigs
> - check for get_cpu_device() return value
> - add comment why an extra platform driver+device is required
>
> v3 changes:
> - Fix incorrect order of arguments to dfll_scale_dvco_rate
> - Fix accidental commas at end-of-statement to semicolons
> - Some cpufreq changes:
> - rename cpufreq-tegra to cpufreq-tegra20
> - have separate Kconfig entries for Tegra20/Tegra124 support
> - use 'select GENERIC_CPUFREQ_CPU0', not depends
> - support unbinding of the platform device
> - requires adding the vdd_cpu regulator to the DT so
> the old voltage can be restored when switching to PLLX
> - allocate a state structure instead of globals
> - use of_match_machine()
> - various style nits fixed
>
> The cpufreq part is dependant on the of_match_machine() series.
>
> Original cover letter:
>
> This series implements the DFLL/CL-DVFS clock source for the fast CPU
> cluster on Tegra124, and a cpufreq driver that uses the DFLL for
> clocking the CPU. Most of this is based on Paul Walmsley's public patch
> set from December 2013, which is available at
> http://comments.gmane.org/gmane.linux.ports.tegra/15273
>
> The DFLL clock hardware is a voltage-controlled oscillator plus
> control logic that compares the generated output clock with a
> 51 MHz reference clock, and can make decisions to either lower
> or raise the DFLL voltage to keep the output rate close to the
> software-requested rate. The voltage changes are done by
> communicating with an off-chip PMIC via either I2C or PWM.
> As the DFLL oscillator is powered via the CPU rail, using
> the DFLL as the CPU clocksource also gives us dynamic CPU
> voltage scaling.
>
> This series has been tested on the Jetson TK1 (Rev C). Porting this to
> the Venice2 should be simple, though do note that it does not have
> active cooling.
At a quick glance, the clock driver changes look good to me.
Regards,
Mike
>
> Thanks,
> Tuomas
>
> Paul Walmsley (1):
> clk: tegra: Add DFLL DVCO reset control for Tegra124
>
> Tuomas Tynkkynen (15):
> clk: tegra: Add binding for the Tegra124 DFLL clocksource
> clk: tegra: Add library for the DFLL clock source (open-loop mode)
> clk: tegra: Add closed loop support for the DFLL
> clk: tegra: Add functions for parsing CVB tables
> clk: tegra: Add Tegra124 DFLL clocksource platform driver
> clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend
> clk: tegra: Add the DFLL as a possible parent of the cclk_g clock
> ARM: tegra: Add the DFLL to Tegra124 device tree
> ARM: tegra: Enable the DFLL on the Jetson TK1
> cpufreq: tegra124: Add device tree bindings
> cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq
> cpufreq: Add cpufreq driver for Tegra124
> ARM: tegra: Add entries for cpufreq on Tegra124
> ARM: tegra: Add CPU regulator to the Jetson TK1 device tree
> ARM: tegra: enable Tegra124 cpufreq driver by default
>
> .../bindings/clock/nvidia,tegra124-dfll.txt| 69 +
> .../bindings/cpufreq/tegra124-cpufreq.txt | 44 +
> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 12 +-
> arch/arm/boot/dts/tegra124.dtsi| 33 +-
> arch/arm/configs/tegra_defconfig |1 +
> arch/arm/mach-tegra/Kconfig|1 +
> drivers/clk/tegra/Makefile |3 +
> drivers/clk/tegra/clk-dfll.c | 1741
>
> drivers/clk/tegra/clk-dfll.h | 55 +
> drivers/clk/tegra/clk-tegra-super-gen4.c |4 +-
> drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 165 ++
> drivers/clk/tegra/clk-tegra124.c | 61 +
> drivers/clk/tegra/clk.h|3 +
> drivers/clk/tegra/cvb.c| 133 ++
> drivers/clk/tegra/cvb.h| 67 +
> drivers/cpufreq/Kconfig.arm| 13 +-
> drivers/cpufreq/Makefile |3 +-
> drivers/cpufreq/tegra124-cpufreq.c | 215 +++
> .../cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} |0
> 19 files changed, 2616 insertions(+), 7 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
> create mode 100644
> Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
> create mode 100644 drivers/clk/tegra/clk-dfll.c
> create mode 100644 drivers/clk/tegra/clk-dfll.h
>
[PATCH 01/12] Staging: rtl8821ae: hal_bt_coexist: fix commenting style
Fix commenting style from C99 comments to C89 comments
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index 8bee772..cff300c 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -44,7 +44,7 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
PRX_TS_RECORD pRxTs = NULL;
if(b_reject){
- // Do not allow receiving A-MPDU aggregation.
+ /* Do not allow receiving A-MPDU aggregation. */
if (rtlpriv->mac80211.vendor == PEER_CISCO) {
if (pHTInfo->bAcceptAddbaReq) {
RTPRINT(FBT, BT_TRACE, ("BT_Disallow
AMPDU \n"));
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue which requires a space before the open
curly brace '{'.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index cff300c..b9afcfc 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -43,7 +43,7 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
struct rtl_priv rtlpriv = rtl_priv(hw);
PRX_TS_RECORD pRxTs = NULL;
- if(b_reject){
+ if(b_reject) {
/* Do not allow receiving A-MPDU aggregation. */
if (rtlpriv->mac80211.vendor == PEER_CISCO) {
if (pHTInfo->bAcceptAddbaReq) {
@@ -224,7 +224,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state(struct
ieee80211_hw *hw,
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_RSSI_MEDIUM;
if ((rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
- (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_STAY_LOW)){
+ (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_STAY_LOW)) {
if (undecoratedsmoothed_pwdb
>= (rssi_thresh + BT_FW_COEX_THRESH_TOL)) {
bt_rssi_state = BT_RSSI_STATE_HIGH;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue which requires a space after the open
parenthesis '('.
Signed-off-by: An Ha
---
.../staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 50 +++---
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index b9afcfc..bce3771 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -43,13 +43,13 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
struct rtl_priv rtlpriv = rtl_priv(hw);
PRX_TS_RECORD pRxTs = NULL;
- if(b_reject) {
+ if (b_reject) {
/* Do not allow receiving A-MPDU aggregation. */
if (rtlpriv->mac80211.vendor == PEER_CISCO) {
if (pHTInfo->bAcceptAddbaReq) {
RTPRINT(FBT, BT_TRACE, ("BT_Disallow
AMPDU \n"));
pHTInfo->bAcceptAddbaReq = FALSE;
- if(GetTs(Adapter,
(PTS_COMMON_INFO*)(), pMgntInfo->Bssid, 0, RX_DIR, FALSE))
+ if (GetTs(Adapter,
(PTS_COMMON_INFO*)(), pMgntInfo->Bssid, 0, RX_DIR, FALSE))
TsInitDelBA(Adapter,
(PTS_COMMON_INFO)pRxTs, RX_DIR);
}
} else {
@@ -59,7 +59,7 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
}
}
} else {
- if(rtlpriv->mac80211.vendor == PEER_CISCO) {
+ if (rtlpriv->mac80211.vendor == PEER_CISCO) {
if (!pHTInfo->bAcceptAddbaReq) {
RTPRINT(FBT, BT_TRACE, ("BT_Allow AMPDU
\n"));
pHTInfo->bAcceptAddbaReq = TRUE;
@@ -78,13 +78,13 @@ struct rtl_phy *rtlphy = &(rtlpriv->phy);
if (rtlpriv->link_info.b_busytraffic) {
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_WIFI_IDLE;
- if(rtlpriv->link_info.b_tx_busy_traffic) {
+ if (rtlpriv->link_info.b_tx_busy_traffic) {
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_UPLINK;
} else {
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_UPLINK;
}
- if(rtlpriv->link_info.b_rx_busy_traffic) {
+ if (rtlpriv->link_info.b_rx_busy_traffic) {
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_DOWNLINK;
} else {
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_DOWNLINK;
@@ -102,7 +102,7 @@ if (rtlpriv->mac80211.mode == WIRELESS_MODE_G
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_WIFI_HT40;
} else {
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_WIFI_LEGACY;
- if(rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40) {
+ if (rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40) {
rtlpcipriv->btcoexist.current_state |= BT_COEX_STATE_WIFI_HT40;
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_WIFI_HT20;
} else {
@@ -130,12 +130,12 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct
ieee80211_hw *hw,
undecoratedsmoothed_pwdb = rtl8821ae_dm_bt_get_rx_ss(hw);
- if(level_num == 2) {
+ if (level_num == 2) {
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_RSSI_1_MEDIUM;
- if( (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
+ if ( (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
(rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_STAY_LOW)) {
- if(undecoratedsmoothed_pwdb >= (rssi_thresh +
BT_FW_COEX_THRESH_TOL)) {
+ if (undecoratedsmoothed_pwdb >= (rssi_thresh +
BT_FW_COEX_THRESH_TOL)) {
bt_rssi_state = BT_RSSI_STATE_HIGH;
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_RSSI_1_HIGH;
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_RSSI_1_LOW;
@@ -145,7 +145,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct
ieee80211_hw *hw,
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("[DM][BT], RSSI_1 state stay at Low\n"));
}
} else {
- if(undecoratedsmoothed_pwdb < rssi_thresh) {
+ if (undecoratedsmoothed_pwdb < rssi_thresh) {
bt_rssi_state = BT_RSSI_STATE_LOW;
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_RSSI_1_LOW;
[PATCH 05/12] Staging: rtl8821ae: hal_bt_coexist: fix pointer placement coding style issue
Fix pointer placement coding style issue, where using "foo *" is
preferable over "foo*".
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index 48c6160..a478ee4 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -49,7 +49,7 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
if (pHTInfo->bAcceptAddbaReq) {
RTPRINT(FBT, BT_TRACE, ("BT_Disallow
AMPDU \n"));
pHTInfo->bAcceptAddbaReq = FALSE;
- if (GetTs(Adapter,
(PTS_COMMON_INFO*)(), pMgntInfo->Bssid, 0, RX_DIR, FALSE))
+ if (GetTs(Adapter, (PTS_COMMON_INFO
*)(), pMgntInfo->Bssid, 0, RX_DIR, FALSE))
TsInitDelBA(Adapter,
(PTS_COMMON_INFO)pRxTs, RX_DIR);
}
} else {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue which requires a space after the equal sign '='.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index 38addec..d587072 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -347,7 +347,7 @@ void rtl8821ae_dm_bt_balance(struct ieee80211_hw *hw,
{
struct rtl_pci_priv *rtlpcipriv = rtl_pcipriv(hw);
struct rtl_priv *rtlpriv = rtl_priv(hw);
- u8 h2c_parameter[3] ={0};
+ u8 h2c_parameter[3] = {0};
if (b_balance_on) {
h2c_parameter[2] = 1;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue which requires a space after a comma.
Signed-off-by: An Ha
---
.../staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 26 +++---
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index bce3771..48c6160 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -197,7 +197,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct
ieee80211_hw *hw,
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_RSSI_1_MEDIUM;
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_RSSI_1_HIGH;
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_RSSI_1_LOW;
- RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,("[DM][BT],
RSSI_1 state switch to Medium\n"));
+ RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("[DM][BT], RSSI_1 state switch to Medium\n"));
} else {
bt_rssi_state = BT_RSSI_STATE_STAY_HIGH;
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("[DM][BT], RSSI_1 state stay at High\n"));
@@ -382,11 +382,11 @@ void rtl8821ae_dm_bt_agc_table(struct ieee80211_hw *hw,
u8 type)
if (type == BT_AGCTABLE_OFF) {
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE, ("[BT]AGCTable Off!\n"));
- rtl_write_dword(rtlpriv, 0xc78,0x641c0001);
- rtl_write_dword(rtlpriv, 0xc78,0x631d0001);
- rtl_write_dword(rtlpriv, 0xc78,0x621e0001);
- rtl_write_dword(rtlpriv, 0xc78,0x611f0001);
- rtl_write_dword(rtlpriv, 0xc78,0x6021);
+ rtl_write_dword(rtlpriv, 0xc78, 0x641c0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x631d0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x621e0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x611f0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x6021);
rtl8821ae_phy_set_rf_reg(hw, RF90_PATH_A,
RF_RX_AGC_HP, 0xf, 0x32000);
@@ -400,11 +400,11 @@ void rtl8821ae_dm_bt_agc_table(struct ieee80211_hw *hw,
u8 type)
RF_RX_G1, 0xf, 0x30355);
} else if (type == BT_AGCTABLE_ON) {
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE, ("[BT]AGCTable On!\n"));
- rtl_write_dword(rtlpriv, 0xc78,0x4e1c0001);
- rtl_write_dword(rtlpriv, 0xc78,0x4d1d0001);
- rtl_write_dword(rtlpriv, 0xc78,0x4c1e0001);
- rtl_write_dword(rtlpriv, 0xc78,0x4b1f0001);
- rtl_write_dword(rtlpriv, 0xc78,0x4a21);
+ rtl_write_dword(rtlpriv, 0xc78, 0x4e1c0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x4d1d0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x4c1e0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x4b1f0001);
+ rtl_write_dword(rtlpriv, 0xc78, 0x4a21);
rtl8821ae_phy_set_rf_reg(hw, RF90_PATH_A,
RF_RX_AGC_HP, 0xf, 0xdc000);
@@ -428,10 +428,10 @@ void rtl8821ae_dm_bt_bb_back_off_level(struct
ieee80211_hw *hw, u8 type)
if (type == BT_BB_BACKOFF_OFF) {
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE, ("[BT]BBBackOffLevel
Off!\n"));
- rtl_write_dword(rtlpriv, 0xc04,0x3a05611);
+ rtl_write_dword(rtlpriv, 0xc04, 0x3a05611);
} else if (type == BT_BB_BACKOFF_ON) {
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE, ("[BT]BBBackOffLevel
On!\n"));
- rtl_write_dword(rtlpriv, 0xc04,0x3a07611);
+ rtl_write_dword(rtlpriv, 0xc04, 0x3a07611);
rtlpcipriv->btcoexist.b_sw_coexist_all_off = false;
}
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue where the open curly brace '{' should be on
the same line as the if statement.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index 869b094..38addec 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -288,8 +288,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state(struct
ieee80211_hw *hw,
&= ~BT_COEX_STATE_WIFI_RSSI_MEDIUM;
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("[DM][BT], RSSI state switch to
High\n"));
- } else if (undecoratedsmoothed_pwdb < rssi_thresh)
- {
+ } else if (undecoratedsmoothed_pwdb < rssi_thresh) {
bt_rssi_state = BT_RSSI_STATE_LOW;
rtlpcipriv->btcoexist.current_state
|= BT_COEX_STATE_WIFI_RSSI_LOW;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Remove unnecessary whitespace before a quoted newline.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index b0326c9..938c98a 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -47,7 +47,7 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
/* Do not allow receiving A-MPDU aggregation. */
if (rtlpriv->mac80211.vendor == PEER_CISCO) {
if (pHTInfo->bAcceptAddbaReq) {
- RTPRINT(FBT, BT_TRACE, ("BT_Disallow
AMPDU \n"));
+ RTPRINT(FBT, BT_TRACE, ("BT_Disallow
AMPDU\n"));
pHTInfo->bAcceptAddbaReq = FALSE;
if (GetTs(Adapter, (PTS_COMMON_INFO
*)(), pMgntInfo->Bssid, 0, RX_DIR, FALSE))
TsInitDelBA(Adapter,
(PTS_COMMON_INFO)pRxTs, RX_DIR);
@@ -61,7 +61,7 @@ void rtl8821ae_dm_bt_reject_ap_aggregated_packet(struct
ieee80211_hw *hw, bool b
} else {
if (rtlpriv->mac80211.vendor == PEER_CISCO) {
if (!pHTInfo->bAcceptAddbaReq) {
- RTPRINT(FBT, BT_TRACE, ("BT_Allow AMPDU
\n"));
+ RTPRINT(FBT, BT_TRACE, ("BT_Allow
AMPDU\n"));
pHTInfo->bAcceptAddbaReq = TRUE;
}
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue where the if statement unnecessarily uses curly
braces for one line statements.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index 938c98a..f1cf373 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -78,17 +78,15 @@ struct rtl_phy *rtlphy = &(rtlpriv->phy);
if (rtlpriv->link_info.b_busytraffic) {
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_WIFI_IDLE;
- if (rtlpriv->link_info.b_tx_busy_traffic) {
+ if (rtlpriv->link_info.b_tx_busy_traffic)
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_UPLINK;
- } else {
+ else
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_UPLINK;
- }
- if (rtlpriv->link_info.b_rx_busy_traffic) {
+ if (rtlpriv->link_info.b_rx_busy_traffic)
rtlpcipriv->btcoexist.current_state |=
BT_COEX_STATE_WIFI_DOWNLINK;
- } else {
+ else
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_DOWNLINK;
- }
} else {
rtlpcipriv->btcoexist.current_state |= BT_COEX_STATE_WIFI_IDLE;
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_WIFI_UPLINK;
@@ -111,12 +109,11 @@ if (rtlpriv->mac80211.mode == WIRELESS_MODE_G
}
}
-if (bt_operation_on) {
+if (bt_operation_on)
rtlpcipriv->btcoexist.current_state |= BT_COEX_STATE_BT30;
-} else {
+else
rtlpcipriv->btcoexist.current_state &= ~BT_COEX_STATE_BT30;
}
-}
u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct ieee80211_hw *hw,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Remove whitespace after open parenthesis '('.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index a478ee4..b0326c9 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -133,7 +133,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct
ieee80211_hw *hw,
if (level_num == 2) {
rtlpcipriv->btcoexist.current_state &=
~BT_COEX_STATE_WIFI_RSSI_1_MEDIUM;
- if ( (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
+ if ((rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
(rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_STAY_LOW)) {
if (undecoratedsmoothed_pwdb >= (rssi_thresh +
BT_FW_COEX_THRESH_TOL)) {
bt_rssi_state = BT_RSSI_STATE_HIGH;
@@ -161,7 +161,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct
ieee80211_hw *hw,
return rtlpcipriv->btcoexist.bt_pre_rssi_state;
}
- if ( (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
+ if ((rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_LOW) ||
(rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_STAY_LOW)) {
if (undecoratedsmoothed_pwdb >=
(rssi_thresh+BT_FW_COEX_THRESH_TOL)) {
bt_rssi_state = BT_RSSI_STATE_MEDIUM;
@@ -173,7 +173,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state1(struct
ieee80211_hw *hw,
bt_rssi_state = BT_RSSI_STATE_STAY_LOW;
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("[DM][BT], RSSI_1 state stay at Low\n"));
}
- } else if ( (rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_MEDIUM) ||
+ } else if ((rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_MEDIUM) ||
(rtlpcipriv->btcoexist.bt_pre_rssi_state ==
BT_RSSI_STATE_STAY_MEDIUM)) {
if (undecoratedsmoothed_pwdb >= (rssi_thresh1 +
BT_FW_COEX_THRESH_TOL)) {
bt_rssi_state = BT_RSSI_STATE_HIGH;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue which requires a blank line after declarations.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index d587072..293bf9d 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -435,6 +435,7 @@ void rtl8821ae_dm_bt_fw_coex_all_off(struct ieee80211_hw
*hw)
{
struct rtl_pci_priv *rtlpcipriv = rtl_pcipriv(hw);
struct rtl_priv *rtlpriv = rtl_priv(hw);
+
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("rtl8821ae_dm_bt_fw_coex_all_off()\n"));
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] Staging: rtl8821ae: hal_bt_coexist: fix coding style issue
Fix coding style issue where the else conditional statement should
follow the closing curly brace '}'.
Signed-off-by: An Ha
---
drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
index f1cf373..869b094 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.c
@@ -251,8 +251,7 @@ u8 rtl8821ae_dm_bt_check_coex_rssi_state(struct
ieee80211_hw *hw,
("[DM][BT], RSSI state stay at
High\n"));
}
}
- }
- else if (level_num == 3) {
+ } else if (level_num == 3) {
if (rssi_thresh > rssi_thresh1) {
RT_TRACE(COMP_BT_COEXIST, DBG_TRACE,
("[DM][BT], RSSI thresh error!!\n"));
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package.
From: Mika Westerberg
Adds ACPICA kernel runtime support to validate contents/format
of the _DSD package, similar to the iASL support. Ported by
Mika Westerberg.
Signed-off-by: Mika Westerberg
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/nsprepkg.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/acpi/acpica/nsprepkg.c b/drivers/acpi/acpica/nsprepkg.c
index 68f7258..1b13b92 100644
--- a/drivers/acpi/acpica/nsprepkg.c
+++ b/drivers/acpi/acpica/nsprepkg.c
@@ -316,6 +316,45 @@ acpi_ns_check_package(struct acpi_evaluate_info *info,
acpi_ns_check_package_list(info, package, elements, count);
break;
+ case ACPI_PTYPE2_UUID_PAIR:
+
+ /* The package must contain pairs of (UUID + type) */
+
+ if (count & 1) {
+ expected_count = count + 1;
+ goto package_too_small;
+ }
+
+ while (count > 0) {
+ status = acpi_ns_check_object_type(info, elements,
+ package->ret_info.
+ object_type1, 0);
+ if (ACPI_FAILURE(status)) {
+ return (status);
+ }
+
+ /* Validate length of the UUID buffer */
+
+ if ((*elements)->buffer.length != 16) {
+ ACPI_WARN_PREDEFINED((AE_INFO,
+ info->full_pathname,
+ info->node_flags,
+ "Invalid length for UUID
Buffer"));
+ return (AE_AML_OPERAND_VALUE);
+ }
+
+ status = acpi_ns_check_object_type(info, elements + 1,
+ package->ret_info.
+ object_type2, 0);
+ if (ACPI_FAILURE(status)) {
+ return (status);
+ }
+
+ elements += 2;
+ count -= 2;
+ }
+ break;
+
default:
/* Should not get here if predefined info table is correct */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] ACPICA: 20140828 Release
The 20140828 ACPICA kernel-resident subsystem updates are linuxized based on the pm/linux-next branch to form this patchset. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. i386 + allyes + CONFIG_ACPI=y 3. i386 + default + COFNIG_ACPI=n 4. i386 + allyes + CONFIG_ACPI=n 5. x86_64 + default + COFNIG_ACPI=y 6. x86_64 + allyes + CONFIG_ACPI=y 7. x86_64 + default + COFNIG_ACPI=n 8. x86_64 + allyes + CONFIG_ACPI=n Boot tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. x86_64 + default + COFNIG_ACPI=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All drivers/acpi configurations All platform drivers The divergences checking result: Before applying (20140724 Release): 848 lines After applying (20140828 Release): 710 lines Bob Moore (3): ACPICA: Add _PSx names to the METHOD_NAME list. ACPICA: Disassembler: Fix for gpio_int interrupt polarity flags. ACPICA: Update version to 20140828. Hanjun Guo (2): ACPICA: ACPI 5.1/Disassembler: Add GICC affinity subtable to SRAT table. ACPICA: Headers: Add GTDT flag definitions for the timer subtable. Mika Westerberg (1): ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package. drivers/acpi/acpica/nsprepkg.c | 39 +++ drivers/acpi/acpica/utresrc.c |4 +++- include/acpi/acnames.h |4 include/acpi/acpixf.h |2 +- include/acpi/actbl1.h | 19 +-- include/acpi/actbl3.h |9 +++-- 6 files changed, 71 insertions(+), 6 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ACPICA: Disassembler: Fix for gpio_int interrupt polarity flags.
From: Bob Moore
The field is actually 2 bits, not 1.
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/utresrc.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c
index 14cb6c0..5cd017c 100644
--- a/drivers/acpi/acpica/utresrc.c
+++ b/drivers/acpi/acpica/utresrc.c
@@ -87,7 +87,9 @@ const char *acpi_gbl_io_decode[] = {
const char *acpi_gbl_ll_decode[] = {
"ActiveHigh",
- "ActiveLow"
+ "ActiveLow",
+ "ActiveBoth",
+ "Reserved"
};
const char *acpi_gbl_max_decode[] = {
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] ACPICA: Update version to 20140828.
From: Bob Moore Version 20140828. Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index b7c89d4..dc9d037 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20140724 +#define ACPI_CA_VERSION 0x20140828 #include #include -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ACPICA: Headers: Add GTDT flag definitions for the timer subtable.
From: Hanjun Guo
Mostly by Hanjun Guo
Signed-off-by: Hanjun Guo
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
include/acpi/actbl3.h |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
index 787bcc8..5480cb2 100644
--- a/include/acpi/actbl3.h
+++ b/include/acpi/actbl3.h
@@ -310,10 +310,15 @@ struct acpi_gtdt_timer_entry {
u32 common_flags;
};
+/* Flag Definitions: timer_flags and virtual_timer_flags above */
+
+#define ACPI_GTDT_GT_IRQ_MODE (1)
+#define ACPI_GTDT_GT_IRQ_POLARITY (1<<1)
+
/* Flag Definitions: common_flags above */
-#define ACPI_GTDT_GT_IS_SECURE_TIMER(1)
-#define ACPI_GTDT_GT_ALWAYS_ON (1<<1)
+#define ACPI_GTDT_GT_IS_SECURE_TIMER(1)
+#define ACPI_GTDT_GT_ALWAYS_ON (1<<1)
/* 1: SBSA Generic Watchdog Structure */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] ACPICA: ACPI 5.1/Disassembler: Add GICC affinity subtable to SRAT table.
From: Hanjun Guo
Update template for SRAT.
Add clock_domain to standard CPU affinity subtable.
Mostly by Hanjun Guo
Signed-off-by: Hanjun Guo
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
include/acpi/actbl1.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 7626bfe..29e7937 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -952,7 +952,8 @@ enum acpi_srat_type {
ACPI_SRAT_TYPE_CPU_AFFINITY = 0,
ACPI_SRAT_TYPE_MEMORY_AFFINITY = 1,
ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY = 2,
- ACPI_SRAT_TYPE_RESERVED = 3 /* 3 and greater are reserved */
+ ACPI_SRAT_TYPE_GICC_AFFINITY = 3,
+ ACPI_SRAT_TYPE_RESERVED = 4 /* 4 and greater are reserved */
};
/*
@@ -968,7 +969,7 @@ struct acpi_srat_cpu_affinity {
u32 flags;
u8 local_sapic_eid;
u8 proximity_domain_hi[3];
- u32 reserved; /* Reserved, must be zero */
+ u32 clock_domain;
};
/* Flags */
@@ -1010,6 +1011,20 @@ struct acpi_srat_x2apic_cpu_affinity {
#define ACPI_SRAT_CPU_ENABLED (1)/* 00: Use affinity structure */
+/* 3: GICC Affinity (ACPI 5.1) */
+
+struct acpi_srat_gicc_affinity {
+ struct acpi_subtable_header header;
+ u32 proximity_domain;
+ u32 acpi_processor_uid;
+ u32 flags;
+ u32 clock_domain;
+};
+
+/* Flags for struct acpi_srat_gicc_affinity */
+
+#define ACPI_SRAT_GICC_ENABLED (1) /* 00: Use affinity structure */
+
/* Reset to default packing */
#pragma pack()
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] ACPICA: Add _PSx names to the METHOD_NAME list.
From: Bob Moore Will be used by iASL. Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acnames.h |4 1 file changed, 4 insertions(+) diff --git a/include/acpi/acnames.h b/include/acpi/acnames.h index c728113..f97804b 100644 --- a/include/acpi/acnames.h +++ b/include/acpi/acnames.h @@ -59,6 +59,10 @@ #define METHOD_NAME__PRS"_PRS" #define METHOD_NAME__PRT"_PRT" #define METHOD_NAME__PRW"_PRW" +#define METHOD_NAME__PS0"_PS0" +#define METHOD_NAME__PS1"_PS1" +#define METHOD_NAME__PS2"_PS2" +#define METHOD_NAME__PS3"_PS3" #define METHOD_NAME__REG"_REG" #define METHOD_NAME__SB_"_SB_" #define METHOD_NAME__SEG"_SEG" -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v1 2/5] mfd: lpc_sch: better code manageability with chipset info struct
> -Original Message- > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] > Sent: 01 September, 2014 6:25 PM > To: Lee Jones > Cc: Bjorn Helgaas; linux-kernel@vger.kernel.org; Samuel Ortiz; Chang, Rebecca > Swee Fun > Subject: Re: [PATCH v1 2/5] mfd: lpc_sch: better code manageability with > chipset info struct > > On Mon, 2014-09-01 at 10:16 +0100, Lee Jones wrote: > > On Fri, 22 Aug 2014, Andy Shevchenko wrote: > > > > > Introduce additional struct to hold chipset info. This chipset info > > > will be used to store features that are supported by specific > > > processor or chipset. LPC_SCH supports SMBUS, GPIO and WDT features. > > > As this code base might expand further to support more processors, > > > this implementation will help to keep code base clean and manageable. > > > > > > Signed-off-by: Chang Rebecca Swee Fun > > > > > > Tested-by: Chang Rebecca Swee Fun > > > Signed-off-by: Andy Shevchenko > > [] > > > > The first patch would look a great deal cleaner if it had these > > changes in too. Unless you have a really good reason not to, please > > consider squashing them. > > The only reason behind is that this patch (in other form) was written by > Rebecca in the first place. I recommended to clean up before, and actually did > that clean up and amended Rebecca's patch. > > So, if Rebecca has now objections I could squash it. I have no objections. Thanks. > > > -- > Andy Shevchenko Intel Finland Oy
RE: [PATCH v1 3/5] pci_ids: add support for Intel Quark ILB
> -Original Message- > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] > Sent: 01 September, 2014 5:14 PM > To: Bjorn Helgaas > Cc: Lee Jones; linux-kernel@vger.kernel.org; Samuel Ortiz; Chang, Rebecca > Swee Fun; Ahmad, Josef > Subject: Re: [PATCH v1 3/5] pci_ids: add support for Intel Quark ILB > > On Fri, 2014-08-29 at 08:27 -0600, Bjorn Helgaas wrote: > > On Fri, Aug 22, 2014 at 4:58 AM, Andy Shevchenko > > wrote: > > > From: Josef Ahmad > > > > > > This patch adds the PCI id for Intel Quark ILB. > > > It will be used for GPIO and Multifunction device driver. > > > > > > Signed-off-by: Josef Ahmad > > > Signed-off-by: Andy Shevchenko > > > > Assuming that this will actually be used in more than one place: > > Yes, look for the other IDs in the same driver (lpc_sch). > > The question is will we have the update for sch_gpio in time to be included to > v3.18? I think Rebecca can answer to this one. Yes, we are working on updating sch_gpio but I can't give you a confirm answer whether it will be included in v3.18. Sch_gpio has been scheduled as my 2nd priority work currently. However, I will try to make it in time if possible. Rebecca > > > > > Acked-by: Bjorn Helgaas > > > > > --- > > > include/linux/pci_ids.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index > > > 6ed0bb7..4e82195 100644 > > > --- a/include/linux/pci_ids.h > > > +++ b/include/linux/pci_ids.h > > > @@ -2557,6 +2557,7 @@ > > > #define PCI_DEVICE_ID_INTEL_MFD_EMMC0 0x0823 #define > > > PCI_DEVICE_ID_INTEL_MFD_EMMC1 0x0824 > > > #define PCI_DEVICE_ID_INTEL_MRST_SD2 0x084F > > > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB0x095E > > > #define PCI_DEVICE_ID_INTEL_I960 0x0960 > > > #define PCI_DEVICE_ID_INTEL_I960RM 0x0962 > > > #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB 0x0c60 > > > -- > > > 2.1.0 > > > > > > -- > Andy Shevchenko Intel Finland Oy
Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h
On Mon, Sep 1, 2014 at 1:34 AM, Arnd Bergmann wrote: > On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote: >> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann wrote: >> > On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote: >> >> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and >> >> the upcoming Danube board in . Since Sead-3 is >> >> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0), >> >> define its MIPS_GIC_IRQ_BASE in . >> >> >> >> Signed-off-by: Andrew Bresticker >> >> >> > >> > Why do you actually have to hardwire an IRQ base? Can't you move >> > to the linear irqdomain code for DT based MIPS systems yet? >> >> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they >> still require a hard-coded IRQ base. For boards using device-tree, I >> stuck with a legacy IRQ domain as it allows most of the existing GIC >> irqchip code to be reused. > > I see. Note that we now have irq_domain_add_simple(), which should > do the right think in either case: use a legacy domain when a > nonzero base is provided for the old boards, but use the simple > domain when probed from DT without an irq base. > > This makes the latter case more memory efficient (it avoids > allocating the irq descriptors for every possibly but unused > IRQ number) and helps ensure that you don't accidentally rely > on hardcoded IRQ numbers for the DT based machines, which would > be considered a bug. Ah, ok. It looks like add_simple() is what I want then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver
The at91sam9g20 SOC uses its own pllb implementation which is different
from the one inherited from at91sam9260 SOC.
Signed-off-by: Gaël PORTAY
---
arch/arm/boot/dts/at91sam9g20.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi
b/arch/arm/boot/dts/at91sam9g20.dtsi
index 31f7652..4e0abbd 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -40,6 +40,7 @@
};
pllb: pllbck {
+ compatible =
"atmel,at91sam9g20-clk-pllb";
atmel,clk-input-range = <200
3200>;
atmel,pll-clk-output-ranges = <3000
1 0 0>;
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/super.c: do not shrink fs slab during direct memory reclaim
On Fri, Aug 29, 2014 at 05:57:22PM +0800, Xue jiufei wrote: > The patch trys to solve one deadlock problem caused by cluster > fs, like ocfs2. And the problem may happen at least in the below > situations: > 1)Receiving a connect message from other nodes, node queues a > work_struct o2net_listen_work. > 2)o2net_wq processes this work and calls sock_alloc() to allocate > memory for a new socket. > 3)It would do direct memory reclaim when available memory is not > enough and trigger the inode cleanup. That inode being cleaned up > is happened to be ocfs2 inode, so call evict()->ocfs2_evict_inode() > ->ocfs2_drop_lock()->dlmunlock()->o2net_send_message_vec(), > and wait for the unlock response from master. > 4)tcp layer received the response, call o2net_data_ready() and > queue sc_rx_work, waiting o2net_wq to process this work. > 5)o2net_wq is a single thread workqueue, it process the work one by > one. Right now it is still doing o2net_listen_work and cannot handle > sc_rx_work. so we deadlock. > > It is impossible to set GFP_NOFS for memory allocation in sock_alloc(). > So we use PF_FSTRANS to avoid the task reentering filesystem when > available memory is not enough. > > Signed-off-by: joyce.xue For the second time: use memalloc_noio_save/memalloc_noio_restore. And please put a great big comment in the code explaining why you need to do this special thing with memory reclaim flags. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] semaphore: Resolve some shadow warnings
On Mon, 2014-09-01 at 14:02 +0200, Peter Zijlstra wrote: > On Thu, Aug 28, 2014 at 05:19:26AM -0700, Jeff Kirsher wrote: > > From: Mark Rustad > > > > Resolve some shadow warnings resulting from using the name > > jiffies, which is a well-known global. This is not a problem > > of course, but it could be a trap for someone copying and > > pasting code, and it just makes W=2 a little cleaner. > > > > Signed-off-by: Mark Rustad > > Signed-off-by: Jeff Kirsher > > Why isn't Mark sending this email? Mark sent me several patches like this, for me to push upstream. So, I am making sure the appropriate owner is the receives the patch versus blindly sending to LKML. > > > --- > > kernel/locking/semaphore.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c > > index 6815171..7782dbc 100644 > > --- a/kernel/locking/semaphore.c > > +++ b/kernel/locking/semaphore.c > > @@ -36,7 +36,7 @@ > > static noinline void __down(struct semaphore *sem); > > static noinline int __down_interruptible(struct semaphore *sem); > > static noinline int __down_killable(struct semaphore *sem); > > -static noinline int __down_timeout(struct semaphore *sem, long jiffies); > > +static noinline int __down_timeout(struct semaphore *sem, long njiffies); > > static noinline void __up(struct semaphore *sem); > > So what's wrong with calling it "timeout" instead? That's what most > other sites do. Timeout would work as well to resolve the shadow warnings. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] net: sh_eth: fix driver dependencies
On Mon, Sep 01, 2014 at 06:36:19PM +0200, Geert Uytterhoeven wrote: > On Mon, Sep 1, 2014 at 4:25 PM, Bartlomiej Zolnierkiewicz > wrote: > > Renesas SuperH Ethernet support should be available only on > > Renesas ARM SoCs and SuperH architecture. > > > > Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Kyungmin Park > > Cc: Simon Horman > > Cc: Magnus Damm > > --- > > v2: > > - s/ARCH_SH/SUPERH/ (thanks to Sergei Shtylyov) > > Acked-by: Geert Uytterhoeven Acked-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: renesas_usbhs: fix driver dependencies
On Mon, Sep 01, 2014 at 06:40:50PM +0200, Geert Uytterhoeven wrote: > On Mon, Sep 1, 2014 at 4:24 PM, Bartlomiej Zolnierkiewicz > wrote: > > Renesas USBHS controller support should be available only on > > Renesas ARM SoCs and SuperH architecture. > > > > Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Kyungmin Park > > Cc: Simon Horman > > Cc: Magnus Damm > > --- > > v2: > > - s/ARCH_SH/SUPERH/ (thanks to Sergei Shtylyov) > > Acked-by: Geert Uytterhoeven Acked-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v4l: vsp1: fix driver dependencies
On Mon, Sep 01, 2014 at 06:32:56PM +0200, Geert Uytterhoeven wrote: > On Mon, Sep 1, 2014 at 3:18 PM, Bartlomiej Zolnierkiewicz > wrote: > > Renesas VSP1 Video Processing Engine support should be available > > only on Renesas ARM SoCs. > > Thanks! > > > Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Kyungmin Park > > Cc: Simon Horman > > Cc: Magnus Damm > > Acked-by: Geert Uytterhoeven Acked-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / Domains: Make generic_pm_domain.name const
On Friday, August 29, 2014 03:13:21 PM Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
I'm going to apply this one. Does anything depend on it?
> ---
> include/linux/pm_domain.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 7c1d252b20c0..ebc4c76ffb73 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -60,7 +60,7 @@ struct generic_pm_domain {
> struct mutex lock;
> struct dev_power_governor *gov;
> struct work_struct power_off_work;
> - char *name;
> + const char *name;
> unsigned int in_progress; /* Number of devices being suspended
> now */
> atomic_t sd_count; /* Number of subdomains with power "on" */
> enum gpd_status status; /* Current state of the domain */
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powercap/rapl: lower warning level for domain detection
On Thursday, August 28, 2014 09:56:08 PM Jacob Pan wrote:
> Many CPUs do not support complete set of RAPL domains, as a
> result this detection failed message is very misleading and
> annoying. So lower the warning message to info and reword.
>
> Signed-off-by: Jacob Pan
What about printing a (info-level) message if the RAPL domain *is*
supported? That surely is more interesting?
> ---
> drivers/powercap/intel_rapl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index b1cda6f..0b282e7 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -1169,7 +1169,7 @@ static int rapl_detect_domains(struct rapl_package *rp,
> int cpu)
> if (!rapl_check_domain(cpu, i))
> rp->domain_map |= 1 << i;
> else
> - pr_warn("RAPL domain %s detection failed\n",
> + pr_info("RAPL domain %s not supported\n",
> rapl_domain_names[i]);
> }
> rp->nr_domains = bitmap_weight(>domain_map, RAPL_DOMAIN_MAX);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PM / sleep: Fix test_suspend= command line option
From: Rafael J. Wysocki
After commit d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs
interface code) the pm_states[] array is not populated initially,
which causes setup_test_suspend() to always fail and the suspend
testing during boot doesn't work any more.
Fix the problem by using pm_labels[] instead of pm_states[] in
setup_test_suspend() and storing a pointer to the label of the
sleep state to test rather than the number representing it,
because the connection between the state numbers and labels is
only established by suspend_set_ops().
Fixes: d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code)
Reported-by: Srinivas Pandruvada
Signed-off-by: Rafael J. Wysocki
---
kernel/power/power.h|1 +
kernel/power/suspend.c |2 +-
kernel/power/suspend_test.c | 29 +
3 files changed, 19 insertions(+), 13 deletions(-)
Index: linux-pm/kernel/power/power.h
===
--- linux-pm.orig/kernel/power/power.h
+++ linux-pm/kernel/power/power.h
@@ -179,6 +179,7 @@ extern void swsusp_show_speed(struct tim
#ifdef CONFIG_SUSPEND
/* kernel/power/suspend.c */
+extern const char *pm_labels[];
extern const char *pm_states[];
extern int suspend_devices_and_enter(suspend_state_t state);
Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -31,7 +31,7 @@
#include "power.h"
-static const char *pm_labels[] = { "mem", "standby", "freeze", };
+const char *pm_labels[] = { "mem", "standby", "freeze", NULL };
const char *pm_states[PM_SUSPEND_MAX];
static const struct platform_suspend_ops *suspend_ops;
Index: linux-pm/kernel/power/suspend_test.c
===
--- linux-pm.orig/kernel/power/suspend_test.c
+++ linux-pm/kernel/power/suspend_test.c
@@ -129,20 +129,20 @@ static int __init has_wakealarm(struct d
* at startup time. They're normally disabled, for faster boot and because
* we can't know which states really work on this particular system.
*/
-static suspend_state_t test_state __initdata = PM_SUSPEND_ON;
+static const char *test_state_label __initdata;
static char warn_bad_state[] __initdata =
KERN_WARNING "PM: can't test '%s' suspend state\n";
static int __init setup_test_suspend(char *value)
{
- suspend_state_t i;
+ int i;
/* "=mem" ==> "mem" */
value++;
- for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
- if (!strcmp(pm_states[i], value)) {
- test_state = i;
+ for (i = 0; pm_labels[i]; i++)
+ if (!strcmp(pm_labels[i], value)) {
+ test_state_label = pm_labels[i];
return 0;
}
@@ -158,13 +158,19 @@ static int __init test_suspend(void)
struct rtc_device *rtc = NULL;
struct device *dev;
+ suspend_state_t test_state;
/* PM is initialized by now; is that state testable? */
- if (test_state == PM_SUSPEND_ON)
- goto done;
- if (!pm_states[test_state]) {
- printk(warn_bad_state, pm_states[test_state]);
- goto done;
+ if (!test_state_label)
+ return 0;
+
+ for (test_state = PM_SUSPEND_MIN; test_state < PM_SUSPEND_MAX;
test_state++)
+ if (!strcmp(test_state_label, pm_states[test_state]))
+ break;
+
+ if (test_state == PM_SUSPEND_MAX) {
+ printk(warn_bad_state, test_state_label);
+ return 0;
}
/* RTCs have initialized by now too ... can we use one? */
@@ -173,13 +179,12 @@ static int __init test_suspend(void)
rtc = rtc_class_open(dev_name(dev));
if (!rtc) {
printk(warn_no_rtc);
- goto done;
+ return 0;
}
/* go for it */
test_wakealarm(rtc, test_state);
rtc_class_close(rtc);
-done:
return 0;
}
late_initcall(test_suspend);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ufs: fix deadlocks after mutex merge
On Tue, Sep 02, 2014 at 12:08:35AM +0100, Al Viro wrote:
> Your commit message makes no sense - ufs_evict_inode() is *never* called
> with that lock held, for one thing. I agree that "ufs: sb mutex merge +
> mutex_destroy" was been badly broken and apparently never tested, though -
> the bugs are real.
>
> Please, write a saner commit message; what happens is that
> ufs_{new,free}_inode() take the damn lock themselves these days, so
> their caller shouldn't do that.
PS: after rereading your mail, I see what you meant to say, but it really
wasn't clear enough. The crucial part is that the lock is *always* taken
by free/new, not that some of the callers take it and some do not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 1
Changes since 20140829: The akpm-current gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 2553 2686 files changed, 98625 insertions(+), 79475 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git . 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 an allmodconfig for x86_64 and a multi_v7_defconfig for arm. Below is a summary of the state of the merge. I am currently merging 214 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of Stephen's 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. signature.asc Description: Digital signature
Re: [PATCH] ufs: fix deadlocks after mutex merge
On Tue, Sep 02, 2014 at 02:30:24AM +0400, Alexey Khoroshilov wrote:
> Commit 0244756edc4b ("ufs: sb mutex merge + mutex_destroy") introduces
> deadlocks in ufs_new_inode() and ufs_free_inode() that call lock_ufs()
> being already invoked with mutex held.
>
> ufs_free_inode() is always invoked with mutex locked, while
> ufs_new_inode() is called with mutex locked two times of four.
>
> The patch proposes to resolve the issue by agreement to call
> ufs_new_inode() and ufs_free_inode() with mutex unheld.
> @@ -902,9 +902,6 @@ void ufs_evict_inode(struct inode * inode)
> invalidate_inode_buffers(inode);
> clear_inode(inode);
>
> - if (want_delete) {
> - lock_ufs(inode->i_sb);
> - ufs_free_inode (inode);
> - unlock_ufs(inode->i_sb);
> - }
> + if (want_delete)
> + ufs_free_inode(inode);
Your commit message makes no sense - ufs_evict_inode() is *never* called
with that lock held, for one thing. I agree that "ufs: sb mutex merge +
mutex_destroy" was been badly broken and apparently never tested, though -
the bugs are real.
Please, write a saner commit message; what happens is that
ufs_{new,free}_inode() take the damn lock themselves these days, so
their caller shouldn't do that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with the tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
scripts/checkpatch.pl between commit 8678fa326053d41 ("checkpatch: relax check
for length of git commit IDs") from Linus' tree and what looks like the same
commit from the akpm-current tree.
I fixed it up by taking Linus' version and can carry as required.
Thanks,
Mark
pgpxYynondReK.pgp
Description: PGP signature
[PATCH] ethernet: nvidia: Remove extra parens
Remove unnecessary double parenthesis around if statement.
Signed-off-by: David Wood
---
drivers/net/ethernet/nvidia/forcedeth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c
b/drivers/net/ethernet/nvidia/forcedeth.c
index 925b296..f39cae6 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -1481,7 +1481,7 @@ static int phy_init(struct net_device *dev)
}
/* phy vendor specific configuration */
- if ((np->phy_oui == PHY_OUI_CICADA)) {
+ if (np->phy_oui == PHY_OUI_CICADA) {
if (init_cicada(dev, np, phyinterface)) {
netdev_info(dev, "%s: phy init failed\n",
pci_name(np->pci_dev));
--
2.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] KVM: minor cleanup and optimizations
On 28.08.14 15:13, Radim Krčmář wrote:
> The first patch answers a demand for inline arch functions.
> (There is a lot of constant functions that could be inlined as well.)
>
> Second patch digs a bit into the history of KVM and removes a useless
> argument that seemed suspicious when preparing the first patch.
>
>
> Radim Krčmář (2):
> KVM: static inline empty kvm_arch functions
> KVM: remove garbage arg to *hardware_{en,dis}able
Acked-by: Alexander Graf
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.17-rc3] Warning in ieee80211_can_queue_work
I am using the kernel 3.17-rc3 which I compiled today and I get the warning below right before suspending to RAM: [ 37.856537] [ cut here ] [ 37.856559] WARNING: CPU: 3 PID: 43 at /home/mafra/linux-2.6/net/mac80211/util.c:716 ieee80211_can_queue_work.isra.38+0x2d/0x40 [mac80211]() [ 37.856559] queueing ieee80211 work while going to suspend [ 37.856575] Modules linked in: ctr ccm nls_iso8859_1 nls_cp437 vfat fat arc4 b43 mac80211 snd_hda_codec_hdmi snd_hda_codec_cirrus snd_hda_codec_generic snd_hda_intel snd_hda_controller cfg80211 snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_pcm crc32c_intel ghash_clmulni_intel uvcvideo rfkill videobuf2_core bcm5974 ssb videobuf2_vmalloc videobuf2_memops snd_timer rtc_cmos [ 37.856577] CPU: 3 PID: 43 Comm: kworker/3:1 Not tainted 3.17.0-rc3 #44 [ 37.856578] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B01.1208311637 08/31/2012 [ 37.856583] Workqueue: events led_work_function [ 37.856586] 0009 88026409fd18 816f6176 88026409fd60 [ 37.856587] 88026409fd50 81067343 880263920660 8802639222f0 [ 37.856589] 88026f391300 88026409fdb0 [ 37.856589] Call Trace: [ 37.856594] [] dump_stack+0x4d/0x6f [ 37.856598] [] warn_slowpath_common+0x73/0x90 [ 37.856600] [] warn_slowpath_fmt+0x47/0x50 [ 37.856604] [] ? put_prev_entity+0x2c/0x3b0 [ 37.856606] [] ? pick_next_task_fair+0x1f7/0x8a0 [ 37.856615] [] ieee80211_can_queue_work.isra.38+0x2d/0x40 [mac80211] [ 37.856622] [] ieee80211_queue_work+0x20/0x40 [mac80211] [ 37.856630] [] b43_led_brightness_set+0x27/0x30 [b43] [ 37.856632] [] led_work_function+0x113/0x130 [ 37.856634] [] process_one_work+0x166/0x390 [ 37.856636] [] worker_thread+0x11b/0x490 [ 37.856638] [] ? rescuer_thread+0x290/0x290 [ 37.856641] [] kthread+0xcd/0xf0 [ 37.856643] [] ? kthread_create_on_node+0x170/0x170 [ 37.856645] [] ret_from_fork+0x7c/0xb0 [ 37.856647] [] ? kthread_create_on_node+0x170/0x170 [ 37.856649] ---[ end trace 01a2610015279813 ]--- The reason for such an early suspend (37 seconds after booting) is related to another issue which I hope to describe in another email but which is "fixed" by a suspend cycle. The wireless seems to be working fine right now though, using the 'b43' module. I'm not sure if the warning is new in 3.17-rcX since I haven't tested the previous releases for a while (sorry), but I can test patches. The kernel config and dmesg are here: http://damtp.cam.ac.uk/user/crm66/dmesg-3.17-rc3.txt http://damtp.cam.ac.uk/user/crm66/config-3.17-rc2+ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ufs: fix deadlocks after mutex merge
Commit 0244756edc4b ("ufs: sb mutex merge + mutex_destroy") introduces
deadlocks in ufs_new_inode() and ufs_free_inode() that call lock_ufs()
being already invoked with mutex held.
ufs_free_inode() is always invoked with mutex locked, while
ufs_new_inode() is called with mutex locked two times of four.
The patch proposes to resolve the issue by agreement to call
ufs_new_inode() and ufs_free_inode() with mutex unheld.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
fs/ufs/inode.c | 7 ++-
fs/ufs/namei.c | 14 ++
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/fs/ufs/inode.c b/fs/ufs/inode.c
index 7c580c97990e..be7d42c7d938 100644
--- a/fs/ufs/inode.c
+++ b/fs/ufs/inode.c
@@ -902,9 +902,6 @@ void ufs_evict_inode(struct inode * inode)
invalidate_inode_buffers(inode);
clear_inode(inode);
- if (want_delete) {
- lock_ufs(inode->i_sb);
- ufs_free_inode (inode);
- unlock_ufs(inode->i_sb);
- }
+ if (want_delete)
+ ufs_free_inode(inode);
}
diff --git a/fs/ufs/namei.c b/fs/ufs/namei.c
index 90d74b8f8eba..2df62a73f20c 100644
--- a/fs/ufs/namei.c
+++ b/fs/ufs/namei.c
@@ -126,12 +126,12 @@ static int ufs_symlink (struct inode * dir, struct dentry
* dentry,
if (l > sb->s_blocksize)
goto out_notlocked;
- lock_ufs(dir->i_sb);
inode = ufs_new_inode(dir, S_IFLNK | S_IRWXUGO);
err = PTR_ERR(inode);
if (IS_ERR(inode))
- goto out;
+ goto out_notlocked;
+ lock_ufs(dir->i_sb);
if (l > UFS_SB(sb)->s_uspi->s_maxsymlinklen) {
/* slow symlink */
inode->i_op = _symlink_inode_operations;
@@ -181,13 +181,9 @@ static int ufs_mkdir(struct inode * dir, struct dentry *
dentry, umode_t mode)
struct inode * inode;
int err;
- lock_ufs(dir->i_sb);
- inode_inc_link_count(dir);
-
inode = ufs_new_inode(dir, S_IFDIR|mode);
- err = PTR_ERR(inode);
if (IS_ERR(inode))
- goto out_dir;
+ return PTR_ERR(inode);
inode->i_op = _dir_inode_operations;
inode->i_fop = _dir_operations;
@@ -195,6 +191,9 @@ static int ufs_mkdir(struct inode * dir, struct dentry *
dentry, umode_t mode)
inode_inc_link_count(inode);
+ lock_ufs(dir->i_sb);
+ inode_inc_link_count(dir);
+
err = ufs_make_empty(inode, dir);
if (err)
goto out_fail;
@@ -212,7 +211,6 @@ out_fail:
inode_dec_link_count(inode);
inode_dec_link_count(inode);
iput (inode);
-out_dir:
inode_dec_link_count(dir);
unlock_ufs(dir->i_sb);
goto out;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: fix rtnl locking in setsockopt for anycast and multicast
Hi,
On Mo, 2014-09-01 at 23:05 +0200, Sabrina Dubroca wrote:
> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
> triggers the assertion in addrconf_join_solict()/addrconf_leave_solict()
>
> ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to
> take RTNL before calling ipv6_dev_ac_inc/dec. Same thing with
> ipv6_sock_mc_join(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
> calling ipv6_dev_mc_inc/dec.
>
> This patch moves ASSERT_RTNL() up a level in the call stack.
>
> Signed-off-by: Cong Wang
> Signed-off-by: Sabrina Dubroca
> Reported-by: Tommi Rantala
> ---
> I included Cong's Signed-off-by for the first part of the patch,
> I hope that's OK.
>
> This patch is based on -next, but since the assertion can also be
> triggered on a current kernel (tested on a 3.16), I think it should
> also go in stable.
Ack, thus you should base the patch on the net tree.
>
> include/linux/netdevice.h | 4 ++--
> net/core/dev.c| 11 ++-
> net/ipv6/addrconf.c | 15 +--
> net/ipv6/anycast.c| 30 +++---
> net/ipv6/mcast.c | 16
> 5 files changed, 48 insertions(+), 28 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 429801370d0c..1ae0e745b1b1 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2077,8 +2077,8 @@ void __dev_remove_pack(struct packet_type *pt);
> void dev_add_offload(struct packet_offload *po);
> void dev_remove_offload(struct packet_offload *po);
>
> -struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short
> flags,
> - unsigned short mask);
> +struct net_device *dev_get_by_flags(struct net *net, unsigned short flags,
> + unsigned short mask);
> struct net_device *dev_get_by_name(struct net *net, const char *name);
> struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
> struct net_device *__dev_get_by_name(struct net *net, const char *name);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 443b814db05b..8fede6ef4a39 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -897,23 +897,24 @@ struct net_device *dev_getfirstbyhwtype(struct net
> *net, unsigned short type)
> EXPORT_SYMBOL(dev_getfirstbyhwtype);
>
> /**
> - * dev_get_by_flags_rcu - find any device with given flags
> + * dev_get_by_flags - find any device with given flags
> * @net: the applicable net namespace
> * @if_flags: IFF_* values
> * @mask: bitmask of bits in if_flags to check
> *
> * Search for any interface with the given flags. Returns NULL if a device
> * is not found or a pointer to the device. Must be called inside
> - * rcu_read_lock(), and result refcount is unchanged.
> + * rtnl_lock(), and result refcount is unchanged.
> */
>
> -struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short
> if_flags,
> +struct net_device *dev_get_by_flags(struct net *net, unsigned short if_flags,
> unsigned short mask)
> {
> struct net_device *dev, *ret;
>
> + ASSERT_RTNL();
> ret = NULL;
> - for_each_netdev_rcu(net, dev) {
> + for_each_netdev(net, dev) {
> if (((dev->flags ^ if_flags) & mask) == 0) {
> ret = dev;
> break;
> @@ -921,7 +922,7 @@ struct net_device *dev_get_by_flags_rcu(struct net *net,
> unsigned short if_flags
> }
> return ret;
> }
> -EXPORT_SYMBOL(dev_get_by_flags_rcu);
> +EXPORT_SYMBOL(dev_get_by_flags);
I don't have a very strong opinion on that, but think we shouldn't touch
this function. In general it looks like a useful one and if you force
rtnl lock on it you cannot call it from bh anymore. I think we should
keep rcu locking here and in the anycast code. It shouldn't matter much.
> /**
> * dev_valid_name - check if name is okay for network device
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 267ce3caee24..7ada65937d23 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1690,14 +1690,12 @@ void addrconf_dad_failure(struct inet6_ifaddr *ifp)
> addrconf_mod_dad_work(ifp, 0);
> }
>
> -/* Join to solicited addr multicast group. */
> -
> +/* Join to solicited addr multicast group.
> + * caller must hold RTNL */
> void addrconf_join_solict(struct net_device *dev, const struct in6_addr
> *addr)
> {
> struct in6_addr maddr;
>
> - ASSERT_RTNL();
> -
> if (dev->flags&(IFF_LOOPBACK|IFF_NOARP))
> return;
>
> @@ -1705,12 +1703,11 @@ void addrconf_join_solict(struct net_device *dev,
> const struct in6_addr *addr)
> ipv6_dev_mc_inc(dev, );
> }
>
> +/* caller must hold RTNL */
> void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr
> *addr)
> {
> struct in6_addr maddr;
>
> - ASSERT_RTNL();
> -
>
Re: [RFC PATCH 0/2] kmod: Support lockup option to make module un-removable
On Tue, Aug 26, 2014 at 9:04 AM, Masami Hiramatsu wrote: > Hi, > > Here is a pair of patches which adds --lockup option to > modprobe and libkmod. > > As I sent a series of patches which removes stop_machine() > from module removal: https://lkml.org/lkml/2014/8/25/142 > it also adds lockup option which lock up the module in > the kernel and makes it un-removable. > > These patches enables us to use that option when loading > modules. Module lockup may be good for BIG SMP machines > since the kernel skips module refcounting if the module > is locked up :) > > Anyway, this is not needed if the lockup option is dropped > from the series. I send this for testing. Ok. I'm not sure it's clear... I'm waiting for feedback on the kernel patches in order to proceed with any review here. I'm not really convinced we want this option when loading a module. Rusty, what do you think? -- Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Drivers:firewire: fix style errors in core-card.c This is a patch in the core-card.c file which fixes up 2 warnings found by the checkpatch.pl tool Signed-off-by: Sander Nemvalts
Quite a crowded subject line!
On Mon, 2014-09-01 at 23:56 +0200, Stefan Richter wrote:
> On Sep 01 Sander Nemvalts wrote:
> > @@ -132,7 +133,7 @@ static void generate_config_rom(struct fw_card *card,
> > __be32 *config_rom)
> > j = 7 + descriptor_count;
> >
> > /* Generate root directory entries for descriptors. */
> > - list_for_each_entry (desc, _list, link) {
> > + list_for_each_entry(desc, _list, link) {
> > if (desc->immediate > 0)
> > config_rom[i++] = cpu_to_be32(desc->immediate);
> > config_rom[i] = cpu_to_be32(desc->key | (j - i));
>
> We are writing
> for (a; b; c);
> not
> for(a; b; c);
> and thus a space after list_for_each and friends makes sense.
$ git grep "list_for_each_entry (" | wc -l
52
$ git grep "list_for_each_entry(" | wc -l
5991
So "list_for_each_entry(" (without space) seems to be the preferred
style.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: patch "staging: remove nokia_hp4p driver
Hi Pavel, > What is going on here? I get flamed for not cleaning up the driver, > because I cleaned it up before merging to -staging. Ok, so I did more > cleanups, sent 3 cleanup patches, no reaction on those, and now I got > a note that you are going to remove the driver...? For the 3 "cleanup" patches, the first one was rejected and you said to not include it, so I couldn't apply the others. >>> >>> That was different series. I'm talking about: >>> >>> [PATCH 1/3] staging: nokia_h4: switch to right types and use bdaddr_t >>> [PATCH 2/3] staging: nokia_h4: avoid __uX types >>> [PATCH 3/3] staging: use inlines where it makes sense >>> >>> That is still valid and received no comments at all. > >> and these are all trivial cleanups and could have been done back in >> January when this driver was merged into staging. It is end of >> August now and nothing happened to address anything in the TODO >> file. > > [Could you please wrap at 80 characters?] > > Would be done in january if someone pointed the problems out. > > For the record, 3/3 addresses your comment > > "These are a lot of public functions. Are they all really needed or can > the code be done smart." > > in TODO file. so what about all the other really major details that needed fixing. I mean anybody who was compiling for OMAP platform could have fixed the tons and tons of inlines quickly. >> The warning from end of May that this driver will be removed seemed >> to not have triggered anybody to work on the core issues of the >> driver. > > Actually it did trigger me to work on the patch series above. It is > just that the series was ignored, and now I'm told that driver is > going to be removed because I did not do the work. The driver got removed, because nobody started the real work to make it an upstream driver. >> There are 3 major topics that needs addressing before this driver should >> come anywhere near upstream kernel again, staging or otherwise. >> >> a) Convert to using device tree for device detection >> >> b) Convert to using hdev->setup for firmware loading >> >> c) Convert to using hdev->set_bdaddr and HCI_QUIRK_INVALID_BDADDR > > I thought staging is for merging code to be cleaned up. Not "please > rewrite, and possibly break the driver before merging it into > staging". Merge it into staging, then clean it up there. The staging tree is for drivers to eventually go upstream. Staging is not a long term solution for a driver. It never was and never will be. So cleanup means whatever is required to get it upstream. And that means that you need to rewrite pieces. For example a WiFi driver that ships its own 802.11 stack will never get upstream unless you re-write it to use mac80211. > (Also hopefully get some testing from n900 community; code is more > visible in staging). The problem is that they are testing the wrong thing. And lets face it, we already knew this driver works since Nokia shipped it in products. > And BTW it is first time I hear about a). So the whole ARM community is moving over to DT and you are ignoring it. I complained about the platform data before. Someone told me that the N900 will be converted to DT. So I assume that this driver will also use DT then. If that was not clear, then now I made it clear. >> Please keep in mind that this was not an ugly Windows driver with a >> lot of Windows specific typedefs or bad coding style or OS >> abstractions. From that point of view it was always good since it >> was written for Linux in the first place. It was just a bit >> dated. Any fixes to bring that in sync with all other drivers could >> have been done easily after it was merged into the Bluetooth >> subsystem. > > So you are saying that most of the comments you had when I attempted > to merge the driver did not really need to be addressed? That's news > to me, normally maintainers want their comments addressed. All the coding style and cleanups like moving code around could have been done with a few days. So if the 3 major items would have been fixed, then getting the driver into shape is dead simple. > And yes, this driver bitroted a lot while being out of tree. It was > probably pretty good initially, mergeable with minimum effort. Now you > want it to bitrot a bit more. Back in the days it was hard to merge since most of the OMAP stuff it depends on was not upstream. That why it never made it there. In addition that you need to build for specific OMAP boards makes it really hard to just take the driver. If it would have compiled on x86, I bet it would already been upstream. >> The reason why it ended up in staging is that the 3 core problems needed >> fixing. And 8 month later they still have not been fixed. >> > > I attempted hdev->setup conversion, but could not figure it out till > now. Clearly it needs to be done. > > For doing that, it would be good to have userland to work with, and > yes it takes time. (Debugging on 4"
Re: [PATCH] staging: android: add a blank line after declarations
On Sun, Aug 31, 2014 at 09:43:15PM +0100, Grzegorz Swirski wrote:
> Signed-off-by: Grzegorz Swirski
> ---
> drivers/staging/android/sync.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index e7b2e02..0d37495 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -705,6 +705,7 @@ static long sync_fence_ioctl(struct file *file, unsigned
> int cmd,
>unsigned long arg)
> {
> struct sync_fence *fence = file->private_data;
> +
> switch (cmd) {
> case SYNC_IOC_WAIT:
> return sync_fence_ioctl_wait(fence, arg);
This patch is already in my tree, sorry, I can't accept it ;(
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] Regression in drm-intel caused by d91a2cb8e510
On Mon, Sep 01, 2014 at 04:19:23PM -0400, Alan Stern wrote: > Daniel: > > I'm encountering a problem with the drm-intel-nightly branch in your > drm-intel repository. The symptom is that when I boot my laptop, at > some point during the start-up procedure the screen goes totally blank, > as though the backlight were turned off, and it remains that way. I > can't tell if the backlight really is off -- it may be that there's > just nothing being displayed -- and playing with the screen-brightness > function keys doesn't help. > > Git bisect located the source of the problem as commit d91a2cb8e510 > (drm/i915: Add 180 degree primary plane rotation support). The problem > occurs when I boot a kernel built from that commit, and it doesn't > occur when I boot a kernel built from the preceding commit > (19ac737dc3c3). > > If necessary, I can get debugging info by logging in over a network > connection. Tell me what you need. It seems like Ville and Mika already caught a similar bug today, could you give Ville's patch a go (available on the intel-gfx): drm/i915: Don't call intel_plane_restore() when the prop value didn't change Thanks, -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Drivers:firewire: fix style errors in core-card.c This is a patch in the core-card.c file which fixes up 2 warnings found by the checkpatch.pl tool Signed-off-by: Sander Nemvalts
On Sep 01 Sander Nemvalts wrote:
> --- a/drivers/firewire/core-card.c
> +++ b/drivers/firewire/core-card.c
> @@ -89,7 +89,8 @@ static size_t config_rom_length = 1 + 4 + 1 + 1;
> #define BIB_ISC ((1) << 29)
> #define BIB_CMC ((1) << 30)
> #define BIB_IRMC ((1) << 31)
> -#define NODE_CAPABILITIES0x0c0083c0 /* per IEEE 1394 clause 8.3.2.6.5.2
> */
> +/* per IEEE 1394 clause 8.3.2.6.5.2 */
> +#define NODE_CAPABILITIES0x0c0083c0
This is no improvement.
> /*
> * IEEE-1394 specifies a default SPLIT_TIMEOUT value of 800 cycles (100 ms),
> @@ -132,7 +133,7 @@ static void generate_config_rom(struct fw_card *card,
> __be32 *config_rom)
> j = 7 + descriptor_count;
>
> /* Generate root directory entries for descriptors. */
> - list_for_each_entry (desc, _list, link) {
> + list_for_each_entry(desc, _list, link) {
> if (desc->immediate > 0)
> config_rom[i++] = cpu_to_be32(desc->immediate);
> config_rom[i] = cpu_to_be32(desc->key | (j - i));
We are writing
for (a; b; c);
not
for(a; b; c);
and thus a space after list_for_each and friends makes sense.
--
Stefan Richter
-=-- =--= =
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 29
On 09/01/2014 02:15 PM, Christoph Lameter wrote: On Mon, 1 Sep 2014, Guenter Roeck wrote: arch/ia64/sn/kernel/setup.c: In function 'sn_cpu_init': arch/ia64/sn/kernel/setup.c:632:13: error: lvalue required as left operand of assignment make[1]: *** [arch/ia64/sn/kernel/setup.o] Error 1 make: *** [arch/ia64/sn/kernel/setup.o] Error 2 Subject: ia64: sn_nodepda cannot be assigned to after this_cpu conversion. Use __this_cpu_write. There must be an explit statement to modify the percpu variable after the conversion of the sn_nodpda macro to use this_cpu_read. Signed-off-by: Christoph Lameter FWIW: Compile-tested-by: Guenter Roeck Too bad there is no ia64 support in qemu; this could use some "real" testing. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 4/5] clk: RK808: Add clkout driver for RK808
Quoting Chris Zhong (2014-09-01 02:46:40)
> Signed-off-by: Chris Zhong
>
>
> Reviewed-by: Doug Anderson
> Tested-by: Doug Anderson
Hello Chris,
Thanks for submitting this patch. Could you fill in a proper changelog?
Also you should reorder the tags like so:
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
Signed-off-by: Chris Zhong
> +static int rk808_clkout2_control(struct clk_hw *hw, bool enable)
> +{
> + struct rk808_clkout *rk808_clkout = container_of(hw,
> +struct rk808_clkout,
> +clkout2_hw);
> + struct rk808 *rk808 = rk808_clkout->rk808;
> +
> + return regmap_update_bits(rk808->regmap, RK808_CLK32OUT_REG,
> + CLK32KOUT2_EN, enable ? CLK32KOUT2_EN : 0);
> +}
Nitpick: can you rename "control" to "enable" or "ungate"? That makes it
more obvious what the function is doing without having to inspect the
code in the function body.
> +static int rk808_clkout_probe(struct platform_device *pdev)
> +{
> + struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
> + struct i2c_client *client = rk808->i2c;
> + struct device_node *node = client->dev.of_node;
> + struct clk_init_data init = {};
> + struct clk **clk_table;
> + struct rk808_clkout *rk808_clkout;
> +
> + rk808_clkout = devm_kzalloc(>dev,
> + sizeof(*rk808_clkout), GFP_KERNEL);
> + if (!rk808_clkout)
> + return -ENOMEM;
> +
> + rk808_clkout->rk808 = rk808;
> +
> + clk_table = devm_kzalloc(>dev,
> +2 * sizeof(struct clk *), GFP_KERNEL);
Better to use devm_kcalloc. Also good to define a constant like:
#define RK808_NR_OUTPUT 2
... and then use RK8808_NR_OUTPUT instead of hard-coding the value 2 in
the driver.
> + if (!clk_table)
> + return -ENOMEM;
> +
> + init.flags = CLK_IS_ROOT;
> + init.parent_names = NULL;
> + init.num_parents = 0;
> + init.name = "rk808-clkout1";
> + init.ops = _clkout1_ops;
> + rk808_clkout->clkout1_hw.init =
> +
> + /* optional override of the clockname */
> + of_property_read_string_index(node, "clock-output-names",
> + 0, );
> +
> + clk_table[0] = devm_clk_register(>dev,
> +_clkout->clkout1_hw);
> + if (IS_ERR(clk_table[0]))
> + return PTR_ERR(clk_table[0]);
> +
> + init.name = "rk808-clkout2";
> + init.ops = _clkout2_ops;
> + rk808_clkout->clkout2_hw.init =
> +
> + /* optional override of the clockname */
> + of_property_read_string_index(node, "clock-output-names",
> + 1, );
> +
> + clk_table[1] = devm_clk_register(>dev,
> +_clkout->clkout2_hw);
> + if (IS_ERR(clk_table[1]))
> + return PTR_ERR(clk_table[1]);
> +
> + rk808_clkout->clk_data.clks = clk_table;
> + rk808_clkout->clk_data.clk_num = 2;
Again, here you can use RK808_NR_OUTPUT.
Otherwise the driver looks pretty good to me.
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver
On Mon, 1 Sep 2014 23:29:46 +0200
Gaël PORTAY wrote:
> The at91sam9g20 SOC uses its own pllb implementation which is different
> from the one inherited from at91sam9260 SOC.
>
> Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
> ---
> arch/arm/boot/dts/at91sam9g20.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi
> b/arch/arm/boot/dts/at91sam9g20.dtsi
> index 31f7652..4e0abbd 100644
> --- a/arch/arm/boot/dts/at91sam9g20.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g20.dtsi
> @@ -40,6 +40,7 @@
> };
>
> pllb: pllbck {
> + compatible =
> "atmel,at91sam9g20-clk-pllb";
> atmel,clk-input-range = <200
> 3200>;
> atmel,pll-clk-output-ranges = <3000
> 1 0 0>;
> };
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/5] MFD: RK808: Add new mfd driver for RK808
Hi, On Mon, Sep 1, 2014 at 3:09 AM, Lee Jones wrote: > On Mon, 01 Sep 2014, Chris Zhong wrote: > >> The RK808 chip is a power management IC for multimedia and handheld >> devices. It contains the following components: >> >> - Regulators >> - RTC >> - Clkout >> >> The RK808 core driver is registered as a platform driver and provides >> communication through I2C with the host device for the different >> components. >> >> Signed-off-by: Chris Zhong >> Signed-off-by: Zhang Qing > > Couple of nits. Once fixed you can apply my: > > Acked-by: Lee Jones > > [...] > >> +/* >> + * MFD core driver for Rockchip RK808 >> + * >> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd > > Author? I asked Chris to remove the author in my response to an earlier version since it's at the bottom (MODULE_AUTHOR) and it seems extra duplication. You are the boss though, so if it should go both places then Chris should add this back. Sorry for the bad advice, Chris. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: replace int param with size_t for seq_open_private()
On Mon, Sep 01, 2014 at 03:38:51PM +0100, Rob Jones wrote: > >>kmalloc where it is expected to be a size_t. > > > >Which is a mistake too because allocations are never that large. > > Yet. *raised eyebrow* You do realize that kmalloc() gives physically contiguous allocation, right? And refuses to allocate more than KMALLOC_MAX_SIZE, while we are at it. With allocations anywhere near such range being very heavily discouraged. There might or might not be point in using size_t for kmalloc() argument, but "future-proofing" isn't it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How is pivot_root intended to be used?
Hello,
I am not confused about how I can currently use pivot_root for
containers on my kernel (version 3.13). Currently a sequence like:
if (-1 == syscall(__NR_pivot_root, ".", ".")) {
perror("pivot_root");
return EXIT_FAILURE;
}
if (-1 == umount2(".", MNT_DETACH)) {
perror("umount");
return EXIT_FAILURE;
}
/* pivot_root() may or may not affect its current working
* directory. It is therefore recommended to call chdir("/")
* immediately after pivot_root().
*
* - http://man7.org/linux/man-pages/man2/pivot_root.2.html
*/
if (-1 == chdir("/")) {
perror("chdir");
return EXIT_FAILURE;
}
works. However, I am completely and totally confused about how the
pivot_root system call is intended to be used here and have absolutely
no idea if this will work in the future. This concerns me because I
don't want my program to potentially develop silent security bugs on
future versions of the Linux kernel.
Some information about the context. I am sandboxing a program just
after it has done a fork, unshared the mount namespace, setup a
sandbox directory and changed into it. If you just want to look at the
code, the actual code is avaliable at
https://gitorious.org/linted/linted/source/b25685ba4762bfb794c8f36ae74276d32d2b0ca8:src/spawn/spawn.c.
Thank you,
Steven Stewart-Gallus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
