The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 3228e1dc80983ee1f5d2e533d010b3bd8b50f0e2
Gitweb:
https://git.kernel.org/tip/3228e1dc80983ee1f5d2e533d010b3bd8b50f0e2
Author:Anand K Mistry
AuthorDate:Thu, 04 Feb 2021 18:32:32 +11:00
. With
this patch, olddefconfig keeps the old setting, but re-writes it to
"is not set". This is even more surprising because the user is
explicit in what the old config setting is, but olddefconfig still
ignores it.
>
> If that's the case, then I agree that your original patch to
> make HPET_EMULATE_RTC user-visible is needed.
>
> Sorry to be so slow about understanding your goal (if I do
> understand it now).
>
> --
> ~Randy
>
--
Anand K. Mistry
Software Engineer
Google Australia
The RTC config option was removed in commit f52ef24be21a ("rtc/alpha:
remove legacy rtc driver")
Signed-off-by: Anand K Mistry
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f851179ff0..37775478d
On Thu, 4 Feb 2021 at 17:30, Randy Dunlap wrote:
>
> On 2/3/21 10:13 PM, Anand K. Mistry wrote:
> >> Hi,
> >>
> >> When you run "make olddefconfig", should this "depends on"
> >> line evaluate to true or false?
> >
> > True
e to trace
where the option is being overridden in the conf tool, but the
reasoning why is beyond my knowledge.
--
Anand K. Mistry
Software Engineer
Google Australia
the conf tool reads the config file, it only
respects the existing setting if the option is "visible" (see
scripts/kconfig/symbol.c:381).
Signed-off-by: Anand K Mistry
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21
endmsg+0x62/0x9a
do_syscall_64+0x43/0x55
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 4913e675630e ("ath10k: enable rx duration report default for wmi tlv")
Signed-off-by: Anand K Mistry
---
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --g
: 0f7cb26830a6e ("ath10k: add rx bitrate report for SDIO")
Signed-off-by: Anand K Mistry
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 7b
> > This proposal attempts to reduce that cost by letting the system
> > developer choose whether to issue the IBPB on entry or exit of an IB
> > speculation disabled process (default is both, which is current
> > behaviour). Documentation/admin-guide/hw-vuln/spectre.rst documents two
> >
> >
> > Signed-off-by: Anand K Mistry
> > Signed-off-by: Anand K Mistry
>
> Two SoBs by you, why?
Tooling issues probably. Not intentional.
>
> > ---
> > Background:
> > IBPB is slow on some CPUs.
> >
> > More detailed background:
>
a boot flag to explicitly choose
to issue IBPB when the IB spec disabled process is entered or left.
Signed-off-by: Anand K Mistry
Signed-off-by: Anand K Mistry
---
Background:
IBPB is slow on some CPUs.
More detailed background:
On some CPUs, issuing an IBPB can cause the address space
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 33fc379df76b4991e5ae312f07bcd6820811971e
Gitweb:
https://git.kernel.org/tip/33fc379df76b4991e5ae312f07bcd6820811971e
Author:Anand K Mistry
AuthorDate:Tue, 10 Nov 2020 12:33:53 +11:00
ot;x86/speculation: Avoid force-disabling IBPB based on
STIBP and enhanced IBRS.")
Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled
on CPUs with always-on STIBP")
Signed-off-by: Anand K Mistry
---
This is a follow up to my last patch
(https://
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 1978b3a53a74e3230cd46932b149c6e62e832e9a
Gitweb:
https://git.kernel.org/tip/1978b3a53a74e3230cd46932b149c6e62e832e9a
Author:Anand K Mistry
AuthorDate:Thu, 05 Nov 2020 16:33:04 +11:00
Similar to speculation store bypass, show information about the indirect
branch speculation mode of a task in /proc/$pid/status.
Signed-off-by: Anand K Mistry
---
Changes in v2:
- Remove underscores from field name to workaround documentation issue
Documentation/filesystems/proc.rst | 2
SNIPPED
> >
> > Looks like left column became too wide, so rather than shift the right
> > column to the right, I'd suggest to drop underscores in Speculation*.
>
> Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> it's the lesser of two evils.
Oh, do you mean renaming the
_ctxt_switches number of voluntary context switches
> > nonvoluntary_ctxt_switches number of non voluntary context switches
> > ======
> > ===
>
> Same here.
>
> > Introduced by commit
> >
> > 60b492d745d5 ("proc: provide details on indirect branch speculation")
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
>
> --
> Sincerely yours,
> Mike.
--
Anand K. Mistry
Software Engineer
Google Australia
On Sun, 1 Nov 2020 at 07:05, Andrew Morton wrote:
>
> On Fri, 30 Oct 2020 17:27:54 +1100 Anand K Mistry wrote:
>
> > Similar to speculation store bypass, show information about the indirect
> > branch speculation mode of a task in /proc/$pid/status.
>
> Wh
n. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
Signed-off-by: Anand K Mistry
---
Changes in v2:
- Fix typo in commit message
- s/is_spec_ib_user/is_spec_ib_user_controlled
- Update comment in ib_prctl_set() to reference X86_FEATURE_AMD_STIBP_
On Tue, 3 Nov 2020 at 21:58, Borislav Petkov wrote:
>
> On Mon, Nov 02, 2020 at 11:02:10AM +1100, Anand K. Mistry wrote:
> > > I like the idea of passing in the mode you want to check, but it appears
> > > they are never used independently. The ibpb and stibp modes
On Sun, 1 Nov 2020 at 02:05, Tom Lendacky wrote:
>
> On 10/29/20 1:51 AM, Anand K Mistry wrote:
> > On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
> > STIBP is set to on and 'spectre_v2_user_stibp ==
> > SPECTRE_V2_USER_STRICT_PREFERRED'. At the sa
On Sun, 1 Nov 2020 at 01:50, Tom Lendacky wrote:
>
> On 10/29/20 1:51 AM, Anand K Mistry wrote:
> > When attempting to do some performance testing of IBPB on and AMD
> > platform, I noticed the IBPB instruction was never being issued, even
> > though it was conditionall
On Fri, 30 Oct 2020 at 18:20, Greg Kroah-Hartman
wrote:
>
> On Fri, Oct 30, 2020 at 06:04:42PM +1100, Anand K Mistry wrote:
> > This mirrors support for exporting atomic_t values.
> >
> > Signed-off-by: Anand K Mistry
> >
> > ---
&
This mirrors support for exporting atomic_t values.
Signed-off-by: Anand K Mistry
---
fs/debugfs/file.c | 37 +
include/linux/debugfs.h | 6 ++
2 files changed, 43 insertions(+)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index
?
Anand K Mistry (1):
debugfs: Add a helper to export atomic64_t values
fs/debugfs/file.c | 37 +
include/linux/debugfs.h | 6 ++
2 files changed, 43 insertions(+)
--
2.29.1.341.ge80a0c044ae-goog
Similar to speculation store bypass, show information about the indirect
branch speculation mode of a task in /proc/$pid/status.
Signed-off-by: Anand K Mistry
---
Documentation/filesystems/proc.rst | 2 ++
fs/proc/array.c| 28
2 files changed
-on and this was causing an early-out on the prctl() which turns
off IB speculation. Here is my attempt to fix it.
I'm hoping someone that understands this better than me can explain why
I'm wrong.
Anand K Mistry (1):
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with
always-on STIBP
n. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
Signed-off-by: Anand K Mistry
---
arch/x86/kernel/cpu/bugs.c | 41 +-
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arc
@@ gpu_mw600 0.940.743.25 0.00
... and with the regulator on:
@@ NAME COUNT AVERAGE STDDEV MAX MIN
@@ gpu_mw600 0.830.663.250.00
Signed-off-by: Anand K Mistry
---
Changes in v2:
- Remove CHROMIUM from subject line
- Correct device
:facepalm: sorry about the subject line. I'll fix it up in the next revision.
On Tue, 25 Aug 2020 at 15:26, Anand K Mistry wrote:
>
> Keep the da9212 BUCKB always-on. This works around an issue on Elm/Hana
> devices where sometimes, the regulator is disabled before scpsys is
> suspen
COUNT AVERAGE STDDEV MAX MIN
@@ gpu_mw600 0.830.663.250.00
Signed-off-by: Anand K Mistry
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot
Document valid mode values for BUCK regulators.
Signed-off-by: Anand K Mistry
---
Changes in v2: None
.../devicetree/bindings/regulator/mt6397-regulator.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
b
This updates the allowed mt6397 regulator modes for elm (and derivative)
boards to use named constants.
Signed-off-by: Anand K Mistry
---
Changes in v2:
- Introduce constants in dt-bindings
- Improve conditional readability
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +++-
1 file
This will allow device trees to make use of these constants.
Signed-off-by: Anand K Mistry
---
Changes in v2: None
drivers/regulator/mt6397-regulator.c | 4 +---
.../regulator/mediatek,mt6397-regulator.h | 15 +++
2 files changed, 16 insertions(+), 3
Implementing of_map_mode is necessary to be able to specify operating
modes in the devicetree using 'regulator-allowed-modes', and to change
regulator modes.
Signed-off-by: Anand K Mistry
---
Changes in v2: None
drivers/regulator/mt6397-regulator.c | 13 +
1 file changed, 13
, the regulator-allowed-modes
devicetree field is skipped, and attempting to change the regulator mode
results in an error:
[1.439165] vpca15: mode operation not allowed
Changes in v2:
- Introduce constants in dt-bindings
- Improve conditional readability
Anand K Mistry (4):
regulator: mt6397
This sets the allowed regulator modes for elm (and derivative) boards.
According to the datasheet, the da9211 does not support SLEEP mode.
Signed-off-by: Anand K Mistry
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch
Implementing of_map_mode is necessary to be able to specify operating
modes in the devicetree using 'regulator-allowed-modes', and to change
regulator modes.
Signed-off-by: Anand K Mistry
---
drivers/regulator/da9211-regulator.c | 25 +++--
1 file changed, 23 insertions
This will allow device trees to make use of these constants.
Signed-off-by: Anand K Mistry
---
drivers/regulator/da9211-regulator.c | 5 +
.../dt-bindings/regulator/dlg,da9211-regulator.h | 16
2 files changed, 17 insertions(+), 4 deletions(-)
create mode
This patchset adds support for being able to change regulator modes for
the da9211 regulator. This is needed to allow the voltage scaling
support in the MT8173 SoC to be used in the elm (Acer Chromebook R13)
and hana (several Lenovo Chromebooks) devices.
Anand K Mistry (4):
regulator: da9211
This patch adds a description of how operating modes may be specified.
Signed-off-by: Anand K Mistry
---
Documentation/devicetree/bindings/regulator/da9211.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt
b/Documentation
Without a of_map_mode implementation, the regulator-allowed-modes
devicetree field is skipped, and attempting to change the regulator mode
results in an error:
[1.439165] vpca15: mode operation not allowed
Signed-off-by: Anand K Mistry
---
drivers/regulator/mt6397-regulator.c | 7
On Sat, 23 May 2020 at 23:35, Andi Kleen wrote:
>
> Anand K Mistry writes:
> > }
> >
> > + done_fd = eventfd(0, EFD_NONBLOCK);
>
> This will make perf depend on a recent glibc or other library
> that implements eventfd. Wouldn't surprise me if some kin
On Wed, 13 May 2020 at 00:12, Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, May 12, 2020 at 02:12:32PM +0200, Jiri Olsa escreveu:
> > On Tue, May 12, 2020 at 02:59:36PM +1000, Anand K Mistry wrote:
> >
> > SNIP
> >
> > > diff --git a/tools/perf/builtin
kill -TERM $pid
echo "PID $pid"
wait $pid
done
At some point, the loop will stall. Adding logging, even though perf has
received the SIGTERM and set 'done = 1', perf will remain sleeping until
a second signal is sent.
Signed-off-by: Anand K Mistry
---
Changes in v3:
kill -TERM $pid
echo "PID $pid"
wait $pid
done
At some point, the loop will stall. Adding logging, even though perf has
received the SIGTERM and set 'done = 1', perf will remain sleeping until
a second signal is sent.
Signed-off-by: Anand K Mistry
---
tools/perf/builtin-re
kill -TERM $pid
echo "PID $pid"
wait $pid
done
At some point, the loop will stall. Adding logging, even though perf has
received the SIGTERM and set 'done = 1', perf will remain sleeping until
a second signal is sent.
Signed-off-by: Anand K Mistry
---
tools/perf/builtin-
47 matches
Mail list logo
