Hi Corey,
>>> Alternatively, they could be merged by one maintainer, pending an ack
>>> from the other.
>>
>> I'm fine either way.
>
> How about the third option? :)
>
> I've put patch 1 in a topic branch:
>
>
> https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=topic/opal-ipm
On Thu, 2014-11-06 at 08:15 -0600, Corey Minyard wrote:
> On 11/05/2014 09:38 PM, Jeremy Kerr wrote:
> > Corey & Michael: if this is acceptable, it may be mergable as two
> > separate patches - one for the IPMI subsystem, one for the powernv
> > platform. However, we'd need to preserve their order
On 11/09/2014 09:26 PM, Jeremy Kerr wrote:
> Hi Corey,
>
> Thanks for the review.
>
>>> IPMI folks: the IPMI driver could do with a little review, as it's
>>> not a conventional BT/KCS/SMI SI, in that the low-level send/recv
>>> interface will handle the entire message at once.
>> Handling the enti
On Mon, 2014-11-10 at 17:01 +1100, Alistair Popple wrote:
> Ben,
>
> >
> > Our OPAL interface can only do one at a time ? Because our underlying FW
> > driver already has a queue ..
>
> The OPAL interface supports sending more than one message at a time using the
> underlying FW queue as you su
Hi Ben,
> Our OPAL interface can only do one at a time ? Because our underlying
> FW driver already has a queue ..
The Linux driver needs to match responses to their requests, so the
driver needs to keep a reference to the requests that we've sent. The
current implementation is very simple: we ju
Ben,
>
> Our OPAL interface can only do one at a time ? Because our underlying FW
> driver already has a queue ..
The OPAL interface supports sending more than one message at a time using the
underlying FW queue as you suggest. However in theory the interface doesn't
make any response order gu
On Mon, 2014-11-10 at 11:26 +0800, Jeremy Kerr wrote:
> Hi Corey,
>
> Thanks for the review.
>
> >> IPMI folks: the IPMI driver could do with a little review, as it's
> >> not a conventional BT/KCS/SMI SI, in that the low-level send/recv
> >> interface will handle the entire message at once.
> >
Hi Corey,
Thanks for the review.
>> IPMI folks: the IPMI driver could do with a little review, as it's
>> not a conventional BT/KCS/SMI SI, in that the low-level send/recv
>> interface will handle the entire message at once.
>
> Handling the entire message at once should be fine, as that's what
On 11/05/2014 09:38 PM, Jeremy Kerr wrote:
> This series adds IPMI driver and arch glue for OPAL-firmware-based
> powernv machines. The first change exposes the firmware's IPMI API, and
> the second adds an actual driver.
>
> IPMI folks: the IPMI driver could do with a little review, as it's not a
This series adds IPMI driver and arch glue for OPAL-firmware-based
powernv machines. The first change exposes the firmware's IPMI API, and
the second adds an actual driver.
IPMI folks: the IPMI driver could do with a little review, as it's not a
conventional BT/KCS/SMI SI, in that the low-level se
10 matches
Mail list logo
