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 warn
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.
>
>
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 old
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 fo
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 br
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 descriptio
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 brev
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 b
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 unde
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 NO
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 kernel
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 i
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 distrib
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 errors.
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 rout
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: 54c
+ 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.
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 config
"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 CONFIG_C
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
>> of
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 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> e
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 wo
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 r
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 runtime
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
.../n
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 soo
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 var
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
.../
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 M
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, s
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 PCS
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 = <&sys_clk>;
(and associated sys_clk node).
"
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 b
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
35 matches
Mail list logo
