On Thu, 2022-10-13 at 09:39 +0200, Javier Martinez Canillas wrote:
> > In absence of such test results I think the most reasonable thing is to
> > keep the logic that nobody complained about for 10+ years.
> >
>
> I agree with Michal and Thomas on this. I don't see a strong reason to not
> use
On Mon, 2022-08-15 at 15:46 +1000, Michael Ellerman wrote:
> Guenter Roeck writes:
> > On Wed, Jul 06, 2022 at 12:21:48PM +0200, Pali Rohár wrote:
> > > Other Linux architectures use DT property 'linux,pci-domain' for
> > > specifying
> > > fixed PCI domain of PCI controller specified in
On Thu, 2022-09-01 at 13:53 +1000, Michael Ellerman wrote:
> >
> > I sent two patches which do another steps to achieve it:
> > https://lore.kernel.org/linuxppc-dev/20220817163927.24453-1-p...@kernel.org/t/#u
> >
> > Main blocker is pci-OF-bus-map which is in direct conflict with
> >
On Wed, 2022-07-27 at 10:41 +0200, Thomas Zimmermann wrote:
>
> > > +static void __iomem *ofdrm_mach64_cmap_ioremap(struct ofdrm_device *odev,
> > > +struct device_node *of_node,
> > > +u64 fb_base)
> > > +{
> > > +
On Tue, 2022-07-26 at 16:40 +0200, Michal Suchánek wrote:
> Hello,
>
> On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
> > On 7/20/22 16:27, Thomas Zimmermann wrote:
> > > Add a per-model device-function structure in preparation of adding
> > > color-management support.
On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
> +#if !defined(CONFIG_PPC)
> +static inline void out_8(void __iomem *addr, int val)
> +{ }
> +static inline void out_le32(void __iomem *addr, int val)
> +{ }
> +static inline unsigned int in_le32(const void __iomem *addr)
> +{
> +
On Sat, 2022-07-16 at 15:31 +0800, Liang He wrote:
> We should call of_node_put() for the reference 'gparent' escaped
> out of the for_each_child_of_node() as it has increased the refcount.
Same comment as before. That stuff happens once at boot, there's never
any dynamic allocation/deallocation
On Sat, 2022-07-16 at 15:43 +0800, Liang He wrote:
> During the iteration of for_each_child_of_node(), we need to call
> of_node_put() for the old references stored in to 'ch_def' and 'ch_a'
> as their refcounters have been increased in last iteration.
None of these matter since those nodes are
On Wed, 2022-07-13 at 11:53 -0700, Kees Cook wrote:
> On Wed, Jul 13, 2022 at 11:37:34PM +0800, Ning Qiang wrote:
> > In do_adb_query function of drivers/macintosh/adb.c, req->data is
> > copy
> > form userland. the parameter "req->data[2]" is Missing check, the
> > array size of adb_handler[] is
> req->data[2]].original_address" and "adb_handler[
> req->data[2]].handler_id" will lead to oob read.
>
> Signed-off-by: Ning Qiang
Acked-by: Benjamin Herrenschmidt
> ---
> drivers/macintosh/adb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, 2022-07-13 at 09:54 +0800, sohu0106 wrote:
>
>
> In do_adb_query function of drivers/macintosh/adb.c, req->data is
> copy form userland. the parameter "req->data[2]" is Missing check,
> the array size of adb_handler[] is 16, so "adb_handler[req-
> >data[2]].original_address" and
reviewers, they're still on linuxppc-dev if needed.
>
> Signed-off-by: Michael Ellerman
Acked-by: Benjamin Herrenschmidt
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1fc9ead83d2a..af4cf
On Thu, 2022-05-26 at 09:43 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Sat, 21 May 2022, Benjamin Herrenschmidt wrote:
> > On Wed, 2022-05-18 at 20:13 -0700, Jakub Kicinski wrote:
> > > Looks like almost all changes to this driver had been tree-wide
> &g
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote:
> I don't mind adding DRM support for BootX displays, but getting the
> necessary test HW with a suitable Linux seems to be laborious. Would
> a G4 Powerbook work?
Probably not unfortunately... it's going to be tricky. I might sitll
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote:
>
> > The palette handling is useful when using a real Open Firmware
> > implementation which tends to boot in 8-bit mode, so without palette
> > things will look ... bad.
> >
> > It's not necessary when using 16/32 bpp framebuffers
On Sun, 2022-05-22 at 21:35 +0200, Thomas Zimmermann wrote:
> > Interesting. Did you find some formats that were not supported ?
>
> We still don't support XRGB1555. If the native buffer uses this format,
> we'd have no conversion helper. In this case, we rely on userspace/fbcon
> to use the
On Wed, 2022-05-18 at 20:13 -0700, Jakub Kicinski wrote:
> Looks like almost all changes to this driver had been tree-wide
> refactoring since git era begun. There is one commit from Al
> 15 years ago which could potentially be fixing a real bug.
>
> The driver is using virt_to_bus() and is a
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote:
> to build without PCI to see what happens.
If you bring any of the "heuristic" and palette support code in, you
need PCI. I don't see any reason to take it out.
> Those old Macs use BootX, right? BootX is not supported ATM, as I don't
On Thu, 2022-05-19 at 09:11 +0200, Geert Uytterhoeven wrote:
> Hi Michal,
>
>
>
> On Wed, May 18, 2022 at 8:54 PM Michal Suchánek
> wrote:
>
> > On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote:
> > > --- a/drivers/gpu/drm/tiny/Kconfig
> > > +++ b/drivers/gpu/drm/tiny/Kconfig
On Thu, 2021-09-16 at 14:36 +, David Laight wrote:
> > Does userspace accesses non-cached memory directly ?
>
>
> It probably can if a driver mmaps PCI space directly into user space.
>
> That certainly works on x86-64.
The posterchild for that is Xorg
Cheers,
Ben.
On Thu, 2021-09-16 at 17:15 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2021-09-15 at 16:31 +0200, Christophe Leroy wrote:
> > dcbz instruction shouldn't be used on non-cached memory. Using
> > it on non-cached memory can result in alignment exception and
> > imp
On Wed, 2021-09-15 at 16:31 +0200, Christophe Leroy wrote:
> dcbz instruction shouldn't be used on non-cached memory. Using
> it on non-cached memory can result in alignment exception and
> implies a heavy handling.
>
> Instead of silentely emulating the instruction and resulting in high
>
On Mon, 2021-08-02 at 16:18 +1000, Michael Ellerman wrote:
>
> But to be fair the ABI of the VDSO has always been a little fishy,
>
> because the entry points pretend to be a transparent wrapper around
>
> system calls, but then in a case like this are not.
This is somewhat debatable :-) If
On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
> Dear Christophe,
>
>
> On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a segmentation
> fault [1], and it might be related to *[release-branch.go1.16] runtime:
> fix crash during VDSO calls on PowerPC* [2], conjecturing that commit
On Mon, 2021-04-26 at 12:54 +0200, Michael Walle wrote:
> Before I'll try to come up with a patch for this, I'd like to get
> your opinion on it.
>
> (1) replacing of_get_mac_address(node) with eth_get_mac_address(dev)
> might sometimes lead to confusing comments like in
>
On Mon, 2021-04-12 at 19:47 +0200, Michael Walle wrote:
>
> /**
> * of_get_phy_mode - Get phy mode for given device_node
> @@ -59,15 +60,39 @@ static int of_get_mac_addr(struct device_node *np, const
> char *name, u8 *addr)
> static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>
> +static inline void nap_adjust_return(struct pt_regs *regs)
>
> +{
>
> +#ifdef CONFIG_PPC_970_NAP
>
> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
> + /* Can avoid a test-and-clear because NMIs do not
On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote:
> > works fine with huge pages, what is your problem there ? You rely on
> > punching small-page size holes in there ?
> >
>
> ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel
> mapping in the direct mapping as it sets
On Wed, 2020-07-22 at 12:06 +1000, Michael Ellerman wrote:
> Ram Pai writes:
> > An instruction accessing a mmio address, generates a HDSI fault. This
> > fault is
> > appropriately handled by the Hypervisor. However in the case of secureVMs,
> > the
> > fault is delivered to the ultravisor.
On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote:
> > Why ? Branch distance limits ? You can't use trampolines ?
>
> Nothing fundamental, it's just that we don't have a large code model in the C
> compiler. As a result all the global symbols are resolved as 32-bit
> PC-relative accesses.
On Tue, 2020-07-21 at 12:05 -0700, Palmer Dabbelt wrote:
>
> * We waste vmalloc space on 32-bit systems, where there isn't a lot of it.
> * On 64-bit systems the VA space around the kernel is precious because it's
> the
> only place we can place text (modules, BPF, whatever).
Why ? Branch
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
> > > I guess I don't understand why this is necessary at all.
> > > Specifically: why
> > > can't we just relocate the kernel within the linear map? That would
> > > let the
> > > bootloader put the kernel wherever it wants, modulo the
On Thu, 2020-07-16 at 12:38 -0700, Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> This primitive has been renamed, but because it was spelled incorrectly in the
> first place it must have escaped the fixup patch. As far as I can tell this
> logic is still correct: smp_mb__after_spinlock()
On Wed, 2020-07-15 at 17:12 -0500, Bjorn Helgaas wrote:
> > I've 'played' with PCIe error handling - without much success.
> > What might be useful is for a driver that has just read ~0u to
> > be able to ask 'has there been an error signalled for this device?'.
>
> In many cases a driver will
On Wed, 2020-07-15 at 08:47 +0200, Arnd Bergmann wrote:
> drivers/misc/cardreader/rts5261.c: retval =
> rtsx_pci_write_config_dword(pcr, PCR_SETTING_REG2, lval);
>
> That last one is interesting because I think this is a case in which
> we
> actually want to check for errors, as the driver
On Tue, 2020-07-14 at 18:46 -0500, Bjorn Helgaas wrote:
> Yes. I have no problem with that. There are a few cases where it's
> important to check for errors, e.g., we read a status register and do
> something based on a bit being set. A failure will return all bits
> set, and we may do the
On Tue, 2020-07-14 at 23:02 +0200, Kjetil Oftedal wrote:
> >
> > > For b), it might be nice to also change other aspects of the
> > > interface, e.g. passing a pci_host_bridge pointer plus bus number
> > > instead of a pci_bus pointer, or having the callback in the
> > > pci_host_bridge
On Tue, 2020-07-14 at 13:45 -0500, Bjorn Helgaas wrote:
>
> > fail for valid arguments on a valid pci_device* ?
>
> I really like this idea.
>
> pci_write_config_*() has one return value, and only 100ish of 2500
> callers check for errors. It's sometimes possible for config
> accessors to
On Mon, 2020-05-18 at 12:19 +0100, Emil Velikov wrote:
>
> - attempted out-of-bound attempts to read the vbios
So on these things, the actual ROM doesn't contain what you want, but
the device-tree has a property "NVDA,BMP" that contains some kind of
mini-BIOS (around 2.4KB) which should contain
On Mon, 2020-05-18 at 12:00 +0100, Emil Velikov wrote:
> I believe you reported issues due to different page size for the CPU/GPU.
> Have you tried nouveau recently, there has been a handful of patches
> on the topic since your report.
>
> Alternatively, it would make sense you rebase, cleanup
b...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Emil Velikov
> Acked-by: Daniel Vetter (v1)
> ---
> Hi all unless, there are objections I would
On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote:
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu
On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > If this code was broken for non-coherent caches a crude powerpc hack
> > isn't going to help anyone else. Remove the hack as it is the last
> > user of __vmalloc
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
> Benjamin Herrenschmidt writes:
> > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
> > > I have no attachment to 40x, and I'd certainly be happy to have
> > > less
> > > code in the tree,
On Wed, 2020-04-01 at 01:48 -0700, Dan Williams wrote:
> >
> > +u64 pnv_ocxl_platform_lpc_setup(struct pci_dev *pdev, u64 size)
> > +{
> > + struct pci_controller *hose = pci_bus_to_host(pdev->bus);
> > + struct pnv_phb *phb = hose->private_data;
>
> Is calling the local variable
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
> I have no attachment to 40x, and I'd certainly be happy to have less
> code in the tree, we struggle to keep even the modern platforms well
> maintained.
>
> At the same time I don't want to render anyone's hardware obsolete
>
addresses work?
>
> Cc: Frank Rowand
> Cc: Mauro Carvalho Chehab
Acked-by: Benjamin Herrenschmidt
> Cc: Geert Uytterhoeven
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
> ---
> .../devicetree/booting-without-of.txt
On Mon, 2020-02-24 at 10:20 -0500, Joe Lawrence wrote:
> On
> > I don't remember why :-) I think I didn't want to mess with the OPD
> > fixup in glibc back then.
> >
>
> Does it make sense to just drop the unused VDS64_HAS_DESCRIPTORS code
> then?
I'd think so yes.
Cheers,
Ben.
On Sat, 2020-02-22 at 18:07 -0600, Segher Boessenkool wrote:
> >
> > so I don't believe they are ever used by default -- in this case
> > V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base,
> > etc.
> >
> > Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in
On Fri, 2019-10-25 at 23:39 -0700, Christoph Hellwig wrote:
> On Fri, Oct 25, 2019 at 05:28:45PM -0500, Rob Herring wrote:
> > This doesn't work?:
> >
> > if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev-
> > >of_node))
> > value |= ESDHC_DMA_SNOOP;
> > else
>
On Fri, 2019-10-25 at 17:28 -0500, Rob Herring wrote:
> This doesn't work?:
>
> if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev-
> >of_node))
> value |= ESDHC_DMA_SNOOP;
> else
> value &= ~ESDHC_DMA_SNOOP;
CONFIG_PPC is restrictive. What about
On Wed, 2019-10-23 at 16:42 +1100, Michael Ellerman wrote:
>
> Right, it seems of_dma_is_coherent() has baked in the assumption that
> devices are non-coherent unless explicitly marked as coherent.
>
> Which is wrong on all or at least most existing powerpc systems
> according to Ben.
This is
On Wed, 2019-10-16 at 20:30 +1100, Michael Ellerman wrote:
> I think the main reason is that in some configurations we can't use 64K
> pages for MMIO, so the 64K vmalloc mappings and 4K MMIO mappings need to
> be in different segments.
>
> It's possible that's no longer true on modern configs.
On Wed, 2019-10-16 at 15:19 +0200, Carlo Pisani wrote:
> hi
> I am a student, I represent a group of friends running a couple of
> opensource projects(1), and we are lost with this(2) problem.
>
> I wrote here(2) a couple of years ago, we are still working with
> kernel
> 4.11.0 and there is
On Mon, 2019-08-26 at 21:41 +1000, Michael Ellerman wrote:
> Christophe Leroy writes:
> > sched_clock(), used by printk(), calls __USE_RTC() to know
> > whether to use realtime clock or timebase.
> >
> > __USE_RTC() uses cpu_has_feature() which is initialised by
> > machine_init(). Before
On Fri, 2019-08-16 at 14:48 +, Christophe Leroy wrote:
> __get_datapage() is only a few instructions to retrieve the
> address of the page where the kernel stores data to the VDSO.
>
> By inlining this function into its users, a bl/blr pair and
> a mflr/mtlr pair is avoided, plus a few reg
On Wed, 2019-08-21 at 00:28 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 02:07:13PM +, Christophe Leroy wrote:
> > ppc_md.ioremap() is only used for I/O workaround on CELL platform,
> > so indirect function call can be avoided.
> >
> > This patch reworks the io-workaround and
On Tue, 2019-07-30 at 10:07 -0700, Kees Cook wrote:
>
> > Why do we think it's an expected fall through? I can't really
> > convince
> > myself from the surrounding code that it's definitely intentional.
>
> Yeah, good question. Just now when I went looking for who
> used
On Wed, 2019-07-17 at 15:00 +1000, Alexey Kardashevskiy wrote:
> There is a race between releasing an irq on one cpu and fetching it
> from XIVE on another cpu as there does not seem to be any locking between
> these, probably because xive_irq_chip::irq_shutdown() is supposed to
> remove the irq
On Mon, 2019-07-15 at 19:03 -0300, Thiago Jung Bauermann wrote:
> > > Indeed. The idea is that QEMU can offer the flag, old guests can
> > > reject
> > > it (or even new guests can reject it, if they decide not to
> > > convert into
> > > secure VMs) and the feature negotiation will succeed with
On Sun, 2019-07-14 at 21:44 +0200, Cédric Le Goater wrote:
> > Well, best is probably to do just that though, but call it something
> > like ppc_md.orphan_irq() or something like that instead. Another option
> > as you mention is to try to scrub queues, but that's trickier to do due
> > to the
On Sat, 2019-07-13 at 18:53 +1000, Alexey Kardashevskiy wrote:
>
> On 13/07/2019 09:47, Benjamin Herrenschmidt wrote:
> > On Fri, 2019-07-12 at 19:37 +1000, Alexey Kardashevskiy wrote:
> > >
> >
> >
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l
On Fri, 2019-07-12 at 19:37 +1000, Alexey Kardashevskiy wrote:
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/irq.c#n614
>
> If so, then in order to do EOI, I'll need the desc which is gone, or
> I am missing the point?
All you need is drop the
On Fri, 2019-07-12 at 18:20 +1000, Alexey Kardashevskiy wrote:
>
> diff --git a/arch/powerpc/sysdev/xive/common.c
> b/arch/powerpc/sysdev/xive/common.c
> index 082c7e1c20f0..65742e280337 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -148,8
On Wed, 2019-06-19 at 22:32 +1000, Michael Ellerman wrote:
> Christoph Hellwig writes:
> > Any chance this could get picked up to fix the regression?
>
> Was hoping Ben would Ack it. He's still powermac maintainer :)
>
> I guess he OK'ed it in the other thread, will add it to my queue.
Yeah
On Tue, 2019-06-18 at 22:15 +1000, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
> > The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing
> > which is basically reading "assigned-addresses" of every PCI device.
> > However if the property is missing or zero sized, then
On Wed, 2019-06-12 at 14:41 -0500, Larry Finger wrote:
> On 6/12/19 1:55 AM, Christoph Hellwig wrote:
> >
> > Ooops, yes. But I think we could just enable ZONE_DMA on 32-bit
> > powerpc. Crude enablement hack below:
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index
On Wed, 2019-06-12 at 09:25 +0300, Oded Gabbay wrote:
>
> > You can't. Your device is broken. Devices that don't support DMAing to
> > the full 64-bit deserve to be added to the trash pile.
> >
>
> Hmm... right know they are added to customers data-centers but what do I know
> ;)
Well, some
On Wed, 2019-06-12 at 15:45 +1000, Oliver O'Halloran wrote:
>
> Also, are you sure about the MSI thing? The IODA3 spec says the only
> important bits for a 64bit MSI are bits 61:60 (to hit the window) and
> the lower bits that determine what IVE to use. Everything in between
> is ignored so ORing
On Tue, 2019-06-11 at 20:52 -0500, Larry Finger wrote:
> On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:
> > On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
> > > b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
> > > 0x3fff,
> > &
On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote:
>
> > So, to summarize:
> > If I call pci_set_dma_mask with 48, then it fails on POWER9. However,
> > in runtime, I don't know if its POWER9 or not, so upon failure I will
> > call it again with 32, which makes our device pretty much unusable.
On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
> b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
> 0x3fff,
> min_mask = 0x5000/0x5000, dma bits = 0x1f
Ugh ? A mask with holes in it ? That's very wrong... That min_mask is
bogus.
Ben.
On Tue, 2019-06-11 at 09:54 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt
> wrote:
> > Ah stupid me ... it's dma_set_mask that failed, since it has no
> > idea
> > that the calling driver is limited to lowmem.
> >
On Tue, 2019-06-11 at 16:58 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> > On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> > wrote:
> > > The reason I think it sort-of-mostly-worked is that to get m
On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> wrote:
> > The reason I think it sort-of-mostly-worked is that to get more
> > than
> > 1GB of RAM, those machines use CONFIG_HIGHMEM. And *m
On Mon, 2019-06-10 at 13:44 -0500, Larry Finger wrote:
> On 6/7/19 11:21 PM, Benjamin Herrenschmidt wrote:
> >
> > > Please try the attached patch. I'm not really pleased with it and I will
> > > continue to determine why the fallback to a 30-bit mask fails, but at
> Please try the attached patch. I'm not really pleased with it and I will
> continue to determine why the fallback to a 30-bit mask fails, but at least
> this
> one works for me.
Your patch only makes sense if the device is indeed capable of
addressing 31-bits.
So either the driver is
On Thu, 2019-06-06 at 20:56 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2019-06-06 at 12:31 +0300, Aaro Koskinen wrote:
> > Hi,
> >
> > On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt
> > wrote:
> > > On Thu, 2019-06-06 at 01:50 +0
On Thu, 2019-06-06 at 12:31 +0300, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> > > Hi,
> > >
> > > When upgrading from
On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> Hi,
>
> When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
> not work anymore:
>
> [ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14
> (2005-04-18 02:36:27)
> [ 42.184837] b43legacy-phy0
On Mon, 2019-06-03 at 18:42 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 03, 2019 at 12:56:26PM +1000, Alexey Kardashevskiy wrote:
> > On 03/06/2019 09:23, Segher Boessenkool wrote:
> > > > So I go for the simple one and agree with Alexey's idea.
> > >
> > > When dealing with a whole
On Mon, 2019-06-03 at 12:56 +1000, Alexey Kardashevskiy wrote:
>
> > That is all you need if you do not want to use OF at all.
>
> ? We also need OF drivers to boot grub and the system, and a default
> console for early booting, but yes, we do not want to keep using slof
> that much.
>
> > If
On Thu, 2019-05-30 at 14:37 -0500, Segher Boessenkool wrote:
> On Thu, May 30, 2019 at 05:09:06PM +1000, Alexey Kardashevskiy wrote:
> > so, it is sort-of nack from David and sort-of ack from Segher, what
> > happens now?
>
> Maybe what we really need just a CI call to get all properties of a
On Mon, 2019-05-13 at 22:44 -0300, Shawn Landden wrote:
> +
> +/*
> + * Were we in user mode when we were
> + * interrupted?
> + *
> + * Doing kernel_altivec/vsx_begin/end() is ok if we are running
> + * in an interrupt context from user mode - we'll just
> + * save the FPU state as required.
> +
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp,
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp,
On Mon, 2019-02-11 at 07:26 +0100, Christophe Leroy wrote:
>
> Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit :
> > On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote:
> > > /*
> > > + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include
On Mon, 2019-02-11 at 13:38 +1100, David Gibson wrote:
>
> 1) All in kernel
>
> The offset always maps directly to guest irq number and the kernel
> somehow binds it either to an IPI or a host irq as necessary.
> Cédric's original code attempts this, but the mechanism of keeping a
> pointer to
On Fri, 2019-02-08 at 14:51 +, Mark Cave-Ayland wrote:
>
> Indeed, but there are still some questions to be asked here:
>
> 1) Why were these bits removed from the original bitmask in the first place
> without
> it being documented in the commit message?
>
> 2) Is this the right fix? I'm
On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote:
> /*
> + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
> + */
> +.macro __LOAD_MSR_KERNEL r, x
> +.if \x >= 0x8000
> + lis \r, (\x)@h
> + ori \r, \r, (\x)@l
> +.else
> + li \r, (\x)
> +.endif
> +.endm
>
On Tue, 2019-02-05 at 10:45 +0100, Christophe Leroy wrote:
> > > I tested it on the 8xx with the below changes in addition. No issue seen
> > > so far.
> >
> > Thanks !
> >
> > I'll merge that in.
>
> I'm currently working on a refactorisation and simplification of
> exception and syscall entry
On Wed, 2019-01-30 at 08:16 +0100, Christophe Leroy wrote:
> In transfer_to_handler() (entry_32.S), we have:
>
> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> ...
> #ifdef CONFIG_SMP
> CURRENT_THREAD_INFO(r9, r1)
> lwz r9,TI_CPU(r9)
> slwir9,r9,3
> add
On Tue, 2019-01-22 at 16:23 +1100, Paul Mackerras wrote:
>
> Which ones of these could be implemented in QEMU? Are there any that
> can't possibly be implemented in QEMU because they need to do things
> that require calling internal interfaces that userspace doesn't have
> access to?
On Wed, 2019-01-23 at 21:26 +1100, Paul Mackerras wrote:
> If H_INT_ESB is only used for LSIs, then is a guest going to be using
> it at all?
*emulated* LSIs, ie LSIs coming from emulated devices. It will depends
in practice of what kind of emulated device you put in your guest. We
need that
On Wed, 2019-01-23 at 20:07 +0100, Cédric Le Goater wrote:
> Event Assignment Structure, a.k.a IVE (Interrupt Virtualization Entry)
>
> All the names changed somewhere between XIVE v1 and XIVE v2. OPAL and
> Linux should be adjusted ...
All the names changed between the HW design and the
On Wed, 2019-01-23 at 19:39 +0100, Cédric Le Goater wrote:
> > The reason I ask is that we will have to be much more careful about
> > memory allocation lifetimes with this patch.
>
> yes. bad refcounting will lead the host kernel to a crash.
One way to alleviate that is to make sure this is
On Thu, 2019-01-24 at 19:48 +0530, Chandan Rajendra wrote:
> - Here we execute "LD rB,0,r4". In the case of this bug, r4 has an unaligned
> value and hence ends up accessing the "next" double word. The "next" double
> word happens to occur after the last page mapped into the kernel's address
>
On Wed, 2019-01-23 at 21:30 +1100, Paul Mackerras wrote:
> > Afaik bcs we change the mapping to point to the real HW irq ESB page
> > instead of the "IPI" that was there at VM init time.
>
> So that makes it sound like there is a whole lot going on that hasn't
> even been hinted at in the patch
On Tue, 2019-01-22 at 16:26 +1100, Paul Mackerras wrote:
> On Mon, Jan 07, 2019 at 08:10:05PM +0100, Cédric Le Goater wrote:
> > Clear the ESB pages from the VMA of the IRQ being pass through to the
> > guest and let the fault handler repopulate the VMA when the ESB pages
> > are accessed for an
On Thu, 2019-01-17 at 10:42 +0100, Tobias Ulmer wrote:
> On Wed, Jan 16, 2019 at 12:15:14PM +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2019-01-15 at 23:49 +0100, Tobias Ulmer wrote:
> > > Hi,
> > >
> > > both the latest stable 4.20.2 an
1 - 100 of 7203 matches
Mail list logo
