On Wednesday, January 14, 2015 10:42:23 AM David Woodhouse wrote:
>
> --=-3dIl43yXcWwu/nzOqQWw
> Content-Type: multipart/mixed; boundary="=-ca0AFM5hvqL+pJIndiHh"
>
>
> --=-ca0AFM5hvqL+pJIndiHh
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> I'm look
I'm looking again at updating of_serial to work with ACPI properties.
Specifically, I want to support a serial port with a non-standard baud
rate, something like this:
Device(COM1) {
Name(_HID, EisaId("PNP0501"))
Name(_CID, EisaId("PRP0001"))
Name(_DSD, Package() {
On Sat, Oct 18, 2014 at 10:35:49AM +0200, Grant Likely wrote:
> On Wed, 15 Oct 2014 17:43:01 +0200
> , Darren Hart
> wrote:
> >
> >
> > On 10/15/14 17:17, Mark Rutland wrote:
> > > On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
> >
> > >> Mark, what would you propose we do differ
On Thu, 16 Oct 2014 16:55:56 +0200
, David Woodhouse
wrote:
> On Wed, 2014-10-15 at 17:43 +0200, Darren Hart wrote:
> >
> > So my objection here is that by keeping the of_* terms in the driver we
> > are required to include of, although it does safely convert to returning
> > NULL if !CONFIG_OF
On Wed, 15 Oct 2014 17:43:01 +0200
, Darren Hart
wrote:
>
>
> On 10/15/14 17:17, Mark Rutland wrote:
> > On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
>
> >> Mark, what would you propose we do differently to enable this driver to
> >> be firmware-type agnostic?
> >
> > For this
On Thu, 16 Oct 2014 16:55:56 +0200
, David Woodhouse
wrote:
> On Wed, 2014-10-15 at 17:43 +0200, Darren Hart wrote:
> >
> > So my objection here is that by keeping the of_* terms in the driver we
> > are required to include of, although it does safely convert to returning
> > NULL if !CONFIG_OF
On Wed, 2014-10-15 at 17:43 +0200, Darren Hart wrote:
>
> So my objection here is that by keeping the of_* terms in the driver we
> are required to include of, although it does safely convert to returning
> NULL if !CONFIG_OF I suppose.
New version removes everything but the of_match_id bits whic
On Wednesday, October 15, 2014 05:43:01 PM Darren Hart wrote:
>
> On 10/15/14 17:17, Mark Rutland wrote:
> > On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
>
> >> Mark, what would you propose we do differently to enable this driver to
> >> be firmware-type agnostic?
> >
> > For thi
On 10/15/14 17:17, Mark Rutland wrote:
> On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
>> Mark, what would you propose we do differently to enable this driver to
>> be firmware-type agnostic?
>
> For this particular driver, all I'm asking for is that the
> "used-by-rtas" property
On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
>
>
> On 10/15/14 16:08, David Woodhouse wrote:
> >
> >> We have been checking for all DT platforms, and that's a bug for DT.
> >> Copying that bug to ACPI is inexcusable given we know it's a bug to do
> >> so.
> >
> > We'll, perhaps
> We have been checking for all DT platforms, and that's a bug for DT.
> Copying that bug to ACPI is inexcusable given we know it's a bug to do
> so.
We'll, perhaps it should be named 'used-by-firmware' and actually it's
just as valid under ACPI as it is on RTAS systems. All it does is stop the
O
> My comment was going to be along the same lines. It is an optional
> parameter, which is what I would expect for a firmware-specific type of
> property.
Right. Fundamentally, device properties (in DT or ACPI) exist to describe
the hardware in a generic and abstract fashion. It's a slippery slop
On 10/15/14 16:08, David Woodhouse wrote:
>
>> We have been checking for all DT platforms, and that's a bug for DT.
>> Copying that bug to ACPI is inexcusable given we know it's a bug to do
>> so.
>
> We'll, perhaps it should be named 'used-by-firmware' and actually it's
> just as valid under A
On Wed, Oct 15, 2014 at 02:28:56PM +0100, David Woodhouse wrote:
> On Wed, 2014-10-15 at 14:15 +0100, Mark Rutland wrote:
> > > @@ -155,7 +168,7 @@ static int of_platform_serial_probe(struct
> > > platform_device *ofdev)
> > > if (!match)
> > > return -EINVAL;
> > >
> > > - if (of_fi
On Wed, 2014-10-15 at 14:15 +0100, Mark Rutland wrote:
> > @@ -155,7 +168,7 @@ static int of_platform_serial_probe(struct
> > platform_device *ofdev)
> > if (!match)
> > return -EINVAL;
> >
> > - if (of_find_property(ofdev->dev.of_node, "used-by-rtas", NULL))
> > + if (!devic
On Wed, Oct 15, 2014 at 02:04:31PM +0100, David Woodhouse wrote:
> Here's a completely untested patch to convert of_serial to be usable via
> ACPI properties too. The properties themselves were fairly
> straightforward; the interesting part is converting to
> platform_get_irq() and platform_get_res
Here's a completely untested patch to convert of_serial to be usable via
ACPI properties too. The properties themselves were fairly
straightforward; the interesting part is converting to
platform_get_irq() and platform_get_resource() — in the latter case
first trying IORESOURCE_MEM then IORESOURCE_
On Tue, Oct 07, 2014 at 02:10:56AM +0200, Rafael J. Wysocki wrote:
> Hi Everyone,
>
> This is version 4 of the unified device properties interface patchset.
>
> The original cover letter from Mika is here:
>
> http://marc.info/?l=devicetree&m=141087052200600&w=4
>
> My cover letter for version
On Tuesday, October 07, 2014 02:10:56 AM Rafael J. Wysocki wrote:
> Hi Everyone,
>
> This is version 4 of the unified device properties interface patchset.
>
> The original cover letter from Mika is here:
>
> http://marc.info/?l=devicetree&m=141087052200600&w=4
>
> My cover letter for version 3
Hi Everyone,
This is version 4 of the unified device properties interface patchset.
The original cover letter from Mika is here:
http://marc.info/?l=devicetree&m=141087052200600&w=4
My cover letter for version 3 is here:
http://marc.info/?l=linux-acpi&m=141212903816560&w=4
One major change fr
20 matches
Mail list logo
