On Fri, Dec 29, 2017 at 09:11:56PM +1100, Julian Calaby wrote:
> Hi Christoph,
>
> On Fri, Dec 29, 2017 at 7:18 PM, Christoph Hellwig wrote:
> > This frees the dma_direct_* namespace for a generic implementation.
>
> Don't you mean "dma_nommu" not "dma_microblaze" in the subject line?
Yes, than
On Wed, Jan 03, 2018 at 07:19:46PM +1100, Julian Calaby wrote:
> If this is indeed a linear mapping, can we just remove this and
> replace it with the new "generic" mapping being introduced by this
> patchset?
That is the long-term plan. But as the powerpc one includes support
for non-coherent DM
On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote:
> Christoph Hellwig writes:
>
> > We want to use the dma_direct_ namespace for a generic implementation,
> > so rename powerpc to the second best choice: dma_nommu_.
>
> I'm not a fan of "nommu". Some of the users of direct ops *a
On Fri, Dec 29, 2017 at 03:12:25PM +0100, Geert Uytterhoeven wrote:
> > +check_addr(struct device *dev, dma_addr_t dma_addr, size_t size,
> > + const char *caller)
> > +{
> > + if (unlikely(dev && !dma_capable(dev, dma_addr, size))) {
> > + if (*dev->dma_mask >= DM
On Tue, Jan 02, 2018 at 11:36:00AM +0100, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> > CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> > ("alpha/dma: use common noop dma ops"), so mark it as broken.
>
> unknown revi
On Tue, Jan 02, 2018 at 04:43:15PM +, Vladimir Murzin wrote:
> On 29/12/17 08:18, Christoph Hellwig wrote:
> > If we got back an allocation that wasn't inside the support coherent mask,
> > retry the allocation using GFP_DMA.
> >
> > Based on the x86 code.
> >
> > Signed-off-by: Christoph Hel
This patch restores the alphabetic order which was broken by
commit 1e0fc9d1eb2b0 ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX
for some configs")
Fixes: 1e0fc9d1eb2b0 ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some
configs")
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 4 ++--
On Wed, 03 Jan 2018 12:34:34 +0530
"Aneesh Kumar K.V" wrote:
> Nicholas Piggin writes:
>
> > There are several cases outside the normal address space management
> > where a CPU's entire local TLB is to be flushed:
> >
> > 1. Booting the kernel, in case something has left stale entries in
> >
On Mon, Jan 01, 2018 at 04:17:20PM +0100, Maciej S. Szmigiero wrote:
> > AC97 configures some registers earlier to start a communication
> > with CODECs, so this patch moves those register settings to the
> > dai_probe() as well, along with other register configurations.
> This patch breaks AC'97
On Mon, Jan 01, 2018 at 07:39:52PM +0100, Maciej S. Szmigiero wrote:
> > /* The slot number should be >= 2 if using Network mode or I2S mode */
> > - regmap_read(regs, REG_SSI_SCR, &val);
> > - val &= SSI_SCR_I2S_MODE_MASK | SSI_SCR_NET;
> > - if (val && slots < 2) {
> > + if (ssi->i2s
On Mon, Jan 01, 2018 at 10:29:24PM +0100, Maciej S. Szmigiero wrote:
> > @@ -445,16 +445,10 @@ static void fsl_ssi_config(struct fsl_ssi *ssi, bool
> > enable,
> > bool tx = &ssi->regvals[TX] == vals;
> > + /* Check if the opposite stream is active */
> > + aactive = ssi->streams & BIT(!
On Mon, Jan 01, 2018 at 10:59:30PM +0100, Maciej S. Szmigiero wrote:
> > +static void fsl_ssi_config_enable(struct fsl_ssi *ssi, bool tx)
> > + srcr = vals[tx].srcr;
> > + stcr = vals[tx].stcr;
> > + sier = vals[tx].sier;
>
> Implicit assumption here that RX == 0, T
On Tue, Jan 02, 2018 at 03:28:11PM -0800, Caleb Crome wrote:
> tested this patch set on MX6 SSI against broonie for-next (4.15-rc5),
> no problems.
> Do I send a separate Tested-by for each patch, or just the 00/15 one?
> Tested-by: Caleb Crome
I will include your Tested-by to each patch in v2
On Thu, Jan 4, 2018 at 11:48 AM, Nicolin Chen wrote:
> On Tue, Jan 02, 2018 at 03:28:11PM -0800, Caleb Crome wrote:
>
>> tested this patch set on MX6 SSI against broonie for-next (4.15-rc5),
>> no problems.
>> Do I send a separate Tested-by for each patch, or just the 00/15 one?
>
>> Tested-by: Ca
Hi All,
Do we have some information regarding Spectre+Meltdown for our users?
It could be that we have some security issues in our PowerPC CPUs.
Links:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Retpoline-Patches
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI
On 04.01.2018 20:07, Nicolin Chen wrote:
> On Mon, Jan 01, 2018 at 04:17:20PM +0100, Maciej S. Szmigiero wrote:
>>> AC97 configures some registers earlier to start a communication
>>> with CODECs, so this patch moves those register settings to the
>>> dai_probe() as well, along with other register
On 01/03/2018 06:40 AM, SF Markus Elfring wrote:
> Omit an extra message for a memory allocation failure in this function.
I applied this to my ps3-queue branch.
As I mentioned to you several times before, please keep
the commit subject line to less than 50 characters.
Also, in this case the pref
On Thu, Jan 04, 2018 at 09:38:52PM +0100, Maciej S. Szmigiero wrote:
> > Hmm...What's the dependency here? Why is it required like this?
> And a AC'97 CODEC probe needs AC'97 communication to be working,
> since it has to detect the CODEC model, configure it, etc.
Okay. If the CODEC configuratio
Most subsystem specific functions have been moved into the respective
subsystems. Only PCI and networking remain. This series moves most of the
PCI related code to drivers/pci/of.c. Some bus address functions for PCI
remain in of/address.c because we don't have infrastructure to split up
the per bu
Following what has been done for other subsystems, move the remaining PCI
related code out of drivers/of/ and into drivers/pci/of.c
With this, we can kill a few kconfig symbols.
Cc: Frank Rowand
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring
---
arch/arm/mach-mvebu
Instead of calling both of_irq_parse_pci and irq_create_of_mapping, call
of_irq_parse_and_map_pci instead which does the same thing. This will
allow making of_irq_parse_pci a private, static function.
This changes the logic slightly in that the fallback path will also be
taken if irq_create_of_map
Now that the DT PCI code is merged into drivers/pci, of_irq_parse_pci can
be static.
Cc: Bjorn Helgaas
Cc: Frank Rowand
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/pci/of.c | 3 +--
include/linux/of_pci.h | 6 --
2 files changed, 1 insertion(+), 8 deletions(-
Hello,
On Thu, 4 Jan 2018 16:09:34 +0100
Christian Zigotzky wrote:
> Hi All,
>
> Do we have some information regarding Spectre+Meltdown for our users?
>
> It could be that we have some security issues in our PowerPC CPUs.
>
> Links:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Lin
I assume some of the powerpc platforms would be impacted by the newly
announced meltdown/spetre vulnerabilities. It will be good if we have
an aligned implementation of the KPTI.
Regards,
Leo
On Wed, Jan 03, 2018 at 11:16:28AM -0600, Bryant G. Ly wrote:
> Devices can go offline when EEH is reported. This patch adds
> a change to the kernel object and lets udev know of error.
> When device resumes a change is also set reporting device as
> online. Therefore, EEH events are better propaga
Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
of_irq_parse_and_map instead which does the same thing. This gets us closer
to making the former 2 functions static.
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@li
Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
of_irq_parse_and_map instead which does the same thing. This gets us closer
to making the former 2 functions static.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Sign
On Thu, Jan 4, 2018 at 11:45 PM, Rob Herring wrote:
> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
> of_irq_parse_and_map instead which does the same thing. This gets us closer
> to making the former 2 functions static.
>
> Cc: Arnd Bergmann
> Cc: Benjamin Herrenschmid
On 04/01/18 04:16, Bryant G. Ly wrote:
> To correctly use EEH code one has to make
> sure that the EEH_PE_VF is set for dynamic created
> VFs. Therefore this patch allocates an eeh_pe of
> eeh type EEH_PE_VF and associates PE with parent.
>
> Signed-off-by: Bryant G. Ly
> Signed-off-by: Juan J. A
29 matches
Mail list logo
