The current exeception register structure in selftests are missing
few registers (e.g stval). Instead of adding it manually, change
the ex_regs to align with pt_regs to make it future proof.
Suggested-by: Andrew Jones
Reviewed-by: Andrew Jones
Signed-off-by: Atish Patra
---
.../selftests/kvm/i
On 4/30/25 12:05 AM, Andrew Jones wrote:
On Tue, Apr 29, 2025 at 05:18:45PM -0700, Atish Patra wrote:
The current exeception register structure in selftests are missing
few registers (e.g stval). Instead of adding it manually, change
the ex_regs to align with pt_regs to make it future proof.
On Tue, Apr 29, 2025 at 05:18:45PM -0700, Atish Patra wrote:
> The current exeception register structure in selftests are missing
> few registers (e.g stval). Instead of adding it manually, change
> the ex_regs to align with pt_regs to make it future proof.
>
> Suggested-by: Andrew Jones
> Signed
The current exeception register structure in selftests are missing
few registers (e.g stval). Instead of adding it manually, change
the ex_regs to align with pt_regs to make it future proof.
Suggested-by: Andrew Jones
Signed-off-by: Atish Patra
---
.../selftests/kvm/include/riscv/processor.h
Extent information can be helpful to the user to coordinate memory usage
with the external orchestrator and FM.
Expose the details of region extents by creating the following
sysfs entries.
/sys/bus/cxl/devices/dax_regionX/extentX.Y
/sys/bus/cxl/devices/dax_regionX/extentX.Y
cxl_dpa_to_region() finds the region from a tuple.
The search involves finding the device endpoint decoder as well.
Dynamic capacity extent processing uses the endpoint decoder HPA
information to calculate the HPA offset. In addition, well behaved
extents should be contained within an endpoint
On Sat, 29 Mar 2025 03:30:37 +0530 Siddarth G wrote:
> Cppcheck reported a style warning:
> int result is assigned to long long variable. If the variable is long long
> to avoid loss of information, then you have loss of information.
>
> Changing the type of page_size from &#
Cppcheck reported a style warning:
int result is assigned to long long variable. If the variable is long long
to avoid loss of information, then you have loss of information.
Changing the type of page_size from 'unsigned int' to 'unsigned long long'
was considered. But
from the kernel or userspace.
>
> Additionally, some of the bpf_attr struct fields contain pointers to
> arbitrary memory. Currently the functionality to determine whether or
> not a pointer refers to kernel memory or userspace memory is exposed
> to the bpf verifier, but that infor
exposes that
information to applicable LSM hooks.
Change list:
- v6 -> v7
- use gettid/pid in lieu of getpid/tgid in test condition
- v5 -> v6
- fix regression caused by is_kernel renaming
- simplify test logic
- v4 -> v5
- merge v4 selftest breakout patch back into a single patch
e of this is the bpf_prog_load subcommand and its
> fd_array. This data is made available and used by the verifier but not
> made available to the LSM subsystem. This patchset simply exposes that
> information to applicable LSM hooks.
>
> [...]
Here is the summary with links:
-
struct fields contain pointers to
arbitrary memory. Currently the functionality to determine whether or
not a pointer refers to kernel memory or userspace memory is exposed
to the bpf verifier, but that information is missing from various LSM
hooks.
Here we augment the LSM hooks to provide this data
struct fields contain pointers to
arbitrary memory. Currently the functionality to determine whether or
not a pointer refers to kernel memory or userspace memory is exposed
to the bpf verifier, but that information is missing from various LSM
hooks.
Here we augment the LSM hooks to provide this data
exposes that
information to applicable LSM hooks.
Change list:
- v5 -> v6
- fix regression caused by is_kernel renaming
- simplify test logic
- v4 -> v5
- merge v4 selftest breakout patch back into a single patch
- change "is_kernel" to "kernel"
- add selftest
struct fields contain pointers to
arbitrary memory. Currently the functionality to determine whether or
not a pointer refers to kernel memory or userspace memory is exposed
to the bpf verifier, but that information is missing from various LSM
hooks.
Here we augment the LSM hooks to provide this data
exposes that
information to applicable LSM hooks.
Change list:
- v4 -> v5
- merge v4 selftest breakout patch back into a single patch
- change "is_kernel" to "kernel"
- add selftest using new kernel flag
- v3 -> v4
- split out selftest changes into a separate pa
Extract the meat of __do_cpuid_func_emulated() into a separate helper,
cpuid_func_emulated(), so that cpuid_func_emulated() can be used with a
single CPUID entry. This will allow marking emulated features as fully
supported in the guest cpu_caps without needing to hardcode the set of
emulated feat
On Thu, Nov 7, 2024 at 2:38 PM Luis Chamberlain wrote:
>
> On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> > >
> > > > If booted against an old kernel, it will
> > > > behave as though there is no modversions information.
> > >
On Mon, Nov 18, 2024 at 04:09:34PM -0800, Matthew Maurer wrote:
> > Thinking about this some more, if we're going down enabling a new
> > option, it seems to beg the question if the old *two* ksymtab sections
> > could just be folded into the a new one where the "gpl only" thing
> > becomes just on
On Thu, Nov 07, 2024 at 02:38:13PM -0800, Luis Chamberlain wrote:
> The only thing left I think to test is the impact at runtime, and the
> only thing I can think of is first we use find_symbol() on resolve_symbol()
> which it took me a while to review and realize that this just uses a
> completel
> Thinking about this some more, if we're going down enabling a new
> option, it seems to beg the question if the old *two* ksymtab sections
> could just be folded into the a new one where the "gpl only" thing
> becomes just one "column" as you call it. Reasons I ask, it seems like
> we're duplicat
On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> >
> > > If booted against an old kernel, it will
> > > behave as though there is no modversions information.
> >
> > Huh? This I don't get. If you have the new libkmod and boot
> > an
On Wed, Nov 6, 2024 at 10:27 PM Lucas De Marchi
wrote:
>
> On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> >>
> >> > If booted against an old kernel, it will
> >> > behave as though there is no modversions information.
> >>
> &g
On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> If booted against an old kernel, it will
> behave as though there is no modversions information.
Huh? This I don't get. If you have the new libkmod and boot
an old kernel, that should just not break becauase well, l
>
> > If booted against an old kernel, it will
> > behave as though there is no modversions information.
>
> Huh? This I don't get. If you have the new libkmod and boot
> an old kernel, that should just not break becauase well, long
> symbols were not ever
t; symbols, so it will fail to resolve the symbol and fail the load
> regardless.
Thanks for checking all this. It is exactly what I was looking for.
All this should be part of the cover letter and Kconfig documentation.
> If we add and enable NO_BASIC_MODVERSIONS like you suggested above,
&
hese
symbols, so it will fail to resolve the symbol and fail the load
regardless.
If we add and enable NO_BASIC_MODVERSIONS like you suggested above,
today's --show-modversions will claim there is no modversions data.
Applying a libkmod patch will result in modversions info being
displayed b
On Thu, Oct 31, 2024 at 01:00:28PM -0700, Matthew Maurer wrote:
> > The question is, if only extended moversions are used, what new tooling
> > requirements are there? Can you test using only extended modversions?
> >
> > Luis
>
> I'm not sure precisely what you're asking for. Do you want:
> 1.
> The question is, if only extended moversions are used, what new tooling
> requirements are there? Can you test using only extended modversions?
>
> Luis
I'm not sure precisely what you're asking for. Do you want:
1. A kconfig that suppresses the emission of today's MODVERSIONS
format? This wou
On Wed, Oct 30, 2024 at 11:05:03PM +, Matthew Maurer wrote:
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index
> e6b2427e5c190aacf7b9c5c1bb57fca39d311564..a31c617cd67d3d66b24d2fba34cbd5cc9c53ab78
> 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -208,
Generate both the existing modversions format and the new extended one
when running modpost. Presence of this metadata in the final .ko is
guarded by CONFIG_EXTENDED_MODVERSIONS.
We no longer generate an error on long symbols in modpost if
CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app
On Wed, Oct 23, 2024 at 02:31:29AM +, Matthew Maurer wrote:
> Generate both the existing modversions format and the new extended one
> when running modpost. Presence of this metadata in the final .ko is
> guarded by CONFIG_EXTENDED_MODVERSIONS.
>
> We no longer generate an error on long symbol
Generate both the existing modversions format and the new extended one
when running modpost. Presence of this metadata in the final .ko is
guarded by CONFIG_EXTENDED_MODVERSIONS.
We no longer generate an error on long symbols in modpost if
CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app
On Tue, Oct 15, 2024 at 11:18:59PM +, Matthew Maurer wrote:
> Generate both the existing modversions format and the new extended one
> when running modpost. Presence of this metadata in the final .ko is
> guarded by CONFIG_EXTENDED_MODVERSIONS.
>
> We no longer generate an error on long symbol
On Tue, Oct 15, 2024 at 11:18:59PM +, Matthew Maurer wrote:
> Generate both the existing modversions format and the new extended one
> when running modpost. Presence of this metadata in the final .ko is
> guarded by CONFIG_EXTENDED_MODVERSIONS.
>
> We no longer generate an error on long symbol
Hi Matt,
On Tue, Oct 15, 2024 at 4:19 PM Matthew Maurer wrote:
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 107393a8c48a..d18ff8a1109a 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1840,15 +1840,56 @@ static void add_versions(struct buffer *b,
Generate both the existing modversions format and the new extended one
when running modpost. Presence of this metadata in the final .ko is
guarded by CONFIG_EXTENDED_MODVERSIONS.
We no longer generate an error on long symbols in modpost if
CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app
Generate both the existing modversions format and the new extended one
when running modpost.
We no longer generate an error on long symbols in modpost, as they can
now be appropriately encoded in the extended section. These symbols will
be skipped in the previous encoding.
Signed-off-by: Matthew
On 5/09/2024 8:08 pm, Aaron Lu wrote:
For optimized performance, firmware typically distributes EPC sections
evenly across different NUMA nodes. However, there are scenarios where
a node may have both CPUs and memory but no EPC section configured. For
example, in an 8-socket system with a Sub-
On 9/5/24 07:24, Jarkko Sakkinen wrote:
>> +for_each_online_node(nid) {
>> +if (!node_isset(nid, sgx_numa_mask) &&
>> +node_state(nid, N_MEMORY) && node_state(nid, N_CPU))
>> +pr_info("node%d has both CPUs and memory but doesn't
>> have an EPC se
On Thu Sep 5, 2024 at 11:08 AM EEST, Aaron Lu wrote:
> For optimized performance, firmware typically distributes EPC sections
> evenly across different NUMA nodes. However, there are scenarios where
> a node may have both CPUs and memory but no EPC section configured. For
> example, in an 8-socket
For optimized performance, firmware typically distributes EPC sections
evenly across different NUMA nodes. However, there are scenarios where
a node may have both CPUs and memory but no EPC section configured. For
example, in an 8-socket system with a Sub-Numa-Cluster=2 setup, there
are a total of
On Mon, Sep 2, 2024 at 2:56 AM Thomas Weißschuh wrote:
>
> Various information about modules is compiled into the info sections.
> For that a dedicated .mod.c file is generated by modpost for each module
> and then linked into the module.
> However most of the information in th
Various information about modules is compiled into the info sections.
For that a dedicated .mod.c file is generated by modpost for each module
and then linked into the module.
However most of the information in the .mod.c is the same for all
modules, internal and external.
Split the shared
On Wed, Jun 19, 2024 at 08:30:37AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
&
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce.
Unsigned module case:
(linux) insmod unsigned.ko
[ 18.714661] Loading of unsigned module is rejected
On 6/19/24 02:54, Luis Chamberlain wrote:
On Fri, Jun 14, 2024 at 09:25:19AM +, Yusong Gao wrote:
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce
On Fri, Jun 14, 2024 at 09:25:19AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
&
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce.
Unsigned module case:
(linux) insmod unsigned.ko
[ 18.714661] Loading of unsigned module is rejected
On 4/3/24 12:46, Pavel Machek wrote:
> Hi!
>
>> Libcamera requires the cropping information for each mode, so
>> add this information to the driver.
>
>> @@ -116,6 +124,9 @@ struct imx258_mode {
>> u32 link_freq_index;
>> /* Default register v
On 4/3/24 12:46, Pavel Machek wrote:
> Hi!
>
>> Libcamera requires the cropping information for each mode, so
>> add this information to the driver.
>
>> @@ -116,6 +124,9 @@ struct imx258_mode {
>> u32 link_freq_index;
>> /* Default register v
it is a very minor fix, I think it can be applied
在 2024/3/11 下午4:21, Xianting Tian 写道:
Guest moved avail idx not used idx when we need to print log if
'(vq->avail_idx - last_avail_idx) > vq->num', so fix it.
Signed-off-by: Xianting Tian
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 i
Guest moved avail idx not used idx when we need to print log if
'(vq->avail_idx - last_avail_idx) > vq->num', so fix it.
Signed-off-by: Xianting Tian
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index
me that if the payload is larger than a trace entry, that
it is a trace entry. As trace entries have the interrupt context
information saved in a flags field, look at that location and report the
output of the flags.
If the payload is not a trace entry, there's no way to really know, and
the i
On Mon, 18 Dec 2023 17:01:06 -0500
Steven Rostedt wrote:
> @@ -3347,7 +3418,8 @@ static void check_buffer(struct ring_buffer_per_cpu
> *cpu_buffer,
> }
> }
> if ((full && ts > info->ts) ||
> - (!full && ts + info->delta != info->ts)) {
> + (!full && ts +
me that if the payload is larger than a trace entry, that
it is a trace entry. As trace entries have the interrupt context
information saved in a flags field, look at that location and report the
output of the flags.
If the payload is not a trace entry, there's no way to really know, and
the i
me that if the payload is larger than a trace entry, that
it is a trace entry. As trace entries have the interrupt context
information saved in a flags field, look at that location and report the
output of the flags.
If the payload is not a trace entry, there's no way to really know, and
the i
* desc_reopen_last() checked the caller_info, but there was no
* exclusive access at that point. The descriptor may have
* changed since then.
*/
- if (caller_id != info->caller_id)
+ if (!match(ci, &info->caller_info)
goto fail;
> + return in_task() ? task_pid_nr(current) | (smp_processor_id() <<
> CPU_ID_SHIFT) :
There are contexts and CONFIG options around pre-emption where
smp_processor_id()
will throw a warning. Use raw_smp_processor_id().
-Tony
On Fri, Sep 15, 2023 at 04:46:02PM +0800, Enlin Mu wrote:
> John Ogness 于2023年9月15日周五 16:34写道：
> >
> > On 2023-09-15, Enlin Mu wrote:
> > > Sometimes we want to print cpu id of printk() messages to consoles
> > >
> > > diff --git a/include/linux/threads.h b/include/linux/threads.h
> > > index c34
On Fri, Sep 15, 2023 at 03:40:34PM +0800, Enlin Mu wrote:
> From: Enlin Mu
>
> Sometimes we want to print cpu id of printk() messages to consoles
This is rejected every few years. What has changes from the previous
times this was sent?
And why can't you use trace_printk()?
thanks,
greg k-h
John Ogness 于2023年9月15日周五 16:34写道：
>
> On 2023-09-15, Enlin Mu wrote:
> > Sometimes we want to print cpu id of printk() messages to consoles
> >
> > diff --git a/include/linux/threads.h b/include/linux/threads.h
> > index c34173e6c5f1..6700bd9a174f 100644
> > --- a/include/linux/threads.h
> > +++
On 2023-09-15, Enlin Mu wrote:
> Sometimes we want to print cpu id of printk() messages to consoles
>
> diff --git a/include/linux/threads.h b/include/linux/threads.h
> index c34173e6c5f1..6700bd9a174f 100644
> --- a/include/linux/threads.h
> +++ b/include/linux/threads.h
> @@ -34,6 +34,9 @@
> #d
From: Enlin Mu
Sometimes we want to print cpu id of printk() messages to consoles
Signed-off-by: Enlin Mu
---
include/linux/threads.h | 3 +++
kernel/printk/printk.c | 18 +-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/linux/threads.h b/include/lin
I'll take a look. Generally if you want my attention you
should CC me on the patch.
Sorry for that! Did not notice the entire Cc list earlier.
Best regards,
Pankaj
On Wed, Dec 07, 2022 at 05:09:42AM +0100, Gupta, Pankaj wrote:
> +Cc [MST, virtualization-list]
>
> Hi Dan, MST,
>
> > This patch is reviewed and tested. Is there anything that needs to be
> > done from my side (e.g. sync with mainline)?
>
> If there are no further comments, Can we please merge
+Cc [MST, virtualization-list]
Hi Dan, MST,
This patch is reviewed and tested. Is there anything that needs to be
done from my side (e.g. sync with mainline)?
If there are no further comments, Can we please merge this patch?
Thank You,
Pankaj
(Adding my alternative email address to this t
This patch is reviewed and tested. Is there anything that needs to be
done from my side (e.g. sync with mainline)?
(Adding my alternative email address to this thread as I will soon
lose access to the address I am sending this email from.)
> > > > > > > > Compute the numa information for a virtio_pmem device from the
> > > > > > > > memory
> > > > > > > > range of the device. Previously, the target_node was always 0
> > > > > &
Compute the numa information for a virtio_pmem device from the memory
range of the device. Previously, the target_node was always 0 since
the ndr_desc.target_node field was never explicitly set. The code for
computing the numa node is taken from cxl_pmem_region_probe in
drivers/cxl/pmem.c.
Signed
On Sun, Nov 13, 2022 at 9:44 AM Pankaj Gupta
wrote:
>
> > > Pankaj Gupta wrote:
> > > > > > > Compute the numa information for a virtio_pmem device from the
> > > > > > > memory
> > > > > > > range of the device. Prev
> > Pankaj Gupta wrote:
> > > > > > Compute the numa information for a virtio_pmem device from the
> > > > > > memory
> > > > > > range of the device. Previously, the target_node was always 0 since
> > > > > > the
On Wed, Oct 26, 2022 at 2:50 PM Dan Williams wrote:
>
> Pankaj Gupta wrote:
> > > > > Compute the numa information for a virtio_pmem device from the memory
> > > > > range of the device. Previously, the target_node was always 0 since
> > > > >
Pankaj Gupta wrote:
> > > > Compute the numa information for a virtio_pmem device from the memory
> > > > range of the device. Previously, the target_node was always 0 since
> > > > the ndr_desc.target_node field was never explicitly set. The code for
> >
On Mon, Oct 17, 2022 at 1:11 PM Michael Sammler wrote:
>
> Compute the numa information for a virtio_pmem device from the memory
> range of the device. Previously, the target_node was always 0 since
> the ndr_desc.target_node field was never explicitly set. The code for
> computin
> > > Compute the numa information for a virtio_pmem device from the memory
> > > range of the device. Previously, the target_node was always 0 since
> > > the ndr_desc.target_node field was never explicitly set. The code for
> > > computing the numa node is
Hi Pankaj,
Thank you for looking at the patch.
>
> > Compute the numa information for a virtio_pmem device from the memory
> > range of the device. Previously, the target_node was always 0 since
> > the ndr_desc.target_node field was never explicitly set. The code for
> &
> Compute the numa information for a virtio_pmem device from the memory
> range of the device. Previously, the target_node was always 0 since
> the ndr_desc.target_node field was never explicitly set. The code for
> computing the numa node is taken from cxl_pmem_region_probe in
&
Compute the numa information for a virtio_pmem device from the memory
range of the device. Previously, the target_node was always 0 since
the ndr_desc.target_node field was never explicitly set. The code for
computing the numa node is taken from cxl_pmem_region_probe in
drivers/cxl/pmem.c.
Signed
Set the allocation length to 255 for the ATA Information VPD page
requested in the WRITE SAME handler, so as not to limit information
examined by `scsi_get_vpd_page' in the supported vital product data
pages unnecessarily.
Originally it was thought that Areca hardware may have issues w
On Thu, 15 Apr 2021, Nix wrote:
> > Set the allocation length to 255 for the ATA Information VPD page
> > requested in the WRITE SAME handler, so as not to limit information
> > examined by `scsi_get_vpd_page' in the supported vital product data
> > pages unneces
On 14 Apr 2021, Maciej W. Rozycki stated:
> Set the allocation length to 255 for the ATA Information VPD page
> requested in the WRITE SAME handler, so as not to limit information
> examined by `scsi_get_vpd_page' in the supported vital product data
> pages unnecessarily.
>
Hi Nick,
Thanks a lot for looking into this!
On Thu, Apr 15, 2021 at 12:18 AM Nick Desaulniers
wrote:
>
> Was this TODO meant to be removed, or is it still pending? If pending,
> on what? Being able to link back on itself if/once merged?
Still pending -- the plan is to upload the docs to kernel
Set the allocation length to 255 for the ATA Information VPD page
requested in the WRITE SAME handler, so as not to limit information
examined by `scsi_get_vpd_page' in the supported vital product data
pages unnecessarily.
Originally it was thought that Areca hardware may have issues w
le
> (e.g. drivers) written across the kernel.
>
> These documents are general information that do not fit particularly
> well in the source code, like the quick start guide.
>
> Co-developed-by: Alex Gaynor
> Signed-off-by: Alex Gaynor
> Co-developed-by: Geoffrey Thom
information that do not fit particularly
well in the source code, like the quick start guide.
Co-developed-by: Alex Gaynor
Signed-off-by: Alex Gaynor
Co-developed-by: Geoffrey Thomas
Signed-off-by: Geoffrey Thomas
Co-developed-by: Finn Behrens
Signed-off-by: Finn Behrens
Co-developed-by: Adam
Add IPA-related nodes and definitions to "sm8350.dtsi", which uses
IPA v4.9.
Signed-off-by: Alex Elder
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 51
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm835
add gce information for mmsys
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index bc89283..e3a8b10 100644
--- a/arch/arm64/boot
d in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Alex-Elder/ARM-dts-qcom-sdx55-add-IPA-information/20210409-235428
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-defconfig (attached as .config)
compiler:
Add IPA-related nodes and definitions to "sdx55.dtsi". The SMP2P
nodes (ipa_smp2p_out and ipa_smp2p_in) are already present.
Signed-off-by: Alex Elder
---
Note: This depends on this series posted by Mani Sadhasivam:
https://lore.kernel.org/linux-arm-msm/20210408170457.91409-1-manivannan.sadha
add compitable/reg/irq/clock/efuse setting in svs node
Signed-off-by: Roger Lu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a145
add compitable/reg/irq/clock/efuse/reset setting in svs node
Signed-off-by: Roger Lu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
ind
Display information in probe regarding PHY configuration parameters like
single link or multilink protocol information along with number of lanes
used for each protocol link.
Signed-off-by: Swapnil Jakhade
---
drivers/phy/cadence/phy-cadence-torrent.c | 32 +--
1 file
This patch series fixes the documentation issues reported by doing
*make htmldocs*, such as:
- indentation
- text formatting
- missing entry on the table of content related to dw-xdata-pcie misc
driver index
Besides these warnings also fixes some outdated information related to
stop file
From: Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 byte
From: Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 byte
From: Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 byte
From: Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 byte
From: Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 byte
From: Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 byte
1 - 100 of 3452 matches
Mail list logo
