[PATCH 1/2] gpio: pcf857x: Avoid calling irq_domain_cleanup twice
Currently irq_domain_cleanup is called twice if irq_domain_init fails.
This causes the following crash.
Unable to handle kernel paging request at virtual address 00100104
pgd = c0004000
[00100104] *pgd=
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.12.15-01889-gedd10a8-dirty #4
Workqueue: deferwq deferred_probe_work_func
task: ed0ee800 ti: ed116000 task.ti: ed116000
PC is at irq_domain_remove+0x3c/0x8c
LR is at 0x0
pc : []lr : [<>]psr: a013
sp : ed117b50 ip : 00100100 fp : ed117b64
r10: ed5d1a04 r9 : 0008 r8 :
r7 : ffea r6 : ed5d1a20 r5 : ed5d1a00 r4 : ed5e7540
r3 : 00200200 r2 : 00100100 r1 : c08aa180 r0 : 00200200
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 8000406a DAC: 0017
Process kworker/u4:0 (pid: 6, stack limit = 0xed116248)
Stack: (0xed117b50 to 0xed118000)
7b40: 016b ed5d5f10 ed117b74 ed117b68
7b60: c02c8910 c0089704 ed117bb4 ed117b78 c02c8e14 c02c8900 ed5d1a04 ed5d4e80
...
...
fe0: 0013 384a13ea 1590210a
Backtrace:
[] (irq_domain_remove+0x0/0x8c) from []
(pcf857x_irq_domain_cleanup+0x1c/0x20)
r4:ed5d5f10 r3:016b
[] (pcf857x_irq_domain_cleanup+0x0/0x20) from []
(pcf857x_probe+0x2a8/0x364)
[] (pcf857x_probe+0x0/0x364) from []
(i2c_device_probe+0x80/0xc0)
[] (i2c_device_probe+0x0/0xc0) from []
(driver_probe_device+0x104/0x240)
r6: r5:ed5d1a20 r4:c08c709c r3:c047872c
[] (driver_probe_device+0x0/0x240) from []
(__device_attach+0x48/0x4c)
r7:ed4fc480 r6:c036c510 r5:ed5d1a20 r4:c0866bb8
[] (__device_attach+0x0/0x4c) from []
(bus_for_each_drv+0x4c/0x94)
r5:ed5d1a20 r4:
[] (bus_for_each_drv+0x0/0x94) from []
(device_attach+0x78/0x90)
r6:c087fe50 r5:ed5d1a54 r4:ed5d1a20
[] (device_attach+0x0/0x90) from []
(bus_probe_device+0x8c/0xb4)
r6:c087fe50 r5:ed5d1a20 r4:ed5d1a20 r3:ed17e1c0
[] (bus_probe_device+0x0/0xb4) from []
(device_add+0x34c/0x624)
r6:ed5d1a28 r5: r4:ed5d1a20 r3:fffe
[] (device_add+0x0/0x624) from []
(device_register+0x1c/0x20)
...
...
[] (process_one_work+0x0/0x37c) from []
(worker_thread+0x13c/0x3c4)
[] (worker_thread+0x0/0x3c4) from [] (kthread+0xac/0xb8)
[] (kthread+0x0/0xb8) from [] (ret_from_fork+0x14/0x3c)
r7: r6: r5:c0067040 r4:ed105d20
Code: e59fc04c e591e000 e59f0048 e154000e (e5823004)
---[ end trace 59dd1e90032c4217 ]---
Signed-off-by: George Cherian
---
drivers/gpio/gpio-pcf857x.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 8273582..5acffed 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -319,7 +319,7 @@ static int pcf857x_probe(struct i2c_client *client,
status = pcf857x_irq_domain_init(gpio, client);
if (status < 0) {
dev_err(>dev, "irq_domain init failed\n");
- goto fail;
+ goto fail_irq_domain;
}
}
@@ -414,12 +414,13 @@ static int pcf857x_probe(struct i2c_client *client,
return 0;
fail:
- dev_dbg(>dev, "probe error %d for '%s'\n",
- status, client->name);
-
if (client->irq)
pcf857x_irq_domain_cleanup(gpio);
+fail_irq_domain:
+ dev_dbg(>dev, "probe error %d for '%s'\n",
+ status, client->name);
+
return status;
}
--
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 2/2] gpio: pcf857x: Add IRQF_SHARED when request irq
It's quite possible that multiple pcf857x can be hooked up to the same interrupt line with the processor. So add IRQF_SHARED in request irq.. Signed-off-by: George Cherian --- drivers/gpio/gpio-pcf857x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c index 5acffed..27b4675 100644 --- a/drivers/gpio/gpio-pcf857x.c +++ b/drivers/gpio/gpio-pcf857x.c @@ -262,7 +262,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio, /* enable real irq */ status = devm_request_threaded_irq(>dev, client->irq, NULL, pcf857x_irq, IRQF_ONESHOT | - IRQF_TRIGGER_FALLING, + IRQF_TRIGGER_FALLING | IRQF_SHARED, dev_name(>dev), gpio); if (status) -- 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/
Re: 3.15.0-rc6: VM_BUG_ON_PAGE(PageTail(page), page)
On 23.5.2014 6:21, Sasha Levin wrote: On 05/22/2014 09:58 AM, Dave Jones wrote: Not sure if Sasha has already reported this on -next (It's getting hard to keep track of all the VM bugs he's been finding), but I hit this overnight on .15-rc6. First time I've seen this one. Unfortunately I had to disable transhuge/hugetlb in my testing .config since the open issues in -next get hit pretty often, and were unfixed for a while now. Meh, I lost track. We should really consider something like bugzilla for this, IMHO. Keeping them enabled just made it impossible to test anything else. Thanks, Sasha -- 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/
[PATCH 2/2] serial: imx: disable the receiver ready interrupt for imx_stop_rx
This patch disables the receiver ready interrupt for imx_stop_rx. It reduces the interrupt numbers when the uart is going to close or suspend. Signed-off-by: Huang Shijie --- drivers/tty/serial/imx.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index ed6cdf7..6026101 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -440,6 +440,10 @@ static void imx_stop_rx(struct uart_port *port) temp = readl(sport->port.membase + UCR2); writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2); + + /* disable the `Receiver Ready Interrrupt` */ + temp = readl(sport->port.membase + UCR1); + writel(temp & ~UCR1_RRDYEN, sport->port.membase + UCR1); } /* -- 1.7.8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] serial: imx: remove the DMA wait queue
The DMA wait queue makes the code very complicated:
For RX, the @->stop_rx hook does not really stop the RX;
For TX, the @->stop_tx hook does not really stop the TX.
The above make the imx_shutdown has to wait the RX/TX DMA to be finished.
In order to make code more simple, this patch removes the DMA wait queue.
By calling the dmaengine_terminate_all, this patch makes the RX stops
immediately after we call the @->stop_rx hook, so does the TX.
Signed-off-by: Huang Shijie
---
drivers/tty/serial/imx.c | 42 ++
1 files changed, 14 insertions(+), 28 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index d1f16d3..ed6cdf7 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -225,7 +225,6 @@ struct imx_port {
void*rx_buf;
unsigned inttx_bytes;
unsigned intdma_tx_nents;
- wait_queue_head_t dma_wait;
unsigned intsaved_reg[11];
};
@@ -417,12 +416,10 @@ static void imx_stop_tx(struct uart_port *port)
return;
}
- /*
-* We are maybe in the SMP context, so if the DMA TX thread is running
-* on other cpu, we have to wait for it to finish.
-*/
- if (sport->dma_is_enabled && sport->dma_is_txing)
- return;
+ if (sport->dma_is_enabled && sport->dma_is_txing) {
+ dmaengine_terminate_all(sport->dma_chan_tx);
+ sport->dma_is_txing = 0;
+ }
temp = readl(sport->port.membase + UCR1);
writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1);
@@ -436,12 +433,10 @@ static void imx_stop_rx(struct uart_port *port)
struct imx_port *sport = (struct imx_port *)port;
unsigned long temp;
- /*
-* We are maybe in the SMP context, so if the DMA TX thread is running
-* on other cpu, we have to wait for it to finish.
-*/
- if (sport->dma_is_enabled && sport->dma_is_rxing)
- return;
+ if (sport->dma_is_enabled && sport->dma_is_rxing) {
+ dmaengine_terminate_all(sport->dma_chan_rx);
+ sport->dma_is_rxing = 0;
+ }
temp = readl(sport->port.membase + UCR2);
writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
@@ -498,12 +493,6 @@ static void dma_tx_callback(void *data)
dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
uart_write_wakeup(>port);
-
- if (waitqueue_active(>dma_wait)) {
- wake_up(>dma_wait);
- dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
- return;
- }
}
static void imx_dma_tx(struct imx_port *sport)
@@ -876,10 +865,6 @@ static void imx_rx_dma_done(struct imx_port *sport)
writel(temp, sport->port.membase + UCR1);
sport->dma_is_rxing = 0;
-
- /* Is the shutdown waiting for us? */
- if (waitqueue_active(>dma_wait))
- wake_up(>dma_wait);
}
/*
@@ -1026,8 +1011,6 @@ static void imx_enable_dma(struct imx_port *sport)
{
unsigned long temp;
- init_waitqueue_head(>dma_wait);
-
/* set UCR1 */
temp = readl(sport->port.membase + UCR1);
temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
@@ -1219,10 +1202,13 @@ static void imx_shutdown(struct uart_port *port)
unsigned long flags;
if (sport->dma_is_enabled) {
- /* We have to wait for the DMA to finish. */
- wait_event(sport->dma_wait,
- !sport->dma_is_rxing && !sport->dma_is_txing);
+ /*
+* The upper layer may does not call the @->stop_tx and
+* @->stop_rx, so we call them ourselves.
+*/
+ imx_stop_tx(port);
imx_stop_rx(port);
+
imx_disable_dma(sport);
imx_uart_dma_exit(sport);
}
--
1.7.8
--
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/4] drm/ttm: introduce dma cache sync helpers
On Mon, May 19, 2014 at 5:33 PM, Thierry Reding
wrote:
> On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote:
>> From: Lucas Stach
>>
>> On arches with non-coherent PCI,
>
> I guess since this applies to gk20a
>
>> we need to flush caches ourselfes at
>
> "ourselves". Or perhaps even reword to something like: "..., caches need
> to be flushed and invalidated explicitly", since dma_sync_for_cpu() does
> invalidate rather than flush.
Rephrased as "On arches for which access to GPU memory is non-coherent, caches
need to be flushed and invalidated explicitly at the appropriate places."
>
>> the appropriate places. Introduce two small helpers to make things easy
>> for TTM based drivers.
>>
>> Signed-off-by: Lucas Stach
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/drm/ttm/ttm_tt.c| 25 +
>> include/drm/ttm/ttm_bo_driver.h | 28
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> [...]
>> +void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
>> + struct device *dev)
>> +{
>> + int i;
>
> This should probably be unsigned long to match the type of
> ttm_dma->ttm.num_pages.
Fixed.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
One question about this patch.
Why don't you use the devices cgroup check if the root user in that namespace
is allowed to use this device?
This way you can be sure that the root in that namespace can not access devices
to which the host system did not gave
him access to.
Marian
On 05/15/2014 12:34 AM, Seth Forshee wrote:
> Signed-off-by: Seth Forshee ---
> drivers/block/loop.c | 14 +- 1 file
> changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c index
> 66bd938bcc1c..2cc19868ea0d 100644 ---
> a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1074,7 +1074,7 @@
> loop_set_status(struct loop_device *lo,
> const struct loop_info64 *info)
>
> if (lo->lo_encrypt_key_size && !uid_eq(lo->lo_key_owner, uid) && -
> !capable(CAP_SYS_ADMIN)) +
> !ns_capable(disk_to_dev(lo->lo_disk)->ns, CAP_SYS_ADMIN)) return -EPERM; if
> (lo->lo_state != Lo_bound) return
> -ENXIO; @@ -1164,7 +1164,8 @@ loop_get_status(struct loop_device *lo, struct
> loop_info64 *info)
> memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
> info->lo_encrypt_type = lo->lo_encryption ?
> lo->lo_encryption->number : 0; - if (lo->lo_encrypt_key_size &&
> capable(CAP_SYS_ADMIN)) { + if
> (lo->lo_encrypt_key_size && + ns_capable(disk_to_dev(lo->lo_disk)->ns,
> CAP_SYS_ADMIN)) {
> info->lo_encrypt_key_size = lo->lo_encrypt_key_size;
> memcpy(info->lo_encrypt_key, lo->lo_encrypt_key,
> lo->lo_encrypt_key_size); @@ -1309,7 +1310,8 @@ static int lo_ioctl(struct
> block_device *bdev, fmode_t mode,
> break; case LOOP_SET_STATUS: err = -EPERM; - if ((mode &
> FMODE_WRITE) || capable(CAP_SYS_ADMIN)) + if ((mode &
> FMODE_WRITE) || + ns_capable(disk_to_dev(lo->lo_disk)->ns,
> CAP_SYS_ADMIN)) err = loop_set_status_old(lo,
> (struct loop_info __user *)arg); break; @@ -1318,7 +1320,8 @@ static int
> lo_ioctl(struct block_device *bdev,
> fmode_t mode, break; case LOOP_SET_STATUS64: err = -EPERM; - if
> ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN)) +
> if ((mode & FMODE_WRITE) || +
> ns_capable(disk_to_dev(lo->lo_disk)->ns, CAP_SYS_ADMIN)) err =
> loop_set_status64(lo, (struct loop_info64 __user *) arg); break; @@ -1327,7
> +1330,8 @@ static int lo_ioctl(struct
> block_device *bdev, fmode_t mode, break; case LOOP_SET_CAPACITY: err =
> -EPERM; - if ((mode & FMODE_WRITE) ||
> capable(CAP_SYS_ADMIN)) + if ((mode & FMODE_WRITE) || +
> ns_capable(disk_to_dev(lo->lo_disk)->ns,
> CAP_SYS_ADMIN)) err = loop_set_capacity(lo, bdev); break; default:
>
- --
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hack...@jabber.org
ICQ: 7556201
Mobile: +359 886 660 270
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlN+4SkACgkQ4mt9JeIbjJQMTACffYfr/7IGyjGU0DGnqxRJNMvv
3o4An06xvFTbINvXX9AYrM/gwTDL0GMt
=mlO7
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ASoC: max98090: Add master clock handling
On 22 May 2014 16:00, Mark Brown wrote:
> On Thu, May 22, 2014 at 02:47:07PM +0530, Tushar Behera wrote:
>
>> + max98090->mclk = devm_clk_get(codec->dev, "mclk");
>> + if (!IS_ERR(max98090->mclk))
>> + clk_prepare_enable(max98090->mclk);
>> +
>
> Ths doesn't handle deferred probe, we need to at least return an error
> if we get -EPROBE_DEFER.
>
Ok.
> It'd also be better to move the enabling to set_bias_level() if possible
> (I don't know if the clock is needed for register access) though less
> essential.
I tested with moving clk_enable/clk_disable calls to set_bias_level():
SND_SOC_BIAS_PREPARE. That works well for me. Does it look okay?
@@ -1801,6 +1801,25 @@ static int max98090_set_bias_level(struct
snd_soc_codec *codec,
break;
case SND_SOC_BIAS_PREPARE:
+ /*
+* SND_SOC_BIAS_PREPARE is called while preparing for a
+* transition to ON or away from ON. If current bias_level
+* is SND_SOC_BIAS_ON, then it is preparing for a transition
+* away from ON. Disable the clock in that case, otherwise
+* enable it.
+*/
+ if (!IS_ERR(max98090->mclk)) {
+ if (codec->dapm.bias_level == SND_SOC_BIAS_ON)
+ clk_disable(max98090->mclk);
+ else
+ clk_enable(max98090->mclk);
+ }
break;
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the mmc tree
Hi Chris,
After merging the mmc tree, today's linux-next build (arm multi_v7_defconfig)
failed like this:
drivers/mmc/host/sdhci-dove.c: In function 'sdhci_dove_carddetect_irq':
drivers/mmc/host/sdhci-dove.c:42:24: error: 'struct sdhci_host' has no member
named 'card_tasklet'
Caused by commit 3560db8e247a ("mmc: sdhci: push card_tasklet into
threaded irq handler").
I have used the mmc tree from next-20140522 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
linux-next: manual merge of the mmc tree with the slave-dma tree
Hi Chris,
Today's linux-next merge of the mmc tree got a conflict in
include/linux/omap-dma.h between commit a8246fedacad ("dmaengine: omap:
hide filter_fn for built-in drivers") from the slave-dma tree and
commit ee526d515ad1 ("mmc: omap_hsmmc: split omap-dma header file")
from the mmc tree.
I fixed it up (I effectively applied the former commit to the new file)
and can carry the fix as necessary (no action is required).
From: Stephen Rothwell
Date: Fri, 23 May 2014 15:19:48 +1000
Subject: [PATCH] dmaengine: omap: fix for code movement
Signed-off-by: Stephen Rothwell
---
include/linux/omap-dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
index 2b0b6aa01922..8e6906c72e90 100644
--- a/include/linux/omap-dmaengine.h
+++ b/include/linux/omap-dmaengine.h
@@ -10,7 +10,7 @@
struct dma_chan;
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+#if defined(CONFIG_DMA_OMAP) || (defined(CONFIG_DMA_OMAP_MODULE) &&
defined(MODULE))
bool omap_dma_filter_fn(struct dma_chan *, void *);
#else
static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
--
2.0.0.rc4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH] elf, coredump: Extract only the active register set during core dump
Regset active hooks provide a way to query how many registers in the
register set are active at any point of time. Currently this information
is being ignored while creating core dump sections corresponding to any
core note register set. This way the core dump will contain data which are
not part of the active context of the process and may not be useful. This
patch will make sure that only the active part of the register set are
captured during the core dump process which will reduce the core dump
size.
Signed-off-by: Anshuman Khandual
---
NOTE:
Pedro Alves has mentioned that producing smaller note sections in the core
dump may break some existing consumers. I request suggestions, reviews and
test reports on different architectures to prove that this patch does not
break any existing consumer. Thank you.
Please find the previous discussion here
https://lkml.org/lkml/2014/5/20/185
Regards
Anshuman
fs/binfmt_elf.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index aa3cb62..00aba07 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1551,10 +1551,18 @@ static int fill_thread_core_info(struct
elf_thread_core_info *t,
const struct user_regset *regset = >regsets[i];
do_thread_regset_writeback(t->task, regset);
if (regset->core_note_type && regset->get &&
- (!regset->active || regset->active(t->task, regset))) {
+ (!regset->active || regset->active(t->task, regset) > 0)) {
int ret;
- size_t size = regset->n * regset->size;
- void *data = kmalloc(size, GFP_KERNEL);
+ size_t size;
+ void *data;
+
+ if (!regset->active)
+ size = regset->n * regset->size;
+ else
+ size = regset->active(t->task, regset)
+ * regset->size;
+
+ data = kmalloc(size, GFP_KERNEL);
if (unlikely(!data))
return 0;
ret = regset->get(t->task, regset,
--
1.7.11.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: [f2fs-dev] [PATCH] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages
On Wed, May 21, 2014 at 12:36:46PM +0900, Jaegeuk Kim wrote:
> Hi Chao,
>
> 2014-05-16 (금), 17:14 +0800, Chao Yu:
> > Previously we allocate pages with no mapping in ra_sum_pages(), so we may
> > encounter a crash in event trace of f2fs_submit_page_mbio where we access
> > mapping data of the page.
> >
> > We'd better allocate pages in bd_inode mapping and invalidate these pages
> > after
> > we restore data from pages. It could avoid crash in above scenario.
> >
> > Call Trace:
> > [] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
> > [] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
> > [] restore_node_summary+0x13a/0x280 [f2fs]
> > [] build_curseg+0x2bd/0x620 [f2fs]
> > [] build_segment_manager+0x1cb/0x920 [f2fs]
> > [] f2fs_fill_super+0x535/0x8e0 [f2fs]
> > [] mount_bdev+0x16a/0x1a0
> > [] f2fs_mount+0x1f/0x30 [f2fs]
> > [] mount_fs+0x36/0x170
> > [] vfs_kern_mount+0x55/0xe0
> > [] do_mount+0x1e8/0x900
> > [] SyS_mount+0x82/0xc0
> > [] sysenter_do_call+0x12/0x22
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/node.c | 49 -
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 3d60d3d..b5cd814 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1658,13 +1658,16 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
> > struct page *page)
> >
> > /*
> > * ra_sum_pages() merge contiguous pages into one bio and submit.
> > - * these pre-readed pages are linked in pages list.
> > + * these pre-readed pages are alloced in bd_inode's mapping tree.
> > */
> > -static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head *pages,
> > +static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
> > int start, int nrpages)
> > {
> > struct page *page;
> > + struct inode *inode = sbi->sb->s_bdev->bd_inode;
How about use sbi->meta_inode instead of bd_inode, then we can do
caching summary pages for further i/o.
> > + struct address_space *mapping = inode->i_mapping;
> > int page_idx = start;
> > + int alloced, readed;
> > struct f2fs_io_info fio = {
> > .type = META,
> > .rw = READ_SYNC | REQ_META | REQ_PRIO
> > @@ -1672,21 +1675,23 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi,
> > struct list_head *pages,
> >
> > for (; page_idx < start + nrpages; page_idx++) {
> > /* alloc temporal page for read node summary info*/
> > - page = alloc_page(GFP_F2FS_ZERO);
> > + page = grab_cache_page(mapping, page_idx);
> > if (!page)
> > break;
> > -
> > - lock_page(page);
> > - page->index = page_idx;
> > - list_add_tail(>lru, pages);
> > + page_cache_release(page);
>
> IMO, we don't need to do like this.
> Instead,
> for() {
> page = grab_cache_page();
> if (!page)
> break;
> page[page_idx] = page;
> f2fs_submit_page_mbio(sbi, page, );
> }
> f2fs_submit_merged_bio(sbi, META, READ);
> return page_idx - start;
>
> Afterwards, in restore_node_summry(),
> lock_page() will wait the end_io for read.
> ...
> f2fs_put_page(pages[index], 1);
>
> Thanks,
>
> > }
> >
> > - list_for_each_entry(page, pages, lru)
> > - f2fs_submit_page_mbio(sbi, page, page->index, );
> > + alloced = page_idx - start;
> > + readed = find_get_pages_contig(mapping, start, alloced, pages);
> > + BUG_ON(alloced != readed);
> > +
> > + for (page_idx = 0; page_idx < readed; page_idx++)
> > + f2fs_submit_page_mbio(sbi, pages[page_idx],
> > + pages[page_idx]->index, );
> >
> > f2fs_submit_merged_bio(sbi, META, READ);
> >
> > - return page_idx - start;
> > + return readed;
> > }
> >
> > int restore_node_summary(struct f2fs_sb_info *sbi,
> > @@ -1694,11 +1699,11 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> > {
> > struct f2fs_node *rn;
> > struct f2fs_summary *sum_entry;
> > - struct page *page, *tmp;
> > + struct inode *inode = sbi->sb->s_bdev->bd_inode;
> > block_t addr;
> > int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
> > - int i, last_offset, nrpages, err = 0;
> > - LIST_HEAD(page_list);
> > + struct page *pages[bio_blocks];
> > + int i, index, last_offset, nrpages, err = 0;
> >
> > /* scan the node segment */
> > last_offset = sbi->blocks_per_seg;
> > @@ -1709,29 +1714,31 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> > nrpages = min(last_offset - i, bio_blocks);
> >
> > /* read ahead node pages */
> > - nrpages = ra_sum_pages(sbi, _list, addr, nrpages);
> > + nrpages = ra_sum_pages(sbi, pages, addr, nrpages);
> > if (!nrpages)
> > return -ENOMEM;
> >
>
Re: [PATCH net] bridge: notify user space of fdb port change
> - Original Message -
> > From: "Toshiaki Makita"
> > To: "Jon Maxwell" , step...@networkplumber.org
> > Cc: da...@davemloft.net, vyase...@redhat.com,
> > bri...@lists.linux-foundation.org, net...@vger.kernel.org,
> > linux-kernel@vger.kernel.org, jpi...@redhat.com, jmaxw...@redhat.com
> > Sent: Wednesday, May 14, 2014 10:34:38 AM
> > Subject: Re: [PATCH net] bridge: notify user space of fdb port change
> >
> > (2014/05/13 16:55), Jon Maxwell wrote:
> > > From: Jon Maxwell
> > >
> > > There has been a number incidents recently where customers running KVM
> > > have
> > > reported that VM hosts on different Hypervisors are unreachable. Based on
> > > pcap traces we found that the bridge was broadcasting the ARP request out
> > > onto the network. However some NICs have an inbuilt switch which on
> > > occasions
> > > were broadcasting the VMs ARP request back through the physical NIC on
> > > the
> > > Hypervisor. This resulted in the bridge changing ports and incorrectly
> > > learning
> > > that the VMs mac address was external. As a result the ARP reply was
> > > directed
> > > back onto the external network and VM never updated it's ARP cache. This
> > > patch
> > > will notify the bridge command to identify such port toggling.
> > >
> > > Signed-off-by: Jon Maxwell
> > > ---
> > > net/bridge/br_fdb.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> > > index 9203d5a..37742e2 100644
> > > --- a/net/bridge/br_fdb.c
> > > +++ b/net/bridge/br_fdb.c
> > > @@ -507,6 +507,8 @@ void br_fdb_update(struct net_bridge *br, struct
> > > net_bridge_port *source,
> > > source->dev->name);
> > > } else {
> > > /* fastpath: update of existing entry */
> > > + if (source->port_no != fdb->dst->port_no)
> >
> > It seems that we don't need to fetch port_no and it is enough to compare
> > source and fdb->dst.
>
> It may save a few instructions but I have not tested it.
>
> >
> > > + fdb_notify(br, fdb, RTM_NEWNEIGH);
> > > fdb->dst = source;
> > > fdb->updated = jiffies;
> > > if (unlikely(added_by_user))
> > >
> >
> > This notifies fdb entry before updating existing entry. Is this on purpose?
> > I think we should notify the updated fdb entry.
> > Similar code fdb_add_entry() does after updating it.
>
> It was not on purpose but for this particular case there will be burst of
> notifies
> so it probably does not matter. However I agree it should be after the
> update.
> I will do that along with adding the unlikely() conditional and resubmit.
>
> >
> > Also, isn't it better to move update of dst into "if" block?
>
> I would prefer to leave this portion as alone and only use the if
> statement for the notify.
>
> >
> > if (source != fdb->dst) {
> > fdb->dst = source;
> > modified = true;
> > }
> > ...
> > if (modified) ...
> >
Makita-san,
I recoded this using your idea and ran it through a reproducer.
It work fine. After some more consideration I agree that
setting fdb->dst = source is only required when source != fdb->dst.
Thanks for your suggestions. This is the revised patch. It should
retain the original behaviour except for the notify after the fdb update.
Please let me know if you have any further input?
$ diff -Naur br_fdb.c br_fdb.c.patch
--- br_fdb.c2014-05-17 12:43:23.346319609 +1000
+++ br_fdb.c.patch2014-05-17 16:54:46.280235728 +1000
@@ -487,6 +487,7 @@
{
struct hlist_head *head = >hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+bool fdb_modified = 0;
/* some users want to always flood. */
if (hold_time(br) == 0)
@@ -507,10 +508,16 @@
source->dev->name);
} else {
/* fastpath: update of existing entry */
-fdb->dst = source;
+if (unlikely(source != fdb->dst))
+{
+fdb->dst = source;
+fdb_modified = 1;
+}
fdb->updated = jiffies;
if (unlikely(added_by_user))
fdb->added_by_user = 1;
+if (unlikely(fdb_modified))
+fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(>hash_lock);
> > Thanks,
> > Toshiaki Makita
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / devfreq: remove checks for CONFIG_EXYNOS_ASV
On Thu, May 22, 2014 at 5:37 AM, Paul Bolle wrote: > Checks for CONFIG_EXYNOS_ASV were added in v3.3. But the related Kconfig > symbol has never been added to the tree. Remove these checks, as they > always evaluate to false. > > Signed-off-by: Paul Bolle Thanks for pointing this out. ASV was supposed to be merged, but it appears it failed or never attempted. I will merge with the next batch (this week). Cheers, MyungJoo. > --- > 0) Untested. > > 1) I do not really care much for this patch. Two years is not very long > for dead code to remain in the tree. There is, however, a trivial issue > that makes this patch stand out from the other patches in my current > sweep of the tree for Kconfig related problems. > > See, here the use of an unknown Kconfig macro hides an obvious typo: it > should either be "exynos_result_of_asv" or "exynos4_result_of_asv", but > not both. Ie, this almost certainly wouldn't have compiled even if the > Kconfig symbol EXYNOS_ASV would have been part of the tree. > > 2) So this makes me wonder whether there are any guidelines for using > Kconfig macros before the related Kconfig symbols are merged? > > drivers/devfreq/Kconfig | 3 +-- > drivers/devfreq/exynos/exynos4_bus.c | 13 - > 2 files changed, 1 insertion(+), 15 deletions(-)
[PATCH 2/2] staging: slicoss: handle errors from slic_config_get
slic_config_get() can fail. Change the return type from void to
int and handle the error in slic_card_init(). So now, instead of
silently failing (and then timing out waiting for the config data),
the driver will fail loudly at request time.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slicoss.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 5b82455..9c48cd8 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1140,14 +1140,10 @@ static void slic_upr_request_complete(struct adapter
*adapter, u32 isr)
adapter->upr_lock.flags);
}
-static void slic_config_get(struct adapter *adapter, u32 config,
- u32 config_h)
+static int slic_config_get(struct adapter *adapter, u32 config, u32 config_h)
{
- int status;
-
- status = slic_upr_request(adapter,
- SLIC_UPR_RCONFIG,
- (u32) config, (u32) config_h, 0, 0);
+ return slic_upr_request(adapter, SLIC_UPR_RCONFIG, config, config_h,
+ 0, 0);
}
/*
@@ -3262,7 +3258,12 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
spin_unlock_irqrestore(>bit64reglock.lock,
adapter->bit64reglock.flags);
- slic_config_get(adapter, phys_configl, phys_configh);
+ status = slic_config_get(adapter, phys_configl, phys_configh);
+ if (status) {
+ dev_err(>pcidev->dev,
+ "Failed to fetch config data from device.\n");
+ goto card_init_err;
+ }
for (;;) {
if (adapter->pshmem->isr) {
@@ -3293,10 +3294,8 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
_regs->slic_isp, 0,
_regs->slic_addr_upper,
0, FLUSH);
- pci_free_consistent(adapter->pcidev,
- sizeof(struct slic_eeprom),
- peeprom, phys_config);
- return -EINVAL;
+ status = -EINVAL;
+ goto card_init_err;
}
}
}
@@ -3406,6 +3405,11 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
card->reset_in_progress = 0;
return 0;
+
+card_init_err:
+ pci_free_consistent(adapter->pcidev, sizeof(struct slic_eeprom),
+ peeprom, phys_config);
+ return status;
}
static void slic_init_driver(void)
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] fix two bugs in slic_card_init
This patchset fixes two bugs in slic_card_init(). They are grouped in a series because the second patch depends on the first (for a merge without conflicts). In content, they are completely separate changes. They just touch a few of the same lines. David Matlack (2): staging: slicoss: fix dma memory leak staging: slicoss: handle errors from slic_config_get drivers/staging/slicoss/slicoss.c | 25 - 1 file changed, 16 insertions(+), 9 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: slicoss: fix dma memory leak
Fix memory leak in slic_card_init. If the driver fails to poll for an interrupt after requesting config data from the device the dma memory is never freed. Signed-off-by: David Matlack --- This patch was originally sent here https://lkml.org/lkml/2014/5/6/7 with my google.com email address. But due to Google's recent change in DMARC policies, that patchset was silently dropped for at least some users (including my personal gmail account). So I'm sending it out now with my gmail.com account. Let me know if this is an issue. Thanks. drivers/staging/slicoss/slicoss.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index e27b88f..5b82455 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -3293,6 +3293,9 @@ static int slic_card_init(struct sliccard *card, struct adapter *adapter) _regs->slic_isp, 0, _regs->slic_addr_upper, 0, FLUSH); + pci_free_consistent(adapter->pcidev, + sizeof(struct slic_eeprom), + peeprom, phys_config); return -EINVAL; } } -- 1.9.2 -- 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 RFC] mmc: add slot argument to mmc_of_parse
Hi, All.
This patch is working on progress?
I want to merge this patch for fixing dw-mmc controller problem.
If this patch didn't work on progress, i will send the patch based-on this
patch.
Best Regards,
Jaehoon Chung
On 05/14/2014 06:53 PM, Ulf Hansson wrote:
> On 7 May 2014 12:06, Ludovic Desroches wrote:
>> Some hosts manage several slots. In these case information such as the bus
>> width, chip detect and others are into the slot node. So we have to parse
>> child nodes. If not NULL, slot node will be used instead of the device
>> node.
>>
>> Signed-off-by: Ludovic Desroches
>> ---
>>
>> Hi,
>>
>> Since this patch is only a RFC, I have not yet updated drivers using this
>> function.
>>
>> I would like to use mmc_of_parse to reduce code duplication. My issue is that
>> atmel mci is a bit different from others mci host since it can provide
>> several slots, so it allocates several mmc hosts. By the way, it is not the
>> only one.
>>
>> When calling mmc_alloc_host, host->parent is set to >dev. mmc_of_parse
>> uses host->parent->of_node but in my case settings are in the slot nodes so
>> in
>> the child nodes. That's why I would like to have a way to tell which node I
>> want to use.
>
> Seems reasonable, thanks for working on this!
>
>>
>>
>> Regards
>>
>> Ludovic
>>
>>
>>
>> drivers/mmc/core/host.c |9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
>> index fdea825..ed6cea5 100644
>> --- a/drivers/mmc/core/host.c
>> +++ b/drivers/mmc/core/host.c
>> @@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct
>> mmc_host *host)
>> /**
>> * mmc_of_parse() - parse host's device-tree node
>> * @host: host whose node should be parsed.
>> + * @slot: some devices provide several slots so the node to parse
>> + * is not the host one.
>> *
>> * To keep the rest of the MMC subsystem unaware of whether DT has been
>> * used to to instantiate and configure this host instance or not, we
>> * parse the properties and set respective generic mmc-host flags and
>> * parameters.
>> */
>> -int mmc_of_parse(struct mmc_host *host)
>> +int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
>> {
>> struct device_node *np;
>> u32 bus_width;
>> @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
>> if (!host->parent || !host->parent->of_node)
>> return 0;
>>
>> - np = host->parent->of_node;
>> + if (slot)
>> + np = slot;
>> + else
>> + np = host->parent->of_node;
>>
>> /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
>> if (of_property_read_u32(np, "bus-width", _width) < 0) {
>> --
>> 1.7.9.5
>>
>
> How about adding a new API, __mmc_of_parse((struct mmc_host *host,
> struct device_node *slot)
> Then let the old API mmc_of_parse() remain as is, but let it call the
> new API with slot == NULL.
>
> Atmel can then use the new API, but the other drivers can remain as is.
>
> Kind regards
> Ulf Hansson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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 1/8] cpufreq: cpufreq-cpu0: remove dependency on thermal
On 22 May 2014 20:22, Eduardo Valentin wrote: > However, on CPUs that needs thermal managment, it makes sense to have > such dependency, from functional perspective. Mainly because scaling > frequency and voltage up would be allowed only when thermal management > is enabled. AFAIK, dependencies in KCONFIG are only for fixing compilation time issues. As some APIs wouldn't be available without enabling some config options.. If drivers fail at runtime because some API returned error, fix it for your platform instead and not bug KCONFIG for that. Thought we might consider some runtime dependencies here as well. For example regulators. There probably are dummy routine available for cases where CONFIG_REGULATOR (or whatever) isn't enabled and driver would still compile, but it is guaranteed to fail as we don't continue when we get errors from regulator APIs.. Though I still feel that this driver should still support platforms without regulators (atleast in software, they might always have them on board :)).. And so dependencies for regulators may also die out one day.. The dependencies here mean: "This driver would never ever work/compile if the dependencies aren't met.." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: remove private netdev list
Remove the private linked list of netdev structs. This list isn't
being used anyway.
This patch has no noticable effect.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slic.h| 1 -
drivers/staging/slicoss/slicoss.c | 4
2 files changed, 5 deletions(-)
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 7de57c4..0dc73d5 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -407,7 +407,6 @@ struct adapter {
uintcard_size;
uintchipid;
struct net_device *netdev;
- struct net_device *next_netdevice;
struct slic_spinlock adapter_lock;
struct slic_spinlock reset_lock;
struct pci_dev *pcidev;
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index b8eeb3b..0165899 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -104,8 +104,6 @@ static char *slic_banner = "Alacritech SLIC Technology(tm)
Server "
static char *slic_proc_version = "2.0.351 2006/07/14 12:26:00";
-static struct net_device *head_netdevice;
-
static struct base_driver slic_global = { {}, 0, 0, 0, 1, NULL, NULL };
static int intagg_delay = 100;
static u32 dynamic_intagg;
@@ -2993,8 +2991,6 @@ static void slic_init_adapter(struct net_device *netdev,
adapter->slic_regs = (__iomem struct slic_regs *)memaddr;
adapter->irq = pcidev->irq;
/* adapter->netdev = netdev;*/
- adapter->next_netdevice = head_netdevice;
- head_netdevice = netdev;
adapter->chipid = chip_idx;
adapter->port = 0; /*adapter->functionnumber;*/
adapter->cardindex = adapter->port;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: fix use-after-free in slic_entry_probe
Fix a use-after-free bug that can cause a kernel oops. If
slic_card_init fails then slic_entry_probe() (the pci probe()
function for this device) will return error without cleaning
up memory (including the registered netdev struct).
Signed-off-by: David Matlack
---
This patch was originally sent here https://lkml.org/lkml/2014/5/6/10 with
my google.com email address. But due to Google's recent change in DMARC
policies, that patchset was silently dropped for at least some users
(including my personal gmail account). So I'm sending it out now with
my gmail.com account. Let me know if this is an issue. Thanks.
drivers/staging/slicoss/slicoss.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index e27b88f..6113b90 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -3595,7 +3595,6 @@ static int slic_entry_probe(struct pci_dev *pcidev,
struct net_device *netdev;
struct adapter *adapter;
void __iomem *memmapped_ioaddr = NULL;
- u32 status = 0;
ulong mmio_start = 0;
ulong mmio_len = 0;
struct sliccard *card = NULL;
@@ -3686,16 +3685,11 @@ static int slic_entry_probe(struct pci_dev *pcidev,
adapter->allocated = 1;
}
- status = slic_card_init(card, adapter);
+ err = slic_card_init(card, adapter);
+ if (err)
+ goto err_out_unmap;
- if (status != 0) {
- card->state = CARD_FAIL;
- adapter->state = ADAPT_FAIL;
- adapter->linkstate = LINK_DOWN;
- dev_err(>dev, "FAILED status[%x]\n", status);
- } else {
- slic_adapter_set_hwaddr(adapter);
- }
+ slic_adapter_set_hwaddr(adapter);
netdev->base_addr = (unsigned long)adapter->memorybase;
netdev->irq = adapter->irq;
@@ -3712,7 +3706,7 @@ static int slic_entry_probe(struct pci_dev *pcidev,
cards_found++;
- return status;
+ return 0;
err_out_unmap:
iounmap(memmapped_ioaddr);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: remove unused members of struct adapter
Removes two fields from the private "struct adapter".
memorybase duplicate of slic_regs
memorylengthwritten once and never read. This field is trivially
computed with pci_resource_len if it's ever needed in
the future.
This patch has no noticable effect.
Signed-off-by: David Matlack
---
This patch was originally sent here https://lkml.org/lkml/2014/5/6/9 with
my google.com email address. But due to Google's recent change in DMARC
policies, that patchset was silently dropped for at least some users
(including my personal gmail account). So I'm sending it out now with
my gmail.com account. Let me know if this is an issue. Thanks.
drivers/staging/slicoss/slic.h| 2 --
drivers/staging/slicoss/slicoss.c | 4 +---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 702902c..379c4f7 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -420,8 +420,6 @@ struct adapter {
ushort devid;
ushort subsysid;
u32 irq;
- void __iomem *memorybase;
- u32 memorylength;
u32 drambase;
u32 dramlength;
uintqueues_initialized;
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 452aa02..b0b8544 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -3422,7 +3422,6 @@ static void slic_init_adapter(struct net_device *netdev,
adapter->busnumber = pcidev->bus->number;
adapter->slotnumber = ((pcidev->devfn >> 3) & 0x1F);
adapter->functionnumber = (pcidev->devfn & 0x7);
- adapter->memorylength = pci_resource_len(pcidev, 0);
adapter->slic_regs = (__iomem struct slic_regs *)memaddr;
adapter->irq = pcidev->irq;
/* adapter->netdev = netdev;*/
@@ -3431,7 +3430,6 @@ static void slic_init_adapter(struct net_device *netdev,
adapter->chipid = chip_idx;
adapter->port = 0; /*adapter->functionnumber;*/
adapter->cardindex = adapter->port;
- adapter->memorybase = memaddr;
spin_lock_init(>upr_lock.lock);
spin_lock_init(>bit64reglock.lock);
spin_lock_init(>adapter_lock.lock);
@@ -3683,7 +3681,7 @@ static int slic_entry_probe(struct pci_dev *pcidev,
slic_adapter_set_hwaddr(adapter);
- netdev->base_addr = (unsigned long)adapter->memorybase;
+ netdev->base_addr = (unsigned long) memmapped_ioaddr;
netdev->irq = adapter->irq;
netdev->netdev_ops = _netdev_ops;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: fix use-after-free bug in slic_entry_remove
Fix a use-after-free bug that causes a null pointer dereference in slic_entry_halt(). Since unregister_netdev() will ultimately call slic_entry_halt() (the net_device ndo_stop() virtual function for this device), we should call it before freeing the memory that is used by slic_entry_halt(). Specifically, slic_unmap_mmio_space() frees adapter->slic_regs, but those registers are used in slic_entry_halt(). Signed-off-by: David Matlack --- This patch was originally sent here https://lkml.org/lkml/2014/5/6/5 with my google.com email address. But due to Google's recent change in DMARC policies, that patchset was silently dropped for at least some users (including my personal gmail account). So I'm sending it out now with my gmail.com account. Let me know if this is an issue. Thanks. drivers/staging/slicoss/slicoss.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index d670490..b8eeb3b 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -2526,9 +2526,10 @@ static void slic_entry_remove(struct pci_dev *pcidev) struct sliccard *card; struct mcast_address *mcaddr, *mlist; + unregister_netdev(dev); + slic_adapter_freeresources(adapter); slic_unmap_mmio_space(adapter); - unregister_netdev(dev); /* free multicast addresses */ mlist = adapter->mcastaddrs; -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: clean up use of dev_err
First, don't print pci device information or driver prefixes, this
is already printed by dev_err. Next, don't report error messages
via dev_err when the failing function already reports all errors
via dev_err.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slicoss.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 0165899..1278de8 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -395,7 +395,7 @@ static int slic_card_download_gbrcv(struct adapter *adapter)
ret = request_firmware(, file, >pcidev->dev);
if (ret) {
dev_err(>pcidev->dev,
- "SLICOSS: Failed to load firmware %s\n", file);
+ "Failed to load firmware %s\n", file);
return ret;
}
@@ -473,7 +473,7 @@ static int slic_card_download(struct adapter *adapter)
ret = request_firmware(, file, >pcidev->dev);
if (ret) {
dev_err(>pcidev->dev,
- "SLICOSS: Failed to load firmware %s\n", file);
+ "Failed to load firmware %s\n", file);
return ret;
}
numsects = *(u32 *)(fw->data + index);
@@ -2783,13 +2783,8 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
/* Download the microcode */
status = slic_card_download(adapter);
-
- if (status != 0) {
- dev_err(>pcidev->dev,
- "download failed bus %d slot %d\n",
- adapter->busnumber, adapter->slotnumber);
+ if (status)
return status;
- }
if (!card->config_set) {
peeprom = pci_alloc_consistent(adapter->pcidev,
@@ -2801,8 +2796,7 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
if (!peeprom) {
dev_err(>pcidev->dev,
- "eeprom read failed to get memory bus %d slot
%d\n", adapter->busnumber,
- adapter->slotnumber);
+ "Failed to allocate DMA memory for EEPROM.\n");
return -ENOMEM;
} else {
memset(peeprom, 0, sizeof(struct slic_eeprom));
@@ -2846,8 +2840,7 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
i++;
if (i > 5000) {
dev_err(>pcidev->dev,
- "%d config data fetch timed
out!\n",
- adapter->port);
+ "Fetch of config data timed
out.\n");
slic_reg64_write(adapter,
_regs->slic_isp, 0,
_regs->slic_addr_upper,
@@ -2931,19 +2924,16 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
slic_reg64_write(adapter, _regs->slic_isp, 0,
_regs->slic_addr_upper,
0, FLUSH);
- dev_err(>pcidev->dev,
- "unsupported CONFIGURATION EEPROM invalid\n");
+ dev_err(>pcidev->dev, "EEPROM invalid.\n");
return -EINVAL;
}
card->config_set = 1;
}
- if (slic_card_download_gbrcv(adapter)) {
- dev_err(>pcidev->dev,
- "unable to download GB receive microcode\n");
- return -EINVAL;
- }
+ status = slic_card_download_gbrcv(adapter);
+ if (status)
+ return status;
if (slic_global.dynamic_intagg)
slic_intagg_set(adapter, 0);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: fix 64-bit isr address bug
Fix a bug that only manifests when the physical address of the interrupt status register is >4GB. Specifically, the driver was only telling the device about the lower 32 bits of the ISR. This patch adds the upper 32 bits. Without this patch, polling the ISR times out whenever the physical address of the ISR is >4GB. This causes the driver to think it failed to fetch config data from the device when it really didn't. Note: The way 64-bit addresses are handled in this driver needs a rework. There is an entry in the TODO file for this. That will be a rather large patch set which will change a lot of the driver. So for the time being, this patch will at least let the driver run correctly on 64-bit machines with >4GB of physical memory. Signed-off-by: David Matlack --- This patch was originally sent here https://lkml.org/lkml/2014/5/6/6 with my google.com email address. But due to Google's recent change in DMARC policies, that patchset was silently dropped for at least some users (including my personal gmail account). So I'm sending it out now with my gmail.com account. Let me know if this is an issue. Thanks. drivers/staging/slicoss/slicoss.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index 39e6489..d670490 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -2815,7 +2815,8 @@ static int slic_card_init(struct sliccard *card, struct adapter *adapter) spin_lock_irqsave(>bit64reglock.lock, adapter->bit64reglock.flags); - slic_reg32_write(_regs->slic_addr_upper, 0, DONT_FLUSH); + slic_reg32_write(_regs->slic_addr_upper, +SLIC_GET_ADDR_HIGH(>isr), DONT_FLUSH); slic_reg32_write(_regs->slic_isp, SLIC_GET_ADDR_LOW(>isr), FLUSH); spin_unlock_irqrestore(>bit64reglock.lock, -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: remove gratuitous debug infrastructure
As per the TODO file, this patch removes the gratuitous debug
infrastructure. As an extra incentive for removing this code,
the debugfs files are not cleaned up properly. For example, if
register_netdev() fails in slic_entry_probe() then all debugfs
files get left behind, even after the driver module is unloaded.
Touching these files quickly leads to an oops.
The net effect of this patch is that the driver will no longer
create files in debugfs.
Signed-off-by: David Matlack
---
This patch was originally sent here https://lkml.org/lkml/2014/5/6/4 with
my google.com email address. But due to Google's recent change in DMARC
policies, that patchset was silently dropped for at least some users
(including my personal gmail account). So I'm sending it out now with
my gmail.com account. Let me know if this is an issue. Thanks.
drivers/staging/slicoss/TODO | 1 -
drivers/staging/slicoss/slic.h| 3 -
drivers/staging/slicoss/slicoss.c | 450 +-
3 files changed, 3 insertions(+), 451 deletions(-)
diff --git a/drivers/staging/slicoss/TODO b/drivers/staging/slicoss/TODO
index 62ff100..20cc9ab 100644
--- a/drivers/staging/slicoss/TODO
+++ b/drivers/staging/slicoss/TODO
@@ -18,7 +18,6 @@ TODO:
use ethtool instead
- reorder code to elminate use of forward declarations
- don't keep private linked list of drivers.
- - remove all the gratiutous debug infrastructure
- use PCI_DEVICE()
- do ethtool correctly using ethtool_ops
- NAPI?
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 379c4f7..7de57c4 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -310,8 +310,6 @@ struct sliccard {
u32 loadtimerset;
uint config_set;
struct slic_config config;
- struct dentry *debugfs_dir;
- struct dentry *debugfs_cardinfo;
struct adapter *master;
struct adapter *adapter[SLIC_MAX_PORTS];
struct sliccard *next;
@@ -450,7 +448,6 @@ struct adapter {
u32 pingtimerset;
struct timer_list loadtimer;
u32 loadtimerset;
- struct dentry *debugfs_entry;
struct slic_spinlock upr_lock;
struct slic_spinlock bit64reglock;
struct slic_rspqueue rspqueue;
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index b0b8544..39e6489 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -81,7 +81,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -104,19 +103,13 @@ static char *slic_banner = "Alacritech SLIC
Technology(tm) Server "
"and Storage Accelerator (Non-Accelerated)";
static char *slic_proc_version = "2.0.351 2006/07/14 12:26:00";
-static char *slic_product_name = "SLIC Technology(tm) Server "
- "and Storage Accelerator (Non-Accelerated)";
-static char *slic_vendor = "Alacritech, Inc.";
-static int slic_debug = 1;
-static int debug = -1;
static struct net_device *head_netdevice;
static struct base_driver slic_global = { {}, 0, 0, 0, 1, NULL, NULL };
static int intagg_delay = 100;
static u32 dynamic_intagg;
static unsigned int rcv_count;
-static struct dentry *slic_debugfs;
#define DRV_NAME "slicoss"
#define DRV_VERSION "2.0.1"
@@ -1802,430 +1795,6 @@ static u32 slic_rcvqueue_reinsert(struct adapter
*adapter, struct sk_buff *skb)
return rcvq->count;
}
-static int slic_debug_card_show(struct seq_file *seq, void *v)
-{
-#ifdef MOOKTODO
- int i;
- struct sliccard *card = seq->private;
- struct slic_config *config = >config;
- unsigned char *fru = (unsigned char *)(>config.atk_fru);
- unsigned char *oemfru = (unsigned char *)(>config.OemFru);
-#endif
-
- seq_printf(seq, "driver_version : %s\n", slic_proc_version);
- seq_puts(seq, "Microcode versions:\n");
- seq_printf(seq, "Gigabit (gb) : %s %s\n",
- MOJAVE_UCODE_VERS_STRING, MOJAVE_UCODE_VERS_DATE);
- seq_printf(seq, "Gigabit Receiver : %s %s\n",
- GB_RCVUCODE_VERS_STRING, GB_RCVUCODE_VERS_DATE);
- seq_printf(seq, "Vendor : %s\n", slic_vendor);
- seq_printf(seq, "Product Name : %s\n", slic_product_name);
-#ifdef MOOKTODO
- seq_printf(seq, "VendorId : %4.4X\n",
- config->VendorId);
- seq_printf(seq, "DeviceId : %4.4X\n",
- config->DeviceId);
- seq_printf(seq, "RevisionId : %2.2x\n",
- config->RevisionId);
- seq_printf(seq, "Bus# : %d\n", card->busnumber);
- seq_printf(seq, "Device # : %d\n", card->slotnumber);
- seq_printf(seq, "Interfaces
[PATCH] staging: slicoss: fix free-after-free in slic_entry_remove
Fix two trivial free-after-free bugs in slic_entry_remove.
1. Don't iounmap() the same address twice. adapter->slic_regs
(iounmap()'ed in slic_unmap_mmio_space()) and dev->base_addr
(iounmap()'ed in slic_entry_remove()) are the same region.
2. Don't call release_mem_region() and pci_release_regions()
on the same pci_dev struct. They both free pci memory regions.
Signed-off-by: David Matlack
---
This patch was originally sent here https://lkml.org/lkml/2014/5/6/3 with
my google.com email address. But due to Google's recent change in DMARC
policies, that patchset was silently dropped for at least some users
(including my personal gmail account). So I'm sending it out now with
my gmail.com account. Let me know if this is an issue. Thanks.
drivers/staging/slicoss/slicoss.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 6113b90..452aa02 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2955,8 +2955,6 @@ static void slic_card_cleanup(struct sliccard *card)
static void slic_entry_remove(struct pci_dev *pcidev)
{
struct net_device *dev = pci_get_drvdata(pcidev);
- u32 mmio_start = 0;
- uint mmio_len = 0;
struct adapter *adapter = netdev_priv(dev);
struct sliccard *card;
struct mcast_address *mcaddr, *mlist;
@@ -2965,12 +2963,6 @@ static void slic_entry_remove(struct pci_dev *pcidev)
slic_unmap_mmio_space(adapter);
unregister_netdev(dev);
- mmio_start = pci_resource_start(pcidev, 0);
- mmio_len = pci_resource_len(pcidev, 0);
-
- release_mem_region(mmio_start, mmio_len);
-
- iounmap((void __iomem *)dev->base_addr);
/* free multicast addresses */
mlist = adapter->mcastaddrs;
while (mlist) {
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 2/3] cpufreq: add support for intermediate (stable) frequencies
On 22 May 2014 22:07, Stephen Warren wrote:
> It seems rather odd to set both freqs->old and freqs->new to the
> intermediate frequency upon success. It feels like it would make more
> sense to remove that final else clause above, and do the following where
> this function is called:
>
> intermediate_freq = freqs.new;
> if (intermediate_freq)
> freqs.old = intermediate_freq
> freqs.new = freq_table[index].frequency
Looks better.
> (or even return the intermediate frequency from the function)
It can return errors as well and so I didn't tried to return frequency
from it. Though there are routines that return both error and freq
from such calls :)
> ?
>
> But I suppose isolating all the inside __target_intermediate() isn't so bad.
:)
>> static int __target_index(struct cpufreq_policy *policy,
>> struct cpufreq_frequency_table *freq_table, int
>> index)
>> {
>> - struct cpufreq_freqs freqs;
>> + struct cpufreq_freqs freqs = {.old = policy->cur, .flags = 0};
>> + unsigned int intermediate_freq = 0;
>> int retval = -EINVAL;
>> bool notify;
>>
>> notify = !(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION);
>> -
>> if (notify) {
>> - freqs.old = policy->cur;
>> - freqs.new = freq_table[index].frequency;
>> - freqs.flags = 0;
>> + /* Handle switching to intermediate frequency */
>> + if (cpufreq_driver->get_intermediate) {
>> + retval = __target_intermediate(policy, , index);
>> + if (retval)
>> + return retval;
>
> Shouldn't this all be outside the if (notify) block, so that
> __target_intermediate is always called, and it's just the notify
> callbacks that gets skipped if (!notify)?
So, this is logic I had:
Should we support 'intermediate freq' infrastructure when driver wants
to handle notifications themselves?
Probably not.
The whole point of implementing this 'intermediate freq' infrastructure is to
get rid of code redundancy while sending notifications. If drivers want to
handle notifications then they better handle intermediate freqs as well in
their target_index() callback. They don't need to implement another routine
for intermediate stuff..
--
viresh
--
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: 3.15.0-rc6: VM_BUG_ON_PAGE(PageTail(page), page)
On 05/22/2014 09:58 AM, Dave Jones wrote: > Not sure if Sasha has already reported this on -next (It's getting hard > to keep track of all the VM bugs he's been finding), but I hit this overnight > on .15-rc6. First time I've seen this one. Unfortunately I had to disable transhuge/hugetlb in my testing .config since the open issues in -next get hit pretty often, and were unfixed for a while now. Keeping them enabled just made it impossible to test anything else. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] cpufreq: Tegra: implement intermediate frequency callbacks
On 22 May 2014 22:09, Stephen Warren wrote: > I think the call to tegra_target_intermediate() is wrong here; shouldn't > the cpufreq core guarantee that tegra_target_intermediate() has always > been called before tegra_target(), so there's no need to repeat that > call here? That's what Doug requested in the previous version. get_intermediate() can return zero in case drivers don't want to switch to intermediate frequency for some target frequency. Core should rather guarantee that target_index() is always called, if you want core to guarantee that target_intermediate() is also always called, then don't ever return zero from get_intermediate. I did it that way for tegra as both target_intermediate() & target_index() would have tried to set the same frequency for this particular case, i.e. when target freq == intermediate frequency. And both would have sent notification and the last notification wouldn't have made any sense, both old-freq & new-freq would have been intermediate freqs. So, yes I see the feature suggested by Doug quite useful. Like in your case. > Also, tegra_target() doesn't seem to follow the rule documented by patch > 2/3 that states ->target() should restore the orignal frequency on > error. I'm not even sure if that's possible in general. I thought I took care of that. Can you please give some example when we aren't restoring original frequency on failure ? About the rule, that has to be the expectation from core as there is no way out that for core to know what happened at end of target_index().. It can call get_rate() but that would be over engineering it looks .. -- 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: sched: spinlock recursion in migrate_swap_stop
On 05/22/2014 02:59 AM, Peter Zijlstra wrote: > On Wed, May 21, 2014 at 10:34:44PM -0400, Sasha Levin wrote: >> On 05/21/2014 12:49 PM, Peter Zijlstra wrote: >>> On Wed, May 21, 2014 at 03:19:48PM +0200, Peter Zijlstra wrote: > On Wed, May 21, 2014 at 09:08:26AM -0400, Sasha Levin wrote: >>> +++ b/kernel/sched/core.c >>> @@ -1154,6 +1156,7 @@ int migrate_swap(struct task_struct *cur, struct >>> task_struct *p) >>> goto out; >>> >>> trace_sched_swap_numa(cur, arg.src_cpu, p, arg.dst_cpu); >>> + BUG_ON(cur == p); >>> ret = stop_two_cpus(arg.dst_cpu, arg.src_cpu, >>> migrate_swap_stop, ); >>> >>> out: >>> >>> >>> Which seems to get hit. This sounds like a race with task moving to >>> other cpu maybe? > > Oi, good call that, lemme go stare. >>> I think something simple like this should be sufficient to avoid the >>> problem of selecting oneself as a flip target. >> >> Why would that happen in the first place? > > We do all that with preemption enabled, because its big and expensive, > so its entirely possible that current (env->p) got moved around while we > were doing it, at which point we'll look at it as a possible dst, while > its already our src. Seems to be working fine now, thanks! Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] memory-failure: Send right signal code to correct thread
On Tue, May 20, 2014 at 09:28:00AM -0700, Luck, Tony wrote:
> When a thread in a multi-threaded application hits a machine
> check because of an uncorrectable error in memory - we want to
> send the SIGBUS with si.si_code = BUS_MCEERR_AR to that thread.
> Currently we fail to do that if the active thread is not the
> primary thread in the process. collect_procs() just finds primary
> threads and this test:
> if ((flags & MF_ACTION_REQUIRED) && t == current) {
> will see that the thread we found isn't the current thread
> and so send a si.si_code = BUS_MCEERR_AO to the primary
> (and nothing to the active thread at this time).
>
> We can fix this by checking whether "current" shares the same
> mm with the process that collect_procs() said owned the page.
> If so, we send the SIGBUS to current (with code BUS_MCEERR_AR).
>
> Reported-by: Otto Bruggeman
> Signed-off-by: Tony Luck
> ---
> mm/memory-failure.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 35ef28acf137..642c8434b166 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -204,9 +204,9 @@ static int kill_proc(struct task_struct *t, unsigned long
> addr, int trapno,
> #endif
> si.si_addr_lsb = compound_order(compound_head(page)) + PAGE_SHIFT;
>
> - if ((flags & MF_ACTION_REQUIRED) && t == current) {
> + if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
> si.si_code = BUS_MCEERR_AR;
> - ret = force_sig_info(SIGBUS, , t);
> + ret = force_sig_info(SIGBUS, , current);
> } else {
> /*
>* Don't use force here, it's convenient if the signal
> --
> 1.8.4.1
Very interesting. I remembered there was a thread about AO error. Here is
the link: http://www.spinics.net/lists/linux-mm/msg66653.html.
According to this link, I have two concerns:
1) how to handle the similar scenario like it in this link. I mean once
the main thread doesn't handle AR error but a thread does this, if SIGBUS
can't be handled at once.
2) why that patch isn't merged. From that thread, Naoya should mean
"acknowledge" :-).
signature.asc
Description: Digital signature
[PATCH RESEND] drm/ttm: remove declaration of ttm_tt_cache_flush
ttm_tt_cache_flush's implementation was removed in 2009 by commit c9c97b8c, but its declaration has been hiding in ttm_bo_driver.h since then. It has been surviving in the dark for too long now ; give it the mercy blow. Signed-off-by: Alexandre Courbot Reviewed-by: Thierry Reding --- include/drm/ttm/ttm_bo_driver.h | 12 1 file changed, 12 deletions(-) diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index a5183da3ef92..e3f8c99a8a9d 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -653,18 +653,6 @@ extern void ttm_tt_unbind(struct ttm_tt *ttm); extern int ttm_tt_swapin(struct ttm_tt *ttm); /** - * ttm_tt_cache_flush: - * - * @pages: An array of pointers to struct page:s to flush. - * @num_pages: Number of pages to flush. - * - * Flush the data of the indicated pages from the cpu caches. - * This is used when changing caching attributes of the pages from - * cache-coherent. - */ -extern void ttm_tt_cache_flush(struct page *pages[], unsigned long num_pages); - -/** * ttm_tt_set_placement_caching: * * @ttm A struct ttm_tt the backing pages of which will change caching policy. -- 1.9.2 -- 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/ttm: fix kerneldoc of ttm_bo_create
The kerneldoc header of ttm_bo_create() was referring to another (nonexisting) function and had a few obsolete or incorrect arguments. Signed-off-by: Alexandre Courbot --- include/drm/ttm/ttm_bo_api.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index ee127ec33c60..7526c5bf5610 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -485,13 +485,12 @@ extern int ttm_bo_init(struct ttm_bo_device *bdev, void (*destroy) (struct ttm_buffer_object *)); /** - * ttm_bo_synccpu_object_init + * ttm_bo_create * * @bdev: Pointer to a ttm_bo_device struct. - * @bo: Pointer to a ttm_buffer_object to be initialized. * @size: Requested size of buffer object. * @type: Requested type of buffer object. - * @flags: Initial placement flags. + * @placement: Initial placement. * @page_alignment: Data alignment in pages. * @interruptible: If needing to sleep while waiting for GPU resources, * sleep interruptible. -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/bonding/bond_alb.c between commit d0c21d43a5a1 ("bonding:
Send ALB learning packets using the right source") from the net tree
and commit 8557cd74ca8a ("bonding: replace SLAVE_IS_OK() with
bond_slave_can_tx()") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/bonding/bond_alb.c
index 93580a47cc54,03e0bcade234..
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@@ -1117,8 -1106,8 +1117,8 @@@ static void alb_fasten_mac_swap(struct
ASSERT_RTNL();
/* fasten the change in the switch */
- if (SLAVE_IS_OK(slave1)) {
+ if (bond_slave_can_tx(slave1)) {
- alb_send_learning_packets(slave1, slave1->dev->dev_addr);
+ alb_send_learning_packets(slave1, slave1->dev->dev_addr, false);
if (bond->alb_info.rlb_enabled) {
/* inform the clients that the mac address
* has changed
@@@ -1129,8 -1118,8 +1129,8 @@@
disabled_slave = slave1;
}
- if (SLAVE_IS_OK(slave2)) {
+ if (bond_slave_can_tx(slave2)) {
- alb_send_learning_packets(slave2, slave2->dev->dev_addr);
+ alb_send_learning_packets(slave2, slave2->dev->dev_addr, false);
if (bond->alb_info.rlb_enabled) {
/* inform the clients that the mac address
* has changed
signature.asc
Description: PGP signature
linux-next: manual merge of the net-next tree with the wireless tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/iwlwifi/mvm/mac80211.c between commit 7bacc782270f
("iwlwifi: mvm: disable beacon filtering") from the wireless tree and
commit 73e5f2c5d762 ("iwlwifi: remove IWL_UCODE_TLV_FLAGS_BF_UPDATED
flag") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 8735ef1f44ae,97c3deae6552..
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@@ -826,9 -825,8 +825,8 @@@ static int iwl_mvm_mac_add_interface(st
if (ret)
goto out_remove_mac;
- if (!mvm->bf_allowed_vif &&
+ if (!mvm->bf_allowed_vif && false &&
- vif->type == NL80211_IFTYPE_STATION && !vif->p2p &&
- mvm->fw->ucode_capa.flags & IWL_UCODE_TLV_FLAGS_BF_UPDATED){
+ vif->type == NL80211_IFTYPE_STATION && !vif->p2p) {
mvm->bf_allowed_vif = mvmvif;
vif->driver_flags |= IEEE80211_VIF_BEACON_FILTER |
IEEE80211_VIF_SUPPORTS_CQM_RSSI;
signature.asc
Description: PGP signature
[PATCH 1/5] mm,fs: introduce helpers around i_mmap_mutex
Various parts of the kernel acquire and release this mutex,
so add i_mmap_lock_write() and immap_unlock_write() helper
functions that will encapsulate this logic. The next patch
will make use of these.
Signed-off-by: Davidlohr Bueso
---
include/linux/fs.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 1cab2f8..524d2c1 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -456,6 +456,16 @@ struct block_device {
int mapping_tagged(struct address_space *mapping, int tag);
+static inline void i_mmap_lock_write(struct address_space *mapping)
+{
+ mutex_lock(>i_mmap_mutex);
+}
+
+static inline void i_mmap_unlock_write(struct address_space *mapping)
+{
+ mutex_unlock(>i_mmap_mutex);
+}
+
/*
* Might pages of this file be mapped into userspace?
*/
--
1.8.1.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 2/5] mm: use new helper functions around the i_mmap_mutex
Convert all open coded mutex_lock/unlock calls to the
i_mmap_[lock/unlock]_write() helpers.
Signed-off-by: Davidlohr Bueso
---
fs/hugetlbfs/inode.c| 4 ++--
kernel/events/uprobes.c | 4 ++--
kernel/fork.c | 4 ++--
mm/filemap_xip.c| 4 ++--
mm/hugetlb.c| 12 ++--
mm/memory-failure.c | 4 ++--
mm/memory.c | 8
mm/mmap.c | 14 +++---
mm/mremap.c | 4 ++--
mm/nommu.c | 14 +++---
mm/rmap.c | 4 ++--
11 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 93fc531..bcaf4df 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -412,10 +412,10 @@ static int hugetlb_vmtruncate(struct inode *inode, loff_t
offset)
pgoff = offset >> PAGE_SHIFT;
i_size_write(inode, offset);
- mutex_lock(>i_mmap_mutex);
+ i_mmap_lock_write(mapping);
if (!RB_EMPTY_ROOT(>i_mmap))
hugetlb_vmtruncate_list(>i_mmap, pgoff);
- mutex_unlock(>i_mmap_mutex);
+ i_mmap_unlock_write(mapping);
truncate_hugepages(inode, offset);
return 0;
}
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 7716c40..ccf793c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -722,7 +722,7 @@ build_map_info(struct address_space *mapping, loff_t
offset, bool is_register)
int more = 0;
again:
- mutex_lock(>i_mmap_mutex);
+ i_mmap_lock_write(mapping);
vma_interval_tree_foreach(vma, >i_mmap, pgoff, pgoff) {
if (!valid_vma(vma, is_register))
continue;
@@ -753,7 +753,7 @@ build_map_info(struct address_space *mapping, loff_t
offset, bool is_register)
info->mm = vma->vm_mm;
info->vaddr = offset_to_vaddr(vma, offset);
}
- mutex_unlock(>i_mmap_mutex);
+ i_mmap_unlock_write(mapping);
if (!more)
goto out;
diff --git a/kernel/fork.c b/kernel/fork.c
index d2799d1..76b1483 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -419,7 +419,7 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct
*oldmm)
get_file(file);
if (tmp->vm_flags & VM_DENYWRITE)
atomic_dec(>i_writecount);
- mutex_lock(>i_mmap_mutex);
+ i_mmap_lock_write(mapping);
if (tmp->vm_flags & VM_SHARED)
mapping->i_mmap_writable++;
flush_dcache_mmap_lock(mapping);
@@ -431,7 +431,7 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct
*oldmm)
vma_interval_tree_insert_after(tmp, mpnt,
>i_mmap);
flush_dcache_mmap_unlock(mapping);
- mutex_unlock(>i_mmap_mutex);
+ i_mmap_unlock_write(mapping);
}
/*
diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
index d8d9fe3..bad746b 100644
--- a/mm/filemap_xip.c
+++ b/mm/filemap_xip.c
@@ -182,7 +182,7 @@ __xip_unmap (struct address_space * mapping,
return;
retry:
- mutex_lock(>i_mmap_mutex);
+ i_mmap_lock_write(mapping);
vma_interval_tree_foreach(vma, >i_mmap, pgoff, pgoff) {
mm = vma->vm_mm;
address = vma->vm_start +
@@ -202,7 +202,7 @@ retry:
page_cache_release(page);
}
}
- mutex_unlock(>i_mmap_mutex);
+ i_mmap_unlock_write(mapping);
if (locked) {
mutex_unlock(_sparse_mutex);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9519cde..161f98d 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2761,7 +2761,7 @@ static int unmap_ref_private(struct mm_struct *mm, struct
vm_area_struct *vma,
* this mapping should be shared between all the VMAs,
* __unmap_hugepage_range() is called as the lock is already held
*/
- mutex_lock(>i_mmap_mutex);
+ i_mmap_lock_write(mapping);
vma_interval_tree_foreach(iter_vma, >i_mmap, pgoff, pgoff) {
/* Do not unmap the current VMA */
if (iter_vma == vma)
@@ -2778,7 +2778,7 @@ static int unmap_ref_private(struct mm_struct *mm, struct
vm_area_struct *vma,
unmap_hugepage_range(iter_vma, address,
address + huge_page_size(h), page);
}
- mutex_unlock(>i_mmap_mutex);
+ i_mmap_unlock_write(mapping);
return 1;
}
@@ -3342,7 +3342,7 @@ unsigned long hugetlb_change_protection(struct
vm_area_struct *vma,
flush_cache_range(vma, address, end);
mmu_notifier_invalidate_range_start(mm, start, end);
- mutex_lock(>vm_file->f_mapping->i_mmap_mutex);
+
Re: [PATCH v2] gpio: make of_get_named_gpiod_flags() private
On Wed, May 21, 2014 at 6:16 PM, Linus Walleij wrote: > On Sat, May 17, 2014 at 7:54 AM, Alexandre Courbot > wrote: > >> of_get_named_gpiod_flags() is visible and directly usable by GPIO >> consumers, but it really should not as the gpiod interface relies >> on the simpler gpiod_get() to provide properly-configured GPIOs. >> >> of_get_named_gpiod_flags() is just used internally by gpiolib to >> implement gpiod_get(), and by the old of_get_named_gpio_flags() >> function, therefore it makes sense to make it gpiolib-private. >> >> As a side-effect, the unused (and unneeded) of_get_gpiod_flags() >> inline function is also removed, and of_get_named_gpio_flags() is moved >> from a static inline function to a regular one in gpiolib-of.c >> >> This results in all references to gpiod_* functions in of_gpio.h being >> gone, which is the way it should be since this file is part of the old >> integer GPIO interface. >> >> Signed-off-by: Alexandre Courbot >> --- >> Changes since v1: >> - Fixed compilation error when CONFIG_OF_GPIO is not defined >> - Fixed warning due to of_gpio_flags enum not being declared >> in private gpiolib.h header > > Applied this v2 version and pushed for testing, let's hope it flies > properly this time :-D Looks like the world did not break this time. However I noticed that the commit in your tree (and -next) included the changes since v1 in its log. Is it intended? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] mm: i_mmap_mutex to rwsem
This patchset extends the work started by Ingo Molnar in late 2012, optimizing the anon-vma mutex lock, converting it from a exclusive mutex to a rwsem, and sharing the lock for read-only paths when walking the the vma-interval tree. More specifically commits 5a505085 and 4fc3f1d6. The i_mmap_mutex has similar responsibilities with the anon-vma, protecting file backed pages. Therefore we can use similar locking techniques: covert the mutex to a rwsem and share the lock when possible. With the new optimistic spinning property we have in rwsems, we no longer take a hit in performance when using this lock, and we can therefore safely do the conversion. Tests show no throughput regressions in aim7 or pgbench runs, and we can see gains from sharing the lock, in disk workloads ~+15% for over 1000 users on a 8-socket Westmere system. This patchset applies on linux-next-20140522. Thanks! Davidlohr Bueso (5): mm,fs: introduce helpers around i_mmap_mutex mm: use new helper functions around the i_mmap_mutex mm: convert i_mmap_mutex to rwsem mm/rmap: share the i_mmap_rwsem mm: rename leftover i_mmap_mutex fs/hugetlbfs/inode.c | 14 +++--- fs/inode.c | 2 +- include/linux/fs.h | 23 ++- include/linux/mmu_notifier.h | 2 +- kernel/events/uprobes.c | 6 +++--- kernel/fork.c| 4 ++-- mm/filemap.c | 10 +- mm/filemap_xip.c | 4 ++-- mm/hugetlb.c | 22 +++--- mm/memory-failure.c | 4 ++-- mm/memory.c | 8 mm/mmap.c| 22 +++--- mm/mremap.c | 6 +++--- mm/nommu.c | 14 +++--- mm/rmap.c| 10 +- 15 files changed, 86 insertions(+), 65 deletions(-) -- 1.8.1.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 5/5] mm: rename leftover i_mmap_mutex
Update the lock to i_mmap_rwsem throughout the kernel.
All changes are in comments and documentation.
Signed-off-by: Davidlohr Bueso
---
include/linux/mmu_notifier.h | 2 +-
kernel/events/uprobes.c | 2 +-
mm/filemap.c | 10 +-
mm/hugetlb.c | 10 +-
mm/mremap.c | 2 +-
mm/rmap.c| 6 +++---
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index deca874..f9c11ab 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -151,7 +151,7 @@ struct mmu_notifier_ops {
* Therefore notifier chains can only be traversed when either
*
* 1. mmap_sem is held.
- * 2. One of the reverse map locks is held (i_mmap_mutex or anon_vma->rwsem).
+ * 2. One of the reverse map locks is held (i_mmap_rwsem or anon_vma->rwsem).
* 3. No other concurrent thread can access the list (release)
*/
struct mmu_notifier {
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ccf793c..e809554 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -729,7 +729,7 @@ build_map_info(struct address_space *mapping, loff_t
offset, bool is_register)
if (!prev && !more) {
/*
-* Needs GFP_NOWAIT to avoid i_mmap_mutex recursion
through
+* Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion
through
* reclaim. This is optimistic, no harm done if it
fails.
*/
prev = kmalloc(sizeof(struct map_info),
diff --git a/mm/filemap.c b/mm/filemap.c
index 263cffe..aadf613 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -61,16 +61,16 @@
/*
* Lock ordering:
*
- * ->i_mmap_mutex (truncate_pagecache)
+ * ->i_mmap_rwsem (truncate_pagecache)
*->private_lock (__free_pte->__set_page_dirty_buffers)
* ->swap_lock(exclusive_swap_page, others)
*->mapping->tree_lock
*
* ->i_mutex
- *->i_mmap_mutex (truncate->unmap_mapping_range)
+ *->i_mmap_rwsem (truncate->unmap_mapping_range)
*
* ->mmap_sem
- *->i_mmap_mutex
+ *->i_mmap_rwsem
* ->page_table_lock or pte_lock (various, mainly in memory.c)
*->mapping->tree_lock (arch-dependent flush_dcache_mmap_lock)
*
@@ -84,7 +84,7 @@
*sb_lock (fs/fs-writeback.c)
*->mapping->tree_lock (__sync_single_inode)
*
- * ->i_mmap_mutex
+ * ->i_mmap_rwsem
*->anon_vma.lock (vma_adjust)
*
* ->anon_vma.lock
@@ -104,7 +104,7 @@
*->inode->i_lock (zap_pte_range->set_page_dirty)
*->private_lock (zap_pte_range->__set_page_dirty_buffers)
*
- * ->i_mmap_mutex
+ * ->i_mmap_rwsem
* ->tasklist_lock(memory_failure, collect_procs_ao)
*/
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 161f98d..3ab3ffd 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2713,9 +2713,9 @@ void __unmap_hugepage_range_final(struct mmu_gather *tlb,
* on its way out. We're lucky that the flag has such an appropriate
* name, and can in fact be safely cleared here. We could clear it
* before the __unmap_hugepage_range above, but all that's necessary
-* is to clear it before releasing the i_mmap_mutex. This works
+* is to clear it before releasing the i_mmap_rwsem. This works
* because in the context this is called, the VMA is about to be
-* destroyed and the i_mmap_mutex is held.
+* destroyed and the i_mmap_rwsem is held.
*/
vma->vm_flags &= ~VM_MAYSHARE;
}
@@ -3364,9 +3364,9 @@ unsigned long hugetlb_change_protection(struct
vm_area_struct *vma,
spin_unlock(ptl);
}
/*
-* Must flush TLB before releasing i_mmap_mutex: x86's huge_pmd_unshare
+* Must flush TLB before releasing i_mmap_rwsem: x86's huge_pmd_unshare
* may have cleared our pud entry and done put_page on the page table:
-* once we release i_mmap_mutex, another task can do the final put_page
+* once we release i_mmap_rwsem, another task can do the final put_page
* and that page table be reused and filled with junk.
*/
flush_tlb_range(vma, start, end);
@@ -3519,7 +3519,7 @@ static int vma_shareable(struct vm_area_struct *vma,
unsigned long addr)
* and returns the corresponding pte. While this is not necessary for the
* !shared pmd case because we can allocate the pmd later as well, it makes the
* code much cleaner. pmd allocation is essential for the shared case because
- * pud has to be populated inside the same i_mmap_mutex section - otherwise
+ * pud has to be populated inside the same i_mmap_rwsem section - otherwise
* racing tasks could either miss the sharing (see huge_pte_offset) or select a
* bad pmd
[PATCH 3/5] mm: convert i_mmap_mutex to rwsem
The i_mmap_mutex is a close cousin of the anon vma lock,
both protecting similar data, one for file backed pages
and the other for anon memory. To this end, this lock can
also be a rwsem.
This conversion is straightforward. For now, all users take
the write lock.
Signed-off-by: Davidlohr Bueso
---
fs/hugetlbfs/inode.c | 10 +-
fs/inode.c | 2 +-
include/linux/fs.h | 7 ---
mm/mmap.c| 8
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index bcaf4df..020ace5 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -472,12 +472,12 @@ static struct inode *hugetlbfs_get_root(struct
super_block *sb,
}
/*
- * Hugetlbfs is not reclaimable; therefore its i_mmap_mutex will never
+ * Hugetlbfs is not reclaimable; therefore its i_mmap_rwsem will never
* be taken from reclaim -- unlike regular filesystems. This needs an
* annotation because huge_pmd_share() does an allocation under
- * i_mmap_mutex.
+ * i_mmap_rwsem.
*/
-static struct lock_class_key hugetlbfs_i_mmap_mutex_key;
+static struct lock_class_key hugetlbfs_i_mmap_rwsem_key;
static struct inode *hugetlbfs_get_inode(struct super_block *sb,
struct inode *dir,
@@ -495,8 +495,8 @@ static struct inode *hugetlbfs_get_inode(struct super_block
*sb,
struct hugetlbfs_inode_info *info;
inode->i_ino = get_next_ino();
inode_init_owner(inode, dir, mode);
- lockdep_set_class(>i_mapping->i_mmap_mutex,
- _i_mmap_mutex_key);
+ lockdep_set_class(>i_mapping->i_mmap_rwsem,
+ _i_mmap_rwsem_key);
inode->i_mapping->a_ops = _aops;
inode->i_mapping->backing_dev_info =_backing_dev_info;
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
diff --git a/fs/inode.c b/fs/inode.c
index 2feb9b6..d26e9f8 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -348,7 +348,7 @@ void address_space_init_once(struct address_space *mapping)
memset(mapping, 0, sizeof(*mapping));
INIT_RADIX_TREE(>page_tree, GFP_ATOMIC);
spin_lock_init(>tree_lock);
- mutex_init(>i_mmap_mutex);
+ init_rwsem(>i_mmap_rwsem);
INIT_LIST_HEAD(>private_list);
spin_lock_init(>private_lock);
mapping->i_mmap = RB_ROOT;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 524d2c1..60a1d7d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -390,7 +391,7 @@ struct address_space {
unsigned inti_mmap_writable;/* count VM_SHARED mappings */
struct rb_root i_mmap; /* tree of private and shared
mappings */
struct list_headi_mmap_nonlinear;/*list VM_NONLINEAR mappings */
- struct mutexi_mmap_mutex; /* protect tree, count, list */
+ struct rw_semaphore i_mmap_rwsem; /* protect tree, count, list */
/* Protected by tree_lock together with the radix tree */
unsigned long nrpages;/* number of total pages */
unsigned long nrshadows; /* number of shadow entries */
@@ -458,12 +459,12 @@ int mapping_tagged(struct address_space *mapping, int
tag);
static inline void i_mmap_lock_write(struct address_space *mapping)
{
- mutex_lock(>i_mmap_mutex);
+ down_write(>i_mmap_rwsem);
}
static inline void i_mmap_unlock_write(struct address_space *mapping)
{
- mutex_unlock(>i_mmap_mutex);
+ up_write(>i_mmap_rwsem);
}
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 41a0083..bc7a3b2 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -208,7 +208,7 @@ error:
}
/*
- * Requires inode->i_mapping->i_mmap_mutex
+ * Requires inode->i_mapping->i_mmap_rwsem
*/
static void __remove_shared_vm_struct(struct vm_area_struct *vma,
struct file *file, struct address_space *mapping)
@@ -2814,7 +2814,7 @@ void exit_mmap(struct mm_struct *mm)
/* Insert vm structure into process list sorted by address
* and into the inode's i_mmap tree. If vm_file is non-NULL
- * then i_mmap_mutex is taken here.
+ * then i_mmap_rwsem is taken here.
*/
int insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma)
{
@@ -3078,7 +3078,7 @@ static void vm_lock_mapping(struct mm_struct *mm, struct
address_space *mapping)
*/
if (test_and_set_bit(AS_MM_ALL_LOCKS, >flags))
BUG();
- mutex_lock_nest_lock(>i_mmap_mutex, >mmap_sem);
+ down_write_nest_lock(>i_mmap_rwsem, >mmap_sem);
}
}
@@ -3105,7 +3105,7 @@ static void vm_lock_mapping(struct mm_struct *mm, struct
address_space *mapping)
* vma in this mm is backed by the same anon_vma or address_space.
*
* We can take all the
[PATCH 4/5] mm/rmap: share the i_mmap_rwsem
Similarly to rmap_walk_anon() and collect_procs_anon(),
there is opportunity to share the lock in rmap_walk_file()
and collect_procs_file() for file backed pages.
Signed-off-by: Davidlohr Bueso
---
include/linux/fs.h | 10 ++
mm/memory-failure.c | 4 ++--
mm/rmap.c | 4 ++--
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 60a1d7d..4c2c228 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -467,6 +467,16 @@ static inline void i_mmap_unlock_write(struct
address_space *mapping)
up_write(>i_mmap_rwsem);
}
+static inline void i_mmap_lock_read(struct address_space *mapping)
+{
+ down_read(>i_mmap_rwsem);
+}
+
+static inline void i_mmap_unlock_read(struct address_space *mapping)
+{
+ up_read(>i_mmap_rwsem);
+}
+
/*
* Might pages of this file be mapped into userspace?
*/
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 1389a28..acbcd8e 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -434,7 +434,7 @@ static void collect_procs_file(struct page *page, struct
list_head *to_kill,
struct task_struct *tsk;
struct address_space *mapping = page->mapping;
- i_mmap_lock_write(mapping);
+ i_mmap_lock_read(mapping);
read_lock(_lock);
for_each_process(tsk) {
pgoff_t pgoff = page_pgoff(page);
@@ -456,7 +456,7 @@ static void collect_procs_file(struct page *page, struct
list_head *to_kill,
}
}
read_unlock(_lock);
- i_mmap_unlock_write(mapping);
+ i_mmap_unlock_read(mapping);
}
/*
diff --git a/mm/rmap.c b/mm/rmap.c
index 9a56e4f..5841dcb 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1685,7 +1685,7 @@ static int rmap_walk_file(struct page *page, struct
rmap_walk_control *rwc)
if (!mapping)
return ret;
- i_mmap_lock_write(mapping);
+ i_mmap_lock_read(mapping);
vma_interval_tree_foreach(vma, >i_mmap, pgoff, pgoff) {
unsigned long address = vma_address(page, vma);
@@ -1708,7 +1708,7 @@ static int rmap_walk_file(struct page *page, struct
rmap_walk_control *rwc)
ret = rwc->file_nonlinear(page, mapping, rwc->arg);
done:
- i_mmap_unlock_write(mapping);
+ i_mmap_unlock_read(mapping);
return ret;
}
--
1.8.1.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 v3 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC
On Thursday 22 May 2014 05:18 PM, Lee Jones wrote:
The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- Over Temperature warning and Shut down.
This patch adds support for tps65917 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: Keerthy
---
v3 Changes:
* Header file formating
* Changed the cache_type to REGCACHE_RBTREE
* removed unnecessary code
* Corrected documentation style
* Added pm_power_off function
v2 Changes:
* Added volatile register check as some of the registers
in the set are volatile.
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile |1 +
drivers/mfd/tps65917.c | 594 +
include/linux/mfd/tps65917.h | 1485 ++
4 files changed, 2092 insertions(+)
create mode 100644 drivers/mfd/tps65917.c
create mode 100644 include/linux/mfd/tps65917.h
[...]
+ for (i = 0; i < TPS65917_NUM_CLIENTS; i++) {
+ if (i == 0) {
+ tps65917->i2c_clients[i] = i2c;
This is messy. Move this line out of the loop and change the loop
parameters to start from 1. Then we can reduce all of this
unnecessary indentation.
There is a common thing we do after if and else. Removing i == 0
part out of the
loop would mean repeating the common part. This way seems
better.
Ah yes, good point.
+ } else {
+ tps65917->i2c_clients[i] =
+ i2c_new_dummy(i2c->adapter,
+ i2c->addr + i);
+ if (!tps65917->i2c_clients[i]) {
+ dev_err(tps65917->dev,
+ "can't attach client %d\n", i);
+ ret = -ENOMEM;
+ goto err_i2c;
+ }
+
+ tps65917->i2c_clients[i]->dev.of_node =
of_node_get(node);
Don't forget to decrement the reference when you've finished with it.
I did not get this.
Do you know what of_node_get() does?
[...]
What happens if !node? Then no children get registered and this has
all been a waste of time?
Only DT way is possible. This check is redundant. I will add a check
at the beginning for !node.
If that's the case you should add 'depends on OF' in the Kconfig.
+struct tps65917_reg_init {
+ /*
+* 0: reload default values from OTP on warm reset
+* 1: maintain voltage from VSEL on warm reset
+*/
+ bool warm_reset;
Where is this used?
+ /*
+* 0: i2c selection of voltage
+* 1: pin selection of voltage.
+*/
+ bool roof_floor;
And this?
+ /*
+* For SMPS
+*
+* 0: Off
+* 1: AUTO
+* 2: ECO
+* 3: Forced PWM
+*
+* For LDO
+*
+* 0: Off
+* 1: On
+*/
+ int mode_sleep;
And this?
+ u8 vsel;
And this?
All of the above can be used by regulator driver.
Doesn't the regulator driver have its own header file? Why are these
in a shared file if they're not used anywhere else?
[...]
+ if (pdata->mux_from_pdata) {
+ reg = pdata->pad1;
+ ret = regmap_write(tps65917->regmap[slave], addr, reg);
+ if (ret)
+ goto err_irq;
+ } else {
+ ret = regmap_read(tps65917->regmap[slave], addr, );
+ if (ret)
+ goto err_irq;
+ }i
What does the read do? You're not doing anything with the value.
This pad1 and pad2 stuff is not needed. I will remove this.
Then why is it in here?
Did you copy this code from somewhere, if so, where?
Okay, I just answered my own question. There is so much common code
in between this and palmas, there is no way I'm going to accept this
driver. Please merge it in with the palmas driver!
The chip is more like a subset of palmas with lot of register offset changes
and register bit field changes. Adding this would make it clumsy. There
could
be lot of checks. That is why i chose to write a new driver.
Palmas driver already supports palmas variants and tps659038. Merging
this would mean more and more checks :-/.
Regards,
Keerthy
--
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] sound: soc: samsung: dma.c: Fix to remove null pointer checks that could never happen
On 23 May 2014 01:51, Rickard Strandqvist
wrote:
> Removal of null pointer checks that could never happen
>
> Signed-off-by: Rickard Strandqvist
> ---
The subject should probably be (at least should start with "ASoC: samsung:")
"ASoC: samsung: Remove redundant null pointer check from dma.c"
With that change,
Reviewed-by: Tushar Behera
> sound/soc/samsung/dma.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
> index dc09b71..0f17ae0 100644
> --- a/sound/soc/samsung/dma.c
> +++ b/sound/soc/samsung/dma.c
> @@ -124,8 +124,7 @@ static void audio_buffdone(void *data)
> if (prtd->dma_pos >= prtd->dma_end)
> prtd->dma_pos = prtd->dma_start;
>
> - if (substream)
> - snd_pcm_period_elapsed(substream);
> + snd_pcm_period_elapsed(substream);
>
> spin_lock(>lock);
> if (!samsung_dma_has_circular()) {
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h
On Thu, May 22, 2014 at 5:39 PM, Suravee Suthikulanit wrote: > On 5/22/2014 3:20 PM, Bjorn Helgaas wrote: >> On Thu, May 22, 2014 at 1:17 PM, Borislav Petkov wrote: >>> On Thu, May 22, 2014 at 11:56:03AM -0600, Bjorn Helgaas wrote: I chose Fam16h (0x16) because it looks like that's the newest stuff that's in the field. I suspect things would probably work if we changed this patch to leave ECS disabled on some Fam16h, Fam15h, etc., but that would change behavior on existing systems, which obviously adds some risk. I didn't think there was much benefit that makes the risk worthwhile. My goal is to stop needing CPU-specific changes in the future, not necessarily to remove the CPU-specific code we already have. Does that make sense? I'm not sure whether I understood your real question. >>> >>> No, you got it right. I'm just wondering why only the newest stuff. >>> MMCONFIG is supposed to work just fine on everything from Fam10h >>> onwards, I'm not sure all Fam10h supported it though. Maybe Suravee can >>> verify that... >> >> Even if MMCONFIG does work fine on everything from Fam10h onwards, we >> still depend on the BIOS to provide a correct MCFG table. I don't >> think we can guarantee that changing from ECS to MMCONFIG on a Fam16h >> box in the field is safe, because we'd then be using a feature we've >> never used before. > > At this point, family11h and later (upto 16h which is our most current > processor) should already have supports for the MCFG. However, we can't > guarantee that all the systems currently out there would not use the ECS. > So, I think it is ok to say we won't support it post 16h as Bjorn suggests. I think this is more a BIOS question than a hardware question. I'm sure all current AMD hardware supports ECAM just fine. But it's still up to the BIOS to produce a valid MCFG table, so OEMs could still have issues, and *that's* what I'm worried about. I've been poking around for recent dmesg logs that contain "PCI: Using configuration type 1 for extended access", and there are quite a few. In most cases there *is* an MCFG table, but apparently we decide not to use it for some reason (unfortunately we don't print the specific reason). One example is at https://bugzilla.kernel.org/show_bug.cgi?id=68591 . I'm going to go out on a limb and guess that Windows does not enable ECS, so it probably uses ECAM. Therefore, I suspect Linux's parsing of MCFG is broken in some way, and we probably *could* use ECAM in all these cases I'm seeing. It would probably be prudent to figure out why Linux is rejecting these MCFG tables. We'll probably see similar tables on Fam17h systems, and if we continue rejecting them, and we don't turn on ECS, we won't be able to access extended config space. I opened a bugzilla for this issue: https://bugzilla.kernel.org/show_bug.cgi?id=76771 I'm wavering on whether it's a good idea to put this patch in before understanding the issue. As much as I'd like to stop fiddling with ECS, we'd likely end up with a v3.15 where extended config space doesn't work on some Fam17h systems. Bjorn -- 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: v4l2: circular locking between mmap_sem and device mutex
ping?
On 05/05/2014 11:49 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next
> kernel I've stumbled on the following:
>
>
> [ 2179.111265] ==
> [ 2179.112228] [ INFO: possible circular locking dependency detected ]
> [ 2179.113144] 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432 Tainted: G
> W
> [ 2179.114325] ---
> [ 2179.115286] trinity-c15/27050 is trying to acquire lock:
> [ 2179.116071] (>mutex#3){+.+.+.}, at: vb2_fop_mmap
> (drivers/media/v4l2-core/videobuf2-core.c:3029 (discriminator 1))
> [ 2179.117347]
> [ 2179.117347] but task is already holding lock:
> [ 2179.118185] (>mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
> [ 2179.120023]
> [ 2179.120023] which lock already depends on the new lock.
> [ 2179.120023]
> [ 2179.120036]
> [ 2179.120036] the existing dependency chain (in reverse order) is:
> [ 2179.120036]
> -> #1 (>mmap_sem){++}:
> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 2179.120036] might_fault (mm/memory.c:4368)
> [ 2179.120036] video_usercopy (arch/x86/include/asm/uaccess.h:713
> drivers/media/v4l2-core/v4l2-ioctl.c:2369)
> [ 2179.120036] video_ioctl2 (drivers/media/v4l2-core/v4l2-ioctl.c:2445)
> [ 2179.120036] v4l2_ioctl (drivers/media/v4l2-core/v4l2-dev.c:355)
> [ 2179.120036] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:598)
> [ 2179.120036] SyS_ioctl (include/linux/file.h:38 fs/ioctl.c:614
> fs/ioctl.c:604)
> [ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
> [ 2179.120036]
> -> #0 (>mutex#3){+.+.+.}:
> [ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
> kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
> kernel/locking/lockdep.c:3182)
> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
> kernel/locking/mutex.c:616)
> [ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
> [ 2179.120036] mmap_region (mm/mmap.c:1577)
> [ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
> [ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
> [ 2179.120036] SyS_mmap_pgoff (mm/mmap.c:1418 mm/mmap.c:1378)
> [ 2179.120036] SyS_mmap (arch/x86/kernel/sys_x86_64.c:72)
> [ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
> [ 2179.120036]
> [ 2179.120036] other info that might help us debug this:
> [ 2179.120036]
> [ 2179.120036] Possible unsafe locking scenario:
> [ 2179.120036]
> [ 2179.120036]CPU0CPU1
> [ 2179.120036]
> [ 2179.120036] lock(>mmap_sem);
> [ 2179.120036]lock(>mutex#3);
> [ 2179.120036]lock(>mmap_sem);
> [ 2179.120036] lock(>mutex#3);
> [ 2179.120036]
> [ 2179.120036] *** DEADLOCK ***
> [ 2179.120036]
> [ 2179.120036] 1 lock held by trinity-c15/27050:
> [ 2179.120036] #0: (>mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
> [ 2179.120036]
> [ 2179.120036] stack backtrace:
> [ 2179.120036] CPU: 1 PID: 27050 Comm: trinity-c15 Tainted: GW
> 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432
> [ 2179.120036] baa718e0 88065df9dab8 b75326bb
> 0002
> [ 2179.120036] baa718e0 88065df9db08 b7525488
> 0001
> [ 2179.120036] 88065df9db98 88065df9db08 88065dd63cf0
> 88065dd63d28
> [ 2179.120036] Call Trace:
> [ 2179.120036] dump_stack (lib/dump_stack.c:52)
> [ 2179.120036] print_circular_bug (kernel/locking/lockdep.c:1216)
> [ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
> kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
> kernel/locking/lockdep.c:3182)
> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
> kernel/locking/mutex.c:616)
> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] ? get_parent_ip (kernel/sched/core.c:2485)
> [ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
> [ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
> [ 2179.120036] mmap_region (mm/mmap.c:1577)
> [ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
> [ 2179.120036] ? vm_mmap_pgoff
Re: [PATCH v2] mm, compaction: properly signal and act upon lock and need_sched() contention
On 23 May 2014 07:49, Kevin Hilman wrote: > On Fri, May 16, 2014 at 2:47 AM, Vlastimil Babka wrote: >> Compaction uses compact_checklock_irqsave() function to periodically check >> for >> lock contention and need_resched() to either abort async compaction, or to >> free the lock, schedule and retake the lock. When aborting, cc->contended is >> set to signal the contended state to the caller. Two problems have been >> identified in this mechanism. > > This patch (or later version) has hit next-20140522 (in the form > commit 645ceea9331bfd851bc21eea456dda27862a10f4) and according to my > bisect, appears to be the culprit of several boot failures on ARM > platforms. On i.MX6 where CMA is enabled, the commit causes the drivers calling dma_alloc_coherent() fail to probe. Tracing it a little bit, it seems dma_alloc_from_contiguous() always return page as NULL after this commit. Shawn -- 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: Pondering per-process vsyscall disablement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2014 02:04 AM, Andy Lutomirski wrote: > It would be nice to have a way for new programs to declare that they don't > need vsyscalls. What's the right way to > do this? An ELF header entry in the loader? An ELF header entry in the > program? A new arch_prctl? > > As background, there's an old part of the x86_64 ABI that allows programs to > do gettimeofday, clock_gettime, and > getcpu by calling to fixed addresses of the form 0xff600n00 where n > indicates which of those three syscalls > is being invoked. This is a security issue. > > Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a > result, vsyscalls no longer offer any > performance advantage over normal syscalls; in fact, they're much slower. As > far as I know, nothing newer than > 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of > things will still fall back to the > vsyscall page if there is no vdso, but that shouldn't matter, since there is > always a vdso.) > > Despite the emulation, they could still be used as a weird form of ROP gadget > that lives at a fixed address. I'd > like to offer a way for new runtimes to indicate that they don't use > vsyscalls so that the kernel can selectively > disable emulation and remove the fixed-address executable code issue. > > Wouldn't it be more useful if the check is against a bitmask added as extended attribute for that executable? This way the administrators and will have the flexibility to simply add the new attribute to the executable. Marian > --Andy -- 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/ > - -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hack...@jabber.org ICQ: 7556201 Mobile: +359 886 660 270 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlN+tg4ACgkQ4mt9JeIbjJRGkgCgjnD2s+J9kIr5oEDeL3VKHNvX X4cAn17zC0aPKyTCVekmqZRlVukqLWyC =vrfk -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Shrinkers and proportional reclaim
On Thu, May 22, 2014 at 05:30:51PM +0100, Mel Gorman wrote: > On Fri, May 23, 2014 at 12:14:16AM +0800, Yuanhan Liu wrote: > > On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote: > > > This series is aimed at regressions noticed during reclaim activity. The > > > first two patches are shrinker patches that were posted ages ago but never > > > merged for reasons that are unclear to me. I'm posting them again to see > > > if > > > there was a reason they were dropped or if they just got lost. Dave? > > > Time? > > > The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest > > > the vm scalability test cases on a larger machine? Hugh, does this work > > > for you on the memcg test cases? > > > > Sure, and here is the result. I applied these 3 patches on v3.15-rc6, > > and head commit is 60c10afd. e82e0561 is the old commit that introduced > > the regression. The testserver has 512G memory and 120 CPU. > > > > It's a simple result; if you need more data, I can gather them and send > > it to you tomorrow: > > > > e82e0561v3.15-rc6 60c10afd > > > > 185607851223212238868453 > > -34%+109 > > > > As you can see, the performance is back, and it is way much better ;) > > > > Thanks a lot for that and the quick response. It is much appreciated. Welcome! And sorry that I made a silly mistake. Those numbers are right though, I just setup wrong compare base; I should compare them with e82e0561's parent, which is 75485363ce85526 at below table. Here is the detailed results to compensate the mistake I made ;) Legend: ~XX%- stddev percent (3 runs for each kernel) [+-]XX% - change percent 75485363ce85526 e82e0561dae9f3ae5a21fc2d3 v3.15-rc6 60c10afd233f3344479d229dc --- - - - 35979244 ~ 0% -48.4% 18560785 ~ 0% -66.0% 12235090 ~ 0% +8.0% 38868453 ~ 0% vm-scalability.throughput 28138 ~ 0% +7448.2%2123943 ~ 0% +2724.5% 794777 ~ 0% +1.6% 28598 ~ 0% proc-vmstat.allocstall 544 ~ 6% -95.2% 26 ~ 0% -96.5% 19 ~21% -6.9%506 ~ 6% numa-vmstat.node2.nr_isolated_file 12009832 ~11%+368.1% 56215319 ~ 0%+312.9% 49589361 ~ 1% +0.7% 12091235 ~ 5% numa-numastat.node3.numa_foreign 560 ~ 5% -95.7% 24 ~12% -96.9% 17 ~10% -8.7%511 ~ 2% numa-vmstat.node1.nr_isolated_file 8740137 ~12%+574.0% 58910256 ~ 0%+321.0% 36798827 ~ 0% +21.0% 10578905 ~13% numa-vmstat.node0.numa_other 8734988 ~12%+574.4% 58904944 ~ 0%+321.2% 36794158 ~ 0% +21.0% 10572718 ~13% numa-vmstat.node0.numa_miss 1308 ~12%-100.0% 0 ~ 0%-100.0% 0 +23.3% 1612 ~18% proc-vmstat.pgscan_direct_throttle 12294788 ~11%+401.2% 61622745 ~ 0%+332.6% 53190547 ~ 0% -13.2% 10667387 ~ 5% numa-numastat.node1.numa_foreign 576 ~ 6% -91.2% 50 ~22% -94.3% 33 ~20% -18.1%472 ~ 1% numa-vmstat.node0.nr_isolated_file 12 ~24% +2400.0%316 ~ 4% +13543.7% 1728 ~ 5% +155.3% 32 ~29% proc-vmstat.compact_stall 572 ~ 2% -96.4% 20 ~18% -97.6% 13 ~11% -17.5%472 ~ 2% numa-vmstat.node3.nr_isolated_file 3012 ~12% +2388.4% 74959 ~ 0%+254.7% 10685 ~ 1% -45.4% 1646 ~ 1% proc-vmstat.pageoutrun 2312 ~ 3% -94.2%133 ~ 4% -95.8% 97 ~ 8% -12.6% 2021 ~ 2% proc-vmstat.nr_isolated_file 2575163 ~ 0% +2779.1% 74141888 ~ 0%+958.0% 27244229 ~ 0% -1.3%2542941 ~ 0% proc-vmstat.pgscan_direct_dma32 21916603 ~13% +2519.8% 5.742e+08 ~ 0% +2868.9% 6.507e+08 ~ 0% -16.1% 18397644 ~ 5% proc-vmstat.pgscan_kswapd_normal 53306 ~24% +1077.9% 627895 ~ 0% +2066.2%1154741 ~ 0% +23.5% 65815 ~24% proc-vmstat.pgscan_kswapd_dma32 2575163 ~ 0% +2778.6% 74129497 ~ 0%+957.8% 27239606 ~ 0% -1.3%2542353 ~ 0% proc-vmstat.pgsteal_direct_dma32 21907744 ~14% +2520.8% 5.742e+08 ~ 0% +2870.0% 6.507e+08 ~ 0% -16.1% 18386641 ~ 5% proc-vmstat.pgsteal_kswapd_normal 53306 ~24% +1077.7% 627796 ~ 0% +2065.7%1154436 ~ 0% +23.3% 65731 ~24% proc-vmstat.pgsteal_kswapd_dma32 2967449 ~ 0% +2432.7% 75156011 ~ 0%+869.9% 28781337 ~ 0% -0.7%2945933 ~ 0% proc-vmstat.pgalloc_dma32 13081172 ~11%+599.4% 91495653 ~ 0%+337.1% 57180622 ~ 0% +12.1% 14668141 ~13% numa-numastat.node0.other_node 13073426 ~11%+599.8% 91489575 ~ 0%+337.4% 57177129 ~ 0% +12.1% 14660341 ~13% numa-numastat.node0.numa_miss 281 ~23%
Re: [PATCH RESEND] sysfs: fix attribute_group bin file path on removal
On Thu, May 22, 2014 at 07:15:11PM +0200, Robert ABEL wrote: > I sent this patch to the list on 15 Apr 14. > However, no activity since. Should I have sent this patch somewhere else? I have it in my todo queue, sorry for the delay, I've been on the road for 3 weeks and will be home next week and start to catch up. Don't worry, it's not lost. 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: pci: kernel crash in bus_find_device
On Thu, May 22, 2014 at 12:22:40AM -0700, Guenter Roeck wrote:
> On 05/22/2014 12:14 AM, Greg Kroah-Hartmann wrote:
> > On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
> >> On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
> >>> I have been using an x86 platform.
> >>> When I started working on it I got early crashes until I added the
> >>> check for p not NULL in
> >>>
> >>> +void bus_release_device(struct device *dev)
> >>> +{
> >>> + struct device_private *p = dev->p;
> >>> +
> >>> + if (p && klist_node_attached(>knode_bus))
> >>> + klist_put_last(>knode_bus);
> >>> +}
> >>> +
> >>>
> >>> Maybe on powerpc *p is overriden between device_del and device_release?
> >>>
> >>> Or maybe some of the BUG_ONs in the patch? The ones on knode_dead are
> >>> treated as WARN_ONs in the current klist code.
> >>> The one in BUG_ON(!klist_dec_and_del(n)); is new, and in my tests I
> >>> ran into it without the second patch (but only when I ran my module
> >>> and tests).
> >>>
> >> Hi Francesco,
> >>
> >> I replaced the BUG_ON with WARN_ON; still crashes.
> >>
> >> Anyway, the problem seems to be known. I found two related exchanges.
> >>
> >> [1] describes pretty much the same problem. I don't see if/where it was
> >> ever fixed, though.
> >>
> >> [2] is a patch to fix the problem. It did not apply cleanly to 3.14,
> >> so I had to make some adjustments in klist_iter_init_node. Resulting
> >> patch is below. With this patch, the problem is gone. It is not perfect,
> >> as it aborts the loop if it encounters a deleted kobject, but it is better
> >> than nothing. Unfortunately, the patch never made it upstream; no idea why.
> >> Copying the author and Greg to get additional feedback.
> >>
> >> Guenter
> >>
> >> [1] https://lkml.org/lkml/2008/10/26/79
> >> [2] https://lkml.org/lkml/2012/4/16/218
> >
> > 2 years ago? I have no idea what was up with that, sorry...
> >
>
> Ok, but do you have comments on the patch itself in its current version ?
I have no idea, and at the moment, no time to look at this at all,
sorry. Feel free to work on it and verify if it is a valid fix or not
for this issue and let me know.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/03] staging: Emma Mobile USB driver and KZM9D board code
On Thu, May 22, 2014 at 06:32:03PM +0900, Magnus Damm wrote: > Hi Dan, > > On Thu, May 22, 2014 at 6:17 PM, Dan Carpenter > wrote: > > Generally we take things as is into staging so there is no need for a > > re-work if you don't want to. But we do need a TODO file. Read the > > TODO files for other staging drivers. > > Thanks for pointing that out, my apologies for being random and > skipping that! I will add a TODO file to v2! Other than the missing TODO file, the idea looks good, I don't have any objections to taking this. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] lib/devres.c: use dev in devm_request_and_ioremap
On Thu, May 22, 2014 at 07:34:34PM +0200, Fabian Frederick wrote: > devm_request_and_ioremap was the only function to use device > instead of dev(this fixes kernel-doc warning). > > Also fix some checkpatch warnings. Each patch should just do 1 thing. Please break this up into a bug fix patch and then a patch for the checkpatch warning(s). 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: linux-next: manual merge of the samsung tree with the tree
Stephen Rothwell wrote:
>
> Hi Kukjin,
>
Hi Stephen,
> Today's linux-next merge of the samsung tree got a conflict in
> arch/arm/mach-exynos/exynos.c between commit 46bfc99c9225 ("ARM: l2c:
> exynos: convert to generic l2c OF initialisation (and thereby fix it)")
> from the arm tree and commit 3919fb954b3a ("ARM: EXYNOS: Remove
> exynos_subsys registration") from the samsung tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Looks good to me, thanks.
- Kukjin
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc arch/arm/mach-exynos/exynos.c
> index afce154f83f9,93507ee98c86..
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@@ -241,17 -246,22 +243,6 @@@ void __init exynos_init_io(void
> exynos_map_io();
> }
>
> - struct bus_type exynos_subsys = {
> - .name = "exynos-core",
> - .dev_name = "exynos-core",
> - };
> -
> - static int __init exynos_core_init(void)
> -static int __init exynos4_l2x0_cache_init(void)
> --{
> - return subsys_system_register(_subsys, NULL);
> -int ret;
> -
> -ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
> -if (ret)
> -return ret;
> -
> -if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
> -l2x0_regs_phys = virt_to_phys(_saved_regs);
> -clean_dcache_area(_regs_phys, sizeof(unsigned long));
> -}
> -return 0;
> --}
> - core_initcall(exynos_core_init);
> -early_initcall(exynos4_l2x0_cache_init);
> --
> static void __init exynos_dt_machine_init(void)
> {
> struct device_node *i2c_np;
--
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 v4] gpio: Add support for Intel SoC PMIC (Crystal Cove)
Devices based on Intel SoC products such as Baytrail have a Power
Management IC. In the PMIC there are subsystems for voltage regulation,
A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
Crystal Cove.
This patch adds support for the GPIO function in Crystal Cove.
v2:
- Use IRQ chip helper to provide irqdomain.
- Implement .remove and can now build as a module.
- Various fix for unreadable or ugly code pieces.
v3:
- More fix in irq_handler and probe.
v4:
- Minor fix of one return statement.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
Reviewed-by: Mika Westerberg
---
drivers/gpio/Kconfig| 13 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-crystalcove.c | 345
3 files changed, 359 insertions(+)
create mode 100644 drivers/gpio/gpio-crystalcove.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index a86c49a..fed08d9d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -440,6 +440,19 @@ config GPIO_ARIZONA
help
Support for GPIOs on Wolfson Arizona class devices.
+config GPIO_CRYSTAL_COVE
+ tristate "GPIO support for Crystal Cove PMIC"
+ depends on INTEL_SOC_PMIC
+ select GPIOLIB_IRQCHIP
+ help
+ Support for GPIO pins on Crystal Cove PMIC.
+
+ Say Yes if you have a Intel SoC based tablet with Crystal Cove PMIC
+ inside.
+
+ This driver can also be built as a module. If so, the module will be
+ called gpio-crystalcove.
+
config GPIO_LP3943
tristate "TI/National Semiconductor LP3943 GPIO expander"
depends on MFD_LP3943
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6309aff..e6cd935 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
+obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o
obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
new file mode 100644
index 000..76b6d57
--- /dev/null
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -0,0 +1,345 @@
+/*
+ * gpio-crystalcove.c - Intel Crystal Cove GPIO Driver
+ *
+ * Copyright (C) 2012, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NUM_GPIO 16
+
+#define UPDATE_TYPEBIT(0)
+#define UPDATE_MASKBIT(1)
+
+#define GPIO0IRQ 0x0b
+#define GPIO1IRQ 0x0c
+#define MGPIO0IRQS00x19
+#define MGPIO1IRQS00x1a
+#define MGPIO0IRQSX0x1b
+#define MGPIO1IRQSX0x1c
+#define GPIO0P0CTLO0x2b
+#define GPIO0P0CTLI0x33
+#define GPIO1P0CTLO0x3b
+#define GPIO1P0CTLI0x43
+
+#define CTLI_INTCNT_NE (1 << 1)
+#define CTLI_INTCNT_PE (2 << 1)
+#define CTLI_INTCNT_BE (3 << 1)
+
+#define CTLO_DIR_OUT (1 << 5)
+
+#define CTLO_DRV_CMOS (0 << 4)
+#define CTLO_DRV_OD(1 << 4)
+
+#define CTLO_DRV_REN (1 << 3)
+
+#define CTLO_RVAL_2KDW (0)
+#define CTLO_RVAL_2KUP (1 << 1)
+#define CTLO_RVAL_50KDW(2 << 1)
+#define CTLO_RVAL_50KUP(3 << 1)
+
+#define CTLO_INPUT_DEF (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP)
+#define CTLO_OUTPUT_DEF(CTLO_DIR_OUT | CTLO_INPUT_DEF)
+
+#define GPIO_TO_CTL(gpio, dir) \
+ ((gpio < 8 ? GPIO0P0CTL ## dir : GPIO1P0CTL ## dir) + (gpio % 8))
+
+/**
+ * struct crystalcove_gpio - Crystal Cove GPIO controller
+ * @buslock: for bus lock/sync and unlock.
+ * @chip: the abstract gpio_chip structure.
+ * @update: pending IRQ setting update, to be written to the chip upon unlock.
+ * @trigger_type: the trigger type of the IRQ.
+ * @set_irq_mask: true if the IRQ mask needs to be set, false to clear.
+ */
+struct crystalcove_gpio {
+ struct mutexbuslock; /* irq_bus_lock */
+ struct gpio_chipchip;
+ int update;
+ int trigger_type;
+ bool
Re: [PATCH v2] pinctrl: add params in disable_setting for different usage
On 05/23/2014 07:13 AM, Stephen Warren wrote: On 05/21/2014 09:10 PM, f...@marvell.com wrote: From: Fan Wu What the patch did: 1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of calling pinctrl_select_state 2.Remove the HW disable operation in in pinmux_disable_setting function. ... diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index c0fe609..c97491a 100644 --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -993,25 +993,13 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state) * may not be identical to the set of groups with a mux setting * in the new state. While this might be unusual, it's entirely * possible for the "user"-supplied mapping table to be written -* that way. For each group that was configured in the old state -* but not in the new state, this code puts that group into a -* safe/disabled state. +* that way. This code is used for each group that was +* configured in the old state but not in the new state Looking at the code, it's run for every group in the state, not "each group that was configured in the old state but not in the new state" @@ -515,9 +514,6 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting) pins[i], desc->name, gname); } } - - if (ops->disable) - ops->disable(pctldev, setting->data.mux.func, setting->data.mux.group); } Should that op be removed from the header file and all drivers too? Dear Stephen, For you question 1: The disable_pinmux_setting is for the all of the setting in old state. This is what we really need to do, ahead of enable setting in new state. In the first patch I filed, which still includes the HW ops in disable_pinmux_setting, to disable each setting in old state and then to enable the setting in new state will introduce HW glitch. But in the current solution, the glitch will not be there, because there is no HW ops in disable_pinmux_setting. And please notice the patch is mainly used to avoid the duplicated enable operation for the same pin. For your question 2: the pinctrl-single driver is still using ops->disable, if I remove the "disable" in ops, there will be build error in the vendor's code base who is using pinctrl-single driver. Just as I said in the last mail, the next plan for this topic: 1. To remove the disable ops registration when defining the "include/linux/pinctrl/pinmux.h" in inctrl-single driver. Meanwhile, the related things, like "pinctrl-single,function-off" property and corresponding flag in "pcs_device", will be also removed. 2. To remove the disable ops in "pinmux_ops" in the file of include/linux/pinctrl/pinmux.h Are you OK for this ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
Hyper-V hosts can support multiple targets and multiple channels and larger
number of
LUNs per target. Update the code to reflect this. With this patch we can
correctly
enumerate all the paths in a multi-path storage environment.
MS-TFS: 173725
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c | 36 ++--
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..5a63772 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -331,16 +331,15 @@ static int storvsc_timeout = 180;
static void storvsc_on_channel_callback(void *context);
/*
- * In Hyper-V, each port/path/target maps to 1 scsi host adapter. In
- * reality, the path/target is not used (ie always set to 0) so our
- * scsi host adapter essentially has 1 bus with 1 target that contains
- * up to 256 luns.
+ * In Hyper-V, each port/path/target maps to 1 scsi host adapter.
*/
-#define STORVSC_MAX_LUNS_PER_TARGET64
-#define STORVSC_MAX_TARGETS1
-#define STORVSC_MAX_CHANNELS 1
-
+#define STORVSC_MAX_LUNS_PER_TARGET255
+#define STORVSC_MAX_TARGETS2
+#define STORVSC_MAX_CHANNELS 8
+#define STORVSC_FC_MAX_LUNS_PER_TARGET 255
+#define STORVSC_FC_MAX_TARGETS 128
+#define STORVSC_FC_MAX_CHANNELS8
struct storvsc_cmd_request {
struct list_head entry;
@@ -1789,12 +1788,21 @@ static int storvsc_probe(struct hv_device *device,
host_dev->path = stor_device->path_id;
host_dev->target = stor_device->target_id;
- /* max # of devices per target */
- host->max_lun = STORVSC_MAX_LUNS_PER_TARGET;
- /* max # of targets per channel */
- host->max_id = STORVSC_MAX_TARGETS;
- /* max # of channels */
- host->max_channel = STORVSC_MAX_CHANNELS - 1;
+ if (dev_id->driver_data == SFC_GUID) {
+ /* max # of devices per target */
+ host->max_lun = STORVSC_FC_MAX_LUNS_PER_TARGET;
+ /* max # of targets per channel */
+ host->max_id = STORVSC_FC_MAX_TARGETS;
+ /* max # of channels */
+ host->max_channel = STORVSC_FC_MAX_CHANNELS - 1;
+ } else {
+ /* max # of devices per target */
+ host->max_lun = STORVSC_MAX_LUNS_PER_TARGET;
+ /* max # of targets per channel */
+ host->max_id = STORVSC_MAX_TARGETS;
+ /* max # of channels */
+ host->max_channel = STORVSC_MAX_CHANNELS - 1;
+ }
/* max cmd length */
host->max_cmd_len = STORVSC_MAX_CMD_LEN;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] irqchip: add Broadcom Set Top Box Level-2 interrupt controller
On Thu, 22 May 2014, Florian Fainelli wrote:
> +static void brcmstb_l2_intc_irq_handle(unsigned int irq, struct irq_desc
> *desc)
> +{
> + struct brcmstb_l2_intc_data *b = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_get_chip(irq);
irq_desc_get_chip() is what you want here. irq_get_chip() is doing a
full lookop of desc, which is silly as you have desc already.
Thanks,
tglx
--
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: 回复： Re: [PATCH linux-next] net/dccp/timer.c: use 'u64' instead of 's64' to avoid compiler's warning
On 05/23/2014 07:58 AM, 管雪涛 wrote:
>
> - David Miller 写道：
>> From: Chen Gang
>> Date: Wed, 21 May 2014 08:19:34 +0800
>>
>>> 'dccp_timestamp_seed' is initialized once by ktime_get_real() in
>>> dccp_timestamping_init(). It is always less than ktime_get_real()
>>> in dccp_timestamp().
>>>
>>> Then, ktime_us_delta() in dccp_timestamp() will always return positive
>>> number. So can use manual type cast to let compiler and do_div() know
>>> about it to avoid warning.
>>>
>>> The related warning (with allmodconfig under unicore32):
>>>
>>> CC [M] net/dccp/timer.o
>>> net/dccp/timer.c: In function ‘dccp_timestamp’:
>>> net/dccp/timer.c:285: warning: comparison of distinct pointer types lacks
>>> a cast
>>>
>>>
>>> Signed-off-by: Chen Gang
>>
>> Applied to net-next, thanks.
>>
Thank you for your work.
>> But that type check in include/asm-generic/div64.h is bogus, it should
>> be checking sizeof(X) == 8 rather than the type thing, it just wants to
>> make sure that the value is 64-bit regardless of it's signedness.
>>
>> The arch local implementations do not do this, and that's why very few
>> other people notice this warning.
>
> Arch-dependent codes implement it with unsigned long long type.
> And, every warning should not be ignored.
>
Yeah, we have to let do_div() no touch (especially for 32-bit machine,
which the highest bit is checked). The related code in
"include/asm-generic/div64.h":
23 #if BITS_PER_LONG == 64
24
25 # define do_div(n,base) ({ \
26 uint32_t __base = (base); \
27 uint32_t __rem; \
28 __rem = ((uint64_t)(n)) % __base; \
29 (n) = ((uint64_t)(n)) / __base; \
30 __rem; \
31 })
32
33 #elif BITS_PER_LONG == 32
34
35 extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
36
37 /* The unnecessary pointer compare is there
38 * to check for type safety (n must be 64bit)
39 */
40 # define do_div(n,base) ({ \
41 uint32_t __base = (base); \
42 uint32_t __rem; \
43 (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
44 if (likely(((n) >> 32) == 0)) { \
45 __rem = (uint32_t)(n) % __base; \
46 (n) = (uint32_t)(n) / __base; \
47 } else \
48 __rem = __div64_32(&(n), __base); \
49 __rem; \
50 })
And for division operation, architectures are signed/unsigned
sensitive, e.g. div_u64() and div_s64(), they are different.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC V6 2/2] clk: Add handling of clk parent and rate assigned from DT
Quoting Sylwester Nawrocki (2014-05-19 10:22:51)
> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> index 700e7aa..bee649b 100644
> --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> @@ -132,3 +132,35 @@ clock signal, and a UART.
>("pll" and "pll-switched").
> * The UART has its baud clock connected the external oscillator and its
>register clock connected to the PLL clock (the "pll-switched" signal)
> +
> +==Assigned clock parents and rates==
> +
> +Some platforms require static initial configuration of default parent clocks
> +and clock frequecies. Such a configuration can be specified in a device node
s/frequecies/frequencies/
> +through clock-parents and clock-rates DT properties. The former should
> contain
> +a list of parent clocks in form of phandle and clock specifier pairs, the
> +latter the list of assigned clock frequency values (one cell each).
> +To skip setting parent or rate of a clock its corresponding entry should be
> +set to 0, or can be omitted if it is not followed by any non-zero entry.
> +
> +uart@a000 {
> +compatible = "fsl,imx-uart";
> +reg = <0xa000 0x1000>;
> +...
> +clocks = < 0>, < 3>;
> +clock-names = "baud", "mux";
> +
> +clock-parents = <0>, < 1>;
> +clock-rates = <460800>;
> +};
> +
> +In this example the pll is set as parent of "mux" clock and frequency of
> +"baud" clock is specified as 460800 Hz.
> +
> +Configuring a clock's parent and rate through the device node that consumes
> +the clock can be done only for clocks that have a single user. Specifying
> +conflicting parent or rate configuration in multiple consumer nodes for
> +a shared clock is forbidden.
> +
> +Configuration of common clocks, which affect multiple consumer devices can
> +be similarly specified in the clock provider node.
Is it worthwhile to show an example of this? I guess the outcome will
depend on whether or not we support "assigned-clocks" property, which I
just revisited in the V5 thread.
Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU
On Wed, 2014-05-21 at 21:09 +, Luck, Tony wrote: > Please do give us more detail on the scenario that you see that would > make your new version behave better. > > I'm sure the current code has no races w.r.t. clearing mces_seen. The > monarch clears them all in mce_reign() before clearing mce_executing > at the foot of mce_end() and allowing the others to run again. > Right. There are not races for cleaning mces_seen. But, if a timeout occurs in monarch, mces_seen will be not cleaned. It will affect all other CPUs. As Borislav Petkov says, if we reach a timeout, there is very little chance for recovering. Thought. the probability for this situation to happen is very slight, it's not impossible. Indeed, it's hard to know the precise causes for timeout. As Naoya Horiguchi says, this patch also have a small benefit that it can reduce the processing time of monarch CPU. > Your code has the monarch release all the other cpus from the spinloop > in mce_end() so they will all rush together through the final lines of > do_machine_check(). No. My code just distribute cleaning operation to Per-CPU. And all other CPUs still have to wait for clearing mce_executing by monarch. In fact, mces_seen is just used for system panics as quickly as possible if there is a truly data corrupting error. So there is not advantage for cleaning mces_seen in the monarch. > Some of them will have work to do if they saw > errors - they may have to send signals, or log the error. Others can > fly directly to the end of do_machine_check() and clear MCG_STATUS > and return to executing whatever code was interrupted. > > So it is possible that some processors will be out doing things that can > generate another machine check, before others have finished their > tasks and got to the point to clear mces_seen.(*) > > -Tony > > (*) maybe that doesn't matter because they haven't zeroed MCG_STATUS > yet - so this second machine check will force those cpus to shutdown. See MCIP > description in "15.3.1.2 IA32_MCG_STATUS_MSR" section of software > developer manual. Right. This I also know. This is the reason why you can find the following snippet in my code: /* * Now clear the mces_seen of current CPU -*final - so that it does not * reappear on the next mce. */ memset(final, 0, sizeof(struct mce)); mce_wrmsrl(MSR_IA32_MCG_STATUS, 0); --- Thanks very much for your reply. cyc -- 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 RFC v5 2/2] clk: Add handling of clk parent and rate assigned from DT
Quoting Sylwester Nawrocki (2014-04-11 05:25:49)
> >> +==Assigned clock parents and rates==
> >> +
> >> +Some platforms require static initial configuration of parts of the clocks
> >> +controller. Such a configuration can be specified in a clock consumer node
> >> +through clock-parents and clock-rates DT properties. The former should
> >> +contain a list of parent clocks in form of phandle and clock specifier
> >> pairs,
> >> +the latter the list of assigned clock frequency values (one cell each).
> >> +To skip setting parent or rate of a clock its corresponding entry should
> >> be
> >> +set to 0, or can be omitted if it is not followed by any non-zero entry.
> >> +
> >> +uart@a000 {
> >> +compatible = "fsl,imx-uart";
> >> +reg = <0xa000 0x1000>;
> >> +...
> >> +clocks = < 0>, < 3>;
> >> +clock-names = "baud", "mux";
> >> +
> >> +clock-parents = <0>, < 1>;
> >> +clock-rates = <460800>;
> >
> > Is this the input frequency or serial baud rate? Looks like a baud
> > rate, but the clock framework needs input (to the uart) frequency. I
> > would say this should be clock-frequency and specify the max baud rate
> > as is being done with i2c bindings. The uart driver should know how to
> > convert between input clock freq and baud rate.
>
> This UART example is not quite representative for the issues I have been
> trying to address with this patch set. There is a need to set (an initial)
> input clock frequency. E.g. in case of multimedia devices there may be
> a need to set clock parent and frequency of an input clock to multiple IP
> blocks, so they are clocked synchronously and data is carried properly
> across a whole processing chain. Thus there may not be even clock output
> in an IP block, but still input clock needs to be set. IIUC there is
> similar issue with audio, where it is difficult to calculate the clock
> frequencies/determine parent clocks in individual drivers algorithmically.
>
> >> +};
> >> +
> >> +In this example the pll is set as parent of "mux" clock and frequency
> >> of "baud"
> >> +clock is specified as 460800 Hz.
> >
> > I don't really like clock-parents. The parent information is part of
> > the clock source, not the consumer.
>
> I'm not sure we must always consider the parent information as property
> of a clock source. If for example we expose a structure like below as
> single clock object, supporting clock gating, parent and frequency
> setting the parent setting is still accessible from within a device
> driver.
The design of the ccf implementation certainly allows one to hide
individually addressable/configurable clock nodes within a single struct
clk. But should we? I have always maintained that a clock driver should
enumerate clocks in the same way that the data sheet or technical
reference manual states. I did make a recent exception[1], but that is
going to be rolled back after the coordinated clock rate changes land in
mainline.
> And clock parent selection may depend on a system configuration
> not immediately obvious from within a single device driver perspective.
>
> MUX
>,---. DIVIDER GATE
> common clk source 1 -->|--.| ,. ,.
>| \ | || ||
> common clk source 2 -->|- '--|-->||-->||--> consumer
>... | | || ||
> common clk source N -->|- | '' ''
>'---'
>
> > We've somewhat decided against having every single clock defined in DT
> > and rather only describe a clock controller with leaf clocks to
> > devices. That is not a hard rule, but for complex clock trees that is
> > the norm. Doing something like this will require all levels of the
> > clock tree to be described. You may have multiple layers of parents
> > that have to be configured correctly. How are you configuring the rest
> > of the tree?
>
> I believe even clock controllers where clocks are represented as flat
> array often describe the clock tree entirely by parenthood, the tree
> structure is just not obvious from the DT binding.
> In addition, there seems to be appearing more and more clock controller
> DT bindings describing their clocks individually.
I've been discouraging these per-clock node bindings in favor of the
per-controller node style.
>
> >> +Configuring a clock's parent and rate through the device node that uses
> >> +the clock can be done only for clocks that have a single user. Specifying
> >> +conflicting parent or rate configuration in multiple consumer nodes for
> >> +a shared clock is forbidden.
> >> +
> >> +Configuration of common clocks, which affect multiple consumer devices
> >> +can be specified in a dedicated 'assigned-clocks' subnode of a clock
> >> +provider node, e.g.:
> >
> > This seems like a work-around due to having clock-parents in the
> > consumer
Re: [PATCH v4 05/16] PCI: quirk dma_alias_devfn for Marvell devices
Tested-by: George Spelvin (I'm running the whole series, but 1b4b:9172 are the devices I have.) -- 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 3.15-rc6
On Thu, May 22, 2014 at 6:07 PM, Guenter Roeck wrote: > On 05/22/2014 05:43 PM, Linus Torvalds wrote: >> >> >> only s390 seems to need a compat wrapper, and s390 is kind of odd in >> many respects, so I suspect renameat2 should just use ENTRY_SAME() on >> parisc, but without any way to *test* it I won't apply the patch. >> >> Guenter, I assume that changing the >> >> ENTRY_COMP(renameat2) >> >> line in arch/parisc/kernel/syscall_table.S to use ENTRY_SAME() at >> least fixes the compile error? > > Yes, it fixes the build error for parisc64, and parisc (32 bit) still > builds. Ok. I'd like to get some kind of confirmation that it is expected to work too. Miklos/Helge? Linus -- 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] gpio: Add support for Intel SoC PMIC (Crystal Cove)
On 5/22/2014 7:15 PM, Mika Westerberg wrote: > I suppose this is dependent on the MFD driver right? If so, this should > probably be merged along with that patch. > The MFD driver has been submitted on LKML as well. I think these two drivers can be pulled into corresponding trees, and meet each other in the Linus tree in the end, right? Best Regards Lejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the samsung tree with the tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/mach-exynos/exynos.c between commit 46bfc99c9225 ("ARM: l2c:
exynos: convert to generic l2c OF initialisation (and thereby fix it)")
from the arm tree and commit 3919fb954b3a ("ARM: EXYNOS: Remove
exynos_subsys registration") from the samsung tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-exynos/exynos.c
index afce154f83f9,93507ee98c86..
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@@ -241,17 -246,22 +243,6 @@@ void __init exynos_init_io(void
exynos_map_io();
}
- struct bus_type exynos_subsys = {
- .name = "exynos-core",
- .dev_name = "exynos-core",
- };
-
- static int __init exynos_core_init(void)
-static int __init exynos4_l2x0_cache_init(void)
--{
- return subsys_system_register(_subsys, NULL);
- int ret;
-
- ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
- if (ret)
- return ret;
-
- if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
- l2x0_regs_phys = virt_to_phys(_saved_regs);
- clean_dcache_area(_regs_phys, sizeof(unsigned long));
- }
- return 0;
--}
- core_initcall(exynos_core_init);
-early_initcall(exynos4_l2x0_cache_init);
--
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
signature.asc
Description: PGP signature
Re: [PATCH 2/3] of: Make of_find_node_by_path() handle /aliases
On 5/21/2014 6:16 PM, Grant Likely wrote:
> On Tue, 20 May 2014 19:41:22 -0700, Frank Rowand
> wrote:
>> On 5/18/2014 2:27 AM, Grant Likely wrote:
>>> On Fri, 16 May 2014 11:54:44 +0100, Grant Likely
>>> wrote:
On Thu, 15 May 2014 19:51:17 -0700, Frank Rowand
wrote:
> On 5/13/2014 7:58 AM, Grant Likely wrote:
>> Make of_find_node_by_path() handle aliases as prefixes. To make this
>> work the name search is refactored to search by path component instead
>> of by full string. This should be a more efficient search, and it makes
>> it possible to start a search at a subnode of a tree.
>>
>> Signed-off-by: David Daney
>> Signed-off-by: Pantelis Antoniou
>> [grant.likely: Rework to not require allocating at runtime]
>> Acked-by: Rob Herring
>> Signed-off-by: Grant Likely
>> ---
>> drivers/of/base.c | 60
>> +++
>> 1 file changed, 56 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 6e240698353b..60089b9a3014 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -771,9 +771,38 @@ struct device_node *of_get_child_by_name(const
>> struct device_node *node,
>> }
>> EXPORT_SYMBOL(of_get_child_by_name);
>>
>> +static struct device_node *__of_find_node_by_path(struct device_node
>> *parent,
>> +const char *path)
>> +{
>> +struct device_node *child;
>> +int len = strchrnul(path, '/') - path;
>> +
>> +if (!len)
>> +return parent;
>
> (!len) is true if the the final character of the path passed into
> of_find_node_by_path()
> was "/". Strictly speaking, ->full_name will never end with "/", so the
> return value
> should be NULL, indicating that the match fails.
Ah, good catch. I should add a test case for that.
>>>
>>> In my testing this looks okay. The while loop that calls into
>>> __of_find_node_by_path() looks like this:
>>>
>>> while (np && *path == '/') {
>>> path++; /* Increment past '/' delimiter */
>>> np = __of_find_node_by_path(np, path);
>>> path = strchrnul(path, '/');
>>> }
>>>
>>> If the path ends with a '/', then the loop will go around one more time.
>>> The pointer will be incremented to point at the null character and len
>>> will be null because strchrnul() will point at the last item.
>>
>> Yes, that was my point. The old version of of_find_node_by_path() would not
>> find a match if the path ended with a "/" (unless the full path was "/").
>> This patch series changes the behavior to be a match.
>>
>> I will reply to this email with an additional patch that restores the
>> original behavior.
>>
>> If you move the additional test cases you provide below and the test cases
>> in patch 3 to the beginning of the series, you can see the before and after
>> behavior of adding patch 1 and patch 2.
>
> Ah, I see. That raises the question about what the behaviour /should/
> be. Off the top of my head, matching against a trailing '/' seems to be
> okay. Are there situations that you see or can think of where matching
> would be the wrong thing to do?
I have not thought of a case where matching against a trailing '/' would
hurt anything. It just seemed better to be consistent in naming.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: ion: WARN when the handle kmap_cnt is going to wrap around
On Thu, May 22, 2014 at 5:51 PM, Mitchel Humpherys
wrote:
> There are certain client bugs (double unmap, for example) that can cause
> the handle->kmap_cnt (an unsigned int) to wrap around from zero. This
> causes problems when the handle is destroyed because we have:
>
> while (handle->kmap_cnt)
> ion_handle_kmap_put(handle);
>
> which takes a long time to complete when kmap_cnt starts at ~0 and can
> result in a watchdog timeout.
>
> WARN and bail when kmap_cnt is about to wrap around from zero.
>
> Signed-off-by: Mitchel Humpherys
> ---
> drivers/staging/android/ion/ion.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 3d5bf14722..f55f61a4cc 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -626,6 +626,10 @@ static void ion_handle_kmap_put(struct ion_handle
> *handle)
> {
> struct ion_buffer *buffer = handle->buffer;
>
> + if (!handle->kmap_cnt) {
> + WARN(1, "%s: Double unmap detected! bailing...\n", __func__);
> + return;
> + }
> handle->kmap_cnt--;
> if (!handle->kmap_cnt)
> ion_buffer_kmap_put(buffer);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kernel-team+unsubscr...@android.com.
Acked-by: Colin Cross
--
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 3.15-rc6
On 05/22/2014 05:43 PM, Linus Torvalds wrote:
Miklos,
this is from your commit 18e480aa07f78 ("parisc: add renameat2
syscall") which was acked by Helge Deller:
On Thu, May 22, 2014 at 10:20 AM, Guenter Roeck wrote:
Unfortunately it appears that the parisc changes cause build failures
with parisc 64 bit builds.
Building parisc:a500_defconfig ... failed
Building parisc:generic-64bit_defconfig ... failed
Error log:
arch/parisc/kernel/built-in.o: In function `sys_call_table':
(.rodata+0xad0): undefined reference to `compat_sys_renameat2'
make: *** [vmlinux] Error 1
only s390 seems to need a compat wrapper, and s390 is kind of odd in
many respects, so I suspect renameat2 should just use ENTRY_SAME() on
parisc, but without any way to *test* it I won't apply the patch.
Guenter, I assume that changing the
ENTRY_COMP(renameat2)
line in arch/parisc/kernel/syscall_table.S to use ENTRY_SAME() at
least fixes the compile error?
Yes, it fixes the build error for parisc64, and parisc (32 bit) still builds.
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 2/3] of: Make of_find_node_by_path() handle /aliases
On 5/21/2014 8:13 PM, Grant Likely wrote:
> On Tue, 20 May 2014 19:46:19 -0700, Frank Rowand
> wrote:
>> On 5/20/2014 7:41 PM, Frank Rowand wrote:
>> < snip >
>>> I will reply to this email with an additional patch that restores the
>>> original behavior.
>> < snip >
>> From: Frank Rowand
>>
>> If __of_find_node_by_path() returns parent when the remaining portion of the
>> path is "/" then the behavior of of_find_node_by_path() has changed.
>>
>> Previously, adding an extraneous "/" on the end of a path would result
>> in of_find_node_by_path() not finding a match.
>>
>> Signed-off-by: Frank Rowand
>> ---
>> drivers/of/base.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> Index: b/drivers/of/base.c
>> ===
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -778,7 +778,7 @@ static struct device_node *__of_find_nod
>> int len = strchrnul(path, '/') - path;
>>
>> if (!len)
>> -return parent;
>> +return NULL;
>>
>> for_each_child_of_node(parent, child) {
>> const char *name = strrchr(child->full_name, '/');
>> @@ -813,6 +813,17 @@ struct device_node *of_find_node_by_path
>> struct property *pp;
>> unsigned long flags;
>>
>> +if (strcmp(path, "/") == 0) {
>> +raw_spin_lock_irqsave(_lock, flags);
>> +for (; np; np = np->allnext) {
>> +if (np->full_name && (of_node_cmp(np->full_name, path)
>> == 0)
>> +&& of_node_get(np))
>> +break;
>> +}
>> +raw_spin_unlock_irqrestore(_lock, flags);
>> +return np;
>> +}
>> +
>
> Special case for the root node? Could use a comment, and of_allnodes
> will already point to the root node so this could simply be:
>
> if (strcmp(path, "/") == 0)
> return of_node_get(np);
Yes, your version below is better. I was hoping there was a direct way
of getting the node for "/". It works on my dragonboard.
The comment of why special case "/" is that for the path "/"
__of_find_node_by_path() will return NULL.
>
> Here's a complete patch:
>
> commit adc96db6c39ef7b895e75d30dbc69781f6443f1d
> Author: Grant Likely
> Date: Thu May 22 11:55:31 2014 +0900
>
> fix trailing '/' case
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index c05a143b6a70..45ac44c8dfea 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -790,7 +790,7 @@ static struct device_node *__of_find_node_by_path(struct
> device_node *parent,
> int len = strchrnul(path, '/') - path;
>
> if (!len)
> - return parent;
> + return NULL;
>
> __for_each_child_of_node(parent, child) {
> const char *name = strrchr(child->full_name, '/');
> @@ -820,10 +820,13 @@ static struct device_node
> *__of_find_node_by_path(struct device_node *parent,
> */
> struct device_node *of_find_node_by_path(const char *path)
> {
> - struct device_node *np = of_allnodes;
> + struct device_node *np = NULL;
> struct property *pp;
> unsigned long flags;
>
> + if (strcmp(path, "/") == 0)
> + return of_node_get(of_allnodes);
> +
> /* The path could begin with an alias */
> if (*path != '/') {
> char *p = strchrnul(path, '/');
> @@ -833,7 +836,6 @@ struct device_node *of_find_node_by_path(const char *path)
> if (!of_aliases)
> return NULL;
>
> - np = NULL;
> for_each_property_of_node(of_aliases, pp) {
> if (strlen(pp->name) == len && !strncmp(pp->name, path,
> len)) {
> np = of_find_node_by_path(pp->value);
> @@ -847,6 +849,8 @@ struct device_node *of_find_node_by_path(const char *path)
>
> /* Step down the tree matching path components */
> raw_spin_lock_irqsave(_lock, flags);
> + if (!np)
> + np = of_node_get(of_allnodes);
> while (np && *path == '/') {
> path++; /* Increment past '/' delimiter */
> np = __of_find_node_by_path(np, path);
> diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
> index 10900b18fc06..aeb0b5c8b21d 100644
> --- a/drivers/of/selftest.c
> +++ b/drivers/of/selftest.c
> @@ -42,9 +42,7 @@ static void __init of_selftest_find_node_by_name(void)
>
> /* Test if trailing '/' works */
> np = of_find_node_by_path("/testcase-data/");
> - selftest(np && !strcmp("/testcase-data", np->full_name),
> - "find /testcase-data/ failed\n");
> - of_node_put(np);
> + selftest(!np, "trailing '/' on /testcase-data/ should fail\n");
>
> np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
> selftest(np && !strcmp("/testcase-data/phandle-tests/consumer-a",
> np->full_name),
> @@ -58,9 +56,7 @@ static void __init
linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-vexpress/v2m.c between commit 86cb8830d957 ("ARM: l2c:
vexpress: convert to generic l2c OF initialisation") from the arm tree
and commits 3b9334ac835b ("mfd: vexpress: Convert custom func API to
regmap") and d2606f81d563 ("ARM: vexpress: Simplify SMP operations for
DT-powered system") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-vexpress/v2m.c
index b2fea70d412d,38f4f6f37770..
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@@ -369,70 -370,10 +370,9 @@@ MACHINE_START(VEXPRESS, "ARM-Versatile
.init_machine = v2m_init,
MACHINE_END
- static struct map_desc v2m_rs1_io_desc __initdata = {
- .virtual= V2M_PERIPH,
- .pfn= __phys_to_pfn(0x1c00),
- .length = SZ_2M,
- .type = MT_DEVICE,
- };
-
- static int __init v2m_dt_scan_memory_map(unsigned long node, const char
*uname,
- int depth, void *data)
- {
- const char **map = data;
-
- if (strcmp(uname, "motherboard") != 0)
- return 0;
-
- *map = of_get_flat_dt_prop(node, "arm,v2m-memory-map", NULL);
-
- return 1;
- }
-
- void __init v2m_dt_map_io(void)
- {
- const char *map = NULL;
-
- of_scan_flat_dt(v2m_dt_scan_memory_map, );
-
- if (map && strcmp(map, "rs1") == 0)
- iotable_init(_rs1_io_desc, 1);
- else
- iotable_init(v2m_io_desc, ARRAY_SIZE(v2m_io_desc));
-
- #if defined(CONFIG_SMP)
- vexpress_dt_smp_map_io();
- #endif
- }
-
- void __init v2m_dt_init_early(void)
- {
- u32 dt_hbi;
-
- vexpress_sysreg_of_early_init();
-
- /* Confirm board type against DT property, if available */
- if (of_property_read_u32(of_allnodes, "arm,hbi", _hbi) == 0) {
- u32 hbi = vexpress_get_hbi(VEXPRESS_SITE_MASTER);
-
- if (WARN_ON(dt_hbi != hbi))
- pr_warning("vexpress: DT HBI (%x) is not matching "
- "hardware (%x)!\n", dt_hbi, hbi);
- }
-
- versatile_sched_clock_init(vexpress_get_24mhz_clock_base(), 2400);
- }
-
- static const struct of_device_id v2m_dt_bus_match[] __initconst = {
- { .compatible = "simple-bus", },
- { .compatible = "arm,amba-bus", },
- { .compatible = "arm,vexpress,config-bus", },
- {}
- };
-
static void __init v2m_dt_init(void)
{
- of_platform_populate(NULL, v2m_dt_bus_match, NULL, NULL);
- l2x0_of_init(0x0040, 0xfe0f);
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
static const char * const v2m_dt_match[] __initconst = {
@@@ -442,11 -383,7 +382,9 @@@
DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
.dt_compat = v2m_dt_match,
+ .l2c_aux_val= 0x0040,
+ .l2c_aux_mask = 0xfe0f,
- .smp= smp_ops(vexpress_smp_ops),
+ .smp= smp_ops(vexpress_smp_dt_ops),
.smp_init = smp_init_ops(vexpress_smp_init_ops),
- .map_io = v2m_dt_map_io,
- .init_early = v2m_dt_init_early,
.init_machine = v2m_dt_init,
MACHINE_END
signature.asc
Description: PGP signature
[PATCH] staging: ion: WARN when the handle kmap_cnt is going to wrap around
There are certain client bugs (double unmap, for example) that can cause
the handle->kmap_cnt (an unsigned int) to wrap around from zero. This
causes problems when the handle is destroyed because we have:
while (handle->kmap_cnt)
ion_handle_kmap_put(handle);
which takes a long time to complete when kmap_cnt starts at ~0 and can
result in a watchdog timeout.
WARN and bail when kmap_cnt is about to wrap around from zero.
Signed-off-by: Mitchel Humpherys
---
drivers/staging/android/ion/ion.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 3d5bf14722..f55f61a4cc 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -626,6 +626,10 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
{
struct ion_buffer *buffer = handle->buffer;
+ if (!handle->kmap_cnt) {
+ WARN(1, "%s: Double unmap detected! bailing...\n", __func__);
+ return;
+ }
handle->kmap_cnt--;
if (!handle->kmap_cnt)
ion_buffer_kmap_put(buffer);
--
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 v1] drivers/clocksource: do not trace read_sched_clock
On 05/22/2014 08:03 PM, Daniel Lezcano wrote:
On 05/22/2014 03:50 AM, Yang,Wei wrote:
Hi Daniel,
What do you think of it?
Regards
Wei
On 05/13/2014 11:10 AM, wei.y...@windriver.com wrote:
From: Yang Wei
We do not need to trace read_sched_clock function,
so add notrace attribute for this function.
Hi Yang,
I agree with your patch. Applied in my tree for 3.16
Please in the future fix the subject name:
clocksource: [driver]: [A-Z]
Daniel, Got it. I would be careful next time:-)
Thanks
Wei
Thanks
-- Daniel
Signed-off-by: Yang Wei
---
drivers/clocksource/dw_apb_timer_of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/dw_apb_timer_of.c
b/drivers/clocksource/dw_apb_timer_of.c
index 2a2ea27..d305fb0 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -106,7 +106,7 @@ static void __init add_clocksource(struct
device_node *source_timer)
sched_rate = rate;
}
-static u64 read_sched_clock(void)
+static u64 notrace read_sched_clock(void)
{
return ~__raw_readl(sched_io_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/
[PATCH v3.5-rc2 1/1] fs: Fix a false lock inversion dependency warning
The false positive lockdep warning is as follows:
=
[ INFO: possible irq lock inversion dependency detected ]
3.10.10+ #1 Not tainted
-
kswapd0/627 just changed the state of lock:
(sb_writers#3){.+.+.?}, at: [] do_fallocate+0xf4/0x174
but this lock took another, RECLAIM_FS-unsafe lock in the past:
(>s_type->i_mutex_key#8/1){+.+.+.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
lock(>s_type->i_mutex_key#8/1);
local_irq_disable();
lock(sb_writers#3);
lock(>s_type->i_mutex_key#8/1);
lock(sb_writers#3);
*** DEADLOCK ***
the shortest dependencies between 2nd lock and 1st lock:
-> (>s_type->i_mutex_key#8/1){+.+.+.} ops: 633 {
... key at: [] shmem_fs_type+0x55/0x98
... acquired at:
[] check_prevs_add+0x704/0x874
[] validate_chain.isra.24+0x5e0/0x9b0
[] __lock_acquire+0x3fc/0xbcc
[] lock_acquire+0xa4/0x208
[] mutex_lock_nested+0x74/0x3f8
[] kern_path_create+0x7c/0x12c
[] user_path_create+0x48/0x60
[] SyS_mkdirat+0x3c/0xc0
[] SyS_mkdir+0x24/0x28
[] ret_fast_syscall+0x0/0x48
-> (sb_writers#3){.+.+.?} ops: 2054 {
..
... key at: [] shmem_fs_type+0x34/0x98
... acquired at:
[] print_irq_inversion_bug+0x184/0x20c
[] check_usage_forwards+0xb0/0x11c
[] mark_lock+0x1c8/0x71c
[] __lock_acquire+0x558/0xbcc
[] lock_acquire+0xa4/0x208
[] __sb_start_write+0xb4/0x184
[] do_fallocate+0xf4/0x174
[] ashmem_shrink+0xc8/0x150
[] shrink_slab+0x1d8/0x540
[] kswapd+0x494/0xaec
[] kthread+0xb4/0xc0
[] ret_from_fork+0x14/0x20
sb_writers lock is treated as a rw semaphore, and it can be taken
recursively, when multiple threads are modifying data or metadata
of the same filesystem. Since this lock is taken with interrupts
enabled, the above lock inverse order scenario could happen. But,
this will not really cause a deadlock, as sb_writers is always
taken only as a reader. So, disable lockdep checks around this
lock.
Signed-off-by: Madhu Rajakumar
---
fs/super.c | 20
1 file changed, 20 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index e5f6c2c..cc328ec 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1137,7 +1137,14 @@ void __sb_end_write(struct super_block *sb, int level)
smp_mb();
if (waitqueue_active(>s_writers.wait))
wake_up(>s_writers.wait);
+
+ /*
+* s_writers was taken with lockdep checks disabled, so turn off
+* lockdep checks here too
+*/
+ lockdep_off();
rwsem_release(>s_writers.lock_map[level-1], 1, _RET_IP_);
+ lockdep_on();
}
EXPORT_SYMBOL(__sb_end_write);
@@ -1163,7 +1170,20 @@ static void acquire_freeze_lock(struct super_block *sb,
int level, bool trylock,
break;
}
}
+
+ /*
+* s_writers lock sometimes triggers the lockdep warning 'possible irq
+* lock inversion dependency detected'. s_writers is treated as a rw
+* semaphore, always taken only as a reader. It can be taken
+* recursively, when multiple threads are modifying data or metadata of
+* the same filesystem. Since this lock is taken with irqs enabled, it
+* is not always possible to guarantee an ordering between s_writers
+* and other locks. Since this will not actually cause a deadlock, turn
+* off lockdep checks for this case.
+*/
+ lockdep_off();
rwsem_acquire_read(>s_writers.lock_map[level-1], 0, trylock, ip);
+ lockdep_on();
}
#endif
--
1.8.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up
[Resending due to mail client crashing] On 5/21/2014 6:17 PM, Bjorn Helgaas wrote: [resending because I forgot to copy the lists, sorry guys] Hi Suravee, Sorry it took me so long to get to these patches. Here's my proposal. I reordered them and added some comments in the code and changelogs, but I think your patches look fine as-is. So I just need comments on these two significant changes: 1) I added a patch to stop enabling ECS after Fam16h, because that's another case of CPU-dependent code that we should not need to keep carrying. I don't think there are any post-Fam16h CPUs yet, but I certainly don't want to do anything that will keep them from working when they do arrive. It would be useful if somebody could test this on current platforms by tweaking the patch so we don't enable ECS on Fam15h. I'm okay with this. In my V4 patch, I also tested disabling ECS on family15h already and that seems to work fine. But I would not mind deprecate this for post fam16h processors. 2) I dropped the quirk_amd_nb_node() removal. I could be convinced otherwise, but I don't really object to the quirk because it is already explicitly limited to specific devices, and removing it will change things in sysfs. I think the changes would be harmless as far as the kernel is concerned, since there are no drivers for these devices. But Andreas added the quirk because of complaints, so apparently somebody is looking at what's in sysfs, and I don't want to get the same complaints again by removing it. However, I will certainly ask questions if I see the quirk being extended to more devices. I'm okay with keeping this. The AMD BKDG does say the BIOS should provide an MCFG table (sec 2.8 of 42301), so I think it provides guidance matching the intent of my "stop enabling ECS" patch. But the BKDG doesn't mention _PXM at all. Is there any chance you could squeeze in a mention of that, so BIOS writers know that they *should* provide it? I want to avoid more fire-drills in the future. Bjorn The ship for family15h stuff have sailed and we probably would not be able to get them to change. We are going to have to keep an eye on the future platforms to make sure that the _PXM info is documented for future platforms. I have tested this patch set and they seems to be ok now. Suravee --- Bjorn Helgaas (1): x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h Myron Stowe (1): x86/PCI: Warn if we have to "guess" host bridge node information Suravee Suthikulpanit (2): x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM x86/PCI: Clean up and mark early_root_info_init() as deprecated arch/x86/pci/acpi.c|6 +++ arch/x86/pci/amd_bus.c | 87 +++- 2 files changed, 62 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-mvebu/board-v7.c between commit 8ae2473d96f1 ("ARM: l2c:
mvebu: convert to generic l2c OF initialisation") from the arm tree and
commit 5686a1e5aa43 ("bus: mvebu: pass the coherency availability
information at init time") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-mvebu/board-v7.c
index 48169caa56ea,01cfce6ac20b..
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@@ -57,8 -75,10 +75,9 @@@ static void __init mvebu_timer_and_clk_
{
of_clk_init(NULL);
clocksource_of_init();
+ mvebu_scu_enable();
coherency_init();
- BUG_ON(mvebu_mbus_dt_init());
+ BUG_ON(mvebu_mbus_dt_init(coherency_available()));
- l2x0_of_init(0, ~0UL);
if (of_machine_is_compatible("marvell,armada375"))
hook_fault_code(16 + 6, armada_375_external_abort_wa, SIGBUS, 0,
@@@ -121,9 -195,8 +196,10 @@@ static const char * const armada_375_dt
};
DT_MACHINE_START(ARMADA_375_DT, "Marvell Armada 375 (Device Tree)")
+ .l2c_aux_val= 0,
+ .l2c_aux_mask = ~0,
.init_time = mvebu_timer_and_clk_init,
+ .init_machine = mvebu_dt_init,
.restart= mvebu_restart,
.dt_compat = armada_375_dt_compat,
MACHINE_END
signature.asc
Description: PGP signature
Re: [PATCH V5 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up
On 5/21/2014 6:17 PM, Bjorn Helgaas wrote: [resending because I forgot to copy the lists, sorry guys] Hi Suravee, Sorry it took me so long to get to these patches. Here's my proposal. I reordered them and added some comments in the code and changelogs, but I think your patches look fine as-is. So I just need comments on these two significant changes: 1) I added a patch to stop enabling ECS after Fam16h, because that's another case of CPU-dependent code that we should not need to keep carrying. I don't think there are any post-Fam16h CPUs yet, but I certainly don't want to do anything that will keep them from working when they do arrive. It would be useful if somebody could test this on current platforms by tweaking the patch so we don't enable ECS on Fam15h. I'm okay with this. In my V4 patch, I also tested disabling ECS on family15h already and that seems to work fine. But I would not mind deprecate this for post fam16h processors. 2) I dropped the quirk_amd_nb_node() removal. I could be convinced otherwise, but I don't really object to the quirk because it is already explicitly limited to specific devices, and removing it will change things in sysfs. I think the changes would be harmless as far as the kernel is concerned, since there are no drivers for these devices. But Andreas added the quirk because of complaints, so apparently somebody is looking at what's in sysfs, and I don't want to get the same complaints again by removing it. However, I will certainly ask questions if I see the quirk being extended to more devices. I'm okay with keeping this. The AMD BKDG does say the BIOS should provide an MCFG table (sec 2.8 of 42301), so I think it provides guidance matching the intent of my "stop enabling ECS" patch. But the BKDG doesn't mention _PXM at all. Is there any chance you could squeeze in a mention of that, so BIOS writers know that they *should* provide it? I want to avoid more fire-drills in the future. The ship for family15h stuff have sailed and we probably would not be able to get them to change. We are going to have to keep an eye on the future platforms to make sure that the _PXM info is documented for future platforms. I have tested this patch set and they seems to be ok now. Suravee Bjorn --- Bjorn Helgaas (1): x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h Myron Stowe (1): x86/PCI: Warn if we have to "guess" host bridge node information Suravee Suthikulpanit (2): x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM x86/PCI: Clean up and mark early_root_info_init() as deprecated arch/x86/pci/acpi.c|6 +++ arch/x86/pci/amd_bus.c | 87 +++- 2 files changed, 62 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.15-rc6
Miklos,
this is from your commit 18e480aa07f78 ("parisc: add renameat2
syscall") which was acked by Helge Deller:
On Thu, May 22, 2014 at 10:20 AM, Guenter Roeck wrote:
>
> Unfortunately it appears that the parisc changes cause build failures
> with parisc 64 bit builds.
>
> Building parisc:a500_defconfig ... failed
> Building parisc:generic-64bit_defconfig ... failed
>
> Error log:
> arch/parisc/kernel/built-in.o: In function `sys_call_table':
> (.rodata+0xad0): undefined reference to `compat_sys_renameat2'
> make: *** [vmlinux] Error 1
only s390 seems to need a compat wrapper, and s390 is kind of odd in
many respects, so I suspect renameat2 should just use ENTRY_SAME() on
parisc, but without any way to *test* it I won't apply the patch.
Guenter, I assume that changing the
ENTRY_COMP(renameat2)
line in arch/parisc/kernel/syscall_table.S to use ENTRY_SAME() at
least fixes the compile error?
Linus
--
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 RESEND v2 1/4] mfd: intel_soc_pmic: Core driver
This patch provides the common code for the intel_soc_pmic MFD driver,
such as read/write register and set up IRQ.
v2:
- Use regmap instead of our own callbacks for read/write.
- Add one missing EXPORT_SYMBOL.
- Remove some duplicate code and put them into pmic_regmap_load_from_hw.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_core.c | 521 +
drivers/mfd/intel_soc_pmic_core.h | 83 ++
include/linux/mfd/intel_soc_pmic.h | 29 +++
3 files changed, 633 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_core.c
create mode 100644 drivers/mfd/intel_soc_pmic_core.h
create mode 100644 include/linux/mfd/intel_soc_pmic.h
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/drivers/mfd/intel_soc_pmic_core.c
new file mode 100644
index 000..76d366e
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -0,0 +1,521 @@
+/*
+ * intel_soc_pmic_core.c - Intel SoC PMIC Core Functions
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_soc_pmic_core.h"
+
+struct cell_dev_pdata {
+ struct list_headlist;
+ const char *name;
+ void*data;
+ int len;
+};
+static LIST_HEAD(pdata_list);
+
+static DEFINE_MUTEX(pmic_lock);/* protect the following variables */
+static struct intel_soc_pmic *pmic;
+static int cache_offset = -1;
+static unsigned int cache_read_val;
+static unsigned int cache_write_val;
+static int cache_write_pending;
+static int cache_flags;
+
+struct device *intel_soc_pmic_dev(void)
+{
+ return pmic->dev;
+}
+EXPORT_SYMBOL(intel_soc_pmic_dev);
+
+/*
+ * Read from a PMIC register
+ */
+int intel_soc_pmic_readb(int reg)
+{
+ int ret;
+ unsigned int val;
+
+ mutex_lock(_lock);
+
+ if (!pmic) {
+ ret = -EIO;
+ } else {
+ ret = regmap_read(pmic->regmap, reg, );
+ if (!ret)
+ ret = val;
+ }
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_readb);
+
+/*
+ * Write to a PMIC register
+ */
+int intel_soc_pmic_writeb(int reg, u8 val)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_write(pmic->regmap, reg, val);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_writeb);
+
+/*
+ * Set 1 bit in a PMIC register
+ */
+int intel_soc_pmic_setb(int reg, u8 mask)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_update_bits(pmic->regmap, reg, mask, mask);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_setb);
+
+/*
+ * Clear 1 bit in a PMIC register
+ */
+int intel_soc_pmic_clearb(int reg, u8 mask)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_update_bits(pmic->regmap, reg, mask, 0);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_clearb);
+
+/*
+ * Set and clear multiple bits of a PMIC register
+ */
+int intel_soc_pmic_update(int reg, u8 val, u8 mask)
+{
+ int ret;
+
+ mutex_lock(_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = regmap_update_bits(pmic->regmap, reg, mask, val);
+
+ mutex_unlock(_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_update);
+
+/*
+ * Set platform_data of the child devices. Needs to be called before
+ * the MFD device is added.
+ */
+int intel_soc_pmic_set_pdata(const char *name, void *data, int len)
+{
+ struct cell_dev_pdata *pdata;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err("intel_pmic: can't set pdata!\n");
+ return -ENOMEM;
+ }
+
+ pdata->name = name;
+ pdata->data = data;
+ pdata->len = len;
+
+ list_add_tail(>list, _list);
+
+ return 0;
+}
+EXPORT_SYMBOL(intel_soc_pmic_set_pdata);
+
+static void __pmic_regmap_flush(void)
+{
+ if (cache_write_pending)
+ WARN_ON(regmap_write(pmic->regmap, cache_offset,
+
[PATCH RESEND v2 3/4] mfd: intel_soc_pmic: Crystal Cove support
Crystal Cove is the PMIC in Baytrail-T platform. This patch provides
chip-specific support for Crystal Cove.
v2:
- Add regmap_config for Crystal Cove.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_crc.c | 165 +++
1 file changed, 165 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_crc.c
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
new file mode 100644
index 000..6ab4cbf
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -0,0 +1,165 @@
+/*
+ * intel_soc_pmic_crc.c - Device access for Crystal Cove PMIC
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_soc_pmic_core.h"
+
+#define CRYSTAL_COVE_IRQ_NUM 7
+#define CRYSTAL_COVE_MAX_REGISTER 0xBD
+
+#define CHIPID 0x00
+#define CHIPVER0x01
+#define IRQLVL10x02
+#define MIRQLVL1 0x0E
+enum {
+ PWRSRC_IRQ = 0,
+ THRM_IRQ,
+ BCU_IRQ,
+ ADC_IRQ,
+ CHGR_IRQ,
+ GPIO_IRQ,
+ VHDMIOCP_IRQ
+};
+
+static struct resource gpio_resources[] = {
+ {
+ .name = "GPIO",
+ .start = GPIO_IRQ,
+ .end= GPIO_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource pwrsrc_resources[] = {
+ {
+ .name = "PWRSRC",
+ .start = PWRSRC_IRQ,
+ .end = PWRSRC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource adc_resources[] = {
+ {
+ .name = "ADC",
+ .start = ADC_IRQ,
+ .end = ADC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource thermal_resources[] = {
+ {
+ .name = "THERMAL",
+ .start = THRM_IRQ,
+ .end = THRM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+static struct resource bcu_resources[] = {
+ {
+ .name = "BCU",
+ .start = BCU_IRQ,
+ .end = BCU_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+static struct mfd_cell crystal_cove_dev[] = {
+ {
+ .name = "crystal_cove_pwrsrc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(pwrsrc_resources),
+ .resources = pwrsrc_resources,
+ },
+ {
+ .name = "crystal_cove_adc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(adc_resources),
+ .resources = adc_resources,
+ },
+ {
+ .name = "crystal_cove_thermal",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(thermal_resources),
+ .resources = thermal_resources,
+ },
+ {
+ .name = "crystal_cove_bcu",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(bcu_resources),
+ .resources = bcu_resources,
+ },
+ {
+ .name = "crystal_cove_gpio",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(gpio_resources),
+ .resources = gpio_resources,
+ },
+ {NULL, },
+};
+
+#defineCRC_IRQREGMAP_VALUE(irq){ \
+ {MIRQLVL1, irq, 1, 0}, \
+ {IRQLVL1, irq, 1, 0}, \
+ INTEL_PMIC_REG_NULL,\
+ }
+
+static struct intel_pmic_irqregmap crystal_cove_irqregmap[] = {
+ [PWRSRC_IRQ]= CRC_IRQREGMAP_VALUE(PWRSRC_IRQ),
+ [THRM_IRQ] = CRC_IRQREGMAP_VALUE(THRM_IRQ),
+ [BCU_IRQ] = CRC_IRQREGMAP_VALUE(BCU_IRQ),
+ [ADC_IRQ] = CRC_IRQREGMAP_VALUE(ADC_IRQ),
+ [CHGR_IRQ] = CRC_IRQREGMAP_VALUE(CHGR_IRQ),
+ [GPIO_IRQ] = CRC_IRQREGMAP_VALUE(GPIO_IRQ),
+ [VHDMIOCP_IRQ] = CRC_IRQREGMAP_VALUE(VHDMIOCP_IRQ),
+};
+
+static struct regmap_config crystal_cove_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = CRYSTAL_COVE_MAX_REGISTER,
+ .cache_type = REGCACHE_NONE,
+};
+
+static int crystal_cove_init(void)
+{
+ pr_debug("Crystal Cove: ID 0x%02X, VERSION 0x%02X\n",
+intel_soc_pmic_readb(CHIPID), intel_soc_pmic_readb(CHIPVER));
+ return 0;
+}
+
+struct
[PATCH RESEND v2 2/4] mfd: intel_soc_pmic: I2C interface
The Intel SoC PMIC devices are connected to the CPU via the I2C
interface. This patch provides support of the related I2C operations.
v2:
- Use regmap instead of creating our own I2C read/write callbacks.
Signed-off-by: Yang, Bin
Signed-off-by: Zhu, Lejun
---
drivers/mfd/intel_soc_pmic_i2c.c | 148 +++
1 file changed, 148 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c
diff --git a/drivers/mfd/intel_soc_pmic_i2c.c b/drivers/mfd/intel_soc_pmic_i2c.c
new file mode 100644
index 000..b6b8ee1
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_i2c.c
@@ -0,0 +1,148 @@
+/*
+ * intel_soc_pmic_i2c.c - Intel SoC PMIC MFD Driver
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_soc_pmic_core.h"
+
+static struct i2c_client *pmic_i2c_client;
+static struct intel_soc_pmic *pmic_i2c;
+
+static void pmic_shutdown(struct i2c_client *client)
+{
+ disable_irq(pmic_i2c_client->irq);
+ return;
+}
+
+static int pmic_suspend(struct device *dev)
+{
+ disable_irq(pmic_i2c_client->irq);
+ return 0;
+}
+
+static int pmic_resume(struct device *dev)
+{
+ enable_irq(pmic_i2c_client->irq);
+ return 0;
+}
+
+static const struct dev_pm_ops pmic_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pmic_suspend, pmic_resume)
+};
+
+static int pmic_i2c_lookup_gpio(struct device *dev, int acpi_index)
+{
+ struct gpio_desc *desc;
+ int gpio;
+
+ desc = gpiod_get_index(dev, KBUILD_MODNAME, acpi_index);
+ if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ gpio = desc_to_gpio(desc);
+
+ gpiod_put(desc);
+
+ return gpio;
+}
+
+static int pmic_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ if (pmic_i2c_client != NULL || pmic_i2c != NULL)
+ return -EBUSY;
+
+ pmic_i2c= (struct intel_soc_pmic *)id->driver_data;
+ pmic_i2c_client = i2c;
+ pmic_i2c->dev = >dev;
+ pmic_i2c->irq = i2c->irq;
+ pmic_i2c->pmic_int_gpio = pmic_i2c_lookup_gpio(pmic_i2c->dev, 0);
+ pmic_i2c->regmap = devm_regmap_init_i2c(i2c, pmic_i2c->regmap_cfg);
+
+ return intel_pmic_add(pmic_i2c);
+}
+
+static int pmic_i2c_remove(struct i2c_client *i2c)
+{
+ int ret = intel_pmic_remove(pmic_i2c);
+
+ pmic_i2c_client = NULL;
+ pmic_i2c = NULL;
+
+ return ret;
+}
+
+static const struct i2c_device_id pmic_i2c_id[] = {
+ { "crystal_cove", (kernel_ulong_t)_cove_pmic},
+ { "INT33FD", (kernel_ulong_t)_cove_pmic},
+ { "INT33FD:00", (kernel_ulong_t)_cove_pmic},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, pmic_i2c_id);
+
+static struct acpi_device_id pmic_acpi_match[] = {
+ { "INT33FD", (kernel_ulong_t)_cove_pmic},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, pmic_acpi_match);
+
+static struct i2c_driver pmic_i2c_driver = {
+ .driver = {
+ .name = "intel_soc_pmic_i2c",
+ .owner = THIS_MODULE,
+ .pm = _pm_ops,
+ .acpi_match_table = ACPI_PTR(pmic_acpi_match),
+ },
+ .probe = pmic_i2c_probe,
+ .remove = pmic_i2c_remove,
+ .id_table = pmic_i2c_id,
+ .shutdown = pmic_shutdown,
+};
+
+static int __init pmic_i2c_init(void)
+{
+ int ret;
+
+ ret = i2c_add_driver(_i2c_driver);
+ if (ret != 0)
+ pr_err("Failed to register pmic I2C driver: %d\n", ret);
+
+ return ret;
+}
+subsys_initcall(pmic_i2c_init);
+
+static void __exit pmic_i2c_exit(void)
+{
+ i2c_del_driver(_i2c_driver);
+}
+module_exit(pmic_i2c_exit);
+
+MODULE_DESCRIPTION("I2C driver for Intel SoC PMIC");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Yang, Bin ");
--
1.8.3.2
--
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 RESEND v2 0/4] mfd: Intel SoC Power Management IC
Devices based on Intel SoC products such as Baytrail have a Power Management IC. In the PMIC there are subsystems for voltage regulation, A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called Crystal Cove. This series contains common code for these PMICs, and device specific support for Crystal Cove. v2: - Use regmap instead of creating our own I2C read/write callbacks. - Add one missing EXPORT_SYMBOL. - Remove some duplicate code and put them into pmic_regmap_load_from_hw. Zhu, Lejun (4): mfd: intel_soc_pmic: Core driver mfd: intel_soc_pmic: I2C interface mfd: intel_soc_pmic: Crystal Cove support mfd: intel_soc_pmic: Build files drivers/mfd/Kconfig| 11 + drivers/mfd/Makefile | 3 + drivers/mfd/intel_soc_pmic_core.c | 521 + drivers/mfd/intel_soc_pmic_core.h | 83 ++ drivers/mfd/intel_soc_pmic_crc.c | 165 drivers/mfd/intel_soc_pmic_i2c.c | 148 +++ include/linux/mfd/intel_soc_pmic.h | 29 +++ 7 files changed, 960 insertions(+) create mode 100644 drivers/mfd/intel_soc_pmic_core.c create mode 100644 drivers/mfd/intel_soc_pmic_core.h create mode 100644 drivers/mfd/intel_soc_pmic_crc.c create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c create mode 100644 include/linux/mfd/intel_soc_pmic.h -- 1.8.3.2 -- 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 RESEND v2 4/4] mfd: intel_soc_pmic: Build files
Devices based on Intel SoC products such as Baytrail have a Power Management IC. This patch adds Intel SoC PMIC support to the build files. v2: - Add select REGMAP_I2C. Signed-off-by: Yang, Bin Signed-off-by: Zhu, Lejun --- drivers/mfd/Kconfig | 11 +++ drivers/mfd/Makefile | 3 +++ 2 files changed, 14 insertions(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..2c9de8e0 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -241,6 +241,17 @@ config LPC_SCH LPC bridge function of the Intel SCH provides support for System Management Bus and General Purpose I/O. +config INTEL_SOC_PMIC + bool "Support for Intel Atom SoC PMIC" + depends on I2C=y + select MFD_CORE + select REGMAP_I2C + help + Select this option to enable support for the PMIC device + on some Intel SoC systems. The PMIC provides ADC, GPIO, + thermal, charger and related power management functions + on these systems. + config MFD_INTEL_MSIC bool "Intel MSIC" depends on INTEL_SCU_IPC diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 2851275..1a18d8b 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -166,3 +166,6 @@ obj-$(CONFIG_MFD_RETU) += retu-mfd.o obj-$(CONFIG_MFD_AS3711) += as3711.o obj-$(CONFIG_MFD_AS3722) += as3722.o obj-$(CONFIG_MFD_STW481X) += stw481x.o + +intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o intel_soc_pmic_i2c.o +obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/6] seccomp: introduce writer locking
On Thu, May 22, 2014 at 4:05 PM, Kees Cook wrote:
> Normally, task_struct.seccomp.filter is only ever read or modified by
> the task that owns it (current). This property aids in fast access
> during system call filtering as read access is lockless.
>
> Updating the pointer from another task, however, opens up race
> conditions. To allow cross-task filter pointer updates, writes to the
> seccomp fields are now protected by a spinlock. Read access remains
> lockless because pointer updates themselves are atomic. However, writes
> (or cloning) often entail additional checking (like maximum instruction
> counts) which require locking to perform safely.
>
> In the case of cloning threads, the child is invisible to the system
> until it enters the task list. To make sure a child can't be cloned
> from a thread and left in a prior state, seccomp duplication is moved
> under the tasklist_lock. Then parent and child are certain have the same
> seccomp state when they exit the lock.
>
> Based on patches by Will Drewry and David Drysdale.
>
> Signed-off-by: Kees Cook
> ---
> include/linux/init_task.h |8
> include/linux/sched.h | 20
> include/linux/seccomp.h |6 --
> kernel/fork.c | 34 +-
> kernel/seccomp.c | 20 ++--
> 5 files changed, 79 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> index 6df7f9fe0d01..e2370ec3102b 100644
> --- a/include/linux/init_task.h
> +++ b/include/linux/init_task.h
> @@ -154,6 +154,13 @@ extern struct task_group root_task_group;
> # define INIT_VTIME(tsk)
> #endif
>
> +#ifdef CONFIG_SECCOMP
> +# define INIT_SECCOMP(tsk) \
> + .seccomp.lock = __SPIN_LOCK_UNLOCKED(tsk.seccomp.lock),
> +#else
> +# define INIT_SECCOMP(tsk)
> +#endif
> +
> #define INIT_TASK_COMM "swapper"
>
> #ifdef CONFIG_RT_MUTEXES
> @@ -234,6 +241,7 @@ extern struct task_group root_task_group;
> INIT_CPUSET_SEQ(tsk)\
> INIT_RT_MUTEXES(tsk)\
> INIT_VTIME(tsk) \
> + INIT_SECCOMP(tsk) \
> }
>
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 25f54c79f757..71a6cb66a3f3 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2480,6 +2480,26 @@ static inline void task_unlock(struct task_struct *p)
> spin_unlock(>alloc_lock);
> }
>
> +#ifdef CONFIG_SECCOMP
> +/*
> + * Protects changes to ->seccomp
> + */
> +static inline void seccomp_lock(struct task_struct *p, unsigned long *flags)
> +{
> + spin_lock_irqsave(>seccomp.lock, (*flags));
> +}
> +
> +static inline void seccomp_unlock(struct task_struct *p, unsigned long flags)
> +{
> + spin_unlock_irqrestore(>seccomp.lock, flags);
> +}
> +#else
> +static inline void seccomp_lock(struct task_struct *p, unsigned long *flags)
> +{ }
> +static inline void seccomp_unlock(struct task_struct *p, unsigned long flags)
> +{ }
> +#endif
> +
> extern struct sighand_struct *__lock_task_sighand(struct task_struct *tsk,
> unsigned long *flags);
>
> diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
> index 4054b0994071..c47be00e8ffb 100644
> --- a/include/linux/seccomp.h
> +++ b/include/linux/seccomp.h
> @@ -14,14 +14,16 @@ struct seccomp_filter;
> *
> * @mode: indicates one of the valid values above for controlled
> * system calls available to a process.
> - * @filter: The metadata and ruleset for determining what system calls
> - * are allowed for a task.
> + * @lock: held when making changes to avoid thread races.
> + * @filter: must always point to a valid seccomp-filter or NULL as it is
> + * accessed without locking during system call entry.
> *
> * @filter must only be accessed from the context of current as
> there
> * is no locking.
> */
> struct seccomp {
> int mode;
> + spinlock_t lock;
> struct seccomp_filter *filter;
> };
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 54a8d26f612f..e08a1907cd78 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -315,6 +315,15 @@ static struct task_struct *dup_task_struct(struct
> task_struct *orig)
> goto free_ti;
>
> tsk->stack = ti;
> +#ifdef CONFIG_SECCOMP
> + /*
> +* We must handle setting up seccomp filters once we're under
> +* the tasklist_lock in case orig has changed between now and
> +* then. Until then, filter must be NULL to avoid messing up
> +* the usage counts on the error path calling free_task.
> +*/
> + tsk->seccomp.filter = NULL;
> +#endif
>
> setup_thread_stack(tsk, orig);
>
[PATCH RESEND] ARM: trusted_foundations: fix compile error on non-SMP
The setup_max_cpus variable is only defined if CONFIG_SMP is set. Add
a preprocessor condition to avoid the following compilation error if
CONFIG_SMP is not set:
arch/arm/include/asm/trusted_foundations.h: In function
'register_trusted_foundations':
arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus'
undeclared (first use in this function)
Signed-off-by: Alexandre Courbot
Reported-by: Russell King
---
Hi Stephen,
This patch has been originally submitted through Russell's patch tracker,
where it has stayed untouched for ~3 weeks now. Considering that this
fixes a compilation error and should thus be made available quickly, and
that Tegra is the only user of Trusted Foundations, would you agree to take
it into your tree?
arch/arm/include/asm/trusted_foundations.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/trusted_foundations.h
b/arch/arm/include/asm/trusted_foundations.h
index b5f7705..624e1d4 100644
--- a/arch/arm/include/asm/trusted_foundations.h
+++ b/arch/arm/include/asm/trusted_foundations.h
@@ -54,7 +54,9 @@ static inline void register_trusted_foundations(
*/
pr_err("No support for Trusted Foundations, continuing in degraded
mode.\n");
pr_err("Secondary processors as well as CPU PM will be disabled.\n");
+#if IS_ENABLED(CONFIG_SMP)
setup_max_cpus = 0;
+#endif
cpu_idle_poll_ctrl(true);
}
--
1.9.2
--
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] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations
Hi Cody, On Thu, 22 May 2014 16:54:07 -0700 Cody P Schafer wrote: > > I've got a slight preference toward keeping it as is, which lets all of > the non-error path code stay outside of if/else blocks (and the error > handling is kept ever so slightly more consistent). No problem. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH v4 2/2] arm64: enable context tracking
+Mark Rutland Christopher Covington writes: > Hi Larry, > > On 05/22/2014 03:27 PM, Larry Bassel wrote: >> Make calls to ct_user_enter when the kernel is exited >> and ct_user_exit when the kernel is entered (in el0_da, >> el0_ia, el0_svc, el0_irq and all of the "error" paths). >> >> These macros expand to function calls which will only work >> properly if el0_sync and related code has been rearranged >> (in a previous patch of this series). >> >> The calls to ct_user_exit are made after hw debugging has been >> enabled (enable_dbg_and_irq). >> >> The call to ct_user_enter is made at the beginning of the >> kernel_exit macro. >> >> This patch is based on earlier work by Kevin Hilman. >> Save/restore optimizations were also done by Kevin. > >> --- a/arch/arm64/kernel/entry.S >> +++ b/arch/arm64/kernel/entry.S >> @@ -30,6 +30,44 @@ >> #include >> >> /* >> + * Context tracking subsystem. Used to instrument transitions >> + * between user and kernel mode. >> + */ >> +.macro ct_user_exit, restore = 0 >> +#ifdef CONFIG_CONTEXT_TRACKING >> +bl context_tracking_user_exit >> +.if \restore == 1 >> +/* >> + * Save/restore needed during syscalls. Restore syscall arguments from >> + * the values already saved on stack during kernel_entry. >> + */ >> +ldp x0, x1, [sp] >> +ldp x2, x3, [sp, #S_X2] >> +ldp x4, x5, [sp, #S_X4] >> +ldp x6, x7, [sp, #S_X6] >> +.endif >> +#endif >> +.endm >> + >> +.macro ct_user_enter, save = 0 >> +#ifdef CONFIG_CONTEXT_TRACKING >> +.if \save == 1 >> +/* >> + * Save/restore only needed on syscall fastpath, which uses >> + * x0-x2. >> + */ >> +pushx2, x3 > > Why is x3 saved? I'll respond here since I worked with Larry on the context save/restore part. [insert rather embarassing disclamer of ignorance of arm64 assembly] Based on my reading of the code, I figured only x0-x2 needed to be saved. However, based on some experiments with intentionally clobbering the registers[1] (as suggested by Mark Rutland) in order to make sure we're saving/restoring the right things, I discovered x3 was needed too (I missed updating the comment to mention x0-x3.) Maybe Will/Catalin/Mark R. can shed some light here? Kevin [1] >From 8a8702b4d597d08def1368beae5db2f4a8aa Mon Sep 17 00:00:00 2001 From: Kevin Hilman Date: Fri, 9 May 2014 13:37:43 -0700 Subject: [PATCH] KJH: test: clobber regs --- arch/arm64/kernel/entry.S | 38 ++ 1 file changed, 38 insertions(+) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 520da4c02ece..232f0200e88d 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -36,6 +36,25 @@ .macro ct_user_exit, restore = 0 #ifdef CONFIG_CONTEXT_TRACKING bl context_tracking_user_exit + movzx0, #0xff, lsl #48 + movzx1, #0xff, lsl #48 + movzx2, #0xff, lsl #48 + movzx3, #0xff, lsl #48 + movzx4, #0xff, lsl #48 + movzx5, #0xff, lsl #48 + movzx6, #0xff, lsl #48 + movzx7, #0xff, lsl #48 + movzx8, #0xff, lsl #48 + movzx9, #0xff, lsl #48 + movzx10, #0xff, lsl #48 + movzx11, #0xff, lsl #48 + movzx12, #0xff, lsl #48 + movzx13, #0xff, lsl #48 + movzx14, #0xff, lsl #48 + movzx15, #0xff, lsl #48 + movzx16, #0xff, lsl #48 + movzx17, #0xff, lsl #48 + movzx18, #0xff, lsl #48 .if \restore == 1 /* * Save/restore needed during syscalls. Restore syscall arguments from @@ -60,6 +79,25 @@ pushx0, x1 .endif bl context_tracking_user_enter + movzx0, #0xff, lsl #48 + movzx1, #0xff, lsl #48 + movzx2, #0xff, lsl #48 + movzx3, #0xff, lsl #48 + movzx4, #0xff, lsl #48 + movzx5, #0xff, lsl #48 + movzx6, #0xff, lsl #48 + movzx7, #0xff, lsl #48 + movzx8, #0xff, lsl #48 + movzx9, #0xff, lsl #48 + movzx10, #0xff, lsl #48 + movzx11, #0xff, lsl #48 + movzx12, #0xff, lsl #48 + movzx13, #0xff, lsl #48 + movzx14, #0xff, lsl #48 + movzx15, #0xff, lsl #48 + movzx16, #0xff, lsl #48 + movzx17, #0xff, lsl #48 + movzx18, #0xff, lsl #48 .if \save == 1 pop x0, x1 pop x2, x3 -- 1.9.2 -- 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] dt/sparc: Introduce the use of the managed version of kzalloc
On Thu, 22 May 2014, Dmitry Torokhov wrote: > Hi Julia, > > On Fri, May 23, 2014 at 07:03:37AM +0800, Julia Lawall wrote: > > > > > > On Thu, 22 May 2014, Dmitry Torokhov wrote: > > > > > Hi Himangi, > > > > > > On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote: > > > > This patch moves data allocated using kzalloc to managed data allocated > > > > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove > > > > functions. Also the unnecessary labels are done away with. > > > > > > Please no more partial devm conversions. I am not interested in patches > > > that change only 1 resource to be managed and leaving the rest as is. > > > > > > If you want to do devm conversion please do it if you convert all (or at > > > least majority) of resource handling to managed resources. > > > > Sorry, I don't think we are clear on what is wanted. Himangi's patches > > convert everything where a devm function is already available (to our > > knowledge). Do you prefer that new devm functions be introduced? On the > > one hand, that is perhaps useful from a safety point of view. On the > > other hand, it could lead to a huge number of rarely used devm functions > > that no one knows about and to a lot of code diversity. So I don't know > > what is the good solution. > > I strongly dislike changes that mix managed and non-managed resources in > the same driver as it only leads to confusion: should this resource be > freed or will it be freed automatically. > > I am applying patches that convert all (or almost all) resources in a > driver into managed ones, but if that is not [currently] possible then > those drivers are probably better left alone (maybe after additional > audit). OK, we will try to take that into account. Are the new managed functoins added to the devres docuentation? thanks, julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 02/11] PNPACPI: use whilte list for pnpacpi device enumeration
On Thu, 2014-05-22 at 12:14 -0600, Bjorn Helgaas wrote:
> "white" is misspelled in the subject line. I mentioned this before.
>
oops, forgot to update, thanks for the reminder.
>From a8e08d7a6e050f31cec069cc1704f21214b90566 Mon Sep 17 00:00:00 2001
From: Zhang Rui
Date: Tue, 8 Apr 2014 00:06:49 +0800
Subject: [PATCH V7 02/11] PNPACPI: use white list for pnpacpi device
enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.
Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
"three capital charactors followed by four hex numbers",
3. is not in the excluded id list,
it is enumerated to PNP bus.
So actually, PNP bus is used as the default bus for enumerating _HID devices.
But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.
So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.
Note: I just grep all the id strings in all pnp_device_id instances and
copy them to the new white list, with a few changes to the comments
only, to follow the format of:
/* driver name, or file name if not a PNP driver */
{"id-string"}, /* optional comments for the id-string */
...
Note: the PNPACPI devices are created in two step,
1. mark the PNPACPI devices by the acpi pnp scan handler.
2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
In this case, if PNP/PNPACPI is not set or "pnpacpi=off" kernel option
is used, the acpi pnp scan handler is still there, to prevent those
PNPACPI devices from being created to platform bus.
Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
there is already a cmos rtc scan handler installed, thus we need to
check those devices and enumerate them to PNP bus explicitly.
Plus, the cmos rtc scan handler needs to return 1 so that it will not
be enumerated to platform bus.
TODO: Reduce this PNPACPI white list by
1. remove the ids for the devices that are never enumerated via ACPI
2. remove the ids and convert the drivers to platform bus drivers
for the devices that are not PNP devices in nature.
Signed-off-by: Zhang Rui
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_cmos_rtc.c | 2 +-
drivers/acpi/acpi_pnp.c | 388 +++
drivers/acpi/internal.h | 1 +
drivers/acpi/scan.c | 1 +
drivers/pnp/pnpacpi/core.c | 28 +---
include/linux/acpi.h | 2 +
7 files changed, 398 insertions(+), 25 deletions(-)
create mode 100644 drivers/acpi/acpi_pnp.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
acpi-$(CONFIG_X86_INTEL_LPSS) += acpi_lpss.o
acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
acpi-y += power.o
acpi-y += event.o
acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct
acpi_device *adev,
return -ENODEV;
}
- return 0;
+ return 1;
}
static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui
+ *
+ * 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.
+ */
+
+#include
+#include
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+ /* pata_isapnp */
+ {"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk
controller */
+ /* floppy */
+ {"PNP0700"},
+ /* ipmi_si */
+ {"IPI0001"},
+ /* tpm_inf_pnp */
+ {"IFX0101"},/* Infineon TPMs */
+ {"IFX0102"},/* Infineon TPMs */
+
回复： Re: [PATCH linux-next] net/dccp/timer.c: use 'u64' instead of 's64' to avoid compiler's warning
- David Miller 写道： > From: Chen Gang > Date: Wed, 21 May 2014 08:19:34 +0800 > > > 'dccp_timestamp_seed' is initialized once by ktime_get_real() in > > dccp_timestamping_init(). It is always less than ktime_get_real() > > in dccp_timestamp(). > > > > Then, ktime_us_delta() in dccp_timestamp() will always return positive > > number. So can use manual type cast to let compiler and do_div() know > > about it to avoid warning. > > > > The related warning (with allmodconfig under unicore32): > > > > CC [M] net/dccp/timer.o > > net/dccp/timer.c: In function ‘dccp_timestamp’: > > net/dccp/timer.c:285: warning: comparison of distinct pointer types lacks > > a cast > > > > > > Signed-off-by: Chen Gang > > Applied to net-next, thanks. > > But that type check in include/asm-generic/div64.h is bogus, it should > be checking sizeof(X) == 8 rather than the type thing, it just wants to > make sure that the value is 64-bit regardless of it's signedness. > > The arch local implementations do not do this, and that's why very few > other people notice this warning. Arch-dependent codes implement it with unsigned long long type. And, every warning should not be ignored. -- 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] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations
On 05/22/2014 04:49 PM, Stephen Rothwell wrote:
Hi Cody,
On Thu, 22 May 2014 15:44:25 -0700 Cody P Schafer
wrote:
if (ret) {
if (success_expected)
pr_err_ratelimited("hcall failed: %d %#x %#x %d => 0x%lx
(%ld) detail=0x%x failing ix=%x\n",
domain, offset, ix, lpar,
ret, ret,
- result_buffer.buf.detailed_rc,
- result_buffer.buf.failing_request_ix);
- return ret;
+ result_buffer->buf.detailed_rc,
+ result_buffer->buf.failing_request_ix);
+ goto out_hcall;
}
- *res = be64_to_cpu(result_buffer.result);
+ *res = be64_to_cpu(result_buffer->result);
not a biggie, but this last bit could be (remove the goto out_hcall and
teh label and then)
} else {
*res = be64_to_cpu(result_buffer->result);
}
I've got a slight preference toward keeping it as is, which lets all of
the non-error path code stay outside of if/else blocks (and the error
handling is kept ever so slightly more consistent).
+out_hcall:
+ kfree(result_buffer);
+out_resb:
+ kfree(request_buffer);
+out_reqb:
return ret;
}
otherwise looks good to me.
--
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] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations
Hi Cody,
On Thu, 22 May 2014 15:44:25 -0700 Cody P Schafer
wrote:
>
> if (ret) {
> if (success_expected)
> pr_err_ratelimited("hcall failed: %d %#x %#x %d =>
> 0x%lx (%ld) detail=0x%x failing ix=%x\n",
> domain, offset, ix, lpar,
> ret, ret,
> - result_buffer.buf.detailed_rc,
> - result_buffer.buf.failing_request_ix);
> - return ret;
> + result_buffer->buf.detailed_rc,
> + result_buffer->buf.failing_request_ix);
> + goto out_hcall;
> }
>
> - *res = be64_to_cpu(result_buffer.result);
> + *res = be64_to_cpu(result_buffer->result);
not a biggie, but this last bit could be (remove the goto out_hcall and
teh label and then)
} else {
*res = be64_to_cpu(result_buffer->result);
}
> +out_hcall:
> + kfree(result_buffer);
> +out_resb:
> + kfree(request_buffer);
> +out_reqb:
> return ret;
> }
>
otherwise looks good to me.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH v2] mm, compaction: properly signal and act upon lock and need_sched() contention
On Fri, May 16, 2014 at 2:47 AM, Vlastimil Babka wrote:
> Compaction uses compact_checklock_irqsave() function to periodically check for
> lock contention and need_resched() to either abort async compaction, or to
> free the lock, schedule and retake the lock. When aborting, cc->contended is
> set to signal the contended state to the caller. Two problems have been
> identified in this mechanism.
This patch (or later version) has hit next-20140522 (in the form
commit 645ceea9331bfd851bc21eea456dda27862a10f4) and according to my
bisect, appears to be the culprit of several boot failures on ARM
platforms.
Unfortunately, there isn't much useful in the logs of the boot
failures/hangs since they mostly silently hang. However, on one
platform (Marvell Armada 370 Mirabox), it reports a failure to
allocate memory, and the RCU stall detection kicks in:
[1.298234] xhci_hcd :02:00.0: xHCI Host Controller
[1.303485] xhci_hcd :02:00.0: new USB bus registered, assigned
bus number 1
[1.310966] xhci_hcd :02:00.0: Couldn't initialize memory
[ 22.245395] INFO: rcu_sched detected stalls on CPUs/tasks: {}
(detected by 0, t=2102 jiffies, g=-282, c=-283, q=16)
[ 22.255886] INFO: Stall ended before state dump start
[ 48.095396] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
[swapper/0:1]
Reverting this commit makes them all happy again.
Kevin
--
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 2/5] clk: Introduce 'clk_round_rate_nearest()'
On Thu, 2014-05-22 at 02:03PM -0700, Mike Turquette wrote:
> Quoting Sören Brinkmann (2014-05-22 13:32:09)
> > On Thu, 2014-05-22 at 08:20PM +0200, Uwe Kleine-König wrote:
> > > Hello Sören,
> > >
> > > On Thu, May 22, 2014 at 11:03:00AM -0700, Sören Brinkmann wrote:
> > > > On Wed, 2014-05-21 at 01:33PM -0700, Mike Turquette wrote:
> > > > > Quoting Uwe Kleine-König (2014-05-21 11:23:08)
> > > > > > Hello Sören,
> > > > > >
> > > > > > On Wed, May 21, 2014 at 08:58:10AM -0700, Sören Brinkmann wrote:
> > > > > > > On Wed, 2014-05-21 at 09:34AM +0200, Uwe Kleine-König wrote:
> > > > > > > > On Tue, May 20, 2014 at 02:48:20PM -0700, Sören Brinkmann wrote:
> > > > > > > > > On Tue, 2014-05-20 at 10:48AM -0700, Stephen Boyd wrote:
> > > > > > > > > > On 05/20/14 09:01, Sören Brinkmann wrote:
> > > > > > > > > > >
> > > > > > > > > > > +{
> > > > > > > > > > > + unsigned long lower, upper, cur, lower_last,
> > > > > > > > > > > upper_last;
> > > > > > > > > > > +
> > > > > > > > > > > + lower = clk_round_rate(clk, rate);
> > > > > > > > > > > + if (lower >= rate)
> > > > > > > > > > > + return lower;
> > > > > > > > > > Is the >-case worth a warning?
> > > > > > > > > > >>> No, it's correct behavior. If you request a rate that
> > > > > > > > > > >>> is way lower than what the
> > > > > > > > > > >>> clock can generate, returning something larger is
> > > > > > > > > > >>> perfectly valid, IMHO.
> > > > > > > > > > >>> Which reveals one problem in this whole discussion. The
> > > > > > > > > > >>> API does not
> > > > > > > > > > >>> require clk_round_rate() to round down. It is actually
> > > > > > > > > > >>> an implementation
> > > > > > > > > > >>> choice that had been made for clk-divider.
> > > > > > > > > > >> I'm sure it's more than an implementation choice for
> > > > > > > > > > >> clk-divider. But I
> > > > > > > > > > >> don't find any respective documentation (but I didn't
> > > > > > > > > > >> try hard).
> > > > > > > > > > > A similar discussion - without final conclusion:
> > > > > > > > > > > https://lkml.org/lkml/2010/7/14/260
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Please call this new API something like
> > > > > > > > > > clk_find_nearest_rate() or
> > > > > > > > > > something. clk_round_rate() is supposed to return the rate
> > > > > > > > > > that will be
> > > > > > > > > > set if you call clk_set_rate() with the same arguments.
> > > > > > > > > > It's up to the
> > > > > > > > > > implementation to decide if that means rounding the rate up
> > > > > > > > > > or down or
> > > > > > > > > > to the nearest value.
> > > > > > > > >
> > > > > > > > > Sounds good to me. Are there any cases of clocks that round
> > > > > > > > > up? I think
> > > > > > > > > that case would not be handled correctly. But I also don't
> > > > > > > > > see a use
> > > > > > > > > case for such an implementation.
> > > > > > > > I don't really care which semantic (i.e. round up, round down
> > > > > > > > or round
> > > > > > > > closest) is picked, but I'd vote that all should pick up the
> > > > > > > > same. I
> > > > > > > > think the least surprising definition is to choose rounding
> > > > > > > > down and add
> > > > > > > > the function that is under discussion here to get a nearest
> > > > > > > > match.
> > > > > > > >
> > > > > > > > So I suggest:
> > > > > > > >
> > > > > > > > - if round_rate is given a rate that is smaller than the
> > > > > > > > smallest available rate, return 0
> > > > > > > > - add WARN_ONCE to round_rate and set_rate if they return
> > > > > > > > with a
> > > > > > > > rate bigger than requested
> > > > > > >
> > > > > > > Why do you think 0 is always valid? I think for a clock that can
> > > > > > > generate 40, 70, 120, clk_round_rate(20) should return 40.
> > > > > > I didn't say it's a valid value. It just makes the it possible to
> > > > > > check
> > > > > > for clk_round_rate(clk, rate) <= rate.
> > > > > >
> > > > > > I grepped a bit around and found da850_round_armrate which
> > > > > > implements a
> > > > > > round_rate callback returning the best match.
> > > > > > omap1_clk_round_rate_ckctl_arm can return a value < 0.
> > > > > > s3c2412_roundrate_usbsrc can return values that are bigger than
> > > > > > requested. (I wonder if that is a bug though.)
> > > > > >
> > > > > > > > - change the return values to unsigned long
> > > > > > >
> > > > > > > Yep, I agree, this should happen.
> > > > > > And we're using 0 as error value? e.g. for the case where
> > > > > > omap1_clk_round_rate_ckctl_arm returns -EIO now?
> > > > >
> > > > > No. clk_round_rate returns long for a reason, which is that we can
> > > > > provide an error code to the caller. From include/linux/clk.h:
> > > > >
> > > > > /**
> > > > > * clk_round_rate - adjust a rate to the exact rate a clock can
> > > > > provide
> > > > > * @clk: clock source
> > > >
Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h
On 5/22/2014 3:20 PM, Bjorn Helgaas wrote: On Thu, May 22, 2014 at 1:17 PM, Borislav Petkov wrote: On Thu, May 22, 2014 at 11:56:03AM -0600, Bjorn Helgaas wrote: I chose Fam16h (0x16) because it looks like that's the newest stuff that's in the field. I suspect things would probably work if we changed this patch to leave ECS disabled on some Fam16h, Fam15h, etc., but that would change behavior on existing systems, which obviously adds some risk. I didn't think there was much benefit that makes the risk worthwhile. My goal is to stop needing CPU-specific changes in the future, not necessarily to remove the CPU-specific code we already have. Does that make sense? I'm not sure whether I understood your real question. No, you got it right. I'm just wondering why only the newest stuff. MMCONFIG is supposed to work just fine on everything from Fam10h onwards, I'm not sure all Fam10h supported it though. Maybe Suravee can verify that... Even if MMCONFIG does work fine on everything from Fam10h onwards, we still depend on the BIOS to provide a correct MCFG table. I don't think we can guarantee that changing from ECS to MMCONFIG on a Fam16h box in the field is safe, because we'd then be using a feature we've never used before. Bjorn At this point, family11h and later (upto 16h which is our most current processor) should already have supports for the MCFG. However, we can't guarantee that all the systems currently out there would not use the ECS. So, I think it is ok to say we won't support it post 16h as Bjorn suggests. Suravee -- 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] dt/sparc: Introduce the use of the managed version of kzalloc
On Fri, 23 May 2014, Julia Lawall wrote: > > > On Thu, 22 May 2014, Dmitry Torokhov wrote: > > > Hi Himangi, > > > > On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote: > > > This patch moves data allocated using kzalloc to managed data allocated > > > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove > > > functions. Also the unnecessary labels are done away with. > > > > Please no more partial devm conversions. I am not interested in patches > > that change only 1 resource to be managed and leaving the rest as is. > > > > If you want to do devm conversion please do it if you convert all (or at > > least majority) of resource handling to managed resources. > > Sorry, I don't think we are clear on what is wanted. Himangi's patches > convert everything where a devm function is already available (to our > knowledge). Do you prefer that new devm functions be introduced? On the > one hand, that is perhaps useful from a safety point of view. On the > other hand, it could lead to a huge number of rarely used devm functions > that no one knows about and to a lot of code diversity. So I don't know > what is the good solution. I guess that the concrete problem is of_ioremap? Since that is a pretty common function, I guess it could be reasonable to introduce a devm function for it as well. Or maybe one already exists and we overlooked it. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ASoC: max98090: Add master clock handling
On Thu, May 22, 2014 at 04:24:55PM -0600, Stephen Warren wrote: > My main worry is that this patch opens the door for set_sysclk() to > perform some kind of calculation to determine the MCLK rate. Right now, > this patch doesn't do that, but there's nothing obvious from the code > that no CODEC is allowed to do that. After all, sysclk has a parameter > to indicate *which* clock in the CODEC to set. Some CODEC driver author > might write something where the machine driver tells the CODEC driver > the desired rate of some CODEC-internal PLL, from which set_sysclk() > calculates what it needs for MCLK, and then goes off and requests that > value from the clock API. I really think you're reading too much into this - the set_sysclk() API isn't any different to the clock API here really and most of the potential for doing really problematic stuff and defining your clocks to mean funny things exists anyway. Of course people could do tasteless things but that's always going to be a risk and we also want to try to minimise the amount of redundant code people have to write. It should be fairly easy to spot substantial abuse since the driver would need to call clk_set_rate() with a different rate. > Ignoring that, I'm still not sure that the CODEC driver setting the MCLK > rate is appropriate. If we have 1 MCLK output from an SoC, connected to > 2 different CODECs, why wouldn't the overall machine driver call > clk_set_rate() on that clock, and then notify the two CODEC drivers of > that rate. Making each CODEC's set_sysclk() call clk_set_rate() on the > same clock with the same value seems redundant, albeit it should work > out fine since they both request the same rate. Right, it should work fine and it's less work for the machine drivers. The alternative is that every machine driver using a device with a programmable input has the code to get that clock from the CODEC device and set it in sync with telling the CODEC about it which is redundant and makes life harder for generic drivers like simple card (which obviously can't know the specifics of every CODEC it works with). It's certainly a more normal thing from a device model and device tree point of view for the CODEC to be responsible for getting the resource and it seems natural to extend that to such basic management as setting the rate. If anything I think want to expose some or all of the CODEC clock trees to the clock API, sometimes (rarely but not never) the CODEC PLLs and FLLs are used to supply things outside the audio subsystem if they happen to be going spare, it's difficult to do that at the minute since there's no guaranteed API for being a clock provider. At the minute we're mostly reimplementing a custom clock API which seems like the wrong way to be doing things. That might go towards answering your concerns since set_sysclk() would end up as a clock API call (or at least a thin wrapper around one). signature.asc Description: Digital signature
PRIVATE MESSAGE
My late client made his last will and testament in your favour, i sent letters to you but got no response, i advise you contact me immediately. Barr Mark Freedman -- 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] bus: omap_l3_noc.c: use devm functions
This uses devm function to ease mem alloc
Signed-off-by: abdoulaye berthe
---
drivers/bus/omap_l3_noc.c | 73 +++
1 file changed, 17 insertions(+), 56 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae..e8bcc8f 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -133,53 +133,28 @@ static int omap4_l3_probe(struct platform_device *pdev)
static struct omap4_l3 *l3;
struct resource *res;
int ret;
+ struct device *dev = >dev;
- l3 = kzalloc(sizeof(*l3), GFP_KERNEL);
+ l3 = devm_kzalloc(dev, sizeof(struct omap4_l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
platform_set_drvdata(pdev, l3);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(>dev, "couldn't find resource 0\n");
- ret = -ENODEV;
- goto err0;
- }
- l3->l3_base[0] = ioremap(res->start, resource_size(res));
- if (!l3->l3_base[0]) {
- dev_err(>dev, "ioremap failed\n");
- ret = -ENOMEM;
- goto err0;
- }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ l3->l3_base[0] = devm_ioremap(dev, res->start, resource_size(res));
+ if (IS_ERR(l3->l3_base[0]))
+ return PTR_ERR(l3->l3_base[0]);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res) {
- dev_err(>dev, "couldn't find resource 1\n");
- ret = -ENODEV;
- goto err1;
- }
-
- l3->l3_base[1] = ioremap(res->start, resource_size(res));
- if (!l3->l3_base[1]) {
- dev_err(>dev, "ioremap failed\n");
- ret = -ENOMEM;
- goto err1;
- }
+ l3->l3_base[1] = devm_ioremap(dev, res->start, resource_size(res));
+ if (IS_ERR(l3->l3_base[1]))
+ return PTR_ERR(l3->l3_base[1]);
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- if (!res) {
- dev_err(>dev, "couldn't find resource 2\n");
- ret = -ENODEV;
- goto err2;
- }
-
- l3->l3_base[2] = ioremap(res->start, resource_size(res));
- if (!l3->l3_base[2]) {
- dev_err(>dev, "ioremap failed\n");
- ret = -ENOMEM;
- goto err2;
- }
+ l3->l3_base[2] = devm_ioremap(dev, res->start, resource_size(res));
+ if (IS_ERR(l3->l3_base[2]))
+ return PTR_ERR(l3->l3_base[2]);
/*
* Setup interrupt Handlers
@@ -191,7 +166,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
- goto err3;
+ free_irq(l3->debug_irq, l3);
+ return ret;
}
l3->app_irq = platform_get_irq(pdev, 1);
@@ -201,22 +177,11 @@ static int omap4_l3_probe(struct platform_device *pdev)
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->app_irq);
- goto err4;
+ free_irq(l3->app_irq, l3);
+ free_irq(l3->debug_irq, l3);
+ return ret;
}
-
return 0;
-
-err4:
- free_irq(l3->debug_irq, l3);
-err3:
- iounmap(l3->l3_base[2]);
-err2:
- iounmap(l3->l3_base[1]);
-err1:
- iounmap(l3->l3_base[0]);
-err0:
- kfree(l3);
- return ret;
}
static int omap4_l3_remove(struct platform_device *pdev)
@@ -225,10 +190,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
free_irq(l3->app_irq, l3);
free_irq(l3->debug_irq, l3);
- iounmap(l3->l3_base[0]);
- iounmap(l3->l3_base[1]);
- iounmap(l3->l3_base[2]);
- kfree(l3);
return 0;
}
--
1.8.3.2
--
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/
