* Re: [Qemu-devel] [PATCH 29/35] scsi-disk: remove cluster_size
From: Kevin Wolf @ 2011-10-24 15:10 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <1318503845-11473-30-git-send-email-pbonzini@redhat.com>
Am 13.10.2011 13:03, schrieb Paolo Bonzini:
> This field is redundant, and its presence makes it more complicated
> to share reqops between the upcoming scsi-block and scsi-generic.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> hw/scsi-disk.c | 45 ++++++++++++++++++++++-----------------------
> 1 files changed, 22 insertions(+), 23 deletions(-)
>
> diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
> index 5e3ef51..7f2f67f 100644
> --- a/hw/scsi-disk.c
> +++ b/hw/scsi-disk.c
> @@ -65,9 +65,6 @@ typedef struct SCSIDiskReq {
> struct SCSIDiskState
> {
> SCSIDevice qdev;
> - /* The qemu block layer uses a fixed 512 byte sector size.
> - This is the number of 512 byte blocks in a single scsi sector. */
> - int cluster_size;
> uint32_t removable;
> uint64_t max_lba;
> bool media_changed;
> @@ -862,7 +859,7 @@ static int mode_sense_page(SCSIDiskState *s, int page, uint8_t **p_outbuf,
> bdrv_get_geometry_hint(bdrv, &cylinders, &heads, &secs);
> p[4] = heads & 0xff;
> p[5] = secs & 0xff;
> - p[6] = s->cluster_size * 2;
> + p[6] = s->qdev.blocksize >> 8;
> p[8] = (cylinders >> 8) & 0xff;
> p[9] = cylinders & 0xff;
> /* Write precomp start cylinder, disabled */
> @@ -991,7 +988,7 @@ static int scsi_disk_emulate_mode_sense(SCSIDiskReq *r, uint8_t *outbuf)
> } else { /* MODE_SENSE_10 */
> outbuf[7] = 8; /* Block descriptor length */
> }
> - nb_sectors /= s->cluster_size;
> + nb_sectors /= (s->qdev.blocksize / 512);
> if (nb_sectors > 0xffffff)
> nb_sectors = 0;
> p[0] = 0; /* media density code */
> @@ -1000,7 +997,7 @@ static int scsi_disk_emulate_mode_sense(SCSIDiskReq *r, uint8_t *outbuf)
> p[3] = nb_sectors & 0xff;
> p[4] = 0; /* reserved */
> p[5] = 0; /* bytes 5-7 are the sector size in bytes */
> - p[6] = s->cluster_size * 2;
> + p[6] = s->qdev.blocksize >> 8;
> p[7] = 0;
> p += 8;
> }
> @@ -1050,7 +1047,7 @@ static int scsi_disk_emulate_read_toc(SCSIRequest *req, uint8_t *outbuf)
> start_track = req->cmd.buf[6];
> bdrv_get_geometry(s->qdev.conf.bs, &nb_sectors);
> DPRINTF("Read TOC (track %d format %d msf %d)\n", start_track, format, msf >> 1);
> - nb_sectors /= s->cluster_size;
> + nb_sectors /= s->qdev.blocksize / 512;
> switch (format) {
> case 0:
> toclen = cdrom_read_toc(nb_sectors, outbuf, msf, start_track);
> @@ -1176,7 +1173,7 @@ static int scsi_disk_emulate_command(SCSIDiskReq *r)
> if ((req->cmd.buf[8] & 1) == 0 && req->cmd.lba) {
> goto illegal_request;
> }
> - nb_sectors /= s->cluster_size;
> + nb_sectors /= s->qdev.blocksize / 512;
> /* Returned value is the address of the last sector. */
> nb_sectors--;
> /* Remember the new size for read/write sanity checking. */
> @@ -1190,7 +1187,7 @@ static int scsi_disk_emulate_command(SCSIDiskReq *r)
> outbuf[3] = nb_sectors & 0xff;
> outbuf[4] = 0;
> outbuf[5] = 0;
> - outbuf[6] = s->cluster_size * 2;
> + outbuf[6] = s->qdev.blocksize >> 8;
> outbuf[7] = 0;
> buflen = 8;
> break;
> @@ -1226,7 +1223,7 @@ static int scsi_disk_emulate_command(SCSIDiskReq *r)
> if ((req->cmd.buf[14] & 1) == 0 && req->cmd.lba) {
> goto illegal_request;
> }
> - nb_sectors /= s->cluster_size;
> + nb_sectors /= s->qdev.blocksize / 512;
> /* Returned value is the address of the last sector. */
> nb_sectors--;
> /* Remember the new size for read/write sanity checking. */
> @@ -1241,7 +1238,7 @@ static int scsi_disk_emulate_command(SCSIDiskReq *r)
> outbuf[7] = nb_sectors & 0xff;
> outbuf[8] = 0;
> outbuf[9] = 0;
> - outbuf[10] = s->cluster_size * 2;
> + outbuf[10] = s->qdev.blocksize >> 8;
> outbuf[11] = 0;
> outbuf[12] = 0;
> outbuf[13] = get_physical_block_exp(&s->qdev.conf);
> @@ -1349,8 +1346,8 @@ static int32_t scsi_send_command(SCSIRequest *req, uint8_t *buf)
> DPRINTF("Read (sector %" PRId64 ", count %d)\n", r->req.cmd.lba, len);
> if (r->req.cmd.lba > s->max_lba)
> goto illegal_lba;
> - r->sector = r->req.cmd.lba * s->cluster_size;
> - r->sector_count = len * s->cluster_size;
> + r->sector = r->req.cmd.lba * (s->qdev.blocksize / 512);
> + r->sector_count = len * (s->qdev.blocksize / 512);
> break;
> case WRITE_6:
> case WRITE_10:
> @@ -1365,8 +1362,8 @@ static int32_t scsi_send_command(SCSIRequest *req, uint8_t *buf)
> r->req.cmd.lba, len);
> if (r->req.cmd.lba > s->max_lba)
> goto illegal_lba;
> - r->sector = r->req.cmd.lba * s->cluster_size;
> - r->sector_count = len * s->cluster_size;
> + r->sector = r->req.cmd.lba * (s->qdev.blocksize / 512);
> + r->sector_count = len * (s->qdev.blocksize / 512);
> break;
> case MODE_SELECT:
> DPRINTF("Mode Select(6) (len %lu)\n", (long)r->req.cmd.xfer);
> @@ -1409,8 +1406,9 @@ static int32_t scsi_send_command(SCSIRequest *req, uint8_t *buf)
> goto fail;
> }
>
> - rc = bdrv_discard(s->qdev.conf.bs, r->req.cmd.lba * s->cluster_size,
> - len * s->cluster_size);
> + rc = bdrv_discard(s->qdev.conf.bs,
> + r->req.cmd.lba * (s->qdev.blocksize / 512),
> + len * (s->qdev.blocksize / 512));
> if (rc < 0) {
> /* XXX: better error code ?*/
> goto fail;
> @@ -1450,12 +1448,14 @@ static void scsi_disk_reset(DeviceState *dev)
>
> scsi_device_purge_requests(&s->qdev, SENSE_CODE(RESET));
>
> - bdrv_get_geometry(s->qdev.conf.bs, &nb_sectors);
> - nb_sectors /= s->cluster_size;
> - if (nb_sectors) {
> - nb_sectors--;
> + if (s->qdev.blocksize) {
When would it be 0? And wouldn't we crash with a zero blocksize anyway?
Kevin
^ permalink raw reply
* Re: [PATCH 1/2] x86 swiotlb: Verify we can perform the remapping requested.
From: Eric W. Biederman @ 2011-10-24 15:07 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: fujita.tomonori, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86, linux-kernel
In-Reply-To: <20111021004031.GB13687@phenom.dumpdata.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:
> On Mon, Oct 17, 2011 at 02:19:18PM -0700, Eric W. Biederman wrote:
>>
>> Recently I had a driver try with a peculiar 2G dma memory limit.
>> It failed in weird and strange ways because my bounce buffers were
>> being allocated above 2G where the driver could not reach, and
>> no error was reported when the mappings were setup.
>
> OK, so the overflow buffer was used instead.. which presumarily
> also was allocated above the 2G? That seems to point that
> alloc_bootmem_low_pages is not doing its job?
I just looked alloc_bootmem_low_pages allocates memory below
ARCH_ADDRESS_LIMIT which for everything except s390 is 4G.
I know I was mostly using the amd gart driver. So I may be mistaken
that the swiotlb driver had the same issue. However my only solution
at the time was to boot with mem=2G. So I believe the swiotlb did
have this issue.
Mostly the patch was. Hmm. That looks stupid not wiring up the
swiotlb address space limit check when someone has already written it.
>> Use the swiotlb_dma_supported to avoid silent problems like this
>> in the future.
>
> Which driver was it that had this limit?
An unmerged driver. The driver has since been fixed to use it's
hardware in a way that doesn't hit this limit.
At the time that I looked drivers in the kernel with a dma limit
above 16MB and blow 4GB only existed on exotic architectures in
very special cases.
Unfortunately I no longer have access to this hardware to test with.
Eric
^ permalink raw reply
* Re: [PATCH] swapfile.c: Initialize a variable.
From: Michal Hocko @ 2011-10-24 15:06 UTC (permalink / raw)
To: Il Han; +Cc: linux-mm
In-Reply-To: <1317876074-25417-1-git-send-email-corone.il.han@gmail.com>
On Thu 06-10-11 13:41:14, Il Han wrote:
> Initialize the variable to remove the following warning.
>
> mm/swapfile.c:2028: warning: 'span' may be used uninitialized in this function
>
> Initialize it.
It looks that the warning is bogus because span is always initialized
if nr_extents >=0. Check out setup_swap_map_and_extents and
setup_swap_extents (for S_ISBLK it is trivial and for S_ISREG we are
setting the value after we jump out of the loop and all error cases go
either to out directly or through bad_bmap labels).
It should be much better to use uninitialized_var instead if we just
want to shut up compiler.
>
> Signed-off-by: Il Han <corone.il.han@gmail.com>
> ---
> mm/swapfile.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 17bc224..d5ca685 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -2016,7 +2016,7 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
> int error;
> union swap_header *swap_header;
> int nr_extents;
> - sector_t span;
> + sector_t span = 0;
> unsigned long maxpages;
> unsigned char *swap_map = NULL;
> struct page *page = NULL;
> --
> 1.7.4.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Channel-less IIO events
From: Lars-Peter Clausen @ 2011-10-24 15:05 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio@vger.kernel.org
In-Reply-To: <4EA57547.3010804@cam.ac.uk>
On 10/24/2011 04:25 PM, Jonathan Cameron wrote:
> On 10/24/11 14:47, Lars-Peter Clausen wrote:
>> Hi,
>>
>> Some chips generate events which don't really map to a channel, but are
>> rather chip global. For example over-temperature events.
> That one is a channel.
>> Do you think this is something we should add support for or should we rather
>> use a dummy channel, which doesn't report any actual values, for propagating
>> the event?
> Yup, have a temp channel for that one. Conceptually you might have two chips
> that are otherwise identical but one has a readable temp channel, the other
> doesn't. Userspace that is interested only in events won't care about
> this difference. Also we want to report what the conditions are as if it were
> a channel we could read. We want to know at what temperature this occurs.
Ok, what should a read on such a channel return, an error value or just an
dummy value?
> [...]
>>
>> My idea for supporting channel-less events is to add a event_mask to struct
>> iio_info, which would be used just like a channels event_mask, but there
>> would be no index for the sysfs attributes and for events we would set the
>> event number to 0xffff.
> Could you give more examples? The temp one to my mind definitely needs a
> channel, perhaps others do not? I am not against in principal but not
> yet certain exactly when this would make sense...
over-temperature is the only one i've seen so far. but other could be
under-current or voltage for the whole chip.
Thanks
- Lars
^ permalink raw reply
* [PATCH] mmc: debugfs: parse all ext_csd via debug_fs
From: Giuseppe CAVALLARO @ 2011-10-24 15:04 UTC (permalink / raw)
To: linux-mmc; +Cc: Giuseppe Cavallaro
This patch enhances the debug information reported
for the mmc card by parsing the extended CSD registers
obviously according to all the current specifications.
I have no HW to test eMMC 4.5 at this moment. In any case,
the patch supports JEDEC Standard No. 84-B45.
No issues on JESD84-A441 and older specs raised on my side.
Output from /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
looks like this:
Extended CSD rev 1.5 (MMC 4.41)
s_cmd_set: 0x01
hpi_features: 0x00
blops_support: 0x00
ini_timeout_ap: 0x0a
pwr_cl_ddr_52_360 0x00
[snip]
Reported-by: Youssef Triki <youssef.triki@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/mmc/core/debugfs.c | 266 ++++++++++++++++++++++++++++++++++++++------
1 files changed, 232 insertions(+), 34 deletions(-)
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 0b9a4aa..3771624 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -223,19 +223,13 @@ static int mmc_dbg_card_status_get(void *data, u64 *val)
DEFINE_SIMPLE_ATTRIBUTE(mmc_dbg_card_status_fops, mmc_dbg_card_status_get,
NULL, "%08llx\n");
-#define EXT_CSD_STR_LEN 1025
-
-static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
+static int mmc_ext_csd_read(struct seq_file *s, void *data)
{
- struct mmc_card *card = inode->i_private;
- char *buf;
- ssize_t n = 0;
+ struct mmc_card *card = s->private;
u8 *ext_csd;
- int err, i;
-
- buf = kmalloc(EXT_CSD_STR_LEN + 1, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
+ u8 ext_csd_rev;
+ int err;
+ const char *str;
ext_csd = kmalloc(512, GFP_KERNEL);
if (!ext_csd) {
@@ -249,41 +243,245 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
if (err)
goto out_free;
- for (i = 511; i >= 0; i--)
- n += sprintf(buf + n, "%02x", ext_csd[i]);
- n += sprintf(buf + n, "\n");
- BUG_ON(n != EXT_CSD_STR_LEN);
+ ext_csd_rev = ext_csd[192];
- filp->private_data = buf;
- kfree(ext_csd);
- return 0;
+ if (ext_csd_rev > 6)
+ goto out_free;
+
+ switch (ext_csd_rev) {
+ case 6:
+ str = "4.5";
+ break;
+ case 5:
+ str = "4.41";
+ break;
+ case 3:
+ str = "4.3";
+ break;
+ case 2:
+ str = "4.2";
+ break;
+ case 1:
+ str = "4.1";
+ break;
+ default:
+ goto out_free;
+ }
+ seq_printf(s, "Extended CSD rev 1.%d (MMC %s)\n", ext_csd_rev, str);
+
+ if (ext_csd_rev < 3)
+ goto out_free; /* No ext_csd */
+
+ /* Parse the Extended CSD registers.
+ * Reserved bit should be read as "0" in case of spec older
+ * than A441.
+ */
+ seq_printf(s, "s_cmd_set: 0x%02x\n", ext_csd[504]);
+ seq_printf(s, "hpi_features: 0x%02x\n", ext_csd[503]);
+ seq_printf(s, "blops_support: 0x%02x\n", ext_csd[502]);
+
+ if (ext_csd_rev >= 6) { /* eMMC 4.5 */
+ unsigned int cache_size = ext_csd[249] << 0 |
+ ext_csd[250] << 8 |
+ ext_csd[251] << 16 |
+ ext_csd[252] << 24;
+ seq_printf(s, "max_packed_reads: 0x%02x\n", ext_csd[501]);
+ seq_printf(s, "max_packed_writes: 0x%02x\n", ext_csd[500]);
+ seq_printf(s, "data_tag_support: 0x%02x\n", ext_csd[499]);
+ seq_printf(s, "tag_unit_size: 0x%02x\n", ext_csd[498]);
+ seq_printf(s, "tag_res_size: 0x%02x\n", ext_csd[497]);
+ seq_printf(s, "context_capability: 0x%02x\n", ext_csd[496]);
+ seq_printf(s, "large_unit_size_m1: 0x%02x\n", ext_csd[495]);
+ seq_printf(s, "ext_support: 0x%02x\n", ext_csd[494]);
+ if (cache_size)
+ seq_printf(s, "cache_size[]: %d KiB\n", cache_size);
+ else
+ seq_printf(s, "No cache existing\n");
+
+ seq_printf(s, "generic_cmd6_time: 0x%02x\n", ext_csd[248]);
+ seq_printf(s, "power_off_long_time: 0x%02x\n", ext_csd[247]);
+ }
+
+ /* A441: Reserved [501:247]
+ A43: reserved [246:229] */
+ if (ext_csd_rev >= 5) {
+ seq_printf(s, "ini_timeout_ap: 0x%02x\n", ext_csd[241]);
+ /* A441: reserved [240] */
+ seq_printf(s, "pwr_cl_ddr_52_360 0x%02x\n", ext_csd[239]);
+ seq_printf(s, "pwr_cl_ddr_52_195 0x%02x\n", ext_csd[238]);
+
+ /* A441: reserved [237-236] */
+
+ if (ext_csd_rev >= 6) {
+ seq_printf(s, "pwr_cl_200_360 0x%02x\n", ext_csd[237]);
+ seq_printf(s, "pwr_cl_200_195 0x%02x\n", ext_csd[236]);
+ }
+
+ seq_printf(s, "min_perf_ddr_w_8_52 0x%02x\n", ext_csd[235]);
+ seq_printf(s, "min_perf_ddr_r_8_52 0x%02x\n", ext_csd[234]);
+ /* A441: reserved [233] */
+ seq_printf(s, "trim_mult 0x%02x\n", ext_csd[232]);
+ seq_printf(s, "sec_feature_support 0x%02x\n", ext_csd[231]);
+ }
+ if (ext_csd_rev == 5) { /* Obsolete in 4.5 */
+ seq_printf(s, "sec_erase_mult 0x%02x\n", ext_csd[230]);
+ seq_printf(s, "sec_trim_mult 0x%02x\n", ext_csd[229]);
+ }
+ seq_printf(s, "boot_info 0x%02x\n", ext_csd[228]);
+ /* A441/A43: reserved [227] */
+ seq_printf(s, "boot_size_multi 0x%02x\n", ext_csd[226]);
+ seq_printf(s, "acc_size 0x%02x\n", ext_csd[225]);
+ seq_printf(s, "hc_erase_grp_size 0x%02x\n", ext_csd[224]);
+ seq_printf(s, "erase_timeout_mult 0x%02x\n", ext_csd[223]);
+ seq_printf(s, "rel_wr_sec_c 0x%02x\n", ext_csd[222]);
+ seq_printf(s, "hc_wp_grp_size 0x%02x\n", ext_csd[221]);
+ seq_printf(s, "s_c_vcc 0x%02x\n", ext_csd[220]);
+ seq_printf(s, "s_c_vccq 0x%02x\n", ext_csd[219]);
+ /* A441/A43: reserved [218] */
+ seq_printf(s, "s_a_timeout 0x%02x\n", ext_csd[217]);
+ /* A441/A43: reserved [216] */
+ seq_printf(s, "sec_count 0x%02x\n", (ext_csd[215] << 24) |
+ (ext_csd[214] << 16) | (ext_csd[213] << 8) |
+ ext_csd[212]);
+ /* A441/A43: reserved [211] */
+ seq_printf(s, "min_perf_w_8_52 0x%02x\n", ext_csd[210]);
+ seq_printf(s, "min_perf_r_8_52 0x%02x\n", ext_csd[209]);
+ seq_printf(s, "min_perf_w_8_26_4_52 0x%02x\n", ext_csd[208]);
+ seq_printf(s, "min_perf_r_8_26_4_52 0x%02x\n", ext_csd[207]);
+ seq_printf(s, "min_perf_w_4_26 0x%02x\n", ext_csd[206]);
+ seq_printf(s, "min_perf_r_4_26 0x%02x\n", ext_csd[205]);
+ /* A441/A43: reserved [204] */
+ seq_printf(s, "pwr_cl_26_360 0x%02x\n", ext_csd[203]);
+ seq_printf(s, "pwr_cl_52_360 0x%02x\n", ext_csd[202]);
+ seq_printf(s, "pwr_cl_26_195 0x%02x\n", ext_csd[201]);
+ seq_printf(s, "pwr_cl_52_195 0x%02x\n", ext_csd[200]);
+
+ /* A43: reserved [199:198] */
+ if (ext_csd_rev >= 5) {
+ seq_printf(s, "partition_switch_time 0x%02x\n", ext_csd[199]);
+ seq_printf(s, "out_of_interrupt_time 0x%02x\n", ext_csd[198]);
+ }
+
+ /* A441/A43: reserved [197] [195] [193] [190] [188]
+ * [186] [184] [182] [180] [176] */
+
+ if (ext_csd_rev >= 6)
+ seq_printf(s, "driver_strength 0x%02x\n", ext_csd[197]);
+
+ seq_printf(s, "card_type 0x%02x\n", ext_csd[196]);
+ seq_printf(s, "csd_structure 0x%02x\n", ext_csd[194]);
+ seq_printf(s, "ext_csd_rev 0x%02x\n", ext_csd[192]);
+ seq_printf(s, "cmd_set 0x%02x\n", ext_csd[191]);
+ seq_printf(s, "cmd_set_rev 0x%02x\n", ext_csd[189]);
+ seq_printf(s, "power_class 0x%02x\n", ext_csd[187]);
+ seq_printf(s, "hs_timing 0x%02x\n", ext_csd[185]);
+ seq_printf(s, "bus_width 0x%02x\n", ext_csd[183]);
+ seq_printf(s, "erased_mem_cont 0x%02x\n", ext_csd[181]);
+ seq_printf(s, "partition_config 0x%02x\n", ext_csd[179]);
+ seq_printf(s, "boot_config_prot 0x%02x\n", ext_csd[178]);
+ seq_printf(s, "boot_bus_width 0x%02x\n", ext_csd[177]);
+ seq_printf(s, "erase_group_def 0x%02x\n", ext_csd[175]);
+
+ /* A43: reserved [174:0] / A441: reserved [174] */
+ if (ext_csd_rev >= 5) {
+ seq_printf(s, "boot_wp 0x%02x\n", ext_csd[173]);
+ /* A441: reserved [172] */
+ seq_printf(s, "user_wp 0x%02x\n", ext_csd[171]);
+ /* A441: reserved [170] */
+ seq_printf(s, "fw_config 0x%02x\n", ext_csd[169]);
+ seq_printf(s, "rpmb_size_mult 0x%02x\n", ext_csd[168]);
+ seq_printf(s, "wr_rel_set 0x%02x\n", ext_csd[167]);
+ seq_printf(s, "wr_rel_param 0x%02x\n", ext_csd[166]);
+ /* A441: reserved [165] */
+ seq_printf(s, "bkops_start 0x%02x\n", ext_csd[164]);
+ seq_printf(s, "bkops_en 0x%02x\n", ext_csd[163]);
+ seq_printf(s, "rst_n_function 0x%02x\n", ext_csd[162]);
+ seq_printf(s, "hpi_mgmt 0x%02x\n", ext_csd[161]);
+ seq_printf(s, "partitioning_support 0x%02x\n", ext_csd[160]);
+ seq_printf(s, "max_enh_size_mult[2] 0x%02x\n", ext_csd[159]);
+ seq_printf(s, "max_enh_size_mult[1] 0x%02x\n", ext_csd[158]);
+ seq_printf(s, "max_enh_size_mult[0] 0x%02x\n", ext_csd[157]);
+ seq_printf(s, "partitions_attribute 0x%02x\n", ext_csd[156]);
+ seq_printf(s, "partition_setting_completed 0x%02x\n",
+ ext_csd[155]);
+ seq_printf(s, "gp_size_mult_4[2] 0x%02x\n", ext_csd[154]);
+ seq_printf(s, "gp_size_mult_4[1] 0x%02x\n", ext_csd[153]);
+ seq_printf(s, "gp_size_mult_4[0] 0x%02x\n", ext_csd[152]);
+ seq_printf(s, "gp_size_mult_3[2] 0x%02x\n", ext_csd[151]);
+ seq_printf(s, "gp_size_mult_3[1] 0x%02x\n", ext_csd[150]);
+ seq_printf(s, "gp_size_mult_3[0] 0x%02x\n", ext_csd[149]);
+ seq_printf(s, "gp_size_mult_2[2] 0x%02x\n", ext_csd[148]);
+ seq_printf(s, "gp_size_mult_2[1] 0x%02x\n", ext_csd[147]);
+ seq_printf(s, "gp_size_mult_2[0] 0x%02x\n", ext_csd[146]);
+ seq_printf(s, "gp_size_mult_1[2] 0x%02x\n", ext_csd[145]);
+ seq_printf(s, "gp_size_mult_1[1] 0x%02x\n", ext_csd[144]);
+ seq_printf(s, "gp_size_mult_1[0] 0x%02x\n", ext_csd[143]);
+ seq_printf(s, "enh_size_mult[2] 0x%02x\n", ext_csd[142]);
+ seq_printf(s, "enh_size_mult[1] 0x%02x\n", ext_csd[141]);
+ seq_printf(s, "enh_size_mult[0] 0x%02x\n", ext_csd[140]);
+ seq_printf(s, "enh_start_addr[3] 0x%02x\n", ext_csd[139]);
+ seq_printf(s, "enh_start_addr[2] 0x%02x\n", ext_csd[138]);
+ seq_printf(s, "enh_start_addr[1] 0x%02x\n", ext_csd[137]);
+ seq_printf(s, "enh_start_addr[0] 0x%02x\n", ext_csd[136]);
+ /* A441: reserved [135] */
+ seq_printf(s, "sec_bad_blk_mgmnt 0x%02x\n", ext_csd[134]);
+ /* A441: reserved [133:0] */
+ }
+ /* B45 */
+ if (ext_csd_rev >= 6) {
+ int j;
+ seq_printf(s, "tcase_support 0x%02x\n", ext_csd[132]);
+ seq_printf(s, "program_cid_csd_ddr_support 0x%02x\n",
+ ext_csd[130]);
+
+ seq_printf(s, "vendor_specific_field:\n");
+ for (j = 127; j >= 64; j--)
+ seq_printf(s, "\t[%d] 0x%02x\n", j, ext_csd[j]);
+
+ seq_printf(s, "native_sector_size 0x%02x\n", ext_csd[63]);
+ seq_printf(s, "use_native_sector 0x%02x\n", ext_csd[62]);
+ seq_printf(s, "data_sector_size 0x%02x\n", ext_csd[61]);
+ seq_printf(s, "ini_timeout_emu 0x%02x\n", ext_csd[60]);
+ seq_printf(s, "class_6_ctrl 0x%02x\n", ext_csd[59]);
+ seq_printf(s, "dyncap_needed 0x%02x\n", ext_csd[58]);
+ seq_printf(s, "exception_events_ctrl[1] 0x%02x\n", ext_csd[57]);
+ seq_printf(s, "exception_events_ctrl[0] 0x%02x\n", ext_csd[56]);
+ seq_printf(s, "exception_events_status[1] 0x%02x\n",
+ ext_csd[55]);
+ seq_printf(s, "exception_events_status[0] 0x%02x\n",
+ ext_csd[54]);
+ seq_printf(s, "ext_partition_attribute[1] 0x%02x\n",
+ ext_csd[53]);
+ seq_printf(s, "ext_partition_attribute[0] 0x%02x\n",
+ ext_csd[52]);
+
+ seq_printf(s, "context_conf:\n");
+ for (j = 51; j >= 37; j--)
+ seq_printf(s, "\t[%d] 0x%02x\n", j, ext_csd[j]);
+
+ seq_printf(s, "packed_command_status 0x%02x\n", ext_csd[36]);
+ seq_printf(s, "packed_failure_index 0x%02x\n", ext_csd[35]);
+ seq_printf(s, "power_off_notification 0x%02x\n", ext_csd[34]);
+ seq_printf(s, "cache_ctrl 0x%02x\n", ext_csd[33]);
+ seq_printf(s, "flush_cache 0x%02x\n", ext_csd[32]);
+ /*Reserved [31:0] */
+ }
out_free:
- kfree(buf);
kfree(ext_csd);
return err;
}
-static ssize_t mmc_ext_csd_read(struct file *filp, char __user *ubuf,
- size_t cnt, loff_t *ppos)
+static int mmc_ext_csd_open(struct inode *inode, struct file *file)
{
- char *buf = filp->private_data;
-
- return simple_read_from_buffer(ubuf, cnt, ppos,
- buf, EXT_CSD_STR_LEN);
-}
-
-static int mmc_ext_csd_release(struct inode *inode, struct file *file)
-{
- kfree(file->private_data);
- return 0;
+ return single_open(file, mmc_ext_csd_read, inode->i_private);
}
static const struct file_operations mmc_dbg_ext_csd_fops = {
.open = mmc_ext_csd_open,
- .read = mmc_ext_csd_read,
- .release = mmc_ext_csd_release,
- .llseek = default_llseek,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
};
void mmc_add_card_debugfs(struct mmc_card *card)
--
1.7.4.4
^ permalink raw reply related
* Re: system hangs after deleting bad file
From: Helmut Hullen @ 2011-10-24 15:04 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <loom.20111024T054315-615@post.gmane.org>
Hallo, dima,
Du meintest am 24.10.11:
[system hangs]
> I had a similar problem.
> Some files (2-3) got corrupted in my /home subvolume for no apparent
> reason. Trying to access the files gives kernel oops. Sometimes it
> freezes the machine, sometimes I am back to my console without any
> problems.
> Then I switched to the latest 3.1rc and freezes were gone (though I
> still had the kernel oops).
I'll try in some hours ... I've just seen kernel 3.1 has been released.
Viele Gruesse!
Helmut
^ permalink raw reply
* [GIT PULL] (xen) stable/e820-3.2 for Linux 3.2-rc0
From: Konrad Rzeszutek Wilk @ 2011-10-24 15:03 UTC (permalink / raw)
To: torvalds, linux-kernel; +Cc: david.vrabel
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
Hey Linus,
Please git pull the following git branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/e820-3.2
wherein:
#stable/e820-3.2 is based of git commit d93dc5c (Linux 3.1-rc7):
and removes a lot of the old E820 parse code to a) make it easier to understand,
b) working properly when ballooning, and c) removes lots of code!
David Vrabel (5):
xen/balloon: account for pages released during memory setup
xen/balloon: simplify test for the end of usable RAM
xen: allow balloon driver to use more than one memory region
xen: allow extra memory to be in multiple regions
xen: release all pages within 1-1 p2m mappings
arch/x86/xen/setup.c | 284 +++++++++++++++++++++----------------------------
drivers/xen/balloon.c | 50 ++++++----
include/xen/page.h | 12 ++-
3 files changed, 165 insertions(+), 181 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND] block: warn if tag is greater than real_max_depth.
From: Tao Ma @ 2011-10-24 15:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Jens Axboe
In-Reply-To: <1315984992-5158-1-git-send-email-tm@tao.ma>
Hi Jens,
any option with this patch?
Thanks
Tao
On 09/14/2011 03:23 PM, Tao Ma wrote:
> From: Tao Ma <boyu.mt@taobao.com>
>
> In case tag depth is reduced, it is max_depth not real_max_depth.
> So we should allow a request with tag >= max_depth, but for a
> tag >= real_max_depth, there really should be some problem.
>
> Cc: Jens Axboe <jaxboe@fusionio.com>
> Signed-off-by: Tao Ma <boyu.mt@taobao.com>
> ---
> block/blk-tag.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-tag.c b/block/blk-tag.c
> index ece65fc..e74d6d1 100644
> --- a/block/blk-tag.c
> +++ b/block/blk-tag.c
> @@ -286,12 +286,14 @@ void blk_queue_end_tag(struct request_queue *q, struct request *rq)
>
> BUG_ON(tag == -1);
>
> - if (unlikely(tag >= bqt->real_max_depth))
> + if (unlikely(tag >= bqt->max_depth)) {
> /*
> * This can happen after tag depth has been reduced.
> - * FIXME: how about a warning or info message here?
> + * But tag shouldn't be larger than real_max_depth.
> */
> + WARN_ON(tag >= bqt->real_max_depth);
> return;
> + }
>
> list_del_init(&rq->queuelist);
> rq->cmd_flags &= ~REQ_QUEUED;
^ permalink raw reply
* [patch] qsort.3: add qsort_r() function
From: Mark R Bannister @ 2011-10-24 15:03 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]
Please find attached a patch for the qsort.3 man page from 3.35 to add the
qsort_r() function. I've also copied it inline below.
Best regards,
Mark.
--- qsort.3.old 2011-10-04 07:34:44.000000000 +0100
+++ qsort.3 2011-10-24 16:00:44.000000000 +0100
@@ -28,18 +28,22 @@
.\" Modified 1993-03-29, David Metcalfe
.\" Modified 1993-07-24, Rik Faith (faith-+5Oa3zvhR2o3uPMLIKxrzw@public.gmane.org)
.\" 2006-01-15, mtk, Added example program.
+.\" Modified 2011-10-24, Mark R. Bannister (cambridge-Rn4VEauK+AKRv+LV9MX5uv+2+P5yyue3@public.gmane.orgt)
+.\" to add qsort_r()
.\"
-.\" FIXME glibc 2.8 added qsort_r(), which needs to be documented.
-.\"
-.TH QSORT 3 2009-09-15 "" "Linux Programmer's Manual"
+.TH QSORT 3 2011-10-24 "" "Linux Programmer's Manual"
.SH NAME
-qsort \- sorts an array
+qsort, qsort_r \- sorts an array
.SH SYNOPSIS
.nf
.B #include <stdlib.h>
.sp
.BI "void qsort(void *" base ", size_t " nmemb ", size_t " size ,
.BI " int(*" compar ")(const void *, const void *));"
+.sp
+.BI "void qsort_r(void *" base ", size_t " nmemb ", size_t " size ,
+.BI " int(*" compar ")(const void *, const void *, void *),"
+.BI " void *" arg ");"
.fi
.SH DESCRIPTION
The
@@ -58,16 +62,34 @@
less than, equal to, or greater than the second.
If two members compare
as equal, their order in the sorted array is undefined.
+.PP
+The
+.BR qsort_r ()
+function is identical to
+.BR qsort ()
+except that the comparison function
+.I compar
+takes a third argument. A pointer is passed to the comparison function via
+.IR arg .
+In this way, the comparison function does not need to use global variables to
+pass through arbitrary arguments, and is therefore re-entrant and safe to
+use in threads.
.SH "RETURN VALUE"
The
.BR qsort ()
-function returns no value.
+and
+.BR qsort_r ()
+functions return no value.
.SH "CONFORMING TO"
-SVr4, 4.3BSD, C89, C99.
+The
+.BR qsort ()
+function conforms to SVr4, 4.3BSD, C89, C99.
.SH NOTES
Library routines suitable for use as the
.I compar
-argument include
+argument to
+.BR qsort ()
+include
.BR alphasort (3)
and
.BR versionsort (3).
[-- Attachment #2: qsort.3.patch --]
[-- Type: application/octet-stream, Size: 1923 bytes --]
--- qsort.3.old 2011-10-04 07:34:44.000000000 +0100
+++ qsort.3 2011-10-24 16:00:44.000000000 +0100
@@ -28,18 +28,22 @@
.\" Modified 1993-03-29, David Metcalfe
.\" Modified 1993-07-24, Rik Faith (faith@cs.unc.edu)
.\" 2006-01-15, mtk, Added example program.
+.\" Modified 2011-10-24, Mark R. Bannister (cambridge@users.sourceforge.net)
+.\" to add qsort_r()
.\"
-.\" FIXME glibc 2.8 added qsort_r(), which needs to be documented.
-.\"
-.TH QSORT 3 2009-09-15 "" "Linux Programmer's Manual"
+.TH QSORT 3 2011-10-24 "" "Linux Programmer's Manual"
.SH NAME
-qsort \- sorts an array
+qsort, qsort_r \- sorts an array
.SH SYNOPSIS
.nf
.B #include <stdlib.h>
.sp
.BI "void qsort(void *" base ", size_t " nmemb ", size_t " size ,
.BI " int(*" compar ")(const void *, const void *));"
+.sp
+.BI "void qsort_r(void *" base ", size_t " nmemb ", size_t " size ,
+.BI " int(*" compar ")(const void *, const void *, void *),"
+.BI " void *" arg ");"
.fi
.SH DESCRIPTION
The
@@ -58,16 +62,34 @@
less than, equal to, or greater than the second.
If two members compare
as equal, their order in the sorted array is undefined.
+.PP
+The
+.BR qsort_r ()
+function is identical to
+.BR qsort ()
+except that the comparison function
+.I compar
+takes a third argument. A pointer is passed to the comparison function via
+.IR arg .
+In this way, the comparison function does not need to use global variables to
+pass through arbitrary arguments, and is therefore re-entrant and safe to
+use in threads.
.SH "RETURN VALUE"
The
.BR qsort ()
-function returns no value.
+and
+.BR qsort_r ()
+functions return no value.
.SH "CONFORMING TO"
-SVr4, 4.3BSD, C89, C99.
+The
+.BR qsort ()
+function conforms to SVr4, 4.3BSD, C89, C99.
.SH NOTES
Library routines suitable for use as the
.I compar
-argument include
+argument to
+.BR qsort ()
+include
.BR alphasort (3)
and
.BR versionsort (3).
^ permalink raw reply
* Re: [v2 PATCH 0/4] Implement byte-range lock caching
From: Steve French @ 2011-10-24 15:02 UTC (permalink / raw)
To: Pavel Shilovsky; +Cc: Jeff Layton, linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKywueT8Ac-qPfLeXur8fn4ggumSk-LAYt=BbrJGDoGh64T5fg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Oct 24, 2011 at 7:05 AM, Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org> wrote:
> 2011/10/24 Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
>> On Sat, 22 Oct 2011 15:33:28 +0400
>> Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org> wrote:
>>
>>> This is the rest of byte-range lock cache patchset that includes several fixes in patches #1 and #3.
>>>
>>> The patchset is going to simplify brlocking code and add caching support for exclusive oplock cases. I splitted it into several independent parts - so, each can be applied separately once it's reviewed.
>>>
>>> Any comments and testing are welcome!
>>>
>>> Pavel Shilovsky (4):
>>> CIFS: Implement caching mechanism for mandatory brlocks
>>> CIFS: Implement caching mechanism for posix brlocks
>>> CIFS: Send as many mandatory unlock ranges at once as possible
>>> CIFS: Make cifs_push_locks send as many locks at once as possible
>>>
>>> fs/cifs/cifsglob.h | 2 +
>>> fs/cifs/cifsproto.h | 7 +-
>>> fs/cifs/cifssmb.c | 48 +++++-
>>> fs/cifs/file.c | 533 ++++++++++++++++++++++++++++++++++++++++++++++-----
>>> 4 files changed, 538 insertions(+), 52 deletions(-)
>>>
>>
>> This patchset seems to fix the regression in the earlier one. I've also
>> looked over it and don't see any obvious problems. Let's get this
>> merged early so it can get the full testing cycle for 3.2.
>>
>> Acked-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Thanks for the review!
>
> Steve, can you look at these 4 patches, please?
yes - I am testing them now.
--
Thanks,
Steve
^ permalink raw reply
* Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
From: Avi Kivity @ 2011-10-24 15:01 UTC (permalink / raw)
To: Dave Anderson
Cc: Jan Kiszka, Richard W.M. Jones, qemu-devel, Luiz Capitulino,
KAMEZAWA Hiroyuki
In-Reply-To: <b5b3fc10-35e7-4978-8d9a-0aae1690b9ba@zmail05.collab.prod.int.phx2.redhat.com>
On 10/24/2011 04:25 PM, Dave Anderson wrote:
> > The question is that: 'virsh dump' can not be used when host pci device
> > is used by guest. We are discussing how to fix the problem. We have determined
> > that introduce a new monitor command dump. Jan suggested that the core file's
> > format is gdb standard core format. Does crash support such format? If no,
> > is it possible to support such format?
>
> If you are talking about an ELF core dump of the user-space qemu-kvm process
> running on the host, then it's certainly not supported.
No, an ELF image of the guest's physical memory.
> As to whether it's possible, I suppose it could be done if a phyical-memory-read
> function could be created for it, similar to what I asked about for live analysis
> of a guest kernel run on/from the KVM host.
We could use the gdb protocol for this. Currently it reads/writes
virtual memory, but we could extend the gdbserver command to make these
commands apply to physical memory.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH V2 02/11] libxl_json, Check the parser status before to call parse_complete
From: Ian Campbell @ 2011-10-24 15:01 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Xen Devel, Stefano Stabellini
In-Reply-To: <CAJJyHjKSyDtStpAhNM4sbYkovDUFyNh9J+F2vCZjgYfswwOEhQ@mail.gmail.com>
On Mon, 2011-10-24 at 15:59 +0100, Anthony PERARD wrote:
> On Mon, Oct 24, 2011 at 10:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-10-20 at 18:59 +0100, Anthony PERARD wrote:
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >> ---
> >> tools/libxl/libxl_json.c | 4 +++-
> >> 1 files changed, 3 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> >> index 11f65fc..c743114 100644
> >> --- a/tools/libxl/libxl_json.c
> >> +++ b/tools/libxl/libxl_json.c
> >> @@ -744,7 +744,9 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
> >> yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
> >> }
> >> status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
> >> - status = yajl_parse_complete(yajl_ctx.hand);
> >> + if (status == yajl_status_ok) {
> >> + status = yajl_parse_complete(yajl_ctx.hand);
> >> + }
> >>
> >> if (status == yajl_status_ok) {
> >
> > You now have two of these checks back-to-back. I guess they could be
> > combined?
>
> :(, I do not see how I could combine them. Because, if I call
> parse_complete() after a parse() fail, I do not see a good error
> message(yajl forget a bit of his status). And parse_complete() could
> fail too, so I want to check is status too.
> So, I check the same status twice, only in case of error.
>
> (the second if(status) will print the error messages.)
I totally missed that status was updated inside the first if, sorry!
Ian.
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Jan Kiszka @ 2011-10-24 15:00 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <20111024144039.GB29886@redhat.com>
On 2011-10-24 16:40, Michael S. Tsirkin wrote:
> On Mon, Oct 24, 2011 at 03:43:53PM +0200, Jan Kiszka wrote:
>> On 2011-10-24 15:11, Jan Kiszka wrote:
>>> On 2011-10-24 14:43, Michael S. Tsirkin wrote:
>>>> On Mon, Oct 24, 2011 at 02:06:08PM +0200, Jan Kiszka wrote:
>>>>> On 2011-10-24 13:09, Avi Kivity wrote:
>>>>>> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
>>>>>>>>
>>>>>>>> With the new feature it may be worthwhile, but I'd like to see the whole
>>>>>>>> thing, with numbers attached.
>>>>>>>
>>>>>>> It's not a performance issue, it's a resource limitation issue: With the
>>>>>>> new API we can stop worrying about user space device models consuming
>>>>>>> limited IRQ routes of the KVM subsystem.
>>>>>>>
>>>>>>
>>>>>> Only if those devices are in the same process (or have access to the
>>>>>> vmfd). Interrupt routing together with irqfd allows you to disaggregate
>>>>>> the device model. Instead of providing a competing implementation with
>>>>>> new limitations, we need to remove the limitations of the old
>>>>>> implementation.
>>>>>
>>>>> That depends on where we do the cut. Currently we let the IRQ source
>>>>> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
>>>>> cannot build correct MSI-X on top of the current irqfd model as we lack
>>>>> the level information (for PBA emulation). *)
>>>>
>>>>
>>>> I don't agree here. IMO PBA emulation would need to
>>>> clear pending bits on interrupt status register read.
>>>> So clearing pending bits could be done by ioctl from qemu
>>>> while setting them would be done from irqfd.
>>>
>>> How should QEMU know if the reason for "pending" has been cleared at
>>> device level if the device is outside the scope of QEMU? This model only
>>> works for PV devices when you agree that spurious IRQs are OK.
>>>
>>>>
>>>>> So we either need to
>>>>> extend the existing model anyway -- or push per-vector masking back to
>>>>> the IRQ source. In the latter case, it would be a very good chance to
>>>>> give up on limited pseudo GSIs with static routes and do MSI messaging
>>>>> from external IRQ sources to KVM directly.
>>>>> But all those considerations affect different APIs than what I'm
>>>>> proposing here. We will always need a way to inject MSIs in the context
>>>>> of the VM as there will always be scenarios where devices are better run
>>>>> in that very same context, for performance or simplicity or whatever
>>>>> reasons. E.g., I could imagine that one would like to execute an
>>>>> emulated IRQ remapper rather in the hypervisor context than
>>>>> "over-microkernelized" in a separate process.
>>>>>
>>>>> Jan
>>>>>
>>>>> *) Realized this while trying to generalize the proposed MSI-X MMIO
>>>>> acceleration for assigned devices to arbitrary device models, vhost-net,
>>>>
>>>> I'm actually working on a qemu patch to get pba emulation working correctly.
>>>> I think it's doable with existing irqfd.
>>>
>>> irqfd has no notion of level. You can only communicate a rising edge and
>>> then need a side channel for the state of the edge reason.
>>>
>>>>
>>>>> and specifically vfio.
>>>>
>>>> Interesting. How would you clear the pseudo interrupt level?
>>>
>>> Ideally: not at all (for MSI). If we manage the mask at device level, we
>>> only need to send the message if there is actually something to deliver
>>> to the interrupt controller and masked input events would be lost on
>>> real HW as well.
>>
>> This wouldn't work out nicely as well. We rather need a combined model:
>>
>> Devices need to maintain the PBA actively, i.e. set & clear them
>> themselves and do not rely on the core here (with the core being either
>> QEMU user space or an in-kernel MSI-X MMIO accelerator). The core only
>> checks the PBA if it is about to deliver some message and refrains from
>> doing so if the bit became 0 in the meantime (specifically during the
>> masked period).
>>
>> For QEMU device models, that means no additional IOCTLs,
>> just memory sharing of the PBA which is required anyway.
>
> Sorry, I don't understand the above two paragraphs. Maybe I am
> confused by terminology here. We really only need to check PBA when it's
> read. Whether the message is delivered only depends on the mask bit.
This is what I have in mind:
- devices set PBA bit if MSI message cannot be sent due to mask (*)
- core checks&clears PBA bit on unmask, injects message if bit was set
- devices clear PBA bit if message reason is resolved before unmask (*)
The marked (*) lines differ from the current user space model where only
the core does PBA manipulation (including clearance via a special
function). Basically, the PBA becomes a communication channel also
between device and MSI core. And this model also works if core and
device run in different processes provided they set up the PBA as shared
memory.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Is there a way to build a cross reference with kernel file
From: Jimmy Pan @ 2011-10-24 15:00 UTC (permalink / raw)
To: kernelnewbies
It seems we can use ctags, while, I don't really know how to implement it.
I don't want to use the online cross reference every time...
Thanks.
^ permalink raw reply
* Re: [PATCH V2 02/11] libxl_json, Check the parser status before to call parse_complete
From: Anthony PERARD @ 2011-10-24 14:59 UTC (permalink / raw)
To: Ian Campbell; +Cc: Xen Devel, Stefano Stabellini
In-Reply-To: <1319449097.3385.165.camel@zakaz.uk.xensource.com>
On Mon, Oct 24, 2011 at 10:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-10-20 at 18:59 +0100, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> tools/libxl/libxl_json.c | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
>> index 11f65fc..c743114 100644
>> --- a/tools/libxl/libxl_json.c
>> +++ b/tools/libxl/libxl_json.c
>> @@ -744,7 +744,9 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
>> yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
>> }
>> status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
>> - status = yajl_parse_complete(yajl_ctx.hand);
>> + if (status == yajl_status_ok) {
>> + status = yajl_parse_complete(yajl_ctx.hand);
>> + }
>>
>> if (status == yajl_status_ok) {
>
> You now have two of these checks back-to-back. I guess they could be
> combined?
:(, I do not see how I could combine them. Because, if I call
parse_complete() after a parse() fail, I do not see a good error
message(yajl forget a bit of his status). And parse_complete() could
fail too, so I want to check is status too.
So, I check the same status twice, only in case of error.
(the second if(status) will print the error messages.)
--
Anthony PERARD
^ permalink raw reply
* [SOLVED] vm86plus service not available for your kernel
From: Bob Supansic @ 2011-10-24 14:59 UTC (permalink / raw)
To: linux-msdos
(This posting is to replace the thread "Getting SIMX86.exe")
I recently had to reinstall Linux on a file server.
Unfortunately I forgot that I needed a 32-bit kernel and
installed a 64-bit kernel instead. When trying to run
version 1.2.2.0 of DOSemu I got the message that "vm86 plus
service not available for your kernel".
Ivan Baldo suggested replacing the 1.2.2.0 version of DOSemu
with the 1.4 version.
This did the trick. My thanks to Ivan.
^ permalink raw reply
* Re: [PATCH] Reduce vm_stat cacheline contention in __vm_enough_memory
From: Dimitri Sivanich @ 2011-10-24 14:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Rientjes, Andi Kleen, linux-kernel, linux-mm, Andrew Morton,
Mel Gorman
In-Reply-To: <alpine.DEB.2.00.1110191029570.24001@router.home>
On Wed, Oct 19, 2011 at 10:31:54AM -0500, Christoph Lameter wrote:
> On Wed, 19 Oct 2011, Dimitri Sivanich wrote:
>
> > For 120 threads writing in parallel (each to it's own mountpoint), the
> > threshold needs to be on the order of 1000. At a threshold of 750, I
> > start to see a slowdown of 50-60 MB/sec.
> >
> > For 400 threads writing in parallel, the threshold needs to be on the order
> > of 2000 (although we're off by about 40 MB/sec at that point).
> >
> > The necessary deltas in these cases are quite a bit higher than the current
> > 125 maximum (see calculate*threshold in mm/vmstat.c).
> >
> > I like the idea of having certain areas triggering vm_stat sync, as long
> > as we know what those key areas are and how often they might be called.
>
> You could potentially reduce the maximum necessary by applying my earlier
> patch (but please reduce the counters touched to the current cacheline).
> That should reduce the number of updates in the global cacheline and allow
> you to reduce the very high deltas that you have to deal with now.
I tried updating whole, single vm_stat cachelines as you suggest, but that
made little if any difference in tmpfs writeback performance. The same higher
threshold values were still necessary to significantly reduce the contention
seen in __vm_enough_memory.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Xen-users] Re: Xen document day (Oct 12 or 26)
From: Joseph Glanville @ 2011-10-24 14:59 UTC (permalink / raw)
To: Lars Kurth
Cc: Andrew Bobulsky, xen-users@lists.xensource.com,
xen-devel@lists.xensource.com, Ian Campbell,
Konrad Rzeszutek Wilk
In-Reply-To: <4EA54D72.7040205@xen.org>
[-- Attachment #1.1: Type: text/plain, Size: 4478 bytes --]
Agreed on all counts.
I think you have a very good point in the "trails" concept... the idea of
having an information graph resounds with the goal to make advanced
documentation accessible but not overwhelm newcomers.
The DocTools macros look good.
Joseph.
On 24 October 2011 22:35, Lars Kurth <lars.kurth@xen.org> wrote:
> On 22/10/2011 00:33, Joseph Glanville wrote:
>
> As I noted, this is just my opinion, its not my place to decide how
> people want to use it but if we could have to idea of what should and
> shouldn't be in there it makes it easy to then structure the information.
>
> I think we need to setup a guided rewrite/refactor of the core
>>> documentation so it resembles something close to this:
>>>
>>> Overview (brief introduction, architecture, why xen is different and
>>> maybe abit of xen philosophy)
>>> Getting started guide ( Installation of Xen on Debian - probably the
>>> simplest and easiest way to get started with Xen at the moment, start a
>>> Debian PV guest, start at Windows HVM guest)
>>> Installation guide ( More indepth covering all the core distros and some
>>> more advanced installations including compilation from source and using the
>>> Linux 3.1 kernel, networking options etc)
>>> Administration guide ( This bit requires atlot of discussion, do we
>>> recommend xm still? should we only support xl? If that is the case how to we
>>> recommend stuff like managed domains etc..)
>>> Advanced topics.. stuff like Networking, PCI passthrough etc deserve
>>> their own pages
>>>
>> Are you suggesting we restructure the wiki front-page around this?
>
>
> Yes, maybe not -exactly- this format but something resembling it would be
> of value I think. Guiding people towards the beginners documentation and
> making it quite clear there is a reading progression will show much stronger
> cohesion.
>
>
> I think we have two choices:
> a) We re-write large sections of the wiki with the purpose of making it
> more accessible
> b) We use create methods to highlight existing stuff and focus on filling
> gaps, etc.
>
> I think that b) is more valuable. Here are a few ideas:
>
> Trails: I have come across the idea of wiki trails before. These are
> pages/indexes which lead the reader through a series of articles. The key is
> that these are easily identified and highlighted from the main page. E.g. we
> could use Trails (listing all trails and a page template),
> Trails/XenOverview, Trails/XenGettingStarted, etc. By doing this, we group
> the existing documents, rather than re-writing a lot of stuff and just
> refactoring it. This would make an easier start, and if somebody wishes they
> can always clean up and refactor the documentation which makes up a trail.
>
> I had a look around for MoinMoin plug-ins for something which may help with
> trails: not much, but there are a couple of plugins that may help
>
> Being able to create TOCs across sevaleraL wiki pages (
> http://moinmo.in/SteveTindle/DocTools from
> http://moinmo.in/MacroMarket#Release_1.5 using /EnhancedTableOfContents<http://moinmo.in/MacroMarket/EnhancedTableOfContents>
> /SetSection <http://moinmo.in/MacroMarket/SetSection> /TocOf<http://moinmo.in/MacroMarket/TocOf>)
>
>
> The current wiki is poluted with alot of architecture and design info
>> that isn't of interest to a general user but is still key to understanding
>> Xen from a developers point of view.
>>
> Part of the issue is that it is hard for me to identify what is what. If I
>> had a good approximation of what is what, I (or others) could just go
>> through the motions and re-encode stuff accordingly.
>
>
> I have exactly the same problem, I just need to undertand what needs to be
> done and where.
>
> I hope I will get some of this out of Wed.
>
>
> I think what you seem to be saying is that there would be extremely high
>> value in having a "Getting started" guide and some other entry level
>> documentation (even if just an index page) accessible from the wiki front
>> page.
>>
>
> Precisely, documenting the more advanced features of Xen seems to be
> something that we can approach over time. Beginner documentation is
> immeadiately lacking and seems to be an easier target that would benefit
> more people.
>
> Let's see whether we can get enough structure in place on Wed and make a
> good start
>
> Lars
>
>
--
*
Founder | Director | VP Research
Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52
| Mobile: 0428 754 846
[-- Attachment #1.2: Type: text/html, Size: 7571 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] Reduce vm_stat cacheline contention in __vm_enough_memory
From: Dimitri Sivanich @ 2011-10-24 14:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Rientjes, Andi Kleen, linux-kernel, linux-mm, Andrew Morton,
Mel Gorman
In-Reply-To: <alpine.DEB.2.00.1110191029570.24001@router.home>
On Wed, Oct 19, 2011 at 10:31:54AM -0500, Christoph Lameter wrote:
> On Wed, 19 Oct 2011, Dimitri Sivanich wrote:
>
> > For 120 threads writing in parallel (each to it's own mountpoint), the
> > threshold needs to be on the order of 1000. At a threshold of 750, I
> > start to see a slowdown of 50-60 MB/sec.
> >
> > For 400 threads writing in parallel, the threshold needs to be on the order
> > of 2000 (although we're off by about 40 MB/sec at that point).
> >
> > The necessary deltas in these cases are quite a bit higher than the current
> > 125 maximum (see calculate*threshold in mm/vmstat.c).
> >
> > I like the idea of having certain areas triggering vm_stat sync, as long
> > as we know what those key areas are and how often they might be called.
>
> You could potentially reduce the maximum necessary by applying my earlier
> patch (but please reduce the counters touched to the current cacheline).
> That should reduce the number of updates in the global cacheline and allow
> you to reduce the very high deltas that you have to deal with now.
I tried updating whole, single vm_stat cachelines as you suggest, but that
made little if any difference in tmpfs writeback performance. The same higher
threshold values were still necessary to significantly reduce the contention
seen in __vm_enough_memory.
^ permalink raw reply
* [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
From: Linus Walleij @ 2011-10-24 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024125030.GB17693@n2100.arm.linux.org.uk>
2011/10/24 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Oct 24, 2011 at 02:03:42PM +0200, Grant Likely wrote:
>> On Fri, Oct 21, 2011 at 04:08:44PM +0200, Ulf Hansson wrote:
>> > Since we are always runtime resumed when leaving probe
>> > the clock must be enabled. To accomplish that we are able
>> > to be runtime suspended after probe in the case when no
>> > request is going to be recieved, a runtime_idle function
>> > has been implemented.
>> >
>> > Change-Id: I6cb86f2cad30ecaab16f512daf4674b039b18213
>> > Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
>> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34447
>>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>> Since it depends on Russell's tree, I'm okay with it going in that way.
>
> I've received this patch in the patch system, but I'm not planning to
> apply it yet because it depends on two branches in my tree (amba and clk).
We can fixup that in the aftermath of the merge window, no
hurries.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
From: Linus Walleij @ 2011-10-24 14:58 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Grant Likely, spi-devel-general, Lee Jones, Ulf Hansson,
linux-arm-kernel
In-Reply-To: <20111024125030.GB17693@n2100.arm.linux.org.uk>
2011/10/24 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Oct 24, 2011 at 02:03:42PM +0200, Grant Likely wrote:
>> On Fri, Oct 21, 2011 at 04:08:44PM +0200, Ulf Hansson wrote:
>> > Since we are always runtime resumed when leaving probe
>> > the clock must be enabled. To accomplish that we are able
>> > to be runtime suspended after probe in the case when no
>> > request is going to be recieved, a runtime_idle function
>> > has been implemented.
>> >
>> > Change-Id: I6cb86f2cad30ecaab16f512daf4674b039b18213
>> > Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
>> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34447
>>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>> Since it depends on Russell's tree, I'm okay with it going in that way.
>
> I've received this patch in the patch system, but I'm not planning to
> apply it yet because it depends on two branches in my tree (amba and clk).
We can fixup that in the aftermath of the merge window, no
hurries.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
From: Randy Dunlap @ 2011-10-24 14:57 UTC (permalink / raw)
To: Ben Hutchings
Cc: LKML, Dave Jones, Greg KH, Debian kernel maintainers,
Rusty Russell
In-Reply-To: <1319461948.31243.31.camel@deadeye>
On 10/24/11 06:12, Ben Hutchings wrote:
> Use of the GPL or a compatible licence doesn't necessarily make the code
> any good. We already consider staging modules to be suspect, and this
> should also be true for out-of-tree modules which may receive very
> little review.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> Debian has been carrying this for the last few kernel versions. The
> recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest
> that this might be more generally useful.
>
> Ben.
>
> include/linux/kernel.h | 1 +
> kernel/module.c | 5 +++++
> kernel/panic.c | 2 ++
> scripts/mod/modpost.c | 7 +++++++
> 4 files changed, 15 insertions(+), 0 deletions(-)
Hi,
Please add 'O' to Documentation/oops-tracing.txt.
Thanks.
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 46ac9a5..2c05967 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -369,6 +369,7 @@ extern enum system_states {
> #define TAINT_WARN 9
> #define TAINT_CRAP 10
> #define TAINT_FIRMWARE_WORKAROUND 11
> +#define TAINT_OOT_MODULE 12
>
> extern const char hex_asc[];
> #define hex_asc_lo(x) hex_asc[((x) & 0x0f)]
> diff --git a/kernel/module.c b/kernel/module.c
> index 04379f92..c0872f1 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2487,6 +2487,9 @@ static int check_modinfo(struct module *mod, struct load_info *info)
> return -ENOEXEC;
> }
>
> + if (!get_modinfo(info, "intree"))
> + add_taint_module(mod, TAINT_OOT_MODULE);
> +
> if (get_modinfo(info, "staging")) {
> add_taint_module(mod, TAINT_CRAP);
> printk(KERN_WARNING "%s: module is from the staging directory,"
> @@ -3257,6 +3260,8 @@ static char *module_flags(struct module *mod, char *buf)
> buf[bx++] = '(';
> if (mod->taints & (1 << TAINT_PROPRIETARY_MODULE))
> buf[bx++] = 'P';
> + else if (mod->taints & (1 << TAINT_OOT_MODULE))
> + buf[bx++] = 'O';
> if (mod->taints & (1 << TAINT_FORCED_MODULE))
> buf[bx++] = 'F';
> if (mod->taints & (1 << TAINT_CRAP))
> diff --git a/kernel/panic.c b/kernel/panic.c
> index d7bb697..b2659360 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -177,6 +177,7 @@ static const struct tnt tnts[] = {
> { TAINT_WARN, 'W', ' ' },
> { TAINT_CRAP, 'C', ' ' },
> { TAINT_FIRMWARE_WORKAROUND, 'I', ' ' },
> + { TAINT_OOT_MODULE, 'O', ' ' },
> };
>
> /**
> @@ -194,6 +195,7 @@ static const struct tnt tnts[] = {
> * 'W' - Taint on warning.
> * 'C' - modules from drivers/staging are loaded.
> * 'I' - Working around severe firmware bug.
> + * 'O' - Out-of-tree module has been loaded.
> *
> * The string is overwritten by the next call to print_tainted().
> */
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index a509ff8..2bd594e 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1849,6 +1849,12 @@ static void add_header(struct buffer *b, struct module *mod)
> buf_printf(b, "};\n");
> }
>
> +static void add_intree_flag(struct buffer *b, int is_intree)
> +{
> + if (is_intree)
> + buf_printf(b, "\nMODULE_INFO(intree, \"Y\");\n");
> +}
> +
> static void add_staging_flag(struct buffer *b, const char *name)
> {
> static const char *staging_dir = "drivers/staging";
> @@ -2169,6 +2175,7 @@ int main(int argc, char **argv)
> buf.pos = 0;
>
> add_header(&buf, mod);
> + add_intree_flag(&buf, !external_module);
> add_staging_flag(&buf, mod->name);
> err |= add_versions(&buf, mod);
> add_depends(&buf, mod, modules);
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024145139.GH1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > > index 8fe132d..29dcf90 100644
> > > --- a/drivers/regulator/core.c
> > > +++ b/drivers/regulator/core.c
> > > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > >
> > > /* find device_node and attach it */
> > > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > > + regulator_desc->name);
> >
> > of_find_node_by_name() doesn't work that way. The first argument is a
> > starting point, but it doesn't restrict the search to children of a
> > node.
> >
> > for_each_child_of_node() is what you want to use when iterating over
> > the children which unfortunately changes the structure of this
> > function.
> >
> The dev->parent->of_node is meant to point to node 'pmic: mc13892 at 0'.
> And the intention here is not to iterate over the children, but to
> start a search from a reasonable point rather than the top root node.
It is always better to attach the of_node at struct device
registration time instead of searching the tree in common code. The
of_node should already be assigned by the time regulator_register() is
called. The caller should already have access to all that information
before the call anyway, especially since it is not strictly manditory
for all regulators to use the common binding. It is entirely
conceivable that the proposed binding won't work for some regulators.
g.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 14:56 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024145139.GH1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > > index 8fe132d..29dcf90 100644
> > > --- a/drivers/regulator/core.c
> > > +++ b/drivers/regulator/core.c
> > > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > >
> > > /* find device_node and attach it */
> > > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > > + regulator_desc->name);
> >
> > of_find_node_by_name() doesn't work that way. The first argument is a
> > starting point, but it doesn't restrict the search to children of a
> > node.
> >
> > for_each_child_of_node() is what you want to use when iterating over
> > the children which unfortunately changes the structure of this
> > function.
> >
> The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
> And the intention here is not to iterate over the children, but to
> start a search from a reasonable point rather than the top root node.
It is always better to attach the of_node at struct device
registration time instead of searching the tree in common code. The
of_node should already be assigned by the time regulator_register() is
called. The caller should already have access to all that information
before the call anyway, especially since it is not strictly manditory
for all regulators to use the common binding. It is entirely
conceivable that the proposed binding won't work for some regulators.
g.
^ permalink raw reply
* [PATCH 0/2] mmc: mmci: Improvements for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel; +Cc: Russell King, Ulf Hansson, Lee Jones
For the ux500v2 variant of the PL18x block, non power of two block
sizes are now supported.
In addition constraints on buffer alignments is needed since access to the
PL18x FIFO must be done on a 4-byte aligned manner. Moreover to be able to
use DMA for buffers with not 32 bytes aligned sg element lengths, DMAREQCTL
must enabled.
Per Forlin (1):
mmc: mmci: add constraints on alignment for SDIO
Stefan Nilsson XK (1):
mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
drivers/mmc/host/mmci.c | 56 +++++++++++++++++++++++++++++++++++++++++------
drivers/mmc/host/mmci.h | 7 ++++++
2 files changed, 56 insertions(+), 7 deletions(-)
--
1.7.5.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.