On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> >
> > Certainly, we *will* need subsystems to have
On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
>
> What is the plan for fixing things here? It's not obvious (at least to
On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
>
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in spec
On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
> > > > I can't see adding calls li
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() {
19 @@ static int of_platform_serial_probe(struct
platform_device *ofdev)
info->type = port_type;
info->line = ret;
- platform_set_drvdata(ofdev, info);
+ platform_set_drvdata(pdev, info);
return 0;
out:
kfree(info);
- irq_dispose_mapping(port.irq);
return ret;
}
/*
* Release a line
*/
-static int of_platform_serial_remove(struct platform_device *ofdev)
+static int of_platform_serial_remove(struct platform_device *pdev)
{
- struct of_serial_info *info = platform_get_drvdata(ofdev);
+ struct of_serial_info *info = platform_get_drvdata(pdev);
switch (info->type) {
#ifdef CONFIG_SERIAL_8250
case PORT_8250 ... PORT_MAX_8250:
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
> 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
t in the general case for 'leaf-node' peripherals we would hope that
we don't really have to change *anything* other than to make sure the
driver is using generic property accessor functions instead of the old
OF-specific ones. The point here is *consistency*. We really don't w
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_
because it
won't *really* break compatibility with existing firmware because these
boxes have *always* shipped with a DTB built into the kernel or
something.
In which case all I'm complaining about is the fact that you didn't
properly address that in the commit comment and *explain* why it
> So it is time IMHO that the description of how things *shall* work be
> itself revised.
It *is* being revised, with an explicit explicit understanding that things
will have to change and a defined process for how to cope with that.
That was discussed yesterday and we will be finishing the writ
> On Thu, Oct 24, 2013 at 02:22:06PM -0000, David Woodhouse wrote:
>>
>> > Experimental bindings could be a suitable temporary measure, but
>> perhaps
>> > other, better solutions exist.
>>
>> Yes, unstable bindings are part of the currently-documente
> On Thu, Oct 24, 2013 at 02:05:58PM -0000, David Woodhouse wrote:
>>
>> >
>> > On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
>> >
>> >> Note that you are not describing a normal "DT scenario" here. You are
>> >&
> Experimental bindings could be a suitable temporary measure, but perhaps
> other, better solutions exist.
Yes, unstable bindings are part of the currently-documented plan. You are
not expected to need it as a matter of course, but that facility will
exist.
--
dwmw2
--
To unsubscribe from th
>
> On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
>
>> Note that you are not describing a normal "DT scenario" here. You are
>> describing a case in which we screwed up
>
> AKA "real world"
No. Absolutely not. That was a screwup, and it
>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not
>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not
>
> On Thu, 2013-10-24 at 12:22 +, David Woodhouse wrote:
>
>> If you are correct to insist that DMA needs yo be supported in the new
>> driver *even* with old firmware, then yes, maybe.
>
> if DMA gives a performance boost for all workloads, what is the argument
&
>
> On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> my point
>
> before DT scenario for my hw crypto driver example:
Note that you are not describing a normal "DT scenario" here. You are
describing a case in which we screwed up and allowed non-invariant
features of the hardware to be l
> On Thu, Oct 24, 2013 at 12:47:58PM +0100, David Woodhouse wrote:
>> On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
>> >
>> > ok then how do we solve that case:
>> >
>> > - Marvell SOC 1 is mainlined
>> > - Marvell SOC 2 is mainl
On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
>
> ok then how do we solve that case:
>
> - Marvell SOC 1 is mainlined
> - Marvell SOC 2 is mainlined
> - Marvell SOC 'x' is mainlined
> - "PIO" hw crypto driver is written, working for all SOCs
> - [1 year]
> - SOCs bindings are marke
On Wed, 2013-10-23 at 09:55 -0700, Guenter Roeck wrote:
>
> So to avoid tainting the kernel and clogging the kernel log I'll have
> to remove all the "!" from the dt sources, or not use any "!" in the
> dt bindings in the first place. Given that, not sure if anyone will
> really use this mechanism
->full_name);
> +
In the discussions earlier I think we decided that this should set a
taint flag too. If you've built a kernel with CONFIG_OF_EXPERIMENTAL
(which I think we were calling CONFIG_UNSTABLE_DT) then you have no
expectation that it will boot tomorrow, although it might
d way. And it's not unreasonable to
have that as a DT property. We're no *more* Linux-specific than we were
before.
But perhaps it's too late for 3.12 to do that?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
25 matches
Mail list logo
