tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 274d7803837da78dfc911bcda0d593412676fc20 Add linux-next specific
files for 20220930
Error/Warning reports:
https://lore.kernel.org/linux-mm/202209150141.wgbakqmx-...@intel.com
https
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
topic/ppc-kvm
branch HEAD: 1a5486b3c3517aa1f608a10003ade4da122cb175 KVM: PPC: Book3S HV P9:
Restore stolen time logging in dtl
elapsed time: 724m
configs tested: 76
configs skipped: 111
The following configs have
On Thu, 2022-09-29 at 11:55 +0930, Joel Stanley wrote:
> This is the register layout of the litesd peripheral for the fusesoc
> based Microwatt SoC.
The register layout looks right, but the upstream litemmc driver also now
needs the property
clocks = <_clk>;
(and associated sys_clk node).
Now that we actually read registers from QSGMII PCSs, it's important
that we have the correct address (instead of hoping that we're the MAC
with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII
PCSs. The exact mapping of QSGMII to MACs depends on the SoC.
Since the first QSGMII
This allows multiple phandles to be specified for pcs-handle, such as
when multiple PCSs are present for a single MAC. To differentiate
between them, also add a pcs-handle-names property.
Signed-off-by: Sean Anderson
---
This was previously submitted as [1]. I expect to update this series
more,
Now that we actually read registers from QSGMII PCSs, it's important
that we have the correct address (instead of hoping that we're the MAC
with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII
PCSs. They have the same addresses on all SoCs (e.g. if QSGMIIA is
present it's used for
On the T208X SoCs, MAC1 and MAC2 support XGMII. Add some new MAC dtsi
fragments, and mark the QMAN ports as 10G.
Fixes: da414bb923d9 ("powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the
SoC device tree(s)")
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- New
This converts DPAA to phylink. All macs are converted. This should work
with no device tree modifications (including those made in this series),
except for QSGMII (as noted previously).
The mEMAC configuration is one of the tricker areas. I have tried to
capture all the restrictions across the
Although not stated in the datasheet, as far as I can tell PCS for mEMACs
is a "Lynx." By reusing the existing driver, we can remove the PCS
management code from the memac driver. This requires calling some PCS
functions manually which phylink would usually do for us, but we will let
it do that
This adds support for using a serdes which has to be configured. This is
primarly in preparation for the next commit, which will then change the
serdes mode dynamically.
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- Don't fail if phy support was not compiled in
At the moment, mEMACs are configured almost completely based on the
phy-connection-type. That is, if the phy interface is RGMII, it assumed
that RGMII is supported. For some interfaces, it is assumed that the
RCW/bootloader has set up the SerDes properly. This is generally OK, but
restricts
This binding is fairly bare-bones for now, since the Lynx driver doesn't
parse any properties (or match based on the compatible). We just need it
in order to prevent the PCS nodes from having phy devices attached to
them. This is not really a problem, but it is a bit inefficient.
This binding is
This series converts the DPAA driver to phylink.
I have tried to maintain backwards compatibility with existing device
trees whereever possible. However, one area where I was unable to
achieve this was with QSGMII. Please refer to patch 2 for details.
All mac drivers have now been converted. I
On Fri, Sep 30, 2022 at 12:01:26PM +1000, Michael Ellerman wrote:
> Matthew Wilcox writes:
> >> [ 4681.238745] Instruction dump:
> >> [ 4681.238749] fbc1fff0 f821ffc1 7c7d1b78 7c9c2378 ebc30028 7fdff378
> >> 4818 6000
> >> [ 4681.238765] 6000 ebff0008 7c3ef840 41820048 <815f0060>
On Mon, 26 Sep 2022 15:03:14 -0400, Sean Anderson wrote:
> This binding is fairly bare-bones for now, since the Lynx driver doesn't
> parse any properties (or match based on the compatible). We just need it
> in order to prevent the PCS nodes from having phy devices attached to
> them. This is not
On Fri, Sep 30, 2022, at 3:19 PM, Michael Ellerman wrote:
> "Arnd Bergmann" writes:
>>
>> While sys_mmap_pgoff() was meant to replace the various sys_mmap2()
>> implementations, I think it was ultimately a mistake, and we later
>> converged on the sys_mmap2() calling conventions with 12 bits
>>
"Arnd Bergmann" writes:
> On Wed, Sep 28, 2022, at 2:15 PM, Michael Ellerman wrote:
>
>> But I think it makes more sense to do the same as mmap2() and pass the
>> 4K offset through, and pass shift = PAGE_SHIFT - 12. I also borrowed the
>> "off_4k" name from arm64. End result:
>>
>> #ifdef
Lukas Bulwahn writes:
> On Fri, Sep 30, 2022 at 9:42 AM Michael Ellerman wrote:
>>
>> Lukas Bulwahn writes:
>> > Clean up config files by:
>> > - removing configs that were deleted in the past
>> > - removing configs not in tree and without recently pending patches
>> > - adding new
+ CC hwmon ML
On Friday 30 September 2022 14:39:01 Pali Rohár wrote:
> Channel 0 of SA56004ED chip refers to internal SA56004ED chip sensor (chip
> itself is located on the board) and channel 1 of SA56004ED chip refers to
> external sensor which is connected to temperature diode of the P2020 CPU.
On Fri, 30 Sep 2022 14:39:01 +0200
Pali Rohár wrote:
> Channel 0 of SA56004ED chip refers to internal SA56004ED chip sensor (chip
> itself is located on the board) and channel 1 of SA56004ED chip refers to
> external sensor which is connected to temperature diode of the P2020 CPU.
>
> Fixes:
Channel 0 of SA56004ED chip refers to internal SA56004ED chip sensor (chip
itself is located on the board) and channel 1 of SA56004ED chip refers to
external sensor which is connected to temperature diode of the P2020 CPU.
Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x
Li Huafei wrote:
I found a null pointer reference in arch_prepare_kprobe():
Good find!
# echo 'p cmdline_proc_show' > kprobe_events
# echo 'p cmdline_proc_show+16' >> kprobe_events
I think we should extend multiple_kprobes selftest to also place
contiguous probes to catch such
Thadeu Lima de Souza Cascardo wrote:
On Tue, Sep 27, 2022 at 01:22:11PM +0530, Srikar Dronamraju wrote:
Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section
failures")
can cause scripts/faddr2line to fail on ppc64le machines on few
distributions, while working on other
Michal Suchánek writes:
> On Thu, Sep 29, 2022 at 05:16:40PM -0500, Nathan Lynch wrote:
>> Haren Myneni writes:
>> > Generally the hypervisor decides to allocate a window on different
>> > VAS instances. But if the user space wishes to allocate on the
>> > current VAS instance where the process
Hello,
On Thu, Sep 29, 2022 at 05:16:40PM -0500, Nathan Lynch wrote:
> Haren Myneni writes:
> > Generally the hypervisor decides to allocate a window on different
> > VAS instances. But if the user space wishes to allocate on the
> > current VAS instance where the process is executing, the
The following message is seen during boot and the activation of
console port gets delayed until normal serial ports activation.
[0.001346] irq: no irq domain found for pic@930 !
The console port doesn't need irq, perform irq reservation later,
during cpm_uart probe.
While at it, don't use
Add firmware version details to the hardware description, which is
printed at boot and in case of an oops.
Use /hypervisor if we find it, though currently it only exists if we're
running under qemu.
Look for "ibm,powervm-partition" which is specified in PAPR+ v2.11 and
tells us we're running
Add OPAL version details to the hardware description, which is printed
at boot and in case of an oops.
eg: Hardware name: ... opal:v6.2
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powernv/setup.c | 22 ++
1 file changed, 22 insertions(+)
v3: Drop quotes for
Add the PVR and CPU name to the hardware description, which is printed
at boot and in case of an oops.
eg: Hardware name: ... POWER8E (raw) 0x4b0201
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 4
1 file changed, 4 insertions(+)
v3: Drop "cpu:" and "pvr:" tags for
Create a hardware description string, which we will use to record
various details of the hardware platform we are running on.
Print the accumulated description at boot, and use it to set the generic
description which is printed in oopses.
To begin with add ppc_md.name, aka the "machine
If we detect a logical PVR add that to the hardware description, which
is printed at boot and in case of an oops.
eg: Hardware name: ... 0xf04
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
v3: Drop "lpvr:" tag for
Add the model of the machine we're on to the hardware description, which
is printed at boot and in case of an oops.
eg: Hardware name: IBM,8247-22L
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 19 +++
1 file changed, 19 insertions(+)
v3: Drop "model:" tag
On Fri, Sep 30, 2022 at 9:42 AM Michael Ellerman wrote:
>
> Lukas Bulwahn writes:
> > Clean up config files by:
> > - removing configs that were deleted in the past
> > - removing configs not in tree and without recently pending patches
> > - adding new configs that are replacements for
Lukas Bulwahn writes:
> Clean up config files by:
> - removing configs that were deleted in the past
> - removing configs not in tree and without recently pending patches
> - adding new configs that are replacements for old configs in the file
>
> For some detailed information, see Link.
>
Christophe Leroy writes:
> Le 01/09/2022 à 10:54, ruanjinjie a écrit :
>> [Vous ne recevez pas souvent de courriers de ruanjin...@huawei.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> When build Linux kernel, encounter the following
This is the register layout of the litesd peripheral for the fusesoc
based Microwatt SoC.
It requires a description of the system clock, which is hardcoded to
100MHz.
Signed-off-by: Joel Stanley
---
v2:
* remove non-removable property
* Remove status=disabled
* Add clock
---
Each ASoC platform driver is named by rpmsg channel. ASoC machine
driver can parse "fsl,rpmsg-channel-name" property to figure out which
ASoC platform driver it should link with.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/imx-rpmsg.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Some sound card based on rpmsg may support multi-channel. This patch
expands the maximum channels to 32.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_rpmsg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
index
This driver helps register ASoC machine device thus use of
PLATFORM_DEVID_AUTO macro in API can automatically create device for
each sound card based on rpmsg.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_rpmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Some sound card based on rpmsg may support multi-channel. The number of
channels can be sent to Cortex-M in rpmsg for process.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/imx-pcm-rpmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-pcm-rpmsg.c
This patch can register different ASoC platform drivers if there are
several rpmsg channels. Thus sound cards based on different rpmsg
channels can link to their respective platform drivers. Besides, the
name of driver is equal to the name of rpmsg channel.
Signed-off-by: Chancel Liu
---
Rpmsg channel for MICFIL can also be created through rpmsg name service
announcement. If this driver is probed, Cortex-A can access MICFIL
which is actually controlled by Cortex-M through rpmsg channel for
MICFIL. This driver also helps register ASoC platform device thus use
of PLATFORM_DEVID_AUTO
Add a string property to assign the rpmsg channel this sound card sits
on. This property can be omitted if there is only one sound card and it
sits on "rpmsg-audio-channel".
Signed-off-by: Chancel Liu
---
.../devicetree/bindings/sound/fsl,rpmsg.yaml | 36 +--
1 file changed, 34
At a previous time, we have successfully created a virtual sound card
based on rpmsg. The sound card works under this mechanism Cortex-A core
tells the Cortex-M core the format, rate, channel, .etc configuration
of the PCM parameters and Cortex-M controls real hardware devices such
as SAI and DMA.
On 2022/9/30 14:09, Christophe Leroy wrote:
>
>
> Le 01/09/2022 à 10:54, ruanjinjie a écrit :
>> [Vous ne recevez pas souvent de courriers de ruanjin...@huawei.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> When build Linux kernel,
Le 01/09/2022 à 10:54, ruanjinjie a écrit :
> [Vous ne recevez pas souvent de courriers de ruanjin...@huawei.com. Découvrez
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> When build Linux kernel, encounter the following warnings:
>
>
46 matches
Mail list logo
