* RE: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
From: Bharat Bhushan @ 2013-11-13 9:19 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev@lists.ozlabs.org, Alex Graf
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1384324220-30109-1-git-send-email-aik@ozlabs.ru>
> -----Original Message-----
> From: Alexey Kardashevskiy [mailto:aik@ozlabs.ru]
> Sent: Wednesday, November 13, 2013 12:00 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Alexey Kardashevskiy; Benjamin Herrenschmidt; Bhushan Bharat-R65777; =
Alex
> Graf; linux-kernel@vger.kernel.org
> Subject: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
>=20
> The current implementation of IOMMU on sPAPR does not use iommu_ops
> and therefore does not call IOMMU API's bus_set_iommu() which
> 1) sets iommu_ops for a bus
> 2) registers a bus notifier
> Instead, PCI devices are added to IOMMU groups from
> subsys_initcall_sync(tce_iommu_init) which does basically the same
> thing without using iommu_ops callbacks.
>=20
> However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
> implements iommu_ops and when tce_iommu_init is called, every PCI device
> is already added to some group so there is a conflict.
>=20
> This patch does 2 things:
> 1. removes the loop in which PCI devices were added to groups and
> adds explicit iommu_add_device() calls to add devices as soon as they get
> the iommu_table pointer assigned to them.
> 2. moves a bus notifier to powernv code in order to avoid conflict with
> the notifier from Freescale driver.
>=20
> iommu_add_device() and iommu_del_device() are public now.
>=20
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Tested-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> Changes:
> v9:
> * removed "KVM" from the subject as it is not really a KVM patch so
> PPC mainainter (hi Ben!) can review/include it into his tree
>=20
> v8:
> * added the check for iommu_group!=3DNULL before removing device from a g=
roup
> as suggested by Wei Yang <weiyang@linux.vnet.ibm.com>
>=20
> v2:
> * added a helper - set_iommu_table_base_and_group - which does
> set_iommu_table_base() and iommu_add_device()
> ---
> arch/powerpc/include/asm/iommu.h | 9 +++++++
> arch/powerpc/kernel/iommu.c | 41 +++--------------------=
------
> arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++---
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
> arch/powerpc/platforms/powernv/pci.c | 33 ++++++++++++++++++++++-
> arch/powerpc/platforms/pseries/iommu.c | 8 +++---
> 6 files changed, 55 insertions(+), 46 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/=
iommu.h
> index c34656a..19ad77f 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct
> iommu_table * tbl,
> int nid);
> extern void iommu_register_group(struct iommu_table *tbl,
> int pci_domain_number, unsigned long pe_num);
> +extern int iommu_add_device(struct device *dev);
> +extern void iommu_del_device(struct device *dev);
> +
> +static inline void set_iommu_table_base_and_group(struct device *dev,
> + void *base)
> +{
> + set_iommu_table_base(dev, base);
> + iommu_add_device(dev);
> +}
>=20
> extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
> struct scatterlist *sglist, int nelems,
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 572bb5b..ecbf468 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tb=
l)
> }
> EXPORT_SYMBOL_GPL(iommu_release_ownership);
>=20
> -static int iommu_add_device(struct device *dev)
> +int iommu_add_device(struct device *dev)
> {
> struct iommu_table *tbl;
> int ret =3D 0;
> @@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
>=20
> return ret;
> }
> +EXPORT_SYMBOL_GPL(iommu_add_device);
>=20
> -static void iommu_del_device(struct device *dev)
> +void iommu_del_device(struct device *dev)
> {
> iommu_group_remove_device(dev);
> }
> -
> -static int iommu_bus_notifier(struct notifier_block *nb,
> - unsigned long action, void *data)
> -{
> - struct device *dev =3D data;
> -
> - switch (action) {
> - case BUS_NOTIFY_ADD_DEVICE:
> - return iommu_add_device(dev);
> - case BUS_NOTIFY_DEL_DEVICE:
> - iommu_del_device(dev);
> - return 0;
> - default:
> - return 0;
> - }
> -}
> -
> -static struct notifier_block tce_iommu_bus_nb =3D {
> - .notifier_call =3D iommu_bus_notifier,
> -};
> -
> -static int __init tce_iommu_init(void)
> -{
> - struct pci_dev *pdev =3D NULL;
> -
> - BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> -
> - for_each_pci_dev(pdev)
> - iommu_add_device(&pdev->dev);
> -
> - bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> - return 0;
> -}
> -
> -subsys_initcall_sync(tce_iommu_init);
> +EXPORT_SYMBOL_GPL(iommu_del_device);
>=20
> #else
>=20
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 084cdfa..614356c 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -460,7 +460,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb=
*phb,
> struct pci_dev *pdev
> return;
>=20
> pe =3D &phb->ioda.pe_array[pdn->pe_number];
> - set_iommu_table_base(&pdev->dev, &pe->tce32_table);
> + set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
> }
>=20
> static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bu=
s *bus)
> @@ -468,7 +468,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe=
*pe,
> struct pci_bus *bus)
> struct pci_dev *dev;
>=20
> list_for_each_entry(dev, &bus->devices, bus_list) {
> - set_iommu_table_base(&dev->dev, &pe->tce32_table);
> + set_iommu_table_base_and_group(&dev->dev, &pe->tce32_table);
> if (dev->subordinate)
> pnv_ioda_setup_bus_dma(pe, dev->subordinate);
> }
> @@ -644,7 +644,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb =
*phb,
> iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
>=20
> if (pe->pdev)
> - set_iommu_table_base(&pe->pdev->dev, tbl);
> + set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
> else
> pnv_ioda_setup_bus_dma(pe, pe->pbus);
>=20
> @@ -722,7 +722,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb=
*phb,
> iommu_init_table(tbl, phb->hose->node);
>=20
> if (pe->pdev)
> - set_iommu_table_base(&pe->pdev->dev, tbl);
> + set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
> else
> pnv_ioda_setup_bus_dma(pe, pe->pbus);
>=20
> diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> index f8b4bd8..e3807d6 100644
> --- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> +++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
> @@ -92,7 +92,7 @@ static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb=
*phb,
> pci_domain_nr(phb->hose->bus), phb->opal_id);
> }
>=20
> - set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
> + set_iommu_table_base_and_group(&pdev->dev, &phb->p5ioc2.iommu_table);
> }
>=20
> static void __init pnv_pci_init_p5ioc2_phb(struct device_node *np, u64 h=
ub_id,
> diff --git a/arch/powerpc/platforms/powernv/pci.c
> b/arch/powerpc/platforms/powernv/pci.c
> index 4eb33a9..6f3d49c 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -536,7 +536,7 @@ static void pnv_pci_dma_fallback_setup(struct pci_con=
troller
> *hose,
> pdn->iommu_table =3D pnv_pci_setup_bml_iommu(hose);
> if (!pdn->iommu_table)
> return;
> - set_iommu_table_base(&pdev->dev, pdn->iommu_table);
> + set_iommu_table_base_and_group(&pdev->dev, pdn->iommu_table);
> }
>=20
> static void pnv_pci_dma_dev_setup(struct pci_dev *pdev)
> @@ -657,3 +657,34 @@ void __init pnv_pci_init(void)
> ppc_md.teardown_msi_irqs =3D pnv_teardown_msi_irqs;
> #endif
> }
> +
> +static int tce_iommu_bus_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct device *dev =3D data;
> +
> + switch (action) {
> + case BUS_NOTIFY_ADD_DEVICE:
> + return iommu_add_device(dev);
> + case BUS_NOTIFY_DEL_DEVICE:
> + if (dev->iommu_group)
> + iommu_del_device(dev);
> + return 0;
> + default:
> + return 0;
> + }
> +}
> +
> +static struct notifier_block tce_iommu_bus_nb =3D {
> + .notifier_call =3D tce_iommu_bus_notifier,
> +};
> +
> +static int __init tce_iommu_bus_notifier_init(void)
> +{
> + BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> +
> + bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> + return 0;
> +}
> +
> +subsys_initcall_sync(tce_iommu_bus_notifier_init);
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index f253361..a80af6c 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -687,7 +687,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev =
*dev)
> iommu_table_setparms(phb, dn, tbl);
> PCI_DN(dn)->iommu_table =3D iommu_init_table(tbl, phb->node);
> iommu_register_group(tbl, pci_domain_nr(phb->bus), 0);
> - set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> + set_iommu_table_base_and_group(&dev->dev,
> + PCI_DN(dn)->iommu_table);
> return;
> }
>=20
> @@ -699,7 +700,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev =
*dev)
> dn =3D dn->parent;
>=20
> if (dn && PCI_DN(dn))
> - set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> + set_iommu_table_base_and_group(&dev->dev,
> + PCI_DN(dn)->iommu_table);
> else
> printk(KERN_WARNING "iommu: Device %s has no iommu table\n",
> pci_name(dev));
> @@ -1193,7 +1195,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_=
dev
> *dev)
> pr_debug(" found DMA window, table: %p\n", pci->iommu_table);
> }
>=20
> - set_iommu_table_base(&dev->dev, pci->iommu_table);
> + set_iommu_table_base_and_group(&dev->dev, pci->iommu_table);
> }
>=20
> static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
> --
> 1.8.4.rc4
>=20
^ permalink raw reply
* Re: [patch] ALSA: snd-aoa: two copy and paste bugs
From: Johannes Berg @ 2013-11-13 8:29 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, kernel-janitors, Jaroslav Kysela, linuxppc-dev,
Dan Carpenter
In-Reply-To: <s5h4n7gso19.wl%tiwai@suse.de>
On Wed, 2013-11-13 at 09:29 +0100, Takashi Iwai wrote:
> At Wed, 13 Nov 2013 10:45:20 +0300,
> Dan Carpenter wrote:
> >
> > These functions were cut and paste and the tests for NULL weren't
> > updated properly.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Thanks, applied.
FWIW, looks fine to me - I wonder how long this has been broken though,
must be practically forever. I guess we never got it wrong and missed
adding some pointers? :-)
johannes
^ permalink raw reply
* Re: [patch] ALSA: snd-aoa: two copy and paste bugs
From: Takashi Iwai @ 2013-11-13 8:29 UTC (permalink / raw)
To: Dan Carpenter
Cc: alsa-devel, kernel-janitors, Jaroslav Kysela, Johannes Berg,
linuxppc-dev
In-Reply-To: <20131113074520.GD25541@elgon.mountain>
At Wed, 13 Nov 2013 10:45:20 +0300,
Dan Carpenter wrote:
>
> These functions were cut and paste and the tests for NULL weren't
> updated properly.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Thanks, applied.
Takashi
>
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index 61ab640..9dc5806 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -644,7 +644,7 @@ static int n##_control_put(struct snd_kcontrol *kcontrol, \
> struct snd_ctl_elem_value *ucontrol) \
> { \
> struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
> - if (gpio->methods && gpio->methods->get_##n) \
> + if (gpio->methods && gpio->methods->set_##n) \
> gpio->methods->set_##n(gpio, \
> !!ucontrol->value.integer.value[0]); \
> return 1; \
> @@ -1135,7 +1135,7 @@ static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
> {
> struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
>
> - if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
> + if (ldev->gpio.methods && ldev->gpio.methods->all_amps_restore)
> ldev->gpio.methods->all_amps_restore(&ldev->gpio);
>
> return 0;
>
^ permalink raw reply
* [patch] ALSA: snd-aoa: two copy and paste bugs
From: Dan Carpenter @ 2013-11-13 7:45 UTC (permalink / raw)
To: Johannes Berg
Cc: alsa-devel, Takashi Iwai, kernel-janitors, Jaroslav Kysela,
linuxppc-dev
These functions were cut and paste and the tests for NULL weren't
updated properly.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 61ab640..9dc5806 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -644,7 +644,7 @@ static int n##_control_put(struct snd_kcontrol *kcontrol, \
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
- if (gpio->methods && gpio->methods->get_##n) \
+ if (gpio->methods && gpio->methods->set_##n) \
gpio->methods->set_##n(gpio, \
!!ucontrol->value.integer.value[0]); \
return 1; \
@@ -1135,7 +1135,7 @@ static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
{
struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
- if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_restore)
ldev->gpio.methods->all_amps_restore(&ldev->gpio);
return 0;
^ permalink raw reply related
* Re: Problem reading and programming memory location...
From: Anatolij Gustschin @ 2013-11-13 7:32 UTC (permalink / raw)
To: neorf3k; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <985685C7-0122-4D45-96D1-4412E9774A5D@gmail.com>
On Tue, 12 Nov 2013 20:23:20 +0100
neorf3k <neorf3k@gmail.com> wrote:
> we have tried to read and program an 8bit register with 32bit address.
> we have mapped it with: ioremap, kmalloc etc=E2=80=A6 and then using: out=
b,
> iowrite8 etc.. but when we write to it, the value doesn=E2=80=99t change=
=E2=80=A6
> with other memory location is ok.
> That is an 8 bit register, located at 0x10020000 in a mpc5200b
> architecture. we are using kernel 2.6.33.=20
> what could be?
0x10020000 is not in the internal register memory map, so it
is probably a device on the LocalPlus bus. Did you configure
the chip select parameters for this device and did you enable
the associated chip select?
=20
HTH,
Anatolij
^ permalink raw reply
* [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
From: Alexey Kardashevskiy @ 2013-11-13 6:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Alex Graf, Bharat Bhushan, linux-kernel
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically the same
thing without using iommu_ops callbacks.
However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
implements iommu_ops and when tce_iommu_init is called, every PCI device
is already added to some group so there is a conflict.
This patch does 2 things:
1. removes the loop in which PCI devices were added to groups and
adds explicit iommu_add_device() calls to add devices as soon as they get
the iommu_table pointer assigned to them.
2. moves a bus notifier to powernv code in order to avoid conflict with
the notifier from Freescale driver.
iommu_add_device() and iommu_del_device() are public now.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v9:
* removed "KVM" from the subject as it is not really a KVM patch so
PPC mainainter (hi Ben!) can review/include it into his tree
v8:
* added the check for iommu_group!=NULL before removing device from a group
as suggested by Wei Yang <weiyang@linux.vnet.ibm.com>
v2:
* added a helper - set_iommu_table_base_and_group - which does
set_iommu_table_base() and iommu_add_device()
---
arch/powerpc/include/asm/iommu.h | 9 +++++++
arch/powerpc/kernel/iommu.c | 41 +++--------------------------
arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
arch/powerpc/platforms/powernv/pci.c | 33 ++++++++++++++++++++++-
arch/powerpc/platforms/pseries/iommu.c | 8 +++---
6 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index c34656a..19ad77f 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
extern void iommu_register_group(struct iommu_table *tbl,
int pci_domain_number, unsigned long pe_num);
+extern int iommu_add_device(struct device *dev);
+extern void iommu_del_device(struct device *dev);
+
+static inline void set_iommu_table_base_and_group(struct device *dev,
+ void *base)
+{
+ set_iommu_table_base(dev, base);
+ iommu_add_device(dev);
+}
extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
struct scatterlist *sglist, int nelems,
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 572bb5b..ecbf468 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tbl)
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
-static int iommu_add_device(struct device *dev)
+int iommu_add_device(struct device *dev)
{
struct iommu_table *tbl;
int ret = 0;
@@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
return ret;
}
+EXPORT_SYMBOL_GPL(iommu_add_device);
-static void iommu_del_device(struct device *dev)
+void iommu_del_device(struct device *dev)
{
iommu_group_remove_device(dev);
}
-
-static int iommu_bus_notifier(struct notifier_block *nb,
- unsigned long action, void *data)
-{
- struct device *dev = data;
-
- switch (action) {
- case BUS_NOTIFY_ADD_DEVICE:
- return iommu_add_device(dev);
- case BUS_NOTIFY_DEL_DEVICE:
- iommu_del_device(dev);
- return 0;
- default:
- return 0;
- }
-}
-
-static struct notifier_block tce_iommu_bus_nb = {
- .notifier_call = iommu_bus_notifier,
-};
-
-static int __init tce_iommu_init(void)
-{
- struct pci_dev *pdev = NULL;
-
- BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
-
- for_each_pci_dev(pdev)
- iommu_add_device(&pdev->dev);
-
- bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
- return 0;
-}
-
-subsys_initcall_sync(tce_iommu_init);
+EXPORT_SYMBOL_GPL(iommu_del_device);
#else
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 084cdfa..614356c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -460,7 +460,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
return;
pe = &phb->ioda.pe_array[pdn->pe_number];
- set_iommu_table_base(&pdev->dev, &pe->tce32_table);
+ set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
}
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
@@ -468,7 +468,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
struct pci_dev *dev;
list_for_each_entry(dev, &bus->devices, bus_list) {
- set_iommu_table_base(&dev->dev, &pe->tce32_table);
+ set_iommu_table_base_and_group(&dev->dev, &pe->tce32_table);
if (dev->subordinate)
pnv_ioda_setup_bus_dma(pe, dev->subordinate);
}
@@ -644,7 +644,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
if (pe->pdev)
- set_iommu_table_base(&pe->pdev->dev, tbl);
+ set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
else
pnv_ioda_setup_bus_dma(pe, pe->pbus);
@@ -722,7 +722,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
iommu_init_table(tbl, phb->hose->node);
if (pe->pdev)
- set_iommu_table_base(&pe->pdev->dev, tbl);
+ set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
else
pnv_ioda_setup_bus_dma(pe, pe->pbus);
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index f8b4bd8..e3807d6 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -92,7 +92,7 @@ static void pnv_pci_p5ioc2_dma_dev_setup(struct pnv_phb *phb,
pci_domain_nr(phb->hose->bus), phb->opal_id);
}
- set_iommu_table_base(&pdev->dev, &phb->p5ioc2.iommu_table);
+ set_iommu_table_base_and_group(&pdev->dev, &phb->p5ioc2.iommu_table);
}
static void __init pnv_pci_init_p5ioc2_phb(struct device_node *np, u64 hub_id,
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 4eb33a9..6f3d49c 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -536,7 +536,7 @@ static void pnv_pci_dma_fallback_setup(struct pci_controller *hose,
pdn->iommu_table = pnv_pci_setup_bml_iommu(hose);
if (!pdn->iommu_table)
return;
- set_iommu_table_base(&pdev->dev, pdn->iommu_table);
+ set_iommu_table_base_and_group(&pdev->dev, pdn->iommu_table);
}
static void pnv_pci_dma_dev_setup(struct pci_dev *pdev)
@@ -657,3 +657,34 @@ void __init pnv_pci_init(void)
ppc_md.teardown_msi_irqs = pnv_teardown_msi_irqs;
#endif
}
+
+static int tce_iommu_bus_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *dev = data;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ return iommu_add_device(dev);
+ case BUS_NOTIFY_DEL_DEVICE:
+ if (dev->iommu_group)
+ iommu_del_device(dev);
+ return 0;
+ default:
+ return 0;
+ }
+}
+
+static struct notifier_block tce_iommu_bus_nb = {
+ .notifier_call = tce_iommu_bus_notifier,
+};
+
+static int __init tce_iommu_bus_notifier_init(void)
+{
+ BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
+
+ bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
+ return 0;
+}
+
+subsys_initcall_sync(tce_iommu_bus_notifier_init);
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index f253361..a80af6c 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -687,7 +687,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
iommu_table_setparms(phb, dn, tbl);
PCI_DN(dn)->iommu_table = iommu_init_table(tbl, phb->node);
iommu_register_group(tbl, pci_domain_nr(phb->bus), 0);
- set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
+ set_iommu_table_base_and_group(&dev->dev,
+ PCI_DN(dn)->iommu_table);
return;
}
@@ -699,7 +700,8 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
dn = dn->parent;
if (dn && PCI_DN(dn))
- set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
+ set_iommu_table_base_and_group(&dev->dev,
+ PCI_DN(dn)->iommu_table);
else
printk(KERN_WARNING "iommu: Device %s has no iommu table\n",
pci_name(dev));
@@ -1193,7 +1195,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
pr_debug(" found DMA window, table: %p\n", pci->iommu_table);
}
- set_iommu_table_base(&dev->dev, pci->iommu_table);
+ set_iommu_table_base_and_group(&dev->dev, pci->iommu_table);
}
static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
--
1.8.4.rc4
^ permalink raw reply related
* RE: [PATCH] Add a vga alias node for P1022
From: Zhengxiong Jin @ 2013-11-13 6:28 UTC (permalink / raw)
To: Scott Wood, galak@kernel.crashing.org; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1378459957-26334-1-git-send-email-Jason.Jin@freescale.com>
> -----Original Message-----
> From: Jin Zhengxiong-R64188
> Sent: Friday, September 06, 2013 5:33 PM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Jin
> Zhengxiong-R64188
> Subject: [PATCH] Add a vga alias node for P1022
>=20
> From: Jason Jin <Jason.jin@freescale.com>
>=20
> When the vga was set as the stdout and stderr in u-boot, the stdout fixup
> code in u-boot need to find out the vga alias node in dtb.
>=20
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
[Jason Jin-R64188] Any comments about this patch? Thanks.
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Emil Medve @ 2013-11-13 2:34 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <1384307175.1403.118.camel__32063.4016803981$1384307228$gmane$org@snotra.buserror.net>
Hello Scott,
On 11/12/2013 07:46 PM, Scott Wood wrote:
> On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/12/2013 04:04 PM, Scott Wood wrote:
>>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>>>
>>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>>>> ---
>>>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
>>>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
>>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
>>>> 3 files changed, 35 insertions(+), 188 deletions(-)
>>>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>>>
>>> Are we still going to want to have one defconfig if and when we finally
>>> get datapath support upstream? That's a lot of code to add to the 85xx
>>> config just for this one chip.
>>
>> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
>> enabled by default given that just one SoC in that family has the
>> datapath (and we don't plan to put it in another e500v2 based SoC). For
>> regression/automation purposes config fragments should be used
>
> Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
> whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
> fragment?
Not aware of it
> Do we have any config fragments in the tree so far?
Nope. However, just to make sure, the fragment was my secondary point
and not necessarily as a candidate for upstreaming. My main point was
that the datapath support should simply not be enabled by default in the
mpc85xx_[smp_]defconfig
Cheers,
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-13 2:01 UTC (permalink / raw)
To: Scott Wood
Cc: shh.xie@gmail.com, Shruti Kanetkar, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Madalin-Cristian Bucur
In-Reply-To: <1384307679.1403.122.camel@snotra.buserror.net>
PiBPbiBUdWUsIDIwMTMtMTEtMTIgYXQgMTk6NTEgLTA2MDAsIFhpZSBTaGFvaHVpLUIyMTk4OSB3
cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29k
IFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMyA1
OjU4IEFNDQo+ID4gPiBUbzogc2hoLnhpZUBnbWFpbC5jb20NCj4gPiA+IENjOiBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+
IEthbmV0a2FyIFNocnV0aS1CNDQ0NTQ7IFhpZSBTaGFvaHVpLUIyMTk4OTsgQnVjdXINCj4gPiA+
IE1hZGFsaW4tQ3Jpc3RpYW4tQjMyNzE2DQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvNF0g
cGh5bGliOiBBZGQgQ2xhdXNlIDQ1IHJlYWQvd3JpdGUgZnVuY3Rpb25zDQo+ID4gPg0KPiA+ID4g
T24gTW9uLCAyMDEzLTExLTExIGF0IDE5OjA0ICswODAwLCBzaGgueGllQGdtYWlsLmNvbSB3cm90
ZToNCj4gPiA+ID4gRnJvbTogQW5keSBGbGVtaW5nDQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBuZWVk
IGFuIGV4dHJhIHBhcmFtZXRlciB0byByZWFkIG9yIHdyaXRlIENsYXVzZSA0NSBQSFlzLCBzbyB3
ZQ0KPiA+ID4gPiBuZWVkIGEgZGlmZmVyZW50IEFQSSB3aXRoIHRoZSBleHRyYSBwYXJhbWV0ZXIu
DQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IEFuZHkgRmxlbWluZw0KPiA+ID4gPiBT
aWduZWQtb2ZmLWJ5OiBTaGFvaHVpIFhpZSA8U2hhb2h1aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4g
PiA+DQo+ID4gPiBXaHkgZGlkIHlvdSByZW1vdmUgQW5keSdzIGUtbWFpbCBhZGRyZXNzPyAgRXZl
biB0aG91Z2ggaXQncyBubw0KPiA+ID4gbG9uZ2VyIHZhbGlkLCBpdCBoZWxwcyBpZGVudGlmeSB3
aGljaCBzcGVjaWZpYyBwZXJzb24geW91J3JlIHRhbGtpbmcgYWJvdXQuDQo+ID4gPg0KPiA+IFtT
LkhdIEFuZHkncyBlLW1haWwgYWRkcmVzcyBpcyBub3QgdmFsaWQgYW5kIGdpdC1zZW5kLW1haWwg
d2lsbCBmYWlsLCBJIGhhdmUNCj4gdG8gcmVtb3ZlIGl0IHRvIG1ha2UgZ2l0IHdvcmsuDQo+IA0K
PiBUZWxsIGdpdCBzZW5kLWVtYWlsIHRvIG5vdCBpbmNsdWRlIHRoYXQgYWRkcmVzcywgZS5nLiB1
c2luZyAtLXN1cHByZXNzLWNjLCAtLW5vLQ0KPiBzaWduZWQtb2ZmLWJ5LWNjLCAtLXN1cHByZXNz
LWZyb20sIGV0Yy4NCj4gDQpbUy5IXSBPSy4gVGhhbmsgeW91IQ0KDQoNCkJlc3QgUmVnYXJkcywg
DQpTaGFvaHVpIFhpZQ0K
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Emil Medve @ 2013-11-13 1:54 UTC (permalink / raw)
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <ED492CCEAF882048BC2237DE806547C91512489F@039-SN2MPN1-013.039d.mgd.msft.net>
Hello Xiao-Hui,
On 11/12/2013 07:51 PM, Shaohui Xie wrote:
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Wednesday, November 13, 2013 5:58 AM
>> To: shh.xie@gmail.com
>> Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Kanetkar
>> Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716
>> Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>>
>> On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
>>> From: Andy Fleming
>>>
>>> You need an extra parameter to read or write Clause 45 PHYs, so we
>>> need a different API with the extra parameter.
>>>
>>> Signed-off-by: Andy Fleming
>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>
>> Why did you remove Andy's e-mail address? Even though it's no longer valid, it
>> helps identify which specific person you're talking about.
>>
> [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work.
Just use Andy's GMail address: afleming@gmail.com
Cheers,
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Scott Wood @ 2013-11-13 1:54 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: shh.xie@gmail.com, Kanetkar Shruti-B44454,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Bucur Madalin-Cristian-B32716
In-Reply-To: <ED492CCEAF882048BC2237DE806547C91512489F@039-SN2MPN1-013.039d.mgd.msft.net>
On Tue, 2013-11-12 at 19:51 -0600, Xie Shaohui-B21989 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, November 13, 2013 5:58 AM
> > To: shh.xie@gmail.com
> > Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Kanetkar
> > Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716
> > Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
> >
> > On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
> > > From: Andy Fleming
> > >
> > > You need an extra parameter to read or write Clause 45 PHYs, so we
> > > need a different API with the extra parameter.
> > >
> > > Signed-off-by: Andy Fleming
> > > Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> >
> > Why did you remove Andy's e-mail address? Even though it's no longer valid, it
> > helps identify which specific person you're talking about.
> >
> [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work.
Tell git send-email to not include that address, e.g. using
--suppress-cc, --no-signed-off-by-cc, --suppress-from, etc.
-Scott
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-13 1:51 UTC (permalink / raw)
To: Scott Wood, shh.xie@gmail.com
Cc: Shruti Kanetkar, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Madalin-Cristian Bucur
In-Reply-To: <1384293487.1403.67.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEzIDU6NTggQU0NCj4gVG86IHNoaC54
aWVAZ21haWwuY29tDQo+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgt
a2VybmVsQHZnZXIua2VybmVsLm9yZzsgS2FuZXRrYXINCj4gU2hydXRpLUI0NDQ1NDsgWGllIFNo
YW9odWktQjIxOTg5OyBCdWN1ciBNYWRhbGluLUNyaXN0aWFuLUIzMjcxNg0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIDEvNF0gcGh5bGliOiBBZGQgQ2xhdXNlIDQ1IHJlYWQvd3JpdGUgZnVuY3Rpb25z
DQo+IA0KPiBPbiBNb24sIDIwMTMtMTEtMTEgYXQgMTk6MDQgKzA4MDAsIHNoaC54aWVAZ21haWwu
Y29tIHdyb3RlOg0KPiA+IEZyb206IEFuZHkgRmxlbWluZw0KPiA+DQo+ID4gWW91IG5lZWQgYW4g
ZXh0cmEgcGFyYW1ldGVyIHRvIHJlYWQgb3Igd3JpdGUgQ2xhdXNlIDQ1IFBIWXMsIHNvIHdlDQo+
ID4gbmVlZCBhIGRpZmZlcmVudCBBUEkgd2l0aCB0aGUgZXh0cmEgcGFyYW1ldGVyLg0KPiA+DQo+
ID4gU2lnbmVkLW9mZi1ieTogQW5keSBGbGVtaW5nDQo+ID4gU2lnbmVkLW9mZi1ieTogU2hhb2h1
aSBYaWUgPFNoYW9odWkuWGllQGZyZWVzY2FsZS5jb20+DQo+IA0KPiBXaHkgZGlkIHlvdSByZW1v
dmUgQW5keSdzIGUtbWFpbCBhZGRyZXNzPyAgRXZlbiB0aG91Z2ggaXQncyBubyBsb25nZXIgdmFs
aWQsIGl0DQo+IGhlbHBzIGlkZW50aWZ5IHdoaWNoIHNwZWNpZmljIHBlcnNvbiB5b3UncmUgdGFs
a2luZyBhYm91dC4NCj4gDQpbUy5IXSBBbmR5J3MgZS1tYWlsIGFkZHJlc3MgaXMgbm90IHZhbGlk
IGFuZCBnaXQtc2VuZC1tYWlsIHdpbGwgZmFpbCwgSSBoYXZlIHRvIHJlbW92ZSBpdCB0byBtYWtl
IGdpdCB3b3JrLg0KDQoNCkJlc3QgUmVnYXJkcywgDQpTaGFvaHVpIFhpZQ0K
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/p1010rdb:add P1010RDB-PB platform support
From: Scott Wood @ 2013-11-13 1:50 UTC (permalink / raw)
To: Zhao Qiang; +Cc: tony, devicetree, linuxppc-dev, bcousson
In-Reply-To: <1383791369-29324-1-git-send-email-B45475@freescale.com>
On Thu, 2013-11-07 at 10:29 +0800, Zhao Qiang wrote:
> The P1010RDB-PB is similar to P1010RDB(P1010RDB-PA).
> So, P1010RDB-PB use the same platform file as P1010RDB.
> Then Add support for P1010RDB-PB platform.
>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> arch/powerpc/platforms/85xx/p1010rdb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index 0252961..d6a3dd3 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -66,6 +66,8 @@ static int __init p1010_rdb_probe(void)
>
> if (of_flat_dt_is_compatible(root, "fsl,P1010RDB"))
> return 1;
> + if (of_flat_dt_is_compatible(root, "fsl,P1010RDB-PB"))
> + return 1;
> return 0;
> }
>
This had already been merged into Ben's tree when you reposted it
(without any indication that it was a repost/respin), and is now in
Linus's tree.
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-13 1:46 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5282B277.4090300@Freescale.com>
On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 11/12/2013 04:04 PM, Scott Wood wrote:
> > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> >> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
> >> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
> >>
> >> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> >> ---
> >> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
> >> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> >> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> >> 3 files changed, 35 insertions(+), 188 deletions(-)
> >> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
> >
> > Are we still going to want to have one defconfig if and when we finally
> > get datapath support upstream? That's a lot of code to add to the 85xx
> > config just for this one chip.
>
> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
> enabled by default given that just one SoC in that family has the
> datapath (and we don't plan to put it in another e500v2 based SoC). For
> regression/automation purposes config fragments should be used
Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
fragment? Do we have any config fragments in the tree so far?
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 23:09 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Pan Lijun-B44306, linuxppc-dev@ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B37817C@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-11-12 at 17:05 -0600, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, November 12, 2013 4:52 PM
> > To: Zang Roy-R61911
> > Cc: Pan Lijun-B44306; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> > mpc85xx_smp_defconfig and mpc85xx_defconfig
> >
> > On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> > > > fei.zang=freescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> > > > Sent: Tuesday, November 12, 2013 4:05 PM
> > > > To: Pan Lijun-B44306
> > > > Cc: linuxppc-dev@ozlabs.org
> > > > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig
> > > > into mpc85xx_smp_defconfig and mpc85xx_defconfig
> > > >
> > > > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> > > > > mpc85xx_smp_defconfig and mpc85xx_defconfig already have
> > > > CONFIG_P1023RDS=y.
> > > > > Merge CONFIG_P1023RDB=y and other relevant configurations into
> > > > mpc85xx_smp_defconfig and mpc85_defconfig.
> > > > >
> > > > > Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> > > > > ---
> > > > > arch/powerpc/configs/85xx/p1023_defconfig | 188
> > > > > --------------------
> > > > --------
> > > > > arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> > > > > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> > > > > 3 files changed, 35 insertions(+), 188 deletions(-) delete mode
> > > > > 100644 arch/powerpc/configs/85xx/p1023_defconfig
> > > >
> > > > Are we still going to want to have one defconfig if and when we
> > > > finally get datapath support upstream? That's a lot of code to add
> > > > to the 85xx config just for this one chip.
> > > P1023 has dpaa.
> > > Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
> >
> > That's the question I'm asking. Though I suppose we could take a patch
> > like this one for now, and then introduce mpc85xx_dpaa_defconfig when it
> > becomes relevant (which would make clear why the defconfig is separate).
> > p1023 would still work with the non-dpaa defconfigs, but without dpaa
> > support.
>
> It will be hard to find a seat for P1023 in mpc85xx_dpaa_defconfig.
What do you mean?
> P1023 does not have corenet. It has e500v2 core.
> All the other DPAA SOCs have corenet.
> I suggest leaving p1023 defconfig standalone.
I didn't say "mpc85xx_corenet_defconfig", nor did I suggest that
mpc85xx_dpaa_defconfig replace corenet32_defconfig. Perhaps
e500v2_dpaa_defconfig would be a better name. It would effectively be a
standalone p1023 defconfig, but with a name that reflects the reason for
it, and which would accommodate future e500v2 dpaa chips in the unlikely
case that such things are made.
Do you know how large the current SDK datapath code is? Though perhaps
the eventual upstream version will be smaller.
-Scott
^ permalink raw reply
* RE: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Roy Zang @ 2013-11-12 23:05 UTC (permalink / raw)
To: Scott Wood; +Cc: Lijun Pan, linuxppc-dev@ozlabs.org
In-Reply-To: <1384296734.1403.72.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgNDo1MiBQTQ0KPiBUbzogWmFu
ZyBSb3ktUjYxOTExDQo+IENjOiBQYW4gTGlqdW4tQjQ0MzA2OyBsaW51eHBwYy1kZXZAb3psYWJz
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFYyXSBwb3dlcnBjLzg1eHg6IE1lcmdlIDg1eHgv
cDEwMjNfZGVmY29uZmlnIGludG8NCj4gbXBjODV4eF9zbXBfZGVmY29uZmlnIGFuZCBtcGM4NXh4
X2RlZmNvbmZpZw0KPiANCj4gT24gVHVlLCAyMDEzLTExLTEyIGF0IDE2OjQ5IC0wNjAwLCBaYW5n
IFJveS1SNjE5MTEgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4gPiBGcm9tOiBMaW51eHBwYy1kZXYgW21haWx0bzpsaW51eHBwYy1kZXYtYm91bmNlcyt0
aWUtDQo+ID4gPiBmZWkuemFuZz1mcmVlc2NhbGUuY29tQGxpc3RzLm96bGFicy5vcmddIE9uIEJl
aGFsZiBPZiBTY290dCBXb29kDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAx
MyA0OjA1IFBNDQo+ID4gPiBUbzogUGFuIExpanVuLUI0NDMwNg0KPiA+ID4gQ2M6IGxpbnV4cHBj
LWRldkBvemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIFYyXSBwb3dlcnBjLzg1
eHg6IE1lcmdlIDg1eHgvcDEwMjNfZGVmY29uZmlnDQo+ID4gPiBpbnRvIG1wYzg1eHhfc21wX2Rl
ZmNvbmZpZyBhbmQgbXBjODV4eF9kZWZjb25maWcNCj4gPiA+DQo+ID4gPiBPbiBNb24sIDIwMTMt
MTEtMTEgYXQgMTM6MjUgLTA2MDAsIExpanVuIFBhbiB3cm90ZToNCj4gPiA+ID4gbXBjODV4eF9z
bXBfZGVmY29uZmlnIGFuZCBtcGM4NXh4X2RlZmNvbmZpZyBhbHJlYWR5IGhhdmUNCj4gPiA+IENP
TkZJR19QMTAyM1JEUz15Lg0KPiA+ID4gPiBNZXJnZSBDT05GSUdfUDEwMjNSREI9eSBhbmQgb3Ro
ZXIgcmVsZXZhbnQgY29uZmlndXJhdGlvbnMgaW50bw0KPiA+ID4gbXBjODV4eF9zbXBfZGVmY29u
ZmlnIGFuZCBtcGM4NV9kZWZjb25maWcuDQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6
IExpanVuIFBhbiA8TGlqdW4uUGFuQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+IC0tLQ0KPiA+ID4g
PiAgYXJjaC9wb3dlcnBjL2NvbmZpZ3MvODV4eC9wMTAyM19kZWZjb25maWcgIHwgIDE4OA0KPiA+
ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0tLS0tLS0NCj4gPiA+ID4gIGFyY2gv
cG93ZXJwYy9jb25maWdzL21wYzg1eHhfZGVmY29uZmlnICAgICB8ICAgMTggKysrDQo+ID4gPiA+
ICBhcmNoL3Bvd2VycGMvY29uZmlncy9tcGM4NXh4X3NtcF9kZWZjb25maWcgfCAgIDE3ICsrKw0K
PiA+ID4gPiAgMyBmaWxlcyBjaGFuZ2VkLCAzNSBpbnNlcnRpb25zKCspLCAxODggZGVsZXRpb25z
KC0pICBkZWxldGUgbW9kZQ0KPiA+ID4gPiAxMDA2NDQgYXJjaC9wb3dlcnBjL2NvbmZpZ3MvODV4
eC9wMTAyM19kZWZjb25maWcNCj4gPiA+DQo+ID4gPiBBcmUgd2Ugc3RpbGwgZ29pbmcgdG8gd2Fu
dCB0byBoYXZlIG9uZSBkZWZjb25maWcgaWYgYW5kIHdoZW4gd2UNCj4gPiA+IGZpbmFsbHkgZ2V0
IGRhdGFwYXRoIHN1cHBvcnQgdXBzdHJlYW0/ICBUaGF0J3MgYSBsb3Qgb2YgY29kZSB0byBhZGQN
Cj4gPiA+IHRvIHRoZSA4NXh4IGNvbmZpZyBqdXN0IGZvciB0aGlzIG9uZSBjaGlwLg0KPiA+IFAx
MDIzIGhhcyBkcGFhLg0KPiA+IFdpbGwgbXBjODV4eF9kZWZjb25maWcgb3IgbXBjODV4eF9zbXBf
ZGVmY29uZmlnIHN1cHBvcnQgZHBhYT8NCj4gDQo+IFRoYXQncyB0aGUgcXVlc3Rpb24gSSdtIGFz
a2luZy4gIFRob3VnaCBJIHN1cHBvc2Ugd2UgY291bGQgdGFrZSBhIHBhdGNoDQo+IGxpa2UgdGhp
cyBvbmUgZm9yIG5vdywgYW5kIHRoZW4gaW50cm9kdWNlIG1wYzg1eHhfZHBhYV9kZWZjb25maWcg
d2hlbiBpdA0KPiBiZWNvbWVzIHJlbGV2YW50ICh3aGljaCB3b3VsZCBtYWtlIGNsZWFyIHdoeSB0
aGUgZGVmY29uZmlnIGlzIHNlcGFyYXRlKS4NCj4gcDEwMjMgd291bGQgc3RpbGwgd29yayB3aXRo
IHRoZSBub24tZHBhYSBkZWZjb25maWdzLCBidXQgd2l0aG91dCBkcGFhDQo+IHN1cHBvcnQuDQoN
Ckl0IHdpbGwgYmUgaGFyZCB0byBmaW5kIGEgc2VhdCBmb3IgUDEwMjMgaW4gbXBjODV4eF9kcGFh
X2RlZmNvbmZpZy4NClAxMDIzIGRvZXMgbm90IGhhdmUgY29yZW5ldC4gIEl0IGhhcyBlNTAwdjIg
Y29yZS4gQWxsIHRoZSAgb3RoZXIgRFBBQSBTT0NzIGhhdmUgY29yZW5ldC4NCkkgc3VnZ2VzdCAg
bGVhdmluZyBwMTAyMyBkZWZjb25maWcgc3RhbmRhbG9uZS4NClJveQ0K
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Emil Medve @ 2013-11-12 22:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1384293891.1403.70.camel__45039.5534084693$1384293935$gmane$org@snotra.buserror.net>
Hello Scott,
On 11/12/2013 04:04 PM, Scott Wood wrote:
> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>
>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>> ---
>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
>> 3 files changed, 35 insertions(+), 188 deletions(-)
>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>
> Are we still going to want to have one defconfig if and when we finally
> get datapath support upstream? That's a lot of code to add to the 85xx
> config just for this one chip.
Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
enabled by default given that just one SoC in that family has the
datapath (and we don't plan to put it in another e500v2 based SoC). For
regression/automation purposes config fragments should be used
Cheers,
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 22:52 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Pan Lijun-B44306, linuxppc-dev@ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B37812C@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> > fei.zang=freescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> > Sent: Tuesday, November 12, 2013 4:05 PM
> > To: Pan Lijun-B44306
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> > mpc85xx_smp_defconfig and mpc85xx_defconfig
> >
> > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> > > mpc85xx_smp_defconfig and mpc85xx_defconfig already have
> > CONFIG_P1023RDS=y.
> > > Merge CONFIG_P1023RDB=y and other relevant configurations into
> > mpc85xx_smp_defconfig and mpc85_defconfig.
> > >
> > > Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> > > ---
> > > arch/powerpc/configs/85xx/p1023_defconfig | 188 --------------------
> > --------
> > > arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> > > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> > > 3 files changed, 35 insertions(+), 188 deletions(-) delete mode
> > > 100644 arch/powerpc/configs/85xx/p1023_defconfig
> >
> > Are we still going to want to have one defconfig if and when we finally
> > get datapath support upstream? That's a lot of code to add to the 85xx
> > config just for this one chip.
> P1023 has dpaa.
> Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
That's the question I'm asking. Though I suppose we could take a patch
like this one for now, and then introduce mpc85xx_dpaa_defconfig when it
becomes relevant (which would make clear why the defconfig is separate).
p1023 would still work with the non-dpaa defconfigs, but without dpaa
support.
-Scott
^ permalink raw reply
* RE: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Roy Zang @ 2013-11-12 22:49 UTC (permalink / raw)
To: Scott Wood, Lijun Pan; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1384293891.1403.70.camel@snotra.buserror.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> Sent: Tuesday, November 12, 2013 4:05 PM
> To: Pan Lijun-B44306
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into
> mpc85xx_smp_defconfig and mpc85xx_defconfig
>=20
> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> > mpc85xx_smp_defconfig and mpc85xx_defconfig already have
> CONFIG_P1023RDS=3Dy.
> > Merge CONFIG_P1023RDB=3Dy and other relevant configurations into
> mpc85xx_smp_defconfig and mpc85_defconfig.
> >
> > Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> > ---
> > arch/powerpc/configs/85xx/p1023_defconfig | 188 --------------------
> --------
> > arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> > 3 files changed, 35 insertions(+), 188 deletions(-) delete mode
> > 100644 arch/powerpc/configs/85xx/p1023_defconfig
>=20
> Are we still going to want to have one defconfig if and when we finally
> get datapath support upstream? That's a lot of code to add to the 85xx
> config just for this one chip.
P1023 has dpaa.
Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa?
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-12 22:04 UTC (permalink / raw)
To: Lijun Pan; +Cc: linuxppc-dev
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>
> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> ---
> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> 3 files changed, 35 insertions(+), 188 deletions(-)
> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
Are we still going to want to have one defconfig if and when we finally
get datapath support upstream? That's a lot of code to add to the 85xx
config just for this one chip.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Scott Wood @ 2013-11-12 21:58 UTC (permalink / raw)
To: shh.xie; +Cc: Shruti, madalin.bucur, linuxppc-dev, linux-kernel, Shaohui Xie
In-Reply-To: <1384167864-2457-1-git-send-email-shh.xie@gmail.com>
On Mon, 2013-11-11 at 19:04 +0800, shh.xie@gmail.com wrote:
> From: Andy Fleming
>
> You need an extra parameter to read or write Clause 45 PHYs, so
> we need a different API with the extra parameter.
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Why did you remove Andy's e-mail address? Even though it's no longer
valid, it helps identify which specific person you're talking about.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
From: Paul Mackerras @ 2013-11-12 21:03 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Aneesh Kumar K.V, kvm@vger.kernel.org
In-Reply-To: <059527B7-DB8B-4A91-AE3B-3ACA834EEFA4@suse.de>
On Tue, Nov 12, 2013 at 07:37:24AM -0500, Alexander Graf wrote:
>
>
> Am 11.11.2013 um 09:08 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>:
>
> > From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> >
> > This patch make sure we inherit the LE bit correctly in different case
> > so that we can run Little Endian distro in PR mode
> >
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> This is not how real hardware works, is it? Could you please point me to the bits in the ISA that indicate that we should preserve the LE bit anywhere? :)
No, it isn't. What we should really be doing depends a bit on what
CPU we're emulating. Older CPUs had an ILE bit in the MSR that got
copied to LE on interrupt. Recent POWER CPUs moved the ILE bit to the
LPCR, so for them we should have an emulated LPCR (and implement
H_SET_MODE for pseries guests so they can control LPCR[ILE]).
Embedded CPUs of course don't have an LE bit, or an ILE bit, since
they control endianness on a per-page basis.
Paul.
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Timur Tabi @ 2013-11-12 20:13 UTC (permalink / raw)
To: Lijun Pan; +Cc: Linuxppc-dev Development
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
On Mon, Nov 11, 2013 at 1:25 PM, Lijun Pan <Lijun.Pan@freescale.com> wrote:
> +CONFIG_P1023_RDB=y
I think this is the only line you should be adding to the defconfigs.
None of the others should be necessary.
^ permalink raw reply
* [PATCH 01/12] powerpc/windfarm: Remove superfluous name casts
From: Geert Uytterhoeven @ 2013-11-12 19:07 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <1384283245-9419-1-git-send-email-geert@linux-m68k.org>
wf_sensor.name is "const char *"
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/macintosh/windfarm_lm75_sensor.c | 2 +-
drivers/macintosh/windfarm_max6690_sensor.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index 9ef32b3df91f..590214ba736c 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -133,7 +133,7 @@ static int wf_lm75_probe(struct i2c_client *client,
lm->inited = 0;
lm->ds1775 = ds1775;
lm->i2c = client;
- lm->sens.name = (char *)name; /* XXX fix constness in structure */
+ lm->sens.name = name;
lm->sens.ops = &wf_lm75_ops;
i2c_set_clientdata(client, lm);
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 945a25b2f31e..87e439b10318 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -95,7 +95,7 @@ static int wf_max6690_probe(struct i2c_client *client,
}
max->i2c = client;
- max->sens.name = (char *)name; /* XXX fix constness in structure */
+ max->sens.name = name;
max->sens.ops = &wf_max6690_ops;
i2c_set_clientdata(client, max);
--
1.7.9.5
^ permalink raw reply related
* Problem reading and programming memory location...
From: neorf3k @ 2013-11-12 19:23 UTC (permalink / raw)
To: Linux Ppc Dev List Dev List
we have tried to read and program an 8bit register with 32bit address. =
we have mapped it with: ioremap, kmalloc etc=85 and then using: outb, =
iowrite8 etc.. but when we write to it, the value doesn=92t change=85 =
with other memory location is ok.
That is an 8 bit register, located at 0x10020000 in a mpc5200b =
architecture. we are using kernel 2.6.33.=20
what could be?
Thank you
Lorenzo=
^ permalink raw reply
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