Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1677912 > unrolled thread

Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices  before scanning John Garry <john.garry@huawei.com> - 2017-06-29 18:20 +0200
    Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices  before scanning Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-06-30 11:10 +0200
      Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices  before scanning John Garry <john.garry@huawei.com> - 2017-06-30 11:40 +0200
        Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices  before scanning "Rafael J. Wysocki" <rafael@kernel.org> - 2017-06-30 15:00 +0200

#1677912 — Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning

On 16/06/2017 12:24, Rafael J. Wysocki wrote:
>>>> >> >
>>>> >> > It causes acpi_default_enumeration() to be called but it should be fine
>>>> >> > as we are dealing with platform device anyway.
>>> >>
>>> >> I do not quite understand how declaring such MFD cell above would make sure
>>> >> that the LPC probe is called before the IPMI device is enumerated...
>> >
>> > In fact it may be that it is not sufficient in this case because the
>> > ACPI core might enumerate child devices before the LPC driver even gets
>> > a chance to probe so you would need to add also scan handler to the
>> > child devices and mark them already enumerated or something like that.
> Or extend the special I2C/SPI handling to them.
>

For this, is it possible to just configure the ACPI table so we spoof 
that the LPC slave (IPI0001), is an i2c/spi slave? Could we just add a 
resource of type ACPI_RESOURCE_TYPE_SERIAL_BUS, and common serial bus 
type i2c/spi to solve this?

This resource would/should need to be ignored for other purposes.

John

> Thanks,
> Rafael

[toc] | [next] | [standalone]

#1678614

On Thu, Jun 29, 2017 at 05:16:15PM +0100, John Garry wrote:
> On 16/06/2017 12:24, Rafael J. Wysocki wrote:
> > > > > >> >
> > > > > >> > It causes acpi_default_enumeration() to be called but it should be fine
> > > > > >> > as we are dealing with platform device anyway.
> > > > >>
> > > > >> I do not quite understand how declaring such MFD cell above would make sure
> > > > >> that the LPC probe is called before the IPMI device is enumerated...
> > > >
> > > > In fact it may be that it is not sufficient in this case because the
> > > > ACPI core might enumerate child devices before the LPC driver even gets
> > > > a chance to probe so you would need to add also scan handler to the
> > > > child devices and mark them already enumerated or something like that.
> > Or extend the special I2C/SPI handling to them.
> > 
> 
> For this, is it possible to just configure the ACPI table so we spoof that
> the LPC slave (IPI0001), is an i2c/spi slave? Could we just add a resource
> of type ACPI_RESOURCE_TYPE_SERIAL_BUS, and common serial bus type i2c/spi to
> solve this?

But is the device connected to a I2C or SPI bus? If not, then it does
not make much sense to declare it as I2C or SPI slave. Instead it should
be platform device which is the type we use when there is no explicit
bus specified in ACPI.

[toc] | [prev] | [next] | [standalone]

#1678633

On 30/06/2017 10:05, Mika Westerberg wrote:
> On Thu, Jun 29, 2017 at 05:16:15PM +0100, John Garry wrote:
>> On 16/06/2017 12:24, Rafael J. Wysocki wrote:
>>>>>>>>>
>>>>>>>>> It causes acpi_default_enumeration() to be called but it should be fine
>>>>>>>>> as we are dealing with platform device anyway.
>>>>>>>
>>>>>>> I do not quite understand how declaring such MFD cell above would make sure
>>>>>>> that the LPC probe is called before the IPMI device is enumerated...
>>>>>
>>>>> In fact it may be that it is not sufficient in this case because the
>>>>> ACPI core might enumerate child devices before the LPC driver even gets
>>>>> a chance to probe so you would need to add also scan handler to the
>>>>> child devices and mark them already enumerated or something like that.
>>> Or extend the special I2C/SPI handling to them.
>>>
>>
>> For this, is it possible to just configure the ACPI table so we spoof that
>> the LPC slave (IPI0001), is an i2c/spi slave? Could we just add a resource
>> of type ACPI_RESOURCE_TYPE_SERIAL_BUS, and common serial bus type i2c/spi to
>> solve this?
>
> But is the device connected to a I2C or SPI bus? If not, then it does
> not make much sense to declare it as I2C or SPI slave. Instead it should
> be platform device which is the type we use when there is no explicit
> bus specified in ACPI.
>

No, it's not a SPI nor an I2C bus. I actually would say that my idea is 
generally wrong, as the ACPI definition is not a real reflection of the 
bus/slave.

However, Rafael did suggest extending special I2C/SPI handling to them. 
In this case, I don't see how the LPC slave can be identified like an 
I2C or SPI slave is.

Thanks,
John

> .
>

[toc] | [prev] | [next] | [standalone]

#1678797

On Fri, Jun 30, 2017 at 11:28 AM, John Garry <john.garry@huawei.com> wrote:
> On 30/06/2017 10:05, Mika Westerberg wrote:
>>
>> On Thu, Jun 29, 2017 at 05:16:15PM +0100, John Garry wrote:
>>>
>>> On 16/06/2017 12:24, Rafael J. Wysocki wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It causes acpi_default_enumeration() to be called but it should be
>>>>>>>>>> fine
>>>>>>>>>> as we are dealing with platform device anyway.
>>>>>>>>
>>>>>>>>
>>>>>>>> I do not quite understand how declaring such MFD cell above would
>>>>>>>> make sure
>>>>>>>> that the LPC probe is called before the IPMI device is enumerated...
>>>>>>
>>>>>>
>>>>>> In fact it may be that it is not sufficient in this case because the
>>>>>> ACPI core might enumerate child devices before the LPC driver even
>>>>>> gets
>>>>>> a chance to probe so you would need to add also scan handler to the
>>>>>> child devices and mark them already enumerated or something like that.
>>>>
>>>> Or extend the special I2C/SPI handling to them.
>>>>
>>>
>>> For this, is it possible to just configure the ACPI table so we spoof
>>> that
>>> the LPC slave (IPI0001), is an i2c/spi slave? Could we just add a
>>> resource
>>> of type ACPI_RESOURCE_TYPE_SERIAL_BUS, and common serial bus type i2c/spi
>>> to
>>> solve this?
>>
>>
>> But is the device connected to a I2C or SPI bus? If not, then it does
>> not make much sense to declare it as I2C or SPI slave. Instead it should
>> be platform device which is the type we use when there is no explicit
>> bus specified in ACPI.
>>
>
> No, it's not a SPI nor an I2C bus. I actually would say that my idea is
> generally wrong, as the ACPI definition is not a real reflection of the
> bus/slave.
>
> However, Rafael did suggest extending special I2C/SPI handling to them. In
> this case, I don't see how the LPC slave can be identified like an I2C or
> SPI slave is.

I meant that it can be handled similarly (ie. as an exception from the
default enumeration), such that the enumeration is delayed until the
proper subsystem can enumerate those devices as appropriate.  Sorry
for the confusion.

Thanks,
Rafael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web