* RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-03-17 15:49 UTC (permalink / raw)
To: Yoder Stuart-B08248, Kumar Gala
Cc: Wood Scott-B07421, joro@8bytes.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E1503586936@039-SN1MPN1-002.039d.mgd.msft.net>
> -----Original Message-----
> From: Yoder Stuart-B08248
> Sent: Friday, March 15, 2013 2:45 AM
> To: Kumar Gala; Sethi Varun-B16395
> Cc: joro@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> benh@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>=20
>=20
>=20
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Thursday, March 14, 2013 3:20 PM
> > To: Sethi Varun-B16395
> > Cc: joro@8bytes.org; iommu@lists.linux-foundation.org;
> > linuxppc-dev@lists.ozlabs.org; linux- kernel@vger.kernel.org;
> > benh@kernel.crashing.org; Wood Scott-B07421; Yoder Stuart-B08248
> > Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
> >
> >
> > On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
> >
> > > +/*
> > > + * Table of SVRs and the corresponding PORT_ID values.
> > > + *
> > > + * All future CoreNet-enabled SOCs will have this erratum fixed, so
> > > +this table
> > > + * should never need to be updated. SVRs are guaranteed to be
> > > +unique, so
> > > + * there is no worry that a future SOC will inadvertently have one
> > > +of these
> > > + * values.
> > > + */
> >
> > Maybe add to the comment about what port_id represents
>=20
> When you update the comment, I would also suggest identifying the
> specific errata here (A-004510) so that it's easy to reference back to
> the specific issue this code is fixing.
[Sethi Varun-B16395] Ok
-Varun
^ permalink raw reply
* RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-03-17 15:49 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, joro@8bytes.org, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <DF9A711B-63AF-411C-84E4-0C9F61A2EB21@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, March 15, 2013 1:53 AM
> To: Sethi Varun-B16395
> Cc: joro@8bytes.org; linux-kernel@vger.kernel.org; Yoder Stuart-B08248;
> iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>=20
>=20
> On Mar 14, 2013, at 3:20 PM, Kumar Gala wrote:
>=20
> >
> > On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
> >
> >> +/*
> >> + * Table of SVRs and the corresponding PORT_ID values.
> >> + *
> >> + * All future CoreNet-enabled SOCs will have this erratum fixed, so
> >> +this table
> >> + * should never need to be updated. SVRs are guaranteed to be
> >> +unique, so
> >> + * there is no worry that a future SOC will inadvertently have one
> >> +of these
> >> + * values.
> >> + */
> >
> > Maybe add to the comment about what port_id represents
>=20
> also, add reference to the erratum #/id/name
>=20
[Sethi Varun-B16395] Ok.
-Varun
^ permalink raw reply
* RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-03-17 15:48 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <0080B56D-8417-41B9-8341-665457D04DE6@kernel.crashing.org>
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Kumar Gala
> Sent: Friday, March 15, 2013 1:50 AM
> To: Sethi Varun-B16395
> Cc: benh@kernel.crashing.org; linux-kernel@vger.kernel.org; Yoder Stuart-
> B08248; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>=20
>=20
> On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
>=20
> > +/*
> > + * Table of SVRs and the corresponding PORT_ID values.
> > + *
> > + * All future CoreNet-enabled SOCs will have this erratum fixed, so
> > +this table
> > + * should never need to be updated. SVRs are guaranteed to be
> > +unique, so
> > + * there is no worry that a future SOC will inadvertently have one of
> > +these
> > + * values.
> > + */
>=20
> Maybe add to the comment about what port_id represents
>=20
[Sethi Varun-B16395] ok.
> > +static const struct {
> > + u32 svr;
> > + u32 port_id;
> > +} port_id_map[] =3D {
> > + {0x82100010, 0xFF000000}, /* P2040 1.0 */
> > + {0x82100011, 0xFF000000}, /* P2040 1.1 */
> > + {0x82100110, 0xFF000000}, /* P2041 1.0 */
> > + {0x82100111, 0xFF000000}, /* P2041 1.1 */
> > + {0x82110310, 0xFF000000}, /* P3041 1.0 */
> > + {0x82110311, 0xFF000000}, /* P3041 1.1 */
> > + {0x82010020, 0xFFF80000}, /* P4040 2.0 */
> > + {0x82000020, 0xFFF80000}, /* P4080 2.0 */
> > + {0x82210010, 0xFC000000}, /* P5010 1.0 */
> > + {0x82210020, 0xFC000000}, /* P5010 2.0 */
> > + {0x82200010, 0xFC000000}, /* P5020 1.0 */
> > + {0x82050010, 0xFF800000}, /* P5021 1.0 */
> > + {0x82040010, 0xFF800000}, /* P5040 1.0 */
> > +};
> > +
> > +#define SVR_SECURITY 0x80000 /* The Security (E) bit */
> > +
> > +static int __init fsl_pamu_probe(struct platform_device *pdev) {
> > + void __iomem *pamu_regs =3D NULL;
> > + struct ccsr_guts __iomem *guts_regs =3D NULL;
> > + u32 pamubypenr, pamu_counter;
> > + unsigned long pamu_reg_off;
> > + unsigned long pamu_reg_base;
> > + struct pamu_isr_data *data;
> > + struct device_node *guts_node;
> > + u64 size;
> > + struct page *p;
> > + int ret =3D 0;
> > + int irq;
> > + phys_addr_t ppaact_phys;
> > + phys_addr_t spaact_phys;
> > + phys_addr_t omt_phys;
> > + size_t mem_size =3D 0;
> > + unsigned int order =3D 0;
> > + u32 csd_port_id =3D 0;
> > + unsigned i;
> > + /*
> > + * enumerate all PAMUs and allocate and setup PAMU tables
> > + * for each of them,
> > + * NOTE : All PAMUs share the same LIODN tables.
> > + */
> > +
> > + pamu_regs =3D of_iomap(pdev->dev.of_node, 0);
> > + if (!pamu_regs) {
> > + dev_err(&pdev->dev, "ioremap of PAMU node failed\n");
> > + return -ENOMEM;
> > + }
> > + of_get_address(pdev->dev.of_node, 0, &size, NULL);
> > +
> > + irq =3D irq_of_parse_and_map(pdev->dev.of_node, 0);
> > + if (irq =3D=3D NO_IRQ) {
> > + dev_warn(&pdev->dev, "no interrupts listed in PAMU node\n");
> > + goto error;
> > + }
> > +
> > + data =3D kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
> > + if (!data) {
> > + iounmap(pamu_regs);
> > + return -ENOMEM;
> > + }
> > + data->pamu_reg_base =3D pamu_regs;
> > + data->count =3D size / PAMU_OFFSET;
> > +
> > + /* The ISR needs access to the regs, so we won't iounmap them */
> > + ret =3D request_irq(irq, pamu_av_isr, 0, "pamu", data);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "error %i installing ISR for irq %i\n",
> > + ret, irq);
> > + goto error;
> > + }
> > +
> > + guts_node =3D of_find_compatible_node(NULL, NULL,
> > + "fsl,qoriq-device-config-1.0");
>=20
> This doesn't work for T4 or B4 device trees.
>=20
[Sethi Varun-B16395]hmm.... I need to use the dcfg space for this.
> > + if (!guts_node) {
> > + dev_err(&pdev->dev, "could not find GUTS node %s\n",
> > + pdev->dev.of_node->full_name);
> > + ret =3D -ENODEV;
> > + goto error;
> > + }
> > +
> > + guts_regs =3D of_iomap(guts_node, 0);
> > + of_node_put(guts_node);
> > + if (!guts_regs) {
> > + dev_err(&pdev->dev, "ioremap of GUTS node failed\n");
> > + ret =3D -ENODEV;
> > + goto error;
> > + }
> > +
> > + /* read in the PAMU capability registers */
> > + get_pamu_cap_values((unsigned long)pamu_regs);
> > + /*
> > + * To simplify the allocation of a coherency domain, we allocate
> the
> > + * PAACT and the OMT in the same memory buffer. Unfortunately,
> this
> > + * wastes more memory compared to allocating the buffers
> separately.
> > + */
> > + /* Determine how much memory we need */
> > + mem_size =3D (PAGE_SIZE << get_order(PAACT_SIZE)) +
> > + (PAGE_SIZE << get_order(SPAACT_SIZE)) +
> > + (PAGE_SIZE << get_order(OMT_SIZE));
> > + order =3D get_order(mem_size);
> > +
> > + p =3D alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
> > + if (!p) {
> > + dev_err(&pdev->dev, "unable to allocate PAACT/SPAACT/OMT
> block\n");
> > + ret =3D -ENOMEM;
> > + goto error;
> > + }
> > +
> > + ppaact =3D page_address(p);
> > + ppaact_phys =3D page_to_phys(p);
> > +
> > + /* Make sure the memory is naturally aligned */
> > + if (ppaact_phys & ((PAGE_SIZE << order) - 1)) {
> > + dev_err(&pdev->dev, "PAACT/OMT block is unaligned\n");
> > + ret =3D -ENOMEM;
> > + goto error;
> > + }
> > +
> > + spaact =3D (void *)ppaact + (PAGE_SIZE << get_order(PAACT_SIZE));
> > + omt =3D (void *)spaact + (PAGE_SIZE << get_order(SPAACT_SIZE));
> > +
> > + dev_dbg(&pdev->dev, "ppaact virt=3D%p phys=3D0x%llx\n", ppaact,
> > + (unsigned long long) ppaact_phys);
> > +
> > + /* Check to see if we need to implement the work-around on this SOC
> > +*/
> > +
> > + /* Determine the Port ID for our coherence subdomain */
> > + for (i =3D 0; i < ARRAY_SIZE(port_id_map); i++) {
> > + if (port_id_map[i].svr =3D=3D (mfspr(SPRN_SVR) & ~SVR_SECURITY))
> {
> > + csd_port_id =3D port_id_map[i].port_id;
> > + dev_dbg(&pdev->dev, "found matching SVR %08x\n",
> > + port_id_map[i].svr);
> > + break;
> > + }
> > + }
> > +
> > + if (csd_port_id) {
> > + dev_dbg(&pdev->dev, "creating coherency subdomain at address
> "
> > + "0x%llx, size %zu, port id 0x%08x", ppaact_phys,
> > + mem_size, csd_port_id);
> > +
> > + ret =3D create_csd(ppaact_phys, mem_size, csd_port_id);
> > + if (ret) {
> > + dev_err(&pdev->dev, "could not create coherence "
> > + "subdomain\n");
> > + return ret;
> > + }
> > + }
> > +
> > + spaact_phys =3D virt_to_phys(spaact);
> > + omt_phys =3D virt_to_phys(omt);
> > +
> > + spaace_pool =3D gen_pool_create(ilog2(sizeof(struct paace)), -1);
> > + if (!spaace_pool) {
> > + ret =3D -ENOMEM;
> > + dev_err(&pdev->dev, "PAMU : failed to allocate spaace gen
> pool\n");
> > + goto error;
> > + }
> > +
> > + ret =3D gen_pool_add(spaace_pool, (unsigned long)spaact, SPAACT_SIZE,
> -1);
> > + if (ret)
> > + goto error_genpool;
> > +
> > + pamubypenr =3D in_be32(&guts_regs->pamubypenr);
> > +
> > + for (pamu_reg_off =3D 0, pamu_counter =3D 0x80000000; pamu_reg_off <
> size;
> > + pamu_reg_off +=3D PAMU_OFFSET, pamu_counter >>=3D 1) {
> > +
> > + pamu_reg_base =3D (unsigned long) pamu_regs + pamu_reg_off;
> > + setup_one_pamu(pamu_reg_base, pamu_reg_off, ppaact_phys,
> > + spaact_phys, omt_phys);
> > + /* Disable PAMU bypass for this PAMU */
> > + pamubypenr &=3D ~pamu_counter;
> > + }
> > +
> > + setup_omt(omt);
> > +
> > + /* Enable all relevant PAMU(s) */
> > + out_be32(&guts_regs->pamubypenr, pamubypenr);
> > +
> > + iounmap(guts_regs);
> > +
> > + /* Enable DMA for the LIODNs in the device tree*/
> > +
> > + setup_liodns();
> > +
> > + return 0;
> > +
> > +error_genpool:
> > + gen_pool_destroy(spaace_pool);
> > +
> > +error:
> > + if (irq !=3D NO_IRQ)
> > + free_irq(irq, 0);
>=20
> Should be:
>=20
> free_irq(irq, data);
>=20
[Sethi Varun-B16395] Yes.
> > +
> > + if (pamu_regs)
> > + iounmap(pamu_regs);
> > +
> > + if (guts_regs)
> > + iounmap(guts_regs);
> > +
> > + if (ppaact)
> > + free_pages((unsigned long)ppaact, order);
> > +
> > + ppaact =3D NULL;
> > +
>=20
> you alloc data, shouldn't you free it ?
>=20
[Sethi Varun-B16395] Yes.
-Varun
^ permalink raw reply
* Re: Kernel panic on PowerMac G5 while scanning for SMU sensors
From: Phileas Fogg @ 2013-03-17 12:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5145B20C.2090104@mail.ru>
On 03/17/2013 01:07 PM, Phileas Fogg wrote:
>
> I wanted to read the temperature sensors of my PowerMac G5 11,2.
> For that i installed the lm-sensors package, run 'sensors-detect'
> command and my Linux 3.8.2 kernel paniced in
>
> _smu_i2c_low_completion_
>
> with this message
>
> 'Unable to handle kernel paging request for data at address 0x00000008.'
>
> Regards
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
A further analysis showed that it crashes in _smu_i2c_complete_command_
which is called from _smu_i2c_low_completion_.
This line caused the panic:
list_del(&cmd->link);
regards
^ permalink raw reply
* Kernel panic on PowerMac G5 while scanning for SMU sensors
From: Phileas Fogg @ 2013-03-17 12:07 UTC (permalink / raw)
To: linuxppc-dev
I wanted to read the temperature sensors of my PowerMac G5 11,2.
For that i installed the lm-sensors package, run 'sensors-detect'
command and my Linux 3.8.2 kernel paniced in
_smu_i2c_low_completion_
with this message
'Unable to handle kernel paging request for data at address 0x00000008.'
Regards
^ permalink raw reply
* Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
From: Johannes Berg @ 2013-03-15 15:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1363279961.28440.4@snotra>
On Thu, 2013-03-14 at 11:52 -0500, Scott Wood wrote:
> > > +#ifdef CONFIG_PPC_BOOK3S_64
> > > /* can't use RESTORE_SPECIAL(MSR) */
> > > ld r0, SL_MSR(r11)
> > > mtmsrd r0, 0
> >
> > Unfortunately, I forgot the reason for this comment, and didn't put a
> > better one (almost 6 years ago!!)
> If it's because book3s needs mtmsrd instead of mtmsr, that doesn't
> apply to booke.
Indeed, looking at the code again now that seems pretty obvious.
Looking at the patch again, I'd be a little concerned about the lack of
cache flushing, seems a bit odd but I'm sure you know what you're doing
(and I don't know book3e at all, and hardly remember book3s -- or even
that name...) :-)
johannes
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Benjamin Herrenschmidt @ 2013-03-16 5:37 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, Alex Williamson, linuxppc-dev, kvm
In-Reply-To: <20130316013417.GA3873@shangw.(null)>
On Sat, 2013-03-16 at 09:34 +0800, Gavin Shan wrote:
> >Could you explain further how this will be used? How the device is
> >exposed to a guest is entirely a userspace construct, so why does vfio
> >need to know or care about this? I had assumed for AER that QEMU would
> >do the translation from host to guest address space.
> >
>
> The weak IOCTL function (vfio_pci_arch_ioctl) was introduced by previous
> patch. The PowerNV platform is going to override it to figure out the
> information for EEH core to use. On the other hand, QEMU will runs into
> the IOCTL command while opening (creating) one VFIO device.
>
> Though I'm not familiar with AER very much. AER is quite different from
> EEH. The EEH functionality implemented in PHB instead of in PCI device
> core. So we don't care AER stuff in EEH directly :-)
To give Alex a bit more background...
EEH is our IBM specific error handling facility which is a superset of AER.
IE. In addition to AER's error detection and logging, it adds a layer of
error detection at the host bridge level (such as iommu violations etc...)
and a mechanism for handling and recovering from errors. This is tied to
our iommu domain stuff (our PE's) and our device "freezing" capability
among others.
With VFIO + KVM, we want to implement most of the EEH support for guests in
the host kernel. The reason is multipart and we can discuss this separately
as some of it might well be debatable (mostly it's more convenient that way
because we hook into the underlying HW/FW EEH which isn't directly userspace
accessible so we don't have to add a new layer of kernel -> user API in
addition to the VFIO stuff), but there's at least one aspect of it that drives
this requirement more strongly which is performance:
When EEH is enabled, whenever any MMIO returns all 1's, the kernel will do
a firmware call to query the EEH state of the device and check whether it
has been frozen. On some devices, that can be a performance issue, and
going all the way to qemu for that would be horribly expensive.
So we want at least a way to handle that call in the kernel and for that we
need at least some way of mapping things there.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Benjamin Herrenschmidt @ 2013-03-16 5:30 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363376468.16793.18.camel@ul30vt.home>
On Fri, 2013-03-15 at 13:41 -0600, Alex Williamson wrote:
>
> This basically gives userspace free access to any regions that aren't
> covered by known capabilities.
And ?
I mean seriously :-) We already had that discussion ... trying to
"protect" config space is just plain doomed. There is no point.
It makes sense to do things like emulate BARs etc... for things to
function properly under some circumstances/setups where you can't just
expose the original BAR values to the guest and have the HW take care of
it but you *must* be prepared to deal with anything in config space
being changed without you knowing about it.
Devices *will* have backdoors via MMIO. Period. You cannot rely on those
not existing, whether they are documented or not.
If you can't cope with the config space accesses then you aren't
properly isolated. It can be deemed acceptable (depends what you use
your VMs for) but that I mean is that any config space
filtering/emulation for the sake of "security" is ... pointless.
Doing it for functionality to work at all (ie BAR emulation) is fine,
but that's about it. IE. As a mean of security it's pointless.
> We have no idea what this might expose on some devices.
No more than we have any idea what MMIO mapping of the device register
space exposes :-)
> I'd like to support be2net, but what's the minimal
> access that it needs? Can we provide 2 or 4 bytes of read-only access
> at offset 0x7c for just that device? Is it always 0x7c? Let's split
> this patch from the series since it's clearly dealing with something
> independent. Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Gavin Shan @ 2013-03-16 3:34 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363376468.16793.18.camel@ul30vt.home>
On Fri, Mar 15, 2013 at 01:41:08PM -0600, Alex Williamson wrote:
>On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
>> The config registers in [0, 0x40] is being supported by VFIO. Apart
>> from that, the other config registers should be coverred by PCI or
>> PCIe capability. However, there might have some PCI devices (be2net)
>> who has config registers (0x7c) out of [0, 0x40], and don't have
>> corresponding PCI or PCIe capability. VFIO will return 0x0 on reading
>> those registers and writing is dropped. It caused the be2net driver
>> fails to be loaded because 0x0 returned from its config register 0x7c.
>>
>> The patch changes the behaviour so that those config registers out
>> of [0, 0x40] and don't have corresponding PCI or PCIe capability
>> will be accessed directly.
>
>This basically gives userspace free access to any regions that aren't
>covered by known capabilities. We have no idea what this might expose
>on some devices. I'd like to support be2net, but what's the minimal
>access that it needs? Can we provide 2 or 4 bytes of read-only access
>at offset 0x7c for just that device? Is it always 0x7c? Let's split
>this patch from the series since it's clearly dealing with something
>independent. Thanks,
>
0x7c is just one example. Actually, benet driver also need access other
uncoverred config registers like 0x58/0xf0/0xfc (by capabilities) in orde
to make the device work well. All of those uncoverred config registers
are really business of specific device itself. I think we might not bother
their accessing attributes. So exporting those uncoverred registers to
user space might be the reasonable choice.
If we really want to control the accessing attributes for those uncoverred
registers, we might introduce some mechanism to check the vendor/device ID
and read/write to the uncoverred registers according the specified bits.
All of that requires fully understanding the usage of those uncoverred registers.
Yes, I will split this one from the patchset.
Thanks,
Gavin
>> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>> ---
>> drivers/vfio/pci/vfio_pci_config.c | 31 ++++++++++++++++++++-----------
>> 1 files changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
>> index 964ff22..5ea3afb 100644
>> --- a/drivers/vfio/pci/vfio_pci_config.c
>> +++ b/drivers/vfio/pci/vfio_pci_config.c
>> @@ -1471,18 +1471,27 @@ static ssize_t vfio_config_do_rw(struct vfio_pci_device *vdev, char __user *buf,
>>
>> cap_id = vdev->pci_config_map[*ppos / 4];
>>
>> + /*
>> + * Some PCI device config registers might not be coverred by
>> + * capability and useful. We will enable direct access to
>> + * those registers.
>> + */
>> if (cap_id == PCI_CAP_ID_INVALID) {
>> - if (iswrite)
>> - return ret; /* drop */
>> -
>> - /*
>> - * Per PCI spec 3.0, section 6.1, reads from reserved and
>> - * unimplemented registers return 0
>> - */
>> - if (copy_to_user(buf, &val, count))
>> - return -EFAULT;
>> -
>> - return ret;
>> + if (iswrite) {
>> + if (copy_from_user(&val, buf, count))
>> + return -EFAULT;
>> + ret = vfio_user_config_write(vdev->pdev, (int)(*ppos),
>> + val, count);
>> + return ret ? ret : count;
>> + } else {
>> + ret = vfio_user_config_read(vdev->pdev, (int)(*ppos),
>> + &val, count);
>> + if (ret)
>> + return ret;
>> + if (copy_to_user(buf, &val, count))
>> + return -EFAULT;
>> + return count;
>> + }
>> }
>>
>> /*
>
>
>
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Gavin Shan @ 2013-03-16 1:34 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363375740.16793.12.camel@ul30vt.home>
On Fri, Mar 15, 2013 at 01:29:00PM -0600, Alex Williamson wrote:
>On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
>> The address (domain/bus/slot/function) of the passed PCI device
>> looks quite different from perspective of host and guest. Some
>> architectures like PPC need to setup the mapping in host. The patch
>> introduces additional VFIO device IOCTL command to address that.
>
>Could you explain further how this will be used? How the device is
>exposed to a guest is entirely a userspace construct, so why does vfio
>need to know or care about this? I had assumed for AER that QEMU would
>do the translation from host to guest address space.
>
The weak IOCTL function (vfio_pci_arch_ioctl) was introduced by previous
patch. The PowerNV platform is going to override it to figure out the
information for EEH core to use. On the other hand, QEMU will runs into
the IOCTL command while opening (creating) one VFIO device.
Though I'm not familiar with AER very much. AER is quite different from
EEH. The EEH functionality implemented in PHB instead of in PCI device
core. So we don't care AER stuff in EEH directly :-)
>> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>> ---
>> include/uapi/linux/vfio.h | 16 ++++++++++++++++
>> 1 files changed, 16 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 6e58d9b..ecc4f38 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -289,6 +289,22 @@ struct vfio_irq_set {
>> */
>> #define VFIO_DEVICE_RESET _IO(VFIO_TYPE, VFIO_BASE + 11)
>>
>> +/**
>> + * VFIO_DEVICE_SET_ADDR_MAPPING - _IO(VFIO_TYPE, VFIO_BASE + 12)
>> + *
>> + * The address, which comprised of domain/bus/slot/function looks
>> + * different between host and guest. We need to setup the mapping
>> + * in host for some architectures like PPC so that the passed PCI
>> + * devices could support RTAS smoothly.
>> + */
>> +struct vfio_addr_mapping {
>> + __u64 buid;
>
>What's a buid? Thanks,
>
BUID means "Bus Unit Identifier". BUID is the identifier for specific PHB.
Firmware figures it out and expose to OS through device-tree. For VFIO case,
the QEMU figures it out and expose to guest eventually. It's notable that
the PHB (including buid) figured out by QEMU is virtual and something like
container :-)
>> + __u8 bus;
>> + __u8 slot;
>> + __u8 func;
>> +};
>> +#define VFIO_DEVICE_SET_ADDR_MAPPING _IO(VFIO_TYPE, VFIO_BASE + 12)
>> +
>> /*
>> * The VFIO-PCI bus driver makes use of the following fixed region and
>> * IRQ index mapping. Unimplemented regions return a size of zero.
>
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/fsl-booke: Add initial B4420QDS board device tree
From: Kumar Gala @ 2013-03-15 20:31 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: linuxppc-dev
In-Reply-To: <1363334109-21922-4-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/boot/dts/b4420qds.dts | 168 =
++++++++++++++++++++++++++++++++++++
> 1 files changed, 168 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/b4420qds.dts
If B4420 and B4860 qds are same board, refactor this into a b4qds.dtsi =
file for common board features like NOR, NAND, SPI, SDHC, etc.
- k=
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/fsl-booke: Add initial silicon device tree files for B4420QDS
From: Kumar Gala @ 2013-03-15 20:30 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: Andy Fleming, linuxppc-dev, Zhao Chenhui
In-Reply-To: <1363334109-21922-3-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 151 =
+++++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 70 ++++++++++++
> 2 files changed, 221 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
Similar comments to B4860 dts files.
- k=
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree files for B4860QDS
From: Kumar Gala @ 2013-03-15 20:29 UTC (permalink / raw)
To: Shaveta Leekha
Cc: Zhao Chenhui, Minghuan Lian, Tang Yuantian, Andy Fleming,
Ramneek Mehresh, Varun Sethi, linuxppc-dev
In-Reply-To: <1363334109-21922-1-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 184 =
+++++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 80 ++++++++++++
> 2 files changed, 264 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
* SEC node is missing
* DCSR nodes are missing.
- k
>=20
> diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi =
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> new file mode 100644
> index 0000000..2db68b2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> @@ -0,0 +1,184 @@
> +/*
> + * B4860 Silicon/SoC Device Tree Source (post include)
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions =
are met:
> + * * Redistributions of source code must retain the above =
copyright
> + * notice, this list of conditions and the following =
disclaimer.
> + * * Redistributions in binary form must reproduce the above =
copyright
> + * notice, this list of conditions and the following disclaimer =
in the
> + * documentation and/or other materials provided with the =
distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote =
products
> + * derived from this software without specific prior written =
permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of =
the
> + * GNU General Public License ("GPL") as published by the Free =
Software
> + * Foundation, either version 2 of that License or (at your option) =
any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND =
ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE =
IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE =
ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE =
FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL =
DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR =
SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER =
CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, =
OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE =
USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +&ifc {
> + #address-cells =3D <2>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc", "simple-bus";
> + interrupts =3D <25 2 0 0>;
> +};
> +
> +/* controller at 0x200000 */
> +&pci0 {
> + compatible =3D "fsl,b4860-pcie", "fsl,qoriq-pcie-v2.4";
> + device_type =3D "pci";
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + bus-range =3D <0x0 0xff>;
> + interrupts =3D <20 2 0 0>;
> + pcie@0 {
> + #interrupt-cells =3D <1>;
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + device_type =3D "pci";
> + interrupts =3D <20 2 0 0>;
> + interrupt-map-mask =3D <0xf800 0 0 7>;
> + interrupt-map =3D <
> + /* IDSEL 0x0 */
> + 0000 0 0 1 &mpic 40 1 0 0
> + 0000 0 0 2 &mpic 1 1 0 0
> + 0000 0 0 3 &mpic 2 1 0 0
> + 0000 0 0 4 &mpic 3 1 0 0
> + >;
> + };
> +};
> +
> +&rio {
> + compatible =3D "fsl,srio";
> + interrupts =3D <16 2 1 11>;
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + ranges;
> +
> + port1 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <1>;
> + };
> +
> + port2 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <2>;
> + };
> +};
> +
> +&soc {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + device_type =3D "soc";
> + compatible =3D "simple-bus";
> +
> + soc-sram-error {
> + compatible =3D "fsl,soc-sram-error";
> + interrupts =3D <16 2 1 2>;
> + };
> +
> + corenet-law@0 {
> + compatible =3D "fsl,corenet-law";
> + reg =3D <0x0 0x1000>;
> + fsl,num-laws =3D <32>;
> + };
> +
> + ddr1: memory-controller@8000 {
> + compatible =3D "fsl,qoriq-memory-controller-v4.5", =
"fsl,qoriq-memory-controller";
> + reg =3D <0x8000 0x1000>;
> + interrupts =3D <16 2 1 8>;
> + };
> +
> + ddr2: memory-controller@9000 {
> + compatible =3D =
"fsl,qoriq-memory-controller-v4.5","fsl,qoriq-memory-controller";
> + reg =3D <0x9000 0x1000>;
> + interrupts =3D <16 2 1 9>;
> + };
> +
> + cpc: l3-cache-controller@10000 {
> + compatible =3D "fsl,p5020-l3-cache-controller", =
"fsl,p4080-l3-cache-controller", "cache";
> + reg =3D <0x10000 0x1000
> + 0x11000 0x1000>;
> + interrupts =3D <16 2 1 4
> + 16 2 1 5>;
> + };
> +
> + corenet-cf@18000 {
> + compatible =3D "fsl,corenet-cf";
> + reg =3D <0x18000 0x1000>;
> + interrupts =3D <16 2 1 0>;
> + fsl,ccf-num-csdids =3D <32>;
> + fsl,ccf-num-snoopids =3D <32>;
> + };
> +
> + iommu@20000 {
> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
> + reg =3D <0x20000 0x4000>;
> + interrupts =3D <
> + 24 2 0 0
> + 16 2 1 1>;
> + };
> +
> +/include/ "qoriq-mpic.dtsi"
> +
> + guts: global-utilities@e0000 {
> + compatible =3D "fsl,b4860-device-config";
> + reg =3D <0xe0000 0xe00>;
> + fsl,has-rstcr;
> + fsl,liodn-bits =3D <12>;
> + };
> +
> + clockgen: global-utilities@e1000 {
> + compatible =3D "fsl,b4860-clockgen", =
"fsl,qoriq-clockgen-2";
> + reg =3D <0xe1000 0x1000>;
> + };
> +
> + rcpm: global-utilities@e2000 {
> + compatible =3D "fsl,b4860-rcpm", "fsl,qoriq-rcpm-2";
> + reg =3D <0xe2000 0x1000>;
> + };
> +
> +/include/ "qoriq-dma-0.dtsi"
> +/include/ "qoriq-dma-1.dtsi"
> +
> +/include/ "qonverge-usb2-dr-0.dtsi"
> + usb0: usb@210000 {
> + compatible =3D "fsl-usb2-dr-v2.4", "fsl-usb2-dr";
> + };
> +
> +/include/ "qoriq-espi-0.dtsi"
> + spi@110000 {
> + fsl,espi-num-chipselects =3D <4>;
> + };
> +
> +/include/ "qoriq-esdhc-0.dtsi"
> + sdhc@114000 {
> + sdhci,auto-cmd12;
> + };
> +/include/ "qoriq-i2c-0.dtsi"
> +/include/ "qoriq-i2c-1.dtsi"
> +/include/ "qoriq-duart-0.dtsi"
> +/include/ "qoriq-duart-1.dtsi"
> +
> + L2: l2-cache-controller@c20000 {
> + next-level-cache =3D <&cpc>;
should have compatible & reg nodes
> + };
> +};
[ snip ]
- k=
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board device tree
From: Kumar Gala @ 2013-03-15 20:26 UTC (permalink / raw)
To: Shaveta Leekha
Cc: Minghuan Lian, linuxppc-dev, Andy Fleming, Poonam Aggrwal,
Ramneek Mehresh
In-Reply-To: <1363334109-21922-2-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/b4860qds.dts | 178 =
++++++++++++++++++++++++++++++++++++
> 1 files changed, 178 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/b4860qds.dts
>=20
> diff --git a/arch/powerpc/boot/dts/b4860qds.dts =
b/arch/powerpc/boot/dts/b4860qds.dts
> new file mode 100644
> index 0000000..ae6ac05
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/b4860qds.dts
> @@ -0,0 +1,178 @@
> +/*
> + * B4860DS Device Tree Source
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions =
are met:
> + * * Redistributions of source code must retain the above =
copyright
> + * notice, this list of conditions and the following =
disclaimer.
> + * * Redistributions in binary form must reproduce the above =
copyright
> + * notice, this list of conditions and the following disclaimer =
in the
> + * documentation and/or other materials provided with the =
distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote =
products
> + * derived from this software without specific prior written =
permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of =
the
> + * GNU General Public License ("GPL") as published by the Free =
Software
> + * Foundation, either version 2 of that License or (at your option) =
any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND =
ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE =
IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE =
ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE =
FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL =
DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR =
SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER =
CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, =
OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE =
USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/include/ "fsl/b4860si-pre.dtsi"
> +
> +/ {
> + model =3D "fsl,B4860QDS";
> + compatible =3D "fsl,B4860QDS";
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + interrupt-parent =3D <&mpic>;
> +
> + ifc: localbus@ffe124000 {
> + reg =3D <0xf 0xfe124000 0 0x2000>;
> + ranges =3D <0 0 0xf 0xe8000000 0x08000000
> + 2 0 0xf 0xff800000 0x00010000
> + 3 0 0xf 0xffdf0000 0x00008000>;
> +
> + nor@0,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "cfi-flash";
> + reg =3D <0x0 0x0 0x8000000>;
> + bank-width =3D <2>;
> + device-width =3D <1>;
> + };
> +
> + nand@2,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc-nand";
> + reg =3D <0x2 0x0 0x10000>;
> +
> + partition@0 {
> + /* This location must not be altered */
> + /* 1MB for u-boot Bootloader Image */
> + reg =3D <0x0 0x00100000>;
> + label =3D "NAND U-Boot Image";
> + read-only;
> + };
> +
> + partition@100000 {
> + /* 1MB for DTB Image */
> + reg =3D <0x00100000 0x00100000>;
> + label =3D "NAND DTB Image";
> + };
> +
> + partition@200000 {
> + /* 10MB for Linux Kernel Image */
> + reg =3D <0x00200000 0x00A00000>;
> + label =3D "NAND Linux Kernel Image";
> + };
> +
> + partition@c00000 {
> + /* 500MB for Root file System Image */
> + reg =3D <0x00c00000 0x1F400000>;
> + label =3D "NAND RFS Image";
> + };
> + };
> +
> + board-control@3,0 {
> + compatible =3D "fsl,b4860qds-fpga", =
"fsl,fpga-qixis";
> + reg =3D <3 0 0x300>;
> + };
> + };
> +
dscr nodes are missing and should be included
> + memory {
> + device_type =3D "memory";
> + };
> +
> + soc: soc@ffe000000 {
> + ranges =3D <0x00000000 0xf 0xfe000000 0x1000000>;
> + reg =3D <0xf 0xfe000000 0 0x00001000>;
> + spi@110000 {
> + flash@0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "sst,sst25wf040";
> + reg =3D <0>;
> + spi-max-frequency =3D <40000000>; /* =
input clock */
> + };
> + };
> +
> + sdhc@114000 {
> + status =3D "disabled";
> + };
> +
> + i2c@118000 {
> + eeprom@50 {
> + compatible =3D "at24,24c64";
> + reg =3D <0x50>;
> + };
> + eeprom@51 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x51>;
> + };
> + eeprom@53 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x53>;
> + };
> + eeprom@57 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x57>;
> + };
> + rtc@68 {
> + compatible =3D "dallas,ds3232";
> + reg =3D <0x68>;
> + interrupts =3D <0x1 0x1 0 0>;
there is no IRQ for RTC on the board.
> + };
> + };
> +
> + usb@210000 {
> + dr_mode =3D "host";
> + phy_type =3D "ulpi";
> + };
> +
> + };
> +
> + pci0: pcie@ffe200000 {
> + reg =3D <0xf 0xfe200000 0 0x10000>;
> + ranges =3D <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 =
0x20000000
> + 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 =
0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x20000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +
> + rio: rapidio@ffe0c0000 {
> + reg =3D <0xf 0xfe0c0000 0 0x11000>;
> +
> + port1 {
> + ranges =3D <0 0 0xc 0x20000000 0 0x10000000>;
> + };
> + port2 {
> + ranges =3D <0 0 0xc 0x30000000 0 0x10000000>;
> + };
> + };
> +
> +};
> +
> +/include/ "fsl/b4860si-post.dtsi"
> --=20
> 1.7.6.GIT
>=20
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Alex Williamson @ 2013-03-15 19:41 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, linuxppc-dev, kvm
In-Reply-To: <1363332390-12754-4-git-send-email-shangw@linux.vnet.ibm.com>
On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
> The config registers in [0, 0x40] is being supported by VFIO. Apart
> from that, the other config registers should be coverred by PCI or
> PCIe capability. However, there might have some PCI devices (be2net)
> who has config registers (0x7c) out of [0, 0x40], and don't have
> corresponding PCI or PCIe capability. VFIO will return 0x0 on reading
> those registers and writing is dropped. It caused the be2net driver
> fails to be loaded because 0x0 returned from its config register 0x7c.
>
> The patch changes the behaviour so that those config registers out
> of [0, 0x40] and don't have corresponding PCI or PCIe capability
> will be accessed directly.
This basically gives userspace free access to any regions that aren't
covered by known capabilities. We have no idea what this might expose
on some devices. I'd like to support be2net, but what's the minimal
access that it needs? Can we provide 2 or 4 bytes of read-only access
at offset 0x7c for just that device? Is it always 0x7c? Let's split
this patch from the series since it's clearly dealing with something
independent. Thanks,
Alex
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> drivers/vfio/pci/vfio_pci_config.c | 31 ++++++++++++++++++++-----------
> 1 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> index 964ff22..5ea3afb 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c
> @@ -1471,18 +1471,27 @@ static ssize_t vfio_config_do_rw(struct vfio_pci_device *vdev, char __user *buf,
>
> cap_id = vdev->pci_config_map[*ppos / 4];
>
> + /*
> + * Some PCI device config registers might not be coverred by
> + * capability and useful. We will enable direct access to
> + * those registers.
> + */
> if (cap_id == PCI_CAP_ID_INVALID) {
> - if (iswrite)
> - return ret; /* drop */
> -
> - /*
> - * Per PCI spec 3.0, section 6.1, reads from reserved and
> - * unimplemented registers return 0
> - */
> - if (copy_to_user(buf, &val, count))
> - return -EFAULT;
> -
> - return ret;
> + if (iswrite) {
> + if (copy_from_user(&val, buf, count))
> + return -EFAULT;
> + ret = vfio_user_config_write(vdev->pdev, (int)(*ppos),
> + val, count);
> + return ret ? ret : count;
> + } else {
> + ret = vfio_user_config_read(vdev->pdev, (int)(*ppos),
> + &val, count);
> + if (ret)
> + return ret;
> + if (copy_to_user(buf, &val, count))
> + return -EFAULT;
> + return count;
> + }
> }
>
> /*
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Alex Williamson @ 2013-03-15 19:29 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, linuxppc-dev, kvm
In-Reply-To: <1363332390-12754-3-git-send-email-shangw@linux.vnet.ibm.com>
On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
> The address (domain/bus/slot/function) of the passed PCI device
> looks quite different from perspective of host and guest. Some
> architectures like PPC need to setup the mapping in host. The patch
> introduces additional VFIO device IOCTL command to address that.
Could you explain further how this will be used? How the device is
exposed to a guest is entirely a userspace construct, so why does vfio
need to know or care about this? I had assumed for AER that QEMU would
do the translation from host to guest address space.
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> include/uapi/linux/vfio.h | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 6e58d9b..ecc4f38 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -289,6 +289,22 @@ struct vfio_irq_set {
> */
> #define VFIO_DEVICE_RESET _IO(VFIO_TYPE, VFIO_BASE + 11)
>
> +/**
> + * VFIO_DEVICE_SET_ADDR_MAPPING - _IO(VFIO_TYPE, VFIO_BASE + 12)
> + *
> + * The address, which comprised of domain/bus/slot/function looks
> + * different between host and guest. We need to setup the mapping
> + * in host for some architectures like PPC so that the passed PCI
> + * devices could support RTAS smoothly.
> + */
> +struct vfio_addr_mapping {
> + __u64 buid;
What's a buid? Thanks,
Alex
> + __u8 bus;
> + __u8 slot;
> + __u8 func;
> +};
> +#define VFIO_DEVICE_SET_ADDR_MAPPING _IO(VFIO_TYPE, VFIO_BASE + 12)
> +
> /*
> * The VFIO-PCI bus driver makes use of the following fixed region and
> * IRQ index mapping. Unimplemented regions return a size of zero.
^ permalink raw reply
* Re: [PATCH 3/4 v2] net: mvmdio: enhance driver to support SMI error/done interrupts
From: Russell King - ARM Linux @ 2013-03-15 18:05 UTC (permalink / raw)
To: Florian Fainelli
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, linux-doc,
devicetree-discuss, linux-kernel, Rob Herring, netdev,
Paul Mackerras, linux-arm-kernel, Rob Landley, Greg Kroah-Hartman,
linuxppc-dev, davem, Lennert Buytenhek
In-Reply-To: <1363284515-9865-4-git-send-email-florian@openwrt.org>
On Thu, Mar 14, 2013 at 07:08:34PM +0100, Florian Fainelli wrote:
> + if (dev->err_interrupt == NO_IRQ) {
...
> + init_waitqueue_head(&dev->smi_busy_wait);
> +
> + dev->err_interrupt = platform_get_irq(pdev, 0);
> + if (dev->err_interrupt != -ENXIO) {
...
> + } else
> + dev->err_interrupt = NO_IRQ;
FYI, NO_IRQ is not supposed to be used anymore (we're supposed to be
removing it). platform_get_irq() returns negative numbers for failure,
so why not test for < 0 in both the above tests, or maybe <= 0 (as
IRQ0 is also not supposed to be valid.)?
^ permalink raw reply
* [PATCH 1/9] powerpc,kvm: fix imbalance srcu_read_[un]lock()
From: Lai Jiangshan @ 2013-03-15 16:50 UTC (permalink / raw)
To: Paul E. McKenney, Andrew Morton, linux-kernel
Cc: Lai Jiangshan, Gleb Natapov, Marcelo Tosatti, Alexander Graf,
kvm-ppc, Paul Mackerras, kvm, linuxppc-dev
In-Reply-To: <1363366257-4886-1-git-send-email-laijs@cn.fujitsu.com>
At the point of up_out label in kvmppc_hv_setup_htab_rma(),
srcu read lock is still held.
We have to release it before return.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: kvm@vger.kernel.org
Cc: kvm-ppc@vger.kernel.org
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 80dcc53..c26740e 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1799,7 +1799,7 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu)
up_out:
up_read(¤t->mm->mmap_sem);
- goto out;
+ goto out_srcu;
}
int kvmppc_core_init_vm(struct kvm *kvm)
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
From: Scott Wood @ 2013-03-15 16:34 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, David Laight, linuxppc-dev@lists.ozlabs.org,
Stuart Yoder
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01C18FD6@039-SN1MPN1-003.039d.mgd.msft.net>
On 03/14/2013 09:47:58 PM, Jia Hongtao-B38951 wrote:
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, March 14, 2013 12:38 AM
> > To: David Laight
> > Cc: Jia Hongtao-B38951; Wood Scott-B07421; =20
> linuxppc-dev@lists.ozlabs.org;
> > Stuart Yoder
> > Subject: Re: [PATCH V4] powerpc/85xx: Add machine check handler to =20
> fix
> > PCIe erratum on mpc85xx
> >
> > On 03/13/2013 04:40:40 AM, David Laight wrote:
> > > > Hmm, seems there's no probe_user_address() -- for userspace we
> > > > basically want the same thing minus the KERNEL_DS. See
> > > > arch/powerpc/perf/callchain.c for an example.
> > >
> > > Isn't that just copy_from_user() ?
> >
> > Plus pagefault_disable/enable().
> >
> > -Scott
>=20
> pagefault_disable() is identical to preempt_disable(). So I think this
> could not avoid other cpu to swap out the instruction we want to read =20
> back.
> probe_kernel_address() also have the same issue.
That's not the point -- the point is to let the page fault handler know =20
that it should go directly to bad_page_fault(). Do not pass =20
handle_mm_fault(). Do not collect a page from disk.
Granted, we're already in atomic context which will have that effect =20
due to being in the machine check handler, but it's better to be =20
explicit about it and not depend on how pagefault_diasble() is =20
implemented.
-Scott=
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Add platform_device declaration to fsl_pci.h
From: Kumar Gala @ 2013-03-15 16:17 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev, b38951
In-Reply-To: <1363328098-20343-1-git-send-email-hongtao.jia@freescale.com>
On Mar 15, 2013, at 1:14 AM, Jia Hongtao wrote:
> mpc85xx_pci_err_probe(struct platform_device *op) need platform_device
> declaration for definition. Otherwise, it will cause compile error if =
any
> files including fsl_pci.h without declaration of platform_device.
>=20
> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> ---
> Changes for V2:
> - Just declare platform_device instead of including =
<linux/platform_device.h>
>=20
> arch/powerpc/sysdev/fsl_pci.h | 2 ++
> 1 file changed, 2 insertions(+)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: remove "config 8260_PCI9"
From: Kumar Gala @ 2013-03-15 16:17 UTC (permalink / raw)
To: Paul Bolle; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1363274097.1335.83.camel@x61.thuisdomein>
On Mar 14, 2013, at 10:14 AM, Paul Bolle wrote:
> The last user of Kconfig symbol 8260_PCI9 got removed in release v3.2.
> Remove this symbol too.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Untested.
>
> 1) This probably is a second order effect of my commit
> 6805ab6daa2b589fe3242d05ddc47a9dbb0c4eb1 ("powerpc: drop unused Kconfig
> symbols"). Not sure how I missed that.
>
> arch/powerpc/Kconfig | 5 -----
> 1 file changed, 5 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: enable E1000 NIC to mpc85xx_defconfig
From: Kumar Gala @ 2013-03-15 16:16 UTC (permalink / raw)
To: Roy Zang; +Cc: b36666, B11780, linuxppc-dev
In-Reply-To: <1363275622-1412-1-git-send-email-tie-fei.zang@freescale.com>
On Mar 14, 2013, at 10:40 AM, Roy Zang wrote:
> E1000 NIC is a common used Ethernet card. Enable it as default
> for mpc85xx platform.
>
> other change is due to make savedefconfig
>
> Reported-by: Fu Jiwei <b36666@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> tested on P1010rdb board
> arch/powerpc/configs/mpc85xx_defconfig | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/qe: remove useless Kconfig default
From: Kumar Gala @ 2013-03-15 16:16 UTC (permalink / raw)
To: Paul Bolle; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1363124951.3137.156.camel@x61.thuisdomein>
On Mar 12, 2013, at 4:49 PM, Paul Bolle wrote:
> The Kconfig entry for QE_USB contains
> default y if USB_GADGET_FSL_QE
>=20
> But USB_GADGET_FSL_QE got removed in commit
> 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b ("usb: gadget: allow multiple
> gadgets to be built"). This default will therefor never be set and can
> be removed.
>=20
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Tested with "make ARCH=3Dpowerpc menuconfig" and "make ARCH=3Dpowerpc=
> oldconfig" (before and after the patch). Enough to see this patch =
didn't
> obviously break stuff.
>=20
> 1) I don't really understand commit
> 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b. Was its point that we =
replace
> USB_GADGET_FSL_QE with USB_FSL_QE? I couldn't tell and chose not to
> actually change any behavior.
>=20
> arch/powerpc/sysdev/qe_lib/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>=20
You're correct that this isn't quite right, I've posted a proper patch =
that should fix this correctly.
thanks for pointing it out.
- k=
^ permalink raw reply
* [PATCH] powerpc/qe: Fix Kconfig enablement of QE_USB support
From: Kumar Gala @ 2013-03-15 16:15 UTC (permalink / raw)
To: linuxppc-dev
Commit 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b changed the USB gadget
Kconfig symbol from USB_GADGET_FSL_QE to USB_FSL_QE, but did not update
the associated symbol name in qe_lib to match.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/qe_lib/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig
index 41ac3df..3c25199 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -22,6 +22,6 @@ config UCC
config QE_USB
bool
- default y if USB_GADGET_FSL_QE
+ default y if USB_FSL_QE
help
QE USB Controller support
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH 5/6] powerpc/fsl-booke: Add B4_QDS board support
From: Kumar Gala @ 2013-03-15 15:58 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: linuxppc-dev
In-Reply-To: <1363334109-21922-5-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> - Add support for B4 board's personalities in board file
> b4_qds.c, It is common for B4 personalities B4860 and B4420QDS
> - Add B4QDS support in Kconfig and Makefile
Code also references a B4220, what about it?
>=20
> B4860QDS is a high-performance computing evaluation, development and
> test platform supporting the B4860 QorIQ Power Architecture processor,
> with following major features:
>=20
> - Four dual-threaded e6500 Power Architecture processors
> organized in one cluster-each core runs up to 1.8 GHz
> - Two DDR3/3L controllers for high-speed memory interface each
> runs at up to 1866.67 MHz
> - CoreNet fabric that fully supports coherency using MESI protocol
> between the e6500 cores, SC3900 FVP cores, memories and
> external interfaces.
> - Data Path Acceleration Architecture having FMAN, QMan, BMan, SEC =
5.3 and RMAN
> - Large internal cache memory with snooping and stashing =
capabilities
> - Sixteen 10-GHz SerDes lanes that serve:
> - Two SRIO interfaces. Each supports up to 4 lanes and
> a total of up to 8 lanes
> - Up to 8-lanes Common Public Radio Interface (CPRI) controller
> for glue-less antenna connection
> - Two 10-Gbit Ethernet controllers (10GEC)
> - Six 1G/2.5-Gbit Ethernet controllers for network =
communications
> - PCI Express controller
> - Debug (Aurora)
> - Various system peripherals
>=20
> B4420 is a reduced personality of B4860 with fewer core/clusters(both =
SC3900 and e6500),
> fewer DDR controllers, fewer serdes lanes, fewer SGMII interfaces and =
reduced target frequencies.
>=20
> Key differences between B4860 and B4420:
> B4420 has:
> - Fewer e6500 cores:
> 1 cluster with 2 e6500 cores
> - Fewer SC3900 cores/clusters:
> 1 cluster with 2 SC3900 cores per cluster
> - Single DDRC
> - 2X 4 lane serdes
> - 3 SGMII interfaces
> - no sRIO
> - no 10G
>=20
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 16 +++++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/b4_qds.c | 102 =
++++++++++++++++++++++++++++++++++
> 3 files changed, 119 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
>=20
> diff --git a/arch/powerpc/platforms/85xx/Kconfig =
b/arch/powerpc/platforms/85xx/Kconfig
> index 31dc066..7bbd522 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -262,6 +262,22 @@ config SGY_CTS1000
>=20
> endif # PPC32
>=20
> +config B4_QDS
> + bool "Freescale B4 QDS"
> + select DEFAULT_UIMAGE
> + select E500
> + select PPC_E500MC
> + select PHYS_64BIT
> + select SWIOTLB
> + select MPC8xxx_GPIO
should be:
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
> + select HAS_RAPIDIO
> + select PPC_EPAPR_HV_PIC
> + help
> + This option enables support for the B4 QDS board
> + The B4 application development system B4 QDS is a complete
> + debugging environment intended for engineers developing
> + applications for the B4.
> +
Should be in the if PPC64 section with T4240 QDS support
> config P5020_DS
> bool "Freescale P5020 DS"
> select DEFAULT_UIMAGE
> diff --git a/arch/powerpc/platforms/85xx/Makefile =
b/arch/powerpc/platforms/85xx/Makefile
> index 712e233..a12ae2d 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_SMP) +=3D smp.o
> obj-y +=3D common.o
>=20
> obj-$(CONFIG_BSC9131_RDB) +=3D bsc913x_rdb.o
> +obj-$(CONFIG_B4_QDS) +=3D b4_qds.o corenet_ds.o
> obj-$(CONFIG_MPC8540_ADS) +=3D mpc85xx_ads.o
> obj-$(CONFIG_MPC8560_ADS) +=3D mpc85xx_ads.o
> obj-$(CONFIG_MPC85xx_CDS) +=3D mpc85xx_cds.o
> diff --git a/arch/powerpc/platforms/85xx/b4_qds.c =
b/arch/powerpc/platforms/85xx/b4_qds.c
> new file mode 100644
> index 0000000..0c6702f
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/b4_qds.c
> @@ -0,0 +1,102 @@
> +/*
> + * B4 QDS Setup
> + * Should apply for QDS platform of B4860 and it's personalities.
> + * viz B4860/B4420/B4220QDS
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * 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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/phy.h>
> +
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +
> +#include <linux/of_platform.h>
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +#include <asm/ehv_pic.h>
> +
> +#include "corenet_ds.h"
> +
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +static int __init b4_qds_probe(void)
> +{
> + unsigned long root =3D of_get_flat_dt_root();
> +#ifdef CONFIG_SMP
> + extern struct smp_ops_t smp_85xx_ops;
> +#endif
> +
> + if ((of_flat_dt_is_compatible(root, "fsl,B4860QDS")) ||
> + (of_flat_dt_is_compatible(root, "fsl,B4420QDS")) ||
> + (of_flat_dt_is_compatible(root, =
"fsl,B4220QDS")))
> + return 1;
> +
> + /* Check if we're running under the Freescale hypervisor */
> + if ((of_flat_dt_is_compatible(root, "fsl,B4860QDS-hv")) ||
> + (of_flat_dt_is_compatible(root, "fsl,B4420QDS-hv")) ||
> + (of_flat_dt_is_compatible(root, =
"fsl,B4220QDS-hv"))) {
> + ppc_md.init_IRQ =3D ehv_pic_init;
> + ppc_md.get_irq =3D ehv_pic_get_irq;
> + ppc_md.restart =3D fsl_hv_restart;
> + ppc_md.power_off =3D fsl_hv_halt;
> + ppc_md.halt =3D fsl_hv_halt;
> +#ifdef CONFIG_SMP
> + /*
> + * Disable the timebase sync operations because we can't =
write
> + * to the timebase registers under the hypervisor.
> + */
> + smp_85xx_ops.give_timebase =3D NULL;
> + smp_85xx_ops.take_timebase =3D NULL;
> +#endif
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +define_machine(b4_qds) {
> + .name =3D "B4 QDS",
> + .probe =3D b4_qds_probe,
> + .setup_arch =3D corenet_ds_setup_arch,
> + .init_IRQ =3D corenet_ds_pic_init,
> +#ifdef CONFIG_PCI
> + .pcibios_fixup_bus =3D fsl_pcibios_fixup_bus,
> +#endif
> +/* coreint doesn't play nice with lazy EE, use legacy mpic for now */
> +#ifdef CONFIG_PPC64
> + .get_irq =3D mpic_get_irq,
> +#else
> + .get_irq =3D mpic_get_coreint_irq,
> +#endif
> + .restart =3D fsl_rstcr_restart,
> + .calibrate_decr =3D generic_calibrate_decr,
> + .progress =3D udbg_progress,
> +#ifdef CONFIG_PPC64
> + .power_save =3D book3e_idle,
> +#else
> + .power_save =3D e500_idle,
> +#endif
> +};
> +
> +machine_arch_initcall(b4_qds, corenet_ds_publish_devices);
> +
> +#ifdef CONFIG_SWIOTLB
> +machine_arch_initcall(b4_qds, swiotlb_setup_bus_notifier);
> +#endif
> --=20
> 1.7.6.GIT
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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