Re: [PATCH 3/6] autofs4: allow RCU-walk to walk through autofs4.
On Wed, 16 Jul 2014 12:44:17 +0800 Ian Kent wrote:
> On Thu, 2014-07-10 at 09:41 +1000, NeilBrown wrote:
> > Any attempt to look up a pathname that passes though an
> > autofs4 mount is currently forced out of RCU-walk into
> > REF-walk.
> >
> > This can significantly hurt performance of many-thread work
> > loads on many-core systems, especially if the automounted
> > filesystem supports RCU-walk but doesn't get to benefit from
> > it.
> >
> > So if autofs4_d_manage is called with rcu_walk set, only
> > fail with -ECHILD if it is necessary to wait longer than
> > a spinlock, and avoid even the spinlock in one trivial case.
>
> I've looked more closely at this one now and mostly it looks good to me.
>
> But I'm probably a bit slow, there's just one place where I can't work
> out the reasoning
>
> >
> > Signed-off-by: NeilBrown
> > ---
> > fs/autofs4/autofs_i.h |2 +-
> > fs/autofs4/dev-ioctl.c |2 +-
> > fs/autofs4/expire.c|4 +++-
> > fs/autofs4/root.c | 44 +---
> > 4 files changed, 34 insertions(+), 18 deletions(-)
> >
> > diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
> > index 22a280151e45..99dbb05d6148 100644
> > --- a/fs/autofs4/autofs_i.h
> > +++ b/fs/autofs4/autofs_i.h
> > @@ -148,7 +148,7 @@ void autofs4_free_ino(struct autofs_info *);
> >
> > /* Expiration */
> > int is_autofs4_dentry(struct dentry *);
> > -int autofs4_expire_wait(struct dentry *dentry);
> > +int autofs4_expire_wait(struct dentry *dentry, int rcu_walk);
> > int autofs4_expire_run(struct super_block *, struct vfsmount *,
> > struct autofs_sb_info *,
> > struct autofs_packet_expire __user *);
> > diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
> > index 5b570b6efa28..aaf96cb25452 100644
> > --- a/fs/autofs4/dev-ioctl.c
> > +++ b/fs/autofs4/dev-ioctl.c
> > @@ -450,7 +450,7 @@ static int autofs_dev_ioctl_requester(struct file *fp,
> > ino = autofs4_dentry_ino(path.dentry);
> > if (ino) {
> > err = 0;
> > - autofs4_expire_wait(path.dentry);
> > + autofs4_expire_wait(path.dentry, 0);
> > spin_lock(>fs_lock);
> > param->requester.uid = from_kuid_munged(current_user_ns(),
> > ino->uid);
> > param->requester.gid = from_kgid_munged(current_user_ns(),
> > ino->gid);
> > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> > index a7be57e39be7..7e2f22ce6954 100644
> > --- a/fs/autofs4/expire.c
> > +++ b/fs/autofs4/expire.c
> > @@ -467,7 +467,7 @@ found:
> > return expired;
> > }
> >
> > -int autofs4_expire_wait(struct dentry *dentry)
> > +int autofs4_expire_wait(struct dentry *dentry, int rcu_walk)
> > {
> > struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > @@ -477,6 +477,8 @@ int autofs4_expire_wait(struct dentry *dentry)
> > spin_lock(>fs_lock);
> > if (ino->flags & AUTOFS_INF_EXPIRING) {
> > spin_unlock(>fs_lock);
> > + if (rcu_walk)
> > + return -ECHILD;
> >
> > DPRINTK("waiting for expire %p name=%.*s",
> > dentry, dentry->d_name.len, dentry->d_name.name);
> > diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> > index cc87c1abac97..1ad119407e2f 100644
> > --- a/fs/autofs4/root.c
> > +++ b/fs/autofs4/root.c
> > @@ -208,7 +208,8 @@ next:
> > return NULL;
> > }
> >
> > -static struct dentry *autofs4_lookup_expiring(struct dentry *dentry)
> > +static struct dentry *autofs4_lookup_expiring(struct dentry *dentry,
> > + bool rcu_walk)
> > {
> > struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > struct dentry *parent = dentry->d_parent;
> > @@ -225,6 +226,11 @@ static struct dentry *autofs4_lookup_expiring(struct
> > dentry *dentry)
> > struct dentry *expiring;
> > struct qstr *qstr;
> >
> > + if (rcu_walk) {
> > + spin_unlock(>lookup_lock);
> > + return ERR_PTR(-ECHILD);
> > + }
> > +
> > ino = list_entry(p, struct autofs_info, expiring);
> > expiring = ino->dentry;
> >
> > @@ -260,13 +266,15 @@ next:
> > return NULL;
> > }
> >
> > -static int autofs4_mount_wait(struct dentry *dentry)
> > +static int autofs4_mount_wait(struct dentry *dentry, bool rcu_walk)
> > {
> > struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > int status = 0;
> >
> > if (ino->flags & AUTOFS_INF_PENDING) {
> > + if (rcu_walk)
> > + return -ECHILD;
> > DPRINTK("waiting for mount name=%.*s",
> > dentry->d_name.len, dentry->d_name.name);
> > status = autofs4_wait(sbi, dentry, NFY_MOUNT);
> > @@ -276,20 +284,22 @@ static int
Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 15 July 2014 12:28, Srivatsa S. Bhat wrote: > Wait, allowing an offline CPU to be the policy->cpu (i.e., the CPU which is > considered as the master of the policy/group) is just absurd. Yeah, that was as Absurd as I am :) > The goal of this patchset should be to just de-couple the sysfs > files/ownership > from the policy->cpu to an extent where it doesn't matter who owns those > files, and probably make it easier to do CPU hotplug without having to > destroy and recreate the files on every hotplug operation. I went to that Absurd idea because we thought we can skip playing with the sysfs nodes on suspend/hotplug. And if policy->cpu keeps changing with hotplug, we *may* have to keep sysfs stuff moving as well. One way to avoid that is by using something like: policy->sysfs_cpu, but wasn't sure if that's the right path to follow. Lets see what Saravana's new patchset has for us :) -- 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 46/94] ARM: dts: am335x-evm: Enable the McASP FIFO for audio
On 07/15/2014 08:01 PM, Sam Asadi wrote:
> From: Peter Ujfalusi
>
> The use of FIFO in McASP can reduce the risk of audio under/overrun and
> lowers the load on the memories since the DMA will operate in bursts.
>
> Signed-off-by: Peter Ujfalusi
> Signed-off-by: Tony Lindgren
> Signed-off-by: sam-the-6
> ---
> arch/arm/boot/dts/am335x-evm.dts |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
What is the reason this patch is in this */94 series? What is this series of
patches anyways?
FWIW the two McASP FIFO enable patch is already in mainline and they should
not be backported to older kernels w/o the changes in the mcasp driver in 3.16.
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index ecb2677..e2156a5 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -529,8 +529,8 @@
> serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
> 0 0 1 2
> >;
> - tx-num-evt = <1>;
> - rx-num-evt = <1>;
> + tx-num-evt = <32>;
> + rx-num-evt = <32>;
> };
>
> {
>
--
Péter
--
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: [Bug report] Hit false positives bug with script/checkpatch.pl
Parantheses/do {...} while(0) would not work for direct value substituons like
this obviously but fixing this false positive seems hard. An exception case
that is something like "macros with complex values separated by commas but no
statements terminated by semicolons" is my best but seems-very-vague guess.
-Anish
From: Joe Perches [j...@perches.com]
Sent: Tuesday, July 15, 2014 9:20 PM
To: Ethan Zhao
Cc: Anish Bhatt; a...@canonical.com; linux-kernel@vger.kernel.org;
ethan.ker...@gmail.com; joe@oracle.com
Subject: Re: [Bug report] Hit false positives bug with script/checkpatch.pl
On Wed, 2014-07-16 at 10:50 +0800, Ethan Zhao wrote:
> Hi,
> I hit a false positives bug when run script/checkpatch.pl to my patch,
> It reported errors to following macro definition, but in fact the macro is
> correct, I couldn't change that macro according to the error message output
> by script/checkpatch.pl. because of this bug, my patch was rejected by some
> guy's patchwork.
You could tell the guy checkpatch isn't always right.
You could also change the macro to something like:
#define NETXEN_NIC_STAT(name, m)\
{ \
.name = name, \
.type = m, \
.sizeof_stat = FIELD_SIZEOF(struct netxen_adapter, m), \
.stat_offset = offsetof(struct netxen_adapter, m) \
}
and change the uses like:
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
NETXEN_NIC_STAT("xmit called", stats.xmitcalled),
NETXEN_NIC_STAT("xmit_finished", stats.xmitfinished),
etc...
--
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] netlink: remove bool varible
From: Varka Bhadram
This patch removes the bool variable 'pass'.
If the swith case exist return true or return false.
Signed-off-by: Varka Bhadram
---
net/netlink/af_netlink.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index e8c9f97..5dd8193 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -170,7 +170,6 @@ EXPORT_SYMBOL_GPL(netlink_remove_tap);
static bool netlink_filter_tap(const struct sk_buff *skb)
{
struct sock *sk = skb->sk;
- bool pass = false;
/* We take the more conservative approach and
* whitelist socket protocols that may pass.
@@ -184,11 +183,10 @@ static bool netlink_filter_tap(const struct sk_buff *skb)
case NETLINK_FIB_LOOKUP:
case NETLINK_NETFILTER:
case NETLINK_GENERIC:
- pass = true;
- break;
+ return true;
}
- return pass;
+ return false;
}
static int __netlink_deliver_tap_skb(struct sk_buff *skb,
--
1.7.9.5
--
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: [RFC 0/2] vfs / btrfs: add support for ustat()
Isn't this the problem again the btrfs uses different assignments for st_dev than s_dev? I don't even want to think about a mess like this before that is fixed. -- 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] netlink: fix in netlink_filter_tap
From: varkabhad...@gmail.com Date: Wed, 16 Jul 2014 10:47:24 +0530 > From: Varka Bhadram > > Remove the bool variable 'pass'. Return the true/false directly. > > Signed-off-by: Varka Bhadram This doesn't "fix" anything, it's a cleanup. Please resubmit this with a more correct commit header line and commit message. -- 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] netlink: fix in netlink_filter_tap
From: Varka Bhadram
Remove the bool variable 'pass'. Return the true/false directly.
Signed-off-by: Varka Bhadram
---
net/netlink/af_netlink.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index e8c9f97..5dd8193 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -170,7 +170,6 @@ EXPORT_SYMBOL_GPL(netlink_remove_tap);
static bool netlink_filter_tap(const struct sk_buff *skb)
{
struct sock *sk = skb->sk;
- bool pass = false;
/* We take the more conservative approach and
* whitelist socket protocols that may pass.
@@ -184,11 +183,10 @@ static bool netlink_filter_tap(const struct sk_buff *skb)
case NETLINK_FIB_LOOKUP:
case NETLINK_NETFILTER:
case NETLINK_GENERIC:
- pass = true;
- break;
+ return true;
}
- return pass;
+ return false;
}
static int __netlink_deliver_tap_skb(struct sk_buff *skb,
--
1.7.9.5
--
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/2] phy: qcom: Add driver for QCOM IPQ806x SATA PHY
Hi,
On Tuesday 15 July 2014 10:09 PM, Kumar Gala wrote:
> Add a PHY driver for uses with AHCI based SATA controller driver on the
> IPQ806x family of SoCs.
>
> Signed-off-by: Kumar Gala
Please fix this checkpatch warning..
WARNING: memory barrier without comment
#235: FILE: drivers/phy/phy-qcom-ipq806x-sata.c:101:
+ mb();
total: 0 errors, 1 warnings, 223 lines checked
-Kishon
> ---
> v7:
> * Fix compilation issues due to change in devm_phy_create API
>
> v6:
> * Add platform_set_drvdata
>
> v5:
> * Fix copy/paste error when killing qcom_ipq806x_sata_delay_us
>
> v4:
> * removed qcom_ipq806x_sata_delay_us as it was only used one
>
> v3:
> * Added Kconfig HAS_IOMEM dep
> * re-ordered probe function so phy_provider_register is last
>
> v2:
> * dropped unused dev pointer in struct qcom_ipq806x_sata_phy
> * remove unnecessary reg initializaiton
> * Removed unneeded error message
> * Added remove function to disable the clock
>
> drivers/phy/Kconfig | 7 ++
> drivers/phy/Makefile| 1 +
> drivers/phy/phy-qcom-ipq806x-sata.c | 208
>
> 3 files changed, 216 insertions(+)
> create mode 100644 drivers/phy/phy-qcom-ipq806x-sata.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 1704fd4..3e251aa 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -191,4 +191,11 @@ config PHY_QCOM_APQ8064_SATA
> depends on OF
> select GENERIC_PHY
>
> +config PHY_QCOM_IPQ806X_SATA
> + tristate "Qualcomm IPQ806x SATA SerDes/PHY driver"
> + depends on ARCH_QCOM
> + depends on HAS_IOMEM
> + depends on OF
> + select GENERIC_PHY
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 3c2ad59..54ab978 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -23,3 +23,4 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) +=
> phy-exynos5250-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
> +obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
> diff --git a/drivers/phy/phy-qcom-ipq806x-sata.c
> b/drivers/phy/phy-qcom-ipq806x-sata.c
> new file mode 100644
> index 000..2199627
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ipq806x-sata.c
> @@ -0,0 +1,208 @@
> +/*
> + * Copyright (c) 2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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
> +#include
> +#include
> +#include
> +#include
> +
> +struct qcom_ipq806x_sata_phy {
> + void __iomem *mmio;
> + struct clk *cfg_clk;
> + struct device *dev;
> +};
> +
> +#define __set(v, a, b) (((v) << (b)) & GENMASK(a, b))
> +
> +#define SATA_PHY_P0_PARAM0 0x200
> +#define SATA_PHY_P0_PARAM0_P0_TX_PREEMPH_GEN3(x) __set(x, 17, 12)
> +#define SATA_PHY_P0_PARAM0_P0_TX_PREEMPH_GEN3_MASK GENMASK(17, 12)
> +#define SATA_PHY_P0_PARAM0_P0_TX_PREEMPH_GEN2(x) __set(x, 11, 6)
> +#define SATA_PHY_P0_PARAM0_P0_TX_PREEMPH_GEN2_MASK GENMASK(11, 6)
> +#define SATA_PHY_P0_PARAM0_P0_TX_PREEMPH_GEN1(x) __set(x, 5, 0)
> +#define SATA_PHY_P0_PARAM0_P0_TX_PREEMPH_GEN1_MASK GENMASK(5, 0)
> +
> +#define SATA_PHY_P0_PARAM1 0x204
> +#define SATA_PHY_P0_PARAM1_RESERVED_BITS31_21(x) __set(x, 31, 21)
> +#define SATA_PHY_P0_PARAM1_P0_TX_AMPLITUDE_GEN3(x) __set(x, 20, 14)
> +#define SATA_PHY_P0_PARAM1_P0_TX_AMPLITUDE_GEN3_MASK GENMASK(20, 14)
> +#define SATA_PHY_P0_PARAM1_P0_TX_AMPLITUDE_GEN2(x) __set(x, 13, 7)
> +#define SATA_PHY_P0_PARAM1_P0_TX_AMPLITUDE_GEN2_MASK GENMASK(13, 7)
> +#define SATA_PHY_P0_PARAM1_P0_TX_AMPLITUDE_GEN1(x) __set(x, 6, 0)
> +#define SATA_PHY_P0_PARAM1_P0_TX_AMPLITUDE_GEN1_MASK GENMASK(6, 0)
> +
> +#define SATA_PHY_P0_PARAM2 0x208
> +#define SATA_PHY_P0_PARAM2_RX_EQ(x) __set(x, 20, 18)
> +#define SATA_PHY_P0_PARAM2_RX_EQ_MASKGENMASK(20, 18)
> +
> +#define SATA_PHY_P0_PARAM3 0x20C
> +#define SATA_PHY_SSC_EN 0x8
> +#define SATA_PHY_P0_PARAM4 0x210
> +#define SATA_PHY_REF_SSP_EN 0x2
> +#define SATA_PHY_RESET 0x1
> +
> +static int qcom_ipq806x_sata_phy_init(struct phy *generic_phy)
> +{
> + struct qcom_ipq806x_sata_phy *phy = phy_get_drvdata(generic_phy);
> + u32 reg;
> +
> + /* Setting SSC_EN to 1 */
> +
[PATCH kvm-unit-tests] Add a test case for MSR_KVM_GET_RNG_SEED
Signed-off-by: Andy Lutomirski
---
config/config-x86-common.mak | 5 -
x86/get_rng_seed.c | 50
x86/unittests.cfg| 3 +++
3 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644 x86/get_rng_seed.c
diff --git a/config/config-x86-common.mak b/config/config-x86-common.mak
index 0b0da85..201a029 100644
--- a/config/config-x86-common.mak
+++ b/config/config-x86-common.mak
@@ -35,7 +35,8 @@ tests-common = $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \
$(TEST_DIR)/kvmclock_test.flat $(TEST_DIR)/eventinj.flat \
$(TEST_DIR)/s3.flat $(TEST_DIR)/pmu.flat \
$(TEST_DIR)/tsc_adjust.flat $(TEST_DIR)/asyncpf.flat \
- $(TEST_DIR)/init.flat $(TEST_DIR)/smap.flat
+ $(TEST_DIR)/init.flat $(TEST_DIR)/smap.flat \
+ $(TEST_DIR)/get_rng_seed.flat
ifdef API
tests-common += api/api-sample
@@ -105,6 +106,8 @@ $(TEST_DIR)/vmx.elf: $(cstart.o) $(TEST_DIR)/vmx.o
$(TEST_DIR)/vmx_tests.o
$(TEST_DIR)/debug.elf: $(cstart.o) $(TEST_DIR)/debug.o
+$(TEST_DIR)/get_rng_seed.elf: $(cstart.o) $(TEST_DIR)/get_rng_seed.o
+
arch_clean:
$(RM) $(TEST_DIR)/*.o $(TEST_DIR)/*.flat $(TEST_DIR)/*.elf \
$(TEST_DIR)/.*.d lib/x86/.*.d
diff --git a/x86/get_rng_seed.c b/x86/get_rng_seed.c
new file mode 100644
index 000..b2e1b01
--- /dev/null
+++ b/x86/get_rng_seed.c
@@ -0,0 +1,50 @@
+/*
+ * Simple test for MSR_KVM_GET_RNG_SEED.
+ */
+#include "x86/msr.h"
+#include "x86/processor.h"
+#include "x86/apic-defs.h"
+#include "x86/apic.h"
+#include "x86/desc.h"
+#include "x86/isr.h"
+#include "x86/vm.h"
+
+#include "libcflat.h"
+#include
+
+#define MSR_KVM_GET_RNG_SEED 0x4b564d05
+
+volatile int ngpfs;
+bool fail;
+
+static void gpf_isr(struct ex_regs *r)
+{
+ ngpfs++;
+ r->rip += 2;
+}
+
+int main(int ac, char **av)
+{
+ int loop = 3;
+ u64 val, prev = 0;
+
+ setup_vm();
+ setup_idt();
+ while(loop--) {
+ val = rdmsr(MSR_KVM_GET_RNG_SEED);
+ printf("rng seed: %llx\n", (unsigned long)val);
+ if (val == prev)
+ fail = true;
+ prev = val;
+ }
+
+ handle_exception(13, gpf_isr);
+ wrmsr(MSR_KVM_GET_RNG_SEED, 0);
+ if (ngpfs != 1) {
+ printf("error: wrmsr(MSR_KVM_GET_RNG_SEED) should not work\n");
+ fail = true;
+ }
+
+ printf("%s\n", fail ? "FAIL" : "PASS");
+ return fail;
+}
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index d78fe0e..98e5c7b 100644
--- a/x86/unittests.cfg
+++ b/x86/unittests.cfg
@@ -158,3 +158,6 @@ arch = x86_64
[debug]
file = debug.flat
arch = x86_64
+
+[get_rng_seed]
+file = get_rnd_seed.flat
--
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: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On Wed, Jul 16, 2014 at 12:39 AM, Joe Perches wrote: > On Wed, 2014-07-16 at 00:28 -0400, Nick Krause wrote: >> I am cleaning up the kernel as it needs a lot of cleanup. > > Needs are curious things. > > Consistency is a nicety not really a need. > > Bugs need fixing. Defects need eliminating. > Enhancements are appreciated. Inconsistent > code style is a minor annoyance. > > I suggest you focus on the bugs, defects or > enhancements in performance or testing. > > Are you really cross-compiling the patches you > submit here or do you have an alpha on your desk? > > I am cross compiling then. I don't have the hardware :(. Nick -- 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 V5 6/6] staging: vt6556: Replace printk by dev_warn
On Tue, Jul 15, 2014 at 10:46:49PM +0200, Peter Senna Tschudin wrote:
> This patch fixes a checkpatch warning by replacing printk
> by dev_warn. Tested by compilation only.
>
> Signed-off-by: Peter Senna Tschudin
> ---
> Changes from V4:
> - use dev_warn instead of pr_warn
>
> drivers/staging/vt6656/main_usb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/main_usb.c
> b/drivers/staging/vt6656/main_usb.c
> index 7567646..6708e98 100644
> --- a/drivers/staging/vt6656/main_usb.c
> +++ b/drivers/staging/vt6656/main_usb.c
> @@ -527,7 +527,8 @@ static void usb_device_reset(struct vnt_private *pDevice)
>
> status = usb_reset_device(pDevice->usb);
> if (status)
> -printk("usb_device_reset fail status=%d\n",status);
> + dev_warn(>usb->dev,
> + "usb_device_reset fail status=%d\n", status);
> }
>
> static void device_free_int_bufs(struct vnt_private *priv)
This doesn't apply to my latest tree, can you please refresh it and
resend?
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/1] scripts/get_maintainer: increase threshold for --follow to reduce time
On Wed, 2014-07-16 at 00:35 -0400, Pranith Kumar wrote: > The problem is with the default which is at 50% now. That means that a > commit needs to have changed a file by more than 50% -and- moved it in > the same commit. This is highly discouraged and unlikely to happen in > our case. > > Even if we have this a cmd-line configuration, setting the default to > 90% really makes sense, no? Dunno. If it makes sense, maybe it makes global sense and should be the git default. If not, maybe other users have different needs and need some other cmdline option. -- 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 PATCH 0/8] arm: dts: dra7: Add PCIe data and PCIe PHY data
On Tuesday 15 July 2014 12:48 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I [140714 03:44]: >> [1] is split into separate series in order for individual subsystem >> Maintainers to pick up the patches. This series handles the PCIe >> dt data for DRA7. >> >> This series has better commit logs than the previous one modified as >> suggested by Tero. >> >> [1] -> https://lkml.org/lkml/2014/5/29/258 >> >> Keerthy (2): >> ARM: dts: dra7xx-clocks: Add divider table to optfclk_pciephy_div >> clock >> ARM: dts: dra7xx-clocks: Change the parent of apll_pcie_in_clk_mux to >> dpll_pcie_ref_m2ldo_ck >> >> Kishon Vijay Abraham I (6): >> ARM: dts: dra7xx-clocks: Add missing 32KHz clocks used for PHY >> ARM: dts: dra7xx-clocks: rename pcie clocks to accommodate second PHY >> instance >> ARM: dts: dra7xx-clocks: Add missing clocks for second PCIe PHY >> instance >> ARM: dts: dra7: Add dt data for PCIe PHY control module >> ARM: dts: dra7: Add dt data for PCIe PHY >> ARM: dts: dra7: Add dt data for PCIe controller >> >> arch/arm/boot/dts/dra7.dtsi | 127 >> ++ >> arch/arm/boot/dts/dra7xx-clocks.dtsi | 39 ++- >> 2 files changed, 163 insertions(+), 3 deletions(-) > > Applying this series into omap-for-v3.17/dt thanks. Thanks :-) -Kishon > > Tony > -- 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] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
On Wednesday 16 July 2014 01:43 AM, Paul Walmsley wrote: > On Mon, 14 Jul 2014, Kishon Vijay Abraham I wrote: > >> On Wednesday 09 July 2014 04:32 PM, Rajendra Nayak wrote: >>> On Wednesday 09 July 2014 02:32 PM, Kishon Vijay Abraham I wrote: Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC. Cc: Tony Lindgren Cc: Russell King Cc: Paul Walmsley Signed-off-by: Kishon Vijay Abraham I Tested-by: Kishon Vijay Abraham I --- Changes from v1: * changed the clock domain to "pcie_clkdm" * Added PCIe as a slave port for l3_main. >>> >>> Looks good to me, >>> Reviewed-by: Rajendra Nayak >> >> Paul, >> >> Can you pick this one? > > Yep, queued for 3.17. Thanks :-) -Kishon > > - Paul > -- 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/6] autofs4: allow RCU-walk to walk through autofs4.
On Thu, 2014-07-10 at 09:41 +1000, NeilBrown wrote:
> Any attempt to look up a pathname that passes though an
> autofs4 mount is currently forced out of RCU-walk into
> REF-walk.
>
> This can significantly hurt performance of many-thread work
> loads on many-core systems, especially if the automounted
> filesystem supports RCU-walk but doesn't get to benefit from
> it.
>
> So if autofs4_d_manage is called with rcu_walk set, only
> fail with -ECHILD if it is necessary to wait longer than
> a spinlock, and avoid even the spinlock in one trivial case.
I've looked more closely at this one now and mostly it looks good to me.
But I'm probably a bit slow, there's just one place where I can't work
out the reasoning
>
> Signed-off-by: NeilBrown
> ---
> fs/autofs4/autofs_i.h |2 +-
> fs/autofs4/dev-ioctl.c |2 +-
> fs/autofs4/expire.c|4 +++-
> fs/autofs4/root.c | 44 +---
> 4 files changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
> index 22a280151e45..99dbb05d6148 100644
> --- a/fs/autofs4/autofs_i.h
> +++ b/fs/autofs4/autofs_i.h
> @@ -148,7 +148,7 @@ void autofs4_free_ino(struct autofs_info *);
>
> /* Expiration */
> int is_autofs4_dentry(struct dentry *);
> -int autofs4_expire_wait(struct dentry *dentry);
> +int autofs4_expire_wait(struct dentry *dentry, int rcu_walk);
> int autofs4_expire_run(struct super_block *, struct vfsmount *,
> struct autofs_sb_info *,
> struct autofs_packet_expire __user *);
> diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
> index 5b570b6efa28..aaf96cb25452 100644
> --- a/fs/autofs4/dev-ioctl.c
> +++ b/fs/autofs4/dev-ioctl.c
> @@ -450,7 +450,7 @@ static int autofs_dev_ioctl_requester(struct file *fp,
> ino = autofs4_dentry_ino(path.dentry);
> if (ino) {
> err = 0;
> - autofs4_expire_wait(path.dentry);
> + autofs4_expire_wait(path.dentry, 0);
> spin_lock(>fs_lock);
> param->requester.uid = from_kuid_munged(current_user_ns(),
> ino->uid);
> param->requester.gid = from_kgid_munged(current_user_ns(),
> ino->gid);
> diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> index a7be57e39be7..7e2f22ce6954 100644
> --- a/fs/autofs4/expire.c
> +++ b/fs/autofs4/expire.c
> @@ -467,7 +467,7 @@ found:
> return expired;
> }
>
> -int autofs4_expire_wait(struct dentry *dentry)
> +int autofs4_expire_wait(struct dentry *dentry, int rcu_walk)
> {
> struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> struct autofs_info *ino = autofs4_dentry_ino(dentry);
> @@ -477,6 +477,8 @@ int autofs4_expire_wait(struct dentry *dentry)
> spin_lock(>fs_lock);
> if (ino->flags & AUTOFS_INF_EXPIRING) {
> spin_unlock(>fs_lock);
> + if (rcu_walk)
> + return -ECHILD;
>
> DPRINTK("waiting for expire %p name=%.*s",
>dentry, dentry->d_name.len, dentry->d_name.name);
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index cc87c1abac97..1ad119407e2f 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -208,7 +208,8 @@ next:
> return NULL;
> }
>
> -static struct dentry *autofs4_lookup_expiring(struct dentry *dentry)
> +static struct dentry *autofs4_lookup_expiring(struct dentry *dentry,
> + bool rcu_walk)
> {
> struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> struct dentry *parent = dentry->d_parent;
> @@ -225,6 +226,11 @@ static struct dentry *autofs4_lookup_expiring(struct
> dentry *dentry)
> struct dentry *expiring;
> struct qstr *qstr;
>
> + if (rcu_walk) {
> + spin_unlock(>lookup_lock);
> + return ERR_PTR(-ECHILD);
> + }
> +
> ino = list_entry(p, struct autofs_info, expiring);
> expiring = ino->dentry;
>
> @@ -260,13 +266,15 @@ next:
> return NULL;
> }
>
> -static int autofs4_mount_wait(struct dentry *dentry)
> +static int autofs4_mount_wait(struct dentry *dentry, bool rcu_walk)
> {
> struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> struct autofs_info *ino = autofs4_dentry_ino(dentry);
> int status = 0;
>
> if (ino->flags & AUTOFS_INF_PENDING) {
> + if (rcu_walk)
> + return -ECHILD;
> DPRINTK("waiting for mount name=%.*s",
> dentry->d_name.len, dentry->d_name.name);
> status = autofs4_wait(sbi, dentry, NFY_MOUNT);
> @@ -276,20 +284,22 @@ static int autofs4_mount_wait(struct dentry *dentry)
> return status;
> }
>
> -static int do_expire_wait(struct dentry *dentry)
> +static int do_expire_wait(struct dentry *dentry, bool rcu_walk)
> {
> struct dentry *expiring;
>
> -
Re: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On Wed, 2014-07-16 at 00:28 -0400, Nick Krause wrote: > I am cleaning up the kernel as it needs a lot of cleanup. Needs are curious things. Consistency is a nicety not really a need. Bugs need fixing. Defects need eliminating. Enhancements are appreciated. Inconsistent code style is a minor annoyance. I suggest you focus on the bugs, defects or enhancements in performance or testing. Are you really cross-compiling the patches you submit here or do you have an alpha on your desk? -- 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/1] scripts/get_maintainer: increase threshold for --follow to reduce time
On Wed, Jul 16, 2014 at 12:08 AM, Joe Perches wrote: > On Tue, 2014-07-15 at 22:23 -0400, Pranith Kumar wrote: >> ping? >> >> On Sat, Jul 12, 2014 at 3:25 PM, Pranith Kumar wrote: >> > get_maintainer tries to follow files with a matching threshold of default >> > 50%. >> > This is not really necessary as we do not change a file and move it in the >> > same >> > commit usually. Increasing the threshold to 90% should be sufficient. > While I understand the goal, I wonder if this should > be in a .gitconfig, not in get_maintainers at all. > > (git doesn't seem to have a config entry for score though) > > If not, the % should probably be cmd-line configurable. > > The problem is with the default which is at 50% now. That means that a commit needs to have changed a file by more than 50% -and- moved it in the same commit. This is highly discouraged and unlikely to happen in our case. Even if we have this a cmd-line configuration, setting the default to 90% really makes sense, no? -- Pranith -- 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/
ARC backport for stable 3.{10,12,14,15}
Hi, Can you please add the mainline commit a4b6cb735b25aa84a462a1985e3e43bebaf5beb4 "ARC: Implement ptrace(PTRACE_GET_THREAD_AREA)" to stable kernels This is causing buildroot gdb failures with pre 3.16 kernels. Thx, -Vineet -- 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: build failure after merge of the v4l-dvb tree
On 07/15/2014 08:04 PM, Stephen Rothwell wrote: Hi Guenter, On Tue, 15 Jul 2014 12:08:07 -0700 Guenter Roeck wrote: Do you mean b6220ad66 (sched: Fix compiler warnings) ? I thought that was accepted a week or so ago. That is in the tip tree and includes the fixups to powerpc and arm. I don't merge the tip tree till well after the v4l-dvb tree. The merge in the v4l-dvb tree included only the change to include/linus/sched.h and neither parent fo that merge was based on the tip tree ... Stephen, Do you know if/when this patch will be merged upstream? It doesn't seem to be at 2.6.16-rc5. Otherwise, I'll likely cherry-pick it on s/2.16/3.16/ my trees, as the lack of this fixup is making hard for me to check if a media tree patch isn't introducing new warnings. Only queued for 3.17 as far as I can see, and not scheduled for 3.16. Its in the sched/urgent branch of the tip tree, so hopefully it will go to Linus shortly. Excellent, glad to hear that I was wrong. Looking forward to it. Thanks, 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 3.15 00/84] 3.15.6-stable review
On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.6 release. There are 84 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 17 23:17:00 UTC 2014. Anything received after that time might be too late. Build results: total: 139 pass: 139 fail: 0 Qemu tests all passed. Another set of perfect results. Details are available at http://server.roeck-us.net:8010/builders. 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: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On Wed, Jul 16, 2014 at 12:23 AM, Joe Perches wrote: > On Wed, 2014-07-16 at 00:16 -0400, Nick Krause wrote: >> On Tue, Jul 15, 2014 at 11:38 PM, Joe Perches wrote: >> > On Tue, 2014-07-15 at 22:50 -0400, Nick Krause wrote: >> >> I may have not found it myself but if it doesn't exist can we write a >> >> feature for checkpatch to be able to recursively >> >> search a directory structure with a -d aRrgument in order to make it >> >> easier to search larger directories for files that still >> >> need cleanup for files having kernel coding style issues. >> >linux-kernel@vger.kernel.org >> > xargs already works fine. >> > >> > git ls-files /*.[ch] | xargs ./scripts/checkpatch.pl -f >> > >> > I suggest you only use anything like this >> > on staging directories. >> > >> > >> >> Thanks Joe, >> That was what I needed to known :). I was hitting some errors in arch, >> so I will run that to see if there are any others. >> Cheers Nick > > I again suggest you _ONLY_ use checkpatch on staging. > > Doing checkpatch only cleanups will not make you a > better developer nor give you a good understanding > of the code operation. > I am cleaning up the kernel as it needs a lot of cleanup. In addition I am doing build related issues. Some developers removed me from FIX MES after several stupid patches I sent. If there is a area that needs help , please let me know :). -- 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.14 00/66] 3.14.13-stable review
On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.13 release. There are 66 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 17 23:16:50 UTC 2014. Anything received after that time might be too late. Build results: total: 140 pass: 140 fail: 0 Qemu tests all passed. Results are obviously perfect. Details are available at http://server.roeck-us.net:8010/builders. 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 3.10 00/44] 3.10.49-stable review
On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.49 release. There are 44 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 17 23:16:37 UTC 2014. Anything received after that time might be too late. Build results: total: 138 pass: 138 fail: 0 Qemu tests all passed. Results are boring perfect. Details are available at http://server.roeck-us.net:8010/builders. 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 3.4 00/22] 3.4.99-stable review
On 07/15/2014 04:17 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.99 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 17 23:16:04 UTC 2014. Anything received after that time might be too late. Build results: total: 117 pass: 111 fail: 6 Failed builds: alpha:allmodconfig arm:spear6xx_defconfig score:defconfig sparc64:allmodconfig unicore32:defconfig xtensa:allmodconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. A note on the above link and its accessibility: I have seen relentless attacks from various sources recently. All but one of those attacks originated from IP addresses allocated to Chinese service providers (the one exception was an attack from an Amazon virtual host). Attacks have become more sophisticated over time, to a point where I no longer trust my firewalls. For this reason, I now permanently block the entire IP address range of a service provider if an attack originates from an address range allocated to that provider. I understand that this may bve considered a bit drastic, but this is my server, the information on it is provided free of charge, for the benefit of everyone, and there should be no reason to attack it. Blame the attackers, not me. If you have reason to believe that your address has been blocked, I will be happy to selectively unblock it if you can show me legitimate interest in accessing the information. 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: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On Wed, 2014-07-16 at 00:16 -0400, Nick Krause wrote: > On Tue, Jul 15, 2014 at 11:38 PM, Joe Perches wrote: > > On Tue, 2014-07-15 at 22:50 -0400, Nick Krause wrote: > >> I may have not found it myself but if it doesn't exist can we write a > >> feature for checkpatch to be able to recursively > >> search a directory structure with a -d aRrgument in order to make it > >> easier to search larger directories for files that still > >> need cleanup for files having kernel coding style issues. > >linux-kernel@vger.kernel.org > > xargs already works fine. > > > > git ls-files /*.[ch] | xargs ./scripts/checkpatch.pl -f > > > > I suggest you only use anything like this > > on staging directories. > > > > > > Thanks Joe, > That was what I needed to known :). I was hitting some errors in arch, > so I will run that to see if there are any others. > Cheers Nick I again suggest you _ONLY_ use checkpatch on staging. Doing checkpatch only cleanups will not make you a better developer nor give you a good understanding of the code operation. -- 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: [Bug report] Hit false positives bug with script/checkpatch.pl
On Wed, 2014-07-16 at 10:50 +0800, Ethan Zhao wrote:
> Hi,
> I hit a false positives bug when run script/checkpatch.pl to my patch,
> It reported errors to following macro definition, but in fact the macro is
> correct, I couldn't change that macro according to the error message output
> by script/checkpatch.pl. because of this bug, my patch was rejected by some
> guy's patchwork.
You could tell the guy checkpatch isn't always right.
You could also change the macro to something like:
#define NETXEN_NIC_STAT(name, m)\
{ \
.name = name, \
.type = m, \
.sizeof_stat = FIELD_SIZEOF(struct netxen_adapter, m), \
.stat_offset = offsetof(struct netxen_adapter, m) \
}
and change the uses like:
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
NETXEN_NIC_STAT("xmit called", stats.xmitcalled),
NETXEN_NIC_STAT("xmit_finished", stats.xmitfinished),
etc...
--
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: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On Tue, Jul 15, 2014 at 11:38 PM, Joe Perches wrote: > On Tue, 2014-07-15 at 22:50 -0400, Nick Krause wrote: >> I may have not found it myself but if it doesn't exist can we write a >> feature for checkpatch to be able to recursively >> search a directory structure with a -d argument in order to make it >> easier to search larger directories for files that still >> need cleanup for files having kernel coding style issues. >linux-kernel@vger.kernel.org > xargs already works fine. > > git ls-files /*.[ch] | xargs ./scripts/checkpatch.pl -f > > I suggest you only use anything like this > on staging directories. > > Thanks Joe, That was what I needed to known :). I was hitting some errors in arch, so I will run that to see if there are any others. Cheers Nick -- 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/4] alpha: checkpatch errors in mkbb for if statements
This patch fixes all errors related to no space between if and parthesises
to remove this errors when running checkpatch against this file.
---
arch/alpha/boot/tools/mkbb.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/alpha/boot/tools/mkbb.c b/arch/alpha/boot/tools/mkbb.c
index 6f1b957..214b6c7 100644
--- a/arch/alpha/boot/tools/mkbb.c
+++ b/arch/alpha/boot/tools/mkbb.c
@@ -91,21 +91,21 @@ int main(int argc, char ** argv)
int nread;
/* Make sure of the arg count */
- if(argc != 3) {
+ if (argc != 3) {
fprintf(stderr, "Usage: %s device lxboot\n", argv[0]);
exit(0);
}
/* First, open the device and make sure it's accessible */
dev = open(argv[1], O_RDWR);
- if(dev < 0) {
+ if (dev < 0) {
perror(argv[1]);
exit(0);
}
/* Now open the lxboot and make sure it's reasonable */
fd = open(argv[2], O_RDONLY);
- if(fd < 0) {
+ if (fd < 0) {
perror(argv[2]);
close(dev);
exit(0);
@@ -113,7 +113,7 @@ int main(int argc, char ** argv)
/* Read in the lxboot */
nread = read(fd, _image, sizeof(bootblock));
- if(nread != sizeof(bootblock)) {
+ if (nread != sizeof(bootblock)) {
perror("lxboot read");
fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
exit(0);
@@ -121,7 +121,7 @@ int main(int argc, char ** argv)
/* Read in the bootblock from disk. */
nread = read(dev, _from_disk, sizeof(bootblock));
- if(nread != sizeof(bootblock)) {
+ if (nread != sizeof(bootblock)) {
perror("bootblock read");
fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
exit(0);
@@ -132,14 +132,14 @@ int main(int argc, char ** argv)
/* Calculate the bootblock checksum */
bootloader_image.bootblock_checksum = 0;
- for(i = 0; i < 63; i++) {
+ for (i = 0; i < 63; i++) {
bootloader_image.bootblock_checksum +=
bootloader_image.bootblock_quadwords[i];
}
/* Write the whole thing out! */
lseek(dev, 0L, SEEK_SET);
- if(write(dev, _image, sizeof(bootblock)) !=
sizeof(bootblock)) {
+ if (write(dev, _image, sizeof(bootblock)) !=
sizeof(bootblock)) {
perror("bootblock write");
exit(0);
}
--
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/
[PATCH 3/4] alpha: Indent if Statements properly
This patch removes the errors this file gets with checkpatch due
to errors relating to if statements and their enclosing statements
not being indented properly.
---
arch/alpha/boot/tools/mkbb.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/alpha/boot/tools/mkbb.c b/arch/alpha/boot/tools/mkbb.c
index 214b6c7..69f347e 100644
--- a/arch/alpha/boot/tools/mkbb.c
+++ b/arch/alpha/boot/tools/mkbb.c
@@ -92,39 +92,39 @@ int main(int argc, char ** argv)
/* Make sure of the arg count */
if (argc != 3) {
- fprintf(stderr, "Usage: %s device lxboot\n", argv[0]);
- exit(0);
+ fprintf(stderr, "Usage: %s device lxboot\n", argv[0]);
+ exit(0);
}
/* First, open the device and make sure it's accessible */
dev = open(argv[1], O_RDWR);
- if (dev < 0) {
- perror(argv[1]);
- exit(0);
+ if (dev < 0) {
+ perror(argv[1]);
+ exit(0);
}
/* Now open the lxboot and make sure it's reasonable */
fd = open(argv[2], O_RDONLY);
if (fd < 0) {
- perror(argv[2]);
- close(dev);
- exit(0);
+ perror(argv[2]);
+ close(dev);
+ exit(0);
}
/* Read in the lxboot */
nread = read(fd, _image, sizeof(bootblock));
if (nread != sizeof(bootblock)) {
- perror("lxboot read");
- fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
- exit(0);
+ perror("lxboot read");
+ fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock),
nread);
+ exit(0);
}
/* Read in the bootblock from disk. */
nread = read(dev, _from_disk, sizeof(bootblock));
if (nread != sizeof(bootblock)) {
- perror("bootblock read");
- fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
- exit(0);
+ perror("bootblock read");
+ fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock),
nread);
+ exit(0);
}
/* Swap the bootblock's disklabel into the bootloader */
@@ -133,15 +133,15 @@ int main(int argc, char ** argv)
/* Calculate the bootblock checksum */
bootloader_image.bootblock_checksum = 0;
for (i = 0; i < 63; i++) {
- bootloader_image.bootblock_checksum +=
+ bootloader_image.bootblock_checksum +=
bootloader_image.bootblock_quadwords[i];
}
/* Write the whole thing out! */
lseek(dev, 0L, SEEK_SET);
if (write(dev, _image, sizeof(bootblock)) !=
sizeof(bootblock)) {
- perror("bootblock write");
- exit(0);
+ perror("bootblock write");
+ exit(0);
}
close(fd);
--
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/
[PATCH 1/4] alpha: Converse all space errors into tabs in mkbb.c
This patch fixes all the checkpatch errors I get when running it
on mkbb.c for spaces at beginning of lines. I converted then all
to tabs to fix these checkpatch warnings.
---
arch/alpha/boot/tools/mkbb.c | 124 +--
1 file changed, 61 insertions(+), 63 deletions(-)
diff --git a/arch/alpha/boot/tools/mkbb.c b/arch/alpha/boot/tools/mkbb.c
index 1185778..6f1b957 100644
--- a/arch/alpha/boot/tools/mkbb.c
+++ b/arch/alpha/boot/tools/mkbb.c
@@ -34,49 +34,49 @@
#endif
struct disklabel {
-u32d_magic;/* must be
DISKLABELMAGIC */
-u16d_type, d_subtype;
-u8 d_typename[16];
-u8 d_packname[16];
-u32d_secsize;
-u32d_nsectors;
-u32d_ntracks;
-u32d_ncylinders;
-u32d_secpercyl;
-u32d_secprtunit;
-u16d_sparespertrack;
-u16d_sparespercyl;
-u32d_acylinders;
-u16d_rpm, d_interleave, d_trackskew, d_cylskew;
-u32d_headswitch, d_trkseek, d_flags;
-u32d_drivedata[5];
-u32d_spare[5];
-u32d_magic2; /* must be
DISKLABELMAGIC */
-u16d_checksum;
-u16d_npartitions;
-u32d_bbsize, d_sbsize;
-struct d_partition {
+ u32 d_magic;/* must be DISKLABELMAGIC */
+ u16 d_type, d_subtype;
+ u8 d_typename[16];
+ u8 d_packname[16];
+ u32 d_secsize;
+ u32 d_nsectors;
+ u32 d_ntracks;
+ u32 d_ncylinders;
+ u32 d_secpercyl;
+ u32 d_secprtunit;
+ u16 d_sparespertrack;
+ u16 d_sparespercyl;
+ u32 d_acylinders;
+ u16 d_rpm, d_interleave, d_trackskew, d_cylskew;
+ u32 d_headswitch, d_trkseek, d_flags;
+ u32 d_drivedata[5];
+ u32 d_spare[5];
+ u32 d_magic2; /* must be
DISKLABELMAGIC */
+ u16 d_checksum;
+ u16 d_npartitions;
+ u32 d_bbsize, d_sbsize;
+ struct d_partition {
u32 p_size;
u32 p_offset;
u32 p_fsize;
u8 p_fstype;
u8 p_frag;
u16 p_cpg;
-} d_partitions[MAXPARTITIONS];
+ } d_partitions[MAXPARTITIONS];
};
typedef union __bootblock {
-struct {
-char __pad1[64];
-struct disklabel __label;
-} __u1;
-struct {
+ struct {
+ char__pad1[64];
+ struct disklabel__label;
+ } __u1;
+ struct {
unsigned long __pad2[63];
unsigned long __checksum;
-} __u2;
-char bootblock_bytes[512];
-unsigned long bootblock_quadwords[64];
+ } __u2;
+ charbootblock_bytes[512];
+ unsigned long bootblock_quadwords[64];
} bootblock;
#definebootblock_label __u1.__label
@@ -84,69 +84,67 @@ typedef union __bootblock {
int main(int argc, char ** argv)
{
-bootblock bootblock_from_disk;
-bootblock bootloader_image;
-intdev, fd;
-inti;
-intnread;
+ bootblock bootblock_from_disk;
+ bootblock bootloader_image;
+ int dev, fd;
+ int i;
+ int nread;
/* Make sure of the arg count */
-if(argc != 3) {
+ if(argc != 3) {
fprintf(stderr, "Usage: %s device lxboot\n", argv[0]);
exit(0);
-}
+ }
/* First, open the device and make sure it's accessible */
-dev = open(argv[1], O_RDWR);
-if(dev < 0) {
+ dev = open(argv[1], O_RDWR);
+ if(dev < 0) {
perror(argv[1]);
exit(0);
-}
+ }
/* Now open the lxboot and make sure it's reasonable */
-fd = open(argv[2], O_RDONLY);
-if(fd < 0) {
+ fd = open(argv[2], O_RDONLY);
+ if(fd < 0) {
perror(argv[2]);
close(dev);
exit(0);
-}
+ }
/* Read in the lxboot */
-nread = read(fd, _image, sizeof(bootblock));
-if(nread != sizeof(bootblock)) {
+ nread = read(fd, _image, sizeof(bootblock));
+ if(nread != sizeof(bootblock)) {
perror("lxboot read");
fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
exit(0);
-}
+ }
/* Read in the bootblock from disk. */
-nread = read(dev, _from_disk, sizeof(bootblock));
-if(nread != sizeof(bootblock)) {
+ nread = read(dev, _from_disk, sizeof(bootblock));
+ if(nread != sizeof(bootblock)) {
perror("bootblock read");
fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
exit(0);
-}
+ }
/* Swap the
[PATCH 4/4] alpha: Remove checkpatch error in mkk.b
This removes a error I get when I run checkpatch on this file, relating
to the asterisk for declaritations needing to be next to the name of the
variable/structure and not the type of variable/structure.
---
arch/alpha/boot/tools/mkbb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/alpha/boot/tools/mkbb.c b/arch/alpha/boot/tools/mkbb.c
index 69f347e..dac34c2 100644
--- a/arch/alpha/boot/tools/mkbb.c
+++ b/arch/alpha/boot/tools/mkbb.c
@@ -82,7 +82,7 @@ typedef union __bootblock {
#definebootblock_label __u1.__label
#define bootblock_checksum __u2.__checksum
-int main(int argc, char ** argv)
+int main(int argc, char **argv)
{
bootblock bootblock_from_disk;
bootblock bootloader_image;
--
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 1/1] scripts/get_maintainer: increase threshold for --follow to reduce time
On Tue, 2014-07-15 at 22:23 -0400, Pranith Kumar wrote:
> ping?
>
> On Sat, Jul 12, 2014 at 3:25 PM, Pranith Kumar wrote:
> > get_maintainer tries to follow files with a matching threshold of default
> > 50%.
> > This is not really necessary as we do not change a file and move it in the
> > same
> > commit usually. Increasing the threshold to 90% should be sufficient.
[]
> > diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> > index d701627..bc4a69e 100755
> > --- a/scripts/get_maintainer.pl
> > +++ b/scripts/get_maintainer.pl
> > @@ -98,7 +98,7 @@ my %VCS_cmds_git = (
> > "execute_cmd" => \_execute_cmd,
> > "available" => '(which("git") ne "") && (-e ".git")',
> > "find_signers_cmd" =>
> > - "git log --no-color --follow --since=\$email_git_since " .
> > + "git log --no-color --follow -M90 --since=\$email_git_since " .
> > '--numstat --no-merges ' .
> > '--format="GitCommit: %H%n' .
> > 'GitAuthor: %an <%ae>%n' .
While I understand the goal, I wonder if this should
be in a .gitconfig, not in get_maintainers at all.
(git doesn't seem to have a config entry for score though)
If not, the % should probably be cmd-line configurable.
--
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: Additional performance data on Pavel's smb3 multi credit patch series
Continuing testing of Pavel's newest SMB3 multicredit patch series, which significantly improves large file read/write speeds to Samba and Windows from Linux. For this workload LInux to Linux - SMB3 seems faster than alternatives for read (copying from the server) but about the same as NFS for write (copy to server). Some additional data: client Ubuntu with 3.16-rc4 and Pavel's patch series, server Fedora 20 (3.14.9 kernel, and Samba server version 4.1.9) dd if=/mnt/testfile of=/dev/null bs=50M count=30 testfile is 1.5GB existing file, unmount/mount inbetween each large file copy to avoid any caching effect on client (although server will have cached it) SMB3 averaged 199MB/sec reads (copy from server) CIFS averaged 170MB/sec reads (copy from server) NFSv3 averaged 116MB/sec (copy from server) NFSv4 and v4.1 averaged 110MB/sec (copy from server) Write speeds (doing dd if=/dev/zero of=/mnt/testfile bs=60M count=25) were more widely varied but averaged similar speeds for copy to server for both NFSv3/v4/v4.1 and SMB3 (about 175MB/s) On Sun, Jul 13, 2014 at 2:23 PM, Steve French wrote: > Performance of Pavel's multicredit i/o SMB3 patches continues to look > good. Additional informal performance results below comparing cifs > mounts with smb3 mounts (vers=3.0) with and without Pavel's patch set. > I plan to do additional testing with large rsize/wsize (default with > Pavel's code is 1MB). > > 3.16-rc4 (Ubuntu) on client. Server is Windows 8.1. Both VMs on same > host (host disk is fairly fast SSD). > > Copy to server performance increased about 20% percent > dd if=/dev/zero of=/mnt/targetfile bs=80M count=25 > got similar results with or without conv=fdatasync > > 1st run copying to empty directory, 2nd run copying over targetfile, > (pattern repeated multiple times) averaging results > > New code (with Pavel's patches) > - > CIFS 167MB/s > SMB3 200MB/s > > Existing code (without his patches) > > SMB3 166MB/s > CIFS 164.5MB/s > > For large file reading SMB3 performance with Pavel's patches increased > 76% over existing SMB3 code > dd of=/dev/null if=/mnt/targetfile bs=80M count=25 > (mounting and unmounting between attempts to avoid caching effects on > the client) > > New code (with Pavel's patches) > - > CIFS 114MB/s > SMB3 216MB/s > > Existing code (without his patches) > > SMB3 123MB/s > CIFS 110MB/s > > -- > Thanks, > > Steve -- Thanks, Steve -- 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/3] timekeeping: Improved NOHZ frequency steering (v2)
On 07/08/2014 04:08 AM, Miroslav Lichvar wrote: > On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote: >> Another area we have to be careful with is there are still >> architectures (powerpc and ia64) which haven't switched from the old >> vsyscall rounding logic (CONFIG_GENERIC_TIME_VSYSCALL_OLD). In these >> cases we add up to 1ns of error each tick/update as we round up the >> sub-nanoseconds to ensure we don't see inconsistencies. If the >> adjustment logic can't handle this, I don't want to regress those >> arches. > I spent some time trying to figure out a workaround for the nanosecond > rounding, but I didn't find anything that wouldn't complicate the mult > adjustment logic and bring back the problems which the direct division > approach is supposed to solve. > > It seems it may be a while before the old vsyscalls are fixed. How > about including only the first two patches from this set for now? Hey! Sorry for the slow response here, I was on the road the last two weeks. So thanks for the ping here. If you're happy with the first two as an initial step, I'd be willing to try to push those in. The only trouble is there's a whole lot of timekeeping churn headed for 3.17 that Thomas has cooked up. While there isn't likely to be direct conflicts in the changes, I get nervous about mixing too many changes in subtle code at once. But maybe I'm being overly cautious? Thomas: Would you be ok if I push you some patches to improve ntp/ptp freq steering w/ NOHZ for this merge window as well? So far the patches have only shown nice improvements and no regressions, but its clearly subtle code, and there's a lot going on in this merge window. thanks -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: testing result of loop-aio patchset on ext3
On 2014/7/14 17:51, Lukáš Czerner wrote:
> On Mon, 14 Jul 2014, Rui Xiang wrote:
>
>> Date: Mon, 14 Jul 2014 17:34:38 +0800
>> From: Rui Xiang
>> To: Dave Kleikamp , linux-e...@vger.kernel.org
>> Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
>> Li Zefan
>> Subject: testing result of loop-aio patchset on ext3
>>
>> Hi Dave,
>>
>> We export a container image file as a block device via loop device, but we
>> found it's very easy that the container rootfs gets corrupted due to power
>> loss.
>>
>> Your early version of loop-aio patchset said the patchset can make loop
>> mounted filesystems recoverable(lkml.org/lkml/2012/3/30/317), but we found
>> it doesn't help.
>>
>> Both the guest fs and host fs are ext3.
>>
>> The loop-aio patchset is from:
>> git://github.com/kleikamp/linux-shaggy.git aio_loop
>>
>> Steps:
>> 1. dd a 10G image, mkfs.ext3,
>> # dd if=/dev/zero of=./raw_image bs=1M count=1
>> # echo y | mkfs.ext3 raw_image
>>
>> 2. losetup a loop device, mount at ./test_dir
>> # losetup /dev/loop1 raw_image
>> # mount /dev/loop1 ./test_dir
>>
>> 3. copy fs_mark into test_dir and run
>> # ./fs_mark -d ./tmp/ -s 10240 -n 80
>>
>> 4. during runing fs_mark, make systerm reboot indirectly.
>> # echo b > /proc/sysrq-trigger
>>
>> After systerm booted up, sometimes fsck reported raw_image fs has been
>> damaged.
>>
>> # fsck.ext3 -n raw_image
>> e2fsck 1.41.9 (22-Aug-2009)
>> Warning: skipping journal recovery because doing a read-only filesystem
>> check.
>> raw_image contains a file system with errors, check forced.
>> Pass 1: Checking inodes, blocks, and sizes
>> Pass 2: Checking directory structure
>> Pass 3: Checking directory connectivity
>> Pass 4: Checking reference counts
>> Pass 5: Checking group summary information
>> Free blocks count wrong (2481348, counted=2480577).
>> Fix? no
>> Free inodes count wrong (640837, counted=640835).
>> Fix? no
>> raw_image: ** WARNING: Filesystem still has errors **
>> raw_image: 11/640848 files (0.0% non-contiguous), 78652/256 blocks
>
> It's not damaged, this is expected result if you're using old
> e2fsprogs which still treats this as an error.
>
> It's not an error because we only update superblock summary at
> unmount time so with unclean shutdown it's likely that it does not
> match the reality, but e2fsck can and will easily fix that for you.
>
> Please try e2fsprogs v1.42.3 or newer.
>
Hi Lukas,
I updated e2fsprogs to v1.42.3, and user the newer fsck.ext3 to check raw_image.
Exactly, the result seemed normal.
Then, I continue my previous test. And after testing 35 times, "fsck -n"
reported image fs
had been damaged, too.
# fsck.ext3 -n image1
e2fsck 1.42.3.wc1 (28-May-2012)
Warning: skipping journal recovery because doing a read-only filesystem check.
image1 has been mounted 36 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 16407, i_size is 597447, should be 602112. Fix? no
Inode 16407, i_blocks is 1176, should be 1184. Fix? no
Inode 409941, i_blocks is 200208, should be 112. Fix? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -1506836 -1506843 -(1506859--1506860)
-(1660941--1661964) -(1661966--1671167) -(1671688--1686473)
Fix? no
Free blocks count wrong for group #2 (31558, counted=31556).
Fix? no
Free blocks count wrong for group #43 (15871, counted=15867).
Fix? no
Free blocks count wrong (2204041, counted=2204035).
Fix? no
image1: ** WARNING: Filesystem still has errors **
image1: 13008/655360 files (0.3% non-contiguous), 417399/2621440 blocks
I backup the image to image_bk, and then mount the image to a dir, and cat all
files in the image.
Steps:
# dd if=image1 of=image_bk
# mount image1 err_dir
# find -name '*' -exec cat > /dev/null {} \;
There are no issues during catting, and no err in dmesg too.
*But when I umount the image1 from err_dir, The fsck result didn't show any fs
corruption info.
I mount image_bk to err_dir and umount it with no operation directly. The
result is same to iamge1.
*So, is fs in the image as a block device via loop device damaged really, or
does it have some others issues?
Could you give me some opinions?
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/
linux-next: manual merge of the infiniband tree with the net-next tree
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/hw/cxgb4/device.c between commit 7730b4c7e32c
("cxgb4/iw_cxgb4: work request logging feature") from the net-next tree
and commit 6b54d54dea82 ("RDMA/cxgb4: Initialize the device status
page") from the infiniband tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/infiniband/hw/cxgb4/device.c
index df1f1b52c7ec,7db82b24302b..
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@@ -843,16 -696,7 +843,17 @@@ static int c4iw_rdev_open(struct c4iw_r
pr_err(MOD "error allocating status page\n");
goto err4;
}
+ if (c4iw_wr_log) {
+ rdev->wr_log = kzalloc((1 << c4iw_wr_log_size_order) *
+ sizeof(*rdev->wr_log), GFP_KERNEL);
+ if (rdev->wr_log) {
+ rdev->wr_log_size = 1 << c4iw_wr_log_size_order;
+ atomic_set(>wr_log_idx, 0);
+ } else {
+ pr_err(MOD "error allocating wr_log. Logging
disabled\n");
+ }
+ }
+ rdev->status_page->db_off = 0;
return 0;
err4:
c4iw_rqtpool_destroy(rdev);
signature.asc
Description: PGP signature
Re: [patch 51/55] clocksource: Make delta calculation a function
On Fri, Jul 11, 2014 at 6:45 AM, Thomas Gleixner wrote:
> @@ -335,16 +335,15 @@ static void timekeeping_update(struct ti
> */
> static void timekeeping_forward_now(struct timekeeper *tk)
> {
> - cycle_t cycle_now, cycle_delta;
> + cycle_t cycle_now, delta;
> struct clocksource *clock;
> s64 nsec;
>
> clock = tk->clock;
> cycle_now = clock->read(clock);
> - cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
> - tk->cycle_last = clock->cycle_last = cycle_now;
> + delta = clocksource_delta(cycle_now, clock->cycle_last, clock->mask);
Errr.. Was dropping the update to tk->cycle_last and clock->cycle_last
intended? That seems broken.
thanks
-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: [PATCH 6/6] autofs4: don't take spinlock when not needed in autofs4_lookup_expiring
On Thu, 2014-07-10 at 09:41 +1000, NeilBrown wrote:
> If the expiring_list is empty, we can avoid a costly spinlock
> in the rcu-walk path through authfs4_d_manage.
>
> Signed-off-by: NeilBrown
I know it should be straight forward to say this is OK but I always
think twice and again about areas that are subject to race pressure,
such as the expire to mount pressure of this code.
After thinking about it for a while now I don't have any reason to think
this would be a problem. Perhaps later pressure testing will reveal
something I missed.
It occurs to me that autofs4_lookup_active() might benefit from a
similar addition. Multiple calls to ->lookup() made while the dentry is
still unhashed should have enforced ordering due to the directory
i_mutex so there shouldn't be a problem adding this. But perhaps you
haven't seen delays in that function.
Acked-by: Ian Kent
> ---
> fs/autofs4/root.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index 1ad119407e2f..774c2dab331b 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -219,6 +219,8 @@ static struct dentry *autofs4_lookup_expiring(struct
> dentry *dentry,
> const unsigned char *str = name->name;
> struct list_head *p, *head;
>
> + if (list_empty(>expiring_list))
> + return NULL;
> spin_lock(>lookup_lock);
> head = >expiring_list;
> list_for_each(p, head) {
>
>
--
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/1] doc: Add remote CPU access details to this_cpu_ops.txt
Add more details from a recent kernel newbies mailing list discussion here: http://www.spinics.net/lists/newbies/msg52747.html Signed-off-by: Pranith Kumar CC: Christoph Lameter --- Documentation/this_cpu_ops.txt | 107 + 1 file changed, 87 insertions(+), 20 deletions(-) diff --git a/Documentation/this_cpu_ops.txt b/Documentation/this_cpu_ops.txt index 1a4ce7e..2381602 100644 --- a/Documentation/this_cpu_ops.txt +++ b/Documentation/this_cpu_ops.txt @@ -13,22 +13,53 @@ operating on the per cpu variable. This means there are no atomicity issues between the calculation of the offset and the operation on the data. Therefore it is not -necessary to disable preempt or interrupts to ensure that the +necessary to disable preemption or interrupts to ensure that the processor is not changed between the calculation of the address and the operation on the data. Read-modify-write operations are of particular interest. Frequently processors have special lower latency instructions that can operate -without the typical synchronization overhead but still provide some -sort of relaxed atomicity guarantee. The x86 for example can execute -RMV (Read Modify Write) instructions like inc/dec/cmpxchg without the +without the typical synchronization overhead, but still provide some +sort of relaxed atomicity guarantees. The x86, for example, can execute +RMW (Read Modify Write) instructions like inc/dec/cmpxchg without the lock prefix and the associated latency penalty. Access to the variable without the lock prefix is not synchronized but synchronization is not necessary since we are dealing with per cpu data specific to the currently executing processor. Only the current processor should be accessing that variable and therefore there are no -concurrency issues with other processors in the system. +concurrency issues with other processors in the system. Please see the +section "Remote access to per-CPU data" if you need remote access. + +The main use of the this_cpu operations has been to optimize counter +operations. + +The following this_cpu() operations with implied preemption protection +are defined. These operations can be used without worrying about +preemption. Note that interrupts may still occur while an operation is +in progress and if the interrupt too modifies the variable, then RMW +actions may not be atomic. + + this_cpu_add() + this_cpu_read(pcp) + this_cpu_write(pcp, val) + this_cpu_add(pcp, val) + this_cpu_and(pcp, val) + this_cpu_or(pcp, val) + this_cpu_add_return(pcp, val) + this_cpu_xchg(pcp, nval) + this_cpu_cmpxchg(pcp, oval, nval) + this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2) + this_cpu_sub(pcp, val) + this_cpu_inc(pcp) + this_cpu_dec(pcp) + this_cpu_sub_return(pcp, val) + this_cpu_inc_return(pcp) + this_cpu_dec_return(pcp) + + +Inner working of this_cpu operations + On x86 the fs: or the gs: segment registers contain the base of the per cpu area. It is then possible to simply use the segment override @@ -53,12 +84,11 @@ this_cpu_ops such sequence also required preempt disable/enable to prevent the kernel from moving the thread to a different processor while the calculation is performed. -The main use of the this_cpu operations has been to optimize counter -operations. +Consider the following this_cpu operation this_cpu_inc(x) -results in the following single instruction (no lock prefix!) +The above results in the following single instruction (no lock prefix!) inc gs:[x] @@ -100,11 +130,10 @@ Takes the offset of a per cpu variable ( !) and returns the address of the per cpu variable that belongs to the currently executing processor. this_cpu_ptr avoids multiple steps that the common get_cpu/put_cpu sequence requires. No processor number is -available. Instead the offset of the local per cpu area is simply +available. Instead, the offset of the local per cpu area is simply added to the percpu offset. - Per cpu variables and offsets - @@ -118,15 +147,15 @@ Therefore the use of x or outside of the context of per cpu operations is invalid and will generally be treated like a NULL pointer dereference. -In the context of per cpu operations + DEFINE_PER_CPU(int, x); - x is a per cpu variable. Most this_cpu operations take a cpu - variable. +In the context of per cpu operations the above implies that x is a per +cpu variable. Most this_cpu operations take a cpu variable. -is the *offset* a per cpu variable. this_cpu_ptr() takes - the offset of a per cpu variable which makes this look a bit - strange. + int __percpu *p = + and hence p is the *offset* a per cpu variable. this_cpu_ptr() takes +the offset of a per cpu variable which makes this look a bit strange.
Re: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On Tue, 2014-07-15 at 22:50 -0400, Nick Krause wrote: > I may have not found it myself but if it doesn't exist can we write a > feature for checkpatch to be able to recursively > search a directory structure with a -d argument in order to make it > easier to search larger directories for files that still > need cleanup for files having kernel coding style issues. xargs already works fine. git ls-files /*.[ch] | xargs ./scripts/checkpatch.pl -f I suggest you only use anything like this on staging directories. -- 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 v5 0/4] iio: Add support for rotation from north
Hey Srinivas Thanks for looking into this for me! I'll fix it up and resubmit soon. On Tue, Jul 15, 2014 at 4:39 PM, Srinivas Pandruvada wrote: > Hi, > > Since you have only one attribute, it is working for you. > There is a dereference error in *channels. > > Check the attached diff, which will fix this. > > Thanks, > Srinivas > > > On 07/09/2014 03:12 PM, Reyad Attiyat wrote: >> >> Hey Srinivas, >> >> I did look into the panic you sent. I wasn't sure exactly what caused >> the NULL pointer. >> I tested it with out applying the last rotation from north patch, so >> no hid usages are found, my device only has rotation_from_north, and >> hid_parse_report() would return -EINVAL. >> I added another check to make sure a iio channel were set up, and >> return -EINVAL if not, but couldn't think of anything else. >> >> Could you test this version with dynamic debugging and see if it is >> finding any hid usage attributes. >> Any ideas what could cause this? I think I'm handling errors properly >> by returning what parse_report returns (-EINVAL or -ENOMEM) in probe >> >> Thanks, >> Reyad Attiyat >> >> On Wed, Jul 9, 2014 at 2:45 PM, Srinivas Pandruvada >> wrote: >>> >>> On 07/09/2014 12:30 PM, Reyad Attiyat wrote: This series of patches modifies magn-3d driver to handle the rotation from north usage. This is done by scanning the report and then building the iio arrays (vals and channels) dynamically. Changes from V4 I use the address field of struct iio_chan_spec to hold the array index of the usage attribute. The scan_index field is generated when creating an iio channel. Reyad Attiyat (4): iio: Documentation: Add documentation for rotation from north sensor usage attributes iio: types: Added support for rotation from north usage attributes iio: hid-sensor-magn-3d: Scan for usage attributes before setting up iio channels iio: hid-sensor-magn-3d: Add support for rotation from north Documentation/ABI/testing/sysfs-bus-iio | 82 +++ drivers/iio/industrialio-core.c | 4 + drivers/iio/magnetometer/hid-sensor-magn-3d.c | 199 -- include/linux/iio/types.h | 4 + 4 files changed, 245 insertions(+), 44 deletions(-) >>> Did you get chance to look at the cause of panic? >>> >>> Thanks, >>> Srinivas > > -- 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/6] autofs4: remove unused autofs4_ispending()
On Thu, 2014-07-10 at 09:41 +1000, NeilBrown wrote:
> Signed-off-by: NeilBrown
Obviously straight forward.
Acked-by: Ian Kent
> ---
> fs/autofs4/autofs_i.h | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
> index acf32054edd8..22a280151e45 100644
> --- a/fs/autofs4/autofs_i.h
> +++ b/fs/autofs4/autofs_i.h
> @@ -143,20 +143,6 @@ static inline int autofs4_oz_mode(struct autofs_sb_info
> *sbi) {
> return sbi->catatonic || task_pgrp(current) == sbi->oz_pgrp;
> }
>
> -/* Does a dentry have some pending activity? */
> -static inline int autofs4_ispending(struct dentry *dentry)
> -{
> - struct autofs_info *inf = autofs4_dentry_ino(dentry);
> -
> - if (inf->flags & AUTOFS_INF_PENDING)
> - return 1;
> -
> - if (inf->flags & AUTOFS_INF_EXPIRING)
> - return 1;
> -
> - return 0;
> -}
> -
> struct inode *autofs4_get_inode(struct super_block *, umode_t);
> void autofs4_free_ino(struct autofs_info *);
>
>
>
--
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 2/6] autofs4: remove a redundant assignment
On Thu, 2014-07-10 at 09:41 +1000, NeilBrown wrote:
> The variable 'ino' already exists and already
> has the correct value. The d_fsdata of a dentry
> is never changed after the d_fsdata is instantiated,
> so this new assignment cannot be necessary.
>
> It was introduced in
> commit b5b801779d59165c4ecf1009009109545bd1f642
> autofs4: Add d_manage() dentry operation
>
> Signed-off-by: NeilBrown
Again, an obvious cleanup, thanks for that.
Acked-by: Ian Kent
> ---
> fs/autofs4/expire.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> index 394e90b02c5e..a7be57e39be7 100644
> --- a/fs/autofs4/expire.c
> +++ b/fs/autofs4/expire.c
> @@ -333,7 +333,6 @@ struct dentry *autofs4_expire_direct(struct super_block
> *sb,
> if (ino->flags & AUTOFS_INF_PENDING)
> goto out;
> if (!autofs4_direct_busy(mnt, root, timeout, do_now)) {
> - struct autofs_info *ino = autofs4_dentry_ino(root);
> ino->flags |= AUTOFS_INF_EXPIRING;
> init_completion(>expire_complete);
> spin_unlock(>fs_lock);
>
>
--
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/6] autofs4: support RCU-walk
On Thu, 2014-07-10 at 09:41 +1000, NeilBrown wrote: > autofs4 currently doesn't support RCU-walk - it immediately > aborts any attempt at RCU-walk to force REF-walk for path name > lookup. As discussed I don't have time to properly test these just now but I'll do my best to review the patches and return to test them later. My impression is that you will be submitting these patches rather than expecting me to pick them up and submit them. If that's not what your expecting please let me know. I appreciate you including me in this work, all to often things get merged that I'm miss and while I may not have identified any problem with them at the time at least I would be aware of what I might need to look at when problems arise. > > This can cause a significant performance impact on multi-core > systems. > I have a client with a test case which spends >80% of its time > waiting for spinlocks with a "make -j 40" on a 40 core system. > > This patchset aims to remove most of these spinlocks. To be fully > effective in the particular case it needs a second patch set which > makes NFS RCU-walk friendly, but one thing at a time. > > This has only been lightly tested so far so I'm really after feed-back > rather than to have the patch set accepted, though the first two > patches are trivial and could be taken immediately. > > The last two patches are the most interesting so review comments on > those are particularly welcome. > > Thanks, > NeilBrown > > > --- > > NeilBrown (6): > autofs4: remove unused autofs4_ispending() > autofs4: remove a redundant assignment > autofs4: allow RCU-walk to walk through autofs4. > autofs4: factor should_expire() out of autofs4_expire_indirect. > autofs4: avoid taking fs_lock during rcu-walk > autofs4: don't take spinlock when not needed in autofs4_lookup_expiring > > > fs/autofs4/autofs_i.h | 20 + > fs/autofs4/dev-ioctl.c |2 - > fs/autofs4/expire.c| 192 > +--- > fs/autofs4/root.c | 46 > 4 files changed, 151 insertions(+), 109 deletions(-) > -- 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 14/55] timekeeping: Provide internal ktime_t based data
On Fri, Jul 11, 2014 at 6:44 AM, Thomas Gleixner wrote:
> The ktime_t based interfaces are used a lot in performance critical
> code pathes. Add ktime_t based data so the interfaces don't have to
> convert from the xtime/timespec based data.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/timekeeper_internal.h |3 +++
> kernel/time/timekeeping.c | 25 +
> 2 files changed, 28 insertions(+)
>
> Index: tip/include/linux/timekeeper_internal.h
> ===
> --- tip.orig/include/linux/timekeeper_internal.h
> +++ tip/include/linux/timekeeper_internal.h
> @@ -36,6 +36,9 @@ struct timekeeper {
> /* Clock shifted nano seconds */
> u64 xtime_nsec;
>
> + /* Monotonic base time */
> + ktime_t base_mono;
> +
> /* Current CLOCK_REALTIME time in seconds */
> u64 xtime_sec;
> /* CLOCK_REALTIME to CLOCK_MONOTONIC offset */
> Index: tip/kernel/time/timekeeping.c
> ===
> --- tip.orig/kernel/time/timekeeping.c
> +++ tip/kernel/time/timekeeping.c
> @@ -50,12 +50,30 @@ int __read_mostly timekeeping_suspended;
> /* Flag for if there is a persistent clock on this platform */
> bool __read_mostly persistent_clock_exist = false;
>
> +/*
> + * The xtime based monotonic readout is:
> + * nsec = (xtime_sec + wtm_sec) * 1e9 + wtm_nsec + now();
> + * The ktime based monotonic readout is:
> + * nsec = base_mono + now();
> + * ==> base_mono = (xtime_sec + wtm_sec) * 1e9 + wtm_nsec
> + */
> +static inline void tk_update_ktime_base(struct timekeeper *tk)
> +{
> + s64 nsec;
> +
> + nsec = (s64)(tk->xtime_sec + tk->wall_to_monotonic.tv_sec);
> + nsec *= NSEC_PER_SEC;
> + nsec += tk->wall_to_monotonic.tv_nsec;
> + tk->base_mono = ns_to_ktime(nsec);
> +}
Hrmm.. So I do understand why this is useful performance wise.
However, I'm really starting to feel that keeping all this duplicate
data is a real maintenance burden, as remembering to keep the values
in sync always is prone to error.
So I may have to just put up with it, but I'd like to start thinking
about how to reduce the duplicated data in the future. Arnd had an
interesting idea for something like storing fixed point seconds, which
could be cheaply converted to either ktime_t or timespec values.
However, I suspect that would be even more complex for folks to
understand, which I'd rather not do.
Overall, it might be best if we just kill the timespec
wall_to_monotonic/total_sleep_time/tai_offset values and keep the
timekeeper values almost all in timespecs. Then we can leave the
conversion process to basically cache the timespec values to the
vsyscall_update logic?
Or if we do want to maintain performance for non-vdso implementations,
maybe we can split the timespec functions out of the timekeeping core
and do a similar single shot update each tick to set the update the
tiemspec cached values. But that can be layered over the timekeeping
core and we can avoid the crazy updating 2 values any time we change
one logic we currently have.
thanks
-joh
--
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 / devfreq: Allocate memory using the right data type
On Tue, Jul 15, 2014 at 08:10:43PM -0700, Saravana Kannan wrote: > From: Suman Tatiraju > > Long and int have different sizes on a 64-bit machine. Allocate > memory for the time_in_state table using the right data type. > > Change-Id: I335277674018c0ea759aa0996309d52578ea1fd5 Please don't put this crud in patches you submit upstream. It means nothing to us. > Signed-off-by: Suman Tatiraju > Reviewed-by: Saravana Kannan > Signed-off-by: Saravana Kannan > --- > drivers/devfreq/devfreq.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. -- 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: build failure after merge of the wireless-next tree
Hi John,
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723au/core/rtw_sta_mgt.c: In function 'rtw_free_stainfo23a':
drivers/staging/rtl8723au/core/rtw_sta_mgt.c:254:27: error: expected expression
before ';' token
pstapriv->asoc_sta_count-;
^
Caused by commit 3dd51964026e ("rtl8723au: Corrections in the coding
style") (its always the cleanup patches that cause problems :-))
Please unit test *all* patches.
I have used the wireless-next tree from next-20140715 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH 0/4] [GIT PULL] tracing: A few more fixes
Linus, A few more fixes for ftrace infrastructure. I was cleaning out my INBOX and found two fixes from zhangwei from a year ago that were lost in my mail. These fix an inconsistency between trace_puts() and the way trace_printk() works. The reason this is important to fix is because when trace_printk() doesn't have any arguments, it turns into a trace_puts(). Not being able to enable a stack trace against trace_printk() because it does not have any arguments is quite confusing. Also, the fix is rather trivial and low risk. While porting some changes to PowerPC I discovered that it still has the function graph tracer filter bug that if you also enable stack tracing the function graph tracer filter is ignored. I fixed that up. Finally, Martin Lau, fixed a bug that would cause readers of the ftrace ring buffer to block forever even though it was suppose to be NONBLOCK. This is based on top of the last pull request that I sent you earlier today. Please pull the latest trace-fixes-v3.16-rc5-v2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-fixes-v3.16-rc5-v2 Tag SHA1: 4932f1a76294c2e60930de9c3179e54fd95e3771 Head SHA1: 97b8ee845393701edc06e27ccec2876ff9596019 Martin Lau (1): ring-buffer: Fix polling on trace_pipe Steven Rostedt (Red Hat) (1): tracing: Fix graph tracer with stack tracer on other archs zhangwei(Jovi) (2): tracing: Add ftrace_trace_stack into __trace_puts/__trace_bputs tracing: Add TRACE_ITER_PRINTK flag check in __trace_puts/__trace_bputs kernel/trace/ftrace.c | 4 ++-- kernel/trace/ring_buffer.c | 4 kernel/trace/trace.c | 18 -- 3 files changed, 18 insertions(+), 8 deletions(-) -- 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/4] tracing: Add TRACE_ITER_PRINTK flag check in __trace_puts/__trace_bputs
From: "zhangwei(Jovi)" The TRACE_ITER_PRINTK check in __trace_puts/__trace_bputs is missing, so add it, to be consistent with __trace_printk/__trace_bprintk. Those functions are all called by the same function: trace_printk(). Link: http://lkml.kernel.org/p/51e7a7d6.8090...@huawei.com Cc: sta...@vger.kernel.org # 3.11+ Signed-off-by: zhangwei(Jovi) Signed-off-by: Steven Rostedt --- kernel/trace/trace.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index a6ffc8918dda..bda9621638cc 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -468,6 +468,9 @@ int __trace_puts(unsigned long ip, const char *str, int size) int alloc; int pc; + if (!(trace_flags & TRACE_ITER_PRINTK)) + return 0; + pc = preempt_count(); if (unlikely(tracing_selftest_running || tracing_disabled)) @@ -515,6 +518,9 @@ int __trace_bputs(unsigned long ip, const char *str) int size = sizeof(struct bputs_entry); int pc; + if (!(trace_flags & TRACE_ITER_PRINTK)) + return 0; + pc = preempt_count(); if (unlikely(tracing_selftest_running || tracing_disabled)) -- 2.0.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 4/4] ring-buffer: Fix polling on trace_pipe
From: Martin Lau
ring_buffer_poll_wait() should always put the poll_table to its wait_queue
even there is immediate data available. Otherwise, the following epoll and
read sequence will eventually hang forever:
1. Put some data to make the trace_pipe ring_buffer read ready first
2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee)
3. epoll_wait()
4. read(trace_pipe_fd) till EAGAIN
5. Add some more data to the trace_pipe ring_buffer
6. epoll_wait() -> this epoll_wait() will block forever
~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2,
ring_buffer_poll_wait() returns immediately without adding poll_table,
which has poll_table->_qproc pointing to ep_poll_callback(), to its
wait_queue.
~ During the epoll_wait() call in step 3 and step 6,
ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue
because the poll_table->_qproc is NULL and it is how epoll works.
~ When there is new data available in step 6, ring_buffer does not know
it has to call ep_poll_callback() because it is not in its wait queue.
Hence, block forever.
Other poll implementation seems to call poll_wait() unconditionally as the very
first thing to do. For example, tcp_poll() in tcp.c.
Link:
http://lkml.kernel.org/p/20140610060637.ga14...@devbig242.prn2.facebook.com
Cc: sta...@vger.kernel.org # 2.6.27
Fixes: 2a2cc8f7c4d0 "ftrace: allow the event pipe to be polled"
Reviewed-by: Chris Mason
Signed-off-by: Martin Lau
Signed-off-by: Steven Rostedt
---
kernel/trace/ring_buffer.c | 4
1 file changed, 4 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7c56c3d06943..ff7027199a9a 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -616,10 +616,6 @@ int ring_buffer_poll_wait(struct ring_buffer *buffer, int
cpu,
struct ring_buffer_per_cpu *cpu_buffer;
struct rb_irq_work *work;
- if ((cpu == RING_BUFFER_ALL_CPUS && !ring_buffer_empty(buffer)) ||
- (cpu != RING_BUFFER_ALL_CPUS && !ring_buffer_empty_cpu(buffer,
cpu)))
- return POLLIN | POLLRDNORM;
-
if (cpu == RING_BUFFER_ALL_CPUS)
work = >irq_work;
else {
--
2.0.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 2/4] tracing: Fix graph tracer with stack tracer on other archs
From: "Steven Rostedt (Red Hat)" Running my ftrace tests on PowerPC, it failed the test that checks if function_graph tracer is affected by the stack tracer. It was. Looking into this, I found that the update_function_graph_func() must be called even if the trampoline function is not changed. This is because archs like PowerPC do not support ftrace_ops being passed by assembly and instead uses a helper function (what the trampoline function points to). Since this function is not changed even when multiple ftrace_ops are added to the code, the test that falls out before calling update_function_graph_func() will miss that the update must still be done. Call update_function_graph_function() for all calls to update_ftrace_function() Cc: sta...@vger.kernel.org # 3.3+ Signed-off-by: Steven Rostedt --- kernel/trace/ftrace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 5b372e3ed675..ac9d1dad630b 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -265,12 +265,12 @@ static void update_ftrace_function(void) func = ftrace_ops_list_func; } + update_function_graph_func(); + /* If there's no change, then do nothing more here */ if (ftrace_trace_function == func) return; - update_function_graph_func(); - /* * If we are using the list function, it doesn't care * about the function_trace_ops. -- 2.0.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 1/4] tracing: Add ftrace_trace_stack into __trace_puts/__trace_bputs
From: "zhangwei(Jovi)" Currently trace option stacktrace is not applicable for trace_printk with constant string argument, the reason is in __trace_puts/__trace_bputs ftrace_trace_stack is missing. In contrast, when using trace_printk with non constant string argument(will call into __trace_printk/__trace_bprintk), then trace option stacktrace is workable, this inconstant result will confuses users a lot. Link: http://lkml.kernel.org/p/51e7a7c9.9040...@huawei.com Cc: sta...@vger.kernel.org # 3.10+ Signed-off-by: zhangwei(Jovi) Signed-off-by: Steven Rostedt --- kernel/trace/trace.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index f243444a3772..a6ffc8918dda 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -466,6 +466,9 @@ int __trace_puts(unsigned long ip, const char *str, int size) struct print_entry *entry; unsigned long irq_flags; int alloc; + int pc; + + pc = preempt_count(); if (unlikely(tracing_selftest_running || tracing_disabled)) return 0; @@ -475,7 +478,7 @@ int __trace_puts(unsigned long ip, const char *str, int size) local_save_flags(irq_flags); buffer = global_trace.trace_buffer.buffer; event = trace_buffer_lock_reserve(buffer, TRACE_PRINT, alloc, - irq_flags, preempt_count()); + irq_flags, pc); if (!event) return 0; @@ -492,6 +495,7 @@ int __trace_puts(unsigned long ip, const char *str, int size) entry->buf[size] = '\0'; __buffer_unlock_commit(buffer, event); + ftrace_trace_stack(buffer, irq_flags, 4, pc); return size; } @@ -509,6 +513,9 @@ int __trace_bputs(unsigned long ip, const char *str) struct bputs_entry *entry; unsigned long irq_flags; int size = sizeof(struct bputs_entry); + int pc; + + pc = preempt_count(); if (unlikely(tracing_selftest_running || tracing_disabled)) return 0; @@ -516,7 +523,7 @@ int __trace_bputs(unsigned long ip, const char *str) local_save_flags(irq_flags); buffer = global_trace.trace_buffer.buffer; event = trace_buffer_lock_reserve(buffer, TRACE_BPUTS, size, - irq_flags, preempt_count()); + irq_flags, pc); if (!event) return 0; @@ -525,6 +532,7 @@ int __trace_bputs(unsigned long ip, const char *str) entry->str = str; __buffer_unlock_commit(buffer, event); + ftrace_trace_stack(buffer, irq_flags, 4, pc); return 1; } -- 2.0.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/
char interface to sdio, chdio.c
Hi Stephen. I had some people ask me about a sdio userspace interface, and ran across the chdio.c file as found in the MSM android kernel trees: https://android.googlesource.com/kernel/msm/+/57b74303d6f033ab04be039379f6661337fb9279 Any reason why this hasn't been submitted upstream? Or has it, and was it rejected? Also, what userspace code uses this? Is there some android-specific code somewhere that does a weird mix of sysfs and char control of the hardware? And what type of SDIO devices are controlled with this? 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/
[PATCH v5 1/4] pwm: add CSR SiRFSoc PWM driver
PWM controller of CSR SiRFSoC can generate 7 independent outputs. Each output
duty cycle can be adjusted by setting the corresponding wait & hold registers.
There are 6 external channels (0 to 5) and 1 internal channel (6).
Supports a wide frequency range: the source clock divider can be from 2
up to 65536*2.
Signed-off-by: Huayi Li
---
drivers/pwm/Kconfig| 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sirf.c | 450 +
3 files changed, 461 insertions(+)
create mode 100644 drivers/pwm/pwm-sirf.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4ad7b89..77d65a6 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -215,6 +215,16 @@ config PWM_SAMSUNG
To compile this driver as a module, choose M here: the module
will be called pwm-samsung.
+config PWM_SIRF
+ tristate "SiRF PWM support"
+ depends on ARCH_SIRF
+ help
+ Generic PWM framework driver for the PWM controller on SiRF
+ SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sirf.
+
config PWM_SPEAR
tristate "STMicroelectronics SPEAr PWM support"
depends on PLAT_SPEAR
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5c86a19..7fa4f14 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PWM_PUV3)+= pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
+obj-$(CONFIG_PWM_SIRF) += pwm-sirf.o
obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
diff --git a/drivers/pwm/pwm-sirf.c b/drivers/pwm/pwm-sirf.c
new file mode 100644
index 000..a5a9e2f
--- /dev/null
+++ b/drivers/pwm/pwm-sirf.c
@@ -0,0 +1,450 @@
+/*
+ * SIRF serial SoC PWM device core driver
+ *
+ * Copyright (c) 2014 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SIRF_PWM_SELECT_PRECLK 0x0
+#define SIRF_PWM_OE0x4
+#define SIRF_PWM_ENABLE_PRECLOCK 0x8
+#define SIRF_PWM_ENABLE_POSTCLOCK 0xC
+#define SIRF_PWM_GET_WAIT_OFFSET(n)(0x10 + 0x8*n)
+#define SIRF_PWM_GET_HOLD_OFFSET(n)(0x14 + 0x8*n)
+
+#define SIRF_PWM_TR_STEP(n)(0x48 + 0x8*n)
+#define SIRF_PWM_STEP_HOLD(n) (0x4c + 0x8*n)
+
+#define SRC_FIELD_SIZE 3
+#define BYPASS_MODE_BIT21
+#define TRANS_MODE_SELECT_BIT 7
+
+#define SIRF_MAX_SRC_CLK 5
+
+struct sirf_pwm_chip {
+ struct pwm_chip chip;
+ struct mutex mutex;
+ void __iomem *base;
+ struct clk *pwmc_clk;
+};
+
+struct sirf_pwm {
+ u32 sigsrc_clk_idx;
+ struct clk *sigsrc_clk;
+ u32 bypass_mode;
+ u32 duty_ns;
+};
+
+static inline struct sirf_pwm_chip *to_sirf_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct sirf_pwm_chip, chip);
+}
+
+static int sirf_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct sirf_pwm *spwm;
+
+ spwm = devm_kzalloc(chip->dev, sizeof(*spwm), GFP_KERNEL);
+ if (!spwm)
+ return -ENOMEM;
+
+ pwm_set_chip_data(pwm, spwm);
+
+ return 0;
+}
+
+static void sirf_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct sirf_pwm *spwm = pwm_get_chip_data(pwm);
+
+ if (!spwm)
+ devm_kfree(chip->dev, spwm);
+}
+
+static u32 sirf_pwm_ns_to_cycles(struct pwm_device *pwm, u32 time_ns)
+{
+ struct sirf_pwm *spwm = pwm_get_chip_data(pwm);
+ u32 src_clk_rate = clk_get_rate(spwm->sigsrc_clk);
+ u64 cycle;
+
+ cycle = div_u64((u64)src_clk_rate * time_ns, NSEC_PER_SEC);
+
+ return (u32)(cycle > 1 ? cycle : 1);
+}
+
+static void _sirf_pwm_hwconfig(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ u32 period_cycles, high_cycles, low_cycles;
+ struct sirf_pwm_chip *spwmc = to_sirf_pwm_chip(chip);
+ struct sirf_pwm *spwm = pwm_get_chip_data(pwm);
+
+ period_cycles = sirf_pwm_ns_to_cycles(pwm, pwm_get_period(pwm));
+
+ /*
+* enter bypass mode, high_cycles and low_cycle
+* do not need to config if period_cycles == 1
+*/
+ if (period_cycles == 1) {
+ spwm->bypass_mode = 1;
+ } else {
+ spwm->bypass_mode = 0;
+
+ high_cycles = sirf_pwm_ns_to_cycles(pwm, spwm->duty_ns);
+ low_cycles = period_cycles - high_cycles;
+
+ /*
+* high_cycles will equal to period_cycles
[PATCH] PM / devfreq: Allocate memory using the right data type
From: Suman Tatiraju Long and int have different sizes on a 64-bit machine. Allocate memory for the time_in_state table using the right data type. Change-Id: I335277674018c0ea759aa0996309d52578ea1fd5 Signed-off-by: Suman Tatiraju Reviewed-by: Saravana Kannan Signed-off-by: Saravana Kannan --- drivers/devfreq/devfreq.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 65eed38..349e28ea 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -483,9 +483,10 @@ struct devfreq *devfreq_add_device(struct device *dev, devfreq->profile->max_state * devfreq->profile->max_state, GFP_KERNEL); - devfreq->time_in_state = devm_kzalloc(dev, sizeof(unsigned int) * - devfreq->profile->max_state, - GFP_KERNEL); + devfreq->time_in_state = devm_kzalloc(dev, + sizeof(*(devfreq->time_in_state)) * + devfreq->profile->max_state, + GFP_KERNEL); devfreq->last_stat_updated = jiffies; dev_set_name(>dev, "%s", dev_name(dev)); -- 1.8.2.1 The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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: [GIT] Networking
From: Linus Torvalds Date: Tue, 15 Jul 2014 19:24:24 -0700 > I just thought I'd point out this thing when I noticed. It's not > new, and has been going on, I just reacted to it now Ok, I'll discuss with John the best thing for us moving forward. 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: linux-next: manual merge of the pm tree with the ia64 tree
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, July 15, 2014 8:15 PM
>
> On Tuesday, July 15, 2014 01:56:20 PM Stephen Rothwell wrote:
> >
> > --Sig_/Cs291xJCrI1kc_+PiCdNT0M
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hi Rafael,
> >
> > Today's linux-next merge of the pm tree got a conflict in
> > drivers/acpi/acpi_extlog.c between commits 2dfb7d51a61d ("trace, RAS:
> > Add eMCA trace event interface") and d6cae935ec5b ("trace, eMCA: Add a
> > knob to adjust where to save event log") from the ia64 tree and commit
> > 0a00fd5e20fd ("ACPICA: Restore error table definitions to reduce code
> > differences between Linux and ACPICA upstream") from the pm tree.
> >
> > I fixed it up (hopefully - see below) and can carry the fix as
> > necessary (no action is required).
>
> Thanks for fixing this up!
>
> Lv, can you please check if acpi_extlog.c is fine in linux-next?
I checked.
There is no problem in rafael/linux-pm.git/linux-next branch.
The 2 commits:
trace, RAS: Add eMCA trace event interface
trace, eMCA: Add a knob to adjust where to save event log
are not in torvalds/linux.git/master branch, I found them in
aegl/linux.git/next branch.
So if torvalds/linux.git/master merges rafael/linux-pm.git/linux-next before
merging aegl/linux.git/next, we will need the following fix.
And the following collision fix is correct.
Thanks and best regards
-Lv
>
> Rafael
>
>
> > --=20
> > Cheers,
> > Stephen Rothwells...@canb.auug.org.au
> >
> > diff --cc drivers/acpi/acpi_extlog.c
> > index 0ad6f389d922,340d09518f8e..
> > --- a/drivers/acpi/acpi_extlog.c
> > +++ b/drivers/acpi/acpi_extlog.c
> > @@@ -139,12 -137,8 +139,12 @@@ static int extlog_print(struct notifier
> > struct mce *mce =3D (struct mce *)data;
> > int bank =3D mce->bank;
> > int cpu =3D mce->extcpu;
> > - struct acpi_generic_status *estatus, *tmp;
> > - struct acpi_generic_data *gdata;
> > - struct acpi_hest_generic_status *estatus;
> > - int rc;
> > ++ struct acpi_hest_generic_status *estatus, *tmp;
> > ++ struct acpi_hest_generic_data *gdata;
> > + const uuid_le *fru_id =3D _UUID_LE;
> > + char *fru_text =3D "";
> > + uuid_le *sec_type;
> > + static u32 err_seq;
> > =20
> > estatus =3D extlog_elog_entry_check(cpu, bank);
> > if (estatus =3D=3D NULL)
> > @@@ -154,29 -148,8 +154,29 @@@
> > /* clear record status to enable BIOS to update it again */
> > estatus->block_status =3D 0;
> > =20
> > - tmp =3D (struct acpi_generic_status *)elog_buf;
> > - rc =3D print_extlog_rcd(NULL, (struct acpi_hest_generic_status
> > *)elog_bu=
> > f, cpu);
> > ++ tmp =3D (struct acpi_hest_generic_status *)elog_buf;
> > +
> > + if (!ras_userspace_consumers()) {
> > + print_extlog_rcd(NULL, tmp, cpu);
> > + goto out;
> > + }
> > +
> > + /* log event via trace */
> > + err_seq++;
> > - gdata =3D (struct acpi_generic_data *)(tmp + 1);
> > ++ gdata =3D (struct acpi_hest_generic_data *)(tmp + 1);
> > + if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
> > + fru_id =3D (uuid_le *)gdata->fru_id;
> > + if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
> > + fru_text =3D gdata->fru_text;
> > + sec_type =3D (uuid_le *)gdata->section_type;
> > + if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
> > + struct cper_sec_mem_err *mem =3D (void *)(gdata + 1);
> > + if (gdata->error_data_length >=3D sizeof(*mem))
> > + trace_extlog_mem_event(mem, err_seq, fru_id, fru_text,
> > + (u8)gdata->error_severity);
> > + }
> > =20
> > +out:
> > return NOTIFY_STOP;
> > }
> > =20
> >
> > --Sig_/Cs291xJCrI1kc_+PiCdNT0M
> > Content-Type: application/pgp-signature; name=signature.asc
> > Content-Disposition: attachment; filename=signature.asc
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQIcBAEBCAAGBQJTxKZpAAoJEMDTa8Ir7ZwVmnIP/2g7urRq6/whsLXGDEKOlYv+
> > ZhKntRYDFYCTcP3BVWoVMxVkg3FrnH4nbM72qYxQEz5CIFTxLXC6mMyBCmkq6q/7
> > P1fAwUE5RbcCy9p4Iyz43qCATSSpKY5Q/Yam2KixbRWZC2UTRGE+Ku1vqNZnY1WH
> > Uzf7Cb1ShsGhKDZyitrNLHCaMMv1Ds2RES+P2ry6kx8mXms5S/nTB0v/a41Osz/r
> > xPSRt715NJaHKHYuuOdag4ZWOgrbZjEVuvsxyoRZT9uj+6dQc+r7VnpHQ6kMnCpt
> > 1X+0rqi3czijnDlZm1FuK/18Peib0+JNbM4vYEanhMxKT1GDxhwuO7t8b3J+19Z1
> > /Z6eOsaRn+rxUb5TEvSkDRFiev2itbTcYK5vKQ03RfzeGB2wPxTMvOxRMungVlFZ
> > z3i5IVe+awMs5VOWIL4BkJMaQWCqfXtG9iPC22QnFLWHaoZp6d06mFXdUbkNZwhw
> > 3u1SaeuoN+mKo+1GnJOfry8MCYQnqmyRbf2tH5Mk+w9THfkHc+C911p1ff0Lw/gF
> > T3flTK7sRyaPtpQrGCK8W74++b75Y/98XQ4N4bb2MJrym7yT3kh2avQMpQKNG3GO
> > pTJKpKwvp5H3hbYl+CpOJ4i5EAlvG11qstwcih+nFPXebcEfspHRoeHInxgg+zDT
> > Sj9YngNGGQR1//SaTD67
> > =oSfG
> > -END PGP SIGNATURE-
> >
> > --Sig_/Cs291xJCrI1kc_+PiCdNT0M--
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a
[PATCH v5 0/4] PWM: add and enable CSR SiRFSoC PWM driver
Changes in v5: - select the best source clock which can be divided to a more accurate PWM clock - only enable PWM clock and its source clock when needed Changes in v3: - v4: fix many issues from Thierry's feedbacks Changes in v3: - add "depends on" COMPILE_TEST according to Arnd's feedback; - move the pwm clock source to dts according to Arnd's feedback; - add lost dt-binding document Changes in v2: - clean the source clock of PWM wave, use OSC(26MHz) Huayi Li (4): pwm: add CSR SiRFSoc PWM driver pwm: sirf: add dt-binding document ARM: dts: sirf: fix the pwm-cells and clocks ARM: prima2_defconfig: enable PWM and sirf PWM driver Documentation/devicetree/bindings/pwm/pwm-sirf.txt | 29 ++ arch/arm/boot/dts/atlas6.dtsi | 8 +- arch/arm/boot/dts/prima2.dtsi | 8 +- arch/arm/configs/prima2_defconfig | 2 + drivers/pwm/Kconfig| 10 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sirf.c | 450 + 7 files changed, 504 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sirf.txt create mode 100644 drivers/pwm/pwm-sirf.c -- 1.9.3 Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.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/
[PATCH v5 3/4] ARM: dts: sirf: fix the pwm-cells and clocks
This patch adds missed pwm-cells, clock-names and signal source
clock for PWM module.
Signed-off-by: Huayi Li
---
arch/arm/boot/dts/atlas6.dtsi | 8 ++--
arch/arm/boot/dts/prima2.dtsi | 8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index bb22842..d424a69 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -638,10 +638,14 @@
};
};
- pwm@b013 {
+ pwm: pwm@b013 {
compatible = "sirf,prima2-pwm";
+ #pwm-cells = <2>;
reg = <0xb013 0x1>;
- clocks = < 21>;
+ clocks = < 21>, < 1>, < 2>,
+ < 3>, < 0>, < 4>;
+ clock-names = "pwmc", "sigsrc0", "sigsrc1",
+ "sigsrc2", "sigsrc3", "sigsrc4";
};
efusesys@b014 {
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 963b7e5..68bb0c4 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -646,10 +646,14 @@
};
};
- pwm@b013 {
+ pwm: pwm@b013 {
compatible = "sirf,prima2-pwm";
+ #pwm-cells = <2>;
reg = <0xb013 0x1>;
- clocks = < 21>;
+ clocks = < 21>, < 1>, < 2>,
+ < 3>, < 0>, < 4>;
+ clock-names = "pwmc", "sigsrc0", "sigsrc1",
+ "sigsrc2", "sigsrc3", "sigsrc4";
};
efusesys@b014 {
--
1.9.3
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.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: linux-next: build failure after merge of the v4l-dvb tree
Hi Guenter, On Tue, 15 Jul 2014 12:08:07 -0700 Guenter Roeck wrote: > > > > > Do you mean b6220ad66 (sched: Fix compiler warnings) ? I thought that > > > > was accepted > > > > a week or so ago. > > > > > > That is in the tip tree and includes the fixups to powerpc and arm. I > > > don't merge the tip tree till well after the v4l-dvb tree. The merge > > > in the v4l-dvb tree included only the change to include/linus/sched.h > > > and neither parent fo that merge was based on the tip tree ... > > > > > Stephen, > > > > Do you know if/when this patch will be merged upstream? It doesn't > > seem to be at 2.6.16-rc5. Otherwise, I'll likely cherry-pick it on > s/2.16/3.16/ > > my trees, as the lack of this fixup is making hard for me to check > > if a media tree patch isn't introducing new warnings. > > Only queued for 3.17 as far as I can see, and not scheduled for 3.16. Its in the sched/urgent branch of the tip tree, so hopefully it will go to Linus shortly. [ccing various tip tree maintainers ...] Hi guys, this commit (b6220ad66 (sched: Fix compiler warnings)) fixes lots of W=1 build warnings ... just wondering when it will progress? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [Patch V3 00/16] Enable support of IOAPIC hotplug on x86 platforms
Hi Konrad, We have found the root cause with your great support. If BIOS assigns an IRQ number for a PCI device, acpi_pci_irq_enable() fails to assign IOAPIC IRQ then due to the check: if (dev->irq > 0) return 0; For a quick workaround, just comment out above check. But we need some time to figure out a clean fixup for it. We will send out new version once it gets resolved. Thanks for your great help again. Regards! Gerry On 2014/7/16 0:10, Konrad Rzeszutek Wilk wrote: > already assigned IRQ -- 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 v3] PM / devfreq: Add possible_frequencies device attribute
Some devices use freq_table instead of OPP. For those devices, the
available_frequencies sysfs file shows up empty. So, add a
possible_frequencies attribute/syfs file that list all the possible
frequencies.
For devices that use OPP, the output of this file will match
available_frequencies. It may change in the future to show all OPP
frequencies -- even the disabled ones.
Signed-off-by: Saravana Kannan
---
drivers/devfreq/devfreq.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 9f90369..65eed38 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -994,6 +994,31 @@ static ssize_t available_frequencies_show(struct device *d,
}
static DEVICE_ATTR_RO(available_frequencies);
+static ssize_t possible_frequencies_show(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct devfreq *df = to_devfreq(d);
+ unsigned int i = 0;
+ ssize_t count = 0;
+
+ if (!df->profile->freq_table)
+ return available_frequencies_show(d, attr, buf);
+
+ for (i = 0; i < df->profile->max_state; i++)
+ count += scnprintf([count], (PAGE_SIZE - count - 2),
+ "%u ", df->profile->freq_table[i]);
+
+ /* Truncate the trailing space */
+ if (count)
+ count--;
+
+ count += sprintf([count], "\n");
+
+ return count;
+}
+static DEVICE_ATTR_RO(possible_frequencies);
+
static ssize_t trans_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1041,6 +1066,7 @@ static struct attribute *devfreq_attrs[] = {
_attr_available_governors.attr,
_attr_cur_freq.attr,
_attr_available_frequencies.attr,
+ _attr_possible_frequencies.attr,
_attr_target_freq.attr,
_attr_polling_interval.attr,
_attr_min_freq.attr,
--
1.8.2.1
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 v2] alpha: Join lines and merge strings for the two lines
This patch merges lines 92 and 93. In addition it merges the strings on
both lines by removing the quotes around the seperate strings. This is
needed to remove the final checkpatch error I get from running it on
bootpz.c
Signed-off-by: Nicholas Krause
---
arch/alpha/boot/bootpz.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/alpha/boot/bootpz.c b/arch/alpha/boot/bootpz.c
index d6ad191..51122f7 100644
--- a/arch/alpha/boot/bootpz.c
+++ b/arch/alpha/boot/bootpz.c
@@ -89,8 +89,7 @@ check_range(unsigned long vstart, unsigned long vend,
if (kaddr >= kstart && kaddr <= kend)
{
#ifdef DEBUG_CHECK_RANGE
- srm_printk("OVERLAP: vaddr 0x%lx kaddr 0x%lx"
- " [0x%lx:0x%lx]\n",
+ srm_printk("OVERLAP: vaddr 0x%lx kaddr 0x%lx
[0x%lx:0x%lx]\n",
vaddr, kaddr, kstart, kend);
#endif
return 1;
--
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/
[PATCH v5 4/4] ARM: prima2_defconfig: enable PWM and sirf PWM driver
Signed-off-by: Huayi Li --- arch/arm/configs/prima2_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/prima2_defconfig b/arch/arm/configs/prima2_defconfig index 23591db..303204a 100644 --- a/arch/arm/configs/prima2_defconfig +++ b/arch/arm/configs/prima2_defconfig @@ -50,6 +50,8 @@ CONFIG_DMADEVICES_DEBUG=y CONFIG_DMADEVICES_VDEBUG=y CONFIG_SIRF_DMA=y # CONFIG_IOMMU_SUPPORT is not set +CONFIG_PWM=y +CONFIG_PWM_SIRF=y CONFIG_EXT2_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y -- 1.9.3 Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.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] staging: emxx_udc: Fix coding style errors
Hi Greg, On Tue, Jul 15, 2014 at 07:21:28PM -0700, Greg Kroah-Hartman wrote: > On Wed, Jul 16, 2014 at 09:16:15AM +0800, Stone Kang wrote: > > Only fixing errors reported by checkpatch.pl, based on the following > > rules: > > 1. '*' should be adjacent to the data name or function name. > > 2. Don't use C99-style "// ..." comments. > > > > Signed-off-by: KANG Yuxuan > > I see two different names here, one in the "From:" line, and one in the > Signed-off-by: line, are they the same? They need to match up :( > > Please resend with this fixed. > > thanks, > > greg k-h Sorry, I forgot to set the From: line. New patch has been sent, but as the content didn't change, no 'v2' tag was attached in the title. -- 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] drm/qxl: return IRQ_NONE if it was not our irq
On 05/12/2014 04:35 PM, Jason Wang wrote:
> Return IRQ_NONE if it was not our irq. This is necessary for the case
> when qxl is sharing irq line with a device A in a crash kernel. If qxl
> is initialized before A and A's irq was raised during this gap,
> returning IRQ_HANDLED in this case will cause this irq to be raised
> again after EOI since kernel think it was handled but in fact it was
> not.
>
> Cc: Gerd Hoffmann
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jason Wang
> ---
> drivers/gpu/drm/qxl/qxl_irq.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
> index 28f84b4..3485bdc 100644
> --- a/drivers/gpu/drm/qxl/qxl_irq.c
> +++ b/drivers/gpu/drm/qxl/qxl_irq.c
> @@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg)
>
> pending = xchg(>ram_header->int_pending, 0);
>
> + if (!pending)
> + return IRQ_NONE;
> +
> atomic_inc(>irq_received);
>
> if (pending & QXL_INTERRUPT_DISPLAY) {
Ping.
--
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/
[Bug report] Hit false positives bug with script/checkpatch.pl
Hi,
I hit a false positives bug when run script/checkpatch.pl to my patch,
It reported errors to following macro definition, but in fact the macro is
correct, I couldn't change that macro according to the error message output
by script/checkpatch.pl. because of this bug, my patch was rejected by some
guy's patchwork.
--
./scripts/checkpatch.pl netxen.patch
ERROR: Macros with complex values should be enclosed in parenthesis
#38: FILE: drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c:45:
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
ERROR: Macros with complex values should be enclosed in parenthesis
#42: FILE: drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c:49:
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
total: 2 errors, 0 warnings, 62 lines checked
netxen.patch has style problems, please review.
If any of these errors are false positives, please report
--
Please check and fix it.
Thanks,
Ethan
-the sample patch --
From: Ethan Zhao
netxen driver has implemented netxen_nic_get_ethtool_stats() interface,
but it doesn't collect stats.rxdropped in driver, so we will get
different rx_dropped statistic information while using ifconfig and ethtool.
this patch fills stats.rxdropped field with data from net core
with dev_get_stats() just as ixgbe driver did for some of its stats.
V2: only fix the stats.rxdropped field.
Tested with last netxen 4.0.82
Compiled with net-next branch 3.16-rc2
Signed-off-by: Ethan Zhao
Tested-by: Sriharsha Yadagudde
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c| 34 +---
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 4ca2c19..49e6a1b 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -33,22 +33,30 @@
#include "netxen_nic.h"
#include "netxen_nic_hw.h"
+enum {NETDEV_STATS, NETXEN_STATS};
+
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
+ int type;
int sizeof_stat;
int stat_offset;
};
-#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_adapter *)0)->m), \
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
+
#define NETXEN_NIC_PORT_WINDOW 0x1
#define NETXEN_NIC_INVALID_DATA 0xDEADBEEF
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
{"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
{"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
- {"rx_dropped", NETXEN_NIC_STAT(stats.rxdropped)},
+ {"rx_dropped", NETXEN_NETDEV_STAT(rx_dropped)},
{"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
{"csummed", NETXEN_NIC_STAT(stats.csummed)},
{"rx_pkts", NETXEN_NIC_STAT(stats.rx_pkts)},
@@ -679,11 +687,27 @@ netxen_nic_get_ethtool_stats(struct net_device *dev,
{
struct netxen_adapter *adapter = netdev_priv(dev);
int index;
+ struct rtnl_link_stats64 temp;
+ const struct rtnl_link_stats64 *net_stats;
+ char *p = NULL;
+ net_stats = dev_get_stats(dev, );
for (index = 0; index < NETXEN_NIC_STATS_LEN; index++) {
- char *p =
- (char *)adapter +
- netxen_nic_gstrings_stats[index].stat_offset;
+
+ switch (netxen_nic_gstrings_stats[index].type) {
+ case NETDEV_STATS:
+ p = (char *)net_stats +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ case NETXEN_STATS:
+ p = (char *)adapter +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ default:
+ data[index] = 0;
+ continue;
+ }
+
data[index] =
(netxen_nic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *) p : *(u32 *) p;
-- 1.7.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/
Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
I may have not found it myself but if it doesn't exist can we write a feature for checkpatch to be able to recursively search a directory structure with a -d argument in order to make it easier to search larger directories for files that still need cleanup for files having kernel coding style issues. Furthermore I am asking you guys to write this feature if you feel this is a good idea as I am only a beginner in perl. I can help out by testing it however if needed :). Cheers Nick -- 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/4] x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available
It's considerably better than any of the alternatives on KVM.
Signed-off-by: Andy Lutomirski
---
arch/x86/boot/compressed/aslr.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index fc6091a..8583f0e 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -5,6 +5,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -15,6 +17,22 @@
static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+static bool kvm_para_has_feature(unsigned int feature)
+{
+ u32 kvm_base;
+ u32 features;
+
+ if (!has_cpuflag(X86_FEATURE_HYPERVISOR))
+ return false;
+
+ kvm_base = hypervisor_cpuid_base("KVMKVMKVM\0\0\0", KVM_CPUID_FEATURES);
+ if (!kvm_base)
+ return false;
+
+ features = cpuid_eax(kvm_base | KVM_CPUID_FEATURES);
+ return features & (1UL << feature);
+}
+
#define I8254_PORT_CONTROL 0x43
#define I8254_PORT_COUNTER00x40
#define I8254_CMD_READBACK 0xC0
@@ -81,6 +99,15 @@ static unsigned long get_random_long(void)
}
}
+ if (kvm_para_has_feature(KVM_FEATURE_GET_RNG_SEED)) {
+ u64 seed;
+
+ debug_putstr(" MSR_KVM_GET_RNG_SEED");
+ rdmsrl(MSR_KVM_GET_RNG_SEED, seed);
+ random ^= (unsigned long)seed;
+ use_i8254 = false;
+ }
+
if (has_cpuflag(X86_FEATURE_TSC)) {
debug_putstr(" RDTSC");
rdtscll(raw);
--
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/
[PATCH 3/4] random: Seed pools from arch_get_slow_rng_u64 at startup
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski
---
drivers/char/random.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..bd88a24 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1248,7 +1248,7 @@ EXPORT_SYMBOL(get_random_bytes_arch);
*/
static void init_std_data(struct entropy_store *r)
{
- int i;
+ int i, slow_rng_bits = 0;
ktime_t now = ktime_get_real();
unsigned long rv;
@@ -1261,6 +1261,18 @@ static void init_std_data(struct entropy_store *r)
mix_pool_bytes(r, , sizeof(rv), NULL);
}
mix_pool_bytes(r, utsname(), sizeof(*(utsname())), NULL);
+
+ for (i = 0; i < 4; i++) {
+ u64 rv64;
+
+ if (arch_get_slow_rng_u64()) {
+ mix_pool_bytes(r, , sizeof(rv64), NULL);
+ slow_rng_bits += 8 * sizeof(rv64);
+ }
+ }
+ if (slow_rng_bits)
+ pr_info("random: seeded %s pool with %d bits of arch slow rng
data\n",
+ r->name, slow_rng_bits);
}
/*
--
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/
[PATCH 2/4] random,x86: Add arch_get_slow_rng_u64
arch_get_slow_rng_u64 tries to get 64 bits of RNG seed data. Unlike
arch_get_random_{bytes,seed}, etc., it makes no claims about entropy
content. It's also likely to be much slower and should not be used
frequently. That being said, it should be fast enough to call
several times during boot without any noticeable slowdown.
This initial implementation backs it with MSR_KVM_GET_RNG_SEED if
available. The intent is for other hypervisor guest implementations
to implement this interface.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig | 4
arch/x86/include/asm/archslowrng.h | 30 ++
arch/x86/kernel/kvm.c | 22 ++
include/linux/random.h | 9 +
4 files changed, 65 insertions(+)
create mode 100644 arch/x86/include/asm/archslowrng.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8f749e..4dfb539 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -593,6 +593,7 @@ config KVM_GUEST
bool "KVM Guest support (including kvmclock)"
depends on PARAVIRT
select PARAVIRT_CLOCK
+ select ARCH_SLOW_RNG
default y
---help---
This option enables various optimizations for running under the KVM
@@ -627,6 +628,9 @@ config PARAVIRT_TIME_ACCOUNTING
config PARAVIRT_CLOCK
bool
+config ARCH_SLOW_RNG
+ bool
+
endif #HYPERVISOR_GUEST
config NO_BOOTMEM
diff --git a/arch/x86/include/asm/archslowrng.h
b/arch/x86/include/asm/archslowrng.h
new file mode 100644
index 000..c8e8d0d
--- /dev/null
+++ b/arch/x86/include/asm/archslowrng.h
@@ -0,0 +1,30 @@
+/*
+ * This file is part of the Linux kernel.
+ *
+ * Copyright (c) 2014 Andy Lutomirski
+ * Authors: Andy Lutomirski
+ *
+ * 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.
+ */
+
+#ifndef ASM_X86_ARCHSLOWRANDOM_H
+#define ASM_X86_ARCHSLOWRANDOM_H
+
+#ifndef CONFIG_ARCH_SLOW_RNG
+# error archslowrng.h should not be included if !CONFIG_ARCH_SLOW_RNG
+#endif
+
+/*
+ * Performance is irrelevant here, so there's no point in using the
+ * paravirt ops mechanism. Instead just use a function pointer.
+ */
+extern int (*arch_get_slow_rng_u64)(u64 *v);
+
+#endif /* ASM_X86_ARCHSLOWRANDOM_H */
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 3dd8e2c..8d64d28 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -416,6 +416,25 @@ void kvm_disable_steal_time(void)
wrmsr(MSR_KVM_STEAL_TIME, 0, 0);
}
+static int nop_get_slow_rng_u64(u64 *v)
+{
+ return 0;
+}
+
+static int kvm_get_slow_rng_u64(u64 *v)
+{
+ /*
+* Allow migration from a hypervisor with the GET_RNG_SEED
+* feature to a hypervisor without it.
+*/
+ if (rdmsrl_safe(MSR_KVM_GET_RNG_SEED, v) == 0)
+ return 1;
+ else
+ return 0;
+}
+
+int (*arch_get_slow_rng_u64)(u64 *v) = nop_get_slow_rng_u64;
+
#ifdef CONFIG_SMP
static void __init kvm_smp_prepare_boot_cpu(void)
{
@@ -493,6 +512,9 @@ void __init kvm_guest_init(void)
if (kvmclock_vsyscall)
kvm_setup_vsyscall_timeinfo();
+ if (kvm_para_has_feature(KVM_FEATURE_GET_RNG_SEED))
+ arch_get_slow_rng_u64 = kvm_get_slow_rng_u64;
+
#ifdef CONFIG_SMP
smp_ops.smp_prepare_boot_cpu = kvm_smp_prepare_boot_cpu;
register_cpu_notifier(_cpu_notifier);
diff --git a/include/linux/random.h b/include/linux/random.h
index 57fbbff..ceafbcf 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -106,6 +106,15 @@ static inline int arch_has_random_seed(void)
}
#endif
+#ifdef CONFIG_ARCH_SLOW_RNG
+# include
+#else
+static inline int arch_get_slow_rng_u64(u64 *v)
+{
+ return 0;
+}
+#endif
+
/* Pseudo random number generator from numerical recipes. */
static inline u32 next_pseudo_random32(u32 seed)
{
--
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/
[PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED
virtio-rng is both too complicated and insufficient for initial rng seeding. It's far too complicated to use for KASLR or any other early boot random number needs. It also provides /dev/random-style bits, which means that making guest boot wait for virtio-rng is unacceptably slow, and doing it asynchronously means that /dev/urandom might be predictable when userspace starts. This introduces a very simple synchronous mechanism to get /dev/urandom-style bits. This is a KVM change: am I supposed to write a unit test somewhere? Andy Lutomirski (4): x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit random,x86: Add arch_get_slow_rng_u64 random: Seed pools from arch_get_slow_rng_u64 at startup x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available Documentation/virtual/kvm/cpuid.txt | 3 +++ arch/x86/Kconfig | 4 arch/x86/boot/compressed/aslr.c | 27 +++ arch/x86/include/asm/archslowrng.h | 30 ++ arch/x86/include/uapi/asm/kvm_para.h | 2 ++ arch/x86/kernel/kvm.c| 22 ++ arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/x86.c | 4 drivers/char/random.c| 14 +- include/linux/random.h | 9 + 10 files changed, 116 insertions(+), 2 deletions(-) create mode 100644 arch/x86/include/asm/archslowrng.h -- 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/
[PATCH 1/4] x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit
This adds a simple interface to allow a guest to request 64 bits of
host nonblocking entropy. This is independent of virtio-rng for a
couple of reasons:
- It's intended to be usable during early boot, when a trivial
synchronous interface is needed.
- virtio-rng gives blocking entropy, and making guest boot wait for
the host's /dev/random will cause problems.
MSR_KVM_GET_RNG_SEED is intended to provide 64 bits of best-effort
cryptographically secure data for use as a seed. It provides no
guarantee that the result contains any actual entropy.
Signed-off-by: Andy Lutomirski
---
Documentation/virtual/kvm/cpuid.txt | 3 +++
arch/x86/include/uapi/asm/kvm_para.h | 2 ++
arch/x86/kvm/cpuid.c | 3 ++-
arch/x86/kvm/x86.c | 4
4 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/cpuid.txt
b/Documentation/virtual/kvm/cpuid.txt
index 3c65feb..0ab043b 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -54,6 +54,9 @@ KVM_FEATURE_PV_UNHALT || 7 || guest checks
this feature bit
|| || before enabling paravirtualized
|| || spinlock support.
--
+KVM_FEATURE_GET_RNG_SEED || 8 || host provides rng seed data via
+ || || MSR_KVM_GET_RNG_SEED.
+--
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side
|| || per-cpu warps are expected in
|| || kvmclock.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 94dc8ca..e2eaf93 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
#define KVM_FEATURE_STEAL_TIME 5
#define KVM_FEATURE_PV_EOI 6
#define KVM_FEATURE_PV_UNHALT 7
+#define KVM_FEATURE_GET_RNG_SEED 8
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
@@ -40,6 +41,7 @@
#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
#define MSR_KVM_STEAL_TIME 0x4b564d03
#define MSR_KVM_PV_EOI_EN 0x4b564d04
+#define MSR_KVM_GET_RNG_SEED 0x4b564d05
struct kvm_steal_time {
__u64 steal;
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 38a0afe..40d6763 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -479,7 +479,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function,
(1 << KVM_FEATURE_ASYNC_PF) |
(1 << KVM_FEATURE_PV_EOI) |
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
-(1 << KVM_FEATURE_PV_UNHALT);
+(1 << KVM_FEATURE_PV_UNHALT) |
+(1 << KVM_FEATURE_GET_RNG_SEED);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f644933..4e81853 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -2480,6 +2481,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr,
u64 *pdata)
case MSR_KVM_PV_EOI_EN:
data = vcpu->arch.pv_eoi.msr_val;
break;
+ case MSR_KVM_GET_RNG_SEED:
+ get_random_bytes(, sizeof(data));
+ break;
case MSR_IA32_P5_MC_ADDR:
case MSR_IA32_P5_MC_TYPE:
case MSR_IA32_MCG_CAP:
--
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/
[PATCH] staging: emxx_udc: Fix coding style errors
Only fixing errors reported by checkpatch.pl, based on the following
rules:
1. '*' should be adjacent to the data name or function name.
2. Don't use C99-style "// ..." comments.
Signed-off-by: KANG Yuxuan
---
drivers/staging/emxx_udc/emxx_udc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 0003463..b2eaf01 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -562,12 +562,12 @@ static void _nbu2ss_dma_unmap_single(
/*-*/
/* Endpoint 0 OUT Transfer (PIO) */
-static int EP0_out_PIO(struct nbu2ss_udc *udc, u8* pBuf, u32 length)
+static int EP0_out_PIO(struct nbu2ss_udc *udc, u8 *pBuf, u32 length)
{
u32 i;
int nret = 0;
u32 iWordLength = 0;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
/**/
/* Read Length */
@@ -588,12 +588,12 @@ static int EP0_out_PIO(struct nbu2ss_udc *udc, u8* pBuf,
u32 length)
/*-*/
/* Endpoint 0 OUT Transfer (PIO, OverBytes) */
-static int EP0_out_OverBytes(struct nbu2ss_udc *udc, u8* pBuf, u32 length)
+static int EP0_out_OverBytes(struct nbu2ss_udc *udc, u8 *pBuf, u32 length)
{
u32 i;
u32 iReadSize = 0;
USB_REG_ACCESS Temp32;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
if ((0 < length) && (length < sizeof(u32))) {
Temp32.dw = _nbu2ss_readl(>p_regs->EP0_READ);
@@ -613,7 +613,7 @@ static int EP0_in_PIO(struct nbu2ss_udc *udc, u8 *pBuf, u32
length)
u32 iMaxLength = EP0_PACKETSIZE;
u32 iWordLength = 0;
u32 iWriteLength = 0;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
/**/
/* Transfer Length */
@@ -639,7 +639,7 @@ static int EP0_in_OverBytes(struct nbu2ss_udc *udc, u8
*pBuf, u32 iRemainSize)
{
u32 i;
USB_REG_ACCESS Temp32;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
if ((0 < iRemainSize) && (iRemainSize < sizeof(u32))) {
for (i = 0 ; i < iRemainSize ; i++)
@@ -3339,7 +3339,7 @@ static int __init nbu2ss_drv_contest_init(
udc->gadget.ep0 = >ep[0].ep;
udc->gadget.speed = USB_SPEED_UNKNOWN;
udc->gadget.name = driver_name;
- //udc->gadget.is_dualspeed = 1;
+ /* udc->gadget.is_dualspeed = 1; */
device_initialize(>gadget.dev);
--
2.0.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 net-next] virtio-net: rx busy polling support
On 07/15/2014 06:21 PM, Eric Dumazet wrote: > On Tue, 2014-07-15 at 17:41 +0800, Jason Wang wrote: >> Add basic support for rx busy polling. >> >> 1 byte netperf tcp_rr on mlx4 shows 116% improvement: the transaction >> rate was increased from 9151.94 to 19787.37. > This is a misleading changelog. > > You forgot to describe how you allowed busy polling, as it is not > 'automatic' > > If not, this patch adds two spinlock/unlock pairs in fast path. Ok. > Also, it looks like you could split this in smaller patches. > > virtnet_napi_disable_all() & virtnet_napi_enable_all() could be added in > a separate patch for example. Sure, will split this patch into smaller ones in V2. 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/
Add device tree support to ISL12022 driver
Hi all,
The attached patch adds support for configuring the ISL12022 real-time clock
via the Device tree framework. This is based on what I've seen in the related
ISL12057 driver, it has been tested and works on a Technologic Systems TS-7670
device which uses a ISL12020 RTC device, my device tree looks like this:
apbx@8004 {
i2c0: i2c@80058000 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
clock-frequency = <40>;
status = "okay";
isl12022@0x6f {
compatible = "isl,isl12022";
reg = <0x6f>;
};
};
... etc
};
Regards,
Stuart Longland
--
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] drivers/rtc/rtc-isl12022.c: Device tree support
Add some support for configuring isl12020/isl12022 devices using the
Device Tree blob.
Signed-off-by: Stuart Longland
---
drivers/rtc/rtc-isl12022.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c
index 03b8911..aa55f08 100644
--- a/drivers/rtc/rtc-isl12022.c
+++ b/drivers/rtc/rtc-isl12022.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#define DRV_VERSION "0.1"
@@ -271,6 +273,13 @@ static int isl12022_probe(struct i2c_client *client,
return PTR_ERR_OR_ZERO(isl12022->rtc);
}
+#ifdef CONFIG_OF
+static struct of_device_id isl12022_dt_match[] = {
+ { .compatible = "isl,isl12022" },
+ { },
+};
+#endif
+
static const struct i2c_device_id isl12022_id[] = {
{ "isl12022", 0 },
{ }
@@ -280,6 +289,9 @@ MODULE_DEVICE_TABLE(i2c, isl12022_id);
static struct i2c_driver isl12022_driver = {
.driver = {
.name = "rtc-isl12022",
+#ifdef CONFIG_OF
+ .of_match_table = of_match_ptr(isl12022_dt_match),
+#endif
},
.probe = isl12022_probe,
.id_table = isl12022_id,
--
1.8.5.5
--
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/
Build Tests Advice
Hey Steven , I am finding it rather annoying that you aren't replying to my messages about succeeding builds. I am tried repeatedly to ask you to try a new compiler and or build system as all most of the failing builds succeed for me. It would be nice to get a reply in the next few days. Cheers Nick -- 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/1] scripts/get_maintainer: increase threshold for --follow to reduce time
ping?
On Sat, Jul 12, 2014 at 3:25 PM, Pranith Kumar wrote:
> get_maintainer tries to follow files with a matching threshold of default 50%.
> This is not really necessary as we do not change a file and move it in the
> same
> commit usually. Increasing the threshold to 90% should be sufficient.
>
> I encountered this on a recent commit where I was touching 12 files. Time take
> dropped from 24 sec to 12 sec after this change. It can be reduced further by
> increasing the threshold, but I think 90% is sufficient.
>
> Signed-off-by: Pranith Kumar
> ---
> scripts/get_maintainer.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index d701627..bc4a69e 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -98,7 +98,7 @@ my %VCS_cmds_git = (
> "execute_cmd" => \_execute_cmd,
> "available" => '(which("git") ne "") && (-e ".git")',
> "find_signers_cmd" =>
> - "git log --no-color --follow --since=\$email_git_since " .
> + "git log --no-color --follow -M90 --since=\$email_git_since " .
> '--numstat --no-merges ' .
> '--format="GitCommit: %H%n' .
> 'GitAuthor: %an <%ae>%n' .
> --
> 1.9.1
>
--
Pranith
--
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: emxx_udc: Fix coding style errors
On Wed, Jul 16, 2014 at 09:16:15AM +0800, Stone Kang wrote: > Only fixing errors reported by checkpatch.pl, based on the following > rules: > 1. '*' should be adjacent to the data name or function name. > 2. Don't use C99-style "// ..." comments. > > Signed-off-by: KANG Yuxuan I see two different names here, one in the "From:" line, and one in the Signed-off-by: line, are they the same? They need to match up :( Please resend with this fixed. 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 05/13] thermal: rcar: Document SoC-specific bindings
Hi
> > > The documentation only mentioned the generic fallback compatible property.
> > > Add the missing SoC-specific compatible properties, some of which are
> > > already in use.
> > >
> > > Signed-off-by: Geert Uytterhoeven
> > > Cc: Zhang Rui
> > > Cc: Eduardo Valentin
> > > Cc: linux...@vger.kernel.org
> >
> > Acked-by: Simon Horman
>
> Kuninori,
>
> what' your opinion of this patch?
>
> thanks,
> rui
> >
> > > ---
> > > .../devicetree/bindings/thermal/rcar-thermal.txt | 18
> > > --
> > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > index 28ef498a66e5..0ef00be44b01 100644
> > > --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > @@ -1,7 +1,13 @@
> > > * Renesas R-Car Thermal
> > >
> > > Required properties:
> > > -- compatible : "renesas,rcar-thermal"
> > > +- compatible : "renesas,thermal-",
> > > "renesas,rcar-thermal"
> > > + as fallback.
> > > + Examples with soctypes are:
> > > + - "renesas,thermal-r8a73a4" (R-Mobile AP6)
> > > + - "renesas,thermal-r8a7779" (R-Car H1)
> > > + - "renesas,thermal-r8a7790" (R-Car H2)
> > > + - "renesas,thermal-r8a7791" (R-Car M2)
> > > - reg: Address range of the thermal registers.
> > > The 1st reg will be recognized as common register
> > > if it has "interrupts".
> > > @@ -12,18 +18,18 @@ Option properties:
> > >
> > > Example (non interrupt support):
> > >
> > > -thermal@e61f0100 {
> > > - compatible = "renesas,rcar-thermal";
> > > - reg = <0xe61f0100 0x38>;
> > > +thermal@ffc48000 {
> > > + compatible = "renesas,thermal-r8a7779", "renesas,rcar-thermal";
> > > + reg = <0xffc48000 0x38>;
> > > };
> > >
> > > Example (interrupt support):
> > >
> > > thermal@e61f {
> > > - compatible = "renesas,rcar-thermal";
> > > + compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal";
> > > reg = <0xe61f 0x14
> > > 0xe61f0100 0x38
> > > 0xe61f0200 0x38
> > > 0xe61f0300 0x38>;
> > > - interrupts = <0 69 4>;
> > > + interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
> > > };
This patch and [12/13] are adding SoC-specific compatible name.
Of course we don't know future request,
and, adding SoC-specific compatible name for
fallbacking is nice safety for us.
So, I don't have strong objection about it.
But, thermal driver side do nothing for each
SoC-specific compatible name at this point.
This means
-> There is no trouble in driver/SoC
-> Add new (and not used) compatible name
-> Nothing happen in driver/SoC
My questions are...
1) How to verify this patch ?
2) Do we need to update example SoC "specific name" list in rcar-thermal.txt.
Few example codes are very enough ?
--
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/41] perf script: Improve srcline display for BTS
On 07/15/2014 08:16 AM, Arnaldo Carvalho de Melo wrote: Em Mon, Jul 14, 2014 at 01:02:39PM +0300, Adrian Hunter escreveu: Change the order of the output to put the srcline last. e.g. old format: 4028fc main+0x2c (/bin/ls) /build/buildd/coreutils-8.20/src/ls.c:1269 => 40d8a0 set_program_name+0x0 (/bin/ls) new format: 4028fc main+0x2c (/bin/ls) => 40d8a0 set_program_name+0x0 (/bin/ls) /build/buildd/coreutils-8.20/src/ls.c:1269 David, Can I have your acked-by? I believe Stephane is the one who wrote print_sample_bts and bts analysis pieces. David -- 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 v5 2/4] pwm: sirf: add dt-binding document
This patch adds dt-binding document for pwm-sirf. here the controller clock
can't generate PWM signals, so we need seperate clock as signal source.
Signed-off-by: Huayi Li
---
Documentation/devicetree/bindings/pwm/pwm-sirf.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sirf.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sirf.txt
b/Documentation/devicetree/bindings/pwm/pwm-sirf.txt
new file mode 100644
index 000..221e5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-sirf.txt
@@ -0,0 +1,29 @@
+SiRF prima2 & atlas6 PWM drivers
+
+Required properties:
+- compatible: "sirf,prima2-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+ the cells format.
+- clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/prima2-clock.txt for details.
+- clock-names: Must include the following entries:
+ of clock sources to generate PWM signal,
+ - pwmc: PWM controller clock
+ - sigsrc0: source clock 0 for PWM
+ - sigsrc1: source clock 1 for PWM
+ - sigsrc2: source clock 2 for PWM
+ - sigsrc3: source clock 3 for PWM
+ - sigsrc4: source clock 4 for PWM
+
+Example:
+
+pwm: pwm@b013 {
+ compatible = "sirf,prima2-pwm";
+ #pwm-cells = <2>;
+ reg = <0xb013 0x1>;
+ clocks = < 21>, < 1>, < 2>,
+ < 3>, < 0>, < 4>;
+ clock-names = "pwmc", "sigsrc0", "sigsrc1",
+ "sigsrc2", "sigsrc3", "sigsrc4";
+};
--
1.9.3
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.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/
linux-next: build warnings after merge of the ia64 tree
Hi all,
After merging the ia64 tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings (though presumably it started
yesterday):
In file included from include/ras/ras_event.h:11:0,
from drivers/ras/ras.c:13:
include/linux/aer.h:42:58: warning: 'struct pci_dev' declared inside parameter
list
static inline int pci_enable_pcie_error_reporting(struct pci_dev *dev)
^
include/linux/aer.h:42:58: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/aer.h:46:59: warning: 'struct pci_dev' declared inside parameter
list
static inline int pci_disable_pcie_error_reporting(struct pci_dev *dev)
^
include/linux/aer.h:50:65: warning: 'struct pci_dev' declared inside parameter
list
static inline int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
^
include/linux/aer.h:57:14: warning: 'struct pci_dev' declared inside parameter
list
struct aer_capability_regs *aer);
^
Introduced by commit 76ac8275f296 ("trace, RAS: Add basic RAS trace
event") and following patches.
So, presumably, aer.h either needs to include pci.h or, at least, have a
struct pci_dev;
line in it.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Hit bug with script/checkpatch.pl
Hi,
I hit a bug when run script/checkpatch.pl to my patch, It
reported a error with following
macro definition, but in fact the macro is correct, I couldn't change
that macro according to
the error message output by script/checkpatch.pl. because of this bug,
my patch was rejected by some guy's patchwork.
./scripts/checkpatch.pl netxen.patch
ERROR: Macros with complex values should be enclosed in parenthesis
#38: FILE: drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c:45:
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
ERROR: Macros with complex values should be enclosed in parenthesis
#42: FILE: drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c:49:
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
total: 2 errors, 0 warnings, 62 lines checked
netxen.patch has style problems, please review.
If any of these errors are false positives, please report
Please check and fix it.
Thanks,
Ethan
--following is the patch
hit the bug
From: Ethan Zhao
netxen driver has implemented netxen_nic_get_ethtool_stats() interface,
but it doesn't collect stats.rxdropped in driver, so we will get
different rx_dropped statistic information while using ifconfig and ethtool.
this patch fills stats.rxdropped field with data from net core
with dev_get_stats() just as ixgbe driver did for some of its stats.
V2: only fix the stats.rxdropped field.
Tested with last netxen 4.0.82
Compiled with net-next branch 3.16-rc2
Signed-off-by: Ethan Zhao
Tested-by: Sriharsha Yadagudde
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c| 34 +---
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 4ca2c19..49e6a1b 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -33,22 +33,30 @@
#include "netxen_nic.h"
#include "netxen_nic_hw.h"
+enum {NETDEV_STATS, NETXEN_STATS};
+
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
+ int type;
int sizeof_stat;
int stat_offset;
};
-#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_adapter *)0)->m), \
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
+
#define NETXEN_NIC_PORT_WINDOW 0x1
#define NETXEN_NIC_INVALID_DATA 0xDEADBEEF
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
{"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
{"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
- {"rx_dropped", NETXEN_NIC_STAT(stats.rxdropped)},
+ {"rx_dropped", NETXEN_NETDEV_STAT(rx_dropped)},
{"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
{"csummed", NETXEN_NIC_STAT(stats.csummed)},
{"rx_pkts", NETXEN_NIC_STAT(stats.rx_pkts)},
@@ -679,11 +687,27 @@ netxen_nic_get_ethtool_stats(struct net_device *dev,
{
struct netxen_adapter *adapter = netdev_priv(dev);
int index;
+ struct rtnl_link_stats64 temp;
+ const struct rtnl_link_stats64 *net_stats;
+ char *p = NULL;
+ net_stats = dev_get_stats(dev, );
for (index = 0; index < NETXEN_NIC_STATS_LEN; index++) {
- char *p =
- (char *)adapter +
- netxen_nic_gstrings_stats[index].stat_offset;
+
+ switch (netxen_nic_gstrings_stats[index].type) {
+ case NETDEV_STATS:
+ p = (char *)net_stats +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ case NETXEN_STATS:
+ p = (char *)adapter +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ default:
+ data[index] = 0;
+ continue;
+ }
+
data[index] =
(netxen_nic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *) p : *(u32 *) p;
-- 1.7.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/
3.16-rcX crashes on resume from Suspend-To-RAM
My Dell M4400 has been pretty well-supported by Linux a couple of years now, but recent 3.16-rcX cause hard crashes when resuming from Suspend-to-RAM. This is tricky to debug, as device drivers are not yet restored by the time that the crash happens. So, I can't use Page-UP to scroll the screen and see the full crash information. I also cannot use the netconsole; the ethernet device is still suspended. For similar reasons, crash kernels don't seem to work either. After about a day of false starts and a lengthy bi-secting session, I finally narrowed things down to this change list: eec15edbb0e14485998635ea7c62e30911b465f0 is the first bad commit commit eec15edbb0e14485998635ea7c62e30911b465f0 Author: Zhang Rui Date: Fri May 30 04:23:01 2014 +0200 ACPI / PNP: use device ID list for PNPACPI device enumeration ACPI can be used to enumerate PNP devices, but the code does not handle this in the right way currently. Namely, if an ACPI device object 1. Has a _CRS method, 2. Has an identification of "three capital characters followed by four hex digits", 3. Is not in the excluded IDs list, it will be enumerated to PNP bus (that is, a PNP device object will be create for it). This means that, actually, the PNP bus type is used as the default bus type for enumerating _HID devices in ACPI. However, more and more _HID devices need to be enumerated to the platform bus instead (that is, platform device objects need to be created for them). As a result, the device ID list in acpi_platform.c is used to enforce creating platform device objects rather than PNP device objects for matching devices. That list has been continuously growing recently, unfortunately, and it is pretty much guaranteed to grow even more in the future. To address that problem it is better to enumerate _HID devices as platform devices by default. To this end, change the way of enumerating PNP devices by adding a PNP ACPI scan handler that will use a device ID list to create PNP devices for the ACPI device objects whose device IDs are present in that list. The initial device ID list in the PNP ACPI scan handler contains all of the pnp_device_id strings from all the existing PNP drivers, so this change should be transparent to the PNP core and all of the PNP drivers. Still, in the future it should be possible to reduce its size by converting PNP drivers that need not be PNP for any technical reasons into platform drivers. Signed-off-by: Zhang Rui [rjw: Rewrote the changelog, modified the PNP ACPI scan handler code] Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg :04 04 b7c07232aa46ae7b6faf9a907fb7274a02e4680fc2e05b31a61dccd087c554adecc89a43a1ed81f7 M drivers :04 04 4eda970292fffbeebe167f9210502527df4e8ab421e9e6fd84c780a34bf3d48b5e7618b551da3b1a M include I took a photo of the crash. It feels silly to do, but I couldn't think of a better solution. You can find it at https://drive.google.com/file/d/0B8SxqKDe4hyheTlTLXY2YThkMXM As I mentioned earlier, a bunch of information has already scrolled off the screen, but hopefully what is visible is somewhat helpful. I will have only limited internet access the next couple of weeks. But I wanted to make sure I at least got the result of the bisection out to LKML. I will make every best effort to collect additional data, if asked to do so; but some of it might be delayed for a little bit, until I can get access to reasonably powerful hardware or reasonably fast internet. Markus P.S.: Please keep me cc'd on all responses, as I am not subscribed to the firehose that is LKML. -- 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/1] rcu: Remove redundant checks for rcu_scheduler_fully_active
rcu_scheduler_fully_active is set to true early in the boot process.
rcu_prepare_kthreads() is called in two locations. Once after setting the above
flag and the other while hotplugging a CPU from rcu_cpu_notify(). CPU hotplug is
enabled much later by which time the above flag is already set. Hence checking
for this flag is redundant in this function.
The checks in rcu_spawn_one_boost_kthread() and rcu_spawn_all_nocb_kthreads()
are similarly redundant.
This commit removes the redundant checks for this flag from the above
locations.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 17ccb62..a2113f6 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1341,7 +1341,7 @@ static int rcu_spawn_one_boost_kthread(struct rcu_state
*rsp,
if (_preempt_state != rsp)
return 0;
- if (!rcu_scheduler_fully_active || rnp->qsmaskinit == 0)
+ if (rnp->qsmaskinit == 0)
return 0;
rsp->boost = 1;
@@ -1489,8 +1489,7 @@ static void rcu_prepare_kthreads(int cpu)
struct rcu_node *rnp = rdp->mynode;
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
- if (rcu_scheduler_fully_active)
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
#else /* #ifdef CONFIG_RCU_BOOST */
@@ -2509,9 +2508,8 @@ static void rcu_spawn_all_nocb_kthreads(int cpu)
{
struct rcu_state *rsp;
- if (rcu_scheduler_fully_active)
- for_each_rcu_flavor(rsp)
- rcu_spawn_one_nocb_kthread(rsp, cpu);
+ for_each_rcu_flavor(rsp)
+ rcu_spawn_one_nocb_kthread(rsp, cpu);
}
/*
--
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 v2 24/29] nios2: Module support
On Tue, Jul 15, 2014 at 8:21 PM, Arnd Bergmann wrote: >> >> AFAIR this is due to relocation issues, as the FIXME comment in the >> "original" code [1] states. I don't know whether this still applies, >> though (or what would be the proper fix for this to overcome the >> relocation issues). >> >> [1] >> https://github.com/tklauser/linux-nios2/blob/nios2/arch/nios2/kernel/module.c#L45 >> > > Ah, I see. Please at least copy over that comment then. Will copy over the comment. > > A long-term solution would be to copy what ARM does, since that > has the same problem. The modules are allocated with > __vmalloc_node_range, passing a virtual address range that > is just before the kernel virtual address, taken out of the > top 16MB of the user space addresses. Noted, will investigate this for long-term solution. Thanks. Regards Ley Foon -- 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 24/29] nios2: Module support
On Tue, Jul 15, 2014 at 6:24 PM, Arnd Bergmann wrote:
> On Tuesday 15 July 2014 16:45:51 Ley Foon Tan wrote:
>
>> +void module_arch_cleanup(struct module *mod)
>> +{
>> +}
>
> This is not needed at all.
>
Okay, will remove this.
--
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/
Power-managing devices that are not of interest at some point in time
(Re-sending with correct mailing list addresses.) Hi, When the lid of a laptop is closed, certain devices can no longer provide interesting input or will even produce bogus input, such as: - input devices: touchscreen, touchpad, keyboard - sensors: ambient light sensor, accelerometer, magnetometer - a video camera mounted on the lid - display backlight Various workarounds cover some of these cases, and we have some ugly hacks in ChromeOS to make things work. It would be nice if a userspace power management daemon could listen to the lid-close event, and then have a way to temporarily power off these devices, potentially through sysfs. I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes. There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation. It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state. Rafael, can you give us your opinion on this? Kind regards, Patrik -- 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/1 V2] workqueue: unfold start_worker() into create_worker()
On 07/14/2014 12:05 PM, Lai Jiangshan wrote:
> Simply unfold the code of start_worker() into create_worker() and
> remove the original start_worker() and create_and_start_worker().
>
> The only trade-off is the introduced overhead that the pool->lock
> is released and re-grabbed after the newly worker is started.
> The overhead is acceptable since the manager is slow path.
Hi, TJ
Will you accept this trade-off and the patch?
If so, I will rebase this patch without any dependence on other patch.
Thanks,
Lai
>
> And because this new locking behavior, the newly created worker
> may grab the lock earlier than the manager and go to process
> work items. In this case, the need_to_create_worker() may be
> true as expected and the manager goes to restart without complaint.
>
> Signed-off-by: Lai Jiangshan
> ---
> kernel/workqueue.c | 69
> ++--
> 1 files changed, 13 insertions(+), 56 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 2b3c12c..5b68527 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1553,7 +1553,7 @@ static void worker_enter_idle(struct worker *worker)
>(worker->hentry.next || worker->hentry.pprev)))
> return;
>
> - /* can't use worker_set_flags(), also called from start_worker() */
> + /* can't use worker_set_flags(), also called from create_worker() */
> worker->flags |= WORKER_IDLE;
> pool->nr_idle++;
> worker->last_active = jiffies;
> @@ -1674,8 +1674,7 @@ static void worker_detach_from_pool(struct worker
> *worker,
> * create_worker - create a new workqueue worker
> * @pool: pool the new worker will belong to
> *
> - * Create a new worker which is attached to @pool. The new worker must be
> - * started by start_worker().
> + * Create and start a new worker which is attached to @pool.
> *
> * CONTEXT:
> * Might sleep. Does GFP_KERNEL allocations.
> @@ -1720,6 +1719,13 @@ static struct worker *create_worker(struct worker_pool
> *pool)
> /* successful, attach the worker to the pool */
> worker_attach_to_pool(worker, pool);
>
> + /* start the newly created worker */
> + spin_lock_irq(>lock);
> + worker->pool->nr_workers++;
> + worker_enter_idle(worker);
> + wake_up_process(worker->task);
> + spin_unlock_irq(>lock);
> +
> return worker;
>
> fail:
> @@ -1730,44 +1736,6 @@ fail:
> }
>
> /**
> - * start_worker - start a newly created worker
> - * @worker: worker to start
> - *
> - * Make the pool aware of @worker and start it.
> - *
> - * CONTEXT:
> - * spin_lock_irq(pool->lock).
> - */
> -static void start_worker(struct worker *worker)
> -{
> - worker->pool->nr_workers++;
> - worker_enter_idle(worker);
> - wake_up_process(worker->task);
> -}
> -
> -/**
> - * create_and_start_worker - create and start a worker for a pool
> - * @pool: the target pool
> - *
> - * Grab the managership of @pool and create and start a new worker for it.
> - *
> - * Return: 0 on success. A negative error code otherwise.
> - */
> -static int create_and_start_worker(struct worker_pool *pool)
> -{
> - struct worker *worker;
> -
> - worker = create_worker(pool);
> - if (worker) {
> - spin_lock_irq(>lock);
> - start_worker(worker);
> - spin_unlock_irq(>lock);
> - }
> -
> - return worker ? 0 : -ENOMEM;
> -}
> -
> -/**
> * destroy_worker - destroy a workqueue worker
> * @worker: worker to be destroyed
> *
> @@ -1905,18 +1873,7 @@ restart:
> mod_timer(>mayday_timer, jiffies + MAYDAY_INITIAL_TIMEOUT);
>
> while (true) {
> - struct worker *worker;
> -
> - worker = create_worker(pool);
> - if (worker) {
> - spin_lock_irq(>lock);
> - start_worker(worker);
> - if (WARN_ON_ONCE(need_to_create_worker(pool)))
> - goto restart;
> - return true;
> - }
> -
> - if (!need_to_create_worker(pool))
> + if (create_worker(pool) || !need_to_create_worker(pool))
> break;
>
> schedule_timeout_interruptible(CREATE_COOLDOWN);
> @@ -3543,7 +3500,7 @@ static struct worker_pool *get_unbound_pool(const
> struct workqueue_attrs *attrs)
> goto fail;
>
> /* create and start the initial worker */
> - if (create_and_start_worker(pool) < 0)
> + if (!create_worker(pool))
> goto fail;
>
> /* install */
> @@ -4617,7 +4574,7 @@ static int workqueue_cpu_up_callback(struct
> notifier_block *nfb,
> for_each_cpu_worker_pool(pool, cpu) {
> if (pool->nr_workers)
> continue;
> - if (create_and_start_worker(pool) < 0)
> + if (!create_worker(pool))
>
Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings
On 7/13/2014 4:43 AM, Rob Clark wrote: > On Sun, Jul 13, 2014 at 5:43 AM, Will Deacon wrote: >> On Sat, Jul 12, 2014 at 01:57:31PM +0100, Rob Clark wrote: >>> On Sat, Jul 12, 2014 at 8:22 AM, Arnd Bergmann wrote: On Saturday 12 July 2014, Rob Clark wrote: >>> Was there actually a good reason for having the device link to the >>> iommu rather than the other way around? How much would people hate it >>> if I just ignore the generic bindings and use something that works for >>> me instead. I mean, it isn't exactly like there is going to be .dts >>> re-use across different SoC's.. and at least with current IOMMU API >>> some sort of of_get_named_iommu() API doesn't really make sense. >> >> The thing is, if you end up ignoring the generic binding then we have two >> IOMMUs using the same (ARM SMMU) binding and it begs the question as to >> which is the more generic! I know we're keen to get this merged, but >> merging >> something that people won't use and calling it generic doesn't seem ideal >> either. We do, however, desperately need a generic binding. > > yeah, ignoring the generic binding is not my first choice. I'd rather > have something that works well for everyone. But I wasn't really sure > if the current proposal was arbitrary, or if there are some > conflicting requirements between different platforms. The common case that needs to be simple is attaching one (master) device to an IOMMU using the shared global context for the purposes of implementing the dma-mapping API. >>> >>> well, I don't disagree that IOMMU API has some problems. It is too >>> tied to the bus type, which doesn't really seem to make sense for >>> platform devices. (Unless we start having multiple platform busses?) >>> >>> But at least given the current IOMMU API I'm not really sure how it >>> makes a difference which way the link goes. But if there has already >>> been some discussion about how you want to handle the tie in with >>> dma-mapping, if you could point me at that then maybe your point will >>> make more sense to me. >> >> If you look at the proposed binding in isolation, I think it *is* cleaner >> than the ARM SMMU binding (I've acked it...) and I believe it's more >> consistent with the way we describe linkages elsewhere. >> >> However, the issue you're raising is that it's more difficult to make use of >> in a Linux IOMMU driver. The reward you'll get for using it will come >> eventually when the DMA ops are automatically swizzled for devices using the >> generic binding. >> >> My plan for the ARM SMMU driver is: >> >> (1) Change ->probe() to walk the device-tree looking for all masters with >> phandles back to the SMMU instance being probed >> >> (2) For each master, extract the Stream IDs and add them to the internal >> SMMU driver data structures (an rbtree per SMMU instance). For >> hotpluggable buses, we'll need a way for the bus controller to >> reserve a range of IDs -- this will likely be a later extension to >> the binding. >> >> (3) When we get an ->add() call, warn if it's a device we haven't seen >> and reject the addition. >> >> That way, ->attach() should be the same as it is now, I think. >> >> Have you tried implementing something like that? We agreed that (1) isn't >> pretty, but I don't have a good alternative and it's only done at >> probe-time. > > I haven't tried implementing that yet, but I'm sure it would work. I > was just hoping to avoid having to do that ;-) Is the reason you want to do it this way because you want to guarantee that all masters (and stream IDs) have been identified before the first attach call? I am just wondering why you cannot continue doing the master/streamID discovery during add_device() callback? >> >> BTW: Is the msm-v0 IOMMU compatible with the ARM SMMU driver, or is it a >> completely different design requiring a different driver? > > My understanding is that it is different from msm v1 IOMMU, although I > think it shares the same pagetable format with v1. Not sure if that > is the same as arm-smmu? If so it might be nice to try to extract > out some shared helper fxns for map/unmap as well. > > I expect Olav knows better the similarities/differences. > The msm-v0 IOMMU is not compatible with ARM SMMUv1 specification. However, it is a close cousin. The hardware was designed before the ARM SMMUv1 specification was available I believe. But it shares many of the same concepts as the ARM SMMUv1. msm-v0 IOMMU supports V7S page table format only. The ARM SMMU driver does not support V7S at this time. However, I believe we need to support this. Will, this reminds me. We definitely have a need to use different page tables in the ARM SMMU driver vs. the ARM CPU. We have an SoC with ARMv8 cores (and thus ARMv8 page tables) but the SMMUs (SMMUv1) on this SoC only have support for V7S/V7L page table format. So
Re: [PATCH 1/1 V2] workqueue: remove the del_timer_sync()s in maybe_create_worker()
On 07/15/2014 05:42 AM, Thomas Gleixner wrote: > On Tue, 15 Jul 2014, Lai Jiangshan wrote: >> On 07/14/2014 11:33 PM, Thomas Gleixner wrote: >>> On Mon, 14 Jul 2014, Tejun Heo wrote: >>> Hello, On Mon, Jul 14, 2014 at 04:13:21PM +0800, Lai Jiangshan wrote: > It is said in the document that the timer which is being > deleted by del_timer_sync() should not be restarted: > Synchronization rules: Callers must prevent restarting of > the timer, otherwise this function is meaningless. > > Repeating timer may cause the del_timer_sync() spin longer, > or even spin forever in very very very very extreme condition. I'm fairly sure del_timer_sync() can delete self-requeueing timers. The implementation busy-waits if the queued timer is the currently executing one and dequeues only while the timer isn't running which should be able to handle self-requeueing ones just fine. Thomas, del_timer_sync() can reliably delete self-requeueing ones, right? >>> >>> Yes. >> >> The comments of the del_timer_sync() needs to be updated >> if I did not misunderstood? >> >>> If the timer callback is running on the other cpu, then it waits >>> for the callback to finish before checking whether the timer is >>> enqueued or not. >> >> The syncer may be interrupted here, after it comes back, the timer >> may be running again (and maybe again and again). > > No. The del_timer_sync() code holds the base lock with interrupts > disabled. So it can't be interrupted. > The del_timer_sync() waits via cpu_relax() without interrupts disabled. Could you wipe out my concern? > > . > -- 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] mm, tmp: only collapse hugepages to nodes with affinity for zone_reclaim_mode
On 07/16/2014 08:13 AM, David Rientjes wrote:
> Commit 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target
> node") improved the previous khugepaged logic which allocated a
> transparent hugepages from the node of the first page being collapsed.
>
> However, it is still possible to collapse pages to remote memory which may
> suffer from additional access latency. With the current policy, it is
> possible that 255 pages (with PAGE_SHIFT == 12) will be collapsed remotely
> if the majority are allocated from that node.
>
> When zone_reclaim_mode is enabled, it means the VM should make every attempt
> to allocate locally to prevent NUMA performance degradation. In this case,
> we do not want to collapse hugepages to remote nodes that would suffer from
> increased access latency. Thus, when zone_reclaim_mode is enabled, only
> allow collapsing to nodes with RECLAIM_DISTANCE or less.
>
> There is no functional change for systems that disable zone_reclaim_mode.
>
> Signed-off-by: David Rientjes
> ---
> v2: only change behavior for zone_reclaim_mode per Dave Hansen
>
> mm/huge_memory.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2234,6 +2234,26 @@ static void khugepaged_alloc_sleep(void)
> static int khugepaged_node_load[MAX_NUMNODES];
>
> #ifdef CONFIG_NUMA
> +static bool khugepaged_scan_abort(int nid)
> +{
> + int i;
> +
> + /*
> + * If zone_reclaim_mode is disabled, then no extra effort is made to
> + * allocate memory locally.
> + */
> + if (!zone_reclaim_mode)
> + return false;
> +
> + for (i = 0; i < MAX_NUMNODES; i++) {
> + if (!khugepaged_node_load[i])
> + continue;
> + if (node_distance(nid, i) > RECLAIM_DISTANCE)
> + return true;
> + }
> + return false;
> +}
> +
> static int khugepaged_find_target_node(void)
> {
> static int last_khugepaged_target_node = NUMA_NO_NODE;
> @@ -2309,6 +2329,11 @@ static struct page
> return *hpage;
> }
> #else
> +static bool khugepaged_scan_abort(int nid)
> +{
> + return false;
> +}
> +
> static int khugepaged_find_target_node(void)
> {
> return 0;
> @@ -2515,6 +2540,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> unsigned long _address;
> spinlock_t *ptl;
> int node = NUMA_NO_NODE;
> + int last_node = node;
>
> VM_BUG_ON(address & ~HPAGE_PMD_MASK);
>
> @@ -2545,6 +2571,11 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
>* hit record.
>*/
> node = page_to_nid(page);
> + if (node != last_node) {
> + if (khugepaged_scan_abort(node))
> + goto out_unmap;
Nitpick: How about not break the loop but only reset the related
khugepaged_node_load[] to zero. E.g. modify khugepaged_scan_abort() like
this:
if (node_distance(nid, i) > RECLAIM_DISTANCE)
khugepaged_node_load[i] = 0;
By this way, we may have a chance to find a more suitable node.
> + last_node = node;
> + }
> khugepaged_node_load[node]++;
> VM_BUG_ON_PAGE(PageCompound(page), page);
> if (!PageLRU(page) || PageLocked(page) || !PageAnon(page))
>
--
Regards,
-Bob
--
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 00/29] nios2 Linux kernel port
On Tue, Jul 15, 2014 at 7:15 PM, Tobias Klauser wrote: > Hi Ley Foon > > Ah, thanks for the notice. Is it still possible to use the old syscall > ABI as a replacement on top of this series and use the current toolchain > from Mentor Graphics? Hi Tobias There are other changes in the nios2 kernel that requires new compiler. So, old syscall ABI replacement most probably won't work. Regards Ley Foon -- 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 V9 1/2] Serial: allow port drivers to have a default attribute group
From: Greg Kroah-Hartman
Some serial drivers (like 8250), want to add sysfs files. We need to do
so in a race-free way, so allow any port to be able to specify an
attribute group that should be added at device creation time.
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Yoshihiro YUNOMAE
---
drivers/tty/serial/serial_core.c | 24 +---
include/linux/serial_core.h |2 ++
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index fbf6c5a..4af764c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2563,12 +2563,6 @@ static const struct attribute_group tty_dev_attr_group =
{
.attrs = tty_dev_attrs,
};
-static const struct attribute_group *tty_dev_attr_groups[] = {
- _dev_attr_group,
- NULL
- };
-
-
/**
* uart_add_one_port - attach a driver-defined port structure
* @drv: pointer to the uart low level driver structure for this port
@@ -2585,6 +2579,7 @@ int uart_add_one_port(struct uart_driver *drv, struct
uart_port *uport)
struct tty_port *port;
int ret = 0;
struct device *tty_dev;
+ int num_groups;
BUG_ON(in_interrupt());
@@ -2618,12 +2613,26 @@ int uart_add_one_port(struct uart_driver *drv, struct
uart_port *uport)
uart_configure_port(drv, state, uport);
+ num_groups = 2;
+ if (uport->attr_group)
+ num_groups++;
+
+ uport->tty_groups = kcalloc(num_groups, sizeof(**uport->tty_groups),
+ GFP_KERNEL);
+ if (!uport->tty_groups) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ uport->tty_groups[0] = _dev_attr_group;
+ if (uport->attr_group)
+ uport->tty_groups[1] = uport->attr_group;
+
/*
* Register the port whether it's detected or not. This allows
* setserial to be used to alter this port's parameters.
*/
tty_dev = tty_port_register_device_attr(port, drv->tty_driver,
- uport->line, uport->dev, port, tty_dev_attr_groups);
+ uport->line, uport->dev, port, uport->tty_groups);
if (likely(!IS_ERR(tty_dev))) {
device_set_wakeup_capable(tty_dev, 1);
} else {
@@ -2702,6 +2711,7 @@ int uart_remove_one_port(struct uart_driver *drv, struct
uart_port *uport)
*/
if (uport->type != PORT_UNKNOWN)
uport->ops->release_port(uport);
+ kfree(uport->tty_groups);
/*
* Indicate that there isn't a port here anymore.
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5bbb809..cf3a1e7 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -199,6 +199,8 @@ struct uart_port {
unsigned char suspended;
unsigned char irq_wake;
unsigned char unused[2];
+ struct attribute_group *attr_group;/* port specific
attributes */
+ const struct attribute_group **tty_groups; /* all attributes
(serial core use only) */
void*private_data; /* generic platform
data pointer */
};
--
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 V9 2/2] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers
Add tunable RX interrupt trigger I/F of FIFO buffers. Serial devices are used as not only message communication devices but control or sending communication devices. For the latter uses, normally small data will be exchanged, so user applications want to receive data unit as soon as possible for real-time tendency. If we have a sensor which sends a 1 byte data each time and must control a device based on the sensor feedback, the RX interrupt should be triggered for each data. According to HW specification of serial UART devices, RX interrupt trigger can be changed, but the trigger is hard-coded. For example, RX interrupt trigger in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets the trigger to only 8bytes. This patch makes some devices change RX interrupt trigger from userland. - Read current setting # cat /sys/class/tty/ttyS0/rx_trig_bytes 8 - Write user setting # echo 1 > /sys/class/tty/ttyS0/rx_trig_bytes # cat /sys/class/tty/ttyS0/rx_trig_bytes 1 - 16550A and Tegra (1, 4, 8, or 14 bytes) - 16650V2 (8, 16, 24, or 28 bytes) - 16654 (8, 16, 56, or 60 bytes) - 16750 (1, 16, 32, or 56 bytes) Changes in V9: - Use attr_group instead of dev_spec_attr_group of uart_port structure Changes in V8: - Divide this patch from V7's patch based on Greg's comment Changes in V7: - Add Documentation - Change I/F name from rx_int_trig to rx_trig_bytes because the name rx_int_trig is hard to understand how users specify the value Changes in V6: - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h, rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to UART_FCR_R_TRIG_BITS() - Change following function names: convert_fcr2val() => fcr_get_rxtrig_bytes() convert_val2rxtrig() => bytes_to_fcr_rxtrig() - Fix typo in serial8250_do_set_termios() - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig() - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables (but UI remains rx_int_trig) - Change the meaningless variable name 'val' to 'bytes' following functions: fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(), do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig() - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in fcr_get_rxtrig_bytes() - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check in register_dev_spec_attr_grp() - Delete the checking whether a user changed FCR or not when minimum buffer is needed in serial8250_do_set_termios() Changes in V5.1: - Fix FCR_RX_TRIG_MAX_STATE definition Changes in V5: - Support Tegra, 16650V2, 16654, and 16750 - Store default FCR value to up->fcr when the port is first created - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[] in convert_fcr2val() and convert_val2rxtrig() Changes in V4: - Introduce fifo_bug flag in uart_8250_port structure This is enabled only when parity is enabled and UART_BUG_PARITY is enabled for up->bugs. If this flag is enabled, user cannot set RX trigger. - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and at convert_val2rxtrig() - Set the nearest lower RX trigger when users input a meaningless value at convert_val2rxtrig() - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos() - Set fcr = up->fcr in the begging of serial8250_do_set_termios() Changes in V3: - Change I/F from ioctl(2) to sysfs(rx_int_trig) Changed in V2: - Use _IOW for TIOCSFIFORTRIG definition - Pass the interrupt trigger value itself Signed-off-by: Yoshihiro YUNOMAE --- Documentation/ABI/testing/sysfs-tty | 16 +++ drivers/tty/serial/8250/8250.h |2 drivers/tty/serial/8250/8250_core.c | 173 --- include/linux/serial_8250.h |2 include/uapi/linux/serial_reg.h |5 + 5 files changed, 183 insertions(+), 15 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty index ad22fb0..9eb3c2b 100644 --- a/Documentation/ABI/testing/sysfs-tty +++ b/Documentation/ABI/testing/sysfs-tty @@ -138,3 +138,19 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/rx_trig_bytes +Date: May 2014 +Contact: Yoshihiro YUNOMAE +Description: +Shows current RX interrupt trigger bytes or sets the +user specified value to change it for the FIFO buffer. +Users can show or set this value regardless of opening the +serial device file or not. + +The RX trigger can be set one of four kinds of values for UART +serials. When users input a meaning less value to this I/F, +the RX trigger is changed to the nearest lower value for the +device
[ PATCH V9 0/2] serial/uart/8250: Introduce tunable RX trigger I/F
Hi Greg, This patch set introduces tunable RX interrupt trigger I/F for 8250 serials. I used Greg's patch(*1) as 1st patch in this version, and applied 2nd patch of previous version. Would you review this patch set? Thanks! Note: I cleaned up Greg's patch as follows: - Delete extra line break - Use kcalloc instead of kmalloc - sizeof(struct attribute_group *) => sizeof(**uport->tty_groups) *1: https://lkml.org/lkml/2014/7/12/177 Changes in V9: [2/2] - Use attr_group instead of dev_spec_attr_group of uart_port structure Changes in V8: - Split V7's patch up into 2 patches Changes in V7: - Add Documentation - Change I/F name from rx_int_trig to rx_trig_bytes because the name rx_int_trig is hard to understand how users specify the value Changes in V6: - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h, rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to UART_FCR_R_TRIG_BITS() - Change following function names: convert_fcr2val() => fcr_get_rxtrig_bytes() convert_val2rxtrig() => bytes_to_fcr_rxtrig() - Fix typo in serial8250_do_set_termios() - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig() - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables (but UI remains rx_int_trig) - Change the meaningless variable name 'val' to 'bytes' following functions: fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(), do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig() - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in fcr_get_rxtrig_bytes() - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check in register_dev_spec_attr_grp() - Delete the checking whether a user changed FCR or not when minimum buffer is needed in serial8250_do_set_termios() Changes in V5.1: - Fix FCR_RX_TRIG_MAX_STATE definition Changes in V5: - Support Tegra, 16650V2, 16654, and 16750 - Store default FCR value to up->fcr when the port is first created - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[] in convert_fcr2val() and convert_val2rxtrig() Changes in V4: - Introduce fifo_bug flag in uart_8250_port structure This is enabled only when parity is enabled and UART_BUG_PARITY is enabled for up->bugs. If this flag is enabled, user cannot set RX trigger. - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and at convert_val2rxtrig() - Set the nearest lower RX trigger when users input a meaningless value at convert_val2rxtrig() - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos() - Set fcr = up->fcr in the begging of serial8250_do_set_termios() Changes in V3: - Change I/F from ioctl(2) to sysfs(rx_int_trig) Changed in V2: - Use _IOW for TIOCSFIFORTRIG definition - Pass the interrupt trigger value itself --- Greg Kroah-Hartman (1): Serial: allow port drivers to have a default attribute group Yoshihiro YUNOMAE (1): serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers Documentation/ABI/testing/sysfs-tty | 16 +++ drivers/tty/serial/8250/8250.h |2 drivers/tty/serial/8250/8250_core.c | 173 --- drivers/tty/serial/serial_core.c| 24 +++-- include/linux/serial_8250.h |2 include/linux/serial_core.h |2 include/uapi/linux/serial_reg.h |5 + 7 files changed, 202 insertions(+), 22 deletions(-) -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.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/
[PATCH] staging: emxx_udc: Fix coding style errors
Only fixing errors reported by checkpatch.pl, based on the following
rules:
1. '*' should be adjacent to the data name or function name.
2. Don't use C99-style "// ..." comments.
Signed-off-by: KANG Yuxuan
---
drivers/staging/emxx_udc/emxx_udc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 0003463..b2eaf01 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -562,12 +562,12 @@ static void _nbu2ss_dma_unmap_single(
/*-*/
/* Endpoint 0 OUT Transfer (PIO) */
-static int EP0_out_PIO(struct nbu2ss_udc *udc, u8* pBuf, u32 length)
+static int EP0_out_PIO(struct nbu2ss_udc *udc, u8 *pBuf, u32 length)
{
u32 i;
int nret = 0;
u32 iWordLength = 0;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
/**/
/* Read Length */
@@ -588,12 +588,12 @@ static int EP0_out_PIO(struct nbu2ss_udc *udc, u8* pBuf,
u32 length)
/*-*/
/* Endpoint 0 OUT Transfer (PIO, OverBytes) */
-static int EP0_out_OverBytes(struct nbu2ss_udc *udc, u8* pBuf, u32 length)
+static int EP0_out_OverBytes(struct nbu2ss_udc *udc, u8 *pBuf, u32 length)
{
u32 i;
u32 iReadSize = 0;
USB_REG_ACCESS Temp32;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
if ((0 < length) && (length < sizeof(u32))) {
Temp32.dw = _nbu2ss_readl(>p_regs->EP0_READ);
@@ -613,7 +613,7 @@ static int EP0_in_PIO(struct nbu2ss_udc *udc, u8 *pBuf, u32
length)
u32 iMaxLength = EP0_PACKETSIZE;
u32 iWordLength = 0;
u32 iWriteLength = 0;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
/**/
/* Transfer Length */
@@ -639,7 +639,7 @@ static int EP0_in_OverBytes(struct nbu2ss_udc *udc, u8
*pBuf, u32 iRemainSize)
{
u32 i;
USB_REG_ACCESS Temp32;
- USB_REG_ACCESS* pBuf32 = (USB_REG_ACCESS *)pBuf;
+ USB_REG_ACCESS *pBuf32 = (USB_REG_ACCESS *)pBuf;
if ((0 < iRemainSize) && (iRemainSize < sizeof(u32))) {
for (i = 0 ; i < iRemainSize ; i++)
@@ -3339,7 +3339,7 @@ static int __init nbu2ss_drv_contest_init(
udc->gadget.ep0 = >ep[0].ep;
udc->gadget.speed = USB_SPEED_UNKNOWN;
udc->gadget.name = driver_name;
- //udc->gadget.is_dualspeed = 1;
+ /* udc->gadget.is_dualspeed = 1; */
device_initialize(>gadget.dev);
--
2.0.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/
