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
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
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
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
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
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
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
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(-
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
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
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
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
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 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
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 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
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 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 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 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 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 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
> >
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 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
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 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 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 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 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
29 matches
Mail list logo
