Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
On Sun, Jan 7, 2018 at 11:47 AM, Linus Torvalds wrote: > On Sat, Jan 6, 2018 at 10:33 PM, Willy Tarreau wrote: >> >> To be fair there's overreaction on both sides. The vast majority of >> users need to get a 100% safe system and will never notice any >> difference. > > There is no such thing as a "100% safe system". Never will be - unless > you make sure you have no users. > > Also, people definitely *are* noticing the performance issues with the > current set of patches, and they are causing real problems. Go search > for reports of Amazon AWS slowdowns. > > So this whole "security is so important that performance doesn't > matter" mindset is pure and utter garbage. > > And the whole "normal people won't even notice" is pure garbage too. > Don't spread that bullshit when you see actual normal people > complaining. > > Performance matters. A *LOT*. I'm thinking we should provide the option to at least build the hot-path nospec_array_ptr() usages without an lfence. CONFIG_SPECTRE1_PARANOIA_SAFE CONFIG_SPECTRE1_PARANOIA_PERF ...if only for easing performance testing and let the distribution set its policy. Where hot-path usages can do: nospec_relax(nospec_array_ptr()) ...to optionally ellide the lfence.
Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
On Sun, Jan 7, 2018 at 12:12 PM, Willy Tarreau wrote: > > Linus, no need to explain that to me, I'm precisely trying to see how > to disable PTI for a specific process because I face up to 45% loss in > certain circumstances, making it a no-go. But while a few of us have > very specific workloads emphasizing this impact, others have very > different ones and will not notice. For example my laptop did boot > pretty fine and I didn't notice anything until I fire a network > benchmark. Sure, most people have hardware where the bottleneck is entirely elsewhere (slow network, rotating disk, whatever). But this whole "normal people won't notice" is dangerous thinking. They may well notice very much, we simply don't know what they are doing. Quite honesty, it's equally correct to say "normal people won't be affected by the security issue in the first place". That laptop that you didn't have any issues with? Likely it never had an exploit running on it either! So the whole "normal people" argument is pure and utter garbage. It's wrong. It's pure shit when it comes to performance, but it's also pure shit when it comes to the security issue. Don't use it. We need to fix the security problem, but we need to do it *without* these braindead arguments that performance is somehow secondary. Linus
Re: [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
Hi Yixun,
On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote:
> Describe the pinctrl info for the UART controller which is found
> in the Meson-AXG SoCs.
>
> Signed-off-by: Yixun Lan
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97
> ++
> 1 file changed, 97 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 644d0f9eaf8c..1eb45781c850 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -448,6 +448,70 @@
> function = "spi1";
> };
> };
> +
> + uart_a_pins: uart_a {
> + mux {
> + groups = "uart_tx_a",
> + "uart_rx_a";
> + function = "uart_a";
> + };
> + };
> +
> + uart_a_cts_rts_pins: uart_a_cts_rts {
> + mux {
> + groups = "uart_cts_a",
> + "uart_rts_a";
> + function = "uart_a";
> + };
> + };
> +
> + uart_b_x_pins: uart_b_x {
> + mux {
> + groups = "uart_tx_b_x",
> + "uart_rx_b_x";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
> + mux {
> + groups = "uart_cts_b_x",
> + "uart_rts_b_x";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_z_pins: uart_b_z {
> + mux {
> + groups = "uart_tx_b_z",
> + "uart_rx_b_z";
> + function = "uart_b";
> + };
> + };
> +
> + uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
> + mux {
> + groups = "uart_cts_b_z",
> + "uart_rts_b_z";
> + function = "uart_b";
> + };
> + };
> +
> + uart_ao_b_z_pins: uart_ao_b_z {
> + mux {
> + groups = "uart_ao_tx_b_z",
> + "uart_ao_rx_b_z";
> + function = "uart_ao_b_gpioz";
(the following question just came up while I was looking at this
patch, but I guess it's more a question towards the pinctrl driver)
the name of the function looks a bit "weird" since below you are also
using "uart_ao_b"
did you choose "uart_ao_b_gpioz" here because we cannot have the same
function name for the periphs and AO pinctrl or is there some other
reason?
I am asking because I would have expected it to look like this:
groups = "uart_ao_tx_b_z", "uart_ao_rx_b_z";
function = "uart_ao_b";
(same for the cts/rts pins below)
> + };
> + };
> +
> + uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts
> {
> + mux {
> + groups = "uart_ao_cts_b_z",
> + "uart_ao_rts_b_z";
> + function = "uart_ao_b_gpioz";
> + };
> + };
> };
> };
>
> @@ -492,12 +556,45 @@
> gpio-ranges = <&pinctrl_aobus 0 0 15>;
> };
>
> +
did you add this additional newline on purpose?
> remote_input_ao_pins: remote_input_ao {
Re: [PATCH 1/3] mtd: spi-nor: add optional DMA-safe bounce buffer for data transfer
Hi Cyrille,
On Sun, 24 Dec 2017 05:36:04 +0100
Cyrille Pitchen wrote:
> This patch has two purposes:
>
> 1 - To fix the compatible issue between the MTD and SPI sub-systems
>
> The MTD sub-system has no particular requirement about the memory areas it
> uses. Especially, ubifs is well known for using vmalloc'ed buffers, which
> then are not DMA-safe. There are reasons behind that, so we have to deal
> with it.
Well, the only reason is that it's easier to deal with
virtually contiguous memory region, and since the LEB/PEB size can be
quite big (especially for NAND devices) we have to allocate it with
vmalloc() to prevent memory fragmentation.
The solution would be to allocate an array of ubi->min_io_size buffers
using kzalloc() and write/read to/from the MTD device using this
granularity, but this approach would require quite a few changes and
that's not the topic here.
>
> On the other hand, the SPI sub-system clearly states in the kernel doc for
> 'struct spi-transfer' (include/linux/spi/spi.h) that both .tx_buf and
> .rx_buf must point into "dma-safe memory". This requirement has not been
> taken into account by the m25p80.c driver, at the border between MTD and
> SPI, for a long time now. So it's high time to fix this issue.
I agree, even if I guess the MTD layer is not the only offender and
having this bounce buffer logic at the SPI level would be even better
IMO. But let's solve the problem in the SPI-NOR layer for now.
>
> 2 - To help other SPI flash controller drivers to perform DMA transfers
>
> Those controller drivers suffer the same issue as those behind the
> m25p80.c driver in the SPI sub-system: They may be provided by the MTD
> sub-system with buffers not suited to DMA operations. We want to avoid
> each controller to implement its own bounce buffer so we offer them some
> optional bounce buffer, allocated and managed by the spi-nor framework
> itself, as an helper to add support to DMA transfers.
>
> Then the patch adds two hardware capabilities for SPI flash controllers,
> SNOR_HWCAPS_WR_BOUNCE and SNOR_HWCAPS_RD_BOUNCE.
Do you have good reasons to handle the read/write path independently? I
mean, if you need a bounce buffer for one of them it's likely that
you'll need it for both.
>
> SPI flash controller drivers are supposed to use them to request the
> spi-nor framework to allocate an optional bounce buffer in some
> DMA-safe memory area then to use it in some cases during (Fast) Read
> and/or Page Program operations.
>
> More precisely, the bounce buffer is used if and only if two conditions
> are met:
> 1 - The SPI flash controller driver has declared the
> SNOR_HWCAPS_RD_BOUNCE, resp. SNOR_HWCAPS_WR_BOUNCE for (Fast) Read,
> resp. Page Program operations.
> 2 - The buffer provided by the above MTD layer is not already in a
> DMA-safe area.
>
> This policy avoid using the bounce buffer when not explicitly requested
> or when not needed, hence limiting the performance penalty.
>
> Besides, the bounce buffer is allocated once for all at the very first
> time it is actually needed.
Hm, I think it would be better to allocate the buffer at detection/probe
time, when you have all the information you need (sector_size?). My
fear is that you might not be able to kmalloc() a large buffer the
first time a read/write operation is performed, and that means the
operation might randomly fail/succeed depending on when the first IO
operation is done. If you do it at probe time, you'll be able to detect
the allocation failure early and stop the MTD dev registration when
this is the case.
> This means that as long as all buffers
> provided by the above MTD layer are allocated in some DMA-safe areas, the
> bounce buffer itself is never allocated.
>
> Finally, the bounce buffer size is limited to 256KiB, the currently known
> maximum erase sector size. This tradeoff should still provide good
> performances even if new memory parts come with even larger erase sector
> sizes, limiting the memory footprint at the same time.
>
> Signed-off-by: Cyrille Pitchen
> ---
> drivers/mtd/devices/m25p80.c | 4 +-
> drivers/mtd/spi-nor/spi-nor.c | 136
> +++---
> include/linux/mtd/spi-nor.h | 8 +++
> 3 files changed, 139 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index a4e18f6aaa33..60878c62a654 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -239,7 +239,9 @@ static int m25p_probe(struct spi_device *spi)
> struct spi_nor_hwcaps hwcaps = {
> .mask = SNOR_HWCAPS_READ |
> SNOR_HWCAPS_READ_FAST |
> - SNOR_HWCAPS_PP,
> + SNOR_HWCAPS_PP |
> + SNOR_HWCAPS_RD_BOUNCE |
> + SNOR_HWCAPS_WR_BOUNCE,
> };
> char *flash_name;
> int ret;
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
[PATCH] EDAC, mv64x60: Fix an error handling path
We should not call 'edac_mc_del_mc()' if a corresponding call to 'edac_mc_add_mc()' has not been performed yet. So here, we should go to err instead of err2 to branch at the right place of the error handling path. Signed-off-by: Christophe JAILLET --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c index ec5d695bbb72..3c68bb525d5d 100644 --- a/drivers/edac/mv64x60_edac.c +++ b/drivers/edac/mv64x60_edac.c @@ -758,7 +758,7 @@ static int mv64x60_mc_err_probe(struct platform_device *pdev) /* Non-ECC RAM? */ printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__); res = -ENODEV; - goto err2; + goto err; } edac_dbg(3, "init mci\n"); -- 2.14.1
Re: [PATCH v2 net-next] net: tracepoint: exposing sk_faimily in tracepoint inet_sock_set_state
> On Jan 6, 2018, at 10:31 PM, Yafang Shao wrote:
>
> As of now, there're two sk_family are traced with sock:inet_sock_set_state,
> which are AF_INET and AF_INET6.
> So the sk_family are exposed as well.
> Then we can conveniently use it to do the filter.
>
> Both sk_family and sk_protocol are showed in the printk message, so we need
> not expose them as tracepoint arguments.
>
> Suggested-by: Brendan Gregg
> Suggested-by: Song Liu
> Signed-off-by: Yafang Shao
> ---
> include/trace/events/sock.h | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
> index 3537c5f..3176a39 100644
> --- a/include/trace/events/sock.h
> +++ b/include/trace/events/sock.h
> @@ -11,7 +11,11 @@
> #include
> #include
>
> -/* The protocol traced by sock_set_state */
> +#define family_names \
> + EM(AF_INET) \
> + EMe(AF_INET6)
> +
> +/* The protocol traced by inet_sock_set_state */
> #define inet_protocol_names \
> EM(IPPROTO_TCP) \
> EM(IPPROTO_DCCP)\
> @@ -37,6 +41,7 @@
> #define EM(a) TRACE_DEFINE_ENUM(a);
> #define EMe(a) TRACE_DEFINE_ENUM(a);
>
> +family_names
> inet_protocol_names
> tcp_state_names
>
> @@ -45,6 +50,9 @@
> #define EM(a) { a, #a },
> #define EMe(a) { a, #a }
>
> +#define show_family_name(val)\
> + __print_symbolic(val, family_names)
> +
> #define show_inet_protocol_name(val)\
> __print_symbolic(val, inet_protocol_names)
>
> @@ -118,6 +126,7 @@
> __field(int, newstate)
> __field(__u16, sport)
> __field(__u16, dport)
> + __field(__u16, family)
> __field(__u8, protocol)
> __array(__u8, saddr, 4)
> __array(__u8, daddr, 4)
> @@ -134,6 +143,7 @@
> __entry->oldstate = oldstate;
> __entry->newstate = newstate;
>
> + __entry->family = sk->sk_family;
> __entry->protocol = sk->sk_protocol;
> __entry->sport = ntohs(inet->inet_sport);
> __entry->dport = ntohs(inet->inet_dport);
> @@ -160,7 +170,8 @@
> }
> ),
>
> - TP_printk("protocol=%s sport=%hu dport=%hu saddr=%pI4 daddr=%pI4
> saddrv6=%pI6c daddrv6=%pI6c oldstate=%s newstate=%s",
> + TP_printk("family=%s protocol=%s sport=%hu dport=%hu saddr=%pI4
> daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c oldstate=%s newstate=%s",
> + show_family_name(__entry->family),
> show_inet_protocol_name(__entry->protocol),
> __entry->sport, __entry->dport,
> __entry->saddr, __entry->daddr,
> --
> 1.8.3.1
>
Reviewed-by: Song Liu
Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
On Sun, 7 Jan 2018, Linus Torvalds wrote: > We need to fix the security problem, but we need to do it *without* > these braindead arguments that performance is somehow secondary. I surely agree, but we have gone the way of PTI without the ability of exempting individual processes exactly for one reason: Lack of time It can be done on top of the PTI implementation and it won't take ages. For spectre_v1/2 we face the same problem simply because we got informed so much ahead of time and we were all twiddling thumbs, enjoying our christmas vacation and having a good time. The exploits are out in the wild and they are observed already, so we really have to make a decision whether we want to fix that in the most obvious ways even if it hurts performance right now and then take a break from all that hell and sit down and sort the performance mess or whether we want to discuss the right way to fix it for the next 3 month and leave all doors open until the last bit of performance is squeezed out. I totally can understand the anger of those who learned all of this a few days ago and are now grasping straws to avoid the obviously coming performance hit, but its not our fault that we have to make a decision which cannot make everyone happy tomorrow. If the general sentiment is that we have to fix the performance issue first, then please let me know and I take 3 weeks of vacation right now. Thanks, tglx
Re: [RFC PATCH 13/12] Retpoline vs. CONFIG_TRIM_UNUSED_SYMBOLS
On Sun, 2018-01-07 at 18:32 +, Lu, Hongjiu wrote: > > > What's the plan for these vs. official GCC? Is that stuff going to part of > > GCC > > and if so, which versions of GCC will have that? > > If I get positive feedbacks from kernel folks with my GCC 7 patches today, I > will submit my patches for GCC 8 today. After they are checked in, I will > backport them to GCC 7/6/5/4.9. I've pushed a new kernel retpoline branch tested with the changes I made myself. Building your patch set now, both locally and at https://koji.fedoraproject.org/koji/taskinfo?taskID=24065739 smime.p7s Description: S/MIME cryptographic signature
[PATCH 0/2] misc/apds9802als: Adjustments for apds9802als_probe()
From: Markus Elfring Date: Sun, 7 Jan 2018 21:58:42 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/misc/apds9802als.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) -- 2.15.1
[PATCH 1/2] misc/apds9802als: Delete an error message for a failed memory allocation in apds9802als_probe()
From: Markus Elfring
Date: Sun, 7 Jan 2018 21:42:07 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/misc/apds9802als.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index d8ac036f01ab..fa548796c92e 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -231,10 +231,9 @@ static int apds9802als_probe(struct i2c_client *client,
struct als_data *data;
data = kzalloc(sizeof(struct als_data), GFP_KERNEL);
- if (data == NULL) {
- dev_err(&client->dev, "Memory allocation failed\n");
+ if (!data)
return -ENOMEM;
- }
+
i2c_set_clientdata(client, data);
res = sysfs_create_group(&client->dev.kobj, &m_als_gr);
if (res) {
--
2.15.1
[PATCH 2/2] misc/apds9802als: Improve a size determination in apds9802als_probe()
From: Markus Elfring
Date: Sun, 7 Jan 2018 21:48:50 +0100
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/misc/apds9802als.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index fa548796c92e..acf467666737 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -228,9 +228,8 @@ static int apds9802als_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
int res;
- struct als_data *data;
+ struct als_data *data = kzalloc(sizeof(*data), GFP_KERNEL);
- data = kzalloc(sizeof(struct als_data), GFP_KERNEL);
if (!data)
return -ENOMEM;
--
2.15.1
[patch 0/2] sysfs/cpu: Implement generic vulnerabilites directory
The meltdown/spectre vulnerabilities affect several architectures and people are asking for a common way to figure out whether a system is affected or not. Create /sys/devices/system/cpu/vulnerabilites and the files /sys/devices/system/cpu/vulnerabilites/meltdown /sys/devices/system/cpu/vulnerabilites/spectre_v1 /sys/devices/system/cpu/vulnerabilites/spectre_v2 Add the x86 implementation which shows: meltdownMitigation: PTI spectre_v1 Vulnerable sepctre_v1 Vulnerable On an AMD CPU the output of meltdown is: Not affected. If PTI is turned off and the CPU is affected of meltdown the output becomes: Vulnerable That series applies on top of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/pti Thanks, tglx
[patch 1/2] sysfs/cpu: Add vulnerability folder
As the meltdown/spectre problem affects several CPU architectures, it makes
sense to have common way to express whether a system is affected by a
particular vulnerability or not. If affected the way to express the
mitigation should be common as well.
Create /sys/devices/system/cpu/vulnerabilities folder and files for
meltdown, spectre_v1 and spectre_v2.
Allow architextures to override the show function.
Signed-off-by: Thomas Gleixner
---
drivers/base/Kconfig |3 +++
drivers/base/cpu.c | 48
include/linux/cpu.h |7 +++
3 files changed, 58 insertions(+)
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -235,6 +235,9 @@ config GENERIC_CPU_DEVICES
config GENERIC_CPU_AUTOPROBE
bool
+config GENERIC_CPU_VULNERABILITIES
+ bool
+
config SOC_BUS
bool
select GLOB
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -501,10 +501,58 @@ static void __init cpu_dev_register_gene
#endif
}
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t __weak cpu_show_meltdown(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
+}
+
+ssize_t __weak cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
+}
+
+ssize_t __weak cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
+}
+
+static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
+static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
+static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
+
+static struct attribute *cpu_root_vulnerabilities_attrs[] = {
+ &dev_attr_meltdown.attr,
+ &dev_attr_spectre_v1.attr,
+ &dev_attr_spectre_v2.attr,
+ NULL
+};
+
+static const struct attribute_group cpu_root_vulnerabilities_group = {
+ .name = "vulnerabilities",
+ .attrs = cpu_root_vulnerabilities_attrs,
+};
+
+static void __init cpu_register_vulnerabilities(void)
+{
+ if (sysfs_create_group(&cpu_subsys.dev_root->kobj,
+ &cpu_root_vulnerabilities_group))
+ pr_err("Unable to register CPU vulnerabilities\n");
+}
+
+#else
+static inline void cpu_register_vulnerabilities(void) { }
+#endif
+
void __init cpu_dev_init(void)
{
if (subsys_system_register(&cpu_subsys, cpu_root_attr_groups))
panic("Failed to register CPU subsystem");
cpu_dev_register_generic();
+ cpu_register_vulnerabilities();
}
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -47,6 +47,13 @@ extern void cpu_remove_dev_attr(struct d
extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
+extern ssize_t cpu_show_meltdown(struct device *dev,
+struct device_attribute *attr, char *buf);
+extern ssize_t cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf);
+extern ssize_t cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
extern __printf(4, 5)
struct device *cpu_device_create(struct device *parent, void *drvdata,
const struct attribute_group **groups,
[patch 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions
Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and
spectre_v2.
Signed-off-by: Thomas Gleixner
---
arch/x86/Kconfig |1 +
arch/x86/kernel/cpu/bugs.c | 29 +
2 files changed, 30 insertions(+)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -89,6 +89,7 @@ config X86
select GENERIC_CLOCKEVENTS_MIN_ADJUST
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+ select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_FIND_FIRST_BIT
select GENERIC_IOMAP
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -10,6 +10,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -60,3 +61,31 @@ void __init check_bugs(void)
set_memory_4k((unsigned long)__va(0), 1);
#endif
}
+
+#ifdef CONFIG_SYSFS
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN))
+ return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
+ if (boot_cpu_has(X86_FEATURE_PTI))
+ return snprintf(buf, PAGE_SIZE - 2, "Mitigation: PTI\n");
+ return snprintf(buf, PAGE_SIZE - 2, "Vulnerable\n");
+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V1))
+ return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
+ return snprintf(buf, PAGE_SIZE - 2, "Vulnerable\n");
+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
+ return snprintf(buf, PAGE_SIZE - 2, "Vulnerable\n");
+}
+#endif
Re: [patch 1/2] sysfs/cpu: Add vulnerability folder
On Sun, Jan 07, 2018 at 09:57:50PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
>
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
I like this, minor nits below:
>
> Allow architextures to override the show function.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/base/Kconfig |3 +++
> drivers/base/cpu.c | 48
> include/linux/cpu.h |7 +++
> 3 files changed, 58 insertions(+)
A Documentation/ABI/ update is needed for the new sysfs files.
> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
sysfs is one-value-per-file, so you never need to care about the page
size, a simple sprintf() is fine. No need to change if you don't want
to, your call.
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
> +}
> +
> +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
DEVICE_ATTR_RO() please.
Yeah, that does make the global symbols a bit different, meltdown_show()
and the like. Hm, I guess this is ok, given that it's ment to be
overridden.
Oh, nevermind. So, just a documentation update please, that can always
be an add-on patch if you promise to do it :)
thanks,
greg k-h
Re: dvb usb issues since kernel 4.9
On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab wrote: > > Em Sat, 6 Jan 2018 16:04:16 +0100 > "Josef Griebichler" escreveu: >> >> the causing commit has been identified. >> After reverting commit >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 >> its working again. > > Just replying to me won't magically fix this. The ones that were involved on > this patch should also be c/c, plus USB people. Just added them. Actually, you seem to have added an odd subset of the people involved. For example, Ingo - who actually committed that patch - wasn't on the cc. I do think we need to simply revert that patch. It's very simple: it has been reported to lead to actual problems for people, and we don't fix one problem and then say "well, it fixed something else" when something breaks. When something breaks, we either unbreak it, or we revert the change that caused the breakage. It's really that simple. That's what "no regressions" means. We don't accept changes that cause regressions. This one did. Linus
[PATCH 0/2] misc/fsa9480: Adjustments for fsa9480_probe()
From: Markus Elfring Date: Sun, 7 Jan 2018 22:26:44 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/misc/fsa9480.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.15.1
[PATCH 1/2] misc/fsa9480: Delete an error message for a failed memory allocation in fsa9480_probe()
From: Markus Elfring
Date: Sun, 7 Jan 2018 22:17:53 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/misc/fsa9480.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/fsa9480.c b/drivers/misc/fsa9480.c
index 71d2793b372c..4d7f763195bc 100644
--- a/drivers/misc/fsa9480.c
+++ b/drivers/misc/fsa9480.c
@@ -418,10 +418,8 @@ static int fsa9480_probe(struct i2c_client *client,
return -EIO;
usbsw = kzalloc(sizeof(struct fsa9480_usbsw), GFP_KERNEL);
- if (!usbsw) {
- dev_err(&client->dev, "failed to allocate driver data\n");
+ if (!usbsw)
return -ENOMEM;
- }
usbsw->client = client;
usbsw->pdata = client->dev.platform_data;
--
2.15.1
[PATCH 2/2] misc/fsa9480: Improve a size determination in fsa9480_probe()
From: Markus Elfring Date: Sun, 7 Jan 2018 22:20:19 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/misc/fsa9480.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/fsa9480.c b/drivers/misc/fsa9480.c index 4d7f763195bc..bf199cd5fce9 100644 --- a/drivers/misc/fsa9480.c +++ b/drivers/misc/fsa9480.c @@ -417,7 +417,7 @@ static int fsa9480_probe(struct i2c_client *client, if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) return -EIO; - usbsw = kzalloc(sizeof(struct fsa9480_usbsw), GFP_KERNEL); + usbsw = kzalloc(sizeof(*usbsw), GFP_KERNEL); if (!usbsw) return -ENOMEM; -- 2.15.1
Re: [patch 1/2] sysfs/cpu: Add vulnerability folder
On Sun, 7 Jan 2018, Greg Kroah-Hartman wrote:
> > drivers/base/Kconfig |3 +++
> > drivers/base/cpu.c | 48
> >
> > include/linux/cpu.h |7 +++
> > 3 files changed, 58 insertions(+)
>
> A Documentation/ABI/ update is needed for the new sysfs files.
Sure.
> > +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> > +
> > +ssize_t __weak cpu_show_meltdown(struct device *dev,
> > +struct device_attribute *attr, char *buf)
> > +{
> > + return snprintf(buf, PAGE_SIZE - 2, "Not affected\n");
>
> sysfs is one-value-per-file, so you never need to care about the page
> size, a simple sprintf() is fine. No need to change if you don't want
> to, your call.
Done.
> > +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
>
> DEVICE_ATTR_RO() please.
>
> Yeah, that does make the global symbols a bit different, meltdown_show()
> and the like. Hm, I guess this is ok, given that it's ment to be
> overridden.
That and I expect that in the not so distant future we'll see write
functions as well.
> Oh, nevermind. So, just a documentation update please, that can always
> be an add-on patch if you promise to do it :)
You should never make such offers. These promises land on that growth only
thingy, aka. todo list :)
Thanks,
tglx
[PATCH v2] tools: fix cross-compile var clobbering
From: Martin Kelly
Currently a number of Makefiles break when used with toolchains that pass
extra flags in CC and other cross-compile related variables (such as
--sysroot). Thus we get this error when we use a toolchain that puts
--sysroot in the CC var:
~/src/linux/tools$ make iio
[snip]
iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
#include
^~
This occurs because we clobber several env vars related to cross-compiling
with lines like this:
CC = $(CROSS_COMPILE)gcc
Although this will point to a valid cross-compiler, we lose any extra flags
that might exist in the CC variable, which can break toolchains that rely
on them (for example, those that use --sysroot). This easily shows up using
a Yocto SDK:
$ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a8
--sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi
$ echo $CROSS_COMPILE
arm-poky-linux-gnueabi-
$ echo ${CROSS_COMPILE}gcc
krm-poky-linux-gnueabi-gcc
Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
--sysroot and other flags that enable us to find the right libraries to
link against, so we can't find unistd.h and other libraries and headers.
Normally with the --sysroot flag we would find unistd.h in the sdk
directory in the sysroot:
$ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h
The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
already set, and it compiles correctly with the above toolchain.
So, generalize the logic that perf uses in the common Makefile and remove
the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.
Note that this patch does not fix cross-compile for all the tools (some
have other bugs), but it does fix it for all except usb and acpi, which
still have other unrelated issues.
I tested both with and without the patch on native and cross-build and
there appear to be no regressions.
Cc: Tejun Heo
Cc: Li Zefan
Cc: Johannes Weiner
Cc: Linus Walleij
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Jonathan Cameron
Cc: Pali Rohár
Cc: Richard Purdie
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Robert Moore
Cc: Lv Zheng
Cc: "Rafael J. Wysocki"
Cc: Mark Brown
Cc: Greg Kroah-Hartman
Cc: Valentina Manea
Cc: Shuah Khan
Cc: Shuah Khan
Cc: Mario Limonciello
Cc: Andrew Morton
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Martin Kelly
---
Since there is no globals tools maintainer, I'm sending this to linux-kbuild as
the closest match and CC-ing all affected subsystem maintainers. If no one has
objections, I'm hoping Andrew Morton can pull in the patch.
v2:
- Expand commit description to fill in more detail and CC all relevant
maintainers.
- Fix small typo related to the STRIP variable.
tools/cgroup/Makefile| 1 -
tools/gpio/Makefile | 2 --
tools/hv/Makefile| 1 -
tools/iio/Makefile | 2 --
tools/laptop/freefall/Makefile | 1 -
tools/leds/Makefile | 1 -
tools/perf/Makefile.perf | 6 --
tools/power/acpi/Makefile.config | 3 ---
tools/scripts/Makefile.include | 18 ++
tools/spi/Makefile | 2 --
tools/usb/Makefile | 1 -
tools/vm/Makefile| 1 -
tools/wmi/Makefile | 1 -
13 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/tools/cgroup/Makefile b/tools/cgroup/Makefile
index 860fa151640a..ffca068e4a76 100644
--- a/tools/cgroup/Makefile
+++ b/tools/cgroup/Makefile
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for cgroup tools
-CC = $(CROSS_COMPILE)gcc
CFLAGS = -Wall -Wextra
all: cgroup_event_listener
diff --git a/tools/gpio/Makefile b/tools/gpio/Makefile
index 805a2c0cf4cd..240eda014b37 100644
--- a/tools/gpio/Makefile
+++ b/tools/gpio/Makefile
@@ -12,8 +12,6 @@ endif
# (this improves performance and avoids hard-to-debug behaviour);
MAKEFLAGS += -r
-CC = $(CROSS_COMPILE)gcc
-LD = $(CROSS_COMPILE)ld
CFLAGS += -O2 -Wall -g -D_GNU_SOURCE -I$(OUTPUT)include
ALL_TARGETS := lsgpio gpio-hammer gpio-event-mon
diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index 31503819454d..68c2d7b059b3 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for Hyper-V tools
-CC = $(CROSS_COMPILE)gcc
WARNINGS = -Wall -Wextra
CFLAGS = $(WARNINGS) -g $(shell getconf LFS_CFLAGS)
diff --git a/tools/iio/Makefile b/tools/iio/Makefile
index a08e7a47d6a3..332ed2f6c2c2 100644
--- a/tools/iio/Makefile
+++ b/tools/iio/Makefile
@@ -12,8 +12,6 @@ endif
# (this improves performance and avoids hard-to-debug behaviour);
MAKEFLAGS += -r
-CC = $(CROSS_COMPILE)gcc
-LD = $(CROS
Re: [PATCH] tools: fix cross-compile var export
On 01/07/2018 11:04 AM, Paul Gortmaker wrote: [Re: [PATCH] tools: fix cross-compile var export] On 07/01/2018 (Sun 10:31) Martin Kelly wrote: [...] With the change, we add do CC = $(CROSS_COMPILE)gcc if and only if CC is not already set. I'm happy to add all these details to the commit description. That is probably a step in the right direction. I contribute to yocto on a regular basis and hence am sympathetic to these frustrating SDK type issues. But after a quick scan of this patch it wasn't obvious to me that existing behaviour was preserved, or that it would be a pain to separate it into chunks. (key word here being "quick") So I'd recommend updating the commit log, and adding a Cc: line for the maintainers of each subsystem below, and then if nobody complains you might get akpm to pick it up as he does for other patches w/o a clear maintainer or subsystem. P Thanks, I have done so. I also contribute to Yocto and indeed, SDK issues are all-to-common.
[patch V2 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions
Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and
spectre_v2.
Signed-off-by: Thomas Gleixner
---
arch/x86/Kconfig |1 +
arch/x86/kernel/cpu/bugs.c | 29 +
2 files changed, 30 insertions(+)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -89,6 +89,7 @@ config X86
select GENERIC_CLOCKEVENTS_MIN_ADJUST
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+ select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_FIND_FIRST_BIT
select GENERIC_IOMAP
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -10,6 +10,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -60,3 +61,31 @@ void __init check_bugs(void)
set_memory_4k((unsigned long)__va(0), 1);
#endif
}
+
+#ifdef CONFIG_SYSFS
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN))
+ return sprintf(buf, "Not affected\n");
+ if (boot_cpu_has(X86_FEATURE_PTI))
+ return sprintf(buf, "Mitigation: PTI\n");
+ return sprintf(buf, "Vulnerable\n");
+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V1))
+ return sprintf(buf, "Not affected\n");
+ return sprintf(buf, "Vulnerable\n");
+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ return sprintf(buf, "Not affected\n");
+ return sprintf(buf, "Vulnerable\n");
+}
+#endif
[patch V2 0/2] sysfs/cpu: Implement generic vulnerabilites directory
The meltdown/spectre vulnerabilities affect several architectures and people are asking for a common way to figure out whether a system is affected or not. Create /sys/devices/system/cpu/vulnerabilites and the files /sys/devices/system/cpu/vulnerabilites/meltdown /sys/devices/system/cpu/vulnerabilites/spectre_v1 /sys/devices/system/cpu/vulnerabilites/spectre_v2 Add the x86 implementation which shows: meltdownMitigation: PTI spectre_v1 Vulnerable sepctre_v1 Vulnerable On an AMD CPU the output of meltdown is: Not affected. If PTI is turned off and the CPU is affected of meltdown the output becomes: Vulnerable That series applies on top of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/pti V1 -> V2: Add documentation and use sprintf Thanks, tglx
[patch V2 1/2] sysfs/cpu: Add vulnerability folder
As the meltdown/spectre problem affects several CPU architectures, it makes
sense to have common way to express whether a system is affected by a
particular vulnerability or not. If affected the way to express the
mitigation should be common as well.
Create /sys/devices/system/cpu/vulnerabilities folder and files for
meltdown, spectre_v1 and spectre_v2.
Allow architectures to override the show function.
Signed-off-by: Thomas Gleixner
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 16 +++
drivers/base/Kconfig |3 +
drivers/base/cpu.c | 48 +
include/linux/cpu.h|7 +++
4 files changed, 74 insertions(+)
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -373,3 +373,19 @@ Contact: Linux kernel mailing list
+Description: Information about CPU vulnerabilities
+
+ The files are named after the code names of CPU
+ vulnerabilities. The output of those files reflects the
+ state of the CPUs in the system. Possible output values:
+
+ "Not affected"CPU is not affected by the vulnerability
+ "Vulnerable" CPU is affected and no mitigation in effect
+ "Mitigation: $M" CPU is affetcted and mitigation $M is in
effect
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -235,6 +235,9 @@ config GENERIC_CPU_DEVICES
config GENERIC_CPU_AUTOPROBE
bool
+config GENERIC_CPU_VULNERABILITIES
+ bool
+
config SOC_BUS
bool
select GLOB
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -501,10 +501,58 @@ static void __init cpu_dev_register_gene
#endif
}
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t __weak cpu_show_meltdown(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "Not affected\n");
+}
+
+ssize_t __weak cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "Not affected\n");
+}
+
+ssize_t __weak cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "Not affected\n");
+}
+
+static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
+static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
+static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
+
+static struct attribute *cpu_root_vulnerabilities_attrs[] = {
+ &dev_attr_meltdown.attr,
+ &dev_attr_spectre_v1.attr,
+ &dev_attr_spectre_v2.attr,
+ NULL
+};
+
+static const struct attribute_group cpu_root_vulnerabilities_group = {
+ .name = "vulnerabilities",
+ .attrs = cpu_root_vulnerabilities_attrs,
+};
+
+static void __init cpu_register_vulnerabilities(void)
+{
+ if (sysfs_create_group(&cpu_subsys.dev_root->kobj,
+ &cpu_root_vulnerabilities_group))
+ pr_err("Unable to register CPU vulnerabilities\n");
+}
+
+#else
+static inline void cpu_register_vulnerabilities(void) { }
+#endif
+
void __init cpu_dev_init(void)
{
if (subsys_system_register(&cpu_subsys, cpu_root_attr_groups))
panic("Failed to register CPU subsystem");
cpu_dev_register_generic();
+ cpu_register_vulnerabilities();
}
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -47,6 +47,13 @@ extern void cpu_remove_dev_attr(struct d
extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
+extern ssize_t cpu_show_meltdown(struct device *dev,
+struct device_attribute *attr, char *buf);
+extern ssize_t cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf);
+extern ssize_t cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
extern __printf(4, 5)
struct device *cpu_device_create(struct device *parent, void *drvdata,
const struct attribute_group **groups,
Re: [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
Stefan Wahren writes: > This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a. > > The DT clean up could trigger an endless deferred probe of DWC2 USB driver > on the Raspberry Pi 2/3. So revert the change until we fixed the probing > issue. Why's that? I found that I needed to enable the generic no-op phy driver, but other than that it was fine. signature.asc Description: PGP signature
[PATCH v6 01/10] x86/retpoline: Add initial retpoline support
Enable the use of -mindirect-branch=thunk-extern in newer GCC, and provide the corresponding thunks. Provide assembler macros for invoking the thunks in the same way that GCC does, from native and inline assembler. This adds X86_FEATURE_RETPOLINE and sets it by default on all CPUs. In some circumstances, IBRS microcode features may be used instead, and the retpoline can be disabled. On AMD CPUs if lfence is serialising, the retpoline can be dramatically simplified to a simple "lfence; jmp *\reg". A future patch, after it has been verified that lfence really is serialising in all circumstances, can enable this by setting the X86_FEATURE_RETPOLINE_AMD feature bit in addition to X86_FEATURE_RETPOLINE. [Andi Kleen: Rename the macros, add CONFIG_RETPOLINE option, export thunks] Signed-off-by: David Woodhouse Acked-By: Arjan van de Ven --- arch/x86/Kconfig | 13 + arch/x86/Makefile | 10 arch/x86/include/asm/asm-prototypes.h | 25 ++ arch/x86/include/asm/cpufeatures.h| 2 + arch/x86/include/asm/nospec-branch.h | 92 +++ arch/x86/kernel/cpu/common.c | 3 ++ arch/x86/lib/Makefile | 1 + arch/x86/lib/retpoline.S | 48 ++ 8 files changed, 194 insertions(+) create mode 100644 arch/x86/include/asm/nospec-branch.h create mode 100644 arch/x86/lib/retpoline.S diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index cd5199d..77c58ae 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -428,6 +428,19 @@ config GOLDFISH def_bool y depends on X86_GOLDFISH +config RETPOLINE + bool "Avoid speculative indirect branches in kernel" + default y + help + Compile kernel with the retpoline compiler options to guard against + kernel-to-user data leaks by avoiding speculative indirect + branches. Requires a compiler with -mindirect-branch=thunk-extern + support for full protection. The kernel may run slower. + + Without compiler support, at least indirect branches in assembler + code are eliminated. Since this includes the syscall entry path, + it is not entirely pointless. + config INTEL_RDT bool "Intel Resource Director Technology support" default n diff --git a/arch/x86/Makefile b/arch/x86/Makefile index a20eacd..918e550 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -235,6 +235,16 @@ KBUILD_CFLAGS += -Wno-sign-compare # KBUILD_CFLAGS += -fno-asynchronous-unwind-tables +# Avoid indirect branches in kernel to deal with Spectre +ifdef CONFIG_RETPOLINE +RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern -mindirect-branch-register) +ifneq ($(RETPOLINE_CFLAGS),) +KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE +else +$(warning Retpoline not supported in compiler. System may be insecure.) +endif +endif + archscripts: scripts_basic $(Q)$(MAKE) $(build)=arch/x86/tools relocs diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h index ff700d8..0927cdc 100644 --- a/arch/x86/include/asm/asm-prototypes.h +++ b/arch/x86/include/asm/asm-prototypes.h @@ -11,7 +11,32 @@ #include #include #include +#include #ifndef CONFIG_X86_CMPXCHG64 extern void cmpxchg8b_emu(void); #endif + +#ifdef CONFIG_RETPOLINE +#ifdef CONFIG_X86_32 +#define INDIRECT_THUNK(reg) extern asmlinkage void __x86_indirect_thunk_e ## reg(void); +#else +#define INDIRECT_THUNK(reg) extern asmlinkage void __x86_indirect_thunk_r ## reg(void); +INDIRECT_THUNK(8) +INDIRECT_THUNK(9) +INDIRECT_THUNK(10) +INDIRECT_THUNK(11) +INDIRECT_THUNK(12) +INDIRECT_THUNK(13) +INDIRECT_THUNK(14) +INDIRECT_THUNK(15) +#endif +INDIRECT_THUNK(ax) +INDIRECT_THUNK(bx) +INDIRECT_THUNK(cx) +INDIRECT_THUNK(dx) +INDIRECT_THUNK(si) +INDIRECT_THUNK(di) +INDIRECT_THUNK(bp) +INDIRECT_THUNK(sp) +#endif /* CONFIG_RETPOLINE */ diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 511d909..2d65438 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -203,6 +203,8 @@ #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */ #define X86_FEATURE_SME( 7*32+10) /* AMD Secure Memory Encryption */ #define X86_FEATURE_PTI( 7*32+11) /* Kernel Page Table Isolation enabled */ +#define X86_FEATURE_RETPOLINE ( 7*32+12) /* Intel Retpoline mitigation for Spectre variant 2 */ +#define X86_FEATURE_RETPOLINE_AMD ( 7*32+13) /* AMD Retpoline mitigation for Spectre variant 2 */ #define X86_FEATURE_INTEL_PPIN ( 7*32+14) /* Intel Processor Inventory Number */ #define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */ #define X86_FEATURE_AVX512_4VNNIW ( 7*32+16) /* AVX-512 Neural Network Instructions */ diff --git a/arch/x86/include/asm/nospec-branc
[PATCH v6 04/10] x86/retpoline/ftrace: Convert ftrace assembler indirect jumps
Convert all indirect jumps in ftrace assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by: David Woodhouse Acked-By: Arjan van de Ven --- arch/x86/kernel/ftrace_32.S | 6 -- arch/x86/kernel/ftrace_64.S | 8 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S index b6c6468..c3842c9 100644 --- a/arch/x86/kernel/ftrace_32.S +++ b/arch/x86/kernel/ftrace_32.S @@ -8,6 +8,7 @@ #include #include #include +#include #ifdef CC_USING_FENTRY # define function_hook __fentry__ @@ -197,7 +198,8 @@ ftrace_stub: movl0x4(%ebp), %edx subl$MCOUNT_INSN_SIZE, %eax - call*ftrace_trace_function + movlftrace_trace_function, %ecx + NOSPEC_CALL %ecx popl%edx popl%ecx @@ -241,5 +243,5 @@ return_to_handler: movl%eax, %ecx popl%edx popl%eax - jmp *%ecx + NOSPEC_JMP %ecx #endif diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index c832291..0893068 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -7,7 +7,7 @@ #include #include #include - +#include .code64 .section .entry.text, "ax" @@ -286,8 +286,8 @@ trace: * ip and parent ip are used and the list function is called when * function tracing is enabled. */ - call *ftrace_trace_function - + movq ftrace_trace_function, %r8 + NOSPEC_CALL %r8 restore_mcount_regs jmp fgraph_trace @@ -329,5 +329,5 @@ GLOBAL(return_to_handler) movq 8(%rsp), %rdx movq (%rsp), %rax addq $24, %rsp - jmp *%rdi + NOSPEC_JMP %rdi #endif -- 2.7.4
[PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel
This is a mitigation for the 'variant 2' attack described in https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html Using GCC patches available from the hjl/indirect/gcc-7-branch/master branch of https://github.com/hjl-tools/gcc/commits/hjl and by manually patching assembler code, all vulnerable indirect branches (that occur after userspace first runs) are eliminated from the kernel. They are replaced with a 'retpoline' call sequence which deliberately prevents speculation. Fedora 27 packages of the updated compiler are available at https://koji.fedoraproject.org/koji/taskinfo?taskID=24065739 v1: Initial post. v2: Add CONFIG_RETPOLINE to build kernel without it. Change warning messages. Hide modpost warning message v3: Update to the latest CET-capable retpoline version Reinstate ALTERNATIVE support v4: Finish reconciling Andi's and my patch sets, bug fixes. Exclude objtool support for now Add 'noretpoline' boot option Add AMD retpoline alternative v5: Silence MODVERSIONS warnings Use pause;jmp loop instead of lfence;jmp Switch to X86_FEATURE_RETPOLINE positive feature logic Emit thunks inline from assembler macros Merge AMD support into initial patch v6: Update to latest GCC patches with no dots in symbols Fix MODVERSIONS properly(ish) Fix typo breaking 32-bit, introduced in V5 Never set X86_FEATURE_RETPOLINE_AMD yet, pending confirmation Andi Kleen (3): x86/retpoline/irq32: Convert assembler indirect jumps x86/retpoline: Add boot time option to disable retpoline x86/retpoline: Exclude objtool with retpoline David Woodhouse (7): x86/retpoline: Add initial retpoline support x86/retpoline/crypto: Convert crypto assembler indirect jumps x86/retpoline/entry: Convert entry assembler indirect jumps x86/retpoline/ftrace: Convert ftrace assembler indirect jumps x86/retpoline/hyperv: Convert assembler indirect jumps x86/retpoline/xen: Convert Xen hypercall indirect jumps x86/retpoline/checksum32: Convert assembler indirect jumps Documentation/admin-guide/kernel-parameters.txt | 3 + arch/x86/Kconfig| 17 - arch/x86/Kconfig.debug | 6 +- arch/x86/Makefile | 10 +++ arch/x86/crypto/aesni-intel_asm.S | 5 +- arch/x86/crypto/camellia-aesni-avx-asm_64.S | 3 +- arch/x86/crypto/camellia-aesni-avx2-asm_64.S| 3 +- arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 3 +- arch/x86/entry/entry_32.S | 5 +- arch/x86/entry/entry_64.S | 12 +++- arch/x86/include/asm/asm-prototypes.h | 25 +++ arch/x86/include/asm/cpufeatures.h | 2 + arch/x86/include/asm/mshyperv.h | 18 ++--- arch/x86/include/asm/nospec-branch.h| 92 + arch/x86/include/asm/xen/hypercall.h| 5 +- arch/x86/kernel/cpu/common.c| 3 + arch/x86/kernel/cpu/intel.c | 11 +++ arch/x86/kernel/ftrace_32.S | 6 +- arch/x86/kernel/ftrace_64.S | 8 +-- arch/x86/kernel/irq_32.c| 9 +-- arch/x86/lib/Makefile | 1 + arch/x86/lib/checksum_32.S | 7 +- arch/x86/lib/retpoline.S| 48 + 23 files changed, 264 insertions(+), 38 deletions(-) create mode 100644 arch/x86/include/asm/nospec-branch.h create mode 100644 arch/x86/lib/retpoline.S -- 2.7.4
[PATCH v6 05/10] x86/retpoline/hyperv: Convert assembler indirect jumps
Convert all indirect jumps in hyperv inline asm code to use non-speculative
sequences when CONFIG_RETPOLINE is enabled.
Signed-off-by: David Woodhouse
Acked-By: Arjan van de Ven
---
arch/x86/include/asm/mshyperv.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 581bb54..6534e57 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
/*
* The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -186,10 +187,11 @@ static inline u64 hv_do_hypercall(u64 control, void
*input, void *output)
return U64_MAX;
__asm__ __volatile__("mov %4, %%r8\n"
-"call *%5"
+NOSPEC_CALL
: "=a" (hv_status), ASM_CALL_CONSTRAINT,
"+c" (control), "+d" (input_address)
-: "r" (output_address), "m" (hv_hypercall_pg)
+: "r" (output_address),
+ THUNK_TARGET(hv_hypercall_pg)
: "cc", "memory", "r8", "r9", "r10", "r11");
#else
u32 input_address_hi = upper_32_bits(input_address);
@@ -200,13 +202,13 @@ static inline u64 hv_do_hypercall(u64 control, void
*input, void *output)
if (!hv_hypercall_pg)
return U64_MAX;
- __asm__ __volatile__("call *%7"
+ __asm__ __volatile__(NOSPEC_CALL
: "=A" (hv_status),
"+c" (input_address_lo), ASM_CALL_CONSTRAINT
: "A" (control),
"b" (input_address_hi),
"D"(output_address_hi), "S"(output_address_lo),
- "m" (hv_hypercall_pg)
+ THUNK_TARGET(hv_hypercall_pg)
: "cc", "memory");
#endif /* !x86_64 */
return hv_status;
@@ -227,10 +229,10 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64
input1)
#ifdef CONFIG_X86_64
{
- __asm__ __volatile__("call *%4"
+ __asm__ __volatile__(NOSPEC_CALL
: "=a" (hv_status), ASM_CALL_CONSTRAINT,
"+c" (control), "+d" (input1)
-: "m" (hv_hypercall_pg)
+: THUNK_TARGET(hv_hypercall_pg)
: "cc", "r8", "r9", "r10", "r11");
}
#else
@@ -238,13 +240,13 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64
input1)
u32 input1_hi = upper_32_bits(input1);
u32 input1_lo = lower_32_bits(input1);
- __asm__ __volatile__ ("call *%5"
+ __asm__ __volatile__ (NOSPEC_CALL
: "=A"(hv_status),
"+c"(input1_lo),
ASM_CALL_CONSTRAINT
: "A" (control),
"b" (input1_hi),
- "m" (hv_hypercall_pg)
+ THUNK_TARGET(hv_hypercall_pg)
: "cc", "edi", "esi");
}
#endif
--
2.7.4
[PATCH v6 03/10] x86/retpoline/entry: Convert entry assembler indirect jumps
Convert indirect jumps in core 32/64bit entry assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Don't use NOSPEC_CALL in entry_SYSCALL_64_fastpath because the return address after the 'call' instruction must be *precisely* at the .Lentry_SYSCALL_64_after_fastpath label for stub_ptregs_64 to work, and the use of alternatives will mess that up unless we play horrid games to prepend with NOPs and make the variants the same length. It's not worth it; in the case where we ALTERNATIVE out the retpoline, the first instruction at __x86.indirect_thunk.rax is going to be a bare jmp *%rax anyway. Signed-off-by: David Woodhouse Acked-By: Arjan van de Ven --- arch/x86/entry/entry_32.S | 5 +++-- arch/x86/entry/entry_64.S | 12 +--- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index ace8f32..cf9ef33 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -44,6 +44,7 @@ #include #include #include +#include .section .entry.text, "ax" @@ -290,7 +291,7 @@ ENTRY(ret_from_fork) /* kernel thread */ 1: movl%edi, %eax - call*%ebx + NOSPEC_CALL %ebx /* * A kernel thread is allowed to return here after successfully * calling do_execve(). Exit to userspace to complete the execve() @@ -919,7 +920,7 @@ common_exception: movl%ecx, %es TRACE_IRQS_OFF movl%esp, %eax # pt_regs pointer - call*%edi + NOSPEC_CALL %edi jmp ret_from_exception END(common_exception) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index ed31d00..9bce6ed 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -37,6 +37,7 @@ #include #include #include +#include #include #include "calling.h" @@ -187,7 +188,7 @@ ENTRY(entry_SYSCALL_64_trampoline) */ pushq %rdi movq$entry_SYSCALL_64_stage2, %rdi - jmp *%rdi + NOSPEC_JMP %rdi END(entry_SYSCALL_64_trampoline) .popsection @@ -266,7 +267,12 @@ entry_SYSCALL_64_fastpath: * It might end up jumping to the slow path. If it jumps, RAX * and all argument registers are clobbered. */ +#ifdef CONFIG_RETPOLINE + movqsys_call_table(, %rax, 8), %rax + call__x86_indirect_thunk_rax +#else call*sys_call_table(, %rax, 8) +#endif .Lentry_SYSCALL_64_after_fastpath_call: movq%rax, RAX(%rsp) @@ -438,7 +444,7 @@ ENTRY(stub_ptregs_64) jmp entry_SYSCALL64_slow_path 1: - jmp *%rax /* Called from C */ + NOSPEC_JMP %rax /* Called from C */ END(stub_ptregs_64) .macro ptregs_stub func @@ -517,7 +523,7 @@ ENTRY(ret_from_fork) 1: /* kernel thread */ movq%r12, %rdi - call*%rbx + NOSPEC_CALL %rbx /* * A kernel thread is allowed to return here after successfully * calling do_execve(). Exit to userspace to complete the execve() -- 2.7.4
[PATCH v6 02/10] x86/retpoline/crypto: Convert crypto assembler indirect jumps
Convert all indirect jumps in crypto assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by: David Woodhouse Acked-By: Arjan van de Ven --- arch/x86/crypto/aesni-intel_asm.S| 5 +++-- arch/x86/crypto/camellia-aesni-avx-asm_64.S | 3 ++- arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 3 ++- arch/x86/crypto/crc32c-pcl-intel-asm_64.S| 3 ++- 4 files changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 16627fe..f128680 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -32,6 +32,7 @@ #include #include #include +#include /* * The following macros are used to move an (un)aligned 16 byte value to/from @@ -2884,7 +2885,7 @@ ENTRY(aesni_xts_crypt8) pxor INC, STATE4 movdqu IV, 0x30(OUTP) - call *%r11 + NOSPEC_CALL %r11 movdqu 0x00(OUTP), INC pxor INC, STATE1 @@ -2929,7 +2930,7 @@ ENTRY(aesni_xts_crypt8) _aesni_gf128mul_x_ble() movups IV, (IVP) - call *%r11 + NOSPEC_CALL %r11 movdqu 0x40(OUTP), INC pxor INC, STATE1 diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S b/arch/x86/crypto/camellia-aesni-avx-asm_64.S index f7c495e..ba3f075 100644 --- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S +++ b/arch/x86/crypto/camellia-aesni-avx-asm_64.S @@ -17,6 +17,7 @@ #include #include +#include #define CAMELLIA_TABLE_BYTE_LEN 272 @@ -1227,7 +1228,7 @@ camellia_xts_crypt_16way: vpxor 14 * 16(%rax), %xmm15, %xmm14; vpxor 15 * 16(%rax), %xmm15, %xmm15; - call *%r9; + NOSPEC_CALL %r9; addq $(16 * 16), %rsp; diff --git a/arch/x86/crypto/camellia-aesni-avx2-asm_64.S b/arch/x86/crypto/camellia-aesni-avx2-asm_64.S index eee5b39..9b0a88a 100644 --- a/arch/x86/crypto/camellia-aesni-avx2-asm_64.S +++ b/arch/x86/crypto/camellia-aesni-avx2-asm_64.S @@ -12,6 +12,7 @@ #include #include +#include #define CAMELLIA_TABLE_BYTE_LEN 272 @@ -1343,7 +1344,7 @@ camellia_xts_crypt_32way: vpxor 14 * 32(%rax), %ymm15, %ymm14; vpxor 15 * 32(%rax), %ymm15, %ymm15; - call *%r9; + NOSPEC_CALL %r9; addq $(16 * 32), %rsp; diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S index 7a7de27..05178b44 100644 --- a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S +++ b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S @@ -45,6 +45,7 @@ #include #include +#include ## ISCSI CRC 32 Implementation with crc32 and pclmulqdq Instruction @@ -172,7 +173,7 @@ continue_block: movzxw (bufp, %rax, 2), len lea crc_array(%rip), bufp lea (bufp, len, 1), bufp - jmp *bufp + NOSPEC_JMP bufp ## 2a) PROCESS FULL BLOCKS: -- 2.7.4
[PATCH v6 07/10] x86/retpoline/checksum32: Convert assembler indirect jumps
Convert all indirect jumps in 32bit checksum assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by: David Woodhouse Acked-By: Arjan van de Ven --- arch/x86/lib/checksum_32.S | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/lib/checksum_32.S b/arch/x86/lib/checksum_32.S index 4d34bb5..98cf15d 100644 --- a/arch/x86/lib/checksum_32.S +++ b/arch/x86/lib/checksum_32.S @@ -29,7 +29,8 @@ #include #include #include - +#include + /* * computes a partial checksum, e.g. for TCP/UDP fragments */ @@ -156,7 +157,7 @@ ENTRY(csum_partial) negl %ebx lea 45f(%ebx,%ebx,2), %ebx testl %esi, %esi - jmp *%ebx + NOSPEC_JMP %ebx # Handle 2-byte-aligned regions 20:addw (%esi), %ax @@ -439,7 +440,7 @@ ENTRY(csum_partial_copy_generic) andl $-32,%edx lea 3f(%ebx,%ebx), %ebx testl %esi, %esi - jmp *%ebx + NOSPEC_JMP %ebx 1: addl $64,%esi addl $64,%edi SRC(movb -32(%edx),%bl) ; SRC(movb (%edx),%bl) -- 2.7.4
[PATCH v6 08/10] x86/retpoline/irq32: Convert assembler indirect jumps
From: Andi Kleen
Convert all indirect jumps in 32bit irq inline asm code to use
non speculative sequences.
Signed-off-by: Andi Kleen
Signed-off-by: David Woodhouse
Acked-By: Arjan van de Ven
---
arch/x86/kernel/irq_32.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/irq_32.c b/arch/x86/kernel/irq_32.c
index a83b334..e1e58f7 100644
--- a/arch/x86/kernel/irq_32.c
+++ b/arch/x86/kernel/irq_32.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -55,11 +56,11 @@ DEFINE_PER_CPU(struct irq_stack *, softirq_stack);
static void call_on_stack(void *func, void *stack)
{
asm volatile("xchgl %%ebx,%%esp \n"
-"call *%%edi \n"
+NOSPEC_CALL
"movl %%ebx,%%esp \n"
: "=b" (stack)
: "0" (stack),
- "D"(func)
+ [thunk_target] "D"(func)
: "memory", "cc", "edx", "ecx", "eax");
}
@@ -95,11 +96,11 @@ static inline int execute_on_irq_stack(int overflow, struct
irq_desc *desc)
call_on_stack(print_stack_overflow, isp);
asm volatile("xchgl %%ebx,%%esp \n"
-"call *%%edi \n"
+NOSPEC_CALL
"movl %%ebx,%%esp \n"
: "=a" (arg1), "=b" (isp)
: "0" (desc), "1" (isp),
- "D" (desc->handle_irq)
+ [thunk_target] "D" (desc->handle_irq)
: "memory", "cc", "ecx");
return 1;
}
--
2.7.4
[PATCH v6 06/10] x86/retpoline/xen: Convert Xen hypercall indirect jumps
Convert indirect call in Xen hypercall to use non-speculative sequence,
when CONFIG_RETPOLINE is enabled.
Signed-off-by: David Woodhouse
Acked-By: Arjan van de Ven
---
arch/x86/include/asm/xen/hypercall.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index 7cb282e..393c004 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -217,9 +218,9 @@ privcmd_call(unsigned call,
__HYPERCALL_5ARG(a1, a2, a3, a4, a5);
stac();
- asm volatile("call *%[call]"
+ asm volatile(NOSPEC_CALL
: __HYPERCALL_5PARAM
-: [call] "a" (&hypercall_page[call])
+: [thunk_target] "a" (&hypercall_page[call])
: __HYPERCALL_CLOBBER5);
clac();
--
2.7.4
[PATCH v6 09/10] x86/retpoline: Add boot time option to disable retpoline
From: Andi Kleen
Add a noretpoline option boot to disable retpoline and patch out the
extra sequences. It cannot patch out the jumps to the thunk functions
from code generated by the compiler, but those thunks turn into a single
indirect branch now.
Signed-off-by: Andi Kleen
Signed-off-by: David Woodhouse
Acked-By: Arjan van de Ven
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
arch/x86/kernel/cpu/intel.c | 11 +++
2 files changed, 14 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 9059917..d443141 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2596,6 +2596,9 @@
nohugeiomap [KNL,x86] Disable kernel huge I/O mappings.
+ noretpoline [X86] Disable the retpoline kernel indirect branch
speculation
+ workarounds. System may allow data leaks with this
option.
+
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b720dac..35e123e 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -31,6 +31,17 @@
#include
#endif
+#ifdef RETPOLINE
+static int __init noretpoline_setup(char *__unused)
+{
+ pr_info("Retpoline runtime disabled\n");
+ setup_clear_cpu_cap(X86_FEATURE_RETPOLINE);
+ setup_clear_cpu_cap(X86_FEATURE_RETPOLINE_AMD);
+ return 1;
+}
+__setup("noretpoline", noretpoline_setup);
+#endif
+
/*
* Just in case our CPU detection goes bad, or you have a weird system,
* allow a way to override the automatic disabling of MPX.
--
2.7.4
[PATCH v6 10/10] x86/retpoline: Exclude objtool with retpoline
From: Andi Kleen objtool's assembler nanny currently cannot deal with the code generated by the retpoline compiler and throws hundreds of warnings, mostly because it sees calls that don't have a symbolic target. Exclude all the options that rely on objtool when RETPOLINE is active. This mainly means that we use the frame pointer unwinder and livepatch is not supported. Eventually objtool can be fixed to handle this. Signed-off-by: Andi Kleen Signed-off-by: David Woodhouse Acked-By: Arjan van de Ven --- arch/x86/Kconfig | 4 ++-- arch/x86/Kconfig.debug | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 77c58ae..651d25f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -171,8 +171,8 @@ config X86 select HAVE_PERF_USER_STACK_DUMP select HAVE_RCU_TABLE_FREE select HAVE_REGS_AND_STACK_ACCESS_API - select HAVE_RELIABLE_STACKTRACE if X86_64 && UNWINDER_FRAME_POINTER && STACK_VALIDATION - select HAVE_STACK_VALIDATIONif X86_64 + select HAVE_RELIABLE_STACKTRACE if X86_64 && UNWINDER_FRAME_POINTER && STACK_VALIDATION && !RETPOLINE + select HAVE_STACK_VALIDATIONif X86_64 && !RETPOLINE select HAVE_SYSCALL_TRACEPOINTS select HAVE_UNSTABLE_SCHED_CLOCK select HAVE_USER_RETURN_NOTIFIER diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 6293a87..9f3928d 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -359,8 +359,8 @@ config PUNIT_ATOM_DEBUG choice prompt "Choose kernel unwinder" - default UNWINDER_ORC if X86_64 - default UNWINDER_FRAME_POINTER if X86_32 + default UNWINDER_ORC if X86_64 && !RETPOLINE + default UNWINDER_FRAME_POINTER if X86_32 || RETPOLINE ---help--- This determines which method will be used for unwinding kernel stack traces for panics, oopses, bugs, warnings, perf, /proc//stack, @@ -368,7 +368,7 @@ choice config UNWINDER_ORC bool "ORC unwinder" - depends on X86_64 + depends on X86_64 && !RETPOLINE select STACK_VALIDATION ---help--- This option enables the ORC (Oops Rewind Capability) unwinder for -- 2.7.4
Re: Avoid speculative indirect calls in kernel
On Sun, Jan 07, 2018 at 07:55:11PM +0100, Borislav Petkov wrote: > > Just like you have to trust your plane's pilot eventhough you don't > > know him personally. > > Funny you should make that analogy. Remember that germanwings pilot? > People trusted him too. > > Now imagine if the plane had protection against insane pilots... some of > those people might still be alive, who knows... Sure but despite this case many people continue to take the plane because it's their only option to cross half of the world in a reasonable time. Boris, I'm *not* contesting the performance resulting from the fixes, and I would never have been able to produce them myself had I to, so I'm really glad we have them. I just want to be clear that the big drop some of us are facing is not an option *at all* for certain processes in certain environments and that we'll either continue to run with pti=off or with pti=on + a finer grained setting ASAP. I mean, the kernel is not the only sensitive part in a system (and sometimes it's even not at all). A kernel + a userland processes deliver a service, each in it role. Breaking one or the other can be similar or sometimes the trouble can be worse for one than the other. But for some situations, the good work condition of the combination of the two is critical, and even a kernel compromission could be a detail compared to the impact of something crashing at full load. Sometimes a userspace compromission would already be critical enough that the risk is not higher by accepting to take it for the kernel as well. In my specific case, on LB appliances, I don't really care what happens once haproxy has already been compromised, it's too late. End of the game, all sensitive information are already disclosed at this point. What I'd rather avoid however is the occasional sysop who has an account on the machine to retrieve some stats once in a while that would suddenly be able to get more than these stats. That's where I draw the line for *this* use case. Plenty of others will have plenty of other perception and that's fine. Cheers, Willy
Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder
On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
>
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
>
> Allow architectures to override the show function.
>
> Signed-off-by: Thomas Gleixner
> ---
> Documentation/ABI/testing/sysfs-devices-system-cpu | 16 +++
> drivers/base/Kconfig |3 +
> drivers/base/cpu.c | 48
> +
> include/linux/cpu.h|7 +++
> 4 files changed, 74 insertions(+)
>
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -373,3 +373,19 @@ Contact: Linux kernel mailing list Description: information about CPUs heterogeneity.
>
> cpu_capacity: capacity of cpu#.
> +
> +What:/sys/devices/system/cpu/vulnerabilities
> + /sys/devices/system/cpu/vulnerabilities/meltdown
> + /sys/devices/system/cpu/vulnerabilities/spectre_v1
> + /sys/devices/system/cpu/vulnerabilities/spectre_v2
> +Date:Januar 2018
s/Januar/January/
and with that
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
> +
> +static struct attribute *cpu_root_vulnerabilities_attrs[] = {
> + &dev_attr_meltdown.attr,
> + &dev_attr_spectre_v1.attr,
> + &dev_attr_spectre_v2.attr,
> + NULL
> +};
> +
> +static const struct attribute_group cpu_root_vulnerabilities_group = {
> + .name = "vulnerabilities",
> + .attrs = cpu_root_vulnerabilities_attrs,
> +};
> +
> +static void __init cpu_register_vulnerabilities(void)
> +{
> + if (sysfs_create_group(&cpu_subsys.dev_root->kobj,
> +&cpu_root_vulnerabilities_group))
> + pr_err("Unable to register CPU vulnerabilities\n");
> +}
> +
> +#else
> +static inline void cpu_register_vulnerabilities(void) { }
> +#endif
> +
> void __init cpu_dev_init(void)
> {
> if (subsys_system_register(&cpu_subsys, cpu_root_attr_groups))
> panic("Failed to register CPU subsystem");
>
> cpu_dev_register_generic();
> + cpu_register_vulnerabilities();
> }
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -47,6 +47,13 @@ extern void cpu_remove_dev_attr(struct d
> extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
> extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
>
> +extern ssize_t cpu_show_meltdown(struct device *dev,
> + struct device_attribute *attr, char *buf);
> +extern ssize_t cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf);
> +extern ssize_t cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf);
> +
> extern __printf(4, 5)
> struct device *cpu_device_create(struct device *parent, void *drvdata,
>const struct attribute_group **groups,
>
>
Re: [patch V2 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions
On Sun, Jan 07, 2018 at 10:48:01PM +0100, Thomas Gleixner wrote:
> Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and
> spectre_v2.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> ---
> arch/x86/Kconfig |1 +
> arch/x86/kernel/cpu/bugs.c | 29 +
> 2 files changed, 30 insertions(+)
>
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -89,6 +89,7 @@ config X86
> select GENERIC_CLOCKEVENTS_MIN_ADJUST
> select GENERIC_CMOS_UPDATE
> select GENERIC_CPU_AUTOPROBE
> + select GENERIC_CPU_VULNERABILITIES
> select GENERIC_EARLY_IOREMAP
> select GENERIC_FIND_FIRST_BIT
> select GENERIC_IOMAP
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -10,6 +10,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -60,3 +61,31 @@ void __init check_bugs(void)
> set_memory_4k((unsigned long)__va(0), 1);
> #endif
> }
> +
> +#ifdef CONFIG_SYSFS
> +ssize_t cpu_show_meltdown(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + if (!boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN))
> + return sprintf(buf, "Not affected\n");
> + if (boot_cpu_has(X86_FEATURE_PTI))
> + return sprintf(buf, "Mitigation: PTI\n");
> + return sprintf(buf, "Vulnerable\n");
> +}
> +
> +ssize_t cpu_show_spectre_v1(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V1))
> + return sprintf(buf, "Not affected\n");
> + return sprintf(buf, "Vulnerable\n");
> +}
> +
> +ssize_t cpu_show_spectre_v2(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
> + return sprintf(buf, "Not affected\n");
> + return sprintf(buf, "Vulnerable\n");
> +}
> +#endif
>
>
Re: [RFC PATCH 13/12] Retpoline vs. CONFIG_TRIM_UNUSED_SYMBOLS
On Sun, 2018-01-07 at 18:32 +, Lu, Hongjiu wrote: > > If I get positive feedbacks from kernel folks with my GCC 7 patches today, I > will submit my patches for GCC 8 today. After they are checked in, I will > backport them to GCC 7/6/5/4.9. To confirm: These seem to work for me and I've resent the kernel patch series after testing with them. Thanks. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel
On Sun, Jan 7, 2018 at 2:11 PM, David Woodhouse wrote: > This is a mitigation for the 'variant 2' attack described in > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html Ok, I don't love the patches, but I see nothing horribly wrong here either, and I assume the performance impact of this is pretty minimal. Thomas? I'm obviously doing rc7 today without these, but I assume the x86 maintainers are resigned to this all. And yes, we'll have at least an rc8 this release.. Linus
Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder
Thomas Gleixner wrote: > Create /sys/devices/system/cpu/vulnerabilities folder and files for > meltdown, spectre_v1 and spectre_v2. It is called "grep -e '^bugs' /proc/cpuinfo". kpti is deduceable from .config and /proc/cmdline . If people don't know what .config they are running, god bless them.
Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
On Sun, Jan 07, 2018 at 12:17:11PM -0800, Linus Torvalds wrote: > We need to fix the security problem, but we need to do it *without* > these braindead arguments that performance is somehow secondary. OK OK. At least we should have security by default and let people trade it against performance if they want and understand the risk. People never know when they're secure enough (security doesn't measure) but they know fairly well when they're not performant enough to take action (most often changing the machine). Willy
Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants
Hi Miquel, Ezequiel, On 23/12/17 05:56, Ezequiel Garcia wrote: > On 22 December 2017 at 12:53, Miquel RAYNAL > wrote: >> Hello Chris, >> >> On Fri, 22 Dec 2017 12:19:04 +1300 >> Chris Packham wrote: >> >>> From: Kalyan Kinthada >>> >>> The Armada-370 based SoCs support arbitration between the NAND Flash >>> interface and NOR (i.e. devbus) on the same chip select. However there >>> are two guidelines that must be followed to avoid data corruption in >>> this scenario. >> >> Sorry to bother you again with that but, do you actually face any >> issue/data corruption with this scenario? >> > > Indeed. We need a description of a real world problem this patch is fixing. > I totally agree. The Marvell FAE used words like "data corruption" hence my re-newed interest in this. I had hoped these patches would pique the interest of someone from Marvell's engineering team with some more info on how the data corruption exhibits. I've been running some of the mtd-utils tests on my hardware and haven't detected any failures yet. I think the key would be to be doing interleaved accesses between nand and the parallel device. I've just kicked off something I think should do this on my hardware but I'm unsure as to how long I should wait for an issue to present itself. I'll leave it running for as long as I can today. If I find a failure I'll report back otherwise we can leave this patch for the mailing list archives waiting for an issue to be seen.
Linux 4.15-rc7
Ok, we had an interesting week, and by now everybody knows why we were merging all those odd x86 page table isolation patches without following all of the normal release timing rules. But rc7 itself is actually pretty calm. Yes, there were a few small follow-up patches to the PTI code still, and yes, there's been a fair amount of discussion about the exact details of the Spectre fixes, but at least in general things have been nice and calm. And we're actually back to "normal" in that most of the patches are drivers (mainly GPU, some crypto, some random small things - input layer, platform drivers etc). There are misc small filesystem and arch updates too. The appended shortlog is small enough that it's easy to just scroll down and get a feel for what happened. The one thing I want to do now that Meltdown and Spectre are public, is to give a *big* shout-out to the x86 people, and Thomas Gleixner in particular for really being on top of this. It's been one huge annoyance, and honestly, Thomas really went over and beyond in this whole mess. A lot of other people have obviously been involved too, don't get me wrong, but this is exactly the kind of issue that easily results in lots of nasty hacky patches because people are falling all over themselves trying to fix it and they can't even talk about why they are doing it in public, and Thomas &co ended up being a huge reason for why it was all much easier for me to merge: because of the literally _months_ of work on quality control and gating these patches and making sure the end result was a clean and manageable series. So a big *BIG* thanks to Thomas for making it so much easier for me to merge all this stuff. The whole nasty TLB isolation patches would have been just _so_ much more horrible without him. Anyway, due to this all, 4.15 will obviously be one of the releases with an rc8, even if things are starting to really calm down by now. We'll see, hopefully we won't need any more than that. Linus --- Aaron Ma (1): Input: elantech - add new icbody type 15 Al Viro (2): sget(): handle failures of register_shrinker() fix "netfilter: xt_bpf: Fix XT_BPF_MODE_FD_PINNED mode of 'xt_bpf_info_v1'" Alejandro Mery (3): ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA ARM: davinci: Add dma_mask to dm365's eDMA device ARM: davinci: fix mmc entries in dm365's dma_slave_map Alexey Brodkin (2): ARC: Fix detection of dual-issue enabled ARC: [plat-hsdk] Switch DisplayLink driver from fbdev to DRM Aliaksei Karaliou (2): xfs: quota: fix missed destroy of qi_tree_lock xfs: quota: check result of register_shrinker() Andrea Arcangeli (1): userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails Andrew Morton (1): kernel/exit.c: export abort() to modules Andrey Ryabinin (1): x86/mm: Set MODULES_END to 0xff00 Anshuman Khandual (1): mm/mprotect: add a cond_resched() inside change_pmd_range() Anthony Kim (1): Input: hideep - fix compile error due to missing include file Antoine Tenart (3): crypto: inside-secure - free requests even if their handling failed crypto: inside-secure - fix request allocations in invalidation path crypto: inside-secure - do not use areq->result for partial results Ard Biesheuvel (1): efi/capsule-loader: Reinstate virtual capsule mapping Arnd Bergmann (3): ARM: dts: ls1021a: fix incorrect clock references ARM: dts: tango4: remove bogus interrupt-controller property crypto: chelsio - select CRYPTO_GF128MUL Baoquan He (1): mm/sparse.c: wrong allocation for mem_section Bogdan Mirea (2): arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property Boris Brezillon (1): mtd: nand: pxa3xx: Fix READOOB implementation Chen-Yu Tsai (1): ARM: dts: sunxi: Convert to CCU index macros for HDMI controller Chris Mason (1): btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes Christian Borntraeger (2): KVM: s390: fix cmma migration for multiple memory slots KVM: s390: prevent buffer overrun on memory hotplug during migration Dan Carpenter (1): afs: Potential uninitialized variable in afs_extract_data() Darrick J. Wong (1): xfs: fix s_maxbytes overflow problems Dave Young (2): x86/efi: Fix kernel param add_efi_memmap regression mm: check pfn_valid first in zero_resv_unavail David Howells (3): fscache: Fix the default for fscache_maybe_release_page() afs: Fix unlink afs: Fix missing error handling in afs_write_end() David Lechner (1): ARM: dts: da850-lego-ev3: Fix battery voltage gpio David Woodhouse (1): x86/alternatives: Add missing '\n' at end of ALTERNATIVE inline asm Dhinakaran Pandiyan (1): drm/i915/psr: Fix register name mess up. Dmitry T
Re: [PATCH] atm/clip: Use seq_puts() in svc_addr()
On Sat, Jan 6, 2018 at 11:44 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Sat, 6 Jan 2018 22:34:12 +0100
>
> Two strings should be quickly put into a sequence by two function calls.
> Thus use the function "seq_puts" instead of "seq_printf".
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> net/atm/clip.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/atm/clip.c b/net/atm/clip.c
> index d4f6029d5109..62a852165b19 100644
> --- a/net/atm/clip.c
> +++ b/net/atm/clip.c
> @@ -708,11 +708,11 @@ static void svc_addr(struct seq_file *seq, struct
> sockaddr_atmsvc *addr)
> static int e164[] = { 1, 8, 4, 6, 1, 0 };
>
> if (*addr->sas_addr.pub) {
> - seq_printf(seq, "%s", addr->sas_addr.pub);
> + seq_puts(seq, addr->sas_addr.pub);
Which opens a lot of security concerns.
Never do this again.
> if (*addr->sas_addr.prv)
> seq_putc(seq, '+');
> } else if (!*addr->sas_addr.prv) {
> - seq_printf(seq, "%s", "(none)");
> + seq_puts(seq, "(none)");
...while this one is okay per se, better to keep above pattern (same
style over the piece of code / function).
> return;
> }
> if (*addr->sas_addr.prv) {
> --
> 2.15.1
>
P.S. I'm wondering what would be first, Markus starts looking into the
actual code, or most (all) of the maintainers just ban him.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted
On Sun, Jan 7, 2018 at 5:04 PM, Minchan Kim wrote: >> - link->next = -1 << OBJ_TAG_BITS; >> + link->next = -1U << OBJ_TAG_BITS; > > -1UL? Oh, boy, shouldn't be rather GENMASK() / GENMASK_ULL() in a way how it's done, for example, here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=d2b3c353595a855794f8b9df5b5bdbe8deb0c413 -- With Best Regards, Andy Shevchenko
Cache-controlling kernel APIs for user-space programs to defeat Meltdown/Spectre and to make more secure applications portably
I've been thinking that the problem that makes Meltdown/Spectre possible is a synchronization problem between the use of the cache by all running processes and invalidating the cache when switching tasks so that the contents of the cache for a process don't exist when switching and running to another process. I've been thinking that the best solution to prevent memory leakage between processes through the cache would be to provide a new set of API functions that allow user-space programs to control their usage of the cache, for example, to disable the cache entirely for memory pages allocated with malloc(), etc., so that variables/buffers with sensitive data reside only in RAM but never in the cache, and thus making it impossible to leak memory of that sensitive data from another process. For example, 32-bit protected mode of the x86 includes a bit in each page entry that allows to specify whether that memory page will use the cache or not: http://wiki.osdev.org/File:Page_table.png http://wiki.osdev.org/Paging The new cache-controlling API functions could mainly allow a program to control this bit, control cache flushes, etc., so that, given the virtual addres of a buffer or variable, the kernel can resolve that virtual address to mark the page entry to disable it from the cache. If a program uses that for memory that it knows that will contain user/password login data, or encrypted network traffic, then Also, a program loader could be created to invoke programs as with sudo, that when run, makes all data pages, and optionally code pages, to have their use of the cache disabled in the page table entries so that existing programs can run securely without the possibility of cache leaks if for example an user wants to run a high-security script. Programs running as the root user could also have their usage of the cache for data sections disabled for security reasons. It could be an option that could be enabled or disabled, and there could be private data sections in an executable that could specify whether to use the CPU cache or not. DMA memory is very fast and it's supposed to have its usage of the cache disabled, so this case where we might want to disable the cache to prevent sensitive data to be copied in random places of the cache could prove more efficient than other ways to patch the kernel and applications, but it would require a new set of API functions that would allow user programs to enable/disable their cache for code/data globally, as well as for variables configured by the program with that API, and also flushing the cache when done dealing with sensitive data. The multitasking and paging code of the kernel could still need to be improved to make sure that the cache doesn't contain any data from the current program, when switching to another one, to prevent having data that shouldn't reach another program when switching tasks. The page fault vulnerabilities that use speculation/out of order execution to use the cache loads as tests to determine private data values could be addressed by flushing the cache and putting the offending process at the end of the tasking queue for several cycles when a page fault or other sort of related fault/exception occurs, so that by the time that it's multitasked again, no data useful for Meltdown or Spectre is discernible.
[PATCH] scsi: bfa: use ARRAY_SIZE for array sizing calculation on array __pciids
From: Colin Ian King
Use the ARRAY_SIZE macro on array __pciids to determine size of the array.
Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
drivers/scsi/bfa/bfa_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/bfa/bfa_core.c b/drivers/scsi/bfa/bfa_core.c
index 3e1caec82554..10a63be92544 100644
--- a/drivers/scsi/bfa/bfa_core.c
+++ b/drivers/scsi/bfa/bfa_core.c
@@ -1957,7 +1957,7 @@ bfa_get_pciids(struct bfa_pciid_s **pciids, int *npciids)
{BFA_PCI_VENDOR_ID_BROCADE, BFA_PCI_DEVICE_ID_CT_FC},
};
- *npciids = sizeof(__pciids) / sizeof(__pciids[0]);
+ *npciids = ARRAY_SIZE(__pciids);
*pciids = __pciids;
}
--
2.15.1
[PATCH] ixgbe: use ARRAY_SIZE for array sizing calculation on array buf
From: Colin Ian King
Use the ARRAY_SIZE macro on array buf to determine size of the array.
Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index cb7da5f9c4da..28c23ef2ec28 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -949,7 +949,7 @@ static s32 ixgbe_checksum_ptr_x550(struct ixgbe_hw *hw, u16
ptr,
u16 length, bufsz, i, start;
u16 *local_buffer;
- bufsz = sizeof(buf) / sizeof(buf[0]);
+ bufsz = ARRAY_SIZE(buf);
/* Read a chunk at the pointer location */
if (!buffer) {
--
2.15.1
[PATCH] regmap: Allow empty read/write_flag_mask
All zero read and write masks in the regmap config are used to signal no
special mask is needed and the bus defaults are used. In some devices
all zero read/write masks are the special mask and bus defaults should
not be used. To signal this a new variable is added.
For example SPI often sets bit 7 in address to signal to the device a
read is requested. On TI AFE44xx parts with SPI interfaces no bit
needs to be set as registers are either read or write only and the
operation can be determined from the address only. For this case both
masks must be zero to not effect the address.
Signed-off-by: Andrew F. Davis
---
drivers/base/regmap/regmap.c | 4 +++-
include/linux/regmap.h | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 8d516a9bfc01..025c62358bd6 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -769,7 +769,9 @@ struct regmap *__regmap_init(struct device *dev,
INIT_LIST_HEAD(&map->async_free);
init_waitqueue_head(&map->async_waitq);
- if (config->read_flag_mask || config->write_flag_mask) {
+ if (config->read_flag_mask ||
+ config->write_flag_mask ||
+ config->zero_flag_mask) {
map->read_flag_mask = config->read_flag_mask;
map->write_flag_mask = config->write_flag_mask;
} else if (bus) {
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 15eddc1353ba..f8bff272c429 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -296,7 +296,10 @@ typedef void (*regmap_unlock)(void *);
* a read.
* @write_flag_mask: Mask to be set in the top bytes of the register when doing
* a write. If both read_flag_mask and write_flag_mask are
- * empty the regmap_bus default masks are used.
+ * empty and zero_flag_mask is not set the regmap_bus default
+ * masks are used.
+ * @zero_flag_mask: If set, read_flag_mask and write_flag_mask are used even
+ * if they are both empty.
* @use_single_rw: If set, converts the bulk read and write operations into
* a series of single read and write operations. This is useful
* for device that does not support bulk read and write.
@@ -355,6 +358,7 @@ struct regmap_config {
unsigned long read_flag_mask;
unsigned long write_flag_mask;
+ bool zero_flag_mask;
bool use_single_rw;
bool can_multi_write;
--
2.15.1
[PATCH 3/3] regcache: flat: Add valid bit to this cache type
Other regmap cache types (LZO, RBtree) report back un-successful register
lookups when a value has not been previously written into the cache. This
allows regmap core to perform a real un-cached lookup to fetch the value.
The Flat type cache does not and so all read succeed reporting zero for the
registers value, even when the actual value is not known.
We fix this by changing the flat cache element type to a struct
containing both the register's value and a bool signifying if this value
is an actual cached value or not. This also opens up a path to implement
additional regcache_ops such as "sync" and "drop" that rely on such
validity information.
Signed-off-by: Andrew F. Davis
---
drivers/base/regmap/regcache-flat.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 99a7792210b3..89a2226f9a81 100644
--- a/drivers/base/regmap/regcache-flat.c
+++ b/drivers/base/regmap/regcache-flat.c
@@ -16,6 +16,11 @@
#include "internal.h"
+struct regcache_flat_reg {
+ unsigned int value; /* Value of this register */
+ bool valid; /* Is value valid? */
+} __packed;
+
static inline unsigned int regcache_flat_get_index(const struct regmap *map,
unsigned int reg)
{
@@ -25,7 +30,7 @@ static inline unsigned int regcache_flat_get_index(const
struct regmap *map,
static int regcache_flat_init(struct regmap *map)
{
int i;
- unsigned int *cache;
+ struct regcache_flat_reg *cache;
if (!map || map->reg_stride_order < 0 || !map->max_register)
return -EINVAL;
@@ -41,7 +46,8 @@ static int regcache_flat_init(struct regmap *map)
unsigned int reg = map->reg_defaults[i].reg;
unsigned int index = regcache_flat_get_index(map, reg);
- cache[index] = map->reg_defaults[i].def;
+ cache[index].value = map->reg_defaults[i].def;
+ cache[index].valid = true;
}
return 0;
@@ -58,10 +64,13 @@ static int regcache_flat_exit(struct regmap *map)
static int regcache_flat_read(struct regmap *map,
unsigned int reg, unsigned int *value)
{
- unsigned int *cache = map->cache;
+ struct regcache_flat_reg *cache = map->cache;
unsigned int index = regcache_flat_get_index(map, reg);
- *value = cache[index];
+ if (!cache[index].valid)
+ return -ENOENT;
+
+ *value = cache[index].value;
return 0;
}
@@ -69,10 +78,11 @@ static int regcache_flat_read(struct regmap *map,
static int regcache_flat_write(struct regmap *map, unsigned int reg,
unsigned int value)
{
- unsigned int *cache = map->cache;
+ struct regcache_flat_reg *cache = map->cache;
unsigned int index = regcache_flat_get_index(map, reg);
- cache[index] = value;
+ cache[index].value = value;
+ cache[index].valid = true;
return 0;
}
--
2.15.1
[PATCH 2/3] regcache: flat: Un-inline index lookup from cache access
This makes the code slightly more readable and allows for cleaner
addition of functionality in later patches.
Signed-off-by: Andrew F. Davis
---
drivers/base/regmap/regcache-flat.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 2ea5fc84a374..99a7792210b3 100644
--- a/drivers/base/regmap/regcache-flat.c
+++ b/drivers/base/regmap/regcache-flat.c
@@ -37,9 +37,12 @@ static int regcache_flat_init(struct regmap *map)
cache = map->cache;
- for (i = 0; i < map->num_reg_defaults; i++)
- cache[regcache_flat_get_index(map, map->reg_defaults[i].reg)] =
- map->reg_defaults[i].def;
+ for (i = 0; i < map->num_reg_defaults; i++) {
+ unsigned int reg = map->reg_defaults[i].reg;
+ unsigned int index = regcache_flat_get_index(map, reg);
+
+ cache[index] = map->reg_defaults[i].def;
+ }
return 0;
}
@@ -56,8 +59,9 @@ static int regcache_flat_read(struct regmap *map,
unsigned int reg, unsigned int *value)
{
unsigned int *cache = map->cache;
+ unsigned int index = regcache_flat_get_index(map, reg);
- *value = cache[regcache_flat_get_index(map, reg)];
+ *value = cache[index];
return 0;
}
@@ -66,8 +70,9 @@ static int regcache_flat_write(struct regmap *map, unsigned
int reg,
unsigned int value)
{
unsigned int *cache = map->cache;
+ unsigned int index = regcache_flat_get_index(map, reg);
- cache[regcache_flat_get_index(map, reg)] = value;
+ cache[index] = value;
return 0;
}
--
2.15.1
[PATCH 1/3] regcache: flat: Use cache element type in sizeof
A single cache element may not always be unsigned int, use a cache element in sizeof over hard-coding its type. Signed-off-by: Andrew F. Davis --- drivers/base/regmap/regcache-flat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/regmap/regcache-flat.c b/drivers/base/regmap/regcache-flat.c index 4d2e50bfc726..2ea5fc84a374 100644 --- a/drivers/base/regmap/regcache-flat.c +++ b/drivers/base/regmap/regcache-flat.c @@ -31,7 +31,7 @@ static int regcache_flat_init(struct regmap *map) return -EINVAL; map->cache = kcalloc(regcache_flat_get_index(map, map->max_register) -+ 1, sizeof(unsigned int), GFP_KERNEL); ++ 1, sizeof(*cache), GFP_KERNEL); if (!map->cache) return -ENOMEM; -- 2.15.1
Re: [PATCH] Staging: iio: Prefer using BIT macro
On Sat, Jan 6, 2018 at 2:42 PM, Jonathan Cameron wrote: > On Thu, 4 Jan 2018 22:06:31 +0530 >> /* Setup Register Bit Designations (AD7152_REG_CHx_SETUP) */ >> -#define AD7152_SETUP_CAPDIFF (1 << 5) >> +#define AD7152_SETUP_CAPDIFF BIT(5) > > This is indeed a 1 bit field so fine. But shouldn't we prevent style over the module? Otherwise it might be hard to decode one field from the other because of style differences. >> #define AD7152_SETUP_RANGE_2pF (0 << 6) >> -#define AD7152_SETUP_RANGE_0_5pF (1 << 6) >> +#define AD7152_SETUP_RANGE_0_5pF BIT(6) > This is clearly putting the value 1 in a 2 bit field within > the register - BIT macro obscures this compeltely. -- With Best Regards, Andy Shevchenko
Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul
On Saturday, January 6, 2018 4:05:41 AM CET Anson Huang wrote: > Hi, Rafael > > Best Regards! > Anson Huang > > > > -Original Message- > > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael > > J. Wysocki > > Sent: 2018-01-05 8:21 PM > > To: Anson Huang > > Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Linux > > PM ; Linux Kernel Mailing List > ker...@vger.kernel.org>; Shawn Guo ; Sascha Hauer > > ; Fabio Estevam ; Rob > > Herring ; Mark Rutland ; > > Russell King - ARM Linux ; Rafael J. Wysocki > > ; Viresh Kumar ; Jacky Bai > > ; A.s. Dong > > Subject: Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for > > i.mx6ul > > > > On Tue, Jan 2, 2018 at 6:07 PM, Anson Huang wrote: > > > Add 696MHz operating point for i.MX6UL, only for those parts with > > > speed grading fuse set to 2b'10 supports 696MHz operating point, so, > > > speed grading check is also added for i.MX6UL in this patch, the clock > > > tree for each operating point are as below: > > > > > > 696MHz: > > > pll1 69600 > > >pll1_bypass 69600 > > > pll1_sys 69600 > > > pll1_sw 69600 > > > arm69600 > > > 528MHz: > > > pll2 52800 > > >pll2_bypass 52800 > > > pll2_bus 52800 > > > ca7_secondary_sel 52800 > > > step 52800 > > >pll1_sw 52800 > > > arm 52800 > > > 396MHz: > > > pll2_pfd2_396m 39600 > > >ca7_secondary_sel 39600 > > > step 39600 > > > pll1_sw 39600 > > > arm39600 > > > 198MHz: > > > pll2_pfd2_396m 39600 > > >ca7_secondary_sel 39600 > > > step 39600 > > > pll1_sw 39600 > > > arm19800 > > > > > > Signed-off-by: Anson Huang > > > > This doesn't apply for me and in a nontrivial way. > > > > What kernel is it against? > > I did it based on linux-next, it should be on linux-next-pm branch, I redo > the patch set V2 based on linux-next-pm, also redo the test, > sorry for the inconvenience. But you didn't add the Reviewed-by: tags from Fabio to them. Was that on purpose or by mistake? Thanks, Rafael
Linux 3.2.98
I'm announcing the release of the 3.2.98 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.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 The diff from 3.2.97 is attached to this message. Ben. Documentation/kernel-parameters.txt | 12 + Makefile | 2 +- arch/x86/boot/compressed/misc.h | 1 + arch/x86/ia32/ia32entry.S | 9 + arch/x86/include/asm/alternative-asm.h| 43 ++- arch/x86/include/asm/alternative.h| 80 -- arch/x86/include/asm/cmdline.h| 8 + arch/x86/include/asm/cpufeature.h | 11 +- arch/x86/include/asm/desc.h | 2 +- arch/x86/include/asm/hardirq.h| 2 +- arch/x86/include/asm/hw_irq.h | 2 +- arch/x86/include/asm/kaiser.h | 141 ++ arch/x86/include/asm/mmu.h| 6 - arch/x86/include/asm/mmu_context.h| 76 + arch/x86/include/asm/pgtable.h| 27 +- arch/x86/include/asm/pgtable_64.h | 24 +- arch/x86/include/asm/pgtable_types.h | 29 +- arch/x86/include/asm/processor-flags.h| 3 + arch/x86/include/asm/processor.h | 2 +- arch/x86/include/asm/tlbflush.h | 180 arch/x86/include/asm/vsyscall.h | 1 + arch/x86/kernel/alternative.c | 159 +-- arch/x86/kernel/cpu/bugs.c| 8 + arch/x86/kernel/cpu/common.c | 88 +- arch/x86/kernel/cpu/perf_event_intel_ds.c | 54 +++- arch/x86/kernel/entry_32.S| 2 +- arch/x86/kernel/entry_64.S| 122 ++-- arch/x86/kernel/espfix_64.c | 10 + arch/x86/kernel/head_64.S | 29 +- arch/x86/kernel/hpet.c| 3 + arch/x86/kernel/init_task.c | 2 +- arch/x86/kernel/irqinit.c | 2 +- arch/x86/kernel/ldt.c | 27 +- arch/x86/kernel/paravirt_patch_64.c | 2 - arch/x86/kernel/process_64.c | 2 +- arch/x86/kernel/reboot.c | 6 + arch/x86/kernel/setup.c | 7 + arch/x86/kernel/vsyscall_64.c | 7 +- arch/x86/lib/Makefile | 2 +- arch/x86/lib/clear_page_64.S | 4 +- arch/x86/lib/cmdline.c| 215 ++ arch/x86/lib/copy_page_64.S | 2 +- arch/x86/lib/copy_user_64.S | 15 +- arch/x86/lib/memcpy_64.S | 8 +- arch/x86/lib/memmove_64.S | 2 +- arch/x86/lib/memset_64.S | 8 +- arch/x86/mm/Makefile | 4 +- arch/x86/mm/init.c| 2 +- arch/x86/mm/init_64.c | 10 + arch/x86/mm/kaiser.c | 452 ++ arch/x86/mm/pgtable.c | 27 +- arch/x86/mm/tlb.c | 112 +++- arch/x86/xen/enlighten.c | 6 + include/asm-generic/vmlinux.lds.h | 7 + include/linux/kaiser.h| 52 include/linux/mmu_context.h | 7 + include/linux/mmzone.h| 3 +- include/linux/percpu-defs.h | 32 ++- init/main.c | 2 + kernel/fork.c | 6 + kernel/sched.c| 4 +- mm/mmu_context.c | 2 +- mm/vmstat.c | 1 + security/Kconfig | 10 + 64 files changed, 1916 insertions(+), 270 deletions(-) Andrea Arcangeli (1): x86/mm/kaiser: re-enable vsyscalls Andy Lutomirski (13): x86/mm: Add INVPCID helpers x86/mm: Add a 'noinvpcid' boot option to turn off INVPCID x86/mm: If INVPCID is available, use it to flush global mappings sched/core: Add switch_mm_irqs_off() and use it in the scheduler x86/mm: Build arch/x86/mm/tlb.c even on !SMP x86/mm, sched/core: Uninline switch_mm() x86/mm, sched/core: Turn off IRQs in switch_mm() sched/core: Idle_task_exit() shouldn't use switch_mm_irqs_off() x86/mm: Remove the UP asm/tlbflush.h code, always use the (formerly) SMP code x86/mm: Disable PCID on 32-bit kernels x86/mm: Add the 'nopcid' boot option to turn off PCID x86/mm: Enable CR4.PCIDE on supported systems x86/mm/64: Fix reboot interaction with CR4.PCIDE Ben Hutchings (1): Linux 3.2.98 Borislav Petkov (10): x86/mm: Fix INVPCID asm constraint x86/alternatives: Cleanup DPRINTK macro x86/alternatives: Add instruction padding x86/alternatives: Make JMPs more robust
Re: [PATCH] Documentation: security/credentials.rst: explain need to sort group_list
On Sat, Jan 06 2018, Jonathan Corbet wrote: > There is value in using the c:func syntax, as it will generate > cross-references to the kerneldoc comments for those functions. In this > case, it would appear that these comments exist, but nobody has pulled > them into the docs yet. I took the liberty of adding :c:func: references > to this patch on its way into docs-next so that things will Just Work on > that happy day when somebody adds the function documentation. Is this the sort of thing that might result in that happy day? I didn't spend tooo much time on it, in case including the kernel-doc in credentials.rst like this was the wrong direction. Thanks, NeilBrown --8<- From: NeilBrown Subject: [PATCH] Documentation: include kernel-doc in credentials.rst - kernel-doc from include/linux/cred.h, kernel/cred.c, and kernel/group.c is included in credentials.rst. - Various function references in credentials.rst are changed to link to this documentation. - Various minor improvements to the documentation. Signed-off-by: NeilBrown --- Documentation/security/credentials.rst | 55 ++ kernel/groups.c| 19 +++- 2 files changed, 47 insertions(+), 27 deletions(-) diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst index 66a2e24939d8..fd1b7d3b2a78 100644 --- a/Documentation/security/credentials.rst +++ b/Documentation/security/credentials.rst @@ -296,7 +296,7 @@ for example), it must be considered immutable, barring two exceptions: To catch accidental credential alteration at compile time, struct task_struct has _const_ pointers to its credential sets, as does struct file. Furthermore, -certain functions such as ``get_cred()`` and ``put_cred()`` operate on const +certain functions such as :c:func:`get_cred` and :c:func:`put_cred` operate on const pointers, thus rendering casts unnecessary, but require to temporarily ditch the const qualification to be able to alter the reference count. @@ -391,8 +391,8 @@ This does all the RCU magic inside of it. The caller must call put_cred() on the credentials so obtained when they're finished with. .. note:: - The result of ``__task_cred()`` should not be passed directly to - ``get_cred()`` as this may race with ``commit_cred()``. + The result of :c:func:`__task_cred()` should not be passed directly to + :c:func:`get_cred` as this may race with :c:func:`commit_cred`. There are a couple of convenience functions to access bits of another task's credentials, hiding the RCU magic from the caller:: @@ -406,7 +406,7 @@ If the caller is holding the RCU read lock at the time anyway, then:: __task_cred(task)->euid should be used instead. Similarly, if multiple aspects of a task's credentials -need to be accessed, RCU read lock should be used, ``__task_cred()`` called, +need to be accessed, RCU read lock should be used, :c:func:`__task_cred` called, the result stored in a temporary pointer and then the credential aspects called from that before dropping the lock. This prevents the potentially expensive RCU magic from being invoked multiple times. @@ -433,11 +433,8 @@ alter those of another task. This means that it doesn't need to use any locking to alter its own credentials. To alter the current process's credentials, a function should first prepare a -new set of credentials by calling:: - - struct cred *prepare_creds(void); - -this locks current->cred_replace_mutex and then allocates and constructs a +new set of credentials by calling :c:func:`prepare_creds`. +This locks ``current->cred_replace_mutex`` and then allocates and constructs a duplicate of the current process's credentials, returning with the mutex still held if successful. It returns NULL if not successful (out of memory). @@ -453,10 +450,7 @@ still at this point. When the credential set is ready, it should be committed to the current process -by calling:: - - int commit_creds(struct cred *new); - +by calling :c:func:`commit_creds`. This will alter various aspects of the credentials and the process, giving the LSM a chance to do likewise, then it will use ``rcu_assign_pointer()`` to actually commit the new credentials to ``current->cred``, it will release @@ -467,20 +461,17 @@ This function is guaranteed to return 0, so that it can be tail-called at the end of such functions as ``sys_setresuid()``. Note that this function consumes the caller's reference to the new credentials. -The caller should _not_ call ``put_cred()`` on the new credentials afterwards. +The caller should _not_ call :c:func:`put_cred` on the new credentials afterwards. Furthermore, once this function has been called on a new set of credentials, those credentials may _not_ be changed further. Should the security checks fail or some other error occur after -``prepare_creds()`` has been called, then
Re: [PATCH] tpm: remove unused variables
On Tue, 2 Jan 2018, Arnd Bergmann wrote:
> The CLKRUN fix caused a few harmless compile-time warnings:
>
> drivers/char/tpm/tpm_tis.c: In function 'tpm_tis_pnp_remove':
> drivers/char/tpm/tpm_tis.c:274:23: error: unused variable 'priv'
> [-Werror=unused-variable]
> drivers/char/tpm/tpm_tis.c: In function 'tpm_tis_plat_remove':
> drivers/char/tpm/tpm_tis.c:324:23: error: unused variable 'priv'
> [-Werror=unused-variable]
>
> This removes the variables that have now become unused.
>
> Fixes: 6d0866cbc2d3 ("tpm: Keep CLKRUN enabled throughout the duration of
> transmit_cmd()")
> Signed-off-by: Arnd Bergmann
Reviewed-by: James Morris
--
James Morris
Re: [PATCH V4] cpufreq: intel_pstate: allow trace in passive mode
On Saturday, January 6, 2018 5:40:34 PM CET Doug Smythies wrote:
> On 2018.01.05 14:52 Rafael J. Wysocki wrote:
> > On Fri, Jan 5, 2018 at 11:14 PM, Doug Smythies
> > wrote:
>
> >> Allow use of the trace_pstate_sample trace function
> >> when the intel_pstate driver is in passive mode.
> >> Since the core_busy and scaled_busy fields are not
> >> used, and it might be desirable to know which path
> >> through the driver was used, either intel_cpufreq_target
> >> or intel_cpufreq_fast_switch, re-task the core_busy
> >> field as a flag indicator.
> >>
> >> The user can then use the intel_pstate_tracer.py utility
> >> to summarize and plot the trace.
> >>
> >> Sometimes, in passive mode, the driver is not called for
> >> many tens or even hundreds of seconds. The user
> >> needs to understand, and not be confused by, this limitation.
> >
> > The description of the changes between different versions should go
> > under the Signed-off-by: tag, separated by an extra "---" from it.
>
> O.K. sorry.
>
> > Also please see a couple of cosmetic comments below.
> >
> >> V4: Only execute the trace specific overhead code if trace
> >> is enabled. Suggested by Srinivas Pandruvada.
> >>
> >> V3: Move largely duplicate code to a subroutine.
> >> Suggested by Rafael J. Wysocki.
> >>
> >> V2: prepare for resend. Rebase to current kernel, 4.15-rc3.
> >> Signed-off-by: Doug Smythies
> >> ---
> >> drivers/cpufreq/intel_pstate.c | 35 +--
> >> 1 file changed, 33 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/intel_pstate.c
> >> b/drivers/cpufreq/intel_pstate.c
> >> index 93a0e88..53bb953 100644
> >> --- a/drivers/cpufreq/intel_pstate.c
> >> +++ b/drivers/cpufreq/intel_pstate.c
> >> @@ -1943,13 +1943,40 @@ static int intel_cpufreq_verify_policy(struct
> >> cpufreq_policy *policy)
> >> return 0;
> >> }
> >>
> >> +static void intel_cpufreq_trace(struct cpudata *cpu, int fast, int from)
> >
> > Please use "bool" for "fast" and I'd call it "fast_switch".
>
> O.K. thanks.
>
> >> +{
> >> + struct sample *sample;
> >> + u64 time;
> >> +
> >> + time = ktime_get();
> >
> > It is pointless to evaluate ktime_get() if
> > trace_pstate_sample_enabled() returns "false".
>
> Of course, thanks.
>
> >> + if (trace_pstate_sample_enabled()) {
> >> + if (intel_pstate_sample(cpu, time)) {
> >
> > And the extra indentation here is not very useful, so I'd write it as
> >
> > if (!trace_pstate_sample_enabled())
> >return;
> >
> > if (!intel_pstate_sample(cpu, ktime_get()))
> >return;
> >
> > (note that you don't need the "time" variable any more with this).
>
> That is much better, Thanks.
>
> >> + sample = &cpu->sample;
> >> + /* In passvie mode the trace core_busy field is
> >
> > "passive" (typo)
> >
> >> +* re-assigned to indicate if the driver call
> >> +* was via the normal or fast switch path.
> >> +* The scaled_busy field is not used, set to 0.
> >> +*/
> >> + trace_pstate_sample(fast,
> >> + 0,
> >> + from,
> >> + cpu->pstate.current_pstate,
> >> + sample->mperf,
> >> + sample->aperf,
> >> + sample->tsc,
> >> + get_avg_frequency(cpu),
> >> + fp_toint(cpu->iowait_boost * 100));
> >> + }
> >> + }
> >> +}
> >> +
> >> static int intel_cpufreq_target(struct cpufreq_policy *policy,
> >> unsigned int target_freq,
> >> unsigned int relation)
> >> {
> >> struct cpudata *cpu = all_cpu_data[policy->cpu];
> >> struct cpufreq_freqs freqs;
> >> - int target_pstate;
> >> + int target_pstate, from;
> >
> > I would call the new variable "old_pstate" or "orig_pstate" (so that
> > it is visibly clear that it represents a P-state).
>
> O.K.
> I used "from" because that is what Dirk called it in the trace buffer stuff.
>
> >>
> >> update_turbo_state();
> >>
> >> @@ -1969,12 +1996,14 @@ static int intel_cpufreq_target(struct
> >> cpufreq_policy *policy,
> >> break;
> >> }
> >> target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
> >> + from = cpu->pstate.current_pstate;
> >> if (target_pstate != cpu->pstate.current_pstate) {
> >> cpu->pstate.current_pstate = target_pstate;
> >> wrmsrl_on_cpu(policy->cpu, MSR_IA32_PERF_CTL,
> >> pstate_funcs.get_val(cpu, target_pstate));
> >> }
> >> freqs.new = target_pstate * cpu->pstate.scaling;
> >> + intel_cpufreq_trace(cpu, 0, from);
>
[PATCH] be2net: use ARRAY_SIZE for array sizing calculation on array cmd_priv_map
From: Colin Ian King
Use the ARRAY_SIZE macro on array cmd_priv_map to determine size of the
array. Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 02dd5246dfae..1a49297224ed 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -103,7 +103,7 @@ static struct be_cmd_priv_map cmd_priv_map[] = {
static bool be_cmd_allowed(struct be_adapter *adapter, u8 opcode, u8 subsystem)
{
int i;
- int num_entries = sizeof(cmd_priv_map)/sizeof(struct be_cmd_priv_map);
+ int num_entries = ARRAY_SIZE(cmd_priv_map);
u32 cmd_privileges = adapter->cmd_privileges;
for (i = 0; i < num_entries; i++)
--
2.15.1
[PATCH] ipv6: use ARRAY_SIZE for array sizing calculation on array seg6_action_table
From: Colin Ian King
Use the ARRAY_SIZE macro on array seg6_action_table to determine size of
the array. Improvement suggested by coccinelle.
Signed-off-by: Colin Ian King
---
net/ipv6/seg6_local.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index 825b8e01f947..ba3767ef5e93 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -501,7 +501,7 @@ static struct seg6_action_desc *__get_action_desc(int
action)
struct seg6_action_desc *desc;
int i, count;
- count = sizeof(seg6_action_table) / sizeof(struct seg6_action_desc);
+ count = ARRAY_SIZE(seg6_action_table);
for (i = 0; i < count; i++) {
desc = &seg6_action_table[i];
if (desc->action == action)
--
2.15.1
Join the Mailing List
Join the Mailing List
Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks
On 01/05/2018 08:12 AM, Will Deacon wrote: > Aliasing attacks against CPU branch predictors can allow an attacker to > redirect speculative control flow on some CPUs and potentially divulge > information from one context to another. > > This patch adds initial skeleton code behind a new Kconfig option to > enable implementation-specific mitigations against these attacks for > CPUs that are affected. Thanks to Qualcomm for the (typically prompt and immediate) followup. As a reminder to the other usual server suspects (all of whom we've spoken with about mitigations for this so we know there things coming), I'm expecting to see your patches for this hit the list within the next 48 hours. You know who you are, and I'll be doing the rounds over the next 24 hours to check your status as to when you'll be posting these. Thanks, Jon. -- Computer Architect | Sent from my Fedora powered laptop
Re: "BUG: using smp_processor_id() in preemptible" with KPTI on 4.14.11
On Sun, Jan 07, 2018 at 09:53:19AM +0100, Thomas Zeitlhofer wrote: > On Sun, Jan 07, 2018 at 09:17:18AM +0100, Greg Kroah-Hartman wrote: > > On Sat, Jan 06, 2018 at 10:38:38PM +0100, Thomas Zeitlhofer wrote: [...] > > > While solving the previous problem, this patch also introduces new > > > "fun and games"... > > > > > > Now, terminating a systemd-nspawn container, reliably crashes the > > > host (so far tested only on Haswell, if that matters). Once, I was > > > able to capture the following trace: > > > > Is this also reproducable on Linus's tree right now? > > It is reproducible with this patch on top of 4.15-rc6 (might be able > to test Linus's current tree later that day). Some more testing showed that this is not caused by the patch after all, sorry for the noise. The crash happens quite reliably, but with a rather low probability it does not occur. When I have tested 4.14.11 without the patch it was obviously such a low probability event - in the meantime 4.14.11 without the patch also crashed. The situation is also unchanged with 4.15-rc7. Interestingly, it happens only when using the boot switch "-b", i.e.: systemd-nspawn -b -D _and_ terminating the container by pressing ^] three times. Other combinations (e.g., no "-b" and terminating with ^]^]^], "-b" and terminating by running shutdown inside the container) work just fine. Anyway, this is already off-topic and might be subject to a different thread... Thanks, Thomas
Re: [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
On 2018/1/6 4:55, SF Markus Elfring wrote:
From: Markus Elfring
Date: Fri, 5 Jan 2018 21:45:04 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
Acked-by: Wenyou Yang
drivers/mtd/nand/atmel/nand-controller.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/atmel/nand-controller.c
b/drivers/mtd/nand/atmel/nand-controller.c
index 90a71a56bc23..a41b999229c9 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
"%s:nand.%d", dev_name(nc->dev),
nand->cs[0].id);
- if (!mtd->name) {
- dev_err(nc->dev, "Failed to allocate mtd->name\n");
+ if (!mtd->name)
return -ENOMEM;
- }
}
ret = nand_scan_tail(mtd);
@@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct
atmel_nand_controller *nc,
nand = devm_kzalloc(nc->dev,
sizeof(*nand) + (numcs * sizeof(*nand->cs)),
GFP_KERNEL);
- if (!nand) {
- dev_err(nc->dev, "Failed to allocate NAND object\n");
+ if (!nand)
return ERR_PTR(-ENOMEM);
- }
nand->numcs = numcs;
Best Regards,
Wenyou Yang
[PATCH] arm: omap2: timer: fix a kmemleak caused in omap_get_timer_dt
When more than one GP timers are used as kernel system timers and the
corresponding nodes in device-tree are marked with the same "disabled"
property, then the "attr" field of the property will be initialized
more than once as the property being added to sys file system via
__of_add_property_sysfs().
In __of_add_property_sysfs(), the "name" field of pp->attr.attr is set
directly to the return value of safe_name(), without taking care of
whether it's already a valid pointer to a memory block. If it is, its
old value will always be overwritten by the new one and the memory block
allocated before will a "ghost", then a kmemleak happened.
That the same "disabled" property being added to different nodes of device
tree would cause that kind of kmemleak overhead, at leat once.
To fix it, allocate the property dynamically, and delete static one.
Signed-off-by: Qi Hou
---
arch/arm/mach-omap2/timer.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ece09c9..0e6109b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -156,12 +156,6 @@ static struct clock_event_device clockevent_gpt = {
.tick_resume= omap2_gp_timer_shutdown,
};
-static struct property device_disabled = {
- .name = "status",
- .length = sizeof("disabled"),
- .value = "disabled",
-};
-
static const struct of_device_id omap_timer_match[] __initconst = {
{ .compatible = "ti,omap2420-timer", },
{ .compatible = "ti,omap3430-timer", },
@@ -203,8 +197,17 @@ static struct device_node * __init omap_get_timer_dt(const
struct of_device_id *
of_get_property(np, "ti,timer-secure", NULL)))
continue;
- if (!of_device_is_compatible(np, "ti,omap-counter32k"))
- of_add_property(np, &device_disabled);
+ if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
+ struct property *prop;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop)
+ return -ENOMEM;
+ prop->name = "status";
+ prop->length = sizeof("disabled");
+ prop->value = "disabled";
+ of_add_property(np, prop);
+ }
return np;
}
--
2.7.4
Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs
On 1/6/2018 11:33 AM, Avi Kivity wrote: > Meltdown and Spectre mitigations focus on protecting the kernel from a > hostile userspace. However, it's not a given that the kernel is the most > important target in the system. It is common in server workloads that a > single userspace application contains the valuable data on a system, and if > it were hostile, the game would already be over, without the need to > compromise the kernel. > > > In these workloads, a single application performs most system calls, and so > it pays the cost of protection, without benefiting from it directly (since it > is the target, rather than the kernel). > > > I propose to create a new capability, CAP_PAYLOAD, that allows the system > administrator to designate an application as the main workload in that > system. Other processes (like sshd or monitoring daemons) exist to support > it, and so it makes sense to protect the rest of the system from their being > compromised. As one of the authors of the POSIX 1003.1e/2c WITHDRAWN DRAFT capability specification I emphatically NAK this proposal. This is nothing like what capabilities are for. It doesn't fit the use model and it isn't in any way related to enforcing system security policy. > When the kernel switches to user mode of a CAP_PAYLOAD process, it doesn't > switch page tables and instead leaves the kernel mapped into the adddress > space (still with supervisor protection, of course). This reduces context > switch cost, and will also reduce interrupt costs if the interrupt happens > while that process executes. Since a CAP_PAYLOAD process is likely to consume > the majority of CPU time, the costs associated with Meltdown mitigation are > almost completely nullified. This is a horrible hack. The potential for exploitable edge cases is enormous. > CAP_PAYLOAD has potential to be abused; Yet another really, really good reason not to implement it. > every software vendor will be absolutely certain that their application is > the reason the universe (let alone that server) exists and they will turn it > on, so init systems will have to work to make it doesn't get turned on > without administrator opt-in. It's also not perfect, since if there is a > payload application compromise, in addition to stealing the application's > data ssh keys can be stolen too. But I think it's better than having to > choose between significantly reduced performance and security. You get > performance for your important application, and protection against the > possibility that a remote exploit against a supporting process turns into a > remote exploit against that important application. This is just not a viable use of the capability mechanism. I am not at liberty to comment on any aspect of the exploits du'jour, so suggesting alternatives is not something I can do just now.
RE: [PATCH 2/7] ARM: dts: imx6ul: update i.MX 6UltraLite iomux headers
From: Rob Herring Sent: Saturday, January 06, 2018 12:45 AM >To: Stefan Agner >Cc: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam >; mark.rutl...@arm.com; linux-arm- >ker...@lists.infradead.org; devicet...@vger.kernel.org; linux- >ker...@vger.kernel.org; Andy Duan >Subject: Re: [PATCH 2/7] ARM: dts: imx6ul: update i.MX 6UltraLite iomux >headers > >On Tue, Jan 02, 2018 at 05:42:18PM +0100, Stefan Agner wrote: >> From: Fugang Duan >> >> Update i.MX 6UltraLite IOMUXC pin defines. > >That's obvious reading the diff. The commit message should tell me why. >They were wrong? > Yes, the previous iomux header parts of pin setting were wrong, which was generated by IOMUX tool during SOC bringup. The updated header correct the wrong pin setting. >> >> Signed-off-by: Fugang Duan >> Signed-off-by: Stefan Agner
Re: [PATCH v7 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
Hi, Wei On 2018年01月06日 17:51, Li Wei wrote: This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board. Usually here should list the change compared with the last change set, to make it easier to reviewer, who may pay more attention to the differences. For example v7:xxx //change since v6 v6:xxx // change since v5 Li Wei (5): scsi: ufs: add Hisilicon ufs driver code dt-bindings: scsi: ufs: add document for hisi-ufs arm64: dts: add ufs dts node arm64: defconfig: enable configs for Hisilicon ufs arm64: defconfig: enable f2fs and squashfs Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 43 ++ arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 20 + arch/arm64/configs/defconfig | 11 + drivers/scsi/ufs/Kconfig | 9 + drivers/scsi/ufs/Makefile | 1 + drivers/scsi/ufs/ufs-hisi.c| 621 + drivers/scsi/ufs/ufs-hisi.h| 116 7 files changed, 821 insertions(+) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt create mode 100644 drivers/scsi/ufs/ufs-hisi.c create mode 100644 drivers/scsi/ufs/ufs-hisi.h
答复: [PATCH v7 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
Hi. Zhangfei Thank you, I will add it in the next patch. -邮件原件- 发件人: zhangfei [mailto:zhangfei@linaro.org] 发送时间: 2018年1月8日 9:40 收件人: liwei (CM); robh...@kernel.org; mark.rutl...@arm.com; xuwei (O); catalin.mari...@arm.com; will.dea...@arm.com; vinholika...@gmail.com; j...@linux.vnet.ibm.com; martin.peter...@oracle.com; khil...@baylibre.com; a...@arndb.de; gregory.clem...@free-electrons.com; thomas.petazz...@free-electrons.com; yamada.masah...@socionext.com; riku.voi...@linaro.org; tred...@nvidia.com; k...@kernel.org; e...@anholt.net; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-s...@vger.kernel.org 抄送: zangleigang; Gengjianfeng; guodong...@linaro.org; Fengbaopeng (kevin, Kirin Solution Dept) 主题: Re: [PATCH v7 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC Hi, Wei On 2018年01月06日 17:51, Li Wei wrote: > This patchset adds driver support for UFS for Hi3660 SoC. It is verified on > HiKey960 board. Usually here should list the change compared with the last change set, to make it easier to reviewer, who may pay more attention to the differences. For example v7:xxx //change since v6 v6:xxx // change since v5 > Li Wei (5): >scsi: ufs: add Hisilicon ufs driver code >dt-bindings: scsi: ufs: add document for hisi-ufs >arm64: dts: add ufs dts node >arm64: defconfig: enable configs for Hisilicon ufs >arm64: defconfig: enable f2fs and squashfs > > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 43 ++ > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 20 + > arch/arm64/configs/defconfig | 11 + > drivers/scsi/ufs/Kconfig | 9 + > drivers/scsi/ufs/Makefile | 1 + > drivers/scsi/ufs/ufs-hisi.c| 621 > + > drivers/scsi/ufs/ufs-hisi.h| 116 > 7 files changed, 821 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt > create mode 100644 drivers/scsi/ufs/ufs-hisi.c > create mode 100644 drivers/scsi/ufs/ufs-hisi.h >
Re: [PATCH] USB: musb: da8xx: remove clock con_id
On 01/05/2018 07:50 PM, David Lechner wrote: There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- superseded by https://marc.info/?l=linux-usb&m=151529526103513&w=2
Re: [PATCH] USB: ohci: da8xx: remove clk con_id
On 01/05/2018 07:53 PM, David Lechner wrote: The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- superseded by https://marc.info/?l=linux-usb&m=151529526103513&w=2
RE: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul
Best Regards! Anson Huang > -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: 2018-01-08 7:34 AM > To: Anson Huang > Cc: Rafael J. Wysocki ; linux-arm- > ker...@lists.infradead.org; devicet...@vger.kernel.org; Linux PM p...@vger.kernel.org>; Linux Kernel Mailing List ker...@vger.kernel.org>; Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Rob > Herring ; Mark Rutland ; > Russell King - ARM Linux ; Viresh Kumar > ; Jacky Bai ; A.s. Dong > > Subject: Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for > i.mx6ul > > On Saturday, January 6, 2018 4:05:41 AM CET Anson Huang wrote: > > Hi, Rafael > > > > Best Regards! > > Anson Huang > > > > > > > -Original Message- > > > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > > > Rafael J. Wysocki > > > Sent: 2018-01-05 8:21 PM > > > To: Anson Huang > > > Cc: linux-arm-ker...@lists.infradead.org; > > > devicet...@vger.kernel.org; Linux PM ; > > > Linux Kernel Mailing List ; Shawn Guo > > > ; Sascha Hauer ; Fabio > > > Estevam ; Rob Herring ; > > > Mark Rutland ; Russell King - ARM Linux > > > ; Rafael J. Wysocki ; > > > Viresh Kumar ; Jacky Bai > > > ; A.s. Dong > > > Subject: Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point > > > for i.mx6ul > > > > > > On Tue, Jan 2, 2018 at 6:07 PM, Anson Huang > wrote: > > > > Add 696MHz operating point for i.MX6UL, only for those parts with > > > > speed grading fuse set to 2b'10 supports 696MHz operating point, > > > > so, speed grading check is also added for i.MX6UL in this patch, > > > > the clock tree for each operating point are as below: > > > > > > > > 696MHz: > > > > pll1 69600 > > > >pll1_bypass 69600 > > > > pll1_sys 69600 > > > > pll1_sw 69600 > > > > arm69600 > > > > 528MHz: > > > > pll2 52800 > > > >pll2_bypass 52800 > > > > pll2_bus 52800 > > > > ca7_secondary_sel 52800 > > > > step 52800 > > > >pll1_sw 52800 > > > > arm 52800 > > > > 396MHz: > > > > pll2_pfd2_396m 39600 > > > >ca7_secondary_sel 39600 > > > > step 39600 > > > > pll1_sw 39600 > > > > arm39600 > > > > 198MHz: > > > > pll2_pfd2_396m 39600 > > > >ca7_secondary_sel 39600 > > > > step 39600 > > > > pll1_sw 39600 > > > > arm19800 > > > > > > > > Signed-off-by: Anson Huang > > > > > > This doesn't apply for me and in a nontrivial way. > > > > > > What kernel is it against? > > > > I did it based on linux-next, it should be on linux-next-pm branch, I > > redo the patch set V2 based on linux-next-pm, also redo the test, > > sorry for the inconvenience. > > But you didn't add the Reviewed-by: tags from Fabio to them. > > Was that on purpose or by mistake? > > Thanks, > Rafael It was my mistake, I thought it will be added by maintainer, I will add them and set a V3 patch set. Thanks. Anson.
Re: [PATCH] mm: ratelimit end_swap_bio_write() error
On (01/06/18 14:34), Michal Hocko wrote: > > zsmalloc allocation is just one possibility; an error in > > compressing algorithm is another one, yet is rather unlikely. > > most likely it's OOM which can cause problems. but in any case > > it's sort of unclear what should be done. an error can be a > > temporary one or a fatal one, just like in __swap_writepage() > > case. so may be both write error printk()-s can be dropped. > > Then I would suggest starting with sorting out which of those errors are > critical and which are not and report the error accordingly. I am sorry > to be fuzzy here but I am not familiar with the code to be more > specific. Anyway ratelimiting sounds more like a paper over than a real > solution. Also it sounds quite scary that you can see so many failures > to actually lock up the system just by printing a message... the lockup is not the main problem and I'm not really trying to address it here. we simply can fill up the entire kernel logbuf with the same "Write-error on swap-device" errors. -ss
Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Thomas Gleixner Date: Sun, 7 Jan 2018 19:31:41 +0100 (CET) > 2) Alexei's analyis is purely based on the public information of the google >zero folks. If it would be complete and the only attack vector all fine. > >If not and I doubt it is, we're going to regret this decision faster >than we made it and this is not the kind of play field where we can >afford that. Please state this more clearly. Do you know about other attack vectors and just are not allowed to talk about them? Or is this, ironically, speculation?
[PATCH -next] ASoC: mediatek: mt2701: fix return value check in mt2701_afe_pcm_dev_probe()
In case of error, the function syscon_node_to_regmap() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Fixes: dfa3cbb83e09 ("ASoC: mediatek: modify MT2701 AFE driver to adapt mfd
device")
Signed-off-by: Wei Yongjun
---
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index f0cd08f..5bc4e00 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -1440,9 +1440,9 @@ static int mt2701_afe_pcm_dev_probe(struct
platform_device *pdev)
}
afe->regmap = syscon_node_to_regmap(dev->parent->of_node);
- if (!afe->regmap) {
+ if (IS_ERR(afe->regmap)) {
dev_err(dev, "could not get regmap from parent\n");
- return -ENODEV;
+ return PTR_ERR(afe->regmap);
}
mutex_init(&afe->irq_alloc_lock);
Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Alexei Starovoitov wrote: > > which clearly states that bpf_tail_call() was used in the attack. > > Yet none of the intel nor arm patches address speculation in > > this bpf helper! > > It means that: > > - gpz didn't share neither exploit nor the detailed description > > of the POC with cpu vendors until now > > - coverity rules used to find all these places in the kernel > > failed to find bpf_tail_call > > - cpu vendors were speculating what variant 1 can actually do > > You forgot to mention that there might be other attacks than the public POC > which are not covered by a simple AND if above statement is not a pure speculation please share CVE number. For varaint[123] they've been reserved for months. > For spectre_v1/2 we face the same problem simply because we got informed so > much ahead of time and we were all twiddling thumbs, enjoying our christmas > vacation and having a good time. right. they were informed in a way that they failed to address variant1 with pre-embargo and public patches. > The exploits are out in the wild and they are observed already, so we this statement contradicts with everything that was publicly stated. Or you're referring to 'exploit' at the end of spectre paper? > want to discuss the right way to fix it for the next 3 month and leave all > doors open until the last bit of performance is squeezed out. Let's look at facts: - Linus explains his array_access() idea - lfence proponents quickly point out that it needs gcc to be smart enough to emit setbe and go back to lfence patches - I spent half an hour to tweak array_access() to be generic on all archs and compiler indepedent - lfence proponets point out that AND with a variable somehow won't work, yet after further discussion it's actually fine due to the nature of variant1 attack that needs to train predictor with in-bounds access to mispredict with out-of-bounds speculative load - then lfence proponets claim 'non public POC' not covered by AND - it all in the matter of 2 days. - and now the argument that it will take 3 month to discuss a solution without lfence, yet still no performance numbers for lfence though 'people in the know' were twiddling thumbs for months. That's just not cool.
Re: [PATCH 00/13] replace print_symbol() with printk()-s
On (01/05/18 15:42), Petr Mladek wrote: > > I am all for it. But I would postpone this removal to 4.17. > The reason is rather ugly. 13th patch is already in arc tree. > We would need to shuffle the patch or coordinate pull requests. JFI, the patch is in Linus's tree as of now (d0729bc6bee797fb). -ss
[PATCH v2] pinctrl: qcom: Add msm8998 pinctrl driver
From: "Khan, Imran" Add initial pinctrl driver to support pin configuration with pinctrl framework for msm8998. Signed-off-by: Imran Khan Acked-by: Rob Herring [bjorn: Consolidated function groups] Signed-off-by: Bjorn Andersson --- This was never resubmitted after my review a year ago, so fixing up the few comments I had and posting it again. Changes since v1: - Consolidated phase_flag and gdss function groups - Corrected ngpios - Changed to SPDX license header .../bindings/pinctrl/qcom,msm8998-pinctrl.txt | 193 +++ drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-msm8998.c | 1590 4 files changed, 1792 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8998.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt new file mode 100644 index ..e70c79bbbc5b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt @@ -0,0 +1,193 @@ +Qualcomm MSM8998 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8998 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,msm8998-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. + + Valid pins are: + gpio0-gpio149 + Supports mux, bias and drive-strength + + sdc2_clk, sdc2_cmd, sdc2_data + Supports bias and drive-strength + + ufs_reset + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + gpio, adsp_ext, agera_pll, atest_char, atest_gpsadc0, + atest_gpsadc1, atest_tsens, atest_tsens2, atest_usb1, + atest_usb10, atest_usb11, atest_usb12, atest_usb13, + audio_ref, bimc_dte0, bimc_dte1, blsp10_spi, blsp10_spi_a, + blsp10_spi_b, blsp11_i2c, blsp1_spi, blsp1_spi_a, + blsp1_spi_b, blsp2_spi, blsp9_spi, blsp_i2c1, blsp_i2c2, + blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, + blsp_i2c8, blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
[PATCH v5 00/44] ARM: davinci: convert to common clock framework
This series converts mach-davinci to use the common clock framework. The series works like this, the first 21 patches create new clock drivers using the common clock framework. There are basically 3 groups of clocks - PLL, PSC and CFGCHIP (syscon). There are six different SoCs that each have unique init data, which is the reason for so many patches. Then, starting with "ARM: davinci: move davinci_clk_init() to init_time", we get the mach code ready for the switch by adding the code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK around the legacy clocks so that we can switch easily between the old and the new. "ARM: davinci: switch to common clock framework" actually flips the switch to start using the new clock drivers. Then the next 8 patches remove all of the old clock code. The final three patches add device tree support to the one SoC that supports it. v5 changes: - Basically, this is an entirely new series - Patches are broken up into bite-sized pieces - Converted PSC clock driver to use regmap - Restored "force" flag for certain DA850 clocks - Added device tree bindings - Moved more of the clock init to drivers/clk - Fixed frequency scaling (maybe*) * I have frequency scaling using cpufreq-dt, so I know the clocks are doing what they need to do to make this work, but I haven't figured out how to test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be sent separately after this series has landed.) Dependencies: This series applies on top of linux-davinci/master plus the following patches: - [1] clk: fix reentrancy of clk_enable() on UP systems - [2] clk: add helper functions for managing clk_onecell_data - [3] clk: divider: fix clk_round_rate() when CLK_DIVIDER_READ_ONLY && CLK_RATE_SET_PARENT - [4] watchdog: davinci_wdt: add restart function - [5] ARM: davinci: remove watchdog reset - [6] USB: musb: da8xx: remove clock con_id - [7] USB: ohci: da8xx: remove clk con_id - [8] ARM: da8xx: remove con_id from USB clocks You can find a working branch with everything included in the "common-clk-v5" branch of https://github.com/dlech/ev3dev-kernel.git. [1]: https://patchwork.kernel.org/patch/10145933/ [2]: https://patchwork.kernel.org/patch/10145873/ [3]: https://patchwork.kernel.org/patch/10147983/ [4]: https://patchwork.kernel.org/patch/10148097/ [5]: https://patchwork.kernel.org/patch/10148099/ [6]: https://patchwork.kernel.org/patch/10148111/ [7]: https://patchwork.kernel.org/patch/10148107/ [8]: https://patchwork.kernel.org/patch/10148109/ Testing/debugging for the uninitiated: I only have one device to test with, which is based on da850, so I will have to rely on others to do some testing here. Since we are dealing with clocks, if something isn't working, you most likely won't see output on the serial port. To figure out what is going on, you need to enable... CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y and add "earlyprintk clk_ignore_unused" to the kernel command line options. You may need to select a different UART for this depending on your board. I think UART1 is the default in the kernel configuration. On da850 devices comment out the lines: else clk_set_parent(clk, parent->clk); in da850.c or, if using device tree, comment out the lines: assigned-clocks = <&async3_clk>; assigned-clock-parents = <&pll1_sysclk 2>; in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock source will change during boot and cause garbled output after a point. David Lechner (44): dt-bindings: clock: Add new bindings for TI Davinci PLL clocks clk: davinci: New driver for davinci PLL clocks clk: davinci: Add platform information for TI DA830 PLL clk: davinci: Add platform information for TI DA850 PLL clk: davinci: Add platform information for TI DM355 PLL clk: davinci: Add platform information for TI DM365 PLL clk: davinci: Add platform information for TI DM644x PLL clk: davinci: Add platform information for TI DM646x PLL dt-bindings: clock: New bindings for TI Davinci PSC clk: davinci: New driver for davinci PSC clocks clk: davinci: Add platform information for TI DA830 PSC clk: davinci: Add platform information for TI DA850 PSC clk: davinci: Add platform information for TI DM355 PSC clk: davinci: Add platform information for TI DM365 PSC clk: davinci: Add platform information for TI DM644x PSC clk: davinci: Add platform information for TI DM646x PSC dt-bindings: clock: Add bindings for DA8XX CFGCHIP gate clocks dt-bindings: clock: Add binding for TI DA8XX CFGCHIP mux clocks clk: davinci: New driver for TI DA8XX CFGCHIP clocks dt-bindings: clock: Add bindings for TI DA8XX USB PHY clocks clk: davinci: New driver for TI DA8XX USB PHY clocks ARM: davinci: move davinci_clk_init() to init_time ARM: da830: add new clock init using common clock framework ARM: da850: add new clock init using common clock framework ARM: dm355: add new c
[PATCH v5 06/44] clk: davinci: Add platform information for TI DM365 PLL
This adds platform-specific declarations for the PLL clocks on TI
DaVinci 365 based systems.
Signed-off-by: David Lechner
---
drivers/clk/davinci/Makefile| 1 +
drivers/clk/davinci/pll-dm365.c | 64 +
include/linux/clk/davinci.h | 1 +
3 files changed, 66 insertions(+)
create mode 100644 drivers/clk/davinci/pll-dm365.c
diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
index 6720bd0..353aa02 100644
--- a/drivers/clk/davinci/Makefile
+++ b/drivers/clk/davinci/Makefile
@@ -5,4 +5,5 @@ obj-y += pll.o
obj-$(CONFIG_ARCH_DAVINCI_DA830) += pll-da830.o
obj-$(CONFIG_ARCH_DAVINCI_DA850) += pll-da850.o
obj-$(CONFIG_ARCH_DAVINCI_DM355) += pll-dm355.o
+obj-$(CONFIG_ARCH_DAVINCI_DM365) += pll-dm365.o
endif
diff --git a/drivers/clk/davinci/pll-dm365.c b/drivers/clk/davinci/pll-dm365.c
new file mode 100644
index 000..9892b0b
--- /dev/null
+++ b/drivers/clk/davinci/pll-dm365.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PLL clock descriptions for TI DM365
+ *
+ * Copyright (C) 2017 David Lechner
+ */
+
+#include
+#include
+#include
+
+#include "pll.h"
+
+static const char * const dm365_pll_obsclk_parent_names[] = {
+ "ref_clk",
+};
+
+static u32 dm365_pll_obsclk_table[] = {
+ 0x10,
+};
+
+static const struct davinci_pll_divclk_info dm365_pll1_divclk_info[]
__initconst = {
+ DIVCLK(1, pll1_sysclk1, pll1, 0),
+ DIVCLK(2, pll1_sysclk2, pll1, 0),
+ DIVCLK(3, pll1_sysclk3, pll1, 0),
+ DIVCLK(4, pll1_sysclk4, pll1, 0),
+ DIVCLK(5, pll1_sysclk5, pll1, 0),
+ DIVCLK(6, pll1_sysclk6, pll1, 0),
+ DIVCLK(7, pll1_sysclk7, pll1, 0),
+ DIVCLK(8, pll1_sysclk8, pll1, 0),
+ DIVCLK(9, pll1_sysclk9, pll1, 0),
+ { }
+};
+
+static const struct davinci_pll_divclk_info dm365_pll2_divclk_info[]
__initconst = {
+ DIVCLK(1, pll2_sysclk1, pll2, 0),
+ DIVCLK(2, pll2_sysclk2, pll2, 0),
+ DIVCLK(3, pll2_sysclk3, pll2, 0),
+ DIVCLK(4, pll2_sysclk4, pll2, 0),
+ DIVCLK(5, pll2_sysclk5, pll2, 0),
+ { }
+};
+
+void __init dm365_pll_clk_init(void __iomem *pll1, void __iomem *pll2)
+{
+ const struct davinci_pll_divclk_info *info;
+
+ davinci_pll_clk_register("pll1", "ref_clk", pll1);
+ davinci_pll_aux_clk_register("pll1_aux_clk", "ref_clk", pll1);
+ davinci_pll_bpdiv_clk_register("pll1_sysclkbp", "ref_clk", pll1);
+ davinci_pll_obs_clk_register("clkout0", dm365_pll_obsclk_parent_names,
+ARRAY_SIZE(dm365_pll_obsclk_parent_names),
+pll1, dm365_pll_obsclk_table);
+ for (info = dm365_pll1_divclk_info; info->name; info++)
+ davinci_pll_divclk_register(info, pll1);
+
+ davinci_pll_clk_register("pll2", "ref_clk", pll2);
+ davinci_pll_aux_clk_register("clkout1", "ref_clk", pll2);
+ davinci_pll_obs_clk_register("clkout1", dm365_pll_obsclk_parent_names,
+ ARRAY_SIZE(dm365_pll_obsclk_parent_names),
+ pll2, dm365_pll_obsclk_table);
+ for (info = dm365_pll2_divclk_info; info->name; info++)
+ davinci_pll_divclk_register(info, pll2);
+}
diff --git a/include/linux/clk/davinci.h b/include/linux/clk/davinci.h
index 95333fe..5bf60a7 100644
--- a/include/linux/clk/davinci.h
+++ b/include/linux/clk/davinci.h
@@ -12,5 +12,6 @@
void da830_pll_clk_init(void __iomem *pll);
void da850_pll_clk_init(void __iomem *pll0, void __iomem *pll1);
void dm355_pll_clk_init(void __iomem *pll1, void __iomem *pll2);
+void dm365_pll_clk_init(void __iomem *pll1, void __iomem *pll2);
#endif /* __LINUX_CLK_DAVINCI_H__ */
--
2.7.4
[PATCH v5 12/44] clk: davinci: Add platform information for TI DA850 PSC
This adds platform-specific declarations for the PSC clocks on TI DA850/
OMAP-L138/AM18XX SoCs.
Signed-off-by: David Lechner
---
drivers/clk/davinci/Makefile| 1 +
drivers/clk/davinci/psc-da850.c | 117
include/linux/clk/davinci.h | 1 +
3 files changed, 119 insertions(+)
create mode 100644 drivers/clk/davinci/psc-da850.c
diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
index fb14c8c..aef0390 100644
--- a/drivers/clk/davinci/Makefile
+++ b/drivers/clk/davinci/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x) += pll-dm646x.o
obj-y += psc.o
obj-$(CONFIG_ARCH_DAVINCI_DA830) += psc-da830.o
+obj-$(CONFIG_ARCH_DAVINCI_DA850) += psc-da850.o
endif
diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
new file mode 100644
index 000..3b4583d
--- /dev/null
+++ b/drivers/clk/davinci/psc-da850.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PSC clock descriptions for TI DA850/OMAP-L138/AM18XX
+ *
+ * Copyright (C) 2017 David Lechner
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "psc.h"
+
+static const struct davinci_psc_clk_info da850_psc0_info[] __initconst = {
+ LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(3, 0, aemif, pll0_sysclk3, 0),
+ LPSC(4, 0, spi0, pll0_sysclk2, 0),
+ LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
+ LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(7, 0, arm_rom, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(9, 0, uart0, pll0_sysclk2, 0),
+ LPSC(13, 0, pruss, pll0_sysclk2, 0),
+ LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
+ LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
+ { }
+};
+
+static const struct davinci_psc_clk_info da850_psc1_info[] __initconst = {
+ LPSC(0, 0, tpcc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(1, 0, usb0, pll0_sysclk2, 0),
+ LPSC(2, 0, usb1, pll0_sysclk4, 0),
+ LPSC(3, 0, gpio, pll0_sysclk4, 0),
+ LPSC(5, 0, emac, pll0_sysclk4, 0),
+ LPSC(6, 0, emif3, pll0_sysclk5, LPSC_ALWAYS_ENABLED),
+ LPSC(7, 0, mcasp0, async3, 0),
+ LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE),
+ LPSC(9, 0, vpif, pll0_sysclk2, 0),
+ LPSC(10, 0, spi1, async3, 0),
+ LPSC(11, 0, i2c1, pll0_sysclk4, 0),
+ LPSC(12, 0, uart1, async3, 0),
+ LPSC(13, 0, uart2, async3, 0),
+ LPSC(14, 0, mcbsp0, async3, 0),
+ LPSC(15, 0, mcbsp1, async3, 0),
+ LPSC(16, 0, lcdc, pll0_sysclk2, 0),
+ LPSC(17, 0, ehrpwm, async3, 0),
+ LPSC(18, 0, mmcsd1, pll0_sysclk2, 0),
+ LPSC(20, 0, ecap, async3, 0),
+ LPSC(21, 0, tptc2, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ { }
+};
+
+void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1)
+{
+ struct clk_onecell_data *clk_data;
+
+ clk_data = davinci_psc_register_clocks(psc0, da850_psc0_info, 16);
+ if (!clk_data)
+ return;
+
+ clk_register_clkdev(clk_data->clks[3], NULL, "ti-aemif");
+ clk_register_clkdev(clk_data->clks[3], "aemif", "davinci-nand.0");
+ clk_register_clkdev(clk_data->clks[4], NULL, "spi_davinci.0");
+ clk_register_clkdev(clk_data->clks[5], NULL, "da830-mmc.0");
+ clk_register_clkdev(clk_data->clks[9], NULL, "serial8250.0");
+ clk_register_clkdev(clk_data->clks[14], "arm", NULL);
+ clk_register_clkdev(clk_data->clks[15], NULL, "davinci-rproc.0");
+
+ clk_free_onecell_data(clk_data);
+
+ clk_data = davinci_psc_register_clocks(psc1, da850_psc1_info, 32);
+ if (!clk_data)
+ return;
+
+ clk_register_clkdev(clk_data->clks[1], "usb20_psc_clk", NULL);
+ clk_register_clkdev(clk_data->clks[1], NULL, "musb-da8xx");
+ clk_register_clkdev(clk_data->clks[1], NULL, "cppi41-dmaengine");
+ clk_register_clkdev(clk_data->clks[2], NULL, "ohci-da8xx");
+ clk_register_clkdev(clk_data->clks[3], "gpio", NULL);
+ clk_register_clkdev(clk_data->clks[5], NULL, "davinci_emac.1");
+ clk_register_clkdev(clk_data->clks[5], "fck", "davinci_mdio.0");
+ clk_register_clkdev(clk_data->clks[7], NULL, "davinci-mcasp.0");
+ clk_register_clkdev(clk_data->clks[8], "fck", "ahci_da850");
+ clk_register_clkdev(clk_data->clks[9], NULL, "vpif");
+ clk_register_clkdev(clk_data->clks[10], NULL, "spi_davinci.1");
+ clk_register_clkdev(clk_data->clks[11], NULL, "i2c_davinci.2");
+ clk_register_clkdev(clk_data->clks[12], NULL, "serial8250.1");
+ clk_register_clkdev(clk_data->clks[13], NULL, "serial8250.2");
+ clk_register_clkdev(clk_data->clks[14], NULL, "davinci-mcbsp.0");
+ clk_register_clkdev(clk_data->clks[15], NULL, "davinci-mcbsp.1");
+ clk_register_clkdev(clk_data->cl
[PATCH v5 20/44] dt-bindings: clock: Add bindings for TI DA8XX USB PHY clocks
This adds a new binding for TI DA8XX USB PHY clocks. These clocks are part
of a syscon register called CFGCHIP3.
Signed-off-by: David Lechner
---
.../clock/ti/davinci/da8xx-cfgchip-usb-phy.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-usb-phy.txt
diff --git
a/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-usb-phy.txt
b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-usb-phy.txt
new file mode 100644
index 000..8a12e1b
--- /dev/null
+++
b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-usb-phy.txt
@@ -0,0 +1,55 @@
+Binding for TI DA8XX/OMAP-L13X/AM17XX/AM18XX CFGCHIP USB PHY clocks
+
+TI DA8XX/OMAP-L13X/AM17XX/AM18XX SoCs contain a general purpose set of
+registers call CFGCHIPn. Some of these registers function as the USB PHY
+clocks. This document describes the bindings for those clocks.
+
+Required properties:
+- compatible: shall be one of:
+ - "ti,da830-usb0-phy-clock" for the USB 2.0 PHY
+ - "ti,da830-usb1-phy-clock" for the USB 1.1 PHY
+- #clock-cells: from common clock binding; shall be set to 0.
+- clocks: phandle list of clocks corresponding to clock-names
+- clock-names: depends on compatible:
+ - for "ti,da830-usb0-phy-clock" must be "usb_refclkin", "auxclk",
+ "usb0_lpsc"
+ - for "ti,da830-usb1-phy-clock" must be "usb0_phy", "usb_refclkin"
+
+Optional properties:
+- clock-output-names: from common clock binding.
+
+Parent:
+ This node must be a child of a "ti,da830-cfgchip" node.
+
+Assignment:
+ The assigned-clocks and assigned-clock-parents properties from the
+ common clock bindings can be used to indicate which parent clock should
+ be used. Note: for "ti,da830-usb0-phy-clock", only "usb_refclkin" or
+ "auxclk" can be used as the assigned parent clock ("usb0_lpsc" is not
+ an actual parent clock and only used internally).
+
+Examples:
+
+ cfgchip: syscon@1417c {
+ compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
+ reg = <0x1417c 0x14>;
+
+ usb0_phy_clk: usb0-phy-clock {
+ compatible = "ti,da830-usb0-phy-clock";
+ #clock-cells = <0>;
+ clocks = <&usb_refclkin>, <&pll0_aux_clk>, <&psc1 1>;
+ clock-names = "usb_refclkin", "auxclk", "usb0_lpsc";
+ clock-output-names = "usb0_phy_clk";
+ };
+
+ usb1_phy_clk: usb1-phy-clock {
+ compatible = "ti,da830-usb1-phy-clock";
+ #clock-cells = <0>;
+ clocks = <&usb0_phy_clk>, <&usb_refclkin>;
+ clock-names = "usb0_phy", "usb_refclkin";
+ clock-output-names = "usb1_phy_clk";
+ };
+ };
+
+Also see:
+- Documentation/devicetree/bindings/clock/clock-bindings.txt
--
2.7.4
[PATCH v5 29/44] ARM: da8xx: add new USB PHY clock init using common clock framework
This adds the new USB PHY clock init in mach-davinci/usb-da8xx.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/usb-da8xx.c | 84 ++-
1 file changed, 83 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/usb-da8xx.c
b/arch/arm/mach-davinci/usb-da8xx.c
index d480a02..d7340670 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -2,28 +2,36 @@
/*
* DA8xx USB
*/
+#include
#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
-#include
#include
#include
#include
#include
+#ifndef CONFIG_COMMON_CLK
+#include
#include "clock.h"
+#endif
#define DA8XX_USB0_BASE0x01e0
#define DA8XX_USB1_BASE0x01e25000
+#ifndef CONFIG_COMMON_CLK
static struct clk *usb20_clk;
+#endif
static struct platform_device da8xx_usb_phy = {
.name = "da8xx-usb-phy",
@@ -128,6 +136,7 @@ int __init da8xx_register_usb11(struct da8xx_ohci_root_hub
*pdata)
return platform_device_register(&da8xx_usb11_device);
}
+#ifndef CONFIG_COMMON_CLK
static struct clk usb_refclkin = {
.name = "usb_refclkin",
.set_rate = davinci_simple_set_rate,
@@ -354,3 +363,76 @@ int __init da8xx_register_usb11_phy_clk(bool
use_usb_refclkin)
return ret;
}
+#else
+/**
+ * da8xx_register_usb20_phy_clk - register USB0PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "pll0_aux_clk" if false.
+ */
+int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
+{
+ struct regmap *cfgchip;
+ struct clk *usb0_psc_clk, *clk;
+ struct clk_hw *parent;
+
+ cfgchip = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
+ if (IS_ERR(cfgchip))
+ cfgchip = syscon_regmap_lookup_by_pdevname("syscon");
+ if (IS_ERR(cfgchip))
+ return PTR_ERR(cfgchip);
+
+ usb0_psc_clk = clk_get_sys("musb-da8xx", NULL);
+ if (IS_ERR(usb0_psc_clk))
+ return PTR_ERR(usb0_psc_clk);
+
+ clk = da8xx_usb0_phy_clk_register("usb0_phy_clk", "usb_refclkin",
+ "pll0_aux_clk", usb0_psc_clk,
cfgchip);
+ if (IS_ERR(clk)) {
+ clk_put(usb0_psc_clk);
+ return PTR_ERR(clk);
+ }
+
+ parent = clk_hw_get_parent_by_index(__clk_get_hw(clk),
+ use_usb_refclkin ? 0 : 1);
+ if (parent)
+ clk_set_parent(clk, parent->clk);
+ else
+ pr_warn("%s: Failed to find parent clock\n", __func__);
+
+ return clk_register_clkdev(clk, "usb20_phy", "da8xx-usb-phy");
+}
+
+/**
+ * da8xx_register_usb11_phy_clk - register USB1PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "usb0_phy_clk" if false.
+ */
+int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
+{
+ struct regmap *cfgchip;
+ struct clk *clk;
+ struct clk_hw *parent;
+
+ cfgchip = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
+ if (IS_ERR(cfgchip))
+ cfgchip = syscon_regmap_lookup_by_pdevname("syscon");
+ if (IS_ERR(cfgchip))
+ return PTR_ERR(cfgchip);
+
+ clk = da8xx_usb1_phy_clk_register("usb1_phy_clk", "usb0_phy_clk",
+ "usb_refclkin", cfgchip);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ parent = clk_hw_get_parent_by_index(__clk_get_hw(clk),
+ use_usb_refclkin ? 1 : 0);
+ if (parent)
+ clk_set_parent(clk, parent->clk);
+ else
+ pr_warn("%s: Failed to find parent clock\n", __func__);
+
+ return clk_register_clkdev(clk, "usb11_phy", "da8xx-usb-phy");
+}
+#endif
--
2.7.4
[PATCH v5 27/44] ARM: dm644x: add new clock init using common clock framework
This adds the new board-specfic clock init in mach-davinci/dm644x.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Also clean up the #includes since we are adding some here.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/dm644x.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index b409801..bc2e243 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -8,28 +8,34 @@
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
-#include
+#include
#include
-#include
+#include
+#include
#include
-#include
+#include
#include
#include
+#include
+#include
#include
+#include
#include
#include
-#include "psc.h"
#include
-#include
#include
-#include
+#include
+#include "asp.h"
#include "davinci.h"
-#include "clock.h"
#include "mux.h"
-#include "asp.h"
+
+#ifndef CONFIG_COMMON_CLK
+#include "clock.h"
+#include "psc.h"
+#endif
/*
* Device specific clocks
@@ -43,6 +49,7 @@
#define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000
#define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000
+#ifndef CONFIG_COMMON_CLK
static struct pll_data pll1_data = {
.num = 1,
.phys_base = DAVINCI_PLL1_BASE,
@@ -326,6 +333,7 @@ static struct clk_lookup dm644x_clks[] = {
CLK("davinci-wdt", NULL, &timer2_clk),
CLK(NULL, NULL, NULL),
};
+#endif
static struct emac_platform_data dm644x_emac_pdata = {
.ctrl_reg_offset= DM644X_EMAC_CNTRL_OFFSET,
@@ -934,7 +942,19 @@ void __init dm644x_init(void)
void __init dm644x_init_time(void)
{
+#ifdef CONFIG_COMMON_CLK
+ void __iomem *pll1, *pll2, *psc;
+
+ pll1 = ioremap(DAVINCI_PLL1_BASE, SZ_4K);
+ pll2 = ioremap(DAVINCI_PLL2_BASE, SZ_4K);
+ psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
+
+ clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DM644X_REF_FREQ);
+ dm644x_pll_clk_init(pll1, pll2);
+ dm644x_psc_clk_init(psc);
+#else
davinci_clk_init(dm644x_clks);
+#endif
davinci_timer_init();
}
--
2.7.4
[PATCH v5 07/44] clk: davinci: Add platform information for TI DM644x PLL
This adds platform-specific declarations for the PLL clocks on TI
DaVinci 644x based systems.
Signed-off-by: David Lechner
---
drivers/clk/davinci/Makefile | 1 +
drivers/clk/davinci/pll-dm644x.c | 41
include/linux/clk/davinci.h | 1 +
3 files changed, 43 insertions(+)
create mode 100644 drivers/clk/davinci/pll-dm644x.c
diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
index 353aa02..59d8ab6 100644
--- a/drivers/clk/davinci/Makefile
+++ b/drivers/clk/davinci/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_ARCH_DAVINCI_DA830)+= pll-da830.o
obj-$(CONFIG_ARCH_DAVINCI_DA850) += pll-da850.o
obj-$(CONFIG_ARCH_DAVINCI_DM355) += pll-dm355.o
obj-$(CONFIG_ARCH_DAVINCI_DM365) += pll-dm365.o
+obj-$(CONFIG_ARCH_DAVINCI_DM644x) += pll-dm644x.o
endif
diff --git a/drivers/clk/davinci/pll-dm644x.c b/drivers/clk/davinci/pll-dm644x.c
new file mode 100644
index 000..b0d0373
--- /dev/null
+++ b/drivers/clk/davinci/pll-dm644x.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PLL clock descriptions for TI DM644X
+ *
+ * Copyright (C) 2017 David Lechner
+ */
+
+#include
+#include
+
+#include "pll.h"
+
+static const struct davinci_pll_divclk_info dm644x_pll1_divclk_info[]
__initconst = {
+ DIVCLK(1, pll1_sysclk1, pll1, DIVCLK_FIXED_DIV),
+ DIVCLK(2, pll1_sysclk2, pll1, DIVCLK_FIXED_DIV),
+ DIVCLK(3, pll1_sysclk3, pll1, DIVCLK_FIXED_DIV),
+ DIVCLK(5, pll1_sysclk5, pll1, DIVCLK_FIXED_DIV),
+ { }
+};
+
+static const struct davinci_pll_divclk_info dm644x_pll2_divclk_info[]
__initconst = {
+ DIVCLK(1, pll2_sysclk1, pll2, 0),
+ DIVCLK(2, pll2_sysclk2, pll2, 0),
+ { }
+};
+
+void __init dm644x_pll_clk_init(void __iomem *pll1, void __iomem *pll2)
+{
+ const struct davinci_pll_divclk_info *info;
+
+ davinci_pll_clk_register("pll1", "ref_clk", pll1);
+ for (info = dm644x_pll1_divclk_info; info->name; info++)
+ davinci_pll_divclk_register(info, pll1);
+ davinci_pll_aux_clk_register("pll1_aux_clk", "ref_clk", pll1);
+ davinci_pll_bpdiv_clk_register("pll1_sysclkbp", "ref_clk", pll1);
+
+ davinci_pll_clk_register("pll2", "ref_clk", pll2);
+ for (info = dm644x_pll2_divclk_info; info->name; info++)
+ davinci_pll_divclk_register(info, pll2);
+ davinci_pll_bpdiv_clk_register("pll2_sysclkbp", "ref_clk", pll2);
+}
diff --git a/include/linux/clk/davinci.h b/include/linux/clk/davinci.h
index 5bf60a7..535990a 100644
--- a/include/linux/clk/davinci.h
+++ b/include/linux/clk/davinci.h
@@ -13,5 +13,6 @@ void da830_pll_clk_init(void __iomem *pll);
void da850_pll_clk_init(void __iomem *pll0, void __iomem *pll1);
void dm355_pll_clk_init(void __iomem *pll1, void __iomem *pll2);
void dm365_pll_clk_init(void __iomem *pll1, void __iomem *pll2);
+void dm644x_pll_clk_init(void __iomem *pll1, void __iomem *pll2);
#endif /* __LINUX_CLK_DAVINCI_H__ */
--
2.7.4
[PATCH v5 15/44] clk: davinci: Add platform information for TI DM644x PSC
This adds platform-specific declarations for the PSC clocks on TI
DaVinci 644x based systems.
Signed-off-by: David Lechner
---
drivers/clk/davinci/Makefile | 1 +
drivers/clk/davinci/psc-dm644x.c | 73
include/linux/clk/davinci.h | 1 +
3 files changed, 75 insertions(+)
create mode 100644 drivers/clk/davinci/psc-dm644x.c
diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
index 78dc1eb..a20e379 100644
--- a/drivers/clk/davinci/Makefile
+++ b/drivers/clk/davinci/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_ARCH_DAVINCI_DA830) += psc-da830.o
obj-$(CONFIG_ARCH_DAVINCI_DA850) += psc-da850.o
obj-$(CONFIG_ARCH_DAVINCI_DM355) += psc-dm355.o
obj-$(CONFIG_ARCH_DAVINCI_DM365) += psc-dm365.o
+obj-$(CONFIG_ARCH_DAVINCI_DM644x) += psc-dm644x.o
endif
diff --git a/drivers/clk/davinci/psc-dm644x.c b/drivers/clk/davinci/psc-dm644x.c
new file mode 100644
index 000..ef5ef14
--- /dev/null
+++ b/drivers/clk/davinci/psc-dm644x.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PSC clock descriptions for TI DaVinci DM644x
+ *
+ * Copyright (C) 2017 David Lechner
+ */
+
+#include
+#include
+#include
+#include
+
+#include "psc.h"
+
+static const struct davinci_psc_clk_info dm644x_psc_info[] __initconst = {
+ LPSC(0, 0, vpss_master, pll1_sysclk3, 0),
+ LPSC(1, 0, vpss_slave, pll1_sysclk3, 0),
+ LPSC(6, 0, emac, pll1_sysclk5, 0),
+ LPSC(9, 0, usb, pll1_sysclk5, 0),
+ LPSC(10, 0, ide, pll1_sysclk5, 0),
+ LPSC(11, 0, vlynq, pll1_sysclk5, 0),
+ LPSC(14, 0, aemif, pll1_sysclk5, 0),
+ LPSC(15, 0, mmcsd, pll1_sysclk5, 0),
+ LPSC(17, 0, asp0, pll1_sysclk5, 0),
+ LPSC(18, 0, i2c, pll1_aux_clk, 0),
+ LPSC(19, 0, uart0, pll1_aux_clk, 0),
+ LPSC(20, 0, uart1, pll1_aux_clk, 0),
+ LPSC(21, 0, uart2, pll1_aux_clk, 0),
+ LPSC(22, 0, spi, pll1_sysclk5, 0),
+ LPSC(23, 0, pwm0, pll1_aux_clk, 0),
+ LPSC(24, 0, pwm1, pll1_aux_clk, 0),
+ LPSC(25, 0, pwm2, pll1_aux_clk, 0),
+ LPSC(26, 0, gpio, pll1_sysclk5, 0),
+ LPSC(27, 0, timer0, pll1_aux_clk, 0),
+ LPSC(28, 0, timer1, pll1_aux_clk, 0),
+ /* REVISIT: why can't this be disabled? */
+ LPSC(29, 0, timer2, pll1_aux_clk, LPSC_ALWAYS_ENABLED),
+ LPSC(31, 0, arm, pll1_sysclk2, LPSC_ALWAYS_ENABLED),
+ /* REVISIT how to disable? */
+ LPSC(39, 1, dsp, pll1_sysclk1, LPSC_ALWAYS_ENABLED),
+ /* REVISIT how to disable? */
+ LPSC(40, 1, vicp, pll1_sysclk2, LPSC_ALWAYS_ENABLED),
+ { }
+};
+
+void __init dm644x_psc_clk_init(void __iomem *psc)
+{
+ struct clk_onecell_data *clk_data;
+
+ clk_data = davinci_psc_register_clocks(psc, dm644x_psc_info, 41);
+ if (!clk_data)
+ return;
+
+ clk_register_clkdev(clk_data->clks[0], "master", "vpss");
+ clk_register_clkdev(clk_data->clks[1], "slave", "vpss");
+ clk_register_clkdev(clk_data->clks[6], NULL, "davinci_emac.1");
+ clk_register_clkdev(clk_data->clks[6], "fck", "davinci_mdio.0");
+ clk_register_clkdev(clk_data->clks[9], "usb", NULL);
+ clk_register_clkdev(clk_data->clks[10], NULL, "palm_bk3710");
+ clk_register_clkdev(clk_data->clks[14], "aemif", NULL);
+ clk_register_clkdev(clk_data->clks[15], NULL, "dm6441-mmc.0");
+ clk_register_clkdev(clk_data->clks[17], NULL, "davinci-mcbsp");
+ clk_register_clkdev(clk_data->clks[18], NULL, "i2c_davinci.1");
+ clk_register_clkdev(clk_data->clks[19], NULL, "serial8250.0");
+ clk_register_clkdev(clk_data->clks[20], NULL, "serial8250.1");
+ clk_register_clkdev(clk_data->clks[21], NULL, "serial8250.2");
+ clk_register_clkdev(clk_data->clks[26], "gpio", NULL);
+ clk_register_clkdev(clk_data->clks[27], "timer0", NULL);
+ clk_register_clkdev(clk_data->clks[29], NULL, "davinci-wdt");
+ clk_register_clkdev(clk_data->clks[31], "arm", NULL);
+
+ clk_free_onecell_data(clk_data);
+}
diff --git a/include/linux/clk/davinci.h b/include/linux/clk/davinci.h
index c7d8c5f..6d2896d 100644
--- a/include/linux/clk/davinci.h
+++ b/include/linux/clk/davinci.h
@@ -20,5 +20,6 @@ void da830_psc_clk_init(void __iomem *psc0, void __iomem
*psc1);
void da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1);
void dm355_psc_clk_init(void __iomem *psc);
void dm365_psc_clk_init(void __iomem *psc);
+void dm644x_psc_clk_init(void __iomem *psc);
#endif /* __LINUX_CLK_DAVINCI_H__ */
--
2.7.4
[PATCH v5 28/44] ARM: dm646x: add new clock init using common clock framework
This adds the new board-specfic clock init in mach-davinci/dm646x.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Also clean up the #includes since we are adding some here.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/dm646x.c | 41 +
1 file changed, 33 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index d4d7658..bdaf769 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -8,29 +8,35 @@
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
+#include
+#include
+#include
+#include
#include
#include
#include
-#include
-#include
-#include
#include
#include
+#include
+#include
#include
+#include
#include
#include
-#include "psc.h"
#include
-#include
#include
-#include
+#include
+#include "asp.h"
#include "davinci.h"
-#include "clock.h"
#include "mux.h"
-#include "asp.h"
+
+#ifndef CONFIG_COMMON_CLK
+#include "clock.h"
+#include "psc.h"
+#endif
#define DAVINCI_VPIF_BASE (0x01C12000)
@@ -46,6 +52,7 @@
#define DM646X_EMAC_CNTRL_RAM_OFFSET 0x2000
#define DM646X_EMAC_CNTRL_RAM_SIZE 0x2000
+#ifndef CONFIG_COMMON_CLK
static struct pll_data pll1_data = {
.num = 1,
.phys_base = DAVINCI_PLL1_BASE,
@@ -356,6 +363,7 @@ static struct clk_lookup dm646x_clks[] = {
CLK(NULL, "vpif1", &vpif1_clk),
CLK(NULL, NULL, NULL),
};
+#endif
static struct emac_platform_data dm646x_emac_pdata = {
.ctrl_reg_offset= DM646X_EMAC_CNTRL_OFFSET,
@@ -953,9 +961,26 @@ void __init dm646x_init(void)
void __init dm646x_init_time(unsigned long ref_clk_rate,
unsigned long aux_clkin_rate)
{
+#ifdef CONFIG_COMMON_CLK
+ void __iomem *pll1, *pll2, *psc;
+ struct clk *clk;
+
+ pll1 = ioremap(DAVINCI_PLL1_BASE, SZ_4K);
+ pll2 = ioremap(DAVINCI_PLL2_BASE, SZ_4K);
+ psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
+
+ clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, ref_clk_rate);
+ clk_register_fixed_rate(NULL, "aux_clkin", NULL, 0, aux_clkin_rate);
+ dm646x_pll_clk_init(pll1, pll2);
+ dm646x_psc_clk_init(psc);
+ /* no LPSC, always enabled; c.f. spruep9a */
+ clk = clk_register_fixed_factor(NULL, "timer2", "pll1_sysclk3", 0, 1,
1);
+ clk_register_clkdev(clk, NULL, "davinci-wdt");
+#else
ref_clk.rate = ref_clk_rate;
aux_clkin.rate = aux_clkin_rate;
davinci_clk_init(dm646x_clks);
+#endif
davinci_timer_init();
}
--
2.7.4
Re: [PATCH] mtd: mtk-nor: modify functions' name more generally
Hi Cyrille,
Gentle ping...
BR,
Guochun
On Mon, 2017-12-18 at 09:47 +0800, Guochun Mao wrote:
> Since more and more Mediatek's SoC can use this driver to
> control spi-nor flash, functions' name with "mt8173_" is
> no longer properly. Replacing "mt8173_" with "mtk_" will
> be more accurate to describe these functions' usable scope.
>
> Signed-off-by: Guochun Mao
> ---
> drivers/mtd/spi-nor/mtk-quadspi.c | 240
> ++---
> 1 file changed, 120 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
> b/drivers/mtd/spi-nor/mtk-quadspi.c
> index abe455c..5442993 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -110,7 +110,7 @@
> #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
> #define MTK_NOR_SHREG(n) (MTK_NOR_SHREG0_REG + 4 * (n))
>
> -struct mt8173_nor {
> +struct mtk_nor {
> struct spi_nor nor;
> struct device *dev;
> void __iomem *base; /* nor flash base address */
> @@ -118,48 +118,48 @@ struct mt8173_nor {
> struct clk *nor_clk;
> };
>
> -static void mt8173_nor_set_read_mode(struct mt8173_nor *mt8173_nor)
> +static void mtk_nor_set_read_mode(struct mtk_nor *mtk_nor)
> {
> - struct spi_nor *nor = &mt8173_nor->nor;
> + struct spi_nor *nor = &mtk_nor->nor;
>
> switch (nor->read_proto) {
> case SNOR_PROTO_1_1_1:
> - writeb(nor->read_opcode, mt8173_nor->base +
> + writeb(nor->read_opcode, mtk_nor->base +
> MTK_NOR_PRGDATA3_REG);
> - writeb(MTK_NOR_FAST_READ, mt8173_nor->base +
> + writeb(MTK_NOR_FAST_READ, mtk_nor->base +
> MTK_NOR_CFG1_REG);
> break;
> case SNOR_PROTO_1_1_2:
> - writeb(nor->read_opcode, mt8173_nor->base +
> + writeb(nor->read_opcode, mtk_nor->base +
> MTK_NOR_PRGDATA3_REG);
> - writeb(MTK_NOR_DUAL_READ_EN, mt8173_nor->base +
> + writeb(MTK_NOR_DUAL_READ_EN, mtk_nor->base +
> MTK_NOR_DUAL_REG);
> break;
> case SNOR_PROTO_1_1_4:
> - writeb(nor->read_opcode, mt8173_nor->base +
> + writeb(nor->read_opcode, mtk_nor->base +
> MTK_NOR_PRGDATA4_REG);
> - writeb(MTK_NOR_QUAD_READ_EN, mt8173_nor->base +
> + writeb(MTK_NOR_QUAD_READ_EN, mtk_nor->base +
> MTK_NOR_DUAL_REG);
> break;
> default:
> - writeb(MTK_NOR_DUAL_DISABLE, mt8173_nor->base +
> + writeb(MTK_NOR_DUAL_DISABLE, mtk_nor->base +
> MTK_NOR_DUAL_REG);
> break;
> }
> }
>
> -static int mt8173_nor_execute_cmd(struct mt8173_nor *mt8173_nor, u8 cmdval)
> +static int mtk_nor_execute_cmd(struct mtk_nor *mtk_nor, u8 cmdval)
> {
> int reg;
> u8 val = cmdval & 0x1f;
>
> - writeb(cmdval, mt8173_nor->base + MTK_NOR_CMD_REG);
> - return readl_poll_timeout(mt8173_nor->base + MTK_NOR_CMD_REG, reg,
> + writeb(cmdval, mtk_nor->base + MTK_NOR_CMD_REG);
> + return readl_poll_timeout(mtk_nor->base + MTK_NOR_CMD_REG, reg,
> !(reg & val), 100, 1);
> }
>
> -static int mt8173_nor_do_tx_rx(struct mt8173_nor *mt8173_nor, u8 op,
> -u8 *tx, int txlen, u8 *rx, int rxlen)
> +static int mtk_nor_do_tx_rx(struct mtk_nor *mtk_nor, u8 op,
> + u8 *tx, int txlen, u8 *rx, int rxlen)
> {
> int len = 1 + txlen + rxlen;
> int i, ret, idx;
> @@ -167,26 +167,26 @@ static int mt8173_nor_do_tx_rx(struct mt8173_nor
> *mt8173_nor, u8 op,
> if (len > MTK_NOR_MAX_SHIFT)
> return -EINVAL;
>
> - writeb(len * 8, mt8173_nor->base + MTK_NOR_CNT_REG);
> + writeb(len * 8, mtk_nor->base + MTK_NOR_CNT_REG);
>
> /* start at PRGDATA5, go down to PRGDATA0 */
> idx = MTK_NOR_MAX_RX_TX_SHIFT - 1;
>
> /* opcode */
> - writeb(op, mt8173_nor->base + MTK_NOR_PRG_REG(idx));
> + writeb(op, mtk_nor->base + MTK_NOR_PRG_REG(idx));
> idx--;
>
> /* program TX data */
> for (i = 0; i < txlen; i++, idx--)
> - writeb(tx[i], mt8173_nor->base + MTK_NOR_PRG_REG(idx));
> + writeb(tx[i], mtk_nor->base + MTK_NOR_PRG_REG(idx));
>
> /* clear out rest of TX registers */
> while (idx >= 0) {
> - writeb(0, mt8173_nor->base + MTK_NOR_PRG_REG(idx));
> + writeb(0, mtk_nor->base + MTK_NOR_PRG_REG(idx));
> idx--;
> }
>
> - ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PRG_CMD);
> + ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PRG_CMD);
> if (ret)
> return ret;
>
> @@ -195,20 +195,20 @@ static int mt8173_nor_do_tx_rx(struct mt8173_nor
> *mt8173_nor, u8 op,
>
> /* read out RX data */
> for (i = 0; i < r
[PATCH v5 24/44] ARM: da850: add new clock init using common clock framework
This adds the new board-specfic clock init in mach-davinci/da850.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Some CFGCHIP* #defines are removed since they are included in the
linux/mfd/da8xx-cfgchip.h header file.
Also clean up the #includes since we are adding some here.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/da850.c | 74 +++
1 file changed, 61 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 34117e61..4804096 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -11,39 +11,44 @@
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
+
+#include
+#include
+#include
#include
+#include
#include
#include
-#include
+#include
+#include
+#include
#include
-#include
#include
-#include
#include
-#include "psc.h"
-#include
-#include
#include
-#include
-#include
#include
+#include
+#include
+#include
#include
+#include
-#include "clock.h"
#include "mux.h"
+#ifndef CONFIG_COMMON_CLK
+#include "clock.h"
+#include "psc.h"
+#endif
+
#define DA850_PLL1_BASE0x01e1a000
#define DA850_TIMER64P2_BASE 0x01f0c000
#define DA850_TIMER64P3_BASE 0x01f0d000
#define DA850_REF_FREQ 2400
-#define CFGCHIP3_ASYNC3_CLKSRC BIT(4)
-#define CFGCHIP3_PLL1_MASTER_LOCK BIT(5)
-#define CFGCHIP0_PLL_MASTER_LOCK BIT(4)
-
+#ifndef CONFIG_COMMON_CLK
static int da850_set_armrate(struct clk *clk, unsigned long rate);
static int da850_round_armrate(struct clk *clk, unsigned long rate);
static int da850_set_pll0rate(struct clk *clk, unsigned long armrate);
@@ -583,6 +588,7 @@ static struct clk_lookup da850_clks[] = {
CLK("ecap.2", "fck", &ecap2_clk),
CLK(NULL, NULL, NULL),
};
+#endif
/*
* Device specific mux setup
@@ -1170,6 +1176,7 @@ int da850_register_cpufreq(char *async_clk)
return platform_device_register(&da850_cpufreq_device);
}
+#ifndef CONFIG_COMMON_CLK
static int da850_round_armrate(struct clk *clk, unsigned long rate)
{
int ret = 0, diff;
@@ -1232,12 +1239,14 @@ static int da850_set_pll0rate(struct clk *clk, unsigned
long rate)
return 0;
}
+#endif /* CONFIG_COMMON_CLK */
#else
int __init da850_register_cpufreq(char *async_clk)
{
return 0;
}
+#ifndef CONFIG_COMMON_CLK
static int da850_set_armrate(struct clk *clk, unsigned long rate)
{
return -EINVAL;
@@ -1252,6 +1261,7 @@ static int da850_round_armrate(struct clk *clk, unsigned
long rate)
{
return clk->rate;
}
+#endif /* CONFIG_COMMON_CLK */
#endif
/* VPIF resource, platform data */
@@ -1395,6 +1405,44 @@ void __init da850_init(void)
void __init da850_init_time(void)
{
+#ifdef CONFIG_COMMON_CLK
+ void __iomem *pll0, *pll1, *psc0, *psc1;
+ struct clk *clk;
+ struct clk_hw *parent;
+
+ pll0 = ioremap(DA8XX_PLL0_BASE, SZ_4K);
+ pll1 = ioremap(DA850_PLL1_BASE, SZ_4K);
+ psc0 = ioremap(DA8XX_PSC0_BASE, SZ_4K);
+ psc1 = ioremap(DA8XX_PSC1_BASE, SZ_4K);
+
+ clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA850_REF_FREQ);
+ da850_pll_clk_init(pll0, pll1);
+ clk = clk_register_mux(NULL, "async3",
+ (const char * const[]){ "pll0_sysclk2", "pll1_sysclk2" },
+ 2, 0, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG),
+ ilog2(CFGCHIP3_ASYNC3_CLKSRC), 1, 0, NULL);
+ /* pll1_sysclk2 is not affected by CPU scaling, so use it for async3 */
+ parent = clk_hw_get_parent_by_index(__clk_get_hw(clk), 1);
+ if (parent)
+ clk_set_parent(clk, parent->clk);
+ else
+ pr_warn("%s: Failed to find async3 parent clock\n", __func__);
+ da850_psc_clk_init(psc0, psc1);
+ clk = clk_register_fixed_factor(NULL, "i2c0", "pll0_aux_clk", 0, 1, 1);
+ clk_register_clkdev(clk, NULL, "i2c_davinci.1");
+ clk = clk_register_fixed_factor(NULL, "timer0", "pll0_aux_clk", 0, 1,
1);
+ clk_register_clkdev(clk, "timer0", NULL);
+ clk = clk_register_fixed_factor(NULL, "timer1", "pll0_aux_clk", 0, 1,
1);
+ clk_register_clkdev(clk, NULL, "davinci-wdt");
+ clk = clk_register_fixed_factor(NULL, "rmii", "pll0_sysclk7", 0, 1, 1);
+ clk_register_clkdev(clk, "rmii", NULL);
+ clk = clk_register_gate(NULL, "ehrpwm_tbclk", "ehrpwm", 0,
+ DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP1_REG),
+ ilog2(CFGCHIP1_TBCLKSYNC), 0, NULL);
+ clk_register_clkdev(clk, "tbclk", "ehrpwm.0");
+ clk_register_clkdev(clk, "tbclk", "ehrpwm.1");
+#else
davinci_clk_init(da850_clks);
+#endif
davinci_timer_init();
}
--
2.7.4
[PATCH v5 26/44] ARM: dm365: add new clock init using common clock framework
This adds the new board-specfic clock init in mach-davinci/dm365.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Also clean up the #includes since we are adding some here.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/dm365.c | 41 ++---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1e3df9d..fbbe31c 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -12,32 +12,38 @@
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
-#include
+#include
#include
-#include
-#include
+#include
+#include
#include
#include
-#include
+#include
#include
#include
#include
#include
+#include
+#include
+#include
#include
+#include
#include
-#include "psc.h"
-#include
#include
-#include
+#include
#include
-#include
+#include
+#include "asp.h"
#include "davinci.h"
-#include "clock.h"
#include "mux.h"
-#include "asp.h"
+
+#ifndef CONFIG_COMMON_CLK
+#include "clock.h"
+#include "psc.h"
+#endif
#define DM365_REF_FREQ 2400/* 24 MHz on the DM365 EVM */
#define DM365_RTC_BASE 0x01c69000
@@ -54,6 +60,7 @@
#define DM365_EMAC_CNTRL_RAM_OFFSET0x1000
#define DM365_EMAC_CNTRL_RAM_SIZE 0x2000
+#ifndef CONFIG_COMMON_CLK
static struct pll_data pll1_data = {
.num= 1,
.phys_base = DAVINCI_PLL1_BASE,
@@ -485,7 +492,7 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, "mjcp", &mjcp_clk),
CLK(NULL, NULL, NULL),
};
-
+#endif
/*--*/
#define INTMUX 0x18
@@ -1171,7 +1178,19 @@ void __init dm365_init(void)
void __init dm365_init_time(void)
{
+#ifdef CONFIG_COMMON_CLK
+ void __iomem *pll1, *pll2, *psc;
+
+ pll1 = ioremap(DAVINCI_PLL1_BASE, SZ_4K);
+ pll2 = ioremap(DAVINCI_PLL2_BASE, SZ_4K);
+ psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
+
+ clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DM365_REF_FREQ);
+ dm365_pll_clk_init(pll1, pll2);
+ dm365_psc_clk_init(psc);
+#else
davinci_clk_init(dm365_clks);
+#endif
davinci_timer_init();
}
--
2.7.4
[PATCH v5 25/44] ARM: dm355: add new clock init using common clock framework
This adds the new board-specfic clock init in mach-davinci/dm355.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Also clean up the #includes since we are adding some here.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/dm355.c | 47 +--
1 file changed, 36 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index f294804..f087840 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -8,31 +8,37 @@
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
-#include
+#include
#include
-#include
-#include
+#include
+#include
#include
#include
-#include
+#include
#include
#include
#include
+#include
+#include
+#include
#include
+#include
#include
-#include "psc.h"
-#include
#include
-#include
+#include
#include
-#include
+#include
+#include "asp.h"
#include "davinci.h"
-#include "clock.h"
#include "mux.h"
-#include "asp.h"
+
+#ifndef CONFIG_COMMON_CLK
+#include "clock.h"
+#include "psc.h"
+#endif
#define DM355_UART2_BASE (IO_PHYS + 0x206000)
#define DM355_OSD_BASE (IO_PHYS + 0x70200)
@@ -43,6 +49,7 @@
*/
#define DM355_REF_FREQ 2400/* 24 or 36 MHz */
+#ifndef CONFIG_COMMON_CLK
static struct pll_data pll1_data = {
.num = 1,
.phys_base = DAVINCI_PLL1_BASE,
@@ -382,7 +389,7 @@ static struct clk_lookup dm355_clks[] = {
CLK(NULL, "usb", &usb_clk),
CLK(NULL, NULL, NULL),
};
-
+#endif
/*--*/
static u64 dm355_spi0_dma_mask = DMA_BIT_MASK(32);
@@ -1046,7 +1053,25 @@ void __init dm355_init(void)
void __init dm355_init_time(void)
{
+#ifdef CONFIG_COMMON_CLK
+ void __iomem *pll1, *pll2, *psc;
+
+ pll1 = ioremap(DAVINCI_PLL1_BASE, SZ_4K);
+ pll2 = ioremap(DAVINCI_PLL2_BASE, SZ_4K);
+ psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
+
+ clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DM355_REF_FREQ);
+ dm355_pll_clk_init(pll1, pll2);
+ dm355_psc_clk_init(psc);
+
+ /* NOTE: clkout1 can be externally gated by muxing GPIO-18 */
+ clk_register_fixed_factor(NULL, "clkout1", "pll1_aux_clk", 0, 1, 1);
+ clk_register_fixed_factor(NULL, "clkout2", "pll1_sysclkbp", 0, 1, 1);
+ /* NOTE: clkout3 can be externally gated by muxing GPIO-16 */
+ clk_register_fixed_factor(NULL, "clkout3", "pll2_sysclkbp", 0, 1, 1);
+#else
davinci_clk_init(dm355_clks);
+#endif
davinci_timer_init();
}
--
2.7.4
[PATCH v5 18/44] dt-bindings: clock: Add binding for TI DA8XX CFGCHIP mux clocks
This adds a new binding for multiplexer clocks that are part of the
CFGCHIPn registers on TI DA8XX-like SoCs. Currently, there are only
bindings given for the ASYNC3 clock domain, but there are additional
clock multiplexers in this syscon that could be added in the future
if needed.
Signed-off-by: David Lechner
---
.../clock/ti/davinci/da8xx-cfgchip-mux.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-mux.txt
diff --git
a/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-mux.txt
b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-mux.txt
new file mode 100644
index 000..8c874ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-mux.txt
@@ -0,0 +1,42 @@
+Binding for TI DA8XX/OMAP-L13X/AM17XX/AM18XX CFGCHIP multiplexer clocks
+
+TI DA8XX/OMAP-L13X/AM17XX/AM18XX SoCs contain a general purpose set of
+registers call CFGCHIPn. Some of these registers function as clock
+multiplexers. This document describes the bindings for those clocks.
+
+Required properties:
+- compatible: shall be "ti,da850-async3-clock".
+- #clock-cells: from common clock binding; shall be set to 0.
+- clocks: phandle list of clocks corresponding to clock-names
+- clock-names: must include the following: "pll0_sysclk2", "pll1_sysclk2".
+
+Optional properties:
+- clock-output-names: from common clock binding.
+
+Parent:
+This node must be a child of a "ti,da830-cfgchip" node.
+
+Assignment:
+The assigned-clocks and assigned-clock-parents from the common clock bindings
+can be used to indicate which parent clock should be used.
+
+Examples:
+
+cfgchip: syscon@1417c {
+compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
+reg = <0x1417c 0x14>;
+
+async3_clk: async3 {
+compatible = "ti,da850-async3-clock";
+#clock-cells = <0>;
+clocks = <&pll0_sysclk 2>, <&pll1_sysclk 2>;
+clock-names = "pll0_sysclk2", "pll1_sysclk2";
+assigned-clocks = <&async3_clk>;
+assigned-clock-parents = <&pll1_sysclk 2>;
+clock-output-names = "async3";
+};
+};
+
+Also see:
+- Documentation/devicetree/bindings/clock/clock-bindings.txt
+
--
2.7.4
[PATCH v5 23/44] ARM: da830: add new clock init using common clock framework
This adds the new board-specfic clock init in mach-davinci/da830.c using
the new common clock framework drivers.
The #ifdefs are needed to prevent compile errors until the entire
ARCH_DAVINCI is converted.
Also clean up the #includes since we are adding some here.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/da830.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 350d767..cbb351d 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -8,23 +8,29 @@
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
+#include
+#include
+#include
+#include
#include
#include
-#include
#include
#include
-#include "psc.h"
-#include
-#include
#include
-#include
+#include
#include
+#include
+#include
-#include "clock.h"
#include "mux.h"
+#ifndef CONFIG_COMMON_CLK
+#include "clock.h"
+#include "psc.h"
+#endif
+
/* Offsets of the 8 compare registers on the da830 */
#define DA830_CMP12_0 0x60
#define DA830_CMP12_1 0x64
@@ -37,6 +43,7 @@
#define DA830_REF_FREQ 2400
+#ifndef CONFIG_COMMON_CLK
static struct pll_data pll0_data = {
.num= 1,
.phys_base = DA8XX_PLL0_BASE,
@@ -432,6 +439,7 @@ static struct clk_lookup da830_clks[] = {
CLK(NULL, "rmii", &rmii_clk),
CLK(NULL, NULL, NULL),
};
+#endif
/*
* Device specific mux setup
@@ -1223,6 +1231,27 @@ void __init da830_init(void)
void __init da830_init_time(void)
{
+#ifdef CONFIG_COMMON_CLK
+ void __iomem *pll0, *psc0, *psc1;
+ struct clk *clk;
+
+ pll0 = ioremap(DA8XX_PLL0_BASE, SZ_4K);
+ psc0 = ioremap(DA8XX_PSC0_BASE, SZ_4K);
+ psc1 = ioremap(DA8XX_PSC1_BASE, SZ_4K);
+
+ clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA830_REF_FREQ);
+ da830_pll_clk_init(pll0);
+ da830_psc_clk_init(psc0, psc1);
+ clk = clk_register_fixed_factor(NULL, "i2c0", "pll0_aux_clk", 0, 1, 1);
+ clk_register_clkdev(clk, NULL, "i2c_davinci.1");
+ clk = clk_register_fixed_factor(NULL, "timer0", "pll0_aux_clk", 0, 1,
1);
+ clk_register_clkdev(clk, "timer0", NULL);
+ clk = clk_register_fixed_factor(NULL, "timer1", "pll0_aux_clk", 0, 1,
1);
+ clk_register_clkdev(clk, NULL, "davinci-wdt");
+ clk = clk_register_fixed_factor(NULL, "rmii", "pll0_sysclk7", 0, 1, 1);
+ clk_register_clkdev(clk, "rmii", NULL);
+#else
davinci_clk_init(da830_clks);
+#endif
davinci_timer_init();
}
--
2.7.4
[PATCH v5 22/44] ARM: davinci: move davinci_clk_init() to init_time
This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. dm646x is a special case because we need to handle different ref_clk rates depending on which board is being used. The clock init in this case is modified to set the rate before registering the clocks instead of using davinci_set_refclk_rate() to recalculate the entire clock tree after all of the clocks are registered. Also, the cpu_clks field is removed from struct davinci_soc_info since it is no longer needed. Signed-off-by: David Lechner --- arch/arm/mach-davinci/board-da830-evm.c | 2 +- arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c| 2 +- arch/arm/mach-davinci/board-dm646x-evm.c| 19 +-- arch/arm/mach-davinci/board-mityomapl138.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c| 2 +- arch/arm/mach-davinci/da830.c | 7 +-- arch/arm/mach-davinci/da850.c | 7 +-- arch/arm/mach-davinci/da8xx-dt.c| 2 +- arch/arm/mach-davinci/davinci.h | 4 arch/arm/mach-davinci/dm355.c | 8 ++-- arch/arm/mach-davinci/dm365.c | 8 ++-- arch/arm/mach-davinci/dm644x.c | 8 ++-- arch/arm/mach-davinci/dm646x.c | 22 +++--- arch/arm/mach-davinci/include/mach/common.h | 1 - arch/arm/mach-davinci/include/mach/da8xx.h | 3 +++ 21 files changed, 70 insertions(+), 39 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index a58bfca..7adf009 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -638,7 +638,7 @@ MACHINE_START(DAVINCI_DA830_EVM, "DaVinci DA830/OMAP-L137/AM17x EVM") .atag_offset= 0x100, .map_io = da830_evm_map_io, .init_irq = cp_intc_init, - .init_time = davinci_timer_init, + .init_time = da830_init_time, .init_machine = da830_evm_init, .init_late = davinci_init_late, .dma_zone_size = SZ_128M, diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6039ec1..8602d0d 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -1481,7 +1481,7 @@ MACHINE_START(DAVINCI_DA850_EVM, "DaVinci DA850/OMAP-L138/AM18x EVM") .atag_offset= 0x100, .map_io = da850_evm_map_io, .init_irq = cp_intc_init, - .init_time = davinci_timer_init, + .init_time = da850_init_time, .init_machine = da850_evm_init, .init_late = davinci_init_late, .dma_zone_size = SZ_128M, diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index d60d998..3c15cb7 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -416,7 +416,7 @@ MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM") .atag_offset = 0x100, .map_io = dm355_evm_map_io, .init_irq = davinci_irq_init, - .init_time = davinci_timer_init, + .init_time = dm355_init_time, .init_machine = dm355_evm_init, .init_late = davinci_init_late, .dma_zone_size = SZ_128M, diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index 1e7e9b8..3ebc89d 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -271,7 +271,7 @@ MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard") .atag_offset = 0x100, .map_io = dm355_leopard_map_io, .init_irq = davinci_irq_init, - .init_time = davinci_timer_init, + .init_time = dm355_init_time, .init_machine = dm355_leopard_init, .init_late = davinci_init_late, .dma_zone_size = SZ_128M, diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 17b2c29..3daeac7 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -774,7 +774,7 @@ MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM") .atag_offset= 0x100, .map_io = dm365_evm_map_io, .init_irq = davinci_irq_init, - .init_time = davinci_timer_init, + .init_time = dm365_init_time, .init_machine = dm365_evm_init, .init_late = davinci_in
[PATCH v5 19/44] clk: davinci: New driver for TI DA8XX CFGCHIP clocks
This adds a new driver for the gate and multiplexer clocks in the
CFGCHIPn syscon registers on TI DA8XX-type SoCs.
Signed-off-by: David Lechner
---
drivers/clk/davinci/Makefile| 2 +
drivers/clk/davinci/da8xx-cfgchip.c | 203
2 files changed, 205 insertions(+)
create mode 100644 drivers/clk/davinci/da8xx-cfgchip.c
diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
index 6c388d4..11178b7 100644
--- a/drivers/clk/davinci/Makefile
+++ b/drivers/clk/davinci/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
ifeq ($(CONFIG_COMMON_CLK), y)
+obj-$(CONFIG_ARCH_DAVINCI_DA8XX) += da8xx-cfgchip.o
+
obj-y += pll.o
obj-$(CONFIG_ARCH_DAVINCI_DA830) += pll-da830.o
obj-$(CONFIG_ARCH_DAVINCI_DA850) += pll-da850.o
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c
b/drivers/clk/davinci/da8xx-cfgchip.c
new file mode 100644
index 000..772e09a
--- /dev/null
+++ b/drivers/clk/davinci/da8xx-cfgchip.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Clock driver for DA8xx/AM17xx/AM18xx/OMAP-L13x CFGCHIP
+ *
+ * Copyright (C) 2017 David Lechner
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+struct da8xx_cfgchip_gate_clk {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u32 reg;
+ u32 mask;
+};
+
+#define to_da8xx_cfgchip_gate_clk(_hw) \
+ container_of((_hw), struct da8xx_cfgchip_gate_clk, hw)
+
+static int da8xx_cfgchip_gate_clk_enable(struct clk_hw *hw)
+{
+ struct da8xx_cfgchip_gate_clk *clk = to_da8xx_cfgchip_gate_clk(hw);
+
+ return regmap_write_bits(clk->regmap, clk->reg, clk->mask, clk->mask);
+}
+
+static void da8xx_cfgchip_gate_clk_disable(struct clk_hw *hw)
+{
+ struct da8xx_cfgchip_gate_clk *clk = to_da8xx_cfgchip_gate_clk(hw);
+
+ regmap_write_bits(clk->regmap, clk->reg, clk->mask, 0);
+}
+
+static int da8xx_cfgchip_gate_clk_is_enabled(struct clk_hw *hw)
+{
+ struct da8xx_cfgchip_gate_clk *clk = to_da8xx_cfgchip_gate_clk(hw);
+ unsigned int val;
+
+ regmap_read(clk->regmap, clk->reg, &val);
+
+ return !!(val & clk->mask);
+}
+
+static const struct clk_ops da8xx_cfgchip_gate_clk_ops = {
+ .enable = da8xx_cfgchip_gate_clk_enable,
+ .disable= da8xx_cfgchip_gate_clk_disable,
+ .is_enabled = da8xx_cfgchip_gate_clk_is_enabled,
+};
+
+static void da8xx_cfgchip_gate_clk_init(struct device_node *np, u32 reg,
+ u32 mask)
+{
+ struct da8xx_cfgchip_gate_clk *clk;
+ struct clk_init_data init;
+ const char *name = np->name;
+ const char *parent_name;
+ struct regmap *regmap;
+ int ret;
+
+ of_property_read_string(np, "clock-output-names", &name);
+ parent_name = of_clk_get_parent_name(np, 0);
+
+ regmap = syscon_node_to_regmap(of_get_parent(np));
+ if (IS_ERR(regmap)) {
+ pr_err("%s: no regmap for syscon parent of %s (%ld)\n",
+ __func__, np->full_name, PTR_ERR(regmap));
+ return;
+ }
+
+ clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return;
+
+ init.name = name;
+ init.ops = &da8xx_cfgchip_gate_clk_ops;
+ init.parent_names = parent_name ? &parent_name : NULL;
+ init.num_parents = parent_name ? 1 : 0;
+ init.flags = 0;
+
+ clk->hw.init = &init;
+ clk->regmap = regmap;
+ clk->reg = reg;
+ clk->mask = mask;
+
+ ret = clk_hw_register(NULL, &clk->hw);
+ if (ret) {
+ pr_err("%s: failed to register %s (%d)\n", __func__,
+ np->full_name, ret);
+ return;
+ }
+
+ of_clk_add_hw_provider(np, of_clk_hw_simple_get, &clk->hw);
+}
+
+static void da8xx_tbclk_init(struct device_node *np)
+{
+ da8xx_cfgchip_gate_clk_init(np, CFGCHIP(1), CFGCHIP1_TBCLKSYNC);
+}
+CLK_OF_DECLARE(da8xx_tbclk, "ti,da830-tbclk", da8xx_tbclk_init);
+
+struct da8xx_cfgchip_mux_clk {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u32 reg;
+ u32 mask;
+};
+
+#define to_da8xx_cfgchip_mux_clk(_hw) \
+ container_of((_hw), struct da8xx_cfgchip_mux_clk, hw)
+
+static int da8xx_cfgchip_mux_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct da8xx_cfgchip_mux_clk *clk = to_da8xx_cfgchip_mux_clk(hw);
+ unsigned int val = index ? clk->mask : 0;
+
+ return regmap_write_bits(clk->regmap, clk->reg, clk->mask, val);
+}
+
+static u8 da8xx_cfgchip_mux_clk_get_parent(struct clk_hw *hw)
+{
+ struct da8xx_cfgchip_mux_clk *clk = to_da8xx_cfgchip_mux_clk(hw);
+ unsigned int val;
+
+ regmap_read(clk->regmap, clk->reg, &val);
+
+ return (val & clk->mask) ? 1 : 0;
+}
+
+static const struct clk_ops da8xx_cfgchip_mux_clk_ops = {
+ .set_parent = da8xx_cfgchip_mux_clk_set_parent,
+ .get_parent = da8xx_cfgchip_mux
[PATCH v5 21/44] clk: davinci: New driver for TI DA8XX USB PHY clocks
This adds a new driver for the USB PHY clocks in the CFGCHIP2 syscon
register on TI DA8XX-type SoCs.
The USB0 (USB 2.0) PHY clock is an interesting case because it calls
clk_enable() in a reentrant way. The USB 2.0 PSC only has to be enabled
temporarily while we are locking the PLL, which takes place during the
clk_enable() callback.
Signed-off-by: David Lechner
---
drivers/clk/davinci/Makefile| 1 +
drivers/clk/davinci/da8xx-usb-phy-clk.c | 425
include/linux/clk/davinci.h | 13 +
3 files changed, 439 insertions(+)
create mode 100644 drivers/clk/davinci/da8xx-usb-phy-clk.c
diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
index 11178b7..4c772a7 100644
--- a/drivers/clk/davinci/Makefile
+++ b/drivers/clk/davinci/Makefile
@@ -2,6 +2,7 @@
ifeq ($(CONFIG_COMMON_CLK), y)
obj-$(CONFIG_ARCH_DAVINCI_DA8XX) += da8xx-cfgchip.o
+obj-$(CONFIG_ARCH_DAVINCI_DA8XX) += da8xx-usb-phy-clk.o
obj-y += pll.o
obj-$(CONFIG_ARCH_DAVINCI_DA830) += pll-da830.o
diff --git a/drivers/clk/davinci/da8xx-usb-phy-clk.c
b/drivers/clk/davinci/da8xx-usb-phy-clk.c
new file mode 100644
index 000..fc6ea07
--- /dev/null
+++ b/drivers/clk/davinci/da8xx-usb-phy-clk.c
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * da8xx-usb-phy-clk - TI DaVinci DA8xx USB PHY clocks driver
+ *
+ * Copyright (C) 2017 David Lechner
+ *
+ * This driver exposes the USB PHY clocks on DA8xx/AM18xx/OMAP-L13x SoCs.
+ * The clocks consist of two muxes and a PLL. The USB 2.0 PHY mux and PLL are
+ * combined into a single clock in Linux. The USB 1.0 PHY clock just consists
+ * of a mux. These clocks are controlled through CFGCHIP2, which is accessed
+ * as a syscon regmap since it is shared with other devices.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* --- USB 2.0 PHY clock --- */
+
+struct da8xx_usb0_phy_clk {
+ struct clk_hw hw;
+ struct clk *clk;
+ struct regmap *regmap;
+};
+
+enum da8xx_usb0_phy_clk_parent {
+ DA8XX_USB0_PHY_CLK_PARENT_USB_REFCLKIN,
+ DA8XX_USB0_PHY_CLK_PARENT_PLL0_AUXCLK,
+};
+
+#define to_da8xx_usb0_phy_clk(_hw) \
+ container_of((_hw), struct da8xx_usb0_phy_clk, hw)
+
+static int da8xx_usb0_phy_clk_prepare(struct clk_hw *hw)
+{
+ struct da8xx_usb0_phy_clk *clk = to_da8xx_usb0_phy_clk(hw);
+
+ /* The USB 2.0 PSC clock is only needed temporarily during the USB 2.0
+* PHY clock enable, but since clk_prepare() can't be called in an
+* atomic context (i.e. in clk_enable()), we have to prepare it here.
+*/
+ return clk_prepare(clk->clk);
+}
+
+static void da8xx_usb0_phy_clk_unprepare(struct clk_hw *hw)
+{
+ struct da8xx_usb0_phy_clk *clk = to_da8xx_usb0_phy_clk(hw);
+
+ clk_unprepare(clk->clk);
+}
+
+static int da8xx_usb0_phy_clk_enable(struct clk_hw *hw)
+{
+ struct da8xx_usb0_phy_clk *clk = to_da8xx_usb0_phy_clk(hw);
+ unsigned int mask, val;
+ int ret;
+
+ /* Locking the USB 2.O PLL requires that the USB 2.O PSC is enabled
+* temporaily. It can be turned back off once the PLL is locked.
+*/
+ clk_enable(clk->clk);
+
+ /* Turn on the USB 2.0 PHY, but just the PLL, and not OTG. The USB 1.1
+* PHY may use the USB 2.0 PLL clock without USB 2.0 OTG being used.
+*/
+ mask = CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | CFGCHIP2_PHY_PLLON;
+ val = CFGCHIP2_PHY_PLLON;
+
+ regmap_write_bits(clk->regmap, CFGCHIP(2), mask, val);
+ ret = regmap_read_poll_timeout(clk->regmap, CFGCHIP(2), val,
+ val & CFGCHIP2_PHYCLKGD, 0, 50);
+
+ clk_disable(clk->clk);
+
+ return ret;
+}
+
+static void da8xx_usb0_phy_clk_disable(struct clk_hw *hw)
+{
+ struct da8xx_usb0_phy_clk *clk = to_da8xx_usb0_phy_clk(hw);
+ unsigned int val;
+
+ val = CFGCHIP2_PHYPWRDN;
+ regmap_write_bits(clk->regmap, CFGCHIP(2), val, val);
+}
+
+static int da8xx_usb0_phy_clk_is_enabled(struct clk_hw *hw)
+{
+ struct da8xx_usb0_phy_clk *clk = to_da8xx_usb0_phy_clk(hw);
+ unsigned int val;
+
+ regmap_read(clk->regmap, CFGCHIP(2), &val);
+
+ return !!(val & CFGCHIP2_PHYCLKGD);
+}
+
+static unsigned long da8xx_usb0_phy_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct da8xx_usb0_phy_clk *clk = to_da8xx_usb0_phy_clk(hw);
+ unsigned int mask, val;
+
+ /* The parent clock rate must be one of the following */
+ mask = CFGCHIP2_REFFREQ_MASK;
+ switch (parent_rate) {
+ case 1200:
+ val = CFGCHIP2_REFFREQ_12MHZ;
+ break;
+ case 1300:
+ val = CFGCHIP2_REFFREQ_13MHZ;
+ break;
+ case 1920:
+ val = CFGCHIP2_REFFREQ_19_2MHZ;
+ break;
+ case 2000:
+
[PATCH V3 1/2] ARM: dts: imx6ul: add 696MHz operating point
Add 696MHz operating point according to datasheet (Rev. 0, 12/2015). Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam --- changes since v2: add reviewed-by. arch/arm/boot/dts/imx6ul.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi index d5181f8..963e169 100644 --- a/arch/arm/boot/dts/imx6ul.dtsi +++ b/arch/arm/boot/dts/imx6ul.dtsi @@ -68,12 +68,14 @@ clock-latency = <61036>; /* two CLK32 periods */ operating-points = < /* kHz uV */ + 696000 1275000 528000 1175000 396000 1025000 198000 95 >; fsl,soc-operating-points = < /* KHz uV */ + 696000 1275000 528000 1175000 396000 1175000 198000 1175000 -- 1.9.1
