Rename __read_msi_msg() as __pci_read_msi_msg() and kill unused
read_msi_msg(). It's a preparation to separate generic MSI code
from PCI core.
Signed-off-by: Jiang Liu
---
arch/powerpc/platforms/pseries/msi.c |2 +-
arch/x86/pci/xen.c |2 +-
drivers/pci/msi.c
On Wed, 2014-11-05 at 06:21 -0800, Guenter Roeck wrote:
> On Wed, Nov 05, 2014 at 04:45:14PM +0530, Neelesh Gupta wrote:
> > The current driver probe() function assumes the sensor device to be
> > alwary present and gets executed every time if the driver is loaded,
> > but the appropriate hardware
pm_power_off is defined for all architectures. Move it to common code.
Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.
Acked-by: David Vrabel
A
Register with kernel power-off handler instead of setting pm_power_off
directly.
If there is an indication that there can be more than one power-off handler,
use register_power_off_handler, otherwise use register_power_off_handler_simple
to register the power-off handler.
If the power-off handler
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 27 October 2014 09:09, Yuantian Tang wrote:
> Do we have a conclusion yet?
No. You can keep your initial duplication of Kconfig entries for the time being.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/
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.
> >
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
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the platform device infrastructure to probe the busses
on the platform and registers them with the i2c driver framework.
Signed-off-by:
Add BPF extension SKF_AD_HATYPE to ppc JIT to check
the hw type of the interface
Before:
[ 57.723666] test_bpf: #20 LD_HATYPE
[ 57.723675] BPF filter opcode 0020 (@0) unsupported
[ 57.724168] 48 48 PASS
After:
[ 103.053184] test_bpf: #20 LD_HATYPE 7 6 PASS
CC: Alexei Starovoitov
CC: Danie
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
Convert the pr_warning to the more common pr_warn.
Other miscellanea:
o Convert unusual PR_FMT define and uses to pr_fmt
o Remove unnecessary OOM message
o Fix grammar in an error message
o Convert a pr_warning with a KERN_ERR to pr_err
Signed-off-by: Joe Perches
---
drivers/tty/ehv_bytechan.c
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
13 matches
Mail list logo
