Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.
2016-04-29 1:18 GMT+03:00 Richard W.M. Jones : > [This is an opinionated patch, mainly for discussion.] > > I'm trying to reduce the time taken in the kernel in initcalls, with > my aim being to reduce the current ~700ms spent in initcalls before > userspace, down to something like 100ms. All times on my Broadwell-U > laptop, under virtualization. The purpose of this is to be able to > launch VMs around containers with minimal overhead, like Intel Clear > Containers, but using standard distro kernels and qemu. > > Currently the kernel spends 25ms inspecting the UART that we passed to > it from qemu to find out whether it's an 8250/16550/16550A perhaps > with a non-working FIFO or other quirks. Well, it isn't -- it's a > working emulated 16550A, with a FIFO and no quirks, and if it isn't, > we should fix qemu. > > So the patch detects if we're running virtualized (perhaps it should > only check for qemu/KVM?) and if so, shortcuts the tests. Does anybody know, whether it is possible to pass through real hardware serial port to a guest? It seems to be as simple as to pass through an interrupt and memory IO ports. > > Rich. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: [PATCH v2 2/6] mm/cma: introduce new zone, ZONE_CMA
On Tue, Apr 26, 2016 at 05:38:18PM +0800, Rui Teng wrote: > On 4/25/16 1:21 PM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >Attached cover-letter: > > > >This series try to solve problems of current CMA implementation. > > > >CMA is introduced to provide physically contiguous pages at runtime > >without exclusive reserved memory area. But, current implementation > >works like as previous reserved memory approach, because freepages > >on CMA region are used only if there is no movable freepage. In other > >words, freepages on CMA region are only used as fallback. In that > >situation where freepages on CMA region are used as fallback, kswapd > >would be woken up easily since there is no unmovable and reclaimable > >freepage, too. If kswapd starts to reclaim memory, fallback allocation > >to MIGRATE_CMA doesn't occur any more since movable freepages are > >already refilled by kswapd and then most of freepage on CMA are left > >to be in free. This situation looks like exclusive reserved memory case. > > > >In my experiment, I found that if system memory has 1024 MB memory and > >512 MB is reserved for CMA, kswapd is mostly woken up when roughly 512 MB > >free memory is left. Detailed reason is that for keeping enough free > >memory for unmovable and reclaimable allocation, kswapd uses below > >equation when calculating free memory and it easily go under the watermark. > > > >Free memory for unmovable and reclaimable = Free total - Free CMA pages > > > >This is derivated from the property of CMA freepage that CMA freepage > >can't be used for unmovable and reclaimable allocation. > > > >Anyway, in this case, kswapd are woken up when (FreeTotal - FreeCMA) > >is lower than low watermark and tries to make free memory until > >(FreeTotal - FreeCMA) is higher than high watermark. That results > >in that FreeTotal is moving around 512MB boundary consistently. It > >then means that we can't utilize full memory capacity. > > > >To fix this problem, I submitted some patches [1] about 10 months ago, > >but, found some more problems to be fixed before solving this problem. > >It requires many hooks in allocator hotpath so some developers doesn't > >like it. Instead, some of them suggest different approach [2] to fix > >all the problems related to CMA, that is, introducing a new zone to deal > >with free CMA pages. I agree that it is the best way to go so implement > >here. Although properties of ZONE_MOVABLE and ZONE_CMA is similar, I > >decide to add a new zone rather than piggyback on ZONE_MOVABLE since > >they have some differences. First, reserved CMA pages should not be > >offlined. If freepage for CMA is managed by ZONE_MOVABLE, we need to keep > >MIGRATE_CMA migratetype and insert many hooks on memory hotplug code > >to distiguish hotpluggable memory and reserved memory for CMA in the same > >zone. It would make memory hotplug code which is already complicated > >more complicated. Second, cma_alloc() can be called more frequently > >than memory hotplug operation and possibly we need to control > >allocation rate of ZONE_CMA to optimize latency in the future. > >In this case, separate zone approach is easy to modify. Third, I'd > >like to see statistics for CMA, separately. Sometimes, we need to debug > >why cma_alloc() is failed and separate statistics would be more helpful > >in this situtaion. > > > >Anyway, this patchset solves four problems related to CMA implementation. > > > >1) Utilization problem > >As mentioned above, we can't utilize full memory capacity due to the > >limitation of CMA freepage and fallback policy. This patchset implements > >a new zone for CMA and uses it for GFP_HIGHUSER_MOVABLE request. This > >typed allocation is used for page cache and anonymous pages which > >occupies most of memory usage in normal case so we can utilize full > >memory capacity. Below is the experiment result about this problem. > > > >8 CPUs, 1024 MB, VIRTUAL MACHINE > >make -j16 > > > > > >CMA reserve:0 MB512 MB > >Elapsed-time: 92.4 186.5 > >pswpin: 82 18647 > >pswpout:160 69839 > > > > > >CMA reserve:0 MB512 MB > >Elapsed-time: 93.1 93.4 > >pswpin: 84 46 > >pswpout:183 92 > > > >FYI, there is another attempt [3] trying to solve this problem in lkml. > >And, as far as I know, Qualcomm also has out-of-tree solution for this > >problem. > > > >2) Reclaim problem > >Currently, there is no logic to distinguish CMA pages in reclaim path. > >If reclaim is initiated for unmovable and reclaimable allocation, > >reclaiming CMA pages doesn't help to satisfy the request and reclaiming > >CMA page is just waste. By managing CMA pages in the new zone, we can > >skip to reclaim ZONE_CMA completely if it is unnecessary. > > > >3) Atomic allocation failure problem > >Kswapd isn't started to reclaim pages when allocation request is movab
Re: [BUG] vfio device assignment regression with THP ref counting redesign
On Thu, Apr 28, 2016 at 08:45:42PM -0600, Alex Williamson wrote:
> On Fri, 29 Apr 2016 03:51:06 +0300
> "Kirill A. Shutemov" wrote:
>
> > On Fri, Apr 29, 2016 at 01:21:27AM +0200, Andrea Arcangeli wrote:
> > > Hello Alex and Kirill,
> > >
> > > On Thu, Apr 28, 2016 at 12:58:08PM -0600, Alex Williamson wrote:
> > > > > > specific fix to this code is not applicable. It also still occurs
> > > > > > on
> > > > > > kernels as recent as v4.6-rc5, so the issue hasn't been silently
> > > > > > fixed
> > > > > > yet. I'm able to reproduce this fairly quickly with the above test,
> > > > > > but it's not hard to imagine a test w/o any iommu dependencies which
> > > > > > simply does a user directed get_user_pages_fast() on a set of
> > > > > > userspace
> > > > > > addresses, retains the reference, and at some point later rechecks
> > > > > > that
> > > > > > a new get_user_pages_fast() results in the same page address. It
> > >
> > > Can you try to "git revert 1f25fe20a76af0d960172fb104d4b13697cafa84"
> > > and then apply the below patch on top of the revert?
> > >
> > > Totally untested... if I missed something and it isn't correct, I hope
> > > this brings us in the right direction faster at least.
> > >
> > > Overall the problem I think is that we need to restore full accuracy
> > > and we can't deal with false positive COWs (which aren't entirely
> > > cheap either... reading 512 cachelines should be much faster than
> > > copying 2MB and using 4MB of CPU cache). 32k vs 4MB. The problem of
> > > course is when we really need a COW, we'll waste an additional 32k,
> > > but then it doesn't matter that much as we'd be forced to load 4MB of
> > > cache anyway in such case. There's room for optimizations but even the
> > > simple below patch would be ok for now.
> > >
> > > From 09e3d1ff10b49fb9c3ab77f0b96a862848e30067 Mon Sep 17 00:00:00 2001
> > > From: Andrea Arcangeli
> > > Date: Fri, 29 Apr 2016 01:05:06 +0200
> > > Subject: [PATCH 1/1] mm: thp: calculate page_mapcount() correctly for THP
> > > pages
> > >
> > > This allows to revert commit 1f25fe20a76af0d960172fb104d4b13697cafa84
> > > and it provides fully accuracy with wrprotect faults so page pinning
> > > will stop causing false positive copy-on-writes.
> > >
> > > Signed-off-by: Andrea Arcangeli
> > > ---
> > > mm/util.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/util.c b/mm/util.c
> > > index 6cc81e7..a0b9f63 100644
> > > --- a/mm/util.c
> > > +++ b/mm/util.c
> > > @@ -383,9 +383,10 @@ struct address_space *page_mapping(struct page *page)
> > > /* Slow path of page_mapcount() for compound pages */
> > > int __page_mapcount(struct page *page)
> > > {
> > > - int ret;
> > > + int ret = 0, i;
> > >
> > > - ret = atomic_read(&page->_mapcount) + 1;
> > > + for (i = 0; i < HPAGE_PMD_NR; i++)
> > > + ret = max(ret, atomic_read(&page->_mapcount) + 1);
> > > page = compound_head(page);
> > > ret += atomic_read(compound_mapcount_ptr(page)) + 1;
> > > if (PageDoubleMap(page))
> >
> > You are right about the cause. I spend some time on wrong path: I was only
> > able to trigger the bug with numa balancing enabled, so I assumed
> > something is wrong in that code...
> >
> > I would like to preserve current page_mapcount() behaviouts.
> > I think this fix is better:
>
> This also seems to work in my testing, but assuming all else being
> equal, there is a performance difference between the two for this test
> case in favor of Andrea's solution. Modifying the test to exit after
> the first set of iterations, my system takes on average 107s to complete
> with the solution below or 103.5s with the other approach. Please note
> that I have every mm debugging option I could find enabled and THP
> scanning full speed on the system, so I don't know how this would play
> out in a more tuned configuration.
>
> The only reason I noticed is that I added a side test to sleep a random
> number of seconds and kill the test program because sometimes killing
> the test triggers errors. I didn't see any errors with either of these
> solutions, but suspected the first solution was completing more
> iterations for similar intervals. Modifying the test to exit seems to
> prove that true.
>
> I can't speak to which is the more architecturally correct solution,
> but there may be a measurable performance difference to consider.
Hm. I just woke up and haven't got any coffee yet, but I don't why my
approach would be worse for performance. Both have the same algorithmic
complexity.
> Thanks,
>
> Alex
>
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 86f9f8b82f8e..163c10f48e1b 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1298,15 +1298,9 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct
> > vm_area_struct *vma,
> > VM_BUG_ON_PAGE(!PageCompound(page) || !PageHead(page), page);
> > /*
> > * We can only reuse the page i
[PATCH] net/smscx5xx: use the device tree for mac address
From: Arnd Bergmann
This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.
The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores
the MAC address in ROM accessible via VC4 firmware.
The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.
[lkund...@v3.sk: updated to use of_get_property() as per suggestion from
Arnd, reworded the message and comments a bit]
Tested-by: Lubomir Rintel
Signed-off-by: Arnd Bergmann
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- Prefer DT address to EEPROM address. No practical difference since
the devices are not supposed to have both, but aligned with existing
practice (ixgbe, dm9000).
Changes since v1:
- Made use of_get_property()
- Amended comments/commit message a bit
drivers/net/usb/smsc75xx.c | 12 +++-
drivers/net/usb/smsc95xx.c | 12 +++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 30033db..c369db9 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc75xx.h"
#define SMSC_CHIPNAME "smsc75xx"
@@ -761,6 +762,15 @@ static int smsc75xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc75xx_init_mac_address(struct usbnet *dev)
{
+ const u8 *mac_addr;
+
+ /* maybe the boot loader passed the MAC address in devicetree */
+ mac_addr = of_get_mac_address(dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+ return;
+ }
+
/* try reading mac address from EEPROM */
if (smsc75xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -772,7 +782,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
}
}
- /* no eeprom, or eeprom values are invalid. generate random MAC */
+ /* no useful static MAC address found. generate a random one */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
}
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 66b3ab9..2edc2bc 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc95xx.h"
#define SMSC_CHIPNAME "smsc95xx"
@@ -765,6 +766,15 @@ static int smsc95xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+ const u8 *mac_addr;
+
+ /* maybe the boot loader passed the MAC address in devicetree */
+ mac_addr = of_get_mac_address(dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+ return;
+ }
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -775,7 +785,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
}
}
- /* no eeprom, or eeprom values are invalid. generate random MAC */
+ /* no useful static MAC address found. generate a random one */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
}
--
2.7.4
[GIT PULL] MMC fixes for v.4.6 rc6
Hi Linus, Here are a two mmc fixes intended for v4.6 rc6. It's based on v4.6 rc4. Details are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9: Linux 4.6-rc4 (2016-04-17 19:13:32 -0700) are available in the git repository at: git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.6-rc4 for you to fetch changes up to 2963070a0f8184fe40be11927344e3fcc7e18e7c: mmc: sunxi: Disable eMMC HS-DDR (MMC_CAP_1_8V_DDR) for Allwinner A80 (2016-04-28 11:43:54 +0200) MMC host: - sdhci-acpi: Reduce Baytrail eMMC/SD/SDIO hangs - sunxi: Disable eMMC HS-DDR for Allwinner A80 Adrian Hunter (1): mmc: sdhci-acpi: Reduce Baytrail eMMC/SD/SDIO hangs Chen-Yu Tsai (1): mmc: sunxi: Disable eMMC HS-DDR (MMC_CAP_1_8V_DDR) for Allwinner A80 drivers/mmc/host/Kconfig | 1 + drivers/mmc/host/sdhci-acpi.c | 81 +++ drivers/mmc/host/sunxi-mmc.c | 5 +++ 3 files changed, 87 insertions(+)
linux-next: Tree for Apr 29
Hi all, Changes since 20160428: The arm64 tree gained a conflict against Linus' tree. The pm tree gained a conflict against the arm-soc tree. The tpmdd tree still had its build failure for which I added a fix patch. The tip tree gained a conflict against the arm64 tree. The xen-tip tree gained a conflict against the tip tree. The akpm-current tree gained conflicts against the tile and tip trees and I reverted a commit that produced many new warnings. Non-merge commits (relative to Linus' tree): 6770 6109 files changed, 255051 insertions(+), 125899 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 234 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (b75a2bf899b6 Merge branch 'for-4.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging fixes/master (9735a22799b9 Linux 4.6-rc2) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (1b10cb21d888 ARC: add support for reserved memory defined by device tree) Merging arm-current/fixes (ac36a881b72a ARM: 8564/1: fix cpu feature extracting helper) Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs for v4.6-rc2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (d701cca6744f powerpc: wire up preadv2 and pwritev2 syscalls) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (49fa5230462f sparc64: Fix bootup regressions on some Kconfig combinations.) Merging net/master (1dfcd832b1a9 Merge branch 'bpf-fixes') Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.) Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup with identical name) Merging wireless-drivers/master (e2841ea91611 Merge tag 'iwlwifi-for-kalle-2016-04-12_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if dev_alloc_name() fails) Merging sound-current/for-linus (af9cc93c0dee Merge tag 'asoc-fix-v4.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read both VPD structures) Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4) Merging tty.current/tty-linus (02da2d72174c Linux 4.6-rc5) Merging usb.current/usb-linus (97b9b7dc7722 usb: musb: jz4740: fix error check of usb_get_phy()) Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix use-after-free) Merging usb-serial-fixes/usb-linus (613ac23a46e1 USB: serial: cp210x: add Straizona Focusers device ids) Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable) Merging staging.current/staging-linus (431adc0aeca6 Merge tag 'iio-fixes-for-4.6c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (82dc4afd7e65 misc: mic: Fix for double fetch security bug in VOP driver) Merging input-current/for-linus (eb43335c4095 Input: atmel_mxt_ts - use mxt_acquire_irq in mxt_soft_reset) Merging crypto-current/master (9e209fcfb804 crypto: qat - fix invalid pf2vf_resp_wq logic) Merging
v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi! > On n900, probe finishes ok (verified by adding printks), and the > device shows up in /sys, but I don't get /dev/video* or > /dev/v4l-subdev*. > > Other drivers (back and front camera) load ok, and actually work. Any > idea what could be wrong? Ok, so I guess I realized what is the problem: adp1653 registers itself as a subdev, but there's no device that register it as its part. (ad5820 driver seems to have the same problem). Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking
> Yes, obviously... I'll make that change locally and wait for the rest. Another nit: You could use '--strict' with checkpatch and see if you want to fix the issues reported. I am not keen on those (except for 'space around operators'), it's a matter of taste I guess, but maybe you like some of the suggestions. Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCH v4] mm: SLAB freelist randomization
On Wed, Apr 27, 2016 at 10:39:29AM -0500, Christoph Lameter wrote: > On Tue, 26 Apr 2016, Andrew Morton wrote: > > > : CONFIG_FREELIST_RANDOM bugs me a bit - "freelist" is so vague. > > : CONFIG_SLAB_FREELIST_RANDOM would be better. I mean, what Kconfig > > : identifier could be used for implementing randomisation in > > : slub/slob/etc once CONFIG_FREELIST_RANDOM is used up? > > > > but this pearl appeared to pass unnoticed. > > Ok. lets add SLAB here and then use this option for the other allocators > as well. > > > > + /* If it fails, we will just use the global lists */ > > > + cachep->random_seq = kcalloc(count, sizeof(freelist_idx_t), GFP_KERNEL); > > > + if (!cachep->random_seq) > > > + return -ENOMEM; > > > > OK, no BUG. If this happens, kmem_cache_init_late() will go BUG > > instead ;) > > > > Questions for slab maintainers: > > > > What's going on with the gfp_flags in there? kmem_cache_init_late() > > passes GFP_NOWAIT into enable_cpucache(). > > > > a) why the heck does it do that? It's __init code! > > enable_cpucache() was called when a slab cache was reconfigured by writing to > /proc/slabinfo. > That was changed awhile back when the memcg changes were made ot slab. So > now its ok to be made init code. > > > Finally, all callers of enable_cpucache() (and hence of > > cache_random_seq_create()) are __init, so we're unnecessarily bloating > > up vmlinux. Could someone please take a look at this as a separate > > thing? > > Hmmm. Well if that is the case then lots of stuff could be straightened > out. Joonsoo? > As I mentioned in other thread, enable_cpucache() can be called whenever kmem_cache is created. It should not be __init. Thanks.
Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer
* Kees Cook wrote:
> From: Yinghai Lu
>
> This change makes later calculations about where the kernel is located
> easier to reason about. To better understand this change, we must first
> clarify what VO and ZO are. They were introduced in commits by hpa:
>
> 77d1a49 x86, boot: make symbols from the main vmlinux available
> 37ba7ab x86, boot: make kernel_alignment adjustable; new bzImage fields
>
> Specifically:
>
> VO:
> - uncompressed kernel image
> - size: VO__end - VO__text ("VO_INIT_SIZE" define)
>
> ZO:
> - bootable compressed kernel image (boot/compressed/vmlinux)
> - head text + compressed kernel (VO and relocs table) + decompressor code
> - size: ZO__end - ZO_startup_32 ("ZO_INIT_SIZE" define, though see below)
>
> The INIT_SIZE definition is used to find the larger of the two image sizes:
>
> #define ZO_INIT_SIZE(ZO__end - ZO_startup_32 + ZO_z_extract_offset)
> #define VO_INIT_SIZE(VO__end - VO__text)
> #if ZO_INIT_SIZE > VO_INIT_SIZE
> #define INIT_SIZE ZO_INIT_SIZE
> #else
> #define INIT_SIZE VO_INIT_SIZE
> #endif
>
> The current code uses extract_offset to decide where to position the
> copied ZO (i.e. ZO starts at extract_offset). (This is why ZO_INIT_SIZE
> currently includes the extract_offset.)
Yeah, so I rewrote the above to:
=>
This change makes later calculations about where the kernel is located
easier to reason about. To better understand this change, we must first
clarify what 'VO' and 'ZO' are. These values were introduced in commits
by hpa:
77d1a4999502 ("x86, boot: make symbols from the main vmlinux available")
37ba7ab5e33c ("x86, boot: make kernel_alignment adjustable; new bzImage
fields")
Specifically:
All names prefixed with 'VO_':
- relate to the uncompressed kernel image
- the size of the VO image is: VO__end-VO__text ("VO_INIT_SIZE" define)
All names prefixed with 'ZO_':
- relate to the bootable compressed kernel image (boot/compressed/vmlinux),
which is composed of the following memory areas:
- head text
- compressed kernel (VO image and relocs table)
- decompressor code
- the size of the ZO image is: ZO__end - ZO_startup_32 ("ZO_INIT_SIZE" define,
though see below)
The 'INIT_SIZE' value is used to find the larger of the two image sizes:
#define ZO_INIT_SIZE(ZO__end - ZO_startup_32 + ZO_z_extract_offset)
#define VO_INIT_SIZE(VO__end - VO__text)
#if ZO_INIT_SIZE > VO_INIT_SIZE
# define INIT_SIZE ZO_INIT_SIZE
#else
# define INIT_SIZE VO_INIT_SIZE
#endif
The current code uses extract_offset to decide where to position the
copied ZO (i.e. ZO starts at extract_offset). (This is why ZO_INIT_SIZE
currently includes the extract_offset.)
<=
Assuming the edits I made are correct, this is the point where the changelog
lost
me. It does not explain why ZO_z_extract_offset exists. Why isn't the ZO copied
to
offset 0?
I had to go into arch/x86/boot/compressed/mkpiggy.c, where ZO_z_extract_offset
is
generated, to find the answer: it's needed because we are trying to minimize
the
amount of RAM used for the whole act of creating an uncompressed, executable,
properly relocation-linked kernel image in system memory. We do this so that
kernels can be booted on even very small systems.
To achieve the goal of minimal memory consumption we have implemented an
in-place
decompression strategy: instead of cleanly separating the VO and ZO images and
also allocating some memory for the decompression code's runtime needs, we
instead
create this elaborate layout of memory buffers where the output (decompressed)
stream, as it progresses, overlaps with and destroys the input (compressed)
stream. This can only be done safely if the ZO image is placed to the end of
the
VO range, plus a certain amount of safety distance to make sure that when the
last
bytes of the VO range are decompressed, the compressed stream pointer is safely
beyond the end of the VO range. Correct?
This is a very essential central concept to the whole code, but nowhere is it
described clearly!
But more importantly, especially in view of address space randomization, we
should
realize that the days of 8 MB i386-DX systems are gone, and we should get rid
of
all this crazy obfuscation that is hindering development in this area. I also
suspect that the actual temporary allocation size reduction savings from this
trick are relatively small, compared to the resulting total memory size.
So my suggestion: let's just cleanly separate all the data areas and not try to
do
any clever overlapping: the benefit will be minimal, and any system that has
main
RAM less than twice of the VO+ZO image sizes is fundamentally unbootable and
unusable anyway.
I.e. have a really clean size calculation of:
ZO + VO + decompressor-stacks-size + decompressor-data-size
and decompress accordingly without tricks, without overlaps, without any chance
for corruption - and, most importantly, without this metr
Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource
On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote: > On Wed, Apr 27, 2016 at 09:55:45PM -0700, Yinghai Lu wrote: >> On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote: >> > [+cc Ben, Michael] >> > I'm kind of confused here. There are two ways to mmap PCI BARs: >> > >> > /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()): >> > all BARs in one file; MEM/IO determined by ioctl() >> > mmap offset is a CPU physical address in the PCI resource >> > >> > /sys/devices/pci:00/:00:02.0/resource0 (pci_mmap_resource()): >> > one file per BAR; MEM/IO determined by BAR type >> > mmap offset is between 0 and BAR size >> > >> > Both proc_bus_pci_mmap() and pci_mmap_resource() validate the >> > requested area with pci_mmap_fits() before calling pci_mmap_page_range(). >> > >> > In the proc_bus_pci_mmap() path, the offset in vma->vm_pgoff must be >> > within the pdev->resource[], so the user must be supplying a CPU >> > physical address (not an address obtained from pci_resource_to_user()). >> > That vma->vm_pgoff is passed unchanged to pci_mmap_page_range(). >> > >> > In the pci_mmap_resource() path, vma->vm_pgoff must be between 0 and >> > the BAR size. Then we add in the pci_resource_to_user() information >> > before passing it to pci_mmap_page_range(). The comment in >> > pci_mmap_resource() says pci_mmap_page_range() expects a "user >> > visible" address, but I don't really believe that based on how >> > proc_bus_pci_mmap() works. >> > >> > Do both proc_bus_pci_mmap() and pci_mmap_resource() work on sparc? >> > It looks like they call pci_mmap_page_range() with different >> > assumptions, so I don't see how they can both work. >> >> for sysfs path: in pci_mmap_resource >> pci_resource_to_user(pdev, i, res, &start, &end); >> vma->vm_pgoff += start >> PAGE_SHIFT; >> then call pci_mmap_page_range() >> >> the fit checking in pci_mmap_fits(), >> pci_start = (mmap_api == PCI_MMAP_PROCFS) ? >> pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; >> if (start >= pci_start && start < pci_start + size && >> start + nr <= pci_start + size) >> >> so proc fs assume resource_start for vm_pgoff ? >> >> but current pci_mmap_page_range want to use bus address >> start aka BAR value. >> >> and we have >> >> /* pci_mmap_page_range() expects the same kind of entry as coming >> * from /proc/bus/pci/ which is a "user visible" value. If this is >> * different from the resource itself, arch will do necessary fixup. >> */ >> >> so we need to fix pci_mmap_fits(), please check if it is ok, will >> submit it as separated one. > > 1) The sysfs path uses offsets between 0 and BAR size. This path > should work identically on all arches. "User" addresses are not > involved, so it doesn't make sense that this path calls > pci_resource_to_user() from pci_mmap_resource(). > > 2) The procfs path uses offsets of resource values (CPU physical > addresses) on most architectures. If some arches use something else, > e.g., "user" addresses, the grunge of dealing with them should be in > this path, i.e., in proc_bus_pci_mmap(). This implies that > pci_mmap_page_range() should deal with CPU physical addresses, not bus > addresses, and proc_bus_pci_mmap() should perform any necessary > translation. > > 3) If my theory that proc_bus_pci_mmap() and pci_mmap_resource() are > calling pci_mmap_page_range() with different assumptions is correct, > you should be able to write a test program that fails for one method, > and your patch should fix that failure. > ...> > This is the wrong place to deal with this. IMO, any pci_resource_to_user() > fiddling should be done directly in proc_bus_pci_mmap(), and > pci_mmap_fits() should deal only with resources (CPU physical > addresses). Then it wouldn't care where it was called from, so we > could get rid of the pci_mmap_api thing completely. ok, I got it. We should offset vma->vm_pgoff back into [0, BAR) will look at it Monday. Thanks Yinghai
Re: [PATCH v3 1/3] leds: triggers: Allow to switch the trigger to "panic" on a kernel panic
Hi Ezequiel,
Thanks for the update. It's indeed reasonable to have all the
switching infrastructure in ledtrig-panic.c.
I've noticed two minor issues below.
On 04/29/2016 12:03 AM, Ezequiel Garcia wrote:
This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which
allows to mark a specific LED to be switched to the "panic"
trigger, on a kernel panic.
This is useful to allow the user to assign a regular trigger
to a given LED, and still blink that LED on a kernel panic.
Signed-off-by: Ezequiel Garcia
---
drivers/leds/led-triggers.c | 2 +-
drivers/leds/leds.h | 1 +
drivers/leds/trigger/Kconfig | 3 +++
drivers/leds/trigger/ledtrig-panic.c | 47
include/linux/leds.h | 1 +
5 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 2181581795d3..55fa65e1ae03 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -26,7 +26,7 @@
* Nests outside led_cdev->trigger_lock
*/
static DECLARE_RWSEM(triggers_list_lock);
-static LIST_HEAD(trigger_list);
+LIST_HEAD(trigger_list);
/* Used by LED Class */
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index db3f20da7221..7d38e6b9a740 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -30,5 +30,6 @@ void led_set_brightness_nosleep(struct led_classdev *led_cdev,
extern struct rw_semaphore leds_list_lock;
extern struct list_head leds_list;
+extern struct list_head trigger_list;
#endif/* __LEDS_H_INCLUDED */
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index beac8c31c51b..4e4521c9072a 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -121,6 +121,9 @@ config LEDS_TRIGGER_PANIC
depends on LEDS_TRIGGERS
help
This allows LEDs to be configured to blink on a kernel panic.
+ Enabling this option will allow to mark certain LEDs as
'panic-indicators',
s/"panic-indicators"/panic indicators/
I understand that you referred here to the DT property name, but this
is not obvious at first glance, and it is an implementation detail.
+ allowing to blink them on a kernel panic, even if they are set to
+ a different trigger.
If unsure, say Y.
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/ b/drivers/leds/trigger/ledtrig-panic.c
index 627b350c5ec3..3e447bd2064a 100644
--- a/drivers/leds/trigger/ledtrig-panic.c
+++ b/drivers/leds/trigger/ledtrig-panic.c
@@ -11,10 +11,54 @@
#include
#include
+#include
#include
+#include "../leds.h"
static struct led_trigger *trigger;
+/*
+ * This is a called in a special context by the atomic panic
s/is a/is/
+ * notifier. This means the trigger can be changed without
+ * worrying about locking.
+ */
+static void led_trigger_set_panic(struct led_classdev *led_cdev)
+{
+ struct led_trigger *trig;
+
+ list_for_each_entry(trig, &trigger_list, next_trig) {
+ if (strcmp("panic", trig->name))
+ continue;
+ if (led_cdev->trigger)
+ list_del(&led_cdev->trig_list);
+ list_add_tail(&led_cdev->trig_list, &trig->led_cdevs);
+
+ /* Avoid the delayed blink path */
+ led_cdev->blink_delay_on = 0;
+ led_cdev->blink_delay_off = 0;
+
+ led_cdev->trigger = trig;
+ if (trig->activate)
+ trig->activate(led_cdev);
+ break;
+ }
+}
+
+static int led_trigger_panic_notifier(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+ struct led_classdev *led_cdev;
+
+ list_for_each_entry(led_cdev, &leds_list, node)
+ if (led_cdev->flags & LED_PANIC_INDICATOR)
+ led_trigger_set_panic(led_cdev);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block led_trigger_panic_nb = {
+ .notifier_call = led_trigger_panic_notifier,
+};
+
static long led_panic_blink(int state)
{
led_trigger_event(trigger, state ? LED_FULL : LED_OFF);
@@ -23,6 +67,9 @@ static long led_panic_blink(int state)
static int __init ledtrig_panic_init(void)
{
+ atomic_notifier_chain_register(&panic_notifier_list,
+ &led_trigger_panic_nb);
+
led_trigger_register_simple("panic", &trigger);
panic_blink = led_panic_blink;
return 0;
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 19eb10278bea..7e9fb00e15e8 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -50,6 +50,7 @@ struct led_classdev {
#define LED_SYSFS_DISABLE (1 << 22)
#define LED_DEV_CAP_FLASH (1 << 23)
#define LED_HW_PLUGGABLE (1 << 24)
+#define LED_PANIC_INDICATOR(1 << 25)
/* Set LED brightness level
* Must not sleep. Us
Re: [PATCH v4] x86/boot: Warn on future overlapping memcpy() use
* Kees Cook wrote: > On Thu, Apr 28, 2016 at 11:43 PM, Ingo Molnar wrote: > > > > * Kees Cook wrote: > > > >> If an overlapping memcpy() is ever attempted, we should at least report > >> it, in case it might lead to problems, so it could be changed to a > >> memmove() call instead. > >> > >> Suggested-by: Ingo Molnar > >> Signed-off-by: Kees Cook > >> --- > >> v4: > >> - use __memcpy not memcpy since we've already done the check. > >> v3: > >> - call memmove in addition to doing the warning > >> v2: > >> - warn about overlapping region > >> --- > >> arch/x86/boot/compressed/string.c | 16 +--- > >> 1 file changed, 13 insertions(+), 3 deletions(-) > > > > Applied, thanks Kees! > > > > Btw., can we now also remove the memmove() hack from lib/decompress_unxz.c? > > I'll let Lasse answer for sure, but I don't think so. The original commit > says: > > The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and > memzero() (memset(ptr, 0, size)), which aren't available in all > arch-specific pre-boot environments. I'm including simple versions in > decompress_unxz.c, but a cleaner solution would naturally be nicer. I see, so non-x86 architectures might not have the proper runtime environment implemented, right? Fair enough! Thanks, Ingo
Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering
On 29 April 2016 at 01:06, Douglas Anderson wrote: > This series picks patches from various different places to produce what > I consider the best solution to getting consistent mmc and mmcblk > ordering. > > Why consistent ordering and why not just use UUIDs? IMHO consistent > ordering solves a few different problems: > > 1. For poor, feeble-minded humans like me, have sane numbering for >devices helps a lot. When grepping through dmesg it's terribly handy >if a given SDMMC device has a consistent number. I know that I can >do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about >the eMMC. I know that I can do "dmesg | grep mmc1" to find info >about the SD card slot. I don't want it to matter which one probed >first, I don't want it to matter if I'm working on a variant of the >hardware that has the SD card slot disabled, and I don't want to care >what my boot device was. Worrying about what device number I got >increases my cognitive load. > > 2. There are cases where it's not trivially easy during development to >use the UUID. Specifically I work a lot with coreboot / depthcharge >as a BIOS. When configured properly, that BIOS has a nice feature to >allow you to fetch the kernel and kernel command line from TFTP by >pressing Ctrl-N. In this particular case the BIOS doesn't actually >know which disk I'd like for my root filesystem, so it's not so easy >for it to put the right UUID into the command line. For this >purpose, knowing that "mmcblk0" will always refer to eMMC is handy. > > > Jaehoon Chung (1): > Documentation: mmc: Document mmc aliases > > Stefan Agner (2): > mmc: read mmc alias from device tree > mmc: use SD/MMC host ID for block device name ID > > Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++ > drivers/mmc/card/block.c | 3 ++- > drivers/mmc/core/host.c | 25 - > 3 files changed, 33 insertions(+), 6 deletions(-) > > -- > 2.8.0.rc3.226.g39d4020 > I believe you need to re-base this patchset as things have changed. Currently the mmc host index that gets picked at host registration point, will also be given to the corresponding mmc block device index. That's probably solving most of your concerns, but I am open to extend this to cover aliases as well, as to allow it to be *really* deterministic. Kind regards Uffe
[PATCH v2] iio: accel: Add support for Freescale MMA7660FC
Minimal implementation of an IIO driver for the Freescale
MMA7660FC 3-axis accelerometer. Datasheet:
http://www.freescale.com.cn/files/sensors/doc/data_sheet/MMA7660FC.pdf
Includes:
- ACPI support;
- read_raw for x,y,z axes;
- reading and setting the scale (range) parameter.
- power management
Signed-off-by: Constantin Musca
---
drivers/iio/accel/Kconfig | 10 ++
drivers/iio/accel/Makefile | 2 +
drivers/iio/accel/mma7660.c | 275
3 files changed, 287 insertions(+)
create mode 100644 drivers/iio/accel/mma7660.c
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index e4a758c..2e6a0e6 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -54,6 +54,16 @@ config HID_SENSOR_ACCEL_3D
To compile this driver as a module, choose M here: the
module will be called hid-sensor-accel-3d.
+config MMA7660
+ tristate "Freescale MMA7660FC 3-Axis Accelerometer Driver"
+ depends on I2C
+ help
+ Say yes here to get support for the Freescale MMA7660FC 3-Axis
+ accelerometer.
+
+ Choosing M will build the driver as a module. If so, the module
+ will be called mma7660.
+
config IIO_ST_ACCEL_3AXIS
tristate "STMicroelectronics accelerometers 3-Axis Driver"
depends on (I2C || SPI_MASTER) && SYSFS
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 71b6794..ba1165f 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -15,6 +15,8 @@ obj-$(CONFIG_MMA7455) += mma7455_core.o
obj-$(CONFIG_MMA7455_I2C) += mma7455_i2c.o
obj-$(CONFIG_MMA7455_SPI) += mma7455_spi.o
+obj-$(CONFIG_MMA7660) += mma7660.o
+
obj-$(CONFIG_MMA8452) += mma8452.o
obj-$(CONFIG_MMA9551_CORE) += mma9551_core.o
diff --git a/drivers/iio/accel/mma7660.c b/drivers/iio/accel/mma7660.c
new file mode 100644
index 000..9aad91d
--- /dev/null
+++ b/drivers/iio/accel/mma7660.c
@@ -0,0 +1,275 @@
+/**
+ * Freescale MMA7660FC 3-Axis Accelerometer
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * IIO driver for Freescale MMA7660FC; 7-bit I2C address: 0x4c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define MMA7660_DRIVER_NAME"mma7660"
+
+#define MMA7660_REG_XOUT 0x00
+#define MMA7660_REG_YOUT 0x01
+#define MMA7660_REG_ZOUT 0x02
+#define MMA7660_REG_OUT_BIT_ALERT BIT(6)
+
+#define MMA7660_REG_MODE 0x07
+#define MMA7660_REG_MODE_BIT_MODE BIT(0)
+#define MMA7660_REG_MODE_BIT_TON BIT(2)
+
+#define MMA7660_MODE_STANDBY 0
+#define MMA7660_MODE_ACTIVE1
+
+#define MMA7660_I2C_READ_RETRIES 5
+
+/*
+ * The accelerometer has one measurement range:
+ *
+ * -1.5g - +1.5g (6-bit, signed)
+ *
+ * scale1 = (1.5 + 1.5) * 9.81 / (2^6 - 1) = 0.467142857
+ */
+
+#define MMA7660_SCALE_AVAIL"0.467142857"
+
+const int mma7660_nscale = 467142857;
+
+#define MMA7660_CHANNEL(reg, axis) { \
+ .type = IIO_ACCEL, \
+ .address = reg, \
+ .modified = 1, \
+ .channel2 = IIO_MOD_##axis, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec mma7660_channels[] = {
+ MMA7660_CHANNEL(MMA7660_REG_XOUT, X),
+ MMA7660_CHANNEL(MMA7660_REG_YOUT, Y),
+ MMA7660_CHANNEL(MMA7660_REG_ZOUT, Z),
+};
+
+struct mma7660_data {
+ struct i2c_client *client;
+ struct mutex lock;
+ u8 mode;
+};
+
+static IIO_CONST_ATTR(in_accel_scale_available, MMA7660_SCALE_AVAIL);
+
+static struct attribute *mma7660_attributes[] = {
+ &iio_const_attr_in_accel_scale_available.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group mma7660_attribute_group = {
+ .attrs = mma7660_attributes
+};
+
+static int mma7660_set_mode(struct mma7660_data *data, u8 mode)
+{
+ int ret;
+ struct i2c_client *client = data->client;
+
+ if (mode > 1)
+ return -EINVAL;
+
+ if (mode == data->mode)
+ return 0;
+
+ ret = i2c_smbus_read_byte_data(client, MMA7660_REG_MODE);
+ if (ret < 0) {
+ dev_err(&client->dev, "failed to change sensor mode\n");
+ return ret;
+ }
+
+ if (mode == MMA7660_MODE_ACTIVE) {
+ ret &= ~MMA7660_REG_MODE_BIT_TON;
+ ret |= MMA7660_REG_MODE_BIT_MODE;
+ } else {
+ ret &= ~MMA7660_REG_MODE_BIT_TON;
+ ret &= ~MMA7660_REG_MODE_BIT_MODE;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, MMA7660_REG_MODE, ret);
+ if (ret < 0) {
+ dev_err(&client->dev, "failed to change sensor mode\n");
+ return ret;
+
Re: [PATCH 1/2] zsmalloc: require GFP in zs_malloc()
On (04/29/16 14:44), Minchan Kim wrote: [..] > > @@ -1945,8 +1944,6 @@ struct zs_pool *zs_create_pool(const char *name, > > gfp_t flags) > > So, we can remove flags parameter passing and comment about that. good point; gfp_t is now unneeded there. will resubmit 0001 later. > Other than that, > > Acked-by: Minchan Kim thanks. -ss
Re: random(4) changes
>From smuel...@chronox.de Fri Apr 29 04:56:49 2016 From: Stephan Mueller To: George Spelvin Cc: herb...@gondor.apana.org.au, linux-cry...@vger.kernel.org, linux-kernel@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu Subject: Re: random(4) changes Date: Thu, 28 Apr 2016 22:15:17 +0200 User-Agent: KMail/4.14.10 (Linux/4.4.7-300.fc23.x86_64; KDE/4.14.18; x86_64; ; ) In-Reply-To: <20160427002346.12354.qm...@ns.horizon.com> References: <20160427002346.12354.qm...@ns.horizon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Am Dienstag, 26. April 2016, 20:23:46 schrieb George Spelvin: Hi George, > > And considering that I only want to have 0.9 bits of entropy, why > > should I not collapse it? The XOR operation does not destroy the existing > > entropy, it only caps it to at most one bit of information theoretical > > entropy. > > No. Absolutely, demonstrably false. > > The XOR operation certainly *does* destroy entropy. > If you have 0.9 bits of entropy to start, you will have less > after the XOR. It does NOT return min(input, 1) bits. As I am having difficulties following your explanation, let us start at the definition: XOR is defined as an entropy preserving operation, provided the two arguments to the XOR operation are statistically independent (let us remember that caveat for later). > That means, the entropy behavior of H(A XOR B) is max(H(A), H(B)) if they are > independent. Actually, no. If they're independent, it can be greater. For example, if A has half a bit of entropy, and B has half a bit (both in the Shannon sense), then A XOR B will have 0.713537 bits. > 1. the individual bits of a given 32 bit time stamp are independent >(or IID in terms of NIST) They're not independent, nor are they identically distributed. If they were identically distributed, they'd all have identical entropy. And there's be no reason to stop at 32 bits. If the high 32 bits have the same entropy as the low entropy too?. > 2. show that the maximum entropy of each of the individual bits is equal or >more to my entropy estimate I apply. I'm not sure what you mean here. When you say "maximum entropy" is that a non-strict upper bound? Or does that mean that at least one bit achieves that maximum? That will be a much more interesting proof. > Regarding 1: The time stamp (or cycle counter) is a 32 bit value where > each of the bits does not depend on the other bits. When considering one > and only one time stamp value and we look at, say, the first 20 bits, > there is no way it is clear what the missing 12 bits will be. If you deliberately exclude all external data, then a 32-bit constant is random. (I suggest 17, the "most random number".) But that's meaningless. When we talk about "entropy", we are talking about an attacker's uncertainty about the value. Any other measure is garbage in, and proiduces nothing but garbage out. Note I am not saying that when comparing two or more time stamps that one cannot deduce the bits! And here it is clear that the bits within one given time stamp are independent, but multiple time stamps are not independent. This finding is supported with measurements given in 3.4.1 (I understand that the measurements are only supportive and no proof). Figure 3.1 shows an (almost) rectangular distribution which is the hint to an equidistribution which in turn supports the finding that the individual bits within a time stamp are independent. In addition, when you look at the Shannon/Min Entropy values (which do not give an entropy estimate here, but only help in understanding the distribution!), the values show that the distribution has hardly any discontinuities -- please read the explanation surrounding the figure. Regarding 2: I did numerous measurements that show that the low bits do have close to one bit of entropy per data bit. If I may ask to consider section 3.4.1 again (please consider that I tried to break the logic by applying a pathological generation of interrupts here to stimulate the worst case): The entropy is not found in the absolute time stamps, but visible in the time deltas (and the uncertainty of the variations of those). So I calculated the time deltas from the collected set of time stamps of events. Now, when simply using the four (you may also use three or perhaps five) lower bits of the time delta values, we can calculate an interesting and very important Minimum Entropy value: the Markov Min Entropy. Using the table 2, I calculated the Markov Min Entropy of the data set of the 4 low bit time delta values. The result shows that the 4 bit values still have 3.92 bits of entropy (about 0.98 bits of entropy per data bit). Ok, one worst case measurement may not be good enough. So I continued on other environments with the same testing. Table 3 provides the results on those environments. And they have even more entropy than the first measurement! So, with all the measure
Re: OpRegion conflicts for Skylake LPSS
Ben Gamari writes: > [ Unknown signature status ] > Mika Westerberg writes: > >> On Tue, Apr 26, 2016 at 02:44:13AM +0200, Ben Gamari wrote: >>> > snip > >>> It looks very much like these are describing the same device. Perhaps >>> the lpss driver should be binding to this ACPI node? Or perhaps this is >>> a firmware issue? Any guidance would be greatly appreciated. >> >> Can you send me full acpidump of that machine? > > It can be found at > https://github.com/bgamari/dell-e7470-dsdt/blob/master/acpi.log. > Did this provide any insight? Let me know if more information would be helpful. Also, is there a way to simply allow the driver subsystem to allow probing to proceed despite this resource conflict so that I can resume debugging my original input device issue? Cheers, - Ben signature.asc Description: PGP signature
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
On 04/29/2016 09:15 AM, Pavel Machek wrote: > Hi! > >> On n900, probe finishes ok (verified by adding printks), and the >> device shows up in /sys, but I don't get /dev/video* or >> /dev/v4l-subdev*. >> >> Other drivers (back and front camera) load ok, and actually work. Any >> idea what could be wrong? > > Ok, so I guess I realized what is the problem: > > adp1653 registers itself as a subdev, but there's no device that > register it as its part. > > (ad5820 driver seems to have the same problem). > > Is there example "dummy" device I could use, for sole purpose of > having these devices appear in /dev? They are on i2c, so both can work > on their own. Ah, interesting. This was discussed a little bit during the Media Summit a few weeks back: http://linuxtv.org/news.php?entry=2016-04-20.mchehab See section 5: "5. DT Bindings for flash & lens controllers There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don’t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree? Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices." This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code. But now you run into the same problem that I have. The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part. Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties". Something like: controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers. Warning: I'm no DT expert, so this is just a first attempt. Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously. Regards, Hans
Re: [PATCH 07/21] X86_64, UV: Enable/Disable UV1 only workaround code
* Mike Travis wrote:
> This patch allows enabling or disabling of the "EXTRA APIC ID BITS"
> workaround found only on UV100/UV1000 systems. This workaround was
> required by the Intel Nahelm Processor (used in that architecture)
> because it could only support a limited number of CPU threads within
> the SSI. This was due to only having 8 APIC ID bits thus a workaround
> was added to add and remove extra bits to the APIC ID. It also required
> a specialized UV1 only apic driver.
>
> Signed-off-by: Mike Travis
> Tested-by: Nathan Zimmer
> ---
> arch/x86/Kconfig | 14 ++
> arch/x86/include/asm/uv/uv_hub.h | 11 ---
> arch/x86/include/asm/uv/uv_mmrs.h |2 ++
> arch/x86/kernel/apic/x2apic_uv_x.c | 26 +++---
> 4 files changed, 43 insertions(+), 10 deletions(-)
>
> --- linux.orig/arch/x86/Kconfig
> +++ linux/arch/x86/Kconfig
> @@ -489,6 +489,20 @@ config X86_UV
> This option is needed in order to support SGI Ultraviolet systems.
> If you don't have one of these, you should say N here.
>
> +config X86_UV1_SUPPORTED
> + bool "SGI Ultraviolet Series 1 Supported"
> + depends on X86_UV
> + default n
> + ---help---
> + Set this option if you have a UV100/UV1000 system. By setting
> + this option extra execution time and space is introduced for
> + workarounds designed for processors limited to only 8 apicid bits.
> + This limited the number of processors that could be supported in
> + an SSI. With the Intel release of the SandyBridge Processor (used
> + in UV2000 systems), the "x2apic" mode was introduced to extend
> + the number of apicid bits. Thus more processors are supported
> + without these workarounds and the specialized UV1 only apic driver.
> +
> # Following is an alphabetically sorted list of 32 bit extended platforms
> # Please maintain the alphabetic order if and when there are additions
>
> --- linux.orig/arch/x86/include/asm/uv/uv_hub.h
> +++ linux/arch/x86/include/asm/uv/uv_hub.h
> @@ -289,25 +289,21 @@ union uvh_apicid {
> #define UV4_GLOBAL_MMR32_SIZE(16UL * 1024 * 1024)
>
> #define UV_LOCAL_MMR_BASE( \
> - is_uv1_hub() ? UV1_LOCAL_MMR_BASE : \
> is_uv2_hub() ? UV2_LOCAL_MMR_BASE : \
> is_uv3_hub() ? UV3_LOCAL_MMR_BASE : \
> /*is_uv4_hub*/ UV4_LOCAL_MMR_BASE)
>
> #define UV_GLOBAL_MMR32_BASE ( \
> - is_uv1_hub() ? UV1_GLOBAL_MMR32_BASE : \
> is_uv2_hub() ? UV2_GLOBAL_MMR32_BASE : \
> is_uv3_hub() ? UV3_GLOBAL_MMR32_BASE : \
> /*is_uv4_hub*/ UV4_GLOBAL_MMR32_BASE)
>
> #define UV_LOCAL_MMR_SIZE( \
> - is_uv1_hub() ? UV1_LOCAL_MMR_SIZE : \
> is_uv2_hub() ? UV2_LOCAL_MMR_SIZE : \
> is_uv3_hub() ? UV3_LOCAL_MMR_SIZE : \
> /*is_uv4_hub*/ UV4_LOCAL_MMR_SIZE)
>
> #define UV_GLOBAL_MMR32_SIZE ( \
> - is_uv1_hub() ? UV1_GLOBAL_MMR32_SIZE : \
> is_uv2_hub() ? UV2_GLOBAL_MMR32_SIZE : \
> is_uv3_hub() ? UV3_GLOBAL_MMR32_SIZE : \
> /*is_uv4_hub*/ UV4_GLOBAL_MMR32_SIZE)
Hm, are you sure this can be removed?
> @@ -445,9 +441,6 @@ static inline int uv_apicid_to_pnode(int
> */
> static inline int uv_apicid_to_socket(int apicid)
> {
> - if (is_uv1_hub())
> - return (apicid >> (uv_hub_info->apic_pnode_shift - 1)) & 1;
> - else
> return 0;
> }
>
> @@ -704,7 +697,11 @@ static inline void uv_set_cpu_scir_bits(
> }
> }
>
> +#ifdef UV1_HUB_IS_SUPPORTED
> extern unsigned int uv_apicid_hibits;
> +#else
> +#define uv_apicid_hibits0
> +#endif
> static unsigned long uv_hub_ipi_value(int apicid, int vector, int mode)
> {
> apicid |= uv_apicid_hibits;
> --- linux.orig/arch/x86/include/asm/uv/uv_mmrs.h
> +++ linux/arch/x86/include/asm/uv/uv_mmrs.h
> @@ -95,7 +95,9 @@
> #define UV4_HUB_PART_NUMBER 0x99a1
>
> /* Compat: Indicate which UV Hubs are supported. */
> +#ifdef CONFIG_X86_UV1_SUPPORTED
> #define UV1_HUB_IS_SUPPORTED 1
> +#endif
> #define UV2_HUB_IS_SUPPORTED 1
> #define UV3_HUB_IS_SUPPORTED 1
> #define UV4_HUB_IS_SUPPORTED 1
> --- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -39,7 +39,9 @@
> #include
> #include
>
> +#ifdef UV
Re: [PATCH v2 00/11] pwm: Add support for PWM Capture
Hi Lee, On Fri, 22 Apr 2016 11:18:04 +0100 Lee Jones wrote: > The first part of this set extends the current PWM API to allow external > code to request a PWM Capture. Subsequent patches then make use of the > new API by providing a userspace offering via /sysfs. The final part of > the set supplies PWM Capture functionality into the already existing STi > PWM driver. Is there a reason you decided to not put this driver in IIO? IMHO, it would be more appropriate to make your PWM device an MFD that can either bind to the PWM or the capture driver. And BTW, IIO already has a sysfs interface (you may have to extend the API to support your type of capture though). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.
On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote: > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones : > > [This is an opinionated patch, mainly for discussion.] > > > > I'm trying to reduce the time taken in the kernel in initcalls, with > > my aim being to reduce the current ~700ms spent in initcalls before > > userspace, down to something like 100ms. All times on my Broadwell-U > > laptop, under virtualization. The purpose of this is to be able to > > launch VMs around containers with minimal overhead, like Intel Clear > > Containers, but using standard distro kernels and qemu. > > > > Currently the kernel spends 25ms inspecting the UART that we passed to > > it from qemu to find out whether it's an 8250/16550/16550A perhaps > > with a non-working FIFO or other quirks. Well, it isn't -- it's a > > working emulated 16550A, with a FIFO and no quirks, and if it isn't, > > we should fix qemu. > > > > So the patch detects if we're running virtualized (perhaps it should > > only check for qemu/KVM?) and if so, shortcuts the tests. > > Does anybody know, whether it is possible to pass through real > hardware serial port to a guest? It seems to be as simple as to pass > through an interrupt and memory IO ports. In theory it seems like something VFIO could do. Passing something as low performance as a serial port through would seem to make little sense though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
Re: [PATCH v2 06/10] mfd: stmpe: rework registers access
On Thu, Apr 28, 2016 at 2:13 PM, wrote: > From: Patrice Chotard > > this update allows to use registers map as following : > regs[reg_index + offset] instead of > regs[reg_index] + offset > > This makes code clearer and will facilitate the addition of STMPE1600 > on which LSB and MSB registers are respectively located at addr and addr + 1. > Despite for all others STMPE variant, LSB and MSB registers are respectively > located in reverse order at addr + 1 and addr. > > For variant which have 3 registers's bank, we use LSB,CSB and MSB indexes > which contains respectively LSB (or LOW), CSB (or MID) and MSB (or HIGH) > register addresses (STMPE1801/STMPE24xx). > For variant which have 2 registers's bank, we use LSB and CSB indexes only. > In this case the CSB index contains the MSB regs address (STMPE 1601). > > Signed-off-by: Patrice Chotard Yep this is so much clearer! Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: OpRegion conflicts for Skylake LPSS
On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote: > Ben Gamari writes: > > > [ Unknown signature status ] > > Mika Westerberg writes: > > > >> On Tue, Apr 26, 2016 at 02:44:13AM +0200, Ben Gamari wrote: > >>> > > snip > > > >>> It looks very much like these are describing the same device. Perhaps > >>> the lpss driver should be binding to this ACPI node? Or perhaps this is > >>> a firmware issue? Any guidance would be greatly appreciated. > >> > >> Can you send me full acpidump of that machine? > > > > It can be found at > > https://github.com/bgamari/dell-e7470-dsdt/blob/master/acpi.log. > > > Did this provide any insight? Let me know if more information would be > helpful. Sorry about the delay. The GEXP device is most probably a GPIO expander that is connected to one of the I2C buses. And it indeed looks to use directly the I2C host controller registers so kernel rightfully complains about that. Are you able to run Windows on that machine? If yes, it would be nice to know if the INT3446 I2C device is shown in the device manager. > Also, is there a way to simply allow the driver subsystem to allow > probing to proceed despite this resource conflict so that I can resume > debugging my original input device issue? Try to pass "acpi_enforce_resources=lax" in the kernel command line.
Re: [PATCH v2 07/10] gpio: stmpe: rework registers access
On Thu, Apr 28, 2016 at 2:13 PM, wrote: > From: Patrice Chotard > > This update allows to use registers map as following : > regs[reg_index + offset] instead of > regs[reg_index] + offset > > This makes code clearer and will facilitate the addition of STMPE1600 > on which LSB and MSB registers are respectively located at addr and addr + 1. > Despite for all others STMPE variant, LSB and MSB registers are respectively > located in reverse order at addr + 1 and addr. > > For variant which have 3 registers's bank, we use LSB,CSB and MSB indexes > which contains respectively LSB (or LOW), CSB (or MID) and MSB (or HIGH) > register addresses (STMPE1801/STMPE24xx). > For variant which have 2 registers's bank, we use LSB and CSB indexes only. > In this case the CSB index contains the MSB regs address (STMPE 1601). > > Signed-off-by: Patrice Chotard Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property
Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring: > On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote: > > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID > > information via I2C interface. > > > > Signed-off-by: Akshay Bhat > > --- > > > > v3: > > Newly added. > > > > Documentation/devicetree/bindings/display/imx/ldb.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt > > b/Documentation/devicetree/bindings/display/imx/ldb.txt > > index 0a175d9..a407462 100644 > > --- a/Documentation/devicetree/bindings/display/imx/ldb.txt > > +++ b/Documentation/devicetree/bindings/display/imx/ldb.txt > > @@ -62,6 +62,7 @@ Required properties: > > display-timings are used instead. > > > > Optional properties (required if display-timings are used): > > The required part doesn't make sense if you add this, but... > > > + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > Really, this should be part of a connector node since i2c goes from the > i2c controller to a connector and is not part of the display controller. If the ddc i2c bus does indeed go through a connector, yes. Would that warrant a generic "lvds-connector" binding for all those different types of internal LVDS connectors? regards Philipp
Re: [PATCH v2 10/10] gpio: stmpe: Add STMPE1600 support
On Thu, Apr 28, 2016 at 2:13 PM, wrote: > From: Patrice Chotard > > The particularities of this variant are: > - GPIO_XXX_LSB and GPIO_XXX_MSB memory locations are inverted compared > to other variants. > - There is no Edge detection, Rising Edge and Falling Edge registers. > - IRQ flags are cleared when read, no need to write in Status register. > > Signed-off-by: Amelie DELAUNAY > Signed-off-by: Patrice Chotard Reviewed-by: Linus Walleij Yours, Linus Walleij
[PATCH] drm/rockchip: vop: Initialize vskiplines to zero
There is a path that use vskiplines with non-initialize.
That would cause vop abnormal behavior.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 8652bb1..bf55cda 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -310,7 +310,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
uint16_t vsu_mode;
uint16_t lb_mode;
uint32_t val;
- int vskiplines;
+ int vskiplines = 0;
if (dst_w > 3840) {
DRM_ERROR("Maximum destination width (3840) exceeded\n");
--
1.9.1
Re: [PATCH v2 00/10] STMPE fixes/rework and add STMPE1600 support
On Thu, Apr 28, 2016 at 2:12 PM, wrote: > From: Patrice Chotard > > This series cleans and fixes some bugs in MFD/GPIO STMPE drivers and prepare > the ground to add new STMPE1600 support. This series is finished and looking good from a GPIO perspective. Lee, once you feel satisfied with the patches and merge them I'd need an immutable branch, this one I definately have to pull into the GPIO tree (because of dependent patches). Yours, Linus Walleij
Re: [RFC v2 5/8] drm/fence: add in-fences support
Hi, On 28 April 2016 at 23:28, Rob Clark wrote: > On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote: >> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote: >>> A (per-CRTC?) array of fences would be more flexible. And even in the cases >>> where you could make a 1-to-1 mapping between planes and fences, it's not >>> that much more work for userspace to assemble those fences into an array >>> anyway. >> >> I'm ok with an array too if that's what you folks prefer (it's meant to be >> used by you after all). I just don't want just 1 fence for the entire op, >> forcing userspace to first merge them all together. That seems silly. > > I was kinda more a fan of array too, if for no other reason that to be > consistent w/ how out-fences work. (And using property just for > in-fence seemed slightly weird/abusive to me) I don't think it's really useful to look for much consistency between the two, beyond the name. I'm more concerned with consistency between in-fences and the implicit fences on buffers/FBs, and between out-fences and the page_flip_events. >> One side-effect of that is that we'd also have to rework all the internal >> bits and move fences around in atomic. Which means change a pile of >> drivers. Not sure that's worth it, but I'd be ok either way really. > > hmm, well we could keep the array per-plane (and if one layer is using > multiple planes, just list the same fd multiple times).. then it > mostly comes down to changes in the ioctl fxn itself. ... and new API in libdrm, which is going to be a serious #ifdef and distribution pain. The core property API has been available since 2.4.62 last June, but for this we'd have to write the code, wait for the kernel code, wait for HWC, get everything together, and then merge and release. That gives minimum one year of libdrm releases which have had atomic but not in-fence API support, if we're adding a new array. And I just don't really see what it buys us, apart from the need for the core atomic_get_property helper to statically return -1 when requesting FENCE_FD. Cheers, Daniel
Re: klp: make object/func-walking helpers more robust
On Thu, 28 Apr 2016, Josh Poimboeuf wrote:
> On Thu, Apr 28, 2016 at 02:21:31PM -0400, Jessica Yu wrote:
> > +++ Miroslav Benes [28/04/16 16:34 +0200]:
> > > Current object-walking helper checks the presence of obj->funcs to
> > > determine the end of objs array in klp_object structure. This is
> > > somewhat fragile because one can easily forget about funcs definition
> > > during livepatch creation. In such a case the livepatch module is
> > > successfully loaded and all objects after the incorrect one are omitted.
> > > This is very confusing. Let's make the helper more robust and check also
> > > for the other external member, name. Thus the helper correctly stops on
> > > an empty item of the array. We need to have a check for obj->funcs in
> > > klp_init_object() to make it work.
> > >
> > > The same applies to a func-walking helper.
> > >
> > > As a benefit we'll check for new_func member definition during the
> > > livepatch initialization. There is no such check anywhere in the code
> > > now.
> > >
> > > Signed-off-by: Miroslav Benes
> > > ---
> > > include/linux/livepatch.h | 6 --
> > > kernel/livepatch/core.c | 3 +++
> > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> > > index 0933ca47791c..a93a0b23dc8d 100644
> > > --- a/include/linux/livepatch.h
> > > +++ b/include/linux/livepatch.h
> > > @@ -104,10 +104,12 @@ struct klp_patch {
> > > };
> > >
> > > #define klp_for_each_object(patch, obj) \
> > > - for (obj = patch->objs; obj->funcs; obj++)
> > > + for (obj = patch->objs; obj->funcs || obj->name; obj++)
> >
> > Remember that for patches to vmlinux, obj->name and obj->mod will also
> > both be NULL. So if someone happens to forget to fill in obj->funcs
> > for a vmlinux patch, we won't catch that case here.
Yes, that is true. My reasoning is that if someone even accidently writes
{ } somewhere in the middle of the array, there is nothing we can do to
help :). I consider it improbable whereas an omission of one field is
possible.
> > Perhaps we need a
> > better way of determining whether we've reached the end of the array,
> > or determining that the struct is truly empty..
>
> That would be nice, but I'm not sure how we could do that. I suppose we
> could add a patch->nr_objs field. But that might arguably be even
> easier for the user to mess up.
Yeah, that is perhaps the only way (ARRAY_SIZE won't work here) besides
introducing some special mark. I think this is not worth it. I agree it is
even more error-prone.
The idea behind this patch is that there is at least something we can do
to help without imposing much on the user.
Miroslav
Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer
On Fri, Apr 29, 2016 at 12:18 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> From: Yinghai Lu
>>
>> This change makes later calculations about where the kernel is located
>> easier to reason about. To better understand this change, we must first
>> clarify what VO and ZO are. They were introduced in commits by hpa:
>>
>> 77d1a49 x86, boot: make symbols from the main vmlinux available
>> 37ba7ab x86, boot: make kernel_alignment adjustable; new bzImage fields
>>
>> Specifically:
>>
>> VO:
>> - uncompressed kernel image
>> - size: VO__end - VO__text ("VO_INIT_SIZE" define)
>>
>> ZO:
>> - bootable compressed kernel image (boot/compressed/vmlinux)
>> - head text + compressed kernel (VO and relocs table) + decompressor code
>> - size: ZO__end - ZO_startup_32 ("ZO_INIT_SIZE" define, though see below)
>>
>> The INIT_SIZE definition is used to find the larger of the two image sizes:
>>
>> #define ZO_INIT_SIZE(ZO__end - ZO_startup_32 + ZO_z_extract_offset)
>> #define VO_INIT_SIZE(VO__end - VO__text)
>> #if ZO_INIT_SIZE > VO_INIT_SIZE
>> #define INIT_SIZE ZO_INIT_SIZE
>> #else
>> #define INIT_SIZE VO_INIT_SIZE
>> #endif
>>
>> The current code uses extract_offset to decide where to position the
>> copied ZO (i.e. ZO starts at extract_offset). (This is why ZO_INIT_SIZE
>> currently includes the extract_offset.)
>
> Yeah, so I rewrote the above to:
>
> =>
> This change makes later calculations about where the kernel is located
> easier to reason about. To better understand this change, we must first
> clarify what 'VO' and 'ZO' are. These values were introduced in commits
> by hpa:
>
> 77d1a4999502 ("x86, boot: make symbols from the main vmlinux available")
> 37ba7ab5e33c ("x86, boot: make kernel_alignment adjustable; new bzImage
> fields")
>
> Specifically:
>
> All names prefixed with 'VO_':
>
> - relate to the uncompressed kernel image
>
> - the size of the VO image is: VO__end-VO__text ("VO_INIT_SIZE" define)
>
> All names prefixed with 'ZO_':
>
> - relate to the bootable compressed kernel image (boot/compressed/vmlinux),
>which is composed of the following memory areas:
> - head text
> - compressed kernel (VO image and relocs table)
> - decompressor code
>
> - the size of the ZO image is: ZO__end - ZO_startup_32 ("ZO_INIT_SIZE"
> define, though see below)
>
> The 'INIT_SIZE' value is used to find the larger of the two image sizes:
>
> #define ZO_INIT_SIZE(ZO__end - ZO_startup_32 + ZO_z_extract_offset)
> #define VO_INIT_SIZE(VO__end - VO__text)
>
> #if ZO_INIT_SIZE > VO_INIT_SIZE
> # define INIT_SIZE ZO_INIT_SIZE
> #else
> # define INIT_SIZE VO_INIT_SIZE
> #endif
>
> The current code uses extract_offset to decide where to position the
> copied ZO (i.e. ZO starts at extract_offset). (This is why ZO_INIT_SIZE
> currently includes the extract_offset.)
> <=
>
> Assuming the edits I made are correct, this is the point where the changelog
> lost
> me. It does not explain why ZO_z_extract_offset exists. Why isn't the ZO
> copied to
> offset 0?
>
> I had to go into arch/x86/boot/compressed/mkpiggy.c, where
> ZO_z_extract_offset is
> generated, to find the answer: it's needed because we are trying to minimize
> the
> amount of RAM used for the whole act of creating an uncompressed, executable,
> properly relocation-linked kernel image in system memory. We do this so that
> kernels can be booted on even very small systems.
>
> To achieve the goal of minimal memory consumption we have implemented an
> in-place
> decompression strategy: instead of cleanly separating the VO and ZO images and
> also allocating some memory for the decompression code's runtime needs, we
> instead
> create this elaborate layout of memory buffers where the output (decompressed)
> stream, as it progresses, overlaps with and destroys the input (compressed)
> stream. This can only be done safely if the ZO image is placed to the end of
> the
> VO range, plus a certain amount of safety distance to make sure that when the
> last
> bytes of the VO range are decompressed, the compressed stream pointer is
> safely
> beyond the end of the VO range. Correct?
>
> This is a very essential central concept to the whole code, but nowhere is it
> described clearly!
That would certainly be worth calling out in the description, true.
> But more importantly, especially in view of address space randomization, we
> should
> realize that the days of 8 MB i386-DX systems are gone, and we should get rid
> of
> all this crazy obfuscation that is hindering development in this area. I also
> suspect that the actual temporary allocation size reduction savings from this
> trick are relatively small, compared to the resulting total memory size.
>
> So my suggestion: let's just cleanly separate all the data areas and not try
> to do
> any clever overlapping: the benefit will be minimal, and any system that has
> main
> RAM less than twice of the VO+ZO image sizes is funda
Re: [GIT PULL] move ARM LCD display driver to auxdisplay
On Thu, Apr 28, 2016 at 11:26 AM, Maxime Ripard wrote: > Still, moving it to a "framework" that has been inactive for so long > (and you even mention it in your PR) doesn't seem like the right move. I still think sorting the driver into the right bucket has a value. When/if the Linux LCD support gets an upstream push they will know where to put their stuff: here, and then common stuff can be abstracted. With drivers floating around in misc the situation is even worse. http://lcd-linux.sourceforge.net/ Yours, Linus Walleij
[PATCH v2] drm/rockchip: vop: fix iommu crash with async atomic
After async atomic_commit callback, drm_atomic_clean_old_fb will
cleanup all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.
Fix the problem by reference the fb and unreference it when the fb
actually swap out from vop hardware.
Signed-off-by: Mark Yao
---
Changes in v2:
- fix some format problem.
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 28596e7..8652bb1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -560,6 +560,22 @@ static void vop_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
}
+static int vop_plane_prepare_fb(struct drm_plane *plane,
+ const struct drm_plane_state *new_state)
+{
+ if (plane->state->fb)
+ drm_framebuffer_reference(plane->state->fb);
+
+ return 0;
+}
+
+static void vop_plane_cleanup_fb(struct drm_plane *plane,
+const struct drm_plane_state *old_state)
+{
+ if (old_state->fb)
+ drm_framebuffer_unreference(old_state->fb);
+}
+
static int vop_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -756,6 +772,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
static const struct drm_plane_helper_funcs plane_helper_funcs = {
+ .prepare_fb = vop_plane_prepare_fb,
+ .cleanup_fb = vop_plane_cleanup_fb,
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,
--
1.9.1
Re: [PATCH v2 01/13] staging/android: remove redundant comments on sync_merge_data
>
> From: Gustavo Padovan
>
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Maarten Lankhorst
> Reviewed-by: Daniel Vetter
> ---
> drivers/staging/android/uapi/sync.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/android/uapi/sync.h
> b/drivers/staging/android/uapi/sync.h
> index 7de5d6a..413303d 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -23,9 +23,9 @@
> * @pad: padding for 64-bit alignment, should always be zero
> */
> struct sync_merge_data {
> - charname[32]; /* name of new fence */
> - __s32 fd2; /* fd of second fence */
> - __s32 fence; /* fd on newly created fence */
> + charname[32];
> + __s32 fd2;
> + __s32 fence;
> __u32 flags;
> __u32 pad;
> };
> @@ -33,8 +33,8 @@ struct sync_merge_data {
> /**
> * struct sync_fence_info - detailed fence information
> * @obj_name:name of parent sync_timeline
> - * @driver_name: name of driver implementing the parent
> - * @status: status of the fence 0:active 1:signaled <0:error
> +* @driver_name: name of driver implementing the parent
> +* @status: status of the fence 0:active 1:signaled <0:error
Would you please specify why this hunk is needed, with
fence info not mentioned in commit message?
> * @flags: fence_info flags
> * @timestamp_ns:timestamp of status change in nanoseconds
> */
> --
> 2.5.5
>
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi Hans and Pavel, On Fri, Apr 29, 2016 at 09:31:51AM +0200, Hans Verkuil wrote: > On 04/29/2016 09:15 AM, Pavel Machek wrote: > > Hi! > > > >> On n900, probe finishes ok (verified by adding printks), and the > >> device shows up in /sys, but I don't get /dev/video* or > >> /dev/v4l-subdev*. > >> > >> Other drivers (back and front camera) load ok, and actually work. Any > >> idea what could be wrong? > > > > Ok, so I guess I realized what is the problem: > > > > adp1653 registers itself as a subdev, but there's no device that > > register it as its part. > > > > (ad5820 driver seems to have the same problem). > > > > Is there example "dummy" device I could use, for sole purpose of > > having these devices appear in /dev? They are on i2c, so both can work > > on their own. > > Ah, interesting. This was discussed a little bit during the Media Summit > a few weeks back: > > http://linuxtv.org/news.php?entry=2016-04-20.mchehab > > See section 5: > > "5. DT Bindings for flash & lens controllers > > There are drivers that create their MC topology using the device tree > information, > which works great for entities that transport data, but how to detect entities > that don’t transport data such as flash devices, focusers, etc.? How can > those be > deduced using the device tree? > > Sensor DT node add phandle to focus controller: add generic v4l binding > properties > to reference such devices." > > This wasn't a problem with the original N900 since that didn't use DT AFAIK > and > these devices were loaded explicitly through board code. > > But now you run into the same problem that I have. > > The solution is that sensor devices have to provide phandles to those > controller > devices. And to do that you need to define bindings which is always the hard > part. > > Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section > "Optional endpoint properties". > > Something like: > > controllers: an array of phandles to controller devices associated with this > endpoint such as flash and lens controllers. > > Warning: I'm no DT expert, so this is just a first attempt. > > Platform drivers (omap3isp) will have to add these controller devices to the > list > of subdevs to load asynchronously. I seem to have patches I haven't had time to push back then: http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a> This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here). -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH v4] x86/boot: Warn on future overlapping memcpy() use
* Kees Cook wrote:
> If an overlapping memcpy() is ever attempted, we should at least report
> it, in case it might lead to problems, so it could be changed to a
> memmove() call instead.
>
> Suggested-by: Ingo Molnar
> Signed-off-by: Kees Cook
> ---
> v4:
> - use __memcpy not memcpy since we've already done the check.
> v3:
> - call memmove in addition to doing the warning
> v2:
> - warn about overlapping region
> ---
> arch/x86/boot/compressed/string.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
I think you'll hate this patch some more:
arch/x86/boot/compressed/string.c:68:3: warning: implicit declaration of
function ‘warn’ [-Wimplicit-function-declaration]
:-)
Can we do the trick below? Because misc.h also includes the regular kernel
memcpy
functions, we can remove the decompressor specific __memcpy() - but the
question
is, is it safe to do?
If it's not safe to do, we are playing with fire already I suspect:
arch/x86/boot/compressed/cmdline.c:#include "misc.h"
arch/x86/boot/compressed/early_serial_console.c:#include "misc.h"
arch/x86/boot/compressed/kaslr.c:#include "misc.h"
arch/x86/boot/compressed/misc.c:#include "misc.h"
?
Thanks,
Ingo
arch/x86/boot/compressed/string.c | 31 +--
1 file changed, 1 insertion(+), 30 deletions(-)
diff --git a/arch/x86/boot/compressed/string.c
b/arch/x86/boot/compressed/string.c
index 952510976732..f4b95ed4e7a2 100644
--- a/arch/x86/boot/compressed/string.c
+++ b/arch/x86/boot/compressed/string.c
@@ -6,37 +6,8 @@
* (e.g. FPU ops) in the minimal decompression stub execution environment.
*/
#include "../string.c"
-#include "misc.h"
-
-#ifdef CONFIG_X86_32
-static void *__memcpy(void *dest, const void *src, size_t n)
-{
- int d0, d1, d2;
- asm volatile(
- "rep ; movsl\n\t"
- "movl %4,%%ecx\n\t"
- "rep ; movsb\n\t"
- : "=&c" (d0), "=&D" (d1), "=&S" (d2)
- : "0" (n >> 2), "g" (n & 3), "1" (dest), "2" (src)
- : "memory");
-
- return dest;
-}
-#else
-static void *__memcpy(void *dest, const void *src, size_t n)
-{
- long d0, d1, d2;
- asm volatile(
- "rep ; movsq\n\t"
- "movq %4,%%rcx\n\t"
- "rep ; movsb\n\t"
- : "=&c" (d0), "=&D" (d1), "=&S" (d2)
- : "0" (n >> 3), "g" (n & 7), "1" (dest), "2" (src)
- : "memory");
- return dest;
-}
-#endif
+#include "misc.h"
void *memset(void *s, int c, size_t n)
{
Re: [PATCH v3 0/7] drm: Add fbdev deferred io support to helpers
On Mi, 2016-04-27 at 20:16 +0200, Noralf Trønnes wrote: > I have also added patches that converts qxl and udl to use this > deferred io support. I have only compile tested it, no functional > testing. > I know that qxl is purely a software thing so I could actually test > it, but > I have never used qemu so I'm not keen on spending a lot of time on > that. Tested-by: Gerd Hoffmann
Re: random(4) changes
Am Freitag, 29. April 2016, 03:29:50 schrieb George Spelvin: Hi George, > > 1. the individual bits of a given 32 bit time stamp are independent > > > >(or IID in terms of NIST) > > They're not independent, nor are they identically distributed. That is an interesting statement: you say that the time stamp has holes in it, i.e. some values have zero probability of being selected! Second, you imply that when bit x of a given time stamp has some particular value, bit y can be deduced from bit x. I have not experienced that nor do I see any hints for that claim. > > If they were identically distributed, they'd all have identical > entropy. And there's be no reason to stop at 32 bits. If the high > 32 bits have the same entropy as the low > entropy too?. There is absolutely no limit to the 32 bits. We easily can take the high bits too. But we know (as you mention below), an attacker has more and more knowledge about the selected bits the higher the bit is as he can predict an event with a certain degree of probability. Thus, mixing in the high 32 bits do not hurt here from a mathematical point of view. But from a technical, it hurts: we know that these high 32 bits have hardly any entropy relative to the attacker. Thus, we would mix in bits that do not really help us in the entropy collection. But the processing still requires CPU cycles -- for each interrupt. Thus, to prevent wasting CPU cycles, I think that the high 32 bits should be discarded. But if people say that they want them considered too, I have no problems in adding them > > > 2. show that the maximum entropy of each of the individual bits is equal > > or > > > >more to my entropy estimate I apply. > > I'm not sure what you mean here. When you say "maximum entropy" is that > a non-strict upper bound? > > Or does that mean that at least one bit achieves that maximum? Exactly that -- I have to show that at least one bit out of the 32 bit value reaches that maximum, i.e. one bit has more entropy than my entropy estimate. > > That will be a much more interesting proof. > > > Regarding 1: The time stamp (or cycle counter) is a 32 bit value where > > each of the bits does not depend on the other bits. When considering one > > and only one time stamp value and we look at, say, the first 20 bits, > > there is no way it is clear what the missing 12 bits will be. > > If you deliberately exclude all external data, then a 32-bit > constant is random. (I suggest 17, the "most random number".) > > But that's meaningless. When we talk about "entropy", we are talking > about an attacker's uncertainty about the value. Any other measure is > garbage in, and proiduces nothing but garbage out. Correct. Please attack the, say, low 4 or 5 bits of a high-res timer so that you can predict their values with a certain confidence for the observed events (in the legacy /dev/random, that is a hdd event, a HID event and an interrupt -- all of those events are user-triggerable). If you achieve that, you broke, well, almost all timer based noise sources -- be it the legacy /dev/random, be it OpenBSD, XNU, you name it. Note, I thought I can attack the legacy /dev/random HID noise source using the X11 logic: if one has access to the X11 server, one can see all HID events. I measured its RDTSC time and obtained the respective RDTSC time from the legacy /dev/random event processing. There are about 500,000,000 clock ticks in variations between both measurements. For a ping flood from a VMM host to a virtual machine guest, I get down to 11 bits variations. I even measured RDTSC timers (see my Jitter RNG measurements) in a tight loop where interrupts are immediately to be spotted -- the variations of those interrupts are also in the vicinity of 10 or 11 bits. Regardless of what I am doing, I do not see that I can get below 10 bits of "accuracy" in predicting an RDTSC time stamp of an event processed by the legacy /dev/random. Maybe I am not smart enough for attacking the system. Maybe others are smarter than me and find a way to attack it to get to 5 or 6 bits of accuracy. Yet, this is means there is way more entropy than I need -- this is my first safety margin. Ciao Stephan
Re: [PATCH V6 07/13] PCI: Provide common functions for ECAM mapping
On Fri, Apr 29, 2016 at 3:17 AM, Bjorn Helgaas wrote: > On Fri, Apr 15, 2016 at 07:06:42PM +0200, Tomasz Nowicki wrote: >> From: Jayachandran C >> >> Add config option PCI_GENERIC_ECAM and file drivers/pci/ecam.c to >> provide generic functions for accessing memory mapped PCI config space. >> >> The API is defined in drivers/pci/ecam.h and is written to replace the >> API in drivers/pci/host/pci-host-common.h. The file defines a new >> 'struct pci_config_window' to hold the information related to a PCI >> config area and its mapping. This structure is expected to be used as >> sysdata for controllers that have ECAM based mapping. >> >> Helper functions are provided to setup the mapping, free the mapping >> and to implement the map_bus method in 'struct pci_ops' > > Spec reference: PCI Express Base Specification, rev 3.0, sec 7.2.2. > >> Signed-off-by: Jayachandran C >> --- >> drivers/pci/Kconfig | 3 ++ >> drivers/pci/Makefile | 2 + >> drivers/pci/ecam.c | 137 >> +++ >> drivers/pci/ecam.h | 61 +++ >> 4 files changed, 203 insertions(+) >> create mode 100644 drivers/pci/ecam.c >> create mode 100644 drivers/pci/ecam.h >> >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig >> index 209292e..e930d62 100644 >> --- a/drivers/pci/Kconfig >> +++ b/drivers/pci/Kconfig >> @@ -83,6 +83,9 @@ config HT_IRQ >> config PCI_ATS >> bool >> >> +config PCI_GENERIC_ECAM >> + bool > > "PCI_ECAM" is enough, I think. It's defined by and required by the > spec unless there's some arch-specific interface. Plus, if I Ok. Looking at the comments I think I have to take out generic from all the names - will do this in next version. > understand correctly, this infrastructure supports non-generic ECAM > implementations as well, since the caller supplies "struct > pci_generic_ecam_ops *ops". Yes, the idea was to support ECAM with quirks (and CAM) on both 32 and 64 bit, otherwise it would be too trivial to have a separate implementation. >> config PCI_IOV >> bool "PCI IOV support" >> depends on PCI >> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile >> index 2154092..810aec8 100644 >> --- a/drivers/pci/Makefile >> +++ b/drivers/pci/Makefile >> @@ -55,6 +55,8 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o >> >> obj-$(CONFIG_PCI_STUB) += pci-stub.o >> >> +obj-$(CONFIG_PCI_GENERIC_ECAM) += ecam.o >> + >> obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o >> >> obj-$(CONFIG_OF) += of.o >> diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c >> new file mode 100644 >> index 000..ff04c01 >> --- /dev/null >> +++ b/drivers/pci/ecam.c >> @@ -0,0 +1,137 @@ >> +/* >> + * Copyright 2016 Broadcom >> + * >> + * 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 (the "GPL"). >> + * >> + * This program is distributed in the hope that it will be useful, but >> + * WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + * General Public License version 2 (GPLv2) for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * version 2 (GPLv2) along with this source code. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include "ecam.h" >> + >> +/* >> + * On 64 bit systems, we do a single ioremap for the whole config space >> + * since we have enough virtual address range available. On 32 bit, do an >> + * ioremap per bus. >> + */ >> +static const bool per_bus_mapping = !config_enabled(CONFIG_64BIT); >> + >> +/* >> + * Create a PCI config space window >> + * - reserve mem region >> + * - alloc struct pci_config_window with space for all mappings >> + * - ioremap the config space >> + */ >> +struct pci_config_window *pci_generic_ecam_create(struct device *dev, >> + phys_addr_t addr, u8 bus_start, u8 bus_end, > > Can you take pointers to struct resources here instead of addr, > bus_start, and bus_end? The caller probably has them already, and > then you could add a useful printk like: > > dev_info(dev, "ECAM for %pR at %pR\n", busn_res, mmio_res); > > Would have to be careful about the struct resource lifetimes though. Yes, I had thought of this. The reason I did not go down that path was that we are using request_mem_region() which takes the address and creates a resource .internally. Beyond that, as you noted, the ownership and lifetime is slightly more complex. Either the calling code has to allocate the resource and handoff, or the ecam code has to make a copy of the resource. I would go with copy since it is much more simple to use. Since resource based API seems to be preferred, I will switch to passing bus and mmio resource and will use request_resource_conflict() to a
[tip:x86/boot] x86/KASLR: Handle kernel relocations above 2G correctly
Commit-ID: 6f9af75faa1df61e1ee5bea8a787a90605bb528d
Gitweb: http://git.kernel.org/tip/6f9af75faa1df61e1ee5bea8a787a90605bb528d
Author: Baoquan He
AuthorDate: Thu, 28 Apr 2016 17:09:03 -0700
Committer: Ingo Molnar
CommitDate: Fri, 29 Apr 2016 09:58:26 +0200
x86/KASLR: Handle kernel relocations above 2G correctly
When processing the relocation table, the offset used to calculate the
relocation is an 'int'. This is sufficient for calculating the physical
address of the relocs entry on 32-bit systems and on 64-bit systems when
the relocation is under 2G.
To handle relocations above 2G (seen in situations like kexec, netboot, etc),
this offset needs to be calculated using a 'long' to avoid wrapping and
miscalculating the relocation.
Signed-off-by: Baoquan He
[ Rewrote the changelog. ]
Signed-off-by: Kees Cook
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Young
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Vivek Goyal
Cc: Yinghai Lu
Cc: lasse.col...@tukaani.org
Link:
http://lkml.kernel.org/r/1461888548-32439-2-git-send-email-keesc...@chromium.org
Signed-off-by: Ingo Molnar
Signed-off-by: Ingo Molnar
---
arch/x86/boot/compressed/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 6dde6cc..4514514 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -232,7 +232,7 @@ static void handle_relocations(void *output, unsigned long
output_len)
* So we work backwards from the end of the decompressed image.
*/
for (reloc = output + output_len - sizeof(*reloc); *reloc; reloc--) {
- int extended = *reloc;
+ long extended = *reloc;
extended += map;
ptr = (unsigned long)extended;
Re: [PATCH] Use existing helper to convert "on/off" to boolean
On Fri 29-04-16 13:47:04, Minfei Huang wrote:
> It's more convenient to use existing function helper to convert string
> "on/off" to boolean.
But kstrtobool in linux-next only does "This routine returns 0 iff the
first character is one of 'Yy1Nn0'" so it doesn't know about on/off.
Or am I missing anything?
>
> Signed-off-by: Minfei Huang
> ---
> lib/kstrtox.c| 2 +-
> mm/page_alloc.c | 9 +
> mm/page_poison.c | 8 +---
> 3 files changed, 3 insertions(+), 16 deletions(-)
>
> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
> index d8a5cf6..3c66fc4 100644
> --- a/lib/kstrtox.c
> +++ b/lib/kstrtox.c
> @@ -326,7 +326,7 @@ EXPORT_SYMBOL(kstrtos8);
> * @s: input string
> * @res: result
> *
> - * This routine returns 0 iff the first character is one of 'Yy1Nn0', or
> + * This routine returns 0 if the first character is one of 'Yy1Nn0', or
> * [oO][NnFf] for "on" and "off". Otherwise it will return -EINVAL. Value
> * pointed to by res is updated upon finding a match.
> */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 59de90d..d31426d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -513,14 +513,7 @@ static int __init early_debug_pagealloc(char *buf)
> {
> if (!buf)
> return -EINVAL;
> -
> - if (strcmp(buf, "on") == 0)
> - _debug_pagealloc_enabled = true;
> -
> - if (strcmp(buf, "off") == 0)
> - _debug_pagealloc_enabled = false;
> -
> - return 0;
> + return kstrtobool(buf, &_debug_pagealloc_enabled);
> }
> early_param("debug_pagealloc", early_debug_pagealloc);
>
> diff --git a/mm/page_poison.c b/mm/page_poison.c
> index 479e7ea..1eae5fa 100644
> --- a/mm/page_poison.c
> +++ b/mm/page_poison.c
> @@ -13,13 +13,7 @@ static int early_page_poison_param(char *buf)
> {
> if (!buf)
> return -EINVAL;
> -
> - if (strcmp(buf, "on") == 0)
> - want_page_poisoning = true;
> - else if (strcmp(buf, "off") == 0)
> - want_page_poisoning = false;
> -
> - return 0;
> + return strtobool(buf, &want_page_poisoning);
> }
> early_param("page_poison", early_page_poison_param);
>
> --
> 2.6.3
>
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] iio: accel: Add support for Freescale MMA7660FC
On Fri, 29 Apr 2016, Constantin Musca wrote:
> Minimal implementation of an IIO driver for the Freescale
> MMA7660FC 3-axis accelerometer. Datasheet:
> http://www.freescale.com.cn/files/sensors/doc/data_sheet/MMA7660FC.pdf
comments below
> Includes:
> - ACPI support;
> - read_raw for x,y,z axes;
> - reading and setting the scale (range) parameter.
> - power management
>
> Signed-off-by: Constantin Musca
> ---
> drivers/iio/accel/Kconfig | 10 ++
> drivers/iio/accel/Makefile | 2 +
> drivers/iio/accel/mma7660.c | 275
>
> 3 files changed, 287 insertions(+)
> create mode 100644 drivers/iio/accel/mma7660.c
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index e4a758c..2e6a0e6 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -54,6 +54,16 @@ config HID_SENSOR_ACCEL_3D
> To compile this driver as a module, choose M here: the
> module will be called hid-sensor-accel-3d.
>
> +config MMA7660
> + tristate "Freescale MMA7660FC 3-Axis Accelerometer Driver"
> + depends on I2C
> + help
> + Say yes here to get support for the Freescale MMA7660FC 3-Axis
> + accelerometer.
> +
> + Choosing M will build the driver as a module. If so, the module
> + will be called mma7660.
> +
> config IIO_ST_ACCEL_3AXIS
> tristate "STMicroelectronics accelerometers 3-Axis Driver"
> depends on (I2C || SPI_MASTER) && SYSFS
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 71b6794..ba1165f 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -15,6 +15,8 @@ obj-$(CONFIG_MMA7455) += mma7455_core.o
> obj-$(CONFIG_MMA7455_I2C)+= mma7455_i2c.o
> obj-$(CONFIG_MMA7455_SPI)+= mma7455_spi.o
>
> +obj-$(CONFIG_MMA7660)+= mma7660.o
> +
> obj-$(CONFIG_MMA8452)+= mma8452.o
>
> obj-$(CONFIG_MMA9551_CORE) += mma9551_core.o
> diff --git a/drivers/iio/accel/mma7660.c b/drivers/iio/accel/mma7660.c
> new file mode 100644
> index 000..9aad91d
> --- /dev/null
> +++ b/drivers/iio/accel/mma7660.c
> @@ -0,0 +1,275 @@
> +/**
> + * Freescale MMA7660FC 3-Axis Accelerometer
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for Freescale MMA7660FC; 7-bit I2C address: 0x4c.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MMA7660_DRIVER_NAME "mma7660"
> +
> +#define MMA7660_REG_XOUT 0x00
> +#define MMA7660_REG_YOUT 0x01
> +#define MMA7660_REG_ZOUT 0x02
> +#define MMA7660_REG_OUT_BIT_ALERTBIT(6)
> +
> +#define MMA7660_REG_MODE 0x07
> +#define MMA7660_REG_MODE_BIT_MODEBIT(0)
> +#define MMA7660_REG_MODE_BIT_TON BIT(2)
> +
> +#define MMA7660_MODE_STANDBY 0
> +#define MMA7660_MODE_ACTIVE 1
those two could be an enum?
> +
> +#define MMA7660_I2C_READ_RETRIES 5
> +
> +/*
> + * The accelerometer has one measurement range:
> + *
> + * -1.5g - +1.5g (6-bit, signed)
> + *
> + * scale1 = (1.5 + 1.5) * 9.81 / (2^6 - 1) = 0.467142857
why named scale1?
> + */
> +
> +#define MMA7660_SCALE_AVAIL "0.467142857"
> +
> +const int mma7660_nscale = 467142857;
> +
> +#define MMA7660_CHANNEL(reg, axis) { \
> + .type = IIO_ACCEL, \
> + .address = reg, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +}
> +
> +static const struct iio_chan_spec mma7660_channels[] = {
> + MMA7660_CHANNEL(MMA7660_REG_XOUT, X),
> + MMA7660_CHANNEL(MMA7660_REG_YOUT, Y),
> + MMA7660_CHANNEL(MMA7660_REG_ZOUT, Z),
> +};
> +
> +struct mma7660_data {
> + struct i2c_client *client;
> + struct mutex lock;
> + u8 mode;
use enum here
> +};
> +
> +static IIO_CONST_ATTR(in_accel_scale_available, MMA7660_SCALE_AVAIL);
> +
> +static struct attribute *mma7660_attributes[] = {
> + &iio_const_attr_in_accel_scale_available.dev_attr.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group mma7660_attribute_group = {
> + .attrs = mma7660_attributes
> +};
> +
> +static int mma7660_set_mode(struct mma7660_data *data, u8 mode)
> +{
> + int ret;
> + struct i2c_client *client = data->client;
> +
> + if (mode > 1)
> + return -EINVAL;
check can probably be dropped
> +
> + if (mode == data->mode)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(client, MMA7660_REG_MODE);
> + if (ret < 0) {
> + dev_err(&client->dev, "failed to change sensor mode\n");
to read
> + return ret;
> + }
> +
> + if (mode == MMA7660_MODE_ACTIVE) {
> + ret &= ~MMA7660_REG_MODE_BI
Re: [RFC v5 3/4] gpio: move clps711x, moxart, ts4800 and gpio-ge into gpio-generic
On Fri, Apr 29, 2016 at 3:53 AM, Christian Lamparter
wrote:
> This patch integrates these GPIO drivers into gpio-generic.
>
>
> +static int clps711x_parse_dt(struct platform_device *pdev,
> +struct bgpio_pdata *pdata,
> +unsigned long *flags)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + int id = np ? of_alias_get_id(np, "gpio") : pdev->id;
> + struct resource *res;
> +
> + if ((id < 0) || (id > 4))
> + return -ENODEV;
> +
> + /* PORTE is 3 lines only */
> + if (id == 4)
> + pdata->ngpio = 3;
> +
> + pdata->base = id * 8;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + res->name = "dat";
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -EINVAL;
> +
> + /* PORTD is inverted logic for direction register */
> + res->name = (id == 3) ? "dirin" : "dirout";
> + return 0;
> +}
> +
I think the three below have enough in common to reorganize data
structure and use one parse function.
So, instead of providing just parsing function, something like
ngpios (0 — read from property)
resource size
start, end pairs for dat/set/dirin.
flags
Have no idea if it's possible to re-use this approach for case above.
> +static int ge_parse_dt(struct platform_device *pdev,
> + struct bgpio_pdata *pdata,
> + unsigned long *flags)
> +{
> + struct device_node *np = pdev->dev.of_node;
> +
> + struct resource *res;
> + struct resource nres[] = {
> + DEFINE_RES_MEM_NAMED(0, 1, "dat"),
> + DEFINE_RES_MEM_NAMED(0, 1, "set"),
> + DEFINE_RES_MEM_NAMED(0, 1, "dirin"),
> + };
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res || resource_size(res) != 0x24)
> + return -EINVAL;
> +
> + nres[0].start = res->start + 0x04;
> + nres[0].end = nres[0].start + 3;
> + nres[1].start = res->start + 0x08;
> + nres[1].end = nres[1].start + 3;
> + nres[2].start = res->start + 0x00;
> + nres[2].end = nres[2].start + 3;
> + *flags |= BGPIOF_BIG_ENDIAN_BYTE_ORDER;
> + pdata->label = devm_kstrdup(&pdev->dev, np->full_name, GFP_KERNEL);
> + if (!pdata->label)
> + return -ENOMEM;
> +
> + if (of_device_is_compatible(np, "ge,imp3a-gpio"))
> + pdata->ngpio = 16;
> + else if (of_device_is_compatible(np, "gef,sbc310-gpio"))
> + pdata->ngpio = 6;
> + else if (of_device_is_compatible(np, "gef,sbc610-gpio"))
> + pdata->ngpio = 19;
> +
> + return platform_device_add_resources(pdev, nres, ARRAY_SIZE(nres));
> +}
> +
> +static int moxart_parse_dt(struct platform_device *pdev,
> + struct bgpio_pdata *pdata,
> + unsigned long *flags)
> +{
> + struct resource *res;
> + struct resource nres[] = {
> + DEFINE_RES_MEM_NAMED(0, 1, "dat"),
> + DEFINE_RES_MEM_NAMED(0, 1, "set"),
> + DEFINE_RES_MEM_NAMED(0, 1, "dirout"),
> + };
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res || resource_size(res) != 0xc)
> + return -EINVAL;
> +
> + pdata->label = "moxart-gpio";
> + *flags |= BGPIOF_READ_OUTPUT_REG_SET;
> + nres[0].start = res->start + 0x04;
> + nres[0].end = nres[0].start + 3;
> + nres[1].start = res->start + 0x00;
> + nres[1].end = nres[1].start + 3;
> + nres[2].start = res->start + 0x08;
> + nres[2].end = nres[2].start + 3;
> + return platform_device_add_resources(pdev, nres, ARRAY_SIZE(nres));
> +}
> +
> +static int ts4800_parse_dt(struct platform_device *pdev,
> + struct bgpio_pdata *pdata,
> + unsigned long *flags)
> +{
> + int err;
> + struct resource *res;
> + struct resource nres[] = {
> + DEFINE_RES_MEM_NAMED(0, 1, "dat"),
> + DEFINE_RES_MEM_NAMED(0, 1, "set"),
> + DEFINE_RES_MEM_NAMED(0, 1, "dirout"),
> + };
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res || resource_size(res) != 0x6)
> + return -EINVAL;
> +
> + nres[0].start = res->start;
> + nres[0].end = nres[0].start + 1;
> + nres[1].start = res->start + 0x02;
> + nres[1].end = nres[1].start + 1;
> + nres[2].start = res->start + 0x04;
> + nres[2].end = nres[2].start + 1;
> +
> + err = of_property_read_u32(pdev->dev.of_node, "ngpios",
> &pdata->ngpio);
> + if (err == -EINVAL)
> + pdata->ngpio = 16;
> + else if (err)
> + return err;
> +
> + return platform_device_a
Re: Regression of v4.6-rc vs. v4.5: hangs after a few minutes after boot
On Apr 26 Stefan Richter wrote: > v4.6-rc solidly hangs after a short while after boot, login to X11, and > doing nothing much remarkable on the just brought up X desktop. > > Hardware: x86-64, E3-1245 v3 (Haswell), > mainboard Supermicro X10SAE, > using integrated Intel graphics (HD P4600, i915 driver), > C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI, > Intel LAN (i217, igb driver), > several IEEE 1394 controllers, some of them behind > PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI, Tundra) > and one PCI-to-CardBus bridge (Ricoh) > > kernel.org kernel, Gentoo Linux userland > > 1. known good: v4.5-rc5 (gcc 4.9.3) >known bad: v4.6-rc2 (gcc 4.9.3), only tried one time > > 2. known good: v4.5.2 (gcc 5.2.0) >known bad: v4.6-rc5 (gcc 5.2.0), only tried one time > > I will send my linux-4.6-rc5/.config in a follow-up message. After it proved impossible to capture an oops through netconsole, I started git bisect. This will apparently take almost a week, as git estimated 13 bisection steps and I will be allowing about 12 hours of uptime as a sign for a good kernel. (In my four or five tests of bad kernels before I started bisection, they hung after 3 minutes...5.5 hours uptime, with no discernible difference in workload. Maybe 12 h cutoff is even too short...) -- Stefan Richter -==- -=-- ===-= http://arcgraph.de/sr/
Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer
* Kees Cook wrote: > I don't agree. We do still have embedded systems running x86 kernels, and we > have cases where we're running multiple kernels in memory (like kdump). I > think > the memory savings is worth the complexity, especially since the complexity > is > being reduced up by this patch. [...] Hm, so can we quantify it, how much are the temporary memory savings in practice? I'd like to see actual vmlinuz numbers with say a defconfig and with a distro config. Small systems tend to have smaller kernel images, so the temporary savings tend to be smaller as well. There's no long term loss, we'd still recover all memory not used by the resulting kernel image and make it usable as free RAM. So the only question is the temporary memory allocation size of the decompression step. > [...] But that's not all: > > If we moved the compressed kernel after the buffer, the only thing > we'd do would be taking up more memory. We'd still have the head_*.S > complexity of handling the relocation and handling the copy, we'd > still have the extraction, etc, etc. The only thing would be literally > changing extract_offset to INIT_SIZE. Everything else would be the > same. Yes - but arguing about all this code would cause a lot fewer headaches, for me at least! Also, I think once we've simplified the whole model of decompression, we can improve on the structure even more. > If we moved the decompressed kernel after the compressed kernel, (ignoring > KASLR > for a moment) then we'd end up in a confusing situation where the kernel > would > be running somewhere other than where the boot loader asked it to load. I > don't > even want to think about the weird bug reports we might get from a change > like > that from old or weird loaders. Well, 'where the boot loader asked it to load' in this case is essentially the z_extract_offset .globl, isn't it? But how to use that value is a mostly x86 kernel internal matter - in fact there's even an inversion step between the 32-bit and 64-bit value. Is there any other boot loader environment component I missed? Thanks, Ingo
Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > Currently autoconf spends 25ms (on my laptop) testing if the UART
> > exported to it by KVM is an 8250 without FIFO and/or with strange
> > quirks, which it obviously isn't. Assume it is exported to us by a
> > hypervisor, it's a normal, working 16550A.
> >
> > Signed-off-by: Richard W.M. Jones
> > ---
> > drivers/tty/serial/8250/8250_port.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250_port.c
> > b/drivers/tty/serial/8250/8250_port.c
> > index 00ad2637..de19924 100644
> > --- a/drivers/tty/serial/8250/8250_port.c
> > +++ b/drivers/tty/serial/8250/8250_port.c
> > @@ -1171,6 +1171,13 @@ static void autoconfig(struct uart_8250_port *up)
> > if (!port->iobase && !port->mapbase && !port->membase)
> > return;
> >
> > + /* Hypervisors always export working 16550A devices. */
> > + if (cpu_has_hypervisor) {
> > + up->port.type = PORT_16550A;
> > + up->capabilities |= UART_CAP_FIFO;
> > + return;
> > + }
>
> Have you audited vmware, virtualbox, and everyone else that provides a
> virtual uart device that it will work properly here?
>
> qemu isn't all the world :)
Attached below is a slightly different approach. If the user passes a
special flag on the kernel command line then we force 16550A and avoid
the 25ms delay. Since the user chooses the flag, any concerns about
the behaviour of the hypervisor or use of VFIO should be moot.
Rich.
>From 5694addf0e05de9c842274be8392ebce5dc24280 Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones"
Date: Thu, 28 Apr 2016 23:08:54 +0100
Subject: [PATCH] 8250: Allow user to force 16550A UART and avoid probing.
Currently autoconf spends 25ms (on my laptop) testing the UART.
Allow the user to avoid this delay if they know that all serial ports
(eg on a virtual machine) are ordinary 16550A. The user does this by
passing '8250_base.really_16550a' on the command line.
Signed-off-by: Richard W.M. Jones
---
drivers/tty/serial/8250/8250_port.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 00ad2637..ac92f55 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -53,6 +53,10 @@
#define DEBUG_AUTOCONF(fmt...) do { } while (0)
#endif
+static bool really_16550a;
+module_param(really_16550a, bool, 0644);
+MODULE_PARM_DESC(really_16550a, "Don't probe, assume 16550A");
+
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
/*
@@ -1171,6 +1175,12 @@ static void autoconfig(struct uart_8250_port *up)
if (!port->iobase && !port->mapbase && !port->membase)
return;
+ if (really_16550a) {
+ up->port.type = PORT_16550A;
+ up->capabilities |= UART_CAP_FIFO;
+ return;
+ }
+
DEBUG_AUTOCONF("ttyS%d: autoconf (0x%04lx, 0x%p): ",
serial_index(port), port->iobase, port->membase);
--
2.7.4
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
Re: [PATCH v2 02/13] staging/android: drop sync_file_install() and sync_file_put()
>
> From: Gustavo Padovan
>
> These two functions are just wrappers for one line functions, they
> call fd_install() and fput() respectively, so just get rid of them
> and use fd_install() and fput() directly for more simplicity.
>
Given sync_file is not file, I don't see that simplicity is worth of
the change of 20+ lines.
Can you please specify the disadvantages of the wrappers?
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
> ---
> drivers/staging/android/sync.c | 20
> drivers/staging/android/sync.h | 19 ---
> drivers/staging/android/sync_debug.c | 4 ++--
> 3 files changed, 6 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index f9c6094..b965e2a 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -216,18 +216,6 @@ err:
> }
> EXPORT_SYMBOL(sync_file_fdget);
>
> -void sync_file_put(struct sync_file *sync_file)
> -{
> - fput(sync_file->file);
> -}
> -EXPORT_SYMBOL(sync_file_put);
> -
> -void sync_file_install(struct sync_file *sync_file, int fd)
> -{
> - fd_install(fd, sync_file->file);
> -}
> -EXPORT_SYMBOL(sync_file_install);
> -
> static void sync_file_add_pt(struct sync_file *sync_file, int *i,
>struct fence *fence)
> {
> @@ -469,15 +457,15 @@ static long sync_file_ioctl_merge(struct sync_file
> *sync_file,
> goto err_put_fence3;
> }
>
> - sync_file_install(fence3, fd);
> - sync_file_put(fence2);
> + fd_install(fd, fence3->file);
> + fput(fence2->file);
> return 0;
>
> err_put_fence3:
> - sync_file_put(fence3);
> + fput(fence3->file);
>
> err_put_fence2:
> - sync_file_put(fence2);
> + fput(fence2->file);
>
> err_put_fd:
> put_unused_fd(fd);
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index d2a1734..c45cc7b 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -203,25 +203,6 @@ struct sync_file *sync_file_merge(const char *name,
> */
> struct sync_file *sync_file_fdget(int fd);
>
> -/**
> - * sync_file_put() - puts a reference of a sync_file
> - * @sync_file: sync_file to put
> - *
> - * Puts a reference on @sync_fence. If this is the last reference, the
> - * sync_fil and all it's sync_pts will be freed
> - */
> -void sync_file_put(struct sync_file *sync_file);
> -
> -/**
> - * sync_file_install() - installs a sync_file into a file descriptor
> - * @sync_file: sync_file to install
> - * @fd: file descriptor in which to install the fence
> - *
> - * Installs @sync_file into @fd. @fd's should be acquired through
> - * get_unused_fd_flags(O_CLOEXEC).
> - */
> -void sync_file_install(struct sync_file *sync_file, int fd);
> -
> #ifdef CONFIG_DEBUG_FS
>
> void sync_timeline_debug_add(struct sync_timeline *obj);
> diff --git a/drivers/staging/android/sync_debug.c
> b/drivers/staging/android/sync_debug.c
> index 5a7ec58..e4b0e41 100644
> --- a/drivers/staging/android/sync_debug.c
> +++ b/drivers/staging/android/sync_debug.c
> @@ -272,12 +272,12 @@ static long sw_sync_ioctl_create_fence(struct
> sw_sync_timeline *obj,
>
> data.fence = fd;
> if (copy_to_user((void __user *)arg, &data, sizeof(data))) {
> - sync_file_put(sync_file);
> + fput(sync_file->file);
> err = -EFAULT;
> goto err;
> }
>
> - sync_file_install(sync_file, fd);
> + fd_install(fd, sync_file->file);
>
> return 0;
>
> --
> 2.5.5
>
>
Re: [PATCH] clk: imx: fix ahb clock mux 1
Hello, $Subject ~= s/imx/imx7/ Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH] usbip: vudc: fix Kconfig dependencies
Hi,
On 04/28/2016 02:42 PM, Arnd Bergmann wrote:
> With the addition of VUDC, the USBIP stack can now be used on
> configurations without USB host support, but trying to build
Not exactly. This is the goal but unfortunately for now this will not
work... Most of USB_IP common functions operates on urbs for now because
what USB protocol is sending us is really an serialized URB.
That's why we are also using urbs so we need urb_alloc() and urb_free()
routines which are a part of USB host side support. You may disable all
host side controllers but host side support must remind enabled for now:(
I have a plan to refactor USBIP code and remove those but for now vudc
needs those functions.
> it with USB gadget support disabled fails with
>
> drivers/usb/built-in.o: In function `vep_dequeue':
> vudc_main.c:(.text+0xa6ddc): undefined reference to
> `usb_gadget_giveback_request'
> drivers/usb/built-in.o: In function `nuke':
> vudc_main.c:(.text+0xa6ea8): undefined reference to
> `usb_gadget_giveback_request'
> drivers/usb/built-in.o: In function `vudc_device_reset':
> vudc_main.c:(.text+0xa720c): undefined reference to `usb_gadget_udc_reset'
> drivers/usb/built-in.o: In function `vudc_probe':
>
> This addresses both issues, by changing the dependency for USBIP_CORE
> to USB_COMMON, and adding additional dependencies on USB or USB_GADGET
> for the individual portions as needed.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 9360575c5837 ("usbip: vudc: Add vudc to Kconfig")
> ---
> drivers/usb/usbip/Kconfig | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/usbip/Kconfig b/drivers/usb/usbip/Kconfig
> index ebf4ff050890..17646b25343f 100644
> --- a/drivers/usb/usbip/Kconfig
> +++ b/drivers/usb/usbip/Kconfig
> @@ -1,6 +1,6 @@
> config USBIP_CORE
> tristate "USB/IP support"
> - depends on USB && NET
> + depends on USB_COMMON && NET
> ---help---
> This enables pushing USB packets over IP to allow remote
> machines direct access to USB devices. It provides the
> @@ -16,7 +16,7 @@ config USBIP_CORE
>
> config USBIP_VHCI_HCD
> tristate "VHCI hcd"
> - depends on USBIP_CORE
> + depends on USBIP_CORE && USB
> ---help---
> This enables the USB/IP virtual host controller driver,
> which is run on the remote machine.
> @@ -26,7 +26,7 @@ config USBIP_VHCI_HCD
>
> config USBIP_HOST
> tristate "Host driver"
> - depends on USBIP_CORE
> + depends on USBIP_CORE && USB
> ---help---
> This enables the USB/IP host driver, which is run on the
> machine that is sharing the USB devices.
> @@ -36,7 +36,7 @@ config USBIP_HOST
>
> config USBIP_VUDC
> tristate "VUDC driver"
> - depends on USBIP_CORE
> + depends on USBIP_CORE && USB_GADGET
So having in mind what I wrote you above about urs I would suggest
changing this line to:
depends on USBIP_CORE && USB_GADGET && USB
And we can remove this in a future when we will refactor usbip code.
Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
Re: efi_enabled(EFI_PARAVIRT) use
On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote: > With considerable pain we just got rid of paravirt_enabled() in the > x86 tree, and Xen is now reintroducing it in the EFI code. I think Matt is working towards removing EFI_PARAVIRT but he'll comment himself when he wakes up... :) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: [PATCH v3 0/2] phy: rcar-gen2, rcar-gen3-usb2: add fallback binding
On Thursday 07 April 2016 03:17 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 25 March 2016 07:39 AM, Simon Horman wrote: >> On Mon, Mar 07, 2016 at 10:58:39AM +0900, Simon Horman wrote: >>> Add fallback compatibility strings for rcar phy drivers. >>> >>> In the case of Renesas R-Car hardware we know that there are generations of >>> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the >>> relationship between IP blocks might be. For example, I believe that >>> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a >>> descendant of the former or vice versa. >>> >>> We can, however, by examining the documentation and behaviour of the >>> hardware at run-time observe that the current driver implementation appears >>> to be compatible with the IP blocks on SoCs within a given generation. >>> >>> For the above reasons and convenience when enabling new SoCs a >>> per-generation fallback compatibility string scheme being adopted for >>> drivers for Renesas SoCs. >> >> Hi Kishon, >> >> I am wondering if you could consider applying this series. > > This doesn't appear to be a fix. So will be queuing this for the next merge > window. merged, thanks. -Kishon > > Thanks > Kishon > >> >> Thanks! >> >>> >>> Changes in v3: >>> * Added Acks >>> * Corrected whitespace in examples >>> >>> Changes in v2: >>> * Update new compatibility strings to match the preferred scheme for >>> ordering elements >>> * Rebase >>> >>> Simon Horman (2): >>> phy: rcar-gen2: add fallback binding >>> phy: rcar-gen3-usb2: add fallback binding >>> >>> Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 8 +++- >>> Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 >>> -- >>> drivers/phy/phy-rcar-gen2.c | 1 + >>> drivers/phy/phy-rcar-gen3-usb2.c | 1 + >>> 4 files changed, 17 insertions(+), 3 deletions(-) >>> >>> -- >>> 2.1.4 >>>
Re: [PATCH v2] phy: rcar-gen3-usb2, rcar-gen2: Use ARCH_RENESAS
On Friday 25 March 2016 07:42 AM, Simon Horman wrote: > On Mon, Mar 07, 2016 at 09:01:48AM +0100, Geert Uytterhoeven wrote: >> On Mon, Mar 7, 2016 at 2:14 AM, Simon Horman >> wrote: >>> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. >>> A now redundant dependency on OF is also dropped. >>> >>> This is part of an ongoing process to migrate from ARCH_SHMOBILE to >>> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more >>> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. >>> >>> Signed-off-by: Simon Horman >>> Acked-by: Yoshihiro Shimoda >> >> Acked-by: Geert Uytterhoeven > > Hi Kishon, > > I am wondering if you could consider applying this series too. merged now. Thanks Kishon > > Thanks in advance! >
Re: [PATCH] mtd: nand: gpmi: get correct free oob space
Hi Han, On Wed, 13 Apr 2016 00:43:51 +0200 Boris Brezillon wrote: > Hi Han, > > On Tue, 12 Apr 2016 17:06:33 -0500 > Han Xu wrote: > > > change the way to calculate pagesize to get correct free oob space for > > legacy_set_geometry function. > > Are you sure it's safe to expose free OOB bytes in this case? Do you > know why it wasn't done before? You did not answer this question. Do you want me to drop this patch. If that's not the case, can you confirm it does not break platforms that didn't have those free OOB bytes exposed before this change. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH] efi: Remove unnecessary (and buggy) .memmap initialization from the Xen EFI driver
* tip-bot for Matt Fleming wrote:
> Commit-ID: 884f4f66ffd6ffe632f3a8be4e6d10a858afdc37
> Gitweb: http://git.kernel.org/tip/884f4f66ffd6ffe632f3a8be4e6d10a858afdc37
> Author: Matt Fleming
> AuthorDate: Mon, 25 Apr 2016 21:06:39 +0100
> Committer: Ingo Molnar
> CommitDate: Thu, 28 Apr 2016 11:33:51 +0200
>
> efi: Remove global 'memmap' EFI memory map
>
> Abolish the poorly named EFI memory map, 'memmap'. It is shadowed by a
> bunch of local definitions in various files and having two ways to
> access the EFI memory map ('efi.memmap' vs. 'memmap') is rather
> confusing.
>
> Furthermore, IA64 doesn't even provide this global object, which has
> caused issues when trying to write generic EFI memmap code.
>
> Replace all occurrences with efi.memmap, and convert the remaining
> iterator code to use for_each_efi_mem_desc().
>
> Signed-off-by: Matt Fleming
> Reviewed-by: Ard Biesheuvel
> Cc: Borislav Petkov
> Cc: Luck, Tony
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: linux-...@vger.kernel.org
> Link:
> http://lkml.kernel.org/r/1461614832-17633-8-git-send-email-m...@codeblueprint.co.uk
> Signed-off-by: Ingo Molnar
> ---
> arch/x86/platform/efi/efi.c| 84
> +-
> drivers/firmware/efi/arm-init.c| 20 -
> drivers/firmware/efi/arm-runtime.c | 12 +++---
> drivers/firmware/efi/efi.c | 2 +-
> drivers/firmware/efi/fake_mem.c| 40 +-
> include/linux/efi.h| 5 +--
> 6 files changed, 85 insertions(+), 78 deletions(-)
So this commit triggered the follwing build warning on x86 64-bit allyesconfig:
In file included from ./include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/compiler.h:203,
from include/asm-generic/bug.h:4,
from ./arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from drivers/xen/efi.c:21:
include/linux/stddef.h:7:14: warning: initialization makes integer from pointer
without a cast [-Wint-conversion]
#define NULL ((void *)0)
^
drivers/xen/efi.c:319:30: note: in expansion of macro ‘NULL’
.memmap = NULL, /* Not used under Xen. */
^
CC drivers/gpu/drm/i915/intel_acpi.o
include/linux/stddef.h:7:14: note: (near initialization for
‘efi_xen.memmap.phys_map’)
#define NULL ((void *)0)
^
drivers/xen/efi.c:319:30: note: in expansion of macro ‘NULL’
.memmap = NULL, /* Not used under Xen. */
^
drivers/xen/efi.c:290:47: warning: missing braces around initializer
[-Wmissing-braces]
static const struct efi efi_xen __initconst = {
^
drivers/xen/efi.c:290:47: note: (near initialization for ‘efi_xen’)
It's this initialization in drivers/xen/efi.c:
static const struct efi efi_xen __initconst = {
...
.memmap = NULL, /* Not used under Xen. */
...
which was forgotten about, as .memmap now is an embedded struct:
struct efi_memory_map memmap;
We can remove this initialization - it's an EFI core internal data structure
plus
it's not used in the Xen driver anyway.
Signed-off-by: Ingo Molnar
---
drivers/xen/efi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index be7e56a338e8..e9d2135445c1 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -316,7 +316,6 @@ static const struct efi efi_xen __initconst = {
.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
.reset_system = NULL, /* Functionality provided by Xen. */
.set_virtual_address_map = NULL, /* Not used under Xen. */
- .memmap = NULL, /* Not used under Xen. */
.flags= 0 /* Initialized later. */
};
Re: klp: make object/func-walking helpers more robust
On Thu, 28 Apr 2016, Jessica Yu wrote: > > #define klp_for_each_object(patch, obj) \ > > - for (obj = patch->objs; obj->funcs; obj++) > > + for (obj = patch->objs; obj->funcs || obj->name; obj++) > > Remember that for patches to vmlinux, obj->name and obj->mod will also > both be NULL. So if someone happens to forget to fill in obj->funcs > for a vmlinux patch, we won't catch that case here. Perhaps we need a > better way of determining whether we've reached the end of the array, > or determining that the struct is truly empty.. I'd rather not over-compilcate it. Admittedly, the change in the termination condition catches most of the errors made by the patch author, but not all. But there are many other places in the kernel where inserting an empty item into the middle of statically initialized array will make the whole thing explode, so let's not try to be more clever than necessary. I plan to queue Miroslav's patch unless there are serious objections raised. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller
On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote:
[...]
> > +static int pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root,
> > + struct acpi_pci_generic_root_info *ri)
> > +{
> > + u16 seg = root->segment;
> > + u8 bus_start = root->secondary.start;
> > + u8 bus_end = root->secondary.end;
> > + struct pci_config_window *cfg;
> > + struct mcfg_entry *e;
> > + phys_addr_t addr;
> > + int err = 0;
> > +
> > + mutex_lock(&pci_mcfg_lock);
>
> What does this lock protect? The pci_mcfg_list should already be
> initialized by the time we get there, and it should be immutable for
> the life of the system. In fact, I would prefer if we could just
> search the static table itself whenever we need it rather than caching
> it in our own list. But I don't think we can easily do that because
> acpi_table_parse() is __init.
>
> > + e = pci_mcfg_lookup(seg, bus_start);
>
> I would argue that we should check for _CBA first, and fall back to
> MCFG if _CBA doesn't exist.
>
> > + if (!e) {
> > + addr = acpi_pci_root_get_mcfg_addr(root->device->handle);
>
> IMO, acpi_pci_root_get_mcfg_addr() is misnamed. It should be
> acpi_pci_config_base_addr() or similar. It definitely is not related
> to MCFG. Not your fault, obviously.
>
> > + if (addr == 0) {
> > + pr_err(PREFIX"%04x:%02x-%02x bus range error\n",
> > + seg, bus_start, bus_end);
> > + err = -ENOENT;
> > + goto err_out;
> > + }
> > + } else {
> > + if (bus_start != e->bus_start) {
> > + pr_err("%04x:%02x-%02x bus range mismatch %02x\n",
> > + seg, bus_start, bus_end, e->bus_start);
> > + err = -EINVAL;
> > + goto err_out;
> > + } else if (bus_end != e->bus_end) {
> > + pr_warn("%04x:%02x-%02x bus end mismatch %02x\n",
> > + seg, bus_start, bus_end, e->bus_end);
> > + bus_end = min(bus_end, e->bus_end);
> > + }
> > + addr = e->addr;
> > + }
>
> I really don't think you need a lock around this, so you can factor
> out the address lookup into something like:
>
> addr = acpi_pci_config_base_addr(...);
> if (addr)
> return addr;
>
> return acpi_pci_mcfg_lookup(seg, busn_res);
>
> You can check inside acpi_pci_mcfg_lookup() to make sure the entry you
> find covers the entire [busn_res.start-busn_res.end] range and return
> failure if it doesn't. At this point, I'm not sure it's worth it to
> truncate the host bridge bus range to match something we find in MCFG.
>
> If the MCFG entry covers *more* than the host bridge range from _CRS,
> that's fine. In any case, we have to be careful with the start address,
> because the MCFG start address is always based on bus 0, but I think
> pci_generic_ecam_create() expects the start address based on the
> bus_start you pass to it.
Yes, I spotted this too, it is unfortunate but DT and MCFG handle
the ECAM regions differently. In DT the reg property is relative
to bus_start - ie reg MMIO region maps config space starting at
the first bus in bus-range:
Documentation/devicetree/bindings/pci/host-generic-pci.txt
in ACPI(MCFG) as you said it is always relative to bus 0, it is
unfortunate but the address to be mapped should be computed
differently in the ECAM layer.
Lorenzo
Re: [PATCH v2 0/5] Add SATA3 support for Broadcom NS2 SVK
Hi,
On Monday 28 March 2016 10:18 AM, Anup Patel wrote:
> The Broadcom NS2 SoC has a AHCI compliant SATA3 controller with
> two ports.
>
> This patchset adds common Broadcom SATA3 PHY driver and related
> DT bindings document. It also adds appropriate DT nodes in NS2 DT.
>
> The patchset is based on v4.6-rc1 tag and is available in branch
> ns2_sata3_v2 of https://github.com/Broadcom/arm64-linux.git
>
> All patches have been tested on Broadcom NS2 SVK.
merged the first 3 patches to linux-phy tree.
Thanks
Kishon
>
> Changes since v1:
> - Added ACKed by Rob for DT bindings related patches
>
> Anup Patel (5):
> phy: Rename phy-brcmstb-sata driver to phy-brcm-sata driver
> phy: Add support for NS2 SATA3 PHY in Broadcom SATA3 PHY driver
> dt-bindings: phy: bindings document for common Broadcom SATA3 PHY
> driver
> dt-bindings: ata: add compatible string for iProc AHCI controller
> arm64: dts: Add SATA3 AHCI and SATA3 PHY DT nodes for NS2
>
> .../devicetree/bindings/ata/ahci-platform.txt | 1 +
> ...brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt} | 15 +-
> arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 +
> arch/arm64/boot/dts/broadcom/ns2.dtsi | 43 +++
> drivers/phy/Kconfig| 18 +-
> drivers/phy/Makefile | 2 +-
> drivers/phy/phy-brcm-sata.c| 412
> +
> drivers/phy/phy-brcmstb-sata.c | 250 -
> 8 files changed, 487 insertions(+), 266 deletions(-)
> rename Documentation/devicetree/bindings/phy/{brcm,brcmstb-sata-phy.txt =>
> brcm-sata-phy.txt} (69%)
> create mode 100644 drivers/phy/phy-brcm-sata.c
> delete mode 100644 drivers/phy/phy-brcmstb-sata.c
>
HELLO DEAR
my name is miss pamela i come across to your Facebook profile write me back as soon as posible i have some thing very important to discuse with you (pamela_ab...@outlook.com) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH v2 03/13] staging/android: move sync_file functions comments to sync.c
>
> From: Gustavo Padovan
>
> To keep comments in line with drivers/dma-buf/ move all sync_file comments
> to sync.c.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
> ---
Acked-by: Hillf Danton
> drivers/staging/android/sync.c | 26 +-
> drivers/staging/android/sync.h | 31 ---
> 2 files changed, 25 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index b965e2a..a89ded0 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -173,7 +173,14 @@ static void fence_check_cb_func(struct fence *f, struct
> fence_cb *cb)
> wake_up_all(&sync_file->wq);
> }
>
> -/* TODO: implement a create which takes more that one fence */
> +/**
> + * sync_fence_create() - creates a sync fence
> + * @name:name of fence to create
> + * @fence: fence to add to the sync_fence
> + *
> + * Creates a sync_file containg @fence. Once this is called, the sync_file
> + * takes ownership of @fence.
> + */
> struct sync_file *sync_file_create(const char *name, struct fence *fence)
> {
> struct sync_file *sync_file;
> @@ -198,6 +205,13 @@ struct sync_file *sync_file_create(const char *name,
> struct fence *fence)
> }
> EXPORT_SYMBOL(sync_file_create);
>
> +/**
> + * sync_file_fdget() - get a sync_file from an fd
> + * @fd: fd referencing a fence
> + *
> + * Ensures @fd references a valid sync_file, increments the refcount of the
> + * backing file. Returns the sync_file or NULL in case of error.
> + */
> struct sync_file *sync_file_fdget(int fd)
> {
> struct file *file = fget(fd);
> @@ -229,6 +243,16 @@ static void sync_file_add_pt(struct sync_file
> *sync_file, int *i,
> }
> }
>
> +/**
> + * sync_file_merge() - merge two sync_files
> + * @name:name of new fence
> + * @a: sync_file a
> + * @b: sync_file b
> + *
> + * Creates a new sync_file which contains copies of all the fences in both
> + * @a and @b. @a and @b remain valid, independent sync_file. Returns the
> + * new merged sync_file or NULL in case of error.
> + */
> struct sync_file *sync_file_merge(const char *name,
> struct sync_file *a, struct sync_file *b)
> {
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index c45cc7b..925fba5 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -167,40 +167,9 @@ void sync_timeline_signal(struct sync_timeline *obj);
> */
> struct fence *sync_pt_create(struct sync_timeline *parent, int size);
>
> -/**
> - * sync_fence_create() - creates a sync fence
> - * @name:name of fence to create
> - * @fence: fence to add to the sync_fence
> - *
> - * Creates a sync_file containg @fence. Once this is called, the sync_file
> - * takes ownership of @fence.
> - */
> struct sync_file *sync_file_create(const char *name, struct fence *fence);
> -
> -/*
> - * API for sync_file consumers
> - */
> -
> -/**
> - * sync_file_merge() - merge two sync_files
> - * @name:name of new fence
> - * @a: sync_file a
> - * @b: sync_file b
> - *
> - * Creates a new sync_file which contains copies of all the fences in both
> - * @a and @b. @a and @b remain valid, independent sync_file. Returns the
> - * new merged sync_file or NULL in case of error.
> - */
> struct sync_file *sync_file_merge(const char *name,
> struct sync_file *a, struct sync_file *b);
> -
> -/**
> - * sync_file_fdget() - get a sync_file from an fd
> - * @fd: fd referencing a fence
> - *
> - * Ensures @fd references a valid sync_file, increments the refcount of the
> - * backing file. Returns the sync_file or NULL in case of error.
> - */
> struct sync_file *sync_file_fdget(int fd);
>
> #ifdef CONFIG_DEBUG_FS
> --
> 2.5.5
>
>
Re: [PATCH v3 3/3] block: avoid to call .bi_end_io() recursively
On Fri, 29 Apr 2016, Ming Lei wrote: > On Fri, Apr 29, 2016 at 12:59 AM, Mikulas Patocka wrote: > > > > > > On Fri, 29 Apr 2016, Ming Lei wrote: > > > >> On Thu, Apr 28, 2016 at 11:58 PM, Mikulas Patocka > >> wrote: > >> > > >> > > >> > On Thu, 28 Apr 2016, Ming Lei wrote: > >> > > >> >> Hi Mikulas, > >> >> > >> >> On Thu, Apr 28, 2016 at 11:29 PM, Mikulas Patocka > >> >> wrote: > >> >> > > >> >> > > >> >> > On Thu, 28 Apr 2016, Ming Lei wrote: > >> >> > > >> >> >> There were reports about heavy stack use by recursive calling > >> >> >> .bi_end_io()([1][2][3]). For example, more than 16K stack is > >> >> >> consumed in a single bio complete path[3], and in [2] stack > >> >> >> overflow can be triggered if 20 nested dm-crypt is used. > >> >> >> > >> >> >> Also patches[1] [2] [3] were posted for addressing the issue, > >> >> >> but never be merged. And the idea in these patches is basically > >> >> >> similar, all serializes the recursive calling of .bi_end_io() by > >> >> >> percpu list. > >> >> >> > >> >> >> This patch still takes the same idea, but uses bio_list to > >> >> >> implement it, which turns out more simple and the code becomes > >> >> >> more readable meantime. > >> >> >> > >> >> >> One corner case which wasn't covered before is that > >> >> >> bi_endio() may be scheduled to run in process context(such > >> >> >> as btrfs), and this patch just bypasses the optimizing for > >> >> >> that case because one new context should have enough stack space, > >> >> >> and this approach isn't capable of optimizing it too because > >> >> >> there isn't easy way to get a per-task linked list head. > >> >> > > >> >> > Hi > >> >> > > >> >> > You could use preempt_disable() and then you could use per-cpu list > >> >> > even > >> >> > in the process context. > >> >> > >> >> Image why the .bi_end_io() is scheduled to process context, and the only > >> >> workable/simple way I thought of is to use per-task list because it may > >> >> sleep. > >> > > >> > The bi_end_io callback should not sleep, even if it is called from the > >> > process context. > >> > >> If it shouldn't sleep, why is it scheduled to run in process context by > >> paying > >> extra context switch cost? > > > > Some device mapper (and other) drivers use a worker thread to process > > bios. So the bio may be finished from the worker thread. It would be > > advantageous to prevent stack overflow even in this case. > > If the .bi_end_io wouldn't sleep, it can be put back into interrupt context > for the sake of performance when this patch is merged. The cost of context > switch in high IOPS case isn't cheap. If some block device driver in a process context finds out that it needs to terminate a bio, it calls bio_endio in a process context. Why would it need to trigger an interrupt just to call bio_endio? (and how could it trigger an interrupt if that driver perhaps doesn't use interrupts at all?) I don't know what are you trying to suggest. > It isn't easy to avoid the recursive calling in process context except you > can add something 'task_struct' or introduce 'alloca()' in kernel. Or do you > have better ideas? preempt_disable around the bi_endio callback should be sufficient. > > > >> And you can find that btrfs_subio_endio_read() does sleep for checksum > >> stuff. > > > > I'm not an expert on btrfs. What happens if it is called from an > > interrupt? Do you have an actual stracktrace when this function is called > > What do you expect if sleepable function is called in softirq or > hardirq handler? :-) > > > from bio_endio and when it sleeps? > > The problem is observed in xfstests generic/323 by this patch v1. Sometimes > the > test hangs, and sometimes kernel oops is triggered. and the issue is > fixed by introducing 'if (!in_interrupt())' block for handling running > .bi_end_io() from > process context. > > If the block of 'if (!in_interrupt())' is removed and > preempt_disable()/preempt_enable() is added around bio->bi_end_io(), > the following kernel warning can be seen easily: > > [ 51.086303] BUG: sleeping function called from invalid context at > mm/slab.h:388 > [ 51.087442] in_atomic(): 1, irqs_disabled(): 0, pid: 633, name: > kworker/u8:4 > [ 51.088575] CPU: 3 PID: 633 Comm: kworker/u8:4 Not tainted 4.6.0-rc3+ #2017 > [ 51.088578] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), > BIOS rel-1.9.0-0-g01a84be-prebuilt.qemu-project.org 04/01/2014 > [ 51.088637] Workqueue: btrfs-endio btrfs_endio_helper [btrfs] > [ 51.088640] 88007bbebc00 813d92d3 > 88007ba6ce00 > [ 51.088643] 0184 88007bbebc18 810a38bb > 81a35310 > [ 51.088645] 88007bbebc40 810a3949 02400040 > 02400040 > [ 51.088648] Call Trace: > [ 51.088651] [] dump_stack+0x63/0x90 > [ 51.088655] [] ___might_sleep+0xdb/0x120 > [ 51.088657] [] __might_sleep+0x49/0x80 > [ 51.088659] [] kmem_cache_alloc+0x1a7/0x210 > [ 51.088670] [
Re: [PATCH] efi: Remove unnecessary (and buggy) .memmap initialization from the Xen EFI driver
On Fri, 29 Apr, at 10:31:28AM, Ingo Molnar wrote:
>
> So this commit triggered the follwing build warning on x86 64-bit
> allyesconfig:
Doh! I wonder why the 0day bot didn't tell me about this?
> It's this initialization in drivers/xen/efi.c:
>
> static const struct efi efi_xen __initconst = {
> ...
> .memmap = NULL, /* Not used under Xen. */
> ...
>
> which was forgotten about, as .memmap now is an embedded struct:
>
> struct efi_memory_map memmap;
>
> We can remove this initialization - it's an EFI core internal data structure
> plus
> it's not used in the Xen driver anyway.
>
> Signed-off-by: Ingo Molnar
> ---
> drivers/xen/efi.c | 1 -
> 1 file changed, 1 deletion(-)
Yep, looks good. Thanks Ingo!
Reviewed-by: Matt Fleming
Re: [PATCH RESEND 1/2] pinctrl: ns2: add pinmux driver support for Broadcom NS2 SoC
On Mon, Apr 18, 2016 at 8:24 PM, Ray Jui wrote: > On 4/17/2016 8:34 PM, Yendapally Reddy Dhananjaya Reddy wrote: >>> >>> /* not all Iproc GPIO pins can be muxed individually */ >>> if (!chip->pinmux_is_supported) >>> return 0; > > > NS2 does not support GPIO pins to be muxed individually. The call to > iproc_gpio_request should be rejected for NS2 since > 'chip->pinmux_is_supported' is false. Aha, I see. > since NS2 can only support group based GPIO configuration, the > above functions will be rejected because "pinmux_is_supported" is false: > > chip->pinmux_is_supported = of_property_read_bool(dev->of_node, > "gpio-ranges"); > > Here, "gpio-ranges" should never be defined on NS2 DT files. Makes perfect sense. So for this hardware, muxing will always be done orthogonally (using some pinctrl hogs or similar for GPIO). I'm waiting for a version fixing the bool Kconfig issue, then I guess the driver is ready for inclusion. Yours, Linus Waleij
Re: [PATCH 4/4] pinctrl: iproc: Allow PINCONF to be disabled completely
On Mon, Apr 18, 2016 at 9:30 PM, Ray Jui wrote: > On 4/15/2016 1:24 AM, Linus Walleij wrote: >> >> On Wed, Apr 13, 2016 at 2:15 AM, Ray Jui wrote: >> >>> In some of the future iProc based SoCs, pinconf is handled by another >>> block and the iProc GPIO controller is solely used as a GPIO controller. >>> This patch adds support of a new compatible string >>> "brcm,iproc-gpio-only", >>> that is introduced to handle this case, where pinconf functions in this >>> driver are completely disabled >>> >>> Signed-off-by: Ray Jui >>> Reviewed-by: Yendapally Reddy Dhananjaya Reddy >>> >>> Reviewed-by: Jon Mason >>> Reviewed-by: Scott Branden >> >> >> If this was entirely true, then the driver should end up only executing >> [devm_]gpiochip_add_data() but that does not seem to be the case. > > Yes, in the case of compatible string "brcm,iproc-gpio-only" is detected, > the driver only registers 'gpiochip_add_data'. Please check patch 2/4 of > this series, which takes care of it. OK. >> You are still registering a pin controller, right? Just disabling some of >> the pin config options. The pin multiplexing is still there, right? >> Then it is not "solely a GPIO controller". Not at all. > > This driver does not register itself as a PINCONF driver if > "brcm,iproc-gpio-only" compatible string is detected. This is addressed in > patch 2/4 of this series. > > Pin based IOMUX GPIO override is only activated when > 'chip->pinmux_is_supported' is true, and it is only true if the optional DT > property "gpio-ranges" is defined. OK. > I believe the current issue with this patch series is now only on the naming > of the new compatible string "brcm,iproc-gpio-only". Please correct me if > I'm wrong. Yeah I think I get it now. The patch set makes sense. Looking forward to the next iteration! Yours, Linus Walleij
Re: [PATCH 3/5] mtd: nand: gpmi: correct bitflip for erased NAND page
Hi Han,
On Tue, 23 Feb 2016 17:04:51 -0600
Han Xu wrote:
> i.MX6QP and i.MX7D BCH module integrated a new feature to detect the
> bitflip number for erased NAND page. So for these two platform, set the
> erase threshold to ecc_strength and if bitflip detected, GPMI driver will
> correct the data to all 0xFF.
You're 2 different things in this patch:
1/ adding support for mx6qp
2/ handling bitflips in erased pages with the bitflip count feature
This should be split in 2 different patches.
>
> Signed-off-by: Han Xu
> ---
> drivers/mtd/nand/gpmi-nand/bch-regs.h | 10 ++
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 5 +
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24 +++-
> drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 5 -
> 4 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h
> b/drivers/mtd/nand/gpmi-nand/bch-regs.h
> index 53e58bc..a84d72b 100644
> --- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
> +++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
> @@ -30,7 +30,13 @@
> #define BM_BCH_CTRL_COMPLETE_IRQ (1 << 0)
>
> #define HW_BCH_STATUS0 0x0010
> +
> #define HW_BCH_MODE 0x0020
> +#define BP_BCH_MODE_ERASE_THRESHOLD 0
> +#define BM_BCH_MODE_ERASE_THRESHOLD (0xff << BP_BCH_MODE_ERASE_THRESHOLD)
> +#define BF_BCH_MODE_ERASE_THRESHOLD(v) \
> + (((v) << BP_BCH_MODE_ERASE_THRESHOLD) & BM_BCH_MODE_ERASE_THRESHOLD)
> +
> #define HW_BCH_ENCODEPTR 0x0030
> #define HW_BCH_DATAPTR 0x0040
> #define HW_BCH_METAPTR 0x0050
> @@ -125,4 +131,8 @@
> )
>
> #define HW_BCH_VERSION 0x0160
> +#define HW_BCH_DEBUG10x0170
> +#define BP_BCH_DEBUG1_ERASED_ZERO_COUNT 0
> +#define BM_BCH_DEBUG1_ERASED_ZERO_COUNT \
> + (0x1ff << BP_BCH_DEBUG1_ERASED_ZERO_COUNT)
> #endif
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> index 8acbe04..2c43213 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> @@ -298,6 +298,11 @@ int bch_set_geometry(struct gpmi_nand_data *this)
> | BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size, this),
> r->bch_regs + HW_BCH_FLASH0LAYOUT1);
>
> + /* Set erase threshold to ecc_strength for mx6qp and mx7 */
> + if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
> + writel(BF_BCH_MODE_ERASE_THRESHOLD(ecc_strength),
> + r->bch_regs + HW_BCH_MODE);
> +
> /* Set *all* chip selects to use layout 0. */
> writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 1aba6e6..6b3ca3b 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -71,6 +71,12 @@ static const struct gpmi_devdata gpmi_devdata_imx6q = {
> .max_chain_delay = 12,
> };
>
> +static const struct gpmi_devdata gpmi_devdata_imx6qp = {
> + .type = IS_MX6QP,
> + .bch_max_ecc_strength = 40,
> + .max_chain_delay = 12,
> +};
> +
> static const struct gpmi_devdata gpmi_devdata_imx6sx = {
> .type = IS_MX6SX,
> .bch_max_ecc_strength = 62,
> @@ -1010,6 +1016,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> {
> struct gpmi_nand_data *this = nand_get_controller_data(chip);
> struct bch_geometry *nfc_geo = &this->bch_geometry;
> + void __iomem *bch_regs = this->resources.bch_regs;
> void *payload_virt;
> dma_addr_tpayload_phys;
> void *auxiliary_virt;
> @@ -1018,6 +1025,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> unsigned char *status;
> unsigned int max_bitflips = 0;
> int ret;
> + int flag = 0;
>
> dev_dbg(this->dev, "page number is : %d\n", page);
> ret = read_page_prepare(this, buf, nfc_geo->payload_size,
> @@ -1050,9 +1058,16 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
> struct nand_chip *chip,
> status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
>
> for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
> - if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
> + if (*status == STATUS_GOOD)
> continue;
>
> + if (*status == STATUS_ERASED) {
> + if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
> + if (readl(bch_regs + HW_BCH_DEBUG1))
> + flag = 1;
You should update max_bitflips here.
> + continue;
> + }
> +
> if (*sta
Re: [PATCH v2 2/9] drivers: irqchip: Add STM32 external interrupts support
On Tue, Apr 19, 2016 at 10:00 AM, Maxime Coquelin
wrote:
> 2016-04-08 11:38 GMT+02:00 Linus Walleij :
>> while ((stat = readl_relaxed(vic->base + VIC_IRQ_STATUS))) {
>> irq = ffs(stat) - 1;
>> handle_domain_irq(vic->domain, irq, regs);
>> handled = 1;
>> }
>>
>> return handled;
>> }
>
> Indeed, it would be better doing it like this.
> Do you think I could even do this with two nested loops to reduce the
> number of reg accesses?
> It would look like this (just compiled, not tested):
>
> static void stm32_irq_handler(struct irq_desc *desc)
> {
> struct irq_domain *domain = irq_desc_get_handler_data(desc);
> struct irq_chip_generic *gc = domain->gc->gc[0];
> struct irq_chip *chip = irq_desc_get_chip(desc);
> unsigned long pending;
> int n;
>
> chained_irq_enter(chip, desc);
>
> while ((pending = irq_reg_readl(gc, EXTI_PR))) {
> for_each_set_bit(n, &pending, BITS_PER_LONG) {
> generic_handle_irq(irq_find_mapping(domain, n));
> }
> }
Looks clever! :)
If it also works, I'm in for it.
Yours,
Linus Walleij
Re: [PATCH 4/5] mtd: nand: gpmi: support NAND on i.MX6UL
On Tue, 23 Feb 2016 17:04:52 -0600
Han Xu wrote:
> From: Han Xu
>
> support GPMI NAND on i.MX6UL
>
> Signed-off-by: Han Xu
> ---
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +
> drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 4 +++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 6b3ca3b..1987f03 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -89,6 +89,12 @@ static const struct gpmi_devdata gpmi_devdata_imx7d = {
> .max_chain_delay = 12,
> };
>
> +static const struct gpmi_devdata gpmi_devdata_imx6ul = {
> + .type = IS_MX6UL,
> + .bch_max_ecc_strength = 40,
> + .max_chain_delay = 12,
> +};
> +
> static irqreturn_t bch_irq(int irq, void *cookie)
> {
> struct gpmi_nand_data *this = cookie;
> @@ -2013,6 +2019,9 @@ static const struct of_device_id gpmi_nand_id_table[] =
> {
> .compatible = "fsl,imx6sx-gpmi-nand",
> .data = &gpmi_devdata_imx6sx,
> }, {
> + .compatible = "fsl,imx6ul-gpmi-nand",
> + .data = (void *)&gpmi_devdata_imx6ul,
Drop this (void *) cast.
> + }, {
> .compatible = "fsl,imx7d-gpmi-nand",
> .data = (void *)&gpmi_devdata_imx7d,
> }, { /* sentinel */ }
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> index 605d96e..eb45a3c 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> @@ -126,6 +126,7 @@ enum gpmi_type {
> IS_MX6QP,
> IS_MX6SX,
> IS_MX7D,
> + IS_MX6UL,
> };
>
> struct gpmi_devdata {
> @@ -309,8 +310,9 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
> #define GPMI_IS_MX6QP(x) ((x)->devdata->type == IS_MX6QP)
> #define GPMI_IS_MX6SX(x) ((x)->devdata->type == IS_MX6SX)
> #define GPMI_IS_MX7D(x) ((x)->devdata->type == IS_MX7D)
> +#define GPMI_IS_MX6UL(x) ((x)->devdata->type == IS_MX6UL)
>
> #define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6QP(x)\
> -|| GPMI_IS_MX6SX(x))
> +|| GPMI_IS_MX6SX(x) || GPMI_IS_MX6UL(x))
And fix the missing space and alignment issue here as well.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH v2 05/13] staging/android: make sync_file_fdget() static
>
> From: Gustavo Padovan
>
> There is no plan in the near future to use this function outside of this
> file so keep it as static.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
> ---
Acked-by: Hillf Danton
> drivers/staging/android/sync.c | 3 +--
> drivers/staging/android/sync.h | 1 -
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index e9bf251..7e0fa20 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -212,7 +212,7 @@ EXPORT_SYMBOL(sync_file_create);
> * Ensures @fd references a valid sync_file, increments the refcount of the
> * backing file. Returns the sync_file or NULL in case of error.
> */
> -struct sync_file *sync_file_fdget(int fd)
> +static struct sync_file *sync_file_fdget(int fd)
> {
> struct file *file = fget(fd);
>
> @@ -228,7 +228,6 @@ err:
> fput(file);
> return NULL;
> }
> -EXPORT_SYMBOL(sync_file_fdget);
>
> static void sync_file_add_pt(struct sync_file *sync_file, int *i,
>struct fence *fence)
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index ffc6df6..1f164df 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -168,7 +168,6 @@ void sync_timeline_signal(struct sync_timeline *obj);
> struct fence *sync_pt_create(struct sync_timeline *parent, int size);
>
> struct sync_file *sync_file_create(const char *name, struct fence *fence);
> -struct sync_file *sync_file_fdget(int fd);
>
> #ifdef CONFIG_DEBUG_FS
>
> --
> 2.5.5
>
>
Re: linux-next: manual merge of the arm64 tree with Linus' tree
On Fri, Apr 29, 2016 at 09:59:58AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm/kvm/arm.c
>
> between commit:
>
> 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")
>
> from Linus' tree and commit:
>
> 67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
>
> from the arm64 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm/kvm/arm.c
> index dded1b763c16,1687e1450c3a..
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@@ -1198,8 -1226,6 +1233,7 @@@ static void teardown_hyp_mode(void
> free_hyp_pgds();
> for_each_possible_cpu(cpu)
> free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> - unregister_cpu_notifier(&hyp_init_cpu_nb);
> +hyp_cpu_pm_exit();
> }
>
> static int init_vhe_mode(void)
Thanks Stephen, this looks good to me.
Will
Re: [PATCH 2/5] mtd: nand: gpmi: document the clocks and clock-names in DT property
Hi Han,
On Tue, 23 Feb 2016 17:04:50 -0600
Han Xu wrote:
> add the clocks and clock-names in DT property, gpmi-io clock is
> mandatory for all platforms, but some platforms, such as i.MX6Q may
> need more extra clocks for submodules. More details please refer to the
> SoC reference manual.
>
> Signed-off-by: Han Xu
> ---
> Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 9 +
Please make sure you add the DT maintainers (and the DT ML) in Cc when
you update DT bindings.
Best Regards,
Boris
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> index d02acaf..c8d0e2f 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> @@ -13,6 +13,13 @@ Required properties:
> and GPMI DMA channel ID.
> Refer to dma.txt and fsl-mxs-dma.txt for details.
>- dma-names: Must be "rx-tx".
> + - clocks : The clocks needed by the gpmi controller. This field varies
> +depends on the SoC design, "gpmi-io" is mandatory but some platforms may
> +need several extra clocks, such as i.MX6Q, it requires "gpmi_apb,
> +gpmi_bch, gpmi_bch_apb and per1_bch" for all submodules. Please refer to
> +the HW design manual.
> + - clock-names : the name of the clocks, please refer to the HW design
> +manual.
>
> Optional properties:
>- nand-on-flash-bbt: boolean to enable on flash bbt option if not
> @@ -51,6 +58,8 @@ gpmi-nand@8000c000 {
> interrupt-names = "bch";
> dmas = <&dma_apbh 4>;
> dma-names = "rx-tx";
> + clocks = <&clks 50>,;
> + clock-names = "gpmi_io";
>
> partition@0 {
> ...
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH] scripts/dtc: Update to upstream version 53bf130b1cdd
Hi Rob,
On Tue, Mar 8, 2016 at 9:00 AM, Rob Herring wrote:
> On Mon, Mar 7, 2016 at 5:27 AM, Geert Uytterhoeven
> wrote:
>> On Fri, Mar 4, 2016 at 4:13 PM, Rob Herring wrote:
>>> Sync to upstream dtc commit 53bf130b1cdd ("libfdt: simplify
>>> fdt_node_check_compatible()"). This adds the following commits from
>>> upstream:
>>>
>>> 53bf130 libfdt: simplify fdt_node_check_compatible()
>>> c9d9121 Warn on node name unit-address presence/absence mismatch
>>> 2e53f9d Catch unsigned 32bit overflow when parsing flattened device tree
>>> offsets
>>>
>>> Signed-off-by: Rob Herring
>>> ---
>>> As usual, this is just an automated copy of upstream dtc into the kernel
>>> tree. The changeset is small enough that I have left it here.
>>>
>>> The main reason for this sync is to pick-up the new unit-address
>>> warnings.
>>
>> I gave this a try. Obviously it finds many abuses that should be fixed.
>>
>> However, I'm wondering about the following, where the unit-address is just
>> used to distinguish between multiple instances:
>>
>> Warning (unit_address_vs_reg): Node /cache-controller@0 has a unit
>> name, but no reg property
>> compatible = "cache";
>
> Just add a reg property. The values should probably match the MPIDR in
> some way (e.g. 0 and 100).
Is it correct to move the cache-controller nodes under the cpus node?
Else the reg properties don't match #address/size-cells?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 25/32] sched: introduce the finish_arch_pre_lock_switch() scheduler hook
On Thu, Apr 28, 2016 at 09:43:31PM -0700, David Carrillo-Cisneros wrote: > This hook allows architecture specific code to be called at the end of > the task switch and after perf_events' context switch but before the > scheduler lock is released. > > The specific use case in this series is to avoid multiple writes to a slow > MSR until all functions which modify such register in task switch have > finished. Yeah, no. This really need way more justification. Why can't you use the regular perf sched-in stuff for CQM?
Re: [PATCH v2 6/9] pinctrl: Add IRQ support to STM32 gpios
On Tue, Apr 19, 2016 at 11:04 AM, Maxime Coquelin
wrote:
> 2016-04-08 11:43 GMT+02:00 Linus Walleij :
>> On Thu, Mar 31, 2016 at 5:09 PM, Maxime Coquelin
>> wrote:
>>
>>> +static int stm32_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
>>> +{
>>> + struct stm32_pinctrl *pctl = dev_get_drvdata(chip->parent);
>>> + struct stm32_gpio_bank *bank = gpiochip_get_data(chip);
>>> + unsigned int irq;
>>> +
>>> + regmap_field_write(pctl->irqmux[offset], bank->range.id);
>>
>> No. You must implement the irqchip and GPIO controllers to
>> be orthogonal, doing things like this creates a semantic that
>> assumes .to_irq() is always called before using the IRQ and
>> that is not guaranteed at all. A consumer may very well
>> use an interrupt right off the irqchip without this being called
>> first. All this function should do is translate a number. No
>> other semantics.
>>
>> This needs to be done from the irqchip (sorry).
>
> Actually, the register written here is not part of the irqchip.
> It is a system config register that is only used when using a GPIO as
> external interrupt.
> Its aim is to mux the GPIO bank on a line.
Then it should be done in .request() for the GPIO, not in
.to_irq().
It should *also* be done in the set-up path for the irqchip
side, if that line is used without any interaction with the
gpio side of things.
> For example on line 1, it can be muxed to select either gpioa1,
> gpiob1, gpioc1, ...
> How could I do it in the irqchip that has no gpio knowledge?
I don't understand this.
We are discussing an irqchip that is tightly coupled with
a gpiochip. Usually d->hwirq is the same as the GPIO offset
but that varies.
The point is that each IRQ that ever get used
has a 1-to-1 relationship to a certain GPIO line, and if that
relationship cannot be resolved from the irqchip side,
something is wrong. The irqchip needs to enable the
GPIO line it is backing to recieve interrupts without any
requirements that .to_irq() have been called first.
If to_irq() does something else than translate to an IRQ
something is wrong.
Yours,
Linus Walleij
[PATCH] sched/core: don't include asm/mmu_context from drivers
The introduction of switch_mm_irqs_off() brought back an old bug
regarding the use of preempt_enable_no_resched:
As part of 62b94a08da1b ("sched/preempt: Take away
preempt_enable_no_resched() from modules"), the definition of
preempt_enable_no_resched() is only available in built-in code,
not in loadable modules, so we can't generally use it from header
files. However, the ARM version of finish_arch_post_lock_switch()
calls preempt_enable_no_resched() and is defined as a static
inline function in asm/mmu_context.h. This in turn means we cannot
include asm/mmu_context.h from modules.
With today's tip tree, asm/mmu_context.h gets included from
linux/mmu_context.h, which is normally the exact pattern one would
expect, but unfortunately, linux/mmu_context.h can be included from
the vhost driver that is a loadable module, now causing this compile
time error:
In file included from ../include/linux/mmu_context.h:4:0,
from ../drivers/vhost/vhost.c:18:
../arch/arm/include/asm/mmu_context.h: In function
'finish_arch_post_lock_switch':
../arch/arm/include/asm/mmu_context.h:88:3: error: implicit declaration of
function 'preempt_enable_no_resched' [-Werror=implicit-function-declaration]
preempt_enable_no_resched();
Andy already tried to fix the bug by including linux/preempt.h
from asm/mmu_context.h, but that obviously didn't help.
This reverts the earlier fix attempt and works around the problem
by including both linux/mmu_context.h and asm/mmu_context.h from
kernel/sched/core.c. This is not a good solution but seems less
hacky than the alternatives.
Signed-off-by: Arnd Bergmann
Fixes: f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the
scheduler")
Reverts: 88f10e37e150 ("sched/core, ARM: Include linux/preempt.h from
asm/mmu_context.h")
---
arch/arm/include/asm/mmu_context.h | 1 -
include/linux/mmu_context.h| 2 --
kernel/sched/core.c| 1 +
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/mmu_context.h
b/arch/arm/include/asm/mmu_context.h
index ed73babc0dc9..fa5b42d44985 100644
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -15,7 +15,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/include/linux/mmu_context.h b/include/linux/mmu_context.h
index a4441784503b..88d270706792 100644
--- a/include/linux/mmu_context.h
+++ b/include/linux/mmu_context.h
@@ -1,8 +1,6 @@
#ifndef _LINUX_MMU_CONTEXT_H
#define _LINUX_MMU_CONTEXT_H
-#include
-
struct mm_struct;
void use_mm(struct mm_struct *mm);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c82ca6eccfec..baa2a5152658 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -78,6 +78,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PARAVIRT
#include
--
2.7.0
Re: [PATCH v2 6/9] pinctrl: Add IRQ support to STM32 gpios
On Fri, Apr 29, 2016 at 10:53 AM, Linus Walleij
wrote:
> On Tue, Apr 19, 2016 at 11:04 AM, Maxime Coquelin
> wrote:
>> 2016-04-08 11:43 GMT+02:00 Linus Walleij :
>>> On Thu, Mar 31, 2016 at 5:09 PM, Maxime Coquelin
>>> wrote:
>>>
+static int stm32_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+{
+ struct stm32_pinctrl *pctl = dev_get_drvdata(chip->parent);
+ struct stm32_gpio_bank *bank = gpiochip_get_data(chip);
+ unsigned int irq;
+
+ regmap_field_write(pctl->irqmux[offset], bank->range.id);
>>>
>>> No. You must implement the irqchip and GPIO controllers to
>>> be orthogonal, doing things like this creates a semantic that
>>> assumes .to_irq() is always called before using the IRQ and
>>> that is not guaranteed at all. A consumer may very well
>>> use an interrupt right off the irqchip without this being called
>>> first. All this function should do is translate a number. No
>>> other semantics.
>>>
>>> This needs to be done from the irqchip (sorry).
>>
>> Actually, the register written here is not part of the irqchip.
>> It is a system config register that is only used when using a GPIO as
>> external interrupt.
>> Its aim is to mux the GPIO bank on a line.
>
> Then it should be done in .request() for the GPIO, not in
> .to_irq().
>
> It should *also* be done in the set-up path for the irqchip
> side, if that line is used without any interaction with the
> gpio side of things.
Or, hm, maybe not in the irqchip then if it is as you say
that the interrupt can be used anyway, without this being
set up.
But it should certainly not be done in .to_irq(), rather in
.request().
Yours,
Linus Walleij
Re: [PATCH V2 1/3] gpio: tegra: Don't open code of_device_get_match_data()
On Tue, Apr 19, 2016 at 11:43 AM, Laxman Dewangan wrote: > Use of_device_get_match_data() for getting matched data > instead of implementing this locally. > > Signed-off-by: Laxman Dewangan > Reviewed-by: Stephen Warren Patch applied with Thierry's ACK. Yours, Linus Walleij
[PATCH kernel v4 03/11] powerpc/powernv: Rename pnv_pci_ioda2_tce_invalidate_entire
As in fact pnv_pci_ioda2_tce_invalidate_entire() invalidates TCEs for
the specific PE rather than the entire cache, rename it to
pnv_pci_ioda2_tce_invalidate_pe(). In later patches we will add
a proper pnv_pci_ioda2_tce_invalidate_entire().
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
arch/powerpc/platforms/powernv/pci-ioda.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index c5baaf3..ca307b6 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1811,7 +1811,7 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
.get = pnv_tce_get,
};
-static inline void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_ioda_pe *pe)
+static inline void pnv_pci_ioda2_tce_invalidate_pe(struct pnv_ioda_pe *pe)
{
/* 01xb - invalidate TCEs that match the specified PE# */
unsigned long val = (0x4ull << 60) | (pe->pe_number & 0xFF);
@@ -2075,7 +2075,7 @@ static long pnv_pci_ioda2_set_window(struct
iommu_table_group *table_group,
pnv_pci_link_table_and_group(phb->hose->node, num,
tbl, &pe->table_group);
- pnv_pci_ioda2_tce_invalidate_entire(pe);
+ pnv_pci_ioda2_tce_invalidate_pe(pe);
return 0;
}
@@ -2219,7 +2219,7 @@ static long pnv_pci_ioda2_unset_window(struct
iommu_table_group *table_group,
if (ret)
pe_warn(pe, "Unmapping failed, ret = %ld\n", ret);
else
- pnv_pci_ioda2_tce_invalidate_entire(pe);
+ pnv_pci_ioda2_tce_invalidate_pe(pe);
pnv_pci_unlink_table_and_group(table_group->tables[num], table_group);
--
2.5.0.rc3
[PATCH kernel v4 05/11] powerpc/powernv/npu: TCE Kill helpers cleanup
NPU PHB TCE Kill register is exactly the same as in the rest of POWER8
so let's reuse the existing code for NPU. The only bit missing is
a helper to reset the entire TCE cache so this moves such a helper
from NPU code and renames it.
Since pnv_npu_tce_invalidate() does really invalidate the entire cache,
this uses pnv_pci_ioda2_tce_invalidate_entire() directly for NPU.
This adds an explicit comment for workaround for invalidating NPU TCE
cache.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
Reviewed-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 41 ---
arch/powerpc/platforms/powernv/pci-ioda.c | 29 ++
arch/powerpc/platforms/powernv/pci.h | 7 +-
3 files changed, 25 insertions(+), 52 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 7229acd..778570c 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -25,8 +25,6 @@
* Other types of TCE cache invalidation are not functional in the
* hardware.
*/
-#define TCE_KILL_INVAL_ALL PPC_BIT(0)
-
static struct pci_dev *get_pci_dev(struct device_node *dn)
{
return PCI_DN(dn)->pcidev;
@@ -161,45 +159,6 @@ static struct pnv_ioda_pe *get_gpu_pci_dev_and_pe(struct
pnv_ioda_pe *npe,
return pe;
}
-void pnv_npu_tce_invalidate_entire(struct pnv_ioda_pe *npe)
-{
- struct pnv_phb *phb = npe->phb;
-
- if (WARN_ON(phb->type != PNV_PHB_NPU ||
- !phb->ioda.tce_inval_reg ||
- !(npe->flags & PNV_IODA_PE_DEV)))
- return;
-
- mb(); /* Ensure previous TCE table stores are visible */
- __raw_writeq(cpu_to_be64(TCE_KILL_INVAL_ALL),
- phb->ioda.tce_inval_reg);
-}
-
-void pnv_npu_tce_invalidate(struct pnv_ioda_pe *npe,
- struct iommu_table *tbl,
- unsigned long index,
- unsigned long npages,
- bool rm)
-{
- struct pnv_phb *phb = npe->phb;
-
- /* We can only invalidate the whole cache on NPU */
- unsigned long val = TCE_KILL_INVAL_ALL;
-
- if (WARN_ON(phb->type != PNV_PHB_NPU ||
- !phb->ioda.tce_inval_reg ||
- !(npe->flags & PNV_IODA_PE_DEV)))
- return;
-
- mb(); /* Ensure previous TCE table stores are visible */
- if (rm)
- __raw_rm_writeq(cpu_to_be64(val),
- (__be64 __iomem *) phb->ioda.tce_inval_reg_phys);
- else
- __raw_writeq(cpu_to_be64(val),
- phb->ioda.tce_inval_reg);
-}
-
void pnv_npu_init_dma_pe(struct pnv_ioda_pe *npe)
{
struct pnv_ioda_pe *gpe;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 03be25d..a67d51e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1811,9 +1811,23 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
.get = pnv_tce_get,
};
+#define TCE_KILL_INVAL_ALL PPC_BIT(0)
#define TCE_KILL_INVAL_PE PPC_BIT(1)
#define TCE_KILL_INVAL_TCE PPC_BIT(2)
+void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+{
+ const unsigned long val = TCE_KILL_INVAL_ALL;
+
+ mb(); /* Ensure previous TCE table stores are visible */
+ if (rm)
+ __raw_rm_writeq(cpu_to_be64(val),
+ (__be64 __iomem *)
+ phb->ioda.tce_inval_reg_phys);
+ else
+ __raw_writeq(cpu_to_be64(val), phb->ioda.tce_inval_reg);
+}
+
static inline void pnv_pci_ioda2_tce_invalidate_pe(struct pnv_ioda_pe *pe)
{
/* 01xb - invalidate TCEs that match the specified PE# */
@@ -1834,7 +1848,7 @@ static inline void pnv_pci_ioda2_tce_invalidate_pe(struct
pnv_ioda_pe *pe)
if (!npe || npe->phb->type != PNV_PHB_NPU)
continue;
- pnv_npu_tce_invalidate_entire(npe);
+ pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
}
}
@@ -1883,14 +1897,19 @@ static void pnv_pci_ioda2_tce_invalidate(struct
iommu_table *tbl,
index, npages);
if (pe->flags & PNV_IODA_PE_PEER)
- /* Invalidate PEs using the same TCE table */
+ /*
+* The NVLink hardware does not support TCE kill
+* per TCE entry so we have to invalidate
+* the entire cache for it.
+*/
for (i = 0; i < PNV_IODA_MAX_PEER_PES; i++) {
npe = pe->peers[i];
- if (!npe || npe->phb->type != PNV_PHB_NPU)
+
Re: [PATCH V5 1/4] gpio: tegra: Don't open code of_device_get_match_data()
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan wrote: > Use of_device_get_match_data() for getting matched data > instead of implementing this locally. > > Signed-off-by: Laxman Dewangan > Reviewed-by: Stephen Warren > Reviewed-by: Alexandre Courbot > Acked-by: Thierry Reding Oops sorry, backed out the v2 and applied this v5 version instead. Yours, Linus Walleij
Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput -11.8% regression
On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote: > All of them are order-2 and this was a known problem for "mm, oom: > rework oom detection" commit and later should make it much more > resistant to failures for higher (!costly) orders. So I would definitely > encourage you to retest with the current _complete_ mmotm tree. OK, will run the test on this branch: https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git since-4.5 with head commit: commit 81cc2e6f1e8bd81ebc7564a3cd3797844ee1712e Author: Michal Hocko Date: Thu Apr 28 12:03:24 2016 +0200 drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable Please let me know if this isn't right.
Re: [PATCH V5 2/4] gpio: tegra: Make of_device_id compatible data to constant
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan wrote: > The data member of the of_device_id is the constant type > and hence all static structure which is used for this > initialisation as static. > > Signed-off-by: Laxman Dewangan > Suggested-by: Thierry Reding > Reviewed-by: Stephen Warren Patch applied. Yours, Linus Walleij
[PATCH kernel v4 01/11] vfio_pci: Test for extended capabilities if config space > 256 bytes
PCI-Express spec says that reading 4 bytes at offset 100h should return
zero if there is no extended capability so VFIO reads this dword to
know if there are extended capabilities.
However it is not always possible to access the extended space so
generic PCI code in pci_cfg_space_size_ext() checks if
pci_read_config_dword() can read beyond 100h and if the check fails,
it sets the config space size to 100h.
VFIO does its own extended capabilities check by reading at offset 100h
which may produce 0x which VFIO treats as the extended config
space presense and calls vfio_ecap_init() which fails to parse
capabilities (which is expected) but right before the exit, it writes
zero at offset 100h which is beyond the buffer allocated for
vdev->vconfig (which is 256 bytes) which leads to random memory
corruption.
This makes VFIO only check for the extended capabilities if
the discovered config size is more than 256 bytes.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v2:
* instead of checking for 0x, this only does the check if
device's config size is big enough
---
drivers/vfio/pci/vfio_pci_config.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index 142c533..d0c4358 100644
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -1124,9 +1124,12 @@ static int vfio_cap_len(struct vfio_pci_device *vdev, u8
cap, u8 pos)
return pcibios_err_to_errno(ret);
if (PCI_X_CMD_VERSION(word)) {
- /* Test for extended capabilities */
- pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword);
- vdev->extended_caps = (dword != 0);
+ if (pdev->cfg_size > PCI_CFG_SPACE_SIZE) {
+ /* Test for extended capabilities */
+ pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE,
+ &dword);
+ vdev->extended_caps = (dword != 0);
+ }
return PCI_CAP_PCIX_SIZEOF_V2;
} else
return PCI_CAP_PCIX_SIZEOF_V0;
@@ -1138,9 +1141,11 @@ static int vfio_cap_len(struct vfio_pci_device *vdev, u8
cap, u8 pos)
return byte;
case PCI_CAP_ID_EXP:
- /* Test for extended capabilities */
- pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword);
- vdev->extended_caps = (dword != 0);
+ if (pdev->cfg_size > PCI_CFG_SPACE_SIZE) {
+ /* Test for extended capabilities */
+ pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword);
+ vdev->extended_caps = dword != 0;
+ }
/* length based on version */
if ((pcie_caps_reg(pdev) & PCI_EXP_FLAGS_VERS) == 1)
--
2.5.0.rc3
[PATCH kernel v4 02/11] vfio/spapr: Relax the IOMMU compatibility check
We are going to have multiple different types of PHB on the same system
with POWER8 + NVLink and PHBs will have different IOMMU ops. However
we only really care about one callback - create_table - so we can
relax the compatibility check here.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
drivers/vfio/vfio_iommu_spapr_tce.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 0582b72..3054e3f 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1188,7 +1188,8 @@ static int tce_iommu_attach_group(void *iommu_data,
goto unlock_exit;
}
table_group_tmp = iommu_group_get_iommudata(tcegrp->grp);
- if (table_group_tmp->ops != table_group->ops) {
+ if (table_group_tmp->ops->create_table !=
+ table_group->ops->create_table) {
pr_warn("tce_vfio: Group %d is incompatible with group
%d\n",
iommu_group_id(iommu_group),
iommu_group_id(tcegrp->grp));
--
2.5.0.rc3
Re: [PATCH v2 04/13] staging/android: make sync_file_merge() static
>
> From: Gustavo Padovan
>
> There is no plan in the near future to use this function outside of this
> file so keep it as static.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
> ---
Acked-by: Hillf Danton
> drivers/staging/android/sync.c | 5 ++---
> drivers/staging/android/sync.h | 2 --
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index a89ded0..e9bf251 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -253,8 +253,8 @@ static void sync_file_add_pt(struct sync_file *sync_file,
> int *i,
> * @a and @b. @a and @b remain valid, independent sync_file. Returns the
> * new merged sync_file or NULL in case of error.
> */
> -struct sync_file *sync_file_merge(const char *name,
> - struct sync_file *a, struct sync_file *b)
> +static struct sync_file *sync_file_merge(const char *name, struct sync_file
> *a,
> + struct sync_file *b)
> {
> int num_fences = a->num_fences + b->num_fences;
> struct sync_file *sync_file;
> @@ -310,7 +310,6 @@ struct sync_file *sync_file_merge(const char *name,
> sync_file_debug_add(sync_file);
> return sync_file;
> }
> -EXPORT_SYMBOL(sync_file_merge);
>
> static const char *android_fence_get_driver_name(struct fence *fence)
> {
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index 925fba5..ffc6df6 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -168,8 +168,6 @@ void sync_timeline_signal(struct sync_timeline *obj);
> struct fence *sync_pt_create(struct sync_timeline *parent, int size);
>
> struct sync_file *sync_file_create(const char *name, struct fence *fence);
> -struct sync_file *sync_file_merge(const char *name,
> - struct sync_file *a, struct sync_file *b);
> struct sync_file *sync_file_fdget(int fd);
>
> #ifdef CONFIG_DEBUG_FS
> --
> 2.5.5
>
>
Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table
On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote:
>
> From what I know, this works because the first PGD entry (the one
> containing the identity mappings) of the trampoline_pgd is shared with
> the main kernel PGD (init_level4_pgt), so when __map_region maps this
> stuff into the trampoline_pgd, we get it in the kernel PGD as well.
Correct.
> The way I understand it, the motivation behind this change is to isolate
> the EFI runtime services code/data from the regular kernel page tables,
Yep.
> but it appears that we've isolated a bit more than that. I do
> understand that if we were doing an actual EFI callback, we'd switch
> over to the efi_pgd, where we'd have this stuff mapped in, but, until
> now, we've been able to read these MMRs using the regular kernel page
> table without issues.
>
> Please let me know what you guys think about this issue, and if you have
> any suggestions for possible solutions. Any input is greatly
> appreciated!
The issue is that you're relying on the EFI mapping code to map these
regions for you, and that's a bug. These regions have nothing to do
with EFI.
Arguably it's always been a bug. You're not alone though, there were
also other pieces of code piggy-backing on the EFI mapping functions,
and EFI code piggy-backing on the regular kernel mapping functions,
see 452308de6105 ("x86/efi: Fix boot crash by always mapping boot
service regions into new EFI page tables").
I agree with Boris' suggestion that removing the "if (is_uv1_hub())"
check in uv_system_init() is probably the way to go, since it should
always be the responsibility of uv_system_init() to setup these
mappings.
Re: [PATCH V5 3/4] gpio: tegra: Get rid of all file scoped global variables
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan wrote: > Move the file scoped multiple global variable from Tegra GPIO > driver to the structure and make this as gpiochip data which > can be referred from GPIO chip callbacks. > > Signed-off-by: Laxman Dewangan > Reviewed-by: Stephen Warren > Reviewed-by: Alexandre Courbot Patch applied. Yours, Linus Walleij
Re: [PATCH 1/5] mtd: nand: gpmi: add GPMI NAND support for i.MX7D
On Tue, 23 Feb 2016 17:04:49 -0600 Han Xu wrote: > From: Han Xu > > support GPMI NAND on i.MX7D > > Signed-off-by: Han Xu > --- > drivers/mtd/nand/gpmi-nand/bch-regs.h | 14 +++--- > drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 10 ++ > drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 27 ++- > drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 7 +-- > 4 files changed, 40 insertions(+), 18 deletions(-) > > diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h > b/drivers/mtd/nand/gpmi-nand/bch-regs.h > index 05bb91f..53e58bc 100644 > --- a/drivers/mtd/nand/gpmi-nand/bch-regs.h > +++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h > @@ -1,7 +1,7 @@ > /* > * Freescale GPMI NAND Flash Driver > * > - * Copyright 2008-2011 Freescale Semiconductor, Inc. > + * Copyright 2008-2015 Freescale Semiconductor, Inc. > * Copyright 2008 Embedded Alley Solutions, Inc. > * > * This program is free software; you can redistribute it and/or modify > @@ -54,7 +54,7 @@ > #define MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0 11 > #define MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0 (0x1f << > MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0) > #define BF_BCH_FLASH0LAYOUT0_ECC0(v, x) \ > - (GPMI_IS_MX6(x) \ > + ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \ > ? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0) \ > & MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0) \ > : (((v) << BP_BCH_FLASH0LAYOUT0_ECC0) \ > @@ -65,7 +65,7 @@ > #define MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14 \ > (0x1 << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14) > #define BF_BCH_FLASH0LAYOUT0_GF(v, x)\ > - ((GPMI_IS_MX6(x) && ((v) == 14))\ > + (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\ Missing tab at the end of the line ") \" > ? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14) \ > & MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14) \ > : 0 \ > @@ -77,7 +77,7 @@ > #define MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE \ > (0x3ff << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE) > #define BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(v, x) > \ > - (GPMI_IS_MX6(x) \ > + ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \ > ? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) \ > : ((v) & BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) \ > ) > @@ -96,7 +96,7 @@ > #define MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN 11 > #define MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN (0x1f << > MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN) > #define BF_BCH_FLASH0LAYOUT1_ECCN(v, x) \ > - (GPMI_IS_MX6(x) \ > + ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \ > ? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN) \ > & MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN) \ > : (((v) << BP_BCH_FLASH0LAYOUT1_ECCN) \ > @@ -107,7 +107,7 @@ > #define MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14 \ > (0x1 << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14) > #define BF_BCH_FLASH0LAYOUT1_GF(v, x)\ > - ((GPMI_IS_MX6(x) && ((v) == 14))\ > + (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\ Ditto. > ? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14) \ > & MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14) \ > : 0 \ > @@ -119,7 +119,7 @@ > #define MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE \ > (0x3ff << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE) > #define BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(v, x) > \ > - (GPMI_IS_MX6(x) \ > + ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \ > ? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) \ > : ((v) & BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) \ > ) > diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c > b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c > index 0f68a99..8acbe04 100644 > --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c > +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c > @@ -1,7 +1,7 @@ > /* > * Freescale GPMI NAND Flash Driver > * > - * Copyright (C) 2008-2011 Freescale Semiconductor, Inc. > + * Copyright (C) 2008-2015 Freescale Semiconductor, Inc. > * Copyright (C) 2008 Embedded Alley Solutions, Inc. > * > * This program is free software; you can redistribute it and/or modify > @@ -971,7 +971,8 @@ int gpmi_extra_init(struct gpmi_nand_data *this) > struct nand_chip *chip = &this->nand; > > /* Enable the asynchronou
[PATCH kernel v4 04/11] powerpc/powernv: Define TCE Kill flags
This replaces magic constants for TCE Kill IODA2 register with macros.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
arch/powerpc/platforms/powernv/pci-ioda.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index ca307b6..03be25d 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1811,10 +1811,13 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
.get = pnv_tce_get,
};
+#define TCE_KILL_INVAL_PE PPC_BIT(1)
+#define TCE_KILL_INVAL_TCE PPC_BIT(2)
+
static inline void pnv_pci_ioda2_tce_invalidate_pe(struct pnv_ioda_pe *pe)
{
/* 01xb - invalidate TCEs that match the specified PE# */
- unsigned long val = (0x4ull << 60) | (pe->pe_number & 0xFF);
+ unsigned long val = TCE_KILL_INVAL_PE | (pe->pe_number & 0xFF);
struct pnv_phb *phb = pe->phb;
struct pnv_ioda_pe *npe;
int i;
@@ -1842,7 +1845,7 @@ static void pnv_pci_ioda2_do_tce_invalidate(unsigned
pe_number, bool rm,
unsigned long start, end, inc;
/* We'll invalidate DMA address in PE scope */
- start = 0x2ull << 60;
+ start = TCE_KILL_INVAL_TCE;
start |= (pe_number & 0xFF);
end = start;
--
2.5.0.rc3
Re: [PATCH v2 06/13] staging/android: remove name arg from sync_file_create()
>
> From: Gustavo Padovan
>
> Simplifies the API to only receive the fence it needs to add to the
> sync and create a name for the sync_file based on the fence context and
> seqno.
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
> ---
> drivers/staging/android/sync.c | 16 +---
> drivers/staging/android/sync.h | 2 +-
> drivers/staging/android/sync_debug.c | 3 +--
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index 7e0fa20..5470ae9 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -136,7 +136,7 @@ struct fence *sync_pt_create(struct sync_timeline *obj,
> int size)
> }
> EXPORT_SYMBOL(sync_pt_create);
>
> -static struct sync_file *sync_file_alloc(int size, const char *name)
> +static struct sync_file *sync_file_alloc(int size)
> {
> struct sync_file *sync_file;
>
> @@ -150,7 +150,6 @@ static struct sync_file *sync_file_alloc(int size, const
> char *name)
> goto err;
>
> kref_init(&sync_file->kref);
> - strlcpy(sync_file->name, name, sizeof(sync_file->name));
>
> init_waitqueue_head(&sync_file->wq);
>
> @@ -175,23 +174,25 @@ static void fence_check_cb_func(struct fence *f, struct
> fence_cb *cb)
>
> /**
> * sync_fence_create() - creates a sync fence
> - * @name:name of fence to create
> * @fence: fence to add to the sync_fence
> *
> * Creates a sync_file containg @fence. Once this is called, the sync_file
> * takes ownership of @fence.
> */
> -struct sync_file *sync_file_create(const char *name, struct fence *fence)
> +struct sync_file *sync_file_create(struct fence *fence)
> {
> struct sync_file *sync_file;
>
> - sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]),
> - name);
> + sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
> if (!sync_file)
> return NULL;
>
> sync_file->num_fences = 1;
> atomic_set(&sync_file->status, 1);
> + snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%d-%d",
> + fence->ops->get_driver_name(fence),
> + fence->ops->get_timeline_name(fence), fence->context,
> + fence->seqno);
>
> sync_file->cbs[0].fence = fence;
> sync_file->cbs[0].sync_file = sync_file;
> @@ -260,7 +261,7 @@ static struct sync_file *sync_file_merge(const char
> *name, struct sync_file *a,
> int i, i_a, i_b;
> unsigned long size = offsetof(struct sync_file, cbs[num_fences]);
>
> - sync_file = sync_file_alloc(size, name);
> + sync_file = sync_file_alloc(size);
> if (!sync_file)
> return NULL;
>
> @@ -306,6 +307,7 @@ static struct sync_file *sync_file_merge(const char
> *name, struct sync_file *a,
> atomic_sub(num_fences - i, &sync_file->status);
> sync_file->num_fences = i;
>
> + strlcpy(sync_file->name, name, sizeof(sync_file->name));
> sync_file_debug_add(sync_file);
> return sync_file;
> }
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index 1f164df..7dee444 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -167,7 +167,7 @@ void sync_timeline_signal(struct sync_timeline *obj);
> */
> struct fence *sync_pt_create(struct sync_timeline *parent, int size);
>
> -struct sync_file *sync_file_create(const char *name, struct fence *fence);
> +struct sync_file *sync_file_create(struct fence *fence);
>
> #ifdef CONFIG_DEBUG_FS
>
> diff --git a/drivers/staging/android/sync_debug.c
> b/drivers/staging/android/sync_debug.c
> index e4b0e41..2cab40d 100644
> --- a/drivers/staging/android/sync_debug.c
> +++ b/drivers/staging/android/sync_debug.c
> @@ -262,8 +262,7 @@ static long sw_sync_ioctl_create_fence(struct
> sw_sync_timeline *obj,
> goto err;
> }
>
> - data.name[sizeof(data.name) - 1] = '\0';
> - sync_file = sync_file_create(data.name, fence);
> + sync_file = sync_file_create(fence);
The name injected from user spce is ignored, why?
Is it a semantic change?
Mentioned in commit message?
> if (!sync_file) {
> fence_put(fence);
> err = -ENOMEM;
> --
> 2.5.5
>
>
[PATCH kernel v4 11/11] powerpc/powernv/npu: Enable NVLink pass through
IBM POWER8 NVlink systems come with Tesla K40-ish GPUs each of which
also has a couple of fast speed links (NVLink). The interface to links
is exposed as an emulated PCI bridge which is included into the same
IOMMU group as the corresponding GPU.
In the kernel, NPUs get a separate PHB of the PNV_PHB_NPU type and a PE
which behave pretty much as the standard IODA2 PHB except NPU PHB has
just a single TVE in the hardware which means it can have either
32bit window or 64bit window or DMA bypass but never two of these.
In order to make these links work when GPU is passed to the guest,
these bridges need to be passed as well; otherwise performance will
degrade.
This implements and exports API to manage NPU state in regard to VFIO;
it replicates iommu_table_group_ops.
This defines a new pnv_pci_ioda2_npu_ops which is assigned to
the IODA2 bridge if there are NPUs for a GPU on the bridge.
The new callbacks call the default IODA2 callbacks plus new NPU API.
This adds a gpe_table_group_to_npe() helper to find NPU PE for the IODA2
table_group, it is not expected to fail as the helper is only called
from the pnv_pci_ioda2_npu_ops.
This does not define NPU-specific .release_ownership() so after
VFIO is finished, DMA on NPU is disabled which is ok as the nvidia
driver sets DMA mask when probing which enable 32 or 64bit DMA on NPU.
This adds a pnv_pci_npu_setup_iommu() helper which adds NPUs to
the GPU group if any found. The helper uses helpers to look for
the "ibm,gpu" property in the device tree which is a phandle of
the corresponding GPU.
This adds an additional loop over PEs in pnv_ioda_setup_dma() as the main
loop skips NPU PEs as they do not have 32bit DMA segments.
As pnv_npu_set_window() and pnv_npu_unset_window() are started being used
by the new IODA2-NPU IOMMU group, this makes the helpers public and
adds the DMA window number parameter.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* reused pnv_npu_set_window/pnv_npu_unset_window where possible
* added comments, changed commit log
v3:
* moved NPU-to-GPU IOMMU grouping later after all PHBs are discovered
* removed hack to make iommu_add_device() work, iommu_group_add_device()
is used instead
* cleanup in gpe_table_group_to_npe_cb()
v2:
* reimplemented to support NPU + GPU in the same group
* merged "powerpc/powernv/npu: Add NPU devices to IOMMU group" and
"powerpc/powernv/npu: Enable passing through via VFIO" into this patch
---
arch/powerpc/platforms/powernv/npu-dma.c | 64 +--
arch/powerpc/platforms/powernv/pci-ioda.c | 102 ++
arch/powerpc/platforms/powernv/pci.h | 6 ++
3 files changed, 166 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index cb2d1da..0459e10 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -154,7 +155,7 @@ static struct pnv_ioda_pe *get_gpu_pci_dev_and_pe(struct
pnv_ioda_pe *npe,
return pe;
}
-static long pnv_npu_set_window(struct pnv_ioda_pe *npe,
+long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
struct iommu_table *tbl)
{
struct pnv_phb *phb = npe->phb;
@@ -182,13 +183,13 @@ static long pnv_npu_set_window(struct pnv_ioda_pe *npe,
pnv_pci_ioda2_tce_invalidate_entire(phb, false);
/* Add the table to the list so its TCE cache will get invalidated */
- pnv_pci_link_table_and_group(phb->hose->node, 0,
+ pnv_pci_link_table_and_group(phb->hose->node, num,
tbl, &npe->table_group);
return 0;
}
-static long pnv_npu_unset_window(struct pnv_ioda_pe *npe)
+long pnv_npu_unset_window(struct pnv_ioda_pe *npe, int num)
{
struct pnv_phb *phb = npe->phb;
int64_t rc;
@@ -205,7 +206,7 @@ static long pnv_npu_unset_window(struct pnv_ioda_pe *npe)
}
pnv_pci_ioda2_tce_invalidate_entire(phb, false);
- pnv_pci_unlink_table_and_group(npe->table_group.tables[0],
+ pnv_pci_unlink_table_and_group(npe->table_group.tables[num],
&npe->table_group);
return 0;
@@ -231,7 +232,7 @@ static void pnv_npu_dma_set_32(struct pnv_ioda_pe *npe)
if (!gpe)
return;
- rc = pnv_npu_set_window(npe, gpe->table_group.tables[0]);
+ rc = pnv_npu_set_window(npe, 0, gpe->table_group.tables[0]);
/*
* We don't initialise npu_pe->tce32_table as we always use
@@ -255,7 +256,7 @@ static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe)
if (phb->type != PNV_PHB_NPU || !npe->pdev)
return -EINVAL;
- rc = pnv_npu_unset_window(npe);
+ rc = pnv_npu_unset_window(npe, 0);
if (rc != OPAL_SUCCESS)
return rc;
@@ -307,3 +308,54 @@ void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev,
bool bypass)
Re: [PATCH 1/2 v6] ASoC: dwc: Add custom PCM driver
Hi Mark,
Can you give me some comments regarding this patch? Am I following the right
track? This is the first time that I am using ALSA SoC so pardon me if I am
making some mistake. I would appreciate some kind of input. I tested this only
on a ARC SDP and it is working.
On 27-04-2016 11:05, Jose Abreu wrote:
> HDMI audio support was added to the AXS board using an
> I2S cpu driver and a custom platform driver.
>
> The platform driver supports two channels @ 16 bits with
> rates 32k, 44.1k and 48k.
>
> Although the mainline I2S driver uses ALSA DMA engine,
> this controller can be built without DMA support so it
> was necessary to add this custom platform driver so that
> HDMI audio works in AXS boards.
>
> The selection between the use of DMA engine or PIO mode
> is detected by declaring or not the DMA parameters in
> the device tree.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Mark Brown
> Cc: Liam Girdwood
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Alexey Brodkin
> Cc: linux-snps-...@lists.infradead.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Changes v5 -> v6:
> * Use SNDRV_DMA_TYPE_CONTINUOUS
>
> Changes v4 -> v5:
> * Resolve undefined references when compiling as module
> * Use DMA properties in I2S to check which mode to use: PIO or DMA (as
> suggested by Lars-Peter Clausen)
>
> Changes v3 -> v4:
> * Reintroduced custom PCM driver
> * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
>
> Changes v2 -> v3:
> * Removed pll_config functions (as suggested by Alexey Brodkin)
> * Dropped custom platform driver, using now ALSA DMA engine
> * Dropped IRQ handler for I2S
>
> No changes v1 -> v2.
>
> sound/soc/dwc/Kconfig | 9 ++
> sound/soc/dwc/Makefile | 1 +
> sound/soc/dwc/designware.h | 71 +
> sound/soc/dwc/designware_i2s.c | 94 -
> sound/soc/dwc/designware_pcm.c | 228
> +
> 5 files changed, 376 insertions(+), 27 deletions(-)
> create mode 100644 sound/soc/dwc/designware.h
> create mode 100644 sound/soc/dwc/designware_pcm.c
>
> diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
> index d50e085..2a21120 100644
> --- a/sound/soc/dwc/Kconfig
> +++ b/sound/soc/dwc/Kconfig
> @@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
>Synopsys desigwnware I2S device. The device supports upto
>maximum of 8 channels each for play and record.
>
> +config SND_DESIGNWARE_PCM
> + tristate "Synopsys I2S PCM Driver"
> + help
> + Say Y or M if you want to add support for ALSA ASoC platform driver
> + using I2S.
> +
> + Select this option if you want to be able to create a sound interface
> + using the I2S device driver as CPU driver. Instead of using ALSA
> + DMA engine by selecting this driver a custom PCM driver will be used.
>
> diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
> index 319371f..1b48bccc 100644
> --- a/sound/soc/dwc/Makefile
> +++ b/sound/soc/dwc/Makefile
> @@ -1,3 +1,4 @@
> # SYNOPSYS Platform Support
> obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
> +obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
>
> diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
> new file mode 100644
> index 000..09fafee
> --- /dev/null
> +++ b/sound/soc/dwc/designware.h
> @@ -0,0 +1,71 @@
> +/*
> + * ALSA SoC Synopsys Audio Layer
> + *
> + * sound/soc/dwc/designware.h
> + *
> + * Copyright (C) 2016 Synopsys
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __DESIGNWARE_H
> +#define __DESIGNWARE_H
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct dw_pcm_binfo {
> + struct snd_pcm_substream *stream;
> + unsigned char *dma_base;
> + unsigned char *dma_pointer;
> + unsigned int period_size_frames;
> + unsigned int size;
> + snd_pcm_uframes_t period_pointer;
> + unsigned int total_periods;
> + unsigned int current_period;
> +};
> +
> +union dw_i2s_snd_dma_data {
> + struct i2s_dma_data pd;
> + struct snd_dmaengine_dai_dma_data dt;
> +};
> +
> +struct dw_i2s_dev {
> + void __iomem *i2s_base;
> + struct clk *clk;
> + int active;
> + unsigned int capability;
> + unsigned int quirks;
> + unsigned int i2s_reg_comp1;
> + unsigned int i2s_reg_comp2;
> + struct device *dev;
> + u32 ccr;
> + u32 xfer_resolution;
> + u32 fifo_th;
> +
> + /* data related to DMA transfers b/w i2s and DMAC */
> + bool use_dmaengine;
> + union dw_i2s_snd_dma_data play_dma_data;
> + union dw_i2s_snd_dma_data capture_dma_data;
> + struct i2s_clk_config_data config;
> + int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
> + struct dw_pcm_binfo binfo;
> +};
> +
> +#if IS
Re: [PATCH V5 4/4] gpio: tegra: Add support for gpio debounce
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan wrote: > NVIDIA's Tegra210 support the HW debounce in the GPIO controller > for all its GPIO pins. > > Add support for setting debounce timing by implementing the > set_debounce callback of gpiochip. > > Signed-off-by: Laxman Dewangan > Reviewed-by: Stephen Warren Patch applied, also added Alex' review tag. Yours, Linus Walleij
[PATCH kernel v4 08/11] powerpc/powernv/ioda2: Export debug helper pe_level_printk()
This exports debugging helper pe_level_printk() and corresponding macroses
so they can be used in npu-dma.c.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 +
arch/powerpc/platforms/powernv/pci.h | 9 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 272521e..db7695f 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -56,7 +56,7 @@
static void pnv_pci_ioda2_table_free_pages(struct iommu_table *tbl);
-static void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
+void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
const char *fmt, ...)
{
struct va_format vaf;
@@ -87,13 +87,6 @@ static void pe_level_printk(const struct pnv_ioda_pe *pe,
const char *level,
va_end(args);
}
-#define pe_err(pe, fmt, ...) \
- pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
-#define pe_warn(pe, fmt, ...) \
- pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
-#define pe_info(pe, fmt, ...) \
- pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
-
static bool pnv_iommu_bypass_disabled __read_mostly;
static int __init iommu_setup(char *str)
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index d574a9d..485e5b1 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -236,6 +236,15 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus *bus);
extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type);
extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
+extern void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
+ const char *fmt, ...);
+#define pe_err(pe, fmt, ...) \
+ pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
+#define pe_warn(pe, fmt, ...) \
+ pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
+#define pe_info(pe, fmt, ...) \
+ pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
+
/* Nvlink functions */
extern void pnv_npu_init_dma_pe(struct pnv_ioda_pe *npe);
extern void pnv_npu_setup_dma_pe(struct pnv_ioda_pe *npe);
--
2.5.0.rc3
[patch] iio: dac: ad5592r: Off by one bug in ad5592r_alloc_channels()
The > here should be >= or we go beyond the end for the array.
Signed-off-by: Dan Carpenter
diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
index 948f600..69bde59 100644
--- a/drivers/iio/dac/ad5592r-base.c
+++ b/drivers/iio/dac/ad5592r-base.c
@@ -525,7 +525,7 @@ static int ad5592r_alloc_channels(struct ad5592r_state *st)
device_for_each_child_node(st->dev, child) {
ret = fwnode_property_read_u32(child, "reg", ®);
- if (ret || reg > ARRAY_SIZE(st->channel_modes))
+ if (ret || reg >= ARRAY_SIZE(st->channel_modes))
continue;
ret = fwnode_property_read_u32(child, "adi,mode", &tmp);
Re: linux-next: manual merge of the tip tree with the arm64 tree
On Fri, 29 Apr, at 01:56:45PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/firmware/efi/arm-init.c
>
> between commits:
>
> 500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing
> them")
> 7464b6e3a5fb ("efi: ARM: avoid warning about phys_addr_t cast")
>
> from the arm64 tree and commits:
>
> 78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()")
> 884f4f66ffd6 ("efi: Remove global 'memmap' EFI memory map")
>
> from the tip tree.
[...]
> diff --cc drivers/firmware/efi/arm-init.c
> index fac567c3b66a,ef90f0c4b70a..
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@@ -143,15 -178,7 +178,15 @@@ static __init void reserve_regions(void
> if (efi_enabled(EFI_DBG))
> pr_info("Processing EFI memory map:\n");
>
> +/*
> + * Discard memblocks discovered so far: if there are any at this
> + * point, they originate from memory nodes in the DT, and UEFI
> + * uses its own memory map instead.
> + */
> +memblock_dump_all();
> +memblock_remove(0, (phys_addr_t)ULLONG_MAX);
> +
> - for_each_efi_memory_desc(&memmap, md) {
> + for_each_efi_memory_desc(md) {
> paddr = md->phys_addr;
> npages = md->num_pages;
>
This looks fine, thanks Stephen.
[PATCH kernel v4 00/11] powerpc/powernv/npu: Enable PCI pass through for NVLink
IBM POWER8 NVlink systems contain usual Tesla K40-ish GPUs but also contain a couple of really fast links between GPU and CPU. These links are exposed to the userspace by the OPAL firmware as bridges. In order to make these links work when GPU is passed to the guest, these bridges need to be passed as well; otherwise performance will degrade. More details are in 11/11. This reworks the existing NPU support in the powernv platform and adds VFIO support on top of that. v4 has new patch "powerpc/powernv/npu: Add set/unset window" and bunch of cleanups. "vfio_pci: Test for extended capabilities if config space > 256 bytes" is included here if anyone decides to test the patchset which will crash without it. This was tested on POWER8NVL platform; pvr=0x004c0100. Please comment. Thanks. Alex, I guess we will need your "acked-by" for "vfio/spapr: Relax the IOMMU compatibility check" to proceed. Alexey Kardashevskiy (11): vfio_pci: Test for extended capabilities if config space > 256 bytes vfio/spapr: Relax the IOMMU compatibility check powerpc/powernv: Rename pnv_pci_ioda2_tce_invalidate_entire powerpc/powernv: Define TCE Kill flags powerpc/powernv/npu: TCE Kill helpers cleanup powerpc/powernv/npu: Use the correct IOMMU page size powerpc/powernv/npu: Simplify DMA setup powerpc/powernv/ioda2: Export debug helper pe_level_printk() powerpc/powernv/npu: Add set/unset window helpers powerpc/powernv/npu: Rework TCE Kill handling powerpc/powernv/npu: Enable NVLink pass through arch/powerpc/platforms/powernv/npu-dma.c | 287 -- arch/powerpc/platforms/powernv/pci-ioda.c | 224 +++ arch/powerpc/platforms/powernv/pci.h | 31 ++-- drivers/vfio/pci/vfio_pci_config.c| 17 +- drivers/vfio/vfio_iommu_spapr_tce.c | 3 +- 5 files changed, 327 insertions(+), 235 deletions(-) -- 2.5.0.rc3
[PATCH kernel v4 07/11] powerpc/powernv/npu: Simplify DMA setup
NPU devices are emulated in firmware and mainly used for NPU NVLink
training; one NPU device is per a hardware link. Their DMA/TCE setup
must match the GPU which is connected via PCIe and NVLink so any changes
to the DMA/TCE setup on the GPU PCIe device need to be propagated to
the NVLink device as this is what device drivers expect and it doesn't
make much sense to do anything else.
This makes NPU DMA setup explicit.
pnv_npu_ioda_controller_ops::pnv_npu_dma_set_mask is moved to pci-ioda,
made static and prints warning as dma_set_mask() should never be called
on this function as in any case it will not configure GPU; so we make
this explicit.
Instead of using PNV_IODA_PE_PEER and peers[] (which the next patch will
remove), we test every PCI device if there are corresponding NVLink
devices. If there are any, we propagate bypass mode to just found NPU
devices by calling the setup helper directly (which takes @bypass) and
avoid guessing (i.e. calculating from DMA mask) whether we need bypass
or not on NPU devices. Since DMA setup happens in very rare occasion,
this will not slow down booting or VFIO start/stop much.
This renames pnv_npu_disable_bypass to pnv_npu_dma_set_32 to make it
more clear what the function really does which is programming 32bit
table address to the TVT ("disabling bypass" means writing zeroes to
the TVT).
This removes pnv_npu_dma_set_bypass() from pnv_npu_ioda_fixup() as
the DMA configuration on NPU does not matter until dma_set_mask() is
called on GPU and that will do the NPU DMA configuration.
This removes phb->dma_dev_setup initialization for NPU as
pnv_pci_ioda_dma_dev_setup is no-op for it anyway.
This stops using npe->tce_bypass_base as it never changes and values
other than zero are not supported.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
Reviewed-by: Alistair Popple
---
Changes:
v2:
* changed first paragraph of the commit log from Alistair comment
* removed npe->tce_bypass_base
---
arch/powerpc/platforms/powernv/npu-dma.c | 89 ++-
arch/powerpc/platforms/powernv/pci-ioda.c | 30 +--
arch/powerpc/platforms/powernv/pci.h | 3 +-
3 files changed, 53 insertions(+), 69 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 5bd5fee..bec9267 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -196,10 +196,9 @@ void pnv_npu_init_dma_pe(struct pnv_ioda_pe *npe)
}
/*
- * For the NPU we want to point the TCE table at the same table as the
- * real PCI device.
+ * Enables 32 bit DMA on NPU.
*/
-static void pnv_npu_disable_bypass(struct pnv_ioda_pe *npe)
+static void pnv_npu_dma_set_32(struct pnv_ioda_pe *npe)
{
struct pnv_phb *phb = npe->phb;
struct pci_dev *gpdev;
@@ -235,72 +234,62 @@ static void pnv_npu_disable_bypass(struct pnv_ioda_pe
*npe)
}
/*
- * Enable/disable bypass mode on the NPU. The NPU only supports one
+ * Enables bypass mode on the NPU. The NPU only supports one
* window per link, so bypass needs to be explicitly enabled or
* disabled. Unlike for a PHB3 bypass and non-bypass modes can't be
* active at the same time.
*/
-int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe, bool enable)
+static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe)
{
struct pnv_phb *phb = npe->phb;
int64_t rc = 0;
+ phys_addr_t top = memblock_end_of_DRAM();
if (phb->type != PNV_PHB_NPU || !npe->pdev)
return -EINVAL;
- if (enable) {
- /* Enable the bypass window */
- phys_addr_t top = memblock_end_of_DRAM();
+ /* Enable the bypass window */
- npe->tce_bypass_base = 0;
- top = roundup_pow_of_two(top);
- dev_info(&npe->pdev->dev, "Enabling bypass for PE %d\n",
-npe->pe_number);
- rc = opal_pci_map_pe_dma_window_real(phb->opal_id,
- npe->pe_number, npe->pe_number,
- npe->tce_bypass_base, top);
- } else {
- /*
-* Disable the bypass window by replacing it with the
-* TCE32 window.
-*/
- pnv_npu_disable_bypass(npe);
- }
+ top = roundup_pow_of_two(top);
+ dev_info(&npe->pdev->dev, "Enabling bypass for PE %d\n",
+ npe->pe_number);
+ rc = opal_pci_map_pe_dma_window_real(phb->opal_id,
+ npe->pe_number, npe->pe_number,
+ 0 /* bypass base */, top);
return rc;
}
-int pnv_npu_dma_set_mask(struct pci_dev *npdev, u64 dma_mask)
+void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass)
{
- struct pci_controller *hose = pci_bus_to_host(npdev->bus);
- struct pnv_phb *phb = hose->private_data;
- struct pci_dn *pdn = pci_get_pdn(npdev);
-
[PATCH kernel v4 10/11] powerpc/powernv/npu: Rework TCE Kill handling
The pnv_ioda_pe struct keeps an array of peers. At the moment it is only
used to link GPU and NPU for 2 purposes:
1. Access NPU quickly when configuring DMA for GPU - this was addressed
in the previos patch by removing use of it as DMA setup is not what
the kernel would constantly do.
2. Invalidate TCE cache for NPU when it is invalidated for GPU.
GPU and NPU are in different PE. There is already a mechanism to
attach multiple iommu_table_group to the same iommu_table (used for VFIO),
we can reuse it here so does this patch.
This gets rid of peers[] array and PNV_IODA_PE_PEER flag as they are
not needed anymore.
While we are here, add TCE cache invalidation after enabling bypass.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* reworked as "powerpc/powernv/npu: Add set/unset window helpers" has been
added
---
arch/powerpc/platforms/powernv/npu-dma.c | 69 +--
arch/powerpc/platforms/powernv/pci-ioda.c | 57 -
arch/powerpc/platforms/powernv/pci.h | 6 ---
3 files changed, 26 insertions(+), 106 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 800d70f..cb2d1da 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -136,22 +136,17 @@ static struct pnv_ioda_pe *get_gpu_pci_dev_and_pe(struct
pnv_ioda_pe *npe,
struct pnv_ioda_pe *pe;
struct pci_dn *pdn;
- if (npe->flags & PNV_IODA_PE_PEER) {
- pe = npe->peers[0];
- pdev = pe->pdev;
- } else {
- pdev = pnv_pci_get_gpu_dev(npe->pdev);
- if (!pdev)
- return NULL;
+ pdev = pnv_pci_get_gpu_dev(npe->pdev);
+ if (!pdev)
+ return NULL;
- pdn = pci_get_pdn(pdev);
- if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
- return NULL;
+ pdn = pci_get_pdn(pdev);
+ if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
+ return NULL;
- hose = pci_bus_to_host(pdev->bus);
- phb = hose->private_data;
- pe = &phb->ioda.pe_array[pdn->pe_number];
- }
+ hose = pci_bus_to_host(pdev->bus);
+ phb = hose->private_data;
+ pe = &phb->ioda.pe_array[pdn->pe_number];
if (gpdev)
*gpdev = pdev;
@@ -186,6 +181,10 @@ static long pnv_npu_set_window(struct pnv_ioda_pe *npe,
}
pnv_pci_ioda2_tce_invalidate_entire(phb, false);
+ /* Add the table to the list so its TCE cache will get invalidated */
+ pnv_pci_link_table_and_group(phb->hose->node, 0,
+ tbl, &npe->table_group);
+
return 0;
}
@@ -206,45 +205,12 @@ static long pnv_npu_unset_window(struct pnv_ioda_pe *npe)
}
pnv_pci_ioda2_tce_invalidate_entire(phb, false);
+ pnv_pci_unlink_table_and_group(npe->table_group.tables[0],
+ &npe->table_group);
+
return 0;
}
-void pnv_npu_init_dma_pe(struct pnv_ioda_pe *npe)
-{
- struct pnv_ioda_pe *gpe;
- struct pci_dev *gpdev;
- int i, avail = -1;
-
- if (!npe->pdev || !(npe->flags & PNV_IODA_PE_DEV))
- return;
-
- gpe = get_gpu_pci_dev_and_pe(npe, &gpdev);
- if (!gpe)
- return;
-
- for (i = 0; i < PNV_IODA_MAX_PEER_PES; i++) {
- /* Nothing to do if the PE is already connected. */
- if (gpe->peers[i] == npe)
- return;
-
- if (!gpe->peers[i])
- avail = i;
- }
-
- if (WARN_ON(avail < 0))
- return;
-
- gpe->peers[avail] = npe;
- gpe->flags |= PNV_IODA_PE_PEER;
-
- /*
-* We assume that the NPU devices only have a single peer PE
-* (the GPU PCIe device PE).
-*/
- npe->peers[0] = gpe;
- npe->flags |= PNV_IODA_PE_PEER;
-}
-
/*
* Enables 32 bit DMA on NPU.
*/
@@ -302,6 +268,9 @@ static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe)
npe->pe_number, npe->pe_number,
0 /* bypass base */, top);
+ if (rc == OPAL_SUCCESS)
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
+
return rc;
}
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index db7695f..922c74c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1816,23 +1816,12 @@ static inline void
pnv_pci_ioda2_tce_invalidate_pe(struct pnv_ioda_pe *pe)
/* 01xb - invalidate TCEs that match the specified PE# */
unsigned long val = TCE_KILL_INVAL_PE | (pe->pe_number & 0xFF);
struct pnv_phb *phb = pe->phb;
- struct pnv_ioda_pe *npe;
- int i;
if (!phb->ioda.tce_inval_reg)
return;
Re: [PATCH V4] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar
On Thursday 14 April 2016 03:07 PM, Rafał Miłecki wrote:
> Northstar is a family of SoCs used in home routers. They have USB 2.0
> and 3.0 controllers with PHYs that need to be properly initialized.
> This driver provides PHY init support in a generic way and can be bound
> with an EHCI controller driver.
> There are (just a few) registers being defined in bcma header. It's
> because DMU/CRU registers will be also needed in other drivers. We will
> need them e.g. in PCIe controller/PHY driver and at some point probably
> in clock driver for BCM53573 chipset. By using include/linux/bcma/ we
> avoid code duplication.
merged, thanks.
-Kishon
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Support reg-names and clock-names. As you can see PHY PLL is
> controlled over DMU, not a separated PHY registers range. This may
> be a bit confusing and even less clear if we happen to support more
> complex hardware in the future. Using a clear name should make code
> cleaner.
> Also use struct device *dev helpers to make code simpler.
> V3: Update Kconfig entry fixing 2.0 vs. 3.0 typo and removing info about
> bcma (this driver is not bcma specific).
> V4: Drop unneeded #clock-cells = <0>; from Documentation
> Do ioremap in probe function
> Switch to readl and writel
> Slightly optimize usb_pll_pdiv calculation
> Describe 0xea68 as magic value (we don't know bits meaning)
> Fix MODULE_LICENSE
> Update commit message
> ---
> .../devicetree/bindings/phy/bcm-ns-usb2-phy.txt| 21
> drivers/phy/Kconfig| 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-bcm-ns-usb2.c | 137
> +
> include/linux/bcma/bcma.h | 1 +
> include/linux/bcma/bcma_driver_arm_c9.h| 15 +++
> 6 files changed, 184 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> create mode 100644 drivers/phy/phy-bcm-ns-usb2.c
> create mode 100644 include/linux/bcma/bcma_driver_arm_c9.h
>
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> new file mode 100644
> index 000..a7aee9e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> @@ -0,0 +1,21 @@
> +Driver for Broadcom Northstar USB 2.0 PHY
> +
> +Required properties:
> +- compatible: brcm,ns-usb2-phy
> +- reg: iomem address range of DMU (Device Management Unit)
> +- reg-names: "dmu", the only needed & supported reg right now
> +- clocks: USB PHY reference clock
> +- clock-names: "phy-ref-clk", the only needed & supported clock right now
> +
> +To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
> +requires passing phandle to the USB PHY reference clock.
> +
> +Example:
> + usb2-phy {
> + compatible = "brcm,ns-usb2-phy";
> + reg = <0x1800c000 0x1000>;
> + reg-names = "dmu";
> + #phy-cells = <0>;
> + clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
> + clock-names = "phy-ref-clk";
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..3292502 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,6 +15,15 @@ config GENERIC_PHY
> phy users can obtain reference to the PHY. All the users of this
> framework should select this config.
>
> +config PHY_BCM_NS_USB2
> + tristate "Broadcom Northstar USB 2.0 PHY Driver
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + select GENERIC_PHY
> + help
> + Enable this to support Broadcom USB 2.0 PHY connected to the USB
> + controller on Northstar family.
> +
> config PHY_BERLIN_USB
> tristate "Marvell Berlin USB PHY Driver"
> depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..9c8f08d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,6 +3,7 @@
> #
>
> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> +obj-$(CONFIG_PHY_BCM_NS_USB2)+= phy-bcm-ns-usb2.o
> obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
> obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
> diff --git a/drivers/phy/phy-bcm-ns-usb2.c b/drivers/phy/phy-bcm-ns-usb2.c
> new file mode 100644
> index 000..95ab6b2
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-ns-usb2.c
> @@ -0,0 +1,137 @@
> +/*
> + * Broadcom Northstar USB 2.0 PHY Driver
> + *
> + * Copyright (C) 2016 Rafał Miłecki
> + *
> + * 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.
> + *
> + */
Re: [PATCH V5 0/4] gpio: tegra: Cleanups and support for debounce
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan wrote: > Add support for the debounce as Tegra210 support debounce in HW. > Also do the clenaups to remove all global variables. OK this v5 is applied. Laxman does this GPIO also have open drain and/or open source handling? Then you might want to look into supporting that too as I just added support for native single-endedness to gpiolib, c.f.: http://marc.info/?l=linux-gpio&m=146011780301280&w=2 It would be nice if you also implement .get_direction() which makes debugfs and initial reading of the state of the lines more accurate. Yours, Linus Walleij
