On Mon, Oct 01, 2018 at 02:51:48PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 01 Oct 2018 12:56:37 +0200, Jan Kundrát wrote:
>
> > Thomas, Russell, Lorenzo,
> > did you have time to convert this into a patch which can hit 4.19? I don't
> > see anything related in 4.19-rc6, but perhaps
On Mon, Oct 01, 2018 at 02:51:48PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 01 Oct 2018 12:56:37 +0200, Jan Kundrát wrote:
>
> > Thomas, Russell, Lorenzo,
> > did you have time to convert this into a patch which can hit 4.19? I don't
> > see anything related in 4.19-rc6, but perhaps
Hello,
On Mon, 01 Oct 2018 12:56:37 +0200, Jan Kundrát wrote:
> Thomas, Russell, Lorenzo,
> did you have time to convert this into a patch which can hit 4.19? I don't
> see anything related in 4.19-rc6, but perhaps I missed something. Is there
> something that I should test or otherwise help?
Hello,
On Mon, 01 Oct 2018 12:56:37 +0200, Jan Kundrát wrote:
> Thomas, Russell, Lorenzo,
> did you have time to convert this into a patch which can hit 4.19? I don't
> see anything related in 4.19-rc6, but perhaps I missed something. Is there
> something that I should test or otherwise help?
On pondělí 24. září 2018 16:52:18 CEST, Thomas Petazzoni wrote:
Hello,
On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote:
I understand that, I wanted to make sure we come up with a fix asap
and what I put forward would cover everything discussed in this thread,
at least temporarily,
On pondělí 24. září 2018 16:52:18 CEST, Thomas Petazzoni wrote:
Hello,
On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote:
I understand that, I wanted to make sure we come up with a fix asap
and what I put forward would cover everything discussed in this thread,
at least temporarily,
Hi Thomas,
On Mon, Sep 24, 2018 at 02:12:03PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 12:13:41 +0100, Russell King - ARM Linux wrote:
>
> > > But being able to unmap it would also be needed to be able to remove
> > > PCI host controller drivers, and therefore compile
Hi Thomas,
On Mon, Sep 24, 2018 at 02:12:03PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 12:13:41 +0100, Russell King - ARM Linux wrote:
>
> > > But being able to unmap it would also be needed to be able to remove
> > > PCI host controller drivers, and therefore compile
On Mon, Sep 24, 2018 at 04:52:18PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote:
>
> > I understand that, I wanted to make sure we come up with a fix asap
> > and what I put forward would cover everything discussed in this thread,
> > at
On Mon, Sep 24, 2018 at 04:52:18PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote:
>
> > I understand that, I wanted to make sure we come up with a fix asap
> > and what I put forward would cover everything discussed in this thread,
> > at
Hello,
On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote:
> I understand that, I wanted to make sure we come up with a fix asap
> and what I put forward would cover everything discussed in this thread,
> at least temporarily, giving us time to check ISA related issues while
> unmapping
Hello,
On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote:
> I understand that, I wanted to make sure we come up with a fix asap
> and what I put forward would cover everything discussed in this thread,
> at least temporarily, giving us time to check ISA related issues while
> unmapping
On Mon, Sep 24, 2018 at 03:10:40PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote:
>
> > What I think you can do short term, given that AFAICS MVEBU is not
> > removable, instead of using pci_host_probe() you move part of its code
> > into
On Mon, Sep 24, 2018 at 03:10:40PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote:
>
> > What I think you can do short term, given that AFAICS MVEBU is not
> > removable, instead of using pci_host_probe() you move part of its code
> > into
Hello,
On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote:
> What I think you can do short term, given that AFAICS MVEBU is not
> removable, instead of using pci_host_probe() you move part of its code
> into the driver and make sure that you remap IO as last operation before
> probe
Hello,
On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote:
> What I think you can do short term, given that AFAICS MVEBU is not
> removable, instead of using pci_host_probe() you move part of its code
> into the driver and make sure that you remap IO as last operation before
> probe
On Mon, Sep 24, 2018 at 02:12:03PM +0200, Thomas Petazzoni wrote:
[...]
> > Trying to address a regression with further development means that
> > _that_ development needs thought and review, which is a slower
> > process.
> >
> > I do understand the desire to keep moving forward and never take
On Mon, Sep 24, 2018 at 02:12:03PM +0200, Thomas Petazzoni wrote:
[...]
> > Trying to address a regression with further development means that
> > _that_ development needs thought and review, which is a slower
> > process.
> >
> > I do understand the desire to keep moving forward and never take
Hello,
On Mon, 24 Sep 2018 12:13:41 +0100, Russell King - ARM Linux wrote:
> > But being able to unmap it would also be needed to be able to remove
> > PCI host controller drivers, and therefore compile them as module, and
> > make them more like any other drivers.
> >
> > I'm not sure why we
Hello,
On Mon, 24 Sep 2018 12:13:41 +0100, Russell King - ARM Linux wrote:
> > But being able to unmap it would also be needed to be able to remove
> > PCI host controller drivers, and therefore compile them as module, and
> > make them more like any other drivers.
> >
> > I'm not sure why we
On Mon, Sep 24, 2018 at 12:26:14PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
>
> > > Thanks for the testing. I'll wait for Russell to say if he is happy
> > > (or not) with the addition of pci_unmap_io() in the ARM code, if
On Mon, Sep 24, 2018 at 12:26:14PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
>
> > > Thanks for the testing. I'll wait for Russell to say if he is happy
> > > (or not) with the addition of pci_unmap_io() in the ARM code, if
Hello,
On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
> > Thanks for the testing. I'll wait for Russell to say if he is happy
> > (or not) with the addition of pci_unmap_io() in the ARM code, if that's
> > the case, I'll send a proper patch to fix the issue.
>
> I'd
Hello,
On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
> > Thanks for the testing. I'll wait for Russell to say if he is happy
> > (or not) with the addition of pci_unmap_io() in the ARM code, if that's
> > the case, I'll send a proper patch to fix the issue.
>
> I'd
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by
Hello,
On Mon, 24 Sep 2018 12:02:33 +0200, Jan Kundrát wrote:
> is there a proper patch for this? I've just verified that 4.19-rc5 won't
> boot for me either. Thomas' quick patch applies and makes the problem go
> away.
I was waiting for a quick review from Russell on my proposal, but since
Hello,
On Mon, 24 Sep 2018 12:02:33 +0200, Jan Kundrát wrote:
> is there a proper patch for this? I've just verified that 4.19-rc5 won't
> boot for me either. Thomas' quick patch applies and makes the problem go
> away.
I was waiting for a quick review from Russell on my proposal, but since
What about something like the below. I tested it, including the error
case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
after pci_unmap_iospace(). Actually, I would prefer to use
pci_remap_iospace() and pci_unmap_iospace() but for now this API
doesn't allow overloading the
What about something like the below. I tested it, including the error
case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
after pci_unmap_iospace(). Actually, I would prefer to use
pci_remap_iospace() and pci_unmap_iospace() but for now this API
doesn't allow overloading the
Hello,
On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > What about something like the below. I tested it, including the error
> > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
> > after
Hello,
On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > What about something like the below. I tested it, including the error
> > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
> > after
On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
What about something like the below. I tested it, including the error
case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
after pci_unmap_iospace(). Actually, I would prefer to use
pci_remap_iospace() and
On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
What about something like the below. I tested it, including the error
case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
after pci_unmap_iospace(). Actually, I would prefer to use
pci_remap_iospace() and
Russell, Baruch, Jan,
On Thu, 13 Sep 2018 00:10:51 +0100, Russell King - ARM Linux wrote:
> It's probably the latter - the region is probably already mapped, that
> being the PCI IO region.
>
> The original driver was setup to call pci_ioremap_io() as the very
> last thing - and as the driver
Russell, Baruch, Jan,
On Thu, 13 Sep 2018 00:10:51 +0100, Russell King - ARM Linux wrote:
> It's probably the latter - the region is probably already mapped, that
> being the PCI IO region.
>
> The original driver was setup to call pci_ioremap_io() as the very
> last thing - and as the driver
Hi Russell,
Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>>
>> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [1.855954] Code: e2844004
Hi Russell,
Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>>
>> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [1.855954] Code: e2844004
On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
> I reproduced the same Oops on Clearfog Base without any taint:
>
> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
...
> [1.855954] Code: e2844004 e5972000 e352 0aee (e7f001f2)
That is a
On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
> I reproduced the same Oops on Clearfog Base without any taint:
>
> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
...
> [1.855954] Code: e2844004 e5972000 e352 0aee (e7f001f2)
That is a
You mean '4.19-rc3', right?
Right, sorry.
[1.741458] Internal error: Oops - undefined instruction:
0 [#1] SMP ARM
[1.748182] CPU: 1 PID: 72 Comm: kworker/1:2 Tainted: G
W 4.19.0-rc3 #1
The 'W' taint means that there was a kernel warning before. Which
warning was
You mean '4.19-rc3', right?
Right, sorry.
[1.741458] Internal error: Oops - undefined instruction:
0 [#1] SMP ARM
[1.748182] CPU: 1 PID: 72 Comm: kworker/1:2 Tainted: G
W 4.19.0-rc3 #1
The 'W' taint means that there was a kernel warning before. Which
warning was
Jan, Baruch,
On Wed, 12 Sep 2018 21:49:41 +0300, Baruch Siach wrote:
> Jan Kundrát writes:
> > since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> > remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> > finish booting with 4.18-rc3 won't boot:
>
>
Jan, Baruch,
On Wed, 12 Sep 2018 21:49:41 +0300, Baruch Siach wrote:
> Jan Kundrát writes:
> > since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> > remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> > finish booting with 4.18-rc3 won't boot:
>
>
Hi Jan,
Jan Kundrát writes:
> since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> finish booting with 4.18-rc3 won't boot:
You mean '4.19-rc3', right?
>> [1.741458] Internal error: Oops -
Hi Jan,
Jan Kundrát writes:
> since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> finish booting with 4.18-rc3 won't boot:
You mean '4.19-rc3', right?
>> [1.741458] Internal error: Oops -
46 matches
Mail list logo
