On Tue, May 14, 2019 at 02:02:40PM +0200, Esben Haabendal wrote:
> Andy Shevchenko writes:
>
> > On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko
> > wrote:
> >> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal
> >> wrote:
> >
> >> > Please take a look at https://lkml.org/lkml/2019/4/9/576
>
On Tue, May 14, 2019 at 02:02:36PM +0200, Esben Haabendal wrote:
> Andy Shevchenko writes:
> > On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
> >> Andy Shevchenko writes:
> >> > On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
> >
> >> We are on repeat here. I don't
Andy Shevchenko writes:
> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
>
>> We are on repeat here. I don't agree with you here. I have a simple
>> generic 8250 (16550A) compatible
Andy Shevchenko writes:
> On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko
> wrote:
>> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
>
>> > Please take a look at https://lkml.org/lkml/2019/4/9/576
>> > ("[PATCH v2 2/4] mfd: ioc3: Add driver for SGI IOC3 chip")
>>
>> Thank you for
On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko
wrote:
> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
> > Please take a look at https://lkml.org/lkml/2019/4/9/576
> > ("[PATCH v2 2/4] mfd: ioc3: Add driver for SGI IOC3 chip")
>
> Thank you for this link.
> Now, look at this comment:
On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote:
> Andy Shevchenko writes:
> > On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
> We are on repeat here. I don't agree with you here. I have a simple
> generic 8250 (16550A) compatible device, and cannot use it in a mfd
>
Andy Shevchenko writes:
> On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
>> >> Lee Jones writes:
>> >> > On Thu, 02 May 2019, Esben Haabendal wrote:
>> >> >
>> >> >> Could you
Andy Shevchenko writes:
> On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> > On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
>> >> Lee Jones writes:
>> >> > On Thu, 02 May 2019, Esben Haabendal wrote:
>> >> >
>> >> >> Could you
On Tue, May 07, 2019 at 02:22:18PM +0200, Esben Haabendal wrote:
> Andy Shevchenko writes:
> > On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
> >> Lee Jones writes:
> >> > On Thu, 02 May 2019, Esben Haabendal wrote:
> >> >
> >> >> Could you help clarify whether or not this
Andy Shevchenko writes:
> On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
>> Lee Jones writes:
>> > On Thu, 02 May 2019, Esben Haabendal wrote:
>> >
>> >> Could you help clarify whether or not this patch is trying to do
>> >> something odd/wrong?
>> >>
>> >> I might be
On Tue, May 07, 2019 at 01:35:58PM +0200, Esben Haabendal wrote:
> Lee Jones writes:
> > On Thu, 02 May 2019, Esben Haabendal wrote:
> >
> >> Could you help clarify whether or not this patch is trying to do
> >> something odd/wrong?
> >>
> >> I might be misunderstanding Andy (probably is), but
Lee Jones writes:
> On Thu, 02 May 2019, Esben Haabendal wrote:
>
>> Could you help clarify whether or not this patch is trying to do
>> something odd/wrong?
>>
>> I might be misunderstanding Andy (probably is), but the discussion
>> revolves around the changes I propose where I change the
Lee Jones writes:
> On Tue, 07 May 2019, Lee Jones wrote:
>> On Thu, 02 May 2019, Esben Haabendal wrote:
>>
>> > Could you help clarify whether or not this patch is trying to do
>> > something odd/wrong?
>> >
>> > I might be misunderstanding Andy (probably is), but the discussion
>> > revolves
On Tue, 07 May 2019, Lee Jones wrote:
> On Thu, 02 May 2019, Esben Haabendal wrote:
>
> > Hi Lee
> >
> > Could you help clarify whether or not this patch is trying to do
> > something odd/wrong?
> >
> > I might be misunderstanding Andy (probably is), but the discussion
> > revolves around the
On Thu, 02 May 2019, Esben Haabendal wrote:
> Hi Lee
>
> Could you help clarify whether or not this patch is trying to do
> something odd/wrong?
>
> I might be misunderstanding Andy (probably is), but the discussion
> revolves around the changes I propose where I change the serial8250
> driver
Let's start from simple things:
- I really failed to find where resources are requested in
mfd_add_device():
https://elixir.bootlin.com/linux/latest/ident/mfd_add_device
- as for 8250_dw.c (as MFD child of intel-lpss-pci.c) see below...
1. 8250_dw.c remaps resources, but doesn't request them.
2.
> On Mon, May 06, 2019 at 05:46:56PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> >> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
>> >> >> Andy Shevchenko writes:
>
>> As an example, the sm501.c driver, the only driver in drivers/mfd/ which
>> uses serial8250
On Mon, May 06, 2019 at 05:46:56PM +0200, Esben Haabendal wrote:
> Andy Shevchenko writes:
> >> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
> >> >> Andy Shevchenko writes:
> As an example, the sm501.c driver, the only driver in drivers/mfd/ which
> uses serial8250 driver,
Andy Shevchenko writes:
>> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
>> >> Andy Shevchenko writes:
>> >
>> >> > Hmm... Currently it's done inside individual port drivers, like
>> >> > 8250_dw.c.
>> >> > Each of the drivers can do it differently, for example 8250_lpss.c
"Enrico Weigelt, metux IT consult" writes:
> On 30.04.19 16:04, Esben Haabendal wrote:
>> Allow getting memory resource (mapbase or iobase) as well as irq from
>> platform_device resources.
>>
>> The UPF_DEV_RESOURCES flag must be set for devices where platform_device
>> resources are to be
On 30.04.19 16:04, Esben Haabendal wrote:
> Allow getting memory resource (mapbase or iobase) as well as irq from
> platform_device resources.
>
> The UPF_DEV_RESOURCES flag must be set for devices where platform_device
> resources are to be used. When not set, driver behaves as before.
>
>
On Thu, May 02, 2019 at 02:41:45PM +0200, Esben Haabendal wrote:
> Hi Lee
>
> Could you help clarify whether or not this patch is trying to do
> something odd/wrong?
>
> I might be misunderstanding Andy (probably is), but the discussion
> revolves around the changes I propose where I change the
Hi Lee
Could you help clarify whether or not this patch is trying to do
something odd/wrong?
I might be misunderstanding Andy (probably is), but the discussion
revolves around the changes I propose where I change the serial8250
driver to use platform_get_resource() in favour of
On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
> Andy Shevchenko writes:
> > Hmm... Currently it's done inside individual port drivers, like 8250_dw.c.
> > Each of the drivers can do it differently, for example 8250_lpss.c or
> > 8250_pnp.c.
>
> So, you would prefer to create
Andy Shevchenko writes:
> On Tue, Apr 30, 2019 at 04:04:13PM +0200, Esben Haabendal wrote:
>> Remaining platform_data fields (other than mapbase, iobase, mapsize and
>> irq) are used just as before. Note
>
> Note what?
Note nothing. I will remove it, sorry about that.
>> +static int
On Tue, Apr 30, 2019 at 04:04:13PM +0200, Esben Haabendal wrote:
> Allow getting memory resource (mapbase or iobase) as well as irq from
> platform_device resources.
>
> The UPF_DEV_RESOURCES flag must be set for devices where platform_device
> resources are to be used. When not set, driver
Allow getting memory resource (mapbase or iobase) as well as irq from
platform_device resources.
The UPF_DEV_RESOURCES flag must be set for devices where platform_device
resources are to be used. When not set, driver behaves as before.
This allows use of the serial8250 driver together with
27 matches
Mail list logo
