When handle a perf event, Arm SPE decoder needs to decide if this perf
event is earlier or later than the samples from Arm SPE trace data; to
do comparision, it needs to use the same unit for the time.
This patch converts the event kernel time to arch timer's counter value,
thus it can be used
In current code, it assigns the arch timer counter to the synthesized
samples Arm SPE trace, thus the samples don't contain the kernel time
but only contain the raw counter value.
To fix the issue, this patch converts the timer counter to kernel time
and assigns it to sample timestamp.
Signed
stats.last_rx;
timeout += IEEE80211_CONNECTION_IDLE_TIME;
- if (time_is_before_jiffies(timeout)) {
+ /* If timeout is after now, then update timer to fire at
+* the later date, but do not actually probe at this time.
+*/
+ if (time_is_after_ji
From: Mike Marciniszyn
commit 5de61a47eb9064cbbc5f3360d639e8e34a690a54 upstream.
A panic can result when AIP is enabled:
BUG: unable to handle kernel NULL pointer dereference at 000
PGD 0 P4D 0
Oops: 1 SMP PTI
CPU: 70 PID: 981 Comm: systemd-udevd Tainted: G OE
stats.last_rx;
timeout += IEEE80211_CONNECTION_IDLE_TIME;
- if (time_is_before_jiffies(timeout)) {
+ /* If timeout is after now, then update timer to fire at
+* the later date, but do not actually probe at this time.
+*/
+ if (time_is_after_ji
From: Mike Marciniszyn
commit 5de61a47eb9064cbbc5f3360d639e8e34a690a54 upstream.
A panic can result when AIP is enabled:
BUG: unable to handle kernel NULL pointer dereference at 000
PGD 0 P4D 0
Oops: 1 SMP PTI
CPU: 70 PID: 981 Comm: systemd-udevd Tainted: G OE
Committer: Paul E. McKenney
CommitterDate: Mon, 08 Mar 2021 14:21:40 -08:00
rcutorture: Make TREE03 use real-time tree.use_softirq setting
TREE03 tests RCU priority boosting, which is a real-time feature.
It would also be good if it tested something closer to what is
actually used by the real-time
In current code, it assigns the arch timer counter to the synthesized
samples Arm SPE trace, thus the samples don't contain the kernel time
but only contain the raw counter value.
To fix the issue, this patch converts the timer counter to kernel time
and assigns it to sample timestamp.
Signed
When handle a perf event, Arm SPE decoder needs to decide if this perf
event is earlier or later than the samples from Arm SPE trace data; to
do comparision, it needs to use the same unit for the time.
This patch converts the event kernel time to arch timer's counter value,
thus it can be used
Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.
Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub
Acked-by: Alan Stern
On Fri, Apr 09, 2021 at 10:39:07AM +0800, Chunfeng Yun wrote:
> Return the exactly delay time given by root hub descriptor,
> this helps to reduce resume time etc.
>
> Due to the root hub descriptor is usually provided by the host
> controller driver, if there is compatibility
The kernel currently only loads the kernel module signing key onto the
builtin trusted keyring. Load the module signing key onto the IMA keyring
as well.
Signed-off-by: Nayna Jain
Acked-by: Stefan Berger
---
certs/system_certificates.S | 13 -
certs/system_keyring.c| 50
The "mrproper" target is still looking for build time generated keys in
the kernel root directory instead of certs directory. Fix the path and
remove the names of the files which are no longer generated.
Fixes: cfc411e7fff3 ("Move certificate handling to its own directory")
The kernel build process currently only signs kernel modules when
MODULE_SIG is enabled. Also, sign the kernel modules at build time when
IMA_APPRAISE_MODSIG is enabled.
Signed-off-by: Nayna Jain
Acked-by: Stefan Berger
---
certs/Kconfig | 2 +-
certs/Makefile | 8
init/Kconfig | 6
Hi Mauro,
On 4/8/21 10:40 AM, Mauro Carvalho Chehab wrote:
> Smatch is warning that:
> drivers/media/platform/qcom/venus/hfi_venus.c:1100 venus_isr() warn:
> variable dereferenced before check 'hdev' (see line 1097)
>
> The logic basically does:
> hdev = to_hfi_priv(core);
>
> with
Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.
Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub
Signed-off-by: Chunfeng
On Sun, Apr 4, 2021 at 12:20 PM Christophe Leroy
wrote:
>
> One user has expressed the need to both append and prepend some
> built-in parameters to the command line provided by the bootloader.
>
> Allthough it is a corner case, it is easy to implement so let's do it.
>
> When the user chooses to
Smatch is warning that:
drivers/media/platform/qcom/venus/hfi_venus.c:1100 venus_isr() warn:
variable dereferenced before check 'hdev' (see line 1097)
The logic basically does:
hdev = to_hfi_priv(core);
with is translated to:
hdev = core->priv;
If the IRQ code can
Hello,
Michael Walle wrote on Thu, 08 Apr 2021 08:55:42
+0200:
> Hi Tudor,
>
> Am 2021-04-08 07:51, schrieb tudor.amba...@microchip.com:
> > Would you please resend this patch, together with the mtd-utils
> > and the SPI NOR patch in a single patch set? You'll help us all
> > having all in a
Hi Tudor,
Am 2021-04-08 07:51, schrieb tudor.amba...@microchip.com:
Would you please resend this patch, together with the mtd-utils
and the SPI NOR patch in a single patch set? You'll help us all
having all in a single place.
This has already been picked-up:
Michael,
Would you please resend this patch, together with the mtd-utils
and the SPI NOR patch in a single patch set? You'll help us all
having all in a single place.
For the new ioctl we'll need acks from all the mtd maintainers
and at least a tested-by tag.
Cheers,
ta
Currently, during kexec load we are copying relocation function and
flushing it. However, we can also flush kexec relocation buffers and
if new kernel image is already in place (i.e. crash kernel), we can
also flush the new kernel image itself.
Signed-off-by: Pavel Tatashin
---
he effective elapsed time with a 1us timer, we got ~59us.
> Even with larger timeout periods, the difference is still evident
> (e.g., with a 100us timer, we measured ~158us of elapsed time).
So the delta is a constant of ~50us, right?
> We believe that one of the reasons is the use of the
> Due to clock stretch, our HW IP cannot meet the ac-timing
> spec(tSU;STA,tSU;STO).
> There isn't a same delay for clock stretching, so we need pass a
> parameter which can be found through measurement to meet most
> conditions.
What about using this existing binding?
-
ces that are not
> ready yet and devices that are not connected (i.e. will never be ready),
> delay adding these devices. This should give them enough time to set up.
>
> The delay is set to 2.5 seconds, which should give us a good safety
> margin based on testing and still be fairly
On Tue, 2021-04-06 at 21:48 +0200, Wolfram Sang wrote:
> On Sat, Mar 13, 2021 at 04:04:24PM +0800, qii.w...@mediatek.com wrote:
> > From: Qii Wang
> >
> > tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> > clock-stretching or circuit loss, we could get de
Current sleep services (nanosleep) provide sleep periods very far from the
expectations when scheuling microsecond-scale timers. On our testbed, using
rdtscp() before and after a nanosleep() syscall to measure the effective
elapsed time with a 1us timer, we got ~59us.
Even with larger timeout
irqoff() that is needed
irrespective of vtime, then KVM will end up with different RCU logic depending
on whether or not vtime is enabled. RCU is just an example. My point is that
it doesn't seem impossible that there would be something in the future that
wants to tap into the guest->host transition.
Maybe that never happens and the vtime check is perfectly ok, but for me, the
name guest_exit_irqoff() doesn't sound like something that should hinge on
time accounting being enabled.
On Sat, Mar 13, 2021 at 04:04:24PM +0800, qii.w...@mediatek.com wrote:
> From: Qii Wang
>
> tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> clock-stretching or circuit loss, we could get device
> clock-stretch time from dts to adjust these parameters
> to meet the
lay adding these devices. This should give them enough time to set up.
The delay is set to 2.5 seconds, which should give us a good safety
margin based on testing and still be fairly responsive for users.
To achieve that delay switch to updating via a delayed work struct,
which means that we can also get r
On Wed, Mar 31, 2021 at 04:48:47PM +, Christophe Leroy wrote:
> This patch adds the necessary glue to provide time namespaces.
>
> Things are mainly copied from ARM64.
>
> __arch_get_timens_vdso_data() calculates timens vdso data position
> based on the vdso data
One user has expressed the need to both append and prepend some
built-in parameters to the command line provided by the bootloader.
Allthough it is a corner case, it is easy to implement so let's do it.
When the user chooses to prepend the bootloader provided command line
with the built-in
On 4/3/2021 04:48, Oleksij Rempel wrote:
This switch provides global ageing time configuration, so let DSA use
it.
Signed-off-by: Oleksij Rempel
Reviewed-by: Florian Fainelli
--
Florian
> > cycles: sample_period=11
> > >
> > > After:
> > > $ perf record -c 11 -F 99 true
> > > cannot set frequency and period at the same time
> > >
> > > So this change can break existing usages, but I think it's rare to
> >
On Sat, Apr 03, 2021 at 01:48:45PM +0200, Oleksij Rempel wrote:
> This switch provides global ageing time configuration, so let DSA use
> it.
>
> Signed-off-by: Oleksij Rempel
Reviewed-by: Andrew Lunn
Andrew
This switch provides global ageing time configuration, so let DSA use
it.
Signed-off-by: Oleksij Rempel
---
drivers/net/dsa/qca/ar9331.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index 4a98f14f31f4
In current code, it assigns the arch timer counter to the synthesized
samples Arm SPE trace, thus the samples don't contain the kernel time
but only contain the raw counter value.
To fix the issue, this patch converts the timer counter to kernel time
and assigns it to sample timestamp.
Signed
When handle a perf event, Arm SPE decoder needs to decide if this perf
event is earlier or later than the samples from Arm SPE trace data; to
do comparision, it needs to use the same unit for the time.
This patch converts the event kernel time to arch timer's counter value,
thus it can be used
er:
> $ perf record -c 11 -F 99 true
> cannot set frequency and period at the same time
>
> So this change can break existing usages, but I think it's rare to
> have both options and it'd be better changing them.
Humm, perhaps we can just make that an warning stating that -c i
On 3/30/21 9:16 AM, Nayna Jain wrote:
The kernel currently only loads the kernel module signing key onto the
builtin trusted keyring. Load the module signing key onto the IMA keyring
as well.
Signed-off-by: Nayna Jain
Acked-by: Stefan Berger
---
certs/system_certificates.S | 13
On 3/30/21 9:16 AM, Nayna Jain wrote:
The kernel build process currently only signs kernel modules when
MODULE_SIG is enabled. Also, sign the kernel modules at build time when
IMA_APPRAISE_MODSIG is enabled.
Signed-off-by: Nayna Jain
Acked-by: Stefan Berger
---
certs/Kconfig | 2
record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.031 MB perf.data (8 samples) ]
$ perf evlist -F
cycles: sample_period=11
After:
$ perf record -c 11 -F 99 true
cannot set frequency and period at the same time
So this change can break existing usages
On book3s/32, the segment below kernel text is used for module
allocation when CONFIG_STRICT_KERNEL_RWX is defined.
In order to benefit from the powerpc specific module_alloc()
function which allocate modules with 32 Mbytes from
end of kernel text, use that segment below PAGE_OFFSET at all time
This patch adds the necessary glue to provide time namespaces.
Things are mainly copied from ARM64.
__arch_get_timens_vdso_data() calculates timens vdso data position
based on the vdso data position, knowing it is the next page in vvar.
This avoids having to redo the mflr/bcl/mflr/mtlr dance
[Sorry, resending with complete destination list, I used the wrong script on
the first delivery]
This series adds support for time namespaces on powerpc.
All timens selftests are successfull.
Christophe Leroy (3):
lib/vdso: Mark do_hres_timens() and do_coarse_timens()
__always_inline
This patch adds the necessary glue to provide time namespaces.
Things are mainly copied from ARM64.
__arch_get_timens_vdso_data() calculates timens vdso data position
based on the vdso data position, knowing it is the next page in vvar.
This avoids having to redo the mflr/bcl/mflr/mtlr dance
This series adds support for time namespaces on powerpc.
All timens selftests are successfull.
Christophe Leroy (3):
lib/vdso: Mark do_hres_timens() and do_coarse_timens()
__always_inline()
lib/vdso: Add vdso_data pointer as input to
__arch_get_timens_vdso_data()
powerpc/vdso: Add
On Tue, Mar 30, 2021 at 09:16:34AM -0400, Nayna Jain wrote:
> The "mrproper" target is still looking for build time generated keys in
> the kernel root directory instead of certs directory. Fix the path and
> remove the names of the files which are no longer generated.
>
Rather than adding one page at a time to the page cache and taking the
page cache xarray lock each time, where possible add pages in bulk by
first populating an xarray node outside of the page cache before taking
the lock to insert it.
When a group of pages to be inserted will fill an xarray node
To prepare for multithreading the work to preserve a shmem file,
divide the work into subranges of the total index range of the file.
The chunk size is a rather arbitrary 256k indices.
Signed-off-by: Anthony Yznaga
---
mm/shmem_pkram.c | 64
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 30 Mar 2021 10:46:53 +0800 you wrote:
> Cross time-stamping mechanism used in certain instance of Intel mGbE
> may run at different clock frequency in comparison to the clock
> frequency used by process
From: Thomas Gleixner
System time snapshots are not conveying information about the current
clocksource which was used, but callers like the PTP KVM guest
implementation have the requirement to evaluate the clocksource type to
select the appropriate mechanism.
Introduce a clocksource id field
The kernel currently only loads the kernel module signing key onto the
builtin trusted keyring. Load the module signing key onto the IMA keyring
as well.
Signed-off-by: Nayna Jain
---
certs/system_certificates.S | 13 +-
certs/system_keyring.c| 47
The kernel build process currently only signs kernel modules when
MODULE_SIG is enabled. Also, sign the kernel modules at build time when
IMA_APPRAISE_MODSIG is enabled.
Signed-off-by: Nayna Jain
---
certs/Kconfig | 2 +-
certs/Makefile | 8
init/Kconfig | 6 +++---
3 files changed
The "mrproper" target is still looking for build time generated keys in
the kernel root directory instead of certs directory. Fix the path and
remove the names of the files which are no longer generated.
Fixes: cfc411e7fff3 ("Move certificate handling to its own directory")
On Mon, 29 Mar 2021 at 17:30, Jonathan Cameron wrote:
>
> On Wed, 24 Mar 2021 14:55:39 +0200
> Alexandru Ardelean wrote:
>
> > The 'toshiba_acpi_dev' object is allocated first and free'd last. We can
> > bind it's life-time to the parent ACPI device object. This is a firs
Cross time-stamping mechanism used in certain instance of Intel mGbE
may run at different clock frequency in comparison to the clock
frequency used by processor, so we introduce cross T/S frequency
adjustment to ensure TSC calculation is correct when processor got the
cross time-stamps.
Signed
On Tue, 30 Mar 2021 at 01:15, Sean Christopherson wrote:
>
> +Thomas
>
> On Mon, Mar 29, 2021, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> > reported that the guest time remains 0 when runnin
+Thomas
On Mon, Mar 29, 2021, Wanpeng Li wrote:
> From: Wanpeng Li
>
> The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> reported that the guest time remains 0 when running a while true
> loop in the guest.
>
> The commit 87fa7f3e98a131 ("x86/kvm: M
On Mon, 29 Mar 2021 15:06:20 +0200
Oleksij Rempel wrote:
> On Mon, Mar 29, 2021 at 11:25:32AM +0100, Jonathan Cameron wrote:
> > On Mon, 29 Mar 2021 09:31:29 +0200
> > Oleksij Rempel wrote:
> >
> > > Settling time and over sampling is a typical challeng
On Wed, 24 Mar 2021 14:55:39 +0200
Alexandru Ardelean wrote:
> The 'toshiba_acpi_dev' object is allocated first and free'd last. We can
> bind it's life-time to the parent ACPI device object. This is a first step
> in using more device-managed allocated functions for this.
>
>
On Mon, Mar 29, 2021 at 11:25:32AM +0100, Jonathan Cameron wrote:
> On Mon, 29 Mar 2021 09:31:29 +0200
> Oleksij Rempel wrote:
>
> > Settling time and over sampling is a typical challenge for different IIO ADC
> > devices. So, introduce channel specific settling-time-us
On Mon, 29 Mar 2021 09:31:29 +0200
Oleksij Rempel wrote:
> Settling time and over sampling is a typical challenge for different IIO ADC
> devices. So, introduce channel specific settling-time-us and
> oversampling-ratio
> properties to cover this use case.
>
> Signed-off-
From: Wanpeng Li
The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
reported that the guest time remains 0 when running a while true
loop in the guest.
The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where it
belongs") moves guest_exit_irqoff() close to vme
Settling time and over sampling is a typical challenge for different IIO ADC
devices. So, introduce channel specific settling-time-us and oversampling-ratio
properties to cover this use case.
Signed-off-by: Oleksij Rempel
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 8
1
Since for "cycles:u' on hybrid platform, it creates two "cycles".
So the second evsel in evlist also needs initialization.
With this patch,
# ./perf test 71
71: Convert perf time to TSC: Ok
Signed-off-by: Jin Yao
---
v3:
- No fu
Currently in schedstats we have sum_sleep_runtime and iowait_sum, but
there's no metric to show how long the task is in D state. Once a task in
D state, it means the task is blocked in the kernel, for example the
task may be waiting for a mutex. The D state is more frequent than
iowait, and it is
On Mon, Mar 22, 2021 at 04:06:06PM +0100, Oleksij Rempel wrote:
> Settling time and over sampling is a typical challenge for different IIO ADC
> devices. So, introduce channel specific settling-time-us and
> oversampling-ratio
> properties to cover this use case.
>
> Sign
bridges. So, let's fix this documentation to clarify when the right
time to use drm_dp_aux_init() or drm_dp_aux_register() is.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 44 +++--
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git
On Wed, 2021-03-24 at 11:12 -0600, Rob Herring wrote:
> On Sat, Mar 13, 2021 at 04:07:09PM +0800, qii.w...@mediatek.com wrote:
> > From: Qii Wang
> >
> > tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> > clock-stretching or circuit loss, we could get device
Amp requires 10 ~ 30ms for the power ON and OFF.
Added 30ms delay for stability.
Signed-off-by: Ryan Lee
---
sound/soc/codecs/max98373.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
index 746c829312b8..1346a98ce8a1 100644
---
On Sat, Mar 13, 2021 at 04:07:09PM +0800, qii.w...@mediatek.com wrote:
> From: Qii Wang
>
> tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> clock-stretching or circuit loss, we could get device
> clock-stretch time from dts to adjust these parameters
> to meet the
The 'toshiba_acpi_dev' object is allocated first and free'd last. We can
bind it's life-time to the parent ACPI device object. This is a first step
in using more device-managed allocated functions for this.
The main intent is to try to convert the IIO framework to export only
device-managed
On Mar 20, 2021, at 14:31, Thomas Gleixner wrote:
> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>>
>> +static void check_xtile_data_against_struct(int size)
>> +{
>> +u32 max_palid, palid, state_size;
>> +u32 eax, ebx, ecx, edx;
>> +u16 max_tile;
>> +
>> +/*
>> + *
On 23/03/2021 01:51, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port creation
enough strategy thus far, because the 'bridge join'
moment always coincided with the 'bridge port creation' moment.
But with sandwiched interfaces, such as:
br0
|
bond0
|
swp0
it may happen that the user has had time to change the bridge port flags
of bond0 before enslaving swp0
From: Vladimir Oltean
The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
sysfs/ioctl/netlink
-> br_set_ageing_time
-> __set_ageing_time
therefore not at bridge port creation time, so:
(a) switchdev drivers have to hardcode the initial value for the address
On 3/20/2021 3:34 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port cre
Settling time and over sampling is a typical challenge for different IIO ADC
devices. So, introduce channel specific settling-time-us and oversampling-ratio
properties to cover this use case.
Signed-off-by: Oleksij Rempel
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 9 +
1
From: Gerald Schaefer
commit d54cb7d54877d529bc1e0e1f47a3dd082f73add3 upstream.
Commit 152e9b8676c6e ("s390/vtime: steal time exponential moving average")
inadvertently changed the input value for account_steal_time() from
"cputime_to_nsecs(steal)" to just "steal",
From: Gerald Schaefer
commit d54cb7d54877d529bc1e0e1f47a3dd082f73add3 upstream.
Commit 152e9b8676c6e ("s390/vtime: steal time exponential moving average")
inadvertently changed the input value for account_steal_time() from
"cputime_to_nsecs(steal)" to just "steal",
From: Gerald Schaefer
commit d54cb7d54877d529bc1e0e1f47a3dd082f73add3 upstream.
Commit 152e9b8676c6e ("s390/vtime: steal time exponential moving average")
inadvertently changed the input value for account_steal_time() from
"cputime_to_nsecs(steal)" to just "steal",
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port
Hi Vladimir,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
base:
Hi Vladimir,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
base:
From: Vladimir Oltean
The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
sysfs/ioctl/netlink
-> br_set_ageing_time
-> __set_ageing_time
therefore not at bridge port creation time, so:
(a) drivers had to hardcode the initial value for the address agein
enough strategy thus far, because the 'bridge join'
moment always coincided with the 'bridge port creation' moment.
But with sandwiched interfaces, such as:
br0
|
bond0
|
swp0
it may happen that the user has had time to change the bridge port flags
of bond0 before enslaving swp0
On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>
> +static void check_xtile_data_against_struct(int size)
> +{
> + u32 max_palid, palid, state_size;
> + u32 eax, ebx, ecx, edx;
> + u16 max_tile;
> +
> + /*
> + * Check the maximum palette id:
> + * eax: the highest
t; > + return 0;
> > +
> > + br = netdev_priv(br_dev);
> > +
> > + return jiffies_to_clock_t(br->ageing_time);
>
> Don't you want an ASSERT_RTNL() in this function as well?
Hmm, I'm not sure. I don't think I'm accessing anything that is under
the p
'bridge join'
> > moment always coincided with the 'bridge port creation' moment.
> >
> > But with sandwiched interfaces, such as:
> >
> > br0
> > |
> > bond0
> > |
> > swp0
> >
> > it may happen that the user has had time to change the bri
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port cre
br0
> |
> bond0
> |
> swp0
>
> it may happen that the user has had time to change the bridge port flags
> of bond0 before enslaving swp0 to it. In that case, swp0 will falsely
> assume that the bridge port flags are those determined by new_nbp, when
> in fact this can happen
From: "Steven Rostedt (VMware)"
Currently, ring_buffer_event_time_stamp() only returns an accurate time
stamp of the event if it has an absolute extended time stamp attached to
it. To make it more robust, use the event_stamp() in case the event does
not have an absolute valu
gt; getting out of scope here.
>
> > I assume we don't want anything like this in an upstream driver, but
> > I'm really running out of any plausible explanation :(
>
> As discussed, let's try the reset workaround, to see if it helps.
>
> I wonder if opening the camer
Settling time and over sampling is a typical challenge for different IIO ADC
devices. So, introduce channel specific settling-time-us and oversampling-ratio
properties to cover this use case.
Signed-off-by: Oleksij Rempel
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 9 +
1
Hi Jacopo,
On Wed, Mar 17, 2021 at 11:04:45AM +0100, Jacopo Mondi wrote:
> On Mon, Mar 15, 2021 at 05:22:37PM +, Kieran Bingham wrote:
> > On 15/03/2021 13:15, Jacopo Mondi wrote:
> > > It has been observed through repeated testing (250 boots) that in the
> > > 10% of the cases the RDACM21
From: Vladimir Oltean
The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
sysfs/ioctl/netlink
-> br_set_ageing_time
-> __set_ageing_time
therefore not at bridge port creation time, so:
(a) drivers had to hardcode the initial value for the address agein
enough strategy thus far, because the 'bridge join'
moment always coincided with the 'bridge port creation' moment.
But with sandwiched interfaces, such as:
br0
|
bond0
|
swp0
it may happen that the user has had time to change the bridge port flags
of bond0 before enslaving swp0
> tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> clock-stretching or circuit loss, we could get device
> clock-stretch time from dts to adjust these parameters
> to meet the spec via EXT_CONF register.
>
> Signed-off-by: Qii Wang
I will look at this next and t
Committer: Thomas Gleixner
CommitterDate: Thu, 18 Mar 2021 11:20:26 +01:00
time/debug: Remove dentry pointer for debugfs
There is no need to keep the dentry pointer around for the created
debugfs file, as it is only needed when removing it from the system.
When it is to be removed, ask debugfs
101 - 200 of 28825 matches
Mail list logo
