Re: [RFC v6 00/51] Large pages in the page cache
On Wed, Jun 10, 2020 at 01:12:54PM -0700, Matthew Wilcox wrote: > From: "Matthew Wilcox (Oracle)" > > Another fortnight, another dump of my current large pages work. > I've squished a lot of bugs this time. xfstests is much happier now, > running for 1631 seconds and getting as far as generic/086. This patchset > is getting a little big, so I'm going to try to get some bits of it > upstream soon (the bits that make sense regardless of whether the rest > of this is merged). At this size a git tree to pull would also be nice..
Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/translations/it_IT
Am 11.06.20 um 05:12 schrieb Kees Cook: On Wed, Jun 10, 2020 at 08:11:39PM +0200, Alexander A. Klimov wrote: Am 10.06.20 um 10:57 schrieb Federico Vaga: On Tuesday, June 9, 2020 10:12:41 PM CEST Alexander A. Klimov wrote: Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Is this script somewhere we can read it? (It's easier usually to review the code for bulk changes than the bulk changes themselves.) Is any of you familiar with Golang? @Maintainers Would any of you actually review like this? If yes, is the pseudo-code not enough? Signed-off-by: Alexander A. Klimov --- .../translations/it_IT/admin-guide/README.rst | 2 +- .../translations/it_IT/doc-guide/parse-headers.rst | 2 +- .../translations/it_IT/doc-guide/sphinx.rst| 10 +- .../translations/it_IT/process/2.Process.rst | 12 ++-- .../translations/it_IT/process/3.Early-stage.rst | 2 +- .../translations/it_IT/process/4.Coding.rst| 4 ++-- .../it_IT/process/7.AdvancedTopics.rst | 8 .../translations/it_IT/process/8.Conclusion.rst| 14 +++--- .../translations/it_IT/process/adding-syscalls.rst | 4 ++-- .../translations/it_IT/process/changes.rst | 6 +++--- .../translations/it_IT/process/clang-format.rst| 2 +- .../translations/it_IT/process/coding-style.rst| 2 +- Documentation/translations/it_IT/process/howto.rst | 2 +- .../it_IT/process/maintainer-pgp-guide.rst | 2 +- .../it_IT/process/submitting-patches.rst | 4 ++-- .../it_IT/process/volatile-considered-harmful.rst | 4 ++-- 16 files changed, 40 insertions(+), 40 deletions(-) diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst b/Documentation/translations/it_IT/doc-guide/sphinx.rst index f1ad4504b734..0aaeb0297661 100644 --- a/Documentation/translations/it_IT/doc-guide/sphinx.rst +++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst @@ -14,7 +14,7 @@ Per generare la documentazione in HTML o PDF, usate comandi ``make htmldocs`` o ``make pdfdocs``. La documentazione così generata sarà disponibile nella cartella ``Documentation/output``. -.. _Sphinx: http://www.sphinx-doc.org/ +.. _Sphinx: https://www.sphinx-doc.org/ .. _reStructuredText: http://docutils.sourceforge.net/rst.html It is not part of the deterministic algorithm but you may consider this as well Why did it not match? I didn't log that link-by-link. Maybe because I also didn't follow plain HTTP redirects while opening HTTPS links. Maybe it even matched, but was added after I made the changes. Anyway, I'll maybe cover it in round II. -.. _reStructuredText: http://docutils.sourceforge.net/rst.html +.. _reStructuredText: https://docutils.sourceforge.io/rst.html I'll think about analyzing such almost-matches, extending the algo and supplying a second round of patches once all [1] of this round arrive in torvalds/master. [1]: ➜ linux git:(feature/https-links-3) ✗ git diff --shortstat 1963 files changed, 2882 insertions(+), 2882 deletions(-) ➜ linux git:(feature/https-links-3) ✗ Is there a reason to do this one language at a time instead of just doing everything in one go? There are two reasons: * Jonathan said like theoretically you could give it all at once to Linus, but practically I'd not do that, please split by subsystem * Linus *didn't even respond* (at least I didn't receive anything) to my catch-them-all patch at all, not even like please not as .gz attachment or please split by subsystem
Re: [LKP] [ima] 8eb613c0b8: stress-ng.icache.ops_per_sec -84.2% regression
On 6/10/2020 9:53 PM, Mimi Zohar wrote:
Hi Xing,
On Wed, 2020-06-10 at 11:21 +0800, Xing Zhengjun wrote:
Hi Mimi,
Do you have time to take a look at this? we noticed a 3.7%
regression of boot-time.dhcp and a 84.2% regression of
stress-ng.icache.ops_per_sec. Thanks.
On 6/3/2020 5:11 PM, kernel test robot wrote:
Greeting,
FYI, we noticed a 3.7% regression of boot-time.dhcp due to commit:
commit: 8eb613c0b8f19627ba1846dcf78bb2c85edbe8dd ("ima: verify mprotect change is
consistent with mmap policy")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: stress-ng
on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 192G
memory
with following parameters:
nr_threads: 100%
disk: 1HDD
testtime: 30s
class: cpu-cache
cpufreq_governor: performance
ucode: 0x52c
Does the following change resolve it?
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index c44414a7f82e..78e1dfc8a3f2 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -426,7 +426,8 @@ int ima_file_mprotect(struct vm_area_struct *vma, unsigned
long prot)
int pcr;
/* Is mprotect making an mmap'ed file executable? */
- if (!vma->vm_file || !(prot & PROT_EXEC) || (vma->vm_flags & VM_EXEC))
+ if (!(ima_policy_flag & IMA_APPRAISE) || !vma->vm_file ||
+ !(prot & PROT_EXEC) || (vma->vm_flags & VM_EXEC))
return 0;
security_task_getsecid(current, &secid);
Thanks. I test the change, it can resolve the regression.
=
tbox_group/testcase/rootfs/kconfig/compiler/debug-setup/nr_threads/disk/testtime/class/cpufreq_governor/ucode:
lkp-csl-2sp5/stress-ng/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-9/test/100%/1HDD/30s/cpu-cache/performance/0x52c
commit:
0c4395fb2aa77341269ea619c5419ea48171883f
8eb613c0b8f19627ba1846dcf78bb2c85edbe8dd
8745d6eb3a493b1d324eeb9edefec5d23c16cba9 (fix for the regression)
0c4395fb2aa77341 8eb613c0b8f19627ba1846dcf78 8745d6eb3a493b1d324eeb9edef
--- ---
%stddev %change %stddev %change %stddev
\ |\ |\
884.33 ± 4% +4.6% 924.67 +45.1% 1283 ±
3% stress-ng.cache.ops
29.47 ± 4% +4.6% 30.82 +45.1% 42.76 ±
3% stress-ng.cache.ops_per_sec
1245720 -84.3% 195648-0.8%1235416
stress-ng.icache.ops
41522 -84.3% 6520-0.8% 41179
stress-ng.icache.ops_per_sec
--
Zhengjun Xing
Re: [PATCH V2 2/2] mtd: rawnand: qcom: set BAM mode only if not set already
Hi Sivaprakash,
Sivaprakash Murugesan wrote on Thu, 11 Jun
2020 09:57:59 +0530:
> Hi Miquel,
>
> Thanks for the review.
>
> On 6/9/2020 7:33 PM, Miquel Raynal wrote:
> > Hi Sivaprakash,
> >
> > Sivaprakash Murugesan wrote on Tue, 9 Jun
> > 2020 16:40:56 +0530:
> >
> >> BAM mode is set by writing BAM_MODE_EN bit on NAND_CTRL register.
> >> NAND_CTRL is an operational register and in BAM mode operational
> >> registers are read only.
> >>
> >> So, before writing into NAND_CTRL register check if BAM mode is already
> >> enabled by bootloader, and set BAM mode only if it is not set already.
> >>
> >> Signed-off-by: Sivaprakash Murugesan
> >> ---
> >> drivers/mtd/nand/raw/qcom_nandc.c | 9 -
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
> >> b/drivers/mtd/nand/raw/qcom_nandc.c
> >> index e0afa2c..7740059 100644
> >> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> >> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> >> @@ -2779,7 +2779,14 @@ static int qcom_nandc_setup(struct
> >> qcom_nand_controller *nandc)
> >>/* enable ADM or BAM DMA */
> >>if (nandc->props->is_bam) {
> >>nand_ctrl = nandc_read(nandc, NAND_CTRL);
> >> - nandc_write(nandc, NAND_CTRL, nand_ctrl | BAM_MODE_EN);
> >> + /* NAND_CTRL is an operational registers, and CPU
> >> + * access to operational registers are read only
> >> + * in BAM mode. So update the NAND_CTRL register
> >> + * only if it is not in BAM mode. In most cases BAM
> >> + * mode will be enabled in bootloader
> >> + */
> >> + if (!(nand_ctrl | BAM_MODE_EN))
> >> + nandc_write(nandc, NAND_CTRL, nand_ctrl | BAM_MODE_EN);
> >>} else {
> >>nandc_write(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
> >>}
> > Does this currently produces an issue at runtime?
> >
> > If yes, you should have a Fixes/CC: stable pair of tags.
> >
> > Also, what is BAM mode? Please tell us in the commit log.
>
> Currently this is not causing any issue on run time.
>
> The writes to this register is silently ignored.
>
> However, this could be an issue in future Hardware designs.
>
> BAM is the DMA engine on QCOM IPQ platforms, sure will explain this
>
> mode in next patchset.
I don't like so much the idea of DMA being enabled by the Bootloader or
not, this is something that should need to be fixed.
Thanks,
Miquèl
Re: [PATCH 1/2] mtd: rawnand: brcmnand: Don't default to edu transfer
Hi Kamal,
Kamal Dasu wrote on Thu, 11 Jun 2020 01:44:53
-0400:
> When flash-dma is absent do not default to using flash-edu.
> Make sure flash-edu is enabled before setting EDU transfer
> function.
>
> Fixes: a5d53ad26a8b ("mtd: rawnand: brcmnand: Add support for flash-edu for
> dma transfers")
> Signed-off-by: Kamal Dasu
> ---
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> index 8f9ffb46a09f..0c1d6e543586 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -2953,8 +2953,9 @@ int brcmnand_probe(struct platform_device *pdev, struct
> brcmnand_soc *soc)
> if (ret < 0)
> goto err;
>
> - /* set edu transfer function to call */
> - ctrl->dma_trans = brcmnand_edu_trans;
> + if (has_edu(ctrl))
> + /* set edu transfer function to call */
> + ctrl->dma_trans = brcmnand_edu_trans;
Does this fallback to returning an error in case !has_edu() ? Othewise,
how is it handled?
Thanks,
Miquèl
Re: [PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP platforms
> On Jun 10, 2020, at 23:49, mario.limoncie...@dell.com wrote:
>
>> -Original Message-
>> From: platform-driver-x86-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Kai-Heng Feng
>> Sent: Wednesday, June 10, 2020 10:38 AM
>> To: alex.h...@canonical.com
>> Cc: Kai-Heng Feng; Darren Hart; Andy Shevchenko; open list:INTEL HID EVENT
>> DRIVER; open list
>> Subject: [PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP
>> platforms
>>
>>
>> [EXTERNAL EMAIL]
>>
>> Wireless hotkey on HP platforms can trigger two events, if both
>> hp-wireless and intel-hid are supported. Two events at the same time
>> renders wireless hotkey useless.
>>
>> HP confirmed that hp-wireless (HPQ6001) should always be the canonical
>> source of wireless hotkey event, so skip registering rfkill hotkey if
>> HPQ6001 is present.
>>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/platform/x86/intel-hid.c | 31 ++-
>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-
>> hid.c
>> index 9ee79b74311c..31091c8faf70 100644
>> --- a/drivers/platform/x86/intel-hid.c
>> +++ b/drivers/platform/x86/intel-hid.c
>> @@ -25,6 +25,8 @@ static const struct acpi_device_id intel_hid_ids[] = {
>> };
>> MODULE_DEVICE_TABLE(acpi, intel_hid_ids);
>>
>> +static bool hp_wireless_present;
>> +
>> /* In theory, these are HID usages. */
>> static const struct key_entry intel_hid_keymap[] = {
>> /* 1: LSuper (Page 0x07, usage 0xE3) -- unclear what to do */
>> @@ -49,6 +51,29 @@ static const struct key_entry intel_hid_keymap[] = {
>> { KE_END },
>> };
>>
>> +static const struct key_entry intel_hid_no_rfkill_keymap[] = {
>> +/* 1: LSuper (Page 0x07, usage 0xE3) -- unclear what to do */
>> +/* 2: Toggle SW_ROTATE_LOCK -- easy to implement if seen in wild */
>> +{ KE_KEY, 3, { KEY_NUMLOCK } },
>> +{ KE_KEY, 4, { KEY_HOME } },
>> +{ KE_KEY, 5, { KEY_END } },
>> +{ KE_KEY, 6, { KEY_PAGEUP } },
>> +{ KE_KEY, 7, { KEY_PAGEDOWN } },
>> +/* 8: rfkill -- use hp-wireless instead */
>> +{ KE_KEY, 9, { KEY_POWER } },
>> +{ KE_KEY, 11, { KEY_SLEEP } },
>> +/* 13 has two different meanings in the spec -- ignore it. */
>> +{ KE_KEY, 14, { KEY_STOPCD } },
>> +{ KE_KEY, 15, { KEY_PLAYPAUSE } },
>> +{ KE_KEY, 16, { KEY_MUTE } },
>> +{ KE_KEY, 17, { KEY_VOLUMEUP } },
>> +{ KE_KEY, 18, { KEY_VOLUMEDOWN } },
>> +{ KE_KEY, 19, { KEY_BRIGHTNESSUP } },
>> +{ KE_KEY, 20, { KEY_BRIGHTNESSDOWN } },
>> +/* 27: wake -- needs special handling */
>> +{ KE_END },
>> +};
>> +
>> /* 5 button array notification value. */
>> static const struct key_entry intel_array_keymap[] = {
>> { KE_KEY,0xC2, { KEY_LEFTMETA } },/* Press */
>> @@ -317,7 +342,8 @@ static int intel_hid_input_setup(struct platform_device
>> *device)
>> if (!priv->input_dev)
>> return -ENOMEM;
>>
>> -ret = sparse_keymap_setup(priv->input_dev, intel_hid_keymap, NULL);
>> +ret = sparse_keymap_setup(priv->input_dev, hp_wireless_present ?
>> +intel_hid_no_rfkill_keymap : intel_hid_keymap, NULL);
>> if (ret)
>> return ret;
>>
>> @@ -575,6 +601,9 @@ check_acpi_dev(acpi_handle handle, u32 lvl, void
>> *context, void **rv)
>> dev_info(&dev->dev,
>> "intel-hid: created platform device\n");
>>
>> +if (!strcmp(acpi_device_hid(dev), "HPQ6001"))
>> +hp_wireless_present = true;
>
> Just having the ACPI device present doesn't actually mean that the user
> has a kernel compiled with hp-wireless or that it has finished initializing.
We can use IS_REACHEABLE() to see if it's compiled.
>
> I would think this needs a better handshake in case hp-wireless was unloaded
> or not present so the event could still come through intel-hid in this
> circumstance.
However, it's hard to determine if the other driver has finished initialization
or any form of cross module handshake.
Can you please point me to any good example if there's one?
>
>> +
>> return AE_OK;
>> }
>>
>> --
>> 2.17.1
Re: [PATCH 4.4 00/36] 4.4.227-rc2 review
On Wed, Jun 10, 2020 at 01:37:56PM -0600, Shuah Khan wrote: > On 6/9/20 1:18 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.227 release. > > There are 36 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu, 11 Jun 2020 19:02:00 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.227-rc2.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.4.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Linux 5.7.2
I'm announcing the release of the 5.7.2 kernel. All users of the 5.7 kernel series must upgrade. The updated 5.7.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.7.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/admin-guide/kernel-parameters.txt | 20 + Makefile| 2 arch/x86/include/asm/cpu_device_id.h| 27 + arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/msr-index.h| 4 arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/common.c| 56 +++ arch/x86/kernel/cpu/cpu.h | 1 arch/x86/kernel/cpu/match.c | 7 drivers/base/cpu.c | 8 drivers/iio/adc/stm32-adc-core.c| 34 -- drivers/iio/chemical/pms7003.c | 17 - drivers/iio/chemical/sps30.c| 9 drivers/iio/light/vcnl4000.c| 6 drivers/nvmem/qfprom.c | 14 drivers/staging/rtl8712/wifi.h | 9 drivers/tty/hvc/hvc_console.c | 23 - drivers/tty/serial/8250/Kconfig | 1 drivers/tty/vt/keyboard.c | 26 + drivers/usb/class/cdc-acm.c | 2 drivers/usb/musb/jz4740.c | 4 drivers/usb/musb/musb_core.c| 7 drivers/usb/musb/musb_debugfs.c | 10 drivers/usb/serial/ch341.c | 68 drivers/usb/serial/option.c | 4 drivers/usb/serial/qcserial.c | 1 drivers/usb/serial/usb_wwan.c | 4 include/linux/mod_devicetable.h | 2 kernel/events/uprobes.c | 16 - 32 files changed, 531 insertions(+), 110 deletions(-) Bin Liu (2): USB: serial: usb_wwan: do not resubmit rx urb on fatal errors usb: musb: start session in resume for host port Daniele Palmas (1): USB: serial: option: add Telit LE910C1-EUX compositions Dinghao Liu (1): usb: musb: Fix runtime PM imbalance on error Dmitry Torokhov (1): vt: keyboard: avoid signed integer overflow in k_ascii Fabrice Gasnier (1): iio: adc: stm32-adc: fix a wrong error message when probing interrupts Greg Kroah-Hartman (1): Linux 5.7.2 Jiri Slaby (1): tty: hvc_console, fix crashes on parallel open/close Johan Hovold (1): USB: serial: ch341: fix lockup of devices with limited prescaler Jonathan Cameron (2): iio:chemical:sps30: Fix timestamp alignment iio:chemical:pms7003: Fix timestamp alignment and prevent data leak. Josh Poimboeuf (1): x86/speculation: Add Ivy Bridge to affected list Josh Triplett (1): serial: 8250: Enable 16550A variants by default on non-x86 Mark Gross (4): x86/cpu: Add a steppings field to struct x86_cpu_id x86/cpu: Add 'table' argument to cpu_matches() x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation x86/speculation: Add SRBDS vulnerability and mitigation documentation Mathieu Othacehe (1): iio: vcnl4000: Fix i2c swapped word reading. Matt Jolly (1): USB: serial: qcserial: add DW5816e QDL support Michael Hanselmann (1): USB: serial: ch341: add basis for quirk detection Oleg Nesterov (1): uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned Oliver Neukum (1): CDC-ACM: heed quirk also in error handling Pascal Terjan (1): staging: rtl8712: Fix IEEE80211_ADDBA_PARA
Re: [PATCH 5.7 00/24] 5.7.2-rc1 review
On Wed, Jun 10, 2020 at 12:11:33PM -0700, Guenter Roeck wrote: > On Tue, Jun 09, 2020 at 07:45:31PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.7.2 release. > > There are 24 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu, 11 Jun 2020 17:41:38 +. > > Anything received after that time might be too late. > > > > Build results: > total: 155 pass: 155 fail: 0 > Qemu test results: > total: 431 pass: 431 fail: 0 Thanks for testing all of these and letting me know. greg k-h
Re: Linux 5.6.18
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 2e0e3b45d02a..b39531a3c5bc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -492,6 +492,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index 0795e3c2643f..ca4dbdd9016d 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -14,3 +14,4 @@ are configurable at compile, boot or run time. mds tsx_async_abort multihit.rst + special-register-buffer-data-sampling.rst diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do n
Re: Linux 5.7.2
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 2e0e3b45d02a..b39531a3c5bc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -492,6 +492,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index 0795e3c2643f..ca4dbdd9016d 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -14,3 +14,4 @@ are configurable at compile, boot or run time. mds tsx_async_abort multihit.rst + special-register-buffer-data-sampling.rst diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do n
Re: [RFC PATCH 7/7] objtool: Make unwind_hints available for all architectures
Hi Miroslav, On 6/10/20 2:20 PM, Miroslav Benes wrote: Hi Julien, On Mon, 8 Jun 2020, Julien Thierry wrote: Unwind hints are useful to give some information about the call frame or stack states in non-standard code. Despite unwind hints being used in arch-independent code, the unwind_hint structure type itself is define in x86 kernel headers. This is because what an unwind hint will describe is very architecture specific, both regarding the state and the affected registers. To get to share this concept, expose the unwind_hint structure across architecutres. However, the hint types remain defined by the architecture code. Objtool then needs it's arch specific code to "decode" the unwind hint into a cfi_state. I think it would be nice to split the patch. Something like. 1. current include/linux/frame.h mixes assembly and non-assembly definitions, so introduce ASSEMBLY ifdef first seems like a good idea to me. 2. move the relevant definitions to frame.h and add the file to sync-check 3. the rest of the patch Would it make sense? Yes, I think your approach will make it simpler to review. I wasn't sure how to split it but I like your suggestion, thank you for it. I'll probably post the split patch separately if the rest of the series gets picked. Cheers, -- Julien Thierry
Re: Linux 4.19.128
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index b492fb6057c9..b9c14c11efc5 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -478,6 +478,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index 0795e3c2643f..ca4dbdd9016d 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -14,3 +14,4 @@ are configurable at compile, boot or run time. mds tsx_async_abort multihit.rst + special-register-buffer-data-sampling.rst diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do n
Linux 5.6.18
I'm announcing the release of the 5.6.18 kernel. All users of the 5.6 kernel series must upgrade. The updated 5.6.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.6.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/admin-guide/kernel-parameters.txt | 20 + Makefile| 2 arch/x86/include/asm/cpu_device_id.h| 30 ++ arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/msr-index.h| 4 arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/common.c| 56 +++ arch/x86/kernel/cpu/cpu.h | 1 arch/x86/kernel/cpu/match.c | 7 drivers/base/cpu.c | 8 drivers/iio/adc/stm32-adc-core.c| 34 -- drivers/iio/chemical/pms7003.c | 17 - drivers/iio/chemical/sps30.c| 9 drivers/iio/light/vcnl4000.c| 6 drivers/net/dsa/ocelot/felix.c | 8 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 6 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 6 drivers/net/ethernet/mellanox/mlx5/core/main.c | 18 + drivers/net/ethernet/netronome/nfp/flower/offload.c | 3 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 drivers/net/usb/qmi_wwan.c | 1 drivers/nfc/st21nfca/dep.c | 4 drivers/nvmem/qfprom.c | 14 drivers/staging/rtl8712/wifi.h | 9 drivers/tty/hvc/hvc_console.c | 23 - drivers/tty/serial/8250/Kconfig | 1 drivers/tty/vt/keyboard.c | 26 + drivers/usb/class/cdc-acm.c | 2 drivers/usb/musb/musb_core.c| 7 drivers/usb/musb/musb_debugfs.c | 10 drivers/usb/serial/ch341.c | 68 drivers/usb/serial/option.c | 4 drivers/usb/serial/qcserial.c | 1 drivers/usb/serial/usb_wwan.c | 4 include/linux/mod_devicetable.h | 6 include/linux/virtio_net.h | 25 + kernel/events/uprobes.c | 16 - net/ipv4/devinet.c | 1 net/l2tp/l2tp_core.c| 3 net/l2tp/l2tp_ip.c | 29 + net/l2tp/l2tp_ip6.c | 30 +- net/mptcp/protocol.c| 20 + net/sched/sch_fq_pie.c | 4 net/sctp/ulpevent.c | 3 net/vmw_vsock/af_vsock.c| 2 net/vmw_vsock/virtio_transport_common.c | 8 tools/testing/selftests/tc-testing/tc-tests/qdiscs/fq_pie.json | 21 + 50 files changed, 693 insertions(+), 146 deletions(-) Bin Liu (2): USB: serial: usb_wwan: do not resubmit rx urb on fatal errors usb: musb: start session in resume for host port Chuhong Yuan (1): NFC: st21nfca: add missed
Linux 4.19.128
I'm announcing the release of the 4.19.128 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/admin-guide/kernel-parameters.txt | 20 + Makefile| 2 arch/x86/include/asm/cpu_device_id.h| 27 + arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/msr-index.h| 4 arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/common.c| 54 ++- arch/x86/kernel/cpu/cpu.h | 1 arch/x86/kernel/cpu/match.c | 7 drivers/base/cpu.c | 8 drivers/iio/light/vcnl4000.c| 6 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 6 drivers/net/usb/qmi_wwan.c | 1 drivers/nfc/st21nfca/dep.c | 4 drivers/nvmem/qfprom.c | 14 drivers/staging/rtl8712/wifi.h | 9 drivers/tty/hvc/hvc_console.c | 23 - drivers/tty/vt/keyboard.c | 26 + drivers/usb/class/cdc-acm.c | 2 drivers/usb/musb/musb_core.c| 7 drivers/usb/musb/musb_debugfs.c | 10 drivers/usb/serial/option.c | 4 drivers/usb/serial/qcserial.c | 1 drivers/usb/serial/usb_wwan.c | 4 include/linux/mod_devicetable.h | 6 include/linux/virtio_net.h | 14 kernel/events/uprobes.c | 14 net/ipv4/devinet.c | 1 net/l2tp/l2tp_core.c| 3 net/l2tp/l2tp_ip.c | 29 + net/l2tp/l2tp_ip6.c | 30 +- net/vmw_vsock/af_vsock.c| 2 35 files changed, 500 insertions(+), 98 deletions(-) Bin Liu (2): USB: serial: usb_wwan: do not resubmit rx urb on fatal errors usb: musb: start session in resume for host port Chuhong Yuan (1): NFC: st21nfca: add missed kfree_skb() in an error path Daniele Palmas (2): net: usb: qmi_wwan: add Telit LE910C1-EUX composition USB: serial: option: add Telit LE910C1-EUX compositions Dinghao Liu (1): usb: musb: Fix runtime PM imbalance on error Dmitry Torokhov (1): vt: keyboard: avoid signed integer overflow in k_ascii Eric Dumazet (2): l2tp: add sk_family checks to l2tp_validate_socket l2tp: do not use inet_hash()/inet_unhash() Greg Kroah-Hartman (2): Revert "net/mlx5: Annotate mutex destroy for root ns" Linux 4.19.128 Jiri Slaby (1): tty: hvc_console, fix crashes on parallel open/close Josh Poimboeuf (1): x86/speculation: Add Ivy Bridge to affected list Mark Gross (4): x86/cpu: Add a steppings field to struct x86_cpu_id x86/cpu: Add 'table' argument to cpu_matches() x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation x86/speculation: Add SRBDS vulnerability and mitigation documentation Mathieu Othacehe (1): iio: vcnl4000: Fix i2c swapped word reading. Matt Jolly (1): USB: serial: qcserial: add DW5816e QDL support Oleg Nesterov (1): uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned Oliver Neukum (1): CDC-ACM: heed quirk also in
Re: Linux 5.4.46
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index fc20cde63d1e..c24afa60a30e 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -486,6 +486,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index 0795e3c2643f..ca4dbdd9016d 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -14,3 +14,4 @@ are configurable at compile, boot or run time. mds tsx_async_abort multihit.rst + special-register-buffer-data-sampling.rst diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do n
Re: Re: [PATCH v15 03/14] mm/damon: Implement region based sampling
On Wed, 10 Jun 2020 22:36:00 +0200 wrote:
> On 6/8/20 1:40 PM, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > This commit implements DAMON's basic access check and region based
> > sampling mechanisms. This change would seems make no sense, mainly
> > because it is only a part of the DAMON's logics. Following two commits
> > will make more sense.
> >
[...]
> > +
> > +/*
> > + * Find three regions separated by two biggest unmapped regions
> > + *
> > + * vma the head vma of the target address space
> > + * regions an array of three 'struct region's that results will be saved
> > + *
> > + * This function receives an address space and finds three regions in it
> > which
> > + * separated by the two biggest unmapped regions in the space. Please
> > refer to
> > + * below comments of 'damon_init_regions_of()' function to know why this is
> > + * necessary.
> > + *
> > + * Returns 0 if success, or negative error code otherwise.
> > + */
> > +static int damon_three_regions_in_vmas(struct vm_area_struct *vma,
> > + struct region regions[3])
> > +{
> > + struct region gap = {0}, first_gap = {0}, second_gap = {0};
> > + struct vm_area_struct *last_vma = NULL;
> > + unsigned long start = 0;
> > +
> > + /* Find two biggest gaps so that first_gap > second_gap > others */
> > + for (; vma; vma = vma->vm_next) {
>
> Since vm_area_struct already maintains information about the largest gap
> below this vma
> in the mm_rb rbtree, walking the vma via mm_rb instead of the linked list,
> and skipping
> the ones with don't fit the gap requirement via vma->rb_subtree_gap helps
> avoid the
> extra comparisons in this function.
Thanks for the idea!
>
> I measured the following implementation to be considerably faster as the
> number of
> vmas grows for a process damon would attach to:
>
> -static int damon_three_regions_in_vmas(struct vm_area_struct *vma,
> +static int damon_three_regions_in_vmas(struct rb_root *root,
> struct region regions[3])
> {
> + struct rb_node *nd = NULL;
> struct region gap = {0}, first_gap = {0}, second_gap = {0};
> - struct vm_area_struct *last_vma = NULL;
I like this cleanup. I'm so wonder how I forgot using '->vm_prev'. :)
> + struct vm_area_struct *vma = NULL;
> unsigned long start = 0;
>
> /* Find two biggest gaps so that first_gap > second_gap > others */
> - for (; vma; vma = vma->vm_next) {
> - if (!last_vma) {
> - start = vma->vm_start;
> - last_vma = vma;
> + for (nd = rb_first(root); nd; nd = rb_next(nd)) {
> + vma = rb_entry(nd, struct vm_area_struct, vm_rb);
This seems meaningless to me. This will iterate the vma tree in address order,
as same to the old code. Moreover, 'rb_next()' and 'rb_entry()' might be
slower than the direct reference of '->vm_next'.
> +
> + if (vma->rb_subtree_gap < sz_region(&second_gap)) {
> + /*
> + * Skip this vma if the largest gap at this vma is still
> + * smaller than what we have encountered so far.
> + */
> continue;
This means we are skipping this node only. It would make no big difference
from the old code, as we still iterate all nodes.
Rather than that, by the definition of the '->rb_subtree_gap', we could skip
all vmas in the subtree. For example:
vma = rb_entry(rb_last(vma->vm_rb), struct vm_area_struct, vm_rb);
continue;
Nevertheless, this function is not the performance critical point, as this will
be called only once for the initial time in this patch, and the followup
patches will make this function to be called for every regions update interval,
which defaults to 1 second. The followup patches will also allow users set the
interval large enough and even configure their own optimized version. For the
reason, I concern simpleness ratherthan performance here.
That said, your fundamental idea obviously makes sense and the changes for that
would be subtle. I will update this patch in abovely modified way and do some
test.
If I missed something, please let me know.
Thanks,
SeongJae Park
Linux 5.4.46
I'm announcing the release of the 5.4.46 kernel. All users of the 5.4 kernel series must upgrade. The updated 5.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/admin-guide/kernel-parameters.txt | 20 + Makefile| 2 arch/x86/include/asm/cpu_device_id.h| 30 ++ arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/msr-index.h| 4 arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/common.c| 63 +++- arch/x86/kernel/cpu/cpu.h | 1 arch/x86/kernel/cpu/match.c | 7 drivers/base/cpu.c | 8 drivers/iio/adc/stm32-adc-core.c| 34 -- drivers/iio/chemical/pms7003.c | 17 - drivers/iio/chemical/sps30.c| 9 drivers/iio/light/vcnl4000.c| 6 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 6 drivers/net/ethernet/mellanox/mlx5/core/main.c | 18 + drivers/net/ethernet/netronome/nfp/flower/offload.c | 3 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 drivers/net/usb/qmi_wwan.c | 1 drivers/nfc/st21nfca/dep.c | 4 drivers/nvmem/qfprom.c | 14 drivers/staging/rtl8712/wifi.h | 9 drivers/tty/hvc/hvc_console.c | 23 - drivers/tty/vt/keyboard.c | 26 + drivers/usb/class/cdc-acm.c | 2 drivers/usb/musb/musb_core.c| 7 drivers/usb/musb/musb_debugfs.c | 10 drivers/usb/serial/ch341.c | 53 +++ drivers/usb/serial/option.c | 4 drivers/usb/serial/qcserial.c | 1 drivers/usb/serial/usb_wwan.c | 4 include/linux/mod_devicetable.h | 6 include/linux/virtio_net.h | 25 + kernel/events/uprobes.c | 16 - net/ipv4/devinet.c | 1 net/l2tp/l2tp_core.c| 3 net/l2tp/l2tp_ip.c | 29 + net/l2tp/l2tp_ip6.c | 30 +- net/vmw_vsock/af_vsock.c| 2 42 files changed, 626 insertions(+), 134 deletions(-) Bin Liu (2): USB: serial: usb_wwan: do not resubmit rx urb on fatal errors usb: musb: start session in resume for host port Chuhong Yuan (1): NFC: st21nfca: add missed kfree_skb() in an error path Daniele Palmas (2): net: usb: qmi_wwan: add Telit LE910C1-EUX composition USB: serial: option: add Telit LE910C1-EUX compositions Dinghao Liu (1): usb: musb: Fix runtime PM imbalance on error Dmitry Torokhov (1): vt: keyboard: avoid signed integer overflow in k_ascii Eric Dumazet (3): l2tp: add sk_family checks to l2tp_validate_socket l2tp: do not use inet_hash()/inet_unhash() net: be more gentle about silly gso requests coming from user Fabrice Gasnier (1): iio: adc: stm32-adc: fix a wrong error message when probing interrupts Fugang Duan (1): net: stmmac: enable timestamp snapshot for require
Re: [PATCH v3 2/2] regulator: Add driver for cros-ec-regulator
Thanks for the review, would address most of them in v4. An inline reply as below: On Thu, Jun 11, 2020 at 12:47 AM Enric Balletbo i Serra wrote: > > Hi Pi-Hsun, > > Thank you for your patch. > > On 10/6/20 11:07, Pi-Hsun Shih wrote: > > +/*/ > > +/* Voltage regulator controls */ > > + > > +/* > > + * Get basic info of voltage regulator for given index. > > + * > > + * Returns the regulator name and supported voltage list in mV. > > + */ > > +#define EC_CMD_REGULATOR_GET_INFO 0x012B > > This introduces a new EC command, while you are here, please also add the > command in drivers/platform/chrome/cros_ec_trace.c, so we can trace properly > the > command. Also can you point me to the commit that introduces this command in > the > EC firmware? The commit that introduces this in EC firmware is at https://crrev.com/c/2100327
Re: [PATCH 4.4 00/36] 4.4.227-rc2 review
On Thu, Jun 11, 2020 at 06:51:15AM +, Chris Paterson wrote: > Hello Greg, > > > From: stable-ow...@vger.kernel.org On > > Behalf Of Greg Kroah-Hartman > > Sent: 09 June 2020 20:18 > > > > This is the start of the stable review cycle for the 4.4.227 release. > > There are 36 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > No build/boot issues seen for CIP configs Linux 4.4.227-rc2 (61ef7e7aaf1d). > > Build/test pipeline/logs: > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/154557183 > GitLab CI pipeline: > https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.4.y.yml > Relevant LAVA jobs: > https://lava.ciplatform.org/scheduler/alljobs?length=25&search=61ef7e#table Thanks for testing 2 of these and letting me know. greg k-h
Re: [PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP platforms
> On Jun 11, 2020, at 01:41, Alex Hung wrote:
>
> On 2020-06-10 9:49 a.m., mario.limoncie...@dell.com wrote:
>>> -Original Message-
>>> From: platform-driver-x86-ow...@vger.kernel.org >> ow...@vger.kernel.org> On Behalf Of Kai-Heng Feng
>>> Sent: Wednesday, June 10, 2020 10:38 AM
>>> To: alex.h...@canonical.com
>>> Cc: Kai-Heng Feng; Darren Hart; Andy Shevchenko; open list:INTEL HID EVENT
>>> DRIVER; open list
>>> Subject: [PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP
>>> platforms
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> Wireless hotkey on HP platforms can trigger two events, if both
>>> hp-wireless and intel-hid are supported. Two events at the same time
>>> renders wireless hotkey useless.
>>>
>>> HP confirmed that hp-wireless (HPQ6001) should always be the canonical
>>> source of wireless hotkey event, so skip registering rfkill hotkey if
>>> HPQ6001 is present.
>>>
>>> Signed-off-by: Kai-Heng Feng
>>> ---
>>> drivers/platform/x86/intel-hid.c | 31 ++-
>>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-
>>> hid.c
>>> index 9ee79b74311c..31091c8faf70 100644
>>> --- a/drivers/platform/x86/intel-hid.c
>>> +++ b/drivers/platform/x86/intel-hid.c
>>> @@ -25,6 +25,8 @@ static const struct acpi_device_id intel_hid_ids[] = {
>>> };
>>> MODULE_DEVICE_TABLE(acpi, intel_hid_ids);
>>>
>>> +static bool hp_wireless_present;
>>> +
>>> /* In theory, these are HID usages. */
>>> static const struct key_entry intel_hid_keymap[] = {
>>> /* 1: LSuper (Page 0x07, usage 0xE3) -- unclear what to do */
>>> @@ -49,6 +51,29 @@ static const struct key_entry intel_hid_keymap[] = {
>>> { KE_END },
>>> };
>>>
>>> +static const struct key_entry intel_hid_no_rfkill_keymap[] = {
>>> + /* 1: LSuper (Page 0x07, usage 0xE3) -- unclear what to do */
>>> + /* 2: Toggle SW_ROTATE_LOCK -- easy to implement if seen in wild */
>>> + { KE_KEY, 3, { KEY_NUMLOCK } },
>>> + { KE_KEY, 4, { KEY_HOME } },
>>> + { KE_KEY, 5, { KEY_END } },
>>> + { KE_KEY, 6, { KEY_PAGEUP } },
>>> + { KE_KEY, 7, { KEY_PAGEDOWN } },
>>> + /* 8: rfkill -- use hp-wireless instead */
>>> + { KE_KEY, 9, { KEY_POWER } },
>>> + { KE_KEY, 11, { KEY_SLEEP } },
>>> + /* 13 has two different meanings in the spec -- ignore it. */
>>> + { KE_KEY, 14, { KEY_STOPCD } },
>>> + { KE_KEY, 15, { KEY_PLAYPAUSE } },
>>> + { KE_KEY, 16, { KEY_MUTE } },
>>> + { KE_KEY, 17, { KEY_VOLUMEUP } },
>>> + { KE_KEY, 18, { KEY_VOLUMEDOWN } },
>>> + { KE_KEY, 19, { KEY_BRIGHTNESSUP } },
>>> + { KE_KEY, 20, { KEY_BRIGHTNESSDOWN } },
>>> + /* 27: wake -- needs special handling */
>>> + { KE_END },
>>> +};
>>> +
>>> /* 5 button array notification value. */
>>> static const struct key_entry intel_array_keymap[] = {
>>> { KE_KEY,0xC2, { KEY_LEFTMETA } },/* Press */
>>> @@ -317,7 +342,8 @@ static int intel_hid_input_setup(struct platform_device
>>> *device)
>>> if (!priv->input_dev)
>>> return -ENOMEM;
>>>
>>> - ret = sparse_keymap_setup(priv->input_dev, intel_hid_keymap, NULL);
>>> + ret = sparse_keymap_setup(priv->input_dev, hp_wireless_present ?
>>> + intel_hid_no_rfkill_keymap : intel_hid_keymap, NULL);
>>> if (ret)
>>> return ret;
>>>
>>> @@ -575,6 +601,9 @@ check_acpi_dev(acpi_handle handle, u32 lvl, void
>>> *context, void **rv)
>>> dev_info(&dev->dev,
>>> "intel-hid: created platform device\n");
>>>
>>> + if (!strcmp(acpi_device_hid(dev), "HPQ6001"))
>>> + hp_wireless_present = true;
>
> (Resend with format removed)
>
> This can impact all HP systems that do not have this problem.
HP is certain that HPQ6001 should always be used over INT33D5.
If this patch breaks other platform, then we should fix HPQ6001 instead.
> How about
> a DMI quirk that is limited to this particular system?
We should avoid using DMI quirk for this one, as this is to follow the HP's
spec.
Kai-Heng
>
>
>>
>> Just having the ACPI device present doesn't actually mean that the user
>> has a kernel compiled with hp-wireless or that it has finished initializing.
>>
>> I would think this needs a better handshake in case hp-wireless was unloaded
>> or not present so the event could still come through intel-hid in this
>> circumstance.
>>
>>> +
>>> return AE_OK;
>>> }
>>>
>>> --
>>> 2.17.1
>>
>
>
> --
> Cheers,
> Alex Hung
Re: [Patch v2] lib: test get_count_order/long in test_bitops.c
On Thu, Jun 11, 2020 at 1:06 AM Wei Yang wrote: > On Wed, Jun 10, 2020 at 01:17:28PM +0300, Andy Shevchenko wrote: > >On Wed, Jun 10, 2020 at 2:06 AM Wei Yang wrote: > >> On Tue, Jun 09, 2020 at 12:16:49PM +0300, Andy Shevchenko wrote: > >> >On Mon, Jun 08, 2020 at 10:31:12PM +, Wei Yang wrote: > >> >> On Fri, Jun 05, 2020 at 05:16:29PM -0700, Andrew Morton wrote: > >> > > >> >... > >> > > >> >> The test on 64bit machine pass. Since I don't have a 32bit machine by > >> >> hand, > >> > > >> >Out of curiosity what that machine is? > >> > > >> > >> It is a Intel Xeon Gold CPU. > > > >I suppose it's x86 (and not ia64). > >In this case you can always build an i386 configuration and test on a > >32-bit "machine". > > > > Yes, you are right. While last time I tried to run a 32bit guest, it took me a > lot of time to setup. If my understanding is correct, to run on a 32bit > machine, we not only need the kernel but a whole 32bit system. This means I > need to re-install a 32bit system. And I found many distro doesn't support > 32bit system any more. > > Do you have a better way to setup the environment? Yes, BuildRoot is your friend. I have a branch [1] to make it suitable to create bootable images for x86 machines. There is a quick instructions what it does provide. [1]: https://github.com/andy-shev/buildroot/tree/intel/board/intel/common -- With Best Regards, Andy Shevchenko
[patch for-5.8] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL
DMA_REMAP is an unnecessary requirement for AMD SEV, which requires
DMA_COHERENT_POOL, so avoid selecting it when it is otherwise unnecessary.
The only other requirement for DMA coherent pools is DMA_DIRECT_REMAP, so
ensure that properly selects the config option when needed.
Fixes: 82fef0ad811f ("x86/mm: unencrypted non-blocking DMA allocations use
coherent pools")
Suggested-by: Christoph Hellwig
Signed-off-by: David Rientjes
---
kernel/dma/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -73,18 +73,18 @@ config SWIOTLB
config DMA_NONCOHERENT_MMAP
bool
+config DMA_COHERENT_POOL
+ bool
+
config DMA_REMAP
+ bool
depends on MMU
select GENERIC_ALLOCATOR
select DMA_NONCOHERENT_MMAP
- bool
-
-config DMA_COHERENT_POOL
- bool
- select DMA_REMAP
config DMA_DIRECT_REMAP
bool
+ select DMA_REMAP
select DMA_COHERENT_POOL
config DMA_CMA
Re: [PATCH 2/2] mtd: rawnand: brcmnand: Ecc error handling on EDU transfers
Hi Kamal,
Kamal Dasu wrote on Thu, 11 Jun 2020 01:44:54
-0400:
> Implemented ECC correctable and uncorrectable error handling for EDU
Implement?
> reads. If ECC correctable bitflips are encountered on EDU transfer,
extra space ^
> read page again using pio, This is needed due to a controller lmitation
s/pio/PIO/
> where read and corrected data is not transferred to the DMA buffer on ECC
> errors. This holds true for ECC correctable errors beyond set threshold.
error.
Not sure what the last sentence means?
>
> Fixes: a5d53ad26a8b ("mtd: rawnand: brcmnand: Add support for flash-edu for
> dma transfers")
> Signed-off-by: Kamal Dasu
> ---
Minor nits below :)
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 26
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> index 0c1d6e543586..d7daa83c8a58 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -1855,6 +1855,22 @@ static int brcmnand_edu_trans(struct brcmnand_host
> *host, u64 addr, u32 *buf,
> edu_writel(ctrl, EDU_STOP, 0); /* force stop */
> edu_readl(ctrl, EDU_STOP);
>
> + if (ret == 0 && edu_cmd == EDU_CMD_READ) {
!ret
> + u64 err_addr = 0;
> +
> + /*
> + * check for ecc errors here, subpage ecc erros are
> + * retained in ecc error addr register
s/ecc/ECC/
s/erros/errors/
s/addr/address/
> + */
> + err_addr = brcmnand_get_uncorrecc_addr(ctrl);
> + if (!err_addr) {
> + err_addr = brcmnand_get_correcc_addr(ctrl);
> + if (err_addr)
> + ret = -EUCLEAN;
> + } else
> + ret = -EBADMSG;
I don't like very much to see these values being used within NAND
controller drivers but I see it's already the cause, so I guess I can
live with that.
> + }
> +
> return ret;
> }
>
> @@ -2058,6 +2074,7 @@ static int brcmnand_read(struct mtd_info *mtd, struct
> nand_chip *chip,
> u64 err_addr = 0;
> int err;
> bool retry = true;
> + bool edu_read = false;
>
> dev_dbg(ctrl->dev, "read %llx -> %p\n", (unsigned long long)addr, buf);
>
> @@ -2075,6 +2092,10 @@ static int brcmnand_read(struct mtd_info *mtd, struct
> nand_chip *chip,
> else
> return -EIO;
> }
> +
> + if (has_edu(ctrl))
> + edu_read = true;
You don't need this extra value, you already have the cmd parameter
which tells you if it is a read or a write. You might even want to
create a if block so set dir and edu_cmd and eventually a local
edu_read if you think it still makes sense.
> +
> } else {
> if (oob)
> memset(oob, 0x99, mtd->oobsize);
> @@ -2122,6 +2143,11 @@ static int brcmnand_read(struct mtd_info *mtd, struct
> nand_chip *chip,
> if (mtd_is_bitflip(err)) {
> unsigned int corrected = brcmnand_count_corrected(ctrl);
>
> + /* in case of edu correctable error we read again using pio */
s/edu/EDU/ ?
s/pio/PIO/
> + if (edu_read)
> + err = brcmnand_read_by_pio(mtd, chip, addr, trans, buf,
> +oob, &err_addr);
> +
> dev_dbg(ctrl->dev, "corrected error at 0x%llx\n",
> (unsigned long long)err_addr);
> mtd->ecc_stats.corrected += corrected;
Thanks,
Miquèl
Re: [PATCH] printk/kdb: Redirect printk messages into kdb in any context
On (20/06/10 17:41), Daniel Thompson wrote:
> > Thanks for the link. I'm slightly surprised it took so many years
> > to notice the addition of printk_nmi/printk_safe :)
>
> Rather by coincidence (at least I think its a coincidence) the problem
> has recently become much more obvious.
>
> 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") just brought
> this to the surface by treating debug traps as NMIs. This means the CPU
> that takes a breakpoint, and where almost all of the kdb printk() calls
> take place, will now unconditionally have printk() interception enabled.
Interesting. Feels like ist_enter() should have been using
printk_nmi_enter/exit() in the first place.
-ss
Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On 6/4/20 10:12 AM, Daniel Vetter wrote: Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mmu notifier callbacks (which amdgpu does, and which i915 sometimes also does, and probably always should, but that's kinda a debate). Also for stuff like HMM we really need to be able to do this, or things get real dicey. Consequence is that any critical path necessary to get to a dma_fence_signal for a fence must never a) call dma_resv_lock nor b) allocate memory with GFP_KERNEL. Also by implication of dma_resv_lock(), no userspace faulting allowed. That's some supremely obnoxious limitations, which is why we need to sprinkle the right annotations to all relevant paths. The one big locking context we're leaving out here is mmu notifiers, added in commit 23b68395c7c78a764e8963fc15a7cfd318bf187f Author: Daniel Vetter Date: Mon Aug 26 22:14:21 2019 +0200 mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end that one covers a lot of other callsites, and it's also allowed to wait on dma-fences from mmu notifiers. But there's no ready-made functions exposed to prime this, so I've left it out for now. v2: Also track against mmu notifier context. v3: kerneldoc to spec the cross-driver contract. Note that currently i915 throws in a hard-coded 10s timeout on foreign fences (not sure why that was done, but it's there), which is why that rule is worded with SHOULD instead of MUST. Also some of the mmu_notifier/shrinker rules might surprise SoC drivers, I haven't fully audited them all. Which is infeasible anyway, we'll need to run them with lockdep and dma-fence annotations and see what goes boom. v4: A spelling fix from Mika Cc: Mika Kuoppala Cc: Thomas Hellstrom Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst | 6 drivers/dma-buf/dma-fence.c | 41 drivers/dma-buf/dma-resv.c | 4 +++ include/linux/dma-fence.h| 1 + 4 files changed, 52 insertions(+) I still have my doubts about allowing fence waiting from within shrinkers. IMO ideally they should use a trywait approach, in order to allow memory allocation during command submission for drivers that publish fences before command submission. (Since early reservation object release requires that). But since drivers are already waiting from within shrinkers and I take your word for HMM requiring this, Reviewed-by: Thomas Hellström
[PATCH v4 16/27] clk: bcm: rpi: Rename is_prepared function
The raspberrypi_fw_pll_is_on function doesn't only apply to PLL
registered in the driver, but any clock exposed by the firmware.
Since we also implement the is_prepared hook, make the function
consistent with the other function names.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 3fce49a65a79..58ac1b104429 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -85,7 +85,7 @@ static int raspberrypi_clock_property(struct rpi_firmware
*firmware,
return 0;
}
-static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
+static int raspberrypi_fw_is_prepared(struct clk_hw *hw)
{
struct raspberrypi_clk_data *data =
container_of(hw, struct raspberrypi_clk_data, hw);
@@ -166,7 +166,7 @@ static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
}
static const struct clk_ops raspberrypi_firmware_pll_clk_ops = {
- .is_prepared = raspberrypi_fw_pll_is_on,
+ .is_prepared = raspberrypi_fw_is_prepared,
.recalc_rate = raspberrypi_fw_pll_get_rate,
.set_rate = raspberrypi_fw_pll_set_rate,
.determine_rate = raspberrypi_pll_determine_rate,
--
git-series 0.9.1
[PATCH v4 01/27] dt-bindings: arm: bcm: Convert BCM2835 firmware binding to YAML
From: Florian Fainelli
Convert the Raspberry Pi BCM2835 firmware binding document to YAML.
Verified with dt_binding_check and dtbs_check.
Signed-off-by: Florian Fainelli
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt |
14 --
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml |
35 +++
2 files changed, 35 insertions(+), 14 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
create mode 100644
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
diff --git
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
deleted file mode 100644
index 6824b3180ffb..
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Raspberry Pi VideoCore firmware driver
-
-Required properties:
-
-- compatible: Should be "raspberrypi,bcm2835-firmware"
-- mboxes: Phandle to the firmware device's Mailbox.
- (See: ../mailbox/mailbox.txt for more information)
-
-Example:
-
-firmware {
- compatible = "raspberrypi,bcm2835-firmware";
- mboxes = <&mailbox>;
-};
diff --git
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
new file mode 100644
index ..cec540c052b6
--- /dev/null
+++
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi VideoCore firmware driver
+
+maintainers:
+ - Eric Anholt
+ - Stefan Wahren
+
+properties:
+ compatible:
+items:
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-bus
+
+ mboxes:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description: |
+ Phandle to the firmware device's Mailbox.
+ (See: ../mailbox/mailbox.txt for more information)
+
+required:
+ - compatible
+ - mboxes
+
+examples:
+ - |
+firmware {
+compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
+mboxes = <&mailbox>;
+};
+...
--
git-series 0.9.1
[PATCH v4 02/27] dt-bindings: clock: Add a binding for the RPi Firmware clocks
The firmware running on the RPi VideoCore can be used to discover and
change the various clocks running in the BCM2711. Since devices will
need to use them through the DT, let's add a pretty simple binding.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Reviewed-by: Stephen Boyd
Reviewed-by: Rob Herring
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml |
24
1 file changed, 24 insertions(+)
diff --git
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index cec540c052b6..b48ed875eb8e 100644
---
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -22,6 +22,25 @@ properties:
Phandle to the firmware device's Mailbox.
(See: ../mailbox/mailbox.txt for more information)
+ clocks:
+type: object
+
+properties:
+ compatible:
+const: raspberrypi,firmware-clocks
+
+ "#clock-cells":
+const: 1
+description: >
+ The argument is the ID of the clocks contained by the
+ firmware messages.
+
+required:
+ - compatible
+ - "#clock-cells"
+
+additionalProperties: false
+
required:
- compatible
- mboxes
@@ -31,5 +50,10 @@ examples:
firmware {
compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
mboxes = <&mailbox>;
+
+firmware_clocks: clocks {
+compatible = "raspberrypi,firmware-clocks";
+#clock-cells = <1>;
+};
};
...
--
git-series 0.9.1
[PATCH v4 07/27] clk: bcm: rpi: Remove global pllb_arm clock pointer
The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used
anywhere but in the raspberrypi_register_pllb_arm.
Let's remove it, this will make our lives easier in future patches.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 5f0d4875e145..b21dd6ddc4fe 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -40,7 +40,6 @@ struct raspberrypi_clk {
unsigned long max_rate;
struct clk_hw pllb;
- struct clk_hw *pllb_arm;
struct clk_lookup *pllb_arm_lookup;
};
@@ -246,12 +245,12 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
return ret;
}
- rpi->pllb_arm = &raspberrypi_clk_pllb_arm.hw;
- rpi->pllb_arm_lookup = clkdev_hw_create(rpi->pllb_arm, NULL, "cpu0");
+ rpi->pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
+ NULL, "cpu0");
if (!rpi->pllb_arm_lookup) {
dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
- clk_hw_unregister_fixed_factor(rpi->pllb_arm);
+ clk_hw_unregister_fixed_factor(&raspberrypi_clk_pllb_arm.hw);
return -ENOMEM;
}
--
git-series 0.9.1
[PATCH v4 00/27] clk: bcm: rpi: Add support for BCM2711 firmware clocks
Hi, Since the whole DRM/HDMI support began to grow fairly big, I've chosen to split away the two discussions between the firmware clocks and the HDMI support. Let me know what you think, Maxime Cc: bcm-kernel-feedback-l...@broadcom.com Cc: devicet...@vger.kernel.org Cc: Kamal Dasu Cc: linux-...@vger.kernel.org Cc: Michael Turquette Cc: Rob Herring Cc: Stephen Boyd Changes from v3: - Moved the firmware structure to the driver, and changed for u32 - Prevented cache issues with MMIO driver - Removed message when discovering min and max rates - Added the gathered tags Changes from v2: - Rebased on top of next-20200526 - Split away from the HDMI series - Fixed an of_node leakage in the firmware driver - Fixed an of_node leakage in the firmware clocks driver - Added the min/max rate retrieval to all the firmware clocks - Added proper name for the firmware clocks - Removed the PLLB setup from the firmware clocks and moved it back to the MMIO driver Florian Fainelli (1): dt-bindings: arm: bcm: Convert BCM2835 firmware binding to YAML Maxime Ripard (26): dt-bindings: clock: Add a binding for the RPi Firmware clocks firmware: rpi: Only create clocks device if we don't have a node for it clk: bcm: rpi: Allow the driver to be probed by DT clk: bcm: rpi: Statically init clk_init_data clk: bcm: rpi: Use clk_hw_register for pllb_arm clk: bcm: rpi: Remove global pllb_arm clock pointer clk: bcm: rpi: Make sure pllb_arm is removed clk: bcm: rpi: Remove pllb_arm_lookup global pointer clk: bcm: rpi: Switch to clk_hw_register_clkdev clk: bcm: rpi: Make sure the clkdev lookup is removed clk: bcm: rpi: Use CCF boundaries instead of rolling our own clk: bcm: rpi: Create a data structure for the clocks clk: bcm: rpi: Add clock id to data clk: bcm: rpi: Pass the clocks data to the firmware function clk: bcm: rpi: Rename is_prepared function clk: bcm: rpi: Split pllb clock hooks clk: bcm: rpi: Make the PLLB registration function return a clk_hw clk: bcm: rpi: Add DT provider for the clocks clk: bcm: rpi: Add an enum for the firmware clocks clk: bcm: rpi: Discover the firmware clocks clk: bcm: rpi: Give firmware clocks a name Revert "clk: bcm2835: remove pllb" ARM: dts: bcm2711: Add firmware clocks node clk: bcm2835: Allow custom CCF flags for the PLLs clk: bcm2835: Don't cache the PLLB rate clk: bcm: rpi: Remove the quirks for the CPU clock Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt | 14 +--- Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 59 ++- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 5 +- drivers/clk/bcm/clk-bcm2835.c | 34 ++-- drivers/clk/bcm/clk-raspberrypi.c | 311 +++- drivers/firmware/raspberrypi.c | 14 +++- 6 files changed, 294 insertions(+), 143 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml base-commit: 192e08e14e37b78e83cc2f5b9eb5a15a7d71c4e2 -- git-series 0.9.1
[PATCH v4 03/27] firmware: rpi: Only create clocks device if we don't have a node for it
The firmware clocks driver was previously probed through a platform_device
created by the firmware driver.
Since we will now have a node for that clocks driver, we need to create the
device only in the case where there's no node for it already.
Reviewed-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/firmware/raspberrypi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index ef8098856a47..b25901a77c09 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -208,6 +208,20 @@ rpi_register_hwmon_driver(struct device *dev, struct
rpi_firmware *fw)
static void rpi_register_clk_driver(struct device *dev)
{
+ struct device_node *firmware;
+
+ /*
+* Earlier DTs don't have a node for the firmware clocks but
+* rely on us creating a platform device by hand. If we do
+* have a node for the firmware clocks, just bail out here.
+*/
+ firmware = of_get_compatible_child(dev->of_node,
+ "raspberrypi,firmware-clocks");
+ if (firmware) {
+ of_node_put(firmware);
+ return;
+ }
+
rpi_clk = platform_device_register_data(dev, "raspberrypi-clk",
-1, NULL, 0);
}
--
git-series 0.9.1
[PATCH v4 15/27] clk: bcm: rpi: Pass the clocks data to the firmware function
The raspberry_clock_property only takes the clock ID as an argument, but
now that we have a clock data structure it makes more sense to just pass
that structure instead.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 97ac04604b0a..3fce49a65a79 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -65,11 +65,12 @@ struct raspberrypi_firmware_prop {
__le32 disable_turbo;
} __packed;
-static int raspberrypi_clock_property(struct rpi_firmware *firmware, u32 tag,
- u32 clk, u32 *val)
+static int raspberrypi_clock_property(struct rpi_firmware *firmware,
+ const struct raspberrypi_clk_data *data,
+ u32 tag, u32 *val)
{
struct raspberrypi_firmware_prop msg = {
- .id = cpu_to_le32(clk),
+ .id = cpu_to_le32(data->id),
.val = cpu_to_le32(*val),
.disable_turbo = cpu_to_le32(1),
};
@@ -92,9 +93,8 @@ static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
u32 val = 0;
int ret;
- ret = raspberrypi_clock_property(rpi->firmware,
-RPI_FIRMWARE_GET_CLOCK_STATE,
-data->id, &val);
+ ret = raspberrypi_clock_property(rpi->firmware, data,
+RPI_FIRMWARE_GET_CLOCK_STATE, &val);
if (ret)
return 0;
@@ -111,9 +111,8 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct
clk_hw *hw,
u32 val = 0;
int ret;
- ret = raspberrypi_clock_property(rpi->firmware,
-RPI_FIRMWARE_GET_CLOCK_RATE,
-data->id, &val);
+ ret = raspberrypi_clock_property(rpi->firmware, data,
+RPI_FIRMWARE_GET_CLOCK_RATE, &val);
if (ret)
return ret;
@@ -129,9 +128,9 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
int ret;
- ret = raspberrypi_clock_property(rpi->firmware,
+ ret = raspberrypi_clock_property(rpi->firmware, data,
RPI_FIRMWARE_SET_CLOCK_RATE,
-data->id, &new_rate);
+&new_rate);
if (ret)
dev_err_ratelimited(rpi->dev, "Failed to change %s frequency:
%d",
clk_hw_get_name(hw), ret);
@@ -194,18 +193,18 @@ static int raspberrypi_register_pllb(struct
raspberrypi_clk *rpi)
init.flags = CLK_GET_RATE_NOCACHE | CLK_IGNORE_UNUSED;
/* Get min & max rates set by the firmware */
- ret = raspberrypi_clock_property(rpi->firmware,
+ ret = raspberrypi_clock_property(rpi->firmware, data,
RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
-data->id, &min_rate);
+&min_rate);
if (ret) {
dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
init.name, ret);
return ret;
}
- ret = raspberrypi_clock_property(rpi->firmware,
+ ret = raspberrypi_clock_property(rpi->firmware, data,
RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
-data->id, &max_rate);
+&max_rate);
if (ret) {
dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
init.name, ret);
--
git-series 0.9.1
[PATCH v4 27/27] clk: bcm: rpi: Remove the quirks for the CPU clock
The CPU clock has had so far a bunch of quirks to expose the clock tree
properly, but since we reverted to exposing them through the MMIO driver,
we can remove that code from the firmware driver.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 164 +---
1 file changed, 164 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index adc0bb56008a..5cc82954e1ce 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -56,14 +56,6 @@ static char *rpi_firmware_clk_names[] = {
#define RPI_FIRMWARE_STATE_ENABLE_BIT BIT(0)
#define RPI_FIRMWARE_STATE_WAIT_BITBIT(1)
-/*
- * Even though the firmware interface alters 'pllb' the frequencies are
- * provided as per 'pllb_arm'. We need to scale before passing them trough.
- */
-#define RPI_FIRMWARE_PLLB_ARM_DIV_RATE 2
-
-#define A2W_PLL_FRAC_BITS 20
-
struct raspberrypi_clk {
struct device *dev;
struct rpi_firmware *firmware;
@@ -152,13 +144,6 @@ static unsigned long raspberrypi_fw_get_rate(struct clk_hw
*hw,
return val;
}
-static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
-unsigned long parent_rate)
-{
- return raspberrypi_fw_get_rate(hw, parent_rate) *
- RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
-}
-
static int raspberrypi_fw_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
@@ -177,142 +162,6 @@ static int raspberrypi_fw_set_rate(struct clk_hw *hw,
unsigned long rate,
return ret;
}
-static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long parent_rate)
-{
- u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
-
- return raspberrypi_fw_set_rate(hw, new_rate, parent_rate);
-}
-
-/*
- * Sadly there is no firmware rate rounding interface. We borrowed it from
- * clk-bcm2835.
- */
-static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
- struct clk_rate_request *req)
-{
- u64 div, final_rate;
- u32 ndiv, fdiv;
-
- /* We can't use req->rate directly as it would overflow */
- final_rate = clamp(req->rate, req->min_rate, req->max_rate);
-
- div = (u64)final_rate << A2W_PLL_FRAC_BITS;
- do_div(div, req->best_parent_rate);
-
- ndiv = div >> A2W_PLL_FRAC_BITS;
- fdiv = div & ((1 << A2W_PLL_FRAC_BITS) - 1);
-
- final_rate = ((u64)req->best_parent_rate *
- ((ndiv << A2W_PLL_FRAC_BITS) + fdiv));
-
- req->rate = final_rate >> A2W_PLL_FRAC_BITS;
-
- return 0;
-}
-
-static const struct clk_ops raspberrypi_firmware_pll_clk_ops = {
- .is_prepared = raspberrypi_fw_is_prepared,
- .recalc_rate = raspberrypi_fw_pll_get_rate,
- .set_rate = raspberrypi_fw_pll_set_rate,
- .determine_rate = raspberrypi_pll_determine_rate,
-};
-
-static struct clk_hw *raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
-{
- struct raspberrypi_clk_data *data;
- struct clk_init_data init = {};
- u32 min_rate = 0, max_rate = 0;
- int ret;
-
- data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
- if (!data)
- return ERR_PTR(-ENOMEM);
- data->rpi = rpi;
- data->id = RPI_FIRMWARE_ARM_CLK_ID;
-
- /* All of the PLLs derive from the external oscillator. */
- init.parent_names = (const char *[]){ "osc" };
- init.num_parents = 1;
- init.name = "pllb";
- init.ops = &raspberrypi_firmware_pll_clk_ops;
- init.flags = CLK_GET_RATE_NOCACHE | CLK_IGNORE_UNUSED;
-
- /* Get min & max rates set by the firmware */
- ret = raspberrypi_clock_property(rpi->firmware, data,
-RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
-&min_rate);
- if (ret) {
- dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
- init.name, ret);
- return ERR_PTR(ret);
- }
-
- ret = raspberrypi_clock_property(rpi->firmware, data,
-RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
-&max_rate);
- if (ret) {
- dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
- init.name, ret);
- return ERR_PTR(ret);
- }
-
- if (!min_rate || !max_rate) {
- dev_err(rpi->dev, "Unexpected frequency range: min %u, max
%u\n",
- min_rate, max_rate);
- return ERR_PTR(-EINVAL);
- }
-
- dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
-min_rate, max_rate);
-
- data->hw.init = &init;
-
- ret = devm_clk_hw_register(rpi->dev, &data->hw);
[PATCH v4 17/27] clk: bcm: rpi: Split pllb clock hooks
The driver only supports the pllb for now and all the clock framework hooks
are a mix of the generic firmware interface and the specifics of the pllb.
Since we will support more clocks in the future let's split the generic and
specific hooks
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 58ac1b104429..19571602ba64 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -102,8 +102,8 @@ static int raspberrypi_fw_is_prepared(struct clk_hw *hw)
}
-static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
-unsigned long parent_rate)
+static unsigned long raspberrypi_fw_get_rate(struct clk_hw *hw,
+unsigned long parent_rate)
{
struct raspberrypi_clk_data *data =
container_of(hw, struct raspberrypi_clk_data, hw);
@@ -116,21 +116,27 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct
clk_hw *hw,
if (ret)
return ret;
- return val * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+ return val;
}
-static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long parent_rate)
+static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return raspberrypi_fw_get_rate(hw, parent_rate) *
+ RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+}
+
+static int raspberrypi_fw_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
{
struct raspberrypi_clk_data *data =
container_of(hw, struct raspberrypi_clk_data, hw);
struct raspberrypi_clk *rpi = data->rpi;
- u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+ u32 _rate = rate;
int ret;
ret = raspberrypi_clock_property(rpi->firmware, data,
-RPI_FIRMWARE_SET_CLOCK_RATE,
-&new_rate);
+RPI_FIRMWARE_SET_CLOCK_RATE, &_rate);
if (ret)
dev_err_ratelimited(rpi->dev, "Failed to change %s frequency:
%d",
clk_hw_get_name(hw), ret);
@@ -138,6 +144,14 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return ret;
}
+static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+
+ return raspberrypi_fw_set_rate(hw, new_rate, parent_rate);
+}
+
/*
* Sadly there is no firmware rate rounding interface. We borrowed it from
* clk-bcm2835.
--
git-series 0.9.1
[PATCH v4 19/27] clk: bcm: rpi: Add DT provider for the clocks
For the upcoming registration of the clocks provided by the firmware, make
sure it's exposed to the device tree providers.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index d2cb90c086a7..5f4e2d49432f 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -31,6 +31,8 @@
#define A2W_PLL_FRAC_BITS 20
+#define NUM_FW_CLKS16
+
struct raspberrypi_clk {
struct device *dev;
struct rpi_firmware *firmware;
@@ -282,11 +284,13 @@ static struct clk_hw
*raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
static int raspberrypi_clk_probe(struct platform_device *pdev)
{
+ struct clk_hw_onecell_data *clk_data;
struct device_node *firmware_node;
struct device *dev = &pdev->dev;
struct rpi_firmware *firmware;
struct raspberrypi_clk *rpi;
struct clk_hw *hw;
+ int ret;
/*
* We can be probed either through the an old-fashioned
@@ -316,6 +320,11 @@ static int raspberrypi_clk_probe(struct platform_device
*pdev)
rpi->firmware = firmware;
platform_set_drvdata(pdev, rpi);
+ clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, NUM_FW_CLKS),
+ GFP_KERNEL);
+ if (!clk_data)
+ return -ENOMEM;
+
hw = raspberrypi_register_pllb(rpi);
if (IS_ERR(hw)) {
dev_err(dev, "Failed to initialize pllb, %ld\n", PTR_ERR(hw));
@@ -325,6 +334,13 @@ static int raspberrypi_clk_probe(struct platform_device
*pdev)
hw = raspberrypi_register_pllb_arm(rpi);
if (IS_ERR(hw))
return PTR_ERR(hw);
+ clk_data->hws[RPI_FIRMWARE_ARM_CLK_ID] = hw;
+ clk_data->num = RPI_FIRMWARE_ARM_CLK_ID + 1;
+
+ ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
+ clk_data);
+ if (ret)
+ return ret;
rpi->cpufreq = platform_device_register_data(dev, "raspberrypi-cpufreq",
-1, NULL, 0);
--
git-series 0.9.1
[PATCH v4 23/27] Revert "clk: bcm2835: remove pllb"
This reverts commit 2256d89333bd17b8b56b42734a7e1046d52f7fc3. Since we
will be expanding the firmware clock driver, we'll need to remove the
quirks to deal with the PLLB. However, we still want to expose the clock
tree properly, so having that clock in the MMIO driver will allow that.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-bcm2835.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 6bb7efa12037..32f5c13be9d1 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1684,10 +1684,32 @@ static const struct bcm2835_clk_desc clk_desc_array[] =
{
.fixed_divider = 1,
.flags = CLK_SET_RATE_PARENT),
- /*
-* PLLB is used for the ARM's clock. Controlled by firmware, see
-* clk-raspberrypi.c.
-*/
+ /* PLLB is used for the ARM's clock. */
+ [BCM2835_PLLB] = REGISTER_PLL(
+ SOC_ALL,
+ .name = "pllb",
+ .cm_ctrl_reg = CM_PLLB,
+ .a2w_ctrl_reg = A2W_PLLB_CTRL,
+ .frac_reg = A2W_PLLB_FRAC,
+ .ana_reg_base = A2W_PLLB_ANA0,
+ .reference_enable_mask = A2W_XOSC_CTRL_PLLB_ENABLE,
+ .lock_mask = CM_LOCK_FLOCKB,
+
+ .ana = &bcm2835_ana_default,
+
+ .min_rate = 6u,
+ .max_rate = 30u,
+ .max_fb_rate = BCM2835_MAX_FB_RATE),
+ [BCM2835_PLLB_ARM] = REGISTER_PLL_DIV(
+ SOC_ALL,
+ .name = "pllb_arm",
+ .source_pll = "pllb",
+ .cm_reg = CM_PLLB,
+ .a2w_reg = A2W_PLLB_ARM,
+ .load_mask = CM_PLLB_LOADARM,
+ .hold_mask = CM_PLLB_HOLDARM,
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
/*
* PLLC is the core PLL, used to drive the core VPU clock.
--
git-series 0.9.1
[PATCH v4 14/27] clk: bcm: rpi: Add clock id to data
The driver has really only supported one clock so far and has hardcoded the
ID used in communications with the firmware in all the functions
implementing the clock framework hooks. Let's store that in the clock data
structure so that we can support more clocks later on.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 00735704eabc..97ac04604b0a 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -39,6 +39,9 @@ struct raspberrypi_clk {
struct raspberrypi_clk_data {
struct clk_hw hw;
+
+ unsigned int id;
+
struct raspberrypi_clk *rpi;
};
@@ -91,7 +94,7 @@ static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
ret = raspberrypi_clock_property(rpi->firmware,
RPI_FIRMWARE_GET_CLOCK_STATE,
-RPI_FIRMWARE_ARM_CLK_ID, &val);
+data->id, &val);
if (ret)
return 0;
@@ -110,8 +113,7 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct
clk_hw *hw,
ret = raspberrypi_clock_property(rpi->firmware,
RPI_FIRMWARE_GET_CLOCK_RATE,
-RPI_FIRMWARE_ARM_CLK_ID,
-&val);
+data->id, &val);
if (ret)
return ret;
@@ -129,8 +131,7 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
ret = raspberrypi_clock_property(rpi->firmware,
RPI_FIRMWARE_SET_CLOCK_RATE,
-RPI_FIRMWARE_ARM_CLK_ID,
-&new_rate);
+data->id, &new_rate);
if (ret)
dev_err_ratelimited(rpi->dev, "Failed to change %s frequency:
%d",
clk_hw_get_name(hw), ret);
@@ -183,6 +184,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk
*rpi)
if (!data)
return -ENOMEM;
data->rpi = rpi;
+ data->id = RPI_FIRMWARE_ARM_CLK_ID;
/* All of the PLLs derive from the external oscillator. */
init.parent_names = (const char *[]){ "osc" };
@@ -194,8 +196,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk
*rpi)
/* Get min & max rates set by the firmware */
ret = raspberrypi_clock_property(rpi->firmware,
RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
-RPI_FIRMWARE_ARM_CLK_ID,
-&min_rate);
+data->id, &min_rate);
if (ret) {
dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
init.name, ret);
@@ -204,8 +205,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk
*rpi)
ret = raspberrypi_clock_property(rpi->firmware,
RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
-RPI_FIRMWARE_ARM_CLK_ID,
-&max_rate);
+data->id, &max_rate);
if (ret) {
dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
init.name, ret);
--
git-series 0.9.1
[PATCH v4 21/27] clk: bcm: rpi: Discover the firmware clocks
The RaspberryPi4 firmware actually exposes more clocks than are currently
handled by the driver and we will need to change some of them directly
based on the pixel rate for the display related clocks, or the load for the
GPU.
Since the firmware implements DVFS, this rate change can have a number of
side-effects, including adjusting the various PLL voltages or the PLL
parents. The firmware also implements thermal throttling, so even some
thermal pressure can change those parameters behind Linux back.
DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc
clocks, so updating any of them using the MMIO driver (and thus behind the
firmware's back) can lead to troubles, the arm clock obviously being the
most problematic.
In order to make Linux play as nice as possible with those constraints, it
makes sense to rely on the firmware clocks as much as possible. However,
the firmware doesn't seem to provide some equivalents to their MMIO
counterparts, so we can't really replace that driver entirely.
Fortunately, the firmware has an interface to discover the clocks it
exposes.
Let's use it to discover, register the clocks in the clocks framework and
then expose them through the device tree for consumers to use them.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 153 ---
1 file changed, 141 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index eebd16040f8a..11a62bde5203 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -296,6 +296,144 @@ static struct clk_hw
*raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
return &raspberrypi_clk_pllb_arm.hw;
}
+static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ /*
+* The firmware will do the rounding but that isn't part of
+* the interface with the firmware, so we just do our best
+* here.
+*/
+ req->rate = clamp(req->rate, req->min_rate, req->max_rate);
+ return 0;
+}
+
+static const struct clk_ops raspberrypi_firmware_clk_ops = {
+ .is_prepared= raspberrypi_fw_is_prepared,
+ .recalc_rate= raspberrypi_fw_get_rate,
+ .determine_rate = raspberrypi_fw_dumb_determine_rate,
+ .set_rate = raspberrypi_fw_set_rate,
+};
+
+static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
+ unsigned int parent,
+ unsigned int id)
+{
+ struct raspberrypi_clk_data *data;
+ struct clk_init_data init = {};
+ u32 min_rate, max_rate;
+ int ret;
+
+ if (id == RPI_FIRMWARE_ARM_CLK_ID) {
+ struct clk_hw *hw;
+
+ hw = raspberrypi_register_pllb(rpi);
+ if (IS_ERR(hw)) {
+ dev_err(rpi->dev, "Failed to initialize pllb, %ld\n",
+ PTR_ERR(hw));
+ return hw;
+ }
+
+ return raspberrypi_register_pllb_arm(rpi);
+ }
+
+ data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+ data->rpi = rpi;
+ data->id = id;
+
+ init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);
+ init.ops = &raspberrypi_firmware_clk_ops;
+ init.flags = CLK_GET_RATE_NOCACHE;
+
+ data->hw.init = &init;
+
+ ret = raspberrypi_clock_property(rpi->firmware, data,
+RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
+&min_rate);
+ if (ret) {
+ dev_err(rpi->dev, "Failed to get clock %d min freq: %d",
+ id, ret);
+ return ERR_PTR(ret);
+ }
+
+ ret = raspberrypi_clock_property(rpi->firmware, data,
+RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
+&max_rate);
+ if (ret) {
+ dev_err(rpi->dev, "Failed to get clock %d max freq: %d\n",
+ id, ret);
+ return ERR_PTR(ret);
+ }
+
+ ret = devm_clk_hw_register(rpi->dev, &data->hw);
+ if (ret)
+ return ERR_PTR(ret);
+
+ clk_hw_set_rate_range(&data->hw, min_rate, max_rate);
+
+ if (id == RPI_FIRMWARE_ARM_CLK_ID) {
+ ret = devm_clk_hw_register_clkdev(rpi->dev, &data->hw,
+ NULL, "cpu0");
+ if (ret) {
+ dev_err(rpi->dev, "Failed to initialize clkdev\n");
+ return ERR_PTR(ret);
+ }
+ }
+
+ return &data->hw;
+}
[PATCH v4 12/27] clk: bcm: rpi: Use CCF boundaries instead of rolling our own
The raspberrypi firmware clock driver has a min_rate / max_rate clamping by
storing the info it needs in a private structure.
However, the CCF already provides such a facility, so we can switch to it
to remove the boilerplate.
Reviewed-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index a20492fade6a..e135ad28d38d 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -36,9 +36,6 @@ struct raspberrypi_clk {
struct rpi_firmware *firmware;
struct platform_device *cpufreq;
- unsigned long min_rate;
- unsigned long max_rate;
-
struct clk_hw pllb;
};
@@ -142,13 +139,11 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
{
- struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
- pllb);
u64 div, final_rate;
u32 ndiv, fdiv;
/* We can't use req->rate directly as it would overflow */
- final_rate = clamp(req->rate, rpi->min_rate, rpi->max_rate);
+ final_rate = clamp(req->rate, req->min_rate, req->max_rate);
div = (u64)final_rate << A2W_PLL_FRAC_BITS;
do_div(div, req->best_parent_rate);
@@ -215,12 +210,15 @@ static int raspberrypi_register_pllb(struct
raspberrypi_clk *rpi)
dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
min_rate, max_rate);
- rpi->min_rate = min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
- rpi->max_rate = max_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
-
rpi->pllb.init = &init;
- return devm_clk_hw_register(rpi->dev, &rpi->pllb);
+ ret = devm_clk_hw_register(rpi->dev, &rpi->pllb);
+ if (!ret)
+ clk_hw_set_rate_range(&rpi->pllb,
+ min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE,
+ max_rate *
RPI_FIRMWARE_PLLB_ARM_DIV_RATE);
+
+ return ret;
}
static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
--
git-series 0.9.1
[PATCH v4 20/27] clk: bcm: rpi: Add an enum for the firmware clocks
While the firmware allows us to discover the available clocks, we need to
discriminate those clocks to only register the ones meaningful to Linux.
The firmware also doesn't provide a clock name, so having a list of the ID
will help us to give clocks a proper name later on.
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 5f4e2d49432f..eebd16040f8a 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -18,7 +18,23 @@
#include
-#define RPI_FIRMWARE_ARM_CLK_ID0x0003
+enum rpi_firmware_clk_id {
+ RPI_FIRMWARE_EMMC_CLK_ID = 1,
+ RPI_FIRMWARE_UART_CLK_ID,
+ RPI_FIRMWARE_ARM_CLK_ID,
+ RPI_FIRMWARE_CORE_CLK_ID,
+ RPI_FIRMWARE_V3D_CLK_ID,
+ RPI_FIRMWARE_H264_CLK_ID,
+ RPI_FIRMWARE_ISP_CLK_ID,
+ RPI_FIRMWARE_SDRAM_CLK_ID,
+ RPI_FIRMWARE_PIXEL_CLK_ID,
+ RPI_FIRMWARE_PWM_CLK_ID,
+ RPI_FIRMWARE_HEVC_CLK_ID,
+ RPI_FIRMWARE_EMMC2_CLK_ID,
+ RPI_FIRMWARE_M2MC_CLK_ID,
+ RPI_FIRMWARE_PIXEL_BVB_CLK_ID,
+ RPI_FIRMWARE_NUM_CLK_ID,
+};
#define RPI_FIRMWARE_STATE_ENABLE_BIT BIT(0)
#define RPI_FIRMWARE_STATE_WAIT_BITBIT(1)
@@ -31,8 +47,6 @@
#define A2W_PLL_FRAC_BITS 20
-#define NUM_FW_CLKS16
-
struct raspberrypi_clk {
struct device *dev;
struct rpi_firmware *firmware;
@@ -320,7 +334,8 @@ static int raspberrypi_clk_probe(struct platform_device
*pdev)
rpi->firmware = firmware;
platform_set_drvdata(pdev, rpi);
- clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, NUM_FW_CLKS),
+ clk_data = devm_kzalloc(dev, struct_size(clk_data, hws,
+RPI_FIRMWARE_NUM_CLK_ID),
GFP_KERNEL);
if (!clk_data)
return -ENOMEM;
--
git-series 0.9.1
[PATCH v4 22/27] clk: bcm: rpi: Give firmware clocks a name
We've registered the firmware clocks using their ID as name, but it's much
more convenient to register them using their proper name. Since the
firmware doesn't provide it, we have to duplicate it.
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 11a62bde5203..adc0bb56008a 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -36,6 +36,23 @@ enum rpi_firmware_clk_id {
RPI_FIRMWARE_NUM_CLK_ID,
};
+static char *rpi_firmware_clk_names[] = {
+ [RPI_FIRMWARE_EMMC_CLK_ID] = "emmc",
+ [RPI_FIRMWARE_UART_CLK_ID] = "uart",
+ [RPI_FIRMWARE_ARM_CLK_ID] = "arm",
+ [RPI_FIRMWARE_CORE_CLK_ID] = "core",
+ [RPI_FIRMWARE_V3D_CLK_ID] = "v3d",
+ [RPI_FIRMWARE_H264_CLK_ID] = "h264",
+ [RPI_FIRMWARE_ISP_CLK_ID] = "isp",
+ [RPI_FIRMWARE_SDRAM_CLK_ID] = "sdram",
+ [RPI_FIRMWARE_PIXEL_CLK_ID] = "pixel",
+ [RPI_FIRMWARE_PWM_CLK_ID] = "pwm",
+ [RPI_FIRMWARE_HEVC_CLK_ID] = "hevc",
+ [RPI_FIRMWARE_EMMC2_CLK_ID] = "emmc2",
+ [RPI_FIRMWARE_M2MC_CLK_ID] = "m2mc",
+ [RPI_FIRMWARE_PIXEL_BVB_CLK_ID] = "pixel-bvb",
+};
+
#define RPI_FIRMWARE_STATE_ENABLE_BIT BIT(0)
#define RPI_FIRMWARE_STATE_WAIT_BITBIT(1)
@@ -343,7 +360,9 @@ static struct clk_hw *raspberrypi_clk_register(struct
raspberrypi_clk *rpi,
data->rpi = rpi;
data->id = id;
- init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);
+ init.name = devm_kasprintf(rpi->dev, GFP_KERNEL,
+ "fw-clk-%s",
+ rpi_firmware_clk_names[id]);
init.ops = &raspberrypi_firmware_clk_ops;
init.flags = CLK_GET_RATE_NOCACHE;
--
git-series 0.9.1
[PATCH v4 11/27] clk: bcm: rpi: Make sure the clkdev lookup is removed
The clkdev lookup created for the cpufreq device is never removed if
there's an issue later in probe or at module removal time.
Let's convert to the managed variant of the clk_hw_register_clkdev function
to make sure it happens.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 23f06618a356..a20492fade6a 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -245,8 +245,9 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
return ret;
}
- ret = clk_hw_register_clkdev(&raspberrypi_clk_pllb_arm.hw,
-NULL, "cpu0");
+ ret = devm_clk_hw_register_clkdev(rpi->dev,
+ &raspberrypi_clk_pllb_arm.hw,
+ NULL, "cpu0");
if (ret) {
dev_err(rpi->dev, "Failed to initialize clkdev\n");
return ret;
--
git-series 0.9.1
[PATCH v4 18/27] clk: bcm: rpi: Make the PLLB registration function return a clk_hw
The raspberrypi_register_pllb has been returning an integer so far to
notify whether the functions has exited successfully or not.
However, the OF provider functions in the clock framework require access to
the clk_hw structure so that we can expose those clocks to device tree
consumers.
Since we'll want that for the future clocks, let's return a clk_hw pointer
instead of the return code.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 46
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 19571602ba64..d2cb90c086a7 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -186,7 +186,7 @@ static const struct clk_ops
raspberrypi_firmware_pll_clk_ops = {
.determine_rate = raspberrypi_pll_determine_rate,
};
-static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
+static struct clk_hw *raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
{
struct raspberrypi_clk_data *data;
struct clk_init_data init = {};
@@ -195,7 +195,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk
*rpi)
data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
if (!data)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
data->rpi = rpi;
data->id = RPI_FIRMWARE_ARM_CLK_ID;
@@ -213,7 +213,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk
*rpi)
if (ret) {
dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
init.name, ret);
- return ret;
+ return ERR_PTR(ret);
}
ret = raspberrypi_clock_property(rpi->firmware, data,
@@ -222,13 +222,13 @@ static int raspberrypi_register_pllb(struct
raspberrypi_clk *rpi)
if (ret) {
dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
init.name, ret);
- return ret;
+ return ERR_PTR(ret);
}
if (!min_rate || !max_rate) {
dev_err(rpi->dev, "Unexpected frequency range: min %u, max
%u\n",
min_rate, max_rate);
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
@@ -237,12 +237,14 @@ static int raspberrypi_register_pllb(struct
raspberrypi_clk *rpi)
data->hw.init = &init;
ret = devm_clk_hw_register(rpi->dev, &data->hw);
- if (!ret)
- clk_hw_set_rate_range(&data->hw,
- min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE,
- max_rate *
RPI_FIRMWARE_PLLB_ARM_DIV_RATE);
+ if (ret)
+ return ERR_PTR(ret);
- return ret;
+ clk_hw_set_rate_range(&data->hw,
+ min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE,
+ max_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE);
+
+ return &data->hw;
}
static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
@@ -257,14 +259,14 @@ static struct clk_fixed_factor raspberrypi_clk_pllb_arm =
{
},
};
-static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
+static struct clk_hw *raspberrypi_register_pllb_arm(struct raspberrypi_clk
*rpi)
{
int ret;
ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
if (ret) {
dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
- return ret;
+ return ERR_PTR(ret);
}
ret = devm_clk_hw_register_clkdev(rpi->dev,
@@ -272,10 +274,10 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
NULL, "cpu0");
if (ret) {
dev_err(rpi->dev, "Failed to initialize clkdev\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return &raspberrypi_clk_pllb_arm.hw;
}
static int raspberrypi_clk_probe(struct platform_device *pdev)
@@ -284,7 +286,7 @@ static int raspberrypi_clk_probe(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
struct rpi_firmware *firmware;
struct raspberrypi_clk *rpi;
- int ret;
+ struct clk_hw *hw;
/*
* We can be probed either through the an old-fashioned
@@ -314,15 +316,15 @@ static int raspberrypi_clk_probe(struct platform_device
*pdev)
rpi->firmware = firmware;
platform_set_drvdata(pdev, rpi);
- ret = raspberrypi_register_pllb(rpi);
- if (ret) {
- dev_err(dev, "Failed to initialize pllb, %d\n", ret);
- return ret;
+ hw = raspberrypi_re
[PATCH v4 13/27] clk: bcm: rpi: Create a data structure for the clocks
So far the driver has really only been providing a single clock, and stored
both the data associated to that clock in particular with the data
associated to the "controller".
Since we will change that in the future, let's decouple the clock data from
the provider data.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index e135ad28d38d..00735704eabc 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -35,8 +35,11 @@ struct raspberrypi_clk {
struct device *dev;
struct rpi_firmware *firmware;
struct platform_device *cpufreq;
+};
- struct clk_hw pllb;
+struct raspberrypi_clk_data {
+ struct clk_hw hw;
+ struct raspberrypi_clk *rpi;
};
/*
@@ -80,8 +83,9 @@ static int raspberrypi_clock_property(struct rpi_firmware
*firmware, u32 tag,
static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
{
- struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
- pllb);
+ struct raspberrypi_clk_data *data =
+ container_of(hw, struct raspberrypi_clk_data, hw);
+ struct raspberrypi_clk *rpi = data->rpi;
u32 val = 0;
int ret;
@@ -98,8 +102,9 @@ static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
- struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
- pllb);
+ struct raspberrypi_clk_data *data =
+ container_of(hw, struct raspberrypi_clk_data, hw);
+ struct raspberrypi_clk *rpi = data->rpi;
u32 val = 0;
int ret;
@@ -116,8 +121,9 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct
clk_hw *hw,
static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
- struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
- pllb);
+ struct raspberrypi_clk_data *data =
+ container_of(hw, struct raspberrypi_clk_data, hw);
+ struct raspberrypi_clk *rpi = data->rpi;
u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
int ret;
@@ -168,10 +174,15 @@ static const struct clk_ops
raspberrypi_firmware_pll_clk_ops = {
static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
{
+ struct raspberrypi_clk_data *data;
struct clk_init_data init = {};
u32 min_rate = 0, max_rate = 0;
int ret;
+ data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+ data->rpi = rpi;
/* All of the PLLs derive from the external oscillator. */
init.parent_names = (const char *[]){ "osc" };
@@ -210,11 +221,11 @@ static int raspberrypi_register_pllb(struct
raspberrypi_clk *rpi)
dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
min_rate, max_rate);
- rpi->pllb.init = &init;
+ data->hw.init = &init;
- ret = devm_clk_hw_register(rpi->dev, &rpi->pllb);
+ ret = devm_clk_hw_register(rpi->dev, &data->hw);
if (!ret)
- clk_hw_set_rate_range(&rpi->pllb,
+ clk_hw_set_rate_range(&data->hw,
min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE,
max_rate *
RPI_FIRMWARE_PLLB_ARM_DIV_RATE);
--
git-series 0.9.1
[PATCH v4 08/27] clk: bcm: rpi: Make sure pllb_arm is removed
The pllb_arm clock was created at probe time, but was never removed if
something went wrong later in probe, or if the driver was ever removed from
the system.
Now that we are using clk_hw_register(), we can just use its managed variant
to take care of that for us.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index b21dd6ddc4fe..d62605861028 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -240,7 +240,7 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
{
int ret;
- ret = clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
+ ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
if (ret) {
dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
return ret;
@@ -250,7 +250,6 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
NULL, "cpu0");
if (!rpi->pllb_arm_lookup) {
dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
- clk_hw_unregister_fixed_factor(&raspberrypi_clk_pllb_arm.hw);
return -ENOMEM;
}
--
git-series 0.9.1
[PATCH v4 06/27] clk: bcm: rpi: Use clk_hw_register for pllb_arm
The pllb_arm clock is defined as a fixed factor clock with the pllb
clock as a parent. However, all its configuration is entirely static,
and thus we don't really need to call clk_hw_register_fixed_factor() but
can simply call clk_hw_register() with a static clk_fixed_factor
structure.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index ddc72207212e..5f0d4875e145 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -225,16 +225,28 @@ static int raspberrypi_register_pllb(struct
raspberrypi_clk *rpi)
return devm_clk_hw_register(rpi->dev, &rpi->pllb);
}
+static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
+ .mult = 1,
+ .div = 2,
+ .hw.init = &(struct clk_init_data) {
+ .name = "pllb_arm",
+ .parent_names = (const char *[]){ "pllb" },
+ .num_parents= 1,
+ .ops= &clk_fixed_factor_ops,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ },
+};
+
static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
{
- rpi->pllb_arm = clk_hw_register_fixed_factor(rpi->dev,
- "pllb_arm", "pllb",
- CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
- 1, 2);
- if (IS_ERR(rpi->pllb_arm)) {
+ int ret;
+
+ ret = clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
+ if (ret) {
dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
- return PTR_ERR(rpi->pllb_arm);
+ return ret;
}
+ rpi->pllb_arm = &raspberrypi_clk_pllb_arm.hw;
rpi->pllb_arm_lookup = clkdev_hw_create(rpi->pllb_arm, NULL, "cpu0");
if (!rpi->pllb_arm_lookup) {
--
git-series 0.9.1
[PATCH v4 24/27] ARM: dts: bcm2711: Add firmware clocks node
Now that we have a clock driver for the clocks exposed by the firmware,
let's add the device tree nodes for it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index c7f1d97e69bb..222d7825e1ab 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -69,6 +69,11 @@
};
&firmware {
+ firmware_clocks: clocks {
+ compatible = "raspberrypi,firmware-clocks";
+ #clock-cells = <1>;
+ };
+
expgpio: gpio {
compatible = "raspberrypi,firmware-gpio";
gpio-controller;
--
git-series 0.9.1
[PATCH v4 26/27] clk: bcm2835: Don't cache the PLLB rate
The PLLB rate will be changed through the firmware clocks drivers and will
change behind this drivers' back, so we don't want to cache the rate.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-bcm2835.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 846ea68b2c73..64e23733e6b7 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1700,7 +1700,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.min_rate = 6u,
.max_rate = 30u,
- .max_fb_rate = BCM2835_MAX_FB_RATE),
+ .max_fb_rate = BCM2835_MAX_FB_RATE,
+ .flags = CLK_GET_RATE_NOCACHE),
[BCM2835_PLLB_ARM] = REGISTER_PLL_DIV(
SOC_ALL,
.name = "pllb_arm",
@@ -1710,7 +1711,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLB_LOADARM,
.hold_mask = CM_PLLB_HOLDARM,
.fixed_divider = 1,
- .flags = CLK_SET_RATE_PARENT),
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE),
/*
* PLLC is the core PLL, used to drive the core VPU clock.
--
git-series 0.9.1
[PATCH v4 09/27] clk: bcm: rpi: Remove pllb_arm_lookup global pointer
The pllb_arm_lookup pointer in the struct raspberrypi_clk is not used for
anything but to store the returned pointer to clkdev_hw_create, and is not
used anywhere else in the driver.
Let's remove that global pointer from the structure.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index d62605861028..5a06c4991c7f 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -40,7 +40,6 @@ struct raspberrypi_clk {
unsigned long max_rate;
struct clk_hw pllb;
- struct clk_lookup *pllb_arm_lookup;
};
/*
@@ -238,6 +237,7 @@ static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
{
+ struct clk_lookup *pllb_arm_lookup;
int ret;
ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
@@ -246,9 +246,9 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
return ret;
}
- rpi->pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
- NULL, "cpu0");
- if (!rpi->pllb_arm_lookup) {
+ pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
+ NULL, "cpu0");
+ if (!pllb_arm_lookup) {
dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
return -ENOMEM;
}
--
git-series 0.9.1
[PATCH v4 05/27] clk: bcm: rpi: Statically init clk_init_data
Instead of declaring the clk_init_data and then calling memset on it, just
initialise properly.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 8610355bda47..ddc72207212e 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -175,11 +175,10 @@ static const struct clk_ops
raspberrypi_firmware_pll_clk_ops = {
static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
{
+ struct clk_init_data init = {};
u32 min_rate = 0, max_rate = 0;
- struct clk_init_data init;
int ret;
- memset(&init, 0, sizeof(init));
/* All of the PLLs derive from the external oscillator. */
init.parent_names = (const char *[]){ "osc" };
--
git-series 0.9.1
[PATCH v4 10/27] clk: bcm: rpi: Switch to clk_hw_register_clkdev
Since we don't care about retrieving the clk_lookup structure pointer
returned by clkdev_hw_create, we can just use the clk_hw_register_clkdev
function.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 5a06c4991c7f..23f06618a356 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -237,7 +237,6 @@ static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
{
- struct clk_lookup *pllb_arm_lookup;
int ret;
ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
@@ -246,11 +245,11 @@ static int raspberrypi_register_pllb_arm(struct
raspberrypi_clk *rpi)
return ret;
}
- pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
- NULL, "cpu0");
- if (!pllb_arm_lookup) {
- dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
- return -ENOMEM;
+ ret = clk_hw_register_clkdev(&raspberrypi_clk_pllb_arm.hw,
+NULL, "cpu0");
+ if (ret) {
+ dev_err(rpi->dev, "Failed to initialize clkdev\n");
+ return ret;
}
return 0;
--
git-series 0.9.1
[PATCH v4 25/27] clk: bcm2835: Allow custom CCF flags for the PLLs
While some clock types allow for each clock to specify its own custom
flags, the PLLs can't. We will need this for the PLLB, so let's add it.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-bcm2835.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 32f5c13be9d1..846ea68b2c73 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -421,6 +421,7 @@ struct bcm2835_pll_data {
u32 reference_enable_mask;
/* Bit in CM_LOCK to indicate when the PLL has locked. */
u32 lock_mask;
+ u32 flags;
const struct bcm2835_pll_ana_bits *ana;
@@ -1310,7 +1311,7 @@ static struct clk_hw *bcm2835_register_pll(struct
bcm2835_cprman *cprman,
init.num_parents = 1;
init.name = pll_data->name;
init.ops = &bcm2835_pll_clk_ops;
- init.flags = CLK_IGNORE_UNUSED;
+ init.flags = data->flags | CLK_IGNORE_UNUSED;
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
--
git-series 0.9.1
[PATCH v4 04/27] clk: bcm: rpi: Allow the driver to be probed by DT
The current firmware clock driver for the RaspberryPi can only be probed by
manually registering an associated platform_device.
While this works fine for cpufreq where the device gets attached a clkdev
lookup, it would be tedious to maintain a table of all the devices using
one of the clocks exposed by the firmware.
Since the DT on the other hand is the perfect place to store those
associations, make the firmware clocks driver probe-able through the device
tree so that we can represent it as a node.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Reviewed-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index 1654fd0eedc9..8610355bda47 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -255,8 +255,16 @@ static int raspberrypi_clk_probe(struct platform_device
*pdev)
struct raspberrypi_clk *rpi;
int ret;
- firmware_node = of_find_compatible_node(NULL, NULL,
- "raspberrypi,bcm2835-firmware");
+ /*
+* We can be probed either through the an old-fashioned
+* platform device registration or through a DT node that is a
+* child of the firmware node. Handle both cases.
+*/
+ if (dev->of_node)
+ firmware_node = of_get_parent(dev->of_node);
+ else
+ firmware_node = of_find_compatible_node(NULL, NULL,
+
"raspberrypi,bcm2835-firmware");
if (!firmware_node) {
dev_err(dev, "Missing firmware node\n");
return -ENOENT;
@@ -300,9 +308,16 @@ static int raspberrypi_clk_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id raspberrypi_clk_match[] = {
+ { .compatible = "raspberrypi,firmware-clocks" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, raspberrypi_clk_match);
+
static struct platform_driver raspberrypi_clk_driver = {
.driver = {
.name = "raspberrypi-clk",
+ .of_match_table = raspberrypi_clk_match,
},
.probe = raspberrypi_clk_probe,
.remove = raspberrypi_clk_remove,
--
git-series 0.9.1
Re: [PATCH v6 11/12] PCI: qcom: Add Force GEN1 support
Hi Ansuel,
Sorry that I didn't make this comment earlier.
The subject and description are misleading. The patch itself is not
forcing anything (the DT is filling the gen to 1), so please fix that.
On 6/10/20 7:06 PM, Ansuel Smith wrote:
> From: Sham Muthayyan
>
> Add Force GEN1 support needed in some ipq8064 board that needs to limit
> some PCIe line to gen1 for some hardware limitation. This is set by the
> max-link-speed binding and needed by some soc based on ipq8064. (for
> example Netgear R7800 router)
>
> Signed-off-by: Sham Muthayyan
> Signed-off-by: Ansuel Smith
> Reviewed-by: Rob Herring
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> index 259b627bf890..c40921589122 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -27,6 +27,7 @@
> #include
> #include
>
> +#include "../../pci.h"
> #include "pcie-designware.h"
>
> #define PCIE20_PARF_SYS_CTRL 0x00
> @@ -99,6 +100,8 @@
> #define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE 0x358
> #define SLV_ADDR_SPACE_SZ0x1000
>
> +#define PCIE20_LNK_CONTROL2_LINK_STATUS2 0xa0
> +
> #define DEVICE_TYPE_RC 0x4
>
> #define QCOM_PCIE_2_1_0_MAX_SUPPLY 3
> @@ -195,6 +198,7 @@ struct qcom_pcie {
> struct phy *phy;
> struct gpio_desc *reset;
> const struct qcom_pcie_ops *ops;
> + int gen;
> };
>
> #define to_qcom_pcie(x) dev_get_drvdata((x)->dev)
> @@ -395,6 +399,11 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> /* wait for clock acquisition */
> usleep_range(1000, 1500);
>
> + if (pcie->gen == 1) {
> + val = readl(pci->dbi_base + PCIE20_LNK_CONTROL2_LINK_STATUS2);
> + val |= PCI_EXP_LNKSTA_CLS_2_5GB;
> + writel(val, pci->dbi_base + PCIE20_LNK_CONTROL2_LINK_STATUS2);
> + }
>
> /* Set the Max TLP size to 2K, instead of using default of 4K */
> writel(CFG_REMOTE_RD_REQ_BRIDGE_SIZE_2K,
> @@ -1397,6 +1406,10 @@ static int qcom_pcie_probe(struct platform_device
> *pdev)
> goto err_pm_runtime_put;
> }
>
> + pcie->gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> + if (pcie->gen < 0)
> + pcie->gen = 2;
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "parf");
> pcie->parf = devm_ioremap_resource(dev, res);
> if (IS_ERR(pcie->parf)) {
>
--
regards,
Stan
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Lontium vendor prefix
Add prefix for Lontium Semiconductor Corporation Acked-by: Rob Herring Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index d3891386d671..7294852bc47b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -579,6 +579,8 @@ patternProperties: description: Logic Technologies Limited "^longcheer,.*": description: Longcheer Technology (Shanghai) Co., Ltd. + "^lontium,.*": +description: Lontium Semiconductor Corporation "^loongson,.*": description: Loongson Technology Corporation Limited "^lsi,.*": -- 2.26.2
[PATCH v2 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/lontium-lt9611.c | 1219 +++
3 files changed, 1233 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index aaed2347ace9..5cac15ce2027 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -38,6 +38,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT9611
+ tristate "Lontium LT9611 DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611 DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 6fb062b5b0f0..d2a696e8ca5d 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611) += lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
new file mode 100644
index ..228da63e0854
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -0,0 +1,1219 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_SEG_SIZE 256
+#define EDID_LEN 32
+#define EDID_LOOP 8
+#define KEY_DDC_ACCS_DONE 0x02
+#define DDC_NO_ACK 0x50
+
+#define LT9611_4LANES 0
+
+struct lt9611 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct regmap *regmap;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ bool ac_mode;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool power_on;
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ enum drm_connector_status status;
+
+ u8 edid_buf[EDID_SEG_SIZE];
+ u32 vic;
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0x85ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611_ranges),
+};
+
+struct lt9611_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611_mode lt9611_modes[] = {
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611, bridge);
+}
+
+static struct lt9611 *connector_to_lt9611(struct drm_connector *connector)
+{
+ return container_of(connector, struct lt9611, connector);
+}
+
+static int lt9611_mipi_input_analog(struct lt9611 *lt9611)
+{
+ const struct reg_sequenc
[PATCH v2 0/3] Add LT9611 DSI to HDMI bridge
Hi, This series adds driver and bindings for Lontium LT9611 bridge chip which takes MIPI DSI as input and HDMI as output. This chip can be found in 96boards RB3 platform [1] commonly called DB845c. [1]: https://www.96boards.org/product/rb3-platform/ Changes in v2: - Add acks by Rob - Fix comments reported by Emil and rename the file to lontium-lt9611.c - Fix comments reported by Laurent on binding and driver - Add HDMI audio support Vinod Koul (3): dt-bindings: vendor-prefixes: Add Lontium vendor prefix dt-bindings: display: bridge: Add documentation for LT9611 drm/bridge: Introduce LT9611 DSI to HDMI bridge .../display/bridge/lontium,lt9611.yaml| 176 +++ .../devicetree/bindings/vendor-prefixes.yaml |2 + drivers/gpu/drm/bridge/Kconfig| 13 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/lontium-lt9611.c | 1219 + 5 files changed, 1411 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c -- 2.26.2
[PATCH v2 2/3] dt-bindings: display: bridge: Add documentation for LT9611
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Reviewed-by: Rob Herring
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
new file mode 100644
index ..d60208359234
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT9611 2 Port MIPI to HDMI Bridge
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ The LT9611 is a bridge device which converts DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt9611
+
+ reg:
+maxItems: 1
+
+ "#sound-dai-cells":
+const: 1
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ vdd-supply:
+description: Regulator for 1.8V MIPI phy power.
+
+ vcc-supply:
+description: Regulator for 3.3V IO power.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ Primary MIPI port-1 for MIPI input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@1:
+type: object
+description: |
+ Additional MIPI port-2 for MIPI input, used in combination
+ with primary MIPI port-1 to drive higher resolution displays
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@2:
+type: object
+description: |
+ HDMI port for HDMI output
+
+properties:
+ reg:
+const: 2
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+ - vcc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@3b {
+compatible = "lontium,lt9611";
+reg = <0x3b>;
+
+reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
+interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
+
+vdd-supply = <<9611_1v8>;
+vcc-supply = <<9611_3v3>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+lt9611_a: endpoint {
+ remote-endpoint = <&dsi0_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+lt9611_b: endpoint {
+ remote-endpoint = <&dsi1_out>;
+};
+ };
+
+ port@2 {
+reg = <2>;
+lt9611_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+};
+ };
+};
+ };
+};
+
+...
--
2.26.2
Re: [PATCH] arch/x86: reset MXCSR to default in kernel_fpu_begin()
Hi, > How about putting the file you frob in > /sys/kernel/debug/selftest_helpers/something_or_other. The idea would > be that /sys/kernel/debug/selftest_helpers would be a general place > for kernel helpers needed to make selftests work. Seems like this is the consensus for now. Any opinions on whether the module should remove "selftest_helpers" directory on unloading, or not? 1) Removing would break if other test modules will use the same dir. 2) Not removing will leave the directory dangling. 3) Remove only if empty is one option, though I'm unsure how to cleanly check if debugfs directory is empty. 4) E.g. /sys/kernel/debug/x86/ is created centrally and a symbol is exported for its dentry. But I'm not sure if it really makes sense to add another exported symbol just for selftest_helpers. -- Petteri
Re: Re: [PATCH v4 0/2] Recommend denylist/allowlist instead of blacklist/whitelist
On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches wrote: > On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote: > > From: SeongJae Park > > > > This patchset 1) adds support of deprecated terms in the 'checkpatch.pl' > > and 2) set the 'blacklist' and 'whitelist' as deprecated with > > replacement suggestion of 'denylist' and 'allowlist', because the > > suggestions are incontrovertible, doesn't make people hurt, and more > > self-explanatory. > > While the checkpatch implementation is better, > I'm still very "meh" about the whole concept. I can understand your concerns about politic things in the second patch. However, the concept of the 'deprecated terms' in the first patch is not political but applicable to the general cases. We already had the commits[1] for a similar case. So, could you ack for at least the first patch? [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs Thanks, SeongJae Park
Re: [PATCH 1/2] xhci: Suspend ports to U3 directly from U1 or U2
> On Jun 10, 2020, at 23:58, Mathias Nyman
> wrote:
>
> On 10.6.2020 18.43, Kai-Heng Feng wrote:
>>
>>
>>> On Jun 10, 2020, at 22:32, Alan Stern wrote:
>>>
>>> On Wed, Jun 10, 2020 at 02:42:30PM +0800, Kai-Heng Feng wrote:
xHCI spec "4.15.1 Port Suspend" states that port can be put to U3 as long
as Enabled bit is set and from U0, U1 or U2 state.
Currently only USB_PORT_FEAT_LINK_STATE puts port to U3 directly, let's
do the same for USB_PORT_FEAT_SUSPEND and bus suspend case.
This is particularly useful for USB2 devices, which may take a very long
time to switch USB2 LPM on and off.
>>>
>>> Have these two patches been tested with a variety of USB-2.0 and USB-2.1
>>> devices?
>>
>> I tested some laptops around and they work fine.
>> Only internally connected USB devices like USB Bluetooth and USB Camera have
>> USB2 LPM enabled, so this patch won't affect external connected devices.
>>
>
> Took a fresh look at the USB2 side and it's not as clear as the USB3 case,
> where
> we know the hub must support transition to U3 from any other state. [1]
>
> Supporting link state transition to U3 (USB2 L2) from any other U state for
> USB2 seems
> to be xHCI specific feature. xHC hardware will make sure it goes via the U0
> state.
>
> I have no clue about other hosts (or hubs), USB2 LPM ECN just shows that link
> state transitions to L1 or L2 should always goes via L0.
> It's possible this has to be done in software by disabling USB2 LPM before
> suspending the device.
Is there any host or hub other than xHCI support USB2 LPM? Seem like only xHCI
implements it.
>
> So I guess the original suggestion to wait for link state to reach U0 before
> is a better solution. Sorry about my hasty suggestion.
>
> Kai-Heng, does it help if you fist manually set the link to U0 before
> disabling
> USB2 LPM (set PLS to 0 before clearing the HLE bit). Does it transition to U0
> any faster, or get rid of the extra port event with PLC:U0?
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 03b64b73eb99..0b8db13e79e4 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4385,7 +4385,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_port **ports;
__le32 __iomem *pm_addr, *hlpm_addr;
- u32 pm_val, hlpm_val, field;
+ u32 portsc, pm_val, hlpm_val, field;
unsigned intport_num;
unsigned long flags;
int hird, exit_latency;
@@ -4463,6 +4463,15 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd
*hcd,
/* flush write */
readl(pm_addr);
} else {
+ portsc = readl(ports[port_num]->addr);
+ if ((portsc & PORT_PE) && ((portsc & PORT_PLS_MASK) == XDEV_U1
||
+ (portsc & PORT_PLS_MASK) == XDEV_U2)) {
+ xhci_set_link_state(xhci, ports[port_num], XDEV_U0);
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ dev_info(&udev->dev, "DEBUG: SLEEP\n");
+ msleep(100);
+ spin_lock_irqsave(&xhci->lock, flags);
+ }
pm_val &= ~(PORT_HLE | PORT_RWE | PORT_HIRD_MASK |
PORT_L1DS_MASK);
writel(pm_val, pm_addr);
/* flush write */
If there's a long enough delay for U0 before clearing HLE, then the PLC can be
avoided.
It's not any faster though.
Kai-Heng
>
> -Mathias
>
>
> [1]
>USB3.1 spec (10.16.2.10) Set Port feature:
> "If the value is 3, then host software wants to selectively suspend the
>device connected to this port. The hub shall transition the link to U3
>from any of the other U states using allowed link state transitions.
>If the port is not already in the U0 state, then it shall transition the
>port to the U0 state and then initiate the transition to U3.
Re: [PATCH 14/21] KVM: Move x86's version of struct kvm_mmu_memory_cache to common code
Hi Sean, On 2020-06-05 22:38, Sean Christopherson wrote: Move x86's 'struct kvm_mmu_memory_cache' to common code in anticipation of moving the entire x86 implementation code to common KVM and reusing it for arm64 and MIPS. Add a new architecture specific asm/kvm_types.h to control the existence and parameters of the struct. The new header is needed to avoid a chicken-and-egg problem with asm/kvm_host.h as all architectures define instances of the struct in their vCPU structs. Suggested-by: Christoffer Dall Signed-off-by: Sean Christopherson --- arch/arm64/include/asm/kvm_types.h | 6 ++ arch/mips/include/asm/kvm_types.h| 5 + arch/powerpc/include/asm/kvm_types.h | 5 + arch/s390/include/asm/kvm_types.h| 5 + arch/x86/include/asm/kvm_host.h | 13 - arch/x86/include/asm/kvm_types.h | 7 +++ include/linux/kvm_types.h| 19 +++ 7 files changed, 47 insertions(+), 13 deletions(-) create mode 100644 arch/arm64/include/asm/kvm_types.h create mode 100644 arch/mips/include/asm/kvm_types.h create mode 100644 arch/powerpc/include/asm/kvm_types.h create mode 100644 arch/s390/include/asm/kvm_types.h create mode 100644 arch/x86/include/asm/kvm_types.h diff --git a/arch/arm64/include/asm/kvm_types.h b/arch/arm64/include/asm/kvm_types.h new file mode 100644 index ..d0987007d581 --- /dev/null +++ b/arch/arm64/include/asm/kvm_types.h @@ -0,0 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_ARM64_KVM_TYPES_H +#define _ASM_ARM64_KVM_TYPES_H + +#endif /* _ASM_ARM64_KVM_TYPES_H */ + diff --git a/arch/mips/include/asm/kvm_types.h b/arch/mips/include/asm/kvm_types.h new file mode 100644 index ..5efeb32a5926 --- /dev/null +++ b/arch/mips/include/asm/kvm_types.h @@ -0,0 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_MIPS_KVM_TYPES_H +#define _ASM_MIPS_KVM_TYPES_H + +#endif /* _ASM_MIPS_KVM_TYPES_H */ diff --git a/arch/powerpc/include/asm/kvm_types.h b/arch/powerpc/include/asm/kvm_types.h new file mode 100644 index ..f627eceaa314 --- /dev/null +++ b/arch/powerpc/include/asm/kvm_types.h @@ -0,0 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_KVM_TYPES_H +#define _ASM_POWERPC_KVM_TYPES_H + +#endif /* _ASM_POWERPC_KVM_TYPES_H */ diff --git a/arch/s390/include/asm/kvm_types.h b/arch/s390/include/asm/kvm_types.h new file mode 100644 index ..b66a81f8a354 --- /dev/null +++ b/arch/s390/include/asm/kvm_types.h @@ -0,0 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_S390_KVM_TYPES_H +#define _ASM_S390_KVM_TYPES_H + +#endif /* _ASM_S390_KVM_TYPES_H */ Instead of carrying an empty include file for at least two of the architectures (s390 and Power), how about having it in asm-generic, and updating arch/$ARCH/include/asm/Kbuild to point to the generic one? Thanks, M. -- Jazz is not dead. It just smells funny...
[PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
The header file linux/uio.h includes crypto/hash.h which pulls in
most of the Crypto API. Since linux/uio.h is used throughout the
kernel this means that every tiny bit of change to the Crypto API
causes the entire kernel to get rebuilt.
This patch fixes this by moving it into lib/iov_iter.c instead
where it is actually used.
This patch also fixes the ifdef to use CRYPTO_HASH instead of just
CRYPTO which does not guarantee the existence of ahash.
Finally the prototype of the function has been changed to avoid
the unnecessary use of a void pointer.
Signed-off-by: Herbert Xu
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 9576fd8158d7..67a8ffd31ad8 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -7,9 +7,9 @@
#include
#include
-#include
#include
+struct ahash_request;
struct page;
struct pipe_inode_info;
@@ -264,7 +264,7 @@ static inline void iov_iter_reexpand(struct iov_iter *i,
size_t count)
size_t csum_and_copy_to_iter(const void *addr, size_t bytes, void *csump,
struct iov_iter *i);
size_t csum_and_copy_from_iter(void *addr, size_t bytes, __wsum *csum, struct
iov_iter *i);
bool csum_and_copy_from_iter_full(void *addr, size_t bytes, __wsum *csum,
struct iov_iter *i);
-size_t hash_and_copy_to_iter(const void *addr, size_t bytes, void *hashp,
+size_t hash_and_copy_to_iter(const void *addr, size_t bytes, struct
ahash_request *hash,
struct iov_iter *i);
ssize_t import_iovec(int type, const struct iovec __user * uvector,
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 51595bf3af85..ac537111dcc6 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include
#include
#include
#include
@@ -1563,11 +1564,10 @@ size_t csum_and_copy_to_iter(const void *addr, size_t
bytes, void *csump,
}
EXPORT_SYMBOL(csum_and_copy_to_iter);
-size_t hash_and_copy_to_iter(const void *addr, size_t bytes, void *hashp,
+size_t hash_and_copy_to_iter(const void *addr, size_t bytes, struct
ahash_request *hash,
struct iov_iter *i)
{
-#ifdef CONFIG_CRYPTO
- struct ahash_request *hash = hashp;
+#ifdef CONFIG_CRYPTO_HASH
struct scatterlist sg;
size_t copied;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: possible deadlock in send_sigio
On Thu, Jun 11, 2020 at 4:33 AM Waiman Long wrote:
>
> On 4/4/20 1:55 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15f39c5de0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=91b674b8f0368e69
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a9fb1457d720a55d6dc5
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1454c3b7e0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a22ac7e0
> >
> > The bug was bisected to:
> >
> > commit 7bc3e6e55acf065500a24621f3b313e7e5998acf
> > Author: Eric W. Biederman
> > Date: Thu Feb 20 00:22:26 2020 +
> >
> > proc: Use a list of inodes to flush from proc
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=165c4acde0
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=155c4acde0
> > console output: https://syzkaller.appspot.com/x/log.txt?x=115c4acde0
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+a9fb1457d720a55d6...@syzkaller.appspotmail.com
> > Fixes: 7bc3e6e55acf ("proc: Use a list of inodes to flush from proc")
> >
> >
> > WARNING: possible irq lock inversion dependency detected
> > 5.6.0-syzkaller #0 Not tainted
> >
> > ksoftirqd/0/9 just changed the state of lock:
> > 898090d8 (tasklist_lock){.+.?}-{2:2}, at: send_sigio+0xa9/0x340
> > fs/fcntl.c:800
> > but this lock took another, SOFTIRQ-unsafe lock in the past:
> > (&pid->wait_pidfd){+.+.}-{2:2}
> >
> >
> > and interrupts could create inverse lock ordering between them.
> >
> >
> > other info that might help us debug this:
> > Possible interrupt unsafe locking scenario:
> >
> > CPU0CPU1
> >
> >lock(&pid->wait_pidfd);
> > local_irq_disable();
> > lock(tasklist_lock);
> > lock(&pid->wait_pidfd);
> >
> > lock(tasklist_lock);
> >
> > *** DEADLOCK ***
>
> That is a false positive. The qrwlock has the special property that it
> becomes unfair (for read lock) at interrupt context. So unless it is
> taking a write lock in the interrupt context, it won't go into deadlock.
> The current lockdep code does not capture the full semantics of qrwlock
> leading to this false positive.
Hi Longman
Thanks for looking into this.
Now the question is: how should we change lockdep annotations to fix this bug?
Re: Linux 4.4.227
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index f97d1aaec1f9..e9f9ce0688bc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -279,6 +279,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do not impact performance of sibling logical +processors memory accesses. The opt-out mechanism does not affect Intel SGX +enclaves (including execution of RDRAND or RDSEED inside an enclave, as well +as EGETKEY execution). + +IA32_MCU_OPT_CTRL MSR Definition + +Along with the mitigation for this issue, Intel added a new thread-scope +IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and +RNG
Linux 4.4.227
I'm announcing the release of the 4.4.227 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu |1 Documentation/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/kernel-parameters.txt | 20 + Makefile|2 arch/arc/kernel/setup.c |5 arch/s390/kernel/mcount.S |1 arch/x86/include/asm/acpi.h |2 arch/x86/include/asm/cpu_device_id.h| 27 + arch/x86/include/asm/cpufeatures.h |2 arch/x86/include/asm/msr-index.h|4 arch/x86/include/asm/processor.h|2 arch/x86/kernel/amd_nb.c|2 arch/x86/kernel/asm-offsets_32.c|2 arch/x86/kernel/cpu/amd.c | 26 - arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/centaur.c |4 arch/x86/kernel/cpu/common.c| 62 +++- arch/x86/kernel/cpu/cpu.h |1 arch/x86/kernel/cpu/cyrix.c |2 arch/x86/kernel/cpu/intel.c | 20 - arch/x86/kernel/cpu/match.c |7 arch/x86/kernel/cpu/microcode/intel.c |4 arch/x86/kernel/cpu/mtrr/generic.c |2 arch/x86/kernel/cpu/mtrr/main.c |4 arch/x86/kernel/cpu/perf_event_intel.c |2 arch/x86/kernel/cpu/perf_event_intel_lbr.c |2 arch/x86/kernel/cpu/perf_event_p6.c |2 arch/x86/kernel/cpu/proc.c |4 arch/x86/kernel/head_32.S |4 arch/x86/kernel/mpparse.c |2 arch/x86/mm/mmio-mod.c |4 drivers/base/cpu.c |8 drivers/char/hw_random/via-rng.c|2 drivers/cpufreq/acpi-cpufreq.c |2 drivers/cpufreq/longhaul.c |6 drivers/cpufreq/p4-clockmod.c |2 drivers/cpufreq/powernow-k7.c |2 drivers/cpufreq/speedstep-centrino.c|4 drivers/cpufreq/speedstep-lib.c |6 drivers/crypto/padlock-aes.c|2 drivers/edac/amd64_edac.c |2 drivers/edac/mce_amd.c |2 drivers/hwmon/coretemp.c|6 drivers/hwmon/hwmon-vid.c |2 drivers/hwmon/k10temp.c |2 drivers/hwmon/k8temp.c |2 drivers/iio/light/vcnl4000.c|6 drivers/infiniband/hw/mlx4/mr.c |7 drivers/net/can/slcan.c |3 drivers/net/ethernet/apple/bmac.c |2 drivers/net/ethernet/freescale/ucc_geth.c | 13 drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 13 drivers/net/ppp/pppoe.c |3 drivers/net/slip/slip.c |3 drivers/nfc/st21nfca/dep.c |4 drivers/platform/x86/acer-wmi.c |9 drivers/scsi/scsi_devinfo.c | 23 - drivers/scsi/ufs/ufshcd.c |1 drivers/spi/spi-dw.c|3 drivers/staging/rtl8712/wifi.h |9 drivers/tty/vt/keyboard.c | 26 + drivers/usb/gadget/function/f_uac2.c|4 drivers/usb/serial/option.c
Linux 4.9.227
I'm announcing the release of the 4.9.227 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu |1 Documentation/hw-vuln/index.rst |3 Documentation/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/kernel-parameters.txt | 20 + Makefile|2 arch/arc/kernel/setup.c |5 arch/s390/kernel/mcount.S |1 arch/x86/include/asm/cpu_device_id.h| 27 + arch/x86/include/asm/cpufeatures.h | 30 +- arch/x86/include/asm/msr-index.h|4 arch/x86/include/asm/pgtable.h |1 arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/common.c| 54 ++- arch/x86/kernel/cpu/cpu.h |1 arch/x86/kernel/cpu/match.c |7 arch/x86/mm/mmio-mod.c |4 drivers/base/cpu.c |8 drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c|8 drivers/iio/light/vcnl4000.c|6 drivers/net/can/slcan.c |3 drivers/net/ethernet/apple/bmac.c |2 drivers/net/ethernet/freescale/ucc_geth.c | 13 drivers/net/ethernet/smsc/smsc911x.c|9 drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 13 drivers/net/ppp/pppoe.c |3 drivers/net/slip/slip.c |3 drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/cisco/airo.c | 12 drivers/net/wireless/intersil/p54/p54usb.c |1 drivers/nfc/st21nfca/dep.c |4 drivers/nvmem/qfprom.c | 14 drivers/scsi/scsi_devinfo.c | 23 - drivers/scsi/ufs/ufshcd.c |1 drivers/spi/spi-dw.c|3 drivers/staging/rtl8712/wifi.h |9 drivers/tty/hvc/hvc_console.c | 23 - drivers/tty/vt/keyboard.c | 26 + drivers/usb/gadget/function/f_uac2.c|4 drivers/usb/musb/musb_debugfs.c | 10 drivers/usb/serial/option.c |4 drivers/usb/serial/qcserial.c |1 drivers/usb/serial/usb_wwan.c |4 include/linux/mod_devicetable.h |6 include/uapi/linux/mmc/ioctl.h |1 kernel/events/uprobes.c | 14 kernel/relay.c |5 mm/mremap.c |2 net/ipv4/devinet.c |1 net/ipv6/esp6.c |4 net/l2tp/l2tp_core.c|2 net/l2tp/l2tp_ip.c | 29 + net/l2tp/l2tp_ip6.c | 30 +- net/vmw_vsock/af_vsock.c|2 53 files changed, 584 insertions(+), 135 deletions(-) Ben Hutchings (1): slcan: Fix double-free on slcan_open() error path Bin Liu (1): USB: serial: usb_wwan: do not resubmit rx urb on fatal errors Can Guo (1): scsi: ufs: Release clock if DMA map fails Chuhong Yuan (1): NFC: st21nfca: add missed kfree_skb() in an error path Dan Carpenter (1): airo: Fix read overflows sending packets Daniel Axtens (1): kernel/relay.c: handle alloc_percpu returning NULL in relay_open Daniele Palmas (2): net: usb: qmi_wwan: add Telit LE910C1-EUX composition USB: serial: option: add Telit LE910C1-EUX compositions Dinghao Liu (2): ne
Re: Linux 4.14.184
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 9ebca6a750f3..5abe1cc9f068 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -381,6 +381,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index 0795e3c2643f..ca4dbdd9016d 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -14,3 +14,4 @@ are configurable at compile, boot or run time. mds tsx_async_abort multihit.rst + special-register-buffer-data-sampling.rst diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do n
Linux 4.14.184
I'm announcing the release of the 4.14.184 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 149 ++ Documentation/admin-guide/kernel-parameters.txt | 20 + Makefile| 2 arch/arc/kernel/setup.c | 5 arch/arc/plat-eznps/Kconfig | 1 arch/s390/kernel/mcount.S | 1 arch/x86/include/asm/cpu_device_id.h| 27 + arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/msr-index.h| 4 arch/x86/include/asm/pgtable.h | 1 arch/x86/kernel/cpu/bugs.c | 106 +++ arch/x86/kernel/cpu/common.c| 54 ++- arch/x86/kernel/cpu/cpu.h | 1 arch/x86/kernel/cpu/match.c | 7 arch/x86/mm/mmio-mod.c | 4 drivers/base/cpu.c | 8 drivers/hid/hid-sony.c | 17 + drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c| 8 drivers/i2c/busses/i2c-altera.c | 10 drivers/iio/light/vcnl4000.c| 6 drivers/net/ethernet/apple/bmac.c | 2 drivers/net/ethernet/freescale/ucc_geth.c | 13 drivers/net/ethernet/smsc/smsc911x.c| 9 drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 13 drivers/net/ppp/pppoe.c | 3 drivers/net/usb/qmi_wwan.c | 1 drivers/net/wireless/cisco/airo.c | 12 drivers/net/wireless/intersil/p54/p54usb.c | 1 drivers/nfc/st21nfca/dep.c | 4 drivers/nvdimm/btt.c| 8 drivers/nvdimm/namespace_devs.c | 7 drivers/nvmem/qfprom.c | 14 drivers/scsi/hisi_sas/hisi_sas_main.c | 3 drivers/scsi/scsi_devinfo.c | 23 - drivers/scsi/ufs/ufshcd.c | 1 drivers/spi/spi-dw.c| 3 drivers/staging/rtl8712/wifi.h | 9 drivers/tty/hvc/hvc_console.c | 23 - drivers/tty/vt/keyboard.c | 26 + drivers/usb/class/cdc-acm.c | 2 drivers/usb/musb/musb_core.c| 7 drivers/usb/musb/musb_debugfs.c | 10 drivers/usb/serial/option.c | 4 drivers/usb/serial/qcserial.c | 1 drivers/usb/serial/usb_wwan.c | 4 include/linux/mod_devicetable.h | 6 include/linux/virtio_net.h | 14 include/uapi/linux/mmc/ioctl.h | 1 kernel/events/uprobes.c | 14 kernel/relay.c | 5 mm/mremap.c |
Re: Linux 4.9.227
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index b41046b5713b..a5225df4a070 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -358,6 +358,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 diff --git a/Documentation/hw-vuln/index.rst b/Documentation/hw-vuln/index.rst index 24f53c501366..b5fbc6ae9d5f 100644 --- a/Documentation/hw-vuln/index.rst +++ b/Documentation/hw-vuln/index.rst @@ -12,4 +12,5 @@ are configurable at compile, boot or run time. l1tf mds tsx_async_abort - multihit.rst + multihit + special-register-buffer-data-sampling diff --git a/Documentation/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index ..47b1b3afac99 --- /dev/null +++ b/Documentation/hw-vuln/special-register-buffer-data-sampling.rst @@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling += + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors + +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + = + common nameFamily_Model Stepping + = + IvyBridge 06_3AHAll + + Haswell06_3CHAll + Haswell_L 06_45HAll + Haswell_G 06_46HAll + + Broadwell_G06_47HAll + Broadwell 06_3DHAll + + Skylake_L 06_4EHAll + Skylake06_5EHAll + + Kabylake_L 06_8EH<= 0xC + Kabylake 06_9EH<= 0xD + = + +Related CVEs + + +The following CVE entry is related to this SRBDS issue: + +== = = +CVE-2020-0543 SRBDS Special Register Buffer Data Sampling +== = = + +Attack scenarios + +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +--- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do not impact performance of sibling logical +processors memory accesses.
RE: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes
From: Kees Cook > Sent: 11 June 2020 04:03 ... > > IIRC other kernels (eg NetBSD) do the copies for ioctl() requests > > in the ioctl syscall wrapper. > > The IOW/IOR/IOWR flags have to be right. > > Yeah, this seems like it'd make a lot more sense (and would have easily > caught the IOR/IOW issue pointed out later in the thread). I wonder how > insane it would be to try to fix that globally in the kernel... Seems like a good idea to me. (Even though I'll need to fix our 'out of tree' modules.) Unlike [sg]etsockopt() at least the buffer is bounded to 1k. But you'd really need to add new kernel_ioctl() entry points before deprecating the existing ones a release or two later. With a bit of luck there aren't any drivers ported from SYSV that just treat the ioctl command as a 32bit transparent value and the argument as an integer. I actually suspect that BSD added IOW (etc) in the 16bit to 32bit port. The kernel copies being moved to the syscall stub at the same time. Since Linux has only ever been 32bit and uses IOW is it actually odd that Linus didn't do the copies in the stub. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [git pull] drm i915 fixes for rc1
On Thu, 11 Jun 2020 at 13:56, Dave Airlie wrote: > > Hi Linus, Hey actually skip this one in favour of the later one, one of the ast fixes needs to get into stable as well. Dave.
Re: [PATCH v6 2/8] mtd: rawnand: rockchip: NFC drivers for RK3308, RK2928 and others
Hi Yifeng,
[...]
> +static void rk_nfc_disable_clk(struct rk_nfc_clk *clk)
> +{
> + if (!IS_ERR(clk->nfc_clk))
> + clk_disable_unprepare(clk->nfc_clk);
> + clk_disable_unprepare(clk->ahb_clk);
> +}
> +
> +static int rk_nfc_ooblayout_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oob_region)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> +
> + if (section >= chip->ecc.steps)
> + return -ERANGE;
> +
> + if (!section) {
> + /* The first byte is bad block mask flag. */
> + oob_region->length = NFC_SYS_DATA_SIZE - 1;
> + oob_region->offset = 1;
> + } else {
> + oob_region->length = NFC_SYS_DATA_SIZE;
> + oob_region->offset = section * NFC_SYS_DATA_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +static int rk_nfc_ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oob_region)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> +
> + if (section)
> + return -ERANGE;
> +
> + oob_region->offset = NFC_SYS_DATA_SIZE * chip->ecc.steps;
> + oob_region->length = mtd->oobsize - oob_region->offset;
> +
> + return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops rk_nfc_ooblayout_ops = {
> + .free = rk_nfc_ooblayout_free,
> + .ecc = rk_nfc_ooblayout_ecc,
> +};
This looks like a copy of the core's nand_lp_ooblayout, better use the
generic one than creation your own.
> +
> +static int rk_nfc_ecc_init(struct device *dev, struct mtd_info *mtd)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct rk_nfc *nfc = nand_get_controller_data(chip);
> + struct nand_ecc_ctrl *ecc = &chip->ecc;
> + const u8 *strengths = nfc->cfg->ecc_strengths;
> + u8 max_strength, nfc_max_strength;
> + int i;
> +
> + nfc_max_strength = nfc->cfg->ecc_strengths[0];
> + /* If optional dt settings not present. */
> + if (!ecc->size || !ecc->strength ||
> + ecc->strength > nfc_max_strength) {
> + /* Use datasheet requirements. */
> + ecc->strength = chip->base.eccreq.strength;
> + ecc->size = chip->base.eccreq.step_size;
> +
> + /*
> + * Align eccstrength and eccsize.
> + * This controller only supports 512 and 1024 sizes.
> + */
> + if (chip->ecc.size < 1024) {
> + if (mtd->writesize > 512) {
> + chip->ecc.size = 1024;
> + chip->ecc.strength <<= 1;
> + } else {
> + dev_err(dev, "ecc.size not supported\n");
> + return -EINVAL;
> + }
> + } else {
> + chip->ecc.size = 1024;
> + }
> +
> + ecc->steps = mtd->writesize / ecc->size;
> +
> + /*
> + * HW ECC always request ECC bytes for 1024 bytes blocks.
> + * 4 Bytes is oob for sys data.
> + */
> + max_strength = ((mtd->oobsize / ecc->steps) - 4) * 8 /
> + fls(8 * 1024);
> + if (max_strength > nfc_max_strength)
> + max_strength = nfc_max_strength;
> +
> + for (i = 0; i < 4; i++) {
> + if (max_strength >= strengths[i])
> + break;
> + }
> +
> + if (i >= 4) {
> + dev_err(nfc->dev, "unsupported strength\n");
> + return -ENOTSUPP;
> + }
> +
> + ecc->strength = strengths[i];
> + }
> + ecc->steps = mtd->writesize / ecc->size;
> + ecc->bytes = DIV_ROUND_UP(ecc->strength * fls(8 * 1024), 8);
> + /* HW ECC always work with even numbers of ECC bytes. */
> + ecc->bytes = ALIGN(ecc->bytes, 2);
> +
> + rk_nfc_hw_ecc_setup(chip, ecc, ecc->strength);
> +
> + return 0;
> +}
> +
> +static int rk_nfc_attach_chip(struct nand_chip *chip)
> +{
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + struct device *dev = mtd->dev.parent;
> + struct rk_nfc *nfc = nand_get_controller_data(chip);
> + struct rk_nfc_nand_chip *rk_nand = to_rk_nand(chip);
> + struct nand_ecc_ctrl *ecc = &chip->ecc;
> + int len;
> + int ret;
> +
> + if (chip->options & NAND_BUSWIDTH_16) {
> + dev_err(dev, "16 bits bus width not supported");
> + return -EINVAL;
> + }
> +
> + if (ecc->mode != NAND_ECC_HW)
> + return 0;
> +
> + ret = rk_nfc_ecc_init(dev, mtd);
> + if (ret)
> + return ret;
> + rk_nand->spare_per_sector = ecc->bytes + NFC_SYS_DATA_SIZE;
> +
> + /* Check buffer first, avoid duplicate alloc buffer. */
> + if (nfc->buffer)
> + return 0;
> +
> + len = mtd->writesize + mtd->oobsize;
> + nfc->buffer = devm
Re: [PATCH v2] mtd: parsers: bcm63xx: simplify CFE detection
Hi Álvaro,
Álvaro Fernández Rojas wrote on Mon, 8 Jun 2020
18:06:49 +0200:
> Instead of trying to parse CFE version string, which is customized by some
> vendors, let's just check that "CFE1" was passed on argument 3.
>
> Signed-off-by: Álvaro Fernández Rojas
> Signed-off-by: Jonas Gorski
> ---
> v2: use CFE_EPTSEAL definition and avoid using an additional funtion.
>
> drivers/mtd/parsers/bcm63xxpart.c | 29 -
> 1 file changed, 4 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mtd/parsers/bcm63xxpart.c
> b/drivers/mtd/parsers/bcm63xxpart.c
> index 78f90c6c18fd..493a75b2f266 100644
> --- a/drivers/mtd/parsers/bcm63xxpart.c
> +++ b/drivers/mtd/parsers/bcm63xxpart.c
> @@ -22,6 +22,9 @@
> #include
> #include
>
> +#include
> +#include
Are you sure both includes are needed?
I don't think it is a good habit to include asm/ headers, are you sure
there is not another header doing it just fine?
> +
> #define BCM963XX_CFE_BLOCK_SIZE SZ_64K /* always at least
> 64KiB */
>
> #define BCM963XX_CFE_MAGIC_OFFSET0x4e0
> @@ -32,30 +35,6 @@
> #define STR_NULL_TERMINATE(x) \
> do { char *_str = (x); _str[sizeof(x) - 1] = 0; } while (0)
>
> -static int bcm63xx_detect_cfe(struct mtd_info *master)
> -{
> - char buf[9];
> - int ret;
> - size_t retlen;
> -
> - ret = mtd_read(master, BCM963XX_CFE_VERSION_OFFSET, 5, &retlen,
> -(void *)buf);
> - buf[retlen] = 0;
> -
> - if (ret)
> - return ret;
> -
> - if (strncmp("cfe-v", buf, 5) == 0)
> - return 0;
> -
> - /* very old CFE's do not have the cfe-v string, so check for magic */
> - ret = mtd_read(master, BCM963XX_CFE_MAGIC_OFFSET, 8, &retlen,
> -(void *)buf);
> - buf[retlen] = 0;
> -
> - return strncmp("CFE1CFE1", buf, 8);
> -}
> -
> static int bcm63xx_read_nvram(struct mtd_info *master,
> struct bcm963xx_nvram *nvram)
> {
> @@ -138,7 +117,7 @@ static int bcm63xx_parse_cfe_partitions(struct mtd_info
> *master,
> struct bcm963xx_nvram *nvram = NULL;
> int ret;
>
> - if (bcm63xx_detect_cfe(master))
> + if (fw_arg3 != CFE_EPTSEAL)
> return -EINVAL;
>
> nvram = vzalloc(sizeof(*nvram));
drivers/mtd/nand/raw/mxic_nand.c:219:9: sparse: sparse: cast removes address space '' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b29482fde649c72441d5478a4ea2c52c56d97a5e
commit: 738b0ca55f4f6ae1035262c2a2a605d2e9085031 mtd: rawnand: Add Macronix raw
NAND controller driver
date: 10 months ago
config: m68k-randconfig-s031-20200611 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
git checkout 738b0ca55f4f6ae1035262c2a2a605d2e9085031
# save the attached .config to linux build tree
make W=1 C=1 ARCH=m68k CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/mtd/nand/raw/mxic_nand.c:219:9: sparse: sparse: cast removes address
>> space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:224:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:288:15: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:299:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:302:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:303:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:304:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:305:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:306:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:307:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:312:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:312:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:314:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:314:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:320:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:320:9: sparse: sparse: cast removes address
space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:356:23: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:356:23: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:361:17: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:363:23: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:363:23: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:368:23: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:368:23: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:374:24: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:379:21: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:403:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:404:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:405:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:414:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:423:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:424:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:432:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:434:25: sparse: sparse: cast removes
address space '' of expression
drivers/mtd/nand/raw/mxic_nand.c:473:17: sparse: sparse: cast removes
address space '' of expression
vim +219 drivers/mtd/nand/raw/mxic_nand.c
216
217 static void mxic_nfc_set_input_delay(struct mxic_nand_ctlr *nfc, u8
idly_code)
218 {
> 219 writel(IDLY_CODE_VAL(0, idly_code) |
220 IDLY_CODE_VAL(1, idly_code) |
221
Re: [PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
On Thu, Jun 11, 2020 at 05:43:32PM +1000, Herbert Xu wrote: > > Finally the prototype of the function has been changed to avoid > the unnecessary use of a void pointer. OK that doesn't quite work. Let me respin without it and instead add some missing inclusions of crypto/hash.h in files that were wrongly relying on uio.h to include it. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v3] sh: Implement __get_user_u64() required for 64-bit get_user()
Hi! This is version 3 of my patch to implement __get_user_u64() for SH. I have asked both Yutaka Niibe and Yoshinori Sato to look over my changes and they both agreed that an entry in __ex_tables for the second access was missing, so I add the missing ".long 1b+2, 3b\n\t". The changes should be correct now and will hopefully get a positive review by the SH maintainers. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH] mld: fix memory leak in ipv6_mc_destroy_dev()
Commit a84d01647989 ("mld: fix memory leak in mld_del_delrec()") fixed
the memory leak of MLD, but missing the ipv6_mc_destroy_dev() path, in
which mca_sources are leaked after ma_put().
Using ip6_mc_clear_src() to take care of the missing free.
BUG: memory leak
unreferenced object 0x8881113d3180 (size 64):
comm "syz-executor071", pid 389, jiffies 4294887985 (age 17.943s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
backtrace:
[<2cbc483c>] kmalloc include/linux/slab.h:555 [inline]
[<2cbc483c>] kzalloc include/linux/slab.h:669 [inline]
[<2cbc483c>] ip6_mc_add1_src net/ipv6/mcast.c:2237 [inline]
[<2cbc483c>] ip6_mc_add_src+0x7f5/0xbb0 net/ipv6/mcast.c:2357
[<58b8b1ff>] ip6_mc_source+0xe0c/0x1530 net/ipv6/mcast.c:449
[<0bfc4fb5>] do_ipv6_setsockopt.isra.12+0x1b2c/0x3b30
net/ipv6/ipv6_sockglue.c:754
[] ipv6_setsockopt+0xda/0x150 net/ipv6/ipv6_sockglue.c:950
[<29260d9a>] rawv6_setsockopt+0x45/0x100 net/ipv6/raw.c:1081
[<5c1b46f9>] __sys_setsockopt+0x131/0x210 net/socket.c:2132
[<8491f7db>] __do_sys_setsockopt net/socket.c:2148 [inline]
[<8491f7db>] __se_sys_setsockopt net/socket.c:2145 [inline]
[<8491f7db>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2145
[] do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:295
[<5fb7a3f3>] entry_SYSCALL_64_after_hwframe+0x49/0xb3
Fixes: 1666d49e1d41 ("mld: do not remove mld souce list info when set link
down")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
net/ipv6/mcast.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 7e12d2114158..8cd2782a31e4 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2615,6 +2615,7 @@ void ipv6_mc_destroy_dev(struct inet6_dev *idev)
idev->mc_list = i->next;
write_unlock_bh(&idev->lock);
+ ip6_mc_clear_src(i);
ma_put(i);
write_lock_bh(&idev->lock);
}
--
2.17.1
[PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
Trying to build the kernel with CONFIG_INFINIBAND_USER_ACCESS enabled fails
ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko]
undefined!
with on SH since the kernel misses a 64-bit implementation of get_user().
Implement the missing 64-bit get_user() as __get_user_u64(), matching the
already existing __put_user_u64() which implements the 64-bit put_user().
Signed-off-by: John Paul Adrian Glaubitz
---
arch/sh/include/asm/uaccess_32.h | 53
1 file changed, 53 insertions(+)
diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
index 624cf55acc27..5d7ddc092afd 100644
--- a/arch/sh/include/asm/uaccess_32.h
+++ b/arch/sh/include/asm/uaccess_32.h
@@ -26,6 +26,9 @@ do {
\
case 4: \
__get_user_asm(x, ptr, retval, "l");\
break; \
+ case 8: \
+ __get_user_u64(x, ptr, retval); \
+ break; \
default:\
__get_user_unknown(); \
break; \
@@ -66,6 +69,56 @@ do { \
extern void __get_user_unknown(void);
+#if defined(CONFIG_CPU_LITTLE_ENDIAN)
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+ "1:\n\t" \
+ "mov.l %2,%R1\n\t" \
+ "mov.l %T2,%S1\n\t" \
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3:\n\t" \
+ "mov #0,%R1\n\t" \
+ "mov #0,%S1\n\t" \
+ "mov.l 4f, %0\n\t" \
+ "jmp@%0\n\t" \
+ " mov %3, %0\n\t" \
+ ".balign4\n" \
+ "4: .long 2b\n\t" \
+ ".previous\n" \
+ ".section __ex_table,\"a\"\n\t" \
+ ".long 1b, 3b\n\t" \
+ ".long 1b + 2, 3b\n\t" \
+ ".previous" \
+ :"=&r" (err), "=&r" (x) \
+ :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#else
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+ "1:\n\t" \
+ "mov.l %2,%S1\n\t" \
+ "mov.l %T2,%R1\n\t" \
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3:\n\t" \
+ "mov #0,%S1\n\t" \
+ "mov #0,%R1\n\t" \
+ "mov.l 4f, %0\n\t" \
+ "jmp@%0\n\t" \
+ " mov %3, %0\n\t" \
+ ".balign4\n" \
+ "4: .long 2b\n\t" \
+ ".previous\n" \
+ ".section __ex_table,\"a\"\n\t" \
+ ".long 1b, 3b\n\t" \
+ ".long 1b + 2, 3b\n\t" \
+ ".previous" \
+ :"=&r" (err), "=&r" (x) \
+ :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#endif
+
#define __put_user_size(x,ptr,size,retval) \
do { \
retval = 0; \
--
2.27.0
Re: [PATCH] printk/kdb: Redirect printk messages into kdb in any context
On Wed 2020-06-10 17:41:40, Daniel Thompson wrote:
> On Sat, May 16, 2020 at 01:36:38AM +0900, Sergey Senozhatsky wrote:
> > On (20/05/15 17:32), Sumit Garg wrote:
> > > > Can I please have some context what problem does this solve?
> > >
> > > You can find the problem description here [1] which leads to this fix.
> >
> > [..]
> >
> > > [1] https://lkml.org/lkml/2020/5/12/213
> >
> > Thanks for the link. I'm slightly surprised it took so many years
> > to notice the addition of printk_nmi/printk_safe :)
>
> Rather by coincidence (at least I think its a coincidence) the problem
> has recently become much more obvious.
>
> 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") just brought
> this to the surface by treating debug traps as NMIs. This means the CPU
> that takes a breakpoint, and where almost all of the kdb printk() calls
> take place, will now unconditionally have printk() interception enabled.
Mea culpa. I have marked this patch as proceed by mistake. It has got
enough acks and is ready for 5.8.
I have just commited the patch into printk/linux.git,
branch for-5.8-kdb-nmi.
I am going to push it to Linus when it passes linux-next integration,
hopefully tomorrow.
Thanks a lot for poking me.
Best Regards,
Petr
Re: [PATCH 17/21] KVM: arm64: Use common code's approach for __GFP_ZERO with memory caches
Hi Sean,
On 2020-06-05 22:38, Sean Christopherson wrote:
Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to
make
the struct and its usage compatible with the common 'struct
kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code
churn when arm64 moves to the common implementation in a future patch,
at
the cost of temporarily having somewhat silly code.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/arm.c | 2 ++
arch/arm64/kvm/mmu.c | 5 +++--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index abbdf9703e20..2385dede96e0 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -105,6 +105,7 @@ struct kvm_arch {
*/
struct kvm_mmu_memory_cache {
int nobjs;
+ gfp_t gfp_zero;
void *objects[KVM_NR_MEM_OBJS];
};
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 45276ed50dd6..4c98c6b4d850 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -270,6 +270,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
vcpu->arch.target = -1;
bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES);
+ vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO;
+
/* Set up the timer */
kvm_timer_vcpu_init(vcpu);
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 9398b66f8a87..688213ef34f0 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -131,7 +131,8 @@ static int mmu_topup_memory_cache(struct
kvm_mmu_memory_cache *cache, int min)
if (cache->nobjs >= min)
return 0;
while (cache->nobjs < ARRAY_SIZE(cache->objects)) {
- page = (void *)__get_free_page(GFP_PGTABLE_USER);
+ page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT |
This is definitely a change in the way we account for guest
page tables allocation, although I find it bizarre that not
all architectures account for it the same way.
It seems logical to me that nested page tables would be accounted
against userspace, but I'm willing to be educated on the matter.
Another possibility is that depending on the context, some allocations
should be accounted on either the kernel or userspace (NV on arm64
could definitely do something like that). If that was the case,
maybe moving most of the GFP_* flags into the per-cache flags,
and have the renaming that Ben suggested earlier.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v4 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
On Fri, 2020-05-29 at 13:24 -0600, Rob Herring wrote:
> On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> > Document the devicetree bindings for MediaTek Command-Queue DMA controller
> > which could be found on MT6779 SoC or other similar Mediatek SoCs.
> >
> > Signed-off-by: EastL
>
> Need a full name
OK
> .
>
> > ---
> > .../devicetree/bindings/dma/mtk-cqdma.yaml | 100
> > +
> > 1 file changed, 100 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> > b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> > new file mode 100644
> > index 000..045aa0c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> > @@ -0,0 +1,100 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Dual license new bindings:
>
> (GPL-2.0-only OR BSD-2-Clause)
OK
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek Command-Queue DMA controller Device Tree Binding
> > +
> > +maintainers:
> > + - EastL
> > +
> > +description:
> > + MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> > + is dedicated to memory-to-memory transfer through queue based
> > + descriptor management.
> > +
>
> Need a $ref to dma-controller.yaml
OK
>
> > +properties:
> > + "#dma-cells":
> > +minimum: 1
> > +# Should be enough
> > +maximum: 255
> > +description:
> > + Used to provide DMA controller specific information.
> > +
> > + compatible:
> > +const: mediatek,cqdma
>
> Needs SoC specific compatible string(s).
OK
>
> > +
> > + reg:
> > +minItems: 1
> > +maxItems: 255
>
> You can have 255 register regions?
No, I'll fix maxItems to 5
>
> You need to define what each region is if more than 1.
>
> > +
> > + interrupts:
> > +minItems: 1
> > +maxItems: 255
>
> 255 interrupts?
the same, 5 interripts.
>
> > +
> > + clocks:
> > +maxItems: 1
> > +
> > + clock-names:
> > +const: cqdma
> > +
> > + dma-channel-mask:
> > +description:
> > + Bitmask of available DMA channels in ascending order that are
> > + not reserved by firmware and are available to the
> > + kernel. i.e. first channel corresponds to LSB.
> > + The first item in the array is for channels 0-31, the second is for
> > + channels 32-63, etc.
> > +allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32-array
> > +items:
> > + minItems: 1
> > + # Should be enough
> > + maxItems: 255
>
> This already has a definition in dma-common.yaml. Don't copy-n-paste
> it. Just add any constraints you have. Like what is the max number of
> channels?
OK, the max channel number is 5, I'll fix it on next version.
>
> > +
> > + dma-channels:
> > +$ref: /schemas/types.yaml#definitions/uint32
> > +description:
> > + Number of DMA channels supported by the controller.
> > +
> > + dma-requests:
> > +$ref: /schemas/types.yaml#definitions/uint32
> > +description:
> > + Number of DMA request signals supported by the controller.
>
> Same comment on these 2.
OK
>
> > +
> > +required:
> > + - "#dma-cells"
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - dma-channel-mask
> > + - dma-channels
> > + - dma-requests
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#include
> > +cqdma: dma-controller@10212000 {
> > +compatible = "mediatek,cqdma";
> > +reg = <0 0x10212000 0 0x80>,
> > +<0 0x10212080 0 0x80>,
> > +<0 0x10212100 0 0x80>;
>
> Examples default to 1 cell each for address and size.
OK
>
> > +interrupts = ,
> > +,
> > +;
> > +clocks = <&infracfg_ao CLK_INFRA_CQ_DMA>;
> > +clock-names = "cqdma";
> > +dma-channel-mask = <63>;
> > +dma-channels = <3>;
> > +dma-requests = <32>;
> > +#dma-cells = <1>;
> > +};
> > +
> > +...
> > --
> > 1.9.1
Re: [PATCH 18/21] KVM: arm64: Use common KVM implementation of MMU memory caches
On 2020-06-05 22:38, Sean Christopherson wrote:
Move to the common MMU memory cache implementation now that the common
code and arm64's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 12 ---
arch/arm64/include/asm/kvm_types.h | 2 ++
arch/arm64/kvm/mmu.c | 51 ++
3 files changed, 12 insertions(+), 53 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 2385dede96e0..d221b6b129fd 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -97,18 +97,6 @@ struct kvm_arch {
bool return_nisv_io_abort_to_user;
};
-#define KVM_NR_MEM_OBJS 40
-
-/*
- * We don't want allocation failures within the mmu code, so we
preallocate
- * enough memory for a single page fault in a cache.
- */
-struct kvm_mmu_memory_cache {
- int nobjs;
- gfp_t gfp_zero;
- void *objects[KVM_NR_MEM_OBJS];
-};
-
struct kvm_vcpu_fault_info {
u32 esr_el2;/* Hyp Syndrom Register */
u64 far_el2;/* Hyp Fault Address Register */
diff --git a/arch/arm64/include/asm/kvm_types.h
b/arch/arm64/include/asm/kvm_types.h
index d0987007d581..9a126b9e2d7c 100644
--- a/arch/arm64/include/asm/kvm_types.h
+++ b/arch/arm64/include/asm/kvm_types.h
@@ -2,5 +2,7 @@
#ifndef _ASM_ARM64_KVM_TYPES_H
#define _ASM_ARM64_KVM_TYPES_H
+#define KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE 40
+
#endif /* _ASM_ARM64_KVM_TYPES_H */
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 688213ef34f0..976405e2fbb2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -124,37 +124,6 @@ static void stage2_dissolve_pud(struct kvm *kvm,
phys_addr_t addr, pud_t *pudp)
put_page(virt_to_page(pudp));
}
-static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
int min)
-{
- void *page;
-
- if (cache->nobjs >= min)
- return 0;
- while (cache->nobjs < ARRAY_SIZE(cache->objects)) {
- page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT |
- cache->gfp_zero);
- if (!page)
- return -ENOMEM;
- cache->objects[cache->nobjs++] = page;
- }
- return 0;
-}
-
-static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
-{
- while (mc->nobjs)
- free_page((unsigned long)mc->objects[--mc->nobjs]);
-}
-
-static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
-{
- void *p;
-
- BUG_ON(!mc || !mc->nobjs);
- p = mc->objects[--mc->nobjs];
- return p;
-}
-
static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd,
phys_addr_t addr)
{
pud_t *pud_table __maybe_unused = stage2_pud_offset(kvm, pgd, 0UL);
@@ -1024,7 +993,7 @@ static pud_t *stage2_get_pud(struct kvm *kvm,
struct kvm_mmu_memory_cache *cache
if (stage2_pgd_none(kvm, *pgd)) {
if (!cache)
return NULL;
- pud = mmu_memory_cache_alloc(cache);
+ pud = kvm_mmu_memory_cache_alloc(cache);
stage2_pgd_populate(kvm, pgd, pud);
get_page(virt_to_page(pgd));
}
Quick note: this patch (as it is) breaks on arm64 due to Mike Rapoport's
P4D rework. I've fixed it locally in order to test the series.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v2] exfat: add missing brelse() calls on error paths
… > +++ b/fs/exfat/namei.c > @@ -1077,10 +1077,14 @@ static int exfat_rename_file(struct inode *inode, > struct exfat_chain *p_dir, > > epold = exfat_get_dentry(sb, p_dir, oldentry + 1, &old_bh, > §or_old); > + if (!epold) > + return -EIO; … Can it become helpful to annotate such null pointer checks for branch prediction? Would you like to indicate a likelihood in any way? Regards, Markus
Re: [PATCH 2/2] spi: tools: Fix build errors
Hi Qing,
Thanks for your patch!
On Thu, Jun 11, 2020 at 5:43 AM Qing Zhang wrote:
> Fix the following build errors:
>
> include/linux/spi 2>&1 || true
> ln -sf
> /home/zhangqing/spi.git2/tools/spi/../../include/uapi/linux/spi/spidev.h
> include/linux/spi/spidev.h
> make -f /home/zhangqing/spi.git2/tools/build/Makefile.build dir=.
> obj=spidev_test
> make[1]: Entering directory '/home/zhangqing/spi.git2/tools/spi'
> CC spidev_test.o
> spidev_test.c: In function ‘transfer’:
> spidev_test.c:131:13: error: ‘SPI_TX_OCTAL’ undeclared (first use in this
> function)
> if (mode & SPI_TX_OCTAL)
> ^
> spidev_test.c:131:13: note: each undeclared identifier is reported only once
> for each function it appears in
> spidev_test.c:137:13: error: ‘SPI_RX_OCTAL’ undeclared (first use in this
> function)
> if (mode & SPI_RX_OCTAL)
> ^
> spidev_test.c: In function ‘parse_opts’:
> spidev_test.c:290:12: error: ‘SPI_TX_OCTAL’ undeclared (first use in this
> function)
> mode |= SPI_TX_OCTAL;
> ^
> spidev_test.c:308:12: error: ‘SPI_RX_OCTAL’ undeclared (first use in this
> function)
> mode |= SPI_RX_OCTAL;
> ^
> LD spidev_test-in.o
> ld: cannot find spidev_test.o: No such file or directory
> /home/zhangqing/spi.git2/tools/build/Makefile.build:144: recipe for target
> 'spidev_test-in.o' failed
> make[1]: *** [spidev_test-in.o] Error 1
> make[1]: Leaving directory '/home/zhangqing/spi.git2/tools/spi'
> Makefile:39: recipe for target 'spidev_test-in.o' failed
> make: *** [spidev_test-in.o] Error 2
>
> Signed-off-by: Qing Zhang
Oops, somehow I forgot I had made a similar change on the target
when adding Octal mode support to spidev_test.c.
Sorry for that.
Fixes: 896fa735084e4a91 ("spi: spidev_test: Add support for Octal mode
data transfers")
Reviewed-by: Geert Uytterhoeven
> --- a/include/uapi/linux/spi/spidev.h
> +++ b/include/uapi/linux/spi/spidev.h
> @@ -48,6 +48,8 @@
> #define SPI_TX_QUAD0x200
> #define SPI_RX_DUAL0x400
> #define SPI_RX_QUAD0x800
> +#defineSPI_TX_OCTAL0x2000
> +#defineSPI_RX_OCTAL0x4000
Probably we should add SPI_CS_WORD and SPI_3WIRE_HIZ, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH v4] scsi: ufs: Fix imprecise load calculation in devfreq window
>
> The UFS load calculation is based on "total_time" and "busy_time" in a
> devfreq window. However, the source of time is different for both
> parameters: "busy_time" is assigned from "jiffies" thus has different
> accuracy from "total_time" which is assigned from ktime_get().
>
> Besides, the time of window boundary is not exactly the same as
> the starting busy time in this window if UFS is actually busy
> in the beginning of the window. A similar accuracy error may also
> happen for the end of busy time in current window.
>
> To guarantee the precision of load calculation, we need to
>
> 1. Align time accuracy of both devfreq_dev_status.total_time and
>devfreq_dev_status.busy_time. For example, use "ktime_get()"
>directly.
>
> 2. Align below timelines,
>- The beginning time of devfreq windows
>- The beginning of busy time in a new window
>- The end of busy time in the current window
>
> Fixes: a3cd5ec55f6c ("scsi: ufs: add load based scaling of UFS gear")
> Signed-off-by: Stanley Chu
Reviewed-by: Avri Altman
Just a small nit.
> - stat->total_time = jiffies_to_usecs((long)jiffies -
> - (long)scaling->window_start_t);
> + stat->total_time = ktime_to_us(curr_t) - scaling->window_start_t;
ktime_sub ?
Thanks,
Avri
[PATCH v4 2/2] regulator: Add driver for cros-ec-regulator
Add driver for cros-ec-regulator, representing a voltage regulator that
is connected and controlled by ChromeOS EC, and is controlled by kernel
with EC host commands.
Signed-off-by: Pi-Hsun Shih
---
Changes from v3:
* Remove check around CONFIG_OF.
* Add new host commands to cros_ec_trace.
* Use devm_kstrdup for duping regulator name.
* Change license header and add MODULE_AUTHOR.
* Address review comments.
Changes from v2:
* Add 'depends on OF' to Kconfig.
* Add Kconfig description about compiling as module.
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Address comments on code styles.
This patch contains function cros_ec_cmd that is copied from the series:
https://lore.kernel.org/patchwork/project/lkml/list/?series=428457.
I can't find the first patch in that v2 series, so the function is
modified from v1 of that series according to reviewers comment:
https://lore.kernel.org/patchwork/patch/1188110/
I copied the function instead of depending on that series since I feel
the function is small enough, and the series has stalled for some time.
---
drivers/platform/chrome/cros_ec_trace.c | 5 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile| 1 +
drivers/regulator/cros-ec-regulator.c | 256 ++
.../linux/platform_data/cros_ec_commands.h| 82 ++
5 files changed, 354 insertions(+)
create mode 100644 drivers/regulator/cros-ec-regulator.c
diff --git a/drivers/platform/chrome/cros_ec_trace.c
b/drivers/platform/chrome/cros_ec_trace.c
index 523a39bd0ff6..425e9441b7ca 100644
--- a/drivers/platform/chrome/cros_ec_trace.c
+++ b/drivers/platform/chrome/cros_ec_trace.c
@@ -161,6 +161,11 @@
TRACE_SYMBOL(EC_CMD_ADC_READ), \
TRACE_SYMBOL(EC_CMD_ROLLBACK_INFO), \
TRACE_SYMBOL(EC_CMD_AP_RESET), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_GET_INFO), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_ENABLE), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_IS_ENABLED), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_SET_VOLTAGE), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_GET_VOLTAGE), \
TRACE_SYMBOL(EC_CMD_CR51_BASE), \
TRACE_SYMBOL(EC_CMD_CR51_LAST), \
TRACE_SYMBOL(EC_CMD_FP_PASSTHRU), \
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8f677f5d79b4..c398e90e0e73 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -238,6 +238,16 @@ config REGULATOR_CPCAP
Say y here for CPCAP regulator found on some Motorola phones
and tablets such as Droid 4.
+config REGULATOR_CROS_EC
+ tristate "ChromeOS EC regulators"
+ depends on CROS_EC && OF
+ help
+ This driver supports voltage regulators that is connected to ChromeOS
+ EC and controlled through EC host commands.
+
+ This driver can also be built as a module. If so, the module
+ will be called cros-ec-regulator.
+
config REGULATOR_DA903X
tristate "Dialog Semiconductor DA9030/DA9034 regulators"
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f163371071..46592c160d22 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) +=
userspace-consumer.o
obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
+obj-$(CONFIG_REGULATOR_CROS_EC) += cros-ec-regulator.o
obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o
obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
diff --git a/drivers/regulator/cros-ec-regulator.c
b/drivers/regulator/cros-ec-regulator.c
new file mode 100644
index ..1e05abf57b95
--- /dev/null
+++ b/drivers/regulator/cros-ec-regulator.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright 2020 Google LLC.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cros_ec_regulator_data {
+ struct regulator_desc desc;
+ struct regulator_dev *dev;
+ struct cros_ec_device *ec_dev;
+
+ u32 index;
+
+ u16 *voltages_mV;
+ u16 num_voltages;
+};
+
+static int cros_ec_cmd(struct cros_ec_device *ec, u32 version, u32 command,
+ void *outdata, u32 outsize, void *indata, u32 insize)
+{
+ struct cros_ec_command *msg;
+ int ret;
+
+ msg = kzalloc(sizeof(*msg) + max(outsize, insize), GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
+
+ msg->version = version;
+ msg->command = command;
+ msg->outsize = outsize;
+ msg->insize = insize;
+
+ if (outdata && outsize > 0)
+ memcpy(msg->data, outdata, outsize);
+
+ ret = cros_ec_cmd_xfer_status(ec, msg);
+ if (ret < 0)
+ goto cleanup;
+
+
[PATCH v4 0/2] Add support for voltage regulator on ChromeOS EC.
Add support for controlling voltage regulator that is connected and controlled by ChromeOS EC. Kernel controls these regulators through newly added EC host commands. Changes from v3: * Fix dt bindings file name. * Remove check around CONFIG_OF in driver. * Add new host commands to cros_ec_trace. * Address review comments. Changes from v2: * Add 'depends on OF' to Kconfig. * Add Kconfig description about compiling as module. Changes from v1: * Change compatible string to google,regulator-cros-ec. * Use reg property in device tree. * Change license for dt binding according to checkpatch.pl. * Address comments on code styles. Pi-Hsun Shih (2): dt-bindings: regulator: Add DT binding for cros-ec-regulator regulator: Add driver for cros-ec-regulator .../regulator/google,cros-ec-regulator.yaml | 51 drivers/platform/chrome/cros_ec_trace.c | 5 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/cros-ec-regulator.c | 256 ++ .../linux/platform_data/cros_ec_commands.h| 82 ++ 6 files changed, 405 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml create mode 100644 drivers/regulator/cros-ec-regulator.c base-commit: b29482fde649c72441d5478a4ea2c52c56d97a5e -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH v4 1/2] dt-bindings: regulator: Add DT binding for cros-ec-regulator
Add DT binding documentation for cros-ec-regulator, a voltage regulator
controlled by ChromeOS EC.
Signed-off-by: Pi-Hsun Shih
---
Changes from v3:
* Fix dt bindings file name.
* Add full example.
Changes from v2:
* No change
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Change license for dt binding according to checkpatch.pl.
---
.../regulator/google,cros-ec-regulator.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
new file mode 100644
index ..7e341b65b2dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/google,cros-ec-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS EC controlled voltage regulators
+
+maintainers:
+ - Pi-Hsun Shih
+
+description:
+ Any property defined as part of the core regulator binding, defined in
+ regulator.yaml, can also be used.
+
+allOf:
+ - $ref: "regulator.yaml#"
+
+properties:
+ compatible:
+const: google,regulator-cros-ec
+
+ reg:
+maxItems: 1
+description: Identifier for the voltage regulator to ChromeOS EC.
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+spi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cros_ec: ec@0 {
+compatible = "google,cros-ec-spi";
+reg = <0>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+regulator@0 {
+compatible = "google,regulator-cros-ec";
+regulator-min-microvolt = <180>;
+regulator-max-microvolt = <330>;
+reg = <0>;
+};
+};
+};
+...
--
2.27.0.278.ge193c7cf3a9-goog
Re: [PATCH 00/21] KVM: Cleanup and unify kvm_mmu_memory_cache usage
Hi Sean, On 2020-06-05 22:38, Sean Christopherson wrote: This series resurrects Christoffer Dall's series[1] to provide a common MMU memory cache implementation that can be shared by x86, arm64 and MIPS. It also picks up a suggested change from Ben Gardon[2] to clear shadow page tables during initial allocation so as to avoid clearing entire pages while holding mmu_lock. The front half of the patches do house cleaning on x86's memory cache implementation in preparation for moving it to common code, along with a fair bit of cleanup on the usage. The middle chunk moves the patches to common KVM, and the last two chunks convert arm64 and MIPS to the common implementation. Cleanup aside, the notable difference from Christoffer and Ben's proposed patches is to make __GFP_ZERO optional, e.g. to allow x86 to skip zeroing for its gfns array and to provide line of sight for my cannot-yet-be-discussed-in-detail use case for non-zero initialized shadow page tables[3]. Tested on x86 only, no testing whatsoever on arm64 or MIPS. I've given it a go on a small bunch of arm64 boxes, and nothing caught fire! As Ben noticed, the series isn't bisectable (easily fixed) and there is some nagging conflicts with the current state of mainline. Overall, a very welcome cleanup. The only point of contention is the change in allocation accounting on arm64, but there is an easy fix for that. Thanks, M. -- Jazz is not dead. It just smells funny...
Kernel 5.7.0, nouveau 1.0.15-r1, sudo lshw -C display, *-display UNCLAIMED
Hi With Kernel 5.7.0, nouveau drivers 1.0.15-r1 sudo `lshw -C display` will show me: *-display UNCLAIMED Also `xrandr -q` will not work: xrandr: Failed to get size of gamma for output default Screen 0: minimum 1680 x 1050, current 1680 x 1050, maximum 1680 x 1050 default connected primary 1680x1050+0+0 0mm x 0mm 1680x1050 0.00* So I can not start up my second monitor with this command: xrandr --output DVI-D-1 --auto --output DP-1 --auto --left-of DVI-D-1 This used to work with Kernel 5.5. It was "completely broken" in 5.6 and with 5.7 my first display is back, but not my second. I am on Gentoo Linux. Please CC for replies. Best Zeno
Re: [PATCH v2 2/2] usb: phy: Add USB3 PHY support for Intel LGM SoC
On Thu, Jun 11, 2020 at 10:12:46AM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan
>
> Add support for USB PHY on Intel LGM SoC.
...
> +static int get_flipped(struct tca_apb *ta, bool *flipped)
> +{
> + union extcon_property_value property;
> + int ret;
> +
> + ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_TYPEC_POLARITY, &property);
> + if (ret) {
> + dev_err(ta->phy.dev, "no polarity property from extcon\n");
> + return false;
return ret;
> + }
> +
> + *flipped = property.intval;
> +
> + return *flipped;
return 0;
> +}
...I suppose it should be as above.
...
> + ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE,
> + 10, 10 * 1000);
On one line easier to read.
> + if (ret) {
> + dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
> + return ret;
> + }
...
> +static int phy_set_vbus(struct usb_phy *phy, int on)
> +{
> + struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
> + int ret = 0;
Assignment is redundant.
> +
> + if (on) {
> + ret = regulator_enable(ta->vbus);
> + if (ret)
> + dev_err(ta->phy.dev, "regulator not enabled\n");
> + } else {
> + ret = regulator_disable(ta->vbus);
> + if (ret)
> + dev_err(ta->phy.dev, "regulator not disabled\n");
> + }
> +
> + return ret;
> +}
...
> + ret = get_flipped(ta, &flipped);
> + if (!ret)
> + dev_err(ta->phy.dev, "no polarity property from extcon\n");
This should be fixed accordingly.
...
> + dev_info(ta->phy.dev, "connected%s\n",
> + flipped ? " flipped" : "");
One line.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v4 1/2] dt-bindings: regulator: Add DT binding for cros-ec-regulator
Hi Pi-Hsun,
Thank you for the patch, one minor nitpick that in my opinion would be good to
address.
On 11/6/20 10:04, Pi-Hsun Shih wrote:
> Add DT binding documentation for cros-ec-regulator, a voltage regulator
> controlled by ChromeOS EC.
>
> Signed-off-by: Pi-Hsun Shih
> ---
> Changes from v3:
> * Fix dt bindings file name.
> * Add full example.
>
> Changes from v2:
> * No change
>
> Changes from v1:
> * Change compatible string to google,regulator-cros-ec.
> * Use reg property in device tree.
> * Change license for dt binding according to checkpatch.pl.
> ---
> .../regulator/google,cros-ec-regulator.yaml | 51 +++
> 1 file changed, 51 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
> b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
> new file mode 100644
> index ..7e341b65b2dd
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/google,cros-ec-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ChromeOS EC controlled voltage regulators
> +
> +maintainers:
> + - Pi-Hsun Shih
> +
> +description:
> + Any property defined as part of the core regulator binding, defined in
> + regulator.yaml, can also be used.
> +
> +allOf:
> + - $ref: "regulator.yaml#"
> +
> +properties:
> + compatible:
> +const: google,regulator-cros-ec
Could we use "google,cros-ec-regulator" as compatible, so we are aligned with
the driver name and other cros-ec drivers? If you're agree you need to do
changes here, in the example and in the of table id.
In any case the file binding name should match the compatible name and that's
not the case now, as the file is google,cros-ec-regulator and the compatible is
google,regulator-cros-ec. So either fix the file binding name or the compatible
(I'd prefer the second).
Thanks,
Enric
> +
> + reg:
> +maxItems: 1
> +description: Identifier for the voltage regulator to ChromeOS EC.
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cros_ec: ec@0 {
> +compatible = "google,cros-ec-spi";
> +reg = <0>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +regulator@0 {
> +compatible = "google,regulator-cros-ec";
> +regulator-min-microvolt = <180>;
> +regulator-max-microvolt = <330>;
> +reg = <0>;
> +};
> +};
> +};
> +...
>
Re: [PATCH 2/2] KVM: async_pf: Inject 'page ready' event only if 'page not present' was previously injected
Vivek Goyal writes: > On Wed, Jun 10, 2020 at 07:55:32PM +0200, Vitaly Kuznetsov wrote: >> 'Page not present' event may or may not get injected depending on >> guest's state. If the event wasn't injected, there is no need to >> inject the corresponding 'page ready' event as the guest may get >> confused. E.g. Linux thinks that the corresponding 'page not present' >> event wasn't delivered *yet* and allocates a 'dummy entry' for it. >> This entry is never freed. >> >> Note, 'wakeup all' events have no corresponding 'page not present' >> event and always get injected. >> >> s390 seems to always be able to inject 'page not present', the >> change is effectively a nop. >> >> Suggested-by: Vivek Goyal >> Signed-off-by: Vitaly Kuznetsov >> --- >> arch/s390/include/asm/kvm_host.h | 2 +- >> arch/s390/kvm/kvm-s390.c | 4 +++- >> arch/x86/include/asm/kvm_host.h | 2 +- >> arch/x86/kvm/x86.c | 7 +-- >> include/linux/kvm_host.h | 1 + >> virt/kvm/async_pf.c | 2 +- >> 6 files changed, 12 insertions(+), 6 deletions(-) >> >> diff --git a/arch/s390/include/asm/kvm_host.h >> b/arch/s390/include/asm/kvm_host.h >> index 3d554887794e..cee3cb6455a2 100644 >> --- a/arch/s390/include/asm/kvm_host.h >> +++ b/arch/s390/include/asm/kvm_host.h >> @@ -978,7 +978,7 @@ bool kvm_arch_can_dequeue_async_page_present(struct >> kvm_vcpu *vcpu); >> void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, >> struct kvm_async_pf *work); >> >> -void kvm_arch_async_page_not_present(struct kvm_vcpu *vcpu, >> +bool kvm_arch_async_page_not_present(struct kvm_vcpu *vcpu, >> struct kvm_async_pf *work); > > Hi Vitaly, > > A minor nit. Using return code to figure out if exception was injected > or not is little odd. How about we pass a pointer instead as parameter > and kvm_arch_async_page_not_present() sets it to true if page not > present exception was injected. This probably will be easier to > read. > > If for some reason you don't like above, atleats it warrants a comment > explaining what do 0 and 1 mean. > I think it's the 'kvm_arch_async_page_not_present' name which is a bit misleading now, if we rename it to something like kvm_arch_inject_apf_not_present() then it becomes a bit more clear what's going on. We may as well write the code as if (kvm_arch_inject_apf_not_present()) work->notpresent_injected = true; or change the return type to int so it'll be if (!kvm_arch_inject_apf_not_present()) work->notpresent_injected = true; > Otherwise both the patches look good to me. I tested and I can confirm > that now page ready events are not being delivered to guest if page > not present was not injected. Thank you for testing! -- Vitaly
Re: [PATCH v4 0/2] Recommend denylist/allowlist instead of blacklist/whitelist
On 11. 06. 20, 9:38, SeongJae Park wrote: > On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches wrote: > >> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote: >>> From: SeongJae Park >>> >>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl' >>> and 2) set the 'blacklist' and 'whitelist' as deprecated with >>> replacement suggestion of 'denylist' and 'allowlist', because the >>> suggestions are incontrovertible, doesn't make people hurt, and more >>> self-explanatory. >> >> While the checkpatch implementation is better, >> I'm still very "meh" about the whole concept. > > I can understand your concerns about politic things in the second patch. > However, the concept of the 'deprecated terms' in the first patch is not > political but applicable to the general cases. We already had the commits[1] > for a similar case. So, could you ack for at least the first patch? > > [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs Fuck you! replaced by hug you! is a completely different story. The former is indeed offending to majority (despite it's quite common to tell someone "fuck you" in my subregion; OTOH hugging, no way -- I'm a straight non-communist). If it turns out that any word (e.g. blacklist) offends _majority_ (or at least a significant part of it) of some minority or culture, then sure, we should send it to /dev/null. But we should by no means listen to extreme individuals. thanks, -- js suse labs
Re: [PATCH] serial: core: drop unnecessary gpio include
[cc += Heiko] On Wed, Jun 10, 2020 at 05:51:21PM +0200, Johan Hovold wrote: > Drop the recently added gpio include from the serial-core header in > favour of a forward declaration and instead include the gpio header only > where needed. Hm, but why? Are there adverse effects if this is included by ? Thanks, Lukas > > Signed-off-by: Johan Hovold > --- > drivers/tty/serial/8250/8250_port.c | 1 + > drivers/tty/serial/serial_core.c| 1 + > include/linux/serial_core.h | 2 +- > 3 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/8250/8250_port.c > b/drivers/tty/serial/8250/8250_port.c > index 1632f7d25acc..d64ca77d9cfa 100644 > --- a/drivers/tty/serial/8250/8250_port.c > +++ b/drivers/tty/serial/8250/8250_port.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/tty/serial/serial_core.c > b/drivers/tty/serial/serial_core.c > index 3706f31b0c37..cba19f7d9ea3 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > index 791f4844efeb..01fc4d9c9c54 100644 > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -10,7 +10,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -30,6 +29,7 @@ > struct uart_port; > struct serial_struct; > struct device; > +struct gpio_desc; > > /* > * This structure describes all the operations that can be done on the > -- > 2.26.2 >
[PATCH v5 0/2] Add support for voltage regulator on ChromeOS EC.
Add support for controlling voltage regulator that is connected and controlled by ChromeOS EC. Kernel controls these regulators through newly added EC host commands. Changes from v4: * Change compatible name from regulator-cros-ec to cros-ec-regulator. Changes from v3: * Fix dt bindings file name. * Remove check around CONFIG_OF in driver. * Add new host commands to cros_ec_trace. * Address review comments. Changes from v2: * Add 'depends on OF' to Kconfig. * Add Kconfig description about compiling as module. Changes from v1: * Change compatible string to google,regulator-cros-ec. * Use reg property in device tree. * Change license for dt binding according to checkpatch.pl. * Address comments on code styles. Pi-Hsun Shih (2): dt-bindings: regulator: Add DT binding for cros-ec-regulator regulator: Add driver for cros-ec-regulator .../regulator/google,cros-ec-regulator.yaml | 51 drivers/platform/chrome/cros_ec_trace.c | 5 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/cros-ec-regulator.c | 256 ++ .../linux/platform_data/cros_ec_commands.h| 82 ++ 6 files changed, 405 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml create mode 100644 drivers/regulator/cros-ec-regulator.c base-commit: b29482fde649c72441d5478a4ea2c52c56d97a5e -- 2.27.0.278.ge193c7cf3a9-goog
Re: [smp] b2a02fc43a: suspend-stress.fail
Hi Peter,
On Wed, Jun 10, 2020 at 5:52 PM Peter Zijlstra wrote:
>
> On Wed, Jun 10, 2020 at 04:35:02PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: b2a02fc43a1f40ef4eb2fb2b06357382608d4d84 ("smp: Optimize
> > send_call_function_single_ipi()")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> > in testcase: suspend-stress
> > with following parameters:
> >
> > mode: freeze
> > iterations: 10
> >
> >
> >
> > on test machine: 2 threads Broxton with 4G memory
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> >
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot
> >
> >
> > the result of this commit:
> >
> > test started
>
> No dmesg output? No splat?
This issue was only found on one of the test machines from lkp team.
I've borrowed that machine and will try to narrow down and give feedback later.
thanks,
Chenyu
[PATCH v5 2/2] regulator: Add driver for cros-ec-regulator
Add driver for cros-ec-regulator, representing a voltage regulator that
is connected and controlled by ChromeOS EC, and is controlled by kernel
with EC host commands.
Signed-off-by: Pi-Hsun Shih
---
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Remove check around CONFIG_OF.
* Add new host commands to cros_ec_trace.
* Use devm_kstrdup for duping regulator name.
* Change license header and add MODULE_AUTHOR.
* Address review comments.
Changes from v2:
* Add 'depends on OF' to Kconfig.
* Add Kconfig description about compiling as module.
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Address comments on code styles.
This patch contains function cros_ec_cmd that is copied from the series:
https://lore.kernel.org/patchwork/project/lkml/list/?series=428457.
I can't find the first patch in that v2 series, so the function is
modified from v1 of that series according to reviewers comment:
https://lore.kernel.org/patchwork/patch/1188110/
I copied the function instead of depending on that series since I feel
the function is small enough, and the series has stalled for some time.
---
drivers/platform/chrome/cros_ec_trace.c | 5 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile| 1 +
drivers/regulator/cros-ec-regulator.c | 256 ++
.../linux/platform_data/cros_ec_commands.h| 82 ++
5 files changed, 354 insertions(+)
create mode 100644 drivers/regulator/cros-ec-regulator.c
diff --git a/drivers/platform/chrome/cros_ec_trace.c
b/drivers/platform/chrome/cros_ec_trace.c
index 523a39bd0ff6..425e9441b7ca 100644
--- a/drivers/platform/chrome/cros_ec_trace.c
+++ b/drivers/platform/chrome/cros_ec_trace.c
@@ -161,6 +161,11 @@
TRACE_SYMBOL(EC_CMD_ADC_READ), \
TRACE_SYMBOL(EC_CMD_ROLLBACK_INFO), \
TRACE_SYMBOL(EC_CMD_AP_RESET), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_GET_INFO), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_ENABLE), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_IS_ENABLED), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_SET_VOLTAGE), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_GET_VOLTAGE), \
TRACE_SYMBOL(EC_CMD_CR51_BASE), \
TRACE_SYMBOL(EC_CMD_CR51_LAST), \
TRACE_SYMBOL(EC_CMD_FP_PASSTHRU), \
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8f677f5d79b4..c398e90e0e73 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -238,6 +238,16 @@ config REGULATOR_CPCAP
Say y here for CPCAP regulator found on some Motorola phones
and tablets such as Droid 4.
+config REGULATOR_CROS_EC
+ tristate "ChromeOS EC regulators"
+ depends on CROS_EC && OF
+ help
+ This driver supports voltage regulators that is connected to ChromeOS
+ EC and controlled through EC host commands.
+
+ This driver can also be built as a module. If so, the module
+ will be called cros-ec-regulator.
+
config REGULATOR_DA903X
tristate "Dialog Semiconductor DA9030/DA9034 regulators"
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f163371071..46592c160d22 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) +=
userspace-consumer.o
obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
+obj-$(CONFIG_REGULATOR_CROS_EC) += cros-ec-regulator.o
obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o
obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
diff --git a/drivers/regulator/cros-ec-regulator.c
b/drivers/regulator/cros-ec-regulator.c
new file mode 100644
index ..830ceefc704a
--- /dev/null
+++ b/drivers/regulator/cros-ec-regulator.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright 2020 Google LLC.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cros_ec_regulator_data {
+ struct regulator_desc desc;
+ struct regulator_dev *dev;
+ struct cros_ec_device *ec_dev;
+
+ u32 index;
+
+ u16 *voltages_mV;
+ u16 num_voltages;
+};
+
+static int cros_ec_cmd(struct cros_ec_device *ec, u32 version, u32 command,
+ void *outdata, u32 outsize, void *indata, u32 insize)
+{
+ struct cros_ec_command *msg;
+ int ret;
+
+ msg = kzalloc(sizeof(*msg) + max(outsize, insize), GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
+
+ msg->version = version;
+ msg->command = command;
+ msg->outsize = outsize;
+ msg->insize = insize;
+
+ if (outdata && outsize > 0)
+ memcpy(msg->data, outdata, outsize);
+
+ ret = c
