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
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
On Wed, 31 Mar 2021 15:10:46 +0800, Jack Yu wrote:
> Add address-cells and size-cells information to fix warnings
> for rt1019.yaml.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] dt-bindings: sound: add address-cells and size
On Wed, Mar 31, 2021 at 03:10:46PM +0800, Jack Yu wrote:
> Add address-cells and size-cells information to fix warnings
> for rt1019.yaml.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look a
Add address-cells and size-cells information to fix warnings
for rt1019.yaml.
Signed-off-by: Jack Yu
---
Documentation/devicetree/bindings/sound/rt1019.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt1019.yaml
b/Documentation/devicetree
As same as kretprobe_trampoline, move the optprobe template
code in the text for making ORC information on that.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/opt.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/kprobes
Add all the files maintained by Turris team, not only for MOX, but also
for Omnia. Change website.
Signed-off-by: Marek Behún
---
MAINTAINERS | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d23b0ec0c90..2cf388c89196 100644
--- a/MA
; support for stashing things on the signal stack?
>
> From what we can tell, the most flexible option though appears to be
> just some user settable opaque data in perf_event_attr, that is
> copied to siginfo. It'd allow user space to store a pointer or a
> hash/key, or
xible option though appears to be
just some user settable opaque data in perf_event_attr, that is copied
to siginfo. It'd allow user space to store a pointer or a hash/key, or
just encode the relevant information it wants; but could also go
further, and add information beyond perf_event_attr, such
* Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 3:05 PM Marco Elver wrote:
> >
> > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > >
> > > One last try, I'll leave it alone now, I promise :-)
> >
> > This looks like it does what you suggested, thanks! :-)
> >
> > I'll still need to t
On Wed, 24 Mar 2021 at 15:15, Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov wrote:
> > > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > > >
> > > > One last try, I'll leave it alone now, I promise :-)
> > >
> > > This looks like it does what you suggested, thanks!
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
On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov wrote:
> > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> > >
> > > One last try, I'll leave it alone now, I promise :-)
> >
> > This looks like it does what you suggested, thanks! :-)
> >
> > I'll still need to think about it, because of the p
On Wed, Mar 24, 2021 at 3:05 PM Marco Elver wrote:
>
> On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
> >
> > One last try, I'll leave it alone now, I promise :-)
>
> This looks like it does what you suggested, thanks! :-)
>
> I'll still need to think about it, because of the potential probl
On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote:
>
> One last try, I'll leave it alone now, I promise :-)
This looks like it does what you suggested, thanks! :-)
I'll still need to think about it, because of the potential problem
with modify-signal-races and what the user's synchronization st
One last try, I'll leave it alone now, I promise :-)
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -778,6 +778,9 @@ struct perf_event {
void *security;
#endif
struct list_headsb_list;
+
+ unsigned long si_uattr;
+
On Wed, 24 Mar 2021 at 14:21, Peter Zijlstra wrote:
>
> On Wed, Mar 24, 2021 at 02:01:56PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 01:53:48PM +0100, Peter Zijlstra wrote:
> > > On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> > > > E
On Wed, Mar 24, 2021 at 02:21:37PM +0100, Peter Zijlstra wrote:
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5652,13 +5652,17 @@ static long _perf_ioctl(struct perf_even
> return perf_event_query_prog_array(event, (void __user *)arg);
>
> case PERF_EVENT_IOC
On Wed, Mar 24, 2021 at 02:01:56PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 24, 2021 at 01:53:48PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> > > Encode information from breakpoint attributes into siginfo_t, which
> &
On Wed, Mar 24, 2021 at 01:53:48PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> > Encode information from breakpoint attributes into siginfo_t, which
> > helps disambiguate which breakpoint fired.
> >
> > Note, pr
On Wed, Mar 24, 2021 at 12:24:59PM +0100, Marco Elver wrote:
> Encode information from breakpoint attributes into siginfo_t, which
> helps disambiguate which breakpoint fired.
>
> Note, providing the event fd may be unreliable, since the event may have
> bee
Encode information from breakpoint attributes into siginfo_t, which
helps disambiguate which breakpoint fired.
Note, providing the event fd may be unreliable, since the event may have
been modified (via PERF_EVENT_IOC_MODIFY_ATTRIBUTES) between the event
triggering and the signal being delivered
Reviewed-by: Dan Carpenter
regards,
dan carpenter
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
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 bytes of data using memcpy():
(In rtllib_rx.c:1972)
memcpy(network->CcxRmState
Performance Monitoring Unit (PMU) registers in powerpc exports
number of cycles elapsed between different stages in the pipeline.
Example, sampling registers in ISA v3.1.
This patchset implements kernel and perf tools support to expose
these pipeline stage cycles using the sample type PERF_SAMPLE_
1 - 100 of 3425 matches
Mail list logo
