Received frame from QMC contains the CRC.
Upper layers don't need this CRC and tcpdump mentioned trailing junk
data due to this CRC presence.
As some other HDLC driver, simply discard this CRC.
Fixes: d0f2258e79fd ("net: wan: Add support for QMC HDLC")
Cc: sta...@vger.kernel.org
Signed-off-by: He
The carrier_lock spinlock protects the carrier detection. While it is
hold, framer_get_status() is called witch in turn takes a mutex.
This is not correct and can lead to a deadlock.
A run with PROVE_LOCKING enabled detected the issue:
[ BUG: Invalid wait context ]
...
c204ddbc (&framer->mut
Hi Herve,
kernel test robot noticed the following build errors:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v6.11-rc1 next-20240729]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
Hi Herve,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v6.11-rc1 next-20240729]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
master v6.11-rc1 next-20240729]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://gi
Hi Herve,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v6.11-rc1 next-20240729]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On 26.07.24 13:37, Rob Herring wrote:
+ Ubuntu kernel list, again
On Thu, Jul 25, 2024 at 11:15:39PM +0530, Amit Machhiwal wrote:
Hi Lizhi, Rob,
Sorry for responding late. I got busy with some other things.
On 2024/07/23 02:08 PM, Lizhi Hou wrote:
On 7/23/24 12:54, Rob Herring wrote:
On Tu
The CXL driver has its own custom implementations of typed DT property
accessors. Replace the custom property accessor functions with the
common DT property functions.
This clean-up is part of a larger effort to remove of_get_property() and
other DT functions which leak pointers to DT node and pro
++---
drivers/misc/cxl/pci.c | 32
2 files changed, 36 insertions(+), 203 deletions(-)
---
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
change-id: 20240729-dt-cxl-cleanup-eaf8185a99fc
Best regards,
--
Rob Herring (Arm)
There's little reason to dump DT property values when they can be read
at any time from the DT in /proc/device-tree. If such a feature is
needed, then it really should be implemented in the DT core such that
any module/driver can use it.
Signed-off-by: Rob Herring (Arm)
---
drivers/misc/cxl/of.c
Hi,
On Tue, Jul 02, 2024 at 03:51:28PM +0200, Christophe Leroy wrote:
> At the time being when CONFIG_PTE_64BIT is selected, PTE entries are
> 64 bits but PGD entries are still 32 bits.
>
> In order to allow leaf PMD entries, switch the PGD to 64 bits entries.
>
> Signed-off-by: Christophe Leroy
Hi Baruch,
kernel test robot noticed the following build warnings:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on powerpc/next powerpc/fixes s390/features
linus/master v6.11-rc1 next-20240729]
[If your patch is applied to the wrong git tree, kindly drop us a note
Convert dt-binding rcpm from txt to yaml format.
Add fsl,ls1028a-rcpm compatible string.
Signed-off-by: Frank Li
---
.../bindings/rtc/fsl,ls-ftm-alarm.yaml| 2 +-
.../devicetree/bindings/soc/fsl/fsl,rcpm.yaml | 91 +++
.../devicetree/bindings/soc/fsl/rcpm.txt | 69 -
On Mon, 29 July 2024, Ilpo Järvinen wrote:
> The most obvious solution is to not leave the speed at Gen1 on failure in
> Target Speed quirk but to restore the original Target Speed value. The
> downside with that is if the current retraining interface (function) is
> used, it adds delay.
Tends to
On 7/29/24 09:55, Amit Machhiwal wrote:
Hi Lizhi,
On 2024/07/29 09:47 AM, Lizhi Hou wrote:
Hi Amit
On 7/29/24 04:13, Amit Machhiwal wrote:
Hi Lizhi,
On 2024/07/26 11:45 AM, Lizhi Hou wrote:
On 7/26/24 10:52, Rob Herring wrote:
On Thu, Jul 25, 2024 at 6:06 PM Lizhi Hou wrote:
Hi Amit,
Hi Lizhi,
On 2024/07/29 09:47 AM, Lizhi Hou wrote:
> Hi Amit
>
> On 7/29/24 04:13, Amit Machhiwal wrote:
> > Hi Lizhi,
> >
> > On 2024/07/26 11:45 AM, Lizhi Hou wrote:
> > > On 7/26/24 10:52, Rob Herring wrote:
> > > > On Thu, Jul 25, 2024 at 6:06 PM Lizhi Hou wrote:
> > > > > Hi Amit,
> > > >
Hi Amit
On 7/29/24 04:13, Amit Machhiwal wrote:
Hi Lizhi,
On 2024/07/26 11:45 AM, Lizhi Hou wrote:
On 7/26/24 10:52, Rob Herring wrote:
On Thu, Jul 25, 2024 at 6:06 PM Lizhi Hou wrote:
Hi Amit,
I try to follow the option which add a OF flag. If Rob is ok with this,
I would suggest to use
Hello:
This pull request was applied to riscv/linux.git (for-next)
by Linus Torvalds :
On Wed, 24 Jul 2024 23:00:14 +0200 you wrote:
> Linus
>
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as they would reside in .rodata. To get
> there, the pr
Hello:
This pull request was applied to riscv/linux.git (fixes)
by Linus Torvalds :
On Wed, 24 Jul 2024 23:00:14 +0200 you wrote:
> Linus
>
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as they would reside in .rodata. To get
> there, the proc_
Hello Michael,
In the case of no sibling call within the livepatch then the store is
only "restoring" the r2 value that was already there as it is stored
and retrieved from the livepatch stack. The only time that the r2 value
is corrupted is in the case of a sibling call and thus this additi
On Mon, 29 Jul 2024, Ilpo Järvinen wrote:
> > > The main reason is it is believed that it is the downstream device
> > > causing the issue, and obviously you can't fetch its ID if you can't
> > > negotiate link so as to talk to it in the first place.
> >
> > Have had some more time to look into t
On Mon, Jul 29, 2024 at 03:27:11PM +0100, Dave Martin wrote:
> On Fri, Jul 26, 2024 at 06:39:27PM +0100, Mark Brown wrote:
> > Yes, though that would mean if we had to generate any register in there
> > we'd always have to generate at least as many entries as whatever number
> > it got assigned wh
On Fri, Jul 26, 2024 at 06:39:27PM +0100, Mark Brown wrote:
> On Fri, Jul 26, 2024 at 05:14:01PM +0100, Dave Martin wrote:
> > On Thu, Jul 25, 2024 at 07:11:41PM +0100, Mark Brown wrote:
>
> > > That'd have to be a variably sized structure with pairs of sysreg
> > > ID/value items in it I think wh
The QUICC Engine (QE) QMC can use a firmware to have the QMC working in
'soft-qmc' mode.
Handle this optional 'soft-qmc' firmware.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 67
1 file changed, 67 insertions(+)
diff --git a/drivers/soc/f
checkpatch.pl raises the following issue
CHECK: spinlock_t definition without comment
Add the missing comments.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
Introduce devm_cpm_muram_alloc() and devm_cpm_muram_alloc_fixed(), the
resource-managed version of cpm_muram_alloc and cpm_muram_alloc_fixed().
These resource-managed versions simplify the user avoiding the need to
call cpm_muram_free(). Indeed, the allocated area returned by these
functions will
checkpatch.pl signals the following improvement for qmc.c
CHECK: Prefer using the BIT macro
Follow its suggestion and convert the code to BIT() and related macros.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 132 +--
1 file changed, 72 insert
Current code handles the CPM1 version of QMC, RPACK does not need to
be initialized. This is not the case in the QUICC Engine (QE) version.
In preparation of the support for QE, initialize the RPACK register
when the receiver is initialized and each time it is restarted.
This additional RPACK ini
Current code handles the CPM1 version of QMC and initialize the QMC used
SCC. The QUICC Engine (QE) version uses an UCC (Unified Communication
Controllers) instead of the SCC (Serial Communication Controllers) used
in the CPM1 version. These controllers serve the same purpose and are
used in the sa
The Freescale QMC controller driver supports both QE and CPM1.
Add the newly introduced QE files to the existing entry.
Signed-off-by: Herve Codina
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1d32d38f2247..1331bdeb7386 100644
--- a/MAINTAI
Add support for the QMC (QUICC Multichannel Controller) available in
some PowerQUICC SoC that uses a QUICC Engine (QE) block such as MPC8321.
This QE QMC is similar to the CPM QMC except that it uses UCCs (Unified
Communication Controllers) instead of SCCs (Serial Communication
Controllers). Also,
The PUSHSCHED command is missing in the QE header file.
This command is supported on MPC8321 and is used to modify the start
address for the task running on a given peripheral. It is needed for the
QMC in order to perform the re-initialization procedure and so, ensure
the correct UCC setup in that
Current code handles the CPM1 version of QMC.
In order to prepare the support for the QUICC Engine (QE) version of
QMC, introduce qmc_version to identify versions. This will enable the
code to make the distinction between several QMC implementations.
Signed-off-by: Herve Codina
---
drivers/soc/
Current code handles CPM1 version of QMC. Even if GSMRL is specific to
the CPM1 version, the exact same purpose and format register (GUMRL) is
present in the QUICC Engine (QE) version of QMC. Compared to the QE
version, the values defined for the mode bitfield are different and the
0x0A value defin
Current code handles CPM1 version of QMC and qmc_chan_command() is
clearly CPM1 specific.
In order to prepare the support for the QUICC Engine (QE) version,
rename qmc_chan_command() to reflect that point.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 6 +++---
1 file changed, 3 in
Current code handles CPM1 version of QMC. In the QUICC Engine (QE)
version, some operations done at probe() need to be done in a different
order.
In order to prepare the support for the QE version, changed the sequence
of operation done at probe():
- Retrieve the tsa_serial earlier, before initial
Current code handles the CPM1 version of QMC. Resources initialisations
(i.e. retrieving base addresses and offsets of different parts) will
be slightly different in the QUICC Engine (QE) version. Indeed, in QE
version, some resources need to be allocated and are no more "staticaly"
defined.
In or
Current code handles CPM1 version of QMC. Some hardcoded values are used
several times to initialize the QMC state machine. In the QUICC Engine
(QE) version of QMC, these values are different.
In order to prepare the support for the QE version of QMC and avoid the
copy of the hardcoded values, int
Add support for the QMC (QUICC Multichannel Controller) available in
some PowerQUICC SoC that uses a QUICC Engine (QE) block such as MPC8321.
This QE QMC is similar to the CPM QMC except that it uses UCCs (Unified
Communication Controllers) instead of SCCs (Serial Communication
Controllers). Also,
checkpatch.pl raises the following issue
CHECK: 'transmiter' may be misspelled - perhaps 'transmitter'?
Indeed, fix it.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/q
checkpatch.pl raises the following issue in several places
CHECK: Unnecessary parenthesis around ...
Remove them.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/
checkpatch.pl raises the following issues
CHECK: Please don't use multiple blank lines
CHECK: Alignment should match open parenthesis
Fix them.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/soc
QMC_TSA_MASK is a bitfield. The value defined is a specific value of
this bitfield and correspond to the use of 8bit resolution for the
routing entry.
Be accurate and rename the defined constant to reflect this point.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 8
1 file
TSA consumers in CPM1 implementation don't need to know about the serial
device number used by the TSA component. In QUICC Engine implementation,
this information is needed.
Improve the TSA API with tsa_serial_get_num() in order to provide this
information.
Signed-off-by: Herve Codina
---
drive
The Freescale TSA controller driver supports both QE and CPM1.
Add the newly introduced QE files to the existing entry.
Signed-off-by: Herve Codina
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42decde38320..1d32d38f2247 100644
--- a/MAINT
Add support for the time slot assigner (TSA) available in some
PowerQUICC SoC that uses a QUICC Engine (QE) block such as MPC8321.
The QE TSA is similar to the CPM1 TSA except that it uses UCCs (Unified
Communication Controllers) instead of SCCs (Serial Communication
Controllers).
Also, compared a
Current code handles the CPM1 version of TSA. Compared against QUICC
Engine (QE) version of TSA, CPM1 SIRAM entries are slightly different.
In order to prepare the support for the QE version, clearly identify
these entries and functions handling them as CPM1 compatible.
Signed-off-by: Herve Codin
Current code handles the CPM1 version of TSA. Connecting and
disconnecting the SCC to/from the TSA consists in handling SICR register
which is CPM1 specific. The connection and disconnection operation in
the QUICC Engine (QE) version are slightly different.
In order to prepare the support for the
Current code handles the CPM1 version of TSA. Setting up TSA consists in
handling SIMODE and SIGMR registers. These registers are CPM1 specific.
Setting up the QUICC Engine (QE) version of TSA is slightly different.
In order to prepare the support for QE version, clearly identify these
registers
Current code handles CPM1 version of TSA.
In order to prepare the support for the QUICC Engine (QE) version of
TSA, introduce tsa_version to identify versions. This will enable the
code to make the distinction between several TSA implementations.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/
Loops handling the tdm array use hardcoded size and the initialization
part uses hardcoded indexes to initialize the array.
Use ARRAY_SIZE() to avoid the hardcoded size and initialize the array
using a loop.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/tsa.c | 8
1 file changed,
checkpatch.pl raises the following issues
CHECK: Please don't use multiple blank lines
CHECK: spaces preferred around that '/' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
Fix them.
Signed-off-by: Herve Codina
---
drivers/
The TRNSYNC feature is enabled whatever the number of time-slots used.
The feature is needed only when more than one time-slot is used.
Improve the driver enabling TRNSYNC only when it is needed.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/qmc.c | 12 +++-
1 file changed, 11 inse
Add support for the time slot assigner (TSA) available in some
PowerQUICC SoC that uses a QUICC Engine (QE) block such as MPC8321.
This QE TSA is similar to the CPM TSA except that it uses UCCs (Unified
Communication Controllers) instead of SCCs (Serial Communication
Controllers). Also, compared a
Hi,
This series add support for the QUICC Engine (QE) version of TSA and QMC
components.
CPM1 version is already supported and, as the QE version of those
component are pretty similar to the CPM1 version, the series extend
the already existing drivers to support for the QE version.
The TSA and Q
SISTR, SICMR and SIRP registers offset definitions are not used.
In order to avoid unneeded code, remove them.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/tsa.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c
index a9d35b444
The TRNSYNC feature is available (and enabled) only in transparent mode.
Since commit 7cc9bda9c163 ("soc: fsl: cpm1: qmc: Handle timeslot entries
at channel start() and stop()") TRNSYNC register is updated in
transparent and hdlc mode. In hdlc mode, the address of the TRNSYNC
register is used by t
checkpatch.pl raises the following issue
CHECK: spinlock_t definition without comment
Add the missing comment.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/tsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c
index
The tsa_write8() parameter is an u32 value. This is not consistent with
the function itself. Indeed, tsa_write8() writes an 8bits value.
Be consistent and use an u8 parameter value.
Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA")
Cc: sta...@vger.kernel.org
Signed-off-by: Herve Codina
checkpatch.pl signals the following improvement for tsa.c
CHECK: Prefer using the BIT macro
Follow its suggestion and convert the code to BIT() and related macros.
Signed-off-by: Herve Codina
---
drivers/soc/fsl/qe/tsa.c | 127 +--
1 file changed, 68 insert
Hi Ryan,
Thanks for the patch.
Ryan Sullivan writes:
> Currently, on PowerPC machines, sibling calls in livepatched functions
> cause the stack to be corrupted and are thus not supported by tools
> such as kpatch. Below is an example stack frame showing one such
> currupted stacks:
...
> diff --
On Mon Jul 29, 2024 at 4:29 PM EEST, Stefan Berger wrote:
> Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced
> CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the
> following message appears in the kernel log due to a missing call to
> tpm2_sessions_init().
>
> [
Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced
CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the
following message appears in the kernel log due to a missing call to
tpm2_sessions_init().
[2.654549] tpm tpm0: auth session is not active
Add the missing call
On Fri, Jul 26, 2024 at 05:07:26PM +0200, David Hildenbrand wrote:
> Let's clean that up a bit and prepare for depending on
> CONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options.
>
> More cleanups would be reasonable (like the arch-specific "depends on"
> for CONFIG_SPLIT_PTE_PTLOCKS), but we'll lea
Hi Lizhi,
On 2024/07/26 11:45 AM, Lizhi Hou wrote:
>
> On 7/26/24 10:52, Rob Herring wrote:
> > On Thu, Jul 25, 2024 at 6:06 PM Lizhi Hou wrote:
> > > Hi Amit,
> > >
> > >
> > > I try to follow the option which add a OF flag. If Rob is ok with this,
> > > I would suggest to use it instead of V
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB.
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Reported-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
kernel/dma/direc
Current code using zone_dma_limit assume that all address range below
limit is suitable for DMA. For some existing platforms this assumption
is not correct. DMA range might have non zero lower limit.
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made DMA/
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Signed-off-by: Catalin Marinas
Signed-off-by:
On Fri, 26 Jul 2024, Matthew W Carlis wrote:
> On Mon, 22 Jul 2024, Maciej W. Rozycki wrote:
>
> > The main reason is it is believed that it is the downstream device
> > causing the issue, and obviously you can't fetch its ID if you can't
> > negotiate link so as to talk to it in the first place.
Hi Arnd,
On Mon, Jul 29, 2024 at 11:55 AM Arnd Bergmann wrote:
> On Mon, Jul 29, 2024, at 11:35, Geert Uytterhoeven wrote:
> >> + /kisskb/src/kernel/fork.c: error: #warning clone3() entry point is
> >> missing, please fix [-Werror=cpp]: => 3072:2
> >
> > sh4-gcc13/se{7619,7750}_defconfig
> > s
On Mon, Jul 29, 2024, at 11:35, Geert Uytterhoeven wrote:
>
>> + /kisskb/src/kernel/fork.c: error: #warning clone3() entry point is
>> missing, please fix [-Werror=cpp]: => 3072:2
>
> sh4-gcc13/se{7619,7750}_defconfig
> sh4-gcc13/sh-all{mod,no,yes}config
> sh4-gcc13/sh-defconfig
> sparc64-gcc5/s
On Mon, 29 Jul 2024, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.11-rc1[1] compared to v6.10[2].
Summarized:
- build errors: +7/-22
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8400291e289ee6b2bf9779ff1c83a291501f017b/
(all
On Tue, 2024-06-18 at 13:09 +, LEROY Christophe wrote
>
> Seems like this series doesn't apply, patch 1 has conflict with
> RISCV,
> patch 2 with mm and RISCV.
>
> Please rebase as appropriate.
As you've probably gathered from the mailer-daemon failure notice I
assume you probably received,
On 7/25/2024 11:54 AM, Shengjiu Wang wrote:
There are some register difference for i.MX8 and i.MX9
REG_MICFIL_FIFO_CTRL definition is updated.
REG_MICFIL_FSYNC_CTRL, REG_MICFIL_VERID, REG_MICFIL_PARAM are added from
i.MX9
Shengjiu Wang (2):
ASoC: fsl_micfil: Expand the range of FIFO watermark
On 2024/7/26 23:07, David Hildenbrand wrote:
Let's clean that up a bit and prepare for depending on
CONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options.
More cleanups would be reasonable (like the arch-specific "depends on"
for CONFIG_SPLIT_PTE_PTLOCKS), but we'll leave that for another day.
S
76 matches
Mail list logo
