Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1212581 > unrolled thread

Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram Laura Abbott <labbott@redhat.com> - 2015-08-25 01:40 +0200
    RE: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang <qiang.zhao@freescale.com> - 2015-08-25 05:10 +0200
      Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram Laura Abbott <labbott@redhat.com> - 2015-08-25 06:20 +0200
        RE: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang <qiang.zhao@freescale.com> - 2015-08-25 09:40 +0200
          RE: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang <qiang.zhao@freescale.com> - 2015-08-26 03:50 +0200

#1212581 — Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram

On 08/24/2015 02:31 AM, Zhao Qiang wrote:

> diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
> new file mode 100644
> index 0000000..7f1762c
> --- /dev/null
> +++ b/drivers/soc/fsl/qe/qe_common.c
> @@ -0,0 +1,193 @@
> +/*
> + * common qe code
> + *
> + * author: scott wood <scottwood@freescale.com>
> + *
> + * copyright 2007-2008,2010 freescale Semiconductor, Inc.
> + *
> + * some parts derived from commproc.c/qe2_common.c, which is:
> + * copyright (c) 1997 dan error_act (dmalek@jlc.net)
> + * copyright (c) 1999-2001 dan Malek <dan@embeddedalley.com>
> + * copyright (c) 2000 montavista Software, Inc (source@mvista.com)
> + * 2006 (c) montavista software, Inc.
> + * vitaly bordug <vbordug@ru.mvista.com>
> + *
> + * this program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the free software Foundation.
> + */
> +
> +#include <linux/genalloc.h>
> +#include <linux/list.h>
> +#include <linux/init.h>
> +#include <linux/of_device.h>
> +#include <linux/spinlock.h>
> +#include <linux/export.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +
> +#include <linux/io.h>
> +#include <soc/fsl/qe/qe.h>
> +
> +static struct gen_pool *muram_pool;
> +static struct genpool_data_align muram_pool_data;
> +static spinlock_t qe_muram_lock;
> +static u8 __iomem *muram_vbase;
> +static phys_addr_t muram_pbase;
> +
> +struct muram_block {
> +	struct list_head head;
> +	unsigned long start;
> +	int size;
> +};
> +
> +static LIST_HEAD(muram_block_list);
> +
> +/* max address size we deal with */
> +#define OF_MAX_ADDR_CELLS	4
> +
> +int qe_muram_init(void)
> +{
> +	struct device_node *np;
> +	struct resource r;
> +	u32 zero[OF_MAX_ADDR_CELLS] = {};
> +	resource_size_t max = 0;
> +	int i = 0;
> +	int ret = 0;
> +
> +	if (muram_pbase)
> +		return 0;
> +
> +	muram_pool = gen_pool_create(1, -1);
> +	gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> +			  &muram_pool_data);
> +
> +	np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
> +	if (!np) {
> +		/* try legacy bindings */
> +		np = of_find_node_by_name(NULL, "data-only");
> +		if (!np) {
> +			pr_err("Cannot find CPM muram data node");
> +			ret = -ENODEV;
> +			goto out;
> +		}
> +	}
> +
> +	muram_pbase = of_translate_address(np, zero);
> +	if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> +		pr_err("Cannot translate zero through CPM muram node");
> +		ret = -ENODEV;
> +		goto out;
> +	}
> +
> +	while (of_address_to_resource(np, i++, &r) == 0) {
> +		if (r.end > max)
> +			max = r.end;
> +		ret = gen_pool_add(muram_pool, r.start - muram_pbase,
> +				   resource_size(&r), -1);
> +		if (ret) {
> +				pr_err("QE MURAM: could not add muram ");
> +				pr_err("remainder to pool!\n");

Don't split the error string over two lines

> +				return ret;

returning here misses the error path

> +			}
> +
> +	}
> +
> +	muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
> +	if (!muram_vbase) {
> +		pr_err("Cannot map CPM muram");
> +		ret = -ENOMEM;
> +	}
> +

gen_pool_destroy on the error path

> +out:
> +	of_node_put(np);
> +	return ret;
> +}
> +
> +/**
> + * qe_muram_alloc - allocate the requested size worth of multi-user ram
> + * @size: number of bytes to allocate
> + * @align: requested alignment, in bytes
> + *
> + * This function returns an offset into the muram area.
> + * Use qe_dpram_addr() to get the virtual address of the area.
> + * Use qe_muram_free() to free the allocation.
> + */
> +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
> +{
> +	unsigned long start;
> +	unsigned long flags;
> +	struct muram_block *entry;
> +
> +	spin_lock_irqsave(&qe_muram_lock, flags);
> +	muram_pool_data.align = align;
> +	start = gen_pool_alloc(muram_pool, size);

The advantage of creating gen_pool_alloc_data was so that you could
pass in the align automatically without having to modify the structure.
Is there a reason you aren't using that?

> +	memset(qe_muram_addr(start), 0, size);

There doesn't seem to be a check for allocation failure from the
gen_alloc.

> +	entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> +	if (!entry)
> +		goto out;
> +	entry->start = start;
> +	entry->size = size;
> +	list_add(&entry->head, &muram_block_list);

What's the point of keeping the block list anyway? It's used only in
this file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a gen_alloc
API to do so?

> +	spin_unlock_irqrestore(&qe_muram_lock, flags);
> +
> +	return start;
> +out:
> +	gen_pool_free(muram_pool, start, size);
> +	return (unsigned long) -ENOMEM;
> +}
> +EXPORT_SYMBOL(qe_muram_alloc);
> +
> +/**
> + * qe_muram_free - free a chunk of multi-user ram
> + * @offset: The beginning of the chunk as returned by qe_muram_alloc().
> + */
> +int qe_muram_free(unsigned long offset)
> +{
> +	unsigned long flags;
> +	int size;
> +	struct muram_block *tmp;
> +
> +	size = 0;
> +	spin_lock_irqsave(&qe_muram_lock, flags);
> +	list_for_each_entry(tmp, &muram_block_list, head) {
> +		if (tmp->start == offset) {
> +			size = tmp->size;
> +			list_del(&tmp->head);
> +			kfree(tmp);
> +			break;
> +		}
> +	}
> +	gen_pool_free(muram_pool, offset, size);
> +	spin_unlock_irqrestore(&qe_muram_lock, flags);
> +
> +	return size;
> +}
> +EXPORT_SYMBOL(qe_muram_free);
> +
> +/**
> + * qe_muram_addr - turn a muram offset into a virtual address
> + * @offset: muram offset to convert
> + */
> +void __iomem *qe_muram_addr(unsigned long offset)
> +{
> +	return muram_vbase + offset;
> +}
> +EXPORT_SYMBOL(qe_muram_addr);
> +
> +unsigned long qe_muram_offset(void __iomem *addr)
> +{
> +	return addr - (void __iomem *)muram_vbase;
> +}
> +EXPORT_SYMBOL(qe_muram_offset);
> +
> +/**
> + * qe_muram_dma - turn a muram virtual address into a DMA address
> + * @offset: virtual address from qe_muram_addr() to convert
> + */
> +dma_addr_t qe_muram_dma(void __iomem *addr)
> +{
> +	return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
> +}
> +EXPORT_SYMBOL(qe_muram_dma);

Thanks,
Laura

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1212676

> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com]
> Sent: Tuesday, August 25, 2015 7:32 AM
> To: Zhao Qiang-B45475; Wood Scott-B07421
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On 08/24/2015 02:31 AM, Zhao Qiang wrote:
> 
> 
> > +out:
> > +	of_node_put(np);
> > +	return ret;
> > +}
> > +
> > +/**
> > + * qe_muram_alloc - allocate the requested size worth of multi-user
> > +ram
> > + * @size: number of bytes to allocate
> > + * @align: requested alignment, in bytes
> > + *
> > + * This function returns an offset into the muram area.
> > + * Use qe_dpram_addr() to get the virtual address of the area.
> > + * Use qe_muram_free() to free the allocation.
> > + */
> > +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
> > +{
> > +	unsigned long start;
> > +	unsigned long flags;
> > +	struct muram_block *entry;
> > +
> > +	spin_lock_irqsave(&qe_muram_lock, flags);
> > +	muram_pool_data.align = align;
> > +	start = gen_pool_alloc(muram_pool, size);
> 
> The advantage of creating gen_pool_alloc_data was so that you could pass
> in the align automatically without having to modify the structure.
> Is there a reason you aren't using that?
> 
> > +	memset(qe_muram_addr(start), 0, size);
> 
> There doesn't seem to be a check for allocation failure from the
> gen_alloc.

gen_pool_alloc will return 0 if there is error, but if the address returned is 
just 0x0, it can't distinguish it is address or error.

> 
> > +	entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> > +	if (!entry)
> > +		goto out;
> > +	entry->start = start;
> > +	entry->size = size;
> > +	list_add(&entry->head, &muram_block_list);
> 
> What's the point of keeping the block list anyway? It's used only in this
> file and it only seems to duplicate what gen_alloc is doing internally.
> Is there some lookup functionality you still need? Could you use a
> gen_alloc API to do so?

I need to record the size when allocation, so when free the block, I can get 
The right size for the block, and pass the right size to 
gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).

> 
> 
> Thanks,
> Laura
Thanks 
Zhao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212687

On 08/24/2015 08:03 PM, Zhao Qiang wrote:
>
>> -----Original Message-----
>> From: Laura Abbott [mailto:labbott@redhat.com]
>> Sent: Tuesday, August 25, 2015 7:32 AM
>> To: Zhao Qiang-B45475; Wood Scott-B07421
>> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
>> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
>> Yang-Leo-R58472; paulus@samba.org
>> Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
>> muram
>>
>> On 08/24/2015 02:31 AM, Zhao Qiang wrote:
>>
>>
>>> +out:
>>> +	of_node_put(np);
>>> +	return ret;
>>> +}
>>> +
>>> +/**
>>> + * qe_muram_alloc - allocate the requested size worth of multi-user
>>> +ram
>>> + * @size: number of bytes to allocate
>>> + * @align: requested alignment, in bytes
>>> + *
>>> + * This function returns an offset into the muram area.
>>> + * Use qe_dpram_addr() to get the virtual address of the area.
>>> + * Use qe_muram_free() to free the allocation.
>>> + */
>>> +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
>>> +{
>>> +	unsigned long start;
>>> +	unsigned long flags;
>>> +	struct muram_block *entry;
>>> +
>>> +	spin_lock_irqsave(&qe_muram_lock, flags);
>>> +	muram_pool_data.align = align;
>>> +	start = gen_pool_alloc(muram_pool, size);
>>
>> The advantage of creating gen_pool_alloc_data was so that you could pass
>> in the align automatically without having to modify the structure.
>> Is there a reason you aren't using that?
>>
>>> +	memset(qe_muram_addr(start), 0, size);
>>
>> There doesn't seem to be a check for allocation failure from the
>> gen_alloc.
>
> gen_pool_alloc will return 0 if there is error, but if the address returned is
> just 0x0, it can't distinguish it is address or error.
>

Yes, that's a bad limitation of gen_pool. Maybe one day that will get fixed.
In a previous out of tree driver, I worked around this by offsetting the
gen_pool_add by a constant so any return value was non-zero and out of memory
was zero and then subtracting the constant off of the return value. Not sure
if that's better or worse than just fixing gen_alloc.
  
>>
>>> +	entry = kmalloc(sizeof(*entry), GFP_KERNEL);
>>> +	if (!entry)
>>> +		goto out;
>>> +	entry->start = start;
>>> +	entry->size = size;
>>> +	list_add(&entry->head, &muram_block_list);
>>
>> What's the point of keeping the block list anyway? It's used only in this
>> file and it only seems to duplicate what gen_alloc is doing internally.
>> Is there some lookup functionality you still need? Could you use a
>> gen_alloc API to do so?
>
> I need to record the size when allocation, so when free the block, I can get
> The right size for the block, and pass the right size to
> gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).
>

Yes, I see now what you are doing.
  
>>
>>
>> Thanks,
>> Laura
> Thanks
> Zhao
>

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212760

On 08/25/2015 12:15 PM, Laura Abbott wrote
> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com]
> Sent: Tuesday, August 25, 2015 12:15 PM
> To: Zhao Qiang-B45475; Wood Scott-B07421
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On 08/24/2015 08:03 PM, Zhao Qiang wrote:
> >
> >> -----Original Message-----
> >> From: Laura Abbott [mailto:labbott@redhat.com]
> >> Sent: Tuesday, August 25, 2015 7:32 AM
> >> To: Zhao Qiang-B45475; Wood Scott-B07421
> >> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> >> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> >> Li Yang-Leo-R58472; paulus@samba.org
> >> Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to
> >> manage muram
> >>
> >> On 08/24/2015 02:31 AM, Zhao Qiang wrote:
> >>
> >>
> >>> +out:
> >>> +	of_node_put(np);
> >>> +	return ret;
> >>> +}
> >>> +
> >>> +/**
> >>> + * qe_muram_alloc - allocate the requested size worth of multi-user
> >>> +ram
> >>> + * @size: number of bytes to allocate
> >>> + * @align: requested alignment, in bytes
> >>> + *
> >>> + * This function returns an offset into the muram area.
> >>> + * Use qe_dpram_addr() to get the virtual address of the area.
> >>> + * Use qe_muram_free() to free the allocation.
> >>> + */
> >>> +unsigned long qe_muram_alloc(unsigned long size, unsigned long
> >>> +align) {
> >>> +	unsigned long start;
> >>> +	unsigned long flags;
> >>> +	struct muram_block *entry;
> >>> +
> >>> +	spin_lock_irqsave(&qe_muram_lock, flags);
> >>> +	muram_pool_data.align = align;
> >>> +	start = gen_pool_alloc(muram_pool, size);
> >>
> >> The advantage of creating gen_pool_alloc_data was so that you could
> >> pass in the align automatically without having to modify the structure.
> >> Is there a reason you aren't using that?
> >>
> >>> +	memset(qe_muram_addr(start), 0, size);
> >>
> >> There doesn't seem to be a check for allocation failure from the
> >> gen_alloc.
> >
> > gen_pool_alloc will return 0 if there is error, but if the address
> > returned is just 0x0, it can't distinguish it is address or error.
> >
> 
> Yes, that's a bad limitation of gen_pool. Maybe one day that will get
> fixed.
> In a previous out of tree driver, I worked around this by offsetting the
> gen_pool_add by a constant so any return value was non-zero and out of
> memory was zero and then subtracting the constant off of the return value.
> Not sure if that's better or worse than just fixing gen_alloc.
> 

The workaround works for non alignment allocation, but for alignment allocation,
It need to align bytes to addr 0, offsetting the gen_pool_add maybe make wrong alignment
.

> 
> Thanks,
> Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213491

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNiwgMjAxNSAxMjoyMyBBTQ0KPiBUbzogWmhhbyBR
aWFuZy1CNDU0NzUNCj4gQ2M6IExhdXJhIEFiYm90dDsgbGludXgta2VybmVsQHZnZXIua2VybmVs
Lm9yZzsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxhYnMub3JnOyBsYXVyYWFAY29kZWF1cm9y
YS5vcmc7IFhpZSBYaWFvYm8tUjYzMDYxOw0KPiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExp
IFlhbmctTGVvLVI1ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENI
IHY2IDMvM10gcWVfY29tbW9uOiBhZGQgcWVfbXVyYW1fIGZ1bmN0aW9ucyB0byBtYW5hZ2UNCj4g
bXVyYW0NCj4gDQo+IE9uIFR1ZSwgMjAxNS0wOC0yNSBhdCAwMjoxOSAtMDUwMCwgWmhhbyBRaWFu
Zy1CNDU0NzUgd3JvdGU6DQo+ID4gT24gMDgvMjUvMjAxNSAxMjoxNSBQTSwgTGF1cmEgQWJib3R0
IHdyb3RlDQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogTGF1
cmEgQWJib3R0IFttYWlsdG86bGFiYm90dEByZWRoYXQuY29tXQ0KPiA+ID4gU2VudDogVHVlc2Rh
eSwgQXVndXN0IDI1LCAyMDE1IDEyOjE1IFBNDQo+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzU7
IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9y
ZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+ID4gPiBsYXVyYWFAY29kZWF1cm9y
YS5vcmc7IFhpZSBYaWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7DQo+ID4g
PiBMaSBZYW5nLUxlby1SNTg0NzI7IHBhdWx1c0BzYW1iYS5vcmcNCj4gPiA+IFN1YmplY3Q6IFJl
OiBbUEFUQ0ggdjYgMy8zXSBxZV9jb21tb246IGFkZCBxZV9tdXJhbV8gZnVuY3Rpb25zIHRvDQo+
ID4gPiBtYW5hZ2UgbXVyYW0NCj4gPiA+DQo+ID4gPiBPbiAwOC8yNC8yMDE1IDA4OjAzIFBNLCBa
aGFvIFFpYW5nIHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogTGF1cmEgQWJib3R0IFttYWlsdG86bGFiYm90dEByZWRo
YXQuY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyNSwgMjAxNSA3OjMyIEFN
DQo+ID4gPiA+ID4gVG86IFpoYW8gUWlhbmctQjQ1NDc1OyBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+
ID4gPiA+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZzsNCj4gPiA+ID4gPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7IFhpZSBYaWFv
Ym8tUjYzMDYxOw0KPiA+ID4gPiA+IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkgWWFuZy1M
ZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtQQVRD
SCB2NiAzLzNdIHFlX2NvbW1vbjogYWRkIHFlX211cmFtXyBmdW5jdGlvbnMNCj4gPiA+ID4gPiB0
byBtYW5hZ2UgbXVyYW0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZXJlIGRvZXNuJ3Qgc2VlbSB0
byBiZSBhIGNoZWNrIGZvciBhbGxvY2F0aW9uIGZhaWx1cmUgZnJvbSB0aGUNCj4gPiA+ID4gPiBn
ZW5fYWxsb2MuDQo+ID4gPiA+DQo+ID4gPiA+IGdlbl9wb29sX2FsbG9jIHdpbGwgcmV0dXJuIDAg
aWYgdGhlcmUgaXMgZXJyb3IsIGJ1dCBpZiB0aGUgYWRkcmVzcw0KPiA+ID4gPiByZXR1cm5lZCBp
cyBqdXN0IDB4MCwgaXQgY2FuJ3QgZGlzdGluZ3Vpc2ggaXQgaXMgYWRkcmVzcyBvciBlcnJvci4N
Cj4gPiA+ID4NCj4gPiA+DQo+ID4gPiBZZXMsIHRoYXQncyBhIGJhZCBsaW1pdGF0aW9uIG9mIGdl
bl9wb29sLiBNYXliZSBvbmUgZGF5IHRoYXQgd2lsbA0KPiA+ID4gZ2V0IGZpeGVkLg0KPiA+ID4g
SW4gYSBwcmV2aW91cyBvdXQgb2YgdHJlZSBkcml2ZXIsIEkgd29ya2VkIGFyb3VuZCB0aGlzIGJ5
IG9mZnNldHRpbmcNCj4gPiA+IHRoZSBnZW5fcG9vbF9hZGQgYnkgYSBjb25zdGFudCBzbyBhbnkg
cmV0dXJuIHZhbHVlIHdhcyBub24temVybyBhbmQNCj4gPiA+IG91dCBvZiBtZW1vcnkgd2FzIHpl
cm8gYW5kIHRoZW4gc3VidHJhY3RpbmcgdGhlIGNvbnN0YW50IG9mZiBvZiB0aGUNCj4gcmV0dXJu
IHZhbHVlLg0KPiA+ID4gTm90IHN1cmUgaWYgdGhhdCdzIGJldHRlciBvciB3b3JzZSB0aGFuIGp1
c3QgZml4aW5nIGdlbl9hbGxvYy4NCj4gPiA+DQo+ID4NCj4gPiBUaGUgd29ya2Fyb3VuZCB3b3Jr
cyBmb3Igbm9uIGFsaWdubWVudCBhbGxvY2F0aW9uLCBidXQgZm9yIGFsaWdubWVudA0KPiA+IGFs
bG9jYXRpb24sIEl0IG5lZWQgdG8gYWxpZ24gYnl0ZXMgdG8gYWRkciAwLCBvZmZzZXR0aW5nIHRo
ZQ0KPiA+IGdlbl9wb29sX2FkZCBtYXliZSBtYWtlIHdyb25nIGFsaWdubWVudA0KPiANCj4gSXQg
d291bGQgd29yayBpZiB0aGUgb2Zmc2V0IHlvdSBhZGQgaXMgYSBtdWx0aXBsZSBvZiB0aGUgc2l6
ZSBvZiBtdXJhbS4NCg0KVGhlIFFFIGFwcHMgYXNrIGRpZmZlcmVudCBieXRlcyBhbGlnbm1lbnQg
Zm9yIGRpZmZlcmVudCB1c2UgZHVlIHRvIGhhcmR3YXJlIHJlc3RyaWN0aW9uLg0KV2h5IGRvbuKA
mXQgd2UgZGVhbCB3aXRoIGl0IGluIGdlbl9wb29sX2FsbG9jIGZ1bmMgaW5zdGVhZCBvZiBhIHdv
cmthcm91bmQ/DQpJdCBpcyBtb3JlIHJlYXNvbmFibGUuDQoNCj4gDQo+IC1TY290dA0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web