Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support
Hi Marc, On 06/22/2016 09:34 PM, Hanjun Guo wrote: > On 2016/6/22 22:51, Marc Zyngier wrote: >> On 22/06/16 14:52, Tomasz Nowicki wrote: >>> On 22.06.2016 15:25, Marc Zyngier wrote: On 22/06/16 13:35, Tomasz Nowicki wrote: > IORT shows representation of IO topology for ARM based systems. > It describes how various components are connected together on > parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec. > http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf > > Initial support allows to detect IORT table presence and save its > root pointer obtained through acpi_get_table(). The pointer validity > depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap > is not set while using IORT nodes we would dereference unmapped pointers. > > For the aforementioned reason call iort_table_detect() from acpi_init() > which guarantees acpi_gbl_permanent_mmap to be set at that point. > > Add generic helpers which are helpful for scanning and retrieving > information from IORT table content. List of the most important helpers: > - iort_find_dev_node() finds IORT node for a given device > - iort_node_map_rid() maps device RID and returns IORT node which provides >final translation > > Signed-off-by: Tomasz Nowicki > --- > drivers/acpi/Kconfig | 3 + > drivers/acpi/Makefile | 1 + > drivers/acpi/bus.c| 2 + > drivers/acpi/iort.c | 217 > ++ > include/linux/iort.h | 30 +++ > 5 files changed, 253 insertions(+) > create mode 100644 drivers/acpi/iort.c > create mode 100644 include/linux/iort.h > I tracked Marc's tree on git.kernel.org, it's acpi_os_free(buffer.pointer) > there so > my worry is gone :) Do you plan on submitting this during the 4.8 merge window? Thanks, Cov -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros
On Tue, 26 Jul 2016 16:00:04 +0300, Kalle Valo wrote: > Jakub Kicinski writes: > > > On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote: > >> Hi! > >> > >> I've added few lines about the compilation problems in > >> the commit message of patch 1. I would prefer the mass > >> rename of macros in mt7601u not to be part of this series > >> so patch 2 is left as it was and I'll follow up once this > >> is accepted. > > > > Hi Kalle, > > > > what's the status of this set? It's marked as 'Deferred' in > > linux-wireless patchwork. > > Like I said before, I would prefer to see an ack from someone else like > Andrew Morton or Dave Miller. I don't feel comfortable adding new files > to include/ without some sort of support from others. Or maybe Andrew > could even take these directly to his tree? OK, once the merge window is over I'll repost and TO: some important guys. Hopefully we'll catch someone's attention :)
Re: [PATCH] genirq/msi: Make sure PCI MSIs are activated early
On Tue, 26 Jul 2016, Thomas Gleixner wrote: > On Mon, 25 Jul 2016, Bjorn Helgaas wrote: > > On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote: > > I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being > > written before PCI_MSI_ADDRESS_LO. That doesn't sound like a good > > idea to me. > > Well. That's only a problem if the PCI device does not support masking. But > yes, we missed that case back then. > > > That does seem like a problem. Maybe it would be better to delay > > setting PCI_MSI_FLAGS_ENABLE until after the MSI address & data bits > > have been set? > > I thought about that, but that gets ugly pretty fast. Here is an alternative > solution. > > I think that's the proper place to do it _AFTER_ the hierarchical allocation > took place. On x86 Marc's ACTIVATE_EARLY flag would not work because the > message is not yet ready to be assembled. Actually it works, because the MSI domain is the last one which is running the allocation function. So everything else is initialized already. I'll take Marc's patch with some additional commentry as it turned out to be a workaround for the reported VMware issues with PCI/MSI-X pass through. Thanks, tglx
Re: [PATCH] power:bq27xxx: 27000/10 read FLAGS register as single
On 07/18/2016 11:12 AM, H. Nikolaus Schaller wrote:
> The bq27000 and bq27010 have a single byte FLAGS register.
> Other gauges have 16 bit FLAGS registers.
>
> For reading the FLAGS register it is sufficient to read the single
> register instead of reading RSOC at the next higher address as
> well and then ignore the high byte.
>
> This does not change functionality but optimizes i2c and hdq
> traffic.
>
> Signed-off-by: H. Nikolaus Schaller
> ---
Matches the datasheet,
Acked-by: Andrew F. Davis
> drivers/power/bq27xxx_battery.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/bq27xxx_battery.c b/drivers/power/bq27xxx_battery.c
> index 45f6ebf..56712b2 100644
> --- a/drivers/power/bq27xxx_battery.c
> +++ b/drivers/power/bq27xxx_battery.c
> @@ -656,8 +656,9 @@ static bool bq27xxx_battery_dead(struct
> bq27xxx_device_info *di, u16 flags)
> static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
> {
> int flags;
> + bool has_singe_flag = di->chip == BQ27000 || di->chip == BQ27010;
>
> - flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, false);
> + flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, has_singe_flag);
> if (flags < 0) {
> dev_err(di->dev, "error reading flag register:%d\n", flags);
> return flags;
> @@ -760,7 +761,7 @@ static int bq27xxx_battery_current(struct
> bq27xxx_device_info *di,
> }
>
> if (di->chip == BQ27000 || di->chip == BQ27010) {
> - flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, false);
> + flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, true);
> if (flags & BQ27000_FLAG_CHGS) {
> dev_dbg(di->dev, "negative current!\n");
> curr = -curr;
>
Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs
On 26/07/16 13:30, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This doesn't work very well for PVHVM guests as > we have a number of hypercalls where we pass vCPU id as a parameter. These > hypercalls either fail or do something unexpected. To solve the issue we > need to have a mapping between Linux's and Xen's vCPU ids. > > This series solves the issue for x86 PVHVM guests. PV guests don't (and > probably won't) support kdump so I always assume Xen's vCPU id == Linux's > vCPU id. ARM guests will probably need to get proper mapping once we start > supporting kexec/kdump there. > > Changes since v2: > - Use 'uint32_t' for xen_vcpu_id mapping [Julien Grall] > - Rebased to linux-4.7 I already applied v2. If you provide an incremental patch I can queue it for 4.9. David
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)
On Tue, 26 Jul 2016, Foster Snowhill wrote: > On 26.07.16 14:46, Thomas Gleixner wrote: > > Can you please try whether the replacement patch below fixes your issue as > > well? > This one doesn't fix the issue, getting resets again. Patch applied to HEAD > (commit e65805251f2db69c9f67ed8062ab82526be5a374). > > [4.413127] igb :13:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx > queue(s) Gah! That's MSI-X not MSI. So yes, the patch can't work then. Though it confirms that it is an actual VMWARE emulation bug ... Thanks, tglx
Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros
Jakub Kicinski writes: > On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote: >> Hi! >> >> I've added few lines about the compilation problems in >> the commit message of patch 1. I would prefer the mass >> rename of macros in mt7601u not to be part of this series >> so patch 2 is left as it was and I'll follow up once this >> is accepted. > > Hi Kalle, > > what's the status of this set? It's marked as 'Deferred' in > linux-wireless patchwork. Like I said before, I would prefer to see an ack from someone else like Andrew Morton or Dave Miller. I don't feel comfortable adding new files to include/ without some sort of support from others. Or maybe Andrew could even take these directly to his tree? -- Kalle Valo
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)
On 26.07.16 14:46, Thomas Gleixner wrote: > Can you please try whether the replacement patch below fixes your issue as > well? This one doesn't fix the issue, getting resets again. Patch applied to HEAD (commit e65805251f2db69c9f67ed8062ab82526be5a374). [4.377316] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k [4.377319] igb: Copyright (c) 2007-2014 Intel Corporation. [4.377387] igb :13:00.0: enabling device ( -> 0002) [4.413040] igb :13:00.0: added PHC on eth0 [4.413041] igb :13:00.0: Intel(R) Gigabit Ethernet Network Connection [4.413043] igb :13:00.0: eth0: (PCIe:5.0Gb/s:unknown) xx:xx:xx:xx:xx:xx [4.413125] igb :13:00.0: eth0: PBA No: 001300-000 [4.413127] igb :13:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [4.981302] igb :13:00.0 ens224: renamed from eth0 [5.394728] igb :13:00.0: changing MTU from 1500 to 9000 [7.904222] igb :13:00.0 ens224: igb: ens224 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [7.904479] IPv6: ADDRCONF(NETDEV_CHANGE): ens224: link becomes ready [ 13.023592] [ cut here ] [ 13.023621] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:272 dev_watchdog+0x22c/0x230 [ 13.023624] NETDEV WATCHDOG: ens224 (igb): transmit queue 0 timed out [ 13.023625] Modules linked in: vmw_vsock_vmci_transport vsock joydev ppdev vmw_balloon intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel input_leds psmouse serio_raw igb ptp pps_core dca i2c_algo_bit nls_iso8859_1 ahci libahci fjes parport_pc parport vmw_vmci i2c_piix4 pata_acpi mac_hid sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd vmw_pvscsi vmwgfx ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm shpchp [ 13.023650] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-msi2 #1 [ 13.023652] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.0.B64.1506250318 06/25/2015 [ 13.023653] 0286 dd7086eb3068bd0c 8880fc603d70 833f8cd3 [ 13.023654] 8880fc603dc0 8880fc603db0 830820bb [ 13.023655] 0110fc603da8 0008 [ 13.023656] Call Trace: [ 13.023657][] dump_stack+0x63/0x90 [ 13.023664] [] __warn+0xcb/0xf0 [ 13.023665] [] warn_slowpath_fmt+0x5f/0x80 [ 13.023667] [] dev_watchdog+0x22c/0x230 [ 13.023668] [] ? qdisc_rcu_free+0x40/0x40 [ 13.023671] [] call_timer_fn+0x35/0x120 [ 13.023672] [] run_timer_softirq+0x222/0x4d0 [ 13.023674] [] ? ktime_get+0x3c/0xb0 [ 13.023676] [] ? lapic_next_deadline+0x2a/0x30 [ 13.023678] [] ? clockevents_program_event+0x82/0x120 [ 13.023681] [] __do_softirq+0xf6/0x280 [ 13.023683] [] irq_exit+0xa3/0xb0 [ 13.023684] [] smp_apic_timer_interrupt+0x42/0x50 [ 13.023686] [] apic_timer_interrupt+0x82/0x90 [ 13.023686][] ? native_safe_halt+0x6/0x10 [ 13.023691] [] default_idle+0x1e/0xd0 [ 13.023692] [] arch_cpu_idle+0xf/0x20 [ 13.023693] [] default_idle_call+0x2a/0x40 [ 13.023694] [] cpu_startup_entry+0x2ea/0x350 [ 13.023696] [] rest_init+0x77/0x80 [ 13.023699] [] start_kernel+0x466/0x487 [ 13.023700] [] ? early_idt_handler_array+0x120/0x120 [ 13.023701] [] x86_64_start_reservations+0x29/0x2b [ 13.023702] [] x86_64_start_kernel+0x143/0x166 [ 13.023704] ---[ end trace 46f69508befb7107 ]--- [ 13.023724] igb :13:00.0 ens224: Reset adapter [ 17.824272] igb :13:00.0 ens224: igb: ens224 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Re: [PATCH] README: Mention when 386 support ended + update obsolete 386 paths
On 26 July 2016 at 14:12, Jonathan Corbet wrote: > On Tue, 26 Jul 2016 09:45:43 +0200 Øyvind A. Holm > wrote: > > - Compiling the kernel with "Processor type" set higher than 386 > > will result in a kernel that does NOT work on a 386. The > > - kernel will detect this on bootup, and give up. > > + kernel will detect this on bootup, and give up. The last kernel > > + with support for 386 was version 3.7. > > So we want the documentation to reflect current kernels, not those > from years gone by. I can't think of a reason why this paragraph > should continue to exist at all. Can you make a new version that > removes it altogether? That was also my first thought, yes. But then I thought, maybe there's some value to that information in case someone wants to try a new kernel on some ancient hardware. But it's probably an unlikely scenario. I'll send a new patch now. Øyvind
Re: [PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v2
On Tue, Jul 26, 2016 at 05:11:30PM +0900, Joonsoo Kim wrote:
> > These patches did not OOM for me on a 2G 32-bit KVM instance while running
> > a stress test for an hour. Preliminary tests on a 64-bit system using a
> > parallel dd workload did not show anything alarming.
> >
> > If an OOM is detected then please post the full OOM message.
>
> Before attaching OOM message, I should note that my test case also triggers
> OOM in old kernel if there are four parallel file-readers. With node-lru and
> patch 1~5, OOM is triggered even if there are one or more parallel
> file-readers.
> With node-lru and patch 1~4, OOM is triggered if there are two or more
> parallel file-readers.
>
The key there is that patch 5 allows OOM to be detected quicker. The fork
workload exits after some time so it's inherently a race to see if the
forked process exits before OOM is triggered or not.
>
> Mem-Info:
> active_anon:26762 inactive_anon:95 isolated_anon:0
> active_file:42543 inactive_file:347438 isolated_file:0
> unevictable:0 dirty:0 writeback:0 unstable:0
> slab_reclaimable:5476 slab_unreclaimable:23140
> mapped:389534 shmem:95 pagetables:20927 bounce:0
> free:6948 free_pcp:222 free_cma:0
> Node 0 active_anon:107048kB inactive_anon:380kB active_file:170008kB
> inactive_file:1389752kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
> mapped:1558136kB dirty:0kB writeback:0kB shmem:0kB shmem_$
> hp: 0kB shmem_pmdmapped: 0kB anon_thp: 380kB writeback_tmp:0kB unstable:0kB
> pages_scanned:4697206 all_unreclaimable? yes
> Node 0 DMA free:2168kB min:204kB low:252kB high:300kB active_anon:3544kB
> inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
> writepending:0kB present:15992kB managed:15908kB mlocked:0kB sl$
> b_reclaimable:0kB slab_unreclaimable:2684kB kernel_stack:1760kB
> pagetables:3092kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> lowmem_reserve[]: 0 493 493 1955
Zone DMA is unusable
> Node 0 DMA32 free:6508kB min:6492kB low:8112kB high:9732kB
> active_anon:81264kB inactive_anon:0kB active_file:101204kB
> inactive_file:228kB unevictable:0kB writepending:0kB present:2080632kB
> managed:508584k$
> mlocked:0kB slab_reclaimable:21904kB slab_unreclaimable:89876kB
> kernel_stack:46400kB pagetables:80616kB bounce:0kB free_pcp:544kB
> local_pcp:120kB free_cma:0kB
> lowmem_reserve[]: 0 0 0 1462
Zone DMA32 has reclaimable pages but not very many and they are active. It's
at the min watemark. The pgdat is unreclaimable indicating that scans
are high which implies that the active file pages are due to genuine
activations.
> Node 0 Movable free:19116kB min:19256kB low:24068kB high:28880kB
> active_anon:22240kB inactive_anon:380kB active_file:68812kB
> inactive_file:1389688kB unevictable:0kB writepending:0kB present:1535864kB
> mana$
> ed:1500964kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
> kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:368kB local_pcp:0kB
> free_cma:0kB
Zone Movable has reclaimable pages but it's at the min watermark and
scanning aggressively.
As the failing allocation can use all allocations, this appears to be close
to a genuine OOM case. Whether it survives is down to timing of when OOM
is triggered and whether the forked process exits in time or not.
To some extent, it could be "addressed" by immediately reclaiming active
pages moving to the inactive list at the cost of distorting page age for a
workload that is genuinely close to OOM. That is similar to what zone-lru
ended up doing -- fast reclaiming young pages from a zone.
> > Optionally please test without patch 5 if an OOM occurs.
>
> Here goes without patch 5.
>
Causing OOM detection to be delayed. Observations on the OOM message
without patch 5 are similar.
Do you mind trying the following? In the patch there is a line
scan += list_empty(src) ? total_skipped : total_skipped >> 2;
Try
scan += list_empty(src) ? total_skipped : total_skipped >> 3;
scan += list_empty(src) ? total_skipped : total_skipped >> 4;
scan += total_skipped >> 4;
Each line slows the rate that OOM is detected but it'll be somewhat
specific to your test case as it's relying to fork to exit before OOM is
fired.
A hackier option that is also related to the fact fork is a major source
of the OOM triggering is to increase the zone reserve. That would give
more space for the fork bomb while giving the file reader slightly less
memory to work with. Again, what this is doing is simply altering OOM
timing because indications are the stress workload is genuinely close to
OOM.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 08ae8b0ef5c5..cedc8113c7a0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -201,9 +201,9 @@ int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = {
256,
#endif
#ifdef CONFIG_HIGHMEM
-32,
+8,
#endif
-32,
+8,
};
EXPORT_SYMBOL(totalram_pages);
--
Mel Gorman
SUSE Labs
Re: bcache super block corruption with non 4k pages
On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote: > On 26.07.2016 12:21, Kent Overstreet wrote: > > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: > >> On 21.07.2016 10:58, Stefan Bader wrote: > >>> I was pointed at the thread which seems to address the same after > >>> I wrote most of below text. Did not want to re-write this so please > >>> bear with the odd layout. > >>> > >>> https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html > >>> > >>> Zhengyuan tries to fix the problem by relocating the superblock on > >>> disk. But I am not sure whether there is really any guarantee about > >>> how __bread fills data into the buffer_head. What if there is the next > >>> odd arch with 128K pages? > >>> > >>> So below is an attempt to be more generic. Still I don't feel completely > >>> happy with the way that a page moves (or is shared) between buffer_head > >>> and biovec. What I tried to outline below is to let the register functions > >>> allocate bio+biovec memory and use the in-memory sb_cache data to > >>> initialize > >>> the biovec buffer. > >> > >> Any opinions here? Also adding LKML as I don't seem to get through > >> moderation on > >> dm-devel. > > > > The correct solution is to rip out the __bread() and just read the > > superblock by > > issuing a bio, the same way all the other IO in bcache is done. > > > > This is the way it's done in the bcache-dev branch - unfortunately, the > > patch > > that does that in bcache-dev is big and invasive and probably not worth the > > hassle to backport: > > > > https://evilpiepirate.org/git/linux-bcache.git/commit/?h=bcache-dev&id=303eb67bffad57b4d9e71523e7df04bf258e66d1 > > I agree that this looks better and also rather large. > > > > Probably best to just do something small and localized. > > > So what did you think about the change I did? It seemed to be ok for 4K and > 64K > at least and is rather small. And I believe that, compared to Zhengyuan's > approach this would have the benefit of not changing the superblock sector. So > it would be compatible with previously created superblocks. Too ugly to live. Just kmalloc() 4k, allocate a bio on the stack, set it up, and submit it with submit_bio_wait(). Use virt_to_page(), don't bother with raw pages - you want 4k, not whatever the page size is.
Is reading from /proc/self/smaps thread-safe?
Hey
I have a simple program that mmaps 8MB of anonymous memory, spawns 16
threads, reads /proc/self/smaps in each thread and looks up whether
mapped address can be found in smaps. From time to time it's not there.
Is this supposed to work reliably?
My guess is that libc functions allocate memory internally using mmap
and modify process' address space while other thread is iterating over
vmas.
I see that reading from smaps takes mmap_sem in read mode. I'm guessing
vm modifications are done under mmap_sem in write mode.
Documentation/filesystem/proc.txt says reading from smaps is "slow but
very precise" (although in context of RSS).
Example program below.
smaps_test.c:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define N 16
#define SZ (8 * 1024 * 1024)
void *addr;
char addrstr[20];
pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
static void *worker(void *arg)
{
char tmp[10];
int ret;
int off = 0;
int fd = open("/proc/self/smaps", O_RDONLY);
if (fd < 0)
abort();
do {
ret = read(fd, tmp + off, sizeof(tmp) - off);
if (ret < 0)
abort();
off += ret;
if (off == sizeof(tmp))
abort();
} while (ret != 0);
char *found = strstr(tmp, addrstr);
/* lock to prevent multiple threads from
writing to stdout at the same time */
pthread_mutex_lock(&mtx);
printf("%d\n", found ? 1 : 0);
if (!found) {
printf("%s\n", tmp);
printf("address %p not found in smaps\n", addr);
fflush(stdout);
abort();
}
pthread_mutex_unlock(&mtx);
close(fd);
return NULL;
}
int main()
{
pthread_t t[N];
addr = mmap(NULL, SZ, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_ANONYMOUS, -1, 0);
if (addr == MAP_FAILED)
abort();
sprintf(addrstr, "%lx-", (uintptr_t)addr);
for (int i = 0; i < N; ++i)
if (pthread_create(&t[i], NULL, worker, NULL))
abort();
for (int i = 0; i < N; ++i)
if (pthread_join(t[i], NULL))
abort();
munmap(addr, SZ);
return 0;
}
Makefile:
LDFLAGS=-pthread
smaps_test: smaps_test.c
run: smaps_test
while ./smaps_test; do echo; done | grep -v ': '
Failing run:
$ make run
while ./smaps_test; do echo; done | grep -v ': '
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0040-00401000 r-xp 08:02 19006749
/home/mslusarz/smaps_test/smaps_test
00601000-00602000 rw-p 1000 08:02 19006749
/home/mslusarz/smaps_test/smaps_test
020f8000-02119000 rw-p 00:00 0 [heap]
7f0dfdffc000-7f0dfe7fd000 rw-p 00:00 0
7f0dfe7fd000-7f0dfe7fe000 ---p 00:00 0
7f0dfe7fe000-7f0dfeffe000 rw-p 00:00 0
7f0dfeffe000-7f0dfefff000 ---p 00:00 0
7f0dfefff000-7f0dff7ff000 rw-p 00:00 0
7f0dff7ff000-7f0dff80 ---p 00:00 0
7f0dff80-7f0e rw-p 00:00 0
7f0e-7f0e00022000 rw-p 00:00 0
7f0e00022000-7f0e0400 ---p 00:00 0
7f0e04595000-7f0e04596000 ---p 00:00 0
7f0e04596000-7f0e04d96000 rw-p 00:00 0
7f0e04d96000-7f0e04d97000 ---p 00:00 0
7f0e04d97000-7f0e05597000 rw-p 00:00 0
7f0e05597000-7f0e05598000 ---p 00:00 0
7f0e05598000-7f0e05d98000 rw-p 00:00 0
7f0e05d98000-7f0e05d99000 ---p 00:00 0
7f0e05d99000-7f0e06599000 rw-p 00:00 0
7f0e06599000-7f0e0659a000 ---p 00:00 0
7f0e0659a000-7f0e06d9a000 rw-p 00:00 0
7f0e06d9a000-7f0e06d9b000 ---p 00:00 0
7f0e06d9b000-7f0e0759b000 rw-p 00:00 0
7f0e0759b000-7f0e0759c000 ---p 00:00 0
7f0e0759c000-7f0e07d9c000 rw-p 00:00 0
7f0e07d9c000-7f0e07d9d000 ---p 00:00 0
7f0e07d9d000-7f0e0859d000 rw-p 00:00 0
7f0e0859d000-7f0e0859e000 ---p 00:00 0
7f0e0859e000-7f0e08d9e000 rw-p 00:00 0
7f0e08d9e000-7f0e08d9f000 ---p 00:00 0
7f0e08d9f000-7f0e0959f000 rw-p 00:00 0
7f0e0959f000-7f0e095a ---p 00:00 0
7f0e095a-7f0e09da rw-p 00:00 0
7f0e09da-7f0e09da1000 ---p 00:00 0
(should be here)
7f0e0ada1000-7f0e0af38000 r-xp 08:02 9699508
/lib/x86_64-linux-gnu/libc-2.23.so
7f0e0af38000-7f0e0b138000 ---p 00197000 08:02 9699508
/lib/x86_64-linux-gnu/libc-2.23.so
7f0e0b138000-7f0e0b13c000 r--p 00197000 08:02 9699508
/lib/x86_64-linux-gnu/libc-2.23.so
7f0e0b13c000-7f0e0b13e000 rw-p 0019b000 08:02 9699508
/lib/x86_64-linux-gnu/libc-2.23.so
7f0e0b13e000-7f0e0b142000 rw-p 00:00 0
7f0e0b142000-7f0e0b15a000 r-xp 08:02 9699869
/lib/x86_64-linux-gnu/libpthread-2.23.so
7f0e0b15a000-7f0e0b359000 ---p 00018000 08:02 9699869
/lib/x86_64-linux-gnu/libpthread-2.23.so
7f0e0b359000-7f0e0b35a000 r--p 00017000 08:02 9699869
/lib/x86_64-linux-gnu/libpthread-2.23.so
7f0e0b35a000-7f0e0b35b000 rw-p 00018000 08:02 9699869
/lib/x86_64-linux-gnu/libpthread-2.23.so
7f0e0b35b000-7f0e0b35f
Re: next build: 74 warnings 0 failures (next/next-20160726)
On Tuesday, July 26, 2016 2:08:21 AM CEST Olof's autobuilder wrote: > Warnings: > 1 drivers/infiniband/core/cma.c:1242:12: warning: > 'src_addr_storage.sin_addr.s_addr' may be used uninitialized in this function > [-Wmaybe-uninitialized] > 1 drivers/tty/serial/8250/8250_fintek.c:34:0: warning: "IRQ_MODE" > redefined > 2 drivers/clocksource/jcore-pit.c:277:187: warning: comparison of > distinct pointer types lacks a cast > 2 drivers/media/dvb-frontends/cxd2841er.c:3408:40: warning: > 'carrier_offset' may be used uninitialized in this function > [-Wmaybe-uninitialized] > 34 drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses > around comparison in operand of '&' [-Wparentheses] > 34 drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses > around comparison in operand of '&' [-Wparentheses] The jcore-pit one is new, I've submitted fixes for that one, and had older fixes for all the others. The infiniband warning is the only one that is not a regression against 4.7. Since there is now a very small set of remaining warnings, I plan to repost them as a series until they are all merged. Arnd
Re: [PATCH v9 5/9] acpi/arm64: Add GTDT table parse driver
Hi Rafael,
On 26 July 2016 at 19:50, Rafael J. Wysocki wrote:
> On Monday, July 25, 2016 11:27:03 PM fu@linaro.org wrote:
>> From: Fu Wei
>>
>> This patch adds support for parsing arch timer in GTDT,
>> provides some kernel APIs to parse all the PPIs and
>> always-on info in GTDT and export them.
>>
>> By this driver, we can simplify arm_arch_timer drivers, and
>> separate the ACPI GTDT knowledge from it.
>>
>> Signed-off-by: Fu Wei
>> Signed-off-by: Hanjun Guo
>
> From the ACPI perspective:
>
> Acked-by: Rafael J. Wysocki
Great thanks for your help, I just posted v10, then got your ACK :-)
But there is not change in the patch, I 'm assuming that your ACK
still works for my v10 :-)
>
> and I'm assuming that the patches will go in via some other (non-ACPI) tree.
I think so, I guess the clocksource maintainer will take care of it.
Daniel, is this patch will go into clocksource tree?
Thanks for your help! :-)
>
>> ---
>> arch/arm64/Kconfig | 1 +
>> drivers/acpi/Kconfig | 5 ++
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/arm64/Kconfig | 5 ++
>> drivers/acpi/arm64/Makefile| 1 +
>> drivers/acpi/arm64/acpi_gtdt.c | 152
>> +
>> drivers/clocksource/Kconfig| 1 -
>> include/linux/acpi.h | 6 ++
>> 8 files changed, 171 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 5a0a691..0b9fba7 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -2,6 +2,7 @@ config ARM64
>> def_bool y
>> select ACPI_CCA_REQUIRED if ACPI
>> select ACPI_GENERIC_GSI if ACPI
>> + select ACPI_GTDT if ACPI
>> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>> select ARCH_HAS_DEVMEM_IS_ALLOWED
>> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index b7e2e77..1cdc7d2 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -521,4 +521,9 @@ config XPOWER_PMIC_OPREGION
>>
>> endif
>>
>> +if ARM64
>> +source "drivers/acpi/arm64/Kconfig"
>> +
>> +endif
>> +
>> endif# ACPI
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 251ce85..1a94ff7 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -99,5 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
>> obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o
>> obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
>> obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
>> +obj-$(CONFIG_ARM64) += arm64/
>>
>> video-objs += acpi_video.o video_detect.o
>> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
>> new file mode 100644
>> index 000..80201be
>> --- /dev/null
>> +++ b/drivers/acpi/arm64/Kconfig
>> @@ -0,0 +1,5 @@
>> +#
>> +# ACPI Configuration for ARM64
>> +#
>> +config ACPI_GTDT
>> + bool
>> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
>> new file mode 100644
>> index 000..466de6b
>> --- /dev/null
>> +++ b/drivers/acpi/arm64/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_ACPI_GTDT) += acpi_gtdt.o
>> diff --git a/drivers/acpi/arm64/acpi_gtdt.c b/drivers/acpi/arm64/acpi_gtdt.c
>> new file mode 100644
>> index 000..cdb2fb1
>> --- /dev/null
>> +++ b/drivers/acpi/arm64/acpi_gtdt.c
>> @@ -0,0 +1,152 @@
>> +/*
>> + * ARM Specific GTDT table Support
>> + *
>> + * Copyright (C) 2016, Linaro Ltd.
>> + * Author: Daniel Lezcano
>> + * Fu Wei
>> + * Hanjun Guo
>> + *
>> + * 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.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#undef pr_fmt
>> +#define pr_fmt(fmt) "ACPI GTDT: " fmt
>> +
>> +typedef struct {
>> + struct acpi_table_gtdt *gtdt;
>> + void *platform_timer_start;
>> + void *gtdt_end;
>> +} acpi_gtdt_desc_t;
>> +
>> +static acpi_gtdt_desc_t acpi_gtdt_desc __initdata;
>> +
>> +static inline void *next_platform_timer(void *platform_timer)
>> +{
>> + struct acpi_gtdt_header *gh = platform_timer;
>> +
>> + platform_timer += gh->length;
>> + if (platform_timer < acpi_gtdt_desc.gtdt_end)
>> + return platform_timer;
>> +
>> + return NULL;
>> +}
>> +
>> +#define for_each_platform_timer(_g) \
>> + for (_g = acpi_gtdt_desc.platform_timer_start; _g; \
>> + _g = next_platform_timer(_g))
>> +
>> +static inline bool is_timer_block(void *platform_timer)
>> +{
>> + struct acpi_gtdt_header *gh = platform_timer;
>> +
>> + return gh->type == ACPI_GTDT_TYPE_TIMER_BLOCK;
>> +}
>> +
>> +static inline bool is_watchdog(void *platform_timer)
>> +{
>> + struct acpi_gtdt_header *gh = platform_timer;
>> +
>> + return gh->type == ACPI_GTDT_TYPE_WATCHDOG
Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)
On Tuesday, July 26, 2016 1:29:55 PM CEST Build bot for Mark Brown wrote: > Tree/Branch: master > Git describe: v4.7-1605-ge658052 > Commit: e65805251f Merge branch 'irq-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > > Build Time: 106 min 43 sec > > Passed:7 / 9 ( 77.78 %) > Failed:2 / 9 ( 22.22 %) > > Errors: 0 > Warnings: 3 > Section Mismatches: 0 > > Failed defconfigs: > arm64-allmodconfig > arm-allmodconfig The build report doesn't actually show the error unfortunately, but I'm pretty sure it's this one: drivers/staging/built-in.o: In function `nbu2ss_drv_probe': (.text+0x2428): undefined reference to `usb_ep_set_maxpacket_limit' for which I sent a fix on June 22 and then again on July 5, with subject "staging: emxx_udc: allow modular build". Stephen Rothwell also reported that one yesterday. Greg, let me know if you'd like me to send that once more in case it's no longer in your queue. Arnd
Re: bcache super block corruption with non 4k pages
On 26.07.2016 12:21, Kent Overstreet wrote:
> On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote:
>> On 21.07.2016 10:58, Stefan Bader wrote:
>>> I was pointed at the thread which seems to address the same after
>>> I wrote most of below text. Did not want to re-write this so please
>>> bear with the odd layout.
>>>
>>> https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html
>>>
>>> Zhengyuan tries to fix the problem by relocating the superblock on
>>> disk. But I am not sure whether there is really any guarantee about
>>> how __bread fills data into the buffer_head. What if there is the next
>>> odd arch with 128K pages?
>>>
>>> So below is an attempt to be more generic. Still I don't feel completely
>>> happy with the way that a page moves (or is shared) between buffer_head
>>> and biovec. What I tried to outline below is to let the register functions
>>> allocate bio+biovec memory and use the in-memory sb_cache data to initialize
>>> the biovec buffer.
>>
>> Any opinions here? Also adding LKML as I don't seem to get through
>> moderation on
>> dm-devel.
>
> The correct solution is to rip out the __bread() and just read the superblock
> by
> issuing a bio, the same way all the other IO in bcache is done.
>
> This is the way it's done in the bcache-dev branch - unfortunately, the patch
> that does that in bcache-dev is big and invasive and probably not worth the
> hassle to backport:
>
> https://evilpiepirate.org/git/linux-bcache.git/commit/?h=bcache-dev&id=303eb67bffad57b4d9e71523e7df04bf258e66d1
I agree that this looks better and also rather large.
>
> Probably best to just do something small and localized.
>
So what did you think about the change I did? It seemed to be ok for 4K and 64K
at least and is rather small. And I believe that, compared to Zhengyuan's
approach this would have the benefit of not changing the superblock sector. So
it would be compatible with previously created superblocks.
-Stefan
From 3652e98359b876f3c1e6d7b9b7305e3411178296 Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Wed, 20 Jul 2016 12:06:27 +0200
Subject: [PATCH] bcache: handle non 4k pages returned by __bread
On non-x86 arches pages can be bigger than 4k. Currently read_super
returns a reference to the page used as buffer in the buffer_head
that is returned by __bread().
With 4k page size and a requested read this normally ends up with
the super block data starting at offset 0. But as seen on ppc64le
with 64k page size, the data can start at an offset (from what I
saw the offset was 4k).
This causes harm later on when __write_super() maps the super
block data at the start of the page acquired before and also
not writes back all fields (particularly the super block magic).
Try to avoid this by also returning the potential offset within the
sb_page from read_super() and fully initiallize the single bvec of
the bio used for __write_super() calls. Doing that is the same as
would have been done in bch_bio_map() which now must not be used in
__write_super().
Signed-off-by: Stefan Bader
---
drivers/md/bcache/super.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index e169739..3e0d2de 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -62,7 +62,7 @@ struct workqueue_struct *bcache_wq;
/* Superblock */
static const char *read_super(struct cache_sb *sb, struct block_device *bdev,
- struct page **res)
+ struct page **res, unsigned int *off)
{
const char *err;
struct cache_sb *s;
@@ -192,6 +192,7 @@ static const char *read_super(struct cache_sb *sb, struct block_device *bdev,
err = NULL;
get_page(bh->b_page);
+ *off = (unsigned int) (bh->b_data - ((char *) page_address(bh->b_page)));
*res = bh->b_page;
err:
put_bh(bh);
@@ -202,19 +203,19 @@ static void write_bdev_super_endio(struct bio *bio)
{
struct cached_dev *dc = bio->bi_private;
/* XXX: error checking */
-
closure_put(&dc->sb_write);
}
static void __write_super(struct cache_sb *sb, struct bio *bio)
{
- struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page);
+ struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page) +
+ bio->bi_io_vec[0].bv_offset;
unsigned i;
bio->bi_iter.bi_sector = SB_SECTOR;
bio->bi_rw = REQ_SYNC|REQ_META;
bio->bi_iter.bi_size = SB_SIZE;
- bch_bio_map(bio, NULL);
+ // bch_bio_map(bio, NULL);
out->offset = cpu_to_le64(sb->offset);
out->version = cpu_to_le64(sb->version);
@@ -1139,6 +1140,7 @@ static int cached_dev_init(struct cached_dev *dc, unsigned block_size)
/* Cached device - bcache superblock */
static void register_bdev(struct cache_sb *sb, struct page *sb_page,
+ unsigned int sb_off,
struct block_device *bdev,
struct cached_dev *dc)
{
@@ -1154,6 +1156,8 @@ static void register_bdev(struct cache_sb *sb, struct page *sb_page,
dc->sb_bio.bi_max_vecs = 1;
dc->sb_bio.bi_io_vec = dc->
[PATCH linux v3 4/9] x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op
HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter while
Xen's idea is expected. In some cases these ideas diverge so we need to
do remapping. Convert all callers of HYPERVISOR_vcpu_op() to use
xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps()
intact as they're only being called by PV guests before perpu areas are
initialized. While the issue could be solved by switching to early_percpu
for xen_vcpu_id I think it's not worth it: PV guests will probably never
get to the point where their idea of vCPU id diverges from Xen's.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Modify all callers of HYPERVISOR_vcpu_op() instead of modifying
HYPERVISOR_vcpu_op() [David Vrabel]
---
arch/arm/xen/enlighten.c | 3 ++-
arch/x86/xen/enlighten.c | 10 ++
arch/x86/xen/irq.c | 3 ++-
arch/x86/xen/smp.c | 11 ++-
arch/x86/xen/time.c | 18 --
drivers/xen/events/events_base.c | 3 ++-
drivers/xen/time.c | 2 +-
7 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index fe32267..0456daf 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -189,7 +189,8 @@ static void xen_percpu_init(void)
info.mfn = virt_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
- err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+ err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, xen_vcpu_nr(cpu),
+&info);
BUG_ON(err);
per_cpu(xen_vcpu, cpu) = vcpup;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c833912..3b0ceed 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -228,7 +228,8 @@ static void xen_vcpu_setup(int cpu)
hypervisor has no unregister variant and this hypercall does not
allow to over-write info.mfn and info.offset.
*/
- err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+ err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, xen_vcpu_nr(cpu),
+&info);
if (err) {
printk(KERN_DEBUG "register_vcpu_info failed: err=%d\n", err);
@@ -252,10 +253,11 @@ void xen_vcpu_restore(void)
for_each_possible_cpu(cpu) {
bool other_cpu = (cpu != smp_processor_id());
- bool is_up = HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL);
+ bool is_up = HYPERVISOR_vcpu_op(VCPUOP_is_up, xen_vcpu_nr(cpu),
+ NULL);
if (other_cpu && is_up &&
- HYPERVISOR_vcpu_op(VCPUOP_down, cpu, NULL))
+ HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(cpu), NULL))
BUG();
xen_setup_runstate_info(cpu);
@@ -264,7 +266,7 @@ void xen_vcpu_restore(void)
xen_vcpu_setup(cpu);
if (other_cpu && is_up &&
- HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL))
+ HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL))
BUG();
}
}
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index a1207cb..33e9295 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -109,7 +109,8 @@ static void xen_safe_halt(void)
static void xen_halt(void)
{
if (irqs_disabled())
- HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
+ HYPERVISOR_vcpu_op(VCPUOP_down,
+ xen_vcpu_nr(smp_processor_id()), NULL);
else
xen_safe_halt();
}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 719cf29..a3118f2 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -454,7 +454,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
#endif
ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_gfn(swapper_pg_dir));
- if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
+ if (HYPERVISOR_vcpu_op(VCPUOP_initialise, xen_vcpu_nr(cpu), ctxt))
BUG();
kfree(ctxt);
@@ -492,7 +492,7 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct
*idle)
if (rc)
return rc;
- rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
+ rc = HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL);
BUG_ON(rc);
while (cpu_report_state(cpu) != CPU_ONLINE)
@@ -520,7 +520,8 @@ static int xen_cpu_disable(void)
static void xen_cpu_die(unsigned int cpu)
{
- while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL)) {
+ while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up,
+xen_vcpu_nr(cpu), NULL)) {
__set_current_s
[PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings
The driver has just gained a slightly incorrect pm-sleep implementation that
causes
warnings when CONFIG_PM is set but CONFIG_PM_SLEEP is not:
drivers/mmc/host/sdhci-esdhc-imx.c:1302:12: error: 'sdhci_esdhc_resume' defined
but not used [-Werror=unused-function]
static int sdhci_esdhc_resume(struct device *dev)
^~
drivers/mmc/host/sdhci-esdhc-imx.c:1297:12: error: 'sdhci_esdhc_suspend'
defined but not used [-Werror=unused-function]
static int sdhci_esdhc_suspend(struct device *dev)
This replaces the incorrect #ifdef with a __maybe_unused annotation that does
the right thing in all configurations and is more readable.
Signed-off-by: Arnd Bergmann
Fixes: b70d0b3b5b29 ("mmc: sdhci-esdhc-imx: add esdhc specific suspend resume
callback")
---
drivers/mmc/host/sdhci-esdhc-imx.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 2bb326bbc34a..593e34053c4b 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1293,13 +1293,12 @@ static int sdhci_esdhc_imx_remove(struct
platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int sdhci_esdhc_suspend(struct device *dev)
+static int __maybe_unused sdhci_esdhc_suspend(struct device *dev)
{
return sdhci_pltfm_suspend(dev);
}
-static int sdhci_esdhc_resume(struct device *dev)
+static int __maybe_unused sdhci_esdhc_resume(struct device *dev)
{
struct sdhci_host *host = dev_get_drvdata(dev);
@@ -1309,7 +1308,7 @@ static int sdhci_esdhc_resume(struct device *dev)
return sdhci_pltfm_resume(dev);
}
-static int sdhci_esdhc_runtime_suspend(struct device *dev)
+static int __maybe_unused sdhci_esdhc_runtime_suspend(struct device *dev)
{
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -1327,7 +1326,7 @@ static int sdhci_esdhc_runtime_suspend(struct device *dev)
return ret;
}
-static int sdhci_esdhc_runtime_resume(struct device *dev)
+static int __maybe_unused sdhci_esdhc_runtime_resume(struct device *dev)
{
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -1341,7 +1340,6 @@ static int sdhci_esdhc_runtime_resume(struct device *dev)
return sdhci_runtime_resume_host(host);
}
-#endif
static const struct dev_pm_ops sdhci_esdhc_pmops = {
SET_SYSTEM_SLEEP_PM_OPS(sdhci_esdhc_suspend, sdhci_esdhc_resume)
--
2.9.0
[PATCH] clocksource: j-core: type fix init function return code
The CLOCKSOURCE_OF_DECLARE now takes a function that returns an 'int', but a
this
new clocksource driver has just appeared in linux-next and causes a warning
because
it has the old 'void' return value:
In file included from ../include/linux/clocksource.h:18:0,
from ../include/linux/clockchips.h:13,
from ../drivers/clocksource/jcore-pit.c:14:
include/linux/of.h:1006:20: error: comparison of distinct pointer types lacks a
cast [-Werror]
.data = (fn == (fn_type)NULL) ? fn : fn }
^
This adapts the jcore_pit_init() function to the correct return type.
Signed-off-by: Arnd Bergmann
Fixes: e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
---
The patch that introduces the warnign currently only exists in the linux-sh git
tree and showed up in linux-next this week.
---
drivers/clocksource/jcore-pit.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
index 373b9f954a5c..4a2f7803624b 100644
--- a/drivers/clocksource/jcore-pit.c
+++ b/drivers/clocksource/jcore-pit.c
@@ -154,7 +154,7 @@ static irqreturn_t jcore_timer_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static void __init jcore_pit_init(struct device_node *node)
+static int __init jcore_pit_init(struct device_node *node)
{
int err;
__iomem void *pit_base;
@@ -169,12 +169,14 @@ static void __init jcore_pit_init(struct device_node
*node)
pit_base = of_iomap(node, 0);
if (!pit_base) {
pr_err("Error: Cannot map base address for J-Core PIT\n");
+ err = -ENXIO;
goto out;
}
pit_irq = irq_of_parse_and_map(node, 0);
if (!pit_irq) {
pr_err("Error: J-Core PIT has no IRQ\n");
+ err = -ENXIO;
goto out;
}
@@ -183,6 +185,7 @@ static void __init jcore_pit_init(struct device_node *node)
cs = kzalloc(sizeof *cs, GFP_KERNEL);
if (!cs) {
pr_err("Failed to allocate memory for clocksource\n");
+ err = ENOMEM;
goto out;
}
jcore_cs = &cs->cs;
@@ -207,12 +210,14 @@ static void __init jcore_pit_init(struct device_node
*node)
pit_percpu = alloc_percpu(struct jcore_pit);
if (!pit_percpu) {
pr_err("Failed to allocate memory for clock event device\n");
+ err = ENOMEM;
goto out;
}
nb = kzalloc(sizeof *nb, GFP_KERNEL);
if (!nb) {
pr_err("Failed to allocate memory for J-Core PIT notifier\n");
+ err = ENOMEM;
goto out;
}
@@ -268,10 +273,11 @@ static void __init jcore_pit_init(struct device_node
*node)
jcore_pit_local_init(this_cpu_ptr(pit_percpu));
- return;
+ return 0;
out:
pr_err("Could not initialize J-Core PIT driver\n");
+ return err;
}
CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
--
2.9.0
[PATCH linux v3 6/9] xen/events: use xen_vcpu_id mapping in events_base
EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - Use xen_vcpu_nr() helper [David Vrabel] --- drivers/xen/events/events_base.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 8fb7cbf..d5dbdb9 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -895,7 +895,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu) irq_set_chip_and_handler_name(irq, &xen_percpu_chip, handle_percpu_irq, "ipi"); - bind_ipi.vcpu = cpu; + bind_ipi.vcpu = xen_vcpu_nr(cpu); if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_ipi, &bind_ipi) != 0) BUG(); @@ -991,7 +991,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu) handle_edge_irq, "virq"); bind_virq.virq = virq; - bind_virq.vcpu = cpu; + bind_virq.vcpu = xen_vcpu_nr(cpu); ret = HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq, &bind_virq); if (ret == 0) @@ -1319,7 +1319,7 @@ static int rebind_irq_to_cpu(unsigned irq, unsigned tcpu) /* Send future instances of this interrupt to other vcpu. */ bind_vcpu.port = evtchn; - bind_vcpu.vcpu = tcpu; + bind_vcpu.vcpu = xen_vcpu_nr(tcpu); /* * Mask the event while changing the VCPU binding to prevent @@ -1459,7 +1459,7 @@ static void restore_cpu_virqs(unsigned int cpu) /* Get a new binding from Xen. */ bind_virq.virq = virq; - bind_virq.vcpu = cpu; + bind_virq.vcpu = xen_vcpu_nr(cpu); if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq, &bind_virq) != 0) BUG(); @@ -1483,7 +1483,7 @@ static void restore_cpu_ipis(unsigned int cpu) BUG_ON(ipi_from_irq(irq) != ipi); /* Get a new binding from Xen. */ - bind_ipi.vcpu = cpu; + bind_ipi.vcpu = xen_vcpu_nr(cpu); if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_ipi, &bind_ipi) != 0) BUG(); -- 2.7.4
[PATCH linux v3 8/9] xen/evtchn: use xen_vcpu_id mapping
Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id
for CPU0.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/xen/evtchn.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index f4edd6df..7c3113e 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
struct per_user_data {
@@ -448,7 +449,7 @@ static long evtchn_ioctl(struct file *file,
break;
bind_virq.virq = bind.virq;
- bind_virq.vcpu = 0;
+ bind_virq.vcpu = xen_vcpu_nr(0);
rc = HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
&bind_virq);
if (rc != 0)
--
2.7.4
[PATCH linux v3 7/9] xen/events: fifo: use xen_vcpu_id mapping
EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - Use xen_vcpu_nr() helper [David Vrabel] --- drivers/xen/events/events_fifo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c index 9289a17..266c2c7 100644 --- a/drivers/xen/events/events_fifo.c +++ b/drivers/xen/events/events_fifo.c @@ -113,7 +113,7 @@ static int init_control_block(int cpu, init_control.control_gfn = virt_to_gfn(control_block); init_control.offset = 0; - init_control.vcpu= cpu; + init_control.vcpu= xen_vcpu_nr(cpu); return HYPERVISOR_event_channel_op(EVTCHNOP_init_control, &init_control); } -- 2.7.4
[PATCH linux v3 9/9] xen/pvhvm: run xen_vcpu_setup() for the boot CPU
Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM
guests (while we had it for PV and ARM guests). This is usually fine as we
can use vcpu info in the sared_info page but when we try booting on a vCPU
with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this
CPU) we're not able to boot. Switch to always doing
VCPUOP_register_vcpu_info for the boot CPU.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/enlighten.c | 2 +-
arch/x86/xen/smp.c | 7 +++
arch/x86/xen/xen-ops.h | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c650677..9cc454c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -184,7 +184,7 @@ static void clamp_max_cpus(void)
#endif
}
-static void xen_vcpu_setup(int cpu)
+void xen_vcpu_setup(int cpu)
{
struct vcpu_register_vcpu_info info;
int err;
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index a3118f2..0b4d04c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -322,6 +322,13 @@ static void __init xen_smp_prepare_boot_cpu(void)
xen_filter_cpu_maps();
xen_setup_vcpu_info_placement();
}
+
+ /*
+* Setup vcpu_info for boot CPU.
+*/
+ if (xen_hvm_domain())
+ xen_vcpu_setup(0);
+
/*
* The alternative logic (which patches the unlock/lock) runs before
* the smp bootup up code is activated. Hence we need to set this up
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 4140b07..3cbce3b 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -76,6 +76,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
bool xen_vcpu_stolen(int vcpu);
+void xen_vcpu_setup(int cpu);
void xen_setup_vcpu_info_placement(void);
#ifdef CONFIG_SMP
--
2.7.4
[PATCH linux v3 5/9] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page
shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
these are the first 32 vCPUs from Xen's perspective and we should map them
accordingly with the newly introduced xen_vcpu_id mapping.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
arch/x86/xen/enlighten.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 3b0ceed..c650677 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -207,8 +207,9 @@ static void xen_vcpu_setup(int cpu)
if (per_cpu(xen_vcpu, cpu) == &per_cpu(xen_vcpu_info, cpu))
return;
}
- if (cpu < MAX_VIRT_CPUS)
- per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
+ if (xen_vcpu_nr(cpu) < MAX_VIRT_CPUS)
+ per_cpu(xen_vcpu, cpu) =
+ &HYPERVISOR_shared_info->vcpu_info[xen_vcpu_nr(cpu)];
if (!have_vcpu_info_placement) {
if (cpu >= MAX_VIRT_CPUS)
@@ -1781,9 +1782,10 @@ void __ref xen_hvm_init_shared_info(void)
* in that case multiple vcpus might be online. */
for_each_online_cpu(cpu) {
/* Leave it to be NULL. */
- if (cpu >= MAX_VIRT_CPUS)
+ if (xen_vcpu_nr(cpu) >= MAX_VIRT_CPUS)
continue;
- per_cpu(xen_vcpu, cpu) =
&HYPERVISOR_shared_info->vcpu_info[cpu];
+ per_cpu(xen_vcpu, cpu) =
+ &HYPERVISOR_shared_info->vcpu_info[xen_vcpu_nr(cpu)];
}
}
--
2.7.4
[PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs
It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This doesn't work very well for PVHVM guests as we have a number of hypercalls where we pass vCPU id as a parameter. These hypercalls either fail or do something unexpected. To solve the issue we need to have a mapping between Linux's and Xen's vCPU ids. This series solves the issue for x86 PVHVM guests. PV guests don't (and probably won't) support kdump so I always assume Xen's vCPU id == Linux's vCPU id. ARM guests will probably need to get proper mapping once we start supporting kexec/kdump there. Changes since v2: - Use 'uint32_t' for xen_vcpu_id mapping [Julien Grall] - Rebased to linux-4.7 Changes since v1: - "x86/acpi: store ACPI ids from MADT for future usage" patch added. - Use ACPI ids instead of vLAPIC ids/2 [Andrew Cooper, Jan Beulich] - Introduce xen_vcpu_nr() helper [David Vrabel]. - Modify all callers of HYPERVISOR_vcpu_op() instead of modifying HYPERVISOR_vcpu_op() [David Vrabel] Vitaly Kuznetsov (9): x86/xen: update cpuid.h from Xen-4.7 x86/acpi: store ACPI ids from MADT for future usage xen: introduce xen_vcpu_id mapping x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page xen/events: use xen_vcpu_id mapping in events_base xen/events: fifo: use xen_vcpu_id mapping xen/evtchn: use xen_vcpu_id mapping xen/pvhvm: run xen_vcpu_setup() for the boot CPU arch/arm/xen/enlighten.c | 13 +++- arch/x86/include/asm/cpu.h | 1 + arch/x86/include/asm/smp.h | 2 ++ arch/x86/include/asm/xen/cpuid.h | 5 - arch/x86/kernel/acpi/boot.c | 16 ++ arch/x86/kernel/apic/apic.c | 2 ++ arch/x86/kernel/setup_percpu.c | 3 +++ arch/x86/xen/enlighten.c | 45 +++- arch/x86/xen/irq.c | 3 ++- arch/x86/xen/smp.c | 18 +++- arch/x86/xen/time.c | 18 ++-- arch/x86/xen/xen-ops.h | 1 + drivers/xen/events/events_base.c | 13 ++-- drivers/xen/events/events_fifo.c | 2 +- drivers/xen/evtchn.c | 3 ++- drivers/xen/time.c | 2 +- include/xen/xen-ops.h| 6 ++ 17 files changed, 116 insertions(+), 37 deletions(-) -- 2.7.4
[PATCH linux v3 2/9] x86/acpi: store ACPI ids from MADT for future usage
Currently we don't save ACPI ids (unlike LAPIC ids which go to
x86_cpu_to_apicid) from MADT and we may need this information later.
Particularly, ACPI ids is the only existent way for a PVHVM Xen guest
to figure out Xen's idea of its vCPUs ids before these CPUs boot and
in some cases these ids diverge from Linux's cpu ids.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/cpu.h | 1 +
arch/x86/include/asm/smp.h | 2 ++
arch/x86/kernel/acpi/boot.c| 16
arch/x86/kernel/apic/apic.c| 2 ++
arch/x86/kernel/setup_percpu.c | 3 +++
5 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 59d34c5..9b7fa63 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -16,6 +16,7 @@ extern void prefill_possible_map(void);
static inline void prefill_possible_map(void) {}
#define cpu_physical_id(cpu) boot_cpu_physical_apicid
+#define cpu_acpi_id(cpu) 0
#define safe_smp_processor_id()0
#endif /* CONFIG_SMP */
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 0576b61..83463c0 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -33,6 +33,7 @@ static inline struct cpumask *cpu_llc_shared_mask(int cpu)
}
DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid);
+DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid);
DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid);
#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_32)
DECLARE_EARLY_PER_CPU_READ_MOSTLY(int, x86_cpu_to_logical_apicid);
@@ -147,6 +148,7 @@ void x86_idle_thread_init(unsigned int cpu, struct
task_struct *idle);
void smp_store_boot_cpu_info(void);
void smp_store_cpu_info(int id);
#define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu)
+#define cpu_acpi_id(cpu) per_cpu(x86_cpu_to_acpiid, cpu)
#else /* !CONFIG_SMP */
#define wbinvd_on_cpu(cpu) wbinvd()
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 9414f84..6738e5c 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -161,13 +161,15 @@ static int __init acpi_parse_madt(struct
acpi_table_header *table)
/**
* acpi_register_lapic - register a local apic and generates a logic cpu number
* @id: local apic id to register
+ * @acpiid: ACPI id to register
* @enabled: this cpu is enabled or not
*
* Returns the logic cpu number which maps to the local apic
*/
-static int acpi_register_lapic(int id, u8 enabled)
+static int acpi_register_lapic(int id, u32 acpiid, u8 enabled)
{
unsigned int ver = 0;
+ int cpu;
if (id >= MAX_LOCAL_APIC) {
printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
@@ -182,7 +184,11 @@ static int acpi_register_lapic(int id, u8 enabled)
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
- return generic_processor_info(id, ver);
+ cpu = generic_processor_info(id, ver);
+ if (cpu >= 0)
+ early_per_cpu(x86_cpu_to_acpiid, cpu) = acpiid;
+
+ return cpu;
}
static int __init
@@ -212,7 +218,7 @@ acpi_parse_x2apic(struct acpi_subtable_header *header,
const unsigned long end)
if (!apic->apic_id_valid(apic_id) && enabled)
printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
else
- acpi_register_lapic(apic_id, enabled);
+ acpi_register_lapic(apic_id, processor->uid, enabled);
#else
printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
#endif
@@ -240,6 +246,7 @@ acpi_parse_lapic(struct acpi_subtable_header * header,
const unsigned long end)
* when we use CPU hotplug.
*/
acpi_register_lapic(processor->id, /* APIC ID */
+ processor->processor_id, /* ACPI ID */
processor->lapic_flags & ACPI_MADT_ENABLED);
return 0;
@@ -258,6 +265,7 @@ acpi_parse_sapic(struct acpi_subtable_header *header, const
unsigned long end)
acpi_table_print_madt_entry(header);
acpi_register_lapic((processor->id << 8) | processor->eid,/* APIC ID */
+ processor->processor_id, /* ACPI ID */
processor->lapic_flags & ACPI_MADT_ENABLED);
return 0;
@@ -714,7 +722,7 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid,
int *pcpu)
{
int cpu;
- cpu = acpi_register_lapic(physid, ACPI_MADT_ENABLED);
+ cpu = acpi_register_lapic(physid, U32_MAX, ACPI_MADT_ENABLED);
if (cpu < 0) {
pr_info(PREFIX "Unable to map lapic to logical cpu number\n");
return cpu;
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index f943d2f..ac8d8ad 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -92,8 +92
[PATCH linux v3 1/9] x86/xen: update cpuid.h from Xen-4.7
Update cpuid.h header from xen hypervisor tree to get XEN_HVM_CPUID_VCPU_ID_PRESENT definition. Signed-off-by: Vitaly Kuznetsov --- arch/x86/include/asm/xen/cpuid.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h index 0d809e9..3bdd10d 100644 --- a/arch/x86/include/asm/xen/cpuid.h +++ b/arch/x86/include/asm/xen/cpuid.h @@ -76,15 +76,18 @@ /* * Leaf 5 (0x4x04) * HVM-specific features + * EAX: Features + * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag) */ -/* EAX Features */ /* Virtualized APIC registers */ #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized x2APIC accesses */ #define XEN_HVM_CPUID_X2APIC_VIRT (1u << 1) /* Memory mapped from other domains has valid IOMMU entries */ #define XEN_HVM_CPUID_IOMMU_MAPPINGS (1u << 2) +/* vcpu id is present in EBX */ +#define XEN_HVM_CPUID_VCPU_ID_PRESENT (1u << 3) #define XEN_CPUID_MAX_NUM_LEAVES 4 -- 2.7.4
[PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a number of hypercalls where we pass vCPU id as a parameter. These
hypercalls either fail or do something unexpected. To solve the issue
introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
CPUs it is a bit more trickier. Currently, we initialize IPI vectors
before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
instead.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v2:
- Use uint32_t for xen_vcpu_id mapping [Julien Grall]
Changes since v1:
- Introduce xen_vcpu_nr() helper [David Vrabel]
- Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
---
arch/arm/xen/enlighten.c | 10 ++
arch/x86/xen/enlighten.c | 23 ++-
include/xen/xen-ops.h| 6 ++
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..fe32267 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void
*)&xen_dummy_shared_info;
DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
static struct vcpu_info __percpu *xen_vcpu_info;
+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
+EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
+
/* These are unused until we support booting "pre-ballooned" */
unsigned long xen_released_pages;
struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
@@ -179,6 +183,9 @@ static void xen_percpu_init(void)
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
+ /* Direct vCPU id mapping for ARM guests. */
+ per_cpu(xen_vcpu_id, cpu) = cpu;
+
info.mfn = virt_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
@@ -328,6 +335,9 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
+ /* Direct vCPU id mapping for ARM guests. */
+ per_cpu(xen_vcpu_id, 0) = 0;
+
if (gnttab_setup_auto_xlat_frames(grant_frames)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0f87db2..c833912 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -118,6 +119,10 @@ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
*/
DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
+EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
+
enum xen_domain_type xen_domain_type = XEN_NATIVE;
EXPORT_SYMBOL_GPL(xen_domain_type);
@@ -1135,8 +1140,11 @@ void xen_setup_vcpu_info_placement(void)
{
int cpu;
- for_each_possible_cpu(cpu)
+ for_each_possible_cpu(cpu) {
+ /* Set up direct vCPU id mapping for PV guests. */
+ per_cpu(xen_vcpu_id, cpu) = cpu;
xen_vcpu_setup(cpu);
+ }
/* xen_vcpu_setup managed to place the vcpu_info within the
* percpu area for all cpus, so make use of it. Note that for
@@ -1727,6 +1735,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
#endif
xen_raw_console_write("about to get started...\n");
+ /* Let's presume PV guests always boot on vCPU with id 0. */
+ per_cpu(xen_vcpu_id, 0) = 0;
+
xen_setup_runstate_info(0);
xen_efi_init();
@@ -1795,6 +1806,12 @@ static void __init init_hvm_pv_info(void)
xen_setup_features();
+ cpuid(base + 4, &eax, &ebx, &ecx, &edx);
+ if (eax & XEN_HVM_CPUID_VCPU_ID_PRESENT)
+ this_cpu_write(xen_vcpu_id, ebx);
+ else
+ this_cpu_write(xen_vcpu_id, smp_processor_id());
+
pv_info.name = "Xen HVM";
xen_domain_type = XEN_HVM_DOMAIN;
@@ -1806,6 +1823,10 @@ static int xen_hvm_cpu_notify(struct notifier_block
*self, unsigned long action,
int cpu = (long)hcpu;
switch (action) {
case CPU_UP_PREPARE:
+ if (cpu_acpi_id(cpu) != U32_MAX)
+ per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
+ else
+ per_cpu(xen_vcpu_id, cpu) = cpu;
xen_vcpu_setup(cpu);
if (xen_have_vector_callback) {
if (xen_feature(XENFEAT_hvm_safe_pvclock))
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..648ce814 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -9,6 +9,12 @@
D
[PATCH] lkdtm: fix maybe-uninitialized warning
The do_usercopy_stack() function uses uninitialized stack data to initialize
more of the stack, which causes a warning in some configurations (ARM
allmodconfig):
drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used
uninitialized in this function [-Wmaybe-uninitialized]
The warning gets reports by Mark Brown's build bot and looks correct (we are
trying
to trick the compiler here, and sometimes the compiler notices), and I could
reproduce
it with gcc-4.7 through gcc-5.3 but not gcc-6.1 for some reason.
This changes the code to use the low byte of the address of the stack to
initialize
the stack data, instead of using data from the stack itself, to avoid the
warning.
Signed-off-by: Arnd Bergmann
Fixes: a3dff71c1c88 ("lkdtm: split usercopy tests to separate file")
---
drivers/misc/lkdtm_usercopy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/lkdtm_usercopy.c b/drivers/misc/lkdtm_usercopy.c
index 5a3fd76eec27..5525a204db93 100644
--- a/drivers/misc/lkdtm_usercopy.c
+++ b/drivers/misc/lkdtm_usercopy.c
@@ -49,7 +49,7 @@ static noinline void do_usercopy_stack(bool to_user, bool
bad_frame)
/* This is a pointer to outside our current stack frame. */
if (bad_frame) {
- bad_stack = do_usercopy_stack_callee((uintptr_t)bad_stack);
+ bad_stack = do_usercopy_stack_callee((uintptr_t)&bad_stack);
} else {
/* Put start address just inside stack. */
bad_stack = task_stack_page(current) + THREAD_SIZE;
--
2.9.0
[PATCH v10 8/8] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
From: Fu Wei
This driver adds support for parsing SBSA Generic Watchdog timer
in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT,
and creating a platform device with that information.
This allows the operating system to obtain device data from the
resource of platform device. The platform device named "sbsa-gwdt"
can be used by the ARM SBSA Generic Watchdog driver.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
drivers/acpi/arm64/acpi_gtdt.c | 87 ++
drivers/watchdog/Kconfig | 1 +
2 files changed, 88 insertions(+)
diff --git a/drivers/acpi/arm64/acpi_gtdt.c b/drivers/acpi/arm64/acpi_gtdt.c
index 0159175..05e838f 100644
--- a/drivers/acpi/arm64/acpi_gtdt.c
+++ b/drivers/acpi/arm64/acpi_gtdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
@@ -220,3 +221,89 @@ int __init gtdt_arch_timer_mem_init(struct gt_block_data
*data)
return index;
}
+
+/*
+ * Initialize a SBSA generic Watchdog platform device info from GTDT
+ */
+static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
+ int index)
+{
+ struct platform_device *pdev;
+ int irq = map_gt_gsi(wd->timer_interrupt, wd->timer_flags);
+ int no_irq = 1;
+
+ /*
+* According to SBSA specification the size of refresh and control
+* frames of SBSA Generic Watchdog is SZ_4K(Offset 0x000 – 0xFFF).
+*/
+ struct resource res[] = {
+ DEFINE_RES_MEM(wd->control_frame_address, SZ_4K),
+ DEFINE_RES_MEM(wd->refresh_frame_address, SZ_4K),
+ DEFINE_RES_IRQ(irq),
+ };
+
+ pr_debug("found a Watchdog (0x%llx/0x%llx gsi:%u flags:0x%x).\n",
+wd->refresh_frame_address, wd->control_frame_address,
+wd->timer_interrupt, wd->timer_flags);
+
+ if (!(wd->refresh_frame_address && wd->control_frame_address)) {
+ pr_err(FW_BUG "failed to get the Watchdog base address.\n");
+ return -EINVAL;
+ }
+
+ if (!wd->timer_interrupt)
+ pr_warn(FW_BUG "failed to get the Watchdog interrupt.\n");
+ else if (irq <= 0)
+ pr_warn("failed to map the Watchdog interrupt.\n");
+ else
+ no_irq = 0;
+
+ /*
+* Add a platform device named "sbsa-gwdt" to match the platform driver.
+* "sbsa-gwdt": SBSA(Server Base System Architecture) Generic Watchdog
+* The platform driver (like drivers/watchdog/sbsa_gwdt.c)can get device
+* info below by matching this name.
+*/
+ pdev = platform_device_register_simple("sbsa-gwdt", index, res,
+ ARRAY_SIZE(res) - no_irq);
+ if (IS_ERR(pdev)) {
+ acpi_unregister_gsi(wd->timer_interrupt);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
+
+static int __init gtdt_sbsa_gwdt_init(void)
+{
+ struct acpi_table_header *table;
+ void *platform_timer;
+ int index = 0;
+ int ret;
+
+ if (acpi_disabled)
+ return 0;
+
+ if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_GTDT, 0, &table)))
+ return -EINVAL;
+
+ ret = acpi_gtdt_init(table);
+ if (ret <= 0)
+ return ret;
+
+ for_each_platform_timer(platform_timer) {
+ if (!is_watchdog(platform_timer))
+ continue;
+ ret = gtdt_import_sbsa_gwdt(platform_timer, index);
+ if (ret)
+ break;
+ index++;
+ }
+
+ if (index)
+ pr_info("found %d SBSA generic Watchdog(s).\n", index);
+
+ return ret;
+}
+
+device_initcall(gtdt_sbsa_gwdt_init);
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b4b3e25..4019792 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -206,6 +206,7 @@ config ARM_SBSA_WATCHDOG
tristate "ARM SBSA Generic Watchdog"
depends on ARM64
depends on ARM_ARCH_TIMER
+ depends on ACPI_GTDT || !ACPI
select WATCHDOG_CORE
help
ARM SBSA Generic Watchdog has two stage timeouts:
--
2.5.5
[PATCH v10 5/8] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
From: Fu Wei
The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 50 +---
2 files changed, 13 insertions(+), 38 deletions(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b58d259..a63bf12 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -8,6 +8,7 @@ config CLKSRC_OF
config CLKSRC_ACPI
bool
select CLKSRC_PROBE
+ select ACPI_GTDT if ARM64
config CLKSRC_PROBE
bool
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d863459..b10d84c 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -869,61 +869,35 @@ out:
CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
arch_timer_mem_init);
-#ifdef CONFIG_ACPI
-static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
-{
- int trigger, polarity;
-
- if (!interrupt)
- return 0;
-
- trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
- : ACPI_LEVEL_SENSITIVE;
-
- polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
- : ACPI_ACTIVE_HIGH;
-
- return acpi_register_gsi(NULL, interrupt, trigger, polarity);
-}
-
+#ifdef CONFIG_ACPI_GTDT
/* Initialize per-processor generic timer */
static int __init arch_timer_acpi_init(struct acpi_table_header *table)
{
- struct acpi_table_gtdt *gtdt;
+ int timer_count;
if (arch_timers_present & ARCH_CP15_TIMER) {
pr_warn("already initialized, skipping\n");
return -EINVAL;
}
- gtdt = container_of(table, struct acpi_table_gtdt, header);
-
arch_timers_present |= ARCH_CP15_TIMER;
- arch_timer_ppi[PHYS_SECURE_PPI] =
- map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
- gtdt->secure_el1_flags);
-
- arch_timer_ppi[PHYS_NONSECURE_PPI] =
- map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
- gtdt->non_secure_el1_flags);
+ timer_count = acpi_gtdt_init(table);
- arch_timer_ppi[VIRT_PPI] =
- map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
- gtdt->virtual_timer_flags);
-
- arch_timer_ppi[HYP_PPI] =
- map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
- gtdt->non_secure_el2_flags);
+ arch_timer_ppi[PHYS_SECURE_PPI] = acpi_gtdt_map_ppi(PHYS_SECURE_PPI);
+ arch_timer_ppi[PHYS_NONSECURE_PPI] =
acpi_gtdt_map_ppi(PHYS_NONSECURE_PPI);
+ arch_timer_ppi[VIRT_PPI] = acpi_gtdt_map_ppi(VIRT_PPI);
+ arch_timer_ppi[HYP_PPI] = acpi_gtdt_map_ppi(HYP_PPI);
+ /* Always-on capability */
+ arch_timer_c3stop = acpi_gtdt_c3stop();
/* Get the frequency from CNTFRQ */
arch_timer_detect_rate(NULL, NULL);
- /* Always-on capability */
- arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
+ if (timer_count < 0)
+ pr_err("Failed to get platform timer info, skipping.\n");
- arch_timer_init();
- return 0;
+ return arch_timer_init();
}
CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
#endif
--
2.5.5
[PATCH v10 2/8] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
From: Fu Wei
This patch add a new enum "spi_nr" and use it in the driver.
Just for code's readability, no functional change.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 4 ++--
include/clocksource/arm_arch_timer.h | 6 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index cb08d63..b12fabd 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -843,9 +843,9 @@ static int __init arch_timer_mem_init(struct device_node
*np)
}
if (arch_timer_mem_use_virtual)
- irq = irq_of_parse_and_map(best_frame, 1);
+ irq = irq_of_parse_and_map(best_frame, VIRT_SPI);
else
- irq = irq_of_parse_and_map(best_frame, 0);
+ irq = irq_of_parse_and_map(best_frame, PHYS_SPI);
ret = -EINVAL;
if (!irq) {
diff --git a/include/clocksource/arm_arch_timer.h
b/include/clocksource/arm_arch_timer.h
index 6f06481..16dcd10 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -45,6 +45,12 @@ enum ppi_nr {
MAX_TIMER_PPI
};
+enum spi_nr {
+ PHYS_SPI,
+ VIRT_SPI,
+ MAX_TIMER_SPI
+};
+
#define ARCH_TIMER_PHYS_ACCESS 0
#define ARCH_TIMER_VIRT_ACCESS 1
#define ARCH_TIMER_MEM_PHYS_ACCESS 2
--
2.5.5
[PATCH v10 3/8] clocksource/drivers/arm_arch_timer: Improve printk relevant code
From: Fu Wei
This patch defines pr_fmt(fmt) for all pr_* functions,
then the pr_* doesn't need to add "arch_timer:" everytime.
Also delete some Blank Spaces in arch_timer_banner,
according to the suggestion from checkpatch.pl.
No functional change.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 53 ++--
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index b12fabd..d863459 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -29,6 +29,9 @@
#include
+#undef pr_fmt
+#define pr_fmt(fmt) "arch_timer: " fmt
+
#define CNTTIDR0x08
#define CNTTIDR_VIRT(n)(BIT(1) << ((n) * 4))
@@ -396,24 +399,24 @@ arch_timer_detect_rate(void __iomem *cntbase, struct
device_node *np)
/* Check the timer frequency. */
if (arch_timer_rate == 0)
- pr_warn("Architected timer frequency not available\n");
+ pr_warn("frequency not available\n");
}
static void arch_timer_banner(unsigned type)
{
- pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz
(%s%s%s).\n",
-type & ARCH_CP15_TIMER ? "cp15" : "",
-type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
-type & ARCH_MEM_TIMER ? "mmio" : "",
-(unsigned long)arch_timer_rate / 100,
-(unsigned long)(arch_timer_rate / 1) % 100,
-type & ARCH_CP15_TIMER ?
-(arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
- "",
-type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
-type & ARCH_MEM_TIMER ?
- arch_timer_mem_use_virtual ? "virt" : "phys" :
- "");
+ pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
+ type & ARCH_CP15_TIMER ? "cp15" : "",
+ type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
+ type & ARCH_MEM_TIMER ? "mmio" : "",
+ (unsigned long)arch_timer_rate / 100,
+ (unsigned long)(arch_timer_rate / 1) % 100,
+ type & ARCH_CP15_TIMER ?
+ (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
+ "",
+ type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
+ type & ARCH_MEM_TIMER ?
+ arch_timer_mem_use_virtual ? "virt" : "phys" :
+ "");
}
u32 arch_timer_get_rate(void)
@@ -506,8 +509,7 @@ static void __init arch_counter_register(unsigned type)
static void arch_timer_stop(struct clock_event_device *clk)
{
- pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
-clk->irq, smp_processor_id());
+ pr_debug("disable IRQ%d cpu #%d\n", clk->irq, smp_processor_id());
disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
if (arch_timer_has_nonsecure_ppi())
@@ -605,8 +607,7 @@ static int __init arch_timer_register(void)
}
if (err) {
- pr_err("arch_timer: can't register interrupt %d (%d)\n",
- ppi, err);
+ pr_err("can't register interrupt %d (%d)\n", ppi, err);
goto out_free;
}
@@ -658,7 +659,7 @@ static int __init arch_timer_mem_register(void __iomem
*base, unsigned int irq)
ret = request_irq(irq, func, IRQF_TIMER, "arch_mem_timer", &t->evt);
if (ret) {
- pr_err("arch_timer: Failed to request mem timer irq\n");
+ pr_err("Failed to request mem timer irq\n");
kfree(t);
}
@@ -736,7 +737,7 @@ static int __init arch_timer_init(void)
}
if (!has_ppi) {
- pr_warn("arch_timer: No interrupt available, giving
up\n");
+ pr_warn("No interrupt available, giving up\n");
return -EINVAL;
}
}
@@ -759,7 +760,7 @@ static int __init arch_timer_of_init(struct device_node *np)
int i;
if (arch_timers_present & ARCH_CP15_TIMER) {
- pr_warn("arch_timer: multiple nodes in dt, skipping\n");
+ pr_warn("multiple nodes in dt, skipping\n");
return 0;
}
@@ -794,7 +795,7 @@ static int __init arch_timer_mem_init(struct device_node
*np)
arch_timers_present |= ARCH_MEM_TIMER;
cntctlbase = of_iomap(np, 0);
if (!cntctlbase) {
- pr_err("arch_timer: Can't find CNTCTLBase\n");
+ pr_err("Can't find CNTCTLBase\n");
return -ENXIO;
}
@@ -809,7 +810,7 @@ static int __init arch_timer_mem_init(struct device_node
*np)
u32 cntacr;
if (of_property_read_u32(frame, "frame-number", &n)) {
[PATCH v10 4/8] acpi/arm64: Add GTDT table parse driver
From: Fu Wei
This patch adds support for parsing arch timer in GTDT,
provides some kernel APIs to parse all the PPIs and
always-on info in GTDT and export them.
By this driver, we can simplify arm_arch_timer drivers, and
separate the ACPI GTDT knowledge from it.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
arch/arm64/Kconfig | 1 +
drivers/acpi/Kconfig | 5 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/arm64/Kconfig | 5 ++
drivers/acpi/arm64/Makefile| 1 +
drivers/acpi/arm64/acpi_gtdt.c | 152 +
drivers/clocksource/Kconfig| 1 -
include/linux/acpi.h | 6 ++
8 files changed, 171 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5a0a691..0b9fba7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
def_bool y
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
+ select ACPI_GTDT if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index b7e2e77..1cdc7d2 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -521,4 +521,9 @@ config XPOWER_PMIC_OPREGION
endif
+if ARM64
+source "drivers/acpi/arm64/Kconfig"
+
+endif
+
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 251ce85..1a94ff7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -99,5 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
+obj-$(CONFIG_ARM64)+= arm64/
video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
new file mode 100644
index 000..80201be
--- /dev/null
+++ b/drivers/acpi/arm64/Kconfig
@@ -0,0 +1,5 @@
+#
+# ACPI Configuration for ARM64
+#
+config ACPI_GTDT
+ bool
diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
new file mode 100644
index 000..466de6b
--- /dev/null
+++ b/drivers/acpi/arm64/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ACPI_GTDT)+= acpi_gtdt.o
diff --git a/drivers/acpi/arm64/acpi_gtdt.c b/drivers/acpi/arm64/acpi_gtdt.c
new file mode 100644
index 000..cdb2fb1
--- /dev/null
+++ b/drivers/acpi/arm64/acpi_gtdt.c
@@ -0,0 +1,152 @@
+/*
+ * ARM Specific GTDT table Support
+ *
+ * Copyright (C) 2016, Linaro Ltd.
+ * Author: Daniel Lezcano
+ * Fu Wei
+ * Hanjun Guo
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#undef pr_fmt
+#define pr_fmt(fmt) "ACPI GTDT: " fmt
+
+typedef struct {
+ struct acpi_table_gtdt *gtdt;
+ void *platform_timer_start;
+ void *gtdt_end;
+} acpi_gtdt_desc_t;
+
+static acpi_gtdt_desc_t acpi_gtdt_desc __initdata;
+
+static inline void *next_platform_timer(void *platform_timer)
+{
+ struct acpi_gtdt_header *gh = platform_timer;
+
+ platform_timer += gh->length;
+ if (platform_timer < acpi_gtdt_desc.gtdt_end)
+ return platform_timer;
+
+ return NULL;
+}
+
+#define for_each_platform_timer(_g)\
+ for (_g = acpi_gtdt_desc.platform_timer_start; _g; \
+_g = next_platform_timer(_g))
+
+static inline bool is_timer_block(void *platform_timer)
+{
+ struct acpi_gtdt_header *gh = platform_timer;
+
+ return gh->type == ACPI_GTDT_TYPE_TIMER_BLOCK;
+}
+
+static inline bool is_watchdog(void *platform_timer)
+{
+ struct acpi_gtdt_header *gh = platform_timer;
+
+ return gh->type == ACPI_GTDT_TYPE_WATCHDOG;
+}
+
+static int __init map_gt_gsi(u32 interrupt, u32 flags)
+{
+ int trigger, polarity;
+
+ if (!interrupt)
+ return 0;
+
+ trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
+ : ACPI_LEVEL_SENSITIVE;
+
+ polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+
+ return acpi_register_gsi(NULL, interrupt, trigger, polarity);
+}
+
+/*
+ * Map the PPIs of per-cpu arch_timer.
+ * @type: the type of PPI
+ * Returns 0 if error.
+ */
+int __init acpi_gtdt_map_ppi(int type)
+{
+ struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt;
+
+ switch (type) {
+ case PHYS_SECURE_PPI:
+ return map_gt_gsi(gtdt->secure_el1_interrupt,
+ gtdt->secure_el1_flags);
+ case PHYS_NONSECURE_PPI:
+ return map_gt_gsi(gtdt->non_secure_el1_interrupt,
+
[PATCH v10 6/8] acpi/arm64: Add memory-mapped timer support in GTDT driver
From: Fu Wei
On platforms booting with ACPI, architected memory-mapped timers'
configuration data is provided by firmware through the ACPI GTDT
static table.
The clocksource architected timer kernel driver requires a firmware
interface to collect timer configuration and configure its driver.
this infrastructure is present for device tree systems, but it is
missing on systems booting with ACPI.
Implement the kernel infrastructure required to parse the static
ACPI GTDT table so that the architected timer clocksource driver can
make use of it on systems booting with ACPI, therefore enabling
the corresponding timers configuration.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
drivers/acpi/arm64/acpi_gtdt.c | 70
include/clocksource/arm_arch_timer.h | 15
include/linux/acpi.h | 1 +
3 files changed, 86 insertions(+)
diff --git a/drivers/acpi/arm64/acpi_gtdt.c b/drivers/acpi/arm64/acpi_gtdt.c
index cdb2fb1..0159175 100644
--- a/drivers/acpi/arm64/acpi_gtdt.c
+++ b/drivers/acpi/arm64/acpi_gtdt.c
@@ -150,3 +150,73 @@ int __init acpi_gtdt_init(struct acpi_table_header *table)
return gtdt->platform_timer_count;
}
+
+static int __init gtdt_parse_gt_block(struct acpi_gtdt_timer_block *block,
+ struct gt_block_data *data)
+{
+ struct acpi_gtdt_timer_entry *frame;
+ int i;
+
+ if (!block || !data)
+ return -EINVAL;
+
+ if (!block->block_address || !block->timer_count)
+ return -EINVAL;
+
+ data->cntctlbase_phy = (phys_addr_t)block->block_address;
+ data->timer_count = block->timer_count;
+
+ frame = (void *)block + block->timer_offset;
+ if (frame + block->timer_count != (void *)block + block->header.length)
+ return -EINVAL;
+
+ /*
+* Get the GT timer Frame data for every GT Block Timer
+*/
+ for (i = 0; i < block->timer_count; i++, frame++) {
+ if (!frame->base_address || !frame->timer_interrupt)
+ return -EINVAL;
+
+ data->timer[i].irq = map_gt_gsi(frame->timer_interrupt,
+ frame->timer_flags);
+ if (data->timer[i].irq <= 0)
+ return -EINVAL;
+
+ if (frame->virtual_timer_interrupt) {
+ data->timer[i].virtual_irq =
+ map_gt_gsi(frame->virtual_timer_interrupt,
+ frame->virtual_timer_flags);
+ if (data->timer[i].virtual_irq <= 0)
+ return -EINVAL;
+ }
+
+ data->timer[i].frame_nr = frame->frame_number;
+ data->timer[i].cntbase_phy = frame->base_address;
+ }
+
+ return 0;
+}
+
+/*
+ * Get the GT block info for memory-mapped timer from GTDT table.
+ */
+int __init gtdt_arch_timer_mem_init(struct gt_block_data *data)
+{
+ void *platform_timer;
+ int index = 0;
+ int ret;
+
+ for_each_platform_timer(platform_timer) {
+ if (!is_timer_block(platform_timer))
+ continue;
+ ret = gtdt_parse_gt_block(platform_timer, data + index);
+ if (ret)
+ return ret;
+ index++;
+ }
+
+ if (index)
+ pr_info("found %d memory-mapped timer block(s).\n", index);
+
+ return index;
+}
diff --git a/include/clocksource/arm_arch_timer.h
b/include/clocksource/arm_arch_timer.h
index 16dcd10..94a5d14 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -56,6 +56,8 @@ enum spi_nr {
#define ARCH_TIMER_MEM_PHYS_ACCESS 2
#define ARCH_TIMER_MEM_VIRT_ACCESS 3
+#define ARCH_TIMER_MEM_MAX_FRAME 8
+
#define ARCH_TIMER_USR_PCT_ACCESS_EN (1 << 0) /* physical counter */
#define ARCH_TIMER_USR_VCT_ACCESS_EN (1 << 1) /* virtual counter */
#define ARCH_TIMER_VIRT_EVT_EN (1 << 2)
@@ -71,6 +73,19 @@ struct arch_timer_kvm_info {
int virtual_irq;
};
+struct gt_timer_data {
+ int frame_nr;
+ phys_addr_t cntbase_phy;
+ int irq;
+ int virtual_irq;
+};
+
+struct gt_block_data {
+ phys_addr_t cntctlbase_phy;
+ int timer_count;
+ struct gt_timer_data timer[ARCH_TIMER_MEM_MAX_FRAME];
+};
+
#ifdef CONFIG_ARM_ARCH_TIMER
extern u32 arch_timer_get_rate(void);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index fb8b689..24b1750 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -536,6 +536,7 @@ struct platform_device *acpi_create_platform_device(struct
acpi_device *);
int acpi_gtdt_init(struct acpi_table_header *table);
int acpi_gtdt_map_ppi(int type);
bool acpi_gtdt_c3stop(void);
+int gtdt_arch_timer_mem_init(struct gt_block_data *data);
#endif
#else /* !CONFIG_ACPI */
--
2.5.5
[PATCH v10 7/8] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
From: Fu Wei
The patch add memory-mapped timer register support by using the information
provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 127 ++-
1 file changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index b10d84c..3f6a78c 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -870,7 +870,128 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem,
"arm,armv7-timer-mem",
arch_timer_mem_init);
#ifdef CONFIG_ACPI_GTDT
-/* Initialize per-processor generic timer */
+static struct gt_timer_data __init *arch_timer_mem_get_timer(
+ struct gt_block_data *gt_blocks)
+{
+ struct gt_block_data *gt_block = gt_blocks;
+ struct gt_timer_data *best_frame = NULL;
+ void __iomem *cntctlbase;
+ u32 cnttidr;
+ int i;
+
+ /*
+* According to ARMv8 Architecture Reference Manual(ARM),
+* the size of CNTCTLBase frame of memory-mapped timer
+* is SZ_4K(Offset 0x000 – 0xFFF).
+*/
+ cntctlbase = ioremap(gt_block->cntctlbase_phy, SZ_4K);
+ if (!cntctlbase) {
+ pr_err("Failed to map mem timer control frame base address\n");
+ return NULL;
+ }
+ cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
+
+ /*
+* Try to find a virtual capable frame. Otherwise fall back to a
+* physical capable frame.
+*/
+ for (i = 0; i < gt_block->timer_count; i++) {
+ int n;
+ u32 cntacr;
+
+ n = gt_block->timer[i].frame_nr;
+
+ /* Try enabling everything, and see what sticks */
+ cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
+CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
+ writel_relaxed(cntacr, cntctlbase + CNTACR(n));
+ cntacr = readl_relaxed(cntctlbase + CNTACR(n));
+
+ if ((cnttidr & CNTTIDR_VIRT(n)) &&
+ !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
+ best_frame = >_block->timer[i];
+ arch_timer_mem_use_virtual = true;
+ break;
+ }
+
+ if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
+ continue;
+
+ best_frame = >_block->timer[i];
+ }
+ iounmap(cntctlbase);
+
+ return best_frame;
+}
+
+static int __init arch_timer_mem_acpi_init(size_t timer_count)
+{
+ struct gt_block_data *gt_blocks;
+ struct gt_timer_data *gt_timer;
+ void __iomem *timer_cntbase;
+ int ret = -EINVAL;
+ int timer_irq;
+
+ /*
+* If we don't have any Platform Timer Structures, just return.
+*/
+ if (!timer_count)
+ return 0;
+
+ /*
+* before really check all the Platform Timer Structures,
+* we assume they are GT block, and allocate memory for them.
+* We will free these memory once we finish the initialization.
+*/
+ gt_blocks = kcalloc(timer_count, sizeof(*gt_blocks), GFP_KERNEL);
+ if (!gt_blocks)
+ return -ENOMEM;
+
+ if (gtdt_arch_timer_mem_init(gt_blocks) > 0) {
+ gt_timer = arch_timer_mem_get_timer(gt_blocks);
+ if (!gt_timer) {
+ pr_err("Failed to get mem timer info.\n");
+ goto error;
+ }
+
+ if (arch_timer_mem_use_virtual)
+ timer_irq = gt_timer->virtual_irq;
+ else
+ timer_irq = gt_timer->irq;
+ if (!timer_irq) {
+ pr_err("Failed to get %s irq for mem timer.",
+ arch_timer_mem_use_virtual ? "virt" : "phys");
+ goto error;
+ }
+
+ /*
+* According to ARMv8 Architecture Reference Manual(ARM),
+* the size of CNTBaseN frames of memory-mapped timer
+* is SZ_4K(Offset 0x000 – 0xFFF).
+*/
+ timer_cntbase = ioremap(gt_timer->cntbase_phy, SZ_4K);
+ if (!timer_cntbase) {
+ pr_err("Failed to map mem timer base address.\n");
+ goto error;
+ }
+
+ ret = arch_timer_mem_register(timer_cntbase, timer_irq);
+ if (ret) {
+ iounmap(timer_cntbase);
+ pr_err("Failed to register mem timer.\n");
+ goto error;
+ }
+
+ arch_counter_base = timer_cntbase;
+ arch_timers_present |= ARCH_MEM_TIMER;
+ }
+
+error:
+ kfree(gt_blocks);
+ return ret;
+}
+
+/* Initialize per-processor ge
[PATCH v10 0/8] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei This patchset: (1)Preparation for adding GTDT support in arm_arch_timer: 1. Move some enums and marcos to header file; 2. Add a new enum for spi type; 3. Improve printk relevant code. (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timer This patchset has been tested on the following platforms: (1)ARM Foundation v8 model Changelog: V10: https://lkml.org/lkml/2016/7/26/ Drop the "readq" patch. Rebase to latest Linux 4.7. V9: https://lkml.org/lkml/2016/7/25/345 Improve pr_err message in acpi gtdt driver. Update Commit message for 7/9 shorten the irq mapping function name Improve GTDT driver for memory-mapped timer v8: https://lkml.org/lkml/2016/7/19/660 Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT", and also improve printk message. Simplify is_timer_block and is_watchdog. Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init(); Delete __init in include/linux/acpi.h for GTDT API Make ARM64 select GTDT. Delete "#include " from acpi_gtdt.c Simplify GT block parse code. v7: https://lkml.org/lkml/2016/7/13/769 Move the GTDT driver to drivers/acpi/arm64 Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS Merge 3 patches of GTDT parser driver. Fix the for_each_platform_timer bug. v6: https://lkml.org/lkml/2016/6/29/580 split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer, and SBSA Generic Watchdog timer Improve driver by suggestions and example code from Daniel Lezcano v5: https://lkml.org/lkml/2016/5/24/356 Sorting out all patches, simplify the API of GTDT driver: GTDT driver just fills the data struct for arm_arch_timer driver. v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html Delete the kvm relevant patches Separate two patches for sorting out the code for arm_arch_timer. Improve irq info export code to allow missing irq info in GTDT table. v3: https://lkml.org/lkml/2016/2/1/658 Improve GTDT driver code: (1)improve pr_* by defining pr_fmt(fmt) (2)simplify gtdt_sbsa_gwdt_init (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try to get GTDT table. Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr. Add arm_arch_timer get ppi from DT and GTDT support for kvm. v2: https://lkml.org/lkml/2015/12/2/10 Rebase to latest kernel version(4.4-rc3). Fix the bug about the config problem, use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553 Fu Wei (8): clocksource/drivers/arm_arch_timer: Move enums and defines to header file clocksource/drivers/arm_arch_timer: Add a new enum for spi type clocksource/drivers/arm_arch_timer: Improve printk relevant code acpi/arm64: Add GTDT table parse driver clocksource/drivers/arm_arch_timer: Simplify ACPI support code. acpi/arm64: Add memory-mapped timer support in GTDT driver clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver arch/arm64/Kconfig | 1 + drivers/acpi/Kconfig | 5 + drivers/acpi/Makefile| 1 + drivers/acpi/arm64/Kconfig | 5 + drivers/acpi/arm64/Makefile | 1 + drivers/acpi/arm64/acpi_gtdt.c | 309 +++ drivers/clocksource/Kconfig | 2 +- drivers/clocksource/arm_arch_timer.c | 225 + drivers/watchdog/Kconfig | 1 + include/clocksource/arm_arch_timer.h | 32 include/linux/acpi.h | 7 + 11 files changed, 518 insertions(+), 71 deletions(-) create mode 100644 drivers/acpi/arm64/Kconfig create mode 100644 drivers/acpi/arm64/Makefile create mode 100644 drivers/acpi/arm64/acpi_gtdt.c -- 2.5.5
[PATCH v10 1/8] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
From: Fu Wei
To support the arm_arch_timer via ACPI we need to share defines and enums
between the driver and the ACPI parser code.
Split out the relevant defines and enums into arm_arch_timer.h.
No functional change.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 11 ---
include/clocksource/arm_arch_timer.h | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 5effd30..cb08d63 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -48,8 +48,6 @@
#define CNTV_TVAL 0x38
#define CNTV_CTL 0x3c
-#define ARCH_CP15_TIMERBIT(0)
-#define ARCH_MEM_TIMER BIT(1)
static unsigned arch_timers_present __initdata;
static void __iomem *arch_counter_base;
@@ -62,15 +60,6 @@ struct arch_timer {
#define to_arch_timer(e) container_of(e, struct arch_timer, evt)
static u32 arch_timer_rate;
-
-enum ppi_nr {
- PHYS_SECURE_PPI,
- PHYS_NONSECURE_PPI,
- VIRT_PPI,
- HYP_PPI,
- MAX_TIMER_PPI
-};
-
static int arch_timer_ppi[MAX_TIMER_PPI];
static struct clock_event_device __percpu *arch_timer_evt;
diff --git a/include/clocksource/arm_arch_timer.h
b/include/clocksource/arm_arch_timer.h
index caedb74..6f06481 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -19,6 +19,9 @@
#include
#include
+#define ARCH_CP15_TIMERBIT(0)
+#define ARCH_MEM_TIMER BIT(1)
+
#define ARCH_TIMER_CTRL_ENABLE (1 << 0)
#define ARCH_TIMER_CTRL_IT_MASK(1 << 1)
#define ARCH_TIMER_CTRL_IT_STAT(1 << 2)
@@ -34,6 +37,14 @@ enum arch_timer_reg {
ARCH_TIMER_REG_TVAL,
};
+enum ppi_nr {
+ PHYS_SECURE_PPI,
+ PHYS_NONSECURE_PPI,
+ VIRT_PPI,
+ HYP_PPI,
+ MAX_TIMER_PPI
+};
+
#define ARCH_TIMER_PHYS_ACCESS 0
#define ARCH_TIMER_VIRT_ACCESS 1
#define ARCH_TIMER_MEM_PHYS_ACCESS 2
--
2.5.5
[PATCH] xen: add static initialization of steal_clock op to xen_time_ops
pv_time_ops might be overwritten with xen_time_ops after the
steal_clock operation has been initialized already. To prevent calling
a now uninitialized function pointer add the steal_clock static
initialization to xen_time_ops.
Signed-off-by: Juergen Gross
---
arch/x86/xen/time.c | 1 +
drivers/xen/time.c| 2 +-
include/xen/xen-ops.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index c31006f..a3e8f08 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -359,6 +359,7 @@ void xen_timer_resume(void)
static const struct pv_time_ops xen_time_ops __initconst = {
.sched_clock = xen_clocksource_read,
+ .steal_clock = xen_steal_clock,
};
static void __init xen_time_init(void)
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index a7fe35b..e6f9b2b 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -80,7 +80,7 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
}
-static u64 xen_steal_clock(int cpu)
+u64 xen_steal_clock(int cpu)
{
struct vcpu_runstate_info state;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 77bf9d1..0d1f9b9 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -23,6 +23,7 @@ bool xen_vcpu_stolen(int vcpu);
void xen_setup_runstate_info(int cpu);
void xen_time_setup_guest(void);
void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
+u64 xen_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
--
2.6.6
[PATCH v2 3/4] arm64: dts: rockchip: add reset saradc node for rk3368 SoCs
SARADC controller needs to be reset before programming it, otherwise it will not function properly. Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi index d02a9003..4f44d11 100644 --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi @@ -270,6 +270,8 @@ #io-channel-cells = <1>; clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>; clock-names = "saradc", "apb_pclk"; + resets = <&cru SRST_SARADC>; + reset-names = "saradc-apb"; status = "disabled"; }; -- 1.9.1
[PATCH v2 2/4] arm64: dts: rockchip: add the saradc for rk3399
This patch adds saradc needed information on rk3399 SoCs.
Signed-off-by: Caesar Wang
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4c84229..b81f84b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -299,6 +299,18 @@
};
};
+ saradc: saradc@ff10 {
+ compatible = "rockchip,rk3399-saradc";
+ reg = <0x0 0xff10 0x0 0x100>;
+ interrupts = ;
+ #io-channel-cells = <1>;
+ clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
+ clock-names = "saradc", "apb_pclk";
+ resets = <&cru SRST_P_SARADC>;
+ reset-names = "saradc-apb";
+ status = "disabled";
+ };
+
i2c1: i2c@ff11 {
compatible = "rockchip,rk3399-i2c";
reg = <0x0 0xff11 0x0 0x1000>;
--
1.9.1
[PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it
SARADC controller needs to be reset before programming it, otherwise
it will not function properly.
Signed-off-by: Caesar Wang
Cc: Jonathan Cameron
Cc: Heiko Stuebner
Cc: Rob Herring
Cc: linux-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
---
Changes in v2:
- Make the reset as an optional property, since it should work
with old devicetrees as well.
.../bindings/iio/adc/rockchip-saradc.txt | 7 +
drivers/iio/adc/Kconfig| 1 +
drivers/iio/adc/rockchip_saradc.c | 31 ++
3 files changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
index bf99e2f..205593f 100644
--- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
@@ -16,6 +16,11 @@ Required properties:
- vref-supply: The regulator supply ADC reference voltage.
- #io-channel-cells: Should be 1, see ../iio-bindings.txt
+Optional properties:
+- resets: Must contain an entry for each entry in reset-names if need support
+ this option. See ../reset/reset.txt for details.
+- reset-names: Must include the name "saradc-apb".
+
Example:
saradc: saradc@2006c000 {
compatible = "rockchip,saradc";
@@ -23,6 +28,8 @@ Example:
interrupts = ;
clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
clock-names = "saradc", "apb_pclk";
+ resets = <&cru SRST_SARADC>;
+ reset-names = "saradc-apb";
#io-channel-cells = <1>;
vref-supply = <&vcc18>;
};
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 1de31bd..7675772 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -389,6 +389,7 @@ config QCOM_SPMI_VADC
config ROCKCHIP_SARADC
tristate "Rockchip SARADC driver"
depends on ARCH_ROCKCHIP || (ARM && COMPILE_TEST)
+ depends on RESET_CONTROLLER
help
Say yes here to build support for the SARADC found in SoCs from
Rockchip.
diff --git a/drivers/iio/adc/rockchip_saradc.c
b/drivers/iio/adc/rockchip_saradc.c
index f9ad6c2..dc1379f 100644
--- a/drivers/iio/adc/rockchip_saradc.c
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -53,6 +55,7 @@ struct rockchip_saradc {
struct clk *clk;
struct completion completion;
struct regulator*vref;
+ struct reset_control*reset;
const struct rockchip_saradc_data *data;
u16 last_val;
};
@@ -190,6 +193,16 @@ static const struct of_device_id rockchip_saradc_match[] =
{
};
MODULE_DEVICE_TABLE(of, rockchip_saradc_match);
+/**
+ * Reset SARADC Controller.
+ */
+static void rockchip_saradc_reset_controller(struct reset_control *reset)
+{
+ reset_control_assert(reset);
+ usleep_range(10, 20);
+ reset_control_deassert(reset);
+}
+
static int rockchip_saradc_probe(struct platform_device *pdev)
{
struct rockchip_saradc *info = NULL;
@@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct platform_device
*pdev)
if (IS_ERR(info->regs))
return PTR_ERR(info->regs);
+ /*
+* The reset should be an optional property, as it should work
+* with old devicetrees as well
+*/
+ info->reset = devm_reset_control_get_optional(&pdev->dev,
+ "saradc-apb");
+ if (IS_ERR(info->reset)) {
+ ret = PTR_ERR(info->reset);
+ if (ret != -ENOENT)
+ return ret;
+
+ dev_dbg(&pdev->dev, "no reset control found\n");
+ info->reset = NULL;
+ }
+
init_completion(&info->completion);
irq = platform_get_irq(pdev, 0);
@@ -252,6 +280,9 @@ static int rockchip_saradc_probe(struct platform_device
*pdev)
return PTR_ERR(info->vref);
}
+ if (info->reset)
+ rockchip_saradc_reset_controller(info->reset);
+
/*
* Use a default value for the converter clock.
* This may become user-configurable in the future.
--
1.9.1
[PATCH v2 4/4] arm: dts: rockchip: add reset node for the exist saradc SoCs
SARADC controller needs to be reset before programming it, otherwise it will not function properly. Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm/boot/dts/rk3066a.dtsi | 2 ++ arch/arm/boot/dts/rk3288.dtsi | 2 ++ arch/arm/boot/dts/rk3xxx.dtsi | 2 ++ 3 files changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi index c0ba86c..0d0dae3 100644 --- a/arch/arm/boot/dts/rk3066a.dtsi +++ b/arch/arm/boot/dts/rk3066a.dtsi @@ -197,6 +197,8 @@ clock-names = "saradc", "apb_pclk"; interrupts = ; #io-channel-cells = <1>; + resets = <&cru SRST_SARADC>; + reset-names = "saradc-apb"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index cd33f01..91c4b3c 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -279,6 +279,8 @@ #io-channel-cells = <1>; clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>; clock-names = "saradc", "apb_pclk"; + resets = <&cru SRST_SARADC>; + reset-names = "saradc-apb"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi index 99bbcc2..e2cd683 100644 --- a/arch/arm/boot/dts/rk3xxx.dtsi +++ b/arch/arm/boot/dts/rk3xxx.dtsi @@ -399,6 +399,8 @@ #io-channel-cells = <1>; clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>; clock-names = "saradc", "apb_pclk"; + resets = <&cru SRST_SARADC>; + reset-names = "saradc-apb"; status = "disabled"; }; -- 1.9.1
Re: [PATCH] README: Mention when 386 support ended + update obsolete 386 paths
On Tue, 26 Jul 2016 09:45:43 +0200 Øyvind A. Holm wrote: > - Compiling the kernel with "Processor type" set higher than 386 >will result in a kernel that does NOT work on a 386. The > - kernel will detect this on bootup, and give up. > + kernel will detect this on bootup, and give up. The last kernel > + with support for 386 was version 3.7. So we want the documentation to reflect current kernels, not those from years gone by. I can't think of a reason why this paragraph should continue to exist at all. Can you make a new version that removes it altogether? Thanks, jon
[PATCH 1/6] extcon: Add the extcon_type to group each connector into five category
This patch adds the new extcon type to group the each connecotr
into following five category. This type would be used to handle
the connectors as a group unit instead of a connector unit.
- EXTCON_TYPE_USB : USB connector
- EXTCON_TYPE_CHG : Charger connector
- EXTCON_TYPE_JACK : Jack connector
- EXTCON_TYPE_DISP : Display connector
- EXTCON_TYPE_MISC : Miscellaneous connector
Also, each external connector is possible to belong to one more extcon type.
In caes of EXTCON_CHG_USB_SDP, it have the EXTCON_TYPE_CHG and EXTCON_TYPE_USB.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 159 +++-
include/linux/extcon.h | 9 +++
2 files changed, 139 insertions(+), 29 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 5b61000cde26..b1e6ee6194bc 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -38,43 +38,144 @@
#define SUPPORTED_CABLE_MAX32
#define CABLE_NAME_MAX 30
-static const char *extcon_name[] = {
- [EXTCON_NONE] = "NONE",
+struct __extcon_info {
+ unsigned int type;
+ unsigned int id;
+ const char *name;
+
+} extcon_info[] = {
+ [EXTCON_NONE] = {
+ .type = EXTCON_TYPE_MISC,
+ .id = EXTCON_NONE,
+ .name = "NONE",
+ },
/* USB external connector */
- [EXTCON_USB]= "USB",
- [EXTCON_USB_HOST] = "USB-HOST",
+ [EXTCON_USB] = {
+ .type = EXTCON_TYPE_USB,
+ .id = EXTCON_USB,
+ .name = "USB",
+ },
+ [EXTCON_USB_HOST] = {
+ .type = EXTCON_TYPE_USB,
+ .id = EXTCON_USB,
+ .name = "USB_HOST",
+ },
/* Charging external connector */
- [EXTCON_CHG_USB_SDP]= "SDP",
- [EXTCON_CHG_USB_DCP]= "DCP",
- [EXTCON_CHG_USB_CDP]= "CDP",
- [EXTCON_CHG_USB_ACA]= "ACA",
- [EXTCON_CHG_USB_FAST] = "FAST-CHARGER",
- [EXTCON_CHG_USB_SLOW] = "SLOW-CHARGER",
+ [EXTCON_CHG_USB_SDP] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_SDP,
+ .name = "SDP",
+ },
+ [EXTCON_CHG_USB_DCP] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_DCP,
+ .name = "DCP",
+ },
+ [EXTCON_CHG_USB_CDP] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_CDP,
+ .name = "CDP",
+ },
+ [EXTCON_CHG_USB_ACA] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_ACA,
+ .name = "ACA",
+ },
+ [EXTCON_CHG_USB_FAST] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_FAST,
+ .name = "FAST-CHARGER",
+ },
+ [EXTCON_CHG_USB_SLOW] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_SLOW,
+ .name = "SLOW-CHARGER",
+ },
/* Jack external connector */
- [EXTCON_JACK_MICROPHONE]= "MICROPHONE",
- [EXTCON_JACK_HEADPHONE] = "HEADPHONE",
- [EXTCON_JACK_LINE_IN] = "LINE-IN",
- [EXTCON_JACK_LINE_OUT] = "LINE-OUT",
- [EXTCON_JACK_VIDEO_IN] = "VIDEO-IN",
- [EXTCON_JACK_VIDEO_OUT] = "VIDEO-OUT",
- [EXTCON_JACK_SPDIF_IN] = "SPDIF-IN",
- [EXTCON_JACK_SPDIF_OUT] = "SPDIF-OUT",
+ [EXTCON_JACK_MICROPHONE] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_MICROPHONE,
+ .name = "MICROPHONE",
+ },
+ [EXTCON_JACK_HEADPHONE] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_HEADPHONE,
+ .name = "HEADPHONE",
+ },
+ [EXTCON_JACK_LINE_IN] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_LINE_IN,
+ .name = "LINE-IN",
+ },
+ [EXTCON_JACK_LINE_OUT] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_LINE_OUT,
+ .name = "LINE-OUT",
+ },
+ [EXTCON_JACK_VIDEO_IN] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_VIDEO_IN,
+ .name = "VIDEO-IN",
+ },
+ [EXTCON_JACK_VIDEO_OUT] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_VIDEO_OUT,
+ .name = "VIDEO-OUT",
+ },
+ [EXTCON_JACK_SPDIF_IN] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_SPDIF_IN,
+ .name = "SPDIF-IN",
+ },
+ [EXTCON_JACK_SPDIF_OUT] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JA
[PATCH 5/6] extcon: Add the synchronization extcon APIs to support the notification
This patch adds the synchronization extcon APIs to support the notifications
for both state and property. When extcon_*_sync() functions is called,
the extcon informs the information from extcon provider to extcon client.
The extcon driver may need to change the both state and multiple properties
at the same time. After setting the data of a external connector,
the extcon send the notification to client driver with the extcon_*_sync().
The list of new extcon APIs as following:
- extcon_sync() : Send the notification for each external connector to
synchronize the information between extcon provider driver
and extcon client driver.
- extcon_set_state_sync() : Set the state of external connector with noti.
- extcon_set_property_sync() : Set the property of external connector with noti.
For example,
case 1, change the state of external connector and synchronized the data.
extcon_set_state_sync(edev, EXTCON_USB, 1);
case 2, change both the state and property of external connector
and synchronized the data.
extcon_set_state(edev, EXTCON_USB, 1);
extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_ID, 1);
extcon_sync(edev, EXTCON_USB);
case 3, change the property of external connector and synchronized the data.
extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0);
extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_ID, 1);
extcon_sync(edev, EXTCON_USB);
case 4, change the property of external connector and synchronized the data.
extcon_set_property_sync(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0);
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 199 ++--
include/linux/extcon.h | 30 +++-
2 files changed, 152 insertions(+), 77 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 73c6981bf559..8572523bfd40 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -280,14 +280,11 @@ static bool is_extcon_attached(struct extcon_dev *edev,
unsigned int id,
return ((!!(edev->state & (1 << index))) == 1) ? true : false;
}
-static bool is_extcon_changed(u32 prev, u32 new, int idx, bool *attached)
+static bool is_extcon_changed(struct extcon_dev *edev, int index,
+ bool new_state)
{
- if (((prev >> idx) & 0x1) != ((new >> idx) & 0x1)) {
- *attached = ((new >> idx) & 0x1) ? true : false;
- return true;
- }
-
- return false;
+ int state = !!(edev->state & (1 << index));
+ return (state != new_state) ? true : false;
}
static bool is_extcon_property_supported(unsigned int id, unsigned int prop)
@@ -377,21 +374,13 @@ static ssize_t cable_state_show(struct device *dev,
}
/**
- * extcon_update_state() - Update the cable attach states of the extcon device
- *only for the masked bits.
- * @edev: the extcon device
- * @mask: the bit mask to designate updated bits.
- * @state: new cable attach status for @edev
- *
- * Changing the state sends uevent with environment variable containing
- * the name of extcon device (envp[0]) and the state output (envp[1]).
- * Tizen uses this format for extcon device to get events from ports.
- * Android uses this format as well.
+ * extcon_sync() - Synchronize the states for both the attached/detached
+ * @edev: the extcon device that has the cable.
*
- * Note that the notifier provides which bits are changed in the state
- * variable with the val parameter (second) to the callback.
+ * This function send a notification to synchronize the all states of a
+ * specific external connector
*/
-static int extcon_update_state(struct extcon_dev *edev, u32 mask, u32 state)
+int extcon_sync(struct extcon_dev *edev, unsigned int id)
{
char name_buf[120];
char state_buf[120];
@@ -400,73 +389,58 @@ static int extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state)
int env_offset = 0;
int length;
int index;
+ int state;
unsigned long flags;
- bool attached;
if (!edev)
return -EINVAL;
- spin_lock_irqsave(&edev->lock, flags);
+ index = find_cable_index_by_id(edev, id);
+ if (index < 0)
+ return index;
- if (edev->state != ((edev->state & ~mask) | (state & mask))) {
- u32 old_state;
+ state = !!(edev->state & (1 << index));
+ raw_notifier_call_chain(&edev->nh[index], state, edev);
- if (check_mutually_exclusive(edev, (edev->state & ~mask) |
- (state & mask))) {
- spin_unlock_irqrestore(&edev->lock, flags);
- return -EPERM;
- }
+ spin_lock_irqsave(&edev->lock, flags);
- old_state = edev->state;
- edev->sta
[PATCH 4/6] extcon: Rename the extcon_set/get_state() to maintain the function naming pattern
This patch just renames the existing extcon_get/set_cable_state_()
as following because of maintaining the function naming pattern
like as extcon APIs for property.
- extcon_set_cable_state_() -> extcon_set_state()
- extcon_get_cable_state_() -> extcon_get_state()
But, this patch remains the old extcon_set/get_cable_state_() functions
to prevent the build break. After altering new APIs, remove the old APIs.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 15 +++
include/linux/extcon.h | 25 ++---
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index f9522fcdb99c..73c6981bf559 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -373,8 +373,7 @@ static ssize_t cable_state_show(struct device *dev,
int i = cable->cable_index;
return sprintf(buf, "%d\n",
- extcon_get_cable_state_(cable->edev,
-
cable->edev->supported_cable[i]));
+ extcon_get_state(cable->edev, cable->edev->supported_cable[i]));
}
/**
@@ -470,11 +469,11 @@ static int extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state)
}
/**
- * extcon_get_cable_state_() - Get the status of a specific cable.
+ * extcon_get_state() - Get the state of a external connector.
* @edev: the extcon device that has the cable.
* @id:the unique id of each external connector in extcon
enumeration.
*/
-int extcon_get_cable_state_(struct extcon_dev *edev, const unsigned int id)
+int extcon_get_state(struct extcon_dev *edev, const unsigned int id)
{
int index;
@@ -490,17 +489,17 @@ int extcon_get_cable_state_(struct extcon_dev *edev,
const unsigned int id)
return (int)(is_extcon_attached(edev, id, index));
}
-EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
+EXPORT_SYMBOL_GPL(extcon_get_state);
/**
- * extcon_set_cable_state_() - Set the status of a specific cable.
+ * extcon_set_state() - Set the state of a external connector.
* @edev: the extcon device that has the cable.
* @id:the unique id of each external connector
* in extcon enumeration.
* @state: the new cable status. The default semantics is
* true: attached / false: detached.
*/
-int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
+int extcon_set_state(struct extcon_dev *edev, unsigned int id,
bool cable_state)
{
u32 state;
@@ -527,7 +526,7 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
state = cable_state ? (1 << index) : 0;
return extcon_update_state(edev, 1 << index, state);
}
-EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
+EXPORT_SYMBOL_GPL(extcon_set_state);
/**
* extcon_get_property() - Get the property value of a specific cable.
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index ee34a644594a..26f4481b3788 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -221,11 +221,11 @@ extern struct extcon_dev *devm_extcon_dev_allocate(struct
device *dev,
extern void devm_extcon_dev_free(struct device *dev, struct extcon_dev *edev);
/*
- * get/set_cable_state access each bit of the 32b encoded state value.
+ * get/set_state access each bit of the 32b encoded state value.
* They are used to access the status of each cable based on the cable id.
*/
-extern int extcon_get_cable_state_(struct extcon_dev *edev, unsigned int id);
-extern int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
+extern int extcon_get_state(struct extcon_dev *edev, unsigned int id);
+extern int extcon_set_state(struct extcon_dev *edev, unsigned int id,
bool cable_state);
/*
@@ -310,14 +310,14 @@ static inline struct extcon_dev
*devm_extcon_dev_allocate(struct device *dev,
static inline void devm_extcon_dev_free(struct extcon_dev *edev) { }
-static inline int extcon_get_cable_state_(struct extcon_dev *edev,
- unsigned int id)
+
+static inline int extcon_get_state(struct extcon_dev *edev, unsigned int id)
{
return 0;
}
-static inline int extcon_set_cable_state_(struct extcon_dev *edev,
- unsigned int id, bool cable_state)
+static inline int extcon_set_state(struct extcon_dev *edev, unsigned int id,
+ bool cable_state)
{
return 0;
}
@@ -407,4 +407,15 @@ static inline int extcon_unregister_interest(struct
extcon_specific_cable_nb
{
return -EINVAL;
}
+
+static inline int extcon_get_cable_state_(struct extcon_dev *edev, unsigned
int id)
+{
+ return extcon_get_state(edev, id);
+}
+
+static inline int extcon_set_cable_state_(struct extcon_dev *edev, unsigned
int id,
+ bool cabl
[PATCH 6/6] extcon: Add EXTCON_DISP_DP and the property for USB Type-C
From: Chris Zhong
Add EXTCON_DISP_DP for the Display external connector. For Type-C
connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
Alt Mode on USB Type-C Standard). The Type-C support both normal
and flipped orientation, so add a property to extcon.
Signed-off-by: Chris Zhong
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 5 +
include/linux/extcon.h | 8 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8572523bfd40..00711e811821 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -157,6 +157,11 @@ struct __extcon_info {
.id = EXTCON_DISP_VGA,
.name = "VGA",
},
+ [EXTCON_DISP_DP] = {
+ .type = EXTCON_TYPE_DISP | EXTCON_TYPE_USB,
+ .id = EXTCON_DISP_DP,
+ .name = "DP",
+ },
/* Miscellaneous external connector */
[EXTCON_DOCK] = {
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 00ab1180346c..2f4cde8c38d7 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -69,6 +69,7 @@
#define EXTCON_DISP_MHL41 /* Mobile High-Definition Link
*/
#define EXTCON_DISP_DVI42 /* Digital Visual Interface */
#define EXTCON_DISP_VGA43 /* Video Graphics Array */
+#define EXTCON_DISP_DP 44 /* Display Port */
/* Miscellaneous external connector */
#define EXTCON_DOCK60
@@ -106,12 +107,17 @@
* @type: integer (intval)
* @value: 0 (low) or 1 (high)
* @default: 0 (low)
+ * - EXTCON_PROP_USB_TYPEC_POLARITY
+ * @type: integer (intval)
+ * @value: 0 (normal) or 1 (flip)
+ * @default: 0 (normal)
*/
#define EXTCON_PROP_USB_ID 0
#define EXTCON_PROP_USB_VBUS 1
+#define EXTCON_PROP_USB_TYPEC_POLARITY 2
#define EXTCON_PROP_USB_MIN0
-#define EXTCON_PROP_USB_MAX1
+#define EXTCON_PROP_USB_MAX2
#define EXTCON_PROP_USB_CNT(EXTCON_PROP_USB_MAX - EXTCON_PROP_USB_MIN)
/* Properties of EXTCON_TYPE_CHG. */
--
1.9.1
[PATCH 0/6] extcon: Add the support for extcon type and property
This patch-set add the support the extcon type, extcon property and the synchronization functions. The each external connector has the common characters. So, the external connectors are able to gather in the specific type. And the each external connectors has the specific H/W desigin to support the multiple features throught h/w lines. There are the requirement to express the each h/w character of each external connector. Lastly, when the state and property are changed, the extcon notify the extcon client driver of the changed information. To support the notification on extcon provider drivers, this patches support the three sync functions. Detailed description of these patches: 1. Add the extcon type to group the each external connector. There are five categories unitl now as following: - EXTCON_TYPE_USB : USB connector - EXTCON_TYPE_CHG : Charger connector - EXTCON_TYPE_JACK : Jack connector - EXTCON_TYPE_DISP : Display connector - EXTCON_TYPE_MISC : Miscellaneous connector 2. Add the extcon property to support the multiple characteristic for the specific H/W design. - EXTCON_PROP_USB_[property name] - EXTCON_PROP_CHG_[property name] - EXTCON_PROP_JACK_[property name] - EXTCON_PROP_DISP_[property name] e.g., EXTCON_PROP_USB_ID and EXTCON_PROP_USB_VBUS The list of the new extcon APIs for the property as following: - int extcon_get_property(struct extcon_dev *edev, unsigned int id, unsigned int prop, union extcon_property_value *prop_val) - int extcon_set_property(struct extcon_dev *edev, unsigned int id, unsigned int prop, union extcon_property_value prop_val) - int extcon_get_property_capability(struct extcon_dev *edev, unsigned int id, unsigned int prop); - int extcon_set_property_capability(struct extcon_dev *edev, unsigned int id, unsigned int prop); 3. Add the sync functions to synchronize the data of each external connector between an extcon provider driver and the extcon client drivers. The list of the new extcon sync APIs as following: - extcon_sync() : Send the notification for each external connector to synchronize the information between and extcon provider driver and the extcon client drivers. - extcon_set_state_sync() : Set the state of external connector with noti. - extcon_set_property_sync() : Set the property of external connector with noti. 4. Add the new external connector definition. The EXTCON_DISP_DP means the Display external connector[1]. The list of new external connector as following: - EXTCON_DISP_DP The list of new property of USB connector as following: - EXTCON_PROP_USB_TYPEC_POLARITY 5. Rename the renames the existing extcon_get/set_cable_state_() to maintain the function naming pattern like as extcon APIs for property. - extcon_set_cable_state_() -> extcon_set_state() - extcon_get_cable_state_() -> extcon_get_state() For example, case 1, change the state of external connector and synchronized the data. extcon_set_state_sync(edev, EXTCON_USB, 1); case 2, change both the state and property of external connector and synchronized the data. extcon_set_state(edev, EXTCON_USB, 1); extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_ID, 1); extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0); extcon_sync(edev, EXTCON_USB); case 3, change the property of external connector and synchronized the data. extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0); extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_ID, 1); extcon_sync(edev, EXTCON_USB); case 4, change the property of external connector and synchronized the data. extcon_set_property_sync(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0); Depends on: This patch depend on the extcon patches[2]. [1] https://en.wikipedia.org/wiki/DisplayPort [2] http://comments.gmane.org/gmane.linux.kernel/2270818 Chanwoo Choi (5): extcon: Add the extcon_type to group each connector into five category extcon: Add the support for extcon property according to extcon type extcon: Add the support for the capability of each property extcon: Rename the extcon_set/get_state() to maintain the function naming pattern extcon: Add the synchronization extcon APIs to support the notification Chris Zhong (1): extcon: Add EXTCON_DISP_DP and the property for USB Type-C drivers/extcon/extcon.c | 707 include/linux/extcon.h | 176 +++- 2 files changed, 766 insertions(+), 117 deletions(-) -- 1.9.1
[PATCH 3/6] extcon: Add the support for the capability of each property
This patch adds the support of the property capability setting. This function
decides the supported properties of each external connector on extcon provider
driver.
Ths list of new extcon APIs to get/set the capability of property as following:
- int extcon_get_property_capability(struct extcon_dev *edev,
unsigned int id, unsigned int prop);
- int extcon_set_property_capability(struct extcon_dev *edev,
unsigned int id, unsigned int prop);
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 135 +++-
include/linux/extcon.h | 22
2 files changed, 155 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 2317aaea063f..f9522fcdb99c 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -201,6 +201,11 @@ struct extcon_cable {
union extcon_property_value chg_propval[EXTCON_PROP_CHG_CNT];
union extcon_property_value jack_propval[EXTCON_PROP_JACK_CNT];
union extcon_property_value disp_propval[EXTCON_PROP_DISP_CNT];
+
+ unsigned long usb_bits[BITS_TO_LONGS(EXTCON_PROP_USB_CNT)];
+ unsigned long chg_bits[BITS_TO_LONGS(EXTCON_PROP_CHG_CNT)];
+ unsigned long jack_bits[BITS_TO_LONGS(EXTCON_PROP_JACK_CNT)];
+ unsigned long disp_bits[BITS_TO_LONGS(EXTCON_PROP_DISP_CNT)];
};
static struct class *extcon_class;
@@ -545,7 +550,7 @@ int extcon_get_property(struct extcon_dev *edev, unsigned
int id,
{
struct extcon_cable *cable;
unsigned long flags;
- int index, ret = 0;
+ int index, capability, ret = 0;
*prop_val = (union extcon_property_value)(0);
@@ -561,6 +566,11 @@ int extcon_get_property(struct extcon_dev *edev, unsigned
int id,
if (index < 0)
return index;
+ /* Check whether the property is available or not. */
+ capability = extcon_get_property_capability(edev, id, prop);
+ if (!capability)
+ return -EPERM;
+
/*
* Check whether the external connector is attached.
* If external connector is detached, the user can not
@@ -616,7 +626,7 @@ int extcon_set_property(struct extcon_dev *edev, unsigned
int id,
{
struct extcon_cable *cable;
unsigned long flags;
- int index, ret = 0;
+ int index, capability, ret = 0;
if (!edev)
return -EINVAL;
@@ -630,6 +640,11 @@ int extcon_set_property(struct extcon_dev *edev, unsigned
int id,
if (index < 0)
return index;
+ /* Check whether the property is available or not. */
+ capability = extcon_get_property_capability(edev, id, prop);
+ if (!capability)
+ return -EPERM;
+
cable = &edev->cables[index];
spin_lock_irqsave(&edev->lock, flags);
@@ -659,6 +674,122 @@ int extcon_set_property(struct extcon_dev *edev, unsigned
int id,
EXPORT_SYMBOL_GPL(extcon_set_property);
/**
+ * extcon_get_property_capability() - Get the capability of property
+ * of an external connector.
+ * @edev: the extcon device that has the cable.
+ * @id:the unique id of each external connector
+ * in extcon enumeration.
+ * @prop: the property id among enum extcon_property.
+ *
+ * Returns 1 if the property is available or 0 if not available.
+ */
+int extcon_get_property_capability(struct extcon_dev *edev, unsigned int id,
+ unsigned int prop)
+{
+ struct extcon_cable *cable;
+ int index, type, ret = 0;
+
+ if (!edev)
+ return -EINVAL;
+
+ /* Check whether the property is supported or not */
+ if (!is_extcon_property_supported(id, prop))
+ return -EINVAL;
+
+ /* Find the cable index of external connector by using id */
+ index = find_cable_index_by_id(edev, id);
+ if (index < 0)
+ return index;
+
+ /* Check whether the property is supported or not. */
+ type = get_extcon_type(prop);
+ if (type < 0)
+ return type;
+
+ cable = &edev->cables[index];
+
+ switch (type) {
+ case EXTCON_TYPE_USB:
+ ret = test_bit(prop - EXTCON_PROP_USB_MIN, cable->usb_bits);
+ break;
+ case EXTCON_TYPE_CHG:
+ ret = test_bit(prop - EXTCON_PROP_CHG_MIN, cable->chg_bits);
+ break;
+ case EXTCON_TYPE_JACK:
+ ret = test_bit(prop - EXTCON_PROP_JACK_MIN, cable->jack_bits);
+ break;
+ case EXTCON_TYPE_DISP:
+ ret = test_bit(prop - EXTCON_PROP_DISP_MIN, cable->disp_bits);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(extcon_get_property_capability);
+
+/**
+ * extcon_set_property_capabil
[PATCH 2/6] extcon: Add the support for extcon property according to extcon type
This patch support the extcon property for the external connector
because each external connector might have the property according to
the H/W design and the specific characteristics.
- EXTCON_PROP_USB_[property name]
- EXTCON_PROP_CHG_[property name]
- EXTCON_PROP_JACK_[property name]
- EXTCON_PROP_DISP_[property name]
Add the new extcon APIs to get/set the property value as following:
- int extcon_get_property(struct extcon_dev *edev, unsigned int id,
unsigned int prop,
union extcon_property_value *prop_val)
- int extcon_set_property(struct extcon_dev *edev, unsigned int id,
unsigned int prop,
union extcon_property_value prop_val)
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 206 +++-
include/linux/extcon.h | 86
2 files changed, 291 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index b1e6ee6194bc..2317aaea063f 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -196,6 +196,11 @@ struct extcon_cable {
struct device_attribute attr_state;
struct attribute *attrs[3]; /* to be fed to attr_g.attrs */
+
+ union extcon_property_value usb_propval[EXTCON_PROP_USB_CNT];
+ union extcon_property_value chg_propval[EXTCON_PROP_CHG_CNT];
+ union extcon_property_value jack_propval[EXTCON_PROP_JACK_CNT];
+ union extcon_property_value disp_propval[EXTCON_PROP_DISP_CNT];
};
static struct class *extcon_class;
@@ -248,6 +253,28 @@ static int find_cable_index_by_id(struct extcon_dev *edev,
const unsigned int id
return -EINVAL;
}
+static int get_extcon_type(unsigned int prop)
+{
+ switch (prop) {
+ case EXTCON_PROP_USB_MIN ... EXTCON_PROP_USB_MAX:
+ return EXTCON_TYPE_USB;
+ case EXTCON_PROP_CHG_MIN ... EXTCON_PROP_CHG_MAX:
+ return EXTCON_TYPE_CHG;
+ case EXTCON_PROP_JACK_MIN ... EXTCON_PROP_JACK_MAX:
+ return EXTCON_TYPE_JACK;
+ case EXTCON_PROP_DISP_MIN ... EXTCON_PROP_DISP_MAX:
+ return EXTCON_TYPE_DISP;
+ default:
+ return -EINVAL;
+ }
+}
+
+static bool is_extcon_attached(struct extcon_dev *edev, unsigned int id,
+ unsigned int index)
+{
+ return ((!!(edev->state & (1 << index))) == 1) ? true : false;
+}
+
static bool is_extcon_changed(u32 prev, u32 new, int idx, bool *attached)
{
if (((prev >> idx) & 0x1) != ((new >> idx) & 0x1)) {
@@ -258,6 +285,41 @@ static bool is_extcon_changed(u32 prev, u32 new, int idx,
bool *attached)
return false;
}
+static bool is_extcon_property_supported(unsigned int id, unsigned int prop)
+{
+ unsigned int type;
+
+ /* Check whether the property is supported or not. */
+ type = get_extcon_type(prop);
+ if (type < 0)
+ return false;
+
+ /* Check whether a specific extcon id supports the property or not. */
+ if (extcon_info[id].type | type)
+ return true;
+
+ return false;
+}
+
+#define INIT_PROPERTY(name, name_lower, type) \
+ if (EXTCON_TYPE_##name || type) { \
+ for (i = 0; i < EXTCON_PROP_##name##_CNT; i++) \
+ cable->name_lower##_propval[i] = val; \
+ } \
+
+static void init_property(struct extcon_dev *edev, unsigned int id, int index)
+{
+ unsigned int type = extcon_info[id].type;
+ struct extcon_cable *cable = &edev->cables[index];
+ union extcon_property_value val = (union extcon_property_value)(0);
+ int i;
+
+ INIT_PROPERTY(USB, usb, type);
+ INIT_PROPERTY(CHG, chg, type);
+ INIT_PROPERTY(JACK, jack, type);
+ INIT_PROPERTY(DISP, disp, type);
+}
+
static ssize_t state_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -421,7 +483,7 @@ int extcon_get_cable_state_(struct extcon_dev *edev, const
unsigned int id)
if (edev->max_supported && edev->max_supported <= index)
return -EINVAL;
- return !!(edev->state & (1 << index));
+ return (int)(is_extcon_attached(edev, id, index));
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
@@ -449,12 +511,154 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
if (edev->max_supported && edev->max_supported <= index)
return -EINVAL;
+ /*
+* Initialize the value of extcon property before setting
+* the detached state for an external connector.
+*/
+ if (!cable_state)
+ init_property(edev, id, index);
+
+ /* Set the state for external connector as the detached state. */
state = cable_state ? (1 <<
Re: [RFC PATCH 0/5] USB Audio Gadget refactoring
On 07/26/2016 10:53 AM, Jassi Brar wrote: > On Tue, Jul 26, 2016 at 7:01 AM, Ruslan Bilovol > wrote: >> On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote: > On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol > wrote: >> it may break current usecase for some people >>> >>> And what are the benefits that justify breaking the kernel API? >> >> >> Main limitation with current f_uac1 design is - it can be used only on >> systems >> with real ALSA card present and can have only exact number of >> channels / sampling rate as sink card has. >> Yet it is not flexible - can't do audio processing between f_uac1 and the >> card. >> Also if someone wants to bind f_uac1 it to another sound card he has to >> unload g_audio or reconfigure it through configfs - that means USB >> reenumeration on host device. >> >> If you have a "virtual sound card", audio processing is done in userspace >> and is more flexible. You even don't need to have a real sound card and >> can use some userspace application for playing/capturing audio samples. >> Moreover, existing f_uac2 (that is USB Audio Class 2.0 function >> implementation) already uses approach of "virtual sound card" >> > While I agree the virtual sound card approach is the right way, I am > not sure if we should break the userspace api that the existing UAC1 > driver exposes. Maybe we should add another virtual-sound-card > exposing UAC1 driver ... and hopefully very similar to (or just port > of) the f_audio_source.c from android. Definitely agree with this opinion. I don't see any benefits of breaking the API here instead of adding just another USB function. Maybe even some pieces of code could be shared with f_uac1.c but I think that this should be a brand new function. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics
[PATCHv3] 8250: option 'force_polling' for buggy IRQs
Some serial ports may not emit IRQs properly, or there may be a defect
in their routing on the motherboard.
This patch allows these ports to be used anyway (or until a better
workaround is known for a specific platform), though with no guarantees.
If you have such a buggy UART, boot Linux with 8250.force_polling=1 .
It is essentially the kernel level version of:
setserial /dev/ttySn irq 0
and builds upon the polling code that is already in the kernel.
Signed-off-by: Max Staudt
---
v2:
- Fixed module_param_cb() line
v3:
- Added Signed-off-by:
---
drivers/tty/serial/8250/8250_core.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 13ad5c3..536e226 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -58,6 +58,11 @@ static struct uart_driver serial8250_reg;
static unsigned int skip_txen_test; /* force skip of txen test at init time */
+/* Force polled mode for all newly detected ports.
+ * This can be used if IRQs don't arrive and similar buggyness.
+ */
+static unsigned int force_polling;
+
#define PASS_LIMIT 512
#include
@@ -335,6 +340,13 @@ static int univ8250_setup_irq(struct uart_8250_port *up)
uart_poll_timeout(port) + HZ / 5);
}
+ if (force_polling) {
+ pr_debug("ttyS%d - using polled mode instead of interrupt %u\n",
+serial_index(port),
+port->irq);
+ port->irq = 0;
+ }
+
/*
* If the "interrupt" for this port doesn't correspond with any
* hardware interrupt, we use a timer-based system. The original
@@ -1206,6 +1218,9 @@ MODULE_PARM_DESC(nr_uarts, "Maximum number of UARTs
supported. (1-" __MODULE_STR
module_param(skip_txen_test, uint, 0644);
MODULE_PARM_DESC(skip_txen_test, "Skip checking for the TXEN bug at init
time");
+module_param(force_polling, uint, 0644);
+MODULE_PARM_DESC(force_polling, "Set ports to polling mode at init time");
+
#ifdef CONFIG_SERIAL_8250_RSA
module_param_array(probe_rsa, ulong, &probe_rsa_count, 0444);
MODULE_PARM_DESC(probe_rsa, "Probe I/O ports for RSA");
@@ -1232,6 +1247,7 @@ static void __used s8250_options(void)
module_param_cb(share_irqs, ¶m_ops_uint, &share_irqs, 0644);
module_param_cb(nr_uarts, ¶m_ops_uint, &nr_uarts, 0644);
module_param_cb(skip_txen_test, ¶m_ops_uint, &skip_txen_test, 0644);
+ module_param_cb(force_polling, ¶m_ops_uint, &force_polling, 0644);
#ifdef CONFIG_SERIAL_8250_RSA
__module_param_call(MODULE_PARAM_PREFIX, probe_rsa,
¶m_array_ops, .arr = &__param_arr_probe_rsa,
--
2.6.6
Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent
On Tuesday, July 26, 2016 11:59:38 AM Dou Liyang wrote: > > 在 2016年07月26日 07:20, Andrew Morton 写道: > > On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang > > wrote: > > > >> [Problem] > >> > >> cpuid <-> nodeid mapping is firstly established at boot time. And > >> workqueue caches > >> the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time. > >> > >> When doing node online/offline, cpuid <-> nodeid mapping is > >> established/destroyed, > >> which means, cpuid <-> nodeid mapping will change if node hotplug happens. > >> But > >> workqueue does not update wq_numa_possible_cpumask. > >> > >> So here is the problem: > >> > >> Assume we have the following cpuid <-> nodeid in the beginning: > >> > >> Node | CPU > >> > >> node 0 | 0-14, 60-74 > >> node 1 | 15-29, 75-89 > >> node 2 | 30-44, 90-104 > >> node 3 | 45-59, 105-119 > >> > >> and we hot-remove node2 and node3, it becomes: > >> > >> Node | CPU > >> > >> node 0 | 0-14, 60-74 > >> node 1 | 15-29, 75-89 > >> > >> and we hot-add node4 and node5, it becomes: > >> > >> Node | CPU > >> > >> node 0 | 0-14, 60-74 > >> node 1 | 15-29, 75-89 > >> node 4 | 30-59 > >> node 5 | 90-119 > >> > >> But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the > >> like. > >> > >> When a pool workqueue is initialized, if its cpumask belongs to a node, its > >> pool->node will be mapped to that node. And memory used by this workqueue > >> will > >> also be allocated on that node. > > > > Plan B is to hunt down and fix up all the workqueue structures at > > hotplug-time. Has that option been evaluated? > > > > Yes, the option has been evaluate in this patch: > http://www.gossamer-threads.com/lists/linux/kernel/2116748 > > > > > Your fix is x86-only and this bug presumably affects other > > architectures, yes?I think a "Plan B" would fix all architectures? > > > > Yes, the bug may presumably affect few architectures which support CPU > hotplug and NUMA. > > We have sent the "Plan B" in our community and got a lot of advice and > ideas. Based on these suggestions, We carefully balance that two plan. > Then we choice the first. > > > > > Thirdly, what is the merge path for these patches? Is an x86 > > or ACPI maintainer working with you on them? > > Yes, we get a lot of guidance and help from RJ who is an ACPI maintainer. FWIW, the patches are fine by me from the ACPI perspective. If you want me to apply them, though, ACKs from the x86 and mm maintainers will be necessary. Thanks, Rafael
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)
On Mon, 25 Jul 2016, Foster Snowhill wrote: > On 25.07.16 13:56, Thomas Gleixner wrote: i> > Could you please give the patch below a try? It might be related, but I'm > > not sure whether it will cure that particular vmware oddity. > > Patch fixed the issue for me. Did 4-5 reboots just to be sure, all working > properly, no adapter resets. Just for the sake of experiment built a clean > 4.7 kernel without the patch, issue still present there as expected. Can you please try whether the replacement patch below fixes your issue as well? Thanks, tglx 8< diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index a080f4496fe2..142341f8331b 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -645,6 +645,15 @@ static int msi_capability_init(struct pci_dev *dev, int nvec) return ret; } + /* +* The mask can be ignored and PCI 2.3 does not specify mask bits for +* each MSI interrupt. So in case of hierarchical irqdomains we need +* to make sure that if masking is not available that the msi message +* is written prior to setting the MSI enable bit in the device. +*/ + if (pci_msi_ignore_mask || !entry->msi_attrib.maskbit) + irq_domain_activate_irq(irq_get_irq_data(entry->irq)); + /* Set MSI enabled bits */ pci_intx_for_msi(dev, 0); pci_msi_set_enable(dev, 1);
[PATCHv2] 8250: option 'force_polling' for buggy IRQs
Some serial ports may not emit IRQs properly, or there may be a defect
in their routing on the motherboard.
This patch allows these ports to be used anyway (or until a better
workaround is known for a specific platform), though with no guarantees.
If you have such a buggy UART, boot Linux with 8250.force_polling=1 .
It is essentially the kernel level version of:
setserial /dev/ttySn irq 0
and builds upon the polling code that is already in the kernel.
---
v2:
- Fixed module_param_cb() line
---
drivers/tty/serial/8250/8250_core.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 13ad5c3..536e226 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -58,6 +58,11 @@ static struct uart_driver serial8250_reg;
static unsigned int skip_txen_test; /* force skip of txen test at init time */
+/* Force polled mode for all newly detected ports.
+ * This can be used if IRQs don't arrive and similar buggyness.
+ */
+static unsigned int force_polling;
+
#define PASS_LIMIT 512
#include
@@ -335,6 +340,13 @@ static int univ8250_setup_irq(struct uart_8250_port *up)
uart_poll_timeout(port) + HZ / 5);
}
+ if (force_polling) {
+ pr_debug("ttyS%d - using polled mode instead of interrupt %u\n",
+serial_index(port),
+port->irq);
+ port->irq = 0;
+ }
+
/*
* If the "interrupt" for this port doesn't correspond with any
* hardware interrupt, we use a timer-based system. The original
@@ -1206,6 +1218,9 @@ MODULE_PARM_DESC(nr_uarts, "Maximum number of UARTs
supported. (1-" __MODULE_STR
module_param(skip_txen_test, uint, 0644);
MODULE_PARM_DESC(skip_txen_test, "Skip checking for the TXEN bug at init
time");
+module_param(force_polling, uint, 0644);
+MODULE_PARM_DESC(force_polling, "Set ports to polling mode at init time");
+
#ifdef CONFIG_SERIAL_8250_RSA
module_param_array(probe_rsa, ulong, &probe_rsa_count, 0444);
MODULE_PARM_DESC(probe_rsa, "Probe I/O ports for RSA");
@@ -1232,6 +1247,7 @@ static void __used s8250_options(void)
module_param_cb(share_irqs, ¶m_ops_uint, &share_irqs, 0644);
module_param_cb(nr_uarts, ¶m_ops_uint, &nr_uarts, 0644);
module_param_cb(skip_txen_test, ¶m_ops_uint, &skip_txen_test, 0644);
+ module_param_cb(force_polling, ¶m_ops_uint, &force_polling, 0644);
#ifdef CONFIG_SERIAL_8250_RSA
__module_param_call(MODULE_PARAM_PREFIX, probe_rsa,
¶m_array_ops, .arr = &__param_arr_probe_rsa,
--
2.6.6
Re: [PATCH v9 5/9] acpi/arm64: Add GTDT table parse driver
On Monday, July 25, 2016 11:27:03 PM fu@linaro.org wrote:
> From: Fu Wei
>
> This patch adds support for parsing arch timer in GTDT,
> provides some kernel APIs to parse all the PPIs and
> always-on info in GTDT and export them.
>
> By this driver, we can simplify arm_arch_timer drivers, and
> separate the ACPI GTDT knowledge from it.
>
> Signed-off-by: Fu Wei
> Signed-off-by: Hanjun Guo
>From the ACPI perspective:
Acked-by: Rafael J. Wysocki
and I'm assuming that the patches will go in via some other (non-ACPI) tree.
> ---
> arch/arm64/Kconfig | 1 +
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/arm64/Kconfig | 5 ++
> drivers/acpi/arm64/Makefile| 1 +
> drivers/acpi/arm64/acpi_gtdt.c | 152
> +
> drivers/clocksource/Kconfig| 1 -
> include/linux/acpi.h | 6 ++
> 8 files changed, 171 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 5a0a691..0b9fba7 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2,6 +2,7 @@ config ARM64
> def_bool y
> select ACPI_CCA_REQUIRED if ACPI
> select ACPI_GENERIC_GSI if ACPI
> + select ACPI_GTDT if ACPI
> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index b7e2e77..1cdc7d2 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -521,4 +521,9 @@ config XPOWER_PMIC_OPREGION
>
> endif
>
> +if ARM64
> +source "drivers/acpi/arm64/Kconfig"
> +
> +endif
> +
> endif# ACPI
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 251ce85..1a94ff7 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -99,5 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
> obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o
> obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
> obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
> +obj-$(CONFIG_ARM64) += arm64/
>
> video-objs += acpi_video.o video_detect.o
> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
> new file mode 100644
> index 000..80201be
> --- /dev/null
> +++ b/drivers/acpi/arm64/Kconfig
> @@ -0,0 +1,5 @@
> +#
> +# ACPI Configuration for ARM64
> +#
> +config ACPI_GTDT
> + bool
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> new file mode 100644
> index 000..466de6b
> --- /dev/null
> +++ b/drivers/acpi/arm64/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ACPI_GTDT) += acpi_gtdt.o
> diff --git a/drivers/acpi/arm64/acpi_gtdt.c b/drivers/acpi/arm64/acpi_gtdt.c
> new file mode 100644
> index 000..cdb2fb1
> --- /dev/null
> +++ b/drivers/acpi/arm64/acpi_gtdt.c
> @@ -0,0 +1,152 @@
> +/*
> + * ARM Specific GTDT table Support
> + *
> + * Copyright (C) 2016, Linaro Ltd.
> + * Author: Daniel Lezcano
> + * Fu Wei
> + * Hanjun Guo
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#undef pr_fmt
> +#define pr_fmt(fmt) "ACPI GTDT: " fmt
> +
> +typedef struct {
> + struct acpi_table_gtdt *gtdt;
> + void *platform_timer_start;
> + void *gtdt_end;
> +} acpi_gtdt_desc_t;
> +
> +static acpi_gtdt_desc_t acpi_gtdt_desc __initdata;
> +
> +static inline void *next_platform_timer(void *platform_timer)
> +{
> + struct acpi_gtdt_header *gh = platform_timer;
> +
> + platform_timer += gh->length;
> + if (platform_timer < acpi_gtdt_desc.gtdt_end)
> + return platform_timer;
> +
> + return NULL;
> +}
> +
> +#define for_each_platform_timer(_g) \
> + for (_g = acpi_gtdt_desc.platform_timer_start; _g; \
> + _g = next_platform_timer(_g))
> +
> +static inline bool is_timer_block(void *platform_timer)
> +{
> + struct acpi_gtdt_header *gh = platform_timer;
> +
> + return gh->type == ACPI_GTDT_TYPE_TIMER_BLOCK;
> +}
> +
> +static inline bool is_watchdog(void *platform_timer)
> +{
> + struct acpi_gtdt_header *gh = platform_timer;
> +
> + return gh->type == ACPI_GTDT_TYPE_WATCHDOG;
> +}
> +
> +static int __init map_gt_gsi(u32 interrupt, u32 flags)
> +{
> + int trigger, polarity;
> +
> + if (!interrupt)
> + return 0;
> +
> + trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
> + : ACPI_LEVEL_SENSITIVE;
> +
> + polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
> + : ACPI_ACTIVE_HIGH;
> +
> + return acpi_register_gsi(NULL, interrupt, trigger, polarity);
> +}
> +
> +/*
> + * Map the PPIs of pe
Re: [PATCH] genirq/msi: Make sure PCI MSIs are activated early
On Mon, 25 Jul 2016, Bjorn Helgaas wrote: > On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote: > I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being > written before PCI_MSI_ADDRESS_LO. That doesn't sound like a good > idea to me. Well. That's only a problem if the PCI device does not support masking. But yes, we missed that case back then. > That does seem like a problem. Maybe it would be better to delay > setting PCI_MSI_FLAGS_ENABLE until after the MSI address & data bits > have been set? I thought about that, but that gets ugly pretty fast. Here is an alternative solution. I think that's the proper place to do it _AFTER_ the hierarchical allocation took place. On x86 Marc's ACTIVATE_EARLY flag would not work because the message is not yet ready to be assembled. Thanks, tglx --- diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index a080f4496fe2..142341f8331b 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -645,6 +645,15 @@ static int msi_capability_init(struct pci_dev *dev, int nvec) return ret; } + /* +* The mask can be ignored and PCI 2.3 does not specify mask bits for +* each MSI interrupt. So in case of hierarchical irqdomains we need +* to make sure that if masking is not available that the msi message +* is written prior to setting the MSI enable bit in the device. +*/ + if (pci_msi_ignore_mask || !entry->msi_attrib.maskbit) + irq_domain_activate_irq(irq_get_irq_data(entry->irq)); + /* Set MSI enabled bits */ pci_intx_for_msi(dev, 0); pci_msi_set_enable(dev, 1);
Re: [PATCH] 8250: option 'force_polling' for buggy IRQs
On 07/25/2016 07:47 PM, Greg KH wrote: > On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote: >> Some serial ports may not emit IRQs properly, or there may be a defect >> in their routing on the motherboard. >> >> This patch allows these ports to be used anyway (or until a better >> workaround is known for a specific platform), though with no guarantees. >> >> If you have such a buggy UART, boot Linux with 8250.force_polling=1 . > > Ick, don't add new module parameters if at all possible. I agree, I'd rather not add a parameter either, but... - It's a hardware issue - It needs to be handled at boot time - It can't be auto-detected (AFAIK) The idea is that this parameter allows for a workaround until someone comes up with a workaround or autodetection (if ever). And it can be used to debug future buggy hardware. >> It is essentially the kernel level version of: >> >> setserial /dev/ttySn irq 0 > > Why can't you just do this instead? Because it's too late by the time we reach userspace. In case of "console=ttyS0" the decision to use polling needs to happen before ttyS0 is opened from userspace, as the system will otherwise hang for up to 30 seconds at a time. Input is mostly dropped, thus I can't even use BREAK+B to force reboot it. As it stands now, I can't even boot the system with "rdinit=/bin/bash". The force_polling option makes the system somewhat usable, albeit the serial output is very slow. Curiously, the kernel's printk() is as fast as it should be. It's just userspace that is slow. Any idea why that is the case? The kbuild test bot spotted a mistake, I'll send a new patch. Thanks, Max
Request for your partnership
Good day, I work with one of the major banks in Cambodia as the director of auditor. I have a proposal for you, a very urgent and quick business that will be completed in 12 working days. I have just discovered documents relating to funds belonging to a deceased client of our bank, I went through all the related documents to the funds and I discovered no listed next of kin to inherit the funds which has been in our bank for more than 7 years now. I need your cooperation in getting the funds, I have the power to list you as the beneficiary of the funds and have the funds transferred to you. If you are interested, do get back to me so I can provide you with the full details. Regards Bun Sam. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH] apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling
On Mon, 25 Jul 2016, John Johansen wrote:
> From: Arnd Bergmann
>
> The newly added Kconfig option could never work and just causes a build error
> when disabled:
>
> security/apparmor/lsm.c:675:25: error:
> 'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a function)
> bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;
>
> The problem is that the macro undefined in this case, and we need to use the
> IS_ENABLED()
> helper to turn it into a boolean constant.
>
> Another minor problem with the original patch is that the option is even
> offered
> in sysfs when SECURITY_APPARMOR_HASH is not enabled, so this also hides the
> option
> in that case.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 6059f71f1e94 ("apparmor: add parameter to control whether policy
> hashing is used")
> Signed-off-by: John Johansen
Please rebase this against current Linus.
--
James Morris
Re: Strange behavior of perf top with PEBS
On 07/20/2016 05:38 PM, Jiri Olsa wrote: > On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote: >> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote: >>> Hello, >>> >>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf >>> code) I observed that "perf top" counts no cycles and produces no >>> output. After a bit of head scratching and testing I figured that >>> running "perf top -e cycles" actually works whereas the default option >>> is equivalent to running "perf top -e cycles:p". So the latter version >>> seems to not work on my machine. >> >> hum, I think Core2 has PEBs valid only for instructions not cycles.. >> >> I'll check why perf top forcing the precise for cycles >> I thought we had that automated already > > oops, too soon ;) we have: > > perf/x86/intel: Fix Core2,Atom,NHM,WSM cycles:pp events > commit 517e6341fa123ec3a2f9ea78ad547be910529881 > Author: Peter Zijlstra > Date: Sat Apr 11 12:16:22 2015 +0200 > > > so i guess it should work.. checking ;-) Any update on that? > > jirka >
[PATCH] mmc: core: Optimize the mmc erase size alignment
Before issuing mmc_erase() function, users always have checked if it can
erase with mmc_can_erase/trim/discard() function, thus remove the redundant
erase checking in mmc_erase() function.
This patch also optimizes the erase start/end sector alignment with
round_up()/round_down() function, when erase command is MMC_ERASE_ARG.
Signed-off-by: Baolin Wang
---
drivers/mmc/core/core.c | 58 +++
1 file changed, 28 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index b4c08d1a..4dd333e 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2195,6 +2195,31 @@ out:
return err;
}
+static unsigned int mmc_align_erase_size(struct mmc_card *card,
+unsigned int *from,
+unsigned int *to,
+unsigned int nr)
+{
+ unsigned int from_old = *from, nr_old = nr;
+ unsigned int from_new, nr_new;
+
+ from_new = round_up(from_old, card->erase_size);
+ if (nr_old > from_new - from_old)
+ nr_old -= from_new - from_old;
+ else
+ return 0;
+
+ nr_new = round_down(nr_old, card->erase_size);
+ if (nr_new == 0)
+ return 0;
+
+ /* 'from' and 'to' are inclusive */
+ *to = from_new + nr_new - 1;
+ *from = from_new;
+
+ return nr_new;
+}
+
/**
* mmc_erase - erase sectors.
* @card: card to erase
@@ -2210,13 +2235,6 @@ int mmc_erase(struct mmc_card *card, unsigned int from,
unsigned int nr,
unsigned int rem, to = from + nr;
int err;
- if (!(card->host->caps & MMC_CAP_ERASE) ||
- !(card->csd.cmdclass & CCC_ERASE))
- return -EOPNOTSUPP;
-
- if (!card->erase_size)
- return -EOPNOTSUPP;
-
if (mmc_card_sd(card) && arg != MMC_ERASE_ARG)
return -EOPNOTSUPP;
@@ -2234,31 +2252,11 @@ int mmc_erase(struct mmc_card *card, unsigned int from,
unsigned int nr,
}
if (arg == MMC_ERASE_ARG) {
- rem = from % card->erase_size;
- if (rem) {
- rem = card->erase_size - rem;
- from += rem;
- if (nr > rem)
- nr -= rem;
- else
- return 0;
- }
- rem = nr % card->erase_size;
- if (rem)
- nr -= rem;
+ rem = mmc_align_erase_size(card, &from, &to, nr);
+ if (rem == 0)
+ return 0;
}
- if (nr == 0)
- return 0;
-
- to = from + nr;
-
- if (to <= from)
- return -EINVAL;
-
- /* 'from' and 'to' are inclusive */
- to -= 1;
-
/*
* Special case where only one erase-group fits in the timeout budget:
* If the region crosses an erase-group boundary on this particular
--
1.7.9.5
Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk
Hi, The following commit: commit 13523309495cdbd57a0d344c0d5d574987af007f Author: Josh Poimboeuf Date: Thu Jan 21 16:49:21 2016 -0600 x86/asm/acpi: Create a stack frame in do_suspend_lowlevel() do_suspend_lowlevel() is a callable non-leaf function which doesn't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create a stack frame for it when CONFIG_FRAME_POINTER is enabled. is reported to cause a resume-from-hibernation regression due to an attempt to execute an NX page (we've seen quite a bit of that recently). I'm asking the reporter to try 4.7, but if the problem is still there, we'll need to revert the above I'm afraid. Thanks, Rafael --- Begin Message --- https://bugzilla.kernel.org/show_bug.cgi?id=150021 Bug ID: 150021 Summary: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk Product: Power Management Version: 2.5 Kernel Version: 4.6.x Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Hibernation/Suspend Assignee: r...@rjwysocki.net Reporter: shuz...@mailbox.org Regression: No Created attachment 226381 --> https://bugzilla.kernel.org/attachment.cgi?id=226381&action=edit last working .config Overview: When commit 13523309495cdbd57a0d344c0d5d574987af007f is applied to my kernel sources my kernel panics when trying to resume from hibernate to disk. Steps to Reproduce: 1. have a working hibernate/resume setup 2. compile 4.6.x kernel 3. boot and hibernate to disk 4. test various kernels using "git bisect". Actual Results: kernel panics when trying to resume from hibernate to disk. Expected Results: Resume from hibernate to disk like kernels without commit 13523309495cdbd57a0d344c0d5d574987af007f did. I attached my working .config of my 4.5.7 kernel. Any help will be appreciated. Thanks! -- You are receiving this mail because: You are the assignee for the bug. --- End Message ---
Re: [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it
On Tue, 26 Jul 2016 18:49:56 +0800, Caesar Wang wrote:
>
> On 2016年07月26日 17:00, John Keeping wrote:
> > On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote:
> >
> >> SARADC controller needs to be reset before programming it, otherwise
> >> it will not function properly.
> >>
> >> Signed-off-by: Caesar Wang
> >> Cc: Jonathan Cameron
> >> Cc: Heiko Stuebner
> >> Cc: Rob Herring
> >> Cc: linux-...@vger.kernel.org
> >> Cc: linux-rockc...@lists.infradead.org
> >> ---
> >>
> >> diff --git a/drivers/iio/adc/rockchip_saradc.c
> >> b/drivers/iio/adc/rockchip_saradc.c
> >> index f9ad6c2..2f0e110 100644
> >> --- a/drivers/iio/adc/rockchip_saradc.c
> >> +++ b/drivers/iio/adc/rockchip_saradc.c
> >> @@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct
> >> platform_device *pdev)
> >>if (IS_ERR(info->regs))
> >>return PTR_ERR(info->regs);
> >>
> >> + info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb");
> >> + if (IS_ERR(info->reset)) {
> >> + ret = PTR_ERR(info->reset);
> >> + dev_err(&pdev->dev, "failed to get saradc reset: %d\n", ret);
> >> + return ret;
> >> + }
> > Does this need to handle ENOENT so as to avoid failing with old device
> > tree blobs?
>
> I'm no sure why we have to support the old device tree,
> We can apply this series patches if we need to support the reset property.
> ---
>
> Maybe, I can follow you suggestion to handle the ENOENT, as following:
>
> + /*
> + * The reset should be an optional property, as it should work
> + * with old devicetrees as well
> + */
> + info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb");
> + if (IS_ERR(info->reset)) {
> + if (PTR_ERR(info->reset) == -EPROBE_DEFER) {
> + ret = -EPROBE_DEFER;
> + return ret;
> + }
> + dev_dbg(&pdev->dev, "no reset control found\n");
> + info->reset = NULL;
> + }
> ...
>
> How about it?
I think it's better to handle ENOENT specifically, we still want to fail
if some other errors like EINVAL is returned.
Something like this, perhaps?
if (IS_ERR(info->reset)) {
ret = PTR_ERR(info->reset);
if (ret != -ENOENT)
return ret;
dev_dbg(&pdev->dev, "no reset control found\n");
info->reset = NULL;
}
Although I do wonder if a devm_reset_control_get_optional() helper would
be useful (this isn't the first time I've seen reset control added to
existing drivers).
Re: [PATCH v3] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize
Hi Baolin,
Sorry for not replying for previous emails because for some reason these
emails were archived. :(
On 12/07/16 10:01, Baolin Wang wrote:
> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
> attribute, which means it need to align the request buffer's size to an ep's
> maxpacketsize.
>
> Thus we add usb_ep_align_maybe() function to check if it is need to align
> the request buffer's size to an ep's maxpacketsize.
>
> Signed-off-by: Baolin Wang
> Acked-by: Michal Nazarewicz
> ---
> Changelog:
> v2:
> - Simplify the method to get buffer length.
> v1:
> - Remove the in_ep modification.
> - Remove max_t() function.
>
> drivers/usb/gadget/function/f_midi.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c
> b/drivers/usb/gadget/function/f_midi.c
> index 58fc199..3486941 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -359,10 +359,13 @@ static int f_midi_set_alt(struct usb_function *f,
> unsigned intf, unsigned alt)
>
> /* allocate a bunch of read buffers and queue them all at once. */
> for (i = 0; i < midi->qlen && err == 0; i++) {
> - struct usb_request *req =
> - midi_alloc_ep_req(midi->out_ep,
> - max_t(unsigned, midi->buflen,
> - bulk_out_desc.wMaxPacketSize));
> + struct usb_request *req;
> + unsigned length;
> +
> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
> + midi->buflen);
> +
> + req = midi_alloc_ep_req(midi->out_ep, length);
> if (req == NULL)
> return -ENOMEM;
>
>
Yes, as mentioned before, my intent was to align the size otherwise an
actual nasty bug happens.
I have two problems with this approach:
* usb_ep_align_maybe() has a bug that it doesn't convert wMaxPacketSize
endianness to the CPU. See my patch on that[1] subject. Also this
function uses round_up which expects x and y to be a power of 2, is that
a feasible assumption?
* If the gadget driver doesn't support quirk_ep_out_aligned_size,
usb_ep_align_maybe() can potentially return a len < wMaxPacketSize.
Basically causing a regression.
I believe we should protect this bad behavior on alloc_ep_req() in
drivers/usb/gadget/u_f.c by forcing align the size if the endpoint in
subject is OUT.
[1] [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using
wMaxPacketSize: https://lkml.org/lkml/2016/7/25/1028
--
Felipe
0x92698E6A.asc
Description: application/pgp-keys
Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs
On Tue, 26 Jul 2016, Auger Eric wrote: > On 26/07/2016 11:00, Thomas Gleixner wrote: > > In your case you don't want to have a partial allocation, so instead of > > playing silly games with desc->irq you should add a flag which tells the PCI > > code that you are not interested in a partial allocation and that it should > > return an error code instead. > > In that case can we consider we even succeeded in allocating 1 MSI? In case > the IOMMU mapping fails, the MSI transaction will never reach the target MSI > frame so it is not usable. So when you mean "partial" I understand we did > not succeed in allocating maxvec IRQs, correct? Here we succeeded in > allocating 0 IRQ and still msi_capability_init returns 1. > > msi_capability_init doc-comment says "a positive return value indicates the > number of interrupts which could have been allocated." > > I understand allocation success currently only depends on the fact virq was > allocated and set to desc->irq. But with that IOMMU stuff doesn't the > criteria changes? Right. But then you need to express it differently in a consistent way. Not by hacking around it by setting desc->irq to 0. Something like a flag field in msi_desc which denotes various properties would be a possible solution. MSI_IRQ_ALLOCATED and MSI_IRQ_REMAPPED would be sufficient for now. And the deallocation/cleanup would rely on those flags rather than checking desc->irq. Thanks, tglx
[PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands support in batch mode
This patch adds multi-commands support for the batch mode. The same mode
can be seen in acpiexec.
However people may think this is not useful for an in-kernel debugger,
because the in-kernel debugger is always running, never exits. So we can
run another command by running another acpidbg batch mode instance.
But this mode should still be useful for acpidbg. The reason is: when the
in-kernel debugger has entered the single-stepping mode, ending acpidbg
(which closes the debugger IO interface) will lead to the end of the
single-stepping mode.
So we need the acpidbg multi-commands batch mode in order to execute
multiple single-stepping mode commands in scripts.
Signed-off-by: Lv Zheng
---
tools/power/acpi/tools/acpidbg/acpidbg.c | 77 +-
1 file changed, 64 insertions(+), 13 deletions(-)
diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c
b/tools/power/acpi/tools/acpidbg/acpidbg.c
index f5542b9..99a8f766 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -90,6 +90,7 @@ static char acpi_aml_batch_prompt;
static char acpi_aml_batch_roll;
static unsigned long acpi_aml_log_state;
static char *acpi_aml_batch_cmd = NULL;
+static char *acpi_aml_batch_cmds = NULL;
static char *acpi_aml_batch_pos = NULL;
static int acpi_aml_set_fl(int fd, int flags)
@@ -326,12 +327,65 @@ static void acpi_aml_loop(int fd)
}
}
+static void acpi_aml_delete_batch(void)
+{
+ if (acpi_aml_batch_cmd) {
+ free(acpi_aml_batch_cmd);
+ acpi_aml_batch_cmd = NULL;
+ }
+}
+
+static bool acpi_aml_create_batch(char *cmd)
+{
+ int len;
+
+ acpi_aml_delete_batch();
+ len = strlen(cmd);
+ acpi_aml_batch_cmd = calloc(len + 2, 1);
+ if (!acpi_aml_batch_cmd) {
+ perror("calloc");
+ return false;
+ }
+ memcpy(acpi_aml_batch_cmd, cmd, len);
+ acpi_aml_batch_cmd[len] = '\n';
+ return true;
+}
+
+static void acpi_aml_batch(int fd)
+{
+ char *ptr, *cmd;
+ bool run = false;
+
+ cmd = ptr = acpi_aml_batch_cmds;
+ while (*ptr) {
+ if (*ptr == ',') {
+ /* Convert commas to spaces */
+ *ptr = ' ';
+ } else if (*ptr == ';') {
+ *ptr = '\0';
+ run = true;
+ }
+ ptr++;
+ if (run || (*ptr == '\0')) {
+ if (!acpi_aml_create_batch(cmd))
+ return;
+ ioctl(fd, ACPI_IOCTL_DEBUGGER_FLUSH);
+ acpi_aml_loop(fd);
+ run = 0;
+ cmd = ptr;
+ acpi_aml_delete_batch();
+ }
+ }
+}
+
void usage(FILE *file, char *progname)
{
fprintf(file, "usage: %s [-b cmd] [-f file] [-h]\n", progname);
fprintf(file, "\nOptions:\n");
- fprintf(file, " -b Specify command to be executed in batch
mode\n");
- fprintf(file, " -f Specify interface file other than");
+ fprintf(file, " -b Specify commands to be executed in batch
mode\n");
+ fprintf(file, " Use ';' as command delimiters\n");
+ fprintf(file, " Use ',' as spaces\n");
+ fprintf(file, " -f Specify interface file other than\n");
fprintf(file, " /sys/kernel/debug/acpi/acpidbg\n");
fprintf(file, " -h Print this help message\n");
}
@@ -340,27 +394,23 @@ int main(int argc, char **argv)
{
int fd = -1;
int ch;
- int len;
int ret = EXIT_SUCCESS;
while ((ch = getopt(argc, argv, "b:f:h")) != -1) {
switch (ch) {
case 'b':
- if (acpi_aml_batch_cmd) {
+ if (acpi_aml_batch_cmds) {
fprintf(stderr, "Already specify %s\n",
- acpi_aml_batch_cmd);
+ acpi_aml_batch_cmds);
ret = EXIT_FAILURE;
goto exit;
}
- len = strlen(optarg);
- acpi_aml_batch_cmd = calloc(len + 2, 1);
- if (!acpi_aml_batch_cmd) {
- perror("calloc");
+ acpi_aml_batch_cmds = strdup(optarg);
+ if (!acpi_aml_batch_cmds) {
+ perror("strdup");
ret = EXIT_FAILURE;
goto exit;
}
- memcpy(acpi_aml_batch_cmd, optarg, len);
- acpi_aml_batch_cmd[len] = '\n';
acpi_aml_mode = ACPI_AML_BATCH;
break;
case 'f':
@@ -389,8 +439,9 @@ int main(int argc
[PATCH v4 2/3] tools/power/acpi/acpidbg: Use new flushing mechanism
This patch converts tools/power/acpi/tools/acpidbg/acpidbg to use the new
flushing mechanism.
Signed-off-by: Lv Zheng
---
tools/power/acpi/tools/acpidbg/acpidbg.c | 51 --
1 file changed, 7 insertions(+), 44 deletions(-)
diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c
b/tools/power/acpi/tools/acpidbg/acpidbg.c
index a88ac45..f5542b9 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -15,7 +15,9 @@
#include
#include
#include
+#include
#include
+#include
#define ACPI_AML_FILE "/sys/kernel/debug/acpi/acpidbg"
#define ACPI_AML_SEC_TICK 1
@@ -83,7 +85,6 @@ static const char *acpi_aml_file_path = ACPI_AML_FILE;
static unsigned long acpi_aml_mode = ACPI_AML_INTERACTIVE;
static bool acpi_aml_exit;
-static bool acpi_aml_batch_drain;
static unsigned long acpi_aml_batch_state;
static char acpi_aml_batch_prompt;
static char acpi_aml_batch_roll;
@@ -239,11 +240,9 @@ static int acpi_aml_write_batch_log(int fd, struct
circ_buf *crc)
p = &crc->buf[crc->tail];
len = circ_count_to_end(crc);
- if (!acpi_aml_batch_drain) {
- len = write(fd, p, len);
- if (len < 0)
- perror("write");
- }
+ len = write(fd, p, len);
+ if (len < 0)
+ perror("write");
if (len > 0)
crc->tail = (crc->tail + len) & (ACPI_AML_BUF_SIZE - 1);
return len;
@@ -270,10 +269,7 @@ static void acpi_aml_loop(int fd)
if (acpi_aml_mode == ACPI_AML_BATCH) {
acpi_aml_log_state = ACPI_AML_LOG_START;
acpi_aml_batch_pos = acpi_aml_batch_cmd;
- if (acpi_aml_batch_drain)
- acpi_aml_batch_state = ACPI_AML_BATCH_READ_LOG;
- else
- acpi_aml_batch_state = ACPI_AML_BATCH_WRITE_CMD;
+ acpi_aml_batch_state = ACPI_AML_BATCH_WRITE_CMD;
}
acpi_aml_exit = false;
while (!acpi_aml_exit) {
@@ -330,39 +326,6 @@ static void acpi_aml_loop(int fd)
}
}
-static bool acpi_aml_readable(int fd)
-{
- fd_set rfds;
- struct timeval tv;
- int ret;
- int maxfd = 0;
-
- tv.tv_sec = 0;
- tv.tv_usec = ACPI_AML_USEC_PEEK;
- FD_ZERO(&rfds);
- maxfd = acpi_aml_set_fd(fd, maxfd, &rfds);
- ret = select(maxfd+1, &rfds, NULL, NULL, &tv);
- if (ret < 0)
- perror("select");
- if (ret > 0 && FD_ISSET(fd, &rfds))
- return true;
- return false;
-}
-
-/*
- * This is a userspace IO flush implementation, replying on the prompt
- * characters and can be turned into a flush() call after kernel implements
- * .flush() filesystem operation.
- */
-static void acpi_aml_flush(int fd)
-{
- while (acpi_aml_readable(fd)) {
- acpi_aml_batch_drain = true;
- acpi_aml_loop(fd);
- acpi_aml_batch_drain = false;
- }
-}
-
void usage(FILE *file, char *progname)
{
fprintf(file, "usage: %s [-b cmd] [-f file] [-h]\n", progname);
@@ -426,7 +389,7 @@ int main(int argc, char **argv)
acpi_aml_set_fl(STDOUT_FILENO, O_NONBLOCK);
if (acpi_aml_mode == ACPI_AML_BATCH)
- acpi_aml_flush(fd);
+ ioctl(fd, ACPI_IOCTL_DEBUGGER_FLUSH);
acpi_aml_loop(fd);
exit:
--
1.7.10
[PATCH v4 0/3] ACPI / debugger: Add kernel flushing support
The AML debugger can be used to dump the runtime value of a named object, which is useful for remote debugging issues. The batch mode of the AML debugger allows the debugger functionalities to be integrated into the scripts. Currently, when the batch mode is used, the userspace tool needs to flush the output (logs/prompts) remained in the kernel output buffer in order not to mess up the result of the executed batch mode command, this is implemented in an inefficient way in the userspace by polling the IO and reading everything out. However, the input needn't be flushed as the command input should have already been flushed by the signals and won't be passed to acpi_os_get_line() due to an error return value. This patch introduces a kernel space flushing support, so that userspace can invoke ioctl() to request the driver to drop old outputs. Lv Zheng (3): ACPI / debugger: Add kernel flushing support tools/power/acpi/acpidbg: Use new flushing mechanism tools/power/acpi/acpidbg: Add multi-commands support in batch mode drivers/acpi/acpi_dbg.c | 85 +-- include/linux/acpi.h |1 + include/uapi/linux/acpi-ioctls.h | 21 ++ tools/power/acpi/tools/acpidbg/acpidbg.c | 110 +- 4 files changed, 165 insertions(+), 52 deletions(-) create mode 100644 include/uapi/linux/acpi-ioctls.h -- 1.7.10
[PATCH v4 1/3] ACPI / debugger: Add kernel flushing support
This patch adds debugger output flushing support in kernel via .ioctl()
callback. The in-kernel flushing is more efficient, because it reduces
useless log IOs by bypassing log user_read/kern_write during the flush
period.
This mechanism is useful for the batch mode. Scripts can integrate a batch
mode acpidbg instance to perform AML debugger functionalities.
As the batch mode always starts from a new command write, it thus requires
the kernel debugger driver to drop the old input/output first. The old
input is automatically dropped by acpi_os_get_line() via an error returning
value, but the output are remained in acpi_dbg output buffers and should be
dropped prior than reading the new command, otherwise, the old output can
be read out by the batch mode instance and the result of the batch mode
command will be messed up.
Signed-off-by: Lv Zheng
Cc: linux-...@vger.kernel.org
---
drivers/acpi/acpi_dbg.c | 85 --
include/linux/acpi.h |1 +
include/uapi/linux/acpi-ioctls.h | 21 ++
3 files changed, 103 insertions(+), 4 deletions(-)
create mode 100644 include/uapi/linux/acpi-ioctls.h
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c
index dee8692..a5f4457 100644
--- a/drivers/acpi/acpi_dbg.c
+++ b/drivers/acpi/acpi_dbg.c
@@ -46,6 +46,8 @@
#define ACPI_AML_KERN (ACPI_AML_IN_KERN | ACPI_AML_OUT_KERN)
#define ACPI_AML_BUSY (ACPI_AML_USER | ACPI_AML_KERN)
#define ACPI_AML_OPEN (ACPI_AML_OPENED | ACPI_AML_CLOSED)
+#define ACPI_AML_FLUSHING_LOG 0x0040 /* flushing log output */
+#define ACPI_AML_WAITING_CMD 0x0080 /* waiting for cmd input */
struct acpi_aml_io {
wait_queue_head_t wait;
@@ -120,6 +122,16 @@ static inline bool __acpi_aml_busy(void)
return false;
}
+static inline bool __acpi_aml_waiting_cmd(void)
+{
+ return !!(acpi_aml_io.flags & ACPI_AML_WAITING_CMD);
+}
+
+static inline bool __acpi_aml_flushing_log(void)
+{
+ return !!(acpi_aml_io.flags & ACPI_AML_FLUSHING_LOG);
+}
+
static inline bool __acpi_aml_opened(void)
{
if (acpi_aml_io.flags & ACPI_AML_OPEN)
@@ -152,6 +164,26 @@ static bool acpi_aml_busy(void)
return ret;
}
+static inline bool acpi_aml_waiting_cmd(void)
+{
+ bool ret;
+
+ mutex_lock(&acpi_aml_io.lock);
+ ret = __acpi_aml_waiting_cmd();
+ mutex_unlock(&acpi_aml_io.lock);
+ return ret;
+}
+
+static inline bool acpi_aml_flushing_log(void)
+{
+ bool ret;
+
+ mutex_lock(&acpi_aml_io.lock);
+ ret = __acpi_aml_flushing_log();
+ mutex_unlock(&acpi_aml_io.lock);
+ return ret;
+}
+
static bool acpi_aml_used(void)
{
bool ret;
@@ -183,7 +215,8 @@ static bool acpi_aml_kern_writable(void)
mutex_lock(&acpi_aml_io.lock);
ret = !__acpi_aml_access_ok(ACPI_AML_OUT_KERN) ||
- __acpi_aml_writable(&acpi_aml_io.out_crc, ACPI_AML_OUT_KERN);
+ __acpi_aml_writable(&acpi_aml_io.out_crc, ACPI_AML_OUT_KERN) ||
+ __acpi_aml_flushing_log();
mutex_unlock(&acpi_aml_io.lock);
return ret;
}
@@ -264,6 +297,9 @@ static int acpi_aml_write_kern(const char *buf, int len)
int n;
char *p;
+ if (acpi_aml_flushing_log())
+ return len;
+
ret = acpi_aml_lock_write(crc, ACPI_AML_OUT_KERN);
if (ret < 0)
return ret;
@@ -458,9 +494,18 @@ static int acpi_aml_wait_command_ready(bool single_step,
else
acpi_os_printf("\n%1c ", ACPI_DEBUGGER_COMMAND_PROMPT);
+ mutex_lock(&acpi_aml_io.lock);
+ acpi_aml_io.flags |= ACPI_AML_WAITING_CMD;
+ wake_up_interruptible(&acpi_aml_io.wait);
+ mutex_unlock(&acpi_aml_io.lock);
+
status = acpi_os_get_line(buffer, length, NULL);
if (ACPI_FAILURE(status))
return -EINVAL;
+
+ mutex_lock(&acpi_aml_io.lock);
+ acpi_aml_io.flags &= ~ACPI_AML_WAITING_CMD;
+ mutex_unlock(&acpi_aml_io.lock);
return 0;
}
@@ -593,9 +638,11 @@ static int acpi_aml_read_user(char __user *buf, int len)
smp_rmb();
p = &crc->buf[crc->tail];
n = min(len, circ_count_to_end(crc));
- if (copy_to_user(buf, p, n)) {
- ret = -EFAULT;
- goto out;
+ if (!acpi_aml_flushing_log()) {
+ if (copy_to_user(buf, p, n)) {
+ ret = -EFAULT;
+ goto out;
+ }
}
/* sync tail after removing logs */
smp_mb();
@@ -731,10 +778,40 @@ static unsigned int acpi_aml_poll(struct file *file,
poll_table *wait)
return masks;
}
+static int acpi_aml_flush(void)
+{
+ int ret;
+
+ /*
+* Discard output buffer and put the driver into a state waiting
+* for the new user input.
+*/
+ mutex_lock(&acpi_aml_io.lock);
+ acpi_aml_io.flags |= ACPI_AML_FLUSHING_LOG;
+ mutex_unlock(&ac
Re: [PATCH 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it
On 2016年07月26日 17:00, John Keeping wrote:
On Tue, 26 Jul 2016 14:11:47 +0800, Caesar Wang wrote:
SARADC controller needs to be reset before programming it, otherwise
it will not function properly.
Signed-off-by: Caesar Wang
Cc: Jonathan Cameron
Cc: Heiko Stuebner
Cc: Rob Herring
Cc: linux-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
---
diff --git a/drivers/iio/adc/rockchip_saradc.c
b/drivers/iio/adc/rockchip_saradc.c
index f9ad6c2..2f0e110 100644
--- a/drivers/iio/adc/rockchip_saradc.c
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -218,6 +231,13 @@ static int rockchip_saradc_probe(struct platform_device
*pdev)
if (IS_ERR(info->regs))
return PTR_ERR(info->regs);
+ info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb");
+ if (IS_ERR(info->reset)) {
+ ret = PTR_ERR(info->reset);
+ dev_err(&pdev->dev, "failed to get saradc reset: %d\n", ret);
+ return ret;
+ }
Does this need to handle ENOENT so as to avoid failing with old device
tree blobs?
I'm no sure why we have to support the old device tree,
We can apply this series patches if we need to support the reset property.
---
Maybe, I can follow you suggestion to handle the ENOENT, as following:
+ /*
+ * The reset should be an optional property, as it should work
+ * with old devicetrees as well
+ */
+ info->reset = devm_reset_control_get(&pdev->dev, "saradc-apb");
+ if (IS_ERR(info->reset)) {
+ if (PTR_ERR(info->reset) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ return ret;
+ }
+ dev_dbg(&pdev->dev, "no reset control found\n");
+ info->reset = NULL;
+ }
...
+ if (info->reset)
+ rockchip_saradc_reset_controller(info->reset);
+
How about it?
-
Caesar
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
caesar wang | software engineer | w...@rock-chip.com
Re: [PATCH v2] arm64: mm: convert __dma_* routines to use start, size
On 26/07/16 08:34, Kwangwoo Lee wrote: > v2) > change __dma_* routine names using the terminoloy guidance: > area: takes a start and size > range: takes a start and end > use __dma_flush_area() instead of __dma_flush_range() in dma-mapping.c > > v1) > __dma_* routines have been converted to use start and size instread of > start and end addresses. The patch was origianlly for adding > __clean_dcache_area_poc() which will be used in pmem driver to clean > dcache to the PoC(Point of Coherency) in arch_wb_cache_pmem(). > > The functionality of __clean_dcache_area_poc() was equivalent to > __dma_clean_range(). The difference was __dma_clean_range() uses the end > address, but __clean_dcache_area_poc() uses the size to clean. > > Thus, __clean_dcache_area_poc() has been revised with a fall through > function of __dma_clean_range() after the change that __dma_* routines > use start and size instead of using start and end. > > Signed-off-by: Kwangwoo Lee > --- Nit: the changelog relative to the previous posting wants to be here, under the "---" separator; the commit message above should describe the _current_ state of the patch, as that's all we'll really care about once it's in the Git history. > arch/arm64/include/asm/cacheflush.h | 3 +- > arch/arm64/mm/cache.S | 71 > +++-- > arch/arm64/mm/dma-mapping.c | 6 ++-- > 3 files changed, 41 insertions(+), 39 deletions(-) > > diff --git a/arch/arm64/include/asm/cacheflush.h > b/arch/arm64/include/asm/cacheflush.h > index c64268d..2e5fb97 100644 > --- a/arch/arm64/include/asm/cacheflush.h > +++ b/arch/arm64/include/asm/cacheflush.h > @@ -68,6 +68,7 @@ > extern void flush_cache_range(struct vm_area_struct *vma, unsigned long > start, unsigned long end); > extern void flush_icache_range(unsigned long start, unsigned long end); > extern void __flush_dcache_area(void *addr, size_t len); > +extern void __clean_dcache_area_poc(void *addr, size_t len); > extern void __clean_dcache_area_pou(void *addr, size_t len); > extern long __flush_cache_user_range(unsigned long start, unsigned long end); > > @@ -85,7 +86,7 @@ static inline void flush_cache_page(struct vm_area_struct > *vma, > */ > extern void __dma_map_area(const void *, size_t, int); > extern void __dma_unmap_area(const void *, size_t, int); > -extern void __dma_flush_range(const void *, const void *); > +extern void __dma_flush_area(const void *, size_t); > > /* > * Copy user data from/to a page which is mapped into a different > diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S > index 50ff9ba..4415c1b 100644 > --- a/arch/arm64/mm/cache.S > +++ b/arch/arm64/mm/cache.S > @@ -110,14 +110,16 @@ ENDPROC(__clean_dcache_area_pou) > * - end - end address of region > */ > ENTRY(__inval_cache_range) > + sub x1, x1, x0 Rather than doing this, I think it would be more sensible to simply swap the entry points. > /* FALLTHROUGH */ > > /* > - * __dma_inv_range(start, end) > + * __dma_inv_area(start, size) > * - start - virtual start address of region > - * - end - virtual end address of region > + * - size- size in question > */ > -__dma_inv_range: > +__dma_inv_area: > + add x1, x1, x0 > dcache_line_size x2, x3 > sub x3, x2, #1 > tst x1, x3 // end cache line aligned? > @@ -136,46 +138,47 @@ __dma_inv_range: > dsb sy > ret > ENDPIPROC(__inval_cache_range) > -ENDPROC(__dma_inv_range) > +ENDPROC(__dma_inv_area) > + > +/* > + * __clean_dcache_area_poc(kaddr, size) > + * > + * Ensure that any D-cache lines for the interval [kaddr, kaddr+size) > + * are cleaned to the PoC. > + * > + * - kaddr - kernel address > + * - size- size in question > + */ > +ENTRY(__clean_dcache_area_poc) > + /* FALLTHROUGH */ > > /* > - * __dma_clean_range(start, end) > + * __dma_clean_area(start, size) > * - start - virtual start address of region > - * - end - virtual end address of region > + * - size- size in question > */ > -__dma_clean_range: > - dcache_line_size x2, x3 > - sub x3, x2, #1 > - bic x0, x0, x3 > -1: > +__dma_clean_area: > alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE > - dc cvac, x0 > + dcache_by_line_op cvac, sy, x0, x1, x2, x3 > alternative_else > - dc civac, x0 > + dcache_by_line_op civac, sy, x0, x1, x2, x3 dcache_by_line_op is a relatively large macro - is there any way we can still apply the alternative to just the one instruction which needs it, as opposed to having to patch the entire mostly-identical routine? Robin. > alternative_endif > - add x0, x0, x2 > - cmp x0, x1 > - b.lo1b > - dsb sy > ret > -ENDPROC(__dma_clean_range) > +ENDPIPROC(__clean_dcache_area_poc) > +ENDPROC(__dma_clean_area) > > /* > - * __dma_flush_range(start, end) > + * __dma_flush_area(sta
[PATCH] checkpatch: Improve 'bare use of' signed/unsigned types warning
Fix false positive warning of identifiers ending in signed with an =
assignment of WARNING: Prefer 'signed int' to bare use of 'signed'.
Reported-by: Alan Douglas
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 77915e0..1d5b09d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3347,7 +3347,7 @@ sub process {
next if ($line =~ /^[^\+]/);
# check for declarations of signed or unsigned without int
- while ($line =~
m{($Declare)\s*(?!char\b|short\b|int\b|long\b)\s*($Ident)?\s*[=,;\[\)\(]}g) {
+ while ($line =~
m{\b($Declare)\s*(?!char\b|short\b|int\b|long\b)\s*($Ident)?\s*[=,;\[\)\(]}g) {
my $type = $1;
my $var = $2;
$var = "" if (!defined $var);
--
2.8.0.rc4.16.g56331f8
Re: [PATCH] prctl: remove one-shot limitation for changing exe link
25.07.2016 20:21, Eric W. Biederman пишет: Stanislav Kinsburskiy writes: Gentlemen, Looks like there are no objections to this patch. There has been objection. The only justification for the change that has been put forward is someone doing a restore lazily. I don't see a reason why you can't call prctl_set_mm_exe_file until you have the file in place instead of a place holder that sounds like a trivial solution to any restore issues. If I understand your proposal correctly, you mean, that the call to prctl_set_mm_exe_file can be posponed till the actual file is in place. It can be done this way you propose (although it's ugly). But you objection looks like you want to preserve some behavior you believe is reliable. But it's not. The truth is an unlimited settable exe link is essentially meaningless, as you can't depend on it for anything. One shot seems the best compromise I have seen put forward between the definite checkpoint/restart requirement to set the this value and the general need to have something that makes sense and people can depend on for system management. Depending on exe link for system management is useful, but can't be reliable and can't prevent malicious software to compromise the system. If we wouldn't have the ability to change exe link, than the only thing we could be sure, that process at least started with the binary we believe is reliable. But since we can change it, the only thing we can rely now is the file is executable and process have permissions to execute it. And this guarantee in preserved across any amount of exe link replacement. Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't validate that the new file is a actually mmaped executable. We would definitely need that to be fixed before even considering removing the limit. Why do we need it? To guarantee, that process has read permission to the file? Right now all I see is people involved in the implementation details of their own little feature So for the patch I am responding to: Nacked-by: "Eric W. Biederman" Plus the merge window is open so no one is taking any patches right now. It is the time to take what has already been staged and get that code merged. Eric
Re: [PATCH v2 00/10] userns: sysctl limits for namespaces
Hello Eric, I realized I had a question after the last mail. On 07/21/2016 06:39 PM, Eric W. Biederman wrote: This patchset addresses two use cases: - Implement a sane upper bound on the number of namespaces. - Provide a way for sandboxes to limit the attack surface from namespaces. Can you say more about the second point? What exactly is the problem that is being addressed, and how does the patch series address it? (It would be good to have those details in the revised commit message...) Cheers, Michael
Re: [PATCH v2 00/10] userns: sysctl limits for namespaces
Hello Eric, On 07/21/2016 06:39 PM, Eric W. Biederman wrote: This patchset addresses two use cases: - Implement a sane upper bound on the number of namespaces. - Provide a way for sandboxes to limit the attack surface from namespaces. The maximum sane case I can imagine is if every process is a fat process, so I set the maximum number of namespaces to the maximum number of threads. I make these limits recursive and per user namespace so that a usernamespace root can reduce the limits further. If a user namespace root raises the limit the limit in the parent namespace will be honored. I have cut this implementation to the bare minimum needed to achieve these objectives. Does anyone know if there is a proper error code to return for resource limit exceeded? I am currently using -EUSERS or -ENFILE but both of those feel a little wrong. ENFILE certainly seems weird. I suppose my first question is: why two different errors? Some alternatives you might want to consider: E2BIG, EOVERFLOW, or (maybe) ERANGE. Cheers, Michael
Re: bcache super block corruption with non 4k pages
On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: > On 21.07.2016 10:58, Stefan Bader wrote: > > I was pointed at the thread which seems to address the same after > > I wrote most of below text. Did not want to re-write this so please > > bear with the odd layout. > > > > https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html > > > > Zhengyuan tries to fix the problem by relocating the superblock on > > disk. But I am not sure whether there is really any guarantee about > > how __bread fills data into the buffer_head. What if there is the next > > odd arch with 128K pages? > > > > So below is an attempt to be more generic. Still I don't feel completely > > happy with the way that a page moves (or is shared) between buffer_head > > and biovec. What I tried to outline below is to let the register functions > > allocate bio+biovec memory and use the in-memory sb_cache data to initialize > > the biovec buffer. > > Any opinions here? Also adding LKML as I don't seem to get through moderation > on > dm-devel. The correct solution is to rip out the __bread() and just read the superblock by issuing a bio, the same way all the other IO in bcache is done. This is the way it's done in the bcache-dev branch - unfortunately, the patch that does that in bcache-dev is big and invasive and probably not worth the hassle to backport: https://evilpiepirate.org/git/linux-bcache.git/commit/?h=bcache-dev&id=303eb67bffad57b4d9e71523e7df04bf258e66d1 Probably best to just do something small and localized.
Re: [zer0...@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master]
Vegard Nossum wrote: > $ echo "Code: 5c 41 5d 41 5e 41 5f 5d c3 e8 89 f1 98 ff 4c 8b 25 32 cb > 47 02 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 48 48 89 fa 48 c1 ea > 03 <80> 3c 02 00 0f 85 78 03 00 00 4d 8b 64 24 48 48 b8 00 00 00 00" | > scripts/decodecode Thanks! I didn't know this existed. David
Re: [PATCH v2 11/13] gpu: ipu-ic: Add complete image conversion support with tiling
Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam: > This patch implements complete image conversion support to ipu-ic, > with tiling to support scaling to and from images up to 4096x4096. > Image rotation is also supported. > > The internal API is subsystem agnostic (no V4L2 dependency except > for the use of V4L2 fourcc pixel formats). > > Callers prepare for image conversion by calling > ipu_image_convert_prepare(), which initializes the parameters of > the conversion. The caller passes in the ipu_ic task to use for > the conversion, the input and output image formats, a rotation mode, > and a completion callback and completion context pointer: > > struct image_converter_ctx * > ipu_image_convert_prepare(struct ipu_ic *ic, > struct ipu_image *in, struct ipu_image *out, > enum ipu_rotate_mode rot_mode, > image_converter_cb_t complete, > void *complete_context); > > The caller is given a new conversion context that must be passed to > the further APIs: > > struct image_converter_run * > ipu_image_convert_run(struct image_converter_ctx *ctx, > dma_addr_t in_phys, dma_addr_t out_phys); > > This queues a new image conversion request to a run queue, and > starts the conversion immediately if the run queue is empty. Only > the physaddr's of the input and output image buffers are needed, > since the conversion context was created previously with > ipu_image_convert_prepare(). Returns a new run object pointer. When > the conversion completes, the run pointer is returned to the > completion callback. > > void image_convert_abort(struct image_converter_ctx *ctx); > > This will abort any active or pending conversions for this context. > Any currently active or pending runs belonging to this context are > returned via the completion callback with an error status. > > void ipu_image_convert_unprepare(struct image_converter_ctx *ctx); > > Unprepares the conversion context. Any active or pending runs will > be aborted by calling image_convert_abort(). > > Signed-off-by: Steve Longerbeam > --- > drivers/gpu/ipu-v3/ipu-ic.c | 1691 > ++- > include/video/imx-ipu-v3.h | 57 +- > 2 files changed, 1736 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c > index 1a37afc..5471b72 100644 > --- a/drivers/gpu/ipu-v3/ipu-ic.c > +++ b/drivers/gpu/ipu-v3/ipu-ic.c > @@ -17,6 +17,8 @@ > #include > #include > #include > +#include > +#include > #include "ipu-prv.h" > > /* IC Register Offsets */ > @@ -82,6 +84,40 @@ > #define IC_IDMAC_3_PP_WIDTH_MASK(0x3ff << 20) > #define IC_IDMAC_3_PP_WIDTH_OFFSET 20 > > +/* > + * The IC Resizer has a restriction that the output frame from the > + * resizer must be 1024 or less in both width (pixels) and height > + * (lines). > + * > + * The image conversion support attempts to split up a conversion when > + * the desired output (converted) frame resolution exceeds the IC resizer > + * limit of 1024 in either dimension. > + * > + * If either dimension of the output frame exceeds the limit, the > + * dimension is split into 1, 2, or 4 equal stripes, Imagine converting a 320x200 image up to 1280x800, and consider only the x coordinate. The IC upscaler is a simple bilinear scaler. We want target pixel x' = 1279 to sample the source pixel x = 319, so the scaling factor rsc is calculated to: x = x' * (320-1)/(1280-1) = x' * 8192/rsc, with rsc = 32846 That means that the target pixels x' = 639 and x' = 640 should be sampled (bilinearly) from x = 639 * 8192/32846. = 159.37 and x = 640 * 8192/32846. = 159.62, respectively. Now split the frame in half and suddenly pixel x' = 640 is the start of a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be sampled at x = 160 + (1279 - 640) * 8192/32846. = 319.37, reading over the edge of the source image. This problem gets worse if you start using arbitrary frame sizes and YUV planar images and consider that tile start addresses are (currently) limited to 8 byte boundaries, to the point that there are very visible seams in the center of the image, depending on scaling factor and image sizes. I wonder how much effort it would be to remove the tiling code for now and add it back in a second step once it is fixed? Otherwise we could just disallow scaled tiling for now, but I'd like this to be prepared for tiles with different sizes at least, before merging. regards Philipp
Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall
On 26/07/2016 12:00, Alexander Stein wrote:
> On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote:
>> On 26/07/2016 11:05, Alexander Stein wrote:
>>> On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote:
On 26/07/2016 10:21, Alexander Stein wrote:
> On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote:
>> iio_channel_get_all returns -ENODEV when it cannot find either phandles
>> and
>> properties in the Device Tree or channels whose consumer_dev_name
>> matches
>> iio_hwmon in iio_map_list. The iio_map_list is filled in by iio drivers
>> which might be probed after iio_hwmon.
>
> Would it work if iio_channel_get_all returning ENODEV is used for
> returning
> EPROBE_DEFER in iio_channel_get_all? Using late initcalls for
> driver/device
> dependencies seems not right for me at this place.
Then what if the iio_channel_get_all is called outside of the probe of a
driver? We'll have to change the error code, things we are apparently
trying to avoid (see v2 patches' discussions).
>>>
>>> Maybe I didn't express my idea enough. I don't want to change the behavior
>>> of iio_channel_get_all at all. Just the result evaluation of
>>> iio_channel_get_all in iio_hwmon_probe. I have something link the patch
>>> below in mind.
>>>
>>> Best regards,
>>> Alexander
>>> ---
>>> diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
>>> index b550ba5..e32d150 100644
>>> --- a/drivers/hwmon/iio_hwmon.c
>>> +++ b/drivers/hwmon/iio_hwmon.c
>>> @@ -73,8 +73,12 @@ static int iio_hwmon_probe(struct platform_device
>>> *pdev)
>>>
>>> name = dev->of_node->name;
>>>
>>> channels = iio_channel_get_all(dev);
>>>
>>> - if (IS_ERR(channels))
>>> - return PTR_ERR(channels);
>>> + if (IS_ERR(channels)) {
>>> + if (PTR_ERR(channels) == -ENODEV)
>>> + return -EPROBE_DEFER;
>>> + else
>>> + return PTR_ERR(channels);
>>> + }
>>>
>>> st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
>>> if (st == NULL) {
>>
>> Indeed, I misunderstood what you told me.
>>
>> Actually, the patch you proposed is part of my v1
>> (https://lkml.org/lkml/2016/6/28/203) and v2
>> (https://lkml.org/lkml/2016/7/15/215).
>> Jonathan and Guenter didn't really like the idea of changing the -ENODEV
>> in -EPROBE_DEFER.
>
> Thanks for the links.
>
>> What I thought you were proposing was to change the -ENODEV return code
>> inside iio_channel_get_all. This cannot be an option since the function
>> might be called outside of a probe (it is not yet, but might be in the
>> future?).
>
> AFAICS this is a helper function not knowing about device probing itself. And
> it should stay at that.
>
>> Of what I understood, two possibilities are then possible (proposed
>> either by Guenter or Jonathan): either rework the iio framework to
>> register iio map array earlier or to use late_initcall instead of init
>> for the driver consuming the iio channels.
>
> Interestingly using this problem would not arise due to module dependencies.
> But using late_initcall would mean this needs to be done on any driver using
> iio channels? I would rather keep those consumers simple.
This would mean this needs to be done in any driver *using iio_map
array* to get iio channels. The other way of getting iio channels is
using properties in the Device Tree so no need for late_initcall in that
case.
Quentin
Re: [PATCH v2 05/13] gpu: ipu-v3: Add IDMA channel linking support
Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam:
> Adds functions to link and unlink IDMAC source channels to sink
> channels.
>
> So far the following links are supported:
>
> IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC
> PUV3_CHANNEL_IC_PRP_VF_MEM -> IPUV3_CHANNEL_MEM_ROT_VF
> IPUV3_CHANNEL_IC_PP_MEM -> IPUV3_CHANNEL_MEM_ROT_PP
>
> More links can be added to the idmac_link_info[] array.
>
> Signed-off-by: Steve Longerbeam
This patch looks good to me, but the Frame Synchronisation Unit supports
also linking the internal channels, not only the IDMAC channels.
[...]
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
[...]
> +static const struct idmac_link_info idmac_link_info[] = {
> + {
> + .src = { IPUV3_CHANNEL_IC_PRP_ENC_MEM, IPU_FS_PROC_FLOW1,
> + 0, 4, 7 },
> + .sink = { IPUV3_CHANNEL_MEM_ROT_ENC, IPU_FS_PROC_FLOW2,
> + 0, 4, 1 },
> + }, {
> + .src = { IPUV3_CHANNEL_IC_PRP_VF_MEM, IPU_FS_PROC_FLOW1,
> + 8, 4, 8 },
> + .sink = { IPUV3_CHANNEL_MEM_ROT_VF, IPU_FS_PROC_FLOW2,
> + 4, 4, 1 },
> + }, {
> + .src = { IPUV3_CHANNEL_IC_PP_MEM, IPU_FS_PROC_FLOW1,
> + 16, 4, 5 },
> + .sink = { IPUV3_CHANNEL_MEM_ROT_PP, IPU_FS_PROC_FLOW2,
> + 12, 4, 3 },
> + },
> +};
How about adding new (internal) channel numbers for the CSI->VDI link
and having something like:
{
.src = { IPUV3_CHANNEL_CSI_DIRECT, IPU_FS_PROC_FLOW1,
FS_VDI_SRC_SEL_OFFSET, 2, 1 },
.sink = { IPUV3_CHANNEL_VDI_CUR, 0, 0, 0 },
},
instead of ipu_set_vdi_src_mux? Then in addition to
[...]
> +int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink)
We could have a lower level
ipu_fsu_link(int channel1, int channel2)
which could be called like
ipu_fsu_link(IPUV3_CHANNEL_CSI_DIRECT, IPUV3_CHANNEL_VDI_CUR);
Come to think of it, could we replace shift,bits,sel with mask,value and
add #defines for the FSU bit fields and values? I'm thinking:
/* FS_PROC_FLOW1 */
#define FS_PRPENC_ROT_SRC_SEL_MASK (0xf << 0)
#define FS_PRPENC_ROT_SRC_SEL_ENC (0x7 << 0)
#define FS_PRPVF_ROT_SRC_SEL_MASK (0xf << 8)
#define FS_PRPVF_ROT_SRC_SEL_VF (0x8 << 8)
#define FS_PP_SRC_SEL_MASK (0xf << 12)
#define FS_PP_ROT_SRC_SEL_MASK (0xf << 16)
#define FS_PP_ROT_SRC_SEL_PP(0x5 << 16)
#define FS_VDI1_SRC_SEL_MASK(0x3 << 20)
#define FS_VDI3_SRC_SEL_MASK(0x3 << 20)
#define FS_PRP_SRC_SEL_MASK (0xf << 24)
#define FS_VDI_SRC_SEL_MASK (0x3 << 28)
/* FS_PROC_FLOW2 */
#define FS_PRP_ENC_DEST_SEL_MASK(0xf << 0)
#define FS_PRP_ENC_DEST_SEL_IRT_ENC (0x1 << 0)
#define FS_PRPVF_DEST_SEL_MASK (0xf << 4)
#define FS_PRPVF_DEST_SEL_IRT_VF(0x1 << 4)
#define FS_PRPVF_ROT_DEST_SEL_MASK (0xf << 8)
#define FS_PP_DEST_SEL_MASK (0xf << 12)
#define FS_PP_DEST_SEL_IRT_PP (0x3 << 12)
#define FS_PP_ROT_DEST_SEL_MASK (0xf << 16)
#define FS_PRPENC_ROT_DEST_SEL_MASK (0xf << 20)
#define FS_PRP_DEST_SEL_MASK(0xf << 24)
struct idmac_link_reg_info {
int chno;
u32 reg;
u32 mask;
u32 val;
};
static const struct idmac_link_info idmac_link_info[] = {
{
.src = { IPUV3_CHANNEL_IC_PRP_ENC_MEM, IPU_FS_PROC_FLOW1,
FS_PRPENC_ROT_SRC_SEL_MASK, FS_PRPENC_ROT_SRC_SEL_ENC
},
.sink = { IPUV3_CHANNEL_MEM_ROT_ENC, IPU_FS_PROC_FLOW2,
FS_PRP_ENC_DEST_SEL_MASK, FS_PRP_ENC_DEST_SEL_IRT_ENC
},
}, {
.src = { IPUV3_CHANNEL_IC_PRP_VF_MEM, IPU_FS_PROC_FLOW1,
FS_PRPVF_ROT_SRC_SEL_MASK, FS_PRPVF_ROT_SRC_SEL_VF },
.sink = { IPUV3_CHANNEL_MEM_ROT_VF, IPU_FS_PROC_FLOW2,
FS_PRPVF_DEST_SEL_MASK, FS_PRPVF_DEST_SEL_IRT_VF },
}, {
.src = { IPUV3_CHANNEL_IC_PP_MEM, IPU_FS_PROC_FLOW1,
FS_PP_ROT_SRC_SEL_MASK, FS_PP_ROT_SRC_SEL_PP },
.sink = { IPUV3_CHANNEL_MEM_ROT_PP, IPU_FS_PROC_FLOW2,
FS_PP_DEST_SEL_MASK, FS_PP_DEST_SEL_IRT_PP },
},
};
regards
Philipp
Re: [PATCH v2 01/13] gpu: ipu-v3: Add Video Deinterlacer unit
Am Dienstag, den 19.07.2016, 18:10 -0700 schrieb Steve Longerbeam:
> Adds the Video Deinterlacer (VDIC) unit.
>
> Signed-off-by: Steve Longerbeam
[...]
> +++ b/drivers/gpu/ipu-v3/ipu-vdi.c
[...]
> +static void __ipu_vdi_set_top_field_man(struct ipu_vdi *vdi, bool
> top_field_0)
> +{
> + u32 reg;
> +
> + reg = ipu_vdi_read(vdi, VDI_C);
> + if (top_field_0)
> + reg &= ~VDI_C_TOP_FIELD_MAN_1;
> + else
> + reg |= VDI_C_TOP_FIELD_MAN_1;
> + ipu_vdi_write(vdi, reg, VDI_C);
> +}
[...]
> +void ipu_vdi_toggle_top_field_man(struct ipu_vdi *vdi)
> +{
> + unsigned long flags;
> + u32 reg;
> + u32 mask_reg;
> +
> + spin_lock_irqsave(&vdi->lock, flags);
> +
> + reg = ipu_vdi_read(vdi, VDI_C);
> + mask_reg = reg & VDI_C_TOP_FIELD_MAN_1;
> + if (mask_reg == VDI_C_TOP_FIELD_MAN_1)
> + reg &= ~VDI_C_TOP_FIELD_MAN_1;
> + else
> + reg |= VDI_C_TOP_FIELD_MAN_1;
> +
> + ipu_vdi_write(vdi, reg, VDI_C);
> +
> + spin_unlock_irqrestore(&vdi->lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(ipu_vdi_toggle_top_field_man);
Why not export set top field man? Does it make sense to keep the user of
this API in the dark about the current setting?
regards
Philipp
Re: [PATCH v2 00/13] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v2
Hi Steve, Am Dienstag, den 19.07.2016, 18:10 -0700 schrieb Steve Longerbeam: > These updates to IPUv3 are needed for media staging drivers > for i.MX5/6 video capture and mem2mem. > > Steve Longerbeam (13): > gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset() > gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize() > gpu: ipu-v3: Add ipu_get_num() > gpu: ipu-v3: Add VDI input IDMAC channels > gpu: ipu-v3: set correct full sensor frame for PAL/NTSC > gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats > gpu: ipu-v3: Fix IRT usage > gpu: ipu-v3: rename CSI client device I have applied these. > gpu: ipu-v3: Add Video Deinterlacer unit > gpu: ipu-v3: Add IDMA channel linking support > gpu: ipu-v3: Add ipu_set_vdi_src_mux() > gpu: ipu-ic: Add complete image conversion support with tiling > gpu: ipu-ic: allow multiple handles to ic But I have questions or comments for these. The VDI depends on ipu_set_vdi_src_mux, which I still don't think is in the correct place. Channel linking looks mostly ok to me, but the image converter tiling doesn't work with fixed size tiles. See the other mails for details. best regards Philipp
Re: [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested
Hi Thomas,
On 26/07/2016 11:04, Thomas Gleixner wrote:
> Eric,
>
> On Mon, 25 Jul 2016, Auger Eric wrote:
>> On 20/07/2016 11:09, Thomas Gleixner wrote:
>>> On Tue, 19 Jul 2016, Eric Auger wrote:
@@ -63,10 +63,18 @@ static int msi_compose(struct irq_data *irq_data,
{
int ret = 0;
- if (erase)
+ if (erase) {
memset(msg, 0, sizeof(*msg));
- else
+ } else {
+ struct device *dev;
+
ret = irq_chip_compose_msi_msg(irq_data, msg);
+ if (ret)
+ return ret;
+
+ dev = msi_desc_to_dev(irq_data_get_msi_desc(irq_data));
+ WARN_ON(iommu_msi_msg_pa_to_va(dev, msg));
>>>
>>> What the heck is this call doing? And why is there only a WARN_ON and not a
>>> proper error return code handling?
>>
>> iommu_msi_msg_pa_to_va is part of the new iommu-msi API introduced in PART I
>> of this series. This helper function detects the physical address found in
>> the MSI message has a corresponding allocated IOVA. This happens if the MSI
>> doorbell is accessed through an IOMMU and this IOMMU do not bypass the MSI
>> addresses (ARM case). Allocation of this IOVA was performed in the previous
>> patch.
>>
>> So, if this is the case, the physical address is swapped with the IOVA
>> address. That way the PCIe device will send the MSI with this IOVA and
>> the address will be translated by the IOMMU into the target MSI doorbell PA.
>>
>> Hope this clarifies
>
> No, it does not. You are explaining in great length what that function is
> doing, but you are not explaining WHY your don't do a proper return code
> handling and just do a WARN_ON() and happily proceed. If that function fails
> then the interrupt will not be functional, so WHY on earth are you continuing?
Oh sorry I focused on the function's goal. Originally I could not return an
error since there is a BUG_ON(ret) afterwards. And typically the userspace can
willingly omit to pass IPA range that map MSIs. But now we have this 2 phases
where
we first map the MSIs on pci_enable_msi_range and use the IOVA at compose time
I need to analyze again if the userspace can induce a BUG_ON.
Thanks
Eric
>
> Thanks,
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall
On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote:
> On 26/07/2016 11:05, Alexander Stein wrote:
> > On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote:
> >> On 26/07/2016 10:21, Alexander Stein wrote:
> >>> On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote:
> iio_channel_get_all returns -ENODEV when it cannot find either phandles
> and
> properties in the Device Tree or channels whose consumer_dev_name
> matches
> iio_hwmon in iio_map_list. The iio_map_list is filled in by iio drivers
> which might be probed after iio_hwmon.
> >>>
> >>> Would it work if iio_channel_get_all returning ENODEV is used for
> >>> returning
> >>> EPROBE_DEFER in iio_channel_get_all? Using late initcalls for
> >>> driver/device
> >>> dependencies seems not right for me at this place.
> >>
> >> Then what if the iio_channel_get_all is called outside of the probe of a
> >> driver? We'll have to change the error code, things we are apparently
> >> trying to avoid (see v2 patches' discussions).
> >
> > Maybe I didn't express my idea enough. I don't want to change the behavior
> > of iio_channel_get_all at all. Just the result evaluation of
> > iio_channel_get_all in iio_hwmon_probe. I have something link the patch
> > below in mind.
> >
> > Best regards,
> > Alexander
> > ---
> > diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
> > index b550ba5..e32d150 100644
> > --- a/drivers/hwmon/iio_hwmon.c
> > +++ b/drivers/hwmon/iio_hwmon.c
> > @@ -73,8 +73,12 @@ static int iio_hwmon_probe(struct platform_device
> > *pdev)
> >
> > name = dev->of_node->name;
> >
> > channels = iio_channel_get_all(dev);
> >
> > - if (IS_ERR(channels))
> > - return PTR_ERR(channels);
> > + if (IS_ERR(channels)) {
> > + if (PTR_ERR(channels) == -ENODEV)
> > + return -EPROBE_DEFER;
> > + else
> > + return PTR_ERR(channels);
> > + }
> >
> > st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> > if (st == NULL) {
>
> Indeed, I misunderstood what you told me.
>
> Actually, the patch you proposed is part of my v1
> (https://lkml.org/lkml/2016/6/28/203) and v2
> (https://lkml.org/lkml/2016/7/15/215).
> Jonathan and Guenter didn't really like the idea of changing the -ENODEV
> in -EPROBE_DEFER.
Thanks for the links.
> What I thought you were proposing was to change the -ENODEV return code
> inside iio_channel_get_all. This cannot be an option since the function
> might be called outside of a probe (it is not yet, but might be in the
> future?).
AFAICS this is a helper function not knowing about device probing itself. And
it should stay at that.
> Of what I understood, two possibilities are then possible (proposed
> either by Guenter or Jonathan): either rework the iio framework to
> register iio map array earlier or to use late_initcall instead of init
> for the driver consuming the iio channels.
Interestingly using this problem would not arise due to module dependencies.
But using late_initcall would mean this needs to be done on any driver using
iio channels? I would rather keep those consumers simple.
Best regards,
Alexander
Re: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets
On Tue, Jul 26, 2016 at 07:09:41AM +, Dexuan Cui wrote: > If you meant https://lkml.org/lkml/2016/7/13/382, I don't think Michal > Kubecek was suggesting I build my code using the existing AF_VSOCK > code(?) I think he was only asking me to clarify the way I used to write > the text to explain why I can't fit my code into the existing AF_VSOCK > code. BTW, AF_VSOCK is not on S390, I think. Actually, I believe building on top of existing AF_VSOCK should be the first thought and only if this way shows unfeasible, one should consider a completely new implementation from scratch. After all, when VMware was upstreaming vsock, IIRC they had to work hard on making it a generic solution rather than a one purpose tool tailored for their specific use case. What I wanted to say in that mail was that I didn't find the reasoning very convincing. The only point that wasn't like "AF_VSOCK has many features we don't need" was the incompatible addressing scheme. The cover letter text didn't convince me it was given as much thought as it deserved. I felt - and it still feel - that the option of building on top of vsock wasn't considered seriously enough. I must also admit I'm a bit confused by your response to the issue of socket lookup performance. I always thought the main reason to use special hypervisor sockets instead of TCP/IP over virtual network devices was efficiency (to avoid the overhead of network protocol processing). The fact that traversing a linear linked list under a global mutex for each socket lookup is not an issue as opening a connection is going to be slow anyway surprised me therefore. But maybe it's fine as the typical use case is going to be small number of long running connections and traffic performance is going to make for the connection latency. Or there are other advantages, I don't know. But if that is the case, it would IMHO deserve to be explained. Michal Kubecek
Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs
Hi Thomas,
On 26/07/2016 11:00, Thomas Gleixner wrote:
> B1;2802;0cEric,
>
> On Mon, 25 Jul 2016, Auger Eric wrote:
>> On 20/07/2016 11:04, Thomas Gleixner wrote:
>>> On Tue, 19 Jul 2016, Eric Auger wrote:
+ if (ret) {
+ for (; i >= 0; i--) {
+ struct irq_data *d = irq_get_irq_data(virq + i);
+
+ msi_handle_doorbell_mappings(d, false);
+ }
+ irq_domain_free_irqs(virq, desc->nvec_used);
+ desc->irq = 0;
+ goto error;
>>>
>>> How is that supposed to work? You clear desc->irq and then you call
>>> ops->handle_error.
>>
>> if I don't clear the desc->irq I enter an infinite loop in
>> pci_enable_msix_range.
>>
>> This happens because msix_capability_init and pcie_enable_msix returns 1.
>> In msix_capability_init, at out_avail: we enumerate the msi_desc which have
>> a non zero irq, hence the returned value equal to 1.
>>
>> Currently the only handle_error ops I found, pci_msi_domain_handle_error
>> does not use irq field so works although questionable.
>
> The logic here is: If the allocation does not succeed for the requested number
> of interrupts, we tell the caller how many interrupts we were able to set up.
> So the caller can decide what to do.
>
> In your case you don't want to have a partial allocation, so instead of
> playing silly games with desc->irq you should add a flag which tells the PCI
> code that you are not interested in a partial allocation and that it should
> return an error code instead.
In that case can we consider we even succeeded in allocating 1 MSI? In case the
IOMMU mapping fails, the MSI transaction will never reach the target MSI frame
so it is not usable. So when you mean "partial" I understand we did not succeed
in allocating maxvec IRQs, correct? Here we succeeded in allocating 0 IRQ and
still
msi_capability_init returns 1.
msi_capability_init doc-comment says "a positive return value indicates the
number of
interrupts which could have been allocated."
I understand allocation success currently only depends on the fact virq was
allocated
and set to desc->irq. But with that IOMMU stuff doesn't the criteria changes?
> Something like PCI_DEV_FLAGS_MSI_NO_PARTIAL_ALLOC should do the trick.
>
>> As for the irq_domain_free_irqs I think I can remove it since handled later.
>
> Not only the free_irqs(). You should let the teardown function handle
> everything including your doorbell mapping teardown. It's nothing special and
> free_msi_irqs() at the end of msix_capability_init() will take care of it.
Yep I was forced to call free_irqs myself since free_msi_irqs was doing nothing
due the fact I resetted the irq field. Wrong thing loop ;-)
Thanks
Eric
>
> Thanks,
>
> tglx
>
Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110
On Tue, 26 Jul 2016, Fengguang Wu wrote: > --- a/drivers/net/ethernet/intel/e1000/e1000_main.c > +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c > @@ -3797,7 +3797,7 @@ static irqreturn_t e1000_intr(int irq, void *data) > hw->get_link_status = 1; > /* guard against interrupt when we're going down */ > if (!test_bit(__E1000_DOWN, &adapter->flags)) > - schedule_delayed_work(&adapter->watchdog_task, 1); > + mod_timer(&adapter->watchdog_timer, jiffies + 1); ROTFL
[PATCH v7 1/2] ACPI / button: Fix an issue that the platform triggered reliable events may not be delivered to the userspace
On most platforms, _LID returning value, lid open/close events are all
reliable, but there are exceptions. Some AML tables report wrong initial
lid state (Link 1), and some of them never report lid open state (Link 2).
The usage model on such buggy platforms is:
1. The initial lid state returned from _LID is not reliable;
2. The lid open event is not reliable;
3. The lid close event is always reliable, used by the platform firmware to
trigger OSPM power saving operations.
This usage model is not compliant to the Linux SW_LID model as the Linux
userspace is very strict to the reliability of the open events.
In order not to trigger issues on such buggy platforms, the ACPI button
driver currently implements a lid_init_state=open quirk to send additional
"open" event after resuming. However, this is still not sufficient because:
1. Some special usage models (e.x., the dark resume scenario) cannot be
supported by this mode.
2. If a "close" event is not used to trigger "suspend", then the subsequent
"close" events cannot be seen by the userspace.
So we need to stop sending the additional "open" event and switch the
driver to lid_init_state=ignore mode and make sure the platform triggered
events can be reliably delivered to the userspace. The userspace programs
then can be changed to not to be strict to the "open" events on such buggy
platforms.
Why will the subsequent "close" events be lost? This is because the input
layer automatically filters redundant events for switch events. Thus given
that the buggy AML tables do not guarantee paired "open"/"close" events,
the ACPI button driver currently is not able to guarantee that the platform
triggered reliable events can be always be seen by the userspace via
SW_LID.
This patch adds a mechanism to insert lid events as a compensation for the
platform triggered ones to form a complete event switches in order to make
sure that the platform triggered events can always be reliably delivered
to the userspace. This essentially guarantees that the platform triggered
reliable "close" events will always be relibly delivered to the userspace.
However this mechanism is not suitable for lid_init_state=open/method as
it should not send the complement switch event for the unreliable initial
lid state notification. 2 unreliable events can trigger unexpected
behavior. Thus this patch only implements this mechanism for
lid_init_state=ignore.
Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=89211
https://bugzilla.kernel.org/show_bug.cgi?id=106151
Link 2: https://bugzilla.kernel.org/show_bug.cgi?id=106941
Signed-off-by: Lv Zheng
Suggested-by: Dmitry Torokhov
Cc: Benjamin Tissoires
Cc: Bastien Nocera:
Cc: linux-in...@vger.kernel.org
---
drivers/acpi/button.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 148f4e5..dca1806 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -19,6 +19,8 @@
* ~~
*/
+#define pr_fmt(fmt) "ACPI : button: " fmt
+
#include
#include
#include
@@ -104,6 +106,8 @@ struct acpi_button {
struct input_dev *input;
char phys[32]; /* for input device */
unsigned long pushed;
+ int last_state;
+ unsigned long last_time;
bool suspended;
};
@@ -111,6 +115,10 @@ static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
static struct acpi_device *lid_device;
static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
+static unsigned long lid_report_interval __read_mostly = 500;
+module_param(lid_report_interval, ulong, 0644);
+MODULE_PARM_DESC(lid_report_interval, "Interval (ms) between lid key events");
+
/* --
FS Interface (/proc)
--
*/
@@ -135,9 +143,48 @@ static int acpi_lid_notify_state(struct acpi_device
*device, int state)
struct acpi_button *button = acpi_driver_data(device);
int ret;
- /* input layer checks if event is redundant */
+ if (button->last_state == !!state &&
+ time_after(jiffies, button->last_time +
+ msecs_to_jiffies(lid_report_interval))) {
+ /* Complain the buggy firmware */
+ pr_warn_once("The lid device is not compliant to SW_LID.\n");
+
+ /*
+* Send the unreliable complement switch event:
+*
+* On most platforms, the lid device is reliable. However
+* there are exceptions:
+* 1. Platforms returning initial lid state as "close" by
+*default after booting/resuming:
+* https://bugzilla.kernel.org/show_bug.cgi?id=89211
+* http
[PATCH v7 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
This patch adds documentation for the usage model of the control method lid device on some buggy platforms. Signed-off-by: Lv Zheng Acked-by: Benjamin Tissoires Cc: Dmitry Torokhov Cc: Bastien Nocera: Cc: linux-in...@vger.kernel.org --- Documentation/acpi/acpi-lid.txt | 97 +++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/acpi/acpi-lid.txt diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-lid.txt new file mode 100644 index 000..4dfdc9d --- /dev/null +++ b/Documentation/acpi/acpi-lid.txt @@ -0,0 +1,97 @@ +Special Usage Model of the ACPI Control Method Lid Device + +Copyright (C) 2016, Intel Corporation +Author: Lv Zheng + + +Abstract: + +Platforms containing lids convey lid state (open/close) to OSPMs using a +control method lid device. To implement this, the AML tables issue +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has +changed. The _LID control method for the lid device must be implemented to +report the "current" state of the lid as either "opened" or "closed". + +For most platforms, both the _LID method and the lid notifications are +reliable. However, there are exceptions. In order to work with these +exceptional buggy platforms, special restrictions and expections should be +taken into account. This document describes the restrictions and the +expections of the Linux ACPI lid device driver. + + +1. Restrictions of the returning value of the _LID control method + +The _LID control method is described to return the "current" lid state. +However the word of "current" has ambiguity, some buggy AML tables return +the lid state upon the last lid notification instead of returning the lid +state upon the last _LID evaluation. There won't be difference when the +_LID control method is evaluated during the runtime, the problem is its +initial returning value. When the AML tables implement this control method +with cached value, the initial returning value is likely not reliable. +There are platforms always retun "closed" as initial lid state. + +2. Restrictions of the lid state change notifications + +There are buggy AML tables never notifying when the lid device state is +changed to "opened". Thus the "opened" notification is not guaranteed. But +it is guaranteed that the AML tables always notify "closed" when the lid +state is changed to "closed". The "closed" notification is normally used to +trigger some system power saving operations on Windows. Since it is fully +tested, it is reliable from all AML tables. + +3. Expections for the userspace users of the ACPI lid device driver + +The ACPI button driver exports the lid state to the userspace via the +following file: + /proc/acpi/button/lid/LID0/state +This file actually calls the _LID control method described above. And given +the previous explanation, it is not reliable enough on some platforms. So +it is advised for the userspace program to not to solely rely on this file +to determine the actual lid state. + +The ACPI button driver emits the following input event to the userspace: + SW_LID +The ACPI lid device driver is implemented to try to deliver the platform +triggered events to the userspace. However, given the fact that the buggy +firmware cannot make sure "opened"/"closed" events are paired, the ACPI +button driver uses the following 3 modes in order not to trigger issues. + +If the userspace hasn't been prepared to ignore the unreliable "opened" +events and the unreliable initial state notification, Linux users can use +the following kernel parameters to handle the possible issues: +A. button.lid_init_state=method: + When this option is specified, the ACPI button driver reports the + initial lid state using the returning value of the _LID control method + and whether the "opened"/"closed" events are paired fully relies on the + firmware implementation. + This option can be used to fix some platforms where the returning value + of the _LID control method is reliable but the initial lid state + notification is missing. + This option is the default behavior during the period the userspace + isn't ready to handle the buggy AML tables. +B. button.lid_init_state=open: + When this option is specified, the ACPI button driver always reports the + initial lid state as "opened" and whether the "opened"/"closed" events + are paired fully relies on the firmware implementation. + This may fix some platforms where the returning value of the _LID + control method is not reliable and the initial lid state notification is + missing. + +If the userspace has been prepared to ignore the unreliable "opened" events +and the unreliable initial state notification, Linux users should always +use the following kernel parameter: +C. button.lid_init_state=ignore: + When this option is specified, the ACPI button driver never reports the + initial lid state and there is a compensation mechanism implemented to + ensure th
[PATCH] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY
From: Borislav Petkov
CONFIG_RANDOMIZE_MEMORY randomizes the physical memmap and thus the
address where the initrd is located. Therefore, we need to add the
offset KASLR put us to in order to find the initrd again on the AP path.
In the future, we will get rid of the initrd address caching and query
the address on both the BSP and AP paths but that would need more work.
Thanks to Nicolai Stange for the good bisection and debugging work.
Reported-and-tested-by: Nicolai Stange
Signed-off-by: Borislav Petkov
Cc: Kees Cook
---
arch/x86/kernel/cpu/microcode/intel.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index 6515c802346a..c5a7d74a9fa6 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -793,10 +793,10 @@ void __init load_ucode_intel_bsp(void)
void load_ucode_intel_ap(void)
{
struct ucode_blobs *blobs_p;
+ unsigned long *ptrs, start = 0;
struct mc_saved_data *mcs;
struct ucode_cpu_info uci;
enum ucode_state ret;
- unsigned long *ptrs;
#ifdef CONFIG_X86_32
mcs = (struct mc_saved_data *)__pa_nodebug(&mc_saved_data);
@@ -815,8 +815,20 @@ void load_ucode_intel_ap(void)
if (!mcs->num_saved)
return;
+ if (blobs_p->valid) {
+ start = blobs_p->start;
+
+#ifdef CONFIG_RANDOMIZE_MEMORY
+ /*
+* Pay attention to CONFIG_RANDOMIZE_MEMORY as it shuffles
+* physmem mapping too and there we have the initrd.
+*/
+ start += (PAGE_OFFSET - __PAGE_OFFSET_BASE);
+#endif
+ }
+
collect_cpu_info_early(&uci);
- ret = load_microcode(mcs, ptrs, blobs_p->start, &uci);
+ ret = load_microcode(mcs, ptrs, start, &uci);
if (ret != UCODE_OK)
return;
--
2.8.4
Re: bcache super block corruption with non 4k pages
On 21.07.2016 10:58, Stefan Bader wrote:
> I was pointed at the thread which seems to address the same after
> I wrote most of below text. Did not want to re-write this so please
> bear with the odd layout.
>
> https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html
>
> Zhengyuan tries to fix the problem by relocating the superblock on
> disk. But I am not sure whether there is really any guarantee about
> how __bread fills data into the buffer_head. What if there is the next
> odd arch with 128K pages?
>
> So below is an attempt to be more generic. Still I don't feel completely
> happy with the way that a page moves (or is shared) between buffer_head
> and biovec. What I tried to outline below is to let the register functions
> allocate bio+biovec memory and use the in-memory sb_cache data to initialize
> the biovec buffer.
Any opinions here? Also adding LKML as I don't seem to get through moderation on
dm-devel.
>
> -Stefan
>
>
> ---
>
> This was seen on ppc64le with 64k page size. The problem is that
> in that case __bread returns a page where b_data is not at the
> start of the page. And I am not really sure that the way bcache
> re-purposes the page returned by __bread to be used as biovec
> element is really a good idea.
>
> The way it is now, I saw __bread return a 64k page where b_data
> was starting at 4k offset. Then __write_super was modifying some
> data at offset 0 but for example not writing the magic number again.
>
> Not sure why (maybe this messes up flushes, too) but the bad data was not
> immediately written back when the devices were registered. So at that time
> bcache-super-show would report data as it was written by user-space (like
> the cache type still 0 and not 3, and claiming the cache to still bei
> detached).
>
> But when stopping the cache and unregistering the cache set this changed
> and bcache-super-show was reporting a bad magic number (as expected).
>
> The patch below works around this (tested with 64k and 4k pages) but I
> am not really sure this is a clean approach. My gut feeling would be that
> the bio structures should be allocated speperately (I think there is a way
> of allocating a bioset without using a pool). Then that separate page could
> be pre-initialized from the super block structure without passing around
> a page the feels more private to __bread usage...
>
> -Stefan
>
>
>
> From 3652e98359b876f3c1e6d7b9b7305e3411178296 Mon Sep 17 00:00:00 2001
> From: Stefan Bader
> Date: Wed, 20 Jul 2016 12:06:27 +0200
> Subject: [PATCH] bcache: handle non 4k pages returned by __bread
>
> On non-x86 arches pages can be bigger than 4k. Currently read_super
> returns a reference to the page used as buffer in the buffer_head
> that is returned by __bread().
> With 4k page size and a requested read this normally ends up with
> the super block data starting at offset 0. But as seen on ppc64le
> with 64k page size, the data can start at an offset (from what I
> saw the offset was 4k).
> This causes harm later on when __write_super() maps the super
> block data at the start of the page acquired before and also
> not writes back all fields (particularly the super block magic).
>
> Try to avoid this by also returning the potential offset within the
> sb_page from read_super() and fully initiallize the single bvec of
> the bio used for __write_super() calls. Doing that is the same as
> would have been done in bch_bio_map() which now must not be used in
> __write_super().
>
> Signed-off-by: Stefan Bader
>
> removedebug
>
> Signed-off-by: Stefan Bader
> ---
> drivers/md/bcache/super.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index e169739..3e0d2de 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -62,7 +62,7 @@ struct workqueue_struct *bcache_wq;
> /* Superblock */
>
> static const char *read_super(struct cache_sb *sb, struct block_device *bdev,
> - struct page **res)
> + struct page **res, unsigned int *off)
> {
> const char *err;
> struct cache_sb *s;
> @@ -192,6 +192,7 @@ static const char *read_super(struct cache_sb *sb, struct
> block_device *bdev,
> err = NULL;
>
> get_page(bh->b_page);
> + *off = (unsigned int) (bh->b_data - ((char *)
> page_address(bh->b_page)));
> *res = bh->b_page;
> err:
> put_bh(bh);
> @@ -202,19 +203,19 @@ static void write_bdev_super_endio(struct bio *bio)
> {
> struct cached_dev *dc = bio->bi_private;
> /* XXX: error checking */
> -
> closure_put(&dc->sb_write);
> }
>
> static void __write_super(struct cache_sb *sb, struct bio *bio)
> {
> - struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page);
> + struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page) +
> +bio->bi_io_vec[0].bv_offset;
>
Re: [PATCH 1/3] drm: introduce share plane
On 2016年07月26日 16:26, Daniel Vetter wrote: On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote: >What is share plane: >Plane hardware only be used when the display scanout run into plane active >scanout, that means we can reuse the plane hardware resources on plane >non-active scanout. > > -- > | scanout | > | -- | > | | parent plane | | > | | active scanout | | > | || - | > | -- | share plane 1 | | > | - |active scanout | | > | | share plane 0 | | | | > | |active scanout | - | > | | | | > | - | > -- >One plane hardware can be reuse for multi-planes, we assume the first >plane is parent plane, other planes share the resource with first one. > parent plane > |---share plane 0 > |---share plane 1 > ... > >Because resource share, There are some limit on share plane: one group >of share planes need use same zpos, can not overlap, etc. > >We assume share plane is a universal plane with some limit flags. >people who use the share plane need know the limit, should call the ioctl >DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it. > >A group of share planes would has same shard id, so userspace can >group them, judge share plane's limit. > >Signed-off-by: Mark Yao This seems extremely hw specific, why exactly do we need to add a new relationship on planes? What does this buy on_other_ drivers? Yes, now it's plane hardware specific, maybe others have same design, because this design would save hardware resource to support multi-planes. Imo this should be solved by virtualizing planes in the driver. Start out by assigning planes, and if you can reuse one for sharing then do that, otherwise allocate a new one. If there's not enough real planes, fail the atomic_check. I think that is too complex, trying with atomic_check I think it's not a good idea, userspace try planes every commit would be a heavy work. Userspace need know all planes relationship, group them, some display windows can put together, some can't, too many permutation and combination, I think can't just commit with try. example: userspace: windows 1: pos(0, 0) size(1024, 100) windows 2: pos(0, 50) size(400, 500) windows 3: pos(0, 200) size(800, 300) drm plane resources: plane 0 and plane 1 is a group of share planes plane 2 is common plane. if userspace know the relationship, then they can assign windows 1 and window 3 to plane0 and plane 1. that would be success. but if they don't know, assign window 1/2 to plane 0/1, failed, assign window 2/3 to plane 0/1, failed. mostly would get failed. This seems way to hw specific to be useful as a generic concept. We want to change the drm_mode_getplane_res behavior, if userspace call DRM_CLIENT_CAP_SHARE_PLANES, that means userspace know hardware limit, then we return full planes support to userspace, if don't, just make a group of share planes as one plane. this work is on generic place. -Daniel -- Ｍark Yao
Re: [PATCH V3 3/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP
On 19/07/16 10:17, Joseph Lo wrote: > The BPMP is a specific processor in Tegra chip, which is designed for > booting process handling and offloading the power management, clock > management, and reset control tasks from the CPU. The binding document > defines the resources that would be used by the BPMP firmware driver, > which can create the interprocessor communication (IPC) between the CPU > and BPMP. > > Signed-off-by: Joseph Lo > --- > Changes in V3: > - s/mmio-ram/mmio-sram/ > - revise the file path of the reference binding documents and header files > for more generic viem in different SW projects > Changes in V2: > - update the message that the BPMP is clock and reset control provider > - add tegra186-clock.h and tegra186-reset.h header files > - revise the description of the required properties > --- > .../bindings/firmware/nvidia,tegra186-bpmp.txt | 77 ++ > include/dt-bindings/clock/tegra186-clock.h | 940 > + > include/dt-bindings/reset/tegra186-reset.h | 217 + > 3 files changed, 1234 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt > create mode 100644 include/dt-bindings/clock/tegra186-clock.h > create mode 100644 include/dt-bindings/reset/tegra186-reset.h Acked-by: Jon Hunter Cheers Jon -- nvpublic
Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
On 25/07/16 18:13, Catalin Marinas wrote: On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote: On 07/22/2016 06:16 AM, Catalin Marinas wrote: On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote: [...] The document states: "Up to MAX_STACK_SIZE bytes are copied". That means the arch code could always copy less but never more than MAX_STACK_SIZE. What we are proposing is that we should try to guess how much to copy based on the FP value (caller's frame) and, if larger than MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes against the kprobes.txt document but at least it (a) may improve the performance slightly by avoiding unnecessary copy and (b) it avoids undefined behaviour if we ever encounter a jprobe with arguments passed on the stack beyond MAX_STACK_SIZE. OK, it sounds like an improvement. I do worry a little about unexpected side effects. You get more unexpected side effects by not saving/restoring the whole stack. We looked into this on Friday and came to the conclusion that there is no safe way for kprobes to know which arguments passed on the stack should be preserved, at least not with the current API. Basically the AArch64 PCS states that for arguments passed on the stack (e.g. they can't fit in registers), the caller allocates memory for them (on its own stack) and passes the pointer to the callee. Unfortunately, the frame pointer seems to be decremented correspondingly to cover the arguments, so we don't really have a way to tell how much to copy. Copying just the caller's stack frame isn't safe either since a callee/caller receiving such argument on the stack may passed it down to a callee without copying (I couldn't find anything in the PCS stating that this isn't allowed). The PCS[1] seems (at least to me) to be pretty clear that "the address of the first stacked argument is defined to be the initial value of SP". I think it is only the return value (when stacked via the x8 pointer) that can be passed through an intermediate function in the way described above. Isn't it OK for a jprobe to clobber this memory? The underlying function will overwrite whatever the jprobe put there anyway. Am I overlooking some additional detail in the PCS? Daniel. [1] Google presented me revision IHI 0055B (via infocenter.arm.com)
Re: [PATCH] schedule function called for e1000 driver interrupt
Hi,
[auto build test ERROR on jkirsher-next-queue/dev-queue]
[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/Fengguang-Wu/schedule-function-called-for-e1000-driver-interrupt/20160726-173521
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
dev-queue
config: x86_64-randconfig-x011-201630 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/intel/e1000/e1000_main.c: In function 'e1000_intr':
>> drivers/net/ethernet/intel/e1000/e1000_main.c:3800:22: error: 'struct
>> e1000_adapter' has no member named 'watchdog_timer'; did you mean
>> 'watchdog_task'?
mod_timer(&adapter->watchdog_timer, jiffies + 1);
^~
vim +3800 drivers/net/ethernet/intel/e1000/e1000_main.c
3794 return IRQ_HANDLED;
3795
3796 if (unlikely(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))) {
3797 hw->get_link_status = 1;
3798 /* guard against interrupt when we're going down */
3799 if (!test_bit(__E1000_DOWN, &adapter->flags))
> 3800 mod_timer(&adapter->watchdog_timer, jiffies +
> 1);
3801 }
3802
3803 /* disable interrupts, without the synchronize_irq bit */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH] schedule function called for e1000 driver interrupt
Hi,
[auto build test ERROR on jkirsher-next-queue/dev-queue]
[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/Fengguang-Wu/schedule-function-called-for-e1000-driver-interrupt/20160726-173521
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
dev-queue
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
drivers/net/ethernet/intel/e1000/e1000_main.c: In function 'e1000_intr':
>> drivers/net/ethernet/intel/e1000/e1000_main.c:3800:22: error: 'struct
>> e1000_adapter' has no member named 'watchdog_timer'
mod_timer(&adapter->watchdog_timer, jiffies + 1);
^
vim +3800 drivers/net/ethernet/intel/e1000/e1000_main.c
3794 return IRQ_HANDLED;
3795
3796 if (unlikely(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))) {
3797 hw->get_link_status = 1;
3798 /* guard against interrupt when we're going down */
3799 if (!test_bit(__E1000_DOWN, &adapter->flags))
> 3800 mod_timer(&adapter->watchdog_timer, jiffies +
> 1);
3801 }
3802
3803 /* disable interrupts, without the synchronize_irq bit */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox
On 19/07/16 10:17, Joseph Lo wrote:
> Add DT binding for the Hardware Synchronization Primitives (HSP). The
> HSP is designed for the processors to share resources and communicate
> together. It provides a set of hardware synchronization primitives for
> interprocessor communication. So the interprocessor communication (IPC)
> protocols can use hardware synchronization primitive, when operating
> between two processors not in an SMP relationship.
>
> Signed-off-by: Joseph Lo
> ---
> Sorry. Please allow me just update the binding patches of this series.
> Want to make sure the binding is acceptable first.
> Thanks.
>
> Changes in V3:
> - use two cells for mboxes property
> Changes in V2:
> - revise the compatible string, interrupt-names, interrupts, and #mbox-cells
> properties
> - remove "nvidia,hsp-function" property
> - fix the header file name
> - the binding supports the concept of multiple HSP sub-modules on one HSP HW
> block now.
> ---
> .../bindings/mailbox/nvidia,tegra186-hsp.txt | 52
> ++
> include/dt-bindings/mailbox/tegra186-hsp.h | 20 +
> 2 files changed, 72 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
> create mode 100644 include/dt-bindings/mailbox/tegra186-hsp.h
>
> diff --git
> a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
> b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
> new file mode 100644
> index ..a9152380642d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
> @@ -0,0 +1,52 @@
> +NVIDIA Tegra Hardware Synchronization Primitives (HSP)
> +
> +The HSP modules are used for the processors to share resources and
> communicate
> +together. It provides a set of hardware synchronization primitives for
> +interprocessor communication. So the interprocessor communication (IPC)
> +protocols can use hardware synchronization primitives, when operating between
> +two processors not in an SMP relationship.
> +
> +The features that HSP supported are shared mailboxes, shared semaphores,
> +arbitrated semaphores and doorbells.
> +
> +Required properties:
> +- name : Should be hsp
> +- compatible
> +Array of strings.
> +one of:
> +- "nvidia,tegra186-hsp"
> +- reg : Offset and length of the register set for the device.
> +- interrupt-names
> +Array of strings.
> +Contains a list of names for the interrupts described by the interrupt
> +property. May contain the following entries, in any order:
> +- "doorbell"
> +Users of this binding MUST look up entries in the interrupt property
> +by name, using this interrupt-names property to do so.
> +- interrupts
> +Array of interrupt specifiers.
> +Must contain one entry per entry in the interrupt-names property,
> +in a matching order.
> +- #mbox-cells : Should be 2.
> +
> +The mbox specifier of the "mboxes" property in the client node should
> +contain two data. The first one should be the HSP type and the second
> +one should be the ID that the client is going to use. Those information
> +can be found in the following file.
> +
> +- .
> +
> +Example:
> +
> +hsp_top0: hsp@3c0 {
> + compatible = "nvidia,tegra186-hsp";
> + reg = <0x0 0x03c0 0x0 0xa>;
> + interrupts = ;
> + interrupt-names = "doorbell";
> + #mbox-cells = <2>;
> +};
> +
> +client {
> + ...
> + mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_XXX>;
> +};
> diff --git a/include/dt-bindings/mailbox/tegra186-hsp.h
> b/include/dt-bindings/mailbox/tegra186-hsp.h
> new file mode 100644
> index ..d1c1432707cd
> --- /dev/null
> +++ b/include/dt-bindings/mailbox/tegra186-hsp.h
> @@ -0,0 +1,20 @@
> +/*
> + * This header provides constants for binding nvidia,tegra186-hsp.
> + *
> + * The number with HSP_DB_MASTER prefix indicates the bit that is
> + * associated with a master ID in the doorbell registers.
> + */
> +
> +
> +#ifndef _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
> +#define _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
> +
> +#define HSP_MBOX_TYPE_DB 0x0
> +#define HSP_MBOX_TYPE_SM 0x1
> +#define HSP_MBOX_TYPE_SS 0x2
> +#define HSP_MBOX_TYPE_AS 0x3
Nit ... may be we should add a comment that describes what the above are?
> +
> +#define HSP_DB_MASTER_CCPLEX 17
> +#define HSP_DB_MASTER_BPMP 19
Nit ... I would be tempted to move the comment in the header to above
these defines, as I missed it on my first pass of this.
Otherwise ...
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
[PATCH] binfmt_em86: Fix incompatible pointer type
From: Daniel Wagner
Since the -Wincompatible-pointer-types is reported as error, alpha
doesn't build anymore. Let's fix it in a minimal way.
fs/binfmt_em86.c:73:35: error: passing argument 2 of ‘copy_strings_kernel’ from
incompatible pointer type [-Werror=incompatible-pointer-types]
retval = copy_strings_kernel(1, &i_arg, bprm);
^^
fs/binfmt_em86.c:77:34: error: passing argument 2 of ‘copy_strings_kernel’ from
incompatible pointer type [-Werror=incompatible-pointer-types]
retval = copy_strings_kernel(1, &i_name, bprm);
^
Signed-off-by: Daniel Wagner
---
Hi,
Here is the same patch again. The 0day bot is nagging me that
I broke that and up to now it's still not fixed.
Andrew, are you willing to pick this one up?
cheers,
daniel
fs/binfmt_em86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/binfmt_em86.c b/fs/binfmt_em86.c
index 4905385..dd2d3f0 100644
--- a/fs/binfmt_em86.c
+++ b/fs/binfmt_em86.c
@@ -24,7 +24,8 @@
static int load_em86(struct linux_binprm *bprm)
{
- char *interp, *i_name, *i_arg;
+ const char *i_name, *i_arg;
+ char *interp;
struct file * file;
int retval;
struct elfhdr elf_ex;
--
2.5.5
