From: Andres Salomon <dilinger@queued.net>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5] of/promtree: allow DT device matching by fixing
Date: Sat, 26 Feb 2011 06:41:32 +0000 [thread overview]
Message-ID: <20110225224132.0c15eb8a@queued.net> (raw)
In-Reply-To: <AANLkTimc37=azh11sYYi6x7gTE=0ybud5tXgxa1TDUMT-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 24 Feb 2011 23:06:06 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Feb 24, 2011 at 1:01 PM, Andres Salomon <dilinger@queued.net>
> wrote:
> > On Thu, 24 Feb 2011 12:42:34 -0700
> > Grant Likely <grant.likely@secretlab.ca> wrote:
> >> If firmware is buggy, then pkg2path must deal with it. It is not
> >> okay for it to return NULL. (I know that pkg2path is an OFW
> >> command, but in this context it really means the linux wrapper to
> >> pkg2path which has the semantics, "give me the unique, full and
> >> accurate path for this node"). If OFW pkg2path doesn't work, then
> >> the platform code must work around it. I'm pushing back on this
> >> because I do not want to see platform workarounds in the common
> >> code.
> >
> > I'm fine with that, I just don't want to see BUG() happening that
> > early. I think a workaround should be handled in common code. I
> > agree that heroic workarounds for firmware bugs should be handled in
> > arch-specific pkg2path hooks, but a simple workaround in common code
> > is better than just crashing early in boot (imo).
>
> Alright, you've swayed me a bit. I've made this change and pushed it
> out to devicetree/experimental. I've also picked up your other patch.
> Let me know if it works for you.
Thanks, that looks good. Feel free to push into next.
WARNING: multiple messages have this Message-ID (diff)
From: Andres Salomon <dilinger@queued.net>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: dsd@laptop.org, sparclinux@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness
Date: Fri, 25 Feb 2011 22:41:32 -0800 [thread overview]
Message-ID: <20110225224132.0c15eb8a@queued.net> (raw)
In-Reply-To: <AANLkTimc37=azh11sYYi6x7gTE=0ybud5tXgxa1TDUMT@mail.gmail.com>
On Thu, 24 Feb 2011 23:06:06 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Feb 24, 2011 at 1:01 PM, Andres Salomon <dilinger@queued.net>
> wrote:
> > On Thu, 24 Feb 2011 12:42:34 -0700
> > Grant Likely <grant.likely@secretlab.ca> wrote:
> >> If firmware is buggy, then pkg2path must deal with it. It is not
> >> okay for it to return NULL. (I know that pkg2path is an OFW
> >> command, but in this context it really means the linux wrapper to
> >> pkg2path which has the semantics, "give me the unique, full and
> >> accurate path for this node"). If OFW pkg2path doesn't work, then
> >> the platform code must work around it. I'm pushing back on this
> >> because I do not want to see platform workarounds in the common
> >> code.
> >
> > I'm fine with that, I just don't want to see BUG() happening that
> > early. I think a workaround should be handled in common code. I
> > agree that heroic workarounds for firmware bugs should be handled in
> > arch-specific pkg2path hooks, but a simple workaround in common code
> > is better than just crashing early in boot (imo).
>
> Alright, you've swayed me a bit. I've made this change and pushed it
> out to devicetree/experimental. I've also picked up your other patch.
> Let me know if it works for you.
Thanks, that looks good. Feel free to push into next.
WARNING: multiple messages have this Message-ID (diff)
From: Andres Salomon <dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness
Date: Fri, 25 Feb 2011 22:41:32 -0800 [thread overview]
Message-ID: <20110225224132.0c15eb8a@queued.net> (raw)
In-Reply-To: <AANLkTimc37=azh11sYYi6x7gTE=0ybud5tXgxa1TDUMT-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 24 Feb 2011 23:06:06 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Feb 24, 2011 at 1:01 PM, Andres Salomon <dilinger@queued.net>
> wrote:
> > On Thu, 24 Feb 2011 12:42:34 -0700
> > Grant Likely <grant.likely@secretlab.ca> wrote:
> >> If firmware is buggy, then pkg2path must deal with it. It is not
> >> okay for it to return NULL. (I know that pkg2path is an OFW
> >> command, but in this context it really means the linux wrapper to
> >> pkg2path which has the semantics, "give me the unique, full and
> >> accurate path for this node"). If OFW pkg2path doesn't work, then
> >> the platform code must work around it. I'm pushing back on this
> >> because I do not want to see platform workarounds in the common
> >> code.
> >
> > I'm fine with that, I just don't want to see BUG() happening that
> > early. I think a workaround should be handled in common code. I
> > agree that heroic workarounds for firmware bugs should be handled in
> > arch-specific pkg2path hooks, but a simple workaround in common code
> > is better than just crashing early in boot (imo).
>
> Alright, you've swayed me a bit. I've made this change and pushed it
> out to devicetree/experimental. I've also picked up your other patch.
> Let me know if it works for you.
Thanks, that looks good. Feel free to push into next.
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
next prev parent reply other threads:[~2011-02-26 6:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-24 17:04 [PATCH v5] of/promtree: allow DT device matching by fixing 'name' Grant Likely
2011-02-24 17:04 ` [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness Grant Likely
2011-02-24 17:33 ` [PATCH v5] of/promtree: allow DT device matching by fixing Andres Salomon
2011-02-24 17:33 ` [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness Andres Salomon
2011-02-24 19:42 ` [PATCH v5] of/promtree: allow DT device matching by fixing Grant Likely
2011-02-24 19:42 ` [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness Grant Likely
2011-02-24 20:01 ` [PATCH v5] of/promtree: allow DT device matching by fixing Andres Salomon
2011-02-24 20:01 ` [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness Andres Salomon
[not found] ` <20110224120109.0ed9f473-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>
2011-02-25 6:06 ` Grant Likely
2011-02-25 6:06 ` Grant Likely
2011-02-25 6:06 ` Grant Likely
[not found] ` <AANLkTimc37=azh11sYYi6x7gTE=0ybud5tXgxa1TDUMT-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-02-26 6:41 ` Andres Salomon [this message]
2011-02-26 6:41 ` Andres Salomon
2011-02-26 6:41 ` Andres Salomon
2011-02-24 23:27 ` [PATCH v5] of/promtree: allow DT device matching by fixing Andres Salomon
2011-02-24 23:27 ` [PATCH v5] of/promtree: allow DT device matching by fixing 'name' brokenness Andres Salomon
2011-02-24 19:45 ` [PATCH v6] of/pdt: allow DT device matching by fixing 'name' Andres Salomon
2011-02-24 19:45 ` [PATCH v6] of/pdt: allow DT device matching by fixing 'name' brokenness Andres Salomon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110225224132.0c15eb8a@queued.net \
--to=dilinger@queued.net \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.