Re: [linux-sunxi] [PATCH v3] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board
On Sun, Dec 24, 2017 at 01:40:29PM +0800, Icenowy Zheng wrote:
> Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a form
> factor and GPIO holes similar to Raspberry Pi Zero.
>
> It features:
> - Allwinner H2+ SoC
> - Single-chip (16-bit) 512MiB DDR3 DRAM
> - Ampak AP6212 Wi-Fi/Bluetooth module
> - MicroSD slot
> - Two MicroUSB Type-B ports (one can only be used to power the board and
> the other features OTG functionality)
> - Two keys, a reset and a GPIO-connected key.
> - HDMI Type-C (miniHDMI) connector connected to the HDMI part of H2+.
> - CSI connector to connect the camera sensor provided by Sinovoip.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v3:
> - Add comments about Vbus problem in &usbphy node.
>
> Changes in v2:
> - Use high active SD card detect on the production batch.
>
> arch/arm/boot/dts/Makefile | 1 +
> .../boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts| 162
> +
> 2 files changed, 163 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0bb8db33704a..937a8768671f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -962,6 +962,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a83t-cubietruck-plus.dtb \
> sun8i-a83t-tbs-a711.dtb \
> sun8i-h2-plus-orangepi-r1.dtb \
> + sun8i-h2-plus-bananapi-m2-zero.dtb \
> sun8i-h2-plus-orangepi-zero.dtb \
> sun8i-h3-bananapi-m2-plus.dtb \
> sun8i-h3-beelink-x2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> new file mode 100644
> index ..5bc182ddc5f7
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> @@ -0,0 +1,162 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng
> + *
> + * Based on sun8i-h3-bananapi-m2-plus.dts, which is:
> + * Copyright (C) 2016 Chen-Yu Tsai
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "Banana Pi BPI-M2-Zero";
> + compatible = "sinovoip,bpi-m2-zero", "allwinner,sun8i-h2-plus";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> +
> + pwr_led {
> + label = "bananapi-m2-zero:red:pwr";
> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
> + default-state = "on";
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> +
> + sw4 {
> +
Re: [virtio-dev] Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG
On 12/24/2017 03:42 PM, Wei Wang wrote:
On 12/24/2017 12:45 PM, Tetsuo Handa wrote:
Matthew Wilcox wrote:
+unsigned long pfn = page_to_pfn(page);
+int ret;
+
+*pfn_min = min(pfn, *pfn_min);
+*pfn_max = max(pfn, *pfn_max);
+
+do {
+if (xb_preload(GFP_NOWAIT | __GFP_NOWARN) < 0)
+return -ENOMEM;
+
+ret = xb_set_bit(&vb->page_xb, pfn);
+xb_preload_end();
+} while (unlikely(ret == -EAGAIN));
OK, so you don't need a spinlock because you're under a mutex? But you
can't allocate memory because you're in the balloon driver, and so a
GFP_KERNEL allocation might recurse into your driver?
Right. We can't (directly or indirectly) depend on
__GFP_DIRECT_RECLAIM && !__GFP_NORETRY
allocations because the balloon driver needs to handle OOM notifier
callback.
Would GFP_NOIO
do the job? I'm a little hazy on exactly how the balloon driver works.
GFP_NOIO implies __GFP_DIRECT_RECLAIM. In the worst case, it can
lockup due to
the too small to fail memory allocation rule. GFP_NOIO |
__GFP_NORETRY would work
if there is really a guarantee that GFP_NOIO | __GFP_NORETRY never
depend on
__GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocations, which is too
subtle for me to
validate. The direct reclaim dependency is too complicated to validate.
I consider that !__GFP_DIRECT_RECLAIM is the future-safe choice.
What's the problem with (or how is it better than) the "GFP_NOWAIT |
__GFP_NOWARN" we are using here?
If you can't preload with anything better than that, I think that
xb_set_bit() should attempt an allocation with GFP_NOWAIT |
__GFP_NOWARN,
and then you can skip the preload; it has no value for you.
Yes, that's why I suggest directly using kzalloc() at xb_set_bit().
It has some possibilities to remove that preload if we also do the
bitmap allocation in the xb_set_bit():
bitmap = rcu_dereference_raw(*slot);
if (!bitmap) {
bitmap = this_cpu_xchg(ida_bitmap, NULL);
if (!bitmap) {
bitmap = kmalloc(sizeof(*bitmap), gfp);
if (!bitmap)
return -ENOMEM;
}
}
But why not just follow the radix tree implementation style that puts
the allocation in preload, which would be invoked with a more relaxed
gfp in other use cases?
Its usage in virtio_balloon is just a little special that we need to
put the allocation within the balloon_lock, which doesn't give us the
benefit of using a relaxed gfp in preload, but it doesn't prevent us
from living with the current APIs (i.e. the preload + xb_set pattern).
On the other side, if we do it as above, we have more things that need
to consider. For example, what if the a use case just want the radix
tree implementation style, which means it doesn't want allocation
within xb_set(), then would we be troubled with how to avoid the
allocation path in that case?
So, I think it is better to stick with the convention by putting the
allocation in preload. Breaking the convention should show obvious
advantages, IMHO.
@@ -173,8 +292,15 @@ static unsigned fill_balloon(struct
virtio_balloon *vb, size_t num)
while ((page = balloon_page_pop(&pages))) {
balloon_page_enqueue(&vb->vb_dev_info, page);
+if (use_sg) {
+if (xb_set_page(vb, page, &pfn_min, &pfn_max) < 0) {
+__free_page(page);
+continue;
+}
+} else {
+set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+}
Is this the right behaviour?
I don't think so. In the worst case, we can set no bit using
xb_set_page().
If we can't record the page in the xb,
wouldn't we rather send it across as a single page?
I think that we need to be able to fallback to !use_sg path when OOM.
I also have different thoughts:
1) For OOM, we have leak_balloon_sg_oom (oom has nothing to do with
fill_balloon), which does not use xbitmap to record pages, thus no
memory allocation.
2) If the memory is already under pressure, it is pointless to
continue inflating memory to the host. We need to give thanks to the
memory allocation failure reported by xbitmap, which gets us a chance
to release the inflated pages that have been demonstrated to cause the
memory pressure of the guest.
Forgot to add my conclusion: I think the above behavior is correct.
Best,
Wei
[PATCH] staging: comedi: adv_pci1760: fix typo in comments
Changed 'firware' to 'firmware' Signed-off-by: Richard Sudaryono --- drivers/staging/comedi/drivers/adv_pci1760.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/adv_pci1760.c b/drivers/staging/comedi/drivers/adv_pci1760.c index e692be371f29..f460f21efb90 100644 --- a/drivers/staging/comedi/drivers/adv_pci1760.c +++ b/drivers/staging/comedi/drivers/adv_pci1760.c @@ -60,7 +60,7 @@ #define PCI1760_CMD_SET_DO 0x01/* Set output state */ #define PCI1760_CMD_GET_DO 0x02/* Read output status */ #define PCI1760_CMD_GET_STATUS 0x03/* Read current status */ -#define PCI1760_CMD_GET_FW_VER 0x0e/* Read firware version */ +#define PCI1760_CMD_GET_FW_VER 0x0e/* Read firmware version */ #define PCI1760_CMD_GET_HW_VER 0x0f/* Read hardware version */ #define PCI1760_CMD_SET_PWM_HI(x) (0x10 + (x) * 2) /* Set "hi" period */ #define PCI1760_CMD_SET_PWM_LO(x) (0x11 + (x) * 2) /* Set "lo" period */ -- 2.15.1
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
Le 23/12/2017 à 16:57, Guenter Roeck a écrit : On 12/23/2017 05:48 AM, Greg KH wrote: On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: Hi all, When I tried to use devm_ioremap function and review related code, I found devm_ioremap and devm_ioremap_nocache is almost the same with each other, except one use ioremap while the other use ioremap_nocache. For all arches? Really? Look at MIPS, and x86, they have different functions. Both mips and x86 end up mapping the same function, but other arches don't. mn10300 is one where ioremap and ioremap_nocache are definitely different. alpha: identical arc: identical arm: identical arm64: identical cris: different<== frv: identical hexagone: identical ia64: different<== m32r: identical m68k: identical metag: identical microblaze: identical mips: identical mn10300: different <== nios: identical openrisc: different<== parisc: identical riscv: identical s390: identical sh: identical sparc: identical tile: identical um: rely on asm/generic unicore32: identical x86: identical asm/generic (no mmu): identical So 4 among all arches seems to have ioremap() and ioremap_nocache() being different. Could we have a define set by the 4 arches on which ioremap() and ioremap_nocache() are different, something like HAVE_DIFFERENT_IOREMAP_NOCACHE ? Christophe Guenter While ioremap's default function is ioremap_nocache, so devm_ioremap_nocache also have the same function with devm_ioremap, which can just be killed to reduce the size of devres.o(from 20304 bytes to 18992 bytes in my compile environment). I have posted two versions, which use macro instead of function for devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill devm_ioremap_nocache for no need to keep a macro around for the duplicate thing. So here comes v3 and please help to review. I don't think this can be done, what am I missing? These functions are not identical, sorry for missing that before. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
Le 23/12/2017 à 14:48, Greg KH a écrit :
On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
Hi all,
When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache.
For all arches? Really? Look at MIPS, and x86, they have different
functions.
While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.
I don't think this can be done, what am I missing? These functions are
not identical, sorry for missing that before.
devm_ioremap() and devm_ioremap_nocache() are quite similar, both use
devm_ioremap_release() for the release, why not just defining:
static void __iomem *__devm_ioremap(struct device *dev, resource_size_t
offset,
resource_size_t size, bool nocache)
{
[...]
if (nocache)
addr = ioremap_nocache(offset, size);
else
addr = ioremap(offset, size);
[...]
}
then in include/linux/io.h
static inline void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
resource_size_t size)
{return __devm_ioremap(dev, offset, size, false);}
static inline void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, true);}
Christophe
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
Re: [PATCH 01/12] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL
Am 24.12.2017 um 07:14 schrieb Tan Xiaojun:
From: Michal Srb
The io_mem_pfn field was added in commit
ea642c3216cb2a60d1c0e760ae47ee85c9c16447
and is called unconditionally. However, not all drivers were updated to set it.
Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.
Signed-off-by: Michal Srb
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index c8ebb75..e25a99b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (bo->mem.bus.is_iomem) {
/* Iomem should not be marked encrypted */
cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
- pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+ if (bdev->driver->io_mem_pfn)
+ pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+ else
+ pfn = ttm_bo_default_io_mem_pfn(bo,
page_offset);
Please move this check into a new function ttm_bo_io_mem_pfn().
You can then move the calculation of ttm_bo_default_io_mem_pfn() into
this new function in patch #12 as well.
Regards,
Christian.
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {
Re: [PATCH v3] xen/balloon: Mark unallocated host memory as UNUSABLE
Am 20.12.2017 um 15:05 schrieb Boris Ostrovsky:
Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
reservation") left host memory not assigned to dom0 as available for
memory hotplug.
Unfortunately this also meant that those regions could be used by
others. Specifically, commit fa564ad96366 ("x86/PCI: Enable a 64bit BAR
on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)") may try to map those
addresses as MMIO.
To prevent this mark unallocated host memory as E820_TYPE_UNUSABLE (thus
effectively reverting f5775e0b6116) and keep track of that region as
a hostmem resource that can be used for the hotplug.
Signed-off-by: Boris Ostrovsky
Acked-by: Christian König
---
Changes in v3:
* Use PFN_PHYS
* Replace kzalloc with kmalloc
* Declare arch_xen_balloon_init prototype in balloon.h
* Rename resources (s/memory/RAM/)
* Clarify (I think) comment when populating hostmem_resource
* Print open-ended interval on insert_resource() error
* Constify declaration of struct e820_entry *entry
arch/x86/xen/enlighten.c | 81
arch/x86/xen/setup.c | 6 ++--
drivers/xen/balloon.c| 65 --
include/xen/balloon.h| 5 +++
4 files changed, 144 insertions(+), 13 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d669e9d..c9081c6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1,8 +1,12 @@
+#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
+#include
+#endif
#include
#include
#include
#include
+#include
#include
#include
@@ -331,3 +335,80 @@ void xen_arch_unregister_cpu(int num)
}
EXPORT_SYMBOL(xen_arch_unregister_cpu);
#endif
+
+#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
+void __init arch_xen_balloon_init(struct resource *hostmem_resource)
+{
+ struct xen_memory_map memmap;
+ int rc;
+ unsigned int i, last_guest_ram;
+ phys_addr_t max_addr = PFN_PHYS(max_pfn);
+ struct e820_table *xen_e820_table;
+ const struct e820_entry *entry;
+ struct resource *res;
+
+ if (!xen_initial_domain())
+ return;
+
+ xen_e820_table = kmalloc(sizeof(*xen_e820_table), GFP_KERNEL);
+ if (!xen_e820_table)
+ return;
+
+ memmap.nr_entries = ARRAY_SIZE(xen_e820_table->entries);
+ set_xen_guest_handle(memmap.buffer, xen_e820_table->entries);
+ rc = HYPERVISOR_memory_op(XENMEM_machine_memory_map, &memmap);
+ if (rc) {
+ pr_warn("%s: Can't read host e820 (%d)\n", __func__, rc);
+ goto out;
+ }
+
+ last_guest_ram = 0;
+ for (i = 0; i < memmap.nr_entries; i++) {
+ if (xen_e820_table->entries[i].addr >= max_addr)
+ break;
+ if (xen_e820_table->entries[i].type == E820_TYPE_RAM)
+ last_guest_ram = i;
+ }
+
+ entry = &xen_e820_table->entries[last_guest_ram];
+ if (max_addr >= entry->addr + entry->size)
+ goto out; /* No unallocated host RAM. */
+
+ hostmem_resource->start = max_addr;
+ hostmem_resource->end = entry->addr + entry->size;
+
+ /*
+* Mark non-RAM regions between the end of dom0 RAM and end of host RAM
+* as unavailable. The rest of that region can be used for hotplug-based
+* ballooning.
+*/
+ for (; i < memmap.nr_entries; i++) {
+ entry = &xen_e820_table->entries[i];
+
+ if (entry->type == E820_TYPE_RAM)
+ continue;
+
+ if (entry->addr >= hostmem_resource->end)
+ break;
+
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
+ if (!res)
+ goto out;
+
+ res->name = "Unavailable host RAM";
+ res->start = entry->addr;
+ res->end = (entry->addr + entry->size < hostmem_resource->end) ?
+ entry->addr + entry->size : hostmem_resource->end;
+ rc = insert_resource(hostmem_resource, res);
+ if (rc) {
+ pr_warn("%s: Can't insert [%llx - %llx) (%d)\n",
+ __func__, res->start, res->end, rc);
+ kfree(res);
+ goto out;
+ }
+ }
+
+ out:
+ kfree(xen_e820_table);
+}
+#endif /* CONFIG_XEN_BALLOON_MEMORY_HOTPLUG */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index c114ca7..6e0d208 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -808,7 +808,6 @@ char * __init xen_memory_setup(void)
addr = xen_e820_table.entries[0].addr;
size = xen_e820_table.entries[0].size;
while (i < xen_e820_table.nr_entries) {
- bool discard = false;
chunk_size = size;
type = xen_e820_table.entries[i].type;
@@ -824,11 +823,10 @@ char * __init xen_memory_setup(voi
WARNING: CPU: 1 PID: 1384 at lib/iov_iter.c:695 copy_page_to_iter+0x240/0x3b0
Hi,
this just happened on an i686 machine of mine:
[ cut here ]
WARNING: CPU: 1 PID: 1384 at lib/iov_iter.c:695 copy_page_to_iter+0x240/0x3b0
Modules linked in: xfs algif_skcipher af_alg uas nfsv4 dns_resolver nfs
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_meta
nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 lz4 nf_defrag_ipv4
lz4_compress nft_ct nf_conntrack libcrc32c crc32c_generic nft_set_hash
nf_tables_inet nf_tables_ipv6 nf_tables_ipv4 nf_tables nfnetlink
cpufreq_conservative sch_fq_codel zram evdev tg3 ptp pps_core lpc_ich
libphy input_leds ideapad_laptop sparse_keymap wmi serpent_sse2_i586
thermal serpent_generic lrw glue_helper ablk_helper cryptd video xts
dm_crypt acpi_cpufreq arc4 iTCO_wdt iTCO_vendor_support i2c_i801 fscache
loop coretemp battery b43 bcma mac80211 cfg80211 dm_mod dax ssb mmc_core
rfkill led_class rng_core pcmcia pcmcia_core nfsd auth_rpcgss oid_registry
ac nfs_acl lockd grace
sunrpc usb_storage sd_mod atkbd libps2 uhci_hcd ata_piix libata scsi_mod
ehci_pci ehci_hcd usbcore usb_common i8042 serio jfs [last unloaded:
soundcore]
CPU: 1 PID: 1384 Comm: java Not tainted 4.14.4-1.0-ARCH #1
Hardware name: LENOVO Lenovo /Mariana , BIOS
14CN94WW 06/29/2009
task: f27c1380 task.stack: f1c64000
EIP: copy_page_to_iter+0x240/0x3b0
EFLAGS: 00010286 CPU: 1
EAX: 1000 EBX: ffb48000 ECX: 02c0 EDX: 8001006c
ESI: f67ecb60 EDI: 0d40 EBP: f1c65e30 ESP: f1c65e08
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: 09f060cc CR3: 3260f000 CR4: 06d0
Call Trace:
? touch_atime+0x2b/0xb0
generic_file_read_iter+0x458/0x8c0
? xfs_ilock+0x10d/0x150 [xfs]
? xfs_file_buffered_aio_read+0xed/0x100 [xfs]
xfs_file_buffered_aio_read+0x4e/0x100 [xfs]
? set_next_entity+0x13f/0x8b0
xfs_file_read_iter+0x54/0xc0 [xfs]
__vfs_read+0xe7/0x140
vfs_read+0x7b/0x130
SyS_pread64+0x81/0xb0
do_fast_syscall_32+0x71/0x1d0
entry_SYSENTER_32+0x4e/0x7c
EIP: 0xb7f69cd9
EFLAGS: 0293 CPU: 1
EAX: ffda EBX: 009b ECX: 23c77f10 EDX: 001a
ESI: 156172c0 EDI: EBP: b7f50e70 ESP: 1f32ea60
DS: 007b ES: 007b FS: GS: 0033 SS: 007b
Code: 75 ec e9 ff fe ff ff 8d 74 26 00 8b 55 ec 8b 45 08 85 d2 8b 58 0c 74
09 e8 6e d7 ff ff 84 c0 75 1a 31 f6 e9 13 ff ff ff 8d 76 00 <0f> ff 31 f6
83 c4 1c 5b 89 f0 5e 5f 5d c3 66 90 8b 7d 08 8b 45
---[ end trace 0002deba6d00a28c ]---
This i686 laptop is running 4.14.4-1.0-ARCH [0] and is usually running
just fine, although memory pressure is usually quite hight due to some
Java program running on that machine. For some reason the system was even
more busy today, commands would take a long time to complete and I
rebooted the machine. Shortly after boot (and after starting this Java
program again), the warning above happened.
I couldn't find this exact message in the archives, the closest thing I
found was (mentioning that "EIP:copy_page_to_iter" message):
> 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel
> stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 01be
> https://patchwork.kernel.org/patch/9981273/
The XFS file system is mounted with:
> XFS (dm-2): EXPERIMENTAL reverse mapping btree feature enabled. Use at your
> own risk!
> XFS (dm-2): EXPERIMENTAL reflink feature enabled. Use at your own risk!
But I did not experience any problems with that, yet :)
Full dmesg & .config: http://nerdbynature.de/bits/4.14/
Any pointers?
Thanks,
Christian.
$ mount | grep xfs
/dev/mapper/opt on /opt type xfs
(rw,nosuid,nodev,relatime,attr2,inode64,noquota)
$ xfs_info /opt/
meta-data=/dev/mapper/optisize=512agcount=4, agsize=9079797
blks
= sectsz=512 attr=2, projid32bit=1
= crc=1finobt=1 spinodes=0 rmapbt=1
= reflink=1
data = bsize=4096 blocks=36319185, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=17733, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
[0] https://mirror.archlinux32.org/i686/core/linux-4.14.4-1.0-i686.pkg.tar.xz
--
BOFH excuse #413:
Cow-tippers tipped a cow onto the server.
[PATCH] staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe
rtl8192_usb_probe is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with msleep, to avoid busy wait. Signed-off-by: Jia-Ju Bai --- drivers/staging/rtl8192u/r8192U_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index 09f66b3..3c300f7 100644 --- a/drivers/staging/rtl8192u/r8192U_core.c +++ b/drivers/staging/rtl8192u/r8192U_core.c @@ -4998,7 +4998,7 @@ static int rtl8192_usb_probe(struct usb_interface *intf, kfree(priv->pFirmware); priv->pFirmware = NULL; rtl8192_usb_deleteendpoints(dev); - mdelay(10); + msleep(10); free_ieee80211(dev); RT_TRACE(COMP_ERR, "wlan driver load failed\n"); -- 1.7.9.5
[PATCH] scsi: imm: Replace mdelay with msleep in imm_init
imm_init is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with msleep, to reduce busy wait. Signed-off-by: Jia-Ju Bai --- drivers/scsi/imm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/imm.c b/drivers/scsi/imm.c index 87c9419..4805c0e 100644 --- a/drivers/scsi/imm.c +++ b/drivers/scsi/imm.c @@ -591,9 +591,9 @@ static int imm_init(imm_struct *dev) if (imm_connect(dev, 0) != 1) return -EIO; imm_reset_pulse(dev->base); - mdelay(1); /* Delay to allow devices to settle */ + msleep(1); /* Delay to allow devices to settle */ imm_disconnect(dev); - mdelay(1); /* Another delay to allow devices to settle */ + msleep(1); /* Another delay to allow devices to settle */ return device_check(dev); } -- 1.7.9.5
[PATCH] i40iw: Replace mdelay with msleep in i40iw_wait_pe_ready
i40iw_wait_pe_ready is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with msleep, to reduce busy wait. Signed-off-by: Jia-Ju Bai --- drivers/infiniband/hw/i40iw/i40iw_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c b/drivers/infiniband/hw/i40iw/i40iw_main.c index e824296..8098bc1 100644 --- a/drivers/infiniband/hw/i40iw/i40iw_main.c +++ b/drivers/infiniband/hw/i40iw/i40iw_main.c @@ -1285,7 +1285,7 @@ static void i40iw_wait_pe_ready(struct i40iw_hw *hw) __LINE__, statuscpu2); if ((statuscpu0 == 0x80) && (statuscpu1 == 0x80) && (statuscpu2 == 0x80)) break; /* SUCCESS */ - mdelay(1000); + msleep(1000); retrycount++; } while (retrycount < 14); i40iw_wr32(hw, 0xb4040, 0x4C104C5); -- 1.7.9.5
Dobur den na vas
Dobur den na vas,
Moeto ime e Simona Fionda, az byakh glavniyat operativen risk v METRO BANKA
otgovarya sushto i za chastniya upravlenieto na nyakoi nashumeli klienti,
vklyuchitelno trustove, blagotvoritelni organizatsii i pensionni fondove. Az
sum kontakt s vas za Ivan, murtuv klient ot predishniya mi banka, koyato
investira / deponiraneto na osem miliona dvesta khilyadi paunda (8,200,000.00)
s METRO BANKA.
V pregleda na nashiya finansov otchet ot moya otdel otkrikh tazi informatsiya,
koyato e bila skrita ot bankovi direktori, tui? kato umira.
Razbrakh, che imate edno i sushto familno ime s Ivan, koi?to e zashto az sum
kontakt s vas. Imam vsichki originalni dokumenti s men, tui? kato az sum gotov
da dam na vas, za da poluchite tezi pari ot alchnite bankeri, koito iskat da
sieze tezi pari vsichko tova, zashtoto Ivan se zabavi i ne e izvestno chlen ot
semei?stvoto da doi?de po-gore iziskvane, kogato umrya zaedno sus suprugata si
i dushterite v avtomobilna katastrofa prez 2011 godina.
Az sum gotov da spodelya tezi pari 50/50 s vas, ako ste gotovi da mi pomogne.
Bikh posuvetval ot suobrazheniya za bezopasnost i sigurnost, che nie
poddurzhame tazi mnogo POVERITELNO zaradi razmera na zasegnatite pari.
Molya, vurni se pri men vuzmozhno nai?-skoro, ako ste gotovi da otidete
po-dalech. Sushto taka da mi izpratite telefon za vruzka, za da se svurzhat s
vas.
Az shte chakam za vashiya otgovor, predi da znam kak tryabva da se protsedira.
Pozdravi,
Simona Fionda
This message is intended only for use of the person(s) ("the intended
recipient(s)") to whom it is addressed.
It may contain information which is privileged and confidential within the
meaning of applicable law.
If you are not the intended recipient, please contact the sender as soon as
possible.
The views expressed in this communication may not necessarily be the views held
by National Institute of Technology (NIT Manipur).
Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot
* Alexandru Chirvasitu wrote: > Thank you for the swift reply! > > On Sat, Dec 23, 2017 at 07:30:21PM -0800, Linus Torvalds wrote: > > On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu > > wrote: > > > > > > For testing purposes, I've altered machine_kexec_32.c making the > > > following toy commit. It naively undoes part of e802a51, solely to > > > confirm that's where it goes awry in my setup. > > > > That's really funky. > > > > The idt_invalidate() seems to do *exactly* the same thing. It uses > > "load_idt()" on an IDT with size 0, and the supplied address. > > > > Can you disassemble your "set_idt()" code vs the "idt_invalidate()"? > > > > I seem to have done some such thing just now, but please excuse some > poking around in the dark here (I've disassembled code exactly once > before: yesterday, in answering a similar request for more info in > another lkml thread..). > > I'm actually not even certain the sequel is what you are asking. > > I couldn't find the set_idt symbol in > arch/x86/kernel/machine_kexec_32.o. Google seemed to think this has > something to do with the 'static' marker for that function, so I made > another commit differing from the previous one only in that it removes > that marker (i.e. set_idt is now 'void' rather than 'static void'). > > I can now see that function with objdump. The relevant sections of > objdump -D on the two files are: > > --- arch/x86/kernel/machine_kexec_32.o --- > > 0180 : > 180: e8 fc ff ff ff call 181 > 185: 55 push %ebp > 186: 89 e5 mov%esp,%ebp > 188: 83 ec 0csub$0xc,%esp > 18b: 89 45 f8mov%eax,-0x8(%ebp) > 18e: 66 89 55 f6 mov%dx,-0xa(%ebp) > 192: 8d 45 f6lea-0xa(%ebp),%eax > 195: 65 8b 0d 14 00 00 00mov%gs:0x14,%ecx > 19c: 89 4d fcmov%ecx,-0x4(%ebp) > 19f: 31 c9 xor%ecx,%ecx > 1a1: ff 15 20 00 00 00 call *0x20 > 1a7: 8b 45 fcmov-0x4(%ebp),%eax > 1aa: 65 33 05 14 00 00 00xor%gs:0x14,%eax > 1b1: 75 02 jne1b5 > 1b3: c9 leave > 1b4: c3 ret > 1b5: e8 fc ff ff ff call 1b6 > 1ba: 8d b6 00 00 00 00 lea0x0(%esi),%esi > > -- > > and > > --- arch/x86/kernel/idt.o --- > > : >0: e8 fc ff ff ff call 1 >5: 55 push %ebp >6: 89 e5 mov%esp,%ebp >8: 83 ec 0csub$0xc,%esp >b: 65 8b 15 14 00 00 00mov%gs:0x14,%edx > 12: 89 55 fcmov%edx,-0x4(%ebp) > 15: 31 d2 xor%edx,%edx > 17: 31 d2 xor%edx,%edx > 19: 89 45 f8mov%eax,-0x8(%ebp) > 1c: 8d 45 f6lea-0xa(%ebp),%eax > 1f: 66 89 55 f6 mov%dx,-0xa(%ebp) > 23: ff 15 20 00 00 00 call *0x20 > 29: 8b 45 fcmov-0x4(%ebp),%eax > 2c: 65 33 05 14 00 00 00xor%gs:0x14,%eax > 33: 75 02 jne37 > 35: c9 leave > 36: c3 ret > 37: e8 fc ff ff ff call 38 > > --- > > I've also checked again that this newer compilation still gives a > well-behaved kexec. So guessing from the disassembly your kernel config seems to have both function tracing and paravirt enabled - both can cause complications here, in particular paravirt may override load_idt(). ( In the end execution should run through the same paravirt ops with and without your patch, so I don't see how it can make a difference but it's easier to look at the disassembly without the paravirt indirection - and your patch obviously makes a difference so we are missing some detail. ) So to simplify analysis, could you disable both please - i.e. disable these if your .config has any of these set: CONFIG_HYPERVISOR_GUEST=y CONFIG_FUNCTION_TRACER=y CONFIG_STACK_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y The easiest way to disable these is to run this script over your .config, in the kernel source code directory where you are building your kernel: grep -vE 'CONFIG_HYPERVISOR_GUEST|CONFIG_FUNCTION_TRACER|CONFIG_STACK_TRACER|CONFIG_FUNCTION_GRAPH_TRACER' .config > .config2 /bin/mv .config2 .config ... then run 'make oldconfig' and answer 'N' to every question. Double check the resulting .config via: grep -E 'CONFIG_HYPERVISOR_GUEST|CONFIG_FUNCTION_TRACER|CONFIG_STACK_TRACER|CONFIG_FUNCTION_GRAPH_TRACER' .config which should output: # CONFIG_HYPERVISOR_GUEST is not set # CONFIG_FUNCTION_TRACER is not set # CONFIG_STACK_TRACER is not set Also, could you send us your .config? Thanks, Ing
[PATCH] Coccinelle: kzalloc-simple: Add all zero allocating functions
There are many instances where memory is allocated using regular allocator
functions immediately followed by setting the allocated memory
to 0 value using memset.
We already have zero memory allocator functions to set the memory to
0 value instead of manually setting it using memset.
Therefore, use zero memory allocating functions instead of regular
memory allocators followed by memset 0 to remove redundant memset and
make the code more cleaner and also reduce the code size.
Signed-off-by: Himanshu Jha
---
scripts/coccinelle/api/alloc/kzalloc-simple.cocci | 371 +-
1 file changed, 367 insertions(+), 4 deletions(-)
diff --git a/scripts/coccinelle/api/alloc/kzalloc-simple.cocci
b/scripts/coccinelle/api/alloc/kzalloc-simple.cocci
index 52c55e4..f94888d 100644
--- a/scripts/coccinelle/api/alloc/kzalloc-simple.cocci
+++ b/scripts/coccinelle/api/alloc/kzalloc-simple.cocci
@@ -1,5 +1,5 @@
///
-/// Use kzalloc rather than kmalloc followed by memset with 0
+/// Use zeroing allocator rather than allocator followed by memset with 0
///
/// This considers some simple cases that are common and easy to validate
/// Note in particular that there are no ...s in the rule, so all of the
@@ -8,6 +8,7 @@
// Confidence: High
// Copyright: (C) 2009-2010 Julia Lawall, Nicolas Palix, DIKU. GPLv2.
// Copyright: (C) 2009-2010 Gilles Muller, INRIA/LiP6. GPLv2.
+// Cpoyright: (C) 2017 Himanshu Jha GPLv2.
// URL: http://coccinelle.lip6.fr/rules/kzalloc.html
// Options: --no-includes --include-headers
//
@@ -28,11 +29,14 @@ virtual report
@depends on context@
type T, T2;
expression x;
-expression E1,E2;
+expression E1;
statement S;
@@
-* x = (T)kmalloc(E1,E2);
+* x = (T)\(kmalloc(E1, ...)\|vmalloc(E1)\|dma_alloc_coherent(...,E1,...)\|
+ kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\|
+ devm_kmalloc(...,E1,...)\|kvmalloc(E1,
...)\|pci_alloc_consistent(...,E1,...)\|
+ kvmalloc_node(E1,...)\);
if ((x==NULL) || ...) S
* memset((T2)x,0,E1);
@@ -43,12 +47,101 @@ statement S;
@depends on patch@
type T, T2;
expression x;
-expression E1,E2;
+expression E1,E2,E3,E4;
statement S;
@@
+(
+- x = kmalloc(E1,E2);
++ x = kzalloc(E1,E2);
+|
- x = (T)kmalloc(E1,E2);
++ x = (T)kzalloc(E1,E2);
+|
+- x = (T *)kmalloc(E1,E2);
+ x = kzalloc(E1,E2);
+|
+- x = vmalloc(E1);
++ x = vzalloc(E1);
+|
+- x = (T)vmalloc(E1);
++ x = (T)vzalloc(E1);
+|
+- x = (T *)vmalloc(E1);
++ x = vzalloc(E1);
+|
+- x = dma_alloc_coherent(E2,E1,E3,E4);
++ x = dma_zalloc_coherent(E2,E1,E3,E4);
+|
+- x = (T)dma_alloc_coherent(E2,E1,E3,E4);
++ x = (T)dma_zalloc_coherent(E2,E1,E3,E4);
+|
+- x = (T *)dma_alloc_coherent(E2,E1,E3,E4);
++ x = dma_zalloc_coherent(E2,E1,E3,E4);
+|
+- x = kmalloc_node(E1,E2,E3);
++ x = kzalloc_node(E1,E2,E3);
+|
+- x = (T)kmalloc_node(E1,E2,E3);
++ x = (T)kzalloc_node(E1,E2,E3);
+|
+- x = (T *)kmalloc_node(E1,E2,E3);
++ x = kzalloc_node(E1,E2,E3);
+|
+- x = kmem_cache_alloc(E3,E4);
++ x = kmem_cache_zalloc(E3,E4);
+|
+- x = (T)kmem_cache_alloc(E3,E4);
++ x = (T)kmem_cache_zalloc(E3,E4);
+|
+- x = (T *)kmem_cache_alloc(E3,E4);
++ x = kmem_cache_zalloc(E3,E4);
+|
+- x = kmem_alloc(E1,E2);
++ x = kmem_zalloc(E1,E2);
+|
+- x = (T)kmem_alloc(E1,E2);
++ x = (T)kmem_zalloc(E1,E2);
+|
+- x = (T *)kmem_alloc(E1,E2);
++ x = kmem_zalloc(E1,E2);
+|
+- x = devm_kmalloc(E2,E1,E3);
++ x = devm_kzalloc(E2,E1,E3);
+|
+- x = (T)devm_kmalloc(E2,E1,E3);
++ x = (T)devm_kzalloc(E2,E1,E3);
+|
+- x = (T *)devm_kmalloc(E2,E1,E3);
++ x = devm_kzalloc(E2,E1,E3);
+|
+- x = kvmalloc(E1,E2);
++ x = kvzalloc(E1,E2);
+|
+- x = (T)kvmalloc(E1,E2);
++ x = (T)kvzalloc(E1,E2);
+|
+- x = (T *)kvmalloc(E1,E2);
++ x = kvzalloc(E1,E2);
+|
+- x = pci_alloc_consistent(E2,E1,E3);
++ x = pci_zalloc_consistent(E2,E1,E3);
+|
+- x = (T)pci_alloc_consistent(E2,E1,E3);
++ x = (T)pci_zalloc_consistent(E2,E1,E3);
+|
+- x = (T *)pci_alloc_consistent(E2,E1,E3);
++ x = pci_zalloc_consistent(E2,E1,E3);
+|
+- x = kvmalloc_node(E1,E2,E3);
++ x = kvzalloc_node(E1,E2,E3);
+|
+- x = (T)kvmalloc_node(E1,E2,E3);
++ x = (T)kvzalloc_node(E1,E2,E3);
+|
+- x = (T *)kvmalloc_node(E1,E2,E3);
++ x = kvzalloc_node(E1,E2,E3);
+)
if ((x==NULL) || ...) S
- memset((T2)x,0,E1);
@@ -84,3 +177,273 @@ x << r.x;
msg="WARNING: kzalloc should be used for %s, instead of kmalloc/memset" % (x)
coccilib.report.print_report(p[0], msg)
+
+//-
+@r1 depends on org || report@
+type T, T2;
+expression x;
+expression E1;
+statement S;
+position p;
+@@
+
+ x = (T)vmalloc@p(E1);
+ if ((x==NULL) || ...) S
+ memset((T2)x,0,E1);
+
+@script:python depends on org@
+p << r1.p;
+x << r1.x;
+@@
+
+msg="%s" % (x)
+msg_safe=msg.replace("[","@(").replace("]",")")
+coccilib.org.print_todo(p[0], msg_safe)
+
+@script:python depends on report@
+p << r1.p;
+x << r1.x;
+@@
+
+msg="WARNING: vzalloc should be used for %s, instead of vmalloc/memset" % (x)
+coccilib.report.print_report(p[0], msg)
+
+//
Thinkpad T40p: suspend to ram stopped working sometime before 4.14
Hi! 4.15-rcX is broken, but that had other problems so lets not go there. 4.14 is broken. 4.12 is ok. 4.13 is ok. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2 2/3] backlight: tdo24m: add the reset line gpio
Robert Jarzmik writes: > Daniel Thompson writes: > >> On Fri, Oct 13, 2017 at 09:42:48PM +0200, Robert Jarzmik wrote: >> Also, this adds a new optional property, doesn't the devicetree binding >> docs need to be update to match this? > Ah yes, that too. I'll add it for v3. Actually I won't ... because there is no description for tdo24m I could find. If that's a problem for you, I'll drop that patch as well. Cheers. -- Robert
Re: [PATCH] i40iw: Replace mdelay with msleep in i40iw_wait_pe_ready
On Sun, Dec 24, 2017 at 06:39:40PM +0800, Jia-Ju Bai wrote: > i40iw_wait_pe_ready is not called in an interrupt handler > nor holding a spinlock. > The function mdelay in it can be replaced with msleep, > to reduce busy wait. > > Signed-off-by: Jia-Ju Bai > --- > drivers/infiniband/hw/i40iw/i40iw_main.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Thanks, Reviewed-by: Leon Romanovsky signature.asc Description: PGP signature
Re: [PATCH] Coccinelle: kzalloc-simple: Add all zero allocating functions
On Sun, 24 Dec 2017, Himanshu Jha wrote: > There are many instances where memory is allocated using regular allocator > functions immediately followed by setting the allocated memory > to 0 value using memset. > > We already have zero memory allocator functions to set the memory to > 0 value instead of manually setting it using memset. > > Therefore, use zero memory allocating functions instead of regular > memory allocators followed by memset 0 to remove redundant memset and > make the code more cleaner and also reduce the code size. > > Signed-off-by: Himanshu Jha Acked-by: Julia Lawall > --- > scripts/coccinelle/api/alloc/kzalloc-simple.cocci | 371 > +- > 1 file changed, 367 insertions(+), 4 deletions(-) > > diff --git a/scripts/coccinelle/api/alloc/kzalloc-simple.cocci > b/scripts/coccinelle/api/alloc/kzalloc-simple.cocci > index 52c55e4..f94888d 100644 > --- a/scripts/coccinelle/api/alloc/kzalloc-simple.cocci > +++ b/scripts/coccinelle/api/alloc/kzalloc-simple.cocci > @@ -1,5 +1,5 @@ > /// > -/// Use kzalloc rather than kmalloc followed by memset with 0 > +/// Use zeroing allocator rather than allocator followed by memset with 0 > /// > /// This considers some simple cases that are common and easy to validate > /// Note in particular that there are no ...s in the rule, so all of the > @@ -8,6 +8,7 @@ > // Confidence: High > // Copyright: (C) 2009-2010 Julia Lawall, Nicolas Palix, DIKU. GPLv2. > // Copyright: (C) 2009-2010 Gilles Muller, INRIA/LiP6. GPLv2. > +// Cpoyright: (C) 2017 Himanshu Jha GPLv2. > // URL: http://coccinelle.lip6.fr/rules/kzalloc.html > // Options: --no-includes --include-headers > // > @@ -28,11 +29,14 @@ virtual report > @depends on context@ > type T, T2; > expression x; > -expression E1,E2; > +expression E1; > statement S; > @@ > > -* x = (T)kmalloc(E1,E2); > +* x = (T)\(kmalloc(E1, ...)\|vmalloc(E1)\|dma_alloc_coherent(...,E1,...)\| > + kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\| > + devm_kmalloc(...,E1,...)\|kvmalloc(E1, > ...)\|pci_alloc_consistent(...,E1,...)\| > + kvmalloc_node(E1,...)\); >if ((x==NULL) || ...) S > * memset((T2)x,0,E1); > > @@ -43,12 +47,101 @@ statement S; > @depends on patch@ > type T, T2; > expression x; > -expression E1,E2; > +expression E1,E2,E3,E4; > statement S; > @@ > > +( > +- x = kmalloc(E1,E2); > ++ x = kzalloc(E1,E2); > +| > - x = (T)kmalloc(E1,E2); > ++ x = (T)kzalloc(E1,E2); > +| > +- x = (T *)kmalloc(E1,E2); > + x = kzalloc(E1,E2); > +| > +- x = vmalloc(E1); > ++ x = vzalloc(E1); > +| > +- x = (T)vmalloc(E1); > ++ x = (T)vzalloc(E1); > +| > +- x = (T *)vmalloc(E1); > ++ x = vzalloc(E1); > +| > +- x = dma_alloc_coherent(E2,E1,E3,E4); > ++ x = dma_zalloc_coherent(E2,E1,E3,E4); > +| > +- x = (T)dma_alloc_coherent(E2,E1,E3,E4); > ++ x = (T)dma_zalloc_coherent(E2,E1,E3,E4); > +| > +- x = (T *)dma_alloc_coherent(E2,E1,E3,E4); > ++ x = dma_zalloc_coherent(E2,E1,E3,E4); > +| > +- x = kmalloc_node(E1,E2,E3); > ++ x = kzalloc_node(E1,E2,E3); > +| > +- x = (T)kmalloc_node(E1,E2,E3); > ++ x = (T)kzalloc_node(E1,E2,E3); > +| > +- x = (T *)kmalloc_node(E1,E2,E3); > ++ x = kzalloc_node(E1,E2,E3); > +| > +- x = kmem_cache_alloc(E3,E4); > ++ x = kmem_cache_zalloc(E3,E4); > +| > +- x = (T)kmem_cache_alloc(E3,E4); > ++ x = (T)kmem_cache_zalloc(E3,E4); > +| > +- x = (T *)kmem_cache_alloc(E3,E4); > ++ x = kmem_cache_zalloc(E3,E4); > +| > +- x = kmem_alloc(E1,E2); > ++ x = kmem_zalloc(E1,E2); > +| > +- x = (T)kmem_alloc(E1,E2); > ++ x = (T)kmem_zalloc(E1,E2); > +| > +- x = (T *)kmem_alloc(E1,E2); > ++ x = kmem_zalloc(E1,E2); > +| > +- x = devm_kmalloc(E2,E1,E3); > ++ x = devm_kzalloc(E2,E1,E3); > +| > +- x = (T)devm_kmalloc(E2,E1,E3); > ++ x = (T)devm_kzalloc(E2,E1,E3); > +| > +- x = (T *)devm_kmalloc(E2,E1,E3); > ++ x = devm_kzalloc(E2,E1,E3); > +| > +- x = kvmalloc(E1,E2); > ++ x = kvzalloc(E1,E2); > +| > +- x = (T)kvmalloc(E1,E2); > ++ x = (T)kvzalloc(E1,E2); > +| > +- x = (T *)kvmalloc(E1,E2); > ++ x = kvzalloc(E1,E2); > +| > +- x = pci_alloc_consistent(E2,E1,E3); > ++ x = pci_zalloc_consistent(E2,E1,E3); > +| > +- x = (T)pci_alloc_consistent(E2,E1,E3); > ++ x = (T)pci_zalloc_consistent(E2,E1,E3); > +| > +- x = (T *)pci_alloc_consistent(E2,E1,E3); > ++ x = pci_zalloc_consistent(E2,E1,E3); > +| > +- x = kvmalloc_node(E1,E2,E3); > ++ x = kvzalloc_node(E1,E2,E3); > +| > +- x = (T)kvmalloc_node(E1,E2,E3); > ++ x = (T)kvzalloc_node(E1,E2,E3); > +| > +- x = (T *)kvmalloc_node(E1,E2,E3); > ++ x = kvzalloc_node(E1,E2,E3); > +) >if ((x==NULL) || ...) S > - memset((T2)x,0,E1); > > @@ -84,3 +177,273 @@ x << r.x; > > msg="WARNING: kzalloc should be used for %s, instead of kmalloc/memset" % (x) > coccilib.report.print_report(p[0], msg) > + > +//- > +@r1 depends on org || report@ > +type T, T2; > +expression x; > +expression E1; > +statement S; > +position p; > +@@ > + > + x = (T)vmalloc@p(E1); > + if ((x==NULL) || ..
Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device
On Saturday, December 23, 2017 4:09:33 PM CET Ulf Hansson wrote: > [...] > > > > > So IMO the changes you are proposing make sense regardless of the > > genpd issue, because they generally simplify the phy code, but the > > additional use_runtime_pm field in struct phy represents redundant > > information (manipulating reference counters shouldn't matter if > > runtime PM is disabled), so it doesn't appear to be necessary. > > > > Actually, the first version I posted treated the return codes from > pm_runtime_get_sync() according to your suggestion above. > > However, Kishon pointed out that it didn't work. That's because, there > are phy provider drivers that enables runtime PM *after* calling > phy_create(). And in those cases, that is because they want to treat > runtime PM themselves. > > I think that's probably something we should look into to change, but I > find it being a separate issue, that I didn't want to investigate as > part of this series. > > See more about the thread here: > https://www.spinics.net/lists/linux-renesas-soc/msg21711.html Even so, it shouldn't matter when the provider enables runtime PM. Calling pm_runtime_get_*()/pm_runtime_put_*() should always work as long as they are balanced properly regardless of whether or not runtime PM is enabled for the device or it is enabled in the meantime. Of course, the initial runtime PM status of the device must reflect the values of the usage counters, but that should not be too hard to ensure. The reason why it matters here is because the phy core tries to be smart about manipulating reference counters by itself and that's a mistake. So it looks to me like the whole thing needs to be reworked and yes, that should be done in the first place IMO, because it will make the issue with genpd go away automatically. [Why is phy_pm_runtime_get() there at all, for instance? It seems to have no users and I kind of don't see use cases for it. Also phy_pm_runtime_get_sync() is only used by the phy core in three places - shouldn't be too hard to fix that.] So the issue with genpd really seems to be a messenger here. :-) Thanks, Rafael
Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14
On Sunday, December 24, 2017 12:49:21 PM CET Pavel Machek wrote: > Hi! > > 4.15-rcX is broken, but that had other problems so lets not go there. > > 4.14 is broken. And what exactly does happen? > 4.12 is ok. > 4.13 is ok. Thanks, Rafael
Re: [linux-sunxi] [PATCH v3] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board
在 2017年12月24日星期日 CST 下午4:02:08，Priit Laes 写道：
> On Sun, Dec 24, 2017 at 01:40:29PM +0800, Icenowy Zheng wrote:
> > Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a form
> > factor and GPIO holes similar to Raspberry Pi Zero.
> >
> > It features:
> > - Allwinner H2+ SoC
> > - Single-chip (16-bit) 512MiB DDR3 DRAM
> > - Ampak AP6212 Wi-Fi/Bluetooth module
> > - MicroSD slot
> > - Two MicroUSB Type-B ports (one can only be used to power the board and
> >
> > the other features OTG functionality)
> >
> > - Two keys, a reset and a GPIO-connected key.
> > - HDMI Type-C (miniHDMI) connector connected to the HDMI part of H2+.
> > - CSI connector to connect the camera sensor provided by Sinovoip.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > Changes in v3:
> > - Add comments about Vbus problem in &usbphy node.
> >
> > Changes in v2:
> > - Use high active SD card detect on the production batch.
> >
> > arch/arm/boot/dts/Makefile | 1 +
> > .../boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts| 162
> > + 2 files changed, 163 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 0bb8db33704a..937a8768671f 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -962,6 +962,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >
> > sun8i-a83t-cubietruck-plus.dtb \
> > sun8i-a83t-tbs-a711.dtb \
> > sun8i-h2-plus-orangepi-r1.dtb \
> >
> > + sun8i-h2-plus-bananapi-m2-zero.dtb \
> >
> > sun8i-h2-plus-orangepi-zero.dtb \
> > sun8i-h3-bananapi-m2-plus.dtb \
> > sun8i-h3-beelink-x2.dtb \
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> > b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts new file mode
> > 100644
> > index ..5bc182ddc5f7
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> > @@ -0,0 +1,162 @@
> > +/*
> > + * Copyright (C) 2017 Icenowy Zheng
> > + *
> > + * Based on sun8i-h3-bananapi-m2-plus.dts, which is:
> > + * Copyright (C) 2016 Chen-Yu Tsai
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This file is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +#include "sun8i-h3.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + model = "Banana Pi BPI-M2-Zero";
> > + compatible = "sinovoip,bpi-m2-zero", "allwinner,sun8i-h2-plus";
> > +
> > + aliases {
> > + serial0 = &uart0;
> > + serial1 = &uart1;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > +
> > + pwr_led {
> > + label = "bananapi-m2-zero:red:pwr";
> > + gpios =
[PATCH] xfs: destroy mutex qi_tree_lock before free xfs_quotainfo_t object
The mutex qi_tree_lock of xfs_quotainfo_t object was initialized when calling xfs_qm_init_quotainfo, but it was not destroyed before free xfs_quotainfo_t object when calling xfs_qm_destroy_quotainfo, this was incorrect, so destroy it in function xfs_qm_destroy_quotainfo. Signed-off-by: Xiongwei Song --- fs/xfs/xfs_qm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c index ec952dfad359..deceef5cbbf3 100644 --- a/fs/xfs/xfs_qm.c +++ b/fs/xfs/xfs_qm.c @@ -737,6 +737,7 @@ xfs_qm_destroy_quotainfo( qi->qi_pquotaip = NULL; } mutex_destroy(&qi->qi_quotaofflock); + mutex_destroy(&qi->qi_tree_lock); kmem_free(qi); mp->m_quotainfo = NULL; } -- 2.15.1
Dobur den na vas
Dobur den na vas,
Moeto ime e Simona Fionda, az byakh glavniyat operativen risk v METRO BANKA
otgovarya sushto i za chastniya upravlenieto na nyakoi nashumeli klienti,
vklyuchitelno trustove, blagotvoritelni organizatsii i pensionni fondove. Az
sum kontakt s vas za Ivan, murtuv klient ot predishniya mi banka, koyato
investira / deponiraneto na osem miliona dvesta khilyadi paunda (8,200,000.00)
s METRO BANKA.
V pregleda na nashiya finansov otchet ot moya otdel otkrikh tazi informatsiya,
koyato e bila skrita ot bankovi direktori, tui? kato umira.
Razbrakh, che imate edno i sushto familno ime s Ivan, koi?to e zashto az sum
kontakt s vas. Imam vsichki originalni dokumenti s men, tui? kato az sum gotov
da dam na vas, za da poluchite tezi pari ot alchnite bankeri, koito iskat da
sieze tezi pari vsichko tova, zashtoto Ivan se zabavi i ne e izvestno chlen ot
semei?stvoto da doi?de po-gore iziskvane, kogato umrya zaedno sus suprugata si
i dushterite v avtomobilna katastrofa prez 2011 godina.
Az sum gotov da spodelya tezi pari 50/50 s vas, ako ste gotovi da mi pomogne.
Bikh posuvetval ot suobrazheniya za bezopasnost i sigurnost, che nie
poddurzhame tazi mnogo POVERITELNO zaradi razmera na zasegnatite pari.
Molya, vurni se pri men vuzmozhno nai?-skoro, ako ste gotovi da otidete
po-dalech. Sushto taka da mi izpratite telefon za vruzka, za da se svurzhat s
vas.
Az shte chakam za vashiya otgovor, predi da znam kak tryabva da se protsedira.
Pozdravi,
Simona Fionda
This message is intended only for use of the person(s) ("the intended
recipient(s)") to whom it is addressed.
It may contain information which is privileged and confidential within the
meaning of applicable law.
If you are not the intended recipient, please contact the sender as soon as
possible.
The views expressed in this communication may not necessarily be the views held
by National Institute of Technology (NIT Manipur).
[GIT PULL] GPIO fixes for v4.15 take three
Hi Linus, 1) Merry christmas! God Jul! 2) Please pull the two fixes below for v4.15 fixes. They are both kind of important, so why not send a pull request on christmas eve. Yours, Linus Walleij The following changes since commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b: Linux 4.15-rc4 (2017-12-17 18:59:59 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v4.15-3 for you to fetch changes up to 822703354774ec935169cbbc8d503236bcb54fda: gpio: fix "gpio-line-names" property retrieval (2017-12-22 15:24:31 +0100) GPIO fixes for v4.15 take three: - Fix a build problem in the gpio single register created by refactorings. - Fix assignment of GPIO line names, something that was mangled by another patch. Christophe Leroy (1): gpio: fix "gpio-line-names" property retrieval Grygorii Strashko (1): gpio: gpio-reg: fix build drivers/gpio/gpio-reg.c| 4 ++-- drivers/gpio/gpiolib-acpi.c| 2 +- drivers/gpio/gpiolib-devprop.c | 17 +++-- drivers/gpio/gpiolib-of.c | 3 ++- drivers/gpio/gpiolib.h | 3 ++- 5 files changed, 14 insertions(+), 15 deletions(-)
[PATCH v2] staging: vc04_services: Prefer WARN_ON_ONCE instead of if condition followed by BUG.
From: Kishore KP Coccinelle suggested to use BUG_ON instead of if condition followed by BUG but BUG_ON should be used in situations where integrity of the system is no longer guaranteed. In this case, as suggested by Stefan Wahren, vchiq isn't critical. Since it is not critical, BUG_ON should be avoided. Replaced if condition followed by BUG with WARN_ON_ONCE. Signed-off-by: Kishore KP Signed-off-by: Suniel Mahesh --- Changes for v2: - Subject and Description modified a bit based on the suggestion by Stefan Wahren. --- Note: - Patch was compile tested and built(ARCH=arm) on linux-next (latest). - No build issues reported. --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c index 315b49c..f20cf88 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c @@ -224,8 +224,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state) platform_state = (struct vchiq_2835_state *)state->platform_state; - if (!platform_state->inited) - BUG(); + WARN_ON_ONCE(!platform_state->inited); return &platform_state->arm_state; } -- 1.9.1
Build regressions/improvements in v4.15-rc5
Below is the list of build error/warning regressions/improvements in v4.15-rc5[1] compared to v4.14[2]. Summarized: - build errors: +3/-6 - build warnings: +1525/-786 JFYI, when comparing v4.15-rc5[1] to v4.15-rc4[3], the summaries are: - build errors: +2/-0 - build warnings: +1013/-779 Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/464e1d5f23cca236b930ef068c328a64cab78fb1/ (all 270 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/bebc6082da0a9f5d47a1ea2edc099bf671058bd4/ (all 270 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/1291a0d5049dbc06baaaf66a9ff3f53db493b19b/ (all 270 configs) *** ERRORS *** 3 error regressions: + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: 'cached_to_uncached' undeclared (first use in this function): => 99:17 + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: implicit declaration of function 'cpu_context' [-Werror=implicit-function-declaration]: => 192:2 + /home/kisskb/slave/src/include/linux/bcma/bcma_driver_pci.h: error: field 'pci_controller' has incomplete type: => 218:24 6 error improvements: - /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: 'per_cpu_secondary_mm' undeclared (first use in this function): 82:10 => - /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: implicit declaration of function 'per_cpu' [-Werror=implicit-function-declaration]: 82:2 => - /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: implicit declaration of function 'smp_processor_id' [-Werror=implicit-function-declaration]: 80:12 => - /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: unknown type name 'per_cpu_secondary_mm': 23:37 => - /home/kisskb/slave/src/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: error: implicit declaration of function 'cmpxchg64' [-Werror=implicit-function-declaration]: 4150:6 => - error: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!: N/A => *** WARNINGS *** [Deleted 676 lines about "warning: ... [-Wpointer-sign]" on parisc-allmodconfig] [Deleted 1201 lines about "warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]" on parisc-allmodconfig] 1525 warning regressions: + /home/kisskb/slave/src/arch/arm/include/asm/spinlock.h: warning: 'ws' may be used uninitialized in this function [-Wuninitialized]: => 110:21 + /home/kisskb/slave/src/arch/mips/kernel/cps-vec.S: Warning: mips32 ISA does not support MT ASE: => 391, 238 + /home/kisskb/slave/src/arch/mips/kernel/cps-vec.S: Warning: the `mt' extension requires MIPS32 revision 2 or greater: => 238 + /home/kisskb/slave/src/arch/x86/entry/vsyscall/vsyscall_64.c: warning: 'syscall_nr' may be used uninitialized in this function [-Wuninitialized]: => 216:16 + /home/kisskb/slave/src/arch/x86/events/amd/ibs.c: warning: 'config' may be used uninitialized in this function [-Wuninitialized]: => 306:11 + /home/kisskb/slave/src/arch/x86/kernel/espfix_64.c: warning: 'rand' may be used uninitialized in this function [-Wuninitialized]: => 118:22 + /home/kisskb/slave/src/arch/x86/kernel/hw_breakpoint.c: warning: 'align' may be used uninitialized in this function [-Wuninitialized]: 361:20 => 361:2, 361:20 + /home/kisskb/slave/src/block/blk-merge.c: warning: 'bbio' may be used uninitialized in this function [-Wuninitialized]: => 285:2 + /home/kisskb/slave/src/block/blk-sysfs.c: warning: 'val' may be used uninitialized in this function [-Wuninitialized]: => 459:21 + /home/kisskb/slave/src/block/bsg.c: warning: 'op' may be used uninitialized in this function [-Wuninitialized]: => 244:2 + /home/kisskb/slave/src/crypto/asymmetric_keys/pkcs7_parser.c: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat]: => 482:2, 617:2 + /home/kisskb/slave/src/crypto/asymmetric_keys/x509_cert_parser.c: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat]: => 175:2 + /home/kisskb/slave/src/crypto/asymmetric_keys/x509_cert_parser.c: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat]: => 244:2 + /home/kisskb/slave/src/crypto/asymmetric_keys/x509_cert_parser.c: warning: format '%zu' expects argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat]: => 175:2 + /home/kisskb/slave/src/drivers/android/binder.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]: => 5504:6 + /home/kisskb/slave/src/drivers/android/binder_alloc.c: warning: 'buffer' may be used uninitialized in this function [-Wuninitialized]: => 433:30 + /home/kisskb/slave/src/drivers/android/binder_alloc.c: warning: 'buffer_size' may be used uninitialized in this function [-Wuninitialized]: => 434:2 + /home/kisskb/slave
Re: Build regressions/improvements in v4.15-rc5
On Sun, Dec 24, 2017 at 3:40 PM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.15-rc5[1] to v4.15-rc4[3], the summaries are:
> - build errors: +2/-0
sh/randconfig noise
> [1]
> http://kisskb.ellerman.id.au/kisskb/head/464e1d5f23cca236b930ef068c328a64cab78fb1/
> (all 270 configs)
> [3]
> http://kisskb.ellerman.id.au/kisskb/head/1291a0d5049dbc06baaaf66a9ff3f53db493b19b/
> (all 270 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14
On Sun 2017-12-24 13:04:31, Rafael J. Wysocki wrote: > On Sunday, December 24, 2017 12:49:21 PM CET Pavel Machek wrote: > > Hi! > > > > 4.15-rcX is broken, but that had other problems so lets not go there. > > > > 4.14 is broken. > > And what exactly does happen? Suspend looks ok. I believe there's some reaction to power button, but screen stays blank. I'll re-check that.. I'm in the middle of bisect now. Is there something in 4.14.X I should try? > > 4.12 is ok. > > 4.13 is ok. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14
On Sun 2017-12-24 16:22:32, Pavel Machek wrote: > On Sun 2017-12-24 13:04:31, Rafael J. Wysocki wrote: > > On Sunday, December 24, 2017 12:49:21 PM CET Pavel Machek wrote: > > > Hi! > > > > > > 4.15-rcX is broken, but that had other problems so lets not go there. > > > > > > 4.14 is broken. > > > > And what exactly does happen? > > Suspend looks ok. I believe there's some reaction to power button, but > screen stays blank. I'll re-check that.. I'm in the middle of bisect > now. Ok, so suspend looks ok. On resume, "moon" LED goes off and power / bluetooth LEDs go on, but screen is black and no response to anything. # bad: [eb3b451f8b5a6eb0ebe09ff0f79937977f985a36] Configuration for final v4.14 # good: [9fd3408ca15f4018466e87255ab2644f54de1c1c] "Definitely say Y... so it should be default." git bisect start 'my-v4.14' 'my-v4.13' # good: [088eb54dfadd2cdaeb50969fadda4ecfd8d490c2] Date: Wed, 6 Sep 2017 09:03:47 +0300 From: Adrian Hunter To: Shawn Lin , Pavel Machek , linux-...@vger.kernel.org Cc: kernel list , Seraphime Kirkovski Subject: Re: 4.13 on thinkpad x220: oops when writing to SD card git bisect good 088eb54dfadd2cdaeb50969fadda4ecfd8d490c2 # good: [15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect good 15d8ffc96464f6571ecf22043c45fad659f11bdd # good: [e90937e756938f03d37d4cae7c82316a3a425944] Merge tag 'armsoc-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good e90937e756938f03d37d4cae7c82316a3a425944 (next one is bad). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] gpio: gpio-reg: fix build
Hi Grygorii,
On Wed, Dec 6, 2017 at 6:37 PM, Grygorii Strashko
wrote:
> Revert changes introduced by commit f0fbe7bce733 ("gpio: Move irqdomain
> into struct gpio_irq_chip") as they are not aplicable to this driver.
>
> Cc: Russell King - ARM Linux
> Fixes: f0fbe7bce733 ("gpio: Move irqdomain into struct gpio_irq_chip")
> Signed-off-by: Grygorii Strashko
> ---
> Sorry, for inconvenience, but this driver has no users in lkml and
> it can't be enabled through defconfig - only selected, so builds can't
> be verified in standard way.
Seems like we need:
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -392,7 +392,7 @@ config GPIO_RCAR
Say yes here to support GPIO on Renesas R-Car SoCs.
config GPIO_REG
- bool
+ bool "32-bit single register GPIO fixed in/out support" if COMPILE_TEST
help
A 32-bit single register GPIO fixed in/out implementation. This
can be used to represent any register as a set of GPIO signals.
Any dependencies to be added?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] gpio: gpio-reg: fix build
On Sun, Dec 24, 2017 at 04:49:39PM +0100, Geert Uytterhoeven wrote:
> Hi Grygorii,
>
> On Wed, Dec 6, 2017 at 6:37 PM, Grygorii Strashko
> wrote:
> > Revert changes introduced by commit f0fbe7bce733 ("gpio: Move irqdomain
> > into struct gpio_irq_chip") as they are not aplicable to this driver.
> >
> > Cc: Russell King - ARM Linux
> > Fixes: f0fbe7bce733 ("gpio: Move irqdomain into struct gpio_irq_chip")
> > Signed-off-by: Grygorii Strashko
> > ---
> > Sorry, for inconvenience, but this driver has no users in lkml and
> > it can't be enabled through defconfig - only selected, so builds can't
> > be verified in standard way.
>
> Seems like we need:
>
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -392,7 +392,7 @@ config GPIO_RCAR
> Say yes here to support GPIO on Renesas R-Car SoCs.
>
> config GPIO_REG
> - bool
> + bool "32-bit single register GPIO fixed in/out support" if
> COMPILE_TEST
> help
> A 32-bit single register GPIO fixed in/out implementation. This
> can be used to represent any register as a set of GPIO signals.
>
> Any dependencies to be added?
No need, once some patches go in, this will be selected and then it'll
get build coverage.
But the main thing is, this needs to be fixed - it's been causing build
errors for those of us carrying patches to use it, and thereby destroying
the usefulness of nightly testing.
http://www.home.armlinux.org.uk/developer/build/index.php?id=2002
http://www.home.armlinux.org.uk/developer/build/index.php?id=2004
Can we please get the fix into -rc? Keeping the _regression_ _fix_ out
of -rc not only means that we're stuck with these build failures, but
also means that we create bisect problems for the next merge window.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Sat, Dec 23, 2017 at 09:33:37PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Dec 2017, vcap...@pengaru.com wrote:
> > On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote:
> > Added the following instrumentation:
> >
> > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> > index 93edc2236282..7034eda4d494 100644
> > --- a/arch/x86/kernel/apic/vector.c
> > +++ b/arch/x86/kernel/apic/vector.c
> > @@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct
> > apic_chip_data *d,
> > cpumask_and(vector_searchmask, vector_searchmask, mask);
> > BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata,
> > &d->cfg.dest_apicid));
> > +
> > + printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector,
> > cpumask_first(vector_searchmask));
> > +
> > return 0;
> > }
> >
> > This is what I see:
> >
> > Upon playing song in cmus (on AC power since boot):
> > Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1
> >
> > Yank AC:
> > Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1
> > Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector
> >
> > So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in
> > the added printk.
> >
> > It seems like the affinity changes are assuming a strict adherence to
> > the CPU mask when the underlying hardware is treating it more as a hint.
> > Perhaps handlers still need to be maintained on all CPUs in a given apic
> > domain, regardless of what the masks are configured as, to cover these
> > situations.
>
> That's odd. I'll have a look after the holidays.
>
Ok, just FYI I've reproduced it on rc5 as well.
I may be offline a bit at the start of the new year, in case you've got
something for me to test and I'm unresponsive.
Regards,
Vito Caputo
[PATCH] vhost: remove unused lock check flag in vhost_dev_cleanup()
In commit ea5d404655ba ("vhost: fix release path lockdep checks"),
Michael added a flag to check whether we should hold a lock in
vhost_dev_cleanup(), however, in commit 47283bef7ed3 ("vhost: move
memory pointer to VQs"), RCU operations have been replaced by
mutex, we can remove the no-longer-used `locked' parameter now.
Signed-off-by: Caspar Zhang
---
drivers/vhost/net.c | 2 +-
drivers/vhost/scsi.c | 2 +-
drivers/vhost/test.c | 2 +-
drivers/vhost/vhost.c | 5 ++---
drivers/vhost/vhost.h | 2 +-
drivers/vhost/vsock.c | 2 +-
6 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index c7bdeb655646..a354d8d731e3 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -996,7 +996,7 @@ static int vhost_net_release(struct inode *inode, struct
file *f)
vhost_net_stop(n, &tx_sock, &rx_sock);
vhost_net_flush(n);
vhost_dev_stop(&n->dev);
- vhost_dev_cleanup(&n->dev, false);
+ vhost_dev_cleanup(&n->dev);
vhost_net_vq_reset(n);
if (tx_sock)
sockfd_put(tx_sock);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 71517b3c5558..797d08916553 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1420,7 +1420,7 @@ static int vhost_scsi_release(struct inode *inode, struct
file *f)
mutex_unlock(&vs->dev.mutex);
vhost_scsi_clear_endpoint(vs, &t);
vhost_dev_stop(&vs->dev);
- vhost_dev_cleanup(&vs->dev, false);
+ vhost_dev_cleanup(&vs->dev);
/* Jobs can re-queue themselves in evt kick handler. Do extra flush. */
vhost_scsi_flush(vs);
kfree(vs->dev.vqs);
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 3cc98c07dcd3..906b8f0f19f7 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -157,7 +157,7 @@ static int vhost_test_release(struct inode *inode, struct
file *f)
vhost_test_stop(n, &private);
vhost_test_flush(n);
- vhost_dev_cleanup(&n->dev, false);
+ vhost_dev_cleanup(&n->dev);
/* We do an extra flush before freeing memory,
* since jobs can re-queue themselves. */
vhost_test_flush(n);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 33ac2b186b85..014675c3d569 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -544,7 +544,7 @@ void vhost_dev_reset_owner(struct vhost_dev *dev, struct
vhost_umem *umem)
{
int i;
- vhost_dev_cleanup(dev, true);
+ vhost_dev_cleanup(dev);
/* Restore memory to default empty mapping. */
INIT_LIST_HEAD(&umem->umem_list);
@@ -611,8 +611,7 @@ static void vhost_clear_msg(struct vhost_dev *dev)
spin_unlock(&dev->iotlb_lock);
}
-/* Caller should have device mutex if and only if locked is set */
-void vhost_dev_cleanup(struct vhost_dev *dev, bool locked)
+void vhost_dev_cleanup(struct vhost_dev *dev)
{
int i;
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 79c6e7a60a5e..ff4d918e3e0a 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -181,7 +181,7 @@ bool vhost_dev_has_owner(struct vhost_dev *dev);
long vhost_dev_check_owner(struct vhost_dev *);
struct vhost_umem *vhost_dev_reset_owner_prepare(void);
void vhost_dev_reset_owner(struct vhost_dev *, struct vhost_umem *);
-void vhost_dev_cleanup(struct vhost_dev *, bool locked);
+void vhost_dev_cleanup(struct vhost_dev *);
void vhost_dev_stop(struct vhost_dev *);
long vhost_dev_ioctl(struct vhost_dev *, unsigned int ioctl, void __user
*argp);
long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp);
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 5a5e981bd8e4..0d14e2ff19f1 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -599,7 +599,7 @@ static int vhost_vsock_dev_release(struct inode *inode,
struct file *file)
}
spin_unlock_bh(&vsock->send_pkt_list_lock);
- vhost_dev_cleanup(&vsock->dev, false);
+ vhost_dev_cleanup(&vsock->dev);
kfree(vsock->dev.vqs);
vhost_vsock_free(vsock);
return 0;
--
2.15.1
Re: [PATCH 4.4 00/78] 4.4.108-stable review
On 12/23/2017 11:43 PM, Greg Kroah-Hartman wrote: On Sat, Dec 23, 2017 at 05:30:42PM -0800, Guenter Roeck wrote: On 12/22/2017 12:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.108 release. There are 78 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Dec 24 08:45:30 UTC 2017. Anything received after that time might be too late. For v4.4.107-79-g0989207: Build results: total: 145 pass: 144 fail: 1 Failed builds: alpha:allmodconfig Qemu test results: total: 118 pass: 118 fail: 0 The alpha fix is missing from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git branch linux-4.4.y; it points to the same sha. Ah, I only updated my quilt tree, sorry about that, let me go push this out now... This is better. For v4.4.107-79-ge483f58: Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 118 pass: 118 fail: 0 Guenter
Re: [PATCH] ARM: make ARCH_S3C24XX select USE_OF and clean-up boot/dts/Makefile
2017-12-22 21:41 GMT+09:00 Krzysztof Kozlowski : > On Mon, Nov 27, 2017 at 3:19 AM, Masahiro Yamada > wrote: >> ARCH_S3C24XX is a very exceptional platform that some DT files in >> arch/arm/boot/dts/, but does not select USE_OF. > > Not entirely. The platform does select USE_OF - when MACH_S3C2416_DT > is chosen. For other boards USE_OF is not necessary because they do > not use DT. Why you need to select it for entire arch? > > Best regards, > Krzysztof > The reason is simple - to avoid compile error. If I simply drop ifeq ($(CONFIG_OF),y) but do not select ARCH_S3C24XX, s3c2410_defconfig failed to build. $ make -s ARCH=arm mrproper $ make -s ARCH=arm s3c2410_defconfig $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs ... DTC arch/arm/boot/dts/s3c2416-smdk2416.dtb /bin/sh: 1: ./scripts/dtc/dtc: not found scripts/Makefile.lib:310: recipe for target 'arch/arm/boot/dts/s3c2416-smdk2416.dtb' failed make[1]: *** [arch/arm/boot/dts/s3c2416-smdk2416.dtb] Error 127 arch/arm/Makefile:349: recipe for target 'dtbs' failed make: *** [dtbs] Error 2 Another solution would be to enable dtb by CONFIG_MACH_S3C2416_DT. diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index d0381e9..950b5dd 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -800,7 +798,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-veyron-pinky.dtb \ rk3288-veyron-speedy.dtb \ rk3288-vyasa.dtb -dtb-$(CONFIG_ARCH_S3C24XX) += \ +dtb-$(CONFIG_MACH_S3C2416_DT) += \ s3c2416-smdk2416.dtb dtb-$(CONFIG_ARCH_S3C64XX) += \ s3c6410-mini6410.dtb \ If you migrate S3C24XX platform to DT, per-board CONFIG option will go away. So, I think dtb-$(CONFIG_ARCH_S3C24XX) is OK. >> All the other platforms with DT files correctly select USE_OF >> directly or indirectly (Most of them are either ARCH_MULTIPLATFORM >> or ARM_SINGLE_ARMV7M). >> >> With ARCH_S3C24XX fixed, "ifeq ($(CONFIG_OF),y)" in DT Makefile >> can be deleted. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> arch/arm/Kconfig | 1 + >> arch/arm/boot/dts/Makefile | 3 --- >> 2 files changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 51c8df5..5604497 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -595,6 +595,7 @@ config ARCH_S3C24XX >> select MULTI_IRQ_HANDLER >> select NEED_MACH_IO_H >> select SAMSUNG_ATAGS >> + select USE_OF >> help >> Samsung S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, >> S3C2443 >> and S3C2450 SoCs based systems, such as the Simtec Electronics BAST >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index d0381e9..6f7f25d 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -1,6 +1,4 @@ >> # SPDX-License-Identifier: GPL-2.0 >> -ifeq ($(CONFIG_OF),y) >> - >> dtb-$(CONFIG_ARCH_ALPINE) += \ >> alpine-db.dtb >> dtb-$(CONFIG_MACH_ARTPEC6) += \ >> @@ -1104,4 +1102,3 @@ dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb >> dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \ >> aspeed-bmc-opp-romulus.dtb \ >> aspeed-ast2500-evb.dtb >> -endif >> -- >> 2.7.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH] gpio: gpio-reg: fix build
On Sun, Dec 24, 2017 at 4:56 PM, Russell King - ARM Linux wrote: > But the main thing is, this needs to be fixed - it's been causing build > errors for those of us carrying patches to use it, and thereby destroying > the usefulness of nightly testing. I'm sorry, it's my fault for not being swift enough. :( I sent a combined seasonal greetings and pull request to Torvalds this morning. Yours, Linus Walleij
Re: [PATCH 11/11] ARM: pxa: constify gpio_led
Hi Arvind,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm-soc/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Arvind-Yadav/constify-gpio_led/20171223-142117
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-pxa_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
>> arch/arm/mach-pxa/balloon3.c:390:8: error: expected '{' before 'const'
struct const gpio_led balloon3_gpio_leds[] __initconst = {
^
>> arch/arm/mach-pxa/balloon3.c:405:11: error: 'balloon3_gpio_leds' undeclared
>> here (not in a function); did you mean 'balloon3_gpio_led_info'?
.leds = balloon3_gpio_leds,
^~
balloon3_gpio_led_info
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/platform_device.h:14,
from arch/arm/mach-pxa/balloon3.c:18:
>> include/linux/build_bug.h:30:45: error: bit-field '' width not an
>> integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
include/linux/compiler-gcc.h:65:28: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/kernel.h:71:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^~~
>> arch/arm/mach-pxa/balloon3.c:406:14: note: in expansion of macro 'ARRAY_SIZE'
.num_leds = ARRAY_SIZE(balloon3_gpio_leds),
^~
--
>> arch/arm/mach-pxa/palmld.c:249:8: error: expected '{' before 'const'
struct const gpio_led gpio_leds[] __initconst = {
^
>> arch/arm/mach-pxa/palmld.c:262:11: error: 'gpio_leds' undeclared here (not
>> in a function); did you mean 'gpio_led'?
.leds = gpio_leds,
^
gpio_led
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/platform_device.h:14,
from arch/arm/mach-pxa/palmld.c:17:
>> include/linux/build_bug.h:30:45: error: bit-field '' width not an
>> integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
include/linux/compiler-gcc.h:65:28: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/kernel.h:71:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^~~
>> arch/arm/mach-pxa/palmld.c:263:14: note: in expansion of macro 'ARRAY_SIZE'
.num_leds = ARRAY_SIZE(gpio_leds),
^~
vim +390 arch/arm/mach-pxa/balloon3.c
389
> 390 struct const gpio_led balloon3_gpio_leds[] __initconst = {
391 {
392 .name = "balloon3:green:idle",
393 .default_trigger= "heartbeat",
394 .gpio = BALLOON3_GPIO_LED_IDLE,
395 .active_low = 1,
396 }, {
397 .name = "balloon3:green:nand",
398 .default_trigger= "nand-disk",
399 .gpio = BALLOON3_GPIO_LED_NAND,
400 .active_low = 1,
401 },
402 };
403
404 static struct gpio_led_platform_data balloon3_gpio_led_info = {
> 405 .leds = balloon3_gpio_leds,
> 406 .num_leds = ARRAY_SIZE(balloon3_gpio_leds),
407 };
408
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] gpio: gpio-reg: fix build
On Sun, Dec 24, 2017 at 06:44:07PM +0100, Linus Walleij wrote: > On Sun, Dec 24, 2017 at 4:56 PM, Russell King - ARM Linux > wrote: > > > But the main thing is, this needs to be fixed - it's been causing build > > errors for those of us carrying patches to use it, and thereby destroying > > the usefulness of nightly testing. > > I'm sorry, it's my fault for not being swift enough. :( > > I sent a combined seasonal greetings and pull request to > Torvalds this morning. Thanks, and Seasons Greetings to you! -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
[PATCH] x86: xen: remove the use of VLAIS
Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
frowned upon by others.
https://lkml.org/lkml/2013/9/23/500
Here, the VLAIS was used because the size of the bitmap returned from
xen_mc_entry() depended on possibly (based on kernel configuration)
runtime sized data. Rather than declaring args as a VLAIS then calling
sizeof on *args, we can define the variable length array (mask) to be a
pointer, and calculate the appropriate sizeof args manually. Further, we
can get rid of the #ifdef's and rely on num_possible_cpus() (thanks to a
helpful checkpatch warning from an earlier version of this patch).
Signed-off-by: Nick Desaulniers
---
arch/x86/xen/mmu_pv.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 4d62c07..966976c 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1325,20 +1325,18 @@ static void xen_flush_tlb_others(const struct cpumask
*cpus,
{
struct {
struct mmuext_op op;
-#ifdef CONFIG_SMP
- DECLARE_BITMAP(mask, num_processors);
-#else
- DECLARE_BITMAP(mask, NR_CPUS);
-#endif
+ unsigned long *mask;
} *args;
struct multicall_space mcs;
+ const size_t mc_entry_size = sizeof(args->op) +
+ sizeof(*args->mask) * BITS_TO_LONGS(num_possible_cpus());
trace_xen_mmu_flush_tlb_others(cpus, info->mm, info->start, info->end);
if (cpumask_empty(cpus))
return; /* nothing to do */
- mcs = xen_mc_entry(sizeof(*args));
+ mcs = xen_mc_entry(mc_entry_size);
args = mcs.args;
args->op.arg2.vcpumask = to_cpumask(args->mask);
--
2.7.4
[regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14
Hi! > > > > 4.15-rcX is broken, but that had other problems so lets not go there. > > > > > > > > 4.14 is broken. > > > > > > And what exactly does happen? > > > > Suspend looks ok. I believe there's some reaction to power button, but > > screen stays blank. I'll re-check that.. I'm in the middle of bisect > > now. > > Ok, so suspend looks ok. On resume, "moon" LED goes off and power / > bluetooth LEDs go on, but screen is black and no response to > > > > anything. And it seems bad commit is commit 5620a0d1aacd554ebebcff373e31107bb1ef7769 Author: Greg Kroah-Hartman Date: Thu Sep 14 14:23:01 2017 -0700 firmware: delete in-kernel firmware Unfortuantely, it does not revert cleanly. lspavel@hobit:~$ lspci 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] (rev 02) 02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Ethernet controller: Qualcomm Atheros AR5211 Wireless Network Adapter [AR5001X 802.11ab] (rev 01) pavel@hobit:~$ 5620a0d1aacd554ebebcff373e31107bb1ef7769 contains: firmware/radeon/R200_cp.bin.ihex| 130 ..maybe that's the reason? Pavel # bad: [eb3b451f8b5a6eb0ebe09ff0f79937977f985a36] Configuration for final v4.14 # good: [9fd3408ca15f4018466e87255ab2644f54de1c1c] "Definitely say Y... so it should be default." git bisect start 'my-v4.14' 'my-v4.13' # good: [088eb54dfadd2cdaeb50969fadda4ecfd8d490c2] Date: Wed, 6 Sep 2017 09:03:47 +0300 From: Adrian Hunter To: Shawn Lin , Pavel Machek , linux-...@vger.kernel.org Cc: kernel list , Seraphime Kirkovski Subject: Re: 4.13 on thinkpad x220: oops when writing to SD card git bisect good 088eb54dfadd2cdaeb50969fadda4ecfd8d490c2 # good: [15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect good 15d8ffc96464f6571ecf22043c45fad659f11bdd # good: [e90937e756938f03d37d4cae7c82316a3a425944] Merge tag 'armsoc-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good e90937e756938f03d37d4cae7c82316a3a425944 # bad: [93b5533ab58d635968ebb0939fe90f3b022601af] Merge tag 'pci-v4.14-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci git bisect bad 93b5533ab58d635968ebb0939fe90f3b022601af # bad: [9db59599ae502b38b27cff6462273f84acd59927] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect bad 9db59599ae502b38b27cff6462273f84acd59927 # good: [561a8eb3e1d219f415597c76dae44b530b7f961a] Merge tag 'rtc-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux git bisect good 561a8eb3e1d219f415597c76dae44b530b7f961a # good: [939ae58960bb5ce0c51776aec38877a401c03bcf] Merge git://www.linux-watchdog.org/linux-watchdog git bisect good 939ae58960bb5ce0c51776aec38877a401c03bcf # good: [e7cdb60fd28b252f1c15a0e50f79a01906124915] Merge branch 'zstd-minimal' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs git bisect good e7cdb60fd28b252f1c15a0e50f79a01906124915 # good: [9e0ce554b039e3df288d83189ecf226c16da04af] Merge branch 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect good 9e0ce554b039e3df288d83189ecf226c16da04af # good: [4c0b4bc60f95de4741c89b41174760258343f091] kvm,mips: Fix potential swait_active() races git bisect good 4c0b4bc60f95de4741c89b41174760258343f091 # good: [30db202e54d251e4887935f7b4538b44911bb091] Merge tag 'for-linus-4.14-ofs2' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/l
Re: [PATCH/RFC] perf report: Add option to change offset format when address is specified as a sort_key
On Sat 2017-12-23 00:59 +0100, Jiri Olsa wrote: [ ... ] > not sure we've already discussed that, but this could be default? Probably it is best to keep the default behaviour. I'd prefer a hexadecimal address offset, as the default, however perhaps someone is happy with the current default (decimal). > if not, I think the hex option should be part of -g option arg, maybe like: Does it have to be? > -g graph,callee,xaddress Not sure - adding another sort_key seems odd to me. But if you insist, perhaps address[=hex] would be cleaner? Otherwise I would prefer --hex. Regards, -- Aaron Tomlin signature.asc Description: PGP signature
Re: [PATCH v5] leds: trigger: Introduce a NETDEV trigger
On Sun 2017-12-10 21:17:55, Ben Whitten wrote: > This commit introduces a NETDEV trigger for named device > activity. Available triggers are link, rx, and tx. > > Signed-off-by: Ben Whitten Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] iio: adc: add driver for ti adc081s/adc101s/adc121s
On 12/23/2017 03:13 PM, Philippe Ombredanne wrote:
Milan,
On Sat, Dec 23, 2017 at 12:19 AM, Milan Stevanovic
wrote:
Signed-off-by: Milan Stevanovic
May be it is just me, but you may be missing a commit message?
Yes... Sorry I missed this
--- /dev/null
+++ b/drivers/iio/adc/ti-adc081s.c
@@ -0,0 +1,239 @@
+/*
+ * TI ADC081S/ADC101S/ADC121S 8/10/12-bit ADC driver
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
Could you consider using an SPDX tag here as documented by Thomas in
this patch set [1] ?
This is the new thing for this end of of year and a must have for 2018!
[1] https://lkml.org/lkml/2017/12/4/934
Thanks for this... I added it...
Best regards
Milan
From 039f53aa702bd524e53c61b0365d048e2624ef02 Mon Sep 17 00:00:00 2001
From: Milan Stevanovic
Date: Sat, 23 Dec 2017 00:06:32 +0100
Subject: [PATCH v2] iio: adc: add driver for ti adc081s/adc101s/adc121s
Linux device driver for single-channel CMOS
8/10/12-bit analog-to-digital converter with a
high-speed serial interface.
Signed-off-by: Milan Stevanovic
Changes in v2:
- Add SPDX tag
- Add correct git commit message
---
drivers/iio/adc/Kconfig | 10 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ti-adc081s.c | 242 +++
3 files changed, 253 insertions(+)
create mode 100644 drivers/iio/adc/ti-adc081s.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ef86296..208238f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -701,6 +701,16 @@ config TI_ADC081C
This driver can also be built as a module. If so, the module will be
called ti-adc081c.
+config TI_ADC081S
+ tristate "Texas Instruments ADC081S/ADC101S/ADC121S family"
+ depends on SPI
+ help
+ If you say yes here you get support for Texas Instruments ADC081S,
+ ADC chips.
+
+ This driver can also be built as a module. If so, the module will be
+ called ti-adc081s.
+
config TI_ADC0832
tristate "Texas Instruments ADC0831/ADC0832/ADC0834/ADC0838"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9572c10..020fecf 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
obj-$(CONFIG_STM32_ADC) += stm32-adc.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
+obj-$(CONFIG_TI_ADC081S) += ti-adc081s.o
obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
obj-$(CONFIG_TI_ADC084S021) += ti-adc084s021.o
obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
diff --git a/drivers/iio/adc/ti-adc081s.c b/drivers/iio/adc/ti-adc081s.c
new file mode 100644
index 000..a69abce
--- /dev/null
+++ b/drivers/iio/adc/ti-adc081s.c
@@ -0,0 +1,242 @@
+/*
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ *
+ * TI ADC081S/ADC101S/ADC121S 8/10/12-bit ADC driver
+ *
+ * Linux device driver for single-channel CMOS
+ * 8/10/12-bit analog-to-digital converter with a
+ * high-speed serial interface.
+ *
+ * Datasheets:
+ * http://www.ti.com/lit/ds/symlink/adc081s021.pdf
+ * http://www.ti.com/lit/ds/symlink/adc101s021.pdf
+ * http://www.ti.com/lit/ds/symlink/adc121s021.pdf
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct adc081s {
+ struct spi_device *spi;
+ struct regulator *reg;
+ struct mutex lock;
+
+ /* 8, 10 or 12 */
+ int bits;
+};
+
+static int adc081s_read_raw(struct iio_dev *iio,
+ struct iio_chan_spec const *channel, int *value,
+ int *shift, long mask)
+{
+ struct adc081s *adc = iio_priv(iio);
+ int ret;
+ __be16 buf;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ mutex_lock(&adc->lock);
+ ret = spi_read(adc->spi, (void *) &buf, 2);
+ mutex_unlock(&adc->lock);
+ if (ret)
+ return ret;
+ *value = (be16_to_cpu(buf) & 0x0FFF) >> (12 - adc->bits);
+ *value = sign_extend32(*value, channel->scan_type.realbits - 1);
+
+ return IIO_VAL_INT;
+
+ case IIO_CHAN_INFO_SCALE:
+ *value = regulator_get_voltage(adc->reg);
+ if (*value < 0)
+ return *value;
+
+ /* convert regulator output voltage to mV */
+ *value /= 1000;
+ *shift = adc->bits;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+#define ADCxx1S_CHAN(_bits) { \
+ .type = IIO_VOLTAGE,\
+ .info_mask_shared_by_
Re: [PATCH 4.14 000/159] 4.14.9-stable review
On Fri, Dec 22, 2017 at 8:44 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.9 release. > There are 159 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Dec 24 08:45:36 UTC 2017. > Anything received after that time might be too late. > > Josh Poimboeuf > x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit This is uncovering a very difficult-to-debug build failure with NVIDIA DKMS: with CONFIG_UNWINDER_ORC=y, out-of-tree modules hit this rule in scripts/Makefile.build: $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE and fail (here, at least) to build tools/objtool/objtool (note: I do have libelf-dev installed) After editing dkms.conf to do `make --debug=a -j1`, I see make output: Considering target file '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'. File '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o' does not exist. Looking for an implicit rule for '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'. [...] Trying rule prerequisite 'tools/objtool/objtool'. Looking for a rule with intermediate file 'tools/objtool/objtool'. Avoiding implicit rule recursion. then silently fail to build objtool, silently fail to build all the .o files, then continue until ld finally errors out trying to link nonexistent object files. If things look alright to you, and objtool is known to work with out-of-tree modules, and the Debian packaging just needs to be adjusted, please ignore; I figured I'd send this anyway because it was such a pain to debug. Thanks, Ivan On Fri, Dec 22, 2017 at 8:44 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.9 release. > There are 159 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Dec 24 08:45:36 UTC 2017. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 4.14.9-rc1 > > Peter Hutterer > platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state > changes > > Daniel Lezcano > thermal/drivers/hisi: Fix multiple alarm interrupts firing > > Daniel Lezcano > thermal/drivers/hisi: Simplify the temperature/step computation > > Daniel Lezcano > thermal/drivers/hisi: Fix kernel panic on alarm interrupt > > Daniel Lezcano > thermal/drivers/hisi: Fix missing interrupt enablement > > Niranjana Vishwanathapura > IB/opa_vnic: Properly return the total MACs in UC MAC list > > Scott Franco > IB/opa_vnic: Properly clear Mac Table Digest > > Eric Anholt > drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math. > > Nicholas Piggin > cpuidle: fix broadcast control when broadcast can not be entered > > Alexandre Belloni > rtc: set the alarm to the next expiring timer > > Hoang Tran > tcp: fix under-evaluated ssthresh in TCP Vegas > > Chen-Yu Tsai > clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision > > Arvind Yadav > staging: greybus: light: Release memory obtained by kasprintf > > Wei Hu(Xavier) > RDMA/hns: Avoid NULL pointer exception > > Mike Manning > net: ipv6: send NS for DAD when link operationally up > > Mick Tarsel > ibmvnic: Set state UP > > Jacob Keller > fm10k: ensure we process SM mbx when processing VF mbx > > Marek Szyprowski > ARM: exynos_defconfig: Enable UAS support for Odroid HC1 board > > Alex Williamson > vfio/pci: Virtualize Maximum Payload Size > > Alan Brady > i40e: fix client notify of VF reset > > Dick Kennedy > scsi: lpfc: Fix warning messages when NVME_TARGET_FC not defined > > Dick Kennedy > scsi: lpfc: PLOGI failures during NPIV testing > > Dick Kennedy > scsi: lpfc: Fix secure firmware updates > > Jacob Keller > fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw > > Nicolas Dechesne > ASoC: codecs: msm8916-wcd-analog: fix module autoload > > Marcelo Ricardo Leitner > sctp: silence warns on sctp_stream_init allocations > > Nicholas Piggin > powerpc/watchdog: Do not trigger SMP crash from touch_nmi_watchdog > > Nicholas Piggin > powerpc/xmon: Avoid tripping SMP hardlockup watchdog > > Ed Blake > ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback > > Jean-François Têtu > ASoC: codecs: msm8916-wcd-analog: fix m
Re: [PATCH v6 0/2] Fix corner cases with disabling CLKRUN in tpm_tis
On Fri, Dec 22, 2017 at 12:13:42PM -0800, Azhar Shaikh wrote: > Changes from v1: > - Patch 1: "tpm: Keep CLKRUN enabled throughout the duration of > transmit_cmd()" > - Add NULL checks before calling clk_toggle callback > - Use IS_ENABLED instead of ifdef in tpm_tis_clkrun_toggle() > - Do not call tpm_platform_begin_xfer() and tpm_platform_end_xfer() > from tpm_tis_clkrun_toggle(). Make them static again. > > - Patch 2: "tpm_tis: Move ilb_base_addr to tpm_tis_tcg_phy" > - This is a new patch in this series as per suggestion from Jason. > - Is the current implementation ok or I should move the code in > tpm_tis_pnp_remove() > and tpm_tis_plat_remove() inside tpm_tis_remove(). That way all the > unmapping > can be done in one place, instead of 3 different places now. Also the > unmapping > in tpm_tis_init() can be moved to tpm_tis_remove(), since in case of error > tpm_tis_core_init() calls tpm_tis_remove(). Kindly suggest. > > Changes from v2: > - Patch 1: "tpm: Keep CLKRUN enabled throughout the duration of > transmit_cmd()" > - No changes > > - Patch 2: "tpm_tis: Move ilb_base_addr to tpm_tis_tcg_phy" > - Updated is_bsw() function to have the #ifdef CONFIG_X86 check within the > function > itself. Also removed the #ifdef CONFIG_X86 from all other places around > is_bsw() > > Changes from v3: > - Patch 1: "tpm: Keep CLKRUN enabled throughout the duration of > transmit_cmd()" > - Change function name from clk_toggle to clk_enable > - Update the commit message. > > - Patch 2: "tpm_tis: Move ilb_base_addr to tpm_tis_tcg_phy" > - No changes > > Changes from v4: > - The numbering of patches is now interchanged. > > - Patch 1: "tpm_tis: Move ilb_base_addr to tpm_tis_data" > - Had to move ilb_base_addr to tpm_tis_data, from tpm_tis_tcg_phy. > Since the ioremapping of ilb_base_addr had to be done before any TPM > access, > hence moved the variable to tpm_tis_data. > - Also move the ioremapping of ilb_base_addr from tpm_tis_init() to > tpm_tis_core_init() i.e. before any TPM access is done. > - Rename marco LPC_CNTRL_REG_OFFSET to LPC_CNTRL_OFFSET > - Update the commit message. > > - Patch 2: "tpm: Keep CLKRUN enabled throughout the duration of > transmit_cmd()" > - Remove the functions tpm_platform_begin_xfer() and tpm_platform_end_xfer() > - Move the code from these functions to tpm_tis_clkrun_enable(). > > Changes from v5: > - Patch 1: "tpm_tis: Move ilb_base_addr to tpm_tis_data" > - No changes > > - Patch 2: "tpm: Keep CLKRUN enabled throughout the duration of > transmit_cmd()" > - Update the commit message. > > Changes from v6: > - - Patch 1: "tpm_tis: Move ilb_base_addr to tpm_tis_data" > - No changes > > - Patch 2: "tpm: Keep CLKRUN enabled throughout the duration of > transmit_cmd()" > - chip->ops was set to NULL in tpm_del_char_device() called from > tpm_chip_unregister() in > error/driver exit path. Fix this code. (Suggested by Javier Martinez > Canillas and Jason Gunthorpe) > - Add a comment in tpm_tis_clkrun_enable() function. > > Azhar Shaikh (2): > tpm_tis: Move ilb_base_addr to tpm_tis_data > tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd() > > drivers/char/tpm/tpm-interface.c | 6 ++ > drivers/char/tpm/tpm_tis.c | 121 > ++- > drivers/char/tpm/tpm_tis_core.c | 111 +-- > drivers/char/tpm/tpm_tis_core.h | 17 ++ > include/linux/tpm.h | 1 + > 5 files changed, 147 insertions(+), 109 deletions(-) > > -- > 1.9.1 > Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen (with SPI TPM on Sandybridge machine) /Jarkko
[PATCH v10 0/7] Intel SGX Driver
Intel(R) SGX is a set of CPU instructions that can be used by applications to set aside private regions of code and data. The code outside the enclave is disallowed to access the memory inside the enclave by the CPU access control. In a way you can think that SGX provides inverted sandbox. It protects the application from a malicious host. There is a new hardware unit in the processor called Memory Encryption Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define one or many MEE regions that can hold enclave data by configuring them with PRMRR registers. The MEE automatically encrypts the data leaving the processor package to the MEE regions. The data is encrypted using a random key whose life-time is exactly one power cycle. You can tell if your CPU supports SGX by looking into /proc/cpuinfo: cat /proc/cpuinfo | grep sgx The driver requires a CPU that has an SGX implementation with ability configure the root key for launching enclaves with a set of MSRs and does not support legacy hardware that only supports enclaves signed with keys whitelisted by Intel in the closed proprietary Intel Launch Enclave. This strategy keeps the control as part of the Linux kernel. All of the SGX code is encapsulated as a driver in order to provide non-intrusive way to upstream such a large chunk of completely new code and also because hardware does not exist in stores yet that supports the launch root key configuration. Other valid reason for encapsulating everything to a platform driver is that before KVM patches are upstreamed there are no internal clients for the SGX code. Our plan is to move part of the code (namely memory managemnt) to arch/x86 as part of the KVM patches. v10: * Cleaned up anon inode based IPC between the ring-0 and ring-3 parts of the driver. * Unset the reserved flag from an enclave page if EDBGRD/WR fails (regression in v6). * Close the anon inode when LE is stopped (regression in v9). * Update the documentation with a more detailed description of SGX. v9: * Replaced kernel-LE IPC based on pipes with an anonymous inode. The driver does not require anymore new exports. v8: * Check that public key MSRs match the LE public key hash in the driver initialization when the MSRs are read-only. * Fix the race in VA slot allocation by checking the fullness immediately after succeesful allocation. * Fix the race in hash mrsigner calculation between the launch enclave and user enclaves by having a separate lock for hash calculation. v7: * Fixed offset calculation in sgx_edbgr/wr(). Address was masked with PAGE_MASK when it should have been masked with ~PAGE_MASK. * Fixed a memory leak in sgx_ioc_enclave_create(). * Simplified swapping code by using a pointer array for a cluster instead of a linked list. * Squeezed struct sgx_encl_page to 32 bytes. * Fixed deferencing of an RSA key on??OpenSSL 1.1.0. * Modified TC's CMAC to use kernel AES-NI. Restructured the code a bit in order to better align with kernel conventions. v6: * Fixed semaphore underrun when accessing /dev/sgx from the launch enclave. * In sgx_encl_create() s/IS_ERR(secs)/IS_ERR(encl)/. * Removed virtualization chapter from the documentation. * Changed the default filename for the signing key as signing_key.pem. * Reworked EPC management in a way that instead of a linked list of struct sgx_epc_page instances there is an array of integers that encodes address and bank of an EPC page (the same data as 'pa' field earlier). The locking has been moved to the EPC bank level instead of a global lock. * Relaxed locking requirements for EPC management. EPC pages can be released back to the EPC bank concurrently. * Cleaned up ptrace() code. * Refined commit messages for new architectural constants. * Sorted includes in every source file. * Sorted local variable declarations according to the line length in every function. * Style fixes based on Darren's comments to sgx_le.c. v5: * Described IPC between the Launch Enclave and kernel in the commit messages. * Fixed all relevant checkpatch.pl issues that I have forgot fix in earlier versions except those that exist in the imported TinyCrypt code. * Fixed spelling mistakes in the documentation. * Forgot to check the return value of sgx_drv_subsys_init(). * Encapsulated properly page cache init and teardown. * Collect epc pages to a temp list in sgx_add_epc_bank * Removed SGX_ENCLAVE_INIT_ARCH constant. v4: * Tied life-cycle of the sgx_le_proxy process to /dev/sgx. * Removed __exit annotation from sgx_drv_subsys_exit(). * Fixed a leak of a backing page in sgx_process_add_page_req() in the case when vm_insert_pfn() fails. * Removed unused symbol exports for sgx_page_cache.c. * Updated sgx_alloc_page() to require encl parameter and documented the behavior (Sean Christopherson). * Refactored a more lean API for sgx_encl_find() and documented the behavior. * Moved #PF handler to sgx_fault.c. * Replaced subsys_system_register() with plain bu
[PATCH v10 1/7] intel_sgx: updated MAINTAINERS
Signed-off-by: Jarkko Sakkinen --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 77d819b458a9..545a8e3168c0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7237,6 +7237,13 @@ L: linux-g...@vger.kernel.org S: Maintained F: drivers/gpio/gpio-intel-mid.c +INTEL SGX +M: Jarkko Sakkinen +L: intel-sgx-kernel-...@lists.01.org +Q: https://patchwork.kernel.org/project/intel-sgx/list/ +F: drivers/platform/x86/intel_sgx/ +K: \bSGX_ + INVENSENSE MPU-3050 GYROSCOPE DRIVER M: Linus Walleij L: linux-...@vger.kernel.org -- 2.14.1
[PATCH v10 2/7] x86: add SGX definitions to cpufeature
From: Kai Huang Added X86_FEATURE_SGX and X86_FEATURE_SGX_LC definitions that define the bits CPUID level 7 bits for determining whether the CPU supports SGX and launch configuration other than the Intel proprietary key. If this the case, IA32_SGXLEPUBKEYHASHn MSRs (0 < n < 4) are available for defining the root key for enclaves. Signed-off-by: Kai Huang Signed-off-by: Jarkko Sakkinen Tested-by: Serge Ayoun --- arch/x86/include/asm/cpufeatures.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index c0b0e9e8aa66..a3fca410216e 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -223,6 +223,7 @@ /* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */ #define X86_FEATURE_FSGSBASE ( 9*32+ 0) /* RDFSBASE, WRFSBASE, RDGSBASE, WRGSBASE instructions*/ #define X86_FEATURE_TSC_ADJUST ( 9*32+ 1) /* TSC adjustment MSR 0x3B */ +#define X86_FEATURE_SGX( 9*32+ 2) /* Software Guard Extensions */ #define X86_FEATURE_BMI1 ( 9*32+ 3) /* 1st group bit manipulation extensions */ #define X86_FEATURE_HLE( 9*32+ 4) /* Hardware Lock Elision */ #define X86_FEATURE_AVX2 ( 9*32+ 5) /* AVX2 instructions */ @@ -308,6 +309,7 @@ #define X86_FEATURE_AVX512_VPOPCNTDQ (16*32+14) /* POPCNT for vectors of DW/QW */ #define X86_FEATURE_LA57 (16*32+16) /* 5-level page tables */ #define X86_FEATURE_RDPID (16*32+22) /* RDPID instruction */ +#define X86_FEATURE_SGX_LC (16*32+30) /* supports SGX launch configuration */ /* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */ #define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery support */ -- 2.14.1
[PATCH v10 3/7] x86: add SGX definitions to msr-index.h
From: Sean Christopherson ENCLS and ENCLU are usable if and only if SGX_ENABLE is set and After SGX is activated the IA32_SGXLEPUBKEYHASHn MSRs are writable if SGX_LC_WR is set and the feature control is locked. SGX related bits in IA32_FEATURE_CONTROL cannot be set before SGX is activated by the pre-boot firmware. SGX activation is triggered by setting bit 0 in the MSR 0x7a. Until SGX is activated, the LE hash MSRs are writable to allow pre-boot firmware to lock down the LE root key with a non-Intel value. Signed-off-by: Sean Christopherson Signed-off-by: Haim Cohen Signed-off-by: Jarkko Sakkinen Tested-by: Serge Ayoun --- arch/x86/include/asm/msr-index.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 34c4922bbc3f..8647a2470487 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -439,6 +439,8 @@ #define FEATURE_CONTROL_LOCKED (1<<0) #define FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX (1<<1) #define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX (1<<2) +#define FEATURE_CONTROL_SGX_ENABLE (1<<18) +#define FEATURE_CONTROL_SGX_LE_WR (1<<17) #define FEATURE_CONTROL_LMCE (1<<20) #define MSR_IA32_APICBASE 0x001b @@ -505,6 +507,12 @@ #define PACKAGE_THERM_INT_LOW_ENABLE (1 << 1) #define PACKAGE_THERM_INT_PLN_ENABLE (1 << 24) +/* Intel SGX MSRs */ +#define MSR_IA32_SGXLEPUBKEYHASH0 0x008C +#define MSR_IA32_SGXLEPUBKEYHASH1 0x008D +#define MSR_IA32_SGXLEPUBKEYHASH2 0x008E +#define MSR_IA32_SGXLEPUBKEYHASH3 0x008F + /* Thermal Thresholds Support */ #define THERM_INT_THRESHOLD0_ENABLE(1 << 15) #define THERM_SHIFT_THRESHOLD08 -- 2.14.1
[PATCH v10 5/7] intel_sgx: ptrace() support
Implemented VMA callbacks in order to ptrace() debug enclaves. With
debug enclaves data can be read and write the memory word at a time by
using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.
Signed-off-by: Jarkko Sakkinen
Tested-by: Serge Ayoun
---
drivers/platform/x86/intel_sgx/sgx_vma.c | 119 +++
1 file changed, 119 insertions(+)
diff --git a/drivers/platform/x86/intel_sgx/sgx_vma.c
b/drivers/platform/x86/intel_sgx/sgx_vma.c
index 770668f23efa..95e05d2d9385 100644
--- a/drivers/platform/x86/intel_sgx/sgx_vma.c
+++ b/drivers/platform/x86/intel_sgx/sgx_vma.c
@@ -61,8 +61,127 @@ static int sgx_vma_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+static int sgx_edbgrd(struct sgx_encl *encl, struct sgx_encl_page *page,
+ unsigned long addr, void *data)
+{
+ unsigned long offset;
+ void *ptr;
+ int ret;
+
+ offset = addr & ~PAGE_MASK;
+
+ if ((page->desc & SGX_ENCL_PAGE_TCS) &&
+ (offset + sizeof(unsigned long)) >
+ offsetof(struct sgx_tcs, reserved))
+ return -ECANCELED;
+
+ ptr = sgx_get_page(page->epc_page);
+ ret = __edbgrd((unsigned long)ptr + offset, data);
+ sgx_put_page(ptr);
+ if (ret) {
+ sgx_dbg(encl, "EDBGRD returned %d\n", ret);
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+static int sgx_edbgwr(struct sgx_encl *encl, struct sgx_encl_page *page,
+ unsigned long addr, void *data)
+{
+ unsigned long offset;
+ void *ptr;
+ int ret;
+
+ offset = addr & ~PAGE_MASK;
+
+ /* Writing anything else than flags will cause #GP */
+ if ((page->desc & SGX_ENCL_PAGE_TCS) &&
+ offset < offsetof(struct sgx_tcs, flags) &&
+ (offset + sizeof(unsigned long)) >
+ offsetof(struct sgx_tcs, flags))
+ return -ECANCELED;
+
+ ptr = sgx_get_page(page->epc_page);
+ ret = __edbgwr((unsigned long)ptr + offset, data);
+ sgx_put_page(ptr);
+ if (ret) {
+ sgx_dbg(encl, "EDBGWR returned %d\n", ret);
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+static int sgx_vma_access(struct vm_area_struct *vma, unsigned long addr,
+ void *buf, int len, int write)
+{
+ struct sgx_encl *encl = vma->vm_private_data;
+ struct sgx_encl_page *entry = NULL;
+ unsigned long align;
+ char data[sizeof(unsigned long)];
+ int offset;
+ int cnt;
+ int ret = 0;
+ int i;
+
+ /* If process was forked, VMA is still there but vm_private_data is set
+* to NULL.
+*/
+ if (!encl)
+ return -EFAULT;
+
+ if (!(encl->flags & SGX_ENCL_DEBUG) ||
+ !(encl->flags & SGX_ENCL_INITIALIZED) ||
+ (encl->flags & SGX_ENCL_DEAD))
+ return -EFAULT;
+
+ for (i = 0; i < len; i += cnt) {
+ if (!entry || !((addr + i) & (PAGE_SIZE - 1))) {
+ if (entry)
+ entry->desc &= ~SGX_ENCL_PAGE_RESERVED;
+
+ entry = sgx_fault_page(vma, (addr + i) & PAGE_MASK,
+ SGX_FAULT_RESERVE);
+ if (IS_ERR(entry)) {
+ ret = PTR_ERR(entry);
+ entry = NULL;
+ break;
+ }
+ }
+
+ /* Locking is not needed because only immutable fields of the
+* page are accessed and page itself is reserved so that it
+* cannot be swapped out in the middle.
+*/
+
+ align = ALIGN_DOWN(addr + i, sizeof(unsigned long));
+ offset = (addr + i) & (sizeof(unsigned long) - 1);
+ cnt = sizeof(unsigned long) - offset;
+ cnt = min(cnt, len - i);
+
+ ret = sgx_edbgrd(encl, entry, align, data);
+ if (ret)
+ break;
+
+ memcpy(data + offset, buf + i, cnt);
+
+ if (write) {
+ ret = sgx_edbgwr(encl, entry, align, data);
+ if (ret)
+ break;
+ }
+ }
+
+ if (entry)
+ entry->desc &= ~SGX_ENCL_PAGE_RESERVED;
+
+ return (ret < 0 && ret != -ECANCELED) ? ret : i;
+}
+
const struct vm_operations_struct sgx_vm_ops = {
.close = sgx_vma_close,
.open = sgx_vma_open,
.fault = sgx_vma_fault,
+ .access = sgx_vma_access,
};
--
2.14.1
[PATCH v10 4/7] intel_sgx: driver for Intel Software Guard Extensions
Intel SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the
enclave is disallowed to access the memory inside the enclave by the CPU
access control.
SGX driver provides a ioctl API for loading and initializing enclaves.
Address range for enclaves is reserved with mmap() and they are
destroyed with munmap(). Enclave construction, measurement and
initialization is done with the provided the ioctl API.
The driver implements also a swapper thread ksgxswapd for EPC pages
backed by a private shmem file. Currently it has a limitation of not
swapping VA pages but there is nothing preventing to implement it later
on. Now it was scoped out in order to keep the implementation simple.
The parameter struct for SGX_IOC_ENCLAVE_INIT does not contain a
parameter to supply a launch token. Generating and using tokens is best
to be kept in the control of the kernel because it has direct binding to
the IA32_SGXPUBKEYHASHx MSRs (a core must have MSRs set to the same
value as the signer of token).
By giving user space any role in the launch process is a risk for
introducing bottlenecks as kernel must exhibit behavior that user space
launch daemon depends on, properietary risks (closed launch daemons on
closed platforms) and stability risks as there would be division of
semantics between user space and kernel.
Signed-off-by: Jarkko Sakkinen
Tested-by: Serge Ayoun
---
arch/x86/include/asm/sgx.h | 184 +
arch/x86/include/asm/sgx_arch.h | 222 ++
arch/x86/include/uapi/asm/sgx.h | 138
drivers/platform/x86/Kconfig| 2 +
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/intel_sgx/Kconfig | 19 +
drivers/platform/x86/intel_sgx/Makefile | 13 +
drivers/platform/x86/intel_sgx/sgx.h| 213 ++
drivers/platform/x86/intel_sgx/sgx_encl.c | 926
drivers/platform/x86/intel_sgx/sgx_ioctl.c | 232 ++
drivers/platform/x86/intel_sgx/sgx_main.c | 359 +
drivers/platform/x86/intel_sgx/sgx_page_cache.c | 593 +++
drivers/platform/x86/intel_sgx/sgx_util.c | 298
drivers/platform/x86/intel_sgx/sgx_vma.c| 68 ++
14 files changed, 3268 insertions(+)
create mode 100644 arch/x86/include/asm/sgx.h
create mode 100644 arch/x86/include/asm/sgx_arch.h
create mode 100644 arch/x86/include/uapi/asm/sgx.h
create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
create mode 100644 drivers/platform/x86/intel_sgx/Makefile
create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c
diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
new file mode 100644
index ..dfe26cac174d
--- /dev/null
+++ b/arch/x86/include/asm/sgx.h
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-17 Intel Corporation.
+//
+// Authors:
+//
+// Jarkko Sakkinen
+// Suresh Siddha
+
+#ifndef _ASM_X86_SGX_H
+#define _ASM_X86_SGX_H
+
+#include
+#include
+#include
+#include
+#include
+
+#define SGX_CPUID 0x12
+
+enum sgx_cpuid {
+ SGX_CPUID_CAPABILITIES = 0,
+ SGX_CPUID_ATTRIBUTES= 1,
+ SGX_CPUID_EPC_BANKS = 2,
+};
+
+enum sgx_commands {
+ ECREATE = 0x0,
+ EADD= 0x1,
+ EINIT = 0x2,
+ EREMOVE = 0x3,
+ EDGBRD = 0x4,
+ EDGBWR = 0x5,
+ EEXTEND = 0x6,
+ ELDU= 0x8,
+ EBLOCK = 0x9,
+ EPA = 0xA,
+ EWB = 0xB,
+ ETRACK = 0xC,
+ EAUG= 0xD,
+ EMODPR = 0xE,
+ EMODT = 0xF,
+};
+
+#ifdef CONFIG_X86_64
+#define XAX "%%rax"
+#else
+#define XAX "%%eax"
+#endif
+
+#define __encls_ret(rax, rbx, rcx, rdx)\
+ ({ \
+ int ret;\
+ asm volatile( \
+ "1: .byte 0x0f, 0x01, 0xcf;\n\t"\
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3: mov $-14,"XAX"\n" \
+ " jmp 2b\n" \
+ ".previous\n" \
+ _ASM_EXTABLE(1b, 3b)\
+ : "=a"(ret) \
+ : "a"(rax), "b"(rbx), "c"(rcx), "d"(rdx)\
+ : "memory");\
+ ret;
[PATCH v10 6/7] intel_sgx: driver documentation
Signed-off-by: Jarkko Sakkinen Tested-by: Serge Ayoun --- Documentation/index.rst | 1 + Documentation/x86/intel_sgx.rst | 168 2 files changed, 169 insertions(+) create mode 100644 Documentation/x86/intel_sgx.rst diff --git a/Documentation/index.rst b/Documentation/index.rst index cb7f1ba5b3b1..ccfebc260e04 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -86,6 +86,7 @@ implementation. :maxdepth: 2 sh/index + x86/index Korean translations --- diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst new file mode 100644 index ..3a49415be62b --- /dev/null +++ b/Documentation/x86/intel_sgx.rst @@ -0,0 +1,168 @@ +=== +Intel(R) SGX driver +=== + +Introduction + + +Intel(R) SGX is a set of CPU instructions that can be used by applications to +set aside private regions of code and data. The code outside the enclave is +disallowed to access the memory inside the enclave by the CPU access control. +In a way you can think that SGX provides inverted sandbox. It protects the +application from a malicious host. + +You can tell if your CPU supports SGX by looking into ``/proc/cpuinfo``: + + ``cat /proc/cpuinfo | grep sgx`` + +Overview of SGX +=== + +SGX has a set of data structures to maintain information about the enclaves and +their security properties. BIOS reserves a fixed size region of physical memory +for these structures by setting Processor Reserved Memory Range Registers +(PRMRR). + +This memory range is protected from outside access by the CPU and all the data +coming in and out of the CPU package is encrypted by a key that is generated for +each boot cycle. + +Enclaves execute in ring-3 in a special enclave submode using pages from the +reserved memory range. A fixed logical address range for the enclave is reserved +by ENCLS(ECREATE), a leaf instruction used to create enclaves. It is referred in +the documentation commonly as the ELRANGE. + +Every memory access to the ELRANGE is asserted by the CPU. If the CPU is not +executing in the enclave mode inside the enclave, #GP is raised. On the other +hand enclave code can make memory accesses both inside and outside of the +ELRANGE. + +Enclave can only execute code inside the ELRANGE. Instructions that may cause +VMEXIT, IO instructions and instructions that require a privilege change are +prohibited inside the enclave. Interrupts and exceptions always cause enclave +to exit and jump to an address outside the enclave given when the enclave is +entered by using the leaf instruction ENCLS(EENTER). + +Data types +-- + +The protected memory range contains the following data: + +* **Enclave Page Cache (EPC):** protected pages +* **Enclave Page Cache Map (EPCM):** a database that describes the state of the + pages and link them to an enclave. + +EPC has a number of different types of pages: + +* **SGX Enclave Control Structure (SECS)**: describes the global + properties of an enclave. +* **Regular (REG):** code and data pages in the ELRANGE. +* **Thread Control Structure (TCS):** pages that define entry points inside an + enclave. The enclave can only be entered through these entry points and each + can host a single hardware thread at a time. +* **Version Array (VA)**: 64-bit version numbers for pages that have been + swapped outside the enclave. Each page contains 512 version numbers. + +Launch control +-- + +To launch an enclave, two structures must be provided for ENCLS(EINIT): + +1. **SIGSTRUCT:** signed measurement of the enclave binary. +2. **EINITTOKEN:** a cryptographic token CMAC-signed with a AES256-key called + *launch key*, which is re-generated for each boot cycle. + +The CPU holds a SHA256 hash of a 3072-bit RSA public key inside +IA32_SGXLEPUBKEYHASHn MSRs. Enclaves with a SIGSTRUCT that is signed with this +key do not require a valid EINITTOKEN and can be authorized with special +privileges. One of those privileges is ability to acquire the launch key with +ENCLS(EGETKEY). + +**IA32_FEATURE_CONTROL[17]** is used by to BIOS configure whether +IA32_SGXLEPUBKEYHASH MSRs are read-only or read-write before locking the +feature control register and handing over control to the operating system. + +Enclave construction + + +The construction is started by filling out the SECS that contains enclave +address range, privileged attributes and measurement of TCS and REG pages (pages +that will be mapped to the address range) among the other things. This structure +is passed out to the ENCLS(ECREATE) together with a physical address of a page +in EPC that will hold the SECS. + +Then pages are added with ENCLS(EADD) and measured with ENCLS(EEXTEND). Finally +enclave is initialized with ENCLS(EINIT). ENCLS(INIT) checks that the SIGSTRUCT +is signed with the contained public key and that the supplied EINITTOKEN i
[PATCH v10 7/7] intel_sgx: in-kernel launch enclave
The Launch Enclave (LE) generates cryptographic launch tokens for user
enclaves. A launch token is used by EINIT to check whether the enclave
is authorized to launch or not. By having its own launch enclave, Linux
has full control of the enclave launch process.
LE is wrapped into a user space proxy program that reads enclave
signatures outputs launch tokens. The kernel-side glue code is
implemented by using the user space helper framework. The IPC between
the LE proxy program and kernel is handled with an anonymous inode.
The commit also adds enclave signing tool that is used by kbuild to
measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points
to a PEM-file for the 3072-bit RSA key that is used as the LE public key
pair. The default location is:
drivers/platform/x86/intel_sgx/sgx_signing_key.pem
If the default key does not exist kbuild will generate a random key and
place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify
the passphrase for the LE public key.
The CMAC implementation has been derived from TinyCrypt. The kernel
AES-NI implementation is used for AES.
[1] https://github.com/01org/tinycrypt
Signed-off-by: Jarkko Sakkinen
Tested-by: Serge Ayoun
---
arch/x86/include/asm/sgx.h | 8 +
arch/x86/include/asm/sgx_le.h | 17 +
drivers/platform/x86/intel_sgx/Kconfig | 15 +
drivers/platform/x86/intel_sgx/Makefile| 19 +
drivers/platform/x86/intel_sgx/le/Makefile | 34 ++
drivers/platform/x86/intel_sgx/le/enclave/Makefile | 53 ++
.../x86/intel_sgx/le/enclave/aesni-intel_asm.S | 1 +
.../platform/x86/intel_sgx/le/enclave/cmac_mode.c | 209
.../platform/x86/intel_sgx/le/enclave/cmac_mode.h | 54 ++
.../x86/intel_sgx/le/enclave/encl_bootstrap.S | 114 +
drivers/platform/x86/intel_sgx/le/enclave/main.c | 146 ++
drivers/platform/x86/intel_sgx/le/enclave/main.h | 19 +
.../platform/x86/intel_sgx/le/enclave/sgx_le.lds | 28 ++
.../platform/x86/intel_sgx/le/enclave/sgxsign.c| 551 +
drivers/platform/x86/intel_sgx/le/enclave/string.c | 1 +
drivers/platform/x86/intel_sgx/le/entry.S | 69 +++
.../platform/x86/intel_sgx/le/include/sgx_asm.h| 15 +
drivers/platform/x86/intel_sgx/le/main.c | 138 ++
drivers/platform/x86/intel_sgx/le/main.h | 29 ++
drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S | 22 +
drivers/platform/x86/intel_sgx/le/string.c | 28 ++
drivers/platform/x86/intel_sgx/sgx.h | 24 +
drivers/platform/x86/intel_sgx/sgx_encl.c | 18 +
drivers/platform/x86/intel_sgx/sgx_ioctl.c | 4 +-
drivers/platform/x86/intel_sgx/sgx_le.c| 264 ++
.../platform/x86/intel_sgx/sgx_le_proxy_piggy.S| 22 +
drivers/platform/x86/intel_sgx/sgx_main.c | 78 ++-
drivers/platform/x86/intel_sgx/sgx_util.c | 25 +
28 files changed, 2000 insertions(+), 5 deletions(-)
create mode 100644 arch/x86/include/asm/sgx_le.h
create mode 100644 drivers/platform/x86/intel_sgx/le/Makefile
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/Makefile
create mode 12 drivers/platform/x86/intel_sgx/le/enclave/aesni-intel_asm.S
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/cmac_mode.c
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/cmac_mode.h
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/encl_bootstrap.S
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/main.c
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/main.h
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgx_le.lds
create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgxsign.c
create mode 12 drivers/platform/x86/intel_sgx/le/enclave/string.c
create mode 100644 drivers/platform/x86/intel_sgx/le/entry.S
create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_asm.h
create mode 100644 drivers/platform/x86/intel_sgx/le/main.c
create mode 100644 drivers/platform/x86/intel_sgx/le/main.h
create mode 100644 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S
create mode 100644 drivers/platform/x86/intel_sgx/le/string.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_le.c
create mode 100644 drivers/platform/x86/intel_sgx/sgx_le_proxy_piggy.S
diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
index dfe26cac174d..2a200e742fa6 100644
--- a/arch/x86/include/asm/sgx.h
+++ b/arch/x86/include/asm/sgx.h
@@ -41,6 +41,14 @@ enum sgx_commands {
EMODT = 0xF,
};
+struct sgx_launch_request {
+ u8 mrenclave[32];
+ u8 mrsigner[32];
+ uint64_t attributes;
+ uint64_t xfrm;
+ struct sgx_einittoken token;
+};
+
#ifdef CONFIG_X86_64
#define XAX "%%rax"
#else
diff --git a/arch/x86/include/asm/sgx_le.h b/arch/x86/include/asm/sgx_le.h
new file mode 100644
index ..61f73fa71ba2
--- /dev/null
+++ b/a
Re: TPM driver breaks S3 suspend
On Thu, Dec 21, 2017 at 04:04:56PM +0800, Chris Chiu wrote: > Hi, > We have a desktop which has S3 suspend (to RAM) problem due to > error messages as follows. > [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend > [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 returns 38 > [ 198.908293] dpm_run_callback(): pnp_bus_suspend+0x0/0x20 returns 38 > [ 198.908298] PM: Device 00:0b failed to suspend: error 38 > > However, the first suspend after boot is working although it still > shows an interesting message during resume. > [ 155.789945] tpm tpm0: A TPM error (38) occurred continue selftest > > The error code 38 in definition is TPM_ERR_INVALID_POSTINIT. I > found some explanations which said this error code means that this > command was received in the wrong sequence relative to a TPM_Startup > command. Don't really know what happens here and how should I deal > with this? Any suggestions? Please let me know what else information > should I provide. Thanks > > Chris The sequences for initializing TPM 1.x devices has been fairly static for a long time. Has this occured after a kernel update? Is there a kernel version where it used to work and a version where it doesn't? Thanks. /Jarkko
Re: TPM driver breaks S3 suspend
On Thu, Dec 21, 2017 at 05:43:35PM +0800, Chris Chiu wrote: > On Thu, Dec 21, 2017 at 5:22 PM, Paul Menzel wrote: > > Dear Chris, > > > > > > Thank you for bringin gup the issue. > > > >> We have a desktop which has S3 suspend (to RAM) problem due to > >> error messages as follows. > >> [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend > >> [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 returns 38 > >> [ 198.908293] dpm_run_callback(): pnp_bus_suspend+0x0/0x20 returns 38 > >> [ 198.908298] PM: Device 00:0b failed to suspend: error 38 > >> > >> However, the first suspend after boot is working although it still > >> shows an interesting message during resume. > >> [ 155.789945] tpm tpm0: A TPM error (38) occurred continue selftest > >> > >> The error code 38 in definition is TPM_ERR_INVALID_POSTINIT. I > >> found some explanations which said this error code means that this > >> command was received in the wrong sequence relative to a TPM_Startup > >> command. Don't really know what happens here and how should I deal > >> with this? Any suggestions? Please let me know what else information > >> should I provide. > > > > > > Please provide more information. Tell us your Linux version, attach your > > config and tell us the system name and if you know it the TPM version. > > Sorry for the missing information. This is reproducible in kernel 4.14 > and latest > 4.15-rc2 with all TPM drivers selected. What system name do you need? It's > Acer Desktop Veriton 4410G. The TPM version shows in dmesg is > [0.640244] tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71) > > Chris Can you put lsmod|grep tpm output? /Jarkko
Re: TPM driver breaks S3 suspend
> The correct solution should be something like tpm2_auto_startup > (execute selftests, if they fail because of the missing startup > command, execute that and retry the selftests). Interestingly, > tpm1_auto_startup (same purpose as tpm2_auto_startup, but for TPM 1.2 > instead) does not use the same sequence, the startup-retry part is > missing. Is there any reason this is done differently for TPM 1.2? > Otherwise I'd propose to make tpm1_auto_startup follow the same > sequence as tpm2_auto_startup and then call both from tpm_tis_resume, > similar to what tpm_chip_register does. I think the reason for that is that such regression has never reported on TPM 1.2 platform. No other reason. /Jarkko
Re: [PATCH 1/4] tpm: fix access attempt to an already unmapped I/O memory region
On Wed, Dec 20, 2017 at 12:35:35PM +0100, Javier Martinez Canillas wrote: > The driver maps the I/O memory address to control the LPC bus CLKRUN_EN, > but on the error path the memory is accessed by the .clk_enable handler > after this was already unmapped. So only unmap the I/O memory region if > it will not be used anymore. > > Also, the correct thing to do is to cleanup the resources in the inverse > order that were acquired to prevent issues like these. > > Signed-off-by: Javier Martinez Canillas I applied Azhar's updated patches to master and next. Shouldn't this be dropped now? /Jarkko
Re: [PATCH v2] tpm: remove unused data fields from I2C and OF device ID tables
On Fri, Dec 22, 2017 at 06:47:41PM +0100, Javier Martinez Canillas wrote:
> The data field for the entries in the device tables are set but not used.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> Changes in v2:
> - Also empty spaces (suggested by Jason Gunthorpe).
>
> drivers/char/tpm/tpm_i2c_infineon.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
> b/drivers/char/tpm/tpm_i2c_infineon.c
> index 005c38879b2e..c1dd39eaaeeb 100644
> --- a/drivers/char/tpm/tpm_i2c_infineon.c
> +++ b/drivers/char/tpm/tpm_i2c_infineon.c
> @@ -665,9 +665,9 @@ static int tpm_tis_i2c_init(struct device *dev)
> }
>
> static const struct i2c_device_id tpm_tis_i2c_table[] = {
> - {"tpm_i2c_infineon", 0},
> - {"slb9635tt", 0},
> - {"slb9645tt", 1},
> + {"tpm_i2c_infineon"},
> + {"slb9635tt"},
> + {"slb9645tt"},
> {},
> };
>
> @@ -675,9 +675,9 @@ MODULE_DEVICE_TABLE(i2c, tpm_tis_i2c_table);
>
> #ifdef CONFIG_OF
> static const struct of_device_id tpm_tis_i2c_of_match[] = {
> - { .compatible = "infineon,tpm_i2c_infineon", .data = (void *)0 },
> - { .compatible = "infineon,slb9635tt", .data = (void *)0 },
> - { .compatible = "infineon,slb9645tt", .data = (void *)1 },
> + {.compatible = "infineon,tpm_i2c_infineon"},
> + {.compatible = "infineon,slb9635tt"},
> + {.compatible = "infineon,slb9645tt"},
> {},
> };
> MODULE_DEVICE_TABLE(of, tpm_tis_i2c_of_match);
> --
> 2.14.3
>
Reviewed-by: Jarkko Sakkinen
/Jarkko
[PATCH 00/12] watchdog: sp5100_tco: Various improvements
The sp5100_tco watchdog driver does not really support recent AMD CPUs,
even though it claims to do so. On top of that, it doesn't use the
watchdog subsystem, and various other problems have crept in. Let's
clean it up for good.
The code was tested on AMD Ryzen 1700 with motherboards from MSI and
Gigabyte. Tests on older hardware would be useful to make sure that
nothing broke.
Guenter Roeck (12):
watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG,DATA_REG}
watchdog: sp5100_tco: Fix watchdog disable bit
watchdog: sp5100_tco: Use request_muxed_region where possible
watchdog: sp5100_tco: Use standard error codes
watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice
watchdog: sp5100_tco: Match PCI device early
watchdog: sp5100_tco: Use dev_ print functions where possible
watchdog: sp5100_tco: Clean up function and variable names
watchdog: sp5100_tco: Convert to use watchdog subsystem
watchdog: sp5100_tco: Use bit operations
watchdog: sp5100-tco: Abort if watchdog is disabled by hardware
watchdog: sp5100_tco: Add support for recent FCH versions
drivers/watchdog/sp5100_tco.c | 710 ++
drivers/watchdog/sp5100_tco.h | 57 ++--
2 files changed, 344 insertions(+), 423 deletions(-)
[PATCH 01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG,DATA_REG}
SP5100_IO_PM_INDEX_REG and SB800_IO_PM_INDEX_REG are used inconsistently
and define the same value. Just use SP5100_IO_PM_INDEX_REG throughout.
Do the same for SP5100_IO_PM_DATA_REG and SB800_IO_PM_DATA_REG.
Use helper functions to access the indexed registers.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 94 ++-
drivers/watchdog/sp5100_tco.h | 7 +---
2 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c5eeba..05f9d27a306a 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -48,7 +48,6 @@
static u32 tcobase_phys;
static u32 tco_wdt_fired;
static void __iomem *tcobase;
-static unsigned int pm_iobase;
static DEFINE_SPINLOCK(tco_lock); /* Guards the hardware */
static unsigned long timer_alive;
static char tco_expect_close;
@@ -132,25 +131,38 @@ static int tco_timer_set_heartbeat(int t)
return 0;
}
-static void tco_timer_enable(void)
+static u8 sp5100_tco_read_pm_reg8(u8 index)
+{
+ outb(index, SP5100_IO_PM_INDEX_REG);
+ return inb(SP5100_IO_PM_DATA_REG);
+}
+
+static void sp5100_tco_update_pm_reg8(u8 index, u8 reset, u8 set)
{
- int val;
+ u8 val;
+ outb(index, SP5100_IO_PM_INDEX_REG);
+ val = inb(SP5100_IO_PM_DATA_REG);
+ val &= reset;
+ val |= set;
+ outb(val, SP5100_IO_PM_DATA_REG);
+}
+
+static void tco_timer_enable(void)
+{
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
/* Set the Watchdog timer resolution to 1 sec */
- outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
- val = inb(SB800_IO_PM_DATA_REG);
- val |= SB800_PM_WATCHDOG_SECOND_RES;
- outb(val, SB800_IO_PM_DATA_REG);
+ sp5100_tco_update_pm_reg8(SB800_PM_WATCHDOG_CONFIG,
+ 0xff, SB800_PM_WATCHDOG_SECOND_RES);
/* Enable watchdog decode bit and watchdog timer */
- outb(SB800_PM_WATCHDOG_CONTROL, SB800_IO_PM_INDEX_REG);
- val = inb(SB800_IO_PM_DATA_REG);
- val |= SB800_PCI_WATCHDOG_DECODE_EN;
- val &= ~SB800_PM_WATCHDOG_DISABLE;
- outb(val, SB800_IO_PM_DATA_REG);
+ sp5100_tco_update_pm_reg8(SB800_PM_WATCHDOG_CONTROL,
+ ~SB800_PM_WATCHDOG_DISABLE,
+ SB800_PCI_WATCHDOG_DECODE_EN);
} else {
+ u32 val;
+
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
pci_read_config_dword(sp5100_tco_pci,
@@ -164,11 +176,9 @@ static void tco_timer_enable(void)
val);
/* Enable Watchdog timer and set the resolution to 1 sec */
- outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
- val = inb(SP5100_IO_PM_DATA_REG);
- val |= SP5100_PM_WATCHDOG_SECOND_RES;
- val &= ~SP5100_PM_WATCHDOG_DISABLE;
- outb(val, SP5100_IO_PM_DATA_REG);
+ sp5100_tco_update_pm_reg8(SP5100_PM_WATCHDOG_CONTROL,
+ ~SP5100_PM_WATCHDOG_DISABLE,
+ SP5100_PM_WATCHDOG_SECOND_RES);
}
}
@@ -321,6 +331,17 @@ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+static u8 sp5100_tco_read_pm_reg32(u8 index)
+{
+ u32 val = 0;
+ int i;
+
+ for (i = 3; i >= 0; i--)
+ val = (val << 8) + sp5100_tco_read_pm_reg8(index + i);
+
+ return val;
+}
+
/*
* Init & exit routines
*/
@@ -329,7 +350,7 @@ static unsigned char sp5100_tco_setupdevice(void)
struct pci_dev *dev = NULL;
const char *dev_name = NULL;
u32 val;
- u32 index_reg, data_reg, base_addr;
+ u8 base_addr;
/* Match the PCI device */
for_each_pci_dev(dev) {
@@ -351,35 +372,25 @@ static unsigned char sp5100_tco_setupdevice(void)
*/
if (tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
dev_name = SP5100_DEVNAME;
- index_reg = SP5100_IO_PM_INDEX_REG;
- data_reg = SP5100_IO_PM_DATA_REG;
base_addr = SP5100_PM_WATCHDOG_BASE;
} else {
dev_name = SB800_DEVNAME;
- index_reg = SB800_IO_PM_INDEX_REG;
- data_reg = SB800_IO_PM_DATA_REG;
base_addr = SB800_PM_WATCHDOG_BASE;
}
/* Request the IO ports used by this driver */
- pm_iobase = SP5100_IO_PM_INDEX_REG;
- if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
- pr_err("I/O address 0x%04x already in use\n", pm_iobase);
+ i
[PATCH 09/12] watchdog: sp5100_tco: Convert to use watchdog subsystem
Convert to watchdog subsystem. As part of that rework, use devm functions
where possible, and replace almost all static variables with a dynamically
allocated data structure.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 358 --
1 file changed, 102 insertions(+), 256 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 1123fad38fdf..bb6c4608c1c0 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -24,37 +24,31 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
+#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
#include
-#include
-#include
+#include
+#include
#include "sp5100_tco.h"
-/* Module and version information */
-#define TCO_VERSION "0.05"
-#define TCO_MODULE_NAME "SP5100 TCO timer"
-#define TCO_DRIVER_NAME TCO_MODULE_NAME ", v" TCO_VERSION
+#define TCO_DRIVER_NAME"sp5100-tco"
/* internal variables */
-static u32 tcobase_phys;
-static u32 tco_wdt_fired;
-static void __iomem *tcobase;
-static DEFINE_SPINLOCK(tco_lock); /* Guards the hardware */
-static unsigned long timer_alive;
-static char tco_expect_close;
-static struct pci_dev *sp5100_tco_pci;
+
+struct sp5100_tco {
+ struct watchdog_device wdd;
+ void __iomem *tcobase;
+};
/* the watchdog platform device */
static struct platform_device *sp5100_tco_platform_device;
+/* the associated PCI device */
+static struct pci_dev *sp5100_tco_pci;
/* module parameters */
@@ -79,55 +73,52 @@ static bool tco_has_sp5100_reg_layout(struct pci_dev *dev)
dev->revision < 0x40;
}
-static void tco_timer_start(void)
+static int tco_timer_start(struct watchdog_device *wdd)
{
+ struct sp5100_tco *tco = watchdog_get_drvdata(wdd);
u32 val;
- unsigned long flags;
- spin_lock_irqsave(&tco_lock, flags);
- val = readl(SP5100_WDT_CONTROL(tcobase));
+ val = readl(SP5100_WDT_CONTROL(tco->tcobase));
val |= SP5100_WDT_START_STOP_BIT;
- writel(val, SP5100_WDT_CONTROL(tcobase));
- spin_unlock_irqrestore(&tco_lock, flags);
+ writel(val, SP5100_WDT_CONTROL(tco->tcobase));
+
+ return 0;
}
-static void tco_timer_stop(void)
+static int tco_timer_stop(struct watchdog_device *wdd)
{
+ struct sp5100_tco *tco = watchdog_get_drvdata(wdd);
u32 val;
- unsigned long flags;
- spin_lock_irqsave(&tco_lock, flags);
- val = readl(SP5100_WDT_CONTROL(tcobase));
+ val = readl(SP5100_WDT_CONTROL(tco->tcobase));
val &= ~SP5100_WDT_START_STOP_BIT;
- writel(val, SP5100_WDT_CONTROL(tcobase));
- spin_unlock_irqrestore(&tco_lock, flags);
+ writel(val, SP5100_WDT_CONTROL(tco->tcobase));
+
+ return 0;
}
-static void tco_timer_keepalive(void)
+static int tco_timer_ping(struct watchdog_device *wdd)
{
+ struct sp5100_tco *tco = watchdog_get_drvdata(wdd);
u32 val;
- unsigned long flags;
- spin_lock_irqsave(&tco_lock, flags);
- val = readl(SP5100_WDT_CONTROL(tcobase));
+ val = readl(SP5100_WDT_CONTROL(tco->tcobase));
val |= SP5100_WDT_TRIGGER_BIT;
- writel(val, SP5100_WDT_CONTROL(tcobase));
- spin_unlock_irqrestore(&tco_lock, flags);
+ writel(val, SP5100_WDT_CONTROL(tco->tcobase));
+
+ return 0;
}
-static int tco_timer_set_heartbeat(int t)
+static int tco_timer_set_timeout(struct watchdog_device *wdd,
+unsigned int t)
{
- unsigned long flags;
-
- if (t < 0 || t > 0x)
- return -EINVAL;
+ struct sp5100_tco *tco = watchdog_get_drvdata(wdd);
/* Write new heartbeat to watchdog */
- spin_lock_irqsave(&tco_lock, flags);
- writel(t, SP5100_WDT_COUNT(tcobase));
- spin_unlock_irqrestore(&tco_lock, flags);
+ writel(t, SP5100_WDT_COUNT(tco->tcobase));
+
+ wdd->timeout = t;
- heartbeat = t;
return 0;
}
@@ -182,137 +173,7 @@ static void tco_timer_enable(void)
}
}
-/*
- * /dev/watchdog handling
- */
-
-static int sp5100_tco_open(struct inode *inode, struct file *file)
-{
- /* /dev/watchdog can only be opened once */
- if (test_and_set_bit(0, &timer_alive))
- return -EBUSY;
-
- /* Reload and activate timer */
- tco_timer_start();
- tco_timer_keepalive();
- return nonseekable_open(inode, file);
-}
-
-static int sp5100_tco_release(struct inode *inode, struct file *file)
-{
- /* Shut off the timer. */
- if (tco_expect_close == 42) {
- tco_timer_stop();
- } else {
- pr_crit("Unexpected close, not stopping watchdog!\n");
- tco_timer_keepalive();
- }
- clear_bit(0, &timer_alive);
- tco_expect_close = 0;
- return 0;
-}
-
-static ssize_t sp
[PATCH 07/12] watchdog: sp5100_tco: Use dev_ print functions where possible
Use dev_ instead of pr_ functions where possible.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 5868c6b6bf17..ff240e5be833 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -326,7 +326,7 @@ static u8 sp5100_tco_read_pm_reg32(u8 index)
/*
* Init & exit routines
*/
-static int sp5100_tco_setupdevice(void)
+static int sp5100_tco_setupdevice(struct device *dev)
{
const char *dev_name = NULL;
u32 val;
@@ -347,8 +347,8 @@ static int sp5100_tco_setupdevice(void)
/* Request the IO ports used by this driver */
if (!request_muxed_region(SP5100_IO_PM_INDEX_REG,
SP5100_PM_IOPORTS_SIZE, dev_name)) {
- pr_err("I/O address 0x%04x already in use\n",
- SP5100_IO_PM_INDEX_REG);
+ dev_err(dev, "I/O address 0x%04x already in use\n",
+ SP5100_IO_PM_INDEX_REG);
return -EBUSY;
}
@@ -358,12 +358,12 @@ static int sp5100_tco_setupdevice(void)
*/
val = sp5100_tco_read_pm_reg32(base_addr) & 0xfff8;
- pr_debug("Got 0x%04x from indirect I/O\n", val);
+ dev_dbg(dev, "Got 0x%04x from indirect I/O\n", val);
/* Check MMIO address conflict */
if (!request_mem_region_exclusive(val, SP5100_WDT_MEM_MAP_SIZE,
dev_name)) {
- pr_debug("MMIO address 0x%04x already in use\n", val);
+ dev_dbg(dev, "MMIO address 0x%04x already in use\n", val);
/*
* Secondly, Find the watchdog timer MMIO address
* from SBResource_MMIO register.
@@ -381,7 +381,8 @@ static int sp5100_tco_setupdevice(void)
/* The SBResource_MMIO is enabled and mapped memory space? */
if ((val & (SB800_ACPI_MMIO_DECODE_EN | SB800_ACPI_MMIO_SEL)) !=
SB800_ACPI_MMIO_DECODE_EN) {
- pr_notice("failed to find MMIO address, giving up.\n");
+ dev_notice(dev,
+ "failed to find MMIO address, giving up.\n");
ret = -ENODEV;
goto unreg_region;
}
@@ -392,23 +393,24 @@ static int sp5100_tco_setupdevice(void)
/* Check MMIO address conflict */
if (!request_mem_region_exclusive(val, SP5100_WDT_MEM_MAP_SIZE,
dev_name)) {
- pr_debug("MMIO address 0x%04x already in use\n", val);
+ dev_dbg(dev, "MMIO address 0x%04x already in use\n",
+ val);
ret = -EBUSY;
goto unreg_region;
}
- pr_debug("Got 0x%04x from SBResource_MMIO register\n", val);
+ dev_dbg(dev, "Got 0x%04x from SBResource_MMIO register\n", val);
}
tcobase_phys = val;
tcobase = ioremap(val, SP5100_WDT_MEM_MAP_SIZE);
if (!tcobase) {
- pr_err("failed to get tcobase address\n");
+ dev_err(dev, "failed to get tcobase address\n");
ret = -ENOMEM;
goto unreg_mem_region;
}
- pr_info("Using 0x%04x for watchdog MMIO address\n", val);
+ dev_info(dev, "Using 0x%04x for watchdog MMIO address\n", val);
/* Setup the watchdog timer */
tco_timer_enable();
@@ -443,21 +445,22 @@ static int sp5100_tco_setupdevice(void)
return ret;
}
-static int sp5100_tco_init(struct platform_device *dev)
+static int sp5100_tco_init(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
int ret;
/*
* Check whether or not the hardware watchdog is there. If found, then
* set it up.
*/
- ret = sp5100_tco_setupdevice();
+ ret = sp5100_tco_setupdevice(dev);
if (ret)
return ret;
/* Check to see if last reboot was due to watchdog timeout */
- pr_info("Last reboot was %striggered by watchdog.\n",
- tco_wdt_fired ? "" : "not ");
+ dev_info(dev, "Last reboot was %striggered by watchdog.\n",
+tco_wdt_fired ? "" : "not ");
/*
* Check that the heartbeat value is within it's range.
@@ -470,16 +473,16 @@ static int sp5100_tco_init(struct platform_device *dev)
ret = misc_register(&sp5100_tco_miscdev);
if (ret != 0) {
- pr_err("cannot register miscdev on minor=%d (err=%d)\n",
- WATCHDOG_MINOR, ret);
+ dev_err(dev, "cannot register miscdev on minor=%d (err=%d)\n",
+
[PATCH 10/12] watchdog: sp5100_tco: Use bit operations
Using bit operations makes it easier to improve the driver. Cc: Zoltán Böszörményi Signed-off-by: Guenter Roeck --- drivers/watchdog/sp5100_tco.h | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h index cc00f1157220..ca0721c8d879 100644 --- a/drivers/watchdog/sp5100_tco.h +++ b/drivers/watchdog/sp5100_tco.h @@ -7,6 +7,8 @@ * TCO timer driver for sp5100 chipsets */ +#include + /* * Some address definitions for the Watchdog */ @@ -14,10 +16,10 @@ #define SP5100_WDT_CONTROL(base) ((base) + 0x00) /* Watchdog Control */ #define SP5100_WDT_COUNT(base) ((base) + 0x04) /* Watchdog Count */ -#define SP5100_WDT_START_STOP_BIT (1 << 0) -#define SP5100_WDT_FIRED (1 << 1) -#define SP5100_WDT_ACTION_RESET(1 << 2) -#define SP5100_WDT_TRIGGER_BIT (1 << 7) +#define SP5100_WDT_START_STOP_BIT BIT(0) +#define SP5100_WDT_FIRED BIT(1) +#define SP5100_WDT_ACTION_RESETBIT(2) +#define SP5100_WDT_TRIGGER_BIT BIT(7) #define SP5100_PM_IOPORTS_SIZE 0x02 @@ -37,10 +39,10 @@ #define SP5100_PM_WATCHDOG_BASE0x6C #define SP5100_PCI_WATCHDOG_MISC_REG 0x41 -#define SP5100_PCI_WATCHDOG_DECODE_EN (1 << 3) +#define SP5100_PCI_WATCHDOG_DECODE_EN BIT(3) -#define SP5100_PM_WATCHDOG_DISABLE (1 << 0) -#define SP5100_PM_WATCHDOG_SECOND_RES (3 << 1) +#define SP5100_PM_WATCHDOG_DISABLE ((u8)BIT(0)) +#define SP5100_PM_WATCHDOG_SECOND_RES GENMASK(2, 1) #define SP5100_DEVNAME "SP5100 TCO" @@ -50,12 +52,11 @@ #define SB800_PM_WATCHDOG_BASE 0x48 #define SB800_PM_WATCHDOG_CONFIG 0x4C -#define SB800_PCI_WATCHDOG_DECODE_EN (1 << 0) -#define SB800_PM_WATCHDOG_DISABLE (1 << 1) -#define SB800_PM_WATCHDOG_SECOND_RES (3 << 0) -#define SB800_ACPI_MMIO_DECODE_EN (1 << 0) -#define SB800_ACPI_MMIO_SEL(1 << 1) - +#define SB800_PCI_WATCHDOG_DECODE_EN BIT(0) +#define SB800_PM_WATCHDOG_DISABLE ((u8)BIT(1)) +#define SB800_PM_WATCHDOG_SECOND_RES GENMASK(1, 0) +#define SB800_ACPI_MMIO_DECODE_EN BIT(0) +#define SB800_ACPI_MMIO_SELBIT(1) #define SB800_PM_WDT_MMIO_OFFSET 0xB00 -- 2.7.4
[PATCH 12/12] watchdog: sp5100_tco: Add support for recent FCH versions
Starting with Family 16h Models 30h-3Fh and Family 15h Models 60h-6Fh,
watchdog address space decoding has changed. The cutover point is already
identified in the i2c-piix2 driver, so use the same mechanism.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 169 --
drivers/watchdog/sp5100_tco.h | 21 ++
2 files changed, 133 insertions(+), 57 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 23246cb40598..41aaae2d5287 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -16,6 +16,11 @@
* See AMD Publication 43009 "AMD SB700/710/750 Register Reference Guide",
* AMD Publication 45482 "AMD SB800-Series Southbridges Register
* Reference Guide"
+ * AMD Publication 48751 "BIOS and Kernel Developer’s Guide (BKDG)
+ * for AMD Family 16h Models 00h-0Fh Processors"
+ * AMD Publication 51192 "AMD Bolton FCH Register Reference Guide"
+ * AMD Publication 52740 "BIOS and Kernel Developer’s Guide (BKDG)
+ * for AMD Family 16h Models 30h-3Fh Processors"
*/
/*
@@ -40,9 +45,14 @@
/* internal variables */
+enum tco_reg_layout {
+ sp5100, sb800, efch
+};
+
struct sp5100_tco {
struct watchdog_device wdd;
void __iomem *tcobase;
+ enum tco_reg_layout tco_reg_layout;
};
/* the watchdog platform device */
@@ -67,10 +77,20 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started."
* Some TCO specific functions
*/
-static bool tco_has_sp5100_reg_layout(struct pci_dev *dev)
+static enum tco_reg_layout tco_reg_layout(struct pci_dev *dev)
{
- return dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
- dev->revision < 0x40;
+ if (dev->vendor == PCI_VENDOR_ID_ATI &&
+ dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
+ dev->revision < 0x40) {
+ return sp5100;
+ } else if (dev->vendor == PCI_VENDOR_ID_AMD &&
+ ((dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS &&
+dev->revision >= 0x41) ||
+ (dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS &&
+dev->revision >= 0x49))) {
+ return efch;
+ }
+ return sb800;
}
static int tco_timer_start(struct watchdog_device *wdd)
@@ -139,9 +159,12 @@ static void sp5100_tco_update_pm_reg8(u8 index, u8 reset,
u8 set)
outb(val, SP5100_IO_PM_DATA_REG);
}
-static void tco_timer_enable(void)
+static void tco_timer_enable(struct sp5100_tco *tco)
{
- if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
+ u32 val;
+
+ switch (tco->tco_reg_layout) {
+ case sb800:
/* For SB800 or later */
/* Set the Watchdog timer resolution to 1 sec */
sp5100_tco_update_pm_reg8(SB800_PM_WATCHDOG_CONFIG,
@@ -151,9 +174,8 @@ static void tco_timer_enable(void)
sp5100_tco_update_pm_reg8(SB800_PM_WATCHDOG_CONTROL,
~SB800_PM_WATCHDOG_DISABLE,
SB800_PCI_WATCHDOG_DECODE_EN);
- } else {
- u32 val;
-
+ break;
+ case sp5100:
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
pci_read_config_dword(sp5100_tco_pci,
@@ -170,6 +192,13 @@ static void tco_timer_enable(void)
sp5100_tco_update_pm_reg8(SP5100_PM_WATCHDOG_CONTROL,
~SP5100_PM_WATCHDOG_DISABLE,
SP5100_PM_WATCHDOG_SECOND_RES);
+ break;
+ case efch:
+ /* Set the Watchdog timer resolution to 1 sec and enable */
+ sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN3,
+ ~EFCH_PM_WATCHDOG_DISABLE,
+ EFCH_PM_DECODEEN_SECOND_RES);
+ break;
}
}
@@ -189,89 +218,113 @@ static int sp5100_tco_setupdevice(struct device *dev,
{
struct sp5100_tco *tco = watchdog_get_drvdata(wdd);
const char *dev_name;
- u8 base_addr;
- u32 val;
+ u32 mmio_addr = 0, val;
int ret;
- /*
-* Determine type of southbridge chipset.
-*/
- if (tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
- dev_name = SP5100_DEVNAME;
- base_addr = SP5100_PM_WATCHDOG_BASE;
- } else {
- dev_name = SB800_DEVNAME;
- base_addr = SB800_PM_WATCHDOG_BASE;
- }
-
/* Request the IO ports used by this driver */
if (!request_muxed_region(SP5100_IO_PM_INDEX_REG,
- SP5100_PM_IOPORTS_SIZE, dev_name)) {
+ SP5100_PM_IOPORTS_SIZE, "sp5100
[PATCH 11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware
If the watchdog control register indicates that the watchdog hardware
is disabled even after we tried to enable it, there is no point to
instantiate the driver.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 8 +++-
drivers/watchdog/sp5100_tco.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index bb6c4608c1c0..23246cb40598 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -273,14 +273,20 @@ static int sp5100_tco_setupdevice(struct device *dev,
/* Setup the watchdog timer */
tco_timer_enable();
- /* Check that the watchdog action is set to reset the system */
val = readl(SP5100_WDT_CONTROL(tco->tcobase));
+ if (val & SP5100_WDT_DISABLED) {
+ dev_err(dev, "Watchdog hardware is disabled\n");
+ ret = -ENODEV;
+ goto unreg_region;
+ }
+
/*
* Save WatchDogFired status, because WatchDogFired flag is
* cleared here.
*/
if (val & SP5100_WDT_FIRED)
wdd->bootstatus = WDIOF_CARDRESET;
+ /* Set watchdog action to reset the system */
val &= ~SP5100_WDT_ACTION_RESET;
writel(val, SP5100_WDT_CONTROL(tco->tcobase));
diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h
index ca0721c8d879..008b2094bd13 100644
--- a/drivers/watchdog/sp5100_tco.h
+++ b/drivers/watchdog/sp5100_tco.h
@@ -19,6 +19,7 @@
#define SP5100_WDT_START_STOP_BIT BIT(0)
#define SP5100_WDT_FIRED BIT(1)
#define SP5100_WDT_ACTION_RESETBIT(2)
+#define SP5100_WDT_DISABLEDBIT(3)
#define SP5100_WDT_TRIGGER_BIT BIT(7)
#define SP5100_PM_IOPORTS_SIZE 0x02
--
2.7.4
[PATCH 08/12] watchdog: sp5100_tco: Clean up function and variable names
Use more common function and variable names.
Use pdev instead of dev for platform device.
Use sp5100_tco_probe() instead of sp5100_tco_init() for the probe function.
Drop sp5100_tco_cleanup(); just move the code into sp5100_tco_remove().
Use sp5100_tco_init() instead of sp5100_tco_init_module() for the module
initialization function.
Use sp5100_tco_exit() instead of sp5100_tco_cleanup_module() for the module
exit function.
Use consistent defines for accessing the watchdog control register.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 25 ++---
drivers/watchdog/sp5100_tco.h | 5 ++---
2 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index ff240e5be833..1123fad38fdf 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -421,8 +421,8 @@ static int sp5100_tco_setupdevice(struct device *dev)
* Save WatchDogFired status, because WatchDogFired flag is
* cleared here.
*/
- tco_wdt_fired = val & SP5100_PM_WATCHDOG_FIRED;
- val &= ~SP5100_PM_WATCHDOG_ACTION_RESET;
+ tco_wdt_fired = val & SP5100_WDT_FIRED;
+ val &= ~SP5100_WDT_ACTION_RESET;
writel(val, SP5100_WDT_CONTROL(tcobase));
/* Set a reasonable heartbeat before we stop the timer */
@@ -445,7 +445,7 @@ static int sp5100_tco_setupdevice(struct device *dev)
return ret;
}
-static int sp5100_tco_init(struct platform_device *pdev)
+static int sp5100_tco_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
int ret;
@@ -492,7 +492,7 @@ static int sp5100_tco_init(struct platform_device *pdev)
return ret;
}
-static void sp5100_tco_cleanup(void)
+static int sp5100_tco_remove(struct platform_device *pdev)
{
/* Stop the timer before we leave */
if (!nowayout)
@@ -502,22 +502,17 @@ static void sp5100_tco_cleanup(void)
misc_deregister(&sp5100_tco_miscdev);
iounmap(tcobase);
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
-}
-static int sp5100_tco_remove(struct platform_device *dev)
-{
- if (tcobase)
- sp5100_tco_cleanup();
return 0;
}
-static void sp5100_tco_shutdown(struct platform_device *dev)
+static void sp5100_tco_shutdown(struct platform_device *pdev)
{
tco_timer_stop();
}
static struct platform_driver sp5100_tco_driver = {
- .probe = sp5100_tco_init,
+ .probe = sp5100_tco_probe,
.remove = sp5100_tco_remove,
.shutdown = sp5100_tco_shutdown,
.driver = {
@@ -544,7 +539,7 @@ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
-static int __init sp5100_tco_init_module(void)
+static int __init sp5100_tco_init(void)
{
struct pci_dev *dev = NULL;
int err;
@@ -580,14 +575,14 @@ static int __init sp5100_tco_init_module(void)
return err;
}
-static void __exit sp5100_tco_cleanup_module(void)
+static void __exit sp5100_tco_exit(void)
{
platform_device_unregister(sp5100_tco_platform_device);
platform_driver_unregister(&sp5100_tco_driver);
}
-module_init(sp5100_tco_init_module);
-module_exit(sp5100_tco_cleanup_module);
+module_init(sp5100_tco_init);
+module_exit(sp5100_tco_exit);
MODULE_AUTHOR("Priyanka Gupta");
MODULE_DESCRIPTION("TCO timer driver for SP5100/SB800 chipset");
diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h
index 2622cfe23dc1..cc00f1157220 100644
--- a/drivers/watchdog/sp5100_tco.h
+++ b/drivers/watchdog/sp5100_tco.h
@@ -15,6 +15,8 @@
#define SP5100_WDT_COUNT(base) ((base) + 0x04) /* Watchdog Count */
#define SP5100_WDT_START_STOP_BIT (1 << 0)
+#define SP5100_WDT_FIRED (1 << 1)
+#define SP5100_WDT_ACTION_RESET(1 << 2)
#define SP5100_WDT_TRIGGER_BIT (1 << 7)
#define SP5100_PM_IOPORTS_SIZE 0x02
@@ -34,9 +36,6 @@
#define SP5100_PM_WATCHDOG_CONTROL 0x69
#define SP5100_PM_WATCHDOG_BASE0x6C
-#define SP5100_PM_WATCHDOG_FIRED (1 << 1)
-#define SP5100_PM_WATCHDOG_ACTION_RESET(1 << 2)
-
#define SP5100_PCI_WATCHDOG_MISC_REG 0x41
#define SP5100_PCI_WATCHDOG_DECODE_EN (1 << 3)
--
2.7.4
[PATCH 06/12] watchdog: sp5100_tco: Match PCI device early
Match PCI device in module init function, not in the probe function.
It is pointless trying to probe if we can determine early that the device
is not supported.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 66 ---
1 file changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 5a13ab483c50..5868c6b6bf17 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -312,25 +312,6 @@ static struct miscdevice sp5100_tco_miscdev = {
.fops = &sp5100_tco_fops,
};
-/*
- * Data for PCI driver interface
- *
- * This data only exists for exporting the supported
- * PCI ids via MODULE_DEVICE_TABLE. We do not actually
- * register a pci_driver, because someone else might
- * want to register another driver on the same PCI id.
- */
-static const struct pci_device_id sp5100_tco_pci_tbl[] = {
- { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, PCI_ANY_ID,
- PCI_ANY_ID, },
- { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
- PCI_ANY_ID, },
- { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, PCI_ANY_ID,
- PCI_ANY_ID, },
- { 0, }, /* End of list */
-};
-MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
-
static u8 sp5100_tco_read_pm_reg32(u8 index)
{
u32 val = 0;
@@ -347,27 +328,11 @@ static u8 sp5100_tco_read_pm_reg32(u8 index)
*/
static int sp5100_tco_setupdevice(void)
{
- struct pci_dev *dev = NULL;
const char *dev_name = NULL;
u32 val;
u8 base_addr;
int ret;
- /* Match the PCI device */
- for_each_pci_dev(dev) {
- if (pci_match_id(sp5100_tco_pci_tbl, dev) != NULL) {
- sp5100_tco_pci = dev;
- break;
- }
- }
-
- if (!sp5100_tco_pci)
- return -ENODEV;
-
- pr_info("PCI Vendor ID: 0x%x, Device ID: 0x%x, Revision ID: 0x%x\n",
- sp5100_tco_pci->vendor, sp5100_tco_pci->device,
- sp5100_tco_pci->revision);
-
/*
* Determine type of southbridge chipset.
*/
@@ -557,10 +522,41 @@ static struct platform_driver sp5100_tco_driver = {
},
};
+/*
+ * Data for PCI driver interface
+ *
+ * This data only exists for exporting the supported
+ * PCI ids via MODULE_DEVICE_TABLE. We do not actually
+ * register a pci_driver, because someone else might
+ * want to register another driver on the same PCI id.
+ */
+static const struct pci_device_id sp5100_tco_pci_tbl[] = {
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
+ { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
+ { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
+ { 0, }, /* End of list */
+};
+MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+
static int __init sp5100_tco_init_module(void)
{
+ struct pci_dev *dev = NULL;
int err;
+ /* Match the PCI device */
+ for_each_pci_dev(dev) {
+ if (pci_match_id(sp5100_tco_pci_tbl, dev) != NULL) {
+ sp5100_tco_pci = dev;
+ break;
+ }
+ }
+
+ if (!sp5100_tco_pci)
+ return -ENODEV;
+
pr_info("SP5100/SB800 TCO WatchDog Timer Driver v%s\n", TCO_VERSION);
err = platform_driver_register(&sp5100_tco_driver);
--
2.7.4
[PATCH 00/12] watchdog: sp5100_tco: Various improvements
The sp5100_tco watchdog driver does not really support recent AMD CPUs,
even though it claims to do so. On top of that, it doesn't use the
watchdog subsystem, and various other problems have crept in. Let's
clean it up for good.
The code was tested on AMD Ryzen 1700 with motherboards from MSI and
Gigabyte. Tests on older hardware would be useful to make sure that
nothing broke.
Guenter Roeck (12):
watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG,DATA_REG}
watchdog: sp5100_tco: Fix watchdog disable bit
watchdog: sp5100_tco: Use request_muxed_region where possible
watchdog: sp5100_tco: Use standard error codes
watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice
watchdog: sp5100_tco: Match PCI device early
watchdog: sp5100_tco: Use dev_ print functions where possible
watchdog: sp5100_tco: Clean up function and variable names
watchdog: sp5100_tco: Convert to use watchdog subsystem
watchdog: sp5100_tco: Use bit operations
watchdog: sp5100-tco: Abort if watchdog is disabled by hardware
watchdog: sp5100_tco: Add support for recent FCH versions
drivers/watchdog/sp5100_tco.c | 710 ++
drivers/watchdog/sp5100_tco.h | 57 ++--
2 files changed, 344 insertions(+), 423 deletions(-)
[PATCH 02/12] watchdog: sp5100_tco: Fix watchdog disable bit
According to all published information, the watchdog disable bit for SB800 compatible controllers is bit 1 of PM register 0x48, not bit 2. For the most part that doesn't matter in practice, since the bit has to be cleared to enable watchdog address decoding, which is the default setting, but it still needs to be fixed. Cc: Zoltán Böszörményi Signed-off-by: Guenter Roeck --- drivers/watchdog/sp5100_tco.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h index f495fe03887a..2622cfe23dc1 100644 --- a/drivers/watchdog/sp5100_tco.h +++ b/drivers/watchdog/sp5100_tco.h @@ -52,7 +52,7 @@ #define SB800_PM_WATCHDOG_CONFIG 0x4C #define SB800_PCI_WATCHDOG_DECODE_EN (1 << 0) -#define SB800_PM_WATCHDOG_DISABLE (1 << 2) +#define SB800_PM_WATCHDOG_DISABLE (1 << 1) #define SB800_PM_WATCHDOG_SECOND_RES (3 << 0) #define SB800_ACPI_MMIO_DECODE_EN (1 << 0) #define SB800_ACPI_MMIO_SEL(1 << 1) -- 2.7.4
[PATCH 03/12] watchdog: sp5100_tco: Use request_muxed_region where possible
Use request_muxed_region for multiplexed IO memory regions.
Also, SP5100_IO_PM_INDEX_REG/SP5100_IO_PM_DATA_REG are only
used during initialization; it is unnecessary to keep the
address range reserved.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 05f9d27a306a..11109ac959e2 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -379,8 +379,8 @@ static unsigned char sp5100_tco_setupdevice(void)
}
/* Request the IO ports used by this driver */
- if (!request_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE,
- dev_name)) {
+ if (!request_muxed_region(SP5100_IO_PM_INDEX_REG,
+ SP5100_PM_IOPORTS_SIZE, dev_name)) {
pr_err("I/O address 0x%04x already in use\n",
SP5100_IO_PM_INDEX_REG);
goto exit;
@@ -468,6 +468,7 @@ static unsigned char sp5100_tco_setupdevice(void)
*/
tco_timer_stop();
+ release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE);
/* Done */
return 1;
@@ -521,7 +522,6 @@ static int sp5100_tco_init(struct platform_device *dev)
exit:
iounmap(tcobase);
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
- release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE);
return ret;
}
@@ -535,7 +535,6 @@ static void sp5100_tco_cleanup(void)
misc_deregister(&sp5100_tco_miscdev);
iounmap(tcobase);
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
- release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE);
}
static int sp5100_tco_remove(struct platform_device *dev)
--
2.7.4
[PATCH 05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice
There are too many unnecessary goto statements in sp5100_tco_setupdevice().
Rearrange the code and limit goto statements to error handling.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 62 ---
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 0e816f2cdb07..5a13ab483c50 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -396,48 +396,44 @@ static int sp5100_tco_setupdevice(void)
pr_debug("Got 0x%04x from indirect I/O\n", val);
/* Check MMIO address conflict */
- if (request_mem_region_exclusive(val, SP5100_WDT_MEM_MAP_SIZE,
- dev_name))
- goto setup_wdt;
- else
+ if (!request_mem_region_exclusive(val, SP5100_WDT_MEM_MAP_SIZE,
+ dev_name)) {
pr_debug("MMIO address 0x%04x already in use\n", val);
+ /*
+* Secondly, Find the watchdog timer MMIO address
+* from SBResource_MMIO register.
+*/
+ if (tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
+ /* Read SBResource_MMIO from PCI config(PCI_Reg: 9Ch) */
+ pci_read_config_dword(sp5100_tco_pci,
+ SP5100_SB_RESOURCE_MMIO_BASE,
+ &val);
+ } else {
+ /* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
+ val = sp5100_tco_read_pm_reg32(SB800_PM_ACPI_MMIO_EN);
+ }
- /*
-* Secondly, Find the watchdog timer MMIO address
-* from SBResource_MMIO register.
-*/
- if (tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
- /* Read SBResource_MMIO from PCI config(PCI_Reg: 9Ch) */
- pci_read_config_dword(sp5100_tco_pci,
- SP5100_SB_RESOURCE_MMIO_BASE, &val);
- } else {
- /* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
- val = sp5100_tco_read_pm_reg32(SB800_PM_ACPI_MMIO_EN);
- }
-
- /* The SBResource_MMIO is enabled and mapped memory space? */
- if ((val & (SB800_ACPI_MMIO_DECODE_EN | SB800_ACPI_MMIO_SEL)) ==
+ /* The SBResource_MMIO is enabled and mapped memory space? */
+ if ((val & (SB800_ACPI_MMIO_DECODE_EN | SB800_ACPI_MMIO_SEL)) !=
SB800_ACPI_MMIO_DECODE_EN) {
+ pr_notice("failed to find MMIO address, giving up.\n");
+ ret = -ENODEV;
+ goto unreg_region;
+ }
/* Clear unnecessary the low twelve bits */
val &= ~0xFFF;
/* Add the Watchdog Timer offset to base address. */
val += SB800_PM_WDT_MMIO_OFFSET;
/* Check MMIO address conflict */
- if (request_mem_region_exclusive(val, SP5100_WDT_MEM_MAP_SIZE,
- dev_name)) {
- pr_debug("Got 0x%04x from SBResource_MMIO register\n",
- val);
- goto setup_wdt;
- } else
+ if (!request_mem_region_exclusive(val, SP5100_WDT_MEM_MAP_SIZE,
+ dev_name)) {
pr_debug("MMIO address 0x%04x already in use\n", val);
- } else
- pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
-
- pr_notice("failed to find MMIO address, giving up.\n");
- ret = -ENODEV;
- goto unreg_region;
+ ret = -EBUSY;
+ goto unreg_region;
+ }
+ pr_debug("Got 0x%04x from SBResource_MMIO register\n", val);
+ }
-setup_wdt:
tcobase_phys = val;
tcobase = ioremap(val, SP5100_WDT_MEM_MAP_SIZE);
@@ -472,7 +468,7 @@ static int sp5100_tco_setupdevice(void)
tco_timer_stop();
release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE);
- /* Done */
+
return 0;
unreg_mem_region:
--
2.7.4
[PATCH 02/12] watchdog: sp5100_tco: Fix watchdog disable bit
According to all published information, the watchdog disable bit for SB800 compatible controllers is bit 1 of PM register 0x48, not bit 2. For the most part that doesn't matter in practice, since the bit has to be cleared to enable watchdog address decoding, which is the default setting, but it still needs to be fixed. Cc: Zoltán Böszörményi Signed-off-by: Guenter Roeck --- drivers/watchdog/sp5100_tco.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h index f495fe03887a..2622cfe23dc1 100644 --- a/drivers/watchdog/sp5100_tco.h +++ b/drivers/watchdog/sp5100_tco.h @@ -52,7 +52,7 @@ #define SB800_PM_WATCHDOG_CONFIG 0x4C #define SB800_PCI_WATCHDOG_DECODE_EN (1 << 0) -#define SB800_PM_WATCHDOG_DISABLE (1 << 2) +#define SB800_PM_WATCHDOG_DISABLE (1 << 1) #define SB800_PM_WATCHDOG_SECOND_RES (3 << 0) #define SB800_ACPI_MMIO_DECODE_EN (1 << 0) #define SB800_ACPI_MMIO_SEL(1 << 1) -- 2.7.4
[PATCH 04/12] watchdog: sp5100_tco: Use standard error codes
By using standard error codes, we can identify and return more than one
error condition.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 11109ac959e2..0e816f2cdb07 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -345,12 +345,13 @@ static u8 sp5100_tco_read_pm_reg32(u8 index)
/*
* Init & exit routines
*/
-static unsigned char sp5100_tco_setupdevice(void)
+static int sp5100_tco_setupdevice(void)
{
struct pci_dev *dev = NULL;
const char *dev_name = NULL;
u32 val;
u8 base_addr;
+ int ret;
/* Match the PCI device */
for_each_pci_dev(dev) {
@@ -361,7 +362,7 @@ static unsigned char sp5100_tco_setupdevice(void)
}
if (!sp5100_tco_pci)
- return 0;
+ return -ENODEV;
pr_info("PCI Vendor ID: 0x%x, Device ID: 0x%x, Revision ID: 0x%x\n",
sp5100_tco_pci->vendor, sp5100_tco_pci->device,
@@ -383,7 +384,7 @@ static unsigned char sp5100_tco_setupdevice(void)
SP5100_PM_IOPORTS_SIZE, dev_name)) {
pr_err("I/O address 0x%04x already in use\n",
SP5100_IO_PM_INDEX_REG);
- goto exit;
+ return -EBUSY;
}
/*
@@ -433,6 +434,7 @@ static unsigned char sp5100_tco_setupdevice(void)
pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
pr_notice("failed to find MMIO address, giving up.\n");
+ ret = -ENODEV;
goto unreg_region;
setup_wdt:
@@ -441,6 +443,7 @@ static unsigned char sp5100_tco_setupdevice(void)
tcobase = ioremap(val, SP5100_WDT_MEM_MAP_SIZE);
if (!tcobase) {
pr_err("failed to get tcobase address\n");
+ ret = -ENOMEM;
goto unreg_mem_region;
}
@@ -470,14 +473,13 @@ static unsigned char sp5100_tco_setupdevice(void)
release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE);
/* Done */
- return 1;
+ return 0;
unreg_mem_region:
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
unreg_region:
release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE);
-exit:
- return 0;
+ return ret;
}
static int sp5100_tco_init(struct platform_device *dev)
@@ -488,8 +490,9 @@ static int sp5100_tco_init(struct platform_device *dev)
* Check whether or not the hardware watchdog is there. If found, then
* set it up.
*/
- if (!sp5100_tco_setupdevice())
- return -ENODEV;
+ ret = sp5100_tco_setupdevice();
+ if (ret)
+ return ret;
/* Check to see if last reboot was due to watchdog timeout */
pr_info("Last reboot was %striggered by watchdog.\n",
--
2.7.4
[PATCH 01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG,DATA_REG}
SP5100_IO_PM_INDEX_REG and SB800_IO_PM_INDEX_REG are used inconsistently
and define the same value. Just use SP5100_IO_PM_INDEX_REG throughout.
Do the same for SP5100_IO_PM_DATA_REG and SB800_IO_PM_DATA_REG.
Use helper functions to access the indexed registers.
Cc: Zoltán Böszörményi
Signed-off-by: Guenter Roeck
---
drivers/watchdog/sp5100_tco.c | 94 ++-
drivers/watchdog/sp5100_tco.h | 7 +---
2 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c5eeba..05f9d27a306a 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -48,7 +48,6 @@
static u32 tcobase_phys;
static u32 tco_wdt_fired;
static void __iomem *tcobase;
-static unsigned int pm_iobase;
static DEFINE_SPINLOCK(tco_lock); /* Guards the hardware */
static unsigned long timer_alive;
static char tco_expect_close;
@@ -132,25 +131,38 @@ static int tco_timer_set_heartbeat(int t)
return 0;
}
-static void tco_timer_enable(void)
+static u8 sp5100_tco_read_pm_reg8(u8 index)
+{
+ outb(index, SP5100_IO_PM_INDEX_REG);
+ return inb(SP5100_IO_PM_DATA_REG);
+}
+
+static void sp5100_tco_update_pm_reg8(u8 index, u8 reset, u8 set)
{
- int val;
+ u8 val;
+ outb(index, SP5100_IO_PM_INDEX_REG);
+ val = inb(SP5100_IO_PM_DATA_REG);
+ val &= reset;
+ val |= set;
+ outb(val, SP5100_IO_PM_DATA_REG);
+}
+
+static void tco_timer_enable(void)
+{
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
/* Set the Watchdog timer resolution to 1 sec */
- outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
- val = inb(SB800_IO_PM_DATA_REG);
- val |= SB800_PM_WATCHDOG_SECOND_RES;
- outb(val, SB800_IO_PM_DATA_REG);
+ sp5100_tco_update_pm_reg8(SB800_PM_WATCHDOG_CONFIG,
+ 0xff, SB800_PM_WATCHDOG_SECOND_RES);
/* Enable watchdog decode bit and watchdog timer */
- outb(SB800_PM_WATCHDOG_CONTROL, SB800_IO_PM_INDEX_REG);
- val = inb(SB800_IO_PM_DATA_REG);
- val |= SB800_PCI_WATCHDOG_DECODE_EN;
- val &= ~SB800_PM_WATCHDOG_DISABLE;
- outb(val, SB800_IO_PM_DATA_REG);
+ sp5100_tco_update_pm_reg8(SB800_PM_WATCHDOG_CONTROL,
+ ~SB800_PM_WATCHDOG_DISABLE,
+ SB800_PCI_WATCHDOG_DECODE_EN);
} else {
+ u32 val;
+
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
pci_read_config_dword(sp5100_tco_pci,
@@ -164,11 +176,9 @@ static void tco_timer_enable(void)
val);
/* Enable Watchdog timer and set the resolution to 1 sec */
- outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
- val = inb(SP5100_IO_PM_DATA_REG);
- val |= SP5100_PM_WATCHDOG_SECOND_RES;
- val &= ~SP5100_PM_WATCHDOG_DISABLE;
- outb(val, SP5100_IO_PM_DATA_REG);
+ sp5100_tco_update_pm_reg8(SP5100_PM_WATCHDOG_CONTROL,
+ ~SP5100_PM_WATCHDOG_DISABLE,
+ SP5100_PM_WATCHDOG_SECOND_RES);
}
}
@@ -321,6 +331,17 @@ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+static u8 sp5100_tco_read_pm_reg32(u8 index)
+{
+ u32 val = 0;
+ int i;
+
+ for (i = 3; i >= 0; i--)
+ val = (val << 8) + sp5100_tco_read_pm_reg8(index + i);
+
+ return val;
+}
+
/*
* Init & exit routines
*/
@@ -329,7 +350,7 @@ static unsigned char sp5100_tco_setupdevice(void)
struct pci_dev *dev = NULL;
const char *dev_name = NULL;
u32 val;
- u32 index_reg, data_reg, base_addr;
+ u8 base_addr;
/* Match the PCI device */
for_each_pci_dev(dev) {
@@ -351,35 +372,25 @@ static unsigned char sp5100_tco_setupdevice(void)
*/
if (tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
dev_name = SP5100_DEVNAME;
- index_reg = SP5100_IO_PM_INDEX_REG;
- data_reg = SP5100_IO_PM_DATA_REG;
base_addr = SP5100_PM_WATCHDOG_BASE;
} else {
dev_name = SB800_DEVNAME;
- index_reg = SB800_IO_PM_INDEX_REG;
- data_reg = SB800_IO_PM_DATA_REG;
base_addr = SB800_PM_WATCHDOG_BASE;
}
/* Request the IO ports used by this driver */
- pm_iobase = SP5100_IO_PM_INDEX_REG;
- if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
- pr_err("I/O address 0x%04x already in use\n", pm_iobase);
+ i
[PATCH v1] drm/i915: Try EDID bitbanging on HDMI after failed read
The ACK/NACK implementation as found in e.g. the G965 has the falling
clock edge and the release of the data line to ACK the received byte
happen at the same time.
Some HDMI-to-VGA converters apparently read the ACK not in the middle of
the clock high phase, but at the rising clock edge, so instead of an ACK
sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
transfer.
The bitbanging releases the data line for the ACK only 1/4 bit time after
the falling clock edge, so a slave will see the correct value no matter
if is samples at the rising or the falling clock edge or in the center.
Fallback to bitbanging is already done for the CRT connector.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685
Signed-off-by: Stefan Brüns
---
drivers/gpu/drm/i915/intel_hdmi.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 4dea833f9d1b..847cda4c017c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct edid *edid;
bool connected = false;
+ struct i2c_adapter *i2c;
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi->ddc_bus));
+ i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+ edid = drm_get_edid(connector, i2c);
+
+ if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
+ DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO
bit-banging\n");
+ intel_gmbus_force_bit(i2c, true);
+ edid = drm_get_edid(connector, i2c);
+ intel_gmbus_force_bit(i2c, false);
+ }
intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
--
2.15.1
Re: [PATCH 4.14 000/159] 4.14.9-stable review
On 24. des. 2017 20:37, Ivan Kozik wrote: On Fri, Dec 22, 2017 at 8:44 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late. Josh Poimboeuf x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit This is uncovering a very difficult-to-debug build failure with NVIDIA DKMS: with CONFIG_UNWINDER_ORC=y, out-of-tree modules hit this rule in scripts/Makefile.build: $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE and fail (here, at least) to build tools/objtool/objtool (note: I do have libelf-dev installed) After editing dkms.conf to do `make --debug=a -j1`, I see make output: Considering target file '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'. File '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o' does not exist. Looking for an implicit rule for '/var/lib/dkms/nvidia-current/387.34/build/nvidia/nv-gpu-numa.o'. [...] Trying rule prerequisite 'tools/objtool/objtool'. Looking for a rule with intermediate file 'tools/objtool/objtool'. Avoiding implicit rule recursion. then silently fail to build objtool, silently fail to build all the .o files, then continue until ld finally errors out trying to link nonexistent object files. If things look alright to you, and objtool is known to work with out-of-tree modules, and the Debian packaging just needs to be adjusted, please ignore; I figured I'd send this anyway because it was such a pain to debug. The linux-header packages dkms builds against need to include objtool when the ORC unwinder is enabled. Changing the default like that is a pretty big change for a stable release.
Re: [regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14
Hi! > > > > > 4.15-rcX is broken, but that had other problems so lets not go there. > > > > > > > > > > 4.14 is broken. > > > > > > > > And what exactly does happen? > > > > > > Suspend looks ok. I believe there's some reaction to power button, but > > > screen stays blank. I'll re-check that.. I'm in the middle of bisect > > > now. > > > > Ok, so suspend looks ok. On resume, "moon" LED goes off and power / > > bluetooth LEDs go on, but screen is black and no response to > > > > > anything. > > And it seems bad commit is > > commit 5620a0d1aacd554ebebcff373e31107bb1ef7769 > Author: Greg Kroah-Hartman > Date: Thu Sep 14 14:23:01 2017 -0700 > > firmware: delete in-kernel firmware > > Unfortuantely, it does not revert cleanly. I can't, because there's df85b2d767aad90fd2746f993fcd66dd322768f8 on top of it, partialy reverting it. Seems like 5620 was causing problems for other people before. And then there's huge mega-patch called "license cleanup" on top of that, which changes 11100 files (!) and makes work harder still. Can we go for full revert? Changelog """The last firmware change for the in-kernel firmware source code was back in 2013. Everyone has been relying on the out-of-tree linux-firmware package for a long long time.""" does not really explain what is going on there, and I'd certainly not expect silent breakage of suspend/resume. Clearly 5620a0 patch did not get nearly enough testing. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2] gpio: winbond: add driver
On Fri, Dec 22, 2017 at 07:58:49PM +0100, Maciej S. Szmigiero wrote:
>This commit adds GPIO driver for Winbond Super I/Os.
>
>Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is
>supported but in the future a support for other Winbond models, too, can
>be added to the driver.
>
>A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is
>GPIO1, bit 1 is GPIO2, etc.).
>One should be careful which ports one tinkers with since some might be
>managed by the firmware (for functions like powering on and off, sleeping,
>BIOS recovery, etc.) and some of GPIO port pins are physically shared with
>other devices included in the Super I/O chip.
>
>Signed-off-by: Maciej S. Szmigiero
>---
>Changes from v1:
>* Added SPDX license tag,
>
>* Removed gpiobase parameter,
>
>* Changed uint{8,16}_t types to u{8,16},
>
>* Added kerneldoc descriptions of driver structures,
>
>* Reformatted winbond_gpio_infos array fields so they are on separate
>lines,
>
>* Added few comments here and there as requested,
>
>* Moved port configuration code from separate winbond_gpio_configure_X()
>functions to one, common, parametrized winbond_gpio_configure_port()
>function.
>
>Didn't change "linux/errno.h" and "linux/gpio.h" includes to
>"linux/driver.h" since there is no such file in the current linux-gpio
>tree and so the driver would not compile with this change.
>Other GPIO drivers are using these former two include files, too.
Hi Maciej,
Sorry for the late response; it looks like you already made it to
version 2 of this patch from Linus' initial review. I'll leave the GPIO
subsystem related code to him, and stick to the ISA bus style LPC
interface communication in my review. ;)
First a quick clarification: I suspect Linus meant to suggest
+#include
as an alternative to the "linux/errno.h" and "linux/gpio.h" includes.
>
> drivers/gpio/Kconfig| 15 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-winbond.c | 758
> 3 files changed, 774 insertions(+)
> create mode 100644 drivers/gpio/gpio-winbond.c
>
>diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>index 395669bfcc26..3384a4675a0c 100644
>--- a/drivers/gpio/Kconfig
>+++ b/drivers/gpio/Kconfig
>@@ -698,6 +698,21 @@ config GPIO_TS5500
> blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
> LCD port.
>
>+config GPIO_WINBOND
>+ tristate "Winbond Super I/O GPIO support"
>+ help
>+This option enables support for GPIOs found on Winbond Super I/O
>+chips.
>+Currently, only W83627UHG (also known as Nuvoton NCT6627UD) is
>+supported.
>+
>+You will need to provide a module parameter "gpios", or a
>+boot-time parameter "gpio_winbond.gpios" with a bitmask of GPIO
>+ports to enable (bit 0 is GPIO1, bit 1 is GPIO2, etc.).
>+
>+To compile this driver as a module, choose M here: the module will
>+be called gpio-winbond.
>+
> config GPIO_WS16C48
> tristate "WinSystems WS16C48 GPIO support"
> depends on ISA_BUS_API
>diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
>index bc5dd673fa11..ff3d36d0a443 100644
>--- a/drivers/gpio/Makefile
>+++ b/drivers/gpio/Makefile
>@@ -139,6 +139,7 @@ obj-$(CONFIG_GPIO_VIPERBOARD) += gpio-viperboard.o
> obj-$(CONFIG_GPIO_VR41XX) += gpio-vr41xx.o
> obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
> obj-$(CONFIG_GPIO_WHISKEY_COVE) += gpio-wcove.o
>+obj-$(CONFIG_GPIO_WINBOND)+= gpio-winbond.o
> obj-$(CONFIG_GPIO_WM831X) += gpio-wm831x.o
> obj-$(CONFIG_GPIO_WM8350) += gpio-wm8350.o
> obj-$(CONFIG_GPIO_WM8994) += gpio-wm8994.o
>diff --git a/drivers/gpio/gpio-winbond.c b/drivers/gpio/gpio-winbond.c
>new file mode 100644
>index ..385855fb6c9e
>--- /dev/null
>+++ b/drivers/gpio/gpio-winbond.c
>@@ -0,0 +1,758 @@
>+// SPDX-License-Identifier: GPL-2.0+
>+/*
>+ * GPIO interface for Winbond Super I/O chips
>+ * Currently, only W83627UHG (Nuvoton NCT6627UD) is supported.
>+ *
>+ * Author: Maciej S. Szmigiero
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
I suggest taking a look at the "linux/isa.h" file. For ISA-style
communication such as you would have for LPC interface device, the ISA
subsystem can be more practical to utilize than creating a platform
device.
The 104-IDIO-16 GPIO driver can serve as a good template for ISA-style
drivers; you can find it at drivers/gpio/gpio-104-idio-16.c
>+
>+#define WB_GPIO_DRIVER_NAME "gpio-winbond"
>+
>+#define WB_SIO_BASE 0x2e
>+#define WB_SIO_BASE_HIGH 0x4e
>+
>+#define WB_SIO_EXT_ENTER_KEY 0x87
>+#define WB_SIO_EXT_EXIT_KEY 0xaa
>+
>+#define WB_SIO_CHIP_ID_W83627UHG 0xa230
>+#define WB_SIO_CHIP_ID_W83627UHG_MASK 0xfff0
>+
>+/* not an actual device number, just a value meaning 'no device' */
>+#define WB_SIO_DEV_NONE 0xff
>+
>+#define WB_SIO_DEV_UARTB 3
>+#define WB_SIO_UARTB_REG_ENABLE 0x30
>+#define WB_SIO_UARTB_ENABLE_ON 0
>+
>+#define
Re: Linux 4.15-rc5
Hi! > Ok, so it's not Sunday yet, but tomorrow is Christmas Eve, and while > I've been in the US for over two decades, we still celebrate Christmas > the only _right_ way - with Christmas Eve being the big day, and > Christmas Day being just for recovery. > > So I'm doing the rc5 release a day early, in order to not have to do > it during the actual Christmas festivities at our house. > Russell King (1): In -rc1, Russell introduced perl to arm build, causing locale warnings. Patch is available for more than month, with no reaction from Russell. https://lkml.org/lkml/2017/11/27/188 Can you pick it up directly? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14
Hi! > > And it seems bad commit is > > > > commit 5620a0d1aacd554ebebcff373e31107bb1ef7769 > > Author: Greg Kroah-Hartman > > Date: Thu Sep 14 14:23:01 2017 -0700 > > > > firmware: delete in-kernel firmware > > > > Unfortuantely, it does not revert cleanly. > > I can't, because there's df85b2d767aad90fd2746f993fcd66dd322768f8 on > top of it, partialy reverting it. Seems like 5620 was causing problems > for other people before. > > And then there's huge mega-patch called "license cleanup" on top of > that, which changes 11100 files (!) and makes work harder still. > > Can we go for full revert? And revert indeed fixes suspend on T40p on v4.15-rc5. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2] gpio: winbond: add driver
On 24.12.2017 23:42, William Breathitt Gray wrote:
> On Fri, Dec 22, 2017 at 07:58:49PM +0100, Maciej S. Szmigiero wrote:
>> This commit adds GPIO driver for Winbond Super I/Os.
>>
>> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is
>> supported but in the future a support for other Winbond models, too, can
>> be added to the driver.
>>
>> A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is
>> GPIO1, bit 1 is GPIO2, etc.).
>> One should be careful which ports one tinkers with since some might be
>> managed by the firmware (for functions like powering on and off, sleeping,
>> BIOS recovery, etc.) and some of GPIO port pins are physically shared with
>> other devices included in the Super I/O chip.
>>
>> Signed-off-by: Maciej S. Szmigiero
>> ---
>> Changes from v1:
(..)
>>
>> Didn't change "linux/errno.h" and "linux/gpio.h" includes to
>> "linux/driver.h" since there is no such file in the current linux-gpio
>> tree and so the driver would not compile with this change.
>> Other GPIO drivers are using these former two include files, too.
Hi William,
>
> Hi Maciej,
>
> Sorry for the late response; it looks like you already made it to
> version 2 of this patch from Linus' initial review. I'll leave the GPIO
> subsystem related code to him, and stick to the ISA bus style LPC
> interface communication in my review. ;)
>
> First a quick clarification: I suspect Linus meant to suggest
>
> +#include
>
> as an alternative to the "linux/errno.h" and "linux/gpio.h" includes.
Thanks for your overall input and clarification, will change these
headers to "linux/gpio/driver.h" in a respin.
(..)
>> diff --git a/drivers/gpio/gpio-winbond.c b/drivers/gpio/gpio-winbond.c
>> new file mode 100644
>> index ..385855fb6c9e
>> --- /dev/null
>> +++ b/drivers/gpio/gpio-winbond.c
>> @@ -0,0 +1,758 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * GPIO interface for Winbond Super I/O chips
>> + * Currently, only W83627UHG (Nuvoton NCT6627UD) is supported.
>> + *
>> + * Author: Maciej S. Szmigiero
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> I suggest taking a look at the "linux/isa.h" file. For ISA-style
> communication such as you would have for LPC interface device, the ISA
> subsystem can be more practical to utilize than creating a platform
> device.
>
> The 104-IDIO-16 GPIO driver can serve as a good template for ISA-style
> drivers; you can find it at drivers/gpio/gpio-104-idio-16.c
OK, will convert the driver to use the ISA instead of platform bus.
(..)
>> +static struct platform_device *winbond_gpio_pdev;
>> +
>> +/* probes chip at provided I/O base address, initializes and registers it */
>> +static int winbond_gpio_try_probe_init(u16 base)
>> +{
>> +u16 chip;
>> +int ret;
>> +
>> +ret = winbond_sio_enter(base);
>> +if (ret)
>> +return ret;
>> +
>> +chip = winbond_sio_reg_read(base, WB_SIO_REG_CHIP_MSB) << 8;
>> +chip |= winbond_sio_reg_read(base, WB_SIO_REG_CHIP_LSB);
>> +
>> +pr_notice(WB_GPIO_DRIVER_NAME
>> + ": chip ID at %hx is %.4x\n",
>> + (unsigned int)base,
>> + (unsigned int)chip);
>> +
>> +if ((chip & WB_SIO_CHIP_ID_W83627UHG_MASK) !=
>> +WB_SIO_CHIP_ID_W83627UHG) {
>> +pr_err(WB_GPIO_DRIVER_NAME
>> + ": not an our chip\n");
>> +winbond_sio_leave(base);
>> +return -ENODEV;
>> +}
>> +
>> +ret = winbond_gpio_configure(base);
>> +
>> +winbond_sio_leave(base);
>> +
>> +if (ret)
>> +return ret;
>> +
>> +winbond_gpio_pdev = platform_device_alloc(WB_GPIO_DRIVER_NAME, -1);
>> +if (winbond_gpio_pdev == NULL)
>> +return -ENOMEM;
>> +
>> +ret = platform_device_add_data(winbond_gpio_pdev,
>> + &base, sizeof(base));
>> +if (ret) {
>> +pr_err(WB_GPIO_DRIVER_NAME
>> + ": cannot add platform data\n");
>> +goto ret_put;
>> +}
>> +
>> +ret = platform_device_add(winbond_gpio_pdev);
>> +if (ret) {
>> +pr_err(WB_GPIO_DRIVER_NAME
>> + ": cannot add platform device\n");
>> +goto ret_put;
>> +}
>
> These platform_device functions can all go away if you take advantage of
> the ISA subsystem; the ISA driver handles multiple device allocations
> for you, and feeds each new device structure to the registered probe
> callback you set.
OK, I see (although the driver supports just one chip per system since
motherboards don't have multiple Super I/O chips).
>
> By the way Linus, this is the ISA bus equivalent of an "autodetect" you
> were hoping for in your version 1 responses. It is not a true autodetect
> in the sense that hardware does not determine the device, but rather the
> ISA subsystem fakes detection of the devices to feed to the probe
> callback so that the subsequent driver code f
Re: [linux-sunxi] [PATCH v4 2/2] media: V3s: Add support for Allwinner CSI.
On Fri, 22 Dec 2017 14:40:37 +0100
Philippe Ombredanne wrote:
> Yong,
>
> On Fri, Dec 22, 2017 at 11:21 AM, Priit Laes wrote:
> > On Fri, Dec 22, 2017 at 05:47:00PM +0800, Yong Deng wrote:
> >> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> >> and CSI1 is used for parallel interface. This is not documented in
> >> datasheet but by testing and guess.
> >>
> >> This patch implement a v4l2 framework driver for it.
> >>
> >> Currently, the driver only support the parallel interface. MIPI-CSI2,
> >> ISP's support are not included in this patch.
> >>
> >> Signed-off-by: Yong Deng
>
>
>
> >> --- /dev/null
> >> +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> >> @@ -0,0 +1,878 @@
> >> +/*
> >> + * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing).
> >> + * All rights reserved.
> >> + * Author: Yong Deng
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + */
>
>
> Would you mind using the new SPDX tags documented in Thomas patch set
> [1] rather than this fine but longer legalese?
Sure.
>
> >> +MODULE_LICENSE("GPL v2");
>
> Per module.h this means GPL2 only. This is not matching your top
> license above which is GPL2 or later.
> Please make sure your MODULE_LICENSE is consistent with the top level
> license.
OK. I misunderstood it.
>
>
> [1] https://lkml.org/lkml/2017/12/4/934
>
> --
> Cordially
> Philippe Ombredanne
Thanks,
Yong
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
hi Christophe and Greg, On 2017/12/24 16:55, christophe leroy wrote: > > > Le 23/12/2017 à 16:57, Guenter Roeck a écrit : >> On 12/23/2017 05:48 AM, Greg KH wrote: >>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: Hi all, When I tried to use devm_ioremap function and review related code, I found devm_ioremap and devm_ioremap_nocache is almost the same with each other, except one use ioremap while the other use ioremap_nocache. >>> >>> For all arches? Really? Look at MIPS, and x86, they have different >>> functions. >>> >> >> Both mips and x86 end up mapping the same function, but other arches don't. >> mn10300 is one where ioremap and ioremap_nocache are definitely different. > > alpha: identical > arc: identical > arm: identical > arm64: identical > cris: different<== > frv: identical > hexagone: identical > ia64: different<== > m32r: identical > m68k: identical > metag: identical > microblaze: identical > mips: identical > mn10300: different <== > nios: identical > openrisc: different<== > parisc: identical > riscv: identical > s390: identical > sh: identical > sparc: identical > tile: identical > um: rely on asm/generic > unicore32: identical > x86: identical > asm/generic (no mmu): identical Wow, that's correct, sorry for I have just checked the main archs, I means x86,arm, arm64, mips. However, I stall have no idea about why these 4 archs want different ioremap function with others. Drivers seems cannot aware this? If driver call ioremap want he really want for there 4 archs, cache or nocache? > > So 4 among all arches seems to have ioremap() and ioremap_nocache() being > different. > > Could we have a define set by the 4 arches on which ioremap() and > ioremap_nocache() are different, something like > HAVE_DIFFERENT_IOREMAP_NOCACHE ? Then, what the HAVE_DIFFERENT_IOREMAP_NOCACHE is uesed for ? Thanks Yisheng > > Christophe > >> >> Guenter >> While ioremap's default function is ioremap_nocache, so devm_ioremap_nocache also have the same function with devm_ioremap, which can just be killed to reduce the size of devres.o(from 20304 bytes to 18992 bytes in my compile environment). I have posted two versions, which use macro instead of function for devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill devm_ioremap_nocache for no need to keep a macro around for the duplicate thing. So here comes v3 and please help to review. >>> >>> I don't think this can be done, what am I missing? These functions are >>> not identical, sorry for missing that before. Never mind, I should checked all the arches, sorry about that. >>> >>> thanks, >>> >>> greg k-h >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le > logiciel antivirus Avast. > https://www.avast.com/antivirus > > > . >
[PATCH net-next v8 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
DT bindings for the AVE ethernet controller found on Socionext's
UniPhier platforms.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Jassi Brar
Acked-by: Rob Herring
---
.../bindings/net/socionext,uniphier-ave4.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
new file mode 100644
index 000..8b03668
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
@@ -0,0 +1,47 @@
+* Socionext AVE ethernet controller
+
+This describes the devicetree bindings for AVE ethernet controller
+implemented on Socionext UniPhier SoCs.
+
+Required properties:
+ - compatible: Should be
+ - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
+ - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
+ - "socionext,uniphier-ld11-ave4" : for LD11 SoC
+ - "socionext,uniphier-ld20-ave4" : for LD20 SoC
+ - reg: Address where registers are mapped and size of region.
+ - interrupts: Should contain the MAC interrupt.
+ - phy-mode: See ethernet.txt in the same directory. Allow to choose
+ "rgmii", "rmii", or "mii" according to the PHY.
+ - phy-handle: Should point to the external phy device.
+ See ethernet.txt file in the same directory.
+ - clocks: A phandle to the clock for the MAC.
+
+Optional properties:
+ - resets: A phandle to the reset control for the MAC.
+ - local-mac-address: See ethernet.txt in the same directory.
+
+Required subnode:
+ - mdio: A container for child nodes representing phy nodes.
+ See phy.txt in the same directory.
+
+Example:
+
+ ether: ethernet@6500 {
+ compatible = "socionext,uniphier-ld20-ave4";
+ reg = <0x6500 0x8500>;
+ interrupts = <0 66 4>;
+ phy-mode = "rgmii";
+ phy-handle = <ðphy>;
+ clocks = <&sys_clk 6>;
+ resets = <&sys_rst 6>;
+ local-mac-address = [00 00 00 00 00 00];
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy: ethphy@1 {
+ reg = <1>;
+ };
+ };
+ };
--
2.7.4
[PATCH net-next v8 2/2] net: ethernet: socionext: add AVE ethernet driver
The UniPhier platform from Socionext provides the AVE ethernet controller that includes MAC and MDIO bus supporting RGMII/RMII modes. The controller is named AVE. Signed-off-by: Kunihiko Hayashi Signed-off-by: Jassi Brar Reviewed-by: Andrew Lunn --- drivers/net/ethernet/Kconfig |1 + drivers/net/ethernet/Makefile|1 + drivers/net/ethernet/socionext/Kconfig | 22 + drivers/net/ethernet/socionext/Makefile |5 + drivers/net/ethernet/socionext/sni_ave.c | 1736 ++ 5 files changed, 1765 insertions(+) create mode 100644 drivers/net/ethernet/socionext/Kconfig create mode 100644 drivers/net/ethernet/socionext/Makefile create mode 100644 drivers/net/ethernet/socionext/sni_ave.c diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig index c604213..d50519e 100644 --- a/drivers/net/ethernet/Kconfig +++ b/drivers/net/ethernet/Kconfig @@ -170,6 +170,7 @@ source "drivers/net/ethernet/sis/Kconfig" source "drivers/net/ethernet/sfc/Kconfig" source "drivers/net/ethernet/sgi/Kconfig" source "drivers/net/ethernet/smsc/Kconfig" +source "drivers/net/ethernet/socionext/Kconfig" source "drivers/net/ethernet/stmicro/Kconfig" source "drivers/net/ethernet/sun/Kconfig" source "drivers/net/ethernet/tehuti/Kconfig" diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile index 39f62733..6cf5ade 100644 --- a/drivers/net/ethernet/Makefile +++ b/drivers/net/ethernet/Makefile @@ -82,6 +82,7 @@ obj-$(CONFIG_SFC) += sfc/ obj-$(CONFIG_SFC_FALCON) += sfc/falcon/ obj-$(CONFIG_NET_VENDOR_SGI) += sgi/ obj-$(CONFIG_NET_VENDOR_SMSC) += smsc/ +obj-$(CONFIG_NET_VENDOR_SOCIONEXT) += socionext/ obj-$(CONFIG_NET_VENDOR_STMICRO) += stmicro/ obj-$(CONFIG_NET_VENDOR_SUN) += sun/ obj-$(CONFIG_NET_VENDOR_TEHUTI) += tehuti/ diff --git a/drivers/net/ethernet/socionext/Kconfig b/drivers/net/ethernet/socionext/Kconfig new file mode 100644 index 000..3a1829e --- /dev/null +++ b/drivers/net/ethernet/socionext/Kconfig @@ -0,0 +1,22 @@ +config NET_VENDOR_SOCIONEXT + bool "Socionext ethernet drivers" + default y + ---help--- + Option to select ethernet drivers for Socionext platforms. + + Note that the answer to this question doesn't directly affect the + kernel: saying N will just cause the configurator to skip all + the questions about Socionext devices. If you say Y, you will be asked + for your specific card in the following questions. + +if NET_VENDOR_SOCIONEXT + +config SNI_AVE + tristate "Socionext AVE ethernet support" + depends on (ARCH_UNIPHIER || COMPILE_TEST) && OF + select PHYLIB + ---help--- + Driver for gigabit ethernet MACs, called AVE, in the + Socionext UniPhier family. + +endif #NET_VENDOR_SOCIONEXT diff --git a/drivers/net/ethernet/socionext/Makefile b/drivers/net/ethernet/socionext/Makefile new file mode 100644 index 000..ab83df6 --- /dev/null +++ b/drivers/net/ethernet/socionext/Makefile @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for all ethernet ip drivers on Socionext platforms +# +obj-$(CONFIG_SNI_AVE) += sni_ave.o diff --git a/drivers/net/ethernet/socionext/sni_ave.c b/drivers/net/ethernet/socionext/sni_ave.c new file mode 100644 index 000..0925675 --- /dev/null +++ b/drivers/net/ethernet/socionext/sni_ave.c @@ -0,0 +1,1736 @@ +// SPDX-License-Identifier: GPL-2.0 +/** + * sni_ave.c - Socionext UniPhier AVE ethernet driver + * Copyright 2014 Panasonic Corporation + * Copyright 2015-2017 Socionext Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* General Register Group */ +#define AVE_IDR0x000 /* ID */ +#define AVE_VR 0x004 /* Version */ +#define AVE_GRR0x008 /* Global Reset */ +#define AVE_CFGR 0x00c /* Configuration */ + +/* Interrupt Register Group */ +#define AVE_GIMR 0x100 /* Global Interrupt Mask */ +#define AVE_GISR 0x104 /* Global Interrupt Status */ + +/* MAC Register Group */ +#define AVE_TXCR 0x200 /* TX Setup */ +#define AVE_RXCR 0x204 /* RX Setup */ +#define AVE_RXMAC1R0x208 /* MAC address (lower) */ +#define AVE_RXMAC2R0x20c /* MAC address (upper) */ +#define AVE_MDIOCTR0x214 /* MDIO Control */ +#define AVE_MDIOAR 0x218 /* MDIO Address */ +#define AVE_MDIOWDR0x21c /* MDIO Data */ +#define AVE_MDIOSR 0x220 /* MDIO Status */ +#define AVE_MDIORDR0x224 /* MDIO Rd Data */ + +/* Descriptor Control Register Group */ +#define AVE_DESCC 0x300 /* Descriptor Control */ +#define AVE_TXDC 0x304 /* TX Descriptor Configuration */ +#define AVE_RXDC0 0x308 /*
[PATCH net-next v8 0/2] add UniPhier AVE ethernet support
This series adds support for Socionext AVE ethernet controller implemented
on UniPhier SoCs. This driver supports RGMII/RMII modes.
v7: https://www.spinics.net/lists/netdev/msg473896.html
The PHY patch included in v1 has already separated in:
http://www.spinics.net/lists/netdev/msg454595.html
Changes since v7:
- dt-bindings: fix mdio subnode description
Changes since v6:
- sort the order of local variables from longest to shortest line
- fix ave_probe() which calls register_netdev() at the end of initialization
- dt-bindings: remove phy node descriptions in mdio node
Changes since v5:
- replace license boilerplate with SPDX Identifier
- remove inline directives and an unused function
Changes since v4:
- fix larger integer warning on AVE_PFMBYTE_MASK0
Changes since v3:
- remove checking dma address and use dma_set_mask() to restirct address
- replace ave_mdio_busywait() with read_poll_timeout()
- replace functions to access to registers with readl/writel() directly
- replace a function to access to macaddr with ave_hw_write_macaddr()
- change return value of ave_dma_map() to error value
- move mdiobus_unregister() from ave_remove() to ave_uninit()
- eliminate else block at the end of ave_dma_map()
- add mask definitions for packet filter
- sort bitmap definitions in descending order
- add error check to some functions
- rename and sort functions to clear sub-categories
- fix error value consistency
- remove unneeded initializers
- change type of constant arrays
Changes since v2:
- replace clk_get() with devm_clk_get()
- replace reset_control_get() with devm_reset_control_get_optional_shared()
- add error return when the error occurs on the above *_get functions
- sort soc data and compatible strings
- remove clearly obvious comments
- modify dt-bindings document consistent with these modifications
Changes since v1:
- add/remove devicetree properties and sub-node
- remove "internal-phy-interrupt" and "desc-bits" property
- add SoC data structures based on compatible strings
- add node operation to apply "mdio" sub-node
- add support for features
- add support for {get,set}_pauseparam and pause frame operations
- add support for ndo_get_stats64 instead of ndo_get_stats
- replace with desiable functions
- replace check for valid phy_mode with phy_interface{_mode}_is_rgmii()
- replace phy attach message with phy_attached_info()
- replace 32bit operation with {upper,lower}_32_bits() on ave_wdesc_addr()
- replace nway_reset and get_link with generic functions
- move operations to proper functions
- move phy_start_aneg() to ndo_open,
and remove unnecessary PHY interrupt operations
See http://www.spinics.net/lists/netdev/msg454590.html
- move irq initialization and descriptor memory allocation to ndo_open
- move initialization of reset and clock and mdiobus to ndo_init
- fix skbuffer operations
- fix skb alignment operations and add Rx buffer adjustment for descriptor
See http://www.spinics.net/lists/netdev/msg456014.html
- add error returns when dma_map_single() failed
- clean up code structures
- clean up wait-loop and wake-queue conditions
- add ave_wdesc_addr() and offset definitions
- add ave_macaddr_init() to clean up mac-address operation
- fix checking whether Tx entry is not enough
- fix supported features of phydev
- add necessary free/disable operations
- add phydev check on ave_{get,set}_wol()
- remove netif_carrier functions, phydev initializer, and Tx budget check
- change obsolate codes
- replace ndev->{base_addr,irq} with the members of ave_private
- rename goto labels and mask definitions, and remove unused codes
Kunihiko Hayashi (2):
dt-bindings: net: add DT bindings for Socionext UniPhier AVE
net: ethernet: socionext: add AVE ethernet driver
.../bindings/net/socionext,uniphier-ave4.txt | 47 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/socionext/Kconfig | 22 +
drivers/net/ethernet/socionext/Makefile|5 +
drivers/net/ethernet/socionext/sni_ave.c | 1736
6 files changed, 1812 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
create mode 100644 drivers/net/ethernet/socionext/Kconfig
create mode 100644 drivers/net/ethernet/socionext/Makefile
create mode 100644 drivers/net/ethernet/socionext/sni_ave.c
--
2.7.4
Re: [PATCH 01/12] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL
On 2017/12/24 17:27, Christian König wrote:
> Am 24.12.2017 um 07:14 schrieb Tan Xiaojun:
>> From: Michal Srb
>>
>> The io_mem_pfn field was added in commit
>> ea642c3216cb2a60d1c0e760ae47ee85c9c16447
>> and is called unconditionally. However, not all drivers were updated to set
>> it.
>>
>> Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.
>>
>> Signed-off-by: Michal Srb
>> ---
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index c8ebb75..e25a99b 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
>> if (bo->mem.bus.is_iomem) {
>> /* Iomem should not be marked encrypted */
>> cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
>> -pfn = bdev->driver->io_mem_pfn(bo, page_offset);
>> +if (bdev->driver->io_mem_pfn)
>> +pfn = bdev->driver->io_mem_pfn(bo, page_offset);
>> +else
>> +pfn = ttm_bo_default_io_mem_pfn(bo, page_offset);
>
> Please move this check into a new function ttm_bo_io_mem_pfn().
>
> You can then move the calculation of ttm_bo_default_io_mem_pfn() into this
> new function in patch #12 as well.
>
> Regards,
> Christian.
>
OK. Thank you for your reply. I will modify it and send v2.
Thanks.
Xiaojun.
>> } else {
>> page = ttm->pages[page_offset];
>> if (unlikely(!page && i == 0)) {
>
>
> .
>
RE: [PATCH] arm: imx: suspend/resume: use outer_disable/resume
Hi All, Ping... > -Original Message- > From: Peng Fan > Sent: Sunday, December 10, 2017 8:07 PM > To: shawn...@kernel.org > Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > van.free...@gmail.com; Peng Fan ; Sascha Hauer > ; Fabio Estevam ; Russell > King ; A.s. Dong > Subject: [PATCH] arm: imx: suspend/resume: use outer_disable/resume > > Use outer_disable/resume for suspend/resume. > With the two APIs used, code could be simplified and easy to extend to > introduce l2c_write_sec for i.MX platforms when moving Linux Kernel runs in > non-secure world. > > Signed-off-by: Peng Fan > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Fabio Estevam > Cc: Russell King > Cc: Dong Aisheng > --- > arch/arm/mach-imx/pm-imx6.c | 2 ++ > arch/arm/mach-imx/suspend-imx6.S | 24 > 2 files changed, 2 insertions(+), 24 deletions(-) > > diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c > index ecdf071653d4..153a0afc7645 100644 > --- a/arch/arm/mach-imx/pm-imx6.c > +++ b/arch/arm/mach-imx/pm-imx6.c > @@ -392,8 +392,10 @@ static int imx6q_pm_enter(suspend_state_t state) > imx6_enable_rbc(true); > imx_gpc_pre_suspend(true); > imx_anatop_pre_suspend(); > + outer_disable(); > /* Zzz ... */ > cpu_suspend(0, imx6q_suspend_finish); > + outer_resume(); > if (cpu_is_imx6q() || cpu_is_imx6dl()) > imx_smp_prepare(); > imx_anatop_post_resume(); > diff --git a/arch/arm/mach-imx/suspend-imx6.S b/arch/arm/mach- > imx/suspend-imx6.S > index 76ee2ceec8d5..324f6b165e82 100644 > --- a/arch/arm/mach-imx/suspend-imx6.S > +++ b/arch/arm/mach-imx/suspend-imx6.S > @@ -74,24 +74,6 @@ > > .align 3 > > - .macro sync_l2_cache > - > - /* sync L2 cache to drain L2's buffers to DRAM. */ > -#ifdef CONFIG_CACHE_L2X0 > - ldr r11, [r0, #PM_INFO_MX6Q_L2_V_OFFSET] > - teq r11, #0 > - beq 6f > - mov r6, #0x0 > - str r6, [r11, #L2X0_CACHE_SYNC] > -1: > - ldr r6, [r11, #L2X0_CACHE_SYNC] > - andsr6, r6, #0x1 > - bne 1b > -6: > -#endif > - > - .endm > - > .macro resume_mmdc > > /* restore MMDC IO */ > @@ -185,9 +167,6 @@ ENTRY(imx6_suspend) > str r9, [r11, #MX6Q_SRC_GPR1] > str r1, [r11, #MX6Q_SRC_GPR2] > > - /* need to sync L2 cache before DSM. */ > - sync_l2_cache > - > ldr r11, [r0, #PM_INFO_MX6Q_MMDC_V_OFFSET] > /* >* put DDR explicitly into self-refresh and @@ -342,8 +321,5 @@ > ENDPROC(imx6_suspend) > > ENTRY(v7_cpu_resume) > bl v7_invalidate_l1 > -#ifdef CONFIG_CACHE_L2X0 > - bl l2c310_early_resume > -#endif > b cpu_resume > ENDPROC(v7_cpu_resume) > -- > 2.14.1 Thanks, Peng.
Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations
"Paul E. McKenney" writes: > On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote: >> Minchan Kim writes: >> >> > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: >> >> Minchan Kim writes: >> >> >> >> > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote: >> >> >> From: Huang Ying >> >> >> >> >> >> When the swapin is performed, after getting the swap entry information >> >> >> from the page table, system will swap in the swap entry, without any >> >> >> lock held to prevent the swap device from being swapoff. This may >> >> >> cause the race like below, >> >> >> >> >> >> CPU 1 CPU 2 >> >> >> - - >> >> >>do_swap_page >> >> >> swapin_readahead >> >> >>__read_swap_cache_async >> >> >> swapoff swapcache_prepare >> >> >> p->swap_map = NULL __swap_duplicate >> >> >> p->swap_map[?] /* !!! NULL >> >> >> pointer access */ >> >> >> >> >> >> Because swapoff is usually done when system shutdown only, the race >> >> >> may not hit many people in practice. But it is still a race need to >> >> >> be fixed. >> >> >> >> >> >> To fix the race, get_swap_device() is added to check whether the >> >> >> specified swap entry is valid in its swap device. If so, it will keep >> >> >> the swap entry valid via preventing the swap device from being >> >> >> swapoff, until put_swap_device() is called. >> >> >> >> >> >> Because swapoff() is very race code path, to make the normal path runs >> >> >> as fast as possible, RCU instead of reference count is used to >> >> >> implement get/put_swap_device(). From get_swap_device() to >> >> >> put_swap_device(), the RCU read lock is held, so synchronize_rcu() in >> >> >> swapoff() will wait until put_swap_device() is called. >> >> >> >> >> >> In addition to swap_map, cluster_info, etc. data structure in the >> >> >> struct swap_info_struct, the swap cache radix tree will be freed after >> >> >> swapoff, so this patch fixes the race between swap cache looking up >> >> >> and swapoff too. >> >> >> >> >> >> Cc: Hugh Dickins >> >> >> Cc: Paul E. McKenney >> >> >> Cc: Minchan Kim >> >> >> Cc: Johannes Weiner >> >> >> Cc: Tim Chen >> >> >> Cc: Shaohua Li >> >> >> Cc: Mel Gorman >> >> >> Cc: "Jrme Glisse" >> >> >> Cc: Michal Hocko >> >> >> Cc: Andrea Arcangeli >> >> >> Cc: David Rientjes >> >> >> Cc: Rik van Riel >> >> >> Cc: Jan Kara >> >> >> Cc: Dave Jiang >> >> >> Cc: Aaron Lu >> >> >> Signed-off-by: "Huang, Ying" >> >> >> >> >> >> Changelog: >> >> >> >> >> >> v4: >> >> >> >> >> >> - Use synchronize_rcu() in enable_swap_info() to reduce overhead of >> >> >> normal paths further. >> >> > >> >> > Hi Huang, >> >> >> >> Hi, Minchan, >> >> >> >> > This version is much better than old. To me, it's due to not rcu, >> >> > srcu, refcount thing but it adds swap device dependency(i.e., get/put) >> >> > into every swap related functions so users who don't interested on swap >> >> > don't need to care of it. Good. >> >> > >> >> > The problem is caused by freeing by swap related-data structure >> >> > *dynamically* while old swap logic was based on static data >> >> > structure(i.e., never freed and the verify it's stale). >> >> > So, I reviewed some places where use PageSwapCache and swp_entry_t >> >> > which could make access of swap related data structures. >> >> > >> >> > A example is __isolate_lru_page >> >> > >> >> > It calls page_mapping to get a address_space. >> >> > What happens if the page is on SwapCache and raced with swapoff? >> >> > The mapping got could be disappeared by the race. Right? >> >> >> >> Yes. We should think about that. Considering the file cache pages, the >> >> address_space backing the file cache pages may be freed dynamically too. >> >> So to use page_mapping() return value for the file cache pages, some >> >> kind of locking is needed to guarantee the address_space isn't freed >> >> under us. Page may be locked, or under writeback, or some other locks >> > >> > I didn't look at the code in detail but I guess every file page should >> > be freed before the address space destruction and page_lock/lru_lock makes >> > the work safe, I guess. So, it wouldn't be a problem. >> > >> > However, in case of swapoff, it doesn't remove pages from LRU list >> > so there is no lock to prevent the race at this moment. :( >> >> Take a look at file cache pages and file cache address_space freeing >> code path. It appears that similar situation is possible for them too. >> >> The file cache pages will be delete from file cache address_space before >> address_space (embedded in inode) is freed. But they will be deleted >> from LRU list only when its refcount dropped to zero, please take a look >> at put_page() and release_pages(). While address_space will be freed >> a
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
On 2017/12/24 17:05, christophe leroy wrote:
>
>
> Le 23/12/2017 à 14:48, Greg KH a écrit :
>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
>>> Hi all,
>>>
>>> When I tried to use devm_ioremap function and review related code, I found
>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
>>> except one use ioremap while the other use ioremap_nocache.
>>
>> For all arches? Really? Look at MIPS, and x86, they have different
>> functions.
>>
>>> While ioremap's
>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the
>>> same function with devm_ioremap, which can just be killed to reduce the size
>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
>>>
>>> I have posted two versions, which use macro instead of function for
>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate
>>> thing. So here comes v3 and please help to review.
>>
>> I don't think this can be done, what am I missing? These functions are
>> not identical, sorry for missing that before.
>
> devm_ioremap() and devm_ioremap_nocache() are quite similar, both use
> devm_ioremap_release() for the release, why not just defining:
>
> static void __iomem *__devm_ioremap(struct device *dev, resource_size_t
> offset,
>resource_size_t size, bool nocache)
> {
> [...]
> if (nocache)
> addr = ioremap_nocache(offset, size);
> else
> addr = ioremap(offset, size);
> [...]
> }
>
> then in include/linux/io.h
>
> static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t
> offset,
>resource_size_t size)
> {return __devm_ioremap(dev, offset, size, false);}
>
> static inline void __iomem *devm_ioremap_nocache(struct device *dev,
> resource_size_t offset,
>resource_size_t size);
> {return __devm_ioremap(dev, offset, size, true);}
Yeah, this seems good to me, right now we have devm_ioremap, devm_ioremap_wc,
devm_ioremap_nocache
May be we can use an enum like:
typedef enum {
DEVM_IOREMAP = 0,
DEVM_IOREMAP_NOCACHE,
DEVM_IOREMAP_WC,
} devm_ioremap_type;
static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t
offset,
resource_size_t size)
{return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}
static inline void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}
static inline void __iomem *devm_ioremap_wc(struct device *dev,
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}
static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size, devm_ioremap_type type)
{
void __iomem **ptr, *addr = NULL;
[...]
switch (type){
case DEVM_IOREMAP:
addr = ioremap(offset, size);
break;
case DEVM_IOREMAP_NOCACHE:
addr = ioremap_nocache(offset, size);
break;
case DEVM_IOREMAP_WC:
addr = ioremap_wc(offset, size);
break;
}
[...]
}
Thanks
Yisheng
>
> Christophe
>
>>
>> thanks,
>>
>> greg k-h
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> .
>
Re: [PATCH v3 08/27] PCI: replace devm_ioremap_nocache with devm_ioremap
Hi Fabio, Thanks for you reviewing and comment! On 2017/12/23 20:23, Fabio Estevam wrote: > On Sat, Dec 23, 2017 at 8:58 AM, Yisheng Xie wrote: >> Default ioremap is ioremap_nocache, so devm_ioremap has the same >> function with devm_ioremap_nocache, which can just be killed to >> save the size of devres.o >> >> This patch is to use use devm_ioremap instead of devm_ioremap_nocache, >> which should not have any function change but prepare for killing >> devm_ioremap_nocache. >> >> Cc: Bjorn Helgaas >> Cc: linux-...@vger.kernel.org >> Signed-off-by: Yisheng Xie >> --- >> drivers/pci/dwc/pci-dra7xx.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c >> index e77a4cee..3f3712a 100644 >> --- a/drivers/pci/dwc/pci-dra7xx.c >> +++ b/drivers/pci/dwc/pci-dra7xx.c >> @@ -637,7 +637,7 @@ static int __init dra7xx_pcie_probe(struct >> platform_device *pdev) >> } >> >> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ti_conf"); >> - base = devm_ioremap_nocache(dev, res->start, resource_size(res)); >> + base = devm_ioremap(dev, res->start, resource_size(res)); > > You could also consider using devm_ioremap_resource(), which checks > whether the resource is NULL and it is a bit shorter: > > base = devm_ioremap_resource(dev, res); > if (IS_ERR(base)) >return PTR_ERR(base); Yeah, I will check if all the archs have the same ioremap and ioremap_noache, first. If it is so, I will take your suggestion. Thanks Yisheng > > >> >> -- >> 1.8.3.1 >> > > . >
Re: [PATCH v3 27/27] devres: kill devm_ioremap_nocache
On 2017/12/23 21:45, Greg KH wrote:
> On Sat, Dec 23, 2017 at 07:02:59PM +0800, Yisheng Xie wrote:
>> --- a/lib/devres.c
>> +++ b/lib/devres.c
>> @@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev,
>> resource_size_t offset,
>> EXPORT_SYMBOL(devm_ioremap);
>>
>> /**
>> - * devm_ioremap_nocache - Managed ioremap_nocache()
>> - * @dev: Generic device to remap IO address for
>> - * @offset: Resource address to map
>> - * @size: Size of map
>> - *
>> - * Managed ioremap_nocache(). Map is automatically unmapped on driver
>> - * detach.
>> - */
>> -void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t
>> offset,
>> - resource_size_t size)
>> -{
>> -void __iomem **ptr, *addr;
>> -
>> -ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
>> -if (!ptr)
>> -return NULL;
>> -
>> -addr = ioremap_nocache(offset, size);
>
> Wait, devm_ioremap() calls ioremap(), not ioremap_nocache(), are you
> _SURE_ that these are all identical? For all arches? If so, then
> ioremap_nocache() can also be removed, right?
Yeah, As Christophe pointed out, that 4 archs do not have the same function.
But I do not why they do not want do the same thing. Driver may no know about
this? right?
>
> In my quick glance, I don't think you can do this series at all :(
Yes, maybe should take Christophe suggestion and use a bool or enum to
distinguish them?
Thanks
Yisheng
>
> greg k-h
>
> .
>
Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
On 2017/12/23 6:31, Ross Zwisler wrote: > On Fri, Dec 22, 2017 at 08:39:41AM +0530, Anshuman Khandual wrote: >> On 12/14/2017 07:40 AM, Ross Zwisler wrote: > <> >>> We solve this issue by providing userspace with performance information on >>> individual memory ranges. This performance information is exposed via >>> sysfs: >>> >>> # grep . mem_tgt2/* mem_tgt2/local_init/* 2>/dev/null >>> mem_tgt2/firmware_id:1 >>> mem_tgt2/is_cached:0 >>> mem_tgt2/local_init/read_bw_MBps:40960 >>> mem_tgt2/local_init/read_lat_nsec:50 >>> mem_tgt2/local_init/write_bw_MBps:40960 >>> mem_tgt2/local_init/write_lat_nsec:50 > <> >> We will enlist properties for all possible "source --> target" on the system? > > Nope, just 'local' initiator/target pairs. I talk about the reasoning for > this in the cover letter for patch 3: > > https://lists.01.org/pipermail/linux-nvdimm/2017-December/013574.html > >> Right now it shows only bandwidth and latency properties, can it accommodate >> other properties as well in future ? > > We also have an 'is_cached' attribute for the memory targets if they are > involved in a caching hierarchy, but right now those are all the things we > expose. We can potentially expose whatever we want that is present in the > HMAT, but those seemed like a good start. > > I noticed that in your presentation you had some other examples of attributes > you cared about: > > * reliability > * power consumption > * density > > The HMAT doesn't provide this sort of information at present, but we > could/would add them to sysfs if the HMAT ever grew support for them. > >>> This allows applications to easily find the memory that they want to use. >>> We expect that the existing NUMA APIs will be enhanced to use this new >>> information so that applications can continue to use them to select their >>> desired memory. >> >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be used explicitly from the user space. >> Here is the link to the proposal if you feel interested. The proposal is >> very intrusive and also I dont have a RFC for it yet for discussion here. >> >> https://linuxplumbersconf.org/2017/ocw//system/presentations/4656/original/Hierarchical_NUMA_Design_Plumbers_2017.pdf >> >> Problem is, designing the sysfs interface for memory attribute detection >> from user space without first thinking about redesigning the NUMA for >> heterogeneous memory may not be a good idea. Will look into this further. > > I took another look at your presentation, and overall I think that if/when a > NUMA redesign like this takes place ACPI systems with HMAT tables will be able > to participate. But I think we are probably a ways away from that, and like I I'm afraid not, there are cache-coherent bus like CCIX/OpenCAPI come out soon. No matter to say System-on-Chip already with internal bus linked DDR、HBM、CPU、Accelerator.. > said in my previous mail ACPI systems with memory-only NUMA nodes are going to > exist and need to be supported with the current NUMA scheme. Hence I don't And not only memory-only, but the accelerators can also be a master like CPU. > think that this patch series conflicts with your proposal. Didn't see conflict neither, but perhaps we should think for a longer-term solution and cover more situations/platforms. Anshuman's proposal is really a good start point to us. Cheers, Bob Liu
[RFC] dmaengine: pl330: fix a race condition in case of threaded irqs
I found this problem below, and I now understand why it happens, but I'm not 100% sure what is the best way to fix it. When booting up with "threadirqs" in command line, all irq handlers of the DMA controller pl330 will be threaded forcedly. These threads will race for the same list, pl330->req_done. Before the callback, the spinlock was released. And after it, the spinlock was taken. This opened an race window where another threaded irq handler could steal the spinlock and be permitted to delete entries of the list, pl330->req_done. If the later deleted an entry that was still referred to by the former, there would be a kernel panic when the former was scheduled and tried to get the next sibling of the deleted entry. The scenario could be depicted as below: Thread: T1 pl330->req_done Thread: T2 | | | | -A-B-C-D- | Locked | | | | Waiting Del A | | | -B-C-D- | Unlocked| | | | Locked Waiting | | | |Del B | | | | -C-D- Unlocked Waiting | | | Locked | get C via B \ - Kernel panic The kernel panic looked like as below: Unable to handle kernel paging request at virtual address dead0108 pgd = ff8008c9e000 [dead0108] *pgd=00027fffe003, *pud=00027fffe003, *pmd= Internal error: Oops: 9644 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 85 Comm: irq/59-6633 Not tainted 4.8.24-WR9.0.0.12_standard #2 Hardware name: Broadcom NS2 SVK (DT) task: ffc1f5cc3c00 task.stack: ffc1f5ce PC is at pl330_irq_handler+0x27c/0x390 LR is at pl330_irq_handler+0x2a8/0x390 pc : [] lr : [] pstate: 81c5 sp : ffc1f5ce3d00 x29: ffc1f5ce3d00 x28: 0140 x27: ffc1f5c530b0 x26: dead0100 x25: dead0200 x24: 00418958 x23: 0001 x22: ffc1f5ccd668 x21: ffc1f5ccd590 x20: ffc1f5ccd418 x19: dead0060 x18: 0001 x17: 0007 x16: 0001 x15: x14: x13: x12: x11: 0001 x10: 0840 x9 : ffc1f5ce x8 : ffc1f5cc3338 x7 : ff8008ce2020 x6 : x5 : x4 : 0001 x3 : dead0200 x2 : dead0100 x1 : 0140 x0 : ffc1f5ccd590 Process irq/59-6633 (pid: 85, stack limit = 0xffc1f5ce0020) Stack: (0xffc1f5ce3d00 to 0xffc1f5ce4000) 3d00: ffc1f5ce3d80 ff80080f09d0 ffc1f5ca0c00 ffc1f6f7c600 3d20: ffc1f5ce ffc1f6f7c600 ffc1f5ca0c00 ff80080f0998 3d40: ffc1f5ce ff80080f 3d60: ff8008ce202c ff8008ce2020 ffc1f5ccd668 ffc1f5c530b0 3d80: ffc1f5ce3db0 ff80080f0d70 ffc1f5ca0c40 0001 3da0: ffc1f5ce ff80080f0cfc ffc1f5ce3e20 ff80080bf4f8 3dc0: ffc1f5ca0c80 ff8008bf3798 ff8008955528 ffc1f5ca0c00 3de0: ff80080f0c30 3e00: ff80080f0b68 3e20: ff8008083690 ff80080bf420 ffc1f5ca0c80 3e40: ff80080cb648 3e60: ff8008b1c780 ffc1f5ca0c00 3e80: ffc1 ff80 ffc1f5ce3e90 ffc1f5ce3e90 3ea0: ff80 ffc1f5ce3eb0 ffc1f5ce3eb0 3ec0: 3ee0: 3f00: 3f20: 3f40: 3f60: 3f80: 3fa0: 3fc0: 0005 3fe0: 000275ce3ff0 000275ce3ff8 Call trace: Exception stack(0xffc1f5ce3b30 to 0xffc1f5ce3c60) 3b20: dead0060 0080 3b40: ffc1f5ce3d00 ff80084cb694 0008 0e88 3b60: ffc1f5ce3bb0 ff80080dac68 ffc1f5ce3b90 ff8008826fe4 3b80: 01c0 01c0 ffc1f5ce3bb0 ff800848dfcc 3ba0: 0002 ff8008b15ae4 ffc1f5ce3c00 ff800808f000 3bc0: 0010 fff
Re: [PATCH v2] arm64: dts: Hi3660: Fix up psci state id
Hi Vincent, [ + John, Kevin Wang ] On Fri, Dec 22, 2017 at 03:22:51PM +0100, Vincent Guittot wrote: > Hi Leo, > > Sorry for jumping late in the discussion but should we also remove > the NAP state from the property cpu-idle-states of the CPUs because > this state not supported by the platform at least for now and may be > not in a near future ? Thanks for bringing up this. I don't want to hide anything for patch discussion :) this patch is to resolve the PSCI parameter mismatching issue between kernel and ARM-TF and it's not used to resolve the bug for CPU_NAP, so I didn't mention the CPU_NAP malfunction issue to avoid complex discussion context. I want to keep CPU_NAP state and track bug for CPU_NAP fixing; if we remove this state, I suspect we might have no chance to enable it anymore. Finally this is up to Hisilicon colleague decision and if they have time to fix this. I will offline to check with Daniel and Kevin for this; and if we finally decide to remove it we can commit extra patch for this later, how about you think? > Then, I have another question regarding the update of the > psci-suspend-parameter. These changes implies an update of the psci > firmawre which means that we will now have 2 different firmware > version compatible with 2 different dt. > > Is there any way to check that the ATF on the board is the one that > compatible with the parameter with something like a version ? I > currently use the previous firmware which works fine with current > kernel and dt binding once the NAP state is removed from the table. > When moving on recent kernel, I will have to take care of updating the > firmware and if i need to go back on a previous kernel, i will have to > make sure that i have the right ATF version. This make a lot of chance > of having the wrong configuration AFAIK, we cannot distinguish the PSCI parameter by PSCI version or ARM-TF version number; alternatively one simple way for checking ARM-TF is we can get commit ID (e.g. 83df7ce) from the ARM-TF log; so any ARM-TF commit ID is newer than the patch fdae60b6ba27: "Hikey960: Change to use recommended power state id format" should apply this kernel patch. NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.4(debug):v1.4-441-g83df7ce-dirty NOTICE: BL31: Built : 17:31:35, Dec 22 2017 BTW, I hope we can upgrade Linux kernel and ARM-TF to latest code base to avoid compatible issue; for Android offical releasing it uses the old PSCI parameters with Hisilicon legacy booting images, so they can work well, but if someone uses ARM-TF mainline code + Android kernel 4.4/4.9, there must have compatible issue. I am monitoring the integration ARM-TF/UEFI into Android on Hikey960, we need backport this patch onto Android kernel 4.4/4.9 ASAP after integration ARM-TF/UEFI. Thanks, Leo Yan > Regards, > Vincent > > On 12 December 2017 at 10:12, Leo Yan wrote: > > Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP' > > idle state. From ftrace log we can observe CA73 CPUs can be easily > > waken up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle > > anything and sleep again; so there have tons of trace events for CA73 > > CPUs entering and exiting idle state. > > > > On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we > > set its psci parameter as '0x001' and from this parameter it can > > calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF) > > takes 1 as a invalid value for state id, so the CPU cannot enter idle > > state and directly bail out to kernel. > > > > We want to create good practice for psci parameters platform definition, > > so review the psci specification. The spec "ARM Power State Coordination > > Interface - Platform Design Document (ARM DEN 0022D)" recommends state > > ID in chapter "6.5 Recommended StateID Encoding". The recommended power > > state IDs can be presented by below listed values; and it divides into > > three fields, every field can use 4 bits to present power states > > corresponding to core level, cluster level and system level: > > 0: Run > > 1: Standby > > 2: Retention > > 3: Powerdown > > > > This commit changes psci parameter to compliance with the suggested > > state ID in the doc. Except we change 'CPU_NAP' state psci parameter > > to '0x002', this commit also changes 'CPU_SLEEP' and 'CLUSTER_SLEEP' > > state parameters to '0x0010003' and '0x1010033' respectively. > > > > Credits to Daniel, Sudeep and Soby for suggestion and consolidation. > > > > Cc: Vincent Guittot > > Cc: Daniel Lezcano > > Cc: Sudeep Holla > > Cc: Soby Mathew > > Signed-off-by: Leo Yan > > --- > > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > index ab0b95b..99d5a46 100644 > > --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > +++ b/arch/arm64/boot/dts/hisilicon/hi
[PATCH v2 3/3] tpm: only attempt to disable the LPC CLKRUN if is already enabled
Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
added logic in the TPM TIS driver to disable the Low Pin Count CLKRUN
signal during TPM transactions.
Unfortunately this breaks other devices that are attached to the LPC bus
like for example PS/2 mouse and keyboards.
One flaw with the logic is that it assumes that the CLKRUN is always
enabled, and so it unconditionally enables it after a TPM transaction.
But it could be that the CLKRUN# signal was already disabled in the LPC
bus and so after the driver probes, CLKRUN_EN will remain enabled which
may break other devices that are attached to the LPC bus but don't have
support for the CLKRUN protocol.
Fixes: 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
Signed-off-by: Javier Martinez Canillas
Tested-by: James Ettle
Tested-by: Jeffery Miller
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
---
This patch fixes the bug reported for the Fedora kernel [0] and the kernel
bugzilla [1]. The issue and the propossed solution were discussed in this
[2] thread.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1498987
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=197287
[2]: https://patchwork.kernel.org/patch/10119417/
drivers/char/tpm/tpm_tis_core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 03daf7017e0f..a72a9f03286d 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -747,7 +747,8 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip,
bool value)
struct tpm_tis_data *data = dev_get_drvdata(&chip->dev);
u32 clkrun_val;
- if (!IS_ENABLED(CONFIG_X86) || !is_bsw())
+ if (!IS_ENABLED(CONFIG_X86) || !is_bsw() ||
+ !data->ilb_base_addr)
return;
if (value) {
@@ -806,6 +807,7 @@ int tpm_tis_core_init(struct device *dev, struct
tpm_tis_data *priv, int irq,
u32 vendor;
u32 intfcaps;
u32 intmask;
+ u32 clkrun_val;
u8 rid;
int rc, probe;
struct tpm_chip *chip;
@@ -831,6 +833,13 @@ int tpm_tis_core_init(struct device *dev, struct
tpm_tis_data *priv, int irq,
ILB_REMAP_SIZE);
if (!priv->ilb_base_addr)
return -ENOMEM;
+
+ clkrun_val = ioread32(priv->ilb_base_addr + LPC_CNTRL_OFFSET);
+ /* Check if CLKRUN# is already not enabled in the LPC bus */
+ if (!(clkrun_val & LPC_CLKRUN_EN)) {
+ iounmap(priv->ilb_base_addr);
+ priv->ilb_base_addr = NULL;
+ }
}
if (chip->ops->clk_enable != NULL)
--
2.14.3
[PATCH v2 2/3] tpm: follow coding style for variable declaration in tpm_tis_core_init()
The coding style says "use just one data declaration per line (no commas
for multiple data declarations)" so follow this convention.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm_tis_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index f2bd99fa8352..03daf7017e0f 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -803,7 +803,9 @@ int tpm_tis_core_init(struct device *dev, struct
tpm_tis_data *priv, int irq,
const struct tpm_tis_phy_ops *phy_ops,
acpi_handle acpi_dev_handle)
{
- u32 vendor, intfcaps, intmask;
+ u32 vendor;
+ u32 intfcaps;
+ u32 intmask;
u8 rid;
int rc, probe;
struct tpm_chip *chip;
--
2.14.3
[PATCH v2 0/3] tpm: fix PS/2 devices not working on Braswell systems due CLKRUN enabled
Hello,
Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
added logic in the TPM TIS driver to disable the Low Pin Count CLKRUN
signal during TPM transactions.
Unfortunately this breaks other devices that are attached to the LPC bus
like for example PS/2 mouse and keyboards.
The bug was reported to the Fedora kernel [0] and the kernel bugzilla [1].
This issue and the propossed solution were discussed in this [2] thread,
and the reporter (Jame Ettle) confirmed that his system works again after
the fix in this series.
The patches are based on top or Jarkko Sakkinen's linux-tpmdd [3] tree.
Changes since v1:
- Add collected tags
- Drop patch that fixed a bug in the error path since was already fixed.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1498987
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=197287
[2]: https://patchwork.kernel.org/patch/10119417/
[3]: git.infradead.org/users/jjs/linux-tpmdd.git
Best regards,
Javier
Javier Martinez Canillas (3):
tpm: delete the TPM_TIS_CLK_ENABLE flag
tpm: follow coding style for variable declaration in
tpm_tis_core_init()
tpm: only attempt to disable the LPC CLKRUN if is already enabled
drivers/char/tpm/tpm_tis.c | 15 ---
drivers/char/tpm/tpm_tis_core.c | 17 +
drivers/char/tpm/tpm_tis_core.h | 1 -
3 files changed, 13 insertions(+), 20 deletions(-)
--
2.14.3
[PATCH v2 1/3] tpm: delete the TPM_TIS_CLK_ENABLE flag
This flag is only used to warn if CLKRUN_EN wasn't disabled on Braswell
systems, but the only way this can happen is if the code is not correct.
So it's an unnecessary check that just makes the code harder to read.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm_tis.c | 15 ---
drivers/char/tpm/tpm_tis_core.c | 2 --
drivers/char/tpm/tpm_tis_core.h | 1 -
3 files changed, 18 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index c847fc69a2fc..4b73e28458e3 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -138,9 +138,6 @@ static int tpm_tcg_read_bytes(struct tpm_tis_data *data,
u32 addr, u16 len,
{
struct tpm_tis_tcg_phy *phy = to_tpm_tis_tcg_phy(data);
- if (is_bsw() && !(data->flags & TPM_TIS_CLK_ENABLE))
- WARN(1, "CLKRUN not enabled!\n");
-
while (len--)
*result++ = ioread8(phy->iobase + addr);
@@ -152,9 +149,6 @@ static int tpm_tcg_write_bytes(struct tpm_tis_data *data,
u32 addr, u16 len,
{
struct tpm_tis_tcg_phy *phy = to_tpm_tis_tcg_phy(data);
- if (is_bsw() && !(data->flags & TPM_TIS_CLK_ENABLE))
- WARN(1, "CLKRUN not enabled!\n");
-
while (len--)
iowrite8(*value++, phy->iobase + addr);
@@ -165,9 +159,6 @@ static int tpm_tcg_read16(struct tpm_tis_data *data, u32
addr, u16 *result)
{
struct tpm_tis_tcg_phy *phy = to_tpm_tis_tcg_phy(data);
- if (is_bsw() && !(data->flags & TPM_TIS_CLK_ENABLE))
- WARN(1, "CLKRUN not enabled!\n");
-
*result = ioread16(phy->iobase + addr);
return 0;
@@ -177,9 +168,6 @@ static int tpm_tcg_read32(struct tpm_tis_data *data, u32
addr, u32 *result)
{
struct tpm_tis_tcg_phy *phy = to_tpm_tis_tcg_phy(data);
- if (is_bsw() && !(data->flags & TPM_TIS_CLK_ENABLE))
- WARN(1, "CLKRUN not enabled!\n");
-
*result = ioread32(phy->iobase + addr);
return 0;
@@ -189,9 +177,6 @@ static int tpm_tcg_write32(struct tpm_tis_data *data, u32
addr, u32 value)
{
struct tpm_tis_tcg_phy *phy = to_tpm_tis_tcg_phy(data);
- if (is_bsw() && !(data->flags & TPM_TIS_CLK_ENABLE))
- WARN(1, "CLKRUN not enabled!\n");
-
iowrite32(value, phy->iobase + addr);
return 0;
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index dc3600fc79b7..f2bd99fa8352 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -751,7 +751,6 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip,
bool value)
return;
if (value) {
- data->flags |= TPM_TIS_CLK_ENABLE;
data->clkrun_enabled++;
if (data->clkrun_enabled > 1)
return;
@@ -782,7 +781,6 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip,
bool value)
* sure LPC clock is running before sending any TPM command.
*/
outb(0xCC, 0x80);
- data->flags &= ~TPM_TIS_CLK_ENABLE;
}
}
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index afc50cde1ba6..d5c6a2e952b3 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -86,7 +86,6 @@ enum tis_defaults {
enum tpm_tis_flags {
TPM_TIS_ITPM_WORKAROUND = BIT(0),
- TPM_TIS_CLK_ENABLE = BIT(1),
};
struct tpm_tis_data {
--
2.14.3
Re: TPM driver breaks S3 suspend
On Mon, Dec 25, 2017 at 4:33 AM, Jarkko Sakkinen wrote: > On Thu, Dec 21, 2017 at 04:04:56PM +0800, Chris Chiu wrote: >> Hi, >> We have a desktop which has S3 suspend (to RAM) problem due to >> error messages as follows. >> [ 198.908282] tpm tpm0: Error (38) sending savestate before suspend >> [ 198.908289] __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x160 returns 38 >> [ 198.908293] dpm_run_callback(): pnp_bus_suspend+0x0/0x20 returns 38 >> [ 198.908298] PM: Device 00:0b failed to suspend: error 38 >> >> However, the first suspend after boot is working although it still >> shows an interesting message during resume. >> [ 155.789945] tpm tpm0: A TPM error (38) occurred continue selftest >> >> The error code 38 in definition is TPM_ERR_INVALID_POSTINIT. I >> found some explanations which said this error code means that this >> command was received in the wrong sequence relative to a TPM_Startup >> command. Don't really know what happens here and how should I deal >> with this? Any suggestions? Please let me know what else information >> should I provide. Thanks >> >> Chris > > The sequences for initializing TPM 1.x devices has been fairly static > for a long time. Has this occured after a kernel update? Is there a > kernel version where it used to work and a version where it doesn't? > Thanks. > > /Jarkko Hi Jarkko, Actually, it's a new Acer machine which I never tried an older kernel. I only tried versions >= 4.13. The output of "lsmod | grep tpm" is none. I think it's not built as a module. Chris
