Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
- tristate "Freescale Elo and Elo Plus DMA support"
+ tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
- chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+ chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+ { .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
- pr_info("Freescale Elo / Elo Plus DMA driver\n");
+ pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs; /* DGSR register base */
--
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 v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed
Howdy Seiji,
I failed appily this patch to both 3.12-rc2 and 3.12-rc4. Could you
please let me know which is the right tree for this patch?
Thanks,
Madper.
seiji.agu...@hds.com writes:
> Change from v2:
> - Move dynamic memory allocation to efi_pstore_read() before holding
> efivars->lock to protect entry->var.Data.
> - Access to entry->scanning while holding efivars->lock.
> - Move a comment about a returned value from efi_pstore_read_func() to
> efi_pstore_read() because "size < 0" case may happen in efi_pstore_read().
>
> Currently, when mounting pstore file system, a read callback of efi_pstore
> driver runs mutiple times as below.
>
> - In the first read callback, scan efivar_sysfs_list from head and pass
> a kmsg buffer of a entry to an upper pstore layer.
> - In the second read callback, rescan efivar_sysfs_list from the entry and
> pass
> another kmsg buffer to it.
> - Repeat the scan and pass until the end of efivar_sysfs_list.
>
> In this process, an entry is read across the multiple read function calls.
> To avoid race between the read and erasion, the whole process above is
> protected by a spinlock, holding in open() and releasing in close().
>
> At the same time, kmemdup() is called to pass the buffer to pstore filesystem
> during it.
> And then, it causes a following lockdep warning.
>
> To make the dynamic memory allocation runnable without taking spinlock,
> holding off a deletion of sysfs entry if it happens while scanning it
> via efi_pstore, and deleting it after the scan is completed.
>
> To implement it, this patch introduces two flags, scanning and deleting,
> to efivar_entry.
>
> [1.143710] [ cut here ]
> [1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740
> lockdep_trace_alloc+0x104/0x110()
> [1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [1.144058] Modules linked in:
>
> [1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
> [1.144058] 0009 8800797e9ae0 816614a5
> 8800797e9b28
> [1.144058] 8800797e9b18 8105510d 0080
> 0046
> [1.144058] 00d0 03af 81ccd0c0
> 8800797e9b78
> [1.144058] Call Trace:
> [1.144058] [] dump_stack+0x54/0x74
> [1.144058] [] warn_slowpath_common+0x7d/0xa0
> [1.144058] [] warn_slowpath_fmt+0x4c/0x50
> [1.144058] [] ? vsscanf+0x57f/0x7b0
> [1.144058] [] lockdep_trace_alloc+0x104/0x110
> [1.144058] [] __kmalloc_track_caller+0x50/0x280
> [1.144058] [] ?
> efi_pstore_read_func.part.1+0x12b/0x170
> [1.144058] [] kmemdup+0x20/0x50
> [1.144058] [] efi_pstore_read_func.part.1+0x12b/0x170
> [1.144058] [] ?
> efi_pstore_read_func.part.1+0x170/0x170
> [1.144058] [] efi_pstore_read_func+0xb4/0xe0
> [1.144058] [] __efivar_entry_iter+0xfb/0x120
> [1.144058] [] efi_pstore_read+0x3f/0x50
> [1.144058] [] pstore_get_records+0x9a/0x150
> [1.158207] [] ? selinux_d_instantiate+0x1c/0x20
> [1.158207] [] ? parse_options+0x80/0x80
> [1.158207] [] pstore_fill_super+0xa5/0xc0
> [1.158207] [] mount_single+0xa2/0xd0
> [1.158207] [] pstore_mount+0x18/0x20
> [1.158207] [] mount_fs+0x39/0x1b0
> [1.158207] [] ? __alloc_percpu+0x10/0x20
> [1.158207] [] vfs_kern_mount+0x63/0xf0
> [1.158207] [] do_mount+0x23e/0xa20
> [1.158207] [] ? strndup_user+0x4b/0xf0
> [1.158207] [] SyS_mount+0x83/0xc0
> [1.158207] [] system_call_fastpath+0x16/0x1b
> [1.158207] ---[ end trace 61981bc62de9f6f4 ]---
>
> Signed-off-by: Seiji Aguchi
> ---
> drivers/firmware/efi/efi-pstore.c | 143
> +++---
> drivers/firmware/efi/efivars.c| 12 ++--
> drivers/firmware/efi/vars.c | 12 +++-
> include/linux/efi.h | 2 +
> 4 files changed, 153 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi-pstore.c
> b/drivers/firmware/efi/efi-pstore.c
> index 5002d50..ebd5dbc 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -18,14 +18,12 @@ module_param_named(pstore_disable,
> efivars_pstore_disable, bool, 0644);
>
> static int efi_pstore_open(struct pstore_info *psi)
> {
> - efivar_entry_iter_begin();
> psi->data = NULL;
> return 0;
> }
>
> static int efi_pstore_close(struct pstore_info *psi)
> {
> - efivar_entry_iter_end();
> psi->data = NULL;
> return 0;
> }
> @@ -91,19 +89,125 @@ static int efi_pstore_read_func(struct efivar_entry
> *entry, void *data)
> __efivar_entry_get(entry, >var.Attributes,
> >var.DataSize, entry->var.Data);
> size = entry->var.DataSize;
> + memcpy(*cb_data->buf, entry->var.Data, (size_t)min_t(unsigned long,
> + 1024, size));
>
> - *cb_data->buf = kmemdup(entry->var.Data, size, GFP_KERNEL);
> -
Re: [PATCH] ARM: bcm_defconfig: Run "make savedefconfig"
On Mon, Oct 14, 2013 at 2:41 PM, Tim Kryger wrote: > Several of the options in bcm_defconfig have gotten out of date so > regenerate it with "make savedefconfig" to keep things fresh. > > Signed-off-by: Tim Kryger > Reviewed-by: Matt Porter > --- > arch/arm/configs/bcm_defconfig | 10 ++ > 1 file changed, 2 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig > index efb0132..3a138af 100644 > --- a/arch/arm/configs/bcm_defconfig > +++ b/arch/arm/configs/bcm_defconfig > @@ -1,4 +1,3 @@ > -CONFIG_EXPERIMENTAL=y > # CONFIG_LOCALVERSION_AUTO is not set > # CONFIG_SWAP is not set > CONFIG_SYSVIPC=y > @@ -25,11 +24,8 @@ CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_BLK_DEV_BSG is not set > CONFIG_PARTITION_ADVANCED=y > -CONFIG_EFI_PARTITION=y > CONFIG_ARCH_BCM=y > -CONFIG_ARCH_BCM_MOBILE=y > CONFIG_ARM_THUMBEE=y > -CONFIG_ARM_ERRATA_743622=y > CONFIG_PREEMPT=y > CONFIG_AEABI=y > # CONFIG_OABI_COMPAT is not set > @@ -51,7 +47,6 @@ CONFIG_UNIX_DIAG=y > CONFIG_NET_KEY=y > CONFIG_INET=y > CONFIG_IP_MULTICAST=y > -CONFIG_ARPD=y > CONFIG_SYN_COOKIES=y > CONFIG_TCP_MD5SIG=y > CONFIG_IPV6=y > @@ -96,7 +91,6 @@ CONFIG_MMC_UNSAFE_RESUME=y > CONFIG_MMC_BLOCK_MINORS=32 > CONFIG_MMC_TEST=y > CONFIG_MMC_SDHCI=y > -CONFIG_MMC_SDHCI_PLTFM=y > CONFIG_MMC_SDHCI_BCM_KONA=y > CONFIG_NEW_LEDS=y > CONFIG_LEDS_CLASS=y > @@ -118,12 +112,12 @@ CONFIG_CONFIGFS_FS=y > CONFIG_NLS_CODEPAGE_437=y > CONFIG_NLS_ISO8859_1=y > CONFIG_PRINTK_TIME=y > -CONFIG_MAGIC_SYSRQ=y > +CONFIG_DEBUG_INFO=y > CONFIG_DEBUG_FS=y > +CONFIG_MAGIC_SYSRQ=y > CONFIG_DETECT_HUNG_TASK=y > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=110 > CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y > -CONFIG_DEBUG_INFO=y > # CONFIG_FTRACE is not set > CONFIG_CRC_CCITT=y > CONFIG_CRC_T10DIF=y > -- Reviewed-by: Christian Daudt Applied to armsoc/for-3.13/soc thanks, csd -- 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 v2 2/6] ARM: dts: Specify clocks for UARTs on bcm11351
On Wed, Oct 16, 2013 at 2:47 PM, Tim Kryger wrote: > Rather than declaring the frequency of the external clock, specify the > label of the clock such that the driver may determine the frequency on > its own. > > Signed-off-by: Tim Kryger > Reviewed-by: Markus Mayer > Reviewed-by: Matt Porter > --- > arch/arm/boot/dts/bcm11351.dtsi | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi > index c6464fb..ce65367 100644 > --- a/arch/arm/boot/dts/bcm11351.dtsi > +++ b/arch/arm/boot/dts/bcm11351.dtsi > @@ -43,7 +43,7 @@ > compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; > status = "disabled"; > reg = <0x3e00 0x1000>; > - clock-frequency = <1300>; > + clocks = <_clk>; > interrupts = ; > reg-shift = <2>; > reg-io-width = <4>; Hi Sebastian, this patch series (and a subsequent one from Tim) both rely on your "ARM: provide common arch init for DT clocks" patchset in order to work. Will that patchset be in 3.13 ? I don't want to pull the dt mods unless they are as they break the boot without them. Thanks, csd -- 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 v3 2/9] ipv6: split inet6_ehashfn to hash functions per compilation unit
This patch splits the inet6_ehashfn into separate ones in
ipv6/inet6_hashtables.o and ipv6/udp.o to ease the introduction of
seperate secrets keys later.
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
include/net/inet6_hashtables.h | 28 +++-
include/net/ipv6.h | 4 ++--
net/ipv6/inet6_hashtables.c| 24
net/ipv6/udp.c | 20
4 files changed, 49 insertions(+), 27 deletions(-)
diff --git a/include/net/inet6_hashtables.h b/include/net/inet6_hashtables.h
index a105d1a..ae06135 100644
--- a/include/net/inet6_hashtables.h
+++ b/include/net/inet6_hashtables.h
@@ -28,28 +28,14 @@
struct inet_hashinfo;
-static inline unsigned int inet6_ehashfn(struct net *net,
- const struct in6_addr *laddr, const u16 lport,
- const struct in6_addr *faddr, const __be16
fport)
+static inline unsigned int __inet6_ehashfn(const u32 lhash,
+ const u16 lport,
+ const u32 fhash,
+ const __be16 fport,
+ const u32 initval)
{
- u32 ports = (((u32)lport) << 16) | (__force u32)fport;
-
- return jhash_3words((__force u32)laddr->s6_addr32[3],
- ipv6_addr_jhash(faddr),
- ports,
- inet_ehash_secret + net_hash_mix(net));
-}
-
-static inline int inet6_sk_ehashfn(const struct sock *sk)
-{
- const struct inet_sock *inet = inet_sk(sk);
- const struct in6_addr *laddr = >sk_v6_rcv_saddr;
- const struct in6_addr *faddr = >sk_v6_daddr;
- const __u16 lport = inet->inet_num;
- const __be16 fport = inet->inet_dport;
- struct net *net = sock_net(sk);
-
- return inet6_ehashfn(net, laddr, lport, faddr, fport);
+ const u32 ports = (((u32)lport) << 16) | (__force u32)fport;
+ return jhash_3words(lhash, fhash, ports, initval);
}
int __inet6_hash(struct sock *sk, struct inet_timewait_sock *twp);
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index fe1c7f6..a35055f 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -539,14 +539,14 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a)
}
/* more secured version of ipv6_addr_hash() */
-static inline u32 ipv6_addr_jhash(const struct in6_addr *a)
+static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32
initval)
{
u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1];
return jhash_3words(v,
(__force u32)a->s6_addr32[2],
(__force u32)a->s6_addr32[3],
- ipv6_hash_secret);
+ initval);
}
static inline bool ipv6_addr_loopback(const struct in6_addr *a)
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 842d833..fa7dd38 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -23,6 +23,30 @@
#include
#include
+static unsigned int inet6_ehashfn(struct net *net,
+ const struct in6_addr *laddr,
+ const u16 lport,
+ const struct in6_addr *faddr,
+ const __be16 fport)
+{
+ const u32 lhash = (__force u32)laddr->s6_addr32[3];
+ const u32 fhash = __ipv6_addr_jhash(faddr, ipv6_hash_secret);
+ return __inet6_ehashfn(lhash, lport, fhash, fport,
+ inet_ehash_secret + net_hash_mix(net));
+}
+
+static int inet6_sk_ehashfn(const struct sock *sk)
+{
+ const struct inet_sock *inet = inet_sk(sk);
+ const struct in6_addr *laddr = >sk_v6_rcv_saddr;
+ const struct in6_addr *faddr = >sk_v6_daddr;
+ const __u16 lport = inet->inet_num;
+ const __be16 fport = inet->inet_dport;
+ struct net *net = sock_net(sk);
+
+ return inet6_ehashfn(net, laddr, lport, faddr, fport);
+}
+
int __inet6_hash(struct sock *sk, struct inet_timewait_sock *tw)
{
struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index b496de1..324bd36 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -53,6 +53,18 @@
#include
#include "udp_impl.h"
+static unsigned int udp6_ehashfn(struct net *net,
+ const struct in6_addr *laddr,
+ const u16 lport,
+ const struct in6_addr *faddr,
+ const __be16 fport)
+{
+ const u32 lhash = (__force u32)laddr->s6_addr32[3];
+ const u32 fhash = __ipv6_addr_jhash(faddr, ipv6_hash_secret);
+ return __inet6_ehashfn(lhash, lport, fhash, fport,
+ inet_ehash_secret + net_hash_mix(net));
+}
+
int
[PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called
Based on a patch from Andi Kleen.
Cc: Steven Rostedt
Cc: Peter Zijlstra
Cc: Andi Kleen
Signed-off-by: Hannes Frederic Sowa
---
include/linux/jump_label.h | 10 ++
include/linux/jump_label_ratelimit.h | 2 ++
init/main.c | 7 +++
kernel/jump_label.c | 5 +
4 files changed, 24 insertions(+)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a507907..e96be72 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -48,6 +48,13 @@
#include
#include
+#include
+
+extern bool static_key_initialized;
+
+#define STATIC_KEY_CHECK_USE() WARN(!static_key_initialized, \
+ "%s used before call to jump_label_init", \
+ __func__)
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
@@ -128,6 +135,7 @@ struct static_key {
static __always_inline void jump_label_init(void)
{
+ static_key_initialized = true;
}
static __always_inline bool static_key_false(struct static_key *key)
@@ -146,11 +154,13 @@ static __always_inline bool static_key_true(struct
static_key *key)
static inline void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_inc(>enabled);
}
static inline void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_dec(>enabled);
}
diff --git a/include/linux/jump_label_ratelimit.h
b/include/linux/jump_label_ratelimit.h
index 1137883..089f70f 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -23,12 +23,14 @@ struct static_key_deferred {
};
static inline void static_key_slow_dec_deferred(struct static_key_deferred
*key)
{
+ STATIC_KEY_CHECK_USE();
static_key_slow_dec(>key);
}
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
}
#endif /* HAVE_JUMP_LABEL */
#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/init/main.c b/init/main.c
index af310af..27bbec1a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -136,6 +136,13 @@ static char *execute_command;
static char *ramdisk_execute_command;
/*
+ * Used to generate warnings if static_key manipulation functions are used
+ * before jump_label_init is called.
+ */
+bool static_key_initialized __read_mostly = false;
+EXPORT_SYMBOL_GPL(static_key_initialized);
+
+/*
* If set, this is an indication to the drivers that reset the underlying
* device before going ahead with the initialization otherwise driver might
* rely on the BIOS and skip the reset operation.
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 297a924..9019f15 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -58,6 +58,7 @@ static void jump_label_update(struct static_key *key, int
enable);
void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
if (atomic_inc_not_zero(>enabled))
return;
@@ -103,12 +104,14 @@ static void jump_label_update_timeout(struct work_struct
*work)
void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(key, 0, NULL);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec);
void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(>key, key->timeout, >work);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
@@ -116,6 +119,7 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
void jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
key->timeout = rl;
INIT_DELAYED_WORK(>work, jump_label_update_timeout);
}
@@ -212,6 +216,7 @@ void __init jump_label_init(void)
key->next = NULL;
#endif
}
+ static_key_initialized = true;
jump_label_unlock();
}
--
1.8.3.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 net-next v3 4/9] x86/jump_label: expect default_nop if static_key gets enabled on boot-up
net_get_random_once(intrduced in the next patch) uses static_keys in
a way that they get enabled on boot-up instead of replaced with an
ideal_nop. So check for default_nop on initial enabling.
Other architectures don't check for this.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Steven Rostedt
Cc: Jason Baron
Cc: Peter Zijlstra
Cc: Eric Dumazet
Cc: "David S. Miller"
Cc: x...@kernel.org
Signed-off-by: Hannes Frederic Sowa
---
arch/x86/kernel/jump_label.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
index ee11b7d..26d5a55 100644
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -42,15 +42,27 @@ static void __jump_label_transform(struct jump_entry *entry,
int init)
{
union jump_code_union code;
+ const unsigned char default_nop[] = { STATIC_KEY_INIT_NOP };
const unsigned char *ideal_nop = ideal_nops[NOP_ATOMIC5];
if (type == JUMP_LABEL_ENABLE) {
- /*
-* We are enabling this jump label. If it is not a nop
-* then something must have gone wrong.
-*/
- if (unlikely(memcmp((void *)entry->code, ideal_nop, 5) != 0))
- bug_at((void *)entry->code, __LINE__);
+ if (init) {
+ /*
+* Jump label is enabled for the first time.
+* So we expect a default_nop...
+*/
+ if (unlikely(memcmp((void *)entry->code, default_nop, 5)
+!= 0))
+ bug_at((void *)entry->code, __LINE__);
+ } else {
+ /*
+* ...otherwise expect an ideal_nop. Otherwise
+* something went horribly wrong.
+*/
+ if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
+!= 0))
+ bug_at((void *)entry->code, __LINE__);
+ }
code.jump = 0xe9;
code.offset = entry->target -
@@ -63,7 +75,6 @@ static void __jump_label_transform(struct jump_entry *entry,
* are converting the default nop to the ideal nop.
*/
if (init) {
- const unsigned char default_nop[] = {
STATIC_KEY_INIT_NOP };
if (unlikely(memcmp((void *)entry->code, default_nop,
5) != 0))
bug_at((void *)entry->code, __LINE__);
} else {
--
1.8.3.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 net-next v3 9/9] net: switch net_secret key generation to net_get_random_once
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
net/core/secure_seq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
index 3f1ec15..b02fd16 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
@@ -16,18 +17,7 @@ static u32 net_secret[NET_SECRET_SIZE] cacheline_aligned;
static void net_secret_init(void)
{
- u32 tmp;
- int i;
-
- if (likely(net_secret[0]))
- return;
-
- for (i = NET_SECRET_SIZE; i > 0;) {
- do {
- get_random_bytes(, sizeof(tmp));
- } while (!tmp);
- cmpxchg(_secret[--i], 0, tmp);
- }
+ net_get_random_once(net_secret, sizeof(net_secret));
}
#ifdef CONFIG_INET
--
1.8.3.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 net-next v3 6/9] inet: split syncookie keys for ipv4 and ipv6 and initialize with net_get_random_once
This patch splits the secret key for syncookies for ipv4 and ipv6 and
initializes them with net_get_random_once. This change was the reason I
did this series. I think the initialization of the syncookie_secret is
way to early.
Cc: Florian Westphal
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
include/net/tcp.h | 1 -
net/ipv4/syncookies.c | 15 +--
net/ipv6/syncookies.c | 12 +---
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1db3a01..0fa8fdc 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -475,7 +475,6 @@ int tcp_send_rcvq(struct sock *sk, struct msghdr *msg,
size_t size);
void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb);
/* From syncookies.c */
-extern __u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
int __cookie_v4_check(const struct iphdr *iph, const struct tcphdr *th,
u32 cookie);
struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 3b64c59..b95331e 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -25,15 +25,7 @@
extern int sysctl_tcp_syncookies;
-__u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
-EXPORT_SYMBOL(syncookie_secret);
-
-static __init int init_syncookies(void)
-{
- get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
- return 0;
-}
-__initcall(init_syncookies);
+static u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
#define COOKIEBITS 24 /* Upper bits store count */
#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
@@ -44,8 +36,11 @@ static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS],
static u32 cookie_hash(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport,
u32 count, int c)
{
- __u32 *tmp = __get_cpu_var(ipv4_cookie_scratch);
+ __u32 *tmp;
+
+ net_get_random_once(syncookie_secret, sizeof(syncookie_secret));
+ tmp = __get_cpu_var(ipv4_cookie_scratch);
memcpy(tmp + 4, syncookie_secret[c], sizeof(syncookie_secret[c]));
tmp[0] = (__force u32)saddr;
tmp[1] = (__force u32)daddr;
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index d04d3f1..535a3ad 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -24,6 +24,8 @@
#define COOKIEBITS 24 /* Upper bits store count */
#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
+static u32 syncookie6_secret[2][16-4+SHA_DIGEST_WORDS];
+
/* RFC 2460, Section 8.3:
* [ipv6 tcp] MSS must be computed as the maximum packet size minus 60 [..]
*
@@ -61,14 +63,18 @@ static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS],
static u32 cookie_hash(const struct in6_addr *saddr, const struct in6_addr
*daddr,
__be16 sport, __be16 dport, u32 count, int c)
{
- __u32 *tmp = __get_cpu_var(ipv6_cookie_scratch);
+ __u32 *tmp;
+
+ net_get_random_once(syncookie6_secret, sizeof(syncookie6_secret));
+
+ tmp = __get_cpu_var(ipv6_cookie_scratch);
/*
* we have 320 bits of information to hash, copy in the remaining
-* 192 bits required for sha_transform, from the syncookie_secret
+* 192 bits required for sha_transform, from the syncookie6_secret
* and overwrite the digest with the secret
*/
- memcpy(tmp + 10, syncookie_secret[c], 44);
+ memcpy(tmp + 10, syncookie6_secret[c], 44);
memcpy(tmp, saddr, 16);
memcpy(tmp + 4, daddr, 16);
tmp[8] = ((__force u32)sport << 16) + (__force u32)dport;
--
1.8.3.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 net-next v3 0/9] Introduce support to lazy initialize mostly static keys
Hi! This series implements support for delaying the initialization of secret keys, e.g. used for hashing, for as long as possible. This functionality is implemented by a new macro, net_get_random_bytes. I already used it to protect the socket hashes, the syncookie secret (most important) and the tcp_fastopen secrets. Changelog: v2) Use static_keys in net_get_random_once to have as minimal impact to the fast-path as possible. v3) added patch "static_key: WARN on usage before jump_label_init was called": Patch "x86/jump_label: expect default_nop if static_key gets enabled on boot-up" relaxes the checks for using static_key primitives before jump_label_init. So tighten them first. Included patches: ipv4: split inet_ehashfn to hash functions per compilation unit ipv6: split inet6_ehashfn to hash functions per compilation unit static_key: WARN on usage before jump_label_init was called x86/jump_label: expect default_nop if static_key gets enabled on boot-up net: introduce new macro net_get_random_once inet: split syncookie keys for ipv4 and ipv6 and initialize with net_get_random_once inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once tcp: switch tcp_fastopen key generation to net_get_random_once net: switch net_secret key generation to net_get_random_once Diffstat: arch/x86/kernel/jump_label.c | 25 ++--- include/linux/jump_label.h | 10 ++ include/linux/jump_label_ratelimit.h | 2 ++ include/linux/net.h | 25 + include/net/inet6_hashtables.h | 28 +++- include/net/inet_sock.h | 26 ++ include/net/ipv6.h | 4 ++-- include/net/tcp.h| 3 +-- init/main.c | 7 +++ kernel/jump_label.c | 5 + net/core/secure_seq.c| 14 ++ net/core/utils.c | 48 net/ipv4/af_inet.c | 27 --- net/ipv4/inet_hashtables.c | 25 + net/ipv4/syncookies.c| 15 +-- net/ipv4/sysctl_net_ipv4.c | 5 + net/ipv4/tcp_fastopen.c | 27 --- net/ipv4/udp.c | 20 net/ipv6/af_inet6.c | 5 - net/ipv6/inet6_hashtables.c | 33 + net/ipv6/syncookies.c| 12 +--- net/ipv6/udp.c | 31 +++ net/rds/connection.c | 12 +--- 23 files changed, 278 insertions(+), 131 deletions(-) Greetings, Hannes -- 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 v3 1/9] ipv4: split inet_ehashfn to hash functions per compilation unit
This duplicates a bit of code but let's us easily introduce
separate secret keys later. The separate compilation units are
ipv4/inet_hashtabbles.o, ipv4/udp.o and rds/connection.o.
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
include/net/inet_sock.h| 22 ++
net/ipv4/inet_hashtables.c | 21 +
net/ipv4/udp.c | 16
net/rds/connection.c | 6 +++---
4 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 06da91e..7a6c7f8 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -208,26 +208,16 @@ extern u32 inet_ehash_secret;
extern u32 ipv6_hash_secret;
void build_ehash_secret(void);
-static inline unsigned int inet_ehashfn(struct net *net,
- const __be32 laddr, const __u16 lport,
- const __be32 faddr, const __be16 fport)
+static inline unsigned int __inet_ehashfn(const __be32 laddr,
+ const __u16 lport,
+ const __be32 faddr,
+ const __be16 fport,
+ u32 initval)
{
return jhash_3words((__force __u32) laddr,
(__force __u32) faddr,
((__u32) lport) << 16 | (__force __u32)fport,
- inet_ehash_secret + net_hash_mix(net));
-}
-
-static inline int inet_sk_ehashfn(const struct sock *sk)
-{
- const struct inet_sock *inet = inet_sk(sk);
- const __be32 laddr = inet->inet_rcv_saddr;
- const __u16 lport = inet->inet_num;
- const __be32 faddr = inet->inet_daddr;
- const __be16 fport = inet->inet_dport;
- struct net *net = sock_net(sk);
-
- return inet_ehashfn(net, laddr, lport, faddr, fport);
+ initval);
}
static inline struct request_sock *inet_reqsk_alloc(struct request_sock_ops
*ops)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index a4b66bb..18aa668 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -24,6 +24,27 @@
#include
#include
+static unsigned int inet_ehashfn(struct net *net, const __be32 laddr,
+const __u16 lport, const __be32 faddr,
+const __be16 fport)
+{
+ return __inet_ehashfn(laddr, lport, faddr, fport,
+ inet_ehash_secret + net_hash_mix(net));
+}
+
+
+static unsigned int inet_sk_ehashfn(const struct sock *sk)
+{
+ const struct inet_sock *inet = inet_sk(sk);
+ const __be32 laddr = inet->inet_rcv_saddr;
+ const __u16 lport = inet->inet_num;
+ const __be32 faddr = inet->inet_daddr;
+ const __be16 fport = inet->inet_dport;
+ struct net *net = sock_net(sk);
+
+ return inet_ehashfn(net, laddr, lport, faddr, fport);
+}
+
/*
* Allocate and initialize a new local port bind bucket.
* The bindhash mutex for snum's hash chain must be held here.
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 9f27bb8..b4437c7 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -407,6 +407,14 @@ static inline int compute_score2(struct sock *sk, struct
net *net,
return score;
}
+static unsigned int udp_ehashfn(struct net *net, const __be32 laddr,
+const __u16 lport, const __be32 faddr,
+const __be16 fport)
+{
+ return __inet_ehashfn(laddr, lport, faddr, fport,
+ inet_ehash_secret + net_hash_mix(net));
+}
+
/* called with read_rcu_lock() */
static struct sock *udp4_lib_lookup2(struct net *net,
@@ -430,8 +438,8 @@ begin:
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
- hash = inet_ehashfn(net, daddr, hnum,
- saddr, sport);
+ hash = udp_ehashfn(net, daddr, hnum,
+ saddr, sport);
matches = 1;
}
} else if (score == badness && reuseport) {
@@ -511,8 +519,8 @@ begin:
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
- hash = inet_ehashfn(net, daddr, hnum,
- saddr, sport);
+ hash = udp_ehashfn(net, daddr, hnum,
+ saddr, sport);
matches = 1;
}
} else if (score == badness && reuseport) {
diff --git a/net/rds/connection.c
[PATCH net-next v3 8/9] tcp: switch tcp_fastopen key generation to net_get_random_once
Changed key initialization of tcp_fastopen cookies to net_get_random_once.
If the user sets a custom key net_get_random_once must be called at
least once to ensure we don't overwrite the user provided key when the
first cookie is generated later on.
Cc: Yuchung Cheng
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
include/net/tcp.h | 2 +-
net/ipv4/sysctl_net_ipv4.c | 5 +
net/ipv4/tcp_fastopen.c| 27 ---
3 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 0fa8fdc..027b663 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1322,7 +1322,7 @@ extern struct tcp_fastopen_context __rcu
*tcp_fastopen_ctx;
int tcp_fastopen_reset_cipher(void *key, unsigned int len);
void tcp_fastopen_cookie_gen(__be32 src, __be32 dst,
struct tcp_fastopen_cookie *foc);
-
+void tcp_fastopen_init_key_once(bool publish);
#define TCP_FASTOPEN_KEY_LENGTH 16
/* Fastopen key context */
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index c08f096..4b161d5 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -274,6 +274,11 @@ static int proc_tcp_fastopen_key(struct ctl_table *ctl,
int write,
ret = -EINVAL;
goto bad_key;
}
+ /* Generate a dummy secret but don't publish it. This
+* is needed so we don't regenerate a new key on the
+* first invocation of tcp_fastopen_cookie_gen
+*/
+ tcp_fastopen_init_key_once(false);
tcp_fastopen_reset_cipher(user_key, TCP_FASTOPEN_KEY_LENGTH);
}
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index ab7bd35..766032b 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -14,6 +14,20 @@ struct tcp_fastopen_context __rcu *tcp_fastopen_ctx;
static DEFINE_SPINLOCK(tcp_fastopen_ctx_lock);
+void tcp_fastopen_init_key_once(bool publish)
+{
+ static u8 key[TCP_FASTOPEN_KEY_LENGTH];
+
+ /* tcp_fastopen_reset_cipher publishes the new context
+* atomically, so we allow this race happening here.
+*
+* All call sites of tcp_fastopen_cookie_gen also check
+* for a valid cookie, so this is an acceptable risk.
+*/
+ if (net_get_random_once(key, sizeof(key)) && publish)
+ tcp_fastopen_reset_cipher(key, sizeof(key));
+}
+
static void tcp_fastopen_ctx_free(struct rcu_head *head)
{
struct tcp_fastopen_context *ctx =
@@ -70,6 +84,8 @@ void tcp_fastopen_cookie_gen(__be32 src, __be32 dst,
__be32 path[4] = { src, dst, 0, 0 };
struct tcp_fastopen_context *ctx;
+ tcp_fastopen_init_key_once(true);
+
rcu_read_lock();
ctx = rcu_dereference(tcp_fastopen_ctx);
if (ctx) {
@@ -78,14 +94,3 @@ void tcp_fastopen_cookie_gen(__be32 src, __be32 dst,
}
rcu_read_unlock();
}
-
-static int __init tcp_fastopen_init(void)
-{
- __u8 key[TCP_FASTOPEN_KEY_LENGTH];
-
- get_random_bytes(key, sizeof(key));
- tcp_fastopen_reset_cipher(key, sizeof(key));
- return 0;
-}
-
-late_initcall(tcp_fastopen_init);
--
1.8.3.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 net-next v3 7/9] inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once
Initialize the ehash and ipv6_hash_secrets with net_get_random_once.
Each compilation unit gets its own secret now:
ipv4/inet_hashtables.o
ipv4/udp.o
ipv6/inet6_hashtables.o
ipv6/udp.o
rds/connection.o
The functions still get inlined into the hashing functions. In the fast
path we have at most two (needed in ipv6) if (unlikely(...)).
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
include/net/inet_sock.h | 4
net/ipv4/af_inet.c | 27 ---
net/ipv4/inet_hashtables.c | 4
net/ipv4/udp.c | 6 +-
net/ipv6/af_inet6.c | 5 -
net/ipv6/inet6_hashtables.c | 15 ---
net/ipv6/udp.c | 17 ++---
net/rds/connection.c| 12 +---
8 files changed, 44 insertions(+), 46 deletions(-)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 7a6c7f8..1833c3f 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -204,10 +204,6 @@ static inline void inet_sk_copy_descendant(struct sock
*sk_to,
int inet_sk_rebuild_header(struct sock *sk);
-extern u32 inet_ehash_secret;
-extern u32 ipv6_hash_secret;
-void build_ehash_secret(void);
-
static inline unsigned int __inet_ehashfn(const __be32 laddr,
const __u16 lport,
const __be32 faddr,
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 35913fb..b6bdd82 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -245,29 +245,6 @@ out:
}
EXPORT_SYMBOL(inet_listen);
-u32 inet_ehash_secret __read_mostly;
-EXPORT_SYMBOL(inet_ehash_secret);
-
-u32 ipv6_hash_secret __read_mostly;
-EXPORT_SYMBOL(ipv6_hash_secret);
-
-/*
- * inet_ehash_secret must be set exactly once, and to a non nul value
- * ipv6_hash_secret must be set exactly once.
- */
-void build_ehash_secret(void)
-{
- u32 rnd;
-
- do {
- get_random_bytes(, sizeof(rnd));
- } while (rnd == 0);
-
- if (cmpxchg(_ehash_secret, 0, rnd) == 0)
- get_random_bytes(_hash_secret, sizeof(ipv6_hash_secret));
-}
-EXPORT_SYMBOL(build_ehash_secret);
-
/*
* Create an inet socket.
*/
@@ -284,10 +261,6 @@ static int inet_create(struct net *net, struct socket
*sock, int protocol,
int try_loading_module = 0;
int err;
- if (unlikely(!inet_ehash_secret))
- if (sock->type != SOCK_RAW && sock->type != SOCK_DGRAM)
- build_ehash_secret();
-
sock->state = SS_UNCONNECTED;
/* Look for the requested type/protocol pair. */
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 18aa668..8b9cf27 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -28,6 +28,10 @@ static unsigned int inet_ehashfn(struct net *net, const
__be32 laddr,
const __u16 lport, const __be32 faddr,
const __be16 fport)
{
+ static u32 inet_ehash_secret __read_mostly;
+
+ net_get_random_once(_ehash_secret, sizeof(inet_ehash_secret));
+
return __inet_ehashfn(laddr, lport, faddr, fport,
inet_ehash_secret + net_hash_mix(net));
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b4437c7..89909dd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -411,8 +411,12 @@ static unsigned int udp_ehashfn(struct net *net, const
__be32 laddr,
const __u16 lport, const __be32 faddr,
const __be16 fport)
{
+ static u32 udp_ehash_secret __read_mostly;
+
+ net_get_random_once(_ehash_secret, sizeof(udp_ehash_secret));
+
return __inet_ehashfn(laddr, lport, faddr, fport,
- inet_ehash_secret + net_hash_mix(net));
+ udp_ehash_secret + net_hash_mix(net));
}
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index a2cb07c..20af1fb 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -110,11 +110,6 @@ static int inet6_create(struct net *net, struct socket
*sock, int protocol,
int try_loading_module = 0;
int err;
- if (sock->type != SOCK_RAW &&
- sock->type != SOCK_DGRAM &&
- !inet_ehash_secret)
- build_ehash_secret();
-
/* Look for the requested type/protocol pair. */
lookup_protocol:
err = -ESOCKTNOSUPPORT;
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index fa7dd38..262e13c 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -29,10 +29,19 @@ static unsigned int inet6_ehashfn(struct net *net,
const struct in6_addr *faddr,
const __be16 fport)
{
- const u32 lhash = (__force u32)laddr->s6_addr32[3];
- const u32 fhash = __ipv6_addr_jhash(faddr, ipv6_hash_secret);
+
[PATCH net-next v3 5/9] net: introduce new macro net_get_random_once
net_get_random_once is a new macro which handles the initialization
of secret keys. It is possible to call it in the fast path. Only the
initialization depends on the spinlock and is rather slow. Otherwise
it should get used just before the key is used to delay the entropy
extration as late as possible to get better randomness. It returns true
if the key got initialized.
The usage of static_keys for net_get_random_once is a bit uncommon so
it needs some further explanation why this actually works:
=== In the simple non-HAVE_JUMP_LABEL case we actually have ===
no constrains to use static_key_(true|false) on keys initialized with
STATIC_KEY_INIT_(FALSE|TRUE). So this path just expands in favor of
the likely case that the initialization is already done. The key is
initialized like this:
___done_key = { .enabled = ATOMIC_INIT(0) }
The check
if (!static_key_true(&___done_key)) \
expands into (pseudo code)
if (!likely(___done_key > 0))
, so we take the fast path as soon as ___done_key is increased from the
helper function.
=== If HAVE_JUMP_LABELs are available this depends ===
on patching of jumps into the prepared NOPs, which is done in
jump_label_init at boot-up time (from start_kernel). It is forbidden
and dangerous to use net_get_random_once in functions which are called
before that!
At compilation time NOPs are generated at the call sites of
net_get_random_once. E.g. net/ipv6/inet6_hashtable.c:inet6_ehashfn (we
need to call net_get_random_once two times in inet6_ehashfn, so two NOPs):
71: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
76: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
Both will be patched to the actual jumps to the end of the function to
call __net_get_random_once at boot time as explained above.
arch_static_branch is optimized and inlined for false as return value and
actually also returns false in case the NOP is placed in the instruction
stream. So in the fast case we get a "return false". But because we
initialize ___done_key with (enabled != (entries & 1)) this call-site
will get patched up at boot thus returning true. The final check looks
like this:
if (!static_key_true(&___done_key)) \
___ret = __net_get_random_once(buf, \
expands to
if (!!static_key_false(&___done_key)) \
___ret = __net_get_random_once(buf, \
So we get true at boot time and as soon as static_key_slow_inc is called
on the key it will invert the logic and return false for the fast path.
static_key_slow_inc will change the branch because it got initialized
with .enabled == 0. After static_key_slow_inc is called on the key the
branch is replaced with a nop again.
=== Misc: ===
The helper defers the increment into a workqueue so we don't
have problems calling this code from atomic sections. A seperate boolean
(___done) guards the case where we enter net_get_random_once again before
the increment happend.
Cc: Ingo Molnar
Cc: Steven Rostedt
Cc: Jason Baron
Cc: Peter Zijlstra
Cc: Eric Dumazet
Cc: "David S. Miller"
Signed-off-by: Hannes Frederic Sowa
---
I tested this patchset with !CC_HAVE_ASM_GOTO and with CC_HAVE_ASM_GOTO
on x86_64.
I quickly reviewed that all architectures which implement HAVE_JUMP_LABEL
also patch all branch sites on boot-up. But this needs further review
as this is a security sensitive patch series.
Thank you!
include/linux/net.h | 25 +
net/core/utils.c| 48
2 files changed, 73 insertions(+)
diff --git a/include/linux/net.h b/include/linux/net.h
index ca9ec85..a489705 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -239,6 +239,31 @@ do {
\
#define net_random() prandom_u32()
#define net_srandom(seed) prandom_seed((__force u32)(seed))
+bool __net_get_random_once(void *buf, int nbytes, bool *done,
+ struct static_key *done_key);
+
+#ifdef HAVE_JUMP_LABEL
+#define ___NET_RANDOM_STATIC_KEY_INIT ((struct static_key) \
+ { .enabled = ATOMIC_INIT(0), .entries = (void *)1 })
+#else /* !HAVE_JUMP_LABEL */
+#define ___NET_RANDOM_STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
+#endif /* HAVE_JUMP_LABEL */
+
+/* BE CAREFUL: this function is not interrupt safe */
+#define net_get_random_once(buf, nbytes) \
+ ({ \
+ bool ___ret = false;\
+ static bool ___done = false;\
+ static struct static_key ___done_key = \
+ ___NET_RANDOM_STATIC_KEY_INIT; \
+ if (!static_key_true(&___done_key))
Re: [PATCH v2 01/15] slab: correct pfmemalloc check
On Wed, Oct 16, 2013 at 03:27:54PM +, Christoph Lameter wrote:
> On Wed, 16 Oct 2013, Joonsoo Kim wrote:
>
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -930,7 +930,8 @@ static void *__ac_put_obj(struct kmem_cache *cachep,
> > struct array_cache *ac,
> > {
> > if (unlikely(pfmemalloc_active)) {
> > /* Some pfmemalloc slabs exist, check if this is one */
> > - struct page *page = virt_to_head_page(objp);
> > + struct slab *slabp = virt_to_slab(objp);
> > + struct page *page = virt_to_head_page(slabp->s_mem);
> > if (PageSlabPfmemalloc(page))
>
> I hope the compiler optimizes this code correctly because virt_to_slab
> already does one virt_to_head_page()?
It should not.
objp could be in a different page with slabp->s_mem's,
so virt_to_head_page() should be called twice.
Anyway, after implementing struct slab overloading, one call site is
removed by [14/15] in this patchset, so there is no issue.
Thanks.
>
> Otherwise this looks fine.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 16
On 10/16/2013 11:51 AM, Thierry Reding wrote: Hi all, I've uploaded today's linux-next tree to the master branch of the repository below: git://gitorious.org/thierryreding/linux-next.git A next-20131016 tag is also provided for convenience. Gained two new conflicts, but nothing too exciting. x86 and ARM default configurations as well as the x86 allmodconfig mostly build fine on the final tree. There was a failure for the ARM at91x40_defconfig, but the proper fix wasn't immediately obvious to me, so I've left it broken for now. Upside: mips qemu run now passes (mips64 qemu build still fails). Downside: Up to 13 build failures, from 12. Besides the mips64 qemu build, current failures are: arm:allmodconfig blackfin:defconfig mips:nlm_xlp_defconfig mips:cavium_octeon_defconfig powerpc: (7 out of 14) sparc64:allmodconfig xtensa:allmodconfig (new failure) Details are 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 net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote: > Jason Wang writes: > > We're trying to re-configure the affinity unconditionally in cpu hotplug > > callback. This may lead the issue during resuming from s3/s4 since > > > > - virt queues haven't been allocated at that time. > > - it's unnecessary since thaw method will re-configure the affinity. > > > > Fix this issue by checking the config_enable and do nothing is we're not > > ready. > > > > The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17 > > (virtio-net: reset virtqueue affinity when doing cpu hotplug). > > > > Cc: Rusty Russell > > Cc: Michael S. Tsirkin > > Cc: Wanlong Gao > > Acked-by: Michael S. Tsirkin > > Reviewed-by: Wanlong Gao > > Signed-off-by: Jason Wang > > --- > > The patch is need for 3.8 and above. > > Please put 'CC: sta...@kernel.org # 3.8+' in the commit. Not if this is going in through the net tree. > > (The specification of the stable line is poor, but that seems to be one > common method). > > Cheers, > Rusty. -- 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 28/28] net: use DMA_COMPLETE for dma completion status
From: Vinod Koul Date: Wed, 16 Oct 2013 21:58:46 +0530 > Signed-off-by: Vinod Koul > CC: "David S. Miller" Acked-by: David S. Miller -- 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] of/lib: Export fdt routines to modules
On 10/16/2013 05:27 PM, Michael Bohan wrote: On Wed, Oct 16, 2013 at 04:39:03PM -0700, David Daney wrote: On 10/16/2013 04:27 PM, Michael Bohan wrote: Ever since the following commit, libfdt has been available for usage in the kernel: commit ab25383983fb8d7786696f5371e75e79c3e9a405 Author: David Daney Date: Thu Jul 5 18:12:38 2012 +0200 of/lib: Allow scripts/dtc/libfdt to be used from kernel code Export these functions to modules so that they may be used >from device drivers. --- +EXPORT_SYMBOL_GPL(fdt_next_tag); The code was all written by David Gibson, and is dual GPL/BSD licensed. So I am not sure you should be using the GPL flavor of the export directive. Yeah, I wasn't quite sure about this myself. I can remove the GPL if it's incorrect. But more than this. I don't understand why a driver would be parsing the FDT in the first place. If there is a device tree, why hasn't it been unflattened, and thus used via the normal device tree functions. My motivation is actually to use the fdt format as a firmware. I have a requirement to express driver metadata that's loadable from the filesystem. This data is not reasonable to place in the system Device Tree, since it's application specific and does not actually describe hardware. The fact that the format chosen is 'flattened device tree' is merely just a coincidence. Still, what prevents you from unflattening it and just using the normal device tree functions as David suggested ? Guenter When considering formats, dts / fdt is convenient since: -The dts syntax meets requirements by being human-readable. -There exists a device-tree compiler already -Linux knows how to deal with fdt, so the driver implementation becomes more simple. Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About [PATCH 1/2] regulator: core: Provide a dummy regulator with full constraints
On 10/16/2013 06:39 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Wed, Oct 16, 2013 at 12:36:46PM +0800, Wei Ni wrote: >> On 10/12/2013 08:14 PM, Mark Brown wrote: > >>> OK, I think the device tree board code just needs to set full >>> constraints during machine initialisation. We can't have multiple > >> Hi, Mark, do you mean we can call regulator_has_full_constraints(), but >> some platforms doesn't have board file now, they only have dts file, how >> to call this functions? > > There is still a board file for DT machines, it's just shared between > all machines - it should be doing the call instead of the regulator > framework trying to retrofit it. So do you mean it should call the regulator_has_full_constraints() in the .init_machine for all machines? If so, this will affect all boards, for example, in arch/arm/mach-tegra, if we set full constraints in the shared board file tegra.c, all tegra boards will be set, is it right? Thanks. Wei. > > * Unknown Key > * 0x7EA229BD > -- 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] get_maintainer.pl incomplete output
On Wed, 2013-10-16 at 21:19 -0700, David Rientjes wrote: > On Wed, 16 Oct 2013, Joe Perches wrote: > > > > I haven't looked closely at scripts/get_maintainer.pl, but I recently > > > wrote a patch touching mm/vmpressure.c and it doesn't list the file's > > > author, Anton Vorontsov . > > > > > > Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is > > > missing and git blame attributs >90% of the lines to his authorship. > > > > > > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c > > > Tejun Heo (commit_signer:6/7=86%) > > > Michal Hocko (commit_signer:5/7=71%) > > > Andrew Morton (commit_signer:4/7=57%) > > > Li Zefan (commit_signer:3/7=43%) > > > "Kirill A. Shutemov" (commit_signer:1/7=14%) > > > linux...@kvack.org (open list:MEMORY MANAGEMENT) > > > linux-kernel@vger.kernel.org (open list) > > > > > > Any ideas? > > > > get_maintainer has a lot of options. > > > > get_maintainer tries to find people that are either > > listed in the MAINTAINERS file or that have recently > > (in the last year by default) worked on the file. > > > > If you want to find all authors, use the --git-blame option > > > > It's not the default because it can take quite awhile to run. > > > > Hmm, it's a little strange to only consider recent activity when >90% of > the lines were written by someone not listed. Isn't there any faster way > to determine that besides using the expensive git blame? Not so far as I know. > Something like > weighing the output of "git show --shortstat" for all commits in "git log > mm/vmpressure.c" to determine the most important recent changes? That > should be fairly cheap. Important can be hard to determine. git blame effectively does a --follow get_maintainers already does a git log and accumulates all the signatures for the time selected by --git-since It doesn't weight each commit by +/- count. I think the most significant negative to the current get_maintainer is that only the "signature" lines are considered. The "Author:" line isn't. The default ris for get_maintainer to only list a maximum of 5 "maintainers" ordered by signature count. Anton has only signed/acked 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: [RESEND PATCH 3/4] ARM: dts: bcm281xx: Add i2c busses
Hi Tim,
This patch does not work as it relies on the yet-unmerged clock code
for bcm11351. This patch does not apply to -rc, and when tweaked it
does not compile as it references non-existent bsc_clks.
Has the clk patches been submitted yet ? Applying this will have to
wait until those have been accepted.
thanks,
csd
On Wed, Oct 16, 2013 at 3:01 PM, Tim Kryger wrote:
> Add the DTS nodes for all the i2c busses in the SoC.
>
> Signed-off-by: Tim Kryger
> Reviewed-by: Christian Daudt
> Reviewed-by: Matt Porter
> Reviewed-by: Markus Mayer
> ---
> arch/arm/boot/dts/bcm11351.dtsi | 40
> 1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 1246885..4bfd7e3 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -146,6 +146,46 @@
> status = "disabled";
> };
>
> + i2c@3e016000 {
> + compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> + reg = <0x3e016000 0x80>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> + status = "disabled";
> + };
> +
> + i2c@3e017000 {
> + compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> + reg = <0x3e017000 0x80>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> + status = "disabled";
> + };
> +
> + i2c@3e018000 {
> + compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> + reg = <0x3e018000 0x80>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> + status = "disabled";
> + };
> +
> + i2c@3500d000 {
> + compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> + reg = <0x3500d000 0x80>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_bsc_clk>;
> + status = "disabled";
> + };
> +
> clocks {
> bsc1_clk: bsc1 {
> compatible = "fixed-clock";
> --
> 1.8.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: [bug] get_maintainer.pl incomplete output
On Wed, 16 Oct 2013, Joe Perches wrote: > > I haven't looked closely at scripts/get_maintainer.pl, but I recently > > wrote a patch touching mm/vmpressure.c and it doesn't list the file's > > author, Anton Vorontsov . > > > > Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is > > missing and git blame attributs >90% of the lines to his authorship. > > > > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c > > Tejun Heo (commit_signer:6/7=86%) > > Michal Hocko (commit_signer:5/7=71%) > > Andrew Morton (commit_signer:4/7=57%) > > Li Zefan (commit_signer:3/7=43%) > > "Kirill A. Shutemov" (commit_signer:1/7=14%) > > linux...@kvack.org (open list:MEMORY MANAGEMENT) > > linux-kernel@vger.kernel.org (open list) > > > > Any ideas? > > get_maintainer has a lot of options. > > get_maintainer tries to find people that are either > listed in the MAINTAINERS file or that have recently > (in the last year by default) worked on the file. > > If you want to find all authors, use the --git-blame option > > It's not the default because it can take quite awhile to run. > Hmm, it's a little strange to only consider recent activity when >90% of the lines were written by someone not listed. Isn't there any faster way to determine that besides using the expensive git blame? Something like weighing the output of "git show --shortstat" for all commits in "git log mm/vmpressure.c" to determine the most important recent changes? That should be fairly cheap. -- 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] get_maintainer.pl incomplete output
On Wed, 2013-10-16 at 20:51 -0700, David Rientjes wrote: > Hi Joe, Hi David. > I haven't looked closely at scripts/get_maintainer.pl, but I recently > wrote a patch touching mm/vmpressure.c and it doesn't list the file's > author, Anton Vorontsov . > > Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is > missing and git blame attributs >90% of the lines to his authorship. > > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c > Tejun Heo (commit_signer:6/7=86%) > Michal Hocko (commit_signer:5/7=71%) > Andrew Morton (commit_signer:4/7=57%) > Li Zefan (commit_signer:3/7=43%) > "Kirill A. Shutemov" (commit_signer:1/7=14%) > linux...@kvack.org (open list:MEMORY MANAGEMENT) > linux-kernel@vger.kernel.org (open list) > > Any ideas? get_maintainer has a lot of options. get_maintainer tries to find people that are either listed in the MAINTAINERS file or that have recently (in the last year by default) worked on the file. If you want to find all authors, use the --git-blame option It's not the default because it can take quite awhile to run. If you always want --git-blame added, use a .get_maintainer.conf file to override the default options. $ time ./scripts/get_maintainer.pl -f --git-blame mm/vmpressure.c Tejun Heo (commit_signer:6/7=86%,commits:5/6=83%) Michal Hocko (commit_signer:5/7=71%,authored lines:22/387=6%,commits:5/6=83%) Andrew Morton (commit_signer:4/7=57%,commits:4/6=67%) Li Zefan (commit_signer:3/7=43%,commits:2/6=33%) "Kirill A. Shutemov" (commit_signer:1/7=14%,commits:1/6=17%) Anton Vorontsov (authored lines:354/387=91%) linux...@kvack.org (open list:MEMORY MANAGEMENT) linux-kernel@vger.kernel.org (open list) real0m28.529s user0m25.400s sys 0m0.764s The --help option is moderately descriptive. If you think it needs to be better, please say how. cheers, Joe $ ./scripts/get_maintainer.pl --help usage: ./scripts/get_maintainer.pl [options] patchfile ./scripts/get_maintainer.pl [options] -f file|directory version: 0.26 MAINTAINER field selection options: --email => print email address(es) if any --git => include recent git *-by: signers --git-all-signature-types => include signers regardless of signature type or use only (Signed-off-by:|Reviewed-by:|Acked-by:) signers (default: 0) --git-fallback => use git when no exact MAINTAINERS pattern (default: 1) --git-chief-penguins => include (Linus Torvalds) --git-min-signatures => number of signatures required (default: 1) --git-max-maintainers => maximum maintainers to add (default: 5) --git-min-percent => minimum percentage of commits required (default: 5) --git-blame => use git blame to find modified commits for patch or file --git-since => git history to use (default: 1-year-ago) --hg-since => hg history to use (default: -365) --interactive => display a menu (mostly useful if used with the --git option) --m => include maintainer(s) if any --n => include name 'Full Name ' --l => include list(s) if any --s => include subscriber only list(s) if any --remove-duplicates => minimize duplicate email names/addresses --roles => show roles (status:subsystem, git-signer, list, etc...) --rolestats => show roles and statistics (commits/total_commits, %) --file-emails => add email addresses found in -f file (default: 0 (off)) --scm => print SCM tree(s) if any --status => print status if any --subsystem => print subsystem name if any --web => print website(s) if any Output type options: --separator [, ] => separator for multiple entries on 1 line using --separator also sets --nomultiline if --separator is not [, ] --multiline => print 1 entry per line Other options: --pattern-depth => Number of pattern directory traversals (default: 0 (all)) --keywords => scan patch for keywords (default: 1) --sections => print all of the subsystem sections with pattern matches --mailmap => use .mailmap file (default: 1) --version => show version --help => show this help information Default options: [--email --nogit --git-fallback --m --n --l --multiline -pattern-depth=0 --remove-duplicates --rolestats] Notes: Using "-f directory" may give unexpected results: Used with "--git", git signators for _all_ files in and below directory are examined as git recurses directories. Any specified X: (exclude) pattern matches are _not_ ignored. Used with "--nogit", directory is used as a pattern match, no individual file within the directory or subdirectory is matched. Used with "--git-blame", does not iterate all files in directory Using "--git-blame" is slow and may add old committers and authors that are no longer active maintainers to the output. Using "--roles" or "--rolestats" with git send-email --cc-cmd or any other automated tools that expect only ["name"] may not work because of additional output after . Using
Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
Jason Wang writes: > We're trying to re-configure the affinity unconditionally in cpu hotplug > callback. This may lead the issue during resuming from s3/s4 since > > - virt queues haven't been allocated at that time. > - it's unnecessary since thaw method will re-configure the affinity. > > Fix this issue by checking the config_enable and do nothing is we're not > ready. > > The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17 > (virtio-net: reset virtqueue affinity when doing cpu hotplug). > > Cc: Rusty Russell > Cc: Michael S. Tsirkin > Cc: Wanlong Gao > Acked-by: Michael S. Tsirkin > Reviewed-by: Wanlong Gao > Signed-off-by: Jason Wang > --- > The patch is need for 3.8 and above. Please put 'CC: sta...@kernel.org # 3.8+' in the commit. (The specification of the stable line is poor, but that seems to be one common method). Cheers, Rusty. -- 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/3] switch_creds: Syscall to switch creds for file server ops
Al Viro writes:
> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
>
>> That doesn't look bad but it does need capable(CAP_SETUID) &&
>> capable(CAP_SETGID) or possibly something a little more refined.
>
> D'oh
>
>> I don't think we want file descriptor passing to all of a sudden become
>> a grant of privilege, beyond what the passed fd can do.
>
> Definitely. And an extra ) to make it compile wouldn't hurt either...
There also appears to need to be a check that we don't gain any
capabilities.
We also need a check so that you don't gain any capabilities, and
possibly a few other things.
So I suspect we want a check something like:
if ((new_cred->securebits != current_cred->securebits) ||
(new_cred->cap_inheritable != current_cred->cap_inheritable) ||
(new_cred->cap_permitted != current_cred->cap_permitted) ||
(new_cred->cap_effective != current_cred->cap_effective) ||
(new_cred->cap_bset != current_cred->cap_bset) ||
(new_cred->jit_keyring != current_cred->jit_keyring) ||
(new_cred->session_keyring != current_cred->session_keyring) ||
(new_cred->process_keyring != current_cred->process_keyring) ||
(new_cred->thread_keyring != current_cred->thread_keyring) ||
(new_cred->request_keyring != current_cred->request_keyring) ||
(new_cred->security != current_cred->security) ||
(new_cred->user_ns != current_cred->user_ns)) {
return -EPERM;
}
Eric
--
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] get_maintainer.pl incomplete output
Hi Joe, I haven't looked closely at scripts/get_maintainer.pl, but I recently wrote a patch touching mm/vmpressure.c and it doesn't list the file's author, Anton Vorontsov . Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is missing and git blame attributs >90% of the lines to his authorship. $ ./scripts/get_maintainer.pl -f mm/vmpressure.c Tejun Heo (commit_signer:6/7=86%) Michal Hocko (commit_signer:5/7=71%) Andrew Morton (commit_signer:4/7=57%) Li Zefan (commit_signer:3/7=43%) "Kirill A. Shutemov" (commit_signer:1/7=14%) linux...@kvack.org (open list:MEMORY MANAGEMENT) linux-kernel@vger.kernel.org (open list) Any ideas? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, vmpressure: add high level
On Wed, 16 Oct 2013, Anton Vorontsov wrote: > > Vmpressure has two important levels: medium and critical. Medium is > > defined at 60% and critical is defined at 95%. > > > > We have a customer who needs a notification at a higher level than medium, > > which is slight to moderate reclaim activity, and before critical to start > > throttling incoming requests to save memory and avoid oom. > > > > This patch adds the missing link: a high level defined at 80%. > > > > In the future, it would probably be better to allow the user to specify an > > integer ratio for the notification rather than relying on arbitrarily > > specified levels. > > Does the customer need to differentiate the two levels (medium and high), > or the customer only interested in this (80%) specific level? > Only high. > In the latter case, instead of adding a new level I would vote for adding > a [sysfs] knob for modifying medium level's threshold. > Hmm, doesn't seem like such a good idea. If one process depends on this being 60% and another depends on it being 80%, we're stuck. I think it's legitimate to have things like low, medium, high, and critical as rough approximations (and to keep backwards compatibility), but as mentioned in the changelog I want to extend the interface to allow integer writes to specify their own ratio. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4: fix performance regression in ext4_writepages
On Wed, Oct 16, 2013 at 09:18:37AM +0800, Ming Lei wrote: > Commit 4e7ea81db5(ext4: restructure writeback path) introduces > another performance regression on random write: > > - one more page may be added to ext4 extent in mpage_prepare_extent_to_map, > and will be submitted for I/O so nr_to_write will become -1 before 'done' > is set > > - the worse thing is that dirty pages may still be retrieved from page > cache after nr_to_write becomes negative, so lots of small chunks can be > submitted to block device when page writeback is catching up with write > path, and performance is hurted. > > On one arm A15 board with sata 3.0 SSD(CPU: 1.5GHz dura core, RAM: 2GB, > SATA controller: 3.0Gbps), this patch can improve below test's result > from 157MB/sec to 174MB/sec(>10%): > > dd if=/dev/zero of=./z.img bs=8K count=512K > > The above test is actually prototype of block write in bonnie++ utility. > > This patch makes sure no more pages than nr_to_write can be added to extent > for mapping, so that nr_to_write won't become negative. > > Cc: Ted Tso > Cc: linux-e...@vger.kernel.org > Cc: "linux-fsde...@vger.kernel.org" > Acked-by: Jan Kara > Signed-off-by: Ming Lei Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend PATCH 3/5] ACPI: Add new acpi_dev_resource_address_space_full() function
On 2013年10月17日 07:18, Bjorn Helgaas wrote:
> On Fri, Oct 11, 2013 at 08:18:59PM +0800, tianyu@intel.com wrote:
>> From: Lan Tianyu
>>
>> Make acpi_dev_resource_address_space() to accept struct
>> acpi_resource_address64 as param and rename it to *_full.
>>
>> This is for some cases that acpi address info is also needed
>> after convert from acpi resouce to generic resource.
>
> s/resouce/resource/
>
>> Add acpi_dev_resource_addres_space() again as a wrapper of new
>
> acpi_dev_resource_address_space() (spelled wrong above).
>
>> function for original users.
>>
>> Signed-off-by: Lan Tianyu
>> ---
>> drivers/acpi/resource.c | 53
>> ++---
>> include/linux/acpi.h| 3 +++
>> 2 files changed, 40 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 84bc3db..2e395ba 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -162,19 +162,21 @@ bool acpi_dev_resource_io(struct acpi_resource *ares,
>> struct resource *res)
>> EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
>>
>> /**
>> - * acpi_dev_resource_address_space - Extract ACPI address space information.
>> + * acpi_dev_resource_address_space_full - Extract ACPI address space
>> information.
>> * @ares: Input ACPI resource object.
>> + * @addr: Output ACPI resource address64 space object.
>> * @res: Output generic resource object.
>> *
>> * Check if the given ACPI resource object represents an address space
>> resource
>> - * and if that's the case, use the information in it to populate the generic
>> - * resource object pointed to by @res.
>> + * and if that's the case, convert it to ACPI resource address64 space
>> object
>> + * pointed to by @addr and use the information to populate the generic
>> resource
>> + * object pointed to by @re.
>
> s/@re/@res/ or maybe even just use this:
>
> "If @ares is an address space resource, convert it to an
> acpi_resource_address64 and use that to populate the generic @res."
>
>> */
>> -bool acpi_dev_resource_address_space(struct acpi_resource *ares,
>> +bool acpi_dev_resource_address_space_full(struct acpi_resource *ares,
>> + struct acpi_resource_address64 *addr,
>> struct resource *res)
>> {
>> acpi_status status;
>> -struct acpi_resource_address64 addr;
>> bool window;
>> u64 len;
>> u8 io_decode;
>> @@ -188,29 +190,29 @@ bool acpi_dev_resource_address_space(struct
>> acpi_resource *ares,
>> return false;
>> }
>>
>> -status = acpi_resource_to_address64(ares, );
>> +status = acpi_resource_to_address64(ares, addr);
>> if (ACPI_FAILURE(status))
>> return true;
>
> You didn't actually change this, but it looks wrong to return "true"
> here, because we haven't filled in "res". Returning "true" will cause
> acpi_dev_process_resource() to call acpi_dev_new_resource_entry() with
> a struct resource that's full of zeroes.
>
> I think the best fix would be to remove this code just above:
>
> switch (ares->type) {
> case ACPI_RESOURCE_TYPE_ADDRESS16:
> case ACPI_RESOURCE_TYPE_ADDRESS32:
> case ACPI_RESOURCE_TYPE_ADDRESS64:
> break;
> default:
> return false;
> }
>
> and return "false" if acpi_resource_to_address64() fails.
Yes, Just check acpi_resource_to_address64() and it only processes
ACPI_RESOURCE_TYPE_ADDRESS16, ACPI_RESOURCE_TYPE_ADDRESS32 and
ACPI_RESOURCE_TYPE_ADDRESS64. If other type, it will return false.
I will change it.
>
>>
>> -res->start = addr.minimum + addr.translation_offset;
>> -res->end = addr.maximum + addr.translation_offset;
>> -window = addr.producer_consumer == ACPI_PRODUCER;
>> +res->start = addr->minimum + addr->translation_offset;
>> +res->end = addr->maximum + addr->translation_offset;
>> +window = addr->producer_consumer == ACPI_PRODUCER;
>>
>> -switch(addr.resource_type) {
>> +switch (addr->resource_type) {
>> case ACPI_MEMORY_RANGE:
>> -len = addr.maximum - addr.minimum + 1;
>> +len = addr->maximum - addr->minimum + 1;
>> res->flags = acpi_dev_memresource_flags(len,
>> -addr.info.mem.write_protect,
>> +addr->info.mem.write_protect,
>> window);
>>
>> -if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>> +if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>> res->flags |= IORESOURCE_PREFETCH;
>> break;
>> case ACPI_IO_RANGE:
>> -io_decode = addr.granularity == 0xfff ?
>> +io_decode = addr->granularity == 0xfff ?
>> ACPI_DECODE_10 : ACPI_DECODE_16;
>> -res->flags =
Re: Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
On Thursday, October 17, 2013 02:20:50 Al Viro wrote: > On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote: > > That doesn't look bad but it does need capable(CAP_SETUID) && > > capable(CAP_SETGID) or possibly something a little more refined. > > D'oh > > > I don't think we want file descriptor passing to all of a sudden become > > a grant of privilege, beyond what the passed fd can do. > > Definitely. And an extra ) to make it compile wouldn't hurt either... Ok, I'll rework this, dropping the void arg etc. How about this: 1. have one arg, the fd, i.e. SYSCALL_DEFINE1(switch_cred, int, fd) 2. if the fd >=0 do the override in my "use the fd" variation. This would do the capability check after the valid fd check. This means that you must have privs to mess with privs. Returns 0 or either EBADF or EPERM 3. if the fd == -1 do the revert case. The reason for this is there are 4 syscalls needed to change the creds and each has an error return. We need a way to escape the damage and a revert to the real creds set is the best way to return to a known state. This does not require a capability check because all that can happen is to return to the immutable real set. Also, I don't need the initial open of /dev/null. Does this fit? Jim -- Jim Lieb Linux Systems Engineer Panasas Inc. "If ease of use was the only requirement, we would all be riding tricycles" - Douglas Engelbart 1925–2013 -- 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/
sparse: possible false report of context imbalance
Hi, Sparse reports the following: CHECK drivers/staging/rtl8188eu/core/rtw_mlme.c drivers/staging/rtl8188eu/core/rtw_mlme.c:1003:9: warning: context imbalance in 'rtw_free_assoc_resources' - different lock contexts for basic block The code in question is as follows: if (lock_scanned_queue) spin_lock_bh(&(pmlmepriv->scanned_queue.lock)); pwlan = rtw_find_network(>scanned_queue, tgt_network->network.MacAddress); if (lock_scanned_queue) spin_unlock_bh(&(pmlmepriv->scanned_queue.lock)); As this fragment uses the identical test to unlock that is used to lock, and the test variable is not touched, I think this is a false indication. I am using version 0.4.4 of sparse. Thanks, Larry -- 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 2/5] ACPI/Resource: Add address translation support
On 2013年10月17日 07:05, Bjorn Helgaas wrote:
> On Fri, Oct 11, 2013 at 08:18:58PM +0800, tianyu@intel.com wrote:
>> From: Lan Tianyu
>>
>> According ACPI 5.0 spec Section 19.1.8
>
> This section reference is wrong. Table 5-133 (on page 243) does
> point to Section 19.1.8, but that section is only the ASL grammar
> description and doesn't have any useful information about what
> _TRA means.
>
> A more useful reference (and the source of the quote below) is
> Section 6.4.3.5.1.
>
>> "For bridges, translate addresses across the bridge, this is the
>> offset that must be added to the address on the secondary side
>> to obtain the address on the primary side. Non-bridge devices
>> must list 0."
>
> You didn't quote this correctly. Here's a copy/paste from the spec:
>
> For bridges that translate addresses across the bridge, this is
> the offset that must be added to the address on the secondary side
> to obtain the address on the primary side. Non-bridge devices must
> list 0 for all Address Translation offset bits.
>
>> This patch is to add address translation offset to the start/end
>> of struct resource in the acpi_dev_resource_address_space().
>> Further more, non-bridge device's translation_offset should 0.
>> So this change will affect other devices.
>>
>> Signed-off-by: Lan Tianyu
>
> I like the patch, though :) With the above corrections,
Hi Bjorn:
Thanks for review. I will correct them.
>
> Acked-by: Bjorn Helgaas
>
>> ---
>> drivers/acpi/resource.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 929f416..84bc3db 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -192,8 +192,8 @@ bool acpi_dev_resource_address_space(struct
>> acpi_resource *ares,
>> if (ACPI_FAILURE(status))
>> return true;
>>
>> -res->start = addr.minimum;
>> -res->end = addr.maximum;
>> +res->start = addr.minimum + addr.translation_offset;
>> +res->end = addr.maximum + addr.translation_offset;
>> window = addr.producer_consumer == ACPI_PRODUCER;
>>
>> switch(addr.resource_type) {
>> --
>> 1.8.2.1
>>
--
Best regards
Tianyu Lan
--
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/
[no subject]
-- Dear beneficiary,This is to re-notify you of the $300,000.00 USD that was depositedhere in the western union office in your name is available for pickup.Contact us via email for your M.T.C.N Numbers.Contact Person:Mr. ben c johnEmail: remittance2013@hotmail.comContact Phone : +44 7024043572 -- 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/3 v6] thermal: samsung: Add TMU support for Exynos5420 SoCs
This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Note: The platform data structure will be handled properly once the driver
moves to complete device driver solution.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
As the changes are minimum and can be added here.
Changes since v3:
a. Rearraged the code alphabetically, make exynso5420 come before exynso5440
b. Reduce code duplication in passing platform data by introducing a common
macro
Bartlomiej Zolnierkiewicz Thanks for review and suggestions
Changes since v4:
None
Changes since v5:
None
.../devicetree/bindings/thermal/exynos-thermal.txt | 39
drivers/thermal/samsung/exynos_tmu.c | 12 ++-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 99
drivers/thermal/samsung/exynos_tmu_data.h |7 ++
5 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..c5f9a74 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,7 @@
"samsung,exynos4412-tmu"
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
+ "samsung,exynos5420-tmu"
"samsung,exynos5440-tmu"
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +14,16 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+ The misplaced register address is passed through devicetree as the
+ second base
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = "tmu_apbif";
};
+Example 3): (In case of Exynos5420)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in "aliases" node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index ae80a87..b54825a 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
}
} else {
- trim_info = readl(data->base + reg->triminfo_data);
+ /* On exynos5420 the triminfo register is in the shared space */
+ if (data->base_second && (data->soc == SOC_ARCH_EXYNOS5420))
+ trim_info = readl(data->base_second +
+ reg->triminfo_data);
+ else
+ trim_info = readl(data->base + reg->triminfo_data);
}
data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
@@ -498,6 +503,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.data = (void
[PATCH 2/3 v6] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
None
Changes since v2:
Changed the flag name from SHARED_MEMORY to ADDRESS_MULTIPLE.
https://lkml.org/lkml/2013/8/1/38
Changes since v3:
None
Changes since v4:
Corrected a compilation error, undeclared variable
Changes since v5:
None
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 14 +++---
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to each instance of TMU and second set belongs to second set
+ of common TMU registers.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index b2202fa..ae80a87 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
- writel(0, data->base_common + reg->tmu_pmin);
+ writel(0, data->base_second + reg->tmu_pmin);
out:
clk_disable(data->clk);
mutex_unlock(>lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
- val_type = readl(data->base_common + reg->tmu_irqstatus);
+ val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev->dev.of_node, 1, )) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data->base_common = devm_ioremap(>dev, res.start,
+ data->base_second = devm_ioremap(>dev, res.start,
resource_size());
- if (!data->base_common) {
+ if (!data->base_second) {
dev_err(>dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 5f4fe6c..d79264f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ *
[PATCH 1/3 v6] thermal: samsung: add intclr_fall_shift bit in exynos_tmu_register
On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.
On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.
On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0
This patch introduces a new bit field intclr_fall_shift to handle the
offset for exyns5250 and exynos5440
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
Changes since v2:
Changes since v3:
None
Changes since v4:
Correct the CLEAR_FALL_INT_SHIFT for Exynos5250/Exynos5440
Changes since v5:
Modify the commit message
drivers/thermal/samsung/exynos_tmu.c |2 +-
drivers/thermal/samsung/exynos_tmu.h |2 ++
drivers/thermal/samsung/exynos_tmu_data.c |2 ++
drivers/thermal/samsung/exynos_tmu_data.h |4 +++-
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..b2202fa 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data->base + reg->threshold_th1);
writel((reg->inten_rise_mask << reg->inten_rise_shift) |
- (reg->inten_fall_mask << reg->inten_fall_shift),
+ (reg->inten_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..5f4fe6c 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -136,6 +136,7 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -207,6 +208,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..09a8a27 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -123,6 +123,7 @@ static const struct exynos_tmu_registers
exynos4412_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -228,6 +229,7 @@ static const struct exynos_tmu_registers
exynos5440_tmu_registers = {
.inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
.tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
+ .intclr_fall_shift = EXYNOS5440_TMU_CLEAR_FALL_INT_SHIFT,
.tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
.emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index a1ea19d..9c1e2c8 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -69,9 +69,11 @@
#define EXYNOS_TMU_RISE_INT_MASK 0x111
#define EXYNOS_TMU_RISE_INT_SHIFT 0
#define EXYNOS_TMU_FALL_INT_MASK 0x111
-#define EXYNOS_TMU_FALL_INT_SHIFT 12
+#define EXYNOS_TMU_FALL_INT_SHIFT 16
#define EXYNOS_TMU_CLEAR_RISE_INT 0x111
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 12)
+#define EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT12
+#define EXYNOS5440_TMU_CLEAR_FALL_INT_SHIFT4
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
#define EXYNOS_TMU_TRIP_MODE_MASK 0x7
#define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 29/29] dmaengine: remove unused DMA_SUCCESS
after all the users are converted
Signed-off-by: Vinod Koul
---
include/linux/dmaengine.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 683c380..4b460a6 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -55,7 +55,6 @@ enum dma_status {
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
- DMA_SUCCESS,
};
/**
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, vmpressure: add high level
Hello David, On Wed, Oct 16, 2013 at 05:43:55PM -0700, David Rientjes wrote: > Vmpressure has two important levels: medium and critical. Medium is > defined at 60% and critical is defined at 95%. > > We have a customer who needs a notification at a higher level than medium, > which is slight to moderate reclaim activity, and before critical to start > throttling incoming requests to save memory and avoid oom. > > This patch adds the missing link: a high level defined at 80%. > > In the future, it would probably be better to allow the user to specify an > integer ratio for the notification rather than relying on arbitrarily > specified levels. Does the customer need to differentiate the two levels (medium and high), or the customer only interested in this (80%) specific level? In the latter case, instead of adding a new level I would vote for adding a [sysfs] knob for modifying medium level's threshold. Thanks, Anton -- 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/2] perf-report: add --max-stack option to limit callchain stack scan
On 10/16/13 1:59 PM, Waiman Long wrote:
This patch adds a new --max-stack option to perf-report to limit the
depth of callchain stack data to look at to reduce the time it takes
for perf-report to finish its processing. It trades the presence of
trailing stack information with faster speed.
I like the patch. I have a similar option in my perf-sched-timehist
command, and I have a patch somewhere for perf-script.
It would be even better to pass this arg kernel side and limit the stack
depth at data collection time.
---8<---
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 72eae74..d90d04a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -37,6 +37,12 @@
#include
+/*
+ * 2-level stringification macro to enable stringification of macro value
+ * */
+#define__to_string(x) #x
+#defineSTRINGIFY(x)__to_string(x)
These 2 lines should be somewhere else -- like util/util.h
---8<---
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 2122141..2725aca 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -771,7 +771,8 @@ static void perf_event__process_sample(struct perf_tool
*tool,
sample->callchain) {
err = machine__resolve_callchain(machine, evsel,
al.thread, sample,
-, );
+, ,
+PERF_MAX_STACK_DEPTH);
if (err)
return;
}
Why not add the option to perf-top as well? copy-paste.
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/
Re: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Wed, Oct 16, 2013 at 11:45:48AM -0700, Dan Williams wrote:
> On Wed, Oct 16, 2013 at 11:29 AM, Guennadi Liakhovetski
> >
> > Doesn't this break kernel compilation for a total of 27 commits? Or am I
> > missing anything?
>
> Yes, I think at the start DMA_COMPLETE should just be a alias for
> DMA_SUCCESS, then after all the driver renames are in delete
> DMA_SUCCESS.
Oops, taht was bad of me. ffixes in v2 and sending patch 29 for removal case
--
>From 7768309422a1345d32857974fe8b57805adfd561 Mon Sep 17 00:00:00 2001
From: Vinod Koul
Date: Wed, 16 Oct 2013 13:29:02 +0530
Subject: [PATCH] dmaengine: use DMA_COMPLETE for dma completion status
the DMA_SUCCESS is a misnomer as dmaengine indicates the transfer is complete
and
gives no guarantee of the transfer success. Hence we should use DMA_COMPLTE
instead of DMA_SUCCESS
Signed-off-by: Vinod Koul
---
drivers/dma/dmaengine.c |2 +-
include/linux/dmaengine.h | 13 +++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 9162ac8..81d8765 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1062,7 +1062,7 @@ dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx)
unsigned long dma_sync_wait_timeout = jiffies + msecs_to_jiffies(5000);
if (!tx)
- return DMA_SUCCESS;
+ return DMA_COMPLETE;
while (tx->cookie == -EBUSY) {
if (time_after_eq(jiffies, dma_sync_wait_timeout)) {
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0bc7275..683c380 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -45,16 +45,17 @@ static inline int dma_submit_error(dma_cookie_t cookie)
/**
* enum dma_status - DMA transaction status
- * @DMA_SUCCESS: transaction completed successfully
+ * @DMA_COMPLETE: transaction completed
* @DMA_IN_PROGRESS: transaction not yet processed
* @DMA_PAUSED: transaction is paused
* @DMA_ERROR: transaction failed
*/
enum dma_status {
- DMA_SUCCESS,
+ DMA_COMPLETE,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
+ DMA_SUCCESS,
};
/**
@@ -979,10 +980,10 @@ static inline enum dma_status
dma_async_is_complete(dma_cookie_t cookie,
{
if (last_complete <= last_used) {
if ((cookie <= last_complete) || (cookie > last_used))
- return DMA_SUCCESS;
+ return DMA_COMPLETE;
} else {
if ((cookie <= last_complete) && (cookie > last_used))
- return DMA_SUCCESS;
+ return DMA_COMPLETE;
}
return DMA_IN_PROGRESS;
}
@@ -1013,11 +1014,11 @@ static inline struct dma_chan *dma_find_channel(enum
dma_transaction_type tx_typ
}
static inline enum dma_status dma_sync_wait(struct dma_chan *chan,
dma_cookie_t cookie)
{
- return DMA_SUCCESS;
+ return DMA_COMPLETE;
}
static inline enum dma_status dma_wait_for_async_tx(struct
dma_async_tx_descriptor *tx)
{
- return DMA_SUCCESS;
+ return DMA_COMPLETE;
}
static inline void dma_issue_pending_all(void)
{
--
1.7.0.4
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] n_gsm: race between ld close and gsmtty open
ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.
Here are some of race cases we found recently in test:
CASE #1
releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:
tty_release(ttyA) tty_open(gsmttyB)
| |
- gsmtty_install(gsmttyB)
| |
-gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
tty_ldisc_release(ttyA) -
| |
gsm_dlci_release(dlci[B]) -
| |
gsm_dlci_free(dlci[B])-
| |
- gsmtty_open(gsmttyB)
gsmtty_open()
{
struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
...
}
In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=
CASE #2
=
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:
tty_release(ttyA) tty_open(gsmttyB)
| |
- gsmtty_install(gsmttyB)
| |
-gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
| |
- gsmtty_open(gsmttyB) fail
| |
- tty_release(gsmttyB)
| |
- gsmtty_close(gsmttyB)
| |
-gsmtty_detach_dlci(dlci[B])
| |
- dlci_put(dlci[B])
| |
tty_ldisc_release(ttyA) -
| |
gsm_dlci_release(dlci[0]) -
| |
gsm_dlci_free(dlci[0])-
| |
- dlci_put(dlci[0])
In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
then hit panic.
=
IMHO, n_gsm tty operations would refer released ldisc, as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are not completed..
This patch is try to avoid it by:
1) in n_gsm driver, use a global gsm spin lock to avoid gsm_dlci_release() run
in
parallel with gsmtty_install();
2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(),
the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;
3) Decrease dlci's ref count in gsmtty_remove(), which is a tty framework api,
and
this is the opposite process of step 2).
Signed-off-by: Chao Bi
---
drivers/tty/n_gsm.c | 37 +++--
1 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c0f76da..41ef7d7 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2054,9 +2054,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
dlci->state == DLCI_CLOSED);
}
/* Free up any link layer users */
+ spin_lock(>lock);
for (i = 0; i < NUM_DLCI; i++)
if (gsm->dlci[i])
gsm_dlci_release(gsm->dlci[i]);
+ spin_unlock(>lock);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, >tx_list, list)
kfree(txq);
@@ -2909,23 +2911,33 @@ static int gsmtty_install(struct tty_driver *driver,
struct tty_struct *tty)
This is ok from a locking
perspective as we don't have to worry about this
if DLCI0 is lost */
- if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN)
+ spin_lock(>lock);
+ if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN) {
+ spin_unlock(>lock);
return -EL2NSYNC;
+ }
dlci = gsm->dlci[line];
if (dlci == NULL) {
alloc = true;
dlci = gsm_dlci_alloc(gsm, line);
}
- if (dlci == NULL)
+ if (dlci == NULL) {
+ spin_unlock(>lock);
return -ENOMEM;
+ }
ret = tty_port_install(>port, driver, tty);
if (ret) {
if (alloc)
[PATCH] gpiolib: append SFI helpers for GPIO API
From: Andy Shevchenko
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
Signed-off-by: Andy Shevchenko
Cc: Kuppuswamy Sathyanarayanan
Cc: David Cohen
Cc: Linus Walleij
Cc: Len Brown
---
drivers/gpio/Kconfig | 4 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpiolib-sfi.c | 76 ++
drivers/sfi/sfi_core.c | 7 +
include/linux/sfi_gpio.h | 27
5 files changed, 115 insertions(+)
create mode 100644 drivers/gpio/gpiolib-sfi.c
create mode 100644 include/linux/sfi_gpio.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 3471962..3fa2a0d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -51,6 +51,10 @@ config OF_GPIO
def_bool y
depends on OF
+config GPIO_SFI
+ def_bool y
+ depends on SFI
+
config GPIO_ACPI
def_bool y
depends on ACPI
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f951866..d548ff3 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
obj-$(CONFIG_GPIO_DEVRES) += devres.o
obj-$(CONFIG_GPIOLIB) += gpiolib.o
obj-$(CONFIG_OF_GPIO) += gpiolib-of.o
+obj-$(CONFIG_GPIO_SFI) += gpiolib-sfi.o
obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
# Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-sfi.c b/drivers/gpio/gpiolib-sfi.c
new file mode 100644
index 000..2f15a81
--- /dev/null
+++ b/drivers/gpio/gpiolib-sfi.c
@@ -0,0 +1,76 @@
+/*
+ * SFI helpers for GPIO API
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Andy Shevchenko
+ *
+ * Based on work done for Intel MID platforms (mrst.c)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "SFI: GPIO: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct sfi_gpio_table_entry *sfi_gpio_table;
+static int sfi_gpio_num_entry;
+
+int sfi_get_gpio_by_name(const char *name)
+{
+ struct sfi_gpio_table_entry *pentry = sfi_gpio_table;
+ int i;
+
+ if (!pentry)
+ return -1;
+
+ for (i = 0; i < sfi_gpio_num_entry; i++, pentry++) {
+ if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN))
+ return pentry->pin_no;
+ }
+
+ return -1;
+}
+EXPORT_SYMBOL_GPL(sfi_get_gpio_by_name);
+
+static int __init sfi_gpio_parse(struct sfi_table_header *table)
+{
+ struct sfi_table_simple *sb = (struct sfi_table_simple *)table;
+ struct sfi_gpio_table_entry *pentry;
+ int num, i;
+
+ if (sfi_gpio_table)
+ return 0;
+
+ num = SFI_GET_NUM_ENTRIES(sb, struct sfi_gpio_table_entry);
+ pentry = (struct sfi_gpio_table_entry *)sb->pentry;
+
+ sfi_gpio_table = kmalloc(num * sizeof(*pentry), GFP_KERNEL);
+ if (!sfi_gpio_table)
+ return -ENOMEM;
+
+ memcpy(sfi_gpio_table, pentry, num * sizeof(*pentry));
+ sfi_gpio_num_entry = num;
+
+ pr_debug("Pin info:\n");
+ for (i = 0; i < num; i++, pentry++)
+ pr_debug("[%2d] chip = %16.16s, name = %16.16s, pin=%d\n", i,
+pentry->controller_name, pentry->pin_name,
+pentry->pin_no);
+
+ return 0;
+}
+
+int __init sfi_gpio_init(void)
+{
+ return sfi_table_parse(SFI_SIG_GPIO, NULL, NULL, sfi_gpio_parse);
+}
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a..2828da0 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -67,6 +67,7 @@
#include
#include
#include
+#include
#include
#include "sfi_core.h"
@@ -512,6 +513,12 @@ void __init sfi_init_late(void)
syst_va = sfi_map_memory(syst_pa, length);
sfi_acpi_init();
+
+ /*
+* Parsing GPIO table first, since the DEVS table will need this table
+* to map the pin name to the actual pin.
+*/
+ sfi_gpio_init();
}
/*
diff --git a/include/linux/sfi_gpio.h b/include/linux/sfi_gpio.h
new file mode 100644
index 000..ef7e497
--- /dev/null
+++ b/include/linux/sfi_gpio.h
@@ -0,0 +1,27 @@
+#ifndef _LINUX_SFI_GPIO_H_
+#define _LINUX_SFI_GPIO_H_
+
+#include
+#include
+#include
+
+#ifdef CONFIG_GPIO_SFI
+
+int sfi_get_gpio_by_name(const char *name);
+int __init sfi_gpio_init(void);
+
+#else /* CONFIG_GPIO_SFI */
+
+static inline int sfi_get_gpio_by_name(const char *name);
+{
+ return -1;
+}
+
+static inline int __init sfi_gpio_init(void)
+{
+ return -ENODEV;
+}
+
+#endif /* CONFIG_GPIO_SFI */
+
+#endif /* _LINUX_SFI_GPIO_H_ */
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH v2 3/9] bitops: Introduce a more generic BITMASK macro
On Wed, 2013-10-16 at 10:56 -0400, Chen, Gong wrote: > GENMASK is used to create a contiguous bitmask([hi:lo]). It is > implemented twice in current kernel. One is in EDAC driver, the other > is in SiS/XGI FB driver. Move it to a more generic place for other > usage. [] > diff --git a/include/linux/bitops.h b/include/linux/bitops.h [] > @@ -10,6 +10,14 @@ > #define BITS_TO_LONGS(nr)DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) > #endif > > +/* > + * Create a contiguous bitmask starting at bit position @l and ending at > + * position @h. For example > + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. ull > + */ > +#define GENMASK(h, l)(((U32_C(1) << ((h) - (l) + 1)) - 1) << > (l)) > +#define GENMASK_ULL(h, l)(((U64_C(1) << ((h) - (l) + 1)) - 1) << (l)) Maybe add a BUILD_BUG_ON(__builtin_constant_p(l) && __builtin_constant_p(h) && \ (h) < (l)) -- 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] sfi: fix compiler warnings
From: Andy Shevchenko
drivers/sfi/sfi_core.c:164:26: warning: no previous prototype for
‘sfi_map_table’ [-Wmissing-prototypes]
drivers/sfi/sfi_core.c:192:6: warning: no previous prototype for
‘sfi_unmap_table’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko
Cc: Kuppuswamy Sathyanarayanan
Cc: David Cohen
Cc: Len Brown
---
drivers/sfi/sfi_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 1e824fb..296db7a 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -161,7 +161,7 @@ static int sfi_verify_table(struct sfi_table_header *table)
* Check for common case that we can re-use mapping to SYST,
* which requires syst_pa, syst_va to be initialized.
*/
-struct sfi_table_header *sfi_map_table(u64 pa)
+static struct sfi_table_header *sfi_map_table(u64 pa)
{
struct sfi_table_header *th;
u32 length;
@@ -189,7 +189,7 @@ struct sfi_table_header *sfi_map_table(u64 pa)
* Undoes effect of sfi_map_table() by unmapping table
* if it did not completely fit on same page as SYST.
*/
-void sfi_unmap_table(struct sfi_table_header *th)
+static void sfi_unmap_table(struct sfi_table_header *th)
{
if (!TABLE_ON_PAGE(syst_va, th, th->len))
sfi_unmap_memory(th, TABLE_ON_PAGE(th, th, th->len) ?
--
1.8.4.rc3
--
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] rcu: Create rcu_sync infrastructure
On 10/08/2013 06:25 PM, Peter Zijlstra wrote:
> From: Oleg Nesterov
>
> It is functionally equivalent to
>
> struct rcu_sync_struct {
> atomic_t counter;
> };
>
> static inline bool rcu_sync_is_idle(struct rcu_sync_struct *xxx)
> {
> return atomic_read(>counter) == 0;
> }
>
> static inline void rcu_sync_enter(struct rcu_sync_struct *xxx)
> {
> atomic_inc(>counter);
> synchronize_sched();
> }
>
> static inline void rcu_sync_enter(struct rcu_sync_struct *xxx)
> {
> synchronize_sched();
> atomic_dec(>counter);
> }
>
> except: it records the state and synchronize_sched() is only called by
> rcu_sync_enter() and only if necessary.
>
> Signed-off-by: Oleg Nesterov
> Reviewed-by: Paul McKenney
> Signed-off-by: Peter Zijlstra
> Link: http://lkml.kernel.org/r/20130929183634.ga15...@redhat.com
> ---
> include/linux/rcusync.h | 64
> kernel/Makefile |3 -
> kernel/rcusync.c| 108
>
> 3 files changed, 174 insertions(+), 1 deletion(-)
>
> --- /dev/null
> +++ b/include/linux/rcusync.h
> @@ -0,0 +1,64 @@
> +#ifndef _LINUX_RCUSYNC_H_
> +#define _LINUX_RCUSYNC_H_
> +
> +#include
> +#include
> +
> +struct rcu_sync_struct {
> + int gp_state;
> + int gp_count;
> + wait_queue_head_t gp_wait;
> +
> + int cb_state;
> + struct rcu_head cb_head;
> +
> + void (*sync)(void);
> + void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> +};
> +
> +#define ___RCU_SYNC_INIT(name)
> \
> + .gp_state = 0, \
> + .gp_count = 0, \
> + .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> + .cb_state = 0
> +
> +#define __RCU_SCHED_SYNC_INIT(name) {
> \
> + ___RCU_SYNC_INIT(name), \
> + .sync = synchronize_sched, \
> + .call = call_rcu_sched, \
> +}
> +
> +#define __RCU_BH_SYNC_INIT(name) { \
> + ___RCU_SYNC_INIT(name), \
> + .sync = synchronize_rcu_bh, \
> + .call = call_rcu_bh,\
> +}
> +
> +#define __RCU_SYNC_INIT(name) {
> \
> + ___RCU_SYNC_INIT(name), \
> + .sync = synchronize_rcu,\
> + .call = call_rcu, \
> +}
> +
> +#define DEFINE_RCU_SCHED_SYNC(name) \
> + struct rcu_sync_struct name = __RCU_SCHED_SYNC_INIT(name)
> +
> +#define DEFINE_RCU_BH_SYNC(name) \
> + struct rcu_sync_struct name = __RCU_BH_SYNC_INIT(name)
> +
> +#define DEFINE_RCU_SYNC(name)
> \
> + struct rcu_sync_struct name = __RCU_SYNC_INIT(name)
> +
> +static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
> +{
> + return !rss->gp_state; /* GP_IDLE */
> +}
Hi, All
We may need to use ACCESS_ONCE() here to avoid the compiler access it
multi-times.
it would be better: return ACCESS_ONCE(rss->gp_state) == GP_IDLE;
-my comment continues until it reaches a "Thanks".-
> +
> +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
> +
> +extern void rcu_sync_init(struct rcu_sync_struct *, enum rcu_sync_type);
> +extern void rcu_sync_enter(struct rcu_sync_struct *);
> +extern void rcu_sync_exit(struct rcu_sync_struct *);
> +
> +#endif /* _LINUX_RCUSYNC_H_ */
> +
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -10,7 +10,8 @@ obj-y = fork.o exec_domain.o panic.o
> kthread.o wait.o sys_ni.o posix-cpu-timers.o mutex.o \
> hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \
> notifier.o ksysfs.o cred.o reboot.o \
> - async.o range.o groups.o lglock.o smpboot.o
> + async.o range.o groups.o lglock.o smpboot.o \
> + rcusync.o
>
> ifdef CONFIG_FUNCTION_TRACER
> # Do not trace debug files and internal ftrace files
> --- /dev/null
> +++ b/kernel/rcusync.c
> @@ -0,0 +1,108 @@
> +
> +#include
> +#include
> +
> +enum { GP_IDLE = 0, GP_PENDING, GP_PASSED };
> +enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY };
> +
> +#define rss_lockgp_wait.lock
> +
> +void rcu_sync_init(struct rcu_sync_struct *rss, enum rcu_sync_type type)
> +{
> + memset(rss, 0, sizeof(*rss));
> +
Re: [PATCH] ACPI/Power: Check physical device's runtime pm status before requesting to resume it
On 2013年10月17日 09:02, Lan Tianyu wrote:
> On 2013年10月16日 20:42, Rafael J. Wysocki wrote:
>> On Wednesday, October 16, 2013 05:26:21 PM Lan Tianyu wrote:
>>> This is a multi-part message in MIME format.
>>> --090400010209000300030201
>>> Content-Type: text/plain; charset=UTF-8
>>> Content-Transfer-Encoding: 8bit
>>>
>>> On 10/16/2013 05:22 AM, Rafael J. Wysocki wrote:
On Tuesday, October 15, 2013 04:58:28 PM Lan Tianyu wrote:
> On 2013å¹´10æ11æ¥ 19:19, Rafael J. Wysocki wrote:
>> On Friday, October 11, 2013 04:16:25 PM tianyu@intel.com
>> wrote:
>>> From: Lan Tianyu
>>>
>>> Currently, when one power resource is turned on, devices owning
>>> it will be requested to resume regardless of their runtime pm
>>> status. ACPI power resource maybe turn on in some devices'
>>> runtime pm resume callback(E.G, usb port) while turning on the
>>> power resource will trigger one new resume request of the
>>> device. It causes infinite loop between resume and suspend.
>>> This has happened on clearing usb port's PM Qos NO_POWER_OFF
>>> flag twice. This patch is to add check of physical device's
>>> runtime pm status and request resume if the device is
>>> suspended.
>>>
>>> Signed-off-by: Lan Tianyu ---
>>> drivers/acpi/power.c | 6 -- 1 file changed, 4
>>> insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index
>>> 0dbe5cd..228c138 100644 --- a/drivers/acpi/power.c +++
>>> b/drivers/acpi/power.c @@ -250,8 +250,10 @@ static void
>>> acpi_power_resume_dependent(struct work_struct *work)
>>>
>>> mutex_lock(>physical_node_lock);
>>>
>>> - list_for_each_entry(pn, >physical_node_list, node) -
>>> pm_request_resume(pn->dev); + list_for_each_entry(pn,
>>> >physical_node_list, node) { +if
>>> (pm_runtime_suspended(pn->dev)) + pm_request_resume(pn->dev);
>>> + }
>>
>> This is racy, because the status may change right after you check
>> it and before you call pm_request_resume().
>
> Yes, the runtime status may be changed just after the check.
>
>>
>> Besides, pm_request_resume() checks the status of the device and
>> won't try to resume it if it is not suspended.
>>
>
> For this issue, usb port is in the RPM_SUSPENDING state when
> pm_request_resume() is called.
Why exactly does that happen?
> The deferred_resume will be set to true during this procedure and
> trigger resume after finishing suspend. USB port runtime resume
> callback will turn on its power resource again and the work of
> acpi_power_resume_dependent() is scheduled. Because the usb port's
> usage count remains zero, it's to be suspended soon. When
> pm_request_resume() of acpi_power_resume_dependent() is called, the
> usb port is always in the PRM_SUSPENDING. Fall in the loop of
> suspend and resume.
>
> How about running acpi_power_dependent when turning on power
> resource rather than scheduling a work to run it?
Is this actually going to help? Even if
acpi_power_resume_dependent() is run synchronously from within the
resume callback, it will still see RPM_SUSPENDING as the device's
status, won't it?
> After this, pm_request_resume() can check device's right status
> just after turning on power resource.
The status doesn't change until the .runtime_suspend() callback
returns and running pm_request_resume() syncrhonously from that
callback for the device being suspended just plain doesn't make
sense.
Can you please explain to me how this is possible that the USB port's
power resource is turned "on" while the port is RPM_SUSPENDING?
>>> [This mail seems not to be sent to maillist. So resend. Try again
>>> Sorry for noise]
>>>
>>>
>>> Hi Rafael:
>>>
>>> No, I mean the acpi_power_resume_dependent() is running while the port's
>>> status is RPM_SUSPENDING. It runs from a work item and turning on power
>>> resource adds the work to workqueue. There is a timeslot between running
>>> acpi_power_resume_dependent() and turning on power resource. In the
>>> timeslot, the device runtime pm status maybe change.
>>>
>>> In this case, changing PM Qos flag will do pm_runtime_get_sync and
>>> pm_runtime_put usb port. The usb port is without device attached and so
>>> it will be resumed and suspended soon during changing PM Qos flag.
>>>
>>> Resume callback turns on power resource if NO_POWER_OFF flag has been
>>> cleared and add the work of acpi_power_resume_dependent() to
>>> workqueue. After resume, the usb port will be suspended while the
>>> acpi_power_resume_dependent() is running. pm_request_resume() gets
>>> RPM_SUSPENDING as the usb port's runtime status and set the
>>> deferred_resume of usb port.
>>>
>>> After suspend, usb port will be resumed again and
Re: [Bug] 12.864681 BUG: lock held when returning to user space!
On 10/17/2013 06:41 AM, Douglas Gilbert wrote: > That seems to be the case. Vaughan acknowledged the > problem and forwarded it to me 8 days ago. Yes, it > seems to be a "no-no" to hold a any kernel semaphore > when returning to the user space; in this case from > sg_open(). I was hoping a revised patch might > appear from Vaughan but to date that has not been > the case. So with only a few weeks to go before > lk 3.12 is released, reverting the whole 4 patches > in that series seems to be the safest course. > > Also without a new patch from Vaughan in the next few > weeks he may also miss the opportunity of getting > his improved O_EXCL logic into the lk 3.13 series. > > > Thinking about how to solve this problem: a field could > be added to 'struct sg_device' with one of three states: > no_opens, non_excl_opens and excl_open. It could be > manipulated by sg_open() and sg_release() like a > read-write semaphore. And the faulty 'struct > rw_semaphore o_sem' in sg_device could be replaced by a > normal semaphore to protect the manipulation of the new > three-state field. > And the new three-state field would replace (or expand) the 'char exclude' field in struct sg_device . > > Doug Gilbert Hi Doug, Thanks for providing advice on how to fix this. However, it seems be still awkward somehow. We have to 1. hold a lock (maybe sg_index_lock or a new one) 2. check a) the new three-state field; b) if sfp list is empty; c) sdp->detached field; if either condition fails, we may link the open process into o_excl_wait queue and need wakeup. if satisfied, we go on. 3. then we release at least sg_index_lock to malloc a new sfp and initialize. 4. try to acquire sg_index_lock again and add this sfp into sfd_siblings list if possible. <== We still have to check at least sdp->detached field 5. update three-state field to reflect the result of Step 4, and wake up processes waiting in o_excl_wait. This uncomfortable is introduced by releasing the sg_index_lock in the middle of check->malloc->add the new sfp struct. I wanna ask if it is possible to split the sg_add_sfp() into two functions, sg_init_sfp() and sg_add_sfp2(). We can do all initialize work in sg_init_sfp() without any lock and let sg_add_sfp2() only serve lock-check-add in one way. It seems more convenient for me to understand. But there is still some questions on this approach: 1. memory consume can be very large if lots of sg_init_sfp in the same time; 2. some field are initialized according to the fields of scsi device sdp points to, such as low_dma, sg_tablesize, max_sector, phys_segs. I know scsi_device_get() would keep the underlying scsi_device alive, however would these fields change in the gap of our initialize and add? The relationship of sg_device and scsi_device like above said confuse me somehow... Thanks, Vaughan -- 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 3/9] bitops: Introduce a more generic BITMASK macro
On Wed, Oct 16, 2013 at 02:02:21PM -0300, Mauro Carvalho Chehab wrote: > Date: Wed, 16 Oct 2013 14:02:21 -0300 > From: Mauro Carvalho Chehab > To: "Chen, Gong" > Cc: tony.l...@intel.com, b...@alien8.de, j...@perches.com, > naveen.n@linux.vnet.ibm.com, aroza...@redhat.com, > linux-a...@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas > Winischhofer , Jean-Christophe Plagniol-Villard > , Tomi Valkeinen > Subject: Re: [PATCH v2 3/9] bitops: Introduce a more generic BITMASK macro > X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) > > Em Wed, 16 Oct 2013 10:56:00 -0400 > "Chen, Gong" escreveu: > > > GENMASK is used to create a contiguous bitmask([hi:lo]). It is > > implemented twice in current kernel. One is in EDAC driver, the other > > is in SiS/XGI FB driver. Move it to a more generic place for other > > usage. > > > > Signed-off-by: Chen, Gong > > Cc: Borislav Petkov > > Cc: Thomas Winischhofer > > Cc: Jean-Christophe Plagniol-Villard > > Cc: Tomi Valkeinen > > Acked-by: Mauro Carvalho Chehab > > Btw, there's another incarnation of it at sb_edac.c (GET_BITFIELD). > It could make sense to also replace it by the newly bitops.h macro. > > Regards, > Mauro Aha, I will update it in the next version. signature.asc Description: Digital signature
[PATCH] fuelguage: max17042: Support regmap to access device's registers.
This patch makes max17042 fuelguage driver uses regmap API to access
its device's registers.
It's based on linux-next.
Signed-off-by: Jonghwa Lee
Signed-off-by: Myungjoo Ham
---
drivers/power/max17042_battery.c | 357 +++---
1 file changed, 174 insertions(+), 183 deletions(-)
diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index d664ef5..0382cb5 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/* Status register bits */
#define STATUS_POR_BIT (1 << 1)
@@ -67,6 +68,7 @@
struct max17042_chip {
struct i2c_client *client;
+ struct regmap *regmap;
struct power_supply battery;
enum max170xx_chip_type chip_type;
struct max17042_platform_data *pdata;
@@ -74,35 +76,6 @@ struct max17042_chip {
intinit_complete;
};
-static int max17042_write_reg(struct i2c_client *client, u8 reg, u16 value)
-{
- int ret = i2c_smbus_write_word_data(client, reg, value);
-
- if (ret < 0)
- dev_err(>dev, "%s: err %d\n", __func__, ret);
-
- return ret;
-}
-
-static int max17042_read_reg(struct i2c_client *client, u8 reg)
-{
- int ret = i2c_smbus_read_word_data(client, reg);
-
- if (ret < 0)
- dev_err(>dev, "%s: err %d\n", __func__, ret);
-
- return ret;
-}
-
-static void max17042_set_reg(struct i2c_client *client,
-struct max17042_reg_data *data, int size)
-{
- int i;
-
- for (i = 0; i < size; i++)
- max17042_write_reg(client, data[i].addr, data[i].data);
-}
-
static enum power_supply_property max17042_battery_props[] = {
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_CYCLE_COUNT,
@@ -125,96 +98,98 @@ static int max17042_get_property(struct power_supply *psy,
{
struct max17042_chip *chip = container_of(psy,
struct max17042_chip, battery);
+ struct regmap *map = chip->regmap;
int ret;
+ u32 data;
if (!chip->init_complete)
return -EAGAIN;
switch (psp) {
case POWER_SUPPLY_PROP_PRESENT:
- ret = max17042_read_reg(chip->client, MAX17042_STATUS);
+ ret = regmap_read(map, MAX17042_STATUS, );
if (ret < 0)
return ret;
- if (ret & MAX17042_STATUS_BattAbsent)
+ if (data & MAX17042_STATUS_BattAbsent)
val->intval = 0;
else
val->intval = 1;
break;
case POWER_SUPPLY_PROP_CYCLE_COUNT:
- ret = max17042_read_reg(chip->client, MAX17042_Cycles);
+ ret = regmap_read(map, MAX17042_Cycles, );
if (ret < 0)
return ret;
- val->intval = ret;
+ val->intval = data;
break;
case POWER_SUPPLY_PROP_VOLTAGE_MAX:
- ret = max17042_read_reg(chip->client, MAX17042_MinMaxVolt);
+ ret = regmap_read(map, MAX17042_MinMaxVolt, );
if (ret < 0)
return ret;
- val->intval = ret >> 8;
+ val->intval = data >> 8;
val->intval *= 2; /* Units of LSB = 20mV */
break;
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
if (chip->chip_type == MAX17042)
- ret = max17042_read_reg(chip->client, MAX17042_V_empty);
+ ret = regmap_read(map, MAX17042_V_empty, );
else
- ret = max17042_read_reg(chip->client, MAX17047_V_empty);
+ ret = regmap_read(map, MAX17047_V_empty, );
if (ret < 0)
return ret;
- val->intval = ret >> 7;
+ val->intval = data >> 7;
val->intval *= 1; /* Units of LSB = 10mV */
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
- ret = max17042_read_reg(chip->client, MAX17042_VCELL);
+ ret = regmap_read(map, MAX17042_VCELL, );
if (ret < 0)
return ret;
- val->intval = ret * 625 / 8;
+ val->intval = data * 625 / 8;
break;
case POWER_SUPPLY_PROP_VOLTAGE_AVG:
- ret = max17042_read_reg(chip->client, MAX17042_AvgVCELL);
+ ret = regmap_read(map, MAX17042_AvgVCELL, );
if (ret < 0)
return ret;
- val->intval = ret * 625 / 8;
+ val->intval = data * 625 / 8;
break;
case POWER_SUPPLY_PROP_VOLTAGE_OCV:
- ret = max17042_read_reg(chip->client, MAX17042_OCVInternal);
+ ret = regmap_read(map, MAX17042_OCVInternal, );
[PATCH v8 12/12] intel_mid: move board related codes to their own platform_.* files
As Intel rolling out more SoC's after Moorestown, we need to re-structure the code in a way that is backward compatible and easy to expand. This patch implements a flexible way to support multiple boards and devices. This patch does not add any new functional support. It just refactors the existing code to increase the modularity and decrease the code duplication for supporting multiple soc's and boards. Currently intel-mid.c has both board and soc related code in one file. This patch moves the board related code to new files and let linker script to create SFI devite table following this: 1. Move the SFI device specific code to arch/x86/platform/intel-mid/device-libs/platform_.* A new device file is added for every supported device. This code will get conditionally compiled by using corresponding device driver CONFIG option. 2. Move the device_ids location to .x86_intel_mid_dev.init section by using new sfi_device() macro. This patch was based on previous code from Sathyanarayanan Kuppuswamy. Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: David Cohen --- Changes from v7 to v8: - added missing platform_bma023.c files arch/x86/include/asm/intel-mid.h | 16 + arch/x86/platform/intel-mid/Makefile | 6 +- arch/x86/platform/intel-mid/device_libs/Makefile | 22 ++ .../intel-mid/device_libs/platform_bma023.c| 20 + .../intel-mid/device_libs/platform_emc1403.c | 41 ++ .../intel-mid/device_libs/platform_gpio_keys.c | 83 .../platform/intel-mid/device_libs/platform_ipc.c | 68 .../platform/intel-mid/device_libs/platform_ipc.h | 17 + .../intel-mid/device_libs/platform_lis331.c| 39 ++ .../intel-mid/device_libs/platform_max3111.c | 35 ++ .../intel-mid/device_libs/platform_max7315.c | 79 .../intel-mid/device_libs/platform_mpu3050.c | 36 ++ .../platform/intel-mid/device_libs/platform_msic.c | 87 + .../platform/intel-mid/device_libs/platform_msic.h | 19 + .../intel-mid/device_libs/platform_msic_audio.c| 47 +++ .../intel-mid/device_libs/platform_msic_battery.c | 37 ++ .../intel-mid/device_libs/platform_msic_gpio.c | 48 +++ .../intel-mid/device_libs/platform_msic_ocd.c | 49 +++ .../device_libs/platform_msic_power_btn.c | 36 ++ .../intel-mid/device_libs/platform_msic_thermal.c | 37 ++ .../intel-mid/device_libs/platform_pmic_gpio.c | 54 +++ .../intel-mid/device_libs/platform_tc35876x.c | 36 ++ .../intel-mid/device_libs/platform_tca6416.c | 57 +++ arch/x86/platform/intel-mid/intel-mid.c| 419 - arch/x86/platform/intel-mid/sfi.c | 14 +- include/linux/sfi.h| 3 + 26 files changed, 976 insertions(+), 429 deletions(-) create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.h create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max3111.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.h create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_audio.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_battery.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_gpio.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_ocd.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_power_btn.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_thermal.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_pmic_gpio.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tca6416.c diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h index 3b0e7a7..2838942 100644 --- a/arch/x86/include/asm/intel-mid.h +++ b/arch/x86/include/asm/intel-mid.h @@ -12,8 +12,11 @@ #define _ASM_X86_INTEL_MID_H #include +#include extern int intel_mid_pci_init(void); +extern int get_gpio_by_name(const char *name); +extern void intel_scu_device_register(struct platform_device *pdev); extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
Re: [PATCH] Release device_hotplug_lock when store_mem_state returns EINVAL
(2013/10/12 1:31), Toshi Kani wrote:
On Fri, 2013-10-11 at 15:36 +0900, Yasuaki Ishimatsu wrote:
When inserting a wrong value to /sys/devices/system/memory/memoryX/state file,
following messages are shown. And device_hotplug_lock is never released.
[ BUG: lock held when returning to user space! ]
3.12.0-rc4-debug+ #3 Tainted: GW
bash/6442 is leaving the kernel with locks still held!
1 lock held by bash/6442:
#0: (device_hotplug_lock){+.+.+.}, at: []
lock_device_hotplug_sysfs+0x15/0x50
This issue was introdued by commit fa2be40 (drivers: base: use standard
device online/offline for state change).
This patch releases device_hotplug_lcok when store_mem_state returns EINVAL.
Signed-off-by: Yasuaki Ishimatsu
CC: Toshi Kani
CC: Seth Jennings
CC: Greg Kroah-Hartman
Good catch!
Reviewed-by: Toshi Kani
Thank you for your review.
Thanks,
Yasuaki Ishimatsu
Thanks,
-Toshi
--
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] usb: usb_phy_gen: refine conditional declaration of usb_nop_xceiv_register
Commit 3fa4d734 (usb: phy: rename nop_usb_xceiv => usb_phy_gen_xceiv)
changed the conditional around the declaration of usb_nop_xceiv_register
from
#if defined(CONFIG_NOP_USB_XCEIV) ||
(defined(CONFIG_NOP_USB_XCEIV_MODULE) && defined(MODULE))
to
#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
While that looks the same, it is semantically different. The first expression
is true if CONFIG_NOP_USB_XCEIV is built as module and if the including
code is built as module. The second expression is true if code depending on
CONFIG_NOP_USB_XCEIV if built as module or into the kernel.
As a result, the arm:allmodconfig build fails with
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
arch/arm/mach-omap2/board-omap3evm.c:703: undefined reference to
`usb_nop_xceiv_register'
Fix the problem by reverting to the old conditional.
Cc: Josh Boyer
Signed-off-by: Guenter Roeck
---
include/linux/usb/usb_phy_gen_xceiv.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb/usb_phy_gen_xceiv.h
b/include/linux/usb/usb_phy_gen_xceiv.h
index f9a7e7b..11d85b9 100644
--- a/include/linux/usb/usb_phy_gen_xceiv.h
+++ b/include/linux/usb/usb_phy_gen_xceiv.h
@@ -12,7 +12,7 @@ struct usb_phy_gen_xceiv_platform_data {
unsigned int needs_reset:1;
};
-#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
+#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE) &&
defined(MODULE))
/* sometimes transceivers are accessed only through e.g. ULPI */
extern void usb_nop_xceiv_register(void);
extern void usb_nop_xceiv_unregister(void);
--
1.7.9.7
--
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 4/6] rcusync: Introduce struct rcu_sync_ops
On 10/08/2013 06:25 PM, Peter Zijlstra wrote:
> From: Oleg Nesterov
>
> Add the new struct rcu_sync_ops which holds sync/call methods, and
> turn the function pointers in rcu_sync_struct into an array of struct
> rcu_sync_ops.
Hi, Paul
I think this work should be done in rcupdate.[ch] side by introducing struct
rcu_flavor.
Thanks,
Lai
>
> This simplifies the "init" helpers, and this way it is simpler to add
> the new methods we need, especially ifdef'ed.
>
> Signed-off-by: Peter Zijlstra
> Link: http://lkml.kernel.org/r/20131005171746.ga17...@redhat.com
> ---
>
> diff --git a/include/linux/rcusync.h b/include/linux/rcusync.h
> index 7858491..988ec33 100644
> --- a/include/linux/rcusync.h
> +++ b/include/linux/rcusync.h
> @@ -4,6 +4,8 @@
> #include
> #include
>
> +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
> +
> struct rcu_sync_struct {
> int gp_state;
> int gp_count;
> @@ -12,53 +14,37 @@ struct rcu_sync_struct {
> int cb_state;
> struct rcu_head cb_head;
>
> - void (*sync)(void);
> - void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> + enum rcu_sync_type gp_type;
> };
>
> -#define ___RCU_SYNC_INIT(name)
> \
> - .gp_state = 0, \
> - .gp_count = 0, \
> - .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> - .cb_state = 0
> -
> -#define __RCU_SCHED_SYNC_INIT(name) {
> \
> - ___RCU_SYNC_INIT(name), \
> - .sync = synchronize_sched, \
> - .call = call_rcu_sched, \
> -}
> -
> -#define __RCU_BH_SYNC_INIT(name) { \
> - ___RCU_SYNC_INIT(name), \
> - .sync = synchronize_rcu_bh, \
> - .call = call_rcu_bh,\
> -}
> -
> -#define __RCU_SYNC_INIT(name) {
> \
> - ___RCU_SYNC_INIT(name), \
> - .sync = synchronize_rcu,\
> - .call = call_rcu, \
> -}
> -
> -#define DEFINE_RCU_SCHED_SYNC(name) \
> - struct rcu_sync_struct name = __RCU_SCHED_SYNC_INIT(name)
> -
> -#define DEFINE_RCU_BH_SYNC(name) \
> - struct rcu_sync_struct name = __RCU_BH_SYNC_INIT(name)
> -
> -#define DEFINE_RCU_SYNC(name)
> \
> - struct rcu_sync_struct name = __RCU_SYNC_INIT(name)
> -
> static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
> {
> return !rss->gp_state; /* GP_IDLE */
> }
>
> -enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
> -
> extern void rcu_sync_init(struct rcu_sync_struct *, enum rcu_sync_type);
> extern void rcu_sync_enter(struct rcu_sync_struct *);
> extern void rcu_sync_exit(struct rcu_sync_struct *);
>
> +#define __RCU_SYNC_INITIALIZER(name, type) { \
> + .gp_state = 0, \
> + .gp_count = 0, \
> + .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> + .cb_state = 0, \
> + .gp_type = type,\
> + }
> +
> +#define __DEFINE_RCU_SYNC(name, type) \
> + struct rcu_sync_struct name = __RCU_SYNC_INITIALIZER(name, type)
> +
> +#define DEFINE_RCU_SYNC(name)\
> + __DEFINE_RCU_SYNC(name, RCU_SYNC)
> +
> +#define DEFINE_RCU_SCHED_SYNC(name) \
> + __DEFINE_RCU_SYNC(name, RCU_SCHED_SYNC)
> +
> +#define DEFINE_RCU_BH_SYNC(name) \
> + __DEFINE_RCU_SYNC(name, RCU_BH_SYNC)
> +
> #endif /* _LINUX_RCUSYNC_H_ */
>
> diff --git a/kernel/rcusync.c b/kernel/rcusync.c
> index f84176a..99051b7 100644
> --- a/kernel/rcusync.c
> +++ b/kernel/rcusync.c
> @@ -1,7 +1,24 @@
> -
> #include
> #include
>
> +static const struct {
> + void (*sync)(void);
> + void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> +} gp_ops[] = {
> + [RCU_SYNC] = {
> + .sync = synchronize_rcu,
> + .call = call_rcu,
> + },
> + [RCU_SCHED_SYNC] = {
> + .sync = synchronize_sched,
> + .call = call_rcu_sched,
> + },
> + [RCU_BH_SYNC] = {
> + .sync = synchronize_rcu_bh,
> + .call = call_rcu_bh,
> + },
> +};
> +
> enum { GP_IDLE = 0, GP_PENDING, GP_PASSED };
> enum {
Re: [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check
On 10/03/2013 08:58 AM, Mark Brown wrote: On Wed, Oct 02, 2013 at 09:15:22PM -0700, Guenter Roeck wrote: irq_of_parse_and_map() returns 0 on error, not NO_IRQ. Applied, thanks. Hi Mark, do you plan to send this patch upstream anytime soon ? It fixes an xtensa build problem, so it would be great if it could find its way into 3.13. 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: BUG report about ipt_do_table( )
Hi Will, I am happy to notify that our stability test has passed, And this Crash don't happen again, So seems this patch work now . We has merged it into our release SW . Could I know if this patch will be delivered into kernel Mainline by you ? Thanks again ! -Original Message- From: Wang, Yalin Sent: Friday, October 11, 2013 7:15 PM To: 'Will Deacon' Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng, Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2 Subject: RE: BUG report about ipt_do_table( ) Hi Will, Thanks for your clarification . I have merged the patch, And need wait some time to get The test result , You know that this BUG is not easy to reproduce, It's very infrequent. Maybe we need run several times stability test to Make sure the patch works . I will update to you the result as soon as possible ! Thanks -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Friday, October 11, 2013 7:03 PM To: Wang, Yalin Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng, Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2 Subject: Re: BUG report about ipt_do_table( ) On Fri, Oct 11, 2013 at 02:50:24AM +0100, Wang, Yalin wrote: > Hi Will, Hello again, > Maybe I know your meaning , > If it use spinlock to protected the shared data, The bug will not > happen, because spinlock will Use DSB( ) to sync . Actually, the dsb is for something else (the sev). It is the smp_mb() call which guarantees the ordering of critical sections with respect to spinlock operations. > Unluckily, here, it use a special seqcount_t( ) (see get_counters( ) > function) Well, there is a comment about a write_lock being held, so you should be ok if that's true. The issue I saw was with the newinfo population, as I described in my earlier mail. > To make sure there is no others using the old data, Before release the > old data, this is much like RCU Work, but RCU use rcu_assign_pointer( > ) --> Which use smp_wmb( ) , so it's safe, am I right ? RCU is safe. There are *many* weakly ordered architectures on which Linux runs, so I don't think you have to worry too much about the core data structures and locking/synchronisation/atomic primitives. The major scope for errors is in lockless code, where the barrier usage is explicit. > In my patch, I use mb( ), because this macro Is DSB( ) , while > smp_wmb( ) is DMS( ), I just think DSB is much strict than DMS, mmm.. > so , DSM( ) or DMS ( ) are both ok ? I think you're getting confused with your barriers. We have two memory barriers on ARM: dmb and dsb. dmb is sufficient to enforce ordering of observability. dsb is used to enforce completion. > The whitepaper I use is here: > https://www.google.com/#q=cortex+a15+microarchitecture > > the first: [PDF] Exploring the Design of the Cortex-A15 Processor - > ARM > > I just search in Google, and you know that qcom don't release Much > document about its krait cpu's micro architecture details, I just use > cortex-a15 for a reference, I am not sure if their pipeline ( > load/store unit) are the same, I think the lawyers would have a field day if the pipelines were the same! You really can't use an A15 slide-deck to infer micro-architectural details about Krait. Please can you test the patch I sent you yesterday? Will -- 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] MAINTAINERS: Add Kumar to Device Tree Binding maintainers group
On Oct 16, 2013, at 5:56 PM, Rob Herring wrote:
> On 08/08/2013 10:51 AM, Kumar Gala wrote:
>> I'm tossing my hat into the ring of maintainers/reviewers for device tree
>> bindings based on history of dealing with DT on embedded PPC and starting
>> work on ARM SoCs.
>>
>> Signed-off-by: Kumar Gala
>> Cc: Pawel Moll
>> Cc: Mark Rutland
>> Cc: Stephen Warren
>> Cc: Ian Campbell
>> Cc: Rob Herring
>> Cc: Grant Likely
>> Cc: Olof Johansson
>> ---
>
> Seems this one got lost. I assume you still want to drink from the fire
> hose, so I've applied it.
>
> Rob
Yeah, thanks. Figured I'd bring it up at the DT summit if it hadn't been
applied.
I'd like to hopefully spend a little time on DT review process:
* split list for binding reviews vs .dts{i}
* look at using patchworks to have some 'assignment' of lead reviewer.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of 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: [PATCH] x86: Run checksumming in parallel accross multiple alu's
On Wed, 2013-10-16 at 20:34 -0400, Neil Horman wrote: > > > > So I went to reproduce these results, but was unable to (due to the fact that > I > only have a pretty jittery network to do testing accross at the moment with > these devices). So instead I figured that I would go back to just doing > measurements with the module that I cobbled together (operating under the > assumption that it would give me accurate, relatively jitter free results > (I've > attached the module code for reference below). My results show slightly > different behavior: > > Base results runs: > 89417240 > 85170397 > 85208407 > 89422794 > 91645494 > 103655144 > 86063791 > 75647774 > 83502921 > 85847372 > AVG = 875 ns > > Prefetch only runs: > 70962849 > 77555099 > 81898170 > 68249290 > 72636538 > 83039294 > 78561494 > 83393369 > 85317556 > 79570951 > AVG = 781 ns > > Parallel addition only runs: > 42024233 > 44313064 > 48304416 > 64762297 > 42994259 > 41811628 > 55654282 > 64892958 > 55125582 > 42456403 > AVG = 510 ns > > > Both prefetch and parallel addition: > 41329930 > 40689195 > 61106622 > 46332422 > 49398117 > 52525171 > 49517101 > 61311153 > 43691814 > 49043084 > AVG = 494 ns > > > For reference, each of the above large numbers is the number of nanoseconds > taken to compute the checksum of a 4kb buffer 10 times. To get my average > results, I ran the test in a loop 10 times, averaged them, and divided by > 10. > > > Based on these, prefetching is obviously a a good improvement, but not as good > as parallel execution, and the winner by far is doing both. > > Thoughts? > > Neil > Your benchmark uses a single 4K page, so data is _super_ hot in cpu caches. ( prefetch should give no speedups, I am surprised it makes any difference) Try now with 32 huges pages, to get 64 MBytes of working set. Because in reality we never csum_partial() data in cpu cache. (Unless the NIC preloaded the data into cpu cache before sending the interrupt) Really, if Sebastien got a speed up, it means that something fishy was going on, like : - A copy of data into some area of memory, prefilling cpu caches - csum_partial() done while data is hot in cache. This is exactly a "should not happen" scenario, because the csum in this case should happen _while_ doing the copy, for 0 ns. -- 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][PATCH 1/8] mm: pcp: rename percpu pageset functions
On Tue, 15 Oct 2013, Dave Hansen wrote:
> diff -puN mm/page_alloc.c~rename-pageset-functions mm/page_alloc.c
> --- linux.git/mm/page_alloc.c~rename-pageset-functions2013-10-15
> 09:57:05.870612107 -0700
> +++ linux.git-davehans/mm/page_alloc.c2013-10-15 09:57:05.875612329
> -0700
> @@ -4136,10 +4136,18 @@ static void pageset_update(struct per_cp
> pcp->batch = batch;
> }
>
> -/* a companion to pageset_set_high() */
> -static void pageset_set_batch(struct per_cpu_pageset *p, unsigned long batch)
> +/*
> + * Set the batch size for hot per_cpu_pagelist, and derive
> + * the high water mark from the batch size.
> + */
> +static void pageset_setup_from_batch_size(struct per_cpu_pageset *p,
> + unsigned long batch)
> {
> - pageset_update(>pcp, 6 * batch, max(1UL, 1 * batch));
> + unsigned long high;
> + high = 6 * batch;
> + if (!batch)
> + batch = 1;
high = 6 * batch should be here?
> + pageset_update(>pcp, high, batch);
> }
>
> static void pageset_init(struct per_cpu_pageset *p)
> @@ -4158,15 +4166,15 @@ static void pageset_init(struct per_cpu_
> static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch)
> {
> pageset_init(p);
> - pageset_set_batch(p, batch);
> + pageset_setup_from_batch_size(p, batch);
> }
>
> /*
> - * pageset_set_high() sets the high water mark for hot per_cpu_pagelist
> - * to the value high for the pageset p.
> + * Set the high water mark for the per_cpu_pagelist, and derive
> + * the batch size from this high mark.
> */
> -static void pageset_set_high(struct per_cpu_pageset *p,
> - unsigned long high)
> +static void pageset_setup_from_high_mark(struct per_cpu_pageset *p,
> + unsigned long high)
> {
> unsigned long batch = max(1UL, high / 4);
> if ((high / 4) > (PAGE_SHIFT * 8))
> @@ -4179,11 +4187,11 @@ static void __meminit pageset_set_high_a
> struct per_cpu_pageset *pcp)
> {
> if (percpu_pagelist_fraction)
> - pageset_set_high(pcp,
> + pageset_setup_from_high_mark(pcp,
> (zone->managed_pages /
> percpu_pagelist_fraction));
> else
> - pageset_set_batch(pcp, zone_batchsize(zone));
> + pageset_setup_from_batch_size(pcp, zone_batchsize(zone));
> }
>
> static void __meminit zone_pageset_init(struct zone *zone, int cpu)
> @@ -5781,8 +5789,9 @@ int percpu_pagelist_fraction_sysctl_hand
> unsigned long high;
> high = zone->managed_pages / percpu_pagelist_fraction;
> for_each_possible_cpu(cpu)
> - pageset_set_high(per_cpu_ptr(zone->pageset, cpu),
> - high);
> + pageset_setup_from_high_mark(
> + per_cpu_ptr(zone->pageset, cpu),
> + high);
> }
> mutex_unlock(_batch_high_lock);
> return 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/
Re: linux-next: manual merge of the tip tree
On Wed, 16 Oct 2013 23:30:05 +0200 Peter Zijlstra
wrote:
> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> >
> > include/linux/wait.h
> >
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
> >
> > I've cleaned it up (see below). Please verify that the resolution looks
> > good.
>
> > +#define __wait_event_cmd(wq, condition, cmd1, cmd2)
> > \
> > +do {
> > \
> > + DEFINE_WAIT(__wait);\
> > + \
> > + for (;;) { \
> > + prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
> > + if (condition) \
> > + break; \
> > + cmd1; \
> > + schedule(); \
> > + cmd2; \
> > + } \
> > + finish_wait(, &__wait); \
> > +} while (0)
>
> Ideally we'd write the new thing like:
>
> #define __wait_event_cmd(wq, condition, cmd1, cmd2) \
> (void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0, \
> cmd1; schedule(); cmd2)
>
Oooo.. that looks much nicer. I'll make it look like that before it goes
upstream.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the tip tree
On Wed, 16 Oct 2013 22:52:07 +0200 Peter Zijlstra
wrote:
> Hey Neil;
>
> it looks like its one of your patches isn't it?
>
> http://www.spinics.net/lists/raid/msg44100.html
> http://www.spinics.net/lists/raid/msg44101.html
>
> Given that I can't find them in a lkml archive means nobody's ever seen
> those patches.
>
> Anyway; has that 3/3 patch ever been ran with lockdep enabled?
I always run with lockdep enabled, and I have done at least basic testing
(I've been on leave for a few weeks and don't remember exactly where I got
to).
And I haven't seen any lockdep reports.
>
> Stuff like:
>
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> + spin_lock_init(conf->hash_locks + i);
>
> And:
>
> +static void __lock_all_hash_locks(struct r5conf *conf)
> +{
> + int i;
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> + spin_lock(conf->hash_locks + i);
> +}
>
> Tends to complain real loud.
Why is that?
Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
each one, and when they are all locked it looks like nested locking??
the lock_all_hash_locks doesn't get called very often and my testing mustn't
have got that far. I just tried something that would trigger the
"lock_all_device_hash_locks_irq" (as it is in the current version) and it
went "splat" just as you said it would.
Thanks.
Do you have a suggestion for how to make this work?
Would
spin_lock_nested(conf->hash_locks + i, i)
do the trick?
Thanks,
NeilBrown
>
> This leaves one to wonder...
> 'fancy' locking scheme:1, validation effort:0
>
signature.asc
Description: PGP signature
Re: [PATCH] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED
On Sat, Oct 12, 2013 at 06:37:32AM +0200, Michael Opdenacker wrote: > This patch proposes to remove the use of the IRQF_DISABLED flag > > It's a NOOP since 2.6.35 and it will be removed one day. > > Signed-off-by: Michael Opdenacker > --- > drivers/bus/omap_l3_noc.c | 4 ++-- > drivers/bus/omap_l3_smx.c | 6 ++ > 2 files changed, 4 insertions(+), 6 deletions(-) These files aren't "mine", I suggest sending this to the OF maintainers that scripts/get_maintainer.pl points out for this patch. 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: [Question] Ask for arm arch timer
> -Original Message- > From: Catalin Marinas [mailto:catalin.mari...@arm.com] > Sent: 2013年10月16日 21:21 > To: Rob Herring > Cc: Neil Zhang; linux-kernel@vger.kernel.org; Yu Tang; Zhou Zhu; Will Deacon > Subject: Re: [Question] Ask for arm arch timer > > On Wed, Oct 16, 2013 at 01:59:25PM +0100, Rob Herring wrote: > > On 10/16/2013 07:39 AM, Neil Zhang wrote: > > > I saw your following patch called clocksource_of_init() directly in > > > time_init() for arm64. > > > My question is that what should we do if there are some Soc special > > > work need to be done before arch timer can be used? > > > Thanks in advance. > > > > If the timer itself is different, then you should have a different DT > > compatible string which you can use to trigger additional initialization. > > > > Integration level initialization like enabling clocks would need > > something different as no machine descriptors exist for arm64. > > > > Another option would be do the setup in secure world or the bootloader. > > The generic timer should indeed be initialised in the firmware (bootloader may > not be suitable if initialisation needs to happen on each CPU). Linux doesn't > need > to do other things than reading the frequency, programming the interrupts, > counters (but definitely not SoC-specific initialisation). > > > Can you be more specific what initialization is needed. > > I'm interested in this as well. Thanks Catalin and Rob! Yes, we need to select the clk source and enable it. Seems we need to put more and more works into firmware on arm64. > > -- > Catalin Best Regards, Neil Zhang
Re: [PATCH] ecryptfs: Fix memory leakage in keystore.c
2013/10/16 Tyler Hicks : > On 2013-10-11 16:49:16, Geyslan G. Bem wrote: >> In 'decrypt_pki_encrypted_session_key' function: >> >> Initializes 'payload' pointer and releases it on exit. >> >> Signed-off-by: Geyslan G. Bem >> --- > > Thanks! This one was easy to verify by auditing the code, but I was also > able to verify the leak with kmemleak. It's a pleasure. > > I've targeted it for stable and pushed it to the eCryptfs next branch. > Thank you. > Tyler > >> fs/ecryptfs/keystore.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c >> index 7d52806..4725a07 100644 >> --- a/fs/ecryptfs/keystore.c >> +++ b/fs/ecryptfs/keystore.c >> @@ -1149,7 +1149,7 @@ decrypt_pki_encrypted_session_key(struct >> ecryptfs_auth_tok *auth_tok, >> struct ecryptfs_msg_ctx *msg_ctx; >> struct ecryptfs_message *msg = NULL; >> char *auth_tok_sig; >> - char *payload; >> + char *payload = NULL; >> size_t payload_len = 0; >> int rc; >> >> @@ -1203,6 +1203,7 @@ decrypt_pki_encrypted_session_key(struct >> ecryptfs_auth_tok *auth_tok, >> } >> out: >> kfree(msg); >> + kfree(payload); >> return rc; >> } >> >> -- >> 1.8.4 >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote: > That doesn't look bad but it does need capable(CAP_SETUID) && > capable(CAP_SETGID) or possibly something a little more refined. D'oh > I don't think we want file descriptor passing to all of a sudden become > a grant of privilege, beyond what the passed fd can do. Definitely. And an extra ) to make it compile wouldn't hurt either... -- 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/3] switch_creds: Syscall to switch creds for file server ops
Al Viro writes:
> On Wed, Oct 16, 2013 at 03:01:57PM -0700, Jim Lieb wrote:
>> File servers must do some operations with the credentials of
>> their client. This syscall switches the key credentials similar
>> to nfsd_setuser() in fs/nfsd/auth.c with the capability of retaining a
>> handle to the credentials by way of an fd for an open anonymous file.
>> This makes switching for subsequent operations for that client more
>> efficient.
>
> Yet Another Untyped Multiplexor. Inna bun. Onna stick.
> CMOT Dibbler special...
>
> Switching creds to those of opener of given file descriptor
> is fine, but in any realistic situation you'll get all the real win
> from that - you should cache those fds (which you seem to do), and
> then setuid/etc. is done once per cache miss. Making the magical
> "set them all at once" mess (complete with non-trivial structure,
> 32/64bit compat, etc.) pointless. Moreover, you don't need any magic
> files at all - just set the creds and open /dev/null and there's your fd.
> With proper creds associated with it. While we are at it, just _start_
> with opening /dev/null. With your initial creds. Voila - revert is
> simply switch to that fd's creds.
>
> IOW, you really need only one syscall:
That doesn't look bad but it does need capable(CAP_SETUID) &&
capable(CAP_SETGID) or possibly something a little more refined.
I don't think we want file descriptor passing to all of a sudden become
a grant of privilege, beyond what the passed fd can do.
> SYSCALL_DEFINE1(switch_cred, int, fd)
> {
> struct fd f = fdget(fd);
> if (!f.file)
> return -EBADF;
> put_cred(override_creds(f.file->f_cred);
> fdput(f);
> return 0;
> }
>
> and that's all there is to it.
Eric
--
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] ACPI/Power: Check physical device's runtime pm status before requesting to resume it
On 2013年10月16日 20:42, Rafael J. Wysocki wrote:
> On Wednesday, October 16, 2013 05:26:21 PM Lan Tianyu wrote:
>> This is a multi-part message in MIME format.
>> --090400010209000300030201
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> On 10/16/2013 05:22 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, October 15, 2013 04:58:28 PM Lan Tianyu wrote:
On 2013å¹´10æ11æ¥ 19:19, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 04:16:25 PM tianyu@intel.com
> wrote:
>> From: Lan Tianyu
>>
>> Currently, when one power resource is turned on, devices owning
>> it will be requested to resume regardless of their runtime pm
>> status. ACPI power resource maybe turn on in some devices'
>> runtime pm resume callback(E.G, usb port) while turning on the
>> power resource will trigger one new resume request of the
>> device. It causes infinite loop between resume and suspend.
>> This has happened on clearing usb port's PM Qos NO_POWER_OFF
>> flag twice. This patch is to add check of physical device's
>> runtime pm status and request resume if the device is
>> suspended.
>>
>> Signed-off-by: Lan Tianyu ---
>> drivers/acpi/power.c | 6 -- 1 file changed, 4
>> insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index
>> 0dbe5cd..228c138 100644 --- a/drivers/acpi/power.c +++
>> b/drivers/acpi/power.c @@ -250,8 +250,10 @@ static void
>> acpi_power_resume_dependent(struct work_struct *work)
>>
>> mutex_lock(>physical_node_lock);
>>
>> -list_for_each_entry(pn, >physical_node_list, node) -
>> pm_request_resume(pn->dev); +list_for_each_entry(pn,
>> >physical_node_list, node) { + if
>> (pm_runtime_suspended(pn->dev)) + pm_request_resume(pn->dev);
>> + }
>
> This is racy, because the status may change right after you check
> it and before you call pm_request_resume().
Yes, the runtime status may be changed just after the check.
>
> Besides, pm_request_resume() checks the status of the device and
> won't try to resume it if it is not suspended.
>
For this issue, usb port is in the RPM_SUSPENDING state when
pm_request_resume() is called.
>>>
>>> Why exactly does that happen?
>>>
The deferred_resume will be set to true during this procedure and
trigger resume after finishing suspend. USB port runtime resume
callback will turn on its power resource again and the work of
acpi_power_resume_dependent() is scheduled. Because the usb port's
usage count remains zero, it's to be suspended soon. When
pm_request_resume() of acpi_power_resume_dependent() is called, the
usb port is always in the PRM_SUSPENDING. Fall in the loop of
suspend and resume.
How about running acpi_power_dependent when turning on power
resource rather than scheduling a work to run it?
>>>
>>> Is this actually going to help? Even if
>>> acpi_power_resume_dependent() is run synchronously from within the
>>> resume callback, it will still see RPM_SUSPENDING as the device's
>>> status, won't it?
>>>
After this, pm_request_resume() can check device's right status
just after turning on power resource.
>>>
>>> The status doesn't change until the .runtime_suspend() callback
>>> returns and running pm_request_resume() syncrhonously from that
>>> callback for the device being suspended just plain doesn't make
>>> sense.
>>>
>>>
>>> Can you please explain to me how this is possible that the USB port's
>>> power resource is turned "on" while the port is RPM_SUSPENDING?
>>>
>> [This mail seems not to be sent to maillist. So resend. Try again
>> Sorry for noise]
>>
>>
>> Hi Rafael:
>>
>> No, I mean the acpi_power_resume_dependent() is running while the port's
>> status is RPM_SUSPENDING. It runs from a work item and turning on power
>> resource adds the work to workqueue. There is a timeslot between running
>> acpi_power_resume_dependent() and turning on power resource. In the
>> timeslot, the device runtime pm status maybe change.
>>
>> In this case, changing PM Qos flag will do pm_runtime_get_sync and
>> pm_runtime_put usb port. The usb port is without device attached and so
>> it will be resumed and suspended soon during changing PM Qos flag.
>>
>> Resume callback turns on power resource if NO_POWER_OFF flag has been
>> cleared and add the work of acpi_power_resume_dependent() to
>> workqueue. After resume, the usb port will be suspended while the
>> acpi_power_resume_dependent() is running. pm_request_resume() gets
>> RPM_SUSPENDING as the usb port's runtime status and set the
>> deferred_resume of usb port.
>>
>> After suspend, usb port will be resumed again and turn on power
>> resource. The work of acpi_power_resume_dependent() is also added to
>> workqueue. Because the usb port's usage count remains 0
Re: [PATCH] mm: Do not walk all of system memory during show_mem
On Wed, 16 Oct 2013, Mel Gorman wrote:
> It has been reported on very large machines that show_mem is taking almost
> 5 minutes to display information. This is a serious problem if there is
> an OOM storm. The bulk of the cost is in show_mem doing a very expensive
> PFN walk to give us the following information
>
> Total RAM:Also available as totalram_pages
> Highmem pages:Also available as totalhigh_pages
> Reserved pages: Can be inferred from the zone structure
> Shared pages: PFN walk required
> Unshared pages: PFN walk required
> Quick pages: Per-cpu walk required
>
> Only the shared/unshared pages requires a full PFN walk but that information
> is useless. It is also inaccurate as page pins of unshared pages would
> be accounted for as shared. Even if the information was accurate, I'm
> struggling to think how the shared/unshared information could be useful
> for debugging OOM conditions. Maybe it was useful before rmap existed when
> reclaiming shared pages was costly but it is less relevant today.
>
> The PFN walk could be optimised a bit but why bother as the information is
> useless. This patch deletes the PFN walker and infers the total RAM, highmem
> and reserved pages count from struct zone. It omits the shared/unshared page
> usage on the grounds that it is useless. It also corrects the reporting
> of HighMem as HighMem/MovableOnly as ZONE_MOVABLE has similar problems to
> HighMem with respect to lowmem/highmem exhaustion.
>
We haven't been hit by this for the oom killer, but we did get hit with
this for page allocation failure warnings as a result of having irqs
disabled and passing GFP_ATOMIC to the page allocator without GFP_NOWARN.
That was the intention of passing SHOW_MEM_FILTER_PAGE_COUNT into
show_mem() in 4b59e6c47309 ("mm, show_mem: suppress page counts in
non-blockable contexts").
With this, I assume we can just remove SHOW_MEM_FILTER_PAGE_COUNT
entirely?
--
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] ecryptfs: Fix memory leakage in keystore.c
On 2013-10-11 16:49:16, Geyslan G. Bem wrote: > In 'decrypt_pki_encrypted_session_key' function: > > Initializes 'payload' pointer and releases it on exit. > > Signed-off-by: Geyslan G. Bem > --- Thanks! This one was easy to verify by auditing the code, but I was also able to verify the leak with kmemleak. I've targeted it for stable and pushed it to the eCryptfs next branch. Tyler > fs/ecryptfs/keystore.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c > index 7d52806..4725a07 100644 > --- a/fs/ecryptfs/keystore.c > +++ b/fs/ecryptfs/keystore.c > @@ -1149,7 +1149,7 @@ decrypt_pki_encrypted_session_key(struct > ecryptfs_auth_tok *auth_tok, > struct ecryptfs_msg_ctx *msg_ctx; > struct ecryptfs_message *msg = NULL; > char *auth_tok_sig; > - char *payload; > + char *payload = NULL; > size_t payload_len = 0; > int rc; > > @@ -1203,6 +1203,7 @@ decrypt_pki_encrypted_session_key(struct > ecryptfs_auth_tok *auth_tok, > } > out: > kfree(msg); > + kfree(payload); > return rc; > } > > -- > 1.8.4 > signature.asc Description: Digital signature
[PATCH v3] leds: Added driver for the NXP PCA9685 I2C chip
The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
levels of brightness)
This driver supports configuration using platform_data.
Signed-off-by: Maximilian Güntner
---
v3:
fixed warnings when running make C=1 CF=-D__CHECK_ENDIAN__:
* replaced u16* by __le16*
v2:
addresses bryan wu's comments:
* removed/added some empty lines
addresses peter meerwald's comments:
* fixed typos
* replaced/moved one if statement
* replaced (1 << pca9685_ai) with bit(pca9685_ai)
addresses jingoo han's comments:
* added an empty line
* sorted the header inclusions alphabetically
drivers/leds/Kconfig | 10 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-pca9685.c| 213 +
include/linux/platform_data/leds-pca9685.h | 35 +
4 files changed, 259 insertions(+)
create mode 100644 drivers/leds/leds-pca9685.c
create mode 100644 include/linux/platform_data/leds-pca9685.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 875bbe4..72156c1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -300,6 +300,16 @@ config LEDS_PCA963X
LED driver chip accessed via the I2C bus. Supported
devices include PCA9633 and PCA9634
+config LEDS_PCA9685
+ tristate "LED support for PCA9685 I2C chip"
+ depends on LEDS_CLASS
+ depends on I2C
+ help
+ This option enables support for LEDs connected to the PCA9685
+ LED driver chip accessed via the I2C bus.
+ The PCA9685 offers 12-bit PWM (4095 levels of brightness) on
+ 16 individual channels.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8979b0b..3cd76db 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_LEDS_OT200) += leds-ot200.o
obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
obj-$(CONFIG_LEDS_PCA955X) += leds-pca955x.o
obj-$(CONFIG_LEDS_PCA963X) += leds-pca963x.o
+obj-$(CONFIG_LEDS_PCA9685) += leds-pca9685.o
obj-$(CONFIG_LEDS_DA903X) += leds-da903x.o
obj-$(CONFIG_LEDS_DA9052) += leds-da9052.o
obj-$(CONFIG_LEDS_WM831X_STATUS) += leds-wm831x-status.o
diff --git a/drivers/leds/leds-pca9685.c b/drivers/leds/leds-pca9685.c
new file mode 100644
index 000..6e1ef3a
--- /dev/null
+++ b/drivers/leds/leds-pca9685.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright 2013 Maximilian Güntner
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Based on leds-pca963x.c driver by
+ * Peter Meerwald
+ *
+ * Driver for the NXP PCA9685 12-Bit PWM LED driver chip.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Register Addresses */
+#define PCA9685_MODE1 0x00
+#define PCA9685_MODE2 0x01
+#define PCA9685_LED0_ON_L 0x06
+#define PCA9685_ALL_LED_ON_L 0xFA
+
+/* MODE1 Register */
+#define PCA9685_ALLCALL 0x00
+#define PCA9685_SLEEP 0x04
+#define PCA9685_AI 0x05
+
+/* MODE2 Register */
+#define PCA9685_INVRT 0x04
+#define PCA9685_OUTDRV 0x02
+
+static const struct i2c_device_id pca9685_id[] = {
+ { "pca9685", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, pca9685_id);
+
+struct pca9685_led {
+ struct i2c_client *client;
+ struct work_struct work;
+ u16 brightness;
+ struct led_classdev led_cdev;
+ int led_num; /* 0-15 */
+ char name[32];
+};
+
+static void pca9685_write_msg(struct i2c_client *client, u8 *buf, u8 len)
+{
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = 0x00,
+ .len = len,
+ .buf = buf
+ };
+ i2c_transfer(client->adapter, , 1);
+}
+
+static void pca9685_all_off(struct i2c_client *client)
+{
+ u8 i2c_buffer[5] = {PCA9685_ALL_LED_ON_L, 0x00, 0x00, 0x00, 0x10};
+ pca9685_write_msg(client, i2c_buffer, 5);
+}
+
+static void pca9685_led_work(struct work_struct *work)
+{
+ struct pca9685_led *pca9685;
+ u8 i2c_buffer[5];
+
+ pca9685 = container_of(work, struct pca9685_led, work);
+ i2c_buffer[0] = PCA9685_LED0_ON_L + 4 * pca9685->led_num;
+ /*
+* 4095 is the maximum brightness, so we set the ON time to 0x1000
+* which disables the PWM generator for that LED
+*/
+ if (pca9685->brightness == 4095)
+ *((__le16 *)(i2c_buffer+1)) = cpu_to_le16(0x1000);
+ else
+ *((__le16 *)(i2c_buffer+1)) = 0x;
+
+ if (pca9685->brightness == 0)
+ *((__le16 *)(i2c_buffer+3)) = cpu_to_le16(0x1000);
+ else if (pca9685->brightness == 4095)
Re: [PATCH] kernel/rcutorture.c: use scnprintf() instead of sprintf()
On 10/16/2013 10:07 AM, Chen Gang wrote: > On 10/15/2013 10:47 PM, Paul E. McKenney wrote: >> > On Tue, Oct 15, 2013 at 08:32:41PM +0800, Chen Gang wrote: >>> >> Yeah, that is a way for it. It seems you (related maintainer) like >>> >> additional fix for it. >>> >> >>> >> Hmm... I will try within this week (although I don't think it is quite >>> >> necessary to me). >>> >> >>> >> :-) >> > >> > If you always ensure that the buffer is big enough, do you really need >> > the checking? >> > > Since they are all normal static functions: Of cause not need length > checking, either don't need return value, either don't need local > variable 'cnt'. > 2 information: - this way (base on nr_cpu_ids, not snprintf) is not extensible. when add new printing contents, need modify maximized length. if acceptable to you, I will go (or do you have any new ideas?). - sorry, I have some internal urgent things to do, so may not finish within this week, and I will finish it in this month (2013-10-31). Thanks. -- Chen Gang -- 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: [ 00/50] 3.11.6-stable review
On Wed, Oct 16, 2013 at 03:14:40PM -0700, Guenter Roeck wrote: > On Wed, Oct 16, 2013 at 10:44:46AM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.6 release. > > There are 50 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 Fri Oct 18 17:43:24 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.6-rc1.gz > > and the diffstat can be found below. > > > > Build results: > total: 110 pass: 108 skipped: 2 fail: 0 > > qemu tests all passed, with the usual warning for the 'sh' target. Thanks for testing and letting me know. 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: [ 00/69] 3.10.17-stable review
On Wed, Oct 16, 2013 at 03:11:46PM -0700, Guenter Roeck wrote: > On Wed, Oct 16, 2013 at 10:44:09AM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.17 release. > > There are 69 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. > > > > You might notice a bunch of ipc patches in this series. That is to > > resolve some reported ipc bugs / scalabity issues. Additional testing > > of these code paths would be greatly appreciated. > > > > Responses should be made by Fri Oct 18 17:41:53 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.17-rc1.gz > > and the diffstat can be found below. > > > > Build results: > total: 110 pass: 110 skipped: 0 fail: 0 > > qemu tests all pass, with the usual warning for the 'sh' target. > > Details are at http://server.roeck-us.net:8010/builders. Great, thanks for testing and letting me know. 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 v2] usb: hub: Clear Port Reset Change during init/resume
> Did you run into an issue where port status change events weren't being > generated because the Port Reset flag was set? I'm trying to figure out > if this addresses a real issue you hit (and thus should be queued for > stable), or if this is just a precaution. As Benson said, we're seeing this on the HP Chromebook 14 (Intel LynxPoint xHC). It only happens after system suspend/resume, so I'm not sure if there even is an xHC reset involved (not by the kernel anyway, but with all that other stuff it's hard to say). Note that we build our own firmware (including SMM/ACPI handlers), so this does not directly translate to LynxPoint PCs, but I think we based some of our code off Intel reference code and guides which may have already included the problem. I've found port reset code in both our firmware resume path and ACPI _PS0 handler, but they both seem to clear all Port Change bits correctly, so we are not sure about our true root cause yet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] USB: cdc-acm: put delayed_wb to list
Hi, Greg, I am sorry for the inconvenience again. I will do as what you point to make sure the thing won't happen again in future. On Wed, 2013-10-16 at 13:44 -0700, Greg KH wrote: > On Tue, Oct 15, 2013 at 09:01:35AM +0800, xiao jin wrote: > > If acm_write_start during acm suspend, write acm_wb is backuped > > to delayed_wb. When acm resume, the delayed_wb will be started. > > This mechanism can only record one write during acm suspend. More > > acm write will be abandoned. > > > > This patch is to use list_head to record the write acm_wb during acm > > suspend. It can ensure no acm write abandoned. > > > > Signed-off-by: xiao jin > > You obviously did not test this patch at all, as it breaks the build. > > Please get a senior Intel kernel developer to sign-off on your future > patches so this does not happen again. > > 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] mm, vmpressure: add high level
Vmpressure has two important levels: medium and critical. Medium is
defined at 60% and critical is defined at 95%.
We have a customer who needs a notification at a higher level than medium,
which is slight to moderate reclaim activity, and before critical to start
throttling incoming requests to save memory and avoid oom.
This patch adds the missing link: a high level defined at 80%.
In the future, it would probably be better to allow the user to specify an
integer ratio for the notification rather than relying on arbitrarily
specified levels.
Signed-off-by: David Rientjes
---
mm/vmpressure.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -46,6 +46,7 @@ static const unsigned long vmpressure_win = SWAP_CLUSTER_MAX
* 16;
* unsuccessful reclaims there were.
*/
static const unsigned int vmpressure_level_med = 60;
+static const unsigned int vmpressure_level_high = 80;
static const unsigned int vmpressure_level_critical = 95;
/*
@@ -88,6 +89,7 @@ static struct vmpressure *vmpressure_parent(struct vmpressure
*vmpr)
enum vmpressure_levels {
VMPRESSURE_LOW = 0,
VMPRESSURE_MEDIUM,
+ VMPRESSURE_HIGH,
VMPRESSURE_CRITICAL,
VMPRESSURE_NUM_LEVELS,
};
@@ -95,6 +97,7 @@ enum vmpressure_levels {
static const char * const vmpressure_str_levels[] = {
[VMPRESSURE_LOW] = "low",
[VMPRESSURE_MEDIUM] = "medium",
+ [VMPRESSURE_HIGH] = "high",
[VMPRESSURE_CRITICAL] = "critical",
};
@@ -102,6 +105,8 @@ static enum vmpressure_levels vmpressure_level(unsigned
long pressure)
{
if (pressure >= vmpressure_level_critical)
return VMPRESSURE_CRITICAL;
+ else if (pressure >= vmpressure_level_high)
+ return VMPRESSURE_HIGH;
else if (pressure >= vmpressure_level_med)
return VMPRESSURE_MEDIUM;
return VMPRESSURE_LOW;
--
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: net: wireless: b43: Fix possible NULL ptr dereference
On the ternary expression the 'e' variable could be NULL dereferenced,
when b43_nphy_get_rf_ctl_over_rev7 function returns NULL.
Signed-off-by: Felipe Pena
---
drivers/net/wireless/b43/phy_n.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 7c970d3..05ee7f1 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -164,7 +164,8 @@ static void b43_nphy_rf_ctl_override_rev7(struct b43_wldev
*dev, u16 field,
}
en_addr = en_addrs[override][i];
- val_addr = (i == 0) ? e->val_addr_core0 : e->val_addr_core1;
+ if (e)
+ val_addr = (i == 0) ? e->val_addr_core0 :
e->val_addr_core1;
if (off) {
b43_phy_mask(dev, en_addr, ~en_mask);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LSM: ModPin LSM for module loading restrictions
Kees Cook wrote: > So I sent this LSM as one I\'d been waiting > for stacking on. Essentially, I\'m breaking the catch-22 by sending > this. I\'d like it to get into the tree so we don\'t have a catch-22 > about stacking any more. :) I\'m also trying to break the catch-22 by sending KPortReserve. I would send another one which uses only security_file_alloc/free . > The core changes first, and the userspace interface changes next? I welcome that approach, for none of such single function LSM modules depends on userspace interface changes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
On Mon, Oct 14, 2013 at 03:18:47PM -0700, Eric Dumazet wrote:
> On Mon, 2013-10-14 at 14:19 -0700, Eric Dumazet wrote:
> > On Mon, 2013-10-14 at 16:28 -0400, Neil Horman wrote:
> >
> > > So, early testing results today. I wrote a test module that, allocated a
> > > 4k
> > > buffer, initalized it with random data, and called csum_partial on it
> > > 10
> > > times, recording the time at the start and end of that loop. Results on
> > > a 2.4
> > > GHz Intel Xeon processor:
> > >
> > > Without patch: Average execute time for csum_partial was 808 ns
> > > With patch: Average execute time for csum_partial was 438 ns
> >
> > Impressive, but could you try again with data out of cache ?
>
> So I tried your patch on a GRE tunnel and got following results on a
> single TCP flow. (short result : no visible difference)
>
>
So I went to reproduce these results, but was unable to (due to the fact that I
only have a pretty jittery network to do testing accross at the moment with
these devices). So instead I figured that I would go back to just doing
measurements with the module that I cobbled together (operating under the
assumption that it would give me accurate, relatively jitter free results (I've
attached the module code for reference below). My results show slightly
different behavior:
Base results runs:
89417240
85170397
85208407
89422794
91645494
103655144
86063791
75647774
83502921
85847372
AVG = 875 ns
Prefetch only runs:
70962849
77555099
81898170
68249290
72636538
83039294
78561494
83393369
85317556
79570951
AVG = 781 ns
Parallel addition only runs:
42024233
44313064
48304416
64762297
42994259
41811628
55654282
64892958
55125582
42456403
AVG = 510 ns
Both prefetch and parallel addition:
41329930
40689195
61106622
46332422
49398117
52525171
49517101
61311153
43691814
49043084
AVG = 494 ns
For reference, each of the above large numbers is the number of nanoseconds
taken to compute the checksum of a 4kb buffer 10 times. To get my average
results, I ran the test in a loop 10 times, averaged them, and divided by
10.
Based on these, prefetching is obviously a a good improvement, but not as good
as parallel execution, and the winner by far is doing both.
Thoughts?
Neil
#include
#include
#include
#include
#include
#include
#include
#include
#include
static char *buf;
static int __init csum_init_module(void)
{
int i;
__wsum sum = 0;
struct timespec start, end;
u64 time;
buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!buf) {
printk(KERN_CRIT "UNABLE TO ALLOCATE A BUFFER OF %lu bytes\n",
PAGE_SIZE);
return -ENOMEM;
}
printk(KERN_CRIT "INITALIZING BUFFER\n");
get_random_bytes(buf, PAGE_SIZE);
preempt_disable();
printk(KERN_CRIT "STARTING ITERATIONS\n");
getnstimeofday();
for(i=0;i<10;i++)
sum = csum_partial(buf, PAGE_SIZE, sum);
getnstimeofday();
preempt_enable();
if (start.tv_nsec > end.tv_nsec)
time = (ULLONG_MAX - end.tv_nsec) + start.tv_nsec;
else
time = end.tv_nsec - start.tv_nsec;
printk(KERN_CRIT "COMPLETED 10 iterations of csum in %llu
nanosec\n", time);
kfree(buf);
return 0;
}
static void __exit csum_cleanup_module(void)
{
return;
}
module_init(csum_init_module);
module_exit(csum_cleanup_module);
MODULE_LICENSE("GPL");
--
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 09/28] dmaengine: edma: use DMA_COMPLETE for dma completion status
On 10/16/2013 11:28 AM, Vinod Koul wrote: > Signed-off-by: Vinod Koul > CC: Joel Fernandes The audio davinci-pcm driver once converted to dmaengine usage would be the first user of tx_status so I will get to testing this patch better then. Anyway, with this patch applied I compile-tested and boot-tested it and it doesn't appear to break anything. Tested-by: Joel Fernandes thanks, -Joel -- 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] em_ipset: use dev_net() accessor
Randy found that if network namespace not enabled then
nd_net does not exist and would cause compilation failure.
This is handled correctly by using the dev_net() macro.
Signed-off-by: Stephen Hemminger
Acked-by: Randy Dunlap
--- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
+++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
@@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
{
struct xt_set_info *set = data;
ip_set_id_t index;
- struct net *net = qdisc_dev(tp->q)->nd_net;
+ struct net *net = dev_net(qdisc_dev(tp->q));
if (data_len != sizeof(*set))
return -EINVAL;
@@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
{
const struct xt_set_info *set = (const void *) em->data;
if (set) {
- ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
+ ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
kfree((void *) em->data);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault
> -Original Message- > From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo > Molnar > Sent: Wednesday, October 16, 2013 8:51 PM > To: Steven Rostedt > Cc: LKML; Thomas Gleixner; H. Peter Anvin; Frederic Weisbecker; Andrew > Morton; paul...@linux.vnet.ibm.com; Peter Zijlstra; x...@kernel.org; Wang, > Xiaoming; Li, Zhuangzhi; Liu, Chuansheng > Subject: Re: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault > > > * Steven Rostedt wrote: > > > On Wed, 16 Oct 2013 08:11:18 +0200 > > Ingo Molnar wrote: > > > > > > > > * Steven Rostedt wrote: > > > > > > > Since the NMI iretq nesting has been fixed, there's no reason that > > > > an NMI handler can not take a page fault for vmalloc'd code. No locks > > > > are taken in that code path, and the software now handles nested NMIs > > > > when the fault re-enables NMIs on iretq. > > > > > > > > Not only that, if the vmalloc_fault() WARN_ON_ONCE() is hit, and that > > > > warn on triggers a vmalloc fault for some reason, then we can go into > > > > an infinite loop (the WARN_ON_ONCE() does the WARN() before updating > > > > the variable to make it happen "once"). > > > > > > > > Reported-by: "Liu, Chuansheng" > > > > Signed-off-by: Steven Rostedt > > > > > > Would be nice to see the warning quoted that triggered this. > > > > Sure, want me to add this to the change log? > > Yeah, that would be helpful - but only the stack trace portion I suspect, > to make it clear what caused the fault. > > The one posted in the thread shows: > > [ 17.148755] [] do_page_fault+0x8/0x10 > [ 17.153926] [] error_code+0x5a/0x60 > [ 17.158905] [] ? __do_page_fault+0x4a0/0x4a0 > [ 17.164760] [] ? module_address_lookup+0x29/0xb0 > [ 17.170999] [] kallsyms_lookup+0x9b/0xb0 > [ 17.186804] [] sprint_symbol+0x14/0x20 > [ 17.192063] [] __print_symbol+0x1e/0x40 > [ 17.197430] [] ? ashmem_shrink+0x77/0xf0 > [ 17.202895] [] ? logger_aio_write+0x230/0x230 > [ 17.208845] [] ? up+0x25/0x40 > [ 17.213242] [] ? console_unlock+0x337/0x440 > [ 17.218998] [] ? printk+0x38/0x3a > [ 17.223782] [] __show_regs+0x70/0x190 > [ 17.228954] [] show_regs+0x3a/0x1b0 > [ 17.233931] [] ? printk+0x38/0x3a > [ 17.238717] [] > arch_trigger_all_cpu_backtrace_handler+0x62/0x80 > [ 17.246413] [] nmi_handle.isra.0+0x39/0x60 > [ 17.252071] [] do_nmi+0xe9/0x3f0 > > So kallsyms_lookup() faulted, while the NMI watchdog triggered a > show_regs()? How is that possible? Not NMI watchdog triggered show_regs(), when we call arch_trigger_all_cpu_backtrace(), the NMI handler arch_trigger_all_cpu_backtrace_handler() will call show_regs(). > > Thanks, > > Ingo -- 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] of/lib: Export fdt routines to modules
On Wed, Oct 16, 2013 at 04:39:03PM -0700, David Daney wrote: > On 10/16/2013 04:27 PM, Michael Bohan wrote: > >Ever since the following commit, libfdt has been available for > >usage in the kernel: > > > > commit ab25383983fb8d7786696f5371e75e79c3e9a405 > > Author: David Daney > > Date: Thu Jul 5 18:12:38 2012 +0200 > > > > of/lib: Allow scripts/dtc/libfdt to be used from kernel code > > > >Export these functions to modules so that they may be used > >from device drivers. > >--- > >+EXPORT_SYMBOL_GPL(fdt_next_tag); > > The code was all written by David Gibson, and is dual GPL/BSD > licensed. So I am not sure you should be using the GPL flavor of > the export directive. Yeah, I wasn't quite sure about this myself. I can remove the GPL if it's incorrect. > But more than this. I don't understand why a driver would be > parsing the FDT in the first place. If there is a device tree, why > hasn't it been unflattened, and thus used via the normal device tree > functions. My motivation is actually to use the fdt format as a firmware. I have a requirement to express driver metadata that's loadable from the filesystem. This data is not reasonable to place in the system Device Tree, since it's application specific and does not actually describe hardware. The fact that the format chosen is 'flattened device tree' is merely just a coincidence. When considering formats, dts / fdt is convenient since: -The dts syntax meets requirements by being human-readable. -There exists a device-tree compiler already -Linux knows how to deal with fdt, so the driver implementation becomes more simple. Thanks, Mike -- Qualcomm Innovation Center, Inc. is a member of 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: linux-next: Tree for Oct 16 (net/sched/em_ipset.c)
On 10/16/13 15:39, Stephen Hemminger wrote:
> On Wed, 16 Oct 2013 14:48:32 -0700
> Randy Dunlap wrote:
>
>> On 10/16/13 11:51, Thierry Reding wrote:
>>> Hi all,
>>>
>>> I've uploaded today's linux-next tree to the master branch of the
>>> repository below:
>>>
>>> git://gitorious.org/thierryreding/linux-next.git
>>>
>>> A next-20131016 tag is also provided for convenience.
>>>
>>> Gained two new conflicts, but nothing too exciting. x86 and ARM default
>>> configurations as well as the x86 allmodconfig mostly build fine on the
>>> final tree. There was a failure for the ARM at91x40_defconfig, but the
>>> proper fix wasn't immediately obvious to me, so I've left it broken for
>>> now.
>>
>> on i386, when CONFIG_NET_NS is not enabled:
>>
>> net/sched/em_ipset.c: In function 'em_ipset_change':
>> net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named
>> 'nd_net'
>> net/sched/em_ipset.c: In function 'em_ipset_destroy':
>> net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named
>> 'nd_net'
>>
>>
>
> I think this should fix.
>
That works. Thanks.
Acked-by: Randy Dunlap
>
>
> --- a/net/sched/em_ipset.c2013-10-06 14:48:25.030449222 -0700
> +++ b/net/sched/em_ipset.c2013-10-16 15:38:05.030278287 -0700
> @@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
> {
> struct xt_set_info *set = data;
> ip_set_id_t index;
> - struct net *net = qdisc_dev(tp->q)->nd_net;
> + struct net *net = dev_net(qdisc_dev(tp->q));
>
> if (data_len != sizeof(*set))
> return -EINVAL;
> @@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
> {
> const struct xt_set_info *set = (const void *) em->data;
> if (set) {
> - ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
> + ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
> kfree((void *) em->data);
> }
> }
> --
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: never write to the userspace more data than the caller wants
The amount of data wanted by the userspace caller is encoded in the
ioctl number. Generic drm ioctls were ignoring it.
As a result, Intel Xorg driver didn't work for i386 userspace on x86_64
kernel on some systems. sizeof(struct drm_mode_get_connector) is 76
bytes on i686 and 80 bytes on x86_64 due to the tail alignment (the data
positions match). The userspace was using the 4 bytes after the
structure to hold the result of the ioctl. Since drm_ioctl() was
copying 80 bytes instead of 76, it was clobbering that data.
A workaround has been committed to xf86-video-intel.
Signed-off-by: Pavel Roskin
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_drv.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e572dd2..8a1c721 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -403,8 +403,11 @@ long drm_ioctl(struct file *filp,
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
ioctl = _ioctls[nr];
+ usize = _IOC_SIZE(cmd);
cmd = ioctl->cmd;
- usize = asize = _IOC_SIZE(cmd);
+ asize = _IOC_SIZE(cmd);
+ if (unlikely(usize > asize))
+ usize = asize;
} else
goto err_i1;
--
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 5/5] efi: Capsule update support and pstore backend
> There's also an "either/or" choice between using efi-capsule with pstore, and > the > traditional kexec/kdump method for getting a memory dump from a crash. We > have to go through a reset to save the capsule - but we don't want a reset for > kexec. Perhaps we can pass the reset parameters through the kexec path to > the new kernel to make it do the right kind of reset ... but the value of the > capsule > dump is minimal if kdump managed to dump everything. Tony, I tried to log kmsg into the kexec path months ago. It was rejected due to the impelementation problem. But, as Eric said, it should be OK if it is implemented in the kdump kenel. http://marc.info/?l=linux-kernel=136917686732183=2 The only problem with kdump here is the implementation in the initial ram disk. Fixing the initial ramdisk so it logs to kmsg before it touches scarier hardware should be the solution. Seiji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: hub: Clear Port Reset Change during init/resume
On Wed, Oct 16, 2013 at 4:57 PM, Sarah Sharp wrote: > > Did you run into an issue where port status change events weren't being > generated because the Port Reset flag was set? I'm trying to figure out > if this addresses a real issue you hit (and thus should be queued for > stable), or if this is just a precaution. We ran into this on HP Chromebook 14 (Falco). The port reset flag would be set after a suspend/resume cycle with nothing attached. -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: hub: Clear Port Reset Change during init/resume
On Tue, Oct 15, 2013 at 05:45:00PM -0700, Julius Werner wrote:
> This patch adds the Port Reset Change flag to the set of bits that are
> preemptively cleared on init/resume of a hub. In theory this bit should
> never be set unexpectedly... in practice it can still happen if BIOS,
> SMM or ACPI code plays around with USB devices without cleaning up
> correctly. This is especially dangerous for XHCI root hubs, which don't
> generate any more Port Status Change Events until all change bits are
> cleared, so this is a good precaution to have (similar to how it's
> already done for the Warm Port Reset Change flag).
Did you run into an issue where port status change events weren't being
generated because the Port Reset flag was set? I'm trying to figure out
if this addresses a real issue you hit (and thus should be queued for
stable), or if this is just a precaution.
I do agree this is a good fix. ISTR that with some xHCI vendors, when
the host is reset, the hardware will drive a port reset down all ports.
That may cause the port reset and even warm port reset bits to be set.
I have a vague recollection that some implementations might not even
wait for the port reset to complete before saying the reset is done. We
can't tell which hosts will and won't drive a reset, so we rely on the
USB core to clear those bits if they are set.
So perhaps instead of the BIOS/SMM/ACPI code leaving the ports in an
unclean state, the root cause of your issue is actually the call to
xhci_reset? You can check the port status before that call to find out.
> Signed-off-by: Julius Werner
> ---
> drivers/usb/core/hub.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index e6b682c..c3dd64c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1130,6 +1130,11 @@ static void hub_activate(struct usb_hub *hub, enum
> hub_activation_type type)
> usb_clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_ENABLE);
> }
> + if (portchange & USB_PORT_STAT_C_RESET) {
> + need_debounce_delay = true;
> + usb_clear_port_feature(hub->hdev, port1,
> + USB_PORT_FEAT_C_RESET);
> + }
> if ((portchange & USB_PORT_STAT_C_BH_RESET) &&
> hub_is_superspeed(hub->hdev)) {
> need_debounce_delay = true;
> --
> 1.7.12.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion
On Fri, Oct 11, 2013 at 08:19:01PM +0800, tianyu@intel.com wrote:
> From: Lan Tianyu
>
> Using ACPI resource functions to convert ACPI resource to generic resource
>
> Signed-off-by: Lan Tianyu
> ---
> This patch just passes through compilation test due to no ia64 machine on
> hand.
>
> arch/ia64/pci/pci.c | 38 +-
> 1 file changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 2326790..14fa175 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -232,8 +232,9 @@ out:
> return ~0;
> }
>
> -static acpi_status resource_to_window(struct acpi_resource *resource,
> - struct acpi_resource_address64 *addr)
> +static acpi_status resource_to_window(struct acpi_resource *ares,
> + struct acpi_resource_address64 *addr,
> + struct resource *res)
> {
> acpi_status status;
>
> @@ -244,7 +245,7 @@ static acpi_status resource_to_window(struct
> acpi_resource *resource,
>* - producers, i.e., the address space is routed downstream,
>*not consumed by the bridge itself
>*/
> - status = acpi_resource_to_address64(resource, addr);
> + status = acpi_dev_resource_address_space_full(ares, addr, res);
> if (ACPI_SUCCESS(status) &&
> (addr->resource_type == ACPI_MEMORY_RANGE ||
>addr->resource_type == ACPI_IO_RANGE) &&
> @@ -255,51 +256,54 @@ static acpi_status resource_to_window(struct
> acpi_resource *resource,
> return AE_ERROR;
> }
>
> -static acpi_status count_window(struct acpi_resource *resource, void *data)
> +static acpi_status count_window(struct acpi_resource *ares, void *data)
> {
> unsigned int *windows = (unsigned int *) data;
> struct acpi_resource_address64 addr;
> + struct resource res;
> acpi_status status;
>
> - status = resource_to_window(resource, );
> + status = resource_to_window(ares, , );
> if (ACPI_SUCCESS(status))
> (*windows)++;
>
> return AE_OK;
> }
>
> -static acpi_status add_window(struct acpi_resource *res, void *data)
> +static acpi_status add_window(struct acpi_resource *ares, void *data)
> {
> struct pci_root_info *info = data;
> - struct resource *resource;
> + struct resource *resource = >res[info->res_num];
> struct acpi_resource_address64 addr;
> acpi_status status;
> - unsigned long flags, offset = 0;
> + unsigned long offset = 0;
> struct resource *root;
>
> /* Return AE_OK for non-window resources to keep scanning for more */
> - status = resource_to_window(res, );
> + status = resource_to_window(ares, , resource);
> if (!ACPI_SUCCESS(status))
> return AE_OK;
>
> - if (addr.resource_type == ACPI_MEMORY_RANGE) {
> - flags = IORESOURCE_MEM;
> + if (resource->flags & IORESOURCE_MEM) {
> root = _resource;
> offset = addr.translation_offset;
> - } else if (addr.resource_type == ACPI_IO_RANGE) {
> - flags = IORESOURCE_IO;
> + } else if (resource->flags & IORESOURCE_IO) {
> root = _resource;
> offset = add_io_space(info, );
> if (offset == ~0)
> return AE_OK;
> +
> + /*
> + * io space address translation offset depends
> + * on the return value of add_io_space(). So
> + * Repopulate resource->start and end here.
"Repopulate" makes it sound like "resource->start" got clobbered
somewhere. But it didn't. I think it's just that each bridge can
support its own I/O port range, and the PCI port numbers reported
in the acpi_resource may not be distinct, and add_io_space() adds
an offset so all the I/O port ranges fit into one global I/O port
space.
For example, I think these two bridges have the same port numbers
(0x0-0xfff) in their acpi_resource, but the second has an offset
of 0x100 in the system I/O port space, and I think this offset
is what add_io_space() returns:
HWP0002:00: host bridge window [io 0x-0x0fff] (PCI [0x0-0xfff])
HWP0002:09: host bridge window [io 0x100-0x1000fff] (PCI [0x0-0xfff])
> + */
> + resource->start = addr.minimum + offset;
> + resource->end = resource->start + addr.address_length - 1;
Can't we use this:
resource->start += offset;
resource->end += offset;
to avoid breaking the encapsulation of struct acpi_resource_address64?
> } else
> return AE_OK;
>
> - resource = >res[info->res_num];
> resource->name = info->name;
> - resource->flags = flags;
> - resource->start = addr.minimum + offset;
> - resource->end = resource->start + addr.address_length - 1;
> info->res_offset[info->res_num] =
Re: [PATCH] of/lib: Export fdt routines to modules
On 10/16/2013 04:27 PM, Michael Bohan wrote: Ever since the following commit, libfdt has been available for usage in the kernel: commit ab25383983fb8d7786696f5371e75e79c3e9a405 Author: David Daney Date: Thu Jul 5 18:12:38 2012 +0200 of/lib: Allow scripts/dtc/libfdt to be used from kernel code Export these functions to modules so that they may be used from device drivers. Change-Id: I7f540b7cf860c4be414e32ce183be5268b2ae6af Signed-off-by: Michael Bohan --- lib/fdt.c |6 ++ lib/fdt_ro.c | 28 lib/fdt_rw.c | 13 + lib/fdt_sw.c |9 + lib/fdt_wip.c |6 ++ 5 files changed, 62 insertions(+), 0 deletions(-) diff --git a/lib/fdt.c b/lib/fdt.c index 97f2006..a3fe87b 100644 --- a/lib/fdt.c +++ b/lib/fdt.c @@ -1,2 +1,8 @@ #include +#include #include "../scripts/dtc/libfdt/fdt.c" + +EXPORT_SYMBOL_GPL(fdt_next_tag); The code was all written by David Gibson, and is dual GPL/BSD licensed. So I am not sure you should be using the GPL flavor of the export directive. But more than this. I don't understand why a driver would be parsing the FDT in the first place. If there is a device tree, why hasn't it been unflattened, and thus used via the normal device tree functions. David Daney -- 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] xhci: fix usb3 streams
On Tue, Oct 15, 2013 at 10:53:57AM -0400, Alan Stern wrote: > On Mon, 14 Oct 2013, Gerd Hoffmann wrote: > > > Gerd, Hans, any objections to this updated patch? The warning is fixed > > with it. > > > > The patch probably still needs to address the case where the ring > > expansion fails because we can't insert the new segments into the radix > > tree. The patch should probably allocate the segments, attempt to add > > them to the radix tree, and fail without modifying the link TRBs of the > > ring. I'd have to look more deeply into the code to see what exactly > > should be done there. > > > > I would like that issue fixed before I merge these patches, so if you > > want to take a stab at fixing it, please do. > > > > Sarah Sharp > > Sarah, how did you manage to send an email with the "From:" line set to > Gerd's name and address? I sent it using git format-patch and mutt, and accidentally left Gerd's >From line intact. Looking at the headers, it seems like the default Intel exchange servers simply passed the email through. Header forging, what fun! > > 8<>8 > > > > xhci maintains a radix tree for each stream endpoint because it must > > be able to map a trb address to the stream ring. Each ring segment > > must be added to the ring for this to work. Currently xhci sticks > > only the first segment of each stream ring into the radix tree. > > > > Result is that things work initially, but as soon as the first segment > > is full xhci can't map the trb address from the completion event to the > > stream ring any more -> BOOM. You'll find this message in the logs: > > > > ERROR Transfer event for disabled endpoint or incorrect stream ring > > > > This patch adds a helper function to update the radix tree, and a > > function to remove ring segments from the tree. Both functions loop > > over the segment list and handles all segments instead of just the > > first. > > There may be a simpler approach to this problem. > > When using a new ring segment, keep the first TRB entry in reserve. > Don't put a normal TRB in there, instead leave it as a no-op entry > containing a pointer to the stream ring. (Make the prior Link TRB > point to the second entry in the new segment instead of the first.) > > Then you won't have to add to or remove anything from the radix tree. I don't understand how this would help. Are you advocating a different way of mapping TRB DMA addresses to stream rings that would allow us to ditch the radix tree all together? Ok, so with your solution, we have a virtual stream ring pointer as the first TRB of the segment. We get an event with the DMA address of a TRB in one of many stream rings on an endpoint. From that, I think we can infer the DMA address of the first TRB on the segment, due to the alignment requirements and ring size. And then what do we do with that? We don't have the virtual address of that first TRB, so the xHCI driver can't read the ring pointer from it. I'm confused as to what the next steps would be to solve this. Sarah Sharp -- 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 v7 12/12] intel_mid: move board related code to their own platform_.* files
As Intel rolling out more SoC's after Moorestown, we need to
re-structure the code in a way that is backward compatible and easy to
expand. This patch implements a flexible way to support multiple boards
and devices.
This patch does not add any new functional support. It just refactors
the existing code to increase the modularity and decrease the code
duplication for supporting multiple soc's and boards.
Currently intel-mid.c has both board and soc related code in one file.
This patch moves the board related code to new files and let linker
script to create SFI devite table following this:
1. Move the SFI device specific code to
arch/x86/platform/intel-mid/device-libs/platform_.*
A new device file is added for every supported device. This code will
get conditionally compiled by using corresponding device driver
CONFIG option.
2. Moved the device_ids location to .x86_intel_mid_dev.init section by
using new sfi_device() macro.
This patch was based on previous code from Sathyanarayanan Kuppuswamy.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
Change from v6 to v7:
- updated patch's title description
arch/x86/include/asm/intel-mid.h | 16 +
arch/x86/platform/intel-mid/Makefile | 6 +-
arch/x86/platform/intel-mid/device_libs/Makefile | 22 ++
.../intel-mid/device_libs/platform_emc1403.c | 41 ++
.../intel-mid/device_libs/platform_gpio_keys.c | 83
.../platform/intel-mid/device_libs/platform_ipc.c | 68
.../platform/intel-mid/device_libs/platform_ipc.h | 17 +
.../intel-mid/device_libs/platform_lis331.c| 39 ++
.../intel-mid/device_libs/platform_max3111.c | 35 ++
.../intel-mid/device_libs/platform_max7315.c | 79
.../intel-mid/device_libs/platform_mpu3050.c | 36 ++
.../platform/intel-mid/device_libs/platform_msic.c | 87 +
.../platform/intel-mid/device_libs/platform_msic.h | 19 +
.../intel-mid/device_libs/platform_msic_audio.c| 47 +++
.../intel-mid/device_libs/platform_msic_battery.c | 37 ++
.../intel-mid/device_libs/platform_msic_gpio.c | 48 +++
.../intel-mid/device_libs/platform_msic_ocd.c | 49 +++
.../device_libs/platform_msic_power_btn.c | 36 ++
.../intel-mid/device_libs/platform_msic_thermal.c | 37 ++
.../intel-mid/device_libs/platform_pmic_gpio.c | 54 +++
.../intel-mid/device_libs/platform_tc35876x.c | 36 ++
.../intel-mid/device_libs/platform_tca6416.c | 57 +++
arch/x86/platform/intel-mid/intel-mid.c| 419 -
arch/x86/platform/intel-mid/sfi.c | 14 +-
24 files changed, 953 insertions(+), 429 deletions(-)
create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.h
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max3111.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.h
create mode 100644
arch/x86/platform/intel-mid/device_libs/platform_msic_audio.c
create mode 100644
arch/x86/platform/intel-mid/device_libs/platform_msic_battery.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_gpio.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_ocd.c
create mode 100644
arch/x86/platform/intel-mid/device_libs/platform_msic_power_btn.c
create mode 100644
arch/x86/platform/intel-mid/device_libs/platform_msic_thermal.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_pmic_gpio.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tca6416.c
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 3b0e7a7..2838942 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -12,8 +12,11 @@
#define _ASM_X86_INTEL_MID_H
#include
+#include
extern int intel_mid_pci_init(void);
+extern int get_gpio_by_name(const char *name);
+extern void intel_scu_device_register(struct platform_device *pdev);
extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
extern int sfi_mrtc_num;
@@ -34,6 +37,10 @@ struct devs_id {
struct devs_id *dev);
};
+#define
cp --reflink and target file open flags
cp --reflink opens the target file for O_WRONLY before invoking the (BTRFS) ioctl for clone file, but for copy offload over the network the SMB2 specification requires that the target file be open O_RDWR. I may be able to upgrade the target file handle on the fly by reopening it in cifs.ko, and of course I can write an SMB2/SMB3 specific copy command, but it would be preferable to allow use of cp --reflink since so many people are familiar with it. There is quite a bit of flexibility in server side copy offload - more than cp an offer, especially when using SMB3 or later dialects (e.g. in number of chunks sent at one time, chunk size, attributes copied, and even whether to use T10 style offload), but still it would be nice to support "cp --reflink" over the network. Any ideas on this? After looking at copy.c in coreutils for cp - I couldn't think of any trivial way to force cp to open the target RW. Ideas? -- 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 2/5] efi: Introduce a Runtime Services lock
> +#define efi_call_reset_virt(f, args...)
> \
> +({ \
> + unsigned long __flags; \
> + bool __nmi = in_nmi(); \
> + \
> + if (__nmi) \
> + spin_lock_irqsave(_runtime_lock, __flags); \
If the lock is not held in the nmi context, runtime service may run concurrently
in non-nmi context as follows.
- In nmi context, cpu0 calls a runtime service (no lock is held.)
- In non-nmi context, cpu1 call can take the lock and call the runtime service.
To avoid this, using try_lock in nmi context is better..
If(in_nmi())
try_spin_lock_irqsave();
else
spin_lock_irqsave();
Please see the commit abd4d5587be911f63592537284dad78766d97d62,
which is introduced to pstore by Don Zickus.
Seiji
--
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] of/lib: Export fdt routines to modules
Ever since the following commit, libfdt has been available for usage in the kernel: commit ab25383983fb8d7786696f5371e75e79c3e9a405 Author: David Daney Date: Thu Jul 5 18:12:38 2012 +0200 of/lib: Allow scripts/dtc/libfdt to be used from kernel code Export these functions to modules so that they may be used from device drivers. Change-Id: I7f540b7cf860c4be414e32ce183be5268b2ae6af Signed-off-by: Michael Bohan --- lib/fdt.c |6 ++ lib/fdt_ro.c | 28 lib/fdt_rw.c | 13 + lib/fdt_sw.c |9 + lib/fdt_wip.c |6 ++ 5 files changed, 62 insertions(+), 0 deletions(-) diff --git a/lib/fdt.c b/lib/fdt.c index 97f2006..a3fe87b 100644 --- a/lib/fdt.c +++ b/lib/fdt.c @@ -1,2 +1,8 @@ #include +#include #include "../scripts/dtc/libfdt/fdt.c" + +EXPORT_SYMBOL_GPL(fdt_next_tag); +EXPORT_SYMBOL_GPL(fdt_next_node); +EXPORT_SYMBOL_GPL(fdt_check_header); +EXPORT_SYMBOL_GPL(fdt_move); diff --git a/lib/fdt_ro.c b/lib/fdt_ro.c index f73c04e..97269bc 100644 --- a/lib/fdt_ro.c +++ b/lib/fdt_ro.c @@ -1,2 +1,30 @@ #include +#include #include "../scripts/dtc/libfdt/fdt_ro.c" + +EXPORT_SYMBOL_GPL(fdt_string); +EXPORT_SYMBOL_GPL(fdt_num_mem_rsv); +EXPORT_SYMBOL_GPL(fdt_get_mem_rsv); +EXPORT_SYMBOL_GPL(fdt_subnode_offset_namelen); +EXPORT_SYMBOL_GPL(fdt_subnode_offset); +EXPORT_SYMBOL_GPL(fdt_path_offset); +EXPORT_SYMBOL_GPL(fdt_get_name); +EXPORT_SYMBOL_GPL(fdt_first_property_offset); +EXPORT_SYMBOL_GPL(fdt_next_property_offset); +EXPORT_SYMBOL_GPL(fdt_get_property_by_offset); +EXPORT_SYMBOL_GPL(fdt_get_property_namelen); +EXPORT_SYMBOL_GPL(fdt_get_property); +EXPORT_SYMBOL_GPL(fdt_getprop_by_offset); +EXPORT_SYMBOL_GPL(fdt_getprop_namelen); +EXPORT_SYMBOL_GPL(fdt_getprop); +EXPORT_SYMBOL_GPL(fdt_get_phandle); +EXPORT_SYMBOL_GPL(fdt_get_alias_namelen); +EXPORT_SYMBOL_GPL(fdt_get_alias); +EXPORT_SYMBOL_GPL(fdt_get_path); +EXPORT_SYMBOL_GPL(fdt_supernode_atdepth_offset); +EXPORT_SYMBOL_GPL(fdt_node_depth); +EXPORT_SYMBOL_GPL(fdt_parent_offset); +EXPORT_SYMBOL_GPL(fdt_node_offset_by_prop_value); +EXPORT_SYMBOL_GPL(fdt_node_offset_by_phandle); +EXPORT_SYMBOL_GPL(fdt_node_check_compatible); +EXPORT_SYMBOL_GPL(fdt_node_offset_by_compatible); diff --git a/lib/fdt_rw.c b/lib/fdt_rw.c index 0c1f0f4..30de9ec 100644 --- a/lib/fdt_rw.c +++ b/lib/fdt_rw.c @@ -1,2 +1,15 @@ #include +#include #include "../scripts/dtc/libfdt/fdt_rw.c" + +EXPORT_SYMBOL_GPL(fdt_open_into); +EXPORT_SYMBOL_GPL(fdt_pack); +EXPORT_SYMBOL_GPL(fdt_add_mem_rsv); +EXPORT_SYMBOL_GPL(fdt_del_mem_rsv); +EXPORT_SYMBOL_GPL(fdt_set_name); +EXPORT_SYMBOL_GPL(fdt_setprop); +EXPORT_SYMBOL_GPL(fdt_appendprop); +EXPORT_SYMBOL_GPL(fdt_delprop); +EXPORT_SYMBOL_GPL(fdt_add_subnode_namelen); +EXPORT_SYMBOL_GPL(fdt_add_subnode); +EXPORT_SYMBOL_GPL(fdt_del_node); diff --git a/lib/fdt_sw.c b/lib/fdt_sw.c index 9ac7e50..17d6ba1 100644 --- a/lib/fdt_sw.c +++ b/lib/fdt_sw.c @@ -1,2 +1,11 @@ #include +#include #include "../scripts/dtc/libfdt/fdt_sw.c" + +EXPORT_SYMBOL_GPL(fdt_create); +EXPORT_SYMBOL_GPL(fdt_add_reservemap_entry); +EXPORT_SYMBOL_GPL(fdt_finish_reservemap); +EXPORT_SYMBOL_GPL(fdt_begin_node); +EXPORT_SYMBOL_GPL(fdt_property); +EXPORT_SYMBOL_GPL(fdt_end_node); +EXPORT_SYMBOL_GPL(fdt_finish); diff --git a/lib/fdt_wip.c b/lib/fdt_wip.c index 45b3fc3..22b606d 100644 --- a/lib/fdt_wip.c +++ b/lib/fdt_wip.c @@ -1,2 +1,8 @@ #include +#include #include "../scripts/dtc/libfdt/fdt_wip.c" + +EXPORT_SYMBOL_GPL(fdt_setprop_inplace); +EXPORT_SYMBOL_GPL(fdt_setprop_inplace_u32); +EXPORT_SYMBOL_GPL(fdt_nop_property); +EXPORT_SYMBOL_GPL(fdt_nop_node); -- 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: [PATCH v3] Introduce page fault tracepoint
Thank you for reviewing. > > http://marc.info/?l=linux-mm=136807959830182=2 > > http://marc.info/?l=linux-mm=136807959130175=2 > > > > For permanence, please use links of the form: > > http://lkml.kernel.org/r/message-id > > (Yes, they currently point to marc.info, but can be redirected to point > to any archive.) I will fix it. > This is needlessly confusing, which is apart of why reviewing this patch > took a lot more time than it should. > > Please break this patch into two: one which sets up the tracing IDT and > one to create the #PF tracepoint. The assumption is, I am assuming, > there will be more. OK. I will divide the patch into two or more to make the review smooth. Seiji > > -hpa
Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
On Wed, 2013-10-16 at 11:04 +0200, Hendrik Brueckner wrote: > Indeed, two callbacks change the DTR line. The main difference is that > tiocmget/tiocmset can be called from user space by ioctl. That's not the case > for the dtr_cts callback. Also, tiocmget/tiocmset provide more flags that can > be changed (ST, SR, CTS, CD, RNG, RI, ...) > > Assume we would like to unify them have a single callback to change DTR, then > we have to take care of these differences. So the question to you now is > whether you plan for a) other modem flags to be changed and b) if changing the > DTR line (or other control flags) through an ioctl? > > Depending on your results, I could work on sth that helps us both and reduces > the callbacks. Can we not just have the users of dtr_cts just call the backend's tiocmset ? If they need to filter or clamp bits, we could handle all that in hvc_console by caching the user intended value and passing a cooked value down to the backend.. None of that is urgent or anything, it's just odd and would be nice to cleanup. Cheers, Ben. -- 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 02/12] mm, thp, tmpfs: support to add huge page into page cache for tmpfs
Consider this fixed. I have extracted the common function and the new shmem_insert_page_page_cache function looks like this: spin_lock_irq(>tree_lock); error = __add_to_page_cache_locked(page, mapping, index); if (!error) __mod_zone_page_state(page_zone(page), NR_SHMEM, nr); radix_tree_preload_end(); spin_unlock_irq(>tree_lock); if (error) page_cache_release(page); return error; Best wishes, -- Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066 On Wed, Oct 16, 2013 at 10:49 AM, Ning Qu wrote: > Yes, I guess I can if I just put whatever inside the spin lock into a > common function. Thanks! > Best wishes, > -- > Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066 > > > On Wed, Oct 16, 2013 at 5:26 AM, Kirill A. Shutemov > wrote: >> Ning Qu wrote: >>> Yes, I can try. The code is pretty much similar with some minor difference. >>> >>> One thing I can do is to move the spin lock part (together with the >>> corresponding err handling into a common function. >>> >>> The only problem I can see right now is we need the following >>> additional line for shm: >>> >>> __mod_zone_page_state(page_zone(page), NR_SHMEM, nr); >>> >>> Which means we need to tell if it's coming from shm or not, is that OK >>> to add additional parameter just for that? Or is there any other >>> better way we can infer that information? Thanks! >> >> I think you can account NR_SHMEM after common code succeed, don't you? >> >> -- >> Kirill A. Shutemov -- 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 3/5] ACPI: Add new acpi_dev_resource_address_space_full() function
On Fri, Oct 11, 2013 at 08:18:59PM +0800, tianyu@intel.com wrote:
> From: Lan Tianyu
>
> Make acpi_dev_resource_address_space() to accept struct
> acpi_resource_address64 as param and rename it to *_full.
>
> This is for some cases that acpi address info is also needed
> after convert from acpi resouce to generic resource.
s/resouce/resource/
> Add acpi_dev_resource_addres_space() again as a wrapper of new
acpi_dev_resource_address_space() (spelled wrong above).
> function for original users.
>
> Signed-off-by: Lan Tianyu
> ---
> drivers/acpi/resource.c | 53
> ++---
> include/linux/acpi.h| 3 +++
> 2 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 84bc3db..2e395ba 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -162,19 +162,21 @@ bool acpi_dev_resource_io(struct acpi_resource *ares,
> struct resource *res)
> EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
>
> /**
> - * acpi_dev_resource_address_space - Extract ACPI address space information.
> + * acpi_dev_resource_address_space_full - Extract ACPI address space
> information.
> * @ares: Input ACPI resource object.
> + * @addr: Output ACPI resource address64 space object.
> * @res: Output generic resource object.
> *
> * Check if the given ACPI resource object represents an address space
> resource
> - * and if that's the case, use the information in it to populate the generic
> - * resource object pointed to by @res.
> + * and if that's the case, convert it to ACPI resource address64 space object
> + * pointed to by @addr and use the information to populate the generic
> resource
> + * object pointed to by @re.
s/@re/@res/ or maybe even just use this:
"If @ares is an address space resource, convert it to an
acpi_resource_address64 and use that to populate the generic @res."
> */
> -bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> +bool acpi_dev_resource_address_space_full(struct acpi_resource *ares,
> + struct acpi_resource_address64 *addr,
>struct resource *res)
> {
> acpi_status status;
> - struct acpi_resource_address64 addr;
> bool window;
> u64 len;
> u8 io_decode;
> @@ -188,29 +190,29 @@ bool acpi_dev_resource_address_space(struct
> acpi_resource *ares,
> return false;
> }
>
> - status = acpi_resource_to_address64(ares, );
> + status = acpi_resource_to_address64(ares, addr);
> if (ACPI_FAILURE(status))
> return true;
You didn't actually change this, but it looks wrong to return "true"
here, because we haven't filled in "res". Returning "true" will cause
acpi_dev_process_resource() to call acpi_dev_new_resource_entry() with
a struct resource that's full of zeroes.
I think the best fix would be to remove this code just above:
switch (ares->type) {
case ACPI_RESOURCE_TYPE_ADDRESS16:
case ACPI_RESOURCE_TYPE_ADDRESS32:
case ACPI_RESOURCE_TYPE_ADDRESS64:
break;
default:
return false;
}
and return "false" if acpi_resource_to_address64() fails.
>
> - res->start = addr.minimum + addr.translation_offset;
> - res->end = addr.maximum + addr.translation_offset;
> - window = addr.producer_consumer == ACPI_PRODUCER;
> + res->start = addr->minimum + addr->translation_offset;
> + res->end = addr->maximum + addr->translation_offset;
> + window = addr->producer_consumer == ACPI_PRODUCER;
>
> - switch(addr.resource_type) {
> + switch (addr->resource_type) {
> case ACPI_MEMORY_RANGE:
> - len = addr.maximum - addr.minimum + 1;
> + len = addr->maximum - addr->minimum + 1;
> res->flags = acpi_dev_memresource_flags(len,
> - addr.info.mem.write_protect,
> + addr->info.mem.write_protect,
> window);
>
> - if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> + if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> res->flags |= IORESOURCE_PREFETCH;
> break;
> case ACPI_IO_RANGE:
> - io_decode = addr.granularity == 0xfff ?
> + io_decode = addr->granularity == 0xfff ?
> ACPI_DECODE_10 : ACPI_DECODE_16;
> - res->flags = acpi_dev_ioresource_flags(addr.minimum,
> -addr.maximum,
> + res->flags = acpi_dev_ioresource_flags(addr->minimum,
> +addr->maximum,
> io_decode, window);
> break;
> case ACPI_BUS_NUMBER_RANGE:
> @@
Re: [PATCH] drivers: staging: dgnc: Remove useless casting in dgnc_driver.c
2013/10/16 Greg KH : > On Wed, Oct 16, 2013 at 12:57:35PM -0300, Geyslan G. Bem wrote: >> Casting (void *) value returned by kzalloc is useless >> as mentioned in Documentation/CodingStyle, Chap 14. >> >> Signed-off-by: Geyslan G. Bem >> --- >> drivers/staging/dgnc/dgnc_driver.c | 6 ++ >> 1 file changed, 2 insertions(+), 4 deletions(-) > > This patch doesn't apply at all, what tree did you make it against? > > Please redo it (and your second one) against either the linux-next > releases, or my staging-next branch of my staging.git tree on > git.kernel.org. > > thanks, > > greg k-h Hi Greg, I was using the torvalds tree. I noted that yours is different from his. So, downloading and soon sending the second patch against your staging (https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/). Thanks. Geyslan. -- 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/
