From: "Steven Rostedt (VMware)"
The first thing that the ftrace function callback helper functions should do
is to check for recursion. Peter Zijlstra found that when
"rcu_is_watching()" had its notrace removed, it caused perf function tracing
to crash. This is because the call of rcu_is_watching
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
ftrace/urgent
Head SHA1: b40341fad6cc2daa195f8090fd3348f18fff640a
Steven Rostedt (VMware) (2):
tracing: Fix trace_find_next_entry() accounting of temp buffer size
ftrace: Move RCU is watching check after recursio
On 9/26/20 8:03 PM, Halil Pasic wrote:
On Fri, 21 Aug 2020 15:56:10 -0400
Tony Krowiak wrote:
The current support for pass-through crypto adapters does not allow
configuration of a matrix mdev when it is in use by a KVM guest. Let's
allow AP resources - i.e., adapters, domains and control d
On Wed, Sep 30, 2020 at 2:10 PM Greg Kroah-Hartman
wrote:
>
> There are a number of subdirectories and files in drivers/char/ that
> have their own maintainers and developers and ways of getting patches to
> Linus. This includes random.c, IPMI, hardware random drivers, TPM
> drivers, and agp driv
Hi,
On 9/29/20 10:48 AM, Takashi Iwai wrote:
Hi Hans,
it seems that the recent update of intel-vtn broke the keyboard input
on some laptops with libinput:
https://bugzilla.opensuse.org/show_bug.cgi?id=1175599
Blacklisting intel-vtn fixes the issue, so it's likely the falsely
reported tablet
Hi,
On 9/29/20 10:48 AM, Takashi Iwai wrote:
Hi Hans,
it seems that the recent update of intel-vtn broke the keyboard input
on some laptops with libinput:
https://bugzilla.opensuse.org/show_bug.cgi?id=1175599
Blacklisting intel-vtn fixes the issue, so it's likely the falsely
reported tablet
Hi,
On 29/09/20 10:41 pm, Rob Herring wrote:
> On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel
> wrote:
>>
>> On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou wrote:
>>
>>> Hi Lorenzo,
>>>
>>> Thanks a lot for your comments!
>>>
-Original Message-
From: Lorenzo Pieralisi
Sent:
On Wed, Sep 30, 2020 at 12:15:32PM +0200, Thomas Bogendoerfer wrote:
> On Wed, Sep 30, 2020 at 12:12:32AM +0300, Serge Semin wrote:
> > Thomas,
> > Any comment on the series? The changes aren't that comprehensive, so it
> > would
> > be great to merge it in before the 5.10 merge window is opened.
There's currently a bug with the way kernel-doc script
counts line numbers that can be seen with:
$ ./scripts/kernel-doc -rst -enable-lineno include/linux/math64.h >all
&& ./scripts/kernel-doc -rst -internal -enable-lineno include/linux/math64.h
>int && diff -U0 int all
--- int
include/linux/ethtool.h is included twice with kernel-doc,
both to document ethtool_pause_stats(). The first one is
at statistics.rst, and the second one at ethtool-netlink.rst.
Replace one of the references to use the name of the
function. The automarkup.py extension should create the
cross-refer
This series add proper support for Sphinx 3.1 and above for building the html
docs.
This series comes after the one I wrote fixing the warnings.
With this series applied on the top of next-20200922, there are just 12
warnings:
- 2 of them happens also on Sphinx 2.4.4
(both seem
The sound API is documented on two different parts:
under Documentation/driver-api/sound.rst and under
Documentation/sound/kernel-api/alsa-driver-api.rst.
The alsa-driver-api.rst seems more complete, and APIs
are split per type. There's just one missing kernel-doc
markup there.
Add it and drop th
There are three files with replace macros for structs,
mapping them into Sphinx 2.x C domain references.
Well, this is broken on Sphinx 3.x. Also, for Sphinx 2.x,
the automarkup macro should be able to take care of them.
So, let's just drop those.
Signed-off-by: Mauro Carvalho Chehab
---
Docum
There are some warnings produced with Sphinx 3.x:
Documentation/networking/ieee802154.rst:29: WARNING: Error in
declarator or parameters
Invalid C declaration: Expecting "(" in parameters. [error at 7]
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
---^
The new C domain code on Sphinx 3 doesn't allow anymore
to use c:type:: for structs.
Now that cdomain.py has backward support, let's use
c:struct:: instead.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/media/cec-core.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since Sphinx 3.0, the C domain code was rewritten, but only
after version 3.1 it got support for setting namespaces on
C domains, with is something that it is required, in order to
document system calls, like ioctl() and others.
As part of changing the documentation subsystem to properly
build wit
the :c:type shouldn't be used with structs with Sphinx 3,
as the C domain there uses .. c:struct for structs.
As we have the automarkup extension, let's just get rid of
all :c:type as a hole, as those will be automagically
marked as such.
This solves a bunch of warnings with Sphinx 3, like those:
There are a few namespace clashes by using c:macro everywhere:
basically, when using it, we can't have something like:
.. c:struct:: pwm_capture
.. c:macro:: pwm_capture
So, we need to use, instead:
.. c:function:: int pwm_capture (struct pwm_device * pwm, struct
pwm_c
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab
---
.../dvb/audio-bilingual-channel-select.rst | 7 +++
.../media/dv
The C domain parser of Sphinx3 expects just function names
for :c:func: markups:
./Documentation/driver-api/pm/devices.rst:413: WARNING: Unparseable C
cross-reference: 'device_may_wakeup(dev)'
Invalid C declaration: Expected end of definition. [error at 17]
device_may_wa
This is already included at scsi.rst. So, remove the duplication,
in order to avoid Sphinx warnings.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/target.rst | 12
1 file changed, 12 deletions(-)
diff --git a/Documentation/driver-api/target.rst
b/Documentation/
As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147:
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169:
WARNI
After the build fix patches, it is believed that the output
with Sphinx 3.x won't be a problem. Still, the C domain
support was re-written, and this can have caused hidden
issues.
So, let's keep the warning, changing it to a lighter
warning text.
Signed-off-by: Mauro Carvalho Chehab
---
Documen
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/mediactl/media-func-close.rst| 10 +++---
.../me
Sphinx C parser for the C domain is now more pedantic when
trying to identify the function types. That prevents scope
macros to be used as type defines.
Yet, since 3.0.2, it is possible to provide it a list of
such macros. Add them, in order to solve several Sphinx 3.x
warnings.
Signed-off-by: Ma
The class types changed after the C domain rewrite on
Sphinx 3.x. Due to that, the automarkup extension is just
generating additional noise when trying to convert structs
and other markups into cross references.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/conf.py | 3 ++-
1 file chang
The :c:type:`foo` only works properly with structs before
Sphinx 3.x.
On Sphinx 3.x, structs should now be declared using the
.. c:struct, and referenced via :c:struct tag.
As we now have the automarkup.py macro, that automatically
convert:
struct foo
into cross-references, let's get rid
There's a missing "`", causing this warning:
./Documentation/translations/it_IT/kernel-hacking/hacking.rst:404:
WARNING: Unparseable C cross-reference: 'cpu_to_be32p(), che prende un
puntatore\nad un tipo, e ritorna il valore convertito. L\'altra variante
per\nla famiglia di conversioni
As warned by Sphinx:
./Documentation/core-api/workqueue:400: ./kernel/workqueue.c:1218:
WARNING: Unexpected indentation.
the return code table is currently not recognized, as it lacks
markups.
Signed-off-by: Mauro Carvalho Chehab
---
kernel/workqueue.c | 3 +++
1 file changed, 3 inser
Some such markups are invalid, as reported by Sphinx:
./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3317:
WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*'
Invalid C declaration: Expected end of definition. [error at 20]
snd_rawmidi_transmit*
On Wed, Sep 30, 2020 at 3:14 PM Gioh Kim wrote:
>
> From: Gioh Kim
>
> list field is not used anywhere
>
> Signed-off-by: Gioh Kim
thanks, Gioh!
Acked-by: Jack Wang
> ---
> drivers/infiniband/ulp/rtrs/rtrs-pri.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/rtr
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab
---
.../userspace-api/media/rc/lirc-get-features.rst | 9 -
.../use
The :c:type macros are not used properly there, as reported
by Sphinx 3:
./Documentation/block/blk-mq.rst:112: WARNING: Unparseable C
cross-reference: 'hctx->dispatch'
Invalid C declaration: Expected end of definition. [error at 4]
hctx->dispatch
^
Also, t
Sphinx 3.x doesn't allow expressions using :c:func markup:
./Documentation/driver-api/mei/mei.rst:41: WARNING: Unparseable C
cross-reference: 'close(int fd)'
Invalid C declaration: Expected end of definition. [error at 5]
close(int fd)
-^
So, convert it in
There's no need to use macros to use :c:type on this file,
as automarkup.py should do this automatically.
Also, this breaks compatibility with Sphinx 3.x, as there,
structs should be declared using .. c:struct.
So, get rid of them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-
There is currently a problem with kernel-doc tags from blk.c:
.../Documentation/admin-guide/pstore-blk:239: ./fs/pstore/blk.c:175:
WARNING: Duplicate C declaration, also defined in 'admin-guide/pstore-blk'.
Declaration is 'register_pstore_device'.
.../Documentation/admin-g
Those macros are not doing the right thing with Sphinx 3,
causing parse errors:
./Documentation/driver-api/fpga/fpga-mgr.rst:104: WARNING: Unparseable
C cross-reference: 'fpga_manager->state'
Invalid C declaration: Expected end of definition. [error at 12]
fpga_manager->
The :c:type: tag has problems with Sphinx 3.x, as structs
there should be declared with c:struct.
So, remove them, relying at automarkup.py extension to
convert them into cross-references.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/filesystems/fscrypt.rst | 51 --
pci_device_id is already documented at pci.rst:
./Documentation/driver-api/basics.rst: WARNING: Duplicate C
declaration, also defined in 'PCI/pci'.
Declaration is 'pci_device_id'.
The kstrtol and kstrtoul are already at kernel-api:
./Documentation/driver-api/basics.rst:
As there's already a rst file with workqueue markups, containing
part of them, move the other definitions, in order to avoid
warnings with Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/core-api/workqueue.rst | 2 ++
Documentation/driver-api/basics.rst | 9 -
2 files cha
The usage of :c:type: to reference to a struct member is wrong,
as pointed by Sphinx 3:
./Documentation/driver-api/libata.rst:511: WARNING: Unparseable C
cross-reference: 'qc->complete_fn'
Invalid C declaration: Expected end of definition. [error at 2]
qc->complete_fn
The infrastructure.rst file already includes the external
symbols from drivers/base/core.c.
Duplicating 3 functions there causes namespace collisions:
Documentation/driver-api/device_link.rst: WARNING: Duplicate C
declaration, also defined in 'driver-api/infrastructure'.
Declarat
Which Sphinx 3, :c:type: can't be used anymore for structs,
as this should be used only for typedefs.
Rely on automarkup.py for struct references.
This file has an special case, though: it uses the tag also
to point to an array. Let's use, instead, :c:expr: for such
purpose, as it should do the
Those are already documented at:
Documentation/driver-api/firmware/request_firmware.rst
Including it twice is causing lots of warnings:
./Documentation/driver-api/infrastructure.rst: WARNING: Duplicate C
declaration, also defined in 'driver-api/firmware/request_firmware'.
This is already included at genericirq.rst. Adding it twice
causes C namespace duplication:
.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c:100:
WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'synchronize_hardirq'.
.../Docu
There are some c-domain tags that are wrong. While this won't
cause problems with Sphinx < 3.0, this cause troubles with
newer versions, as the C parser won't recognize the contents
of the tag, and will drop it from the output.
Let's just place them at literal blocks.
Signed-off-by: Mauro Carvalh
As warned by Sphinx:
./Documentation/gpu/drm-kms-helpers:305: ./include/drm/drm_dsc.h:587:
WARNING: Unparseable C cross-reference: 'struct'
Invalid C declaration: Expected identifier in nested name, got keyword:
struct [error at 6]
struct
--^
The markup f
Those are already defined at kernel-api.rst, as part of the
synchronization primitives chapter.
This solves several Sphinx 3 warnings, like:
.../Documentation/driver-api/basics.rst: WARNING: Duplicate C
declaration, also defined in 'core-api/kernel-api'.
Declaration is 'rcu_idle_
The C domain functions there collide with the English ones,
due to namespace collision, generating lots of warnings with
Sphinx 3.x:
./include/linux/mutex.h:121: WARNING: Duplicate C declaration, also
defined in 'translations/it_IT/kernel-hacking/locking'.
Declaration is 'mutex_in
There are several functions at math64.h that are also
defined at div64.c. As both are included at kernel-api.rst,
Sphinx 3.x complains about symbol duplication:
./lib/math/div64.c:73: WARNING: Duplicate C declaration, also defined
in 'core-api/kernel-api'.
Declaration is 'div_s64_
While most of the C domain parsing is done via kernel-doc,
some RST files use C domain tags directly.
While several of them can be removed for Sphinx < 3.0, due
to automarkup.py, and several others that could be
converted into kernel-doc markups, changes like that are
time-consuming, and may not f
Hi,
On 9/29/20 10:47 PM, Limonciello, Mario wrote:
I requested on the Ubuntu bug for someone to provide these.
Joe Barnett was kind enough to share two ACPI dumps to compare.
Not affected:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394/+attachment/5415318/+files/1.2.0.acpidump
Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/cec/cec-func-close.rst | 10 +++---
.../media/c
Unfortunately, Sphinx 3.x parser for c functions is too pedantic:
https://github.com/sphinx-doc/sphinx/issues/8241
While it could be relaxed with some configurations, there are
several corner cases that it would make it hard to maintain,
and will require teaching conf.py about several mac
chanseset b3a7bb1851c8 ("docs: get rid of :c:type explicit declarations for
structs")
removed several :c:type: markups, except by one.
Now, Sphinx 3.x complains about it:
.../Documentation/core-api/boot-time-mm:26: ../mm/memblock.c:51:
WARNING: Unparseable C cross-reference: 'struct\nme
With Sphinx 3.x, the ".. c:type:" tag was changed to accept either:
.. c:type:: typedef-like declaration
.. c:type:: name
Using it for other types (including functions) don't work anymore.
So, there are newer tags for macro, enum, struct, union, and others,
which doesn't exist on
Some typedef expressions are output as normal functions.
As we need to be clearer about the type with Sphinx 3.x,
detect such cases.
While here, fix a wrongly-indented block.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 62 ++
1 file
Currently, kernel/irq/chip.c is included twice, one for
export functions, and then for internal ones. However, as
the :export: and :internal: tags are missing, they ended
being included twice.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/core-api/genericirq.rst | 2 ++
1 file changed,
Currently, there's no way to exclude identifiers from
a kernel-doc markup. Add support for it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kernel-doc.rst | 8
Documentation/sphinx/kerneldoc.py | 7 +++
2 files changed, 15 insertions(+)
diff --git a/Documen
Right now, the build system doesn't use -nofunction, as
it is pretty much useless, because it doesn't consider
the other output modes (extern, internal), working only
with all.
Also, it is limited to exclude functions.
Re-implement it in order to allow excluding any symbols from
the document outp
Finding where an error like this was generated:
../lib/math/div64.c:73: WARNING: Duplicate C declaration, also defined
in 'kernel-api'.
Can take some time, as there's no glue about what kernel-doc
tag generated it. It is a way better to display it as:
.../Documentation/core-api/k
While kernel-doc needs to parse parameters in order to
identify its name, it shouldn't be touching the type,
as parsing it is very difficult, and errors happen.
One current error is when parsing this parameter:
const u32 (*tab)[256]
Found at ./lib/crc32.c, on this function:
u32
Hi Hou,
On 29/09/20 6:43 pm, Zhiqiang Hou wrote:
> From: Hou Zhiqiang
>
> In the current error response behavior, it will send a SLVERR response
> to device's internal AXI slave system interface when the PCIe controller
> experiences an erroneous completion (UR, CA and CT) from an external
> com
On Fri, Sep 18, 2020 at 10:18 AM Jinpu Wang wrote:
>
> On Fri, Sep 18, 2020 at 9:24 AM Gioh Kim wrote:
> >
> > From: Gioh Kim
> >
> > After send_msg_open is done, send_msg_close should be done
> > if any error occurs and it is necessary to recover
> > what has been done.
> >
> > Signed-off-by: G
On Wed 2020-09-30 11:07:33, John Ogness wrote:
> If a reader provides a buffer that is smaller than the message text,
> the @text_len field of @info will have a value larger than the buffer
> size. If readers blindly read @text_len bytes of data without
> checking the size, they will read beyond th
On Wed 2020-09-30 11:07:32, John Ogness wrote:
> Hello,
>
> Marek Szyprowski reported [0] a problem with a particular printk
> usage. This particular usage performs thousands of LOG_CONT calls.
> The printk.c implementation was only limiting the growing record by
> the maximum size available in th
On Fri, Sep 25, 2020 at 06:25:58PM -0400, Peter Xu wrote:
> This prepares for the future work to trigger early cow on pinned pages during
> fork(). No functional change intended.
>
> Signed-off-by: Peter Xu
> ---
> include/linux/mm.h | 2 +-
> kernel/fork.c | 2 +-
> mm/memory.c|
Hi Christoph,
Le mer. 30 sept. 2020 à 11:02, Christoph Hellwig a écrit
:
On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote:
It's allocated with dma_alloc_wc, but then it's only accessed as
non-coherent.
Anyway, for the time being I guess you could revert 37054fc81443.
But I
On Wed, 30 Sep 2020 10:06:24 +0200
Rasmus Villemoes wrote:
> True. But remember that printk is called from _everywhere_, with all
> sorts of locks held and/or preemption disabled or whatnot, and every
> cycle spent in printk makes those windows wider. Doubling the cost of
> every single printk by
On Wed, Sep 30, 2020 at 02:10:07PM +0200, Greg Kroah-Hartman wrote:
> There are a number of subdirectories and files in drivers/char/ that
> have their own maintainers and developers and ways of getting patches to
> Linus. This includes random.c, IPMI, hardware random drivers, TPM
> drivers, and a
On 20-09-11 17:36:06, Dong Aisheng wrote:
> On Tue, Sep 8, 2020 at 6:27 PM Abel Vesa wrote:
> >
> > The i.MX8MP platform introduces a new type of IP which is called BLK_CTL in
> > RM and usually is comprised of some GPRs that are considered too
> > generic to be part of any dedicated IP from that
On Wed, Sep 30, 2020 at 02:44:13PM +0200, Michal Hocko wrote:
> On Wed 30-09-20 14:35:35, Uladzislau Rezki wrote:
> > On Wed, Sep 30, 2020 at 11:27:32AM +0200, Michal Hocko wrote:
> > > On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote:
> > > > > > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issu
On 9/29/2020 9:47 PM, Bjorn Helgaas wrote:
From: Bjorn Helgaas
Remove an unused #define.
Fix the D2 transition delay. I changed this a year ago to conform to the
PCIe r5.0 spec, but I think the number I relied on is a typo in the spec.
I asked the PCI-SIG to fix the typo. Hopefully I'll get
On 9/30/20 2:24 PM, Mauro Carvalho Chehab wrote:
> There are several functions at math64.h that are also
> defined at div64.c. As both are included at kernel-api.rst,
> Sphinx 3.x complains about symbol duplication:
>
> ./lib/math/div64.c:73: WARNING: Duplicate C declaration, also defined
This is a small tidy-up. The of_device_get_match_data() helper retrieves
the driver data from the OF table, without needed to explicitly know the
table variable (since it can retrieve it from the driver object).
Reviewed-by: Alexandre Belloni
Signed-off-by: Alexandru Ardelean
---
drivers/iio/ad
This whole thing started because the lkp bot haunted me for a while with
this build warning:
>> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
>> 'at91_adc_dt_ids' [-Wunused-const-variable]
static const struct of_device_id at91_adc_dt_ids[] = {
The main intent is to get rid of the cast for the void-pointer returned by
of_device_get_match_data().
This requires const-ifying the 'caps' and 'registers' references on the
at91_adc_state struct.
The caps can be obtained also from the old platform_data (in the
at91_adc_probe_pdata() function),
The AT91 ADC driver no longer uses the 'at91_add_device_adc' platform data
type. This is no longer used (at least in mainline boards).
This change removes the platform-data initialization from the driver, since
it is mostly dead code now.
Some definitions [from the platform data at91_adc.h includ
The fix of flagging state->modeset whenever distrust_bios_wm is set
causes a regression when initializing display(s) attached to a Lenovo
USB-C docking station. The display remains blank until the dock is
reattached. Revert to bring the behavior of the functional v5.6 stable.
This reverts commit 0
This tries to solve a warning reported by the lkp bot:
>> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
>> 'at91_adc_dt_ids' [-Wunused-const-variable]
static const struct of_device_id at91_adc_dt_ids[] = {
^
1 warning generated.
This warnin
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 02de58b24d2e1b2cf947d57205bd2221d897193c
commit: 3bbd8ef9f780749426d4e52be0dfa3f70656d92b scsi: bfa: Staticify all local
functions
date: 10 weeks ago
config: ia64-randconfig-s031-20200930 (attached as
This patch provides a driver and an API for exporting
information about the platform integrity
firmware configuration in the sysfs filesystem.
The goal is that the attributes are avilable to fwupd.
Signed-off-by: Daniel Gutson
Tested-by: Richard Hughes
---
.../ABI/stable/sysfs-class-platform-i
This patch exports the BIOS Write Enable (bioswe), BIOS
Lock Enable (biosle), and the SMM BIOS Write Protect (SMM_BIOSWP) fields of
the BIOS Control register using the platform-integrity misc kernel module.
The idea is to keep adding more flags, not only from the BC but also from
other registers in
This patch serie adds a misc kernel module and extends the intel-spi drivers
to publish platform integrity data in the sys-fs.
Please check the comments in the following patches of this serie for further
details.
Daniel Gutson (2):
Platform integrity information in sysfs (version 9)
This patch
On 9/30/20 12:15 AM, Stephane Eranian wrote:
>> + /*
>> +* Software page-table walkers must disable IRQs,
>> +* which prevents any tear down of the page tables.
>> +*/
>> + local_irq_save(flags);
>> +
>> + size = __perf_get_page_size(current->active_mm, add
On 9/30/20 5:16 AM, Juergen Gross wrote:
> Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data
> to store a per interrupt XEN data pointer which contains XEN specific
> information.")
> Xen is using the chip_data pointer for storing IRQ specific data. When
> running as a
On 28/09/2020 11:34, Peter Ujfalusi wrote:
The sysfw ring configuration message has been extended to include virtid
and asel value for the ring.
Add the ASEL_VALID to TI_SCI_MSG_VALUE_RM_ALL_NO_ORDER as it is required
for DMA rings.
Instead of extending the current .config() ops - which would
On 28/09/2020 11:34, Peter Ujfalusi wrote:
Switch to the new set_cfg to configure the ring.
Signed-off-by: Peter Ujfalusi
---
drivers/soc/ti/k3-ringacc.c | 79 +++--
1 file changed, 32 insertions(+), 47 deletions(-)
Reviewed-by: Grygorii Strashko
--
Bes
On 28/09/2020 11:34, Peter Ujfalusi wrote:
The ringacc driver has been converted to use the new set_cfg function to
configure the ring, the old config ops can be removed.
Signed-off-by: Peter Ujfalusi
---
drivers/firmware/ti_sci.c | 72 --
include/linu
On Tue, Sep 29, 2020 at 11:20 AM Aaron Ma wrote:
>
> Evaluating acpi _BCL could be failed, then acpi buffer size will be set
'could be failed' -> 'could fail'
> to 0. When reuse this acpi buffer, AE_BUFFER_OVERFLOW will be triggered.
>
> Re-initialize buffer size will make acpi evaluate successf
On 28/09/2020 11:34, Peter Ujfalusi wrote:
It's JTAG PARTNO is 0xBB38.
Signed-off-by: Peter Ujfalusi
---
drivers/soc/ti/k3-socinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
index bbbc2d2b7091..a14ec68846dd 100644
--- a/
On Wed 2020-09-23 17:08:32, Prasad Sodagudi wrote:
> From: Mohammed Khajapasha
>
> The thread which initiates the hot plug can get scheduled
> out, while trying to acquire the console lock,
> thus increasing the hot plug latency. This option
> allows to selectively disable the console flush and
>
On Wed, Sep 30, 2020 at 01:56:01PM +0200, ansuels...@gmail.com wrote:
> > Subject: Re: [PATCH v2 1/2] devfreq: qcom: Add L2 Krait Cache devfreq
> > scaling driver
> >
> > On Tue, Sep 29, 2020 at 06:29:24PM +0200, Ansuel Smith wrote:
> > > Qcom L2 Krait CPUs use the generic cpufreq-dt driver and doe
On Tue, 29 Sep 2020 at 01:20, Kees Cook wrote:
> Note that I still can't explain what you're seeing. /proc/kallsyms
> shouldn't be affected by these patches -- I would expect it to either
> report the true value or 00s.
>
> > I will disable kptr_restrict and check or, I will enable
> > CONFIG_DEB
On 28/09/2020 11:34, Peter Ujfalusi wrote:
In RING mode the ringacc does not access the ring memory. In this access
mode the ringacc coherency does not have meaning.
If the ring is configured in RING mode, then the ringacc itself will not
access to the ring memory. Only the requester (user) o
On Wed, 2020-09-30 at 13:57 +0200, Greg Kroah-Hartman wrote:
> Kees, and Rafael, I don't know if you saw this proposal from Joe for
> sysfs files, questions below:
https://lore.kernel.org/linux-pm/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git@perches.com/T/
> So I guess I'm asking f
ig
powerpc allnoconfig
i386 randconfig-a003-20200930
i386 randconfig-a002-20200930
i386 randconfig-a006-20200930
i386 randconfig-a005-20200930
i386 randconfig-a004-20200930
i386
Hi, Michael,
PLease accept my apologies for the long delay.
I do agree with Vignesh's comments. Few others below.
On 3/27/20 5:59 PM, Michael Walle wrote:
[cut]
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index cc68ea84318e..fd1c36d70a13 100644
> --- a/drivers/mtd/
Currently, the RX interrupt logic uses the RXEMPTY interrupt, with the
RXEMPTYINV bit set, which means we get an RX interrupt as soon as the
RX FIFO is non-empty.
However, with the MAX310X having a FIFO of 128 bytes, this makes very
poor use of the FIFO: we trigger an interrupt as soon as the RX F
On 9/30/20 6:37 PM, Ivan Mikhaylov wrote:
> On Wed, 2020-09-30 at 15:06 +0530, Vignesh Raghavendra wrote:
>>
>> On 9/21/20 4:54 PM, Ivan Mikhaylov wrote:
>>> Some chips like macronix don't have TB(Top/Bottom protection)
>>> bit in the status register. Do not write tb_mask inside status
>>> regis
301 - 400 of 1591 matches
Mail list logo
