thanks!
Please, remember that we need to push it also to stable :)
On Sun, Aug 23, 2015 at 11:52 PM, Rob Herring wrote:
> On Thu, Jul 16, 2015 at 3:33 PM, Ricardo Ribalda Delgado
> wrote:
>> ping?
>>
>> Hello Grant, Hello Greg
>>
>> Is there any planned ti
ping?
On Thu, Jul 16, 2015 at 10:33 PM, Ricardo Ribalda Delgado
wrote:
> ping?
>
> Hello Grant, Hello Greg
>
> Is there any planned timeframe for applying this patch into someones tree?
>
>
> Thanks!
>
> On Tue, Jun 23, 2015 at 7:12 PM, Ricardo Ribalda Delgado
>
ping?
Hello Grant, Hello Greg
Is there any planned timeframe for applying this patch into someones tree?
Thanks!
On Tue, Jun 23, 2015 at 7:12 PM, Ricardo Ribalda Delgado
wrote:
> Hello
>
>> Tested-by: Wolfram Sang
>
> This patch now have a bunch of tested-by and witho
Ping?
On Fri, Jun 12, 2015 at 11:53 PM, Ricardo Ribalda Delgado
wrote:
> Hello Pantelis
>
> Thanks for your patches, I will try to test it during the next week.
> Just one question.
>
> Where can I find the dtc with support for __fixup__ and __local_fixups__ ?
>
> Seems
Hello
> Tested-by: Wolfram Sang
This patch now have a bunch of tested-by and without it, the current
version of linux-next crash.
Who will take it? Grant, Greg? Please make sure to notify
linux-stable since at least 4.1
Thanks!
--
Ricardo Ribalda
--
To unsubscribe from this list: send the
, Jun 12, 2015 at 10:06 PM, Pantelis Antoniou
wrote:
> Hi Ricardo,
>
>> On Jun 8, 2015, at 23:14 , Ricardo Ribalda Delgado
>> wrote:
>>
>> Hello Pantelis
>>
>> Any progress here?
>>
>
> I just posted a bunch of patches that make possible using P
Hello
Tested-by: Ricardo Ribalda Delgado
Some runtime warnings, but no oops
[ 46.348911] Trying to free nonexistent resource
<b005-b005>
[ 46.351979] Trying to free nonexistent resource
<b900-b900>
[ 46.351993] Trying to free
Hello Greg
On Wed, Jun 10, 2015 at 4:38 PM, Kevin Hilman wrote:
> On Wed, Jun 10, 2015 at 12:11 AM, Ricardo Ribalda Delgado
> At this stage of the cycle (merge window opening soon, maintainers
> trying to stabilize their stuff for Linus) we want to see linux-next
> approaching s
and Kevin sorry for wasting your time.
On Wed, Jun 10, 2015 at 2:22 AM, Kevin Hilman wrote:
> On Tue, Jun 9, 2015 at 4:00 AM, Grant Likely wrote:
>> On Mon, 8 Jun 2015 22:09:13 +0200
>> , Ricardo Ribalda Delgado wrote:
>
> [...]
>
>>>
>>> > Greg,
Hello Grant
On Tue, Jun 9, 2015 at 1:13 PM, Grant Likely wrote:
>
> On Mon, 8 Jun 2015 22:02:06 +0200
> , Ricardo Ribalda Delgado
> wrote:
> > Hello Grant
> >
> > On Mon, Jun 8, 2015 at 8:23 PM, Grant Likely
> > wrote:
> > > On Fri, 5 Ju
ing a v5 :)
Anyway whatever we decide I have some hardware where I can run tests if needed
Regards and sorry for the flood!
On Mon, Jun 8, 2015 at 10:09 PM, Ricardo Ribalda Delgado
wrote:
> Hello Grant
>
>
> On Mon, Jun 8, 2015 at 8:47 PM, Grant Likely wrote:
>> Hi Ric
, Jun 8, 2015 at 6:27 PM, Grant Likely wrote:
> On Tue, Apr 28, 2015 at 9:16 AM, Ricardo Ribalda Delgado
> wrote:
>>
>> Hello
>>
>> I have an X86 platform with device tree support. It has multiple pci
>> slots with a custom board that is described with a devic
Hello Pantelis
Any progress here?
Thanks
On Tue, Apr 28, 2015 at 10:36 AM, Pantelis Antoniou
wrote:
> Hi Ricardo,
>
>> On Apr 28, 2015, at 11:16 , Ricardo Ribalda Delgado
>> wrote:
>>
>> Hello
>>
>> I have an X86 platform with device tree support.
Hello Grant
On Mon, Jun 8, 2015 at 8:47 PM, Grant Likely wrote:
> Hi Ricardo,
>
> Comments below...
>
> On Sun, 7 Jun 2015 20:13:15 +0200
> , Ricardo Ribalda Delgado
> wrote:
>> Hello Grant
>>
>> I would ask you to go through all the discussion re
Hello Grant
On Mon, Jun 8, 2015 at 8:23 PM, Grant Likely wrote:
> On Fri, 5 Jun 2015 12:51:17 +0200
> , Ricardo Ribalda Delgado
> wrote:
>> Some device tree platforms have not defined correctly their memory
>> resources (i.e. Overlapping or duplication of resources).
>
Hello Pantelis
On Mon, Jun 8, 2015 at 10:14 AM, Pantelis Antoniou
wrote:
>>
>
> Either patch fixes (or rather papers over) the problem.
>
> The way I understand it is that we have two issues.
>
> 1. The rather obvious crash on device removal.
> 2. The of_platform_populate (and the subsequent call
ver, there are
> quite a few platforms that end up broken if we try to do that due to
> overlapping resources in the device tree. Until that is fixed, we need
> to solve the immediate problem.
>
> Cc: Pantelis Antoniou
> Cc: Wolfram Sang
> Cc: Rob Herring
Hello Rob,
Thanks for your feedback!
On Fri, Jun 5, 2015 at 6:45 PM, Rob Herring wrote:
> On Fri, Jun 5, 2015 at 5:51 AM, Ricardo Ribalda Delgado
> wrote:
>> Some device tree platform do not define their resources properly. i.e.
>> overlapping or repeated resources.
>>
Hello Grant and Rob
Could you take a look to these two patches that I have just sent.
kernel/resource: Add new flag IORESOURCE_SHARED
of/platform: Mark all device tree resources as SHARED
I think it fixes Grant problem.
Regards!
--
To unsubscribe from this list: send the line "unsubscribe devi
device tree (feature introduced recently).
This new flag tells the resource system that a resource can be shared by
multiple owners, so we can support device trees with problems at the
same time that we do not duplicate code or crash when unloading the
device tree.
Signed-off-by: Ricardo Ribalda
Some device tree platform do not define their resources properly. i.e.
overlapping or repeated resources.
This patch mark all device tree resources as shareable.
In the future this should only be set for the platforms that have
problems.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/of
Hello Grant
On Thu, Jun 4, 2015 at 7:25 AM, Grant Likely wrote:
>
> I think I tried that too and then ran in to a problem where drivers will
> fail if a different device 'owns' the resource.
>
> For example, if device-a and device-b have overlapping regions, device-a
> gets registered first and
Hello Grant
On Thu, Jun 4, 2015 at 9:54 AM, Grant Likely wrote:
>
> I'm pretty sure this is going to break some platforms. I described it in
> my earlier email today, but I'll summarize here too since this is the
> latest patch set.
The version that is in stable is also broken. Unloading the d
release_resource(),
called by of_platform_device_destroy(). This leads to a NULL pointer
deference.
Instead of fixing the NULL pointer deference, what could hide other bugs,
this patch, replaces of_device_add() with platform_device_data().
Signed-off-by: Ricardo Ribalda Delgado
Acked-by: Rob Herring
ring
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 46a56f694cec..5a29387e5ff6 100644
--- a/drivers/base/platform.c
+++ b/drive
platform_device_del only checks the type of the resource in order to
call release_resource.
On the other hand, platform_device_add calls insert_resource for any
resource that has a parent.
Make both code branches balanced.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c
Failure path of platform_device_add was almost the same as
platform_device_del. Refactor same code in a function.
Acked-by: Rob Herring
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c | 60 +
1 file changed, 25 insertions
rg/lkml/2015/4/23/254
https://lkml.org/lkml/2015/4/23/258
https://lkml.org/lkml/2015/4/23/257
https://lkml.org/lkml/2015/4/23/256
https://lkml.org/lkml/2015/4/23/255
v5: From: Rob Herring
-Fix descriptions
Ricardo Ribalda Delgado (4):
base/platform: Only insert MEM an
Hello Greg
Sorry for the mess. I did not want to spam the mailing list too much.
Repacking and resending. Thanks!
On Sun, May 24, 2015 at 9:29 PM, Greg Kroah-Hartman
wrote:
> On Fri, May 15, 2015 at 01:52:10PM +0200, Ricardo Ribalda Delgado wrote:
>> of_platform_device_create_pdata()
Hello
I have an X86 platform with device tree support. It has multiple pci
slots with a custom board that is described with a device tree.
When the pci device is probed, the driver fetches a device tree from
the firmware infrastructure, patches the range property based on the
bar address and adds
platform_device_del only checks the type of the resource in order to
call release_resource.
On the other hand, platform_device_add calls insert_resource for any
resource that has a parent.
Make both code branches balanced.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c
ml.org/lkml/2015/4/22/371
https://lkml.org/lkml/2015/4/22/374
https://lkml.org/lkml/2015/4/22/373
v4: From: Bjorn Helgaas
-Remove WARN() patch
-Show conflicting resources
-Code Style
-Fix descriptions
From: Rob Herring
-Fix descriptions
Ricardo Ribald
but this is not the case
anymore.
This patch let the flow continue when there is an insert error, after
notifying the user with a dev_err(). r->parent is set to NULL, so
platform_device_del() knows that the resource was not added, and
therefore it should not be released.
Signed-off
Failure path of platform_device_add was almost the same as
platform_device_del. Refactor same code in a function.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c | 60 +
1 file changed, 25 insertions(+), 35 deletions(-)
diff
(),
called by of_platform_device_destroy().
This leads to a NULL pointer deference.
This patch, replaces of_device_add() with platform_device_add().
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/of/platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of
Hello Rob
On Thu, Apr 23, 2015 at 9:28 AM, Ricardo Ribalda Delgado
wrote:
>
> I think it can also use platform_device_add. I will prepare a patch to
> finally remove of_device_add()
I will post right away an updated version of this patchset, and then I
will prepare another one
Hi Bjorn
On Wed, Apr 22, 2015 at 6:47 PM, Bjorn Helgaas wrote:
>
> I'm not really a fan of this. The NULL pointer oops is a very good clue
> all by itself, and it doesn't require any extra code here.
It is a pointer to 0x30.
For some reason my platform can handle a couple of oops, but if I ge
Hi Bjorn:
On Wed, Apr 22, 2015 at 6:44 PM, Bjorn Helgaas wrote:
> Usual style for referencing a commit is "(see 02bbde7849e6 ('Revert "of:
> use platform_device_add"'))".
Do you make that reference manually or there is a magic git command
for printing it in that style?
>
> Sounds like we shou
Hello Rob
On Wed, Apr 22, 2015 at 6:25 PM, Rob Herring wrote:
>> This patch, replaces of_device_add() with platform_device_data().
>
> This doesn't match the change.
Thanks for catching it up. Will fix it and resend
>> - if (of_device_add(dev) != 0) {
>> + if (platform_device_add(d
platform_device_del only checks the type of the resource in order to
call release_resource.
On the other hand, platform_device_add calls insert_resource for any
resource that has a parent.
Make both code branches balanced.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c
nline, but this is not the case
anymore.
This patch let the flow continue when there is an insert error, after
notifying the user with a dev_err(). r->parent is set to NULL, so the
device_del knows that the resource was not added, and therefore it
should not be released.
Signed-off-by: Ricardo Ri
(),
called by of_platform_device_destroy().
This leads to a NULL pointer deference.
This patch, replaces of_device_add() with platform_device_data().
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/of/platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of
e_resource+0x26/0x90
Signed-off-by: Ricardo Ribalda Delgado
---
kernel/resource.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/resource.c b/kernel/resource.c
index 90552aa..b7b270f 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -237,6 +237,9 @@ static int __release_
has been modified to use platform_device_add().
v1: https://lkml.org/lkml/2015/4/20/435
v2: https://lkml.org/lkml/2015/4/21/99
https://lkml.org/lkml/2015/4/21/100
Ricardo Ribalda Delgado (4):
kernel/resource: Invalid memory access in __release_resource
base/platform: Only insert MEM and IO r
Hello Rob
On Tue, Apr 21, 2015 at 10:13 PM, Rob Herring wrote:
> On Tue, Apr 21, 2015 at 3:25 AM, Ricardo Ribalda Delgado
> wrote:
>> of_platform_device_create_pdata() was using of_device_add() to create
>> the devices, but of_platform_device_destroy was using
>> of
(),
called by of_platform_device_destroy().
This leads to a NULL pointer deference.
This patch, replaces of_device_add() with platform_device_data().
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/of/platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of
e_resource+0x26/0x90
Signed-off-by: Ricardo Ribalda Delgado
---
kernel/resource.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/resource.c b/kernel/resource.c
index 90552aa..b7b270f 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -237,6 +237,9 @@ static int __release_
No worries :)
On Tue, Jan 20, 2015 at 11:41 AM, Peter Korsgaard wrote:
>>>>>> "Ricardo" == Ricardo Ribalda Delgado writes:
>
> > Hello Peter
> > I thought the logic behind the original driver was:
>
> > 1) Create gpiochip so it can be used
, 2015 at 11:48 PM, Peter Korsgaard wrote:
>>>>>> "Ricardo" == Ricardo Ribalda Delgado writes:
>
> > This way we do not need to transverse the device tree manually.
> > Cc: Linus Walleij
> > Cc: Alexandre Courbot
> > Cc: Grant Likely
Hello Mark
Thanks for noticing. I have just sent the v2 of the patch.
Regards!
On Mon, Jan 19, 2015 at 11:57 AM, Mark Rutland wrote:
> On Sun, Jan 18, 2015 at 11:39:29AM +0000, Ricardo Ribalda Delgado wrote:
>> Instead of parsing manually the shadow content, use the much simpler
Instead of parsing manually the shadow content, use the much simpler
helper of_property_read_u32.
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Grant Likely
Cc: Rob Herring
Cc: John Crispin
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland
Signed-off-by: Ricardo Ribalda Delgado
---
v2
Instead of parsing manually the shadow content, use the much simpler
helper of_property_read_u16.
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Grant Likely
Cc: Rob Herring
Cc: John Crispin
Cc: devicetree@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/gpio/gpio-mm
This way we do not need to transverse the device tree manually.
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Grant Likely
Cc: Rob Herring
Cc: Peter Korsgaard
Cc: devicetree@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/gpio/gpio-mpc8xxx.c | 48
Hello
On Mon, Jan 12, 2015 at 10:24 AM, Linus Walleij
wrote:
> On Wed, Dec 17, 2014 at 4:51 PM, Ricardo Ribalda Delgado
> wrote:
>
>> Core can be accessed via PCIe on X86 platform.
>> This patch also allows the driver to be used as module.
>>
>> Acked-by: Michal
Hello Sebastian
On Thu, Aug 28, 2014 at 3:13 PM, Sebastian Andrzej Siewior
wrote:
> On 08/28/2014 03:04 PM, Ricardo Ribalda Delgado wrote:
>> -- Forwarded message --
>> From: Ricardo Ribalda Delgado
>> Date: Tue, Aug 5, 2014 at 11:19 AM
>> Subject:
-- Forwarded message --
From: Ricardo Ribalda Delgado
Date: Tue, Aug 5, 2014 at 11:19 AM
Subject: [PATCH] x86/devicetree: Fix compile warnings on AMD64
To: Thomas Gleixner , Ingo Molnar
, "H. Peter Anvin" , x...@kernel.org,
Grant Likely , Rob Herring ,
Michal Simek , Ton
56 matches
Mail list logo
