* Pull request: scottwood/linux.git
From: Scott Wood @ 2014-05-23 21:21 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Highlights include a few new boards, a device tree binding for CCF
(including backwards-compatible device tree updates to distinguish
incompatible versions), and some fixes.
The following changes since commit f6869e7fe657bd977e72954cd78c5871a6a4f71d:
Merge remote-tracking branch 'anton/abiv2' into next (2014-05-05 20:57:12 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to e83eb028bb980cecc85b050aa626df384723aff2:
powerpc/fsl: Add fsl,portid-mapping to corenet1-cf chips (2014-05-22 18:10:42 -0500)
----------------------------------------------------------------
Alexander Graf (1):
PPC: ePAPR: Fix hypercall on LE guest
Diana Craciun (3):
powerpc/fsl: Added binding for Freescale CoreNet coherency fabric (CCF)
powerpc/fsl: Updated device trees for platforms with corenet version 2
powerpc/fsl: Updated corenet-cf compatible string for corenet1-cf chips
Lijun Pan (1):
powerpc/mpc85xx: Remove P1023 RDS support
Liu Gang (1):
powerpc/rmu: Fix the error memory free parameters
Martijn de Gouw (1):
powerpc/85xx: Add OCA4080 board support
Prabhakar Kushwaha (2):
powerpc/mpc85xx:Add initial device tree support of T104x
powerpc/fsl-booke: Add initial T104x_QDS board support
Scott Wood (6):
powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-after-unmap
powerpc/fsl-booke64: Set vmemmap_psize to 4K
powerpc: fix build of epapr_paravirt on 64-bit book3s
powerpc: Fix unused variable warning for epapr_has_idle
powerpc/mpic: Don't init the fsl error int until after mpic init
powerpc/fsl: Add fsl,portid-mapping to corenet1-cf chips
Stuart Yoder (1):
powerpc: move epapr paravirt init of power_save to an initcall
Tang Yuantian (1):
clk: qoriq: Update the clock bindings
Valentin Longchamp (3):
devicetree: bindings: add Zarlink to the vendor prefixes
devcietree: bindings: add some MFD Keymile FPGAs
powerpc/mpc85xx: add support for Keymile's kmcoge4 board
Wang Dongsheng (1):
fsl/pci: fix RC cannot detect PME message coming
harninder rai (1):
powerpc/mpc85xx: Add BSC9132 QDS Support
.../clock/{corenet-clock.txt => qoriq-clock.txt} | 10 +-
Documentation/devicetree/bindings/mfd/bfticu.txt | 25 ++
Documentation/devicetree/bindings/mfd/qriox.txt | 17 +
.../devicetree/bindings/powerpc/fsl/board.txt | 17 +
.../devicetree/bindings/powerpc/fsl/ccf.txt | 46 +++
.../devicetree/bindings/powerpc/fsl/cpus.txt | 11 +
.../devicetree/bindings/powerpc/fsl/pamu.txt | 10 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/powerpc/boot/dts/b4860emu.dts | 7 +-
arch/powerpc/boot/dts/bsc9132qds.dts | 35 ++
arch/powerpc/boot/dts/bsc9132qds.dtsi | 101 +++++
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 4 -
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 4 -
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 185 +++++++++
arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi | 66 ++++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 +
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 430 +++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t1042si-post.dtsi | 37 ++
arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi | 104 +++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +
arch/powerpc/boot/dts/kmcoge4.dts | 152 ++++++++
arch/powerpc/boot/dts/oca4080.dts | 118 ++++++
arch/powerpc/boot/dts/p1023rds.dts | 219 -----------
arch/powerpc/boot/dts/t1040qds.dts | 46 +++
arch/powerpc/boot/dts/t1042qds.dts | 46 +++
arch/powerpc/boot/dts/t104xqds.dtsi | 166 ++++++++
arch/powerpc/boot/dts/t4240emu.dts | 15 +-
arch/powerpc/configs/85xx/kmp204x_defconfig | 225 +++++++++++
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_defconfig | 1 -
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
arch/powerpc/kernel/epapr_paravirt.c | 19 +-
arch/powerpc/mm/tlb_nohash.c | 7 +-
arch/powerpc/platforms/85xx/Kconfig | 19 +-
arch/powerpc/platforms/85xx/Makefile | 3 +-
arch/powerpc/platforms/85xx/bsc913x_qds.c | 74 ++++
arch/powerpc/platforms/85xx/corenet_generic.c | 9 +-
.../platforms/85xx/{p1023_rds.c => p1023_rdb.c} | 36 +-
arch/powerpc/sysdev/fsl_pci.c | 3 +-
arch/powerpc/sysdev/fsl_rio.c | 10 +-
arch/powerpc/sysdev/fsl_rmu.c | 6 +-
arch/powerpc/sysdev/mpic.c | 8 +-
55 files changed, 2065 insertions(+), 290 deletions(-)
rename Documentation/devicetree/bindings/clock/{corenet-clock.txt => qoriq-clock.txt} (95%)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
create mode 100644 arch/powerpc/boot/dts/bsc9132qds.dts
create mode 100644 arch/powerpc/boot/dts/bsc9132qds.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/boot/dts/oca4080.dts
delete mode 100644 arch/powerpc/boot/dts/p1023rds.dts
create mode 100644 arch/powerpc/boot/dts/t1040qds.dts
create mode 100644 arch/powerpc/boot/dts/t1042qds.dts
create mode 100644 arch/powerpc/boot/dts/t104xqds.dtsi
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
create mode 100644 arch/powerpc/platforms/85xx/bsc913x_qds.c
rename arch/powerpc/platforms/85xx/{p1023_rds.c => p1023_rdb.c} (75%)
^ permalink raw reply
* PASEMI: Kernel 3.15.0-rc6 doesn't boot with a PA6T cpu
From: Christian Zigotzky @ 2014-05-23 21:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <52DF9AEF.30900@xenosoft.de>
Hi All,
My PA6T system doesn't boot since patch
9000c17dc0f9c910267d2661225c9d33a227b27e from 08/04/14 (powerpc/powernv:
Fix endian issues with sensor code One OPAL call and one device tree
property needed byte swapping).
Experimental protocol:
git checkout -f 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44; git clean -fdx
(from 02/04/14) -> Kernel boots
git checkout -f f1553174a207f68a4ec19d436003097e0a4dc405; git clean -fdx
(from 03/04/14) -> Kernel boots
git checkout -f d40326f4b9f9617cdfd30f83a2db57d47e9c5bac; git clean -fdx
(from 04/04/14) -> Kernel boots
git checkout -f 930b440cd8256f3861bdb0a59d26efaadac7941a; git clean -fdx
(from 05/04/14) -> doesn't boot (rtc error)
git checkout -f 2b3a8fd735f86ebeb2b9d061054003000c36b654; git clean -fdx
(from 06/04/14) -> doesn't boot (rtc error)
git checkout -f 26c12d93348f0bda0756aff83f4867d9ae58a5a6; git clean -fdx
(from 07/04/14) -> doesn't boot (rtc error)
git checkout -f a6c8aff022d4d06e4b41455ae9b2a5d3d503bf76; git clean -fdx
(from 08/04/14) -> Kernel boots
git checkout -f 035328c202d26a824b8632fd3b00635db5aee5a2; git clean -fdx
(from 08/04/14) -> Kernel boots
git checkout -f 9000c17dc0f9c910267d2661225c9d33a227b27e; git clean -fdx
(from 08/04/14) powerpc/powernv: Fix endian issues with sensor code
One OPAL call and one device tree property needed byte swapping. ->
doesn't boot (prom_init)
git checkout -f d3d35d957a9d0733dc51f14b5abc0bff5d3c5f3a; git clean -fdx
(from 08/04/14) -> doesn't boot (prom_init)
git checkout -f c4586256f0c440bc2bdb29d2cbb915f0ca785d26; git clean -fdx
(from 09/04/14) -> doesn't boot (prom_init)
And the RC 6 doesn't boot, either. Have you changed the ppc boot part of
the kernel? Kernel 3.14 and 3.13 boot without any problems.
Rgds,
Christian
^ permalink raw reply
* Re: powerpc: remove checks for CONFIG_BOOK3E_MMU_TLB_STATS
From: Paul Bolle @ 2014-05-23 21:35 UTC (permalink / raw)
To: Scott Wood; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1400865146.12823.54.camel@snotra.buserror.net>
On Fri, 2014-05-23 at 12:12 -0500, Scott Wood wrote:
> On Fri, 2014-05-23 at 12:06 +0200, Paul Bolle wrote:
> > For what it's worth: I can't reproduce this error with the cross
> > compiler now shipped with Fedora 20 (ie, powerpc64-linux-gnu-gcc (GCC)
> > 4.8.1 20130717 (Red Hat 4.8.1-5)). It shows a nice and clean
> > AS arch/powerpc/mm/tlb_low_64e.o
> >
> > in the output.
> >
> > That's v3.15-rc6, with just this patch, and using a .config generated,
> > with "make oldconfig", from arch/powerpc/configs/ppc64e_defconfig.
>
> Hmm, I tried applying again and it was fine.
That's a relieve. Thanks, again, for testing!
Paul Bolle
^ permalink raw reply
* Re: [PATCH v6 2/3] drivers/vfio: EEH support for VFIO PCI device
From: Gavin Shan @ 2014-05-24 1:37 UTC (permalink / raw)
To: Alex Williamson
Cc: aik@ozlabs.ru, Alexander Graf, kvm-ppc@vger.kernel.org,
Gavin Shan, qiudayu@linux.vnet.ibm.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1400856559.3289.460.camel@ul30vt.home>
On Fri, May 23, 2014 at 08:49:19AM -0600, Alex Williamson wrote:
>On Fri, 2014-05-23 at 14:30 +0200, Alexander Graf wrote:
>> On 23.05.14 13:58, Gavin Shan wrote:
>> > On Fri, May 23, 2014 at 08:52:23AM +0200, Alexander Graf wrote:
>> >>> Am 23.05.2014 um 05:23 schrieb Alex Williamson <alex.williamson@redhat.com>:
>> >>>> On Fri, 2014-05-23 at 10:37 +1000, Gavin Shan wrote:
>> >>>>> On Fri, May 23, 2014 at 10:17:30AM +1000, Gavin Shan wrote:
>> >>>>>> On Thu, May 22, 2014 at 11:55:29AM +0200, Alexander Graf wrote:
>> >>>>>> On 22.05.14 10:23, Gavin Shan wrote:
.../...
>
>If there's a reason to use something other than _IO+argsz+flags, we can
>discuss it, but this is not it.
>
If I just need a command, need I define a struct for the command, or I
should pass "NULL" for the 3rd parameter of ioctl() ?
struct foo {
uint32_t argsz;
uint32_t flags;
};
>> > Also, I need keep the return value from
>> > ioctl() less or equal to 0 ? :-)
>>
>> Usually return values are
>>
>> < 0 means error
>> == 0 means success
>> > 0 means return payload
>
>Agree, >0 only makes sense if the return value of the ioctl can be
>expressed as a positive int, ex. VFIO_EEH_ERROR_COUNT (if such a thing
>was needed). Thanks,
>
What if I have to return "0" ? For "0", I need have a field in the
data struct to carry it. For "> 0", to carry it with return value
from ioctl(). Why not make it unified to have additional field in
the data struct to carry the return values. In this case, ioctl()
just returns:
< 0: error
== 0: success, check return value from the data struct.
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH v6 2/3] drivers/vfio: EEH support for VFIO PCI device
From: Gavin Shan @ 2014-05-24 1:46 UTC (permalink / raw)
To: Alexander Graf
Cc: aik@ozlabs.ru, Gavin Shan, kvm-ppc@vger.kernel.org,
Alex Williamson, qiudayu@linux.vnet.ibm.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <537F43C9.1080503@suse.de>
On Fri, May 23, 2014 at 02:49:13PM +0200, Alexander Graf wrote:
.../...
>
>VFIO_EEH_RECOVER?
>
Then it should contain VFIO_EEH_PE_RESET, which is part of the
recovery. I don't expect the recovery to be done with one ioctl
command :-)
I personally prefer to keep VFIO_EEH_PE_CONFIUGRE, which means
the PE need configurtion/reconfiguration before error log retrieval
or after PE reset as defined in PAPR spec.
>So what if user space accesses config space while the device is
>broken? What if it accesses an mmap'ed BAR while the device is in
>broken state and BARs haven't been recovered yet?
>
If the "broken" means device can't funtion properly, any config,
IO, DMA traffic would cause "frozen" device (PE).
If the "broken" means "frozen" here. When the device is put into
frozen state, the config or IO access are dropped from hardware or
software level. So those requests can't reach to hardware under the
situation.
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH v6 2/3] drivers/vfio: EEH support for VFIO PCI device
From: Gavin Shan @ 2014-05-24 2:06 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, Gavin Shan, kvm-ppc, agraf, qiudayu, linuxppc-dev
In-Reply-To: <1400855399.3289.450.camel@ul30vt.home>
On Fri, May 23, 2014 at 08:29:59AM -0600, Alex Williamson wrote:
>On Fri, 2014-05-23 at 14:37 +1000, Gavin Shan wrote:
>> On Thu, May 22, 2014 at 09:10:53PM -0600, Alex Williamson wrote:
>> >On Thu, 2014-05-22 at 18:23 +1000, Gavin Shan wrote:
.../...
>No, sorry, I mean how does the user get information about the error?
>The interface we have here is:
>a) find that something bad has happened
>b) kick it into working again
>c) continue
>
>How does the user figure out what happened and if it makes sense to
>attempt to recover? Where does the user learn that their disk is on
>fire?
>
When 0xFF's returned from config or IO read, user should check the
device (PE)'s state with ioctl command VFIO_EEH_PE_GET_STATE. If the
device (PE) has been put into "frozen" state, It's confirmed the device
("disk" you mentioned) is on fire. User should kick off recovery, which
includes:
- User stops any operatins (config, IO, DMA) on the device because any
PCI traffic to "frozen" device will be dropped from software or hardware
level. Also, we don't expect DMA traffic during recovery. Otherwise,
we will bump into recursive errors and the recovery should fail.
- VFIO_EEH_PE_SET_OPTION to enable I/O path ("DMA" path is still under frozen
state). EEH_VFIO_PE_CONFIGURE to reconfigure affected PCI bridges and then
do error log retrieval.
- VFIO_EEH_PE_RESET to reset the affected device (PE). EEH_VFIO_PE_CONFIUGRE
to restore BARs.
- User resumes the device to start PCI traffic and device is brought to
funtional state.
.../...
>
>No, I prefer to stay consistent with the rest of the VFIO API and use
>argsz + flags.
>
Here's the recap for previous reply: I have several cases for ioctl().
- ioctl(fd, cmd, NULL): I needn't any input info.
- ioctl(fd, cmd, &data): I need input info
For all the cases, should I simply have a data struct to include "argsz+flags"?
For return value from ioctl(), can we simply to have additional field in the
above data struct to carry it? "0" is the information I have to return for
some of the cases.
.../...
>As agraf noted, I'm asking why reset and configure are separate when
>they seem to be used together.
>
Ok. It's the recap: they're 2 separate steps of error recovery as
defined in PAPR spec. Also, they correspond to 2 separate RTAS calls.
So I don't think we can put them together.
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH RFC v13 0/5] MPC512x DMA slave s/g support, OF DMA lookup
From: Alexander Popov @ 2014-05-24 7:33 UTC (permalink / raw)
To: Vinod Koul
Cc: devicetree, Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, Alexander Popov, dmaengine, Dan Williams,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20140522051023.GV21128@intel.com>
Thank you, Vinod
2014-05-22 9:10 GMT+04:00 Vinod Koul <vinod.koul@intel.com>:
> On Thu, May 15, 2014 at 06:15:30PM +0400, Alexander Popov wrote:
>> Changes in v13:
>> A new patch (part 1/5) is added to this series.
>> Part 2/5:
>> - fix style issue;
>> - improve comments;
>
> You need to cc DT- list for 3 to 5 patches. Need ack before we can apply.
In this v13 series parts 0/5, 3/5, 4/5 and 5/5 do have "Cc:
devicetree@vger.kernel.org".
> I suspect 4/5 should come first out of these 3.
Ok. I'll send v14 soon.
> Also in future pls use right subsystem name "dmaengine". Also why are these
> tagged as RFC still?
Ok, thanks.
Best regards,
Alexander
^ permalink raw reply
* [PATCH] pcmcia: m8xx: remove checks for four macros
From: Paul Bolle @ 2014-05-24 7:36 UTC (permalink / raw)
To: Vitaly Bordug, Marcelo Tosatti, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linux-pcmcia, linuxppc-dev, linux-kernel
This driver contains checks for four Kconfig macros. But the related
Kconfig symbols have never been part of the tree. Remove these checks
and the code they hide.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Untested.
This has been an issue ever since this driver was added in v2.6.15. Note
that there is no header named "*/cpld.h", so setting PRxK can't possibly
work.
drivers/pcmcia/m8xx_pcmcia.c | 75 --------------------------------------------
1 file changed, 75 deletions(-)
diff --git a/drivers/pcmcia/m8xx_pcmcia.c b/drivers/pcmcia/m8xx_pcmcia.c
index 182034d2ef58..53b71fe50767 100644
--- a/drivers/pcmcia/m8xx_pcmcia.c
+++ b/drivers/pcmcia/m8xx_pcmcia.c
@@ -78,24 +78,14 @@ MODULE_LICENSE("Dual MPL/GPL");
/* The FADS series are a mess */
#ifdef CONFIG_FADS
-#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821)
-#define CONFIG_PCMCIA_SLOT_A
-#else
#define CONFIG_PCMCIA_SLOT_B
#endif
-#endif
#if defined(CONFIG_MPC885ADS)
#define CONFIG_PCMCIA_SLOT_A
#define PCMCIA_GLITCHY_CD
#endif
-/* Cyclades ACS uses both slots */
-#ifdef CONFIG_PRxK
-#define CONFIG_PCMCIA_SLOT_A
-#define CONFIG_PCMCIA_SLOT_B
-#endif
-
#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)
@@ -340,71 +330,6 @@ static inline int voltage_set(int slot, int vcc, int vpp)
#endif
-#if defined(CONFIG_PRxK)
-#include <asm/cpld.h>
-extern volatile fpga_pc_regs *fpga_pc;
-
-#define PCMCIA_BOARD_MSG "MPC855T"
-
-static int voltage_set(int slot, int vcc, int vpp)
-{
- u8 reg = 0;
- u8 regread;
- cpld_regs *ccpld = get_cpld();
-
- switch (vcc) {
- case 0:
- break;
- case 33:
- reg |= PCMCIA_VCC_33;
- break;
- case 50:
- reg |= PCMCIA_VCC_50;
- break;
- default:
- return 1;
- }
-
- switch (vpp) {
- case 0:
- break;
- case 33:
- case 50:
- if (vcc == vpp)
- reg |= PCMCIA_VPP_VCC;
- else
- return 1;
- break;
- case 120:
- if ((vcc == 33) || (vcc == 50))
- reg |= PCMCIA_VPP_12;
- else
- return 1;
- default:
- return 1;
- }
-
- reg = reg >> (slot << 2);
- regread = in_8(&ccpld->fpga_pc_ctl);
- if (reg !=
- (regread & ((PCMCIA_VCC_MASK | PCMCIA_VPP_MASK) >> (slot << 2)))) {
- /* enable new powersettings */
- regread =
- regread & ~((PCMCIA_VCC_MASK | PCMCIA_VPP_MASK) >>
- (slot << 2));
- out_8(&ccpld->fpga_pc_ctl, reg | regread);
- msleep(100);
- }
-
- return 0;
-}
-
-#define socket_get(_slot_) PCMCIA_SOCKET_KEY_LV
-#define hardware_enable(_slot_) /* No hardware to enable */
-#define hardware_disable(_slot_) /* No hardware to disable */
-
-#endif /* CONFIG_PRxK */
-
static u32 pending_events[PCMCIA_SOCKETS_NO];
static DEFINE_SPINLOCK(pending_event_lock);
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] pcmcia: m8xx: remove checks for four macros
From: Paul Bolle @ 2014-05-24 7:41 UTC (permalink / raw)
To: Vitaly Bordug, Benjamin Herrenschmidt, Paul Mackerras
Cc: linux-pcmcia, linuxppc-dev, linux-kernel
In-Reply-To: <1400916970.31526.78.camel@x220>
The message to Marcelo's address bounced. Does that always happen?
Paul Bolle
^ permalink raw reply
* [PATCH 0/3] dmaengine: mpc512x: add device tree binding document and DMA channel lookup
From: Alexander Popov @ 2014-05-24 9:33 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
This patch series introduces a device tree binding document for
the MPC512x DMA controller and adds device tree based DMA channel lookup
for it.
Alexander Popov (3):
dmaengine: mpc512x: add device tree binding document
dmaengine: of: add common xlate function for matching by channel id
dmaengine: mpc512x: register for device tree channel lookup
.../devicetree/bindings/dma/mpc512x-dma.txt | 40 ++++++++++++++++++++++
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 ++++++-
drivers/dma/of-dma.c | 35 +++++++++++++++++++
include/linux/of_dma.h | 4 +++
5 files changed, 92 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
--
1.8.4.2
^ permalink raw reply
* [PATCH 1/3] dmaengine: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-05-24 9:33 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1400924009-23992-1-git-send-email-a13xp0p0v88@gmail.com>
Introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
.../devicetree/bindings/dma/mpc512x-dma.txt | 40 ++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 0000000..b1cbc3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,40 @@
+* Freescale MPC512x and MPC8308 DMA Controller
+
+The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
+blocks of memory contents between memory and peripherals or
+from memory to memory.
+
+Refer to "Generic DMA Controller and DMA request bindings" in
+the dma/dma.txt file for a more detailed description of binding.
+
+Required properties:
+- compatible: Should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma"
+- reg: Address and size of the DMA controller's register set
+- Interrupt for the DMA controller. Syntax of interrupt client node
+ is described in interrupt-controller/interrupts.txt
+
+Optional properties:
+- #dma-cells: The length of the DMA specifier, must be <1>.
+ Each channel of this DMA controller has a peripheral request line,
+ this assignment is fixed in hardware. The cell in dmas property
+ of a client device represents the channel number
+
+Example:
+
+ dma0: dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt
+
+Example:
+
+ sdhc@1500 {
+ compatible = "fsl,mpc5121-sdhc";
+ /* ... */
+ dmas = <&dma0 30>;
+ dma-names = "rx-tx";
+ };
--
1.8.4.2
^ permalink raw reply related
* [PATCH 2/3] dmaengine: of: add common xlate function for matching by channel id
From: Alexander Popov @ 2014-05-24 9:33 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1400924009-23992-1-git-send-email-a13xp0p0v88@gmail.com>
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter.
New function will use this pointer to match only channels which belong to the
specified DMA controller.
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
drivers/dma/of-dma.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/of_dma.h | 4 ++++
2 files changed, 39 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..d5fbeaa 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver which wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dma_device *dev = ofdma->of_dma_data;
+ struct dma_chan *chan, *candidate = NULL;
+
+ if (!dev || dma_spec->args_count != 1)
+ return NULL;
+
+ list_for_each_entry(chan, &dev->channels, device_node)
+ if (chan->chan_id == dma_spec->args[0]) {
+ candidate = chan;
+ break;
+ }
+
+ if (!candidate)
+ return NULL;
+
+ return dma_get_slave_channel(candidate);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..56bc026 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
return NULL;
}
+#define of_dma_xlate_by_chan_id NULL
+
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/3] dmaengine: mpc512x: register for device tree channel lookup
From: Alexander Popov @ 2014-05-24 9:33 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1400924009-23992-1-git-send-email-a13xp0p0v88@gmail.com>
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 2c0e155..7f9d14f 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -498,6 +498,7 @@
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+ #dma-cells = <1>;
};
};
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2ad4373..881db2b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -53,6 +53,7 @@
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
+#include <linux/of_dma.h>
#include <linux/of_platform.h>
#include <linux/random.h>
@@ -1036,7 +1037,15 @@ static int mpc_dma_probe(struct platform_device *op)
if (retval)
goto err_free2;
- return retval;
+ /* Register with OF helpers for DMA lookups (nonfatal) */
+ if (dev->of_node) {
+ retval = of_dma_controller_register(dev->of_node,
+ of_dma_xlate_by_chan_id, mdma);
+ if (retval)
+ dev_warn(dev, "Could not register for OF lookup\n");
+ }
+
+ return 0;
err_free2:
if (mdma->is_mpc8308)
@@ -1057,6 +1066,8 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = &op->dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
+ if (dev->of_node)
+ of_dma_controller_free(dev->of_node);
dma_async_device_unregister(&mdma->dma);
if (mdma->is_mpc8308) {
free_irq(mdma->irq2, mdma);
--
1.8.4.2
^ permalink raw reply related
* Section mismatch in reference from the variable via_pmu_driver
From: Christian Kujau @ 2014-05-25 0:35 UTC (permalink / raw)
To: linuxppc-dev, geert
Hi,
while compiling 3.15-rc6 for powerpc (gcc-4.8.1 crosscompiler on x86_64),
a warning popped up:
WARNING: modpost: Found 1 section mismatch(es).
Compiling with CONFIG_DEBUG_SECTION_MISMATCH=y gives:
-----------------------------------
LD drivers/macintosh/built-in.o
CC [M] fs/hfsplus/inode.o
WARNING: drivers/macintosh/built-in.o(.data+0x184): Section mismatch in
reference from the variable via_pmu_driver to the function
.init.text:pmu_init()
The variable via_pmu_driver references
the function __init pmu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
-----------------------------------
...and, later on:
-----------------------------------
LD drivers/built-in.o
WARNING: drivers/built-in.o(.data+0x488c): Section mismatch in reference
from the variable via_pmu_driver to the function .init.text:pmu_init()
The variable via_pmu_driver references
the function __init pmu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
LINK vmlinux
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.data+0x1ff44): Section mismatch in reference from the
variable via_pmu_driver to the function .init.text:pmu_init()
The variable via_pmu_driver references
the function __init pmu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
-----------------------------------
This had been reported [0] by Geert for v3.3-rc1 back in 2012, and maybe
the warning was always there, but I didn't notice it until now.
Oh, and after everything has been built, this happens:
-----------------------------------
INFO: Uncompressed kernel (size 0x6714a0) overlaps the address of the wrapper(0x400000)
INFO: Fixing the link_address of wrapper to (0x700000)
-----------------------------------
...but I think this was always printed after compiling a kernel for
PowerPC, I just just I should mention it (again [1]).
Thanks,
Christian.
[0] https://lkml.org/lkml/2012/1/22/17
[1] https://lkml.org/lkml/2012/4/4/140
--
BOFH excuse #30:
positron router malfunction
^ permalink raw reply
* fs/hfsplus/xattr.c: comparison of distinct pointer types lacks a cast
From: Christian Kujau @ 2014-05-25 1:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-fsdevel, geert
Hi,
while compiling 3.15-rc6 for powerpc (gcc-4.8.1 crosscompiling on x86_64),
this happens:
---------------------------------------------------------------
CC [M] fs/hfsplus/xattr_user.o
CC [M] fs/hfsplus/xattr_security.o
CC [M] fs/hfsplus/xattr.o
CC [M] fs/hfsplus/xattr_trusted.o
In file included from
/usr/local/src/linux-git/arch/powerpc/include/asm/div64.h:1:0,
from /usr/local/src/linux-git/include/linux/kernel.h:124,
from /usr/local/src/linux-git/include/asm-generic/bug.h:13,
from /usr/local/src/linux-git/arch/powerpc/include/asm/bug.h:127,
from /usr/local/src/linux-git/include/linux/bug.h:4,
from /usr/local/src/linux-git/include/linux/thread_info.h:11,
from /usr/local/src/linux-git/include/asm-generic/preempt.h:4,
from arch/powerpc/include/generated/asm/preempt.h:1,
from /usr/local/src/linux-git/include/linux/preempt.h:18,
from /usr/local/src/linux-git/include/linux/spinlock.h:50,
from /usr/local/src/linux-git/include/linux/wait.h:8,
from /usr/local/src/linux-git/include/linux/fs.h:6,
from /usr/local/src/linux-git/fs/hfsplus/hfsplus_fs.h:19,
from /usr/local/src/linux-git/fs/hfsplus/xattr.c:9:
/usr/local/src/linux-git/fs/hfsplus/xattr.c: In function
'hfsplus_init_header_node':
/usr/local/src/linux-git/include/asm-generic/div64.h:43:28: warning:
comparison of distinct pointer types lacks a cast [enabled by default]
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
/usr/local/src/linux-git/fs/hfsplus/xattr.c:86:2: note: in expansion of
macro 'do_div'
do_div(tmp, node_size);
^
LD [M] fs/hfsplus/hfsplus.o
---------------------------------------------------------------
I don't fully understand the issue here, but xattr.c:86 reads:
do_div(tmp, node_size);
Now, "git log -S do_div --source fs/hfsplus/xattr.c" brought up the
following commit from Geert, introducing do_div() to xattr.c
commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 HEAD
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu Nov 14 14:32:18 2013 -0800
hfsplus: Fix undefined __divdi3 in hfsplus_init_header_node()
Reverting this commit makes the warning above go away, but I doubt this
would be the correct solution here :-)
Note: the warning has been reported[0] by Geert for v3.13-rc7 back in
January 2014 already.
Thanks,
Christian.
[0] https://lkml.org/lkml/2014/1/6/107
--
BOFH excuse #133:
It's not plugged in.
^ permalink raw reply
* Re: fs/hfsplus/xattr.c: comparison of distinct pointer types lacks a cast
From: Geert Uytterhoeven @ 2014-05-25 8:48 UTC (permalink / raw)
To: Christian Kujau; +Cc: Linux FS Devel, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <alpine.DEB.2.19.4.1405241829250.7552@trent.utfs.org>
Hi Christian,
On Sun, May 25, 2014 at 3:42 AM, Christian Kujau <lists@nerdbynature.de> wrote:
> /usr/local/src/linux-git/include/asm-generic/div64.h:43:28: warning:
> comparison of distinct pointer types lacks a cast [enabled by default]
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ^
> /usr/local/src/linux-git/fs/hfsplus/xattr.c:86:2: note: in expansion of
> macro 'do_div'
> do_div(tmp, node_size);
> ^
> LD [M] fs/hfsplus/hfsplus.o
>
> ---------------------------------------------------------------
>
> I don't fully understand the issue here, but xattr.c:86 reads:
>
> do_div(tmp, node_size);
"tmp" is "loff_t" which is "__kernel_loff_t", which is "long long", i.e. signed,
while include/asm-generic/div64.h compares its type with "uint64_t".
As inode sizes are positive, it should be safe to change the type of "tmp"
to "u64". Does that make the warning go away?
> Now, "git log -S do_div --source fs/hfsplus/xattr.c" brought up the
> following commit from Geert, introducing do_div() to xattr.c
>
> commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 HEAD
> Author: Geert Uytterhoeven <geert@linux-m68k.org>
> Date: Thu Nov 14 14:32:18 2013 -0800
> hfsplus: Fix undefined __divdi3 in hfsplus_init_header_node()
>
> Reverting this commit makes the warning above go away, but I doubt this
> would be the correct solution here :-)
Indeed ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: fs/hfsplus/xattr.c: comparison of distinct pointer types lacks a cast
From: Christian Kujau @ 2014-05-25 19:07 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux FS Devel, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAMuHMdWSd=nLiG_QacqnePbvQ=QBv8dRakDGL6LQ+6tEGP1qEQ@mail.gmail.com>
On Sun, 25 May 2014 at 10:48, Geert Uytterhoeven wrote:
> "tmp" is "loff_t" which is "__kernel_loff_t", which is "long long", i.e. signed,
> while include/asm-generic/div64.h compares its type with "uint64_t".
Thanks for the explanation!
> As inode sizes are positive, it should be safe to change the type of "tmp"
> to "u64". Does that make the warning go away?
Yes, this helped! Compile-tested only:
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
Fixed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 introduced do_div() to
xattr.c and the warning below too.
As Geert remarked: "tmp" is "loff_t" which is "__kernel_loff_t", which
is "long long", i.e. signed, while include/asm-generic/div64.h compares
its type with "uint64_t". As inode sizes are positive, it should be safe
to change the type of "tmp" to "u64".
==============================
CC [M] fs/hfsplus/xattr_user.o
CC [M] fs/hfsplus/xattr_security.o
CC [M] fs/hfsplus/xattr.o
CC [M] fs/hfsplus/xattr_trusted.o
In file included from
arch/powerpc/include/asm/div64.h:1:0,
from include/linux/kernel.h:124,
from include/asm-generic/bug.h:13,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from include/asm-generic/preempt.h:4,
from arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:18,
from include/linux/spinlock.h:50,
from include/linux/wait.h:8,
from include/linux/fs.h:6,
from fs/hfsplus/hfsplus_fs.h:19,
from fs/hfsplus/xattr.c:9:
fs/hfsplus/xattr.c: In function
'hfsplus_init_header_node':
include/asm-generic/div64.h:43:28: warning:
comparison of distinct pointer types lacks a cast [enabled by default]
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
fs/hfsplus/xattr.c:86:2: note: in expansion of
macro 'do_div'
do_div(tmp, node_size);
^
LD [M] fs/hfsplus/hfsplus.o
==============================
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index 4e27edc..cd9ed4c 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -66,7 +66,7 @@ static void hfsplus_init_header_node(struct inode *attr_file,
char *bmp;
u32 used_nodes;
u32 used_bmp_bytes;
- loff_t tmp;
+ u64 tmp;
hfs_dbg(ATTR_MOD, "init_hdr_attr_file: clump %u, node_size %u\n",
clump_size, node_size);
Thanks,
Christian.
--
BOFH excuse #388:
Bad user karma.
^ permalink raw reply related
* Re: fs/hfsplus/xattr.c: comparison of distinct pointer types lacks a cast
From: Sergei Antonov @ 2014-05-25 21:19 UTC (permalink / raw)
To: Christian Kujau
Cc: Linux FS Devel, linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven
In-Reply-To: <alpine.DEB.2.19.4.1405251156110.7552@trent.utfs.org>
On 25 May 2014 21:07, Christian Kujau <lists@nerdbynature.de> wrote:
> On Sun, 25 May 2014 at 10:48, Geert Uytterhoeven wrote:
>> "tmp" is "loff_t" which is "__kernel_loff_t", which is "long long", i.e. signed,
>> while include/asm-generic/div64.h compares its type with "uint64_t".
>
> Thanks for the explanation!
>
>> As inode sizes are positive, it should be safe to change the type of "tmp"
>> to "u64". Does that make the warning go away?
>
> Yes, this helped! Compile-tested only:
>
> Signed-off-by: Christian Kujau <lists@nerdbynature.de>
> Fixed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 introduced do_div() to
> xattr.c and the warning below too.
>
> As Geert remarked: "tmp" is "loff_t" which is "__kernel_loff_t", which
> is "long long", i.e. signed, while include/asm-generic/div64.h compares
> its type with "uint64_t". As inode sizes are positive, it should be safe
> to change the type of "tmp" to "u64".
>
> ==============================
> CC [M] fs/hfsplus/xattr_user.o
> CC [M] fs/hfsplus/xattr_security.o
> CC [M] fs/hfsplus/xattr.o
> CC [M] fs/hfsplus/xattr_trusted.o
> In file included from
> arch/powerpc/include/asm/div64.h:1:0,
> from include/linux/kernel.h:124,
> from include/asm-generic/bug.h:13,
> from arch/powerpc/include/asm/bug.h:127,
> from include/linux/bug.h:4,
> from include/linux/thread_info.h:11,
> from include/asm-generic/preempt.h:4,
> from arch/powerpc/include/generated/asm/preempt.h:1,
> from include/linux/preempt.h:18,
> from include/linux/spinlock.h:50,
> from include/linux/wait.h:8,
> from include/linux/fs.h:6,
> from fs/hfsplus/hfsplus_fs.h:19,
> from fs/hfsplus/xattr.c:9:
> fs/hfsplus/xattr.c: In function
> 'hfsplus_init_header_node':
> include/asm-generic/div64.h:43:28: warning:
> comparison of distinct pointer types lacks a cast [enabled by default]
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ^
> fs/hfsplus/xattr.c:86:2: note: in expansion of
> macro 'do_div'
> do_div(tmp, node_size);
> ^
> LD [M] fs/hfsplus/hfsplus.o
> ==============================
>
>
> diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
> index 4e27edc..cd9ed4c 100644
> --- a/fs/hfsplus/xattr.c
> +++ b/fs/hfsplus/xattr.c
> @@ -66,7 +66,7 @@ static void hfsplus_init_header_node(struct inode *attr_file,
> char *bmp;
> u32 used_nodes;
> u32 used_bmp_bytes;
> - loff_t tmp;
> + u64 tmp;
>
> hfs_dbg(ATTR_MOD, "init_hdr_attr_file: clump %u, node_size %u\n",
> clump_size, node_size);
Acked-by: Sergei Antonov <saproj@gmail.com>
This patch also needs a name, for example "hfsplus: remove compiler
warning on PowerPC".
You may need to send it to Andrew Morton <akpm@linux-foundation.org>
to include in linux-next.
^ permalink raw reply
* [PATCH] hfsplus: fix compiler warning on PowerPC
From: Christian Kujau @ 2014-05-25 21:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Sergei Antonov, Geert Uytterhoeven
Hi Andrew,
Sergei suggested to send this your way, so that it can be included into
linux-next:
Commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 ("hfsplus: Fix
undefined __divdi3 in hfsplus_init_header_node()") introduced do_div() to
xattr.c and the warning below too.
As Geert remarked: "tmp" is "loff_t" which is "__kernel_loff_t", which
is "long long", i.e. signed, while include/asm-generic/div64.h compares
its type with "uint64_t". As inode sizes are positive, it should be safe
to change the type of "tmp" to "u64".
==============================
CC [M] fs/hfsplus/xattr_user.o
CC [M] fs/hfsplus/xattr_security.o
CC [M] fs/hfsplus/xattr.o
CC [M] fs/hfsplus/xattr_trusted.o
In file included from
arch/powerpc/include/asm/div64.h:1:0,
from include/linux/kernel.h:124,
from include/asm-generic/bug.h:13,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from include/asm-generic/preempt.h:4,
from arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:18,
from include/linux/spinlock.h:50,
from include/linux/wait.h:8,
from include/linux/fs.h:6,
from fs/hfsplus/hfsplus_fs.h:19,
from fs/hfsplus/xattr.c:9:
fs/hfsplus/xattr.c: In function
'hfsplus_init_header_node':
include/asm-generic/div64.h:43:28: warning:
comparison of distinct pointer types lacks a cast [enabled by default]
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
fs/hfsplus/xattr.c:86:2: note: in expansion of
macro 'do_div'
do_div(tmp, node_size);
^
LD [M] fs/hfsplus/hfsplus.o
==============================
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
Fixed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Sergei Antonov <saproj@gmail.com>
---
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index 4e27edc..cd9ed4c 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -66,7 +66,7 @@ static void hfsplus_init_header_node(struct inode *attr_file,
char *bmp;
u32 used_nodes;
u32 used_bmp_bytes;
- loff_t tmp;
+ u64 tmp;
hfs_dbg(ATTR_MOD, "init_hdr_attr_file: clump %u, node_size %u\n",
clump_size, node_size);
Thanks,
Christian.
--
BOFH excuse #388:
Bad user karma.
^ permalink raw reply related
* Re: [PATCH] hfsplus: fix compiler warning on PowerPC
From: Sergei Antonov @ 2014-05-26 1:45 UTC (permalink / raw)
To: Christian Kujau
Cc: linuxppc-dev, Andrew Morton, Geert Uytterhoeven, Sergei Antonov
In-Reply-To: <alpine.DEB.2.19.4.1405251425270.7552@trent.utfs.org>
The patch did not pass scripts/checkpatch.pl
The fixed version is below.
---
Subject: [PATCH] hfsplus: fix compiler warning on PowerPC
Commit a99b7069aab8fc3fb4f26d15795dc280b52e38b1 ("hfsplus: Fix
undefined __divdi3 in hfsplus_init_header_node()") introduced do_div() to
xattr.c and the warning below too.
As Geert remarked: "tmp" is "loff_t" which is "__kernel_loff_t", which
is "long long", i.e. signed, while include/asm-generic/div64.h compares
its type with "uint64_t". As inode sizes are positive, it should be safe
to change the type of "tmp" to "u64".
==============================
CC [M] fs/hfsplus/xattr_user.o
CC [M] fs/hfsplus/xattr_security.o
CC [M] fs/hfsplus/xattr.o
CC [M] fs/hfsplus/xattr_trusted.o
In file included from
arch/powerpc/include/asm/div64.h:1:0,
from include/linux/kernel.h:124,
from include/asm-generic/bug.h:13,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from include/asm-generic/preempt.h:4,
from arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:18,
from include/linux/spinlock.h:50,
from include/linux/wait.h:8,
from include/linux/fs.h:6,
from fs/hfsplus/hfsplus_fs.h:19,
from fs/hfsplus/xattr.c:9:
fs/hfsplus/xattr.c: In function
'hfsplus_init_header_node':
include/asm-generic/div64.h:43:28: warning:
comparison of distinct pointer types lacks a cast [enabled by default]
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
fs/hfsplus/xattr.c:86:2: note: in expansion of
macro 'do_div'
do_div(tmp, node_size);
^
LD [M] fs/hfsplus/hfsplus.o
==============================
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Sergei Antonov <saproj@gmail.com>
---
fs/hfsplus/xattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index aab093c..820e83b 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -67,7 +67,7 @@ static void hfsplus_init_header_node(struct inode *attr_file,
char *bmp;
u32 used_nodes;
u32 used_bmp_bytes;
- loff_t tmp;
+ u64 tmp;
hfs_dbg(ATTR_MOD, "init_hdr_attr_file: clump %u, node_size %u\n",
clump_size, node_size);
--
1.9.0
^ permalink raw reply related
* RE: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support
From: Shengzhou.Liu @ 2014-05-26 3:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1400864771.12823.51.camel@snotra.buserror.net>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMjQsIDIwMTQgMTowNiBBTQ0KPiBUbzogTGl1IFNoZW5n
emhvdS1CMzY2ODUNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbMi8yXSBwb3dlcnBjL2NvcmVuZXQ2NF9zbXBfZGVmY29uZmlnOiBlbmFibGUgUlRD
IHN1cHBvcnQNCj4gDQo+IE9uIEZyaSwgMjAxNC0wNS0yMyBhdCAwMzowMyAtMDUwMCwgTGl1IFNo
ZW5nemhvdS1CMzY2ODUgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6IEZyaWRheSwgTWF5IDIz
LCAyMDE0IDY6NTIgQU0NCj4gPiA+IFRvOiBMaXUgU2hlbmd6aG91LUIzNjY4NQ0KPiA+ID4gQ2M6
IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogWzIvMl0g
cG93ZXJwYy9jb3JlbmV0NjRfc21wX2RlZmNvbmZpZzogZW5hYmxlIFJUQw0KPiA+ID4gc3VwcG9y
dA0KPiA+ID4NCj4gPiA+ID4gKysrIGIvYXJjaC9wb3dlcnBjL2NvbmZpZ3MvY29yZW5ldDY0X3Nt
cF9kZWZjb25maWcNCj4gPiA+ID4gQEAgLTEyNSw2ICsxMjUsMTEgQEAgQ09ORklHX1VTQl9FSENJ
X0ZTTD15ICBDT05GSUdfVVNCX1NUT1JBR0U9eQ0KPiA+ID4gPiBDT05GSUdfTU1DPXkgIENPTkZJ
R19NTUNfU0RIQ0k9eQ0KPiA+ID4gPiArQ09ORklHX1JUQ19DTEFTUz15DQo+ID4gPiA+ICtDT05G
SUdfUlRDX0RSVl9DTU9TPXkNCj4gPiA+ID4gK0NPTkZJR19SVENfRFJWX0RTMTMwNz15DQo+ID4g
PiA+ICtDT05GSUdfUlRDX0RSVl9EUzEzNzQ9eQ0KPiA+ID4gPiArQ09ORklHX1JUQ19EUlZfRFMz
MjMyPXkNCj4gPiA+ID4gIENPTkZJR19FREFDPXkNCj4gPiA+ID4gIENPTkZJR19FREFDX01NX0VE
QUM9eQ0KPiA+ID4gPiAgQ09ORklHX0RNQURFVklDRVM9eQ0KPiA+ID4NCj4gPiA+IFdoeSBvbmx5
IGNvcmVuZXQ2NCBhbmQgbm90IGNvcmVuZXQzMj8NCj4gPiA+DQo+ID4gPiAtU2NvdHQNCj4gPiBb
U2hlbmd6aG91XSBUaGVyZSBpcyBhbHJlYWR5IFJUQyBzdXBwb3J0IGluIGNvcmVuZXQzMiwgb25s
eSBtaXNzaW5nIGluDQo+IGNvcmVuZXQ2NC4NCj4gDQo+IE9ubHkgRFMzMjMyLCBub3QgRFMxMzA3
IG9yIERTMTM3NC4gIFdoaWNoIGJvYXJkcyB1c2UgdGhlIGxhdHRlciB0d28/DQo+IA0KPiBXaHkg
ZG8gd2UgbmVlZCBDT05GSUdfUlRDX0RSVl9DTU9TPw0KPiANCj4gLVNjb3R0DQo+IA0KW1NoZW5n
emhvdV0gc28gZmFyIERTMTMwNyBhbmQgRFMxMzc0IG9jY3VyIG9ubHkgb24gdGhvc2UgYm9hcmRz
IHdpdGggY29yZW5ldDY0LiANCkNPTkZJR19SVENfRFJWX0NNT1MgaXMgZW5hYmxlZCBpbiBtcGM4
NXh4X2RlZmNvbmZpZywgbXBjODV4eF9zbXBfZGVmY29uZmlnLCBjb3JlbmV0MzJfc21wX2RlZmNv
bmZpZywgZXRjLCBoZXJlIGtlZXBzIGNvbnNpc3RlbnQgaW4gY29yZW5ldDY0Lg0KSXQgc2VlbXMg
Q09ORklHX1JUQ19EUlZfQ01PUyBpcyBub3QgbmVlZGVkIG9uIDg1eHggcGxhdGZvcm0sIGRvIHdl
IG5lZWQgdG8gcmVtb3ZlIENPTkZJR19SVENfRFJWX0NNT1MgZnJvbSBhbGwgODV4eC9jb3JlbmV0
IGRlZmNvbmZpZz8gSWYgc28sIEkgd2lsbCBwb3N0IGEgbmV3IHBhdGNoIHRvIGRvIGl0Lg0KDQoN
Cg0K
^ permalink raw reply
* Re: [PATCH v2] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
From: Neelesh Gupta @ 2014-05-26 6:22 UTC (permalink / raw)
To: linuxppc-dev, linux, jdelvare, lm-sensors; +Cc: sbhat
In-Reply-To: <20140519141931.9248.11356.stgit@neelegup-tp-t420.in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 15027 bytes --]
Any updates on the patch.
- Neelesh
On 05/19/2014 07:56 PM, Neelesh Gupta wrote:
> This patch adds basic kernel enablement for reading power values, fan
> speed rpm and temperature values on powernv platforms which will
> be exported to user space through sysfs interface.
>
> Test results:
> -------------
> [root@tul163p1 ~]# sensors
> ibmpowernv-isa-0000
> Adapter: ISA adapter
> fan1: 5487 RPM (min = 0 RPM)
> fan2: 5152 RPM (min = 0 RPM)
> fan3: 5590 RPM (min = 0 RPM)
> fan4: 4963 RPM (min = 0 RPM)
> fan5: 0 RPM (min = 0 RPM)
> fan6: 0 RPM (min = 0 RPM)
> fan7: 7488 RPM (min = 0 RPM)
> fan8: 7944 RPM (min = 0 RPM)
> temp1: +39.0°C (high = +0.0°C)
> power1: 192.00 W
>
> [root@tul163p1 ~]# ls /sys/devices/platform/
> alarmtimer ibmpowernv.0 rtc-generic serial8250 uevent
> [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/
> driver/ hwmon/ modalias subsystem/ uevent
> [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/
> device fan2_min fan4_min fan6_min fan8_min power1_input
> fan1_fault fan3_fault fan5_fault fan7_fault in1_fault subsystem
> fan1_input fan3_input fan5_input fan7_input in2_fault temp1_input
> fan1_min fan3_min fan5_min fan7_min in3_fault temp1_max
> fan2_fault fan4_fault fan6_fault fan8_fault in4_fault uevent
> fan2_input fan4_input fan6_input fan8_input name
> [root@tul163p1 ~]#
> [root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/
> device fan2_min fan4_min fan6_min fan8_min power1_input
> fan1_fault fan3_fault fan5_fault fan7_fault in1_fault subsystem
> fan1_input fan3_input fan5_input fan7_input in2_fault temp1_input
> fan1_min fan3_min fan5_min fan7_min in3_fault temp1_max
> fan2_fault fan4_fault fan6_fault fan8_fault in4_fault uevent
> fan2_input fan4_input fan6_input fan8_input name
> [root@tul163p1 ~]#
>
> Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
> ---
>
> Changes in v2
> =============
> - Generic use of devm_* functions in hwmon like using devm_kzalloc() for dynamic
> memory request, avoiding the need to explicit free of memory.
> Adding 'struct attribute_group' as member of platform data structure to be
> populated and then passed to devm_hwmon_device_register_with_groups().
>
> Note: Having an array of pointers of 'attribute_group' and each group
> corresponds to 'enum sensors' type. Not completely sure, if it's ideal or
> could have just one group populated with attributes of sensor types?
>
> - 'ibmpowernv' is not hot-pluggable device so moving 'platform_driver' callback
> function (probe) as part of __init code.
> - Fixed issues related to coding style.
> - Other general comments in v1.
>
> drivers/hwmon/Kconfig | 8 +
> drivers/hwmon/Makefile | 1
> drivers/hwmon/ibmpowernv.c | 368 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 377 insertions(+)
> create mode 100644 drivers/hwmon/ibmpowernv.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index bc196f4..3e308fa 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -554,6 +554,14 @@ config SENSORS_IBMPEX
> This driver can also be built as a module. If so, the module
> will be called ibmpex.
>
> +config SENSORS_IBMPOWERNV
> + tristate "IBM POWERNV platform sensors"
> + depends on PPC_POWERNV
> + default y
> + help
> + If you say yes here you get support for the temperature/fan/power
> + sensors on your platform.
> +
> config SENSORS_IIO_HWMON
> tristate "Hwmon driver that uses channels specified via iio maps"
> depends on IIO
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index c48f987..199c401 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
> obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
> obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
> obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
> +obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
> obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
> obj-$(CONFIG_SENSORS_INA209) += ina209.o
> obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> new file mode 100644
> index 0000000..afce620
> --- /dev/null
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -0,0 +1,368 @@
> +/*
> + * IBM PowerNV platform sensors for temperature/fan/power
> + * Copyright (C) 2014 IBM
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +
> +#include <linux/platform_device.h>
> +#include <asm/opal.h>
> +#include <linux/err.h>
> +
> +#define DRVNAME "ibmpowernv"
> +#define MAX_ATTR_LEN 32
> +
> +/* Sensor suffix name from DT */
> +#define DT_FAULT_ATTR_SUFFIX "faulted"
> +#define DT_DATA_ATTR_SUFFIX "data"
> +#define DT_THRESHOLD_ATTR_SUFFIX "thrs"
> +
> +/*
> + * Enumerates all the types of sensors in the POWERNV platform and does index
> + * into 'struct sensor_group'
> + */
> +enum sensors {
> + FAN,
> + AMBIENT_TEMP,
> + POWER_SUPPLY,
> + POWER_INPUT,
> + MAX_SENSOR_TYPE,
> +};
> +
> +static struct sensor_group {
> + const char *name;
> + const char *compatible;
> + struct attribute_group group;
> + u32 attr_count;
> +} sensor_groups[] = {
> + {"fan", "ibm,opal-sensor-cooling-fan", {0}, 0},
> + {"temp", "ibm,opal-sensor-amb-temp", {0}, 0},
> + {"in", "ibm,opal-sensor-power-supply", {0}, 0},
> + {"power", "ibm,opal-sensor-power", {0}, 0}
> +};
> +
> +struct sensor_data {
> + u32 id; /* An opaque id of the firmware for each sensor */
> + enum sensors type;
> + char name[MAX_ATTR_LEN];
> + struct device_attribute dev_attr;
> +};
> +
> +struct platform_data {
> + const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
> + u32 sensors_count; /* Total count of sensors from each group */
> +};
> +
> +/* Platform device representing all the ibmpowernv sensors */
> +static struct platform_device *pdevice;
> +
> +static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
> + char *buf)
> +{
> + struct sensor_data *sdata = container_of(devattr, struct sensor_data,
> + dev_attr);
> + ssize_t ret;
> + u32 x;
> +
> + ret = opal_get_sensor_data(sdata->id, &x);
> + if (ret) {
> + pr_err("%s: Failed to get opal sensor data\n", __func__);
> + return ret;
> + }
> +
> + /* Convert temperature to milli-degrees */
> + if (sdata->type == AMBIENT_TEMP)
> + x *= 1000;
> + /* Convert power to micro-watts */
> + else if (sdata->type == POWER_INPUT)
> + x *= 1000000;
> +
> + return sprintf(buf, "%d\n", x);
> +}
> +
> +static void __init get_sensor_index_attr(const char *name, u32 *index, char *attr)
> +{
> + char *hash_pos = strchr(name, '#');
> + char *dash_pos;
> + u32 copy_len;
> + char buf[8];
> +
> + memset(buf, 0, sizeof(buf));
> + *index = 0;
> + *attr = '\0';
> +
> + if (hash_pos) {
> + dash_pos = strchr(hash_pos, '-');
> + if (dash_pos) {
> + copy_len = dash_pos - hash_pos - 1;
> + if (copy_len < sizeof(buf)) {
> + strncpy(buf, hash_pos + 1, copy_len);
> + sscanf(buf, "%d", index);
> + }
> +
> + strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
> + }
> + }
> +}
> +
> +/*
> + * This function translates the DT node name into the 'hwmon' attribute name.
> + * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
> + * which need to be mapped as fan2_input, temp1_max respectively before
> + * populating them inside hwmon device class..
> + */
> +static int __init create_hwmon_attr_name(enum sensors type, const char *node_name,
> + char *hwmon_attr_name)
> +{
> + char attr_suffix[MAX_ATTR_LEN];
> + char *attr_name;
> + u32 index;
> +
> + get_sensor_index_attr(node_name, &index, attr_suffix);
> + if (!index || !strlen(attr_suffix)) {
> + pr_info("%s: Sensor device node name is invalid, name: %s\n",
> + __func__, node_name);
> + return -EINVAL;
> + }
> +
> + if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX))
> + attr_name = "fault";
> + else if(!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX))
> + attr_name = "input";
> + else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
> + if (type == AMBIENT_TEMP)
> + attr_name = "max";
> + else if (type == FAN)
> + attr_name = "min";
> + else
> + return -ENOENT;
> + } else
> + return -ENOENT;
> +
> + snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
> + sensor_groups[type].name, index, attr_name);
> + return 0;
> +}
> +
> +static int __init populate_attr_groups(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + const struct attribute_group **pgroups = pdata->attr_groups;
> + struct device_node *opal, *np;
> + enum sensors type;
> + int err = 0;
> +
> + opal = of_find_node_by_path("/ibm,opal/sensors");
> + if (!opal) {
> + pr_err("%s: Opal 'sensors' node not found\n", __func__);
> + return -ENODEV;
> + }
> +
> + for_each_child_of_node(opal, np) {
> + if (np->name == NULL)
> + continue;
> +
> + for (type = 0; type < MAX_SENSOR_TYPE; type++)
> + if (of_device_is_compatible(np,
> + sensor_groups[type].compatible)) {
> + sensor_groups[type].attr_count++;
> + break;
> + }
> + }
> +
> + for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> + if (!sensor_groups[type].attr_count)
> + continue;
> +
> + sensor_groups[type].group.attrs = devm_kzalloc(&pdev->dev,
> + sizeof(struct attribute*) *
> + (sensor_groups[type].attr_count + 1),
> + GFP_KERNEL);
> + if (!sensor_groups[type].group.attrs) {
> + pr_err("%s: Failed to allocate memory for attribute"
> + "array\n", __func__);
> + err = -ENOMEM;
> + goto exit_put_node;
> + }
> +
> + pgroups[type] = &sensor_groups[type].group;
> + pdata->sensors_count += sensor_groups[type].attr_count;
> + sensor_groups[type].attr_count = 0;
> + }
> +
> +exit_put_node:
> + of_node_put(opal);
> + return err;
> +}
> +
> +/*
> + * Iterate through the device tree for each child of sensor node, create
> + * a sysfs attribute file, the file is named by translating the DT node name
> + * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
> + * etc..
> + */
> +static int __init create_device_attrs(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + const struct attribute_group **pgroups = pdata->attr_groups;
> + struct device_node *opal, *np;
> + struct sensor_data *sdata;
> + const u32 *sensor_id;
> + enum sensors type;
> + u32 count = 0;
> + int err = 0;
> +
> + opal = of_find_node_by_path("/ibm,opal/sensors");
> + if (!opal) {
> + pr_err("%s: Opal 'sensors' node not found\n", __func__);
> + return -ENODEV;
> + }
> +
> + sdata = devm_kzalloc(&pdev->dev, (pdata->sensors_count) *
> + sizeof(*sdata), GFP_KERNEL);
> + if (!sdata) {
> + pr_err("%s: Failed to allocate memory for the sensor_data",
> + __func__);
> + err = -ENOMEM;
> + goto exit_put_node;
> + }
> +
> + for_each_child_of_node(opal, np) {
> + if (np->name == NULL)
> + continue;
> +
> + for (type = 0; type < MAX_SENSOR_TYPE; type++)
> + if (of_device_is_compatible(np,
> + sensor_groups[type].compatible))
> + break;
> +
> + if (type == MAX_SENSOR_TYPE)
> + continue;
> +
> + sensor_id = of_get_property(np, "sensor-id", NULL);
> + if (!sensor_id) {
> + pr_info("%s: %s doesn't have sensor-id\n", __func__,
> + np->name);
> + continue;
> + }
> +
> + sdata[count].id = *sensor_id;
> + sdata[count].type = type;
> + err = create_hwmon_attr_name(type, np->name, sdata[count].name);
> + if (err)
> + goto exit_put_node;
> +
> + sysfs_attr_init(&sdata[count].dev_attr.attr);
> + sdata[count].dev_attr.attr.name = sdata[count].name;
> + sdata[count].dev_attr.attr.mode = S_IRUGO;
> + sdata[count].dev_attr.show = show_sensor;
> +
> + pgroups[type]->attrs[sensor_groups[type].attr_count++] =
> + &sdata[count++].dev_attr.attr;
> + }
> +
> +exit_put_node:
> + of_node_put(opal);
> + return err;
> +}
> +
> +static int __init ibmpowernv_probe(struct platform_device *pdev)
> +{
> + struct platform_data *pdata;
> + struct device *hwmon_dev;
> + int err;
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, pdata);
> + pdata->sensors_count = 0;
> + err = populate_attr_groups(pdev);
> + if (err)
> + return err;
> +
> + /* Create sysfs attribute file for each sensor found in the DT */
> + err = create_device_attrs(pdev);
> + if (err)
> + return err;
> +
> + /* Finally, register with hwmon */
> + hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
> + pdata,
> + pdata->attr_groups);
> +
> + return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +static struct platform_driver ibmpowernv_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = DRVNAME,
> + },
> +};
> +
> +static int __init ibmpowernv_init(void)
> +{
> + int err;
> +
> + pdevice = platform_device_alloc(DRVNAME, 0);
> + if (!pdevice) {
> + pr_err("%s: Device allocation failed\n", __func__);
> + err = -ENOMEM;
> + goto exit;
> + }
> +
> + err = platform_device_add(pdevice);
> + if (err) {
> + pr_err("%s: Device addition failed (%d)\n", __func__, err);
> + goto exit_device_put;
> + }
> +
> + err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
> + if (err) {
> + pr_err("%s: Platfrom driver probe failed\n", __func__);
> + goto exit_device_del;
> + }
> +
> + return 0;
> +
> +exit_device_del:
> + platform_device_del(pdevice);
> +exit_device_put:
> + platform_device_put(pdevice);
> +exit:
> + return err;
> +}
> +
> +static void __exit ibmpowernv_exit(void)
> +{
> + platform_driver_unregister(&ibmpowernv_driver);
> + platform_device_unregister(pdevice);
> +}
> +
> +MODULE_AUTHOR("Neelesh Gupta <neelegup@linux.vnet.ibm.com>");
> +MODULE_DESCRIPTION("IBM POWERNV platform sensors");
> +MODULE_LICENSE("GPL");
> +
> +module_init(ibmpowernv_init);
> +module_exit(ibmpowernv_exit);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 15010 bytes --]
^ permalink raw reply
* [PATCH] xmon: Fix up xmon format strings
From: Michael Ellerman @ 2014-05-26 11:02 UTC (permalink / raw)
To: linuxppc-dev
There are a couple of places where xmon is using %x to print values that
are unsigned long.
I found this out the hard way recently:
0:mon> p c000000000d0e7c8 c00000033dc90000 00000000a0000089 c000000000000000
return value is 0x96300500
Which is calling find_linux_pte_or_hugepte(), the result should be a
kernel pointer. After decoding the page tables by hand I discovered the
correct value was c000000396300500.
So fix up that case and a few others.
We also use a mix of 0x%x, %x and %u to print cpu numbers. So
standardise on 0x%x.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/xmon/xmon.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 08504e7..3fd1d9a 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -419,7 +419,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
get_output_lock();
excprint(regs);
if (bp) {
- printf("cpu 0x%x stopped at breakpoint 0x%x (",
+ printf("cpu 0x%x stopped at breakpoint 0x%lx (",
cpu, BP_NUM(bp));
xmon_print_symbol(regs->nip, " ", ")\n");
}
@@ -513,7 +513,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
excprint(regs);
bp = at_breakpoint(regs->nip);
if (bp) {
- printf("Stopped at breakpoint %x (", BP_NUM(bp));
+ printf("Stopped at breakpoint %lx (", BP_NUM(bp));
xmon_print_symbol(regs->nip, " ", ")\n");
}
if (unrecoverable_excp(regs))
@@ -997,14 +997,14 @@ static int cpu_cmd(void)
last_cpu = cpu;
} else {
if (last_cpu != first_cpu)
- printf("-%lx", last_cpu);
+ printf("-0x%lx", last_cpu);
last_cpu = first_cpu = cpu;
- printf(" %lx", cpu);
+ printf(" 0x%lx", cpu);
}
}
}
if (last_cpu != first_cpu)
- printf("-%lx", last_cpu);
+ printf("-0x%lx", last_cpu);
printf("\n");
return 0;
}
@@ -1024,7 +1024,7 @@ static int cpu_cmd(void)
/* take control back */
mb();
xmon_owner = smp_processor_id();
- printf("cpu %u didn't take control\n", cpu);
+ printf("cpu 0x%x didn't take control\n", cpu);
return 0;
}
barrier();
@@ -1086,7 +1086,7 @@ csum(void)
fcs = 0xffff;
for (i = 0; i < ncsum; ++i) {
if (mread(adrs+i, &v, 1) == 0) {
- printf("csum stopped at %x\n", adrs+i);
+ printf("csum stopped at "REG"\n", adrs+i);
break;
}
fcs = FCS(fcs, v);
@@ -1202,12 +1202,12 @@ bpt_cmds(void)
/* assume a breakpoint address */
bp = at_breakpoint(a);
if (bp == NULL) {
- printf("No breakpoint at %x\n", a);
+ printf("No breakpoint at %lx\n", a);
break;
}
}
- printf("Cleared breakpoint %x (", BP_NUM(bp));
+ printf("Cleared breakpoint %lx (", BP_NUM(bp));
xmon_print_symbol(bp->address, " ", ")\n");
bp->enabled = 0;
break;
@@ -1746,7 +1746,7 @@ mwrite(unsigned long adrs, void *buf, int size)
__delay(200);
n = size;
} else {
- printf("*** Error writing address %x\n", adrs + n);
+ printf("*** Error writing address "REG"\n", adrs + n);
}
catch_memory_errors = 0;
return n;
@@ -2435,7 +2435,7 @@ static void proccall(void)
ret = func(args[0], args[1], args[2], args[3],
args[4], args[5], args[6], args[7]);
sync();
- printf("return value is %x\n", ret);
+ printf("return value is 0x%lx\n", ret);
} else {
printf("*** %x exception occurred\n", fault_except);
}
@@ -2700,7 +2700,7 @@ static void dump_slb(void)
unsigned long esid,vsid,valid;
unsigned long llp;
- printf("SLB contents of cpu %x\n", smp_processor_id());
+ printf("SLB contents of cpu 0x%x\n", smp_processor_id());
for (i = 0; i < mmu_slb_size; i++) {
asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
@@ -2732,7 +2732,7 @@ static void dump_stab(void)
int i;
unsigned long *tmp = (unsigned long *)local_paca->stab_addr;
- printf("Segment table contents of cpu %x\n", smp_processor_id());
+ printf("Segment table contents of cpu 0x%x\n", smp_processor_id());
for (i = 0; i < PAGE_SIZE/16; i++) {
unsigned long a, b;
--
1.9.1
^ permalink raw reply related
* Re: [RFT PATCH -next ] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Suzuki K. Poulose @ 2014-05-26 11:25 UTC (permalink / raw)
To: Masami Hiramatsu, Benjamin Herrenschmidt, Paul Mackerras,
Tony Luck
Cc: Jeremy Fitzhardinge, linux-ia64, sparse, H. Peter Anvin,
Thomas Gleixner, linux-tip-commits, anil.s.keshavamurthy,
Ingo Molnar, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, akataria, Tony Luck, Kevin Hao,
Linus Torvalds, rdunlap, Linux Kernel Mailing List, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20140507115551.22259.70581.stgit@ltc230.yrl.intra.hitachi.co.jp>
On 05/07/2014 05:25 PM, Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not point the
> entry address of the function, but the address of function
> discriptor (which contains the entry address and misc
> data.) Since the kprobes passes the function pointer stored
> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
> initalizing its blacklist, it fails and reports many errors
> as below.
>
> Failed to find blacklist 0001013168300000
> Failed to find blacklist 0001013000f0a000
> Failed to find blacklist 000101315f70a000
> Failed to find blacklist 000101324c80a000
> Failed to find blacklist 0001013063f0a000
> Failed to find blacklist 000101327800a000
> Failed to find blacklist 0001013277f0a000
> Failed to find blacklist 000101315a70a000
> Failed to find blacklist 0001013277e0a000
> Failed to find blacklist 000101305a20a000
> Failed to find blacklist 0001013277d0a000
> Failed to find blacklist 00010130bdc0a000
> Failed to find blacklist 00010130dc20a000
> Failed to find blacklist 000101309a00a000
> Failed to find blacklist 0001013277c0a000
> Failed to find blacklist 0001013277b0a000
> Failed to find blacklist 0001013277a0a000
> Failed to find blacklist 000101327790a000
> Failed to find blacklist 000101303140a000
> Failed to find blacklist 0001013a3280a000
>
> To fix this bug, this introduces function_entry() macro to
> retrieve the entry address from the given function pointer,
> and uses it in NOKPROBE_SYMBOL().
>
>
> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Reported-by: Tony Luck <tony.luck@gmail.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: Kevin Hao <haokexin@gmail.com>
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/ia64/include/asm/types.h | 2 ++
> arch/powerpc/include/asm/types.h | 11 +++++++++++
> include/linux/kprobes.h | 3 ++-
> include/linux/types.h | 4 ++++
> 4 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
> index 4c351b1..6ab7b6c 100644
> --- a/arch/ia64/include/asm/types.h
> +++ b/arch/ia64/include/asm/types.h
> @@ -27,5 +27,7 @@ struct fnptr {
> unsigned long gp;
> };
>
> +#define constant_function_entry(fn) (((struct fnptr *)(fn))->ip)
> +
> #endif /* !__ASSEMBLY__ */
> #endif /* _ASM_IA64_TYPES_H */
> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
> index bfb6ded..fd297b8 100644
> --- a/arch/powerpc/include/asm/types.h
> +++ b/arch/powerpc/include/asm/types.h
> @@ -25,6 +25,17 @@ typedef struct {
> unsigned long env;
> } func_descr_t;
>
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address of the function text.
> + */
> +#define constant_function_entry(fn) (((func_descr_t *)(fn))->entry)
> +#else
> +#define constant_function_entry(fn) ((unsigned long)(fn))
> +#endif
> +
> #endif /* __ASSEMBLY__ */
>
> #endif /* _ASM_POWERPC_TYPES_H */
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index e059507..637eafe 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -40,6 +40,7 @@
> #include <linux/rcupdate.h>
> #include <linux/mutex.h>
> #include <linux/ftrace.h>
> +#include <linux/types.h>
>
> #ifdef CONFIG_KPROBES
> #include <asm/kprobes.h>
> @@ -485,7 +486,7 @@ static inline int enable_jprobe(struct jprobe *jp)
> #define __NOKPROBE_SYMBOL(fname) \
> static unsigned long __used \
> __attribute__((section("_kprobe_blacklist"))) \
> - _kbl_addr_##fname = (unsigned long)fname;
> + _kbl_addr_##fname = constant_function_entry(fname);
> #define NOKPROBE_SYMBOL(fname) __NOKPROBE_SYMBOL(fname)
Throws up build errors for me :
CC kernel/notifier.o
kernel/notifier.c:105:1: error: initializer element is not constant
NOKPROBE_SYMBOL(notifier_call_chain);
^
kernel/notifier.c:188:1: error: initializer element is not constant
NOKPROBE_SYMBOL(__atomic_notifier_call_chain);
^
kernel/notifier.c:196:1: error: initializer element is not constant
NOKPROBE_SYMBOL(atomic_notifier_call_chain);
^
kernel/notifier.c:546:1: error: initializer element is not constant
NOKPROBE_SYMBOL(notify_die);
^
make[1]: *** [kernel/notifier.o] Error 1
make: *** [kernel] Error 2
Thanks
Suzuki
^ permalink raw reply
* [PATCH v3] powerpc: Add cpu family documentation
From: Michael Ellerman @ 2014-05-26 11:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: Stephen Rothwell, Arnd Bergmann, tommusta, James.Yang, scottwood
This patch adds some documentation on the different cpu families
supported by arch/powerpc.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
Please send any further corrections as patches :)
v3: Dropped 740, don't need that level of detail.
Don't list 850 separately from 8xx.
Rename 8xx to MPC8xx Core as per James.
Moved Book3e to e500mc.
Add e300 and e600.
Show ambiguous Cell/Power6 relationship.
v2: Reworked formatting to avoid wrapping.
Fixed up Freescale details.
---
Documentation/powerpc/cpu_families.txt | 221 +++++++++++++++++++++++++++++++++
1 file changed, 221 insertions(+)
create mode 100644 Documentation/powerpc/cpu_families.txt
diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.txt
new file mode 100644
index 0000000..fc08e22
--- /dev/null
+++ b/Documentation/powerpc/cpu_families.txt
@@ -0,0 +1,221 @@
+CPU Families
+============
+
+This document tries to summarise some of the different cpu families that exist
+and are supported by arch/powerpc.
+
+
+Book3S (aka sPAPR)
+------------------
+
+ - Hash MMU
+ - Mix of 32 & 64 bit
+
+ +--------------+ +----------------+
+ | Old POWER | --------------> | RS64 (threads) |
+ +--------------+ +----------------+
+ |
+ |
+ v
+ +--------------+ +----------------+ +------+
+ | 601 | --------------> | 603 | ---> | e300 |
+ +--------------+ +----------------+ +------+
+ | |
+ | |
+ v v
+ +--------------+ +----------------+ +-------+
+ | 604 | | 750 (G3) | ---> | 750CX |
+ +--------------+ +----------------+ +-------+
+ | | |
+ | | |
+ v v v
+ +--------------+ +----------------+ +-------+
+ | 620 (64 bit) | | 7400 | | 750CL |
+ +--------------+ +----------------+ +-------+
+ | | |
+ | | |
+ v v v
+ +--------------+ +----------------+ +-------+
+ | POWER3/630 | | 7410 | | 750FX |
+ +--------------+ +----------------+ +-------+
+ | |
+ | |
+ v v
+ +--------------+ +----------------+
+ | POWER3+ | | 7450 |
+ +--------------+ +----------------+
+ | |
+ | |
+ v v
+ +--------------+ +----------------+
+ | POWER4 | | 7455 |
+ +--------------+ +----------------+
+ | |
+ | |
+ v v
+ +--------------+ +-------+ +----------------+
+ | POWER4+ | --> | 970 | | 7447 |
+ +--------------+ +-------+ +----------------+
+ | | |
+ | | |
+ v v v
+ +--------------+ +-------+ +----------------+
+ | POWER5 | | 970FX | | 7448 |
+ +--------------+ +-------+ +----------------+
+ | | |
+ | | |
+ v v v
+ +--------------+ +-------+ +----------------+
+ | POWER5+ | | 970MP | | e600 |
+ +--------------+ +-------+ +----------------+
+ |
+ |
+ v
+ +--------------+
+ | POWER5++ |
+ +--------------+
+ |
+ |
+ v
+ +--------------+ +-------+
+ | POWER6 | <-?-> | Cell |
+ +--------------+ +-------+
+ |
+ |
+ v
+ +--------------+
+ | POWER7 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | POWER7+ |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | POWER8 |
+ +--------------+
+
+
+ +---------------+
+ | PA6T (64 bit) |
+ +---------------+
+
+
+IBM BookE
+---------
+
+ - Software loaded TLB.
+ - All 32 bit
+
+ +--------------+
+ | 401 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | 403 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | 405 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | 440 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+ +----------------+
+ | 450 | --> | BG/P |
+ +--------------+ +----------------+
+ |
+ |
+ v
+ +--------------+
+ | 460 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | 476 |
+ +--------------+
+
+
+Motorola/Freescale 8xx
+----------------------
+
+ - Software loaded with hardware assist.
+ - All 32 bit
+
+ +-------------+
+ | MPC8xx Core |
+ +-------------+
+
+
+Freescale BookE
+---------------
+
+ - Software loaded TLB.
+ - e6500 adds HW loaded indirect TLB entries.
+ - Mix of 32 & 64 bit
+
+ +--------------+
+ | e200 |
+ +--------------+
+
+
+ +--------------------------------+
+ | e500 |
+ +--------------------------------+
+ |
+ |
+ v
+ +--------------------------------+
+ | e500v2 |
+ +--------------------------------+
+ |
+ |
+ v
+ +--------------------------------+
+ | e500mc (Book3e) |
+ +--------------------------------+
+ |
+ |
+ v
+ +--------------------------------+
+ | e5500 (64 bit) |
+ +--------------------------------+
+ |
+ |
+ v
+ +--------------------------------+
+ | e6500 (HW TLB) (Multithreaded) |
+ +--------------------------------+
+
+
+IBM A2 core
+-----------
+
+ - Book3E, software loaded TLB + HW loaded indirect TLB entries.
+ - 64 bit
+
+ +--------------+ +----------------+
+ | A2 core | --> | WSP |
+ +--------------+ +----------------+
+ |
+ |
+ v
+ +--------------+
+ | BG/Q |
+ +--------------+
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox