linux-next: manual merge of the arm-soc tree with the arm-current tree
Hi all, Today's linux-next merge of the arm-soc tree got a conflict in arch/arm/mm/mmu.c between commit a849088aa155 (ARM: Fix ioremap() of address zero) from the arm-current tree and commit c2794437091a (ARM: Add fixed PCI i/o mapping) from the arm-soc tree. I am not sure how to fix this, so I have used the arm-current version of the change to pmd_empty_section_gap() since that changed the vm-flags. It may be that just changing the vm-flags value in vm_reserve_area_early() would be ok? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLvXWgv5xQ8.pgp Description: PGP signature
Re: [ext3/4] PROBLEM: fdatasync not syncing appended data (w/test program)
Jan Kara j...@suse.cz writes: On Mon 03-09-12 10:45:15, Kristian Nielsen wrote: It appears that ext3 and ext4 fdatasync() does not fully sync data to disk. Specifically, when new data is written at the end (so that the file length is increased), not all of the new data is synced by fdatasync(). The culprit is that we forget to update i_datasync_tid when we change only inode size. Thus inode is not forced to disk during fdatasync(). I will send fixes for this in a moment. Cool, thanks for the quick response! Glad that we get this fixed. - Kristian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [ASoC] Fix: Revert 'ASoC: imx-ssi: Remove mono support'.
Hi Javier,
On 09/03/2012 10:27 AM, Javier Martin wrote:
The following commit should be reverted:
0865a75d4166bddc533fd50831829ceefb94f9b0
The bug this patch is meant to solve doesn't occur in Visstrim_M10 boards.
Furthermore, after applying this patch sound in Visstrim_M10 is played
at slower rates.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
diff --git b/sound/soc/fsl/imx-ssi.c a/sound/soc/fsl/imx-ssi.c
index ac337ac..28dd76c 100644
--- b/sound/soc/fsl/imx-ssi.c
+++ a/sound/soc/fsl/imx-ssi.c
@@ -380,13 +380,13 @@ static int imx_ssi_dai_probe(struct snd_soc_dai *dai)
static struct snd_soc_dai_driver imx_ssi_dai = {
.probe = imx_ssi_dai_probe,
.playback = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
When applied on linux-next-20120824, the patch failed because original
imx-ssi.c file looks like :
static struct snd_soc_dai_driver imx_ssi_dai = {
.probe = imx_ssi_dai_probe,
.playback = {
/* The SSI does not support monaural audio. */
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.ops = imx_ssi_pcm_dai_ops,
};
The comment line is missing in your patch. Here is the right patch :
@@ -378,18 +378,17 @@ static int imx_ssi_dai_probe(struct snd_soc_dai *dai)
}
static struct snd_soc_dai_driver imx_ssi_dai = {
.probe = imx_ssi_dai_probe,
.playback = {
- /* The SSI does not support monaural audio. */
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.ops = imx_ssi_pcm_dai_ops,
Regards,
Gaëtan Carlier.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] dw_dmac: max_mem_width limits value for SRC/DST_TR_WID register
On Mon, Sep 3, 2012 at 4:06 PM, Hein Tibosch hein_tibo...@yahoo.es wrote: 1. The first draft of the patches worked with the max allowable value for the SRC_WIDTH DST_WIDTH fields: 0,1,2,3... Viresh thought it was not transparent enough, he suggested to make it simpler with a binary choice of 32- or 64-bits, defaulting to 64-bits. But Andy is right: there are versions supporting 256-bit wide memory transfers. I'd also go for this previous solution and use: min(max_mem_width, width) The only problem is that one doesn't want to change arch code for other platforms (ARM) so I proposed: let max_mem_width=0 mean: leave it up to the driver, for now 3 : 64-bits. Sounds better to support all possible options without any additional layer of conversion, isn't it? 2. In another version I made 'max_mem_width' a member of 'dw_dma_platform_data' because I also see it as 'constant' for all dma slaves. But the dw_dmac controller can be used for multiple (types of) memories and in that case, maybe a limit per slave might be desirable? My knowledge of DMA-hardware doesn't reach far enough to judge that. As Viresh told early that will not cover memory-to-memory transfers. I'd say: for now let it become a member of 'dw_dma_platform_data' because it's the max value of a register field. I support such choice. 3. Felipe Balbi: why don't we ask the DW IP for its maximum allowed value of SRC_WIDTH DST_WIDTH (on the memory side)? Sure, would be elegant! It's not so simple, unfortunately. Alternatively, we could do a small dma-memcpy-test at start-up and try all values from 5 (or 7) down to 2. The first value that works correctly will be used as the maximum. Oh, it might be good idea to get this value in case neither IP nor platform data provides it. I'm pretty sure the platform device driver has to know this beforehand. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warnings after merge of the drm tree
On Tue, Sep 4, 2012 at 5:58 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Dave,
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
dependencies (USB_SUPPORT USB_OHCI_HCD)
warning: (PPC_PS3 PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which has
unmet direct dependencies (USB_SUPPORT USB_OHCI_HCD)
warning: (PPC_PS3 PPC_CELLEB USB_EHCI_HCD_PMC_MSP XPS_USB_HCD_XILINX
USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct
dependencies (USB_SUPPORT USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX
|| ARCH_IXP4XX || XPS_USB_HCD_XILINX || PPC_MPC512x || CPU_CAVIUM_OCTEON ||
PMC_MSP || SPARC_LEON || MIPS_SEAD3))
The x86_64 allmodconfig produces these:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (MOUSE_APPLETOUCH MOUSE_BCM5974 MOUSE_SYNAPTICS_USB
JOYSTICK_XPAD TABLET_USB_ACECAD TABLET_USB_AIPTEK TABLET_USB_HANWANG
TABLET_USB_KBTAB TABLET_USB_WACOM TOUCHSCREEN_USB_COMPOSITE
INPUT_ATI_REMOTE2 INPUT_KEYSPAN_REMOTE INPUT_POWERMATE INPUT_YEALINK
INPUT_CM109 RC_ATI_REMOTE IR_IMON IR_MCEUSB IR_REDRAT3
IR_STREAMZAP IR_IGUANA IR_TTUSBIR DRM_USB) selects USB which has
unmet direct dependencies (USB_SUPPORT USB_ARCH_HAS_HCD)
Maybe introduced by commit df0b34430072 (drm/usb: select USB_SUPPORT in
Kconfig), maybe interacting with a commit 8f057d7bca54 (gpu/mfd/usb:
Fix USB randconfig problems) from Linus' tree (that added depends on
USB_ARCH_HAS_HCD to config DRM_USB and config DRM_UDL).
I have left this mess for now, but it needs addressing.
I have sent a fix (drm/udl: usb: Fix recursive Kconfig dependency)
for this mess and pinged airlied on IRC.
NOTE: I saw this when I merged drm(-intel){-fixes,next} into next-20120824.
- Sedat -
[1] https://patchwork.kernel.org/patch/1373391/
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] virtio-scsi: introduce multiqueue support
Il 04/09/2012 04:21, Nicholas A. Bellinger ha scritto:
@@ -112,6 +118,9 @@ static void virtscsi_complete_cmd(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_cmd *cmd = buf;
struct scsi_cmnd *sc = cmd-sc;
struct virtio_scsi_cmd_resp *resp = cmd-resp.cmd;
+struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+
+atomic_dec(tgt-reqs);
As tgt-tgt_lock is taken in virtscsi_queuecommand_multi() before the
atomic_inc_return(tgt-reqs) check, it seems like using atomic_dec() w/o
smp_mb__after_atomic_dec or tgt_lock access here is not using atomic.h
accessors properly, no..?
No, only a single thing is being accessed, and there is no need to
order the decrement with respect to preceding or subsequent accesses to
other locations.
In other words, tgt-reqs is already synchronized with itself, and that
is enough.
(Besides, on x86 smp_mb__after_atomic_dec is a nop).
+static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+struct virtio_scsi *vscsi = shost_priv(sh);
+struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+unsigned long flags;
+u32 queue_num;
+
+/* Using an atomic_t for tgt-reqs lets the virtqueue handler
+ * decrement it without taking the spinlock.
+ */
+spin_lock_irqsave(tgt-tgt_lock, flags);
+if (atomic_inc_return(tgt-reqs) == 1) {
+queue_num = smp_processor_id();
+while (unlikely(queue_num = vscsi-num_queues))
+queue_num -= vscsi-num_queues;
+tgt-req_vq = vscsi-req_vqs[queue_num];
+}
+spin_unlock_irqrestore(tgt-tgt_lock, flags);
+return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
The extra memory barriers to get this right for the current approach are
just going to slow things down even more for virtio-scsi-mq..
virtio-scsi multiqueue has a performance benefit up to 20% (for a single
LUN) or 40% (on overall bandwidth across multiple LUNs). I doubt that a
single memory barrier can have that much impact. :)
The way to go to improve performance even more is to add new virtio APIs
for finer control of the usage of the ring. These should let us avoid
copying the sg list and almost get rid of the tgt_lock; even though the
locking is quite efficient in virtio-scsi (see how tgt_lock and vq_lock
are pipelined so as to overlap the preparation of two requests), it
should give a nice improvement and especially avoid a kmalloc with small
requests. I may have some time for it next month.
Jen's approach is what we will ultimately need to re-architect in SCSI
core if we're ever going to move beyond the issues of legacy host_lock,
so I'm wondering if maybe this is the direction that virtio-scsi-mq
needs to go in as well..?
We can see after the block layer multiqueue work goes in... I also need
to look more closely at Jens's changes.
Have you measured the host_lock to be a bottleneck in high-iops
benchmarks, even for a modern driver that does not hold it in
queuecommand? (Certainly it will become more important as the
virtio-scsi queuecommand becomes thinner and thinner). If so, we can
start looking at limiting host_lock usage in the fast path.
BTW, supporting this in tcm-vhost should be quite trivial, as all the
request queues are the same and all serialization is done in the
virtio-scsi driver.
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] UBI fix for v3.6-rc5
The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) are available in the git repository at: git://git.infradead.org/linux-ubi.git tags/upstream-3.6-rc5 for you to fetch changes up to 78b495c39add820ab66ab897af9bd77a5f2e91f6: UBI: fix a horrible memory deallocation bug (2012-09-04 09:40:26 +0300) A single small fix for memory deallocation: we allocated memory using 'kmem_cache_alloc()' but were freeing it using 'kfree()' in some cases. Now we fix this by using 'kmem_cache_free()' instead. Artem Bityutskiy (1): UBI: fix a horrible memory deallocation bug drivers/mtd/ubi/vtbl.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [v2 1/1] iommu/tegra: smmu: Use debugfs_create_dir for directory
Stephen Warren swar...@wwwdotorg.org wrote @ Wed, 15 Aug 2012 18:13:18 +0200: On 08/14/2012 11:47 PM, Hiroshi Doyu wrote: The commit c3b1a35 debugfs: make sure that debugfs_create_file() gets used only for regulars doesn't allow to use debugfs_create_file() for dir. Keep debugfs data in smmu_device instead of directory's i_private. Signed-off-by: Hiroshi Doyu hd...@nvidia.com Tested-by: Stephen Warren swar...@wwwdotorg.org Since this fixes a BUG during kernel boot, it'd be great if this could be applied ASAP unless there are significant issues with it. Joerg, any chance to get this in? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 final tree (net-next tree related)
Hi , After merging the final tree, today's linux-next build (powerpc ppc44x_defconfig) failed like this: net/built-in.o: In function `tcp_fastopen_ctx_free': tcp_fastopen.c:(.text+0x5cc5c): undefined reference to `crypto_destroy_tfm' net/built-in.o: In function `tcp_fastopen_reset_cipher': (.text+0x5): undefined reference to `crypto_alloc_base' net/built-in.o: In function `tcp_fastopen_reset_cipher': (.text+0x5cd6c): undefined reference to `crypto_destroy_tfm' Presumably caused by commit 104671636897 (tcp: TCP Fast Open Server - header support functions) from the net-next tree. I assume that some dependency on the CRYPTO infrastructure is missing. I have reverted commit 1bed966cc3bd (Merge branch 'tcp_fastopen_server') for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLUpOujdrI8.pgp Description: PGP signature
Re: need help on development of linux kernel
On 08/30/2012 12:15 PM, Sachin Agarwalla wrote: Dear Sir/Madam, I have some questions on development of linux kernel as follows:- 1.I want to know the location of files in linux kernel source code that contains timer initialization and scheduler part. Scheduler source code is in kernel/sched/* files. 2.Also I want to know location of header files(or library files) that are present in the above files. include/linux/sched.h 3.Is there any version of linux kernel that uses openmp or inteltbb or parallelc tool. No, kernel doesn't use any libraries including libc. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/3] leds-lp5523: add new device id for LP55231
To support LP55231 device, the device id is added.
Additionally, the i2c driver name is changed from lp5523 to lp5523x.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/leds-lp5523.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 80d3792..e69e72a 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -104,6 +104,11 @@
#define LED_ACTIVE(mux, led) (!!(mux (0x0001 led)))
#define SHIFT_MASK(id) (((id) - 1) * 2)
+enum lp5523_chip_id {
+ LP5523,
+ LP55231,
+};
+
struct lp5523_engine {
int id;
u8 mode;
@@ -1005,7 +1010,8 @@ static int lp5523_remove(struct i2c_client *client)
}
static const struct i2c_device_id lp5523_id[] = {
- { lp5523, 0 },
+ { lp5523, LP5523 },
+ { lp55231, LP55231 },
{ }
};
@@ -1013,7 +1019,7 @@ MODULE_DEVICE_TABLE(i2c, lp5523_id);
static struct i2c_driver lp5523_driver = {
.driver = {
- .name = lp5523,
+ .name = lp5523x,
},
.probe = lp5523_probe,
.remove = lp5523_remove,
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/3] leds-lp5523: support new LP55231 device
New TI LP55231 device has same I2C register layout as LP5523. Therefore, all of LED operations can be shared with the LP5523 driver. To support new LP55231 device explicitly, the device description is added in the configuration file. Signed-off-by: Milo(Woogyom) Kim milo@ti.com --- drivers/leds/Kconfig |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 16578d3..0bc80bd 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -192,11 +192,12 @@ config LEDS_LP5521 programming the engines. config LEDS_LP5523 - tristate LED Support for N.S. LP5523 LED driver chip + tristate LED Support for TI/National LP5523/55231 LED driver chip depends on LEDS_CLASS I2C help - If you say yes here you get support for the National Semiconductor - LP5523 LED driver. It is 9 channel chip with programmable engines. + If you say yes here you get support for TI/National Semiconductor + LP5523/55231 LED driver. + It is 9 channel chip with programmable engines. Driver provides direct control via LED class and interface for programming the engines. -- 1.7.9.5 Best Regards, Milo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] leds-lp5523: use the i2c device id rather than fixed name
LP5523 driver supports both LP5523 and LP55231.
The i2c device id is one of the two - lp5523 or lp55231.
So it's better to use matching i2c device id while enumerating the device
and naming LED channels.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/leds-lp5523.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index e69e72a..3d60428 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -833,7 +833,8 @@ static int __init lp5523_init_engine(struct lp5523_engine
*engine, int id)
}
static int __devinit lp5523_init_led(struct lp5523_led *led, struct device
*dev,
- int chan, struct lp5523_platform_data *pdata)
+ int chan, struct lp5523_platform_data *pdata,
+ const char *chip_name)
{
char name[32];
int res;
@@ -856,7 +857,7 @@ static int __devinit lp5523_init_led(struct lp5523_led
*led, struct device *dev,
led-cdev.name = pdata-led_config[chan].name;
} else {
snprintf(name, sizeof(name), %s:channel%d,
- pdata-label ?: lp5523, chan);
+ pdata-label ? : chip_name, chan);
led-cdev.name = name;
}
@@ -927,7 +928,7 @@ static int __devinit lp5523_probe(struct i2c_client *client,
if (ret)
goto fail1;
- dev_info(client-dev, LP5523 Programmable led chip found\n);
+ dev_info(client-dev, %s Programmable led chip found\n, id-name);
/* Initialize engines */
for (i = 0; i ARRAY_SIZE(chip-engines); i++) {
@@ -955,7 +956,8 @@ static int __devinit lp5523_probe(struct i2c_client *client,
INIT_WORK(chip-leds[led].brightness_work,
lp5523_led_brightness_work);
- ret = lp5523_init_led(chip-leds[led], client-dev, i, pdata);
+ ret = lp5523_init_led(chip-leds[led], client-dev, i, pdata,
+ id-name);
if (ret) {
dev_err(client-dev, error initializing leds\n);
goto fail2;
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 can-next v6] can: add tx/rx LED trigger support
On Mon, Sep 03, 2012 at 10:54:49PM +0200, Oliver Hartkopp wrote: On 03.09.2012 20:29, Fabio Baltieri wrote: On Mon, Sep 03, 2012 at 08:13:35PM +0200, Kurt Van Dijck wrote: On Mon, Sep 03, 2012 at 02:40:39PM +0200, Marc Kleine-Budde wrote: The net-ifindex is unique. But it's only an integer. Usually can0 has a ifindex != 0, so a simple can%d is contra productive here. Some pointers to related code: http://lxr.free-electrons.com/source/drivers/base/core.c#L1847 http://lxr.free-electrons.com/source/drivers/base/core.c#L73 http://lxr.free-electrons.com/source/include/linux/device.h#L695 comments? That would probabily makes really hard to choose the right default_trigger for led devices to get to the appropriate CAN LED in embedded systems, as trigger name would depend from other network devices and probing order (correct me if I'm wrong). Something with device name would probaily be more appropriate here. a very recent idea: something with netdevice notifiers and NETDEV_CHANGENAME ... http://lxr.free-electrons.com/source/net/core/dev.c#L1030 you could: rename the trigger, or if we think it's usefull, block the netdev rename when its triggers are in use. Blocking the rename looks overkill to me, renaming a netdev _after_ first attaching led triggers looks stupid to me anyway. what about using device name with an optional port id appended to it? Sounds simpler... The name of the device can only be changed when the interface is down. Is it possible to put some scripting around it to detach and attach the leds to the interfaces on ifup/ifdown triggers? Are the led triggers available for using while the netdev is down then? Kurt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sept 4
Hi all, Changes since 20120824: The pci tree gained conflicts against Linus' tree. The v4l-dvb tree gained a conflict against the arm tree. The ubi tree lost its build failure. The scsi tree lost its conflict. The drm tree lost its build failure and conflicts. The sound tree lost its build failure. The net-next tree gained a build failure for which I reverted a merge (3 commits). The rcu tree lost a conflict. The kvm tree lost its build failure. The kvm-ppc tree gained a conflict against the kvm tree. The char-misc tree lost its conflict. The arm-soc tree gained a conflict against the arm-current tree. I have gone back to using the signal tree as supplied by the maintiner. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 196 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (5b716ac Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (6c7080a firmware: fix directory creation rule matching with make 3.82) Merging arm-current/fixes (36418c5 ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM) Merging m68k-current/for-linus (3be7184 m68k: Add missing RCU idle APIs on idle loop) Merging powerpc-merge/merge (2c39bf4 Revert powerpc: Update g5_defconfig) Merging sparc/master (6dab7ed Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm) Merging net/master (9fef768 mISDN: fix possible memory leak in hfcmulti_init()) Merging sound-current/for-linus (2e4a263 ALSA: snd-usb: fix cross-interface streaming devices) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (c6b6eed Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (fea7a08 Linux 3.6-rc3) Merging tty.current/tty-linus (fea7a08 Linux 3.6-rc3) Merging usb.current/usb-linus (fea7a08 Linux 3.6-rc3) Merging staging.current/staging-linus (fea7a08 Linux 3.6-rc3) Merging char-misc.current/char-misc-linus (fea7a08 Linux 3.6-rc3) Merging input-current/for-linus (6f4d038 Input: wacom - add support for EMR on Cintiq 24HD touch) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (ce026cb crypto: caam - fix possible deadlock condition) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper spi: modalias prefixes.) Merging gpio-current/gpio/merge (96b7064
Re: linux-next: manual merge of the pci tree with Linus' tree
Today's linux-next merge of the pci tree got a conflict in drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit 8eee694c3e66 (bnx2x: fix unload previous driver flow when flr-capable) from Linus' tree and commit 2a80eebcbf3e (bnx2x: Use PCI Express Capability accessors) from the pci tree. The former removes the function updated by the latter, so I just removed the function (see below) and can carry the fix as necessary. Acked-by: Yuval Mintz yuval...@broadcom.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: Use DEFINE_PCI_DEVICE_TABLE macro
On Sun, Sep 2, 2012 at 2:04 AM, Axel Lin axel@gmail.com wrote: Signed-off-by: Axel Lin axel@gmail.com Applied, thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] gpio: adp5588: Use module_i2c_driver
On Sun, Sep 2, 2012 at 2:08 AM, Axel Lin axel@gmail.com wrote: Signed-off-by: Axel Lin axel@gmail.com Applied, thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] Revert spi/doc: spi_master_put must be followed up by kfree
On Mon, Sep 03, 2012 at 01:26:26PM -0700, Guenter Roeck wrote:
Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
by kfree(). The memory is already freed with the call to spi_master_put()
through spi_master_class, which registers a release function. Calling both
spi_master_put() and kfree() results in often nasty (and delayed) crashes
elsewhere in the kernel, often in the networking stack.
This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.
Cc: Uwe Kleine-Koenig u.kleine-koe...@pengutronix.de
Signed-off-by: Guenter Roeck li...@roeck-us.net
I didn't check the callback, but I introduced
eb4af0f5349235df2e4a5057a72fc8962d00308a because I saw the kfree in
drivers/spi/spi-imx.c. So I guess this needs fixing, too?!
Best regards
Uwe
---
drivers/spi/spi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 2d9b5bb..6470750 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1082,8 +1082,7 @@ static struct class spi_master_class = {
*
* The caller is responsible for assigning the bus number and initializing
* the master's methods before calling spi_register_master(); and (after
errors
- * adding the device) calling spi_master_put() and kfree() to prevent a
memory
- * leak.
+ * adding the device) calling spi_master_put() to prevent a memory leak.
*/
struct spi_master *spi_alloc_master(struct device *dev, unsigned size)
{
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] gpio: wm831x: Convert to use devm_kzalloc API
On Sun, Sep 2, 2012 at 5:58 AM, Axel Lin axel@gmail.com wrote: Signed-off-by: Axel Lin axel@gmail.com Applied, thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio: wm8350: Convert to use devm_kzalloc API
On Sun, Sep 2, 2012 at 5:58 AM, Axel Lin axel@gmail.com wrote: Signed-off-by: Axel Lin axel@gmail.com Applied, thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: RCU warning during UBI file system mount
Let's CC LKML and Paul. On Sat, 2012-09-01 at 22:19 -0700, Subodh Nijsure wrote: Hello, I am running 3.6-rc4 kernel on my MX28 based board and every time I mount UBI file system I see following warning. Anybody else seen this errors, particularly those running it on MXS platform? I haven't debugged RCU warnings before any clues as to what is the source of this warning is, should I be looking at start_dma_without_bch_irq() code? Would appreciate any pointers in fixing this... [4.28] WARNING: at /opt/git/kernel-mainline/kernel/rcutiny.c:75 rcu_idle_enter_common.clone.7+0x90/0xac() [4.28] Current pid: 1 comm: swapper / Idle pid: 0 comm: swapper [4.28] Modules linked in: [4.28] [c0014eec] (unwind_backtrace+0x0/0x130) from [c001dd94] (warn_slowpath_common+0x4c/0x64) [4.28] [c001dd94] (warn_slowpath_common+0x4c/0x64) from [c001de40] (warn_slowpath_fmt+0x30/0x40) [4.28] [c001de40] (warn_slowpath_fmt+0x30/0x40) from [c0061618] (rcu_idle_enter_common.clone.7+0x90/0xac) [4.28] [c0061618] (rcu_idle_enter_common.clone.7+0x90/0xac) from [c0061670] (rcu_irq_exit+0x3c/0x78) [4.28] [c0061670] (rcu_irq_exit+0x3c/0x78) from [c000fe90] (handle_IRQ+0x34/0x84) [4.28] [c000fe90] (handle_IRQ+0x34/0x84) from [c000ec34] (__irq_svc+0x34/0x58) [4.28] [c000ec34] (__irq_svc+0x34/0x58) from [c0394c4c] (schedule_timeout+0xdc/0x16c) [4.28] [c0394c4c] (schedule_timeout+0xdc/0x16c) from [c0395f34] (wait_for_common+0xb4/0x160) [4.28] [c0395f34] (wait_for_common+0xb4/0x160) from [c02579d0] (start_dma_without_bch_irq+0x6c/0xa8) [4.28] [c02579d0] (start_dma_without_bch_irq+0x6c/0xa8) from [c0258660] (gpmi_send_command+0x120/0x154) [4.28] [c0258660] (gpmi_send_command+0x120/0x154) from [c0256fb4] (gpmi_cmd_ctrl+0x44/0x6c) [4.28] [c0256fb4] (gpmi_cmd_ctrl+0x44/0x6c) from [c024f8e0] (nand_command_lp+0xe8/0x270) [4.28] [c024f8e0] (nand_command_lp+0xe8/0x270) from [c0251e00] (nand_do_read_ops+0x124/0x444) [4.28] [c0251e00] (nand_do_read_ops+0x124/0x444) from [c0252558] (nand_read+0x54/0x78) [4.28] [c0252558] (nand_read+0x54/0x78) from [c02499a4] (part_read+0x48/0x80) [4.28] [c02499a4] (part_read+0x48/0x80) from [c0246910] (mtd_read+0x88/0xb4) [4.28] [c0246910] (mtd_read+0x88/0xb4) from [c026b188] (ubi_io_read+0xb0/0x3e8) [4.28] [c026b188] (ubi_io_read+0xb0/0x3e8) from [c026740c] (ubi_eba_read_leb+0x198/0x4bc) [4.28] [c026740c] (ubi_eba_read_leb+0x198/0x4bc) from [c0266800] (ubi_leb_read+0xf4/0x16c) [4.28] [c0266800] (ubi_leb_read+0xf4/0x16c) from [c010] (ubifs_leb_read+0x24/0x88) [4.28] [c010] (ubifs_leb_read+0x24/0x88) from [c01572f8] (ubifs_read_node+0xa8/0x2e4) [4.28] [c01572f8] (ubifs_read_node+0xa8/0x2e4) from [c0153c50] (ubifs_read_sb_node+0x54/0x78) [4.28] [c0153c50] (ubifs_read_sb_node+0x54/0x78) from [c0154940] (ubifs_read_superblock+0xc8c/0x133c) [4.28] [c0154940] (ubifs_read_superblock+0xc8c/0x133c) from [c01520ac] (ubifs_mount+0x73c/0x1bc0) [4.28] [c01520ac] (ubifs_mount+0x73c/0x1bc0) from [c00a49ec] (mount_fs+0x44/0x184) [4.28] [c00a49ec] (mount_fs+0x44/0x184) from [c00baf90] (vfs_kern_mount+0x4c/0xc0) [4.28] [c00baf90] (vfs_kern_mount+0x4c/0xc0) from [c00bb1a0] (do_kern_mount+0x34/0xd0) [4.28] [c00bb1a0] (do_kern_mount+0x34/0xd0) from [c00bc93c] (do_mount+0x15c/0x73c) [4.28] [c00bc93c] (do_mount+0x15c/0x73c) from [c00bcfa0] (sys_mount+0x84/0xc4) [4.28] [c00bcfa0] (sys_mount+0x84/0xc4) from [c04e4a04] (do_mount_root+0x24/0xb0) [4.28] [c04e4a04] (do_mount_root+0x24/0xb0) from [c04e4b78] (mount_block_root+0xe8/0x214) [4.28] [c04e4b78] (mount_block_root+0xe8/0x214) from [c04e4e28] (prepare_namespace+0x8c/0x180) [4.28] [c04e4e28] (prepare_namespace+0x8c/0x180) from [c04e4894] (kernel_init+0x16c/0x1b4) [4.28] [c04e4894] (kernel_init+0x16c/0x1b4) from [c000ff70] (kernel_thread_exit+0x0/0x8) [4.28] ---[ end trace 4d36b722759fdc4f ]--- [4.95] UBIFS DBG (pid 58): ubifs_bg_thread: background thread ubifs_bgt0_0 started, PID 58 -Subodh __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/4] drivers/mtd/maps/autcpu12-nvram.c: drop frees of devm_ alloc'd data
On Sat, 2012-09-01 at 18:33 +0200, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr devm free functions should not have to be explicitly used. A semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] udf: extent cache implementation for manipulating block map
2012/9/3, Jan Kara j...@suse.cz:
Hello,
On Fri 31-08-12 12:51:58, Namjae Jeon wrote:
From: Namjae Jeon namjae.j...@samsung.com
While mapping logical blocks of a file to physical blocks on the
partition,
everytime UDF read file metadata from the begining which decrease
preformance.
The drawback of this scheme is more prominent while reading large files.
For example, while reading a large file of ~5GB, read speed will
gradually become less as we near the end of file because of the time
taken in calculating the corresponding physical block.
This patch implements caching and remembers the location of the last read
extent. Instead of reading file metadata from begining, start from the
cached location.
Hi. Jan.
Thanks for the patch. I like this much better than the previous one. Some
comments are below:
Thank you~
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 1a0588e..f4cc4e0 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -357,8 +359,14 @@ static int udf_get_block(struct inode *inode,
sector_t block,
if (!phys)
goto abort;
-if (new)
+if (new) {
+unsigned char lshift = inode-i_sb-s_blocksize_bits;
set_buffer_new(bh_result);
+if (iinfo-cached_extent.sanity
+(iinfo-cached_extent.eblock (block lshift)))
+/* Block allocated for hole, invalidate cache */
+udf_clear_extent_cache(iinfo);
+}
map_bh(bh_result, inode-i_sb, phys);
Instead of this, you should change inode_getblk() to also use the extent
cache (for initialization of prev_epos when appropriate) and then update
the extent cache to the just found / created extent when the function is
done.
Okay, I will check about your suggestion.
abort:
@@ -2132,11 +2144,12 @@ int8_t inode_bmap(struct inode *inode, sector_t
block,
struct udf_inode_info *iinfo;
iinfo = UDF_I(inode);
-pos-offset = 0;
-pos-block = iinfo-i_location;
-pos-bh = NULL;
-*elen = 0;
-
+if (!udf_read_extent_cache(inode, bcount, lbcount, pos)) {
+pos-offset = 0;
+pos-block = iinfo-i_location;
+pos-bh = NULL;
+}
+*elen = 0;
There's TAB added here which doesn't make sense.
do {
etype = udf_next_aext(inode, pos, eloc, elen, 1);
if (etype == -1) {
...
@@ -2176,3 +2190,52 @@ long udf_block_map(struct inode *inode, sector_t
block)
else
return ret;
}
+int udf_read_extent_cache(struct inode *inode, loff_t bcount,
+ loff_t *lbcount, struct extent_position *pos)
+{
+struct udf_inode_info *iinfo = UDF_I(inode);
+mutex_lock(iinfo-i_extent_cache_lock);
+if ((iinfo-cached_extent.eblock = bcount)
+(iinfo-cached_extent.sanity)) {
+/* Cache hit */
+*lbcount = iinfo-cached_extent.eblock;
+memcpy(pos, iinfo-cached_extent.epos,
+ sizeof(struct extent_position));
+mutex_unlock(iinfo-i_extent_cache_lock);
+return 1;
+} else
+udf_clear_extent_cache(iinfo);
It would be less confusing, if udf_read_extent_cache() didn't clear the
cache in case of a miss. Then in udf_update_extent_cache() just clear the
cache if it is still valid.
Okay, It is more effective! I will change ~
+
+mutex_unlock(iinfo-i_extent_cache_lock);
+return 0;
+}
+void udf_update_extent_cache(struct inode *inode, loff_t estart,
+ struct extent_position *pos)
+{
+struct udf_inode_info *iinfo = UDF_I(inode);
+mutex_lock(iinfo-i_extent_cache_lock);
+if (pos-bh != NULL)
+/* Increase ref count */
+get_bh(pos-bh);
+memcpy(iinfo-cached_extent.epos, pos,
+ sizeof(struct extent_position));
+iinfo-cached_extent.eblock = estart;
+iinfo-cached_extent.sanity = 1;
+switch (iinfo-i_alloc_type) {
+case ICBTAG_FLAG_AD_SHORT:
+iinfo-cached_extent.epos.offset -= sizeof(struct short_ad);
+break;
+case ICBTAG_FLAG_AD_LONG:
+iinfo-cached_extent.epos.offset -= sizeof(struct long_ad);
+}
+mutex_unlock(iinfo-i_extent_cache_lock);
+}
+
+void udf_clear_extent_cache(struct udf_inode_info *iinfo)
+{
+if (iinfo-cached_extent.sanity) {
+brelse(iinfo-cached_extent.epos.bh);
+memset(iinfo-cached_extent, 0, sizeof(struct udf_ext_cache));
+}
+}
+
I think udf_clear_entent_cache() should take i_extent_cache_lock. Or if
you are sure it's not needed, you need a good documentation why.
Documentation ? I am a little confusing.. It means udf.txt is in
Documentation/filesystem/ ?
or comment about clear extent function ?
diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h
index bb8309d..ec3878a 100644
--- a/fs/udf/udf_i.h
+++ b/fs/udf/udf_i.h
@@ -1,6 +1,20 @@
#ifndef _UDF_I_H
#define
Re: [PATCH 1/3] leds-lp5523: support new LP55231 device
On Tue, Sep 4, 2012 at 3:06 PM, Kim, Milo milo@ti.com wrote: New TI LP55231 device has same I2C register layout as LP5523. Therefore, all of LED operations can be shared with the LP5523 driver. To support new LP55231 device explicitly, the device description is added in the configuration file. Looks good, I will apply this into my for-next -Bryan Signed-off-by: Milo(Woogyom) Kim milo@ti.com --- drivers/leds/Kconfig |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 16578d3..0bc80bd 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -192,11 +192,12 @@ config LEDS_LP5521 programming the engines. config LEDS_LP5523 - tristate LED Support for N.S. LP5523 LED driver chip + tristate LED Support for TI/National LP5523/55231 LED driver chip depends on LEDS_CLASS I2C help - If you say yes here you get support for the National Semiconductor - LP5523 LED driver. It is 9 channel chip with programmable engines. + If you say yes here you get support for TI/National Semiconductor + LP5523/55231 LED driver. + It is 9 channel chip with programmable engines. Driver provides direct control via LED class and interface for programming the engines. -- 1.7.9.5 Best Regards, Milo -- Bryan Wu bryan...@canonical.com Kernel Developer+86.186-168-78255 Mobile Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the arm-current tree
On Tuesday 04 September 2012, Stephen Rothwell wrote: Today's linux-next merge of the arm-soc tree got a conflict in arch/arm/mm/mmu.c between commit a849088aa155 (ARM: Fix ioremap() of address zero) from the arm-current tree and commit c2794437091a (ARM: Add fixed PCI i/o mapping) from the arm-soc tree. I am not sure how to fix this, so I have used the arm-current version of the change to pmd_empty_section_gap() since that changed the vm-flags. It may be that just changing the vm-flags value in vm_reserve_area_early() would be ok? If I read this correctly, we want pci_reserve_io to use VM_ARM_STATIC_MAPPING while pmd_empty_section_gap should use VM_ARM_EMPTY_MAPPING, so we probably want to add a flag argument to the vm_reserve_area_early() function. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] leds-lp5523: add new device id for LP55231
On Tue, Sep 4, 2012 at 3:06 PM, Kim, Milo milo@ti.com wrote:
To support LP55231 device, the device id is added.
Additionally, the i2c driver name is changed from lp5523 to lp5523x.
Applied to my for-next.
-Bryan
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/leds-lp5523.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 80d3792..e69e72a 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -104,6 +104,11 @@
#define LED_ACTIVE(mux, led) (!!(mux (0x0001 led)))
#define SHIFT_MASK(id) (((id) - 1) * 2)
+enum lp5523_chip_id {
+ LP5523,
+ LP55231,
+};
+
struct lp5523_engine {
int id;
u8 mode;
@@ -1005,7 +1010,8 @@ static int lp5523_remove(struct i2c_client *client)
}
static const struct i2c_device_id lp5523_id[] = {
- { lp5523, 0 },
+ { lp5523, LP5523 },
+ { lp55231, LP55231 },
{ }
};
@@ -1013,7 +1019,7 @@ MODULE_DEVICE_TABLE(i2c, lp5523_id);
static struct i2c_driver lp5523_driver = {
.driver = {
- .name = lp5523,
+ .name = lp5523x,
},
.probe = lp5523_probe,
.remove = lp5523_remove,
--
1.7.9.5
Best Regards,
Milo
--
Bryan Wu bryan...@canonical.com
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel: limit a value of ns_last_pid to (0, max_pid)
The kernel doesn't check pid on a negative values, so if
you would try to write -2 in /proc/sys/kernel/ns_last_pid,
you will get a kernel panic.
In this case the next pid is -1, and alloc_pidmap will try to access
to a nonexistent pidmap.
map = pid_ns-pidmap[pid/BITS_PER_PAGE];
Cc: Andrew Morton a...@linux-foundation.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Pavel Emelyanov xe...@parallels.com
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
Signed-off-by: Andrew Vagin ava...@openvz.org
---
kernel/pid_namespace.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index b3c7fd5..6144bab 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -232,15 +232,19 @@ static int pid_ns_ctl_handler(struct ctl_table *table,
int write,
*/
tmp.data = current-nsproxy-pid_ns-last_pid;
- return proc_dointvec(tmp, write, buffer, lenp, ppos);
+ return proc_dointvec_minmax(tmp, write, buffer, lenp, ppos);
}
+extern int pid_max;
+static int zero = 0;
static struct ctl_table pid_ns_ctl_table[] = {
{
.procname = ns_last_pid,
.maxlen = sizeof(int),
.mode = 0666, /* permissions are checked in the handler */
.proc_handler = pid_ns_ctl_handler,
+ .extra1 = zero,
+ .extra2 = pid_max,
},
{ }
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warnings after merge of the drm tree
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
dependencies (USB_SUPPORT USB_OHCI_HCD)
warning: (PPC_PS3 PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which has
unmet direct dependencies (USB_SUPPORT USB_OHCI_HCD)
warning: (PPC_PS3 PPC_CELLEB USB_EHCI_HCD_PMC_MSP
XPS_USB_HCD_XILINX USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO
which has unmet direct dependencies (USB_SUPPORT USB_EHCI_HCD
(PPC_CELLEB || PPC_PS3 || 440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX ||
PPC_MPC512x || CPU_CAVIUM_OCTEON || PMC_MSP || SPARC_LEON || MIPS_SEAD3))
The x86_64 allmodconfig produces these:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (MOUSE_APPLETOUCH MOUSE_BCM5974 MOUSE_SYNAPTICS_USB
JOYSTICK_XPAD TABLET_USB_ACECAD TABLET_USB_AIPTEK
TABLET_USB_HANWANG TABLET_USB_KBTAB TABLET_USB_WACOM
TOUCHSCREEN_USB_COMPOSITE INPUT_ATI_REMOTE2 INPUT_KEYSPAN_REMOTE
INPUT_POWERMATE INPUT_YEALINK INPUT_CM109 RC_ATI_REMOTE IR_IMON
IR_MCEUSB IR_REDRAT3 IR_STREAMZAP IR_IGUANA IR_TTUSBIR
DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT
USB_ARCH_HAS_HCD)
Maybe introduced by commit df0b34430072 (drm/usb: select USB_SUPPORT in
Kconfig), maybe interacting with a commit 8f057d7bca54 (gpu/mfd/usb:
Fix USB randconfig problems) from Linus' tree (that added depends on
USB_ARCH_HAS_HCD to config DRM_USB and config DRM_UDL).
I have left this mess for now, but it needs addressing.
I have sent a fix (drm/udl: usb: Fix recursive Kconfig dependency)
for this mess and pinged airlied on IRC.
NOTE: I saw this when I merged drm(-intel){-fixes,next} into next-20120824.
I[ve pushed it to drm-next now hopefully it will resolve the mess.
thanks,
Dave.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8 v2] acpi-cpufreq: Move modern AMD cpufreq support to acpi-cpufreq
Hi, now the second, revised version of the patch set. I now tested loading both drivers after each other in several combinations, after two bug fixes this now works as expected. I added a patch to move messages from powernow-k8 after the initialization phase, so it remains silent if driver loading fails. I also rearranged the patches so that the powernow-k8 feature removal patch is now the last one and is somewhat optional. I still prefer to have it in, but it can be dropped if needed. Then powernow-k8 will still support modern AMD CPUs, but will emit a warning message. Regards, Andre Changes from v1: * added hints to Kconfig about CPU support * merge documentation from separate patch into the feature patch * add deprecation warning * prefix acpi-cpufreq warning messages with module name * bugfix: avoid boost init it driver registration failed * bugfix: fix module redirect request call (was not reached before) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/8 v2] ACPI: Add fixups for AMD P-state figures
From: Matthew Garrett m...@redhat.com
Some AMD systems may round the frequencies in ACPI tables to 100MHz
boundaries. We can obtain the real frequencies from MSRs, so add a quirk
to fix these frequencies up on AMD systems.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
arch/x86/include/asm/msr-index.h | 1 +
drivers/acpi/processor_perflib.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 1e1f3eb..fbee971 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -248,6 +248,7 @@
#define MSR_IA32_PERF_STATUS 0x0198
#define MSR_IA32_PERF_CTL 0x0199
+#define MSR_AMD_PSTATE_DEF_BASE0xc0010064
#define MSR_AMD_PERF_STATUS0xc0010063
#define MSR_AMD_PERF_CTL 0xc0010062
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index a093dc1..836bfe0 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -324,6 +324,34 @@ static int acpi_processor_get_performance_control(struct
acpi_processor *pr)
return result;
}
+#ifdef CONFIG_X86
+/*
+ * Some AMDs have 50MHz frequency multiples, but only provide 100MHz rounding
+ * in their ACPI data. Calculate the real values and fix up the _PSS data.
+ */
+static void amd_fixup_frequency(struct acpi_processor_px *px, int i)
+{
+ u32 hi, lo, fid, did;
+ int index = px-control 0x0007;
+
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+ return;
+
+ if ((boot_cpu_data.x86 == 0x10 boot_cpu_data.x86_model 10)
+ || boot_cpu_data.x86 == 0x11) {
+ rdmsr(MSR_AMD_PSTATE_DEF_BASE + index, lo, hi);
+ fid = lo 0x3f;
+ did = (lo 6) 7;
+ if (boot_cpu_data.x86 == 0x10)
+ px-core_frequency = (100 * (fid + 0x10)) did;
+ else
+ px-core_frequency = (100 * (fid + 8)) did;
+ }
+}
+#else
+static void amd_fixup_frequency(struct acpi_processor_px *px, int i) {};
+#endif
+
static int acpi_processor_get_performance_states(struct acpi_processor *pr)
{
int result = 0;
@@ -379,6 +407,8 @@ static int acpi_processor_get_performance_states(struct
acpi_processor *pr)
goto end;
}
+ amd_fixup_frequency(px, i);
+
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
State [%d]: core_frequency[%d] power[%d]
transition_latency[%d] bus_master_latency[%d] control[0x%x] status[0x%x]\n,
i,
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8 v2] cpufreq: Add warning message to powernow-k8
cpufreq modules are often loaded from init scripts that assume that
all recent AMD systems will use powernow-k8.
To inform the user of the change of support and ease the transition
to acpi-cpufreq, emit a warning message.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Kconfig.x86 | 3 ++-
drivers/cpufreq/powernow-k8.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index 8d12e37..b36ca1f 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -96,7 +96,8 @@ config X86_POWERNOW_K8
select CPU_FREQ_TABLE
depends on ACPI ACPI_PROCESSOR
help
- This adds the CPUFreq driver for K8/K10 Opteron/Athlon64 processors.
+ This adds the CPUFreq driver for K8/early Opteron/Athlon64 processors.
+ Support for K10 and newer processors is now in acpi-cpufreq.
To compile this driver as a module, choose M here: the
module will be called powernow-k8.
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index c0e8164..16c7fb6 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -1560,6 +1560,9 @@ static int __cpuinit powernowk8_init(void)
if (!x86_match_cpu(powernow_k8_ids))
return -ENODEV;
+ if (static_cpu_has(X86_FEATURE_HW_PSTATE))
+ pr_warn(PFX support for this CPU is deprecated, use
acpi-cpufreq instead.\n);
+
for_each_online_cpu(i) {
int rc;
smp_call_function_single(i, check_supported_cpu, rc, 1);
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
To workaround some Windows specific behavior, the ACPI _PSD table
on AMD desktop boards advertises all cores as dependent, meaning
that they all can only use the same P-state. acpi-cpufreq strictly
obeys this description, instantiating one CPU only and symlinking
the others. But the hardware can have distinct frequencies for each
core and powernow-k8 did it that way.
So, in order to use the hardware to its full potential and keep the
original powernow-k8 behavior, lets override the _PSD table setting
on AMD hardware.
We use the siblings table, as it matches the current hardware
behavior.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/acpi-cpufreq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..70e7173 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -51,6 +51,8 @@ MODULE_AUTHOR(Paul Diefenbaugh, Dominik Brodowski);
MODULE_DESCRIPTION(ACPI Processor P-States Driver);
MODULE_LICENSE(GPL);
+#define PFX acpi-cpufreq:
+
enum {
UNDEFINED_CAPABLE = 0,
SYSTEM_INTEL_MSR_CAPABLE,
@@ -586,6 +588,14 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
policy-shared_type = CPUFREQ_SHARED_TYPE_ALL;
cpumask_copy(policy-cpus, cpu_core_mask(cpu));
}
+
+ if (check_amd_hwpstate_cpu(cpu) !acpi_pstate_strict) {
+ cpumask_clear(policy-cpus);
+ cpumask_set_cpu(cpu, policy-cpus);
+ cpumask_copy(policy-related_cpus, cpu_sibling_mask(cpu));
+ policy-shared_type = CPUFREQ_SHARED_TYPE_HW;
+ pr_info_once(PFX overriding BIOS provided _PSD data\n);
+ }
#endif
/* capability check */
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] leds-lp5523: use the i2c device id rather than fixed name
On Tue, Sep 4, 2012 at 3:06 PM, Kim, Milo milo@ti.com wrote:
LP5523 driver supports both LP5523 and LP55231.
The i2c device id is one of the two - lp5523 or lp55231.
So it's better to use matching i2c device id while enumerating the device
and naming LED channels.
Applied, thanks.
-Bryan
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/leds-lp5523.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index e69e72a..3d60428 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -833,7 +833,8 @@ static int __init lp5523_init_engine(struct lp5523_engine
*engine, int id)
}
static int __devinit lp5523_init_led(struct lp5523_led *led, struct device
*dev,
- int chan, struct lp5523_platform_data *pdata)
+ int chan, struct lp5523_platform_data *pdata,
+ const char *chip_name)
{
char name[32];
int res;
@@ -856,7 +857,7 @@ static int __devinit lp5523_init_led(struct lp5523_led
*led, struct device *dev,
led-cdev.name = pdata-led_config[chan].name;
} else {
snprintf(name, sizeof(name), %s:channel%d,
- pdata-label ?: lp5523, chan);
+ pdata-label ? : chip_name, chan);
led-cdev.name = name;
}
@@ -927,7 +928,7 @@ static int __devinit lp5523_probe(struct i2c_client
*client,
if (ret)
goto fail1;
- dev_info(client-dev, LP5523 Programmable led chip found\n);
+ dev_info(client-dev, %s Programmable led chip found\n, id-name);
/* Initialize engines */
for (i = 0; i ARRAY_SIZE(chip-engines); i++) {
@@ -955,7 +956,8 @@ static int __devinit lp5523_probe(struct i2c_client
*client,
INIT_WORK(chip-leds[led].brightness_work,
lp5523_led_brightness_work);
- ret = lp5523_init_led(chip-leds[led], client-dev, i,
pdata);
+ ret = lp5523_init_led(chip-leds[led], client-dev, i,
pdata,
+ id-name);
if (ret) {
dev_err(client-dev, error initializing leds\n);
goto fail2;
--
1.7.9.5
Best Regards,
Milo
--
Bryan Wu bryan...@canonical.com
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8 v2] cpufreq: Remove support for hardware P-state chips from powernow-k8
From: Matthew Garrett m...@redhat.com
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Andre: Tighten the deprecation warning message. Trigger load of
acpi-cpufreq and let the load of the module finally fail.
This avoids the problem of users ending up without any cpufreq support
after the transition.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/powernow-k8.c | 392 +++---
drivers/cpufreq/powernow-k8.h | 32
3 files changed, 29 insertions(+), 397 deletions(-)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 9531fc2..b99790f 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -19,7 +19,7 @@ obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
# K8 systems. ACPI is preferred to all other hardware-specific drivers.
# speedstep-* is preferred over p4-clockmod.
-obj-$(CONFIG_X86_POWERNOW_K8) += powernow-k8.o mperf.o
+obj-$(CONFIG_X86_POWERNOW_K8) += powernow-k8.o
obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o mperf.o
obj-$(CONFIG_X86_PCC_CPUFREQ) += pcc-cpufreq.o
obj-$(CONFIG_X86_POWERNOW_K6) += powernow-k6.o
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 8ff0621..c8bfeff 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -49,22 +49,12 @@
#define PFX powernow-k8:
#define VERSION version 2.20.00
#include powernow-k8.h
-#include mperf.h
/* serialize freq changes */
static DEFINE_MUTEX(fidvid_mutex);
static DEFINE_PER_CPU(struct powernow_k8_data *, powernow_data);
-static int cpu_family = CPU_OPTERON;
-
-/* array to map SW pstate number to acpi state */
-static u32 ps_to_as[8];
-
-/* core performance boost */
-static bool cpb_capable, cpb_enabled;
-static struct msr __percpu *msrs;
-
static struct cpufreq_driver cpufreq_amd64_driver;
#ifndef CONFIG_SMP
@@ -86,12 +76,6 @@ static u32 find_khz_freq_from_fid(u32 fid)
return 1000 * find_freq_from_fid(fid);
}
-static u32 find_khz_freq_from_pstate(struct cpufreq_frequency_table *data,
-u32 pstate)
-{
- return data[ps_to_as[pstate]].frequency;
-}
-
/* Return the vco fid for an input fid
*
* Each low fid has corresponding high fid, and you can get to low fids
@@ -114,9 +98,6 @@ static int pending_bit_stuck(void)
{
u32 lo, hi;
- if (cpu_family == CPU_HW_PSTATE)
- return 0;
-
rdmsr(MSR_FIDVID_STATUS, lo, hi);
return lo MSR_S_LO_CHANGE_PENDING ? 1 : 0;
}
@@ -130,20 +111,6 @@ static int query_current_values_with_pending_wait(struct
powernow_k8_data *data)
u32 lo, hi;
u32 i = 0;
- if (cpu_family == CPU_HW_PSTATE) {
- rdmsr(MSR_PSTATE_STATUS, lo, hi);
- i = lo HW_PSTATE_MASK;
- data-currpstate = i;
-
- /*
-* a workaround for family 11h erratum 311 might cause
-* an out-of-range Pstate if the core is in Pstate-0
-*/
- if ((boot_cpu_data.x86 == 0x11) (i = data-numps))
- data-currpstate = HW_PSTATE_0;
-
- return 0;
- }
do {
if (i++ 1) {
pr_debug(detected change pending stuck\n);
@@ -300,14 +267,6 @@ static int decrease_vid_code_by_step(struct
powernow_k8_data *data,
return 0;
}
-/* Change hardware pstate by single MSR write */
-static int transition_pstate(struct powernow_k8_data *data, u32 pstate)
-{
- wrmsr(MSR_PSTATE_CTRL, pstate, 0);
- data-currpstate = pstate;
- return 0;
-}
-
/* Change Opteron/Athlon64 fid and vid, by the 3 phases. */
static int transition_fid_vid(struct powernow_k8_data *data,
u32 reqfid, u32 reqvid)
@@ -524,8 +483,6 @@ static int core_voltage_post_transition(struct
powernow_k8_data *data,
static const struct x86_cpu_id powernow_k8_ids[] = {
/* IO based frequency switching */
{ X86_VENDOR_AMD, 0xf },
- /* MSR based frequency switching supported */
- X86_FEATURE_MATCH(X86_FEATURE_HW_PSTATE),
{}
};
MODULE_DEVICE_TABLE(x86cpu, powernow_k8_ids);
@@ -561,15 +518,8 @@ static void check_supported_cpu(void *_rc)
Power state transitions not supported\n);
return;
}
- } else { /* must be a HW Pstate capable processor */
- cpuid(CPUID_FREQ_VOLT_CAPABILITIES, eax, ebx, ecx, edx);
- if ((edx USE_HW_PSTATE) == USE_HW_PSTATE)
- cpu_family = CPU_HW_PSTATE;
- else
- return;
+ *rc = 0;
}
-
- *rc = 0;
}
static int check_pst_table(struct powernow_k8_data *data, struct pst_s *pst,
@@
[PATCH 7/8 v2] acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob
The powernow-k8 driver supported a sysfs knob called cpb, which was
instantiated per CPU, but actually acted globally for the whole
system. To keep some compatibility with this feature, we re-introduce
this behavior here, but:
a) only enable it on AMD CPUs and
b) protect it with a Kconfig switch
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/Kconfig.x86| 12 +++
drivers/cpufreq/acpi-cpufreq.c | 46 --
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index b36ca1f..934854a 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -33,6 +33,18 @@ config X86_ACPI_CPUFREQ
If in doubt, say N.
+config X86_ACPI_CPUFREQ_CPB
+ default y
+ bool Legacy cpb sysfs knob support for AMD CPUs
+ depends on X86_ACPI_CPUFREQ CPU_SUP_AMD
+ help
+ The powernow-k8 driver used to provide a sysfs knob called cpb
+ to disable the Core Performance Boosting feature of AMD CPUs. This
+ file has now been superseeded by the more generic boost entry.
+
+ By enabling this option the acpi_cpufreq driver provides the old
+ entry in addition to the new boost ones, for compatibility reasons.
+
config ELAN_CPUFREQ
tristate AMD Elan SC400 and SC410
select CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index dffa7af..0d048f6 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -133,8 +133,7 @@ static void boost_set_msrs(bool enable, const struct
cpumask *cpumask)
wrmsr_on_cpus(cpumask, msr_addr, msrs);
}
-static ssize_t store_global_boost(struct kobject *kobj, struct attribute *attr,
- const char *buf, size_t count)
+static ssize_t _store_boost(const char *buf, size_t count)
{
int ret;
unsigned long val = 0;
@@ -161,6 +160,12 @@ static ssize_t store_global_boost(struct kobject *kobj,
struct attribute *attr,
return count;
}
+static ssize_t store_global_boost(struct kobject *kobj, struct attribute *attr,
+ const char *buf, size_t count)
+{
+ return _store_boost(buf, count);
+}
+
static ssize_t show_global_boost(struct kobject *kobj,
struct attribute *attr, char *buf)
{
@@ -171,6 +176,21 @@ static struct global_attr global_boost = __ATTR(boost,
0644,
show_global_boost,
store_global_boost);
+#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
+static ssize_t store_cpb(struct cpufreq_policy *policy, const char *buf,
+size_t count)
+{
+ return _store_boost(buf, count);
+}
+
+static ssize_t show_cpb(struct cpufreq_policy *policy, char *buf)
+{
+ return sprintf(buf, %u\n, boost_enabled);
+}
+
+static struct freq_attr cpb = __ATTR(cpb, 0644, show_cpb, store_cpb);
+#endif
+
static int check_est_cpu(unsigned int cpuid)
{
struct cpuinfo_x86 *cpu = cpu_data(cpuid);
@@ -889,6 +909,7 @@ static int acpi_cpufreq_resume(struct cpufreq_policy
*policy)
static struct freq_attr *acpi_cpufreq_attr[] = {
cpufreq_freq_attr_scaling_available_freqs,
+ NULL, /* this is a placeholder for cpb, do not remove */
NULL,
};
@@ -960,6 +981,27 @@ static int __init acpi_cpufreq_init(void)
if (ret)
return ret;
+#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
+ /* this is a sysfs file with a strange name and an even stranger
+* semantic - per CPU instantiation, but system global effect.
+* Lets enable it only on AMD CPUs for compatibility reasons and
+* only if configured. This is considered legacy code, which
+* will probably be removed at some point in the future.
+*/
+ if (check_amd_hwpstate_cpu(0)) {
+ struct freq_attr **iter;
+
+ pr_debug(adding sysfs entry for cpb\n);
+
+ for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
+ ;
+
+ /* make sure there is a terminator behind it */
+ if (iter[1] == NULL)
+ *iter = cpb;
+ }
+#endif
+
ret = cpufreq_register_driver(acpi_cpufreq_driver);
if (ret)
free_acpi_perf_data();
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8 v2] acpi-cpufreq: Add support for disabling dynamic overclocking
One feature present in powernow-k8 that isn't present in acpi-cpufreq is support for enabling or disabling AMD's core performance boost technology. This patch adds support to acpi-cpufreq, but also includes support for Intel's dynamic acceleration. The original boost disabling sysfs file was per CPU, but acted globally. Also the naming (cpb) was at least not intuitive. So lets introduce a single file simply called boost, which sits once in /sys/devices/system/cpu/cpufreq. This should be the only way of using this feature, so add documentation about the rationale and the usage. A following patch will re-introduce the cpb knob for compatibility reasons on AMD CPUs. Per-CPU boost switching is possible, but not trivial and is thus postponed to a later patch series. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- Documentation/ABI/testing/sysfs-devices-system-cpu | 11 ++ Documentation/cpu-freq/boost.txt | 93 +++ drivers/cpufreq/acpi-cpufreq.c | 177 + 3 files changed, 281 insertions(+) create mode 100644 Documentation/cpu-freq/boost.txt diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 5dab364..6943133 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -176,3 +176,14 @@ Description: Disable L3 cache indices All AMD processors with L3 caches provide this functionality. For details, see BKDGs at http://developer.amd.com/documentation/guides/Pages/default.aspx + + +What: /sys/devices/system/cpu/cpufreq/boost +Date: August 2012 +Contact: Linux kernel mailing list linux-kernel@vger.kernel.org +Description: Processor frequency boosting control + + This switch controls the boost setting for the whole system. + Boosting allows the CPU and the firmware to run at a frequency + beyound it's nominal limit. + More details can be found in Documentation/cpu-freq/boost.txt diff --git a/Documentation/cpu-freq/boost.txt b/Documentation/cpu-freq/boost.txt new file mode 100644 index 000..9b4edfc --- /dev/null +++ b/Documentation/cpu-freq/boost.txt @@ -0,0 +1,93 @@ +Processor boosting control + + - information for users - + +Quick guide for the impatient: + +/sys/devices/system/cpu/cpufreq/boost +controls the boost setting for the whole system. You can read and write +that file with either 0 (boosting disabled) or 1 (boosting allowed). +Reading or writing 1 does not mean that the system is boosting at this +very moment, but only that the CPU _may_ raise the frequency at it's +discretion. + + +Introduction +- +Some CPUs support a functionality to raise the operating frequency of +some cores in a multi-core package if certain conditions apply, mostly +if the whole chip is not fully utilized and below it's intended thermal +budget. This is done without operating system control by a combination +of hardware and firmware. +On Intel CPUs this is called Turbo Boost, AMD calls it Turbo-Core, +in technical documentation Core performance boost. In Linux we use +the term boost for convenience. + +Rationale for disable switch + + +Though the idea is to just give better performance without any user +intervention, sometimes the need arises to disable this functionality. +Most systems offer a switch in the (BIOS) firmware to disable the +functionality at all, but a more fine-grained and dynamic control would +be desirable: +1. While running benchmarks, reproducible results are important. Since + the boosting functionality depends on the load of the whole package, + single thread performance can vary. By explicitly disabling the boost + functionality at least for the benchmark's run-time the system will run + at a fixed frequency and results are reproducible again. +2. To examine the impact of the boosting functionality it is helpful + to do tests with and without boosting. +3. Boosting means overclocking the processor, though under controlled + conditions. By raising the frequency and the voltage the processor + will consume more power than without the boosting, which may be + undesirable for instance for mobile users. Disabling boosting may + save power here, though this depends on the workload. + + +User controlled switch +-- + +To allow the user to toggle the boosting functionality, the acpi-cpufreq +driver exports a sysfs knob to disable it. There is a file: +/sys/devices/system/cpu/cpufreq/boost +which can either read 0 (boosting disabled) or 1 (boosting enabled). +Reading the file is always supported, even if the processor does not +support boosting. In this case the file will be read-only and always +reads as 0. Explicitly changing the permissions and
[PATCH 1/8 v2] acpi-cpufreq: Add support for modern AMD CPUs
From: Matthew Garrett m...@redhat.com
The programming model for P-states on modern AMD CPUs is very similar to
that of Intel and VIA. It makes sense to consolidate this support into one
driver rather than duplicating functionality between two of them. This
patch adds support for AMDs with hardware P-state control to acpi-cpufreq.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
arch/x86/include/asm/msr-index.h | 2 ++
drivers/cpufreq/Kconfig.x86 | 3 ++-
drivers/cpufreq/acpi-cpufreq.c | 43 ++--
3 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 957ec87..1e1f3eb 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -248,6 +248,8 @@
#define MSR_IA32_PERF_STATUS 0x0198
#define MSR_IA32_PERF_CTL 0x0199
+#define MSR_AMD_PERF_STATUS0xc0010063
+#define MSR_AMD_PERF_CTL 0xc0010062
#define MSR_IA32_MPERF 0x00e7
#define MSR_IA32_APERF 0x00e8
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index 78ff7ee..8d12e37 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -23,7 +23,8 @@ config X86_ACPI_CPUFREQ
help
This driver adds a CPUFreq driver which utilizes the ACPI
Processor Performance States.
- This driver also supports Intel Enhanced Speedstep.
+ This driver also supports Intel Enhanced Speedstep and newer
+ AMD CPUs.
To compile this driver as a module, choose M here: the
module will be called acpi-cpufreq.
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 56c6c6b..067a61f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -54,10 +54,12 @@ MODULE_LICENSE(GPL);
enum {
UNDEFINED_CAPABLE = 0,
SYSTEM_INTEL_MSR_CAPABLE,
+ SYSTEM_AMD_MSR_CAPABLE,
SYSTEM_IO_CAPABLE,
};
#define INTEL_MSR_RANGE(0x)
+#define AMD_MSR_RANGE (0x7)
struct acpi_cpufreq_data {
struct acpi_processor_performance *acpi_data;
@@ -82,6 +84,13 @@ static int check_est_cpu(unsigned int cpuid)
return cpu_has(cpu, X86_FEATURE_EST);
}
+static int check_amd_hwpstate_cpu(unsigned int cpuid)
+{
+ struct cpuinfo_x86 *cpu = cpu_data(cpuid);
+
+ return cpu_has(cpu, X86_FEATURE_HW_PSTATE);
+}
+
static unsigned extract_io(u32 value, struct acpi_cpufreq_data *data)
{
struct acpi_processor_performance *perf;
@@ -101,7 +110,11 @@ static unsigned extract_msr(u32 msr, struct
acpi_cpufreq_data *data)
int i;
struct acpi_processor_performance *perf;
- msr = INTEL_MSR_RANGE;
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ msr = AMD_MSR_RANGE;
+ else
+ msr = INTEL_MSR_RANGE;
+
perf = data-acpi_data;
for (i = 0; data-freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
@@ -115,6 +128,7 @@ static unsigned extract_freq(u32 val, struct
acpi_cpufreq_data *data)
{
switch (data-cpu_feature) {
case SYSTEM_INTEL_MSR_CAPABLE:
+ case SYSTEM_AMD_MSR_CAPABLE:
return extract_msr(val, data);
case SYSTEM_IO_CAPABLE:
return extract_io(val, data);
@@ -150,6 +164,7 @@ static void do_drv_read(void *_cmd)
switch (cmd-type) {
case SYSTEM_INTEL_MSR_CAPABLE:
+ case SYSTEM_AMD_MSR_CAPABLE:
rdmsr(cmd-addr.msr.reg, cmd-val, h);
break;
case SYSTEM_IO_CAPABLE:
@@ -174,6 +189,9 @@ static void do_drv_write(void *_cmd)
lo = (lo ~INTEL_MSR_RANGE) | (cmd-val INTEL_MSR_RANGE);
wrmsr(cmd-addr.msr.reg, lo, hi);
break;
+ case SYSTEM_AMD_MSR_CAPABLE:
+ wrmsr(cmd-addr.msr.reg, cmd-val, 0);
+ break;
case SYSTEM_IO_CAPABLE:
acpi_os_write_port((acpi_io_address)cmd-addr.io.port,
cmd-val,
@@ -217,6 +235,10 @@ static u32 get_cur_val(const struct cpumask *mask)
cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
cmd.addr.msr.reg = MSR_IA32_PERF_STATUS;
break;
+ case SYSTEM_AMD_MSR_CAPABLE:
+ cmd.type = SYSTEM_AMD_MSR_CAPABLE;
+ cmd.addr.msr.reg = MSR_AMD_PERF_STATUS;
+ break;
case SYSTEM_IO_CAPABLE:
cmd.type = SYSTEM_IO_CAPABLE;
perf = per_cpu(acfreq_data, cpumask_first(mask))-acpi_data;
@@ -326,6 +348,11 @@ static int acpi_cpufreq_target(struct cpufreq_policy
*policy,
cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
cmd.val = (u32) perf-states[next_perf_state].control;
break;
+ case
Re: [PATCH] USB: ohci-at91: fix PIO handling in relation with number of ports
On 08/29/2012 11:49 AM, Nicolas Ferre :
If the number of ports present on the SoC/board is not the maximum
and that the platform data is not filled with all data, there is
an easy way to mess the PIO setup for this interface.
This quick fix addresses mis-configuration in USB host platform data
that is common in at91 boards since commit 0ee6d1e (USB: ohci-at91:
change maximum number of ports) that did not modified the associatd
board files.
Reported-by: Klaus Falkner klaus.falk...@solectrix.de
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org
Cc: Stable sta...@vger.kernel.org [3.4+]
Alan, Greg, gentle ping...
I really would like to seen it landing in stable soon...
Thanks, best regards,
---
drivers/usb/host/ohci-at91.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index a665b3e..aaa8d2b 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -570,6 +570,16 @@ static int __devinit ohci_hcd_at91_drv_probe(struct
platform_device *pdev)
if (pdata) {
at91_for_each_port(i) {
+ /*
+ * do not configure PIO if not in relation with
+ * real USB port on board
+ */
+ if (i = pdata-ports) {
+ pdata-vbus_pin[i] = -EINVAL;
+ pdata-overcurrent_pin[i] = -EINVAL;
+ break;
+ }
+
if (!gpio_is_valid(pdata-vbus_pin[i]))
continue;
gpio = pdata-vbus_pin[i];
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8 v2] powernow-k8: delay info messages until initialization has succeeded
powernow-k8 is quite prematurely crying Hooray and outputs diagnostic
messages, although the actual initialization can still fail.
Since now we may have acpi-cpufreq already loaded, we move the
messages at the end of the init routine to avoid confusing output
if the loading of powernow-k8 should not succeed.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
drivers/cpufreq/powernow-k8.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 16c7fb6..8ff0621 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -1573,9 +1573,6 @@ static int __cpuinit powernowk8_init(void)
if (supported_cpus != num_online_cpus())
return -ENODEV;
- printk(KERN_INFO PFX Found %d %s (%d cpu cores) ( VERSION )\n,
- num_online_nodes(), boot_cpu_data.x86_model_id, supported_cpus);
-
if (boot_cpu_has(X86_FEATURE_CPB)) {
cpb_capable = true;
@@ -1594,16 +1591,23 @@ static int __cpuinit powernowk8_init(void)
struct msr *reg = per_cpu_ptr(msrs, cpu);
cpb_enabled |= !(!!(reg-l BIT(25)));
}
-
- printk(KERN_INFO PFX Core Performance Boosting: %s.\n,
- (cpb_enabled ? on : off));
}
rv = cpufreq_register_driver(cpufreq_amd64_driver);
- if (rv 0 boot_cpu_has(X86_FEATURE_CPB)) {
- unregister_cpu_notifier(cpb_nb);
- msrs_free(msrs);
- msrs = NULL;
+
+ if (!rv)
+ pr_info(PFX Found %d %s (%d cpu cores) ( VERSION )\n,
+ num_online_nodes(), boot_cpu_data.x86_model_id,
+ supported_cpus);
+
+ if (boot_cpu_has(X86_FEATURE_CPB)) {
+ if (rv 0) {
+ unregister_cpu_notifier(cpb_nb);
+ msrs_free(msrs);
+ msrs = NULL;
+ } else
+ pr_info(PFX Core Performance Boosting: %s.\n,
+ (cpb_enabled ? on : off));
}
return rv;
}
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] memcg: first step towards hierarchical controller
+ of the root memcg, regardless of their positioning in the tree. + + Use of flat hierarchies is highly discouraged, but has been the + default for performance reasons for quite some time. Setting this flag + to on will make hierarchical accounting the default. It is still + possible to set it back to flat by writing 0 to the file + memory.use_hierarchy, albeit discouraged. Distributors are encouraged + to set this option. [...] I don't think that 'default n' is effective encouragement! Ben. If it were up to me, I would just flip it to 1. No option. A bit of history here, is that people have a - quite valid - concern that this will disrupt users using their own kernel, should they decide to update, recompile and run. Conditional on a Kconfig option, people reusing their .config will see no change. Distros, otoh, are versioned. It is not unreasonable to expect a behavior change when a major version flips. The encouragement here comes not from the default, but from the acknowledgment that his thing is totally broken, and we need to act to fix it in a compatible way. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
Aiaiai! :-) [1] [2]
I've build-tested this using aiaiai and it reports that this change breaks the
build:
dedekind@blue:~/git/maintaining$ ./verify ../l2-mtd/ mpc5121_nfc
~/tmp/julia2.mbox
Tested the patch(es) on top of the following commits:
ba64756 Quick fixes - applied by aiaiai
651c6fa JFFS2: don't fail on bitflips in OOB
e22ac84 mtd: autcpu12-nvram: drop frees of devm_ alloc'd data
ea9d312 mtd: cmdlinepart: minor cleanups
Failed to build the following commit for configuration
powerpc-mpc512x_defconfig (architecture powerpc):
0fe13ab drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
...
drivers/mtd/nand/mpc5121_nfc.c: In function 'mpc5121_nfc_probe':
drivers/mtd/nand/mpc5121_nfc.c:622:28: warning: variable 'regs_size' set but
not used [-Wunused-but-set-variable]
drivers/mtd/nand/mpc5121_nfc.c:622:16: warning: variable 'regs_paddr' set but
not used [-Wunused-but-set-variable]
drivers/built-in.o: In function `mpc5121_nfc_probe':
mpc5121_nfc.c:(.devinit.text+0x2a14): undefined reference to `devm_clk_get'
make[1]: *** [vmlinux] Error 1
I do not really know why, but it seems that clock framework is not supported
for powerpc. CCing the PPC mailing list. Preserved the context below for the
PPC people.
So, not taking this patch.
References:
1. http://git.infradead.org/users/dedekind/aiaiai.git
2. http://git.infradead.org/users/dedekind/maintaining.git
On Sat, 2012-09-01 at 18:33 +0200, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
devm free functions should not have to be explicitly used.
The only thing left that is useful in the function mpc5121_nfc_free is the
call to clk_disable, which is moved to the call sites.
This function also incorrectly called iounmap on devm_ioremap allocated
data.
Use devm_request_and_ioremap in place of devm_request_mem_region and
devm_ioremap.
Use devm_clk_get.
A semantic match that finds the first problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
@@
(
* devm_kfree(...);
|
* devm_free_irq(...);
|
* devm_iounmap(...);
|
* devm_release_region(...);
|
* devm_release_mem_region(...);
)
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/mtd/nand/mpc5121_nfc.c | 35 +--
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index c259c24..45183ba 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -632,21 +632,6 @@ out:
return ret;
}
-/* Free driver resources */
-static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd)
-{
- struct nand_chip *chip = mtd-priv;
- struct mpc5121_nfc_prv *prv = chip-priv;
-
- if (prv-clk) {
- clk_disable(prv-clk);
- clk_put(prv-clk);
- }
-
- if (prv-csreg)
- iounmap(prv-csreg);
-}
-
static int __devinit mpc5121_nfc_probe(struct platform_device *op)
{
struct device_node *rootnode, *dn = op-dev.of_node;
@@ -713,12 +698,7 @@ static int __devinit mpc5121_nfc_probe(struct
platform_device *op)
regs_paddr = res.start;
regs_size = resource_size(res);
- if (!devm_request_mem_region(dev, regs_paddr, regs_size, DRV_NAME)) {
- dev_err(dev, Error requesting memory region!\n);
- return -EBUSY;
- }
-
- prv-regs = devm_ioremap(dev, regs_paddr, regs_size);
+ prv-regs = devm_request_and_ioremap(dev, res);
if (!prv-regs) {
dev_err(dev, Error mapping memory region!\n);
return -ENOMEM;
@@ -752,11 +732,10 @@ static int __devinit mpc5121_nfc_probe(struct
platform_device *op)
of_node_put(rootnode);
/* Enable NFC clock */
- prv-clk = clk_get(dev, nfc_clk);
+ prv-clk = devm_clk_get(dev, nfc_clk);
if (IS_ERR(prv-clk)) {
dev_err(dev, Unable to acquire NFC clock!\n);
- retval = PTR_ERR(prv-clk);
- goto error;
+ return PTR_ERR(prv-clk);
}
clk_enable(prv-clk);
@@ -803,7 +782,6 @@ static int __devinit mpc5121_nfc_probe(struct
platform_device *op)
/* Detect NAND chips */
if (nand_scan(mtd, be32_to_cpup(chips_no))) {
dev_err(dev, NAND Flash not found !\n);
- devm_free_irq(dev, prv-irq, mtd);
retval = -ENXIO;
goto error;
}
@@ -828,7 +806,6 @@ static int __devinit mpc5121_nfc_probe(struct
platform_device *op)
default:
dev_err(dev, Unsupported NAND flash!\n);
- devm_free_irq(dev, prv-irq, mtd);
retval = -ENXIO;
goto error;
}
@@ -839,13 +816,12 @@ static int __devinit mpc5121_nfc_probe(struct
Re: [PATCH v2] memcg: first step towards hierarchical controller
On 09/03/2012 09:08 PM, Michal Hocko wrote: On Mon 03-09-12 19:46:51, Glauber Costa wrote: Here is a new attempt to lay down a path that will allow us to deprecate the non-hierarchical mode of operation from memcg. Unlike what I posted before, I am making this behavior conditional on a Kconfig option. Vanilla users will see no change in behavior unless they don't explicitly set this option to on. Which is the reason why I don't like this approach. Why would you enable the option in the first place? If you know the default should be 1 then you would already do that via cgconfig or directly, right? I think we should either change the default (which I am planning to do for the next OpenSUSE) or do it slow way suggested by Tejun. We really want to have as big testing coverage as possible for the default change and config option is IMHO not a way to accomplish this. Not sure you realize, Michal, but you actually agree with me and my patch, given your reasoning. If you plan to change it in OpenSUSE, you have two ways of doing so: You either carry a patch, which as simple as this is, is always undesirable, or you add one line to your distro config. Pick my patch, and do the later. This patch does exactly the do it slowly thing, but without introducing more churn, like mount options. Keep in mind that since there is the concern that direct upstream users won't see a sudden change in behavior, *every* way we choose to do it will raise the same question you posed: Why would you enable this in the first place? Be it a Kconfig, mount option, etc. The solution here is: Direct users of upstream kernels won't see a behavior change - as requested - but distributors will have a way to flip it without carrying a non-upstream patch. Distributions, however, are encouraged to set it. As I said, I plan to change the default with WARN_ONCE for both first cgroup created and default changed. It would be nice if other distributions could do the same but this might be tricky as nobody wants to regress and there are certain usecases which could really suffer (most of them fixable easily but there still might be some where use_hierarchy=0 is valid). tip: They can do the same without applying a non-upstream patch by using this patch and just changing their default config. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 v2] leds: Add new LED driver for lm355x chips
On Mon, Sep 3, 2012 at 3:29 PM, G.Shark Jeong gshark.je...@gmail.com wrote: From: G.Shark Jeong gshark.je...@gmail.com LM3554 and LM3556 have similar functions but very different register map. This driver is a general version for lm3554 and lm3556 both,led chips of TI. lm3556 driver can be replaced by this driver. LM3554 : The LM3554 is a 2 MHz fixed-frequency synchronous boost converter with 1.2A dual high side led drivers. Datasheet: www.ti.com/lit/ds/symlink/lm3554.pdf LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf Signed-off-by: G.Shark Jeong gshark.je...@gmail.com Thanks for adding work_queue stuff and please find my comments below. --- drivers/leds/Kconfig |8 +- drivers/leds/Makefile |2 +- drivers/leds/leds-lm3556.c| 512 - drivers/leds/leds-lm355x.c| 574 + include/linux/platform_data/leds-lm3556.h | 50 --- include/linux/platform_data/leds-lm355x.h | 66 6 files changed, 645 insertions(+), 567 deletions(-) delete mode 100644 drivers/leds/leds-lm3556.c create mode 100644 drivers/leds/leds-lm355x.c delete mode 100644 include/linux/platform_data/leds-lm3556.h create mode 100644 include/linux/platform_data/leds-lm355x.h diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index c96bbaa..4f6ced2 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -422,13 +422,13 @@ config LEDS_MAX8997 This option enables support for on-chip LED drivers on MAXIM MAX8997 PMIC. -config LEDS_LM3556 - tristate LED support for LM3556 Chip +config LEDS_LM355x + tristate LED support for LM355x Chips, LM3554 and LM3556 depends on LEDS_CLASS I2C select REGMAP_I2C help - This option enables support for LEDs connected to LM3556. - LM3556 includes Torch, Flash and Indicator functions. + This option enables support for LEDs connected to LM355x. + LM355x includes Torch, Flash and Indicator functions. config LEDS_OT200 tristate LED support for the Bachmann OT200 diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index a4429a9..b57a021 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -48,7 +48,7 @@ obj-$(CONFIG_LEDS_NETXBIG)+= leds-netxbig.o obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o obj-$(CONFIG_LEDS_RENESAS_TPU) += leds-renesas-tpu.o obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o -obj-$(CONFIG_LEDS_LM3556) += leds-lm3556.o +obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o # LED SPI Drivers diff --git a/drivers/leds/leds-lm3556.c b/drivers/leds/leds-lm3556.c deleted file mode 100644 index 3062abd..000 --- a/drivers/leds/leds-lm3556.c +++ /dev/null @@ -1,512 +0,0 @@ -/* - * Simple driver for Texas Instruments LM3556 LED Flash driver chip (Rev0x03) - * Copyright (C) 2012 Texas Instruments - * - * 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. - * - * Please refer Documentation/leds/leds-lm3556.txt file. - */ -#include linux/module.h -#include linux/delay.h -#include linux/i2c.h -#include linux/leds.h -#include linux/slab.h -#include linux/platform_device.h -#include linux/fs.h -#include linux/regmap.h -#include linux/platform_data/leds-lm3556.h - -#define REG_FILT_TIME (0x0) -#define REG_IVFM_MODE (0x1) -#define REG_NTC(0x2) -#define REG_INDIC_TIME (0x3) -#define REG_INDIC_BLINK(0x4) -#define REG_INDIC_PERIOD (0x5) -#define REG_TORCH_TIME (0x6) -#define REG_CONF (0x7) -#define REG_FLASH (0x8) -#define REG_I_CTRL (0x9) -#define REG_ENABLE (0xA) -#define REG_FLAG (0xB) -#define REG_MAX(0xB) - -#define IVFM_FILTER_TIME_SHIFT (3) -#define UVLO_EN_SHIFT (7) -#define HYSTERSIS_SHIFT(5) -#define IVM_D_TH_SHIFT (2) -#define IVFM_ADJ_MODE_SHIFT(0) -#define NTC_EVENT_LVL_SHIFT(5) -#define NTC_TRIP_TH_SHIFT (2) -#define NTC_BIAS_I_LVL_SHIFT (0) -#define INDIC_RAMP_UP_TIME_SHIFT (3) -#define INDIC_RAMP_DN_TIME_SHIFT (0) -#define INDIC_N_BLANK_SHIFT(4) -#define INDIC_PULSE_TIME_SHIFT (0) -#define INDIC_N_PERIOD_SHIFT (0) -#define
[PATCH 0/2] hwmon/lm70: changes to allow 4w with LM70 and add LM71/LM74
Hello, The two following patches do: 1) Allow the use of NS LM70 with a 4 wire SPI bus too, since the component allows both configuration 2) Adds support for NS LM71 and LM74 Regards Christophe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] hwmon/lm70: Allow 4wire SPI bus with LM70
Removing the 3wire limitation on LM70 as the component also allows operation on 4wire SPI bus Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -u linux-3.5-vanilla/drivers/hwmon/lm70.c linux-3.5/drivers/hwmon/lm70.c --- linux-3.5-vanilla/drivers/hwmon/lm70.c 2012-07-21 22:58:29.0 +0200 +++ linux-3.5/drivers/hwmon/lm70.c 2012-08-25 00:35:40.0 +0200 @@ -143,10 +143,6 @@ if (spi-mode (SPI_CPOL | SPI_CPHA)) return -EINVAL; - /* 3-wire link (shared SI/SO) for LM70 */ - if (chip == LM70_CHIP_LM70 !(spi-mode SPI_3WIRE)) - return -EINVAL; - /* NOTE: we assume 8-bit words, and convert to 16 bits manually */ p_lm70 = kzalloc(sizeof *p_lm70, GFP_KERNEL); diff -u linux-3.5-vanilla/Documentation/hwmon/lm70 linux-3.5/Documentation/hwmon/lm70 --- linux-3.5-vanilla/Documentation/hwmon/lm70 2012-07-21 22:58:29.0 +0200 +++ linux-3.5/Documentation/hwmon/lm70 2012-08-25 00:37:15.0 +0200 @@ -31,9 +31,8 @@ with a SPI master controller driver, see drivers/spi/spi_lm70llp.c and its associated documentation. -The TMP121/TMP123 are very similar; main differences are 4 wire SPI inter- -face (read only) and 13-bit temperature data (0.0625 degrees celsius reso- -lution). +The TMP121/TMP123 are very similar; main difference is 13-bit temperature +data (0.0625 degrees celsius resolution). Thanks to - -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] hwmon/lm70: Adds support for LM71 and LM74
Adding support for LM74 and LM71 chips
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
diff -u linux-3.5-vanilla/drivers/hwmon/Kconfig linux-3.5/drivers/hwmon/Kconfig
--- linux-3.5-vanilla/drivers/hwmon/Kconfig 2012-07-21 22:58:29.0
+0200
+++ linux-3.5/drivers/hwmon/Kconfig 2012-08-25 00:44:05.0 +0200
@@ -530,12 +530,12 @@
will be called lm63.
config SENSORS_LM70
- tristate National Semiconductor LM70 / Texas Instruments TMP121
+ tristate National Semiconductor LM70 and compatibles
depends on SPI_MASTER
help
If you say yes here you get support for the National Semiconductor
- LM70 and Texas Instruments TMP121/TMP123 digital temperature
- sensor chips.
+ LM70, LM71, LM74 and Texas Instruments TMP121/TMP123 digital tempera-
+ ture sensor chips.
This driver can also be built as a module. If so, the module
will be called lm70.
diff -u linux-3.5-vanilla/drivers/hwmon/lm70.c linux-3.5/drivers/hwmon/lm70.c
--- linux-3.5-vanilla/drivers/hwmon/lm70.c 2012-07-21 22:58:29.0
+0200
+++ linux-3.5/drivers/hwmon/lm70.c 2012-08-25 00:49:46.0 +0200
@@ -43,6 +43,8 @@
#define LM70_CHIP_LM70 0 /* original NS LM70 */
#define LM70_CHIP_TMP121 1 /* TI TMP121/TMP123 */
+#define LM70_CHIP_LM71 2 /* NS LM71 */
+#define LM70_CHIP_LM74 3 /* NS LM71 */
struct lm70 {
struct device *hwmon_dev;
@@ -88,9 +90,13 @@
* Celsius.
* So it's equivalent to multiplying by 0.25 * 1000 = 250.
*
-* TMP121/TMP123:
+* LM74 and TMP121/TMP123:
* 13 bits of 2's complement data, discard LSB 3 bits,
* resolution 0.0625 degrees celsius.
+*
+* LM71:
+* 14 bits of 2's complement data, discard LSB 2 bits,
+* resolution 0.0312 degrees celsius.
*/
switch (p_lm70-chip) {
case LM70_CHIP_LM70:
@@ -98,8 +104,13 @@
break;
case LM70_CHIP_TMP121:
+ case LM70_CHIP_LM74:
val = ((int)raw / 8) * 625 / 10;
break;
+
+ case LM70_CHIP_LM71:
+ val = ((int)raw / 4) * 3125 / 100;
+ break;
}
status = sprintf(buf, %d\n, val); /* millidegrees Celsius */
@@ -123,6 +134,12 @@
case LM70_CHIP_TMP121:
ret = sprintf(buf, tmp121\n);
break;
+ case LM71_CHIP_LM71:
+ ret = sprintf(buf, lm71\n);
+ break;
+ case LM74_CHIP_LM74:
+ ret = sprintf(buf, lm74\n);
+ break;
default:
ret = -EINVAL;
}
@@ -139,7 +156,7 @@
struct lm70 *p_lm70;
int status;
- /* signaling is SPI_MODE_0 for both LM70 and TMP121 */
+ /* signaling is SPI_MODE_0 */
if (spi-mode (SPI_CPOL | SPI_CPHA))
return -EINVAL;
@@ -198,6 +215,8 @@
static const struct spi_device_id lm70_ids[] = {
{ lm70, LM70_CHIP_LM70 },
{ tmp121, LM70_CHIP_TMP121 },
+ { lm71, LM70_CHIP_LM71 },
+ { lm74, LM70_CHIP_LM74 },
{ },
};
MODULE_DEVICE_TABLE(spi, lm70_ids);
@@ -215,5 +234,5 @@
module_spi_driver(lm70_driver);
MODULE_AUTHOR(Kaiwan N Billimoria);
-MODULE_DESCRIPTION(NS LM70 / TI TMP121/TMP123 Linux driver);
+MODULE_DESCRIPTION(NS LM70 and compatibles Linux driver);
MODULE_LICENSE(GPL);
diff -u linux-3.5-vanilla/Documentation/hwmon/lm70
linux-3.5/Documentation/hwmon/lm70
--- linux-3.5-vanilla/Documentation/hwmon/lm70 2012-07-21 22:58:29.0
+0200
+++ linux-3.5/Documentation/hwmon/lm70 2012-08-25 00:37:15.0 +0200
@@ -6,6 +6,10 @@
Datasheet: http://www.national.com/pf/LM/LM70.html
* Texas Instruments TMP121/TMP123
Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
+ * National Semiconductor LM71
+Datasheet: http://www.ti.com/product/LM71
+ * National Semiconductor LM74
+Datasheet: http://www.ti.com/product/LM74
Author:
Kaiwan N Billimoria kai...@designergraphix.com
@@ -31,9 +35,12 @@
with a SPI master controller driver, see drivers/spi/spi_lm70llp.c
and its associated documentation.
-The TMP121/TMP123 are very similar; main difference is 13-bit temperature
+The LM74 and TMP121/TMP123 are very similar; main difference is 13-bit
temperature
data (0.0625 degrees celsius resolution).
+The LM71 is also very similar; main difference is 14-bit temperature
+data (0.03125 degrees celsius resolution).
+
Thanks to
-
Jean Delvare kh...@linux-fr.org for mentoring the hwmon-side driver
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] virtio-scsi: introduce multiqueue support
On Tue, Sep 04, 2012 at 08:46:12AM +0200, Paolo Bonzini wrote:
Il 04/09/2012 04:21, Nicholas A. Bellinger ha scritto:
@@ -112,6 +118,9 @@ static void virtscsi_complete_cmd(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_cmd *cmd = buf;
struct scsi_cmnd *sc = cmd-sc;
struct virtio_scsi_cmd_resp *resp = cmd-resp.cmd;
+ struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+
+ atomic_dec(tgt-reqs);
As tgt-tgt_lock is taken in virtscsi_queuecommand_multi() before the
atomic_inc_return(tgt-reqs) check, it seems like using atomic_dec() w/o
smp_mb__after_atomic_dec or tgt_lock access here is not using atomic.h
accessors properly, no..?
No, only a single thing is being accessed, and there is no need to
order the decrement with respect to preceding or subsequent accesses to
other locations.
In other words, tgt-reqs is already synchronized with itself, and that
is enough.
I think your logic is correct and barrier is not needed,
but this needs better documentation.
(Besides, on x86 smp_mb__after_atomic_dec is a nop).
+static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+ struct virtio_scsi *vscsi = shost_priv(sh);
+ struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+ unsigned long flags;
+ u32 queue_num;
+
+ /* Using an atomic_t for tgt-reqs lets the virtqueue handler
+ * decrement it without taking the spinlock.
+ */
Above comment is not really helpful - reader can be safely assumed to
know what atomic_t is.
Please delete, and replace with the text from commit log
that explains the heuristic used to select req_vq.
Also please add a comment near 'reqs' definition.
Something like number of outstanding requests - used to detect idle
target.
+ spin_lock_irqsave(tgt-tgt_lock, flags);
Looks like this lock can be removed - req_vq is only
modified when target is idle and only used when it is
not idle.
+ if (atomic_inc_return(tgt-reqs) == 1) {
+ queue_num = smp_processor_id();
+ while (unlikely(queue_num = vscsi-num_queues))
+ queue_num -= vscsi-num_queues;
+ tgt-req_vq = vscsi-req_vqs[queue_num];
+ }
+ spin_unlock_irqrestore(tgt-tgt_lock, flags);
+ return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
+
.
+static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+ struct virtio_scsi *vscsi = shost_priv(sh);
+ struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+
+ atomic_inc(tgt-reqs);
+ return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
Here, reqs is unused - why bother incrementing it?
A branch on completion would be cheaper IMHO.
virtio-scsi multiqueue has a performance benefit up to 20%
To be fair, you could be running in single queue mode.
In that case extra atomics and indirection that this code
brings will just add overhead without benefits.
I don't know how significant would that be.
--
MST
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 page table
On 09/03/2012 02:26 AM, Jiri Kosina wrote: On Sun, 2 Sep 2012, Xin Tong wrote: 3. can two different processes have their CR3 being the same value even though they have different first level page tables ? Yes, if they are created by clone(CLONE_VM). In such case they share the same mm_struct, and therefore mm_struct-pgd (which is exactly what is loaded into cr3 in switch_mm()) is the same. Is this the COW mechanism in linux. what if the cloned process need to have set of its own pages later. do the CR3s for the 2 processes become different at that point ? That is a different story. COW is applied on fork() (i.e. spawning new process), not on clone(CLONE_VM) (i.e. spawning new thread). Yeah, and unshare(2) does not implement the flag that reverses the effects of CLONE_VM. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: ux500: Provide SMSC911x fixed-regulator when not booting DT
On Mon, Sep 3, 2012 at 3:33 PM, Lee Jones lee.jo...@linaro.org wrote: Author: Lee Jones lee.jo...@linaro.org Date: Fri Aug 24 12:40:58 2012 +0100 ARM: ux500: Provide SMSC911x fixed-regulator when not booting DT The SMSC911x Ethernet chip requires a fixed-regulator in order to function correctly. We have previously provided a means to obtain this during a Device Tree boot, however nothing has been put into place when booting with a non-DT kernel. This patch aims to change that. Signed-off-by: Lee Jones lee.jo...@linaro.org You forgot to add select REGULATOR_FIXED_VOLTAGE to the MOP500 Kconfig entry, but I added it when applying. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warnings after merge of the drm tree
On Tue, Sep 4, 2012 at 10:22 AM, Dave Airlie airl...@linux.ie wrote:
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
dependencies (USB_SUPPORT USB_OHCI_HCD)
warning: (PPC_PS3 PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which
has unmet direct dependencies (USB_SUPPORT USB_OHCI_HCD)
warning: (PPC_PS3 PPC_CELLEB USB_EHCI_HCD_PMC_MSP
XPS_USB_HCD_XILINX USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO
which has unmet direct dependencies (USB_SUPPORT USB_EHCI_HCD
(PPC_CELLEB || PPC_PS3 || 440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX ||
PPC_MPC512x || CPU_CAVIUM_OCTEON || PMC_MSP || SPARC_LEON || MIPS_SEAD3))
The x86_64 allmodconfig produces these:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (MOUSE_APPLETOUCH MOUSE_BCM5974 MOUSE_SYNAPTICS_USB
JOYSTICK_XPAD TABLET_USB_ACECAD TABLET_USB_AIPTEK
TABLET_USB_HANWANG TABLET_USB_KBTAB TABLET_USB_WACOM
TOUCHSCREEN_USB_COMPOSITE INPUT_ATI_REMOTE2 INPUT_KEYSPAN_REMOTE
INPUT_POWERMATE INPUT_YEALINK INPUT_CM109 RC_ATI_REMOTE
IR_IMON IR_MCEUSB IR_REDRAT3 IR_STREAMZAP IR_IGUANA
IR_TTUSBIR DRM_USB) selects USB which has unmet direct dependencies
(USB_SUPPORT USB_ARCH_HAS_HCD)
Maybe introduced by commit df0b34430072 (drm/usb: select USB_SUPPORT in
Kconfig), maybe interacting with a commit 8f057d7bca54 (gpu/mfd/usb:
Fix USB randconfig problems) from Linus' tree (that added depends on
USB_ARCH_HAS_HCD to config DRM_USB and config DRM_UDL).
I have left this mess for now, but it needs addressing.
I have sent a fix (drm/udl: usb: Fix recursive Kconfig dependency)
for this mess and pinged airlied on IRC.
NOTE: I saw this when I merged drm(-intel){-fixes,next} into next-20120824.
I[ve pushed it to drm-next now hopefully it will resolve the mess.
Great and thanks!
Can't say if the label of my patch should be changed to drm/usb: ...
as the culprit commit df0b34430072 (drm/usb: select USB_SUPPORT in
Kconfig) has it and the fix is done in drm/usb Kconfig definition.
( Thinking loud of people searching within (git-)logs. )
For me the current status of drm-next is OK (next time I do better).
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=df0b344300724e00db9fff7eb6406eb91f450b91
thanks,
Dave.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
On 09/04/2012 10:42 AM, Artem Bityutskiy wrote: Aiaiai! :-) [1] [2] I've build-tested this using aiaiai and it reports that this change breaks the build: dedekind@blue:~/git/maintaining$ ./verify ../l2-mtd/ mpc5121_nfc ~/tmp/julia2.mbox Tested the patch(es) on top of the following commits: ba64756 Quick fixes - applied by aiaiai 651c6fa JFFS2: don't fail on bitflips in OOB e22ac84 mtd: autcpu12-nvram: drop frees of devm_ alloc'd data ea9d312 mtd: cmdlinepart: minor cleanups Failed to build the following commit for configuration powerpc-mpc512x_defconfig (architecture powerpc): 0fe13ab drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups ... drivers/mtd/nand/mpc5121_nfc.c: In function 'mpc5121_nfc_probe': drivers/mtd/nand/mpc5121_nfc.c:622:28: warning: variable 'regs_size' set but not used [-Wunused-but-set-variable] drivers/mtd/nand/mpc5121_nfc.c:622:16: warning: variable 'regs_paddr' set but not used [-Wunused-but-set-variable] drivers/built-in.o: In function `mpc5121_nfc_probe': mpc5121_nfc.c:(.devinit.text+0x2a14): undefined reference to `devm_clk_get' make[1]: *** [vmlinux] Error 1 I do not really know why, but it seems that clock framework is not supported for powerpc. CCing the PPC mailing list. Preserved the context below for the PPC people. I've been bitten by the same issue recently, also cause by one of these cocci devm patches. devm_clk_get is only available if the generic clk_get/clk_put implementation is used. Not all architectures do this and some implement their own clk_get/clk_put, etc functions. Since devm_clk_get is merely a wrapper around clk_get/clk_put there is no reason why it should depend CLKDEV_LOOKUP. I've prepared a patch which makes them generically available if the clk_get/clk_put are implemented (i.e. if HAVE_CLK is set), but it is on a different machine right now, will try to submit it later today. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 arm-soc tree with the arm-current tree
On Tue, Sep 04, 2012 at 08:08:24AM +, Arnd Bergmann wrote: On Tuesday 04 September 2012, Stephen Rothwell wrote: Today's linux-next merge of the arm-soc tree got a conflict in arch/arm/mm/mmu.c between commit a849088aa155 (ARM: Fix ioremap() of address zero) from the arm-current tree and commit c2794437091a (ARM: Add fixed PCI i/o mapping) from the arm-soc tree. I am not sure how to fix this, so I have used the arm-current version of the change to pmd_empty_section_gap() since that changed the vm-flags. It may be that just changing the vm-flags value in vm_reserve_area_early() would be ok? If I read this correctly, we want pci_reserve_io to use VM_ARM_STATIC_MAPPING while pmd_empty_section_gap should use VM_ARM_EMPTY_MAPPING, so we probably want to add a flag argument to the vm_reserve_area_early() function. Whereas Rob said to me that both can use VM_ARM_EMPTY_MAPPING when I queried this conflict last week. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 4/9] pktcdvd: Switch to bio_kmalloc()
On Tue, 28 Aug 2012, Tejun Heo wrote: This is prep work for killing bi_destructor - previously, pktcdvd had its own pkt_bio_alloc which was basically duplication bio_kmalloc(), necessitating its own bi_destructor implementation. How was this tested? I have now tested it and it works properly. You can add Signed-off-by: Jiri Kosina jkos...@suse.cz once you will be pushing the patchset through (I will be pushing MAINTAINERS update through my tree to Jens separately). -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: ux500: Provide SMSC911x fixed-regulator when not booting DT
On Tue, Sep 04, 2012 at 10:53:32AM +0200, Linus Walleij wrote: On Mon, Sep 3, 2012 at 3:33 PM, Lee Jones lee.jo...@linaro.org wrote: Author: Lee Jones lee.jo...@linaro.org Date: Fri Aug 24 12:40:58 2012 +0100 ARM: ux500: Provide SMSC911x fixed-regulator when not booting DT The SMSC911x Ethernet chip requires a fixed-regulator in order to function correctly. We have previously provided a means to obtain this during a Device Tree boot, however nothing has been put into place when booting with a non-DT kernel. This patch aims to change that. Signed-off-by: Lee Jones lee.jo...@linaro.org You forgot to add select REGULATOR_FIXED_VOLTAGE to the MOP500 Kconfig entry, but I added it when applying. I didn't forget. I intentionally left it out because it's unconditionally set in the defconfig. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [ASoC] Fix: Revert 'ASoC: imx-ssi: Remove mono support'.
On 4 September 2012 08:35, Gaëtan Carlier gcem...@gmail.com wrote:
Hi Javier,
On 09/03/2012 10:27 AM, Javier Martin wrote:
The following commit should be reverted:
0865a75d4166bddc533fd50831829ceefb94f9b0
The bug this patch is meant to solve doesn't occur in Visstrim_M10 boards.
Furthermore, after applying this patch sound in Visstrim_M10 is played
at slower rates.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
diff --git b/sound/soc/fsl/imx-ssi.c a/sound/soc/fsl/imx-ssi.c
index ac337ac..28dd76c 100644
--- b/sound/soc/fsl/imx-ssi.c
+++ a/sound/soc/fsl/imx-ssi.c
@@ -380,13 +380,13 @@ static int imx_ssi_dai_probe(struct snd_soc_dai
*dai)
static struct snd_soc_dai_driver imx_ssi_dai = {
.probe = imx_ssi_dai_probe,
.playback = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
When applied on linux-next-20120824, the patch failed because original
imx-ssi.c file looks like :
static struct snd_soc_dai_driver imx_ssi_dai = {
.probe = imx_ssi_dai_probe,
.playback = {
/* The SSI does not support monaural audio. */
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.ops = imx_ssi_pcm_dai_ops,
};
The comment line is missing in your patch. Here is the right patch :
@@ -378,18 +378,17 @@ static int imx_ssi_dai_probe(struct snd_soc_dai *dai)
}
static struct snd_soc_dai_driver imx_ssi_dai = {
.probe = imx_ssi_dai_probe,
.playback = {
- /* The SSI does not support monaural audio. */
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.ops = imx_ssi_pcm_dai_ops,
Regards,
Gaëtan Carlier.
Mark,
could you pick up the fixed patch sent by Gaëtan?
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
Hi,
On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote:
diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
new file mode 100644
index 000..bacf2a9
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cbus.c
@@ -0,0 +1,369 @@
+/*
+ * CBUS I2C driver for Nokia Internet Tablets.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
+ * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/io.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/i2c-cbus.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+
+struct cbus_host {
+ /* host lock */
+ spinlock_t lock;
+
+ struct device *dev;
+
+ int clk_gpio;
+ int dat_gpio;
+ int sel_gpio;
+};
+
+/**
+ * cbus_send_bit - sends one bit over the bus
+ * @host: the host we're using
+ * @bit: one bit of information to send
+ * @input: whether to set data pin as input after sending
+ */
+static int cbus_send_bit(struct cbus_host *host, unsigned bit,
+ unsigned input)
+{
+ int ret = 0;
+
+ gpio_set_value(host-dat_gpio, bit ? 1 : 0);
+ gpio_set_value(host-clk_gpio, 1);
+
+ /* The data bit is read on the rising edge of CLK */
+ if (input)
+ ret = gpio_direction_input(host-dat_gpio);
+
+ gpio_set_value(host-clk_gpio, 0);
+
+ return ret;
+}
+
+/**
+ * cbus_send_data - sends @len amount of data over the bus
+ * @host: the host we're using
+ * @data: the data to send
+ * @len: size of the transfer
+ * @input: whether to set data pin as input after sending
+ */
+static int cbus_send_data(struct cbus_host *host, unsigned data, unsigned
len,
+ unsigned input)
+{
+ int ret = 0;
+ int i;
+
+ for (i = len; i 0; i--) {
+ ret = cbus_send_bit(host, data (1 (i - 1)),
+ input (i == 1));
+ if (ret 0)
+ goto out;
+ }
+
+out:
+ return ret;
+}
+
+/**
+ * cbus_receive_bit - receives one bit from the bus
+ * @host: the host we're using
+ */
+static int cbus_receive_bit(struct cbus_host *host)
+{
+ int ret;
+
+ gpio_set_value(host-clk_gpio, 1);
+ ret = gpio_get_value(host-dat_gpio);
+ if (ret 0)
+ goto out;
+ gpio_set_value(host-clk_gpio, 0);
+
+out:
+ return ret;
+}
+
+/**
+ * cbus_receive_word - receives 16-bit word from the bus
+ * @host: the host we're using
+ */
+static int cbus_receive_word(struct cbus_host *host)
+{
+ int ret = 0;
+ int i;
+
+ for (i = 16; i 0; i--) {
+ int bit = cbus_receive_bit(host);
+
+ if (bit 0)
+ goto out;
+
+ if (bit)
+ ret |= 1 (i - 1);
+ }
+
+out:
+ return ret;
+}
+
+/**
+ * cbus_transfer - transfers data over the bus
+ * @host: the host we're using
+ * @rw: read/write flag
+ * @dev: device address
+ * @reg: register address
+ * @data: if @rw == I2C_SBUS_WRITE data to send otherwise 0
+ */
+static int cbus_transfer(struct cbus_host *host, char rw, unsigned dev,
+ unsigned reg, unsigned data)
+{
+ unsigned long flags;
+ int ret;
+
+ /* We don't want interrupts disturbing our transfer */
+ spin_lock_irqsave(host-lock, flags);
+
+ /* Reset state and start of transfer, SEL stays down during transfer */
+ gpio_set_value(host-sel_gpio, 0);
+
+ /* Set the DAT pin to output */
+ gpio_direction_output(host-dat_gpio, 1);
+
+ /* Send the device address */
+ ret = cbus_send_data(host, dev, 3, 0);
+ if (ret 0) {
+ dev_dbg(host-dev, failed sending device addr\n);
+ goto out;
+ }
+
+ /* Send the rw flag */
+ ret = cbus_send_bit(host, rw == I2C_SMBUS_READ, 0);
+ if (ret 0) {
+ dev_dbg(host-dev, failed sending read/write flag\n);
+ goto out;
+ }
+
+ /* Send the device address */
+ ret = cbus_send_data(host, reg, 5, rw == I2C_SMBUS_READ);
+ if (ret 0) {
+ dev_dbg(host-dev, failed sending register addr\n);
+ goto out;
+ }
+
+
[PATCH] usb: otg: Move phy interface to separate file.
As otg.h is containing lots of phy interface related
stuff, moving all phy interface related stuff to new
file named phy.h
Signed-off-by: Venu Byravarasu vbyravarasu@xx
---
include/linux/usb/otg.h | 198 +
include/linux/usb/phy.h | 208 +++
2 files changed, 209 insertions(+), 197 deletions(-)
create mode 100644 include/linux/usb/phy.h
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 16dc520..65a2b6a 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -9,7 +9,7 @@
#ifndef __LINUX_USB_OTG_H
#define __LINUX_USB_OTG_H
-#include linux/notifier.h
+#include linux/usb/phy.h
/* OTG defines lots of enumeration states before device reset */
enum usb_otg_state {
@@ -35,31 +35,6 @@ enum usb_otg_state {
OTG_STATE_A_VBUS_ERR,
};
-enum usb_phy_events {
- USB_EVENT_NONE, /* no events or cable disconnected */
- USB_EVENT_VBUS, /* vbus valid event */
- USB_EVENT_ID, /* id was grounded */
- USB_EVENT_CHARGER, /* usb dedicated charger */
- USB_EVENT_ENUMERATED, /* gadget driver enumerated */
-};
-
-/* associate a type with PHY */
-enum usb_phy_type {
- USB_PHY_TYPE_UNDEFINED,
- USB_PHY_TYPE_USB2,
- USB_PHY_TYPE_USB3,
-};
-
-struct usb_phy;
-
-/* for transceivers connected thru an ULPI interface, the user must
- * provide access ops
- */
-struct usb_phy_io_ops {
- int (*read)(struct usb_phy *x, u32 reg);
- int (*write)(struct usb_phy *x, u32 val, u32 reg);
-};
-
struct usb_otg {
u8 default_a;
@@ -85,120 +60,9 @@ struct usb_otg {
};
-/*
- * the otg driver needs to interact with both device side and host side
- * usb controllers. it decides which controller is active at a given
- * moment, using the transceiver, ID signal, HNP and sometimes static
- * configuration information (including board isn't wired for otg).
- */
-struct usb_phy {
- struct device *dev;
- const char *label;
- unsigned int flags;
-
- enum usb_phy_type type;
- enum usb_otg_state state;
- enum usb_phy_events last_event;
-
- struct usb_otg *otg;
-
- struct device *io_dev;
- struct usb_phy_io_ops *io_ops;
- void __iomem*io_priv;
-
- /* for notification of usb_phy_events */
- struct atomic_notifier_head notifier;
-
- /* to pass extra port status to the root hub */
- u16 port_status;
- u16 port_change;
-
- /* to support controllers that have multiple transceivers */
- struct list_headhead;
-
- /* initialize/shutdown the OTG controller */
- int (*init)(struct usb_phy *x);
- void(*shutdown)(struct usb_phy *x);
-
- /* effective for B devices, ignored for A-peripheral */
- int (*set_power)(struct usb_phy *x,
- unsigned mA);
-
- /* for non-OTG B devices: set transceiver into suspend mode */
- int (*set_suspend)(struct usb_phy *x,
- int suspend);
-
- /* notify phy connect status change */
- int (*notify_connect)(struct usb_phy *x, int port);
- int (*notify_disconnect)(struct usb_phy *x, int port);
-};
-
-
-/* for board-specific init logic */
-extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
-extern void usb_remove_phy(struct usb_phy *);
-
-/* helpers for direct access thru low-level io interface */
-static inline int usb_phy_io_read(struct usb_phy *x, u32 reg)
-{
- if (x-io_ops x-io_ops-read)
- return x-io_ops-read(x, reg);
-
- return -EINVAL;
-}
-
-static inline int usb_phy_io_write(struct usb_phy *x, u32 val, u32 reg)
-{
- if (x-io_ops x-io_ops-write)
- return x-io_ops-write(x, val, reg);
-
- return -EINVAL;
-}
-
-static inline int
-usb_phy_init(struct usb_phy *x)
-{
- if (x-init)
- return x-init(x);
-
- return 0;
-}
-
-static inline void
-usb_phy_shutdown(struct usb_phy *x)
-{
- if (x-shutdown)
- x-shutdown(x);
-}
-
-/* for usb host and peripheral controller drivers */
#ifdef CONFIG_USB_OTG_UTILS
-extern struct usb_phy *usb_get_phy(enum usb_phy_type type);
-extern struct usb_phy *devm_usb_get_phy(struct device *dev,
- enum usb_phy_type type);
-extern void usb_put_phy(struct usb_phy *);
-extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
extern const char *otg_state_string(enum usb_otg_state state);
#else
-static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
-{
- return NULL;
-}
-
-static inline struct usb_phy *devm_usb_get_phy(struct device *dev,
- enum usb_phy_type type)
-{
- return NULL;
-}
-
-static inline void usb_put_phy(struct
Re: [PATCH 3/3] proc: use kzalloc instead of kmalloc and memset
2012/9/4 Ryan Mallon rmal...@gmail.com On 04/09/12 00:14, yan wrote: Signed-off-by: yan clouds@gmail.com --- fs/proc/generic.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/proc/generic.c b/fs/proc/generic.c index 9e8f631..38de015 100644 --- a/fs/proc/generic.c +++ b/fs/proc/generic.c @@ -616,10 +616,9 @@ static struct proc_dir_entry *__proc_create(struct proc_dir_entry **parent, len = strlen(fn); - ent = kmalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL); + ent = kzalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL); if (!ent) goto out; - memset(ent, 0, sizeof(struct proc_dir_entry)); memcpy(ent-name, fn, len + 1); ent-namelen = len; ent-mode = mode; Note that this change results in slightly different behaviour. Before your change only sizeof(struct proc_dir_entry) is zero'ed by memset, and then the name is filled in (the len + 1 part). After your change the structure and the name field are both zeroed, so the name field is being written to twice. The cost is probably negligible though. Oh, I didn't notice that actually. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] mm: introduce a safer interface to check whether a page is managed by SLxB
At 07/03/2012 11:57 AM, Jiang Liu Wrote:
Several subsystems, including memory-failure, swap, sparse, DRBD etc,
use PageSlab() to check whether a page is managed by SLAB/SLUB/SLOB.
And they treat slab pages differently from pagecache/anonymous pages.
But it's unsafe to use PageSlab() to detect whether a page is managed by
SLUB. SLUB allocates compound pages when page order is bigger than 0 and
only sets PG_slab on head pages. So if a SLUB object is hosted by a tail
page, PageSlab() will incorrectly return false for that object.
Following code from sparse.c triggers this issue, which causes failure
when removing a hot-added memory device.
Hi, Liu
What is the status of this patch?
I encounter the same problem when removing a hot-added memory device. It
causes the kernel panicked
Thanks
Wen Congyang
/*
* Check to see if allocation came from hot-plug-add
*/
if (PageSlab(usemap_page)) {
kfree(usemap);
if (memmap)
__kfree_section_memmap(memmap, PAGES_PER_SECTION);
return;
}
So introduce a transparent huge page and compound page safe macro as below
to check whether a page is managed by SLAB/SLUB/SLOB allocator.
#define page_managed_by_slab(page) (!!PageSlab(compound_trans_head(page)))
Signed-off-by: Jiang Liu liu...@gmail.com
---
arch/arm/mm/init.c |3 ++-
arch/ia64/kernel/mca_drv.c |2 +-
arch/unicore32/mm/init.c |3 ++-
crypto/scatterwalk.c |2 +-
drivers/ata/libata-sff.c |3 ++-
drivers/block/drbd/drbd_main.c |3 ++-
fs/proc/page.c |4 ++--
include/linux/slab.h |7 +++
mm/memory-failure.c|6 +++---
mm/sparse.c|4 +---
10 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index f54d592..73ff340 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -18,6 +18,7 @@
#include linux/initrd.h
#include linux/of_fdt.h
#include linux/highmem.h
+#include linux/huge_mm.h
#include linux/gfp.h
#include linux/memblock.h
#include linux/dma-contiguous.h
@@ -116,7 +117,7 @@ void show_mem(unsigned int filter)
reserved++;
else if (PageSwapCache(page))
cached++;
- else if (PageSlab(page))
+ else if (page_managed_by_slab(page))
slab++;
else if (!page_count(page))
free++;
diff --git a/arch/ia64/kernel/mca_drv.c b/arch/ia64/kernel/mca_drv.c
index 1c2e894..4415bb6 100644
--- a/arch/ia64/kernel/mca_drv.c
+++ b/arch/ia64/kernel/mca_drv.c
@@ -136,7 +136,7 @@ mca_page_isolate(unsigned long paddr)
return ISOLATE_NG;
/* kick pages having attribute 'SLAB' or 'Reserved' */
- if (PageSlab(p) || PageReserved(p))
+ if (page_managed_by_slab(p) || PageReserved(p))
return ISOLATE_NG;
/* add attribute 'Reserved' and register the page */
diff --git a/arch/unicore32/mm/init.c b/arch/unicore32/mm/init.c
index de186bd..829a0d9 100644
--- a/arch/unicore32/mm/init.c
+++ b/arch/unicore32/mm/init.c
@@ -21,6 +21,7 @@
#include linux/sort.h
#include linux/dma-mapping.h
#include linux/export.h
+#include linux/huge_mm.h
#include asm/sections.h
#include asm/setup.h
@@ -83,7 +84,7 @@ void show_mem(unsigned int filter)
reserved++;
else if (PageSwapCache(page))
cached++;
- else if (PageSlab(page))
+ else if (page_managed_by_slab(page))
slab++;
else if (!page_count(page))
free++;
diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index 7281b8a..a20e019 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -54,7 +54,7 @@ static void scatterwalk_pagedone(struct scatter_walk *walk,
int out,
struct page *page;
page = sg_page(walk-sg) + ((walk-offset - 1) PAGE_SHIFT);
- if (!PageSlab(page))
+ if (!page_managed_by_slab(page))
flush_dcache_page(page);
}
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index d8af325..1ab8378 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -38,6 +38,7 @@
#include linux/module.h
#include linux/libata.h
#include linux/highmem.h
+#include linux/huge_mm.h
#include libata.h
@@ -734,7 +735,7 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
do_write);
}
- if (!do_write !PageSlab(page))
+ if (!do_write !page_managed_by_slab(page))
Re: [PATCH v2] usb: otg: Move phy interface to separate file.
Hi Felipe, On Monday 03 September 2012 07:43 PM, Felipe Balbi wrote: * PGP Signed by an unknown key Hi, On Wed, Aug 29, 2012 at 12:17:01PM +0530, Venu Byravarasu wrote: As otg.h is containing lots of phy interface related stuff, moving all phy interface related stuff to new file named phy.h Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com this doesn't apply to my xceiv branch. Please rebase there so I don't cause any issues to your patch ;-) Rebased the change in your tree and pushed a patch. Plz merge. Thanks, Venu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: need help on development of linux kernel
Dear Sir/Madam, Thank you for your support.I want to know is the linux kernel cpu scheduling part optimized for scalable multi core architecture.If not then what are the scope if improvements?Can you help me? thanking you, waiting for your reply, yours faithfully, sachinagarwalla - Original Message - From: Cong Wang xiyou.wangc...@gmail.com To: Sachin Agarwalla sachin.agarwa...@cse.iitkgp.ernet.in Cc: linux-kernel linux-kernel@vger.kernel.org Sent: Tuesday, September 4, 2012 12:29:21 PM Subject: Re: need help on development of linux kernel On 08/30/2012 12:15 PM, Sachin Agarwalla wrote: Dear Sir/Madam, I have some questions on development of linux kernel as follows:- 1.I want to know the location of files in linux kernel source code that contains timer initialization and scheduler part. Scheduler source code is in kernel/sched/* files. 2.Also I want to know location of header files(or library files) that are present in the above files. include/linux/sched.h 3.Is there any version of linux kernel that uses openmp or inteltbb or parallelc tool. No, kernel doesn't use any libraries including libc. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] perf ui/browser: Add a browser for perf script
Hi Namhyung,
Thanks for your kind and thorough reviews.
On Tue, 4 Sep 2012 10:57:35 +0900
Namhyung Kim namhy...@kernel.org wrote:
On Mon, 3 Sep 2012 16:14:31 +0800, Feng Tang wrote:
Create a script browser, so that user can check all the available
scripts and run them inside the main perf report or annotation
browsers, for all the perf samples or samples belong to one
thread/symbol.
The work flow is, users can use function key to list all the available
scripts in system and chose one, which will be executed with
popen(perf script -s xxx.xx,) and all the output lines are put into
one ui browser, pressing 'q' or left arrow key will make it return
to previous browser.
It could be used for TUI interface of perf script itself too (at least
for --list option) IMHO.
Do you mean make the perf script -l to be shown in a browser, or we
use the same popen(perf script -l) way to cache and list the all the
scripts so that we don't need the find_scripts()?
Please be noted, most of the in-tree scripts with name xxxtop are
dynamically run and not supported by this static browser.
If so, wouldn't it be better adding a filter not to show those
unsupported scripts somehow?
Good idea, will simply filter them in next version.
You can run the event_analyzing_sample.py for example.
Signed-off-by: Feng Tang feng.t...@intel.com
---
+
+/* 160 bytes for one output line */
+#define AVERAGE_LINE_LEN 160
+
+struct script_line {
+ struct list_head node;
+ char line[AVERAGE_LINE_LEN];
+};
+
+struct perf_script_browser {
+ struct ui_browser b;
+ struct list_head entries;
+ const char *script_name;
+ int nr_lines;
+};
+
+#define SCRIPT_NAMELEN 40
+#define SCRIPT_MAX_NO 32
+#define SCRIPT_FULLPATH_LEN 128
I'm not sure these magic numbers are enough.
+
+/* Return 0 on success */
+static int list_scripts(char *script_name)
+{
+ char *buffer, *scripts[SCRIPT_MAX_NO], *scripts_path[SCRIPT_MAX_NO];
+ int i, num, choice, ret = -1;
+
+ /* Preset the script name to SCRIPT_NAMELEN */
+ buffer = zalloc(SCRIPT_MAX_NO * (SCRIPT_NAMELEN + SCRIPT_FULLPATH_LEN));
+ if (!buffer)
+ return ret;
+
+ for (i = 0; i SCRIPT_MAX_NO; i++) {
+ scripts[i] = buffer + i * (SCRIPT_NAMELEN +
SCRIPT_FULLPATH_LEN);
+ scripts_path[i] = scripts[i] + SCRIPT_NAMELEN;
+ }
+
+ num = find_scripts(scripts, scripts_path);
+ if (num) {
It should be:
if (num 0) {
since the find_scripts() can return -1.
Yes, as you pointed out in the other review.
+
+ fp = popen(cmd, r);
+ if (!fp)
+ goto exit;
+
+ while ((retlen = getline(line, len, fp)) != -1) {
+ strcpy(sline[nr_entries].line, line);
What if the len is larger than sline[].line?
That's a problem, how about adding a check for retlen and cut that
line to fit the SCRIPT_FULLPATH_LEN? Or we just wrap the long line
by using several struct script_line to save it?
+ list_add_tail(sline[nr_entries].node, script.entries);
+
+ if (script.b.width retlen)
+ script.b.width = retlen;
+ nr_entries++;
I think you need this too:
if (nr_entries = MAX_LINES)
break;
+ }
+
+ script.nr_lines = nr_entries;
+ script.b.nr_entries = nr_entries;
+ script.b.entries = script.entries;
+
+ ret = script_browser__run(script);
+
+ if (line)
+ free(line);
No pclose(fp) ?
+
+exit:
+ free(sline);
+ return ret;
+}
diff --git a/tools/perf/ui/browsers/scripts.h
b/tools/perf/ui/browsers/scripts.h
new file mode 100644
index 000..011baa8
--- /dev/null
+++ b/tools/perf/ui/browsers/scripts.h
@@ -0,0 +1,5 @@
+#ifndef _PERF_UI_BROWSER_BROWSER_H_
+#define _PERF_UI_BROWSER_BROWSER_H_ 1
I guess you want _PERF_UI_BROWSER_SCRIPT_H_ ?
Exactly.
I'll address the comments in this email and those in other emails. thanks!
- Feng
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 RESEND 1/2] i2c: pnx: Fix bit definitions
On Mon, Sep 03, 2012 at 10:16:22PM +0200, Roland Stigge wrote: Hi Wolfram, On 20/08/12 19:55, Wolfram Sang wrote: I've never had my hands on a PNX4008 chip at NXP, but I do believe they are the same IP. That specific I2C IP was used in a number of NXP/Phillips chips besides the PNX4008/LPC32xx. I don't think there are any PNX4008's in the wild, and even working in NXP, I can't find any non-marketing reference material for that part (including the user manual). Thanks for the heads up. I'll apply both patches, then. Should I consider the two patches as applied now (where? i2c-embedded?), or should I resend? ;-) I will apply them these days and then let them stay in linux-next for a few days. So, I'd think they should go in for rc6. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH 0/7] use interval trees for anon rmap
This patch series applies on top of the previous ones currently queued into Andrew's -mm tree (the rbtree, augmented rbtree and interval tree changes). The goal here is to use interval trees to replace the same_anon_vma linked list, and avoid anon rmap scalability issues when a given process has many vmas linked onto the same anon_vma (as can easily happen when a large vma is broken up into smaller chunks using mprotect or munmap). Patch 1 modifies the generic interval tree implementation and as such, it can be seen as an amendment to the previous patch series which had introduced it. Patch 2 makes the anon_vma locking more strict in vma_adjust(), fixing an issue I noticed when mprotect adjusts the boundary between two vmas and only the second one has an anon_vma assigned. Patch 3 makes the anon_vma locking more strict in move_ptes(). This is a temporary solution to make things simpler while the anon rmap interval tree is being introduced. Patch 7 later relaxes the locking again for the most common cases. Patch 4 implements the anon rmap interval tree and uses it to replace the same_anon_vma linked list. Patch 5 eliminates the error case in vma_address() - the call sites have gotten their vma's from an interval tree so that the desired pgoff (and address) are guaranteed to fall within the vma's interval. Patch 6 adds a build option for the existing DEBUG_MM_RB code, and extends it to check that vma's intervals have not been modified since the vmas were added onto their interval trees. Patch 7 avoids taking rmap locks in move_ptes() during exec() and for the common cases of mremap(). The most common case where mremap() would still take these locks would be if part of a large vma had been previously moved and is now being moved back to its original location. I don't expect this to be very frequent, though, so move_ptes() should be as efficient as it was before patch 3 for all likely cases. Michel Lespinasse (7): mm: interval tree updates mm: fix potential anon_vma locking issue in mprotect() mm anon rmap: remove anon_vma_moveto_tail mm anon rmap: replace same_anon_vma linked list with an interval tree. mm rmap: remove vma_address check for address inside vma mm: add CONFIG_DEBUG_VM_RB build option mm: avoid taking rmap locks in move_ptes() fs/exec.c |2 +- include/linux/interval_tree_generic.h | 191 include/linux/interval_tree_tmpl.h| 219 - include/linux/mm.h| 29 - include/linux/rmap.h | 15 ++- kernel/fork.c |7 +- lib/Kconfig.debug |9 ++ lib/interval_tree.c | 15 +-- mm/huge_memory.c |9 +- mm/interval_tree.c| 109 - mm/ksm.c |9 +- mm/memory-failure.c |5 +- mm/mmap.c | 100 +++- mm/mremap.c | 65 ++ mm/rmap.c | 117 +- 15 files changed, 484 insertions(+), 417 deletions(-) create mode 100644 include/linux/interval_tree_generic.h delete mode 100644 include/linux/interval_tree_tmpl.h -- 1.7.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] mm: fix potential anon_vma locking issue in mprotect()
This change fixes an anon_vma locking issue in the following situation:
- vma has no anon_vma
- next has an anon_vma
- vma is being shrunk / next is being expanded, due to an mprotect call
We need to take next's anon_vma lock to avoid races with rmap users
(such as page migration) while next is being expanded.
This change also removes an optimization which avoided taking anon_vma
lock during brk adjustments. We could probably make that optimization
work again, but the following anon rmap change would break it,
so I kept things as simple as possible here.
Signed-off-by: Michel Lespinasse wal...@google.com
---
mm/mmap.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index cebc346ba0db..5e64c7dfc090 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -570,14 +570,12 @@ again:remove_next = 1 + (end
next-vm_end);
vma_adjust_trans_huge(vma, start, end, adjust_next);
- /*
-* When changing only vma-vm_end, we don't really need anon_vma
-* lock. This is a fairly rare case by itself, but the anon_vma
-* lock may be shared between many sibling processes. Skipping
-* the lock for brk adjustments makes a difference sometimes.
-*/
- if (vma-anon_vma (importer || start != vma-vm_start)) {
- anon_vma = vma-anon_vma;
+ anon_vma = vma-anon_vma;
+ if (!anon_vma adjust_next)
+ anon_vma = next-anon_vma;
+ if (anon_vma) {
+ VM_BUG_ON(adjust_next next-anon_vma
+ anon_vma != next-anon_vma);
anon_vma_lock(anon_vma);
}
--
1.7.7.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] mm rmap: remove vma_address check for address inside vma
In file and anon rmap, we use interval trees to find potentially relevant
vmas and then call vma_address() to find the virtual address the given
page might be found at in these vmas. vma_address() used to include a
check that the returned address falls within the limits of the vma, but
this check isn't necessary now that we always use interval trees in rmap:
the interval tree just doesn't return any vmas which this check would find
to be irrelevant. As a result, we can replace the use of -EFAULT error code
(which then needed to be checked in every call site) with a VM_BUG_ON().
Signed-off-by: Michel Lespinasse wal...@google.com
---
mm/huge_memory.c |4
mm/rmap.c| 48 +---
2 files changed, 21 insertions(+), 31 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index fe119cb71b41..91b65f962320 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1432,8 +1432,6 @@ static void __split_huge_page(struct page *page,
struct vm_area_struct *vma = avc-vma;
unsigned long addr = vma_address(page, vma);
BUG_ON(is_vma_temporary_stack(vma));
- if (addr == -EFAULT)
- continue;
mapcount += __split_huge_page_splitting(page, vma, addr);
}
/*
@@ -1458,8 +1456,6 @@ static void __split_huge_page(struct page *page,
struct vm_area_struct *vma = avc-vma;
unsigned long addr = vma_address(page, vma);
BUG_ON(is_vma_temporary_stack(vma));
- if (addr == -EFAULT)
- continue;
mapcount2 += __split_huge_page_map(page, vma, addr);
}
if (mapcount != mapcount2)
diff --git a/mm/rmap.c b/mm/rmap.c
index 9c61bf387fd1..28777412de62 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -510,22 +510,26 @@ void page_unlock_anon_vma(struct anon_vma *anon_vma)
/*
* At what user virtual address is page expected in @vma?
- * Returns virtual address or -EFAULT if page's index/offset is not
- * within the range mapped the @vma.
*/
-inline unsigned long
-vma_address(struct page *page, struct vm_area_struct *vma)
+static inline unsigned long
+__vma_address(struct page *page, struct vm_area_struct *vma)
{
pgoff_t pgoff = page-index (PAGE_CACHE_SHIFT - PAGE_SHIFT);
- unsigned long address;
if (unlikely(is_vm_hugetlb_page(vma)))
pgoff = page-index huge_page_order(page_hstate(page));
- address = vma-vm_start + ((pgoff - vma-vm_pgoff) PAGE_SHIFT);
- if (unlikely(address vma-vm_start || address = vma-vm_end)) {
- /* page should be within @vma mapping range */
- return -EFAULT;
- }
+
+ return vma-vm_start + ((pgoff - vma-vm_pgoff) PAGE_SHIFT);
+}
+
+inline unsigned long
+vma_address(struct page *page, struct vm_area_struct *vma)
+{
+ unsigned long address = __vma_address(page, vma);
+
+ /* page should be within @vma mapping range */
+ VM_BUG_ON(address vma-vm_start || address = vma-vm_end);
+
return address;
}
@@ -535,6 +539,7 @@ vma_address(struct page *page, struct vm_area_struct *vma)
*/
unsigned long page_address_in_vma(struct page *page, struct vm_area_struct
*vma)
{
+ unsigned long address;
if (PageAnon(page)) {
struct anon_vma *page__anon_vma = page_anon_vma(page);
/*
@@ -550,7 +555,10 @@ unsigned long page_address_in_vma(struct page *page,
struct vm_area_struct *vma)
return -EFAULT;
} else
return -EFAULT;
- return vma_address(page, vma);
+ address = __vma_address(page, vma);
+ if (unlikely(address vma-vm_start || address = vma-vm_end))
+ return -EFAULT;
+ return address;
}
/*
@@ -624,8 +632,8 @@ int page_mapped_in_vma(struct page *page, struct
vm_area_struct *vma)
pte_t *pte;
spinlock_t *ptl;
- address = vma_address(page, vma);
- if (address == -EFAULT) /* out of vma range */
+ address = __vma_address(page, vma);
+ if (unlikely(address vma-vm_start || address = vma-vm_end))
return 0;
pte = page_check_address(page, vma-vm_mm, address, ptl, 1);
if (!pte) /* the page is not in this mm */
@@ -732,8 +740,6 @@ static int page_referenced_anon(struct page *page,
anon_vma_interval_tree_foreach(avc, anon_vma-rb_root, pgoff, pgoff) {
struct vm_area_struct *vma = avc-vma;
unsigned long address = vma_address(page, vma);
- if (address == -EFAULT)
- continue;
/*
* If we are reclaiming on behalf of a cgroup, skip
* counting on behalf of references from different
@@ -799,8 +805,6 @@ static int page_referenced_file(struct page *page,
vma_interval_tree_foreach(vma,
[PATCH 7/7] mm: avoid taking rmap locks in move_ptes()
During mremap(), the destination VMA is generally placed after the
original vma in rmap traversal order: in move_vma(), we always have
new_pgoff = vma-vm_pgoff, and as a result new_vma-vm_pgoff =
vma-vm_pgoff unless vma_merge() merged the new vma with an adjacent
one.
When the destination VMA is placed after the original in rmap
traversal order, we can avoid taking the rmap locks in move_ptes().
Essentially, this reintroduces the optimization that had been disabled
in mm anon rmap: remove anon_vma_moveto_tail. The difference is that
we don't try to impose the rmap traversal order; instead we just rely
on things being in the desired order in the common case and fall back
to taking locks in the uncommon case. Also we skip the i_mmap_mutex in
addition to the anon_vma lock: in both cases, the vmas are traversed in
increasing vm_pgoff order with ties resolved in tree insertion order.
Signed-off-by: Michel Lespinasse wal...@google.com
---
fs/exec.c |2 +-
include/linux/mm.h |6 +++-
mm/mmap.c |7 -
mm/mremap.c| 57 +++
4 files changed, 49 insertions(+), 23 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index da27b91ff1e8..f7b4009ea327 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -613,7 +613,7 @@ static int shift_arg_pages(struct vm_area_struct *vma,
unsigned long shift)
* process cleanup to remove whatever mess we made.
*/
if (length != move_page_tables(vma, old_start,
- vma, new_start, length))
+ vma, new_start, length, false))
return -ENOMEM;
lru_add_drain();
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1a2b1a44bd4e..c6a6b0b0f176 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1042,7 +1042,8 @@ vm_is_stack(struct task_struct *task, struct
vm_area_struct *vma, int in_group);
extern unsigned long move_page_tables(struct vm_area_struct *vma,
unsigned long old_addr, struct vm_area_struct *new_vma,
- unsigned long new_addr, unsigned long len);
+ unsigned long new_addr, unsigned long len,
+ bool need_rmap_locks);
extern unsigned long do_mremap(unsigned long addr,
unsigned long old_len, unsigned long new_len,
unsigned long flags, unsigned long new_addr);
@@ -1391,7 +1392,8 @@ extern void __vma_link_rb(struct mm_struct *, struct
vm_area_struct *,
struct rb_node **, struct rb_node *);
extern void unlink_file_vma(struct vm_area_struct *);
extern struct vm_area_struct *copy_vma(struct vm_area_struct **,
- unsigned long addr, unsigned long len, pgoff_t pgoff);
+ unsigned long addr, unsigned long len, pgoff_t pgoff,
+ bool *need_rmap_locks);
extern void exit_mmap(struct mm_struct *);
extern int mm_take_all_locks(struct mm_struct *mm);
diff --git a/mm/mmap.c b/mm/mmap.c
index 884bda4cd3ea..cc8c64077a42 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2397,7 +2397,8 @@ int insert_vm_struct(struct mm_struct * mm, struct
vm_area_struct * vma)
* prior to moving page table entries, to effect an mremap move.
*/
struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
- unsigned long addr, unsigned long len, pgoff_t pgoff)
+ unsigned long addr, unsigned long len, pgoff_t pgoff,
+ bool *need_rmap_locks)
{
struct vm_area_struct *vma = *vmap;
unsigned long vma_start = vma-vm_start;
@@ -2438,8 +2439,9 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
**vmap,
* linear if there are no pages mapped yet.
*/
VM_BUG_ON(faulted_in_anon_vma);
- *vmap = new_vma;
+ *vmap = vma = new_vma;
}
+ *need_rmap_locks = (new_vma-vm_pgoff = vma-vm_pgoff);
} else {
new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (new_vma) {
@@ -2466,6 +2468,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
**vmap,
if (new_vma-vm_ops new_vma-vm_ops-open)
new_vma-vm_ops-open(new_vma);
vma_link(mm, new_vma, prev, rb_link, rb_parent);
+ *need_rmap_locks = false;
}
}
return new_vma;
diff --git a/mm/mremap.c b/mm/mremap.c
index 95fb2e024ced..d18cdf09868c 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -71,26 +71,42 @@ static pmd_t *alloc_new_pmd(struct mm_struct *mm, struct
vm_area_struct *vma,
static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
unsigned long old_addr, unsigned long old_end,
struct vm_area_struct *new_vma, pmd_t *new_pmd,
- unsigned long new_addr)
+ unsigned long new_addr, bool need_rmap_locks)
{
[PATCH 6/7] mm: add CONFIG_DEBUG_VM_RB build option
Add a CONFIG_DEBUG_VM_RB build option for the previously existing
DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
recursive algorithms, we can expose it a bit more.
Also extend this code to validate_mm() after stack expansion, and to
check that the vma's start and last pgoffs have not changed since the
nodes were inserted on the anon vma interval tree (as it is important
that the nodes be reindexed after each such update).
Signed-off-by: Michel Lespinasse wal...@google.com
---
include/linux/mm.h |3 +++
include/linux/rmap.h |3 +++
lib/Kconfig.debug|9 +
mm/interval_tree.c | 41 -
mm/mmap.c| 19 +--
5 files changed, 64 insertions(+), 11 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 19d63ec2cbbb..1a2b1a44bd4e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1367,6 +1367,9 @@ struct anon_vma_chain *anon_vma_interval_tree_iter_first(
struct rb_root *root, unsigned long start, unsigned long last);
struct anon_vma_chain *anon_vma_interval_tree_iter_next(
struct anon_vma_chain *node, unsigned long start, unsigned long last);
+#ifdef CONFIG_DEBUG_VM_RB
+void anon_vma_interval_tree_verify(struct anon_vma_chain *node);
+#endif
#define anon_vma_interval_tree_foreach(avc, root, start, last) \
for (avc = anon_vma_interval_tree_iter_first(root, start, last); \
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index dce44f7d3ed8..b2cce644ffc7 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -66,6 +66,9 @@ struct anon_vma_chain {
struct list_head same_vma; /* locked by mmap_sem page_table_lock */
struct rb_node rb; /* locked by anon_vma-mutex */
unsigned long rb_subtree_last;
+#ifdef CONFIG_DEBUG_VM_RB
+ unsigned long cached_vma_start, cached_vma_last;
+#endif
};
#ifdef CONFIG_MMU
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index eba4b0961187..d261b4555dc5 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -781,6 +781,15 @@ config DEBUG_VM
If unsure, say N.
+config DEBUG_VM_RB
+ bool Debug VM red-black trees
+ depends on DEBUG_VM
+ help
+ Enable this to turn on more extended checks in the virtual-memory
+ system that may impact performance.
+
+ If unsure, say N.
+
config DEBUG_VIRTUAL
bool Debug VM translations
depends on DEBUG_KERNEL X86
diff --git a/mm/interval_tree.c b/mm/interval_tree.c
index f7c72cd35e1d..4a5822a586e6 100644
--- a/mm/interval_tree.c
+++ b/mm/interval_tree.c
@@ -70,4 +70,43 @@ static inline unsigned long avc_last_pgoff(struct
anon_vma_chain *avc)
}
INTERVAL_TREE_DEFINE(struct anon_vma_chain, rb, unsigned long, rb_subtree_last,
-avc_start_pgoff, avc_last_pgoff,, anon_vma_interval_tree)
+avc_start_pgoff, avc_last_pgoff,
+static inline, __anon_vma_interval_tree)
+
+void anon_vma_interval_tree_insert(struct anon_vma_chain *node,
+ struct rb_root *root)
+{
+#ifdef CONFIG_DEBUG_VM_RB
+ node-cached_vma_start = avc_start_pgoff(node);
+ node-cached_vma_last = avc_last_pgoff(node);
+#endif
+ __anon_vma_interval_tree_insert(node, root);
+}
+
+void anon_vma_interval_tree_remove(struct anon_vma_chain *node,
+ struct rb_root *root)
+{
+ __anon_vma_interval_tree_remove(node, root);
+}
+
+struct anon_vma_chain *
+anon_vma_interval_tree_iter_first(struct rb_root *root,
+ unsigned long first, unsigned long last)
+{
+ return __anon_vma_interval_tree_iter_first(root, first, last);
+}
+
+struct anon_vma_chain *
+anon_vma_interval_tree_iter_next(struct anon_vma_chain *node,
+unsigned long first, unsigned long last)
+{
+ return __anon_vma_interval_tree_iter_next(node, first, last);
+}
+
+#ifdef CONFIG_DEBUG_VM_RB
+void anon_vma_interval_tree_verify(struct anon_vma_chain *node)
+{
+ WARN_ON_ONCE(node-cached_vma_start != avc_start_pgoff(node));
+ WARN_ON_ONCE(node-cached_vma_last != avc_last_pgoff(node));
+}
+#endif
diff --git a/mm/mmap.c b/mm/mmap.c
index 1a6afdb5194a..884bda4cd3ea 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -51,12 +51,6 @@ static void unmap_region(struct mm_struct *mm,
struct vm_area_struct *vma, struct vm_area_struct *prev,
unsigned long start, unsigned long end);
-/*
- * WARNING: the debugging will use recursive algorithms so never enable this
- * unless you know what you are doing.
- */
-#undef DEBUG_MM_RB
-
/* description of effects of mapping type and prot in current implementation.
* this is due to the limited x86 page protection hardware. The expected
* behavior is in parens:
@@ -306,7 +300,7 @@ out:
return retval;
}
-#ifdef DEBUG_MM_RB
+#ifdef
[PATCH 4/7] mm anon rmap: replace same_anon_vma linked list with an interval tree.
When a large VMA (anon or private file mapping) is first touched, which
will populate its anon_vma field, and then split into many regions through
the use of mprotect(), the original anon_vma ends up linking all of the
vmas on a linked list. This can cause rmap to become inefficient, as we
have to walk potentially thousands of irrelevent vmas before finding the
one a given anon page might fall into.
By replacing the same_anon_vma linked list with an interval tree
(where each avc's interval is determined by its vma's start and
last pgoffs), we can make rmap efficient for this use case again.
While the change is large, all of its pieces are fairly simple.
Most places that were walking the same_anon_vma list were looking for
a known pgoff, so they can just use the anon_vma_interval_tree_foreach()
interval tree iterator instead. The exception here is ksm, where the
page's index is not known. It would probably be possible to rework ksm
so that the index would be known, but for now I have decided to keep things
simple and just walk the entirety of the interval tree there.
When updating vma's that already have an anon_vma assigned, we must take
care to re-index the corresponding avc's on their interval tree. This is
done through the use of anon_vma_interval_tree_pre_update_vma() and
anon_vma_interval_tree_post_update_vma(), which remove the avc's from
their interval tree before the update and re-insert them after the update.
The anon_vma stays locked during the update, so there is no chance that
rmap would miss the vmas that are being updated.
Signed-off-by: Michel Lespinasse wal...@google.com
---
include/linux/mm.h | 14
include/linux/rmap.h | 11 +
mm/huge_memory.c |5 ++-
mm/interval_tree.c | 14
mm/ksm.c |9 +--
mm/memory-failure.c |5 +++-
mm/mmap.c| 57 +++--
mm/rmap.c| 24 ++--
8 files changed, 109 insertions(+), 30 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 38af0048037f..19d63ec2cbbb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -20,6 +20,7 @@
struct mempolicy;
struct anon_vma;
+struct anon_vma_chain;
struct file_ra_state;
struct user_struct;
struct writeback_control;
@@ -1358,6 +1359,19 @@ static inline void vma_nonlinear_insert(struct
vm_area_struct *vma,
list_add_tail(vma-shared.nonlinear, list);
}
+void anon_vma_interval_tree_insert(struct anon_vma_chain *node,
+ struct rb_root *root);
+void anon_vma_interval_tree_remove(struct anon_vma_chain *node,
+ struct rb_root *root);
+struct anon_vma_chain *anon_vma_interval_tree_iter_first(
+ struct rb_root *root, unsigned long start, unsigned long last);
+struct anon_vma_chain *anon_vma_interval_tree_iter_next(
+ struct anon_vma_chain *node, unsigned long start, unsigned long last);
+
+#define anon_vma_interval_tree_foreach(avc, root, start, last) \
+ for (avc = anon_vma_interval_tree_iter_first(root, start, last); \
+avc; avc = anon_vma_interval_tree_iter_next(avc, start, last))
+
/* mmap.c */
extern int __vm_enough_memory(struct mm_struct *mm, long pages, int
cap_sys_admin);
extern int vma_adjust(struct vm_area_struct *vma, unsigned long start,
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 7f32cec57e67..dce44f7d3ed8 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -37,14 +37,14 @@ struct anon_vma {
atomic_t refcount;
/*
-* NOTE: the LSB of the head.next is set by
+* NOTE: the LSB of the rb_root.rb_node is set by
* mm_take_all_locks() _after_ taking the above lock. So the
-* head must only be read/written after taking the above lock
+* rb_root must only be read/written after taking the above lock
* to be sure to see a valid next pointer. The LSB bit itself
* is serialized by a system wide lock only visible to
* mm_take_all_locks() (mm_all_locks_mutex).
*/
- struct list_head head; /* Chain of private related vmas */
+ struct rb_root rb_root; /* Interval tree of private related vmas */
};
/*
@@ -57,14 +57,15 @@ struct anon_vma {
* with a VMA, or the VMAs associated with an anon_vma.
* The same_vma list contains the anon_vma_chains linking
* all the anon_vmas associated with this VMA.
- * The same_anon_vma list contains the anon_vma_chains
+ * The rb field indexes on an interval tree the anon_vma_chains
* which link all the VMAs associated with this anon_vma.
*/
struct anon_vma_chain {
struct vm_area_struct *vma;
struct anon_vma *anon_vma;
struct list_head same_vma; /* locked by mmap_sem page_table_lock */
- struct list_head same_anon_vma; /* locked by anon_vma-mutex */
+ struct rb_node rb; /* locked by
Re: [PATCH 1/3] proc: return -ENOMEM when inode allocation failed
2012/9/4 Cong Wang xiyou.wangc...@gmail.com:
On 09/03/2012 10:14 PM, yan wrote:
Signed-off-by: yan clouds@gmail.com
Please provide a changelog to explain why we need this patch.
I think the title is self explained.
---
fs/proc/generic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index b3647fe..9e8f631 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -427,7 +427,7 @@ struct dentry *proc_lookup_de(struct proc_dir_entry
*de, struct inode *dir,
if (!memcmp(dentry-d_name.name, de-name, de-namelen)) {
pde_get(de);
spin_unlock(proc_subdir_lock);
- error = -EINVAL;
+ error = -ENOMEM;
Why the !memcmp() case is related with ENOMEM ??
We are presetting 'error' here. The following proc_get_inode() will try
to get an inode, either from inode cache or allocate a new one (and fill it).
If we get a NULL inode, that means allocation failed. That's how
ENOMEM involved.
Thank you for your reply.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] mm anon rmap: remove anon_vma_moveto_tail
mremap() had a clever optimization where move_ptes() did not take the
anon_vma lock to avoid a race with anon rmap users such as page migration.
Instead, the avc's were ordered in such a way that the origin vma was
always visited by rmap before the destination. This ordering and the use
of page table locks rmap usage safe. However, we want to replace the
use of linked lists in anon rmap with an interval tree, and this will
make it harder to impose such ordering as the interval tree will always
be sorted by the avc-vma-vm_pgoff value. For now, let's replace the
anon_vma_moveto_tail() ordering function with proper anon_vma locking
in move_ptes(). Once we have the anon interval tree in place, we will
re-introduce an optimization to avoid taking these locks in the most
common cases.
Signed-off-by: Michel Lespinasse wal...@google.com
---
include/linux/rmap.h |1 -
mm/mmap.c|3 +--
mm/mremap.c | 14 +-
mm/rmap.c| 45 -
4 files changed, 6 insertions(+), 57 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 3fce545df394..7f32cec57e67 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -120,7 +120,6 @@ void anon_vma_init(void); /* create anon_vma_cachep */
int anon_vma_prepare(struct vm_area_struct *);
void unlink_anon_vmas(struct vm_area_struct *);
int anon_vma_clone(struct vm_area_struct *, struct vm_area_struct *);
-void anon_vma_moveto_tail(struct vm_area_struct *);
int anon_vma_fork(struct vm_area_struct *, struct vm_area_struct *);
static inline void anon_vma_merge(struct vm_area_struct *vma,
diff --git a/mm/mmap.c b/mm/mmap.c
index 5e64c7dfc090..ea647255d763 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2397,8 +2397,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
**vmap,
*/
VM_BUG_ON(faulted_in_anon_vma);
*vmap = new_vma;
- } else
- anon_vma_moveto_tail(new_vma);
+ }
} else {
new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (new_vma) {
diff --git a/mm/mremap.c b/mm/mremap.c
index 21fed202ddad..95fb2e024ced 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -74,6 +74,7 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t
*old_pmd,
unsigned long new_addr)
{
struct address_space *mapping = NULL;
+ struct anon_vma *anon_vma = vma-anon_vma;
struct mm_struct *mm = vma-vm_mm;
pte_t *old_pte, *new_pte, pte;
spinlock_t *old_ptl, *new_ptl;
@@ -88,6 +89,8 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t
*old_pmd,
mapping = vma-vm_file-f_mapping;
mutex_lock(mapping-i_mmap_mutex);
}
+ if (anon_vma)
+ anon_vma_lock(anon_vma);
/*
* We don't have to worry about the ordering of src and dst
@@ -114,6 +117,8 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t
*old_pmd,
spin_unlock(new_ptl);
pte_unmap(new_pte - 1);
pte_unmap_unlock(old_pte - 1, old_ptl);
+ if (anon_vma)
+ anon_vma_unlock(anon_vma);
if (mapping)
mutex_unlock(mapping-i_mmap_mutex);
}
@@ -221,15 +226,6 @@ static unsigned long move_vma(struct vm_area_struct *vma,
moved_len = move_page_tables(vma, old_addr, new_vma, new_addr, old_len);
if (moved_len old_len) {
/*
-* Before moving the page tables from the new vma to
-* the old vma, we need to be sure the old vma is
-* queued after new vma in the same_anon_vma list to
-* prevent SMP races with rmap_walk (that could lead
-* rmap_walk to miss some page table).
-*/
- anon_vma_moveto_tail(vma);
-
- /*
* On error, move entries back from new area to old,
* which will succeed since page tables still there,
* and then proceed to unmap new area instead of old.
diff --git a/mm/rmap.c b/mm/rmap.c
index 7b5b51d25fc5..8cbd62fde0f1 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -269,51 +269,6 @@ int anon_vma_clone(struct vm_area_struct *dst, struct
vm_area_struct *src)
}
/*
- * Some rmap walk that needs to find all ptes/hugepmds without false
- * negatives (like migrate and split_huge_page) running concurrent
- * with operations that copy or move pagetables (like mremap() and
- * fork()) to be safe. They depend on the anon_vma same_anon_vma
- * list to be in a certain order: the dst_vma must be placed after the
- * src_vma in the list. This is always guaranteed by fork() but
- * mremap() needs to call this function to enforce it in case the
- * dst_vma isn't newly allocated and chained with the anon_vma_clone()
- * function but just an extension of a pre-existing vma
[PATCH 1/7] mm: interval tree updates
This commit updates the generic interval tree code that was
introduced in mm: replace vma prio_tree with an interval tree.
Changes:
- fixed 'endpoing' typo noticed by Andrew Morton
- replaced include/linux/interval_tree_tmpl.h, which was used as a
template (including it automatically defined the interval tree
functions) with include/linux/interval_tree_generic.h, which only
defines a preprocessor macro INTERVAL_TREE_DEFINE(), which itself
defines the interval tree functions when invoked. Now that is a very
long macro which is unfortunate, but it does make the usage sites
(lib/interval_tree.c and mm/interval_tree.c) a bit nicer than previously.
- make use of RB_DECLARE_CALLBACKS() in the INTERVAL_TREE_DEFINE() macro,
instead of duplicating that code in the interval tree template.
- replaced vma_interval_tree_add(), which was actually handling the
nonlinear and interval tree cases, with vma_interval_tree_insert_after()
which handles only the interval tree case and has an API that is more
consistent with the other interval tree handling functions.
The nonlinear case is now handled explicitly in kernel/fork.c dup_mmap().
Signed-off-by: Michel Lespinasse wal...@google.com
---
include/linux/interval_tree_generic.h | 191
include/linux/interval_tree_tmpl.h| 219 -
include/linux/mm.h|6 +-
kernel/fork.c |7 +-
lib/interval_tree.c | 15 +--
mm/interval_tree.c| 60 +-
6 files changed, 235 insertions(+), 263 deletions(-)
create mode 100644 include/linux/interval_tree_generic.h
delete mode 100644 include/linux/interval_tree_tmpl.h
diff --git a/include/linux/interval_tree_generic.h
b/include/linux/interval_tree_generic.h
new file mode 100644
index ..58370e1862ad
--- /dev/null
+++ b/include/linux/interval_tree_generic.h
@@ -0,0 +1,191 @@
+/*
+ Interval Trees
+ (C) 2012 Michel Lespinasse wal...@google.com
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ 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.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+ include/linux/interval_tree_generic.h
+*/
+
+#include linux/rbtree_augmented.h
+
+/*
+ * Template for implementing interval trees
+ *
+ * ITSTRUCT: struct type of the interval tree nodes
+ * ITRB: name of struct rb_node field within ITSTRUCT
+ * ITTYPE: type of the interval endpoints
+ * ITSUBTREE: name of ITTYPE field within ITSTRUCT holding last-in-subtree
+ * ITSTART(n): start endpoint of ITSTRUCT node n
+ * ITLAST(n): last endpoint of ITSTRUCT node n
+ * ITSTATIC: 'static' or empty
+ * ITPREFIX: prefix to use for the inline tree definitions
+ *
+ * Note - before using this, please consider if non-generic version
+ * (interval_tree.h) would work for you...
+ */
+
+#define INTERVAL_TREE_DEFINE(ITSTRUCT, ITRB, ITTYPE, ITSUBTREE,
\
+ITSTART, ITLAST, ITSTATIC, ITPREFIX) \
+ \
+/* Callbacks for augmented rbtree insert and remove */ \
+ \
+static inline ITTYPE ITPREFIX ## _compute_subtree_last(ITSTRUCT *node) \
+{\
+ ITTYPE max = ITLAST(node), subtree_last; \
+ if (node-ITRB.rb_left) { \
+ subtree_last = rb_entry(node-ITRB.rb_left, \
+ ITSTRUCT, ITRB)-ITSUBTREE; \
+ if (max subtree_last) \
+ max = subtree_last; \
+ } \
+ if (node-ITRB.rb_right) {\
+ subtree_last = rb_entry(node-ITRB.rb_right, \
+ ITSTRUCT, ITRB)-ITSUBTREE; \
+ if (max subtree_last) \
+ max = subtree_last; \
+ }
[PATCH] mm: fix mmap overflow checking
POSIX said that if the file is a regular file and the value of off
plus len exceeds the offset maximum established in the open file
description associated with fildes, mmap should return EOVERFLOW.
The following test from LTP can reproduce this bug.
char tmpfname[256];
void *pa = NULL;
void *addr = NULL;
size_t len;
int flag;
int fd;
off_t off = 0;
int prot;
long page_size = sysconf(_SC_PAGE_SIZE);
snprintf(tmpfname, sizeof(tmpfname), /tmp/mmap_test_%d, getpid());
unlink(tmpfname);
fd = open(tmpfname, O_CREAT | O_RDWR | O_EXCL, S_IRUSR | S_IWUSR);
if (fd == -1) {
printf( Error at open(): %s\n, strerror(errno));
return 1;
}
unlink(tmpfname);
flag = MAP_SHARED;
prot = PROT_READ | PROT_WRITE;
/* len + off maximum offset */
len = ULONG_MAX;
if (len % page_size) {
/* Lower boundary */
len = ~(page_size - 1);
}
off = ULONG_MAX;
if (off % page_size) {
/* Lower boundary */
off = ~(page_size - 1);
}
printf(off: %lx, len: %lx\n, (unsigned long)off, (unsigned long)len);
pa = mmap(addr, len, prot, flag, fd, off);
if (pa == MAP_FAILED errno == EOVERFLOW) {
printf(Test Pass: Error at mmap: %s\n, strerror(errno));
return 0;
}
if (pa == MAP_FAILED)
perror(Test FAIL: expect EOVERFLOW but get other error);
else
printf(Test FAIL : Expect EOVERFLOW but got no error\n);
close(fd);
munmap(pa, len);
return 1;
Cc: Andrew Morton a...@linux-foundation.org
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: linux...@kvack.org (open list:MEMORY MANAGEMENT)
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
---
mm/mmap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index ae18a48..5380764 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -980,6 +980,7 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned
long addr,
struct mm_struct * mm = current-mm;
struct inode *inode;
vm_flags_t vm_flags;
+ off_t off = pgoff PAGE_SHIFT;
/*
* Does the application expect PROT_READ to imply PROT_EXEC?
@@ -1003,8 +1004,8 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned
long addr,
return -ENOMEM;
/* offset overflow? */
- if ((pgoff + (len PAGE_SHIFT)) pgoff)
- return -EOVERFLOW;
+ if (off + len off)
+ return -EOVERFLOW;
/* Too many mappings? */
if (mm-map_count sysctl_max_map_count)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: ux500: Provide SMSC911x fixed-regulator when not booting DT
On Tue, Sep 4, 2012 at 11:08 AM, Lee Jones lee.jo...@linaro.org wrote: On Tue, Sep 04, 2012 at 10:53:32AM +0200, Linus Walleij wrote: You forgot to add select REGULATOR_FIXED_VOLTAGE to the MOP500 Kconfig entry, but I added it when applying. I didn't forget. I intentionally left it out because it's unconditionally set in the defconfig. Since disabling that from the config breaks compile this means that you just broke Arnds randconfig builds :-P If something *must* be configured for the thing to compile, so it with select. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] can: rename LED trigger name on netdev renames
The LED trigger name for CAN devices is based on the initial
CAN device name, but does never change. The LED trigger name
is not guaranteed to be unique in case of hotplugging CAN devices.
This patch tries to address this problem by modifying the
LED trigger name according to the CAN device name when
the latter changes.
This patch is meant as illustration only.
In case of VCAN device rename, a segmentation fault will occur.
Signed-off-by: Kurt Van Dijck kurt.van.di...@eia.be
---
drivers/net/can/led.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/drivers/net/can/led.c b/drivers/net/can/led.c
index eaa14ac..f62f908 100644
--- a/drivers/net/can/led.c
+++ b/drivers/net/can/led.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/netdevice.h
#include linux/can/dev.h
+#include linux/if_arp.h
#include linux/can/led.h
@@ -87,3 +88,59 @@ void devm_can_led_init(struct net_device *netdev)
devres_add(netdev-dev, res);
}
EXPORT_SYMBOL_GPL(devm_can_led_init);
+
+/*
+ * NETDEV rename notifier to rename the associated led triggers too
+ */
+static int can_led_notifier(struct notifier_block *nb, unsigned long msg,
+ void *data)
+{
+ struct net_device *netdev = (struct net_device *)data;
+ struct can_priv *priv = netdev_priv(netdev);
+ int busy = 0;
+
+ if (!net_eq(dev_net(netdev), init_net))
+ return NOTIFY_DONE;
+
+ if (netdev-type != ARPHRD_CAN)
+ return NOTIFY_DONE;
+
+ if (msg != NETDEV_CHANGENAME)
+ return NOTIFY_DONE;
+
+ read_lock(priv-tx_led_trig-leddev_list_lock);
+ if (!list_empty(priv-tx_led_trig-led_cdevs))
+ ++busy;
+ read_unlock(priv-tx_led_trig-leddev_list_lock);
+ read_lock(priv-rx_led_trig-leddev_list_lock);
+ if (!list_empty(priv-rx_led_trig-led_cdevs))
+ ++busy;
+ read_unlock(priv-rx_led_trig-leddev_list_lock);
+
+ if (busy)
+ return notifier_from_errno(-EBUSY);
+
+ snprintf(priv-tx_led_trig_name, sizeof(priv-tx_led_trig_name),
+%s-tx, netdev-name);
+ snprintf(priv-rx_led_trig_name, sizeof(priv-rx_led_trig_name),
+%s-rx, netdev-name);
+ return NOTIFY_DONE;
+}
+
+/* notifier block for netdevice event */
+static struct notifier_block can_netdev_notifier __read_mostly = {
+ .notifier_call = can_led_notifier,
+};
+
+static __init int can_led_init(void)
+{
+ return register_netdevice_notifier(can_netdev_notifier);
+}
+
+static __exit void can_led_exit(void)
+{
+ unregister_netdevice_notifier(can_netdev_notifier);
+}
+
+module_init(can_led_init);
+module_exit(can_led_exit);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Why exported const value modified by another driver not updated in original driver
Hi,
I have declared a static const int variable in one driver and exported
that variable symbol. In another driver i am modifying that variable.
The other driver prints the modified value but the original driver
retains the original value. When both virtual and physical addresses
of the variable as seen by both drivers are same, how is this even
possible. Is it a kernel bug?
[root@localhost bug]# uname -a
Linux localhost.localdomain 3.5.3 #3 SMP Mon Sep 3 21:52:12 IST 2012
i686 i686 i386 GNU/Linux
[root@localhost bug]# cat driver.c
#include linux/module.h
static const int value = 123;
int init_module()
{
printk(Base driver (init): value = %d\n, value);
printk(Base driver (init): virtual address of value = %p\n, (void
*)value);
printk(Base driver (init): physical address of value = %p\n, (void
*)__pa(value));
return 0;
}
void cleanup_module()
{
printk(Base driver (exit): value = %d\n, value);
printk(Base driver (exit): virtual address of value = %p\n, (void
*)value);
printk(Base driver (exit): physical address of value = %p\n, (void
*)__pa(value));
}
EXPORT_SYMBOL(value);
==
[root@localhost bug]# cat hacker.c
#include linux/module.h
extern int value;
int init_module()
{
value = 987;
printk(Hacker driver (init): value = %d\n, value);
printk(Hacker Base driver (init): virtual address of value = %p\n,
(void *)value);
printk(Hacker Base driver (init): physical address of value = %p\n,
(void *)__pa(value));
return 0;
}
void cleanup_module()
{
printk(Hacker driver (exit): value = %d\n, value);
printk(Hacker driver (exit): virtual address of value = %p\n,
(void *)value);
printk(Hacker driver (exit): physical address of value = %p\n,
(void *)__pa(value));
return;
}
=
[root@localhost bug]# insmod driver.ko
Base driver (init): value = 123
Base driver (init): virtual address of value = f89d61c8
Base driver (init): physical address of value = 389d61c8
[root@localhost bug]# insmod hacker.ko
Hacker driver (init): value = 987
Hacker Base driver (init): virtual address of value = f89d61c8
Hacker Base driver (init): physical address of value = 389d61c8
[root@localhost bug]# rmmod hacker.ko
Hacker driver (exit): value = 987
Hacker driver (exit): virtual address of value = f89d61c8
Hacker driver (exit): physical address of value = 389d61c8
[root@localhost bug]# rmmod driver.ko
Base driver (exit): value = 123
Base driver (exit): virtual address of value = f89d61c8
Base driver (exit): physical address of value = 389d61c8
[root@localhost bug]# cat /proc/kallsyms | grep value
f89f91c8 R value[driver]
f89f9088 r __ksymtab_value [driver]
f89f91cc r __kstrtab_value [driver]
Interestingly, when i change the declaration of variable to volatile
in driver.c as static const volatile int then the driver.ko prints
modified value 987 during rmmod and the original value 123 is
lost. What is the difference between this and previous declaration?
Please forgive if you find this question silly?
--
Manavendra Nath Manav
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/4] i2c: introduce i2c-cbus driver
On Tue, Sep 04, 2012 at 12:05:07PM +0300, Felipe Balbi wrote: + * CBUS I2C driver for Nokia Internet Tablets. [...] this version misses the entire IRQ handling we already had on linux-omap tree, so it's quite a regression. There's no interrupts used in plain CBUS protocol/communication I think? But Retu MFD supports the GPIO IRQ. I added the code for this set. And the power button driver (patch 4/4) is using this functionality: # cat /proc/interrupts [...] 204: 29 GPIO retu-mfd 224: 29 RETU retu-pwrbutton A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 -tip 1/5] x86, MSI: Support multiple MSIs in presense of IRQ remapping
On Mon, Sep 03, 2012 at 11:53:39AM -0700, Yinghai Lu wrote: On Mon, Sep 3, 2012 at 2:17 AM, Alexander Gordeev agord...@redhat.com wrote: You may update create_irq_nr to be __create_irq_nr, and it could take extra count. and later have create_irq_nr to be __create_irq_nr(,1,) and create_irqs to be __create_irq_nr(,count,) Indeed. Will do. BTW, in short, how much performance benefits for adding 500 lines code? Unfortunatelly, I do not have a short answer here. There are three types of performance this series deals with - I'll try to summarize: - devices - 3 SATA HDDs generate roughly one interrupt every 273 us while it get handled in less than 5 us. So there is/could be no increase here; - the hardware context interrupt handler - its performance dropped 2.5 times (little bit more in fact) at the expense of increase of 1.3 times in overall interrupt handling time (hardware context + threaded context); - overall system performance - I *assume* it should increase, because: (a) AHCI interrupt handlers keep local interrupts disabled 2.5 times less (b) separate AHCI IRQs become subjects of IRQ balancing (c) threaded handlers are per-device, per-CPU (well, up to irqbalanced) and executed with local interrupts enabled; -- Regards, Alexander Gordeev agord...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: ux500: Provide SMSC911x fixed-regulator when not booting DT
On Tue, Sep 04, 2012 at 11:29:02AM +0200, Linus Walleij wrote: On Tue, Sep 4, 2012 at 11:08 AM, Lee Jones lee.jo...@linaro.org wrote: On Tue, Sep 04, 2012 at 10:53:32AM +0200, Linus Walleij wrote: You forgot to add select REGULATOR_FIXED_VOLTAGE to the MOP500 Kconfig entry, but I added it when applying. I didn't forget. I intentionally left it out because it's unconditionally set in the defconfig. Since disabling that from the config breaks compile this means that you just broke Arnds randconfig builds :-P If something *must* be configured for the thing to compile, so it with select. Ah, I see. Noted, thanks. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] floppy, pktcdvd
Jens, please consider pulling from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/linux-block.git for-jens (based on 'master' of your linux-block.git) to receive the changes below. There are a couple of fixes (mostly clenaups) to floppy driver from Herton Ronaldo Krzesinski and Ben Hutchings. Ben's fix I'd like to explicitly point out, as it slightly modifies how GENHD_FL_UP is handled in block/genhd.c, but as you have been CCed on it and didn't object, I am including it as well. Apart from that, Peter is giving up on pktcdvd maintainer ship, so I offered to take it, cosidering that I have the necessary hardware and it's a very low-traffic code anyway. Thanks! Ben Hutchings (1): genhd: Make put_disk() safe for disks that have not been registered Herton Ronaldo Krzesinski (5): floppy: don't call alloc_ordered_workqueue inside the alloc_disk loop floppy: do put_disk on current dr if blk_init_queue fails floppy: properly handle failure on add_disk loop floppy: use common function to check if floppies can be registered floppy: remove dr, reuse drive on do_floppy_init Jiri Kosina (1): pktcdvd: update MAINTAINERS MAINTAINERS|2 +- block/genhd.c |6 +- drivers/block/floppy.c | 97 +++ 3 files changed, 51 insertions(+), 54 deletions(-) -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
On Tue, 4 Sep 2012, Lars-Peter Clausen wrote: On 09/04/2012 10:42 AM, Artem Bityutskiy wrote: Aiaiai! :-) [1] [2] I've build-tested this using aiaiai and it reports that this change breaks the build: dedekind@blue:~/git/maintaining$ ./verify ../l2-mtd/ mpc5121_nfc ~/tmp/julia2.mbox Tested the patch(es) on top of the following commits: ba64756 Quick fixes - applied by aiaiai 651c6fa JFFS2: don't fail on bitflips in OOB e22ac84 mtd: autcpu12-nvram: drop frees of devm_ alloc'd data ea9d312 mtd: cmdlinepart: minor cleanups Failed to build the following commit for configuration powerpc-mpc512x_defconfig (architecture powerpc): 0fe13ab drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups ... drivers/mtd/nand/mpc5121_nfc.c: In function 'mpc5121_nfc_probe': drivers/mtd/nand/mpc5121_nfc.c:622:28: warning: variable 'regs_size' set but not used [-Wunused-but-set-variable] drivers/mtd/nand/mpc5121_nfc.c:622:16: warning: variable 'regs_paddr' set but not used [-Wunused-but-set-variable] drivers/built-in.o: In function `mpc5121_nfc_probe': mpc5121_nfc.c:(.devinit.text+0x2a14): undefined reference to `devm_clk_get' make[1]: *** [vmlinux] Error 1 I do not really know why, but it seems that clock framework is not supported for powerpc. CCing the PPC mailing list. Preserved the context below for the PPC people. I've been bitten by the same issue recently, also cause by one of these cocci devm patches. devm_clk_get is only available if the generic clk_get/clk_put implementation is used. Not all architectures do this and some implement their own clk_get/clk_put, etc functions. Since devm_clk_get is merely a wrapper around clk_get/clk_put there is no reason why it should depend CLKDEV_LOOKUP. I've prepared a patch which makes them generically available if the clk_get/clk_put are implemented (i.e. if HAVE_CLK is set), but it is on a different machine right now, will try to submit it later today. Sorry about this. I wasn't aware that devm_clk_get wasn't supported by all architectures, and I have no way of compiling code for these architectures... But I wonder why it is not, since devm-ness doesn't seem to have anything to do with architecture-specific details? It would be really nice to have it for all architectures, because the clock functions are just as (or at least almost as) common as kzalloc, ioremap, etc. 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 4/4] drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
On Tue, 2012-09-04 at 11:44 +0200, Julia Lawall wrote: I've been bitten by the same issue recently, also cause by one of these cocci devm patches. devm_clk_get is only available if the generic clk_get/clk_put implementation is used. Not all architectures do this and some implement their own clk_get/clk_put, etc functions. Since devm_clk_get is merely a wrapper around clk_get/clk_put there is no reason why it should depend CLKDEV_LOOKUP. I've prepared a patch which makes them generically available if the clk_get/clk_put are implemented (i.e. if HAVE_CLK is set), but it is on a different machine right now, will try to submit it later today. Sorry about this. I wasn't aware that devm_clk_get wasn't supported by all architectures, and I have no way of compiling code for these architectures... But I wonder why it is not, since devm-ness doesn't seem to have anything to do with architecture-specific details? It would be really nice to have it for all architectures, because the clock functions are just as (or at least almost as) common as kzalloc, ioremap, etc. It looks like Lars is going to fix this. I am personally fine if you send patches without build-testing them. Your patches are generally of good quality and you send many of them, so build-testing each would be too much for you. And at least for MTD, I can build-test myself. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] udf: extent cache implementation for manipulating block map
On Tue 04-09-12 16:45:42, Namjae Jeon wrote:
2012/9/3, Jan Kara j...@suse.cz:
+void udf_clear_extent_cache(struct udf_inode_info *iinfo)
+{
+ if (iinfo-cached_extent.sanity) {
+ brelse(iinfo-cached_extent.epos.bh);
+ memset(iinfo-cached_extent, 0, sizeof(struct udf_ext_cache));
+ }
+}
+
I think udf_clear_entent_cache() should take i_extent_cache_lock. Or if
you are sure it's not needed, you need a good documentation why.
Documentation ? I am a little confusing.. It means udf.txt is in
Documentation/filesystem/ ?
or comment about clear extent function ?
I meant in a comment before udf_clear_extent_cache() function...
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem
Hi Wen,
2012/09/04 12:46, Wen Congyang wrote:
Hi, isimatu-san
At 09/01/2012 05:30 AM, Andrew Morton Wrote:
On Tue, 28 Aug 2012 18:00:20 +0800
we...@cn.fujitsu.com wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
There is a possibility that get_page_bootmem() is called to the same page many
times. So when get_page_bootmem is called to the same page, the function only
increments page-_count.
I really don't understand this explanation, even after having looked at
the code. Can you please have another attempt at the changelog?
What is the problem that you want to fix? The function get_page_bootmem()
may be called to the same page more than once, but I don't find any problem
about current implementation.
The patch is just optimization. The patch does not fix a problems.
As you know, the function may be called many times for the same page.
I think if a page is sets to page_type and Page Private flag and page-private,
the page need not be set the same things again. So we check page_type when
get_page_bootmem() is called. And if the page has been set to them, the page
is only incremented page-_count.
Thanks,
Yasuaki Ishimatsu
Thanks
Wen Congyang
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
static void get_page_bootmem(unsigned long info, struct page *page,
unsigned long type)
{
- page-lru.next = (struct list_head *) type;
- SetPagePrivate(page);
- set_page_private(page, info);
- atomic_inc(page-_count);
+ unsigned long page_type;
+
+ page_type = (unsigned long) page-lru.next;
+ if (page_type MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
+ page_type MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
+ page-lru.next = (struct list_head *) type;
+ SetPagePrivate(page);
+ set_page_private(page, info);
+ atomic_inc(page-_count);
+ } else
+ atomic_inc(page-_count);
}
And a code comment which explains what is going on would be good. As
is always the case ;)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] UDF: Add support for O_DIRECT
Add support for the O_DIRECT flag. There are two cases to deal with:
1. Small files stored in the ICB (inode control block?): just return 0
from the new udf_adinicb_direct_IO() handler to fall back to buffered
I/O. For direct writes, there is a gotcha to deal with when
generic_file_direct_write() in mm/filemap.c invalidates the pages. In
the udf_adinicb_writepage() handler, only part of the page data will be
valid and the rest will be zeroed out, so only copy the valid part into
the ICB. (This is actually a bit inefficient as udf_adinicb_write_end()
will have already copied the data into the ICB once, but it's pretty
likely that the file will grow to the point where its data can no longer
be stored in the ICB and will be moved to a different area of the file
system. At that point, a different direct_IO handler will be used - see
below.)
2. Larger files, not stored in the ICB: nothing special here. Just call
blockdev_direct_IO() from our new udf_direct_IO() handler and tidy up
any blocks instantiated outside i_size on error. This is pretty
standard. Factor error handling code out of udf_write_begin() into new
function udf_write_failed() so it can also be called by udf_direct_IO().
Also change the whitespace in udf_aops and udf_adinicb_aops to make them
a bit neater.
Signed-off-by: Ian Abbott abbo...@mev.co.uk
---
v2: Rework error handling in udf_direct_IO to avoid calling deprecated
vmtruncate().
v3: Rebased to next-20120904.
---
fs/udf/file.c | 29 +
fs/udf/inode.c | 52
2 files changed, 61 insertions(+), 20 deletions(-)
diff --git a/fs/udf/file.c b/fs/udf/file.c
index 7f3f7ba..f5f9ddd 100644
--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -34,6 +34,7 @@
#include linux/errno.h
#include linux/pagemap.h
#include linux/buffer_head.h
+#include linux/writeback.h
#include linux/aio.h
#include udf_i.h
@@ -64,12 +65,23 @@ static int udf_adinicb_writepage(struct page *page,
struct inode *inode = page-mapping-host;
char *kaddr;
struct udf_inode_info *iinfo = UDF_I(inode);
+ loff_t start, end, page_start, page_offset;
BUG_ON(!PageLocked(page));
kaddr = kmap(page);
- memcpy(iinfo-i_ext.i_data + iinfo-i_lenEAttr, kaddr, inode-i_size);
- mark_inode_dirty(inode);
+ /* The beginning and/or end of the page data is likely to be invalid
+* for O_DIRECT, so only copy the valid part. */
+ page_start = (loff_t)page-index PAGE_CACHE_SHIFT;
+ start = max(page_start, wbc-range_start);
+ end = min3(page_start + (loff_t)PAGE_CACHE_SIZE - 1,
+ wbc-range_end, inode-i_size - 1);
+ if (likely(start = end)) {
+ page_offset = start - page_start;
+ memcpy(iinfo-i_ext.i_data + iinfo-i_lenEAttr + start,
+ kaddr + page_offset, (end + 1 - start));
+ mark_inode_dirty(inode);
+ }
SetPageUptodate(page);
kunmap(page);
unlock_page(page);
@@ -95,11 +107,20 @@ static int udf_adinicb_write_end(struct file *file,
return simple_write_end(file, mapping, pos, len, copied, page, fsdata);
}
+static ssize_t udf_adinicb_direct_IO(int rw, struct kiocb *iocb,
+const struct iovec *iov,
+loff_t offset, unsigned long nr_segs)
+{
+ /* Fallback to buffered I/O. */
+ return 0;
+}
+
const struct address_space_operations udf_adinicb_aops = {
.readpage = udf_adinicb_readpage,
.writepage = udf_adinicb_writepage,
- .write_begin = simple_write_begin,
- .write_end = udf_adinicb_write_end,
+ .write_begin= simple_write_begin,
+ .write_end = udf_adinicb_write_end,
+ .direct_IO = udf_adinicb_direct_IO,
};
static ssize_t udf_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 1a0588e..b905448 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -95,6 +95,22 @@ void udf_evict_inode(struct inode *inode)
}
}
+static void udf_write_failed(struct address_space *mapping, loff_t to)
+{
+ struct inode *inode = mapping-host;
+ struct udf_inode_info *iinfo = UDF_I(inode);
+ loff_t isize = inode-i_size;
+
+ if (to isize) {
+ truncate_pagecache(inode, to, isize);
+ if (iinfo-i_alloc_type != ICBTAG_FLAG_AD_IN_ICB) {
+ down_write(iinfo-i_data_sem);
+ udf_truncate_extents(inode);
+ up_write(iinfo-i_data_sem);
+ }
+ }
+}
+
static int udf_writepage(struct page *page, struct writeback_control *wbc)
{
return block_write_full_page(page, udf_get_block, wbc);
@@ -124,21 +140,24 @@ static int udf_write_begin(struct file *file, struct
address_space *mapping,
int ret;
ret = block_write_begin
Re: [PATCH v2] udf: extent cache implementation for manipulating block map
2012/9/4 Jan Kara j...@suse.cz:
On Tue 04-09-12 16:45:42, Namjae Jeon wrote:
2012/9/3, Jan Kara j...@suse.cz:
+void udf_clear_extent_cache(struct udf_inode_info *iinfo)
+{
+ if (iinfo-cached_extent.sanity) {
+ brelse(iinfo-cached_extent.epos.bh);
+ memset(iinfo-cached_extent, 0, sizeof(struct udf_ext_cache));
+ }
+}
+
I think udf_clear_entent_cache() should take i_extent_cache_lock. Or if
you are sure it's not needed, you need a good documentation why.
Documentation ? I am a little confusing.. It means udf.txt is in
Documentation/filesystem/ ?
or comment about clear extent function ?
I meant in a comment before udf_clear_extent_cache() function...
Okay, I understood.
Thanks a lot.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] VFS: File System Mount Wide O_DIRECT Support
For file system created on file-backed loop device, there will be two-levels of
page cache present, which typically doubles the memory consumption.
In many cases, it is beneficial to turn on the O_DIRECT option while performing
the upper file system file IO, to bypass the upper page cache, which not only
reduces half
of the memory consumption, but also improves the performance due to shorter
copy path.
For example, the following iozone REREAD test with O_DIRECT turned on over the
one without
enjoys 10x speedup due to redundant cache elimination, consequently, avoiding
page cache thrashing
on a 2GB memory machine running 3.2.9 kernel.
losetup /dev/loop0 dummy // dummy is a ext4 file with a size of 1.1GB
mkfs -t ext2 /dev/loop0
mount /dev/loop0 /dsk
cd /dsk
iozone -t 1 -s 1G -r 4M -i 0 -+n -w // produce a 1GB test file
iozone -t 1 -s 1G -r 4M -i 1 -w // REREAD test without O_DIRECT
echo 1 /proc/sys/vm/drop_caches // cleanup the page cache
iozone -t 1 -s 1G -r 4M -i 1 -w -I // REREAD test with O_DIRECT
This feature is also expected to be useful for virtualization situation, the
file systems inside
the guest operation system will use much less of guest memory, which,
potencially results in less of
host memory use. Especially, it may be more useful if multiple guests are
running based
on a same disk image file.
The idea is simple, leave the desicion for the file system user to enable file
system mount
wide O_DIRECT support with a new mount option, for example,
losetup /dev/loop0 dummy
mount /dev/loop0 -o MS_DIRECT /dsk
Below is the preliminary patch,
---
fs/open.c |5 +
fs/super.c |2 ++
include/linux/fs.h |1 +
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index e1f2cdb..dacac30 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -958,6 +958,11 @@ long do_sys_open(int dfd, const char __user *filename, int
flags, umode_t mode)
} else {
fsnotify_open(f);
fd_install(fd, f);
+ if (f-f_vfsmnt-mnt_sb
f-f_vfsmnt-mnt_sb-s_flags MS_DIRECT) {
+ if
(S_ISREG(f-f_dentry-d_inode-i_mode)) {
+ if (!f-f_mapping-a_ops || ((!f-f_mapping-a_ops-direct_IO)
(!f-f_mapping-a_ops-get_xip_mem)))
+ f-f_flags |= O_DIRECT;
+ }
}
}
putname(tmp);
diff --git a/fs/super.c b/fs/super.c
index 0902cfa..ab5c4a5 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1147,6 +1147,8 @@ mount_fs(struct file_system_type *type, int flags, const
char *name, void *data)
WARN_ON(!sb-s_bdi);
WARN_ON(sb-s_bdi == default_backing_dev_info);
sb-s_flags |= MS_BORN;
+ if (flags MS_DIRECT)
+ sb-s_flags |= MS_DIRECT;
error = security_sb_kern_mount(sb, flags, secdata);
if (error)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index aa11047..127cc85 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -225,6 +225,7 @@ struct inodes_stat_t {
#define MS_KERNMOUNT (122) /* this is a kern_mount call */
#define MS_I_VERSION (123) /* Update inode I_version field */
#define MS_STRICTATIME (124) /* Always perform atime updates */
+#define MS_DIRECT (127)
#define MS_NOSEC (128)
#define MS_BORN(129)
#define MS_ACTIVE (130)
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] x86/oprofile: Fix the calltrace upon profiling some specified events with oprofile
Wei,
see my comments below.
On 27.08.12 09:32:13, wei.y...@windriver.com wrote:
From: Wei Yang wei.y...@windriver.com
Upon enabling the call-graph functionality of oprofile, A few minutes
later the following calltrace will always occur.
BUG: unable to handle kernel paging request at 656d6153
IP: [c10050f5] print_context_stack+0x55/0x110
*pde =
Oops: [#1] PREEMPT SMP
Modules linked in:
Pid: 0, comm: swapper/0 Not tainted 3.6.0-rc3-WR5.0+snapshot-20120820_standard
EIP: 0060:[c10050f5] EFLAGS: 00010093 CPU: 0
EIP is at print_context_stack+0x55/0x110
EAX: 656d7ffc EBX: 656d6153 ECX: c1837ee0 EDX: 656d6153
ESI: EDI: e000 EBP: f600deac ESP: f600de88
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 8005003b CR2: 656d6153 CR3: 01934000 CR4: 07d0
DR0: DR1: DR2: DR3:
DR6: 0ff0 DR7: 0400
Process swapper/0 (pid: 0, ti=f600c000 task=c18411a0 task.ti=c1836000)
Stack:
1a7f76ea 656d7ffc 656d6000 c1837ee0 e000 c1837ee0 656d6153 c188e27c
656d6000 f600dedc c10040f8 c188e27c f600def0 f600dec8 c1837ee0
f600ded4 c1837ee0 f600dfc4 001f f600df08 c1564d22
Call Trace:
[c10040f8] dump_trace+0x68/0xf0
[c1564d22] x86_backtrace+0xb2/0xc0
[c1562dd2] oprofile_add_sample+0xa2/0xc0
[c1003fbf] ? do_softirq+0x6f/0xa0
[c1566519] ppro_check_ctrs+0x79/0x100
[c15664a0] ? ppro_shutdown+0x60/0x60
[c156552f] profile_exceptions_notify+0x8f/0xb0
[c1672248] nmi_handle.isra.0+0x48/0x70
[c1672343] do_nmi+0xd3/0x3c0
[c1033d39] ? __local_bh_enable+0x29/0x70
[c1034620] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[c1671a0d] nmi_stack_correct+0x28/0x2d
[c1034620] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[c1003fbf] ? do_softirq+0x6f/0xa0
IRQ
[c1034ad5] irq_exit+0x65/0x70
[c16776f9] smp_apic_timer_interrupt+0x59/0x89
[c16717da] apic_timer_interrupt+0x2a/0x30
[c135164d] ? acpi_idle_enter_bm+0x245/0x273
[c14f3a25] cpuidle_enter+0x15/0x20
[c14f4070] cpuidle_idle_call+0xa0/0x320
[c1009705] cpu_idle+0x55/0xb0
[c16519a8] rest_init+0x6c/0x74
[c18a291b] start_kernel+0x2ec/0x2f3
[c18a2467] ? repair_env_string+0x51/0x51
[c18a22a2] i386_start_kernel+0x78/0x7d
Code: e0 ff ff 89 7d ec 74 5a 8d b4 26 00 00 00 00 8d bc 27 00 00
00 00 39 f3 72 0c 8b 45 f0 8d 64 24 18 5b 5e 5f 5d c3 3b 5d ec 72
ef 8b 3b 89 f8 89 7d dc e8 ef 40 04 00 85 c0 74 20 8b 40
EIP: [c10050f5] print_context_stack+0x55/0x110 SS:ESP 0068:f600de88
CR2: 656d6153
---[ end trace 751c9b47c6ff5e29 ]---
Let's assume a scenario that do_softirq() switches the stack to a soft irq
stack, and the soft irq stack is totally empty. At this moment, a nmi
interrupt
occurs, subsequently, CPU does not automatically save SS and SP registers
and switch any stack, but instead only stores EFLAGS, CS and IP to the soft
irq
stack. since the CPU is in kernel mode when the NMI exception occurs.
the layout of the current soft irq stack is this:
+--+-the top of soft irq
| EFLAGS |
+--+
|CS|
+--+
|IP|
+--+
| SAVE_ALL |
+--+
but the return value of the function kernel_stack_pointer() is'regs-sp'
(for x86_32 CPU), which is invoked by the x86_backtrace function. Since
the type of regs pointer is a pt_regs structure, the return value is not
in the range of the soft irq stack, as the SP register is not save in the
soft irq stack. Therefore, we need to check if the return value of the
function
resides in valid range. Additionally, the changes has no impact on the normal
NMI exception.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
arch/x86/oprofile/backtrace.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c
index d6aa6e8..a5fca0b 100644
--- a/arch/x86/oprofile/backtrace.c
+++ b/arch/x86/oprofile/backtrace.c
@@ -17,6 +17,11 @@
#include asm/ptrace.h
#include asm/stacktrace.h
+static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
+{
+ void *t = tinfo;
+ return p t + sizeof(struct thread_info) p t + THREAD_SIZE;
+}
static int backtrace_stack(void *data, char *name)
{
/* Yes, we want all stacks */
@@ -110,9 +115,14 @@ void
x86_backtrace(struct pt_regs * const regs, unsigned int depth)
{
struct stack_frame *head = (struct stack_frame *)frame_pointer(regs);
+ struct thread_info *context;
if (!user_mode_vm(regs)) {
unsigned long stack = kernel_stack_pointer(regs);
+ context = (struct thread_info *)
+ (stack (~(THREAD_SIZE - 1)));
You derive the context from a potential wrong stack here.
+ if (!valid_stack_ptr(context, (void *)stack))
Thus, you basically test this:
if (t (THREAD_SIZE - 1) sizeof(struct thread_info))
...
+
Re: [PATCH 5/5] virtio-scsi: introduce multiqueue support
Il 04/09/2012 10:46, Michael S. Tsirkin ha scritto:
+static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+ struct virtio_scsi *vscsi = shost_priv(sh);
+ struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+ unsigned long flags;
+ u32 queue_num;
+
+ /* Using an atomic_t for tgt-reqs lets the virtqueue handler
+ * decrement it without taking the spinlock.
+ */
Above comment is not really helpful - reader can be safely assumed to
know what atomic_t is.
Sure, the comment explains that we use an atomic because _elsewhere_ the
tgt_lock is not held while modifying reqs.
Please delete, and replace with the text from commit log
that explains the heuristic used to select req_vq.
Ok.
Also please add a comment near 'reqs' definition.
Something like number of outstanding requests - used to detect idle
target.
Ok.
+ spin_lock_irqsave(tgt-tgt_lock, flags);
Looks like this lock can be removed - req_vq is only
modified when target is idle and only used when it is
not idle.
If you have two incoming requests at the same time, req_vq is also
modified when the target is not idle; that's the point of the lock.
Suppose tgt-reqs = 0 initially, and you have two processors/queues.
Initially tgt-req_vq is queue #1. If you have this:
queuecommand on CPU #0 queuecommand #2 on CPU #1
--
atomic_inc_return(...) == 1
atomic_inc_return(...) == 2
virtscsi_queuecommand to queue #1
tgt-req_vq = queue #0
virtscsi_queuecommand to queue #0
then two requests are issued to different queues without a quiescent
point in the middle.
+ if (atomic_inc_return(tgt-reqs) == 1) {
+ queue_num = smp_processor_id();
+ while (unlikely(queue_num = vscsi-num_queues))
+ queue_num -= vscsi-num_queues;
+ tgt-req_vq = vscsi-req_vqs[queue_num];
+ }
+ spin_unlock_irqrestore(tgt-tgt_lock, flags);
+ return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
+
.
+static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+ struct virtio_scsi *vscsi = shost_priv(sh);
+ struct virtio_scsi_target_state *tgt = vscsi-tgt[sc-device-id];
+
+ atomic_inc(tgt-reqs);
+ return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
Here, reqs is unused - why bother incrementing it?
A branch on completion would be cheaper IMHO.
Well, I could also let tgt-reqs go negative, but it would be a bit untidy.
Another alternative is to access the target's target_busy field with
ACCESS_ONCE, and drop reqs altogether. Too tricky to do this kind of
micro-optimization so early, though.
virtio-scsi multiqueue has a performance benefit up to 20%
To be fair, you could be running in single queue mode.
In that case extra atomics and indirection that this code
brings will just add overhead without benefits.
I don't know how significant would that be.
Not measurable in my experiments.
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: Why exported const value modified by another driver not updated in original driver
On Tue, Sep 4, 2012 at 3:00 PM, Manavendra Nath Manav
mnm.ker...@gmail.com wrote:
Hi,
I have declared a static const int variable in one driver and exported
that variable symbol. In another driver i am modifying that variable.
The other driver prints the modified value but the original driver
retains the original value. When both virtual and physical addresses
of the variable as seen by both drivers are same, how is this even
possible. Is it a kernel bug?
[root@localhost bug]# uname -a
Linux localhost.localdomain 3.5.3 #3 SMP Mon Sep 3 21:52:12 IST 2012
i686 i686 i386 GNU/Linux
[root@localhost bug]# cat driver.c
#include linux/module.h
static const int value = 123;
int init_module()
{
printk(Base driver (init): value = %d\n, value);
printk(Base driver (init): virtual address of value = %p\n, (void
*)value);
printk(Base driver (init): physical address of value = %p\n, (void
*)__pa(value));
return 0;
}
void cleanup_module()
{
printk(Base driver (exit): value = %d\n, value);
printk(Base driver (exit): virtual address of value = %p\n, (void
*)value);
printk(Base driver (exit): physical address of value = %p\n, (void
*)__pa(value));
}
EXPORT_SYMBOL(value);
==
[root@localhost bug]# cat hacker.c
#include linux/module.h
extern int value;
int init_module()
{
value = 987;
printk(Hacker driver (init): value = %d\n,
value);
printk(Hacker Base driver (init): virtual address of value = %p\n,
(void *)value);
printk(Hacker Base driver (init): physical address of value = %p\n,
(void *)__pa(value));
return 0;
}
void cleanup_module()
{
printk(Hacker driver (exit): value = %d\n,
value);
printk(Hacker driver (exit): virtual address of value = %p\n,
(void *)value);
printk(Hacker driver (exit): physical address of value = %p\n,
(void *)__pa(value));
return;
}
=
[root@localhost bug]# insmod driver.ko
Base driver (init): value = 123
Base driver (init): virtual address of value = f89d61c8
Base driver (init): physical address of value = 389d61c8
[root@localhost bug]# insmod hacker.ko
Hacker driver (init): value = 987
Hacker Base driver (init): virtual address of value = f89d61c8
Hacker Base driver (init): physical address of value = 389d61c8
[root@localhost bug]# rmmod hacker.ko
Hacker driver (exit): value = 987
Hacker driver (exit): virtual address of value = f89d61c8
Hacker driver (exit): physical address of value = 389d61c8
[root@localhost bug]# rmmod driver.ko
Base driver (exit): value = 123
Base driver (exit): virtual address of value = f89d61c8
Base driver (exit): physical address of value = 389d61c8
[root@localhost bug]# cat /proc/kallsyms | grep value
f89f91c8 R value[driver]
f89f9088 r __ksymtab_value [driver]
f89f91cc r __kstrtab_value [driver]
Interestingly, when i change the declaration of variable to volatile
in driver.c as static const volatile int then the driver.ko prints
modified value 987 during rmmod and the original value 123 is
lost. What is the difference between this and previous declaration?
Please forgive if you find this question silly?
--
Manavendra Nath Manav
Is the above a genuine kernel bug, or i am missing something out here. Pls help.
Thanks,
Manavendra Nath Manav
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] fbdev fixes for 3.6
Hi Linus, please pull the fixes below. Thanks, Florian Tobias Schandinat The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0: Linux 3.6-rc3 (2012-08-22 13:29:06 -0700) are available in the git repository at: git://github.com/schandinat/linux-2.6.git fbdev-fixes-for-3.6-1 for you to fetch changes up to c1c52848cef52e157468b8879fc3cae23b6f3a99: OMAPFB: fix framebuffer console colors (2012-08-23 12:37:22 +) fbdev fixes for 3.6 - a fix by Paul Cercueil to prevent a possible buffer overflow - a fix by Bruno Prémont to prevent a rare sleep in invalid context - a fix by Julia Lawall for a double free in auo_k190x - a fix by Dan Carpenter to prevent a division by zero in mb862xxfb - a regression fix by Tomi Valkeinen for the SDI output in OMAP - a fix by Grazvydas Ignotas to fix the console colors in OMAP Bruno Prémont (1): fbcon: Fix bit_putcs() call to kmalloc(s, GFP_KERNEL) Dan Carpenter (1): video: mb862xxfb: prevent divide by zero bug Grazvydas Ignotas (1): OMAPFB: fix framebuffer console colors Julia Lawall (1): drivers/video/auo_k190x.c: drop kfree of devm_kzalloc's data Paul Cercueil (1): fbcon: prevent possible buffer overflow. Tomi Valkeinen (1): OMAPDSS: Fix SDI PLL locking drivers/video/auo_k190x.c|2 -- drivers/video/console/bitblit.c |2 +- drivers/video/console/fbcon.c|2 +- drivers/video/mb862xx/mb862xxfbdrv.c |2 ++ drivers/video/omap2/dss/sdi.c| 14 ++ drivers/video/omap2/omapfb/omapfb-main.c |2 +- 6 files changed, 19 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: allow user to indicate path to objdump in command line
When analyzing perf data from hosts of other architecture than one of the local
host it's useful to call objdump that is part of a toolchain for that
architecture. Instead of calling regular objdump, call one that user specified
in command line.
Signed-off-by: Maciek Borzecki maciek.borze...@gmail.com
---
tools/perf/Documentation/perf-annotate.txt | 3 +++
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-annotate.c | 2 ++
tools/perf/builtin-report.c| 2 ++
tools/perf/util/annotate.c | 4 +++-
tools/perf/util/annotate.h | 1 +
6 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-annotate.txt
b/tools/perf/Documentation/perf-annotate.txt
index c89f9e1..c8ffd9f 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -85,6 +85,9 @@ OPTIONS
-M::
--disassembler-style=:: Set disassembler style for objdump.
+--objdump=path::
+Path to objdump binary.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-report[1]
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 2d89f02..2da267f 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -168,6 +168,9 @@ OPTIONS
branch stacks and it will automatically switch to the branch view mode,
unless --no-branch-stack is used.
+--objdump=path::
+Path to objdump binary.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-annotate[1]
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 67522cf..2f3f002 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -282,6 +282,8 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __used)
Display raw encoding of assembly instructions (default)),
OPT_STRING('M', disassembler-style, disassembler_style,
disassembler style,
Specify disassembler style (e.g. -M intel for intel
syntax)),
+ OPT_STRING(0, objdump, objdump_path, path,
+ objdump binary to use for disassembly and annotations),
OPT_END()
};
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 25249f7..dad231b 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -635,6 +635,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __used)
Show a column with the sum of periods),
OPT_CALLBACK_NOOPT('b', branch-stack, sort__branch_mode, ,
use branch records for histogram filling,
parse_branch_mode),
+ OPT_STRING(0, objdump, objdump_path, path,
+ objdump binary to use for disassembly and annotations),
OPT_END()
};
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 8069dfb..be7290c 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -17,6 +17,7 @@
#include pthread.h
const char *disassembler_style;
+const char *objdump_path;
static struct ins *ins__find(const char *name);
static int disasm_line__parse(char *line, char **namep, char **rawp);
@@ -809,9 +810,10 @@ fallback:
dso, dso-long_name, sym, sym-name);
snprintf(command, sizeof(command),
-objdump %s%s --start-address=0x%016 PRIx64
+%s %s%s --start-address=0x%016 PRIx64
--stop-address=0x%016 PRIx64
-d %s %s -C %s|grep -v %s|expand,
+objdump_path ? objdump_path : objdump,
disassembler_style ? -M : ,
disassembler_style ? disassembler_style : ,
map__rip_2objdump(map, sym-start),
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 78a5692..a6d6bc5 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -152,5 +152,6 @@ int symbol__tui_annotate(struct symbol *sym, struct map
*map, int evidx,
#endif
extern const char *disassembler_style;
+extern const char *objdump_path;
#endif /* __PERF_ANNOTATE_H */
--
1.7.11.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: Why exported const value modified by another driver not updated in original driver
On Tue, Sep 04, 2012 at 03:58:20PM +0530, Manavendra Nath Manav wrote: On Tue, Sep 4, 2012 at 3:00 PM, Manavendra Nath Manav mnm.ker...@gmail.com wrote: Hi, I have declared a static const int variable in one driver and exported that variable symbol. In another driver i am modifying that variable. No, you did not export it. It's static (and static is kind of the opposite of extern). And then you try to assign a value to a non-static variable with the same name, which might not even exist (as the other is static, this should not even work in my opinion). The other driver prints the modified value but the original driver retains the original value. When both virtual and physical addresses of the variable as seen by both drivers are same, how is this even possible. Is it a kernel bug? It only works because the compiler optimized the value = 123 away, and replaced value with 123 in the first module everywhere, as it is declared const and thus cannot be changed, so there's no reason to read it from memory. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why exported const value modified by another driver not updated in original driver
On Tue, 4 Sep 2012 15:00:16 +0530 Manavendra Nath Manav mnm.ker...@gmail.com wrote: Hi, I have declared a static const int variable in one driver and exported that variable symbol. In another driver i am modifying that variable. The other driver prints the modified value but the original driver retains the original value. When both virtual and physical addresses of the variable as seen by both drivers are same, how is this even possible. Is it a kernel bug? It's const, why is it even a surprise. If you don't understand what is going on then I suggest you disassemble the code. That will I think let you understand what is going on. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] VFS: File System Mount Wide O_DIRECT Support
On Tue, Sep 04, 2012 at 06:17:47PM +0800, Li Wang wrote: For file system created on file-backed loop device, there will be two-levels of page cache present, which typically doubles the memory consumption. And the right fix is to not use buffer I/O on the backing file instead of hacks like 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/
Re: Why exported const value modified by another driver not updated in original driver
On Tue, Sep 4, 2012 at 4:09 PM, Julian Andres Klode j...@jak-linux.org wrote: On Tue, Sep 04, 2012 at 03:58:20PM +0530, Manavendra Nath Manav wrote: On Tue, Sep 4, 2012 at 3:00 PM, Manavendra Nath Manav mnm.ker...@gmail.com wrote: Hi, I have declared a static const int variable in one driver and exported that variable symbol. In another driver i am modifying that variable. No, you did not export it. It's static (and static is kind of the opposite of extern). And then you try to assign a value to a non-static variable with the same name, which might not even exist (as the other is static, this should not even work in my opinion). The other driver prints the modified value but the original driver retains the original value. When both virtual and physical addresses of the variable as seen by both drivers are same, how is this even possible. Is it a kernel bug? It only works because the compiler optimized the value = 123 away, and replaced value with 123 in the first module everywhere, as it is declared const and thus cannot be changed, so there's no reason to read it from memory. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Still I am not able to understand !! Why the output behaviour changes when the declaration is made as const volatile. I get the same results as above when i remove static and retain const. -- Manavendra Nath Manav -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] virtio-scsi: introduce multiqueue support
On Tue, Sep 04, 2012 at 12:25:03PM +0200, Paolo Bonzini wrote:
Il 04/09/2012 10:46, Michael S. Tsirkin ha scritto:
+static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+struct virtio_scsi *vscsi = shost_priv(sh);
+struct virtio_scsi_target_state *tgt =
vscsi-tgt[sc-device-id];
+unsigned long flags;
+u32 queue_num;
+
+/* Using an atomic_t for tgt-reqs lets the virtqueue handler
+ * decrement it without taking the spinlock.
+ */
Above comment is not really helpful - reader can be safely assumed to
know what atomic_t is.
Sure, the comment explains that we use an atomic because _elsewhere_ the
tgt_lock is not held while modifying reqs.
Please delete, and replace with the text from commit log
that explains the heuristic used to select req_vq.
Ok.
Also please add a comment near 'reqs' definition.
Something like number of outstanding requests - used to detect idle
target.
Ok.
+spin_lock_irqsave(tgt-tgt_lock, flags);
Looks like this lock can be removed - req_vq is only
modified when target is idle and only used when it is
not idle.
If you have two incoming requests at the same time, req_vq is also
modified when the target is not idle; that's the point of the lock.
Suppose tgt-reqs = 0 initially, and you have two processors/queues.
Initially tgt-req_vq is queue #1. If you have this:
queuecommand on CPU #0 queuecommand #2 on CPU #1
--
atomic_inc_return(...) == 1
atomic_inc_return(...) == 2
virtscsi_queuecommand to queue #1
tgt-req_vq = queue #0
virtscsi_queuecommand to queue #0
then two requests are issued to different queues without a quiescent
point in the middle.
What happens then? Does this break correctness?
+if (atomic_inc_return(tgt-reqs) == 1) {
+queue_num = smp_processor_id();
+while (unlikely(queue_num = vscsi-num_queues))
+queue_num -= vscsi-num_queues;
+tgt-req_vq = vscsi-req_vqs[queue_num];
+}
+spin_unlock_irqrestore(tgt-tgt_lock, flags);
+return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
+
.
+static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
+ struct scsi_cmnd *sc)
+{
+ struct virtio_scsi *vscsi = shost_priv(sh);
+ struct virtio_scsi_target_state *tgt =
vscsi-tgt[sc-device-id];
+
+ atomic_inc(tgt-reqs);
+ return virtscsi_queuecommand(vscsi, tgt, sc);
+}
+
Here, reqs is unused - why bother incrementing it?
A branch on completion would be cheaper IMHO.
Well, I could also let tgt-reqs go negative, but it would be a bit untidy.
Another alternative is to access the target's target_busy field with
ACCESS_ONCE, and drop reqs altogether. Too tricky to do this kind of
micro-optimization so early, though.
So keep it simple and just check a flag.
virtio-scsi multiqueue has a performance benefit up to 20%
To be fair, you could be running in single queue mode.
In that case extra atomics and indirection that this code
brings will just add overhead without benefits.
I don't know how significant would that be.
Not measurable in my experiments.
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] virtio-scsi: introduce multiqueue support
Il 04/09/2012 13:09, Michael S. Tsirkin ha scritto: queuecommand on CPU #0 queuecommand #2 on CPU #1 -- atomic_inc_return(...) == 1 atomic_inc_return(...) == 2 virtscsi_queuecommand to queue #1 tgt-req_vq = queue #0 virtscsi_queuecommand to queue #0 then two requests are issued to different queues without a quiescent point in the middle. What happens then? Does this break correctness? Yes, requests to the same target should be processed in FIFO order, or you have things like a flush issued before the write it was supposed to flush. This is why I can only change the queue when there is no request pending. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 1/2] virtio_console: Add support for DMA memory allocation
Hi Michael,
If an architecture do not support DMA you will get
a link error: unknown symbol for dma_alloc_coherent.
Yes, it even seems intentional.
But I have a question: can the device work without DMA?
The main dependency is actually on the dma-allocation.
In my case I do dma_declare_coherent_memory() with
the memory area shared with the remote device as argument.
Subsequent calls to dma_alloc_coherent() will then allocate
from this memory area.
Does not VIRTIO_CONSOLE_F_DMA_MEM mean dma api is required?
Yes.dma_alloc_coherent to work.
If yes you should just fail load.
Agree, I'll check on VIRTIO_CONSOLE_HAS_DMA before adding
VIRTIO_CONSOLE_F_DMA_MEM to the feature array.
Also let's add a wrapper at top of file so ifdefs
do not litter the code like this. For example:
#ifdef CONFIG_HAS_DMA
#define VIRTIO_CONSOLE_HAS_DMA (1)
#else
#define VIRTIO_CONSOLE_HAS_DMA (0)
#endif
OK, good point. Perhaps we could even exploit gcc's
ability to remove dead code and do something like this:
if (VIRTIO_CONSOLE_HAS_DMA
virtio_has_feature(vdev, VIRTIO_CONSOLE_F_DMA_MEM)) {
...
This does not give any linker warnings when compiling for UML (no DMA).
Regards,
Sjur
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
