(2014/10/02 1:31), ttha...@opensource.altera.com wrote:
> +void socfpga_init_ocram_ecc(void)
> +{
> + struct device_node *np;
> + const __be32 *prop;
> + u32 ocr_edac_addr, iram_addr, len;
> + void __iomem *mapped_ocr_edac_addr;
> + size_t size;
> + struct gen_pool *gp;
> +
(2014/10/04 6:42), Dinh Nguyen wrote:
> On 10/03/2014 04:51 AM, Masami Hiramatsu wrote:
>> Hi Dinh,
>>
>> (2014/10/02 20:38), Dinh Nguyen wrote:
>>> On 10/1/14, 5:18 PM, Thor Thayer wrote:
On 10/01/2014 04:10 PM, Dinh Nguyen wrote:
>
> On 10/1/14, 4:07 PM, Thor Thayer wrote:
>
On 10/04/2014 02:53 AM, Mark Brown wrote:
On Fri, Oct 03, 2014 at 04:23:15PM -0700, Guenter Roeck wrote:
On 10/03/2014 04:13 PM, Mark Brown wrote:
Nope, nothing to do with regulator that I'm aware of and I've not seen
any examples (but I don't tend to review users too often).
Many examples
Quoting jonsm...@gmail.com (2014-10-03 14:50:24)
> On Fri, Oct 3, 2014 at 5:26 PM, Geert Uytterhoeven
> wrote:
> > On Fri, Oct 3, 2014 at 10:55 PM, jonsm...@gmail.com
> > wrote:
> >> On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven
> >> wrote:
> >>> On Thu, Oct 2, 2014 at 3:34 PM, jonsm...@
All phandles in the tree should be unique. Add a testcase to make sure
that this is so.
Note: this testcase fails on the current kernel because the selftest
code itself ends up adding duplicate phandles. Before this testcase is
merged the selftest code needs to be modified to resolve phandles befo
The selftest code removes its testcase data from the live tree when
exiting, but if the testcases data tree contains an empty child of the
root, then it causes an oops due to a NULL dereference. The reason is
that the code tries to directly dereference the child pointer without
checking first if a
Add a testcase to verify that the device tree is properly constructed
and the lists are in a correct order. The new testcase gets run twice;
once after adding the testcase data, and once after removing it again.
It is run twice to make sure adding and removing the testcase data
doesn't corrupt the
From: Pantelis Antoniou
Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare a device tree that's
been loaded on runtime to be modified and inserted at the kernel
live tree.
Export of of_resolve and bug fix of double free by
Guenter Roeck
Signed-off
A value of '0' isn't a valid phandle, so searching for a node with that
phandle is pointless. It will result in nothing but false positives.
Signed-off-by: Grant Likely
---
drivers/of/base.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 293ed4
The selftest data ends up causing duplicate phandles in the live tree
for the time that the testcase data is inserted into the live tree. This
is obviously a bad situation because anything attempting to read the
tree while the selftests are running make resolve phandles to one of the
testcase data
Janusz,
On Mon, Sep 29, 2014 at 11:11 AM, Janusz Uzycki wrote:
>> So I'm deleting all of these now, please resend the latest
>> versions you have, with properly versioning
>> and order information.
>
> Sure. If you don't want to comment dirty patches
> I will not send you them.
> I can send you o
On Sat, Oct 4, 2014 at 5:50 AM, Hans de Goede wrote:
> Hi,
>
> On 10/04/2014 12:56 AM, jonsm...@gmail.com wrote:
>> On Fri, Oct 3, 2014 at 4:08 PM, Rob Herring wrote:
>>> On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede wrote:
Hi,
On 10/03/2014 05:57 PM, Rob Herring wrote:
> On
On 01/10/14 17:14, Ivan T. Ivanov wrote:
> The current ADC is peripheral of Qualcomm SPMI PMIC chips. It has
> 16 bits resolution and register space inside PMIC accessible across
> SPMI bus.
>
> The driver registers itself through IIO interface.
>
> Signed-off-by: Ivan T. Ivanov
Looks good to me.
On Fri, Oct 03, 2014 at 10:06:08AM -0700, Dylan Reid wrote:
> The device tree property uses '-' not '_'.
Applied, thanks.
signature.asc
Description: Digital signature
On 02/10/14 13:08, Ivan T. Ivanov wrote:
> +iio maintainers
>
> On Thu, 2014-10-02 at 12:29 +0300, Ivan T. Ivanov wrote:
>> Hi Stan,
>>
>> On 09/24/2014 03:56 PM, Stanimir Varbanov wrote:
>>
>>
>>
>>> +static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node
>>> *node)
>>> +{
>>> +
On Saturday 04 October 2014 02:13:23 Rafael J. Wysocki wrote:
> > Because people get the format wrong regardless of documentation. The
> > format:
> >
> > Package () {
> > Package () { ^ref1, data, data },
> > Package () { ^ref2, data },
> > Package () { ^ref3, data, data, data }
On Saturday 04 October 2014 01:58:30 Rafael J. Wysocki wrote:
> On Friday, October 03, 2014 05:02:13 PM Arnd Bergmann wrote:
> > On Friday 03 October 2014 14:56:10 Mark Rutland wrote:
> > > On Thu, Oct 02, 2014 at 03:55:56PM +0100, Arnd Bergmann wrote:
> > > I'd certainly not like to see #foo-cells
On Fri, Oct 03, 2014 at 04:23:15PM -0700, Guenter Roeck wrote:
> On 10/03/2014 04:13 PM, Mark Brown wrote:
> >Nope, nothing to do with regulator that I'm aware of and I've not seen
> >any examples (but I don't tend to review users too often).
> Many examples, really. Just picking one.
> Document
Hi,
On 10/04/2014 12:56 AM, jonsm...@gmail.com wrote:
> On Fri, Oct 3, 2014 at 4:08 PM, Rob Herring wrote:
>> On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 10/03/2014 05:57 PM, Rob Herring wrote:
On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
> A simple
Hi,
On 10/03/2014 10:08 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 10/03/2014 05:57 PM, Rob Herring wrote:
>>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
A simple-framebuffer node represents a framebuffer setup by the firmware /
20 matches
Mail list logo
