On Wed, Jan 28, 2015 at 10:58:42AM +1100, Benjamin Herrenschmidt wrote:
>On Tue, 2015-01-27 at 16:58 -0600, Brian King wrote:
>> I'd argue we are our own worst enemy here really. The new user is EEH
>> code.
>> I don't see a huge reason that code would need to use this exact same
>> API.
>>
>> > I
On Tue, 2015-01-27 at 16:58 -0600, Brian King wrote:
> I'd argue we are our own worst enemy here really. The new user is EEH
> code.
> I don't see a huge reason that code would need to use this exact same
> API.
>
> > In fact, even with IPR and the existing call, how do you wait for
> the link to
On 01/26/2015 10:31 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2015-01-26 at 17:36 -0600, Brian King wrote:
>> To set some context, this function is only used by ipr for some old
>> broken adapters. These are adapters that are not supported on p8,
>> so will never show up under OPAL, only PowerVM.
On Mon, 2015-01-26 at 17:36 -0600, Brian King wrote:
> To set some context, this function is only used by ipr for some old
> broken adapters. These are adapters that are not supported on p8,
> so will never show up under OPAL, only PowerVM. I'm fine with looking
> at alternatives for the future, bu
On 01/24/2015 03:57 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2015-01-23 at 14:50 +1100, Gavin Shan wrote:
>
>> Messages from Brian for reference:
>>
>> | The API has changed. I wrote the pci_set_pcie_reset_state API originally.
>> | When this API was put in place initially, it was perfectly leg
On Fri, 2015-01-23 at 14:50 +1100, Gavin Shan wrote:
> Messages from Brian for reference:
>
> | The API has changed. I wrote the pci_set_pcie_reset_state API originally.
> | When this API was put in place initially, it was perfectly legal to call it
> | from an atomic context. Can you clarify why
On Wed, Jan 21, 2015 at 10:53:38AM +1100, Gavin Shan wrote:
>On Wed, Jan 21, 2015 at 09:56:07AM +1100, Gavin Shan wrote:
>>On Tue, Jan 20, 2015 at 10:28:16AM +0100, Benjamin Herrenschmidt wrote:
>>>On Mon, 2015-01-19 at 09:47 +1100, Gavin Shan wrote:
On pseries platform, the EEH reset backend
On Wed, Jan 21, 2015 at 09:56:07AM +1100, Gavin Shan wrote:
>On Tue, Jan 20, 2015 at 10:28:16AM +0100, Benjamin Herrenschmidt wrote:
>>On Mon, 2015-01-19 at 09:47 +1100, Gavin Shan wrote:
>>> On pseries platform, the EEH reset backend pseries_eeh_reset() can
>>> be called in atomic context as follo
On Tue, Jan 20, 2015 at 10:28:16AM +0100, Benjamin Herrenschmidt wrote:
>On Mon, 2015-01-19 at 09:47 +1100, Gavin Shan wrote:
>> On pseries platform, the EEH reset backend pseries_eeh_reset() can
>> be called in atomic context as follows. For this case, we should
>> call udelay() instead of msleep(
On Mon, 2015-01-19 at 09:47 +1100, Gavin Shan wrote:
> On pseries platform, the EEH reset backend pseries_eeh_reset() can
> be called in atomic context as follows. For this case, we should
> call udelay() instead of msleep() to avoid context switching.
>
> drivers/scsi/ipr.c::ipr_reset_slot_r
On pseries platform, the EEH reset backend pseries_eeh_reset() can
be called in atomic context as follows. For this case, we should
call udelay() instead of msleep() to avoid context switching.
drivers/scsi/ipr.c::ipr_reset_slot_reset_done()
drivers/pci/pci.c::pci_set_pcie_reset_state()
11 matches
Mail list logo
