[PATCH] staging: dgnc: re-arrange functions for removing forward declarations
Re-arrange the functions for removing forward declarations in dgnc_driver.c Signed-off-by: Daeseok Youn --- I've checked the object size of dgnc_driver.c before and after. It has same size after re-arranging functions. drivers/staging/dgnc/dgnc_driver.c | 533 ++--- 1 file changed, 261 insertions(+), 272 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_driver.c b/drivers/staging/dgnc/dgnc_driver.c index d3243a3..6f2bffa 100644 --- a/drivers/staging/dgnc/dgnc_driver.c +++ b/drivers/staging/dgnc/dgnc_driver.c @@ -31,21 +31,6 @@ MODULE_DESCRIPTION("Driver for the Digi International Neo and Classic PCI based product line"); MODULE_SUPPORTED_DEVICE("dgnc"); -/** - * - * protos for this file - * - */ -static int dgnc_start(void); -static int dgnc_request_irq(struct dgnc_board *brd); -static void dgnc_free_irq(struct dgnc_board *brd); -static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id); -static voiddgnc_cleanup_board(struct dgnc_board *brd); -static voiddgnc_poll_handler(ulong dummy); -static int dgnc_init_one(struct pci_dev *pdev, - const struct pci_device_id *ent); -static int dgnc_do_remap(struct dgnc_board *brd); - /* * File operations permitted on Control/Management major. */ @@ -114,261 +99,23 @@ struct board_id { { NULL, 0, 0 } }; -static struct pci_driver dgnc_driver = { - .name = "dgnc", - .probe = dgnc_init_one, - .id_table = dgnc_pci_tbl, -}; - -/ - * - * Driver load/unload functions - * - / - -static void cleanup(bool sysfiles) -{ - int i; - unsigned long flags; - - spin_lock_irqsave(&dgnc_poll_lock, flags); - dgnc_poll_stop = 1; - spin_unlock_irqrestore(&dgnc_poll_lock, flags); - - /* Turn off poller right away. */ - del_timer_sync(&dgnc_poll_timer); - - if (sysfiles) - dgnc_remove_driver_sysfiles(&dgnc_driver); - - device_destroy(dgnc_class, MKDEV(dgnc_major, 0)); - class_destroy(dgnc_class); - unregister_chrdev(dgnc_major, "dgnc"); - - for (i = 0; i < dgnc_num_boards; ++i) { - dgnc_remove_ports_sysfiles(dgnc_board[i]); - dgnc_cleanup_tty(dgnc_board[i]); - dgnc_cleanup_board(dgnc_board[i]); - } - -} - -/* - * dgnc_cleanup_module() - * - * Module unload. This is where it all ends. - */ -static void __exit dgnc_cleanup_module(void) -{ - cleanup(true); - pci_unregister_driver(&dgnc_driver); -} - -/* - * init_module() - * - * Module load. This is where it all starts. - */ -static int __init dgnc_init_module(void) -{ - int rc; - - /* -* Initialize global stuff -*/ - rc = dgnc_start(); - - if (rc < 0) - return rc; - - /* -* Find and configure all the cards -*/ - rc = pci_register_driver(&dgnc_driver); - if (rc) { - pr_warn("WARNING: dgnc driver load failed. No Digi Neo or Classic boards found.\n"); - cleanup(false); - return rc; - } - dgnc_create_driver_sysfiles(&dgnc_driver); - - return 0; -} -module_init(dgnc_init_module); -module_exit(dgnc_cleanup_module); /* - * Start of driver. + * Remap PCI memory. */ -static int dgnc_start(void) +static int dgnc_do_remap(struct dgnc_board *brd) { int rc = 0; - unsigned long flags; - struct device *dev; - - /* make sure timer is initialized before we do anything else */ - init_timer(&dgnc_poll_timer); - - /* -* Register our base character device into the kernel. -* This allows the download daemon to connect to the downld device -* before any of the boards are init'ed. -* -* Register management/dpa devices -*/ - rc = register_chrdev(0, "dgnc", &dgnc_board_fops); - if (rc < 0) { - pr_err(DRVSTR ": Can't register dgnc driver device (%d)\n", rc); - return rc; - } - dgnc_major = rc; - - dgnc_class = class_create(THIS_MODULE, "dgnc_mgmt"); - if (IS_ERR(dgnc_class)) { - rc = PTR_ERR(dgnc_class); - pr_err(DRVSTR ": Can't create dgnc_mgmt class (%d)\n", rc); - goto failed_class; - } - - dev = device_create(dgnc_class, NULL, - MKDEV(dgnc_major, 0), - NULL, "dgnc_mgmt"); - if (IS_ERR(dev)) { - rc = PTR_ERR(dev); - pr_err(DRVSTR ": Can't create device (%d)\n", rc); - goto failed_device; - } - -
Re: BYD TouchPad driver (4.8.1) misdetects a Logitech mouse
On Friday 11 November 2016, Eric Wong wrote: > Sorry for the late response, forwarding to Dmitry and linux-input. > I haven't dealt with input in years... > > Michael Shell wrote: > > Not a big deal, but something nonetheless ... > > > > I recently upgraded my kernel from 4.3 to 4.8.1 (this is a Linux From > > Scratch build). There was only one obvious hiccup - X would not > > start because it no longer saw the mouse. > > > > I have a Logitech RX250 PS2/USB mouse on the PS/2 port (via a USB->PS2 > > adapter): > > > > http://support.logitech.com/en_gb/product/rx250-mouse > > > > The RX250 is a wheel mouse, but with an added left/right scroll wheel > > "tilt" feature to provide for horizontal scrolling. > > > > In my xorg.conf I had: > > > > > > Section "InputDevice" > > Identifier "Mouse0" > > Driver "evdev" > > Option "Name" "ImExPS/2 Logitech Explorer Mouse" > > EndSection > > > > > > However, under the 4.8.1 kernel, cat /proc/bus/input/devices shows: > > > > > > I: Bus=0011 Vendor=0002 Product=0006 Version=0073 > > N: Name="ImExPS/2 BYD TouchPad" > > P: Phys=isa0060/serio1/input0 > > S: Sysfs=/devices/platform/i8042/serio1/input/input3 > > U: Uniq= > > H: Handlers=mouse0 event2 > > B: PROP=1 > > B: EV=7 > > B: KEY=1f 0 0 0 0 0 0 0 0 > > B: REL=143 > > > > > > and dmesg shows the lines: > > > > > > psmouse serio1: logips2pp: Detected unknown Logitech mouse model 115 > > input: ImExPS/2 BYD TouchPad as > > /devices/platform/i8042/serio1/input/input3 > > > > > > Changing the mouse name in xorg.conf to "ImExPS/2 BYD TouchPad" did > > allow the mouse to work correctly under X, including the tilt buttons. > > FWIW, in the 4.8.1 kernel config, the byd.c driver does default to > > "Yes", a default which I accepted under make oldconfig. > > > > Apparently, the detection code (byd_detect) in the new byd.c driver, > > which did not even exist in 4.3, (drivers/input/mouse/byd.c) falsely > > sees the Logitech RX250 as being a BYD TouchPad and thus alters the > > vendor and model names. > > > > I do not know if it is also desirable to add an entry for a Logitech > > model 115 in get_model_info in logips2pp.c > > (drivers/input/mouse/logips2pp.c). But if so, I would be willing to > > test any such new code. Even as an unknown Logitech model, it does > > work just fine. I am curious as to how the tilt feature buttons would > > be declared in the model info (would these be PS2PP_EXTRA_BTN, > > or PS2PP_NAV_BTN, etc.?) > > > > > > > > Cheers and thanks in advance, > > > > Mike Shell The BYD detection is broken. I've seen at least 3 different mice detected as BYD touchpad. -- Ondrej Zary
Re: [PATCH v4 1/5] arm64: perf: Basic uncore counter support for Cavium ThunderX SOC
On Thu, Nov 10, 2016 at 04:54:06PM +, Mark Rutland wrote: > > +/* > > + * Some notes about the various counters supported by this "uncore" PMU > > + * and the design: > > + * > > + * All counters are 64 bit long. > > + * There are no overflow interrupts. > > + * Counters are summarized per node/socket. > > + * Most devices appear as separate PCI devices per socket with the > > exception > > + * of OCX TLK which appears as one PCI device per socket and contains > > several > > + * units with counters that are merged. > > As a general note, as I commented on the QC L2 PMU driver [1,2], we need > to figure out if we should be aggregating physical PMUs or not. As said before, although it would be possible to create separate PMUs for each unit, the individual counters are not interesting. For example we are not interested in individual counters of Tag-and-data unit 0..7, we just want the global view. > Judging by subsequent patches, each unit has individual counters and > controls, and thus we cannot atomically read/write counters or controls > across them. As such, I do not think we should aggregate them, and > should expose them separately to userspace. That sounds like just moving the problem of aggregating the counters to user-space. And would make the results even worse, if the user needs several calls to summarize the counters, given how slow a perf counter read is. > That will simplify a number of things (e.g. the CPU migration code no > longer has to iterate over a list of units). Sure, it simplifies the kernel part, but it moves the cost to the user.
Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
On 10/11/16 19:03, Olof Johansson wrote: On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla wrote: On 10/11/16 14:12, Rob Herring wrote: On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla wrote: On 10/11/16 01:22, Rob Herring wrote: On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: This patch adds specific compatible to support legacy SCPI protocol. Cc: Rob Herring Signed-off-by: Sudeep Holla --- Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index d1882c4540d0..ebd03fc93135 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations. Required properties: -- compatible : should be "arm,scpi" +- compatible : should be + * "arm,scpi" : For implementations complying to SCPI v1.0 or above + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0 I'd prefer that we explicitly enumerate the old versions. Are there many? I understand your concern, but this legacy SCPI protocol was not officially released. It was just WIP which vendors picked up from very early releases. Since they are not numbered, it's hard to have specific compatibles with different versions until v1.0. That's one of the reason to retain platform specific compatible so that we can add any quirks based on them if needed. I will probably add these information in the commit log so that it's clear why we can't do version based compatible. This is exactly my point. By enumerate, I meant having platform specific compatibles. Having "arm,legacy-scpi" is pointless because who knows what version they followed and they may all be different. OK, but IIUC Olof's concern wanted a generic one along with the platform specific compatible which kind of makes sense as so far we have seen some commonality between Amlogic and Rockchip. E.g. Amlogic follows most of the legacy protocol though it deviates in couple of things which we can handle with platform specific compatible (in the following patch in the series). When another user(Rockchip ?) make use of this legacy protocol, we can start using those platform specific compatible for deviations only. Is that not acceptable ? If there's no shared legacy feature set, then it's probably less useful to have a shared less precise compatible value. There is and will be some shared feature set for sure. At the least the standard command set will be shared. What the main point I was trying to get across was that we shouldn't expand the generic binding with per-vendor compatible fields, instead we should have those as extensions on the side. Yes I get the point. We will have per-vendor compatibles for handle the deviations but generic one to handle the shared set. I'm also a little apprehensive of using "legacy", it goes in the same bucket as "misc". At some point 1.0 will be legacy too, etc. True and I agree, how about "arm,scpi-pre-1.0" instead ? -- Regards, Sudeep
Re: [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support
On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote: > Quoting Peter Chen (2016-10-18 02:31:40) > > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote: > > > I've also sent separate patches for other minor pieces to make this > > > all work. The full tree can be found here[2], hacks and all to get > > > things working. I've tested this on the db410c, apq8074 dragonboard, > > > and ifc6410 with configfs gadgets and otg cables. > > > > > > Patches based on v4.8-rc1 > > Oops should be v4.9-rc1 here. > > > > > > > Changes from v4: > > > * Picked up Acks from Rob > > > * Updated HS phy init sequence DT property to restrict it to offsets > > > > I remembered that you got all my acks for chipidea patches, right? I did > > not check for this series. > > Sorry I've added in one more patch > >usb: chipidea: Emulate OTGSC interrupt enable path > > to fix extcon interrupt emulation even further. > > > > > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a > > provider" [1] still not be accepted, I need this patch to be merged > > first, then apply your chipidea part, otherwise, there is a building > > warning. > > > > [1] https://patchwork.kernel.org/patch/9322583/ > > Yes, I'm going to resend that patch now. I hope that David will apply it > for -rc2. Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on it), your GPU fix is still not there. -- Best Regards, Peter Chen
Re: [patch v5] i2c: mux: mellanox: add driver
On 2016-11-10 13:56, Vadim Pasternak wrote: > > >> -Original Message- >> From: Peter Rosin [mailto:p...@axentia.se] >> Sent: Thursday, November 10, 2016 1:13 PM >> To: Vadim Pasternak ; w...@the-dreams.de >> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; >> j...@resnulli.us; >> Michael Shych >> Subject: Re: [patch v5] i2c: mux: mellanox: add driver >> >> [resend to all, got the wrong button, sorry] >> >> On 2016-11-10 11:42, Peter Rosin wrote: >>> On 2016-11-03 06:20, Vadim Pasternak wrote: Hi, I see that this patch has not been picked-up yet for i2c-next. Is it possible it was missed from some reason? >>> >>> Yes, apparently, really sorry about that! >>> >>> I'll put it in a branch and make a pull request for Wolfram (but that >>> is a bit new for me, we'll see how it goes). >> >> But now that I looked again, I noticed that the source is dual licensed and >> yet >> your MODULE_LICENSE tag says only "GPL v2". I.e. the same issue your i2c >> master driver had that Vladimir Zapolskiy noticed. >> >> Please fix this, and it might be a good idea to take a look in your other >> drivers as >> well in case you have further problems in this department... > > Hi Peter, > > Thank you for reply. > I'll re-submit it from the current i2c next branch. > Since I'll fix the license, I guess I should issue it as "patch v6". Right? Sounds right, yes. Cheers, Peter
Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks
* Peter Zijlstra wrote: > On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote: > > A possible alternative to nested spinlocks is to use a single rw_lock to > > protect changes to the monr hierarchy. > > > > This works because, when manipulating pmonrs, the monr hierarchy (monr's > > parent and children) is read but never changed (reader path). > > Changes to the monr hierarchy do change pmonrs (writer path). > > > > It would be implemented like: > > > > // system-wide lock for monr hierarchy > > rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock); > > > > > > Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions > > and when reading cgroups (read subtree of pmonrs in same package): > > > > v3 (old): > > > > raw_spin_lock(&pkgd->lock); > > // read monr data, read/write pmonr data > > raw_spin_unlock(&pkgd->lock); > > > > next version: > > > > read_lock(&monr_hrchy_rwlock); > > raw_spin_lock(&pkgd->lock); > > // read monr data, read/write pmonr data > > raw_spin_unlock(&pkgd->lock); > > read_unlock(&monr_hrchy_rwlock); > > > > > > Writer Path: Modifies monr hierarchy (add/remove monr in > > creation/destruction of events and start/stop monitoring > > of cgroups): > > > > v3 (old): > > > > monr_hrchy_acquire_locks(...); // acquires all pkg->lock > > // read/write monr data, potentially read/write pmonr data > > monr_hrchy_release_locks(...); // release all pkg->lock > > > > v4: > > > > write_lock(&monr_hrchy_rwlock); > > // read/write monr data, potentially read/write pmonr data > > write_unlock(&monr_hrchy_rwlock); > > > > > > The write-path should occur infrequently. The reader-path > > is slower due to the additional read_lock(&monr_hrchy_rwlock). > > The number of locks to acquire remains constant on the number of > > packages in both paths. There would be no need to ever nest pkgd->lock's. > > > > For v3, I discarded this idea because, due to the additional > > read_lock(&monr_hrchy_rwlock), the pmonr state transitions that may > > occur in a context switch would be slower than in the current version. > > But it may be ultimately better considering the scalability issues > > that you mention. > > Well, its very hard to suggest alternatives, because there simply isn't > anything of content here. This patch just adds locks, and the next few > patches don't describe much either. > > Why can't this be RCU? > > Also, "monr" is a horribly 'word'. And 'hrchy' is a hrbbl wrd as wll! Thanks, Ingo
Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks
On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote: > A possible alternative to nested spinlocks is to use a single rw_lock to > protect changes to the monr hierarchy. > > This works because, when manipulating pmonrs, the monr hierarchy (monr's > parent and children) is read but never changed (reader path). > Changes to the monr hierarchy do change pmonrs (writer path). > > It would be implemented like: > > // system-wide lock for monr hierarchy > rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock); > > > Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions > and when reading cgroups (read subtree of pmonrs in same package): > > v3 (old): > > raw_spin_lock(&pkgd->lock); > // read monr data, read/write pmonr data > raw_spin_unlock(&pkgd->lock); > > next version: > > read_lock(&monr_hrchy_rwlock); > raw_spin_lock(&pkgd->lock); > // read monr data, read/write pmonr data > raw_spin_unlock(&pkgd->lock); > read_unlock(&monr_hrchy_rwlock); > > > Writer Path: Modifies monr hierarchy (add/remove monr in > creation/destruction of events and start/stop monitoring > of cgroups): > > v3 (old): > > monr_hrchy_acquire_locks(...); // acquires all pkg->lock > // read/write monr data, potentially read/write pmonr data > monr_hrchy_release_locks(...); // release all pkg->lock > > v4: > > write_lock(&monr_hrchy_rwlock); > // read/write monr data, potentially read/write pmonr data > write_unlock(&monr_hrchy_rwlock); > > > The write-path should occur infrequently. The reader-path > is slower due to the additional read_lock(&monr_hrchy_rwlock). > The number of locks to acquire remains constant on the number of > packages in both paths. There would be no need to ever nest pkgd->lock's. > > For v3, I discarded this idea because, due to the additional > read_lock(&monr_hrchy_rwlock), the pmonr state transitions that may > occur in a context switch would be slower than in the current version. > But it may be ultimately better considering the scalability issues > that you mention. Well, its very hard to suggest alternatives, because there simply isn't anything of content here. This patch just adds locks, and the next few patches don't describe much either. Why can't this be RCU? Also, "monr" is a horribly 'word'.
Re: question about clk_get_parent
On Thu, 10 Nov 2016, Russell King - ARM Linux wrote: > On Thu, Nov 10, 2016 at 09:55:16PM +0100, Julia Lawall wrote: > > As far as I can see in the various definitions of clk_get_parent, they all > > return either NULL or a value stored in a structure field. But the > > documentation with the prototype in includ/linux/clk.h says that it > > returns a valid IS_ERR() condition containing errno. Are ERR_PTR values > > stored in the structure fields? > > The API documentation (in clk.h) is correct. The API (from the user > perspective) considers invalid clocks to be the set of pointers for > which IS_ERR() is true. > > By implication, valid clocks are those for which IS_ERR() returns > false. > > Hence, in order for clk_get_parent() to indicate an error, it has to > return a pointer value which corresponds with IS_ERR() being true. > > The question over the NULL clock pointer is left to the implementation > to decide whether it's an error or not as far as the API design goes, > but practically everyone treats it as "there is no clock" which is > entirely reasonable. > > Also, remember from the clk API design point of view, users of the > API should never dereference the clk pointer, it is a cookie as far > as users should be concerned. (The clk structure was not available to > drivers in the early days.) Only clk implementations and clk drivers > should dereference, and these should not dereference anything but > their own clocks. Thanks for the explanation, but I'm not sure how to relate it to what is in the code. For example, in drivers/clk/clk.c, there is: { struct clk *parent; if (!clk) return NULL; clk_prepare_lock(); /* TODO: Create a per-user clk and change callers to call clk_put */ parent = !clk->core->parent ? NULL : clk->core->parent->hw->clk; clk_prepare_unlock(); return parent; } Could clk->core->parent->hw->clk return an ERR_PTR value? Or is the point that from the clock point of view, this definition never fails? thanks, julia > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. >
[PATCH net 0/2] r8152: rx patches
Let the rx sw checksum available and add some checks for rx desc. Hayes Wang (2): r8152: fix the sw rx checksum is unavailable r8152: rx descriptor check drivers/net/usb/r8152.c | 46 +- 1 file changed, 45 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
Fix the hw rx checksum is always enabled, and the user couldn't switch it to sw rx checksum. Note that the RTL_VER_01 only supports sw rx checksum only. Besides, the hw rx checksum for RTL_VER_02 is disabled after commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 75c5168..0e42a78 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc) u8 checksum = CHECKSUM_NONE; u32 opts2, opts3; - if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02) + if (!(tp->netdev->features & NETIF_F_RXCSUM)) goto return_result; opts2 = le32_to_cpu(rx_desc->opts2); @@ -4307,6 +4307,11 @@ static int rtl8152_probe(struct usb_interface *intf, NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | NETIF_F_IPV6_CSUM | NETIF_F_TSO6; + if (tp->version == RTL_VER_01) { + netdev->features &= ~NETIF_F_RXCSUM; + netdev->hw_features &= ~NETIF_F_RXCSUM; + } + netdev->ethtool_ops = &ops; netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE); -- 2.7.4
[PATCH net 2/2] r8152: rx descriptor check
For some platforms, the data in memory is not the same with the one from the device. That is, the data of memory is unbelievable. The check is used to find out this situation. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 49 + 1 file changed, 49 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 0e42a78..e766121 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1756,6 +1756,43 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc) return checksum; } +static int invalid_rx_desc(struct r8152 *tp, struct rx_desc *rx_desc) +{ + u32 opts1 = le32_to_cpu(rx_desc->opts1); + u32 opts2 = le32_to_cpu(rx_desc->opts2); + unsigned int pkt_len = opts1 & RX_LEN_MASK; + + switch (tp->version) { + case RTL_VER_01: + case RTL_VER_02: + if (pkt_len > RTL8152_RMS) + return -EIO; + break; + default: + if (pkt_len > RTL8153_RMS) + return -EIO; + break; + } + + switch (opts2 & (RD_IPV4_CS | RD_IPV6_CS)) { + case (RD_IPV4_CS | RD_IPV6_CS): + return -EIO; + case RD_IPV4_CS: + case RD_IPV6_CS: + switch (opts2 & (RD_UDP_CS | RD_TCP_CS)) { + case (RD_UDP_CS | RD_TCP_CS): + return -EIO; + default: + break; + } + break; + default: + break; + } + + return 0; +} + static int rx_bottom(struct r8152 *tp, int budget) { unsigned long flags; @@ -1812,6 +1849,18 @@ static int rx_bottom(struct r8152 *tp, int budget) unsigned int pkt_len; struct sk_buff *skb; + if (unlikely(invalid_rx_desc(tp, rx_desc))) { + if (net_ratelimit()) + netif_err(tp, rx_err, netdev, + "Memory unbelievable\n"); + if (tp->netdev->features & NETIF_F_RXCSUM) { + tp->netdev->features &= ~NETIF_F_RXCSUM; + netif_err(tp, rx_err, netdev, + "rx checksum off\n"); + } + break; + } + pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK; if (pkt_len < ETH_ZLEN) break; -- 2.7.4
Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA
On Tue, Nov 08, 2016 at 02:59:19PM +0800, Chen Feng wrote: > > > On 2016/11/8 11:59, Joonsoo Kim wrote: > > On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote: > >> > >> > >> On 2016/11/7 15:44, Chen Feng wrote: > >>> On 2016/11/7 15:27, Joonsoo Kim wrote: > On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote: > > > > > > On 2016/11/7 14:15, Joonsoo Kim wrote: > >> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote: > >>> Hello, I hava a question on cma zone. > >>> > >>> When we have cma zone, cma zone will be the highest zone of system. > >>> > >>> In android system, the most memory allocator is ION. Media system will > >>> alloc unmovable memory from it. > >>> > >>> On low memory scene, will the CMA zone always do balance? > >> > >> Allocation request for low zone (normal zone) would not cause CMA zone > >> to be balanced since it isn't helpful. > >> > > Yes. But the cma zone will run out soon. And it always need to do > > balance. > > > > How about use migrate cma before movable and let cma type to fallback > > movable. > > > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html > > ZONE_CMA approach will act like as your solution. Could you elaborate > more on the problem of zone approach? > > >>> > >>> The ZONE approach is that makes cma pages in a zone. It can cause a > >>> higher swapin/out > >>> than use migrate cma first. > > > > Interesting result. I should look at it more deeply. Could you explain > > me why the ZONE approach causes a higher swapin/out? > > > The result is that. I don't have a obvious reason. Maybe add a zone, need to > do more balance > to keep the watermark of cma-zone. cma-zone is always used firstly. Since the > test-case > alloced the same memory in total. Please do more analysis. Without the correct analysis, the result doesn't have any meaning. We can't make sure that it is always better than the other. IMHO, number is important but more important thing is a theory. Number is just auxiliary method to prove the theory. > > >>> > >>> The higher swapin/out may have a performance effect to application. The > >>> application may > >>> use too much time swapin memory. > >>> > >>> You can see my tested result attached for detail. And the baseline is > >>> result of [1]. > >>> > >>> > >> My test case is run 60 applications and alloc 512MB ION memory. > >> > >> Repeat this action 50 times > > > > Could you tell me more detail about your test? > > Kernel version? Total Memory? Total CMA Memory? Android system? What > > type of memory does ION uses? Other statistics? Etc... > > Tested on 4.1, android 7, 512MB-cma in 4G memory. > ION use normal unmovable memory, I use it to simulate a camera open operator. Okay. Kernel version would be the one of the reasons. On 4.1, there is a fair zone allocator so behaviour of ZONE_CMA is different with movable first policy. Allocation would be interleaving between zones. It has pros and cons. The fair zone allocator is removed in the recent kernel so please test with it on the recent kernel for apple to apple comparison. > > > > If it tested on the Android, I'm not sure that we need to consider > > it's result. Android has a lowmemory killer which is quitely different > > with normal reclaim behaviour. > Why? Lowmemory killer don't keep LRU ordering of the page. It uses LRU ordering of the app and kill the app to reclaim the mermory. It makes reclaim behaviour quiet different with original one. And, it largely depends on userspace setting so we can't take care about it. Thanks.
[PATCH 2/2] staging: iio: ad7606: move out of staging
Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the corresponding Makefile and Kconfig associated with the change. Signed-off-by: Eva Rachel Retuya --- drivers/iio/adc/Kconfig | 34 +++ drivers/iio/adc/Makefile | 3 + drivers/iio/adc/ad7606.c | 519 +++ drivers/iio/adc/ad7606.h | 78 ++ drivers/iio/adc/ad7606_par.c | 112 drivers/iio/adc/ad7606_spi.c | 78 ++ drivers/staging/iio/adc/Kconfig | 34 --- drivers/staging/iio/adc/Makefile | 4 - drivers/staging/iio/adc/ad7606.c | 519 --- drivers/staging/iio/adc/ad7606.h | 78 -- drivers/staging/iio/adc/ad7606_par.c | 112 drivers/staging/iio/adc/ad7606_spi.c | 78 -- 12 files changed, 824 insertions(+), 825 deletions(-) create mode 100644 drivers/iio/adc/ad7606.c create mode 100644 drivers/iio/adc/ad7606.h create mode 100644 drivers/iio/adc/ad7606_par.c create mode 100644 drivers/iio/adc/ad7606_spi.c delete mode 100644 drivers/staging/iio/adc/ad7606.c delete mode 100644 drivers/staging/iio/adc/ad7606.h delete mode 100644 drivers/staging/iio/adc/ad7606_par.c delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index c3fe98d..742db8f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -58,6 +58,40 @@ config AD7476 To compile this driver as a module, choose M here: the module will be called ad7476. +config AD7606 + tristate "Analog Devices AD7606 ADC driver" + depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for Analog Devices: + ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the + module will be called ad7606. + +config AD7606_IFACE_PARALLEL + tristate "parallel interface support" + depends on AD7606 + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_parallel. + +config AD7606_IFACE_SPI + tristate "spi interface support" + depends on AD7606 + depends on SPI + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_spi. + config AD7766 tristate "Analog Devices AD7766/AD7767 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 96894b3..d06d3a9 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -9,6 +9,9 @@ obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o obj-$(CONFIG_AD7923) += ad7923.o obj-$(CONFIG_AD7476) += ad7476.o +obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o +obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o +obj-$(CONFIG_AD7606) += ad7606.o obj-$(CONFIG_AD7766) += ad7766.o obj-$(CONFIG_AD7791) += ad7791.o obj-$(CONFIG_AD7793) += ad7793.o diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c new file mode 100644 index 000..cceb18c --- /dev/null +++ b/drivers/iio/adc/ad7606.c @@ -0,0 +1,519 @@ +/* + * AD7606 SPI ADC driver + * + * Copyright 2011 Analog Devices Inc. + * + * Licensed under the GPL-2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include "ad7606.h" + +static int ad7606_reset(struct ad7606_state *st) +{ + if (st->gpio_reset) { + gpiod_set_value(st->gpio_reset, 1); + ndelay(100); /* t_reset >= 100ns */ + gpiod_set_value(st->gpio_reset, 0); + return 0; + } + + return -ENODEV; +} + +static int ad7606_read_samples(struct ad7606_state *st) +{ + unsigned int num = st->chip_info->num_channels; + u16 *data = st->data; + int ret; + + /* +* The frstdata signal is set to high while and after reading the sample +* of the first channel and low for all other channels. This can be used +* to check that the incoming data is correctly aligned. During normal +* operation the data should never become unaligned, but some glitch or +* electrostatic discharge might cause an extra read or clock cycle. +* Monitoring the frstdata signal allows to recover from such failure +* situations. +*/ + + if (st->gpio_frstdata) { + ret = st->bops->read_block(st->dev, 1, data); + if (ret) + return r
[PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
Eliminate the non-standard attribute in_voltage_range and move its functionality under the scale attribute. read_raw() has been taken care of previously so only write_raw() is handled here. Additionally, rename the attribute in_voltage_range_available into in_voltage_scale_available. Suggested-by: Lars-Peter Clausen Signed-off-by: Eva Rachel Retuya --- drivers/staging/iio/adc/ad7606.c | 56 1 file changed, 16 insertions(+), 40 deletions(-) diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/iio/adc/ad7606.c index 4531908..cceb18c 100644 --- a/drivers/staging/iio/adc/ad7606.c +++ b/drivers/staging/iio/adc/ad7606.c @@ -161,42 +161,7 @@ static int ad7606_read_raw(struct iio_dev *indio_dev, return -EINVAL; } -static ssize_t ad7606_show_range(struct device *dev, -struct device_attribute *attr, char *buf) -{ - struct iio_dev *indio_dev = dev_to_iio_dev(dev); - struct ad7606_state *st = iio_priv(indio_dev); - - return sprintf(buf, "%u\n", st->range); -} - -static ssize_t ad7606_store_range(struct device *dev, - struct device_attribute *attr, - const char *buf, size_t count) -{ - struct iio_dev *indio_dev = dev_to_iio_dev(dev); - struct ad7606_state *st = iio_priv(indio_dev); - unsigned long lval; - int ret; - - ret = kstrtoul(buf, 10, &lval); - if (ret) - return ret; - - if (!(lval == 5000 || lval == 1)) - return -EINVAL; - - mutex_lock(&indio_dev->mlock); - gpiod_set_value(st->gpio_range, lval == 1); - st->range = lval; - mutex_unlock(&indio_dev->mlock); - - return count; -} - -static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR, - ad7606_show_range, ad7606_store_range, 0); -static IIO_CONST_ATTR(in_voltage_range_available, "5000 1"); +static IIO_CONST_ATTR(in_voltage_scale_available, "5000 1"); static int ad7606_oversampling_get_index(unsigned int val) { @@ -221,6 +186,19 @@ static int ad7606_write_raw(struct iio_dev *indio_dev, int ret; switch (mask) { + case IIO_CHAN_INFO_SCALE: + if (val2) + return -EINVAL; + + if (!(val == 5000 || val == 1)) + return -EINVAL; + + mutex_lock(&indio_dev->mlock); + gpiod_set_value(st->gpio_range, val == 1); + st->range = val; + mutex_unlock(&indio_dev->mlock); + + return 0; case IIO_CHAN_INFO_OVERSAMPLING_RATIO: if (val2) return -EINVAL; @@ -247,8 +225,7 @@ static int ad7606_write_raw(struct iio_dev *indio_dev, static IIO_CONST_ATTR(oversampling_ratio_available, "1 2 4 8 16 32 64"); static struct attribute *ad7606_attributes_os_and_range[] = { - &iio_dev_attr_in_voltage_range.dev_attr.attr, - &iio_const_attr_in_voltage_range_available.dev_attr.attr, + &iio_const_attr_in_voltage_scale_available.dev_attr.attr, &iio_const_attr_oversampling_ratio_available.dev_attr.attr, NULL, }; @@ -267,8 +244,7 @@ static const struct attribute_group ad7606_attribute_group_os = { }; static struct attribute *ad7606_attributes_range[] = { - &iio_dev_attr_in_voltage_range.dev_attr.attr, - &iio_const_attr_in_voltage_range_available.dev_attr.attr, + &iio_const_attr_in_voltage_scale_available.dev_attr.attr, NULL, }; -- 2.7.4
[PATCH 0/2] staging: iio: ad7606: move driver out of staging
Address the last remaining TODO [1] for this driver and move it from staging into mainline. [1] https://marc.info/?l=linux-iio&m=147689684332118&w=2 Eva Rachel Retuya (2): staging: iio: ad7606: replace range/range_available with corresponding scale staging: iio: ad7606: move out of staging drivers/iio/adc/Kconfig | 34 +++ drivers/iio/adc/Makefile | 3 + drivers/iio/adc/ad7606.c | 519 + drivers/iio/adc/ad7606.h | 78 + drivers/iio/adc/ad7606_par.c | 112 drivers/iio/adc/ad7606_spi.c | 78 + drivers/staging/iio/adc/Kconfig | 34 --- drivers/staging/iio/adc/Makefile | 4 - drivers/staging/iio/adc/ad7606.c | 543 --- drivers/staging/iio/adc/ad7606.h | 78 - drivers/staging/iio/adc/ad7606_par.c | 112 drivers/staging/iio/adc/ad7606_spi.c | 78 - 12 files changed, 824 insertions(+), 849 deletions(-) create mode 100644 drivers/iio/adc/ad7606.c create mode 100644 drivers/iio/adc/ad7606.h create mode 100644 drivers/iio/adc/ad7606_par.c create mode 100644 drivers/iio/adc/ad7606_spi.c delete mode 100644 drivers/staging/iio/adc/ad7606.c delete mode 100644 drivers/staging/iio/adc/ad7606.h delete mode 100644 drivers/staging/iio/adc/ad7606_par.c delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c -- 2.7.4
Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
On Friday 11 November 2016 09:00 AM, John Syne wrote: > >> On Nov 9, 2016, at 9:07 PM, Vignesh R wrote: >> >> Hi, >> >> On Thursday 10 November 2016 05:23 AM, John Syne wrote: >>> OK, then back to my original question. Given that these DT properties are >>> supported in the driver >>> >> >> Below properties are supported by only by ti_am3335x_adc driver and not >> ti_am335x_tsc driver. As author of this patch pointed out in another >> reply, there is no need to change step-opendelay for tsc. AFAIK, I don't >> see a use case where these values needs to be tweaked for tsc channels, >> therefore it does not make sense to be DT properties. > Yeah, the confusion was mine because the author of this patch series was > proposing to hard code these settings while DT properties already existed in > the ti_am335x_adc driver. I use the ADC for sensor measurement and do not use > the touchscreen features. I already pointed out where these DT parameters > should be added by referencing how this was done in one of the BBB DT overlay > files [1]. I am just proposing the same is done as a default in the > AM33xx.dtsi and AM4372.dtsi files. Here is what I was proposing. > Granted, the adc-channels should be restricted to the subset of channels not > used by tsc, but you get the idea. There are 4 wire, 5 wire and 8 wire touchscreens. Therefore there is no way to know in advance, how many channels are available for adc. IMO, this is not a SoC specific configuration but board dependent. Hence, all channel related configurations need to be in board specific dts files and not in top level dtsi files. > > tscadc: tscadc@44e0d000 { > compatible = "ti,am3359-tscadc"; > reg = <0x44e0d000 0x1000>; > interrupt-parent = <&intc>; > interrupts = <16>; > ti,hwmods = "adc_tsc"; > status = "disabled"; > dmas = <&edma 53 0>, <&edma 57 0>; > dma-names = "fifo0", "fifo1”; > > tsc { > compatible = "ti,am3359-tsc"; > }; > am335x_adc: adc { > #io-channel-cells = <1>; > ti,adc-channels = <0 1 2 3 4 5 6>; > ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 > 0x16 0x16>; > ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 > 0x98 0x98 0x98>; > ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 > 0x0 0x0>; > compatible = "ti,am3359-adc"; > }; > }; > > [1]https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts > -- Regards Vignesh
Re: [PATCH] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
Hi Markus, [auto build test ERROR on pm/linux-next] [also build test ERROR on next-20161110] [cannot apply to v4.9-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Markus-Mayer/cpufreq-brcmstb-cpufreq-CPUfreq-driver-for-older-Broadcom-STB-SoCs/2016-075914 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> FATAL: drivers/cpufreq/brcmstb-cpufreq: sizeof(struct platform_device_id)=24 >> is not a modulo of the size of section >> __mod_platform___device_table=392. >> Fix definition of struct platform_device_id in mod_devicetable.h --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 8/9] media: venus: add Makefiles and Kconfig files
On Mon, Nov 7, 2016 at 11:04 PM, Stanimir Varbanov wrote: > Makefile and Kconfig files to build the Venus video codec driver. > > Signed-off-by: Stanimir Varbanov > --- > drivers/media/platform/qcom/Kconfig| 7 +++ > drivers/media/platform/qcom/Makefile | 1 + > drivers/media/platform/qcom/venus/Makefile | 15 +++ > 3 files changed, 23 insertions(+) > create mode 100644 drivers/media/platform/qcom/Kconfig > create mode 100644 drivers/media/platform/qcom/Makefile > create mode 100644 drivers/media/platform/qcom/venus/Makefile > > diff --git a/drivers/media/platform/qcom/Kconfig > b/drivers/media/platform/qcom/Kconfig > new file mode 100644 > index ..bf4d2fcce924 > --- /dev/null > +++ b/drivers/media/platform/qcom/Kconfig > @@ -0,0 +1,7 @@ > + > +menuconfig VIDEO_QCOM_VENUS > +tristate "Qualcomm Venus V4L2 encoder/decoder driver" > +depends on ARCH_QCOM && VIDEO_V4L2 Let's also enable this for COMPILE_TEST. Thanks Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] mm: support anonymous stable page
Sorry for sending a wrong version. Here is new one. >From 2d42ead9335cde51fd58d6348439ca03cf359ba2 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Fri, 11 Nov 2016 15:02:57 +0900 Subject: [PATCH] mm: support anonymous stable page For developemnt for zram-swap asynchronous writeback, I found strange corruption of compressed page. With investigation, it reveals currently stable page doesn't support anonymous page. IOW, reuse_swap_page can reuse the page without waiting writeback completion so that it can corrupt data during zram compression. It can affect every swap device which supports asynchronous writeback and CRC checking as well as zRAM. Unfortunately, reuse_swap_page should be atomic so that we cannot wait on writeback in there so the approach in this patch is simply return false if we found it needs stable page. Although it increases memory footprint temporarily, it happens rarely and it should be reclaimed easily althoug it happened. Also, It would be better than waiting of IO completion, which is critial path for application latency. Cc: Hugh Dickins Cc: Darrick J. Wong Signed-off-by: Minchan Kim --- mm/swapfile.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 2210de290b54..ea591435d8e0 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -943,11 +943,21 @@ bool reuse_swap_page(struct page *page, int *total_mapcount) count = page_trans_huge_mapcount(page, total_mapcount); if (count <= 1 && PageSwapCache(page)) { count += page_swapcount(page); - if (count == 1 && !PageWriteback(page)) { + if (count != 1) + goto out; + if (!PageWriteback(page)) { delete_from_swap_cache(page); SetPageDirty(page); + } else { + struct address_space *mapping; + + mapping = page_mapping(page); + if (bdi_cap_stable_pages_required( + inode_to_bdi(mapping->host))) + return false; } } +out: return count <= 1; } @@ -2180,6 +2190,7 @@ static struct swap_info_struct *alloc_swap_info(void) static int claim_swapfile(struct swap_info_struct *p, struct inode *inode) { int error; + struct address_space *swapper_space; if (S_ISBLK(inode->i_mode)) { p->bdev = bdgrab(I_BDEV(inode)); @@ -2202,6 +2213,9 @@ static int claim_swapfile(struct swap_info_struct *p, struct inode *inode) } else return -EINVAL; + swapper_space = &swapper_spaces[p->type]; + swapper_space->host = inode; + return 0; } -- 2.7.4
[git pull] vfs.git
Christoph's and Jan's aio fixes, fixup for generic_file_splice_read (removal of pointless detritus that actually breaks it when used for gfs2 ->splice_read()) and fixup for generic_file_read_iter() interaction with ITER_PIPE destinations. The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30: Linux 4.9-rc3 (2016-10-29 13:52:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to e519e7774784f3fa7728657d780863805ed1c983: splice: remove detritus from generic_file_splice_read() (2016-11-10 18:32:13 -0500) Al Viro (1): splice: remove detritus from generic_file_splice_read() Christoph Hellwig (3): aio: hold an extra file reference over AIO read/write operations fs: remove the never implemented aio_fsync file operation fs: remove aio_run_iocb Eryu Guan (1): mm/filemap: don't allow partially uptodate page for pipes Jan Kara (1): aio: fix freeze protection of aio writes Documentation/filesystems/Locking | 1 - Documentation/filesystems/vfs.txt | 1 - fs/aio.c | 207 -- fs/ntfs/dir.c | 2 - fs/splice.c | 5 - include/linux/fs.h| 2 +- mm/filemap.c | 3 + 7 files changed, 113 insertions(+), 108 deletions(-)
Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Jitao, I couldn't locate the original mail, so posting on this thread instead. Some comments below. On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote: Hi Jitao, 2016-08-27 8:44 GMT+02:00 Jitao Shi : This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi Reviewed-by: Daniel Kurtz --- Changes since v16: - Disable ps8640 DSI MCS Function. - Rename gpios name more clearly. - Tune the ps8640 power on sequence. Changes since v15: - Drop drm_connector_(un)register calls from parade ps8640. The main DRM driver mtk_drm_drv now calls drm_connector_register_all() after drm_dev_register() in the mtk_drm_bind() function. That function should iterate over all connectors and call drm_connector_register() for each of them. So, remove drm_connector_(un)register calls from parade ps8640. Changes since v14: - update copyright info. - change bridge_to_ps8640 and connector_to_ps8640 to inline function. - fix some coding style. - use sizeof as array counter. - use drm_get_edid when read edid. - add mutex when firmware updating. Changes since v13: - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 *data, u16 data_len) - fix PAGE2_SW_REST tyro. - move the buf[3] init to entrance of the function. Changes since v12: - fix hw_chip_id build warning Changes since v11: - Remove depends on I2C, add DRM depends - Reuse ps8640_write_bytes() in ps8640_write_byte() - Use timer check for polling like the routines in - Fix no drm_connector_unregister/drm_connector_cleanup when ps8640_bridge_attach fail - Check the ps8640 hardware id in ps8640_validate_firmware - Remove fw_version check - Move ps8640_validate_firmware before ps8640_enter_bl - Add ddc_i2c unregister when probe fail and ps8640_remove --- drivers/gpu/drm/bridge/Kconfig | 12 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/parade-ps8640.c | 1077 3 files changed, 1090 insertions(+) create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index b590e67..c59d043 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -50,6 +50,18 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_PARADE_PS8640 + tristate "Parade PS8640 MIPI DSI to eDP Converter" + depends on DRM + depends on OF + select DRM_KMS_HELPER + select DRM_MIPI_DSI + select DRM_PANEL + ---help--- + Choose this option if you have PS8640 for display + The PS8640 is a high-performance and low-power + MIPI DSI to eDP converter + config DRM_SII902X tristate "Silicon Image sii902x RGB/HDMI bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index efdb07e..3360537 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c new file mode 100644 index 000..7d67431 --- /dev/null +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -0,0 +1,1077 @@ +/* + * Copyright (c) 2016 MediaTek Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include Not needed. +#include +#include +#include +#include +#include The above 2 aren't needed. +#include +#include +#include +#include + +#include +#include +#include +#include Not needed. +#include +#include + +#define PAGE1_VSTART 0x6b +#define PAGE2_SPI_CFG3 0x82 +#define I2C_TO_SPI_RESET 0x20 +#define PAGE2_ROMADD_BYTE1 0x8e +#define PAGE2_ROMADD_BYTE2 0x8f +#define PAGE2_SWSPI_WDATA 0x90 +#define PAGE2_SWSPI_RDATA 0x91 +#define PAGE2_SWSPI_LEN0x92 +#define PAGE2_SWSPI_CTL0x93 +#define TRIGGER_NO_READBACK0x05 +#define TRIGGER_READBACK 0x01 +#define PAGE2_SPI_STATUS 0x9e +#define SPI_READY 0x0c +#define PAGE2_GPIO_L 0xa6 +#define PAGE2_GPIO_H
Re: [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN)
Hi Thomas, On Wed, 2016-11-09 at 12:27 -0800, tip-bot for Thomas Gleixner wrote: > Commit-ID: d49597fd3bc7d9534de55e9256767f073be1b33a > Gitweb: > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_tip_d49597fd3bc7d9534de55e9256767f073be1b33a&d=CwIDaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=2AkLWShm6V8Nuu8ZZ-80Flo6y0XxCGmO1xrsAeRArAE&m=WBsB4JFr-Dct0um4Kf8QAxC7w6p-Mlk3H-LwItQJ7Fw&s=qI64vSH3y6q8wJhcqpI4dXYma-i1RTtlxgKwKwhFWWo&e= > > Author: Thomas Gleixner > AuthorDate: Wed, 9 Nov 2016 16:35:51 +0100 > Committer: Thomas Gleixner > CommitDate: Wed, 9 Nov 2016 21:05:01 +0100 > > x86/cpu: Deal with broken firmware (VMWare/XEN) > > Both ACPI and MP specifications require that the APIC id in the respective > tables must be the same as the APIC id in CPUID. > > The kernel retrieves the physical package id from the APIC id during the > ACPI/MP table scan and builds the physical to logical package map. The > physical package id which is used after a CPU comes up is retrieved from > CPUID. So we rely on ACPI/MP tables and CPUID agreeing in that respect. > > There exist VMware and XEN implementations which violate the spec. As a > result the physical to logical package map, which relies on the ACPI/MP > tables does not work on those systems, because the CPUID initialized > physical package id does not match the firmware id. This causes system > crashes and malfunction due to invalid package mappings. For documentation purpose let me note that, VMware VMs running at virtual hardware version 9 and above don't have this ACPI/MP and CPUID divergence on the package id. So not everyone will see this issue on their VMs, this bug is limited to folks running at virtual hardware version 8 and prior. It's good that we can workaround the platform bug for those VMs, thanks for adding these checks. Alok > > The only way to cure this is to sanitize the physical package id after the > CPUID enumeration and yell when the APIC ids are different. Fix up the > initial APIC id, which is fine as it is only used printout purposes. > > If the physical package IDs differ yell and use the package information > from the ACPI/MP tables so the existing logical package map just works. > > Chas provided the resulting dmesg output for his affected 4 virtual > sockets, 1 core per socket VM: > > [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 1 CPUID: 2 > [Firmware Bug]: CPU1: Using firmware package id 1 instead of 2 > > > Reported-and-tested-by: "Charles (Chas) Williams" , > Reported-by: M. Vefa Bicakci > Signed-off-by: Thomas Gleixner > Cc: Peter Zijlstra > Cc: Sebastian Andrzej Siewior > Cc: Borislav Petkov > Cc: Alok Kataria > Cc: Boris Ostrovsky > Cc: #4.6+ > Link: > https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_alpine.DEB.2.20.1611091613540.3501-40nanos&d=CwIDaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=2AkLWShm6V8Nuu8ZZ-80Flo6y0XxCGmO1xrsAeRArAE&m=WBsB4JFr-Dct0um4Kf8QAxC7w6p-Mlk3H-LwItQJ7Fw&s=HNQMGUrw_s6Mc_oyREBnD4TrUjERbLcH1viAZr-aFPY&e= > > Signed-off-by: Thomas Gleixner > --- > arch/x86/kernel/cpu/common.c | 32 ++-- > 1 file changed, 30 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 9bd910a..cc9e980 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -979,6 +979,35 @@ static void x86_init_cache_qos(struct cpuinfo_x86 *c) > } > > /* > + * The physical to logical package id mapping is initialized from the > + * acpi/mptables information. Make sure that CPUID actually agrees with > + * that. > + */ > +static void sanitize_package_id(struct cpuinfo_x86 *c) > +{ > +#ifdef CONFIG_SMP > + unsigned int pkg, apicid, cpu = smp_processor_id(); > + > + apicid = apic->cpu_present_to_apicid(cpu); > + pkg = apicid >> boot_cpu_data.x86_coreid_bits; > + > + if (apicid != c->initial_apicid) { > + pr_err(FW_BUG "CPU%u: APIC id mismatch. Firmware: %x CPUID: > %x\n", > +cpu, apicid, c->initial_apicid); > + c->initial_apicid = apicid; > + } > + if (pkg != c->phys_proc_id) { > + pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of > %u\n", > +cpu, pkg, c->phys_proc_id); > + c->phys_proc_id = pkg; > + } > + c->logical_proc_id = topology_phys_to_logical_pkg(pkg); > +#else > + c->logical_proc_id = 0; > +#endif > +} > + > +/* > * This does the hard work of actually picking apart the CPU stuff... > */ > static void identify_cpu(struct cpuinfo_x86 *c) > @@ -1103,8 +1132,7 @@ static void identify_cpu(struct cpuinfo_x86 *c) > #ifdef CONFIG_NUMA > numa_add_cpu(smp_processor_id()); > #endif > - /* The boot/hotplug time assigment got cleared, restore it */ > - c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id); > + sanitize_package_id(c); > } > > /*
Re: [patch] mm, slab: faster active and free stats
On Wed, Nov 09, 2016 at 04:38:08PM -0800, David Rientjes wrote: > On Tue, 8 Nov 2016, Andrew Morton wrote: > > > > Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive > > > if there are many slab caches and if there are very lengthy per-node > > > partial and/or free lists. > > > > > > Commit 07a63c41fa1f ("mm/slab: improve performance of gathering slabinfo > > > stats") addressed the per-node full lists which showed a significant > > > improvement when no objects were freed. This patch has the same > > > motivation and optimizes the remainder of the usecases where there are > > > very lengthy partial and free lists. > > > > > > This patch maintains per-node active_slabs (full and partial) and > > > free_slabs rather than iterating the lists at runtime when reading > > > /proc/slabinfo. > > > > Are there any nice numbers you can share? > > > > Yes, please add this to the description: > > > When allocating 100GB of slab from a test cache where every slab page is > on the partial list, reading /proc/slabinfo (includes all other slab > caches on the system) takes ~247ms on average with 48 samples. > > As a result of this patch, the same read takes ~0.856ms on average. Hello, David. Maintaining acitve/free_slab counters looks so complex. And, I think that we don't need to maintain these counters for faster slabinfo. Key point is to remove iterating n->slabs_partial list. We can calculate active slab/object by following equation as you did in this patch. active_slab(n) = n->num_slab - the number of free_slab active_object(n) = n->num_slab * cachep->num - n->free_objects To get the number of free_slab, we need to iterate n->slabs_free list but I guess it would be small enough. If you don't like to iterate n->slabs_free list in slabinfo, just maintaining the number of slabs_free would be enough. Thanks.
Re: [PATCH v16 0/5] Mediatek MT8173 CMDQ support
On Thu, Nov 10, 2016 at 4:45 PM, Horng-Shyang Liao wrote: > On Tue, 2016-11-01 at 19:28 +0800, HS Liao wrote: >> Hi, >> >> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used >> to help write registers with critical time limitation, such as >> updating display configuration during the vblank. It controls Global >> Command Engine (GCE) hardware to achieve this requirement. >> >> These patches have a build dependency on top of v4.9-rc1. >> >> Changes since v15: >> - separate "suspend and resume" patch from "save energy" patch >> - don't stop running tasks in cmdq_suspend() >>(i.e. leave no running tasks guarantee to clients) >> >> Best regards, >> HS Liao >> >> HS Liao (5): >> dt-bindings: soc: Add documentation for the MediaTek GCE unit >> CMDQ: Mediatek CMDQ driver >> arm64: dts: mt8173: Add GCE node >> CMDQ: suspend and resume >> CMDQ: save energy >> >> .../devicetree/bindings/mailbox/mtk-gce.txt| 43 ++ >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 + >> drivers/mailbox/Kconfig| 10 + >> drivers/mailbox/Makefile | 2 + >> drivers/mailbox/mtk-cmdq-mailbox.c | 632 >> + >> drivers/soc/mediatek/Kconfig | 11 + >> drivers/soc/mediatek/Makefile | 1 + >> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 ++ >> include/linux/mailbox/mtk-cmdq-mailbox.h | 67 +++ >> include/linux/soc/mediatek/mtk-cmdq.h | 182 ++ >> 10 files changed, 1268 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt >> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c >> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c >> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h >> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h >> > > > Hi Jassi, Matthias, > > Sorry to disturb you. > No, you don't disturb, but the controller driver and protocol driver, introduced in the same patch, does :) So does the suspend/resume support (patch 4&5) added separately as a patch on top. Please reorganise the patchset. Thanks.
[PATCH] mm: support anonymous stable page
For developemnt for zram-swap asynchronous writeback, I found strange corruption of compressed page. With investigation, it reveals currently stable page doesn't support anonymous page. IOW, reuse_swap_page can reuse the page without waiting writeback completion so that it can corrupt data during zram compression. It can affect every swap device which supports asynchronous writeback and CRC checking as well as zRAM. Unfortunately, reuse_swap_page should be atomic so that we cannot wait on writeback in there so the approach in this patch is simply return false if we found it needs stable page. Although it increases memory footprint temporarily, it happens rarely and it should be reclaimed easily althoug it happened. Also, It would be better than waiting of IO completion, which is critial path for application latency. Cc: Hugh Dickins Cc: Darrick J. Wong Signed-off-by: Minchan Kim --- mm/swapfile.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 816ca8663ae5..ea591435d8e0 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -949,7 +949,12 @@ bool reuse_swap_page(struct page *page, int *total_mapcount) delete_from_swap_cache(page); SetPageDirty(page); } else { - wait_for_stable_page(page); + struct address_space *mapping; + + mapping = page_mapping(page); + if (bdi_cap_stable_pages_required( + inode_to_bdi(mapping->host))) + return false; } } out: @@ -2185,6 +2190,7 @@ static struct swap_info_struct *alloc_swap_info(void) static int claim_swapfile(struct swap_info_struct *p, struct inode *inode) { int error; + struct address_space *swapper_space; if (S_ISBLK(inode->i_mode)) { p->bdev = bdgrab(I_BDEV(inode)); @@ -2207,6 +2213,9 @@ static int claim_swapfile(struct swap_info_struct *p, struct inode *inode) } else return -EINVAL; + swapper_space = &swapper_spaces[p->type]; + swapper_space->host = inode; + return 0; } -- 2.7.4
Re: [PATCH 06/35] staging: lustre: osc: Performance tune for LRU
Hi Jinshan, [auto build test ERROR on staging/staging-testing] [also build test ERROR on next-20161110] [cannot apply to v4.9-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/James-Simmons/second-batch-of-missing-lustre-2-8-patches/2016-021225 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=m68k All errors (new ones prefixed by >>): >> ERROR: "__divdi3" [drivers/staging/lustre/lustre/osc/osc.ko] undefined! ERROR: "__umoddi3" [drivers/staging/lustre/lustre/obdclass/obdclass.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc
From: Gustavo Padovan Create one timeline context for each CRTC to be able to handle out-fences and signal them. It adds a few members to struct drm_crtc: fence_context, where we store the context we get from fence_context_alloc(), the fence seqno and the fence lock, that we pass in fence_init() to be used by the fence. v2: Comment by Daniel Stone: - add BUG_ON() to fence_to_crtc() macro v3: Comment by Ville Syrjälä - Use more meaningful name as crtc timeline name v4: Comments by Brian Starkey - Use even more meaninful name for the crtc timeline - add doc for timeline_name Comment by Daniel Vetter - use in-line style for comments - rebase after fence -> dma_fence rename v5: Comment by Daniel Vetter - Add doc for drm_crtc_fence_ops Signed-off-by: Gustavo Padovan Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 31 +++ include/drm/drm_crtc.h | 45 + 2 files changed, 76 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 154e040..9b9881b 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc) #endif } +static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence) +{ + struct drm_crtc *crtc = fence_to_crtc(fence); + + return crtc->dev->driver->name; +} + +static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence) +{ + struct drm_crtc *crtc = fence_to_crtc(fence); + + return crtc->timeline_name; +} + +static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence) +{ + return true; +} + +const struct dma_fence_ops drm_crtc_fence_ops = { + .get_driver_name = drm_crtc_fence_get_driver_name, + .get_timeline_name = drm_crtc_fence_get_timeline_name, + .enable_signaling = drm_crtc_fence_enable_signaling, + .wait = dma_fence_default_wait, +}; + /** * drm_crtc_init_with_planes - Initialise a new CRTC object with *specified primary and cursor planes. @@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc, return -ENOMEM; } + crtc->fence_context = dma_fence_context_alloc(1); + spin_lock_init(&crtc->fence_lock); + snprintf(crtc->timeline_name, sizeof(crtc->timeline_name), +"CRTC:%d-%s", crtc->base.id, crtc->name); + crtc->base.properties = &crtc->properties; list_add_tail(&crtc->head, &config->crtc_list); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 11780a9..0870de1 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -32,6 +32,8 @@ #include #include #include +#include +#include #include #include #include @@ -739,9 +741,52 @@ struct drm_crtc { */ struct drm_crtc_crc crc; #endif + + /** +* @fence_context: +* +* timeline context used for fence operations. +*/ + unsigned int fence_context; + + /** +* @fence_lock: +* +* spinlock to protect the fences in the fence_context. +*/ + + spinlock_t fence_lock; + /** +* @fence_seqno: +* +* Seqno variable used as monotonic counter for the fences +* created on the CRTC's timeline. +*/ + unsigned long fence_seqno; + + /** +* @timeline_name: +* +* The name of the CRTC's fence timeline. +*/ + char timeline_name[32]; }; /** + * dma_crtc_fence_ops - fence ops for the drm_crtc timeline + * + * It contains the dma_fence_ops that should be called by the dma_fence + * code. CRTC core should use this ops when initializing fences. + */ +extern const struct dma_fence_ops drm_crtc_fence_ops; + +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence) +{ + BUG_ON(fence->ops != &drm_crtc_fence_ops); + return container_of(fence->lock, struct drm_crtc, fence_lock); +} + +/** * struct drm_mode_set - new values for a CRTC config change * @fb: framebuffer to use for new config * @crtc: CRTC whose configuration we're about to change -- 2.5.5
[PATCH v8 1/3] drm/fence: add in-fences support
From: Gustavo Padovan There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is then translated to a fence (that may be a fence_array subclass or just a normal fence) and then used by DRM to fence_wait() for all fences in the sync_file to signal. So it only commits when all framebuffers are ready to scanout. v2: Comments by Daniel Vetter: - remove set state->fence = NULL in destroy phase - accept fence -1 as valid and just return 0 - do not call fence_get() - sync_file_fences_get() already calls it - fence_put() if state->fence is already set, in case userspace set the property more than once. v3: WARN_ON if fence is set but state has no FB v4: Comment from Maarten Lankhorst - allow set fence with no related fb v5: rename FENCE_FD to IN_FENCE_FD v6: Comments by Daniel Vetter: - rename plane_state->in_fence back to "fence" - re-introduce WARN_ON if fence set but no fb - rebase after fence -> dma_fence rename v7: Comments by Brian Starkey - set state->fence to NULL when duplicating the state - fail if IN_FENCE_FD was already set Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c| 14 ++ drivers/gpu/drm/drm_atomic_helper.c | 5 + drivers/gpu/drm/drm_crtc.c | 6 ++ drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_crtc.h | 5 + 6 files changed, 32 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 25e8e37..360cb92 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -12,6 +12,7 @@ menuconfig DRM select I2C select I2C_ALGOBIT select DMA_SHARED_BUFFER + select SYNC_FILE help Kernel-level support for the Direct Rendering Infrastructure (DRI) introduced in XFree86 4.0. If you say Y here, you need to select diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index b096c16..8e26ad1 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "drm_crtc_internal.h" @@ -709,6 +710,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane, drm_atomic_set_fb_for_plane(state, fb); if (fb) drm_framebuffer_unreference(fb); + } else if (property == config->prop_in_fence_fd) { + if (state->fence) + return -EINVAL; + + if (U642I64(val) == -1) + return 0; + + state->fence = sync_file_get_fence(val); + if (!state->fence) + return -EINVAL; + } else if (property == config->prop_crtc_id) { struct drm_crtc *crtc = drm_crtc_find(dev, val); return drm_atomic_set_crtc_for_plane(state, crtc); @@ -770,6 +782,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane, if (property == config->prop_fb_id) { *val = (state->fb) ? state->fb->base.id : 0; + } else if (property == config->prop_in_fence_fd) { + *val = -1; } else if (property == config->prop_crtc_id) { *val = (state->crtc) ? state->crtc->base.id : 0; } else if (property == config->prop_crtc_x) { diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 75ad01d..caed870 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3076,6 +3076,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, if (state->fb) drm_framebuffer_reference(state->fb); + + state->fence = NULL; } EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state); @@ -3114,6 +3116,9 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state) { if (state->fb) drm_framebuffer_unreference(state->fb); + + if (state->fence) + dma_fence_put(state->fence); } EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state); diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index ce274ed..154e040 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -397,6 +397,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.prop_fb_id = prop; + prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC, + "IN_FENCE_FD", -1, INT_MAX); + if (!prop) + return -ENOMEM; + dev->mode_config.prop_in_fence_fd = prop; + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC, "CRTC_ID", DRM_MODE_OBJECT_CRTC
[PATCH v8 0/3] drm: add explict fencing
From: Gustavo Padovan Hi, New version of the DRM fences patches with all comments on v7 adressed. Please refer to the cover letter[1] in a previous version to check for more details. The changes since the last version can be seen in commit message on each patch. Robert Foss managed to port Android's drm_hwcomposer to the new HWC2 API and added support to fences. Current patches can be seen here: https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v1 He ran AOSP on top of padovan/fences kernel branch with full fence support on qemu/virgl and msm db410c. That means we already have a working open source userspace using the explicit fencing implementation. Also i-g-t testing are available with all tests suggested in v7 included: https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/ Please review! Gustavo [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253822.html --- Gustavo Padovan (3): drm/fence: add in-fences support drm/fence: add fence timeline to drm_crtc drm/fence: add out-fences support drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c| 256 +--- drivers/gpu/drm/drm_atomic_helper.c | 5 + drivers/gpu/drm/drm_crtc.c | 45 +++ drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_atomic.h| 1 + include/drm/drm_crtc.h | 56 7 files changed, 320 insertions(+), 45 deletions(-) -- 2.5.5
[PATCH v8 3/3] drm/fence: add out-fences support
From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the OUT_FENCE_PTR prop to send the sync_file fd back to userspace. The sync_file and fd are allocated/created before commit, but the fd_install operation only happens after we know that commit succeed. v2: Comment by Rob Clark: - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here. Comment by Daniel Vetter: - Add clean up code for out_fences v3: Comments by Daniel Vetter: - create DRM_MODE_ATOMIC_EVENT_MASK - userspace should fill out_fences_ptr with the crtc_ids for which it wants fences back. v4: Create OUT_FENCE_PTR properties and remove old approach. v5: Comments by Brian Starkey: - Remove extra fence_get() in atomic_ioctl() - Check ret before iterating on the crtc_state - check ret before fd_install - set fence_state to NULL at the beginning - check fence_state->out_fence_ptr before put_user() - change order of fput() and put_unused_fd() on failure - Add access_ok() check to the out_fence_ptr received - Rebase after fence -> dma_fence rename - Store out_fence_ptr in the drm_atomic_state - Split crtc_setup_out_fence() - return -1 as out_fence with TEST_ONLY flag v6: Comments by Daniel Vetter - Add prepare/unprepare_crtc_signaling() - move struct drm_out_fence_state to drm_atomic.c - mark get_crtc_fence() as static Comments by Brian Starkey - proper set fence_ptr fence_state array - isolate fence_idx increment - improve error handling v7: Comments by Daniel Vetter - remove prefix from internal functions - make out_fence_ptr an s64 pointer - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail - fix doc issues - filter out OUT_FENCE_PTR == NULL and do fail in this case - add complete_crtc_signalling() - krealloc fence_state on demand Comment by Brian Starkey - remove unused crtc_state arg from get_out_fence() Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/drm_atomic.c | 242 +++ drivers/gpu/drm/drm_crtc.c | 8 ++ include/drm/drm_atomic.h | 1 + include/drm/drm_crtc.h | 6 ++ 4 files changed, 212 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 8e26ad1..cd39f13 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state, } EXPORT_SYMBOL(drm_atomic_get_crtc_state); +static void set_out_fence_for_crtc(struct drm_atomic_state *state, + struct drm_crtc *crtc, u64 __user *fence_ptr) +{ + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr; +} + +static u64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state, + struct drm_crtc *crtc) +{ + u64 __user *fence_ptr; + + fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr; + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL; + + return fence_ptr; +} + /** * drm_atomic_set_mode_for_crtc - set mode for CRTC * @state: the CRTC whose incoming state to update @@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc, &replaced); state->color_mgmt_changed |= replaced; return ret; + } else if (property == config->prop_out_fence_ptr) { + s64 __user *fence_ptr = u64_to_user_ptr(val); + + if (!fence_ptr) + return 0; + + if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr))) + return -EFAULT; + + set_out_fence_for_crtc(state->state, crtc, fence_ptr); } else if (crtc->funcs->atomic_set_property) return crtc->funcs->atomic_set_property(crtc, state, property, val); else @@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc, *val = (state->ctm) ? state->ctm->base.id : 0; else if (property == config->gamma_lut_property) *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0; + else if (property == config->prop_out_fence_ptr) + *val = 0; else if (crtc->funcs->atomic_get_property) return crtc->funcs->atomic_get_property(crtc, state, property, val); else @@ -1659,11 +1688,9 @@ int drm_atomic_debugfs_init(struct drm_minor *minor) */ static struct drm_pending_vblank_event *create_vblank_event( - struct drm_device *dev, struct drm_file *file_priv, - struct dma_fence *fence, uint64_t user_data) + struct drm_device
[PATCH v4 1/6] kconfig: introduce the "imply" keyword
The "imply" keyword is a weak version of "select" where the target config symbol can still be turned off, avoiding those pitfalls that come with the "select" keyword. This is useful e.g. with multiple drivers that want to indicate their ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. Currently, the same effect can almost be achieved with: config DRIVER_A tristate config DRIVER_B tristate config DRIVER_C tristate config DRIVER_D tristate [...] config SUBSYSTEM_X tristate default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...] This is unwieldy to maintain especially with a large number of drivers. Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X to y or n, excluding m, when some drivers are built-in. The "select" keyword allows for excluding m, but it excludes n as well. Hence this "imply" keyword. The above becomes: config DRIVER_A tristate imply SUBSYSTEM_X config DRIVER_B tristate imply SUBSYSTEM_X [...] config SUBSYSTEM_X tristate This is much cleaner, and way more flexible than "select". SUBSYSTEM_X can still be configured out, and it can be set as a module when none of the drivers are configured in or all of them are modular. Signed-off-by: Nicolas Pitre Reviewed-by: Josh Triplett Acked-by: Richard Cochran Acked-by: Thomas Gleixner --- Documentation/kbuild/kconfig-language.txt | 29 scripts/kconfig/expr.h| 2 ++ scripts/kconfig/menu.c| 55 ++- scripts/kconfig/symbol.c | 24 +- scripts/kconfig/zconf.gperf | 1 + scripts/kconfig/zconf.y | 16 +++-- 6 files changed, 108 insertions(+), 19 deletions(-) diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index 069fcb3eef..262722d886 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -113,6 +113,34 @@ applicable everywhere (see syntax). That will limit the usefulness but on the other hand avoid the illegal configurations all over. +- weak reverse dependencies: "imply" ["if" ] + This is similar to "select" as it enforces a lower limit on another + symbol except that the "implied" symbol's value may still be set to n + from a direct dependency or with a visible prompt. + + Given the following example: + + config FOO + tristate + imply BAZ + + config BAZ + tristate + depends on BAR + + The following values are possible: + + FOO BAR BAZ's default choice for BAZ + --- --- - -- + n y n N/m/y + m y m M/y/n + y y y Y/n + y n * N + + This is useful e.g. with multiple drivers that want to indicate their + ability to hook into a secondary subsystem while allowing the user to + configure that subsystem out without also having to unset these drivers. + - limiting menu display: "visible if" This attribute is only applicable to menu blocks, if the condition is false, the menu block is not displayed to the user (the symbols @@ -481,6 +509,7 @@ historical issues resolved through these different solutions. b) Match dependency semantics: b1) Swap all "select FOO" to "depends on FOO" or, b2) Swap all "depends on FOO" to "select FOO" + c) Consider the use of "imply" instead of "select" The resolution to a) can be tested with the sample Kconfig file Documentation/kbuild/Kconfig.recursion-issue-01 through the removal diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h index 973b6f7333..a73f762c48 100644 --- a/scripts/kconfig/expr.h +++ b/scripts/kconfig/expr.h @@ -85,6 +85,7 @@ struct symbol { struct property *prop; struct expr_value dir_dep; struct expr_value rev_dep; + struct expr_value implied; }; #define for_all_symbols(i, sym) for (i = 0; i < SYMBOL_HASHSIZE; i++) for (sym = symbol_hash[i]; sym; sym = sym->next) if (sym->type != S_OTHER) @@ -136,6 +137,7 @@ enum prop_type { P_DEFAULT, /* default y */ P_CHOICE, /* choice value */ P_SELECT, /* select BAR */ + P_IMPLY,/* imply BAR */ P_RANGE,/* range 7..100 (for a symbol) */ P_ENV, /* value from environment variable */ P_SYMBOL, /* where a symbol is defined */ diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c index aed678e8a7..e9357931b4 100644 --- a/scripts/kconfig/menu.c +++ b/scripts/kconfig/menu.c @@ -233,6 +233,8 @@ static void sym_check_prop(struct symbol *s
[PATCH v4 6/6] posix-timers: make it configurable
Some embedded systems have no use for them. This removes about 25KB from the kernel binary size when configured out. Corresponding syscalls are routed to a stub logging the attempt to use those syscalls which should be enough of a clue if they were disabled without proper consideration. They are: timer_create, timer_gettime: timer_getoverrun, timer_settime, timer_delete, clock_adjtime, setitimer, getitimer, alarm. The clock_settime, clock_gettime, clock_getres and clock_nanosleep syscalls are replaced by simple wrappers compatible with CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_BOOTTIME only which should cover the vast majority of use cases with very little code. Signed-off-by: Nicolas Pitre Reviewed-by: Josh Triplett Acked-by: Richard Cochran Acked-by: Thomas Gleixner --- arch/alpha/kernel/osf_sys.c | 8 +++ drivers/char/Kconfig| 1 + drivers/ptp/Kconfig | 2 +- fs/exec.c | 2 + init/Kconfig| 17 ++ kernel/compat.c | 8 +++ kernel/exit.c | 11 +++- kernel/fork.c | 2 + kernel/signal.c | 6 +++ kernel/sys.c| 3 +- kernel/time/Makefile| 10 +++- kernel/time/alarmtimer.c| 6 ++- kernel/time/posix-stubs.c | 123 kernel/time/timer.c | 3 +- security/selinux/hooks.c| 11 ++-- 15 files changed, 200 insertions(+), 13 deletions(-) create mode 100644 kernel/time/posix-stubs.c diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c index ffb93f499c..56e427c7aa 100644 --- a/arch/alpha/kernel/osf_sys.c +++ b/arch/alpha/kernel/osf_sys.c @@ -1029,11 +1029,16 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 __user *, tv, return do_sys_settimeofday(tv ? &kts : NULL, tz ? &ktz : NULL); } +asmlinkage long sys_ni_posix_timers(void); + SYSCALL_DEFINE2(osf_getitimer, int, which, struct itimerval32 __user *, it) { struct itimerval kit; int error; + if (!IS_ENABLED(CONFIG_POSIX_TIMERS)) + return sys_ni_posix_timers(); + error = do_getitimer(which, &kit); if (!error && put_it32(it, &kit)) error = -EFAULT; @@ -1047,6 +1052,9 @@ SYSCALL_DEFINE3(osf_setitimer, int, which, struct itimerval32 __user *, in, struct itimerval kin, kout; int error; + if (!IS_ENABLED(CONFIG_POSIX_TIMERS)) + return sys_ni_posix_timers(); + if (in) { if (get_it32(&kin, in)) return -EFAULT; diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index dcc09739a5..45ba878ae0 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -542,6 +542,7 @@ config HANGCHECK_TIMER config MMTIMER tristate "MMTIMER Memory mapped RTC for SGI Altix" depends on IA64_GENERIC || IA64_SGI_SN2 + depends on POSIX_TIMERS default y help The mmtimer device allows direct userspace access to the diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index 0f7492f8ea..bdce332911 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -6,7 +6,7 @@ menu "PTP clock support" config PTP_1588_CLOCK tristate "PTP clock support" - depends on NET + depends on NET && POSIX_TIMERS select PPS select NET_PTP_CLASSIFY help diff --git a/fs/exec.c b/fs/exec.c index 6fcfb3f7b1..a67a172332 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1164,8 +1164,10 @@ static int de_thread(struct task_struct *tsk) /* we have changed execution domain */ tsk->exit_signal = SIGCHLD; +#ifdef CONFIG_POSIX_TIMERS exit_itimers(sig); flush_itimer_signals(); +#endif if (atomic_read(&oldsighand->count) != 1) { struct sighand_struct *newsighand; diff --git a/init/Kconfig b/init/Kconfig index 34407f15e6..456e0b8912 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1445,6 +1445,23 @@ config SYSCTL_SYSCALL If unsure say N here. +config POSIX_TIMERS + bool "Posix Clocks & timers" if EXPERT + default y + help + This includes native support for POSIX timers to the kernel. + Some embedded systems have no use for them and therefore they + can be configured out to reduce the size of the kernel image. + + When this option is disabled, the following syscalls won't be + available: timer_create, timer_gettime: timer_getoverrun, + timer_settime, timer_delete, clock_adjtime, getitimer, + setitimer, alarm. Furthermore, the clock_settime, clock_gettime, + clock_getres and clock_nanosleep syscalls will be limited to + CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_BOOTTIME only. + + If unsure say y. + config KALLSYMS bool "Load all symbols for debugging/ksymoops" if EXPERT default y diff --git a/kernel/compat.c b/kernel/compat.c index 333d364be2..b3a04
[PATCH v4 3/6] ptp_clock: allow for it to be optional
In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. Drivers must be ready to accept NULL from ptp_clock_register() in that case. And to make it possible for PTP to be configured out, the select statement in those driver's Kconfig menu entries is converted to the new "imply" statement. This way the PTP subsystem may have Kconfig dependencies of its own, such as POSIX_TIMERS, without having to make those ethernet drivers unavailable if POSIX timers are cconfigured out. And when support for POSIX timers is selected again then the default config option for PTP clock support will automatically be adjusted accordingly. The pch_gbe driver is a bit special as it relies on extra code in drivers/ptp/ptp_pch.c. Therefore we let the make process descend into drivers/ptp/ even if PTP_1588_CLOCK is unselected. Signed-off-by: Nicolas Pitre Reviewed-by: Josh Triplett Acked-by: Richard Cochran Acked-by: Edward Cree Acked-by: Thomas Gleixner --- drivers/Makefile| 2 +- drivers/net/ethernet/adi/Kconfig| 2 +- drivers/net/ethernet/amd/Kconfig| 2 +- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 6 ++- drivers/net/ethernet/broadcom/Kconfig | 4 +- drivers/net/ethernet/cavium/Kconfig | 2 +- drivers/net/ethernet/freescale/Kconfig | 2 +- drivers/net/ethernet/intel/Kconfig | 10 ++-- drivers/net/ethernet/mellanox/mlx4/Kconfig | 2 +- drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 +- drivers/net/ethernet/renesas/Kconfig| 2 +- drivers/net/ethernet/samsung/Kconfig| 2 +- drivers/net/ethernet/sfc/Kconfig| 2 +- drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +- drivers/net/ethernet/ti/Kconfig | 2 +- drivers/net/ethernet/tile/Kconfig | 2 +- drivers/ptp/Kconfig | 8 +-- include/linux/ptp_clock_kernel.h| 65 - 18 files changed, 69 insertions(+), 50 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index f0afdfb3c7..8cfa1ff8f6 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -107,7 +107,7 @@ obj-$(CONFIG_INPUT) += input/ obj-$(CONFIG_RTC_LIB) += rtc/ obj-y += i2c/ media/ obj-$(CONFIG_PPS) += pps/ -obj-$(CONFIG_PTP_1588_CLOCK) += ptp/ +obj-y += ptp/ obj-$(CONFIG_W1) += w1/ obj-y += power/ obj-$(CONFIG_HWMON)+= hwmon/ diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig index 6b94ba6103..98cc8f5350 100644 --- a/drivers/net/ethernet/adi/Kconfig +++ b/drivers/net/ethernet/adi/Kconfig @@ -58,7 +58,7 @@ config BFIN_RX_DESC_NUM config BFIN_MAC_USE_HWSTAMP bool "Use IEEE 1588 hwstamp" depends on BFIN_MAC && BF518 - select PTP_1588_CLOCK + imply PTP_1588_CLOCK default y ---help--- To support the IEEE 1588 Precision Time Protocol (PTP), select y here diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig index 0038709fd3..713ea7ad22 100644 --- a/drivers/net/ethernet/amd/Kconfig +++ b/drivers/net/ethernet/amd/Kconfig @@ -177,7 +177,7 @@ config AMD_XGBE depends on ARM64 || COMPILE_TEST select BITREVERSE select CRC32 - select PTP_1588_CLOCK + imply PTP_1588_CLOCK ---help--- This driver supports the AMD 10GbE Ethernet device found on an AMD SoC. diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c index 9de078819a..e10e569c0d 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c @@ -773,7 +773,8 @@ static int xgbe_probe(struct platform_device *pdev) goto err_wq; } - xgbe_ptp_register(pdata); + if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK)) + xgbe_ptp_register(pdata); xgbe_debugfs_init(pdata); @@ -812,7 +813,8 @@ static int xgbe_remove(struct platform_device *pdev) xgbe_debugfs_exit(pdata); - xgbe_ptp_unregister(pdata); + if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK)) + xgbe_ptp_unregister(pdata); flush_workqueue(pdata->an_workqueue); destroy_workqueue(pdata->an_workqueue); diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig index bd8c80c0b7..6a8d74aeb6 100644 --- a/drivers/net/ethernet/broadcom/Kconfig +++ b/drivers/net/ethernet/broadcom/Kconfig @@ -110,7 +110,7 @@ config TIGON3 depends on PCI select PHYLIB select HWMON - select PTP_1588_CLOCK + impl
[PATCH v4 2/6] kconfig: regenerate *.c_shipped files after previous changes
Signed-off-by: Nicolas Pitre --- scripts/kconfig/zconf.hash.c_shipped | 30 +- scripts/kconfig/zconf.tab.c_shipped | 1581 -- 2 files changed, 753 insertions(+), 858 deletions(-) diff --git a/scripts/kconfig/zconf.hash.c_shipped b/scripts/kconfig/zconf.hash.c_shipped index 360a62df2b..d51b15de07 100644 --- a/scripts/kconfig/zconf.hash.c_shipped +++ b/scripts/kconfig/zconf.hash.c_shipped @@ -55,10 +55,10 @@ kconf_id_hash (register const char *str, register unsigned int len) 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, - 73, 73, 73, 73, 73, 73, 73, 5, 25, 25, + 73, 73, 73, 73, 73, 73, 73, 10, 25, 25, 0, 0, 0, 5, 0, 0, 73, 73, 5, 0, 10, 5, 45, 73, 20, 20, 0, 15, 15, 73, - 20, 5, 73, 73, 73, 73, 73, 73, 73, 73, + 20, 0, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, 73, @@ -120,6 +120,7 @@ struct kconf_id_strings_t char kconf_id_strings_str43[sizeof("hex")]; char kconf_id_strings_str46[sizeof("config")]; char kconf_id_strings_str47[sizeof("boolean")]; +char kconf_id_strings_str50[sizeof("imply")]; char kconf_id_strings_str51[sizeof("string")]; char kconf_id_strings_str54[sizeof("help")]; char kconf_id_strings_str56[sizeof("prompt")]; @@ -157,6 +158,7 @@ static const struct kconf_id_strings_t kconf_id_strings_contents = "hex", "config", "boolean", +"imply", "string", "help", "prompt", @@ -174,7 +176,7 @@ kconf_id_lookup (register const char *str, register unsigned int len) { enum { - TOTAL_KEYWORDS = 34, + TOTAL_KEYWORDS = 35, MIN_WORD_LENGTH = 2, MAX_WORD_LENGTH = 14, MIN_HASH_VALUE = 2, @@ -205,15 +207,15 @@ kconf_id_lookup (register const char *str, register unsigned int len) {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str12, T_DEFAULT, TF_COMMAND, S_TRISTATE}, #line 36 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str13, T_DEFAULT, TF_COMMAND, S_BOOLEAN}, -#line 46 "scripts/kconfig/zconf.gperf" +#line 47 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str14, T_OPT_DEFCONFIG_LIST,TF_OPTION}, {-1}, {-1}, -#line 44 "scripts/kconfig/zconf.gperf" +#line 45 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str17, T_ON, TF_PARAM}, #line 29 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str18, T_OPTIONAL, TF_COMMAND}, {-1}, {-1}, -#line 43 "scripts/kconfig/zconf.gperf" +#line 44 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str21, T_OPTION, TF_COMMAND}, #line 17 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str22, T_ENDMENU, TF_COMMAND}, @@ -223,9 +225,9 @@ kconf_id_lookup (register const char *str, register unsigned int len) #line 23 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str25, T_MENUCONFIG, TF_COMMAND}, {-1}, -#line 45 "scripts/kconfig/zconf.gperf" +#line 46 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str27, T_OPT_MODULES, TF_OPTION}, -#line 48 "scripts/kconfig/zconf.gperf" +#line 49 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str28, T_OPT_ALLNOCONFIG_Y,TF_OPTION}, #line 16 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str29, T_MENU, TF_COMMAND}, @@ -234,10 +236,10 @@ kconf_id_lookup (register const char *str, register unsigned int len) {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str31, T_SELECT, TF_COMMAND}, #line 21 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str32, T_COMMENT, TF_COMMAND}, -#line 47 "scripts/kconfig/zconf.gperf" +#line 48 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str33, T_OPT_ENV, TF_OPTION}, {-1}, -#line 41 "scripts/kconfig/zconf.gperf" +#line 42 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str35, T_RANGE,TF_COMMAND}, #line 19 "scripts/kconfig/zconf.gperf" {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str36, T_CHOICE, TF_COMMAND}, @@ -247,7 +249,7 @@ kconf_id_lookup (register const
[PATCH v4 5/6] posix_cpu_timers_exit: wrong place to collect entropy
There is no logical relation between add_device_randomness() and posix_cpu_timers_exit(). Let's move the former to where the later is called. This way, when posix-cpu-timers.c is compiled out, there is no need to worry about not losing a call to add_device_randomness(). Signed-off-by: Nicolas Pitre --- kernel/exit.c | 4 kernel/time/posix-cpu-timers.c | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index 9d68c45ebb..d16bcdd89d 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -54,6 +54,7 @@ #include #include #include +#include #include #include @@ -116,6 +117,9 @@ static void __exit_signal(struct task_struct *tsk) sig->curr_target = next_thread(tsk); } + add_device_randomness((const void*) &tsk->se.sum_exec_runtime, + sizeof(unsigned long long)); + /* * Accumulate here the counters for all threads as they die. We could * skip the group leader because it is the last user of signal_struct, diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c index 39008d7892..e582f20f47 100644 --- a/kernel/time/posix-cpu-timers.c +++ b/kernel/time/posix-cpu-timers.c @@ -9,7 +9,6 @@ #include #include #include -#include #include #include @@ -447,10 +446,7 @@ static void cleanup_timers(struct list_head *head) */ void posix_cpu_timers_exit(struct task_struct *tsk) { - add_device_randomness((const void*) &tsk->se.sum_exec_runtime, - sizeof(unsigned long long)); cleanup_timers(tsk->cpu_timers); - } void posix_cpu_timers_exit_group(struct task_struct *tsk) { -- 2.7.4
[PATCH v4 0/6] make POSIX timers optional with some Kconfig help
Many embedded systems don't need the full POSIX timer support. Configuring them out provides a nice kernel image size reduction. When POSIX timers are configured out, the PTP clock subsystem should be left out as well. However a bunch of ethernet drivers currently *select* the later in their Kconfig entries. Therefore some more work was needed to break that hard dependency from those drivers without preventing their usage altogether. Therefore this series also includes kconfig changes to implement a new keyword to express some reverse dependencies like "select" does, named "imply", and still allowing for the target config symbol to be disabled if the user or a direct dependency says so. At this point I'd like to gather ACKs especially from people in the "To" field. Ideally this would need to go upstream as a single series to avoid cross subsystem dependency issues. So far it was suggested that this could go via the kbuild tree. Given the end goal and the included timer cleanup patches I'd lean towards the timer tree but any tree would suit me just as well. This is also available here for those who prefer a git tree: git://git.linaro.org/people/nicolas.pitre/linux/ configurable_posix_timers Changes from v3: - Added a patch to move sys_alarm to itimer.c where the support code lives. - Added a patch to move entropy collection out of posix-cpu-timers.c. - Remove itimer as well when POSIX_TIMERS=n as they rely on code already removed. This means the getitimer, setitimer and alarm syscalls are also stubbed out in that case. - Reverted the addition of empty timer stubs from posix-timers.h. Since there is only a few callers, it's better to conditionalize call sites instead, and get a link error if some were missed. Easier to clearly ponder the implications that way. - Collected more ACKs. Changes from v2: - Dropped the patch adding the "suggest" keyword as nothing uses it. Requested by Paul Bolle. - Various documentation and commit log clarifications, prompted also by Paul Bolle. - Collected more ACKs. Changes from v1: - added "suggest" to kconfig for completeness - various typo fixes - small "imply" effect visibility fix The bulk of the diffstat comes from the kconfig lex parser regeneration. Diffstat: Documentation/kbuild/kconfig-language.txt | 29 + arch/alpha/kernel/osf_sys.c |8 + drivers/Makefile|2 +- drivers/char/Kconfig|1 + drivers/net/ethernet/adi/Kconfig|2 +- drivers/net/ethernet/amd/Kconfig|2 +- drivers/net/ethernet/amd/xgbe/xgbe-main.c |6 +- drivers/net/ethernet/broadcom/Kconfig |4 +- drivers/net/ethernet/cavium/Kconfig |2 +- drivers/net/ethernet/freescale/Kconfig |2 +- drivers/net/ethernet/intel/Kconfig | 10 +- drivers/net/ethernet/mellanox/mlx4/Kconfig |2 +- drivers/net/ethernet/mellanox/mlx5/core/Kconfig |2 +- drivers/net/ethernet/renesas/Kconfig|2 +- drivers/net/ethernet/samsung/Kconfig|2 +- drivers/net/ethernet/sfc/Kconfig|2 +- drivers/net/ethernet/stmicro/stmmac/Kconfig |2 +- drivers/net/ethernet/ti/Kconfig |2 +- drivers/net/ethernet/tile/Kconfig |2 +- drivers/ptp/Kconfig | 10 +- fs/exec.c |2 + include/linux/ptp_clock_kernel.h| 65 +- include/linux/time.h|2 - init/Kconfig| 17 + kernel/compat.c |8 + kernel/exit.c | 15 +- kernel/fork.c |2 + kernel/signal.c |6 + kernel/sys.c|3 +- kernel/time/Makefile| 10 +- kernel/time/alarmtimer.c|6 +- kernel/time/itimer.c| 15 +- kernel/time/posix-cpu-timers.c |4 - kernel/time/posix-stubs.c | 123 ++ kernel/time/timer.c | 16 +- scripts/kconfig/expr.h |2 + scripts/kconfig/menu.c | 55 +- scripts/kconfig/symbol.c| 24 +- scripts/kconfig/zconf.gperf |1 + scripts/kconfig/zconf.hash.c_shipped| 30 +- scripts/kconfig/zconf.tab.c_shipped | 1581 +++ scripts/kconfig/zconf.y | 16 +- security/selinux/hooks.c| 11 +- 43 files changed, 1148 insertions(+), 960 deletions(-)
[PATCH v4 4/6] timer: move sys_alarm from timer.c to itimer.c
Move the only user of alarm_setitimer to itimer.c where it is defined. This allows for making alarm_setitimer static, and dropping it from the build when __ARCH_WANT_SYS_ALARM is not defined. Signed-off-by: Nicolas Pitre --- include/linux/time.h | 2 -- kernel/time/itimer.c | 15 ++- kernel/time/timer.c | 13 - 3 files changed, 14 insertions(+), 16 deletions(-) diff --git a/include/linux/time.h b/include/linux/time.h index 4cea09d942..23f0f5ce30 100644 --- a/include/linux/time.h +++ b/include/linux/time.h @@ -172,8 +172,6 @@ extern int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue); extern int do_getitimer(int which, struct itimerval *value); -extern unsigned int alarm_setitimer(unsigned int seconds); - extern long do_utimes(int dfd, const char __user *filename, struct timespec *times, int flags); struct tms; diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c index 1d5c7204dd..2b9f45bc95 100644 --- a/kernel/time/itimer.c +++ b/kernel/time/itimer.c @@ -238,6 +238,8 @@ int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue) return 0; } +#ifdef __ARCH_WANT_SYS_ALARM + /** * alarm_setitimer - set alarm in seconds * @@ -250,7 +252,7 @@ int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue) * On 32 bit machines the seconds value is limited to (INT_MAX/2) to avoid * negative timeval settings which would cause immediate expiry. */ -unsigned int alarm_setitimer(unsigned int seconds) +static unsigned int alarm_setitimer(unsigned int seconds) { struct itimerval it_new, it_old; @@ -275,6 +277,17 @@ unsigned int alarm_setitimer(unsigned int seconds) return it_old.it_value.tv_sec; } +/* + * For backwards compatibility? This can be done in libc so Alpha + * and all newer ports shouldn't need it. + */ +SYSCALL_DEFINE1(alarm, unsigned int, seconds) +{ + return alarm_setitimer(seconds); +} + +#endif + SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value, struct itimerval __user *, ovalue) { diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 2d47980a1b..3ed6c67e17 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1662,19 +1662,6 @@ void run_local_timers(void) raise_softirq(TIMER_SOFTIRQ); } -#ifdef __ARCH_WANT_SYS_ALARM - -/* - * For backwards compatibility? This can be done in libc so Alpha - * and all newer ports shouldn't need it. - */ -SYSCALL_DEFINE1(alarm, unsigned int, seconds) -{ - return alarm_setitimer(seconds); -} - -#endif - static void process_timeout(unsigned long __data) { wake_up_process((struct task_struct *)__data); -- 2.7.4
Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT
On Nov 11 2016, Miklos Szeredi wrote: > On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath wrote: >> Hi Andrew, >> >> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT >> flag. But as far as I can tell, the flag is simply accepted without >> having any effect (including in libfuse). >> >> I tried to find related later commits, but did not find anything either. >> >> Am I missing something? > > Hmm, if fuse fs detects this flag, then it can return ENOSYS from open > resulting in this and subsequent opens succeeding without further > calls to userspace.If fuse fs doesn't detect this flag, it should > not return -ENOSYS, as that will result in the open failing, it should > instead implement a no-op open method. That doesn't sound like a good approach to me. That way, the file system has to *know* that this flag has been introduced in order to behave correctly, i.e. filesystems that predate the introduction of the flag will suddenly behave differently. I think the correct behavior would be to for the kernel to check if userspace passed the flag, and treat ENOSYS specially if and only if the flag was passed. > Could handle this in libfuse and that would make things easier for > filesystem implementors that would want to use this feature. But I > guess its use is relatively rare and so it doesn't really matter. I agree, but it would be nice to get this sorted out properly nevertheless. If nothing else, it will make the behavior easier to explain. Would you accept a patch that makes treatment of ENOSYS conditional on userspace passing the flag (as outlined above)? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default
On Nov 10 2016, Miklos Szeredi wrote: > On Thu, Nov 10, 2016 at 11:21 PM, Nikolaus Rath wrote: >> Hi Miklos, >> >> In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new >> FUSE_PARALLEL_DIROPS capability and bumped the kernel interface no to >> 25 - but there have been no corresponding changes to userspace. > > I think libfuse3 should always set this, it's just for backward compatibility. > >> Is this still preliminary and thus deliberately not in libfuse? I only >> noticed it by chance. > > Oops, I just forgot about it. Are you going to send a patch/pull request? If not, I don't mind adding it either. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: [PATCH 1/3] tuntap: rx batching
On 16-11-10 08:28 PM, Jason Wang wrote: > > > On 2016年11月11日 12:17, John Fastabend wrote: >> On 16-11-10 07:31 PM, Michael S. Tsirkin wrote: >>> >On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote: >> >> >>On 2016年11月10日 00:38, Michael S. Tsirkin wrote: > >>>On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: >> Backlog were used for tuntap rx, but it can only process 1 >> packet at >> one time since it was scheduled during sendmsg() synchronously in >> process context. This lead bad cache utilization so this patch >> tries >> to do some batching before call rx NAPI. This is done through: >> >> - accept MSG_MORE as a hint from sendmsg() caller, if it was set, >> batch the packet temporarily in a linked list and submit >> them all >> once MSG_MORE were cleared. >> - implement a tuntap specific NAPI handler for processing this >> kind of >> possible batching. (This could be done by extending >> backlog to >> support skb like, but using a tun specific one looks >> cleaner and >> easier for future extension). >> >> Signed-off-by: Jason Wang > >>>So why do we need an extra queue? >> >>The idea was borrowed from backlog to allow some kind of bulking and avoid >>spinlock on each dequeuing. >> > >>> This is not what hardware devices do. > >>>How about adding the packet to queue unconditionally, deferring > >>>signalling until we get sendmsg without MSG_MORE? >> >>Then you need touch spinlock when dequeuing each packet. >>> > >> Random thought, I have a cmpxchg ring I am using for the qdisc work that >> could possibly replace the spinlock implementation. I haven't figured >> out the resizing API yet because I did not need it but I assume it could >> help here and let you dequeue multiple skbs in one operation. >> >> I can post the latest version if useful or an older version is >> somewhere on patchworks as well. >> >> .John >> >> > > Look useful here, and I can compare the performance if you post. > > A question is can we extend the skb_array to support that? > > Thanks > Sent out two RFC patches with the implementation, the first has been running on my system for some time the second for multiple packets is only lightly tested and that was awhile back. .John
[RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings
--- include/linux/ptr_ring_ll.h | 136 +++ include/linux/skb_array.h | 25 2 files changed, 161 insertions(+) create mode 100644 include/linux/ptr_ring_ll.h diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h new file mode 100644 index 000..bcb11f3 --- /dev/null +++ b/include/linux/ptr_ring_ll.h @@ -0,0 +1,136 @@ +/* + * Definitions for the 'struct ptr_ring_ll' datastructure. + * + * Author: + * John Fastabend + * + * Copyright (C) 2016 Intel Corp. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This is a limited-size FIFO maintaining pointers in FIFO order, with + * one CPU producing entries and another consuming entries from a FIFO. + * extended from ptr_ring_ll to use cmpxchg over spin lock. + */ + +#ifndef _LINUX_PTR_RING_LL_H +#define _LINUX_PTR_RING_LL_H 1 + +#ifdef __KERNEL__ +#include +#include +#include +#include +#include +#include +#include +#endif + +struct ptr_ring_ll { + u32 prod_size; + u32 prod_mask; + u32 prod_head; + u32 prod_tail; + u32 cons_size; + u32 cons_mask; + u32 cons_head; + u32 cons_tail; + + void **queue; +}; + +/* Note: callers invoking this in a loop must use a compiler barrier, + * for example cpu_relax(). Callers must hold producer_lock. + */ +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr) +{ + u32 ret, head, tail, next, slots, mask; + + do { + head = READ_ONCE(r->prod_head); + mask = READ_ONCE(r->prod_mask); + tail = READ_ONCE(r->cons_tail); + + slots = mask + tail - head; + if (slots < 1) + return -ENOMEM; + + next = head + 1; + ret = cmpxchg(&r->prod_head, head, next); + } while (ret != head); + + r->queue[head & mask] = ptr; + smp_wmb(); + + while (r->prod_tail != head) + cpu_relax(); + + r->prod_tail = next; + return 0; +} + +static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r) +{ + u32 ret, head, tail, next, slots, mask; + void *ptr; + + do { + head = READ_ONCE(r->cons_head); + mask = READ_ONCE(r->cons_mask); + tail = READ_ONCE(r->prod_tail); + + slots = tail - head; + if (slots < 1) + return ERR_PTR(-ENOMEM); + + next = head + 1; + ret = cmpxchg(&r->cons_head, head, next); + } while (ret != head); + + ptr = r->queue[head & mask]; + smp_rmb(); + + while (r->cons_tail != head) + cpu_relax(); + + r->cons_tail = next; + return ptr; +} + +static inline void **__ptr_ring_ll_init_queue_alloc(int size, gfp_t gfp) +{ + return kzalloc(ALIGN(size * sizeof(void *), SMP_CACHE_BYTES), gfp); +} + +static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp) +{ + r->queue = __ptr_ring_init_queue_alloc(size, gfp); + if (!r->queue) + return -ENOMEM; + + r->prod_size = r->cons_size = size; + r->prod_mask = r->cons_mask = size - 1; + r->prod_tail = r->prod_head = 0; + r->cons_tail = r->prod_tail = 0; + + return 0; +} + +static inline void ptr_ring_ll_cleanup(struct ptr_ring_ll *r, void (*destroy)(void *)) +{ + if (destroy) { + void *ptr; + + ptr = __ptr_ring_ll_consume(r); + while (!IS_ERR_OR_NULL(ptr)) { + destroy(ptr); + ptr = __ptr_ring_ll_consume(r); + } + } + kfree(r->queue); +} + +#endif /* _LINUX_PTR_RING_LL_H */ diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h index f4dfade..9b43dfd 100644 --- a/include/linux/skb_array.h +++ b/include/linux/skb_array.h @@ -22,6 +22,7 @@ #ifdef __KERNEL__ #include +#include #include #include #endif @@ -30,6 +31,10 @@ struct skb_array { struct ptr_ring ring; }; +struct skb_array_ll { + struct ptr_ring_ll ring; +}; + /* Might be slightly faster than skb_array_full below, but callers invoking * this in a loop must use a compiler barrier, for example cpu_relax(). */ @@ -43,6 +48,11 @@ static inline bool skb_array_full(struct skb_array *a) return ptr_ring_full(&a->ring); } +static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff *skb) +{ + return __ptr_ring_ll_produce(&a->ring, skb); +} + static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb) { return ptr_ring_produce(&a->ring, skb); @@ -92,6 +102,11 @@ static inline bool skb
[RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once
Signed-off-by: John Fastabend --- include/linux/ptr_ring_ll.h | 22 -- include/linux/skb_array.h | 11 +-- net/sched/sch_generic.c |2 +- 3 files changed, 26 insertions(+), 9 deletions(-) diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h index bcb11f3..5dc25f7 100644 --- a/include/linux/ptr_ring_ll.h +++ b/include/linux/ptr_ring_ll.h @@ -45,9 +45,10 @@ struct ptr_ring_ll { /* Note: callers invoking this in a loop must use a compiler barrier, * for example cpu_relax(). Callers must hold producer_lock. */ -static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr) +static inline int __ptr_ring_ll_produce_many(struct ptr_ring_ll *r, +void **ptr, int num) { - u32 ret, head, tail, next, slots, mask; + u32 ret, head, tail, next, slots, mask, i; do { head = READ_ONCE(r->prod_head); @@ -55,21 +56,30 @@ static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr) tail = READ_ONCE(r->cons_tail); slots = mask + tail - head; - if (slots < 1) + if (slots < num) + num = slots; + + if (unlikely(!num)) return -ENOMEM; - next = head + 1; + next = head + num; ret = cmpxchg(&r->prod_head, head, next); } while (ret != head); - r->queue[head & mask] = ptr; + for (i = 0; i < num; i++) + r->queue[(head + i) & mask] = ptr[i]; smp_wmb(); while (r->prod_tail != head) cpu_relax(); r->prod_tail = next; - return 0; + return num; +} + +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void **ptr) +{ + return __ptr_ring_ll_produce_many(r, ptr, 1); } static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r) diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h index 9b43dfd..de3c700 100644 --- a/include/linux/skb_array.h +++ b/include/linux/skb_array.h @@ -48,9 +48,16 @@ static inline bool skb_array_full(struct skb_array *a) return ptr_ring_full(&a->ring); } -static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff *skb) +static inline int skb_array_ll_produce_many(struct skb_array_ll *a, + struct sk_buff **skb, int num) { - return __ptr_ring_ll_produce(&a->ring, skb); + return __ptr_ring_ll_produce_many(&a->ring, (void **)skb, num); +} + +static inline int skb_array_ll_produce(struct skb_array_ll *a, + struct sk_buff **skb) +{ + return __ptr_ring_ll_produce(&a->ring, (void **)skb); } static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb) diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index 4648ec8..58f2011 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -571,7 +571,7 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc *qdisc, struct skb_array_ll *q = band2list(priv, band); int err; - err = skb_array_ll_produce(q, skb); + err = skb_array_ll_produce(q, &skb); if (unlikely(err)) { net_warn_ratelimited("drop a packet from fast enqueue\n");
[RFC PATCH 0/2] illustrate cmpxchg ring for tap/tun and qdisc
This is a cmpxchg ring that could potentially be used to replace the spinlock variant of skb_array. Couple comments its missing a resize operator which would need to be added before it could be a drop in replacement. And although I tested the first patch with my latest set of qdisc updates the second patch I have not tested for a bit so it may or may not work but it illustrates the idea at least. This was derived from the DPDK documentation where there is a description of the cmpxchg ring presumably used there. It may or may not actually align with what is done in DPDK implementation I have no idea I didn't look. --- John Fastabend (2): net: use cmpxchg instead of spinlock in ptr rings ptr_ring_ll: pop/push multiple objects at once include/linux/netdevice.h | 12 include/linux/ptr_ring_ll.h | 146 +++ include/linux/skb_array.h | 32 + net/core/dev.c | 18 + net/sched/sch_generic.c | 86 + 5 files changed, 224 insertions(+), 70 deletions(-) create mode 100644 include/linux/ptr_ring_ll.h -- Signature
Re: [PATCH RFC 0/2] Generalize tpm2_get_tpm_pt to tpm2_get_cap
On 11/04/2016 12:58 PM, Jarkko Sakkinen wrote: Nayna, I've already sent these earlier this month as we had this discussion. Please look up your emails. I can apply these if they look good for you. Please review them. Sure, I replied just now. I am sorry if delay in response. I was off early this week and still going through all mails. Thanks & Regards, - Nayna /Jarkko On Sun, Oct 09, 2016 at 01:14:14PM +0300, Jarkko Sakkinen wrote: We need to generalize tpm2_get_tpm_pt to tpm2_get_cap in order to it be suitable for grabbing handles, PCR banks and so forth. Jarkko Sakkinen (2): tpm: move TPM 2.0 command and response constants to tpm2-cmd.c tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd drivers/char/tpm/tpm.h | 48 ++ drivers/char/tpm/tpm2-cmd.c | 106 +++- drivers/char/tpm/tpm_tis_core.c | 3 +- 3 files changed, 80 insertions(+), 77 deletions(-) -- 2.7.4
Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
Hello ChenYu On Fri, Nov 11, 2016 at 12:01 AM, Chen-Yu Tsai wrote: > On Fri, Nov 11, 2016 at 5:42 AM, Rob Herring wrote: [snip] >> >> Do you have patches using this already. If not, it is starting to get >> a bit late for v4.10. >> >> I can apply this, but then you'll just be pulling in other DT patches. > > Not sure what you mean by "using" this... > > I have patches which use this to add DT-based modalias entries for > module auto-loading to i2c and sunxi-rsb that I haven't sent. > Unfortunately the I2C core can't be changed without breaking a lot of I2C drivers that are relying on the current behavior. I've already posted a RFC patch [0] for I2C that does this about a year ago and enumerated the issues that have to be addressed before the change can be made (and fixed some of the issues mentioned) on this series [1]. Another issue is that an I2C device ID table is a requirement anyways since I2C drivers expect an i2c_device_id as an argument of their probe function. Kieran already have patches [2] to change that which should land soon. I plan to fix the remaining I2C drivers once his patches are merged and re-post the RFC patch as a proper one. > As far as DT usage goes, we already need this for the axp20x mfd driver. > There are 2 variants, i2c and sunxi-rsb. For the I2C variant a fix was > sent to fix module auto-loading by using the I2C client ID table: > > mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading > > https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=b7142a19321484bd7681aa547c1d50148c8e2825 > Yes, this is the workaround used by most DT-only I2C drivers. The only reason that these drivers have an I2C device ID is due the restrictions imposed by the I2C core. Best regards, Javier
Re: [PATCH 05/35] staging: lustre: llog: fix wrong offset in llog_process_thread()
Hi Mikhail, [auto build test ERROR on staging/staging-testing] [also build test ERROR on next-20161110] [cannot apply to v4.9-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/James-Simmons/second-batch-of-missing-lustre-2-8-patches/2016-021225 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=m68k All errors (new ones prefixed by >>): >> ERROR: "__umoddi3" [drivers/staging/lustre/lustre/obdclass/obdclass.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC
On Thu, 2016-11-10 at 13:23 -0800, Kees Cook wrote: > If we don't use opt-out for atomics, we're going to be in the same > situation where we have to constantly review every commit with an > atomic for exploitable refcount flaws. Kicking this down from > "privilege escalation" to "DoS" is a significant change in the > kernel's weaknesses. The only way I see around that would be to totally get rid of the name atomic_t, forcing people with out of tree code to use kref_t, or whatever name we pick for the variable type that can wrap. Something like checkpatch or a patch checking bot could warn whenever new code is submitted that uses the counter type that can wrap. Not sure whether I like my idea :) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
On 2016-11-10 10:29, Vladimir Zapolskiy wrote: > Hi Stefan, Philipp, > > On 11/09/2016 02:50 AM, Stefan Agner wrote: >> On 2016-11-08 09:33, maitysancha...@gmail.com wrote: >>> Hello Shawn, >>> >>> On 16-10-22 15:43:04, Vladimir Zapolskiy wrote: Hi Shawn, On 10/22/2016 06:25 AM, Shawn Guo wrote: > On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote: >> Remove the use of DDC I2C bus bitbang to support reading of EDID >> and rely on support from internal HDMI I2C master controller instead. >> As a result remove the device tree property ddc-i2c-bus. >> >> Signed-off-by: Sanchayan Maity > > I think that the dw-hdmi i2c support [1] is a prerequisite of this > patch. I do not see it lands on v4.9-rc1. Or am I missing something? > > Shawn > > [1] https://patchwork.kernel.org/patch/9296883/ > I'm adding Philipp to Cc, since he is the last one who tested the change and helped me to push the change to the mainline: https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html The problem is that there is no official DW HDMI bridge maintainer, may be you can review the change, and if you find it satisfactory push it through ARM/iMX tree. >>> >>> Shawn, is it okay if that patch goes through your ARM/iMX tree? >> >> I don't think it makes sense that the DRM bridge changes go through >> Shawn's tree. Dave should merge Philipps pull request... >> > > Philipp, do you mind to submit a rebased pull request one more time? > You probably saw it, Dave merged it today in his drm-next branch: https://cgit.freedesktop.org/~airlied/linux/?h=drm-next I guess with that Shawn can go ahead and merge this patchset for next too...? -- Stefan
Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability
Hi Peter, On 11/10/2016 07:44 PM, Peter Zijlstra wrote: > On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote: >> On Thu, 10 Nov 2016, Lu Baolu wrote: >>> This seems to be a common issue for all early printk drivers. >> No. The other early printk drivers like serial do not have that problem as >> they simply do: >> >>while (*buf) { >> while (inb(UART) & TX_BUSY) >> cpu_relax(); >> outb(*buf++, UART); >>} > Right, which is why actual UARTs rule. If only laptops still had pinouts > for them life would be so much better. > > Ideally the USB debug port would be a virtual UART and its interface as > simple and robust. > >> The wait for the UART to become ready is independent of the context as it >> solely depends on the hardware. >> >> As a result you can see the output from irq/nmi intermingled with the one >> from thread context, but that's the only problem they have. >> >> The only thing you can do to make this work is to prevent printing in NMI >> context: >> >> write() >> { >> if (in_nmi()) >> return; >> >> raw_spinlock_irqsave(&lock, flags); >> >> >> That fully serializes the writes and just ignores NMI context printks. Not >> optimal, but I fear that's all you can do. > I would also suggest telling the hardware people they have designed > something near the brink of useless. If you cannot do random exception > context debugging (#DB, #NMI, #MCE etc..) then there's a whole host of > problems that simply cannot be debugged. > > Also note that kdb runs from NMI context, so you'll not be able to > support that either. > Things become complicated when it comes to USB debug port. But it's still addressable. At this time, we can do it like this. write() { if (in_nmi() && raw_spin_is_locked(&lock)) return; raw_spinlock_irqsave(&lock, flags); This will filter some messages from NMI handler in case that another thread is holding the spinlock. I have no idea about how much chance could a debug user faces this. But it might further be fixed with below enhancement. write() { if (in_nmi() && raw_spin_is_locked(&lock)) { produce_a_pending_item_in_ring(); return; } raw_spinlock_irqsave(&lock, flags); while (!pending_item_ring_is_empty) consume_a_pending_item_in_ring(); We can design the pending item ring in a producer-consumer model. It's easy to avoid race between the producer and consumer. Best regards, Lu Baolu
Re: [PATCH 1/3] tuntap: rx batching
On 2016年11月11日 12:17, John Fastabend wrote: On 16-11-10 07:31 PM, Michael S. Tsirkin wrote: >On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote: >> >> >>On 2016年11月10日 00:38, Michael S. Tsirkin wrote: >>>On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: Backlog were used for tuntap rx, but it can only process 1 packet at one time since it was scheduled during sendmsg() synchronously in process context. This lead bad cache utilization so this patch tries to do some batching before call rx NAPI. This is done through: - accept MSG_MORE as a hint from sendmsg() caller, if it was set, batch the packet temporarily in a linked list and submit them all once MSG_MORE were cleared. - implement a tuntap specific NAPI handler for processing this kind of possible batching. (This could be done by extending backlog to support skb like, but using a tun specific one looks cleaner and easier for future extension). Signed-off-by: Jason Wang >>>So why do we need an extra queue? >> >>The idea was borrowed from backlog to allow some kind of bulking and avoid >>spinlock on each dequeuing. >> >>> This is not what hardware devices do. >>>How about adding the packet to queue unconditionally, deferring >>>signalling until we get sendmsg without MSG_MORE? >> >>Then you need touch spinlock when dequeuing each packet. > Random thought, I have a cmpxchg ring I am using for the qdisc work that could possibly replace the spinlock implementation. I haven't figured out the resizing API yet because I did not need it but I assume it could help here and let you dequeue multiple skbs in one operation. I can post the latest version if useful or an older version is somewhere on patchworks as well. .John Look useful here, and I can compare the performance if you post. A question is can we extend the skb_array to support that? Thanks
Re: [tpmdd-devel] [PATCH RFC 2/2] tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd
On 10/09/2016 03:44 PM, Jarkko Sakkinen wrote: Refactored tpm2_get_tpm_pt to tpm2_getcap_cmd, which means that it also takes capability ID as input. This is required to access TPM_CAP_HANDLES, which contains metadata needed for swapping transient data. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm.h | 6 +++- drivers/char/tpm/tpm2-cmd.c | 64 - drivers/char/tpm/tpm_tis_core.c | 3 +- 3 files changed, 38 insertions(+), 35 deletions(-) diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index 0fab6d5..8176f42 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -85,6 +85,10 @@ enum tpm2_capabilities { TPM2_CAP_TPM_PROPERTIES = 6, }; +enum tpm2_properties { + TPM2_PT_FAMILY_INDICATOR= 0x100, +}; + enum tpm2_startup_types { TPM2_SU_CLEAR = 0x, TPM2_SU_STATE = 0x0001, @@ -485,7 +489,7 @@ int tpm2_seal_trusted(struct tpm_chip *chip, int tpm2_unseal_trusted(struct tpm_chip *chip, struct trusted_key_payload *payload, struct trusted_key_options *options); -ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id, +ssize_t tpm2_getcap_cmd(struct tpm_chip *chip, u32 cap_id, u32 property_id, u32 *value, const char *desc); int tpm2_auto_startup(struct tpm_chip *chip); diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index 2900e18..fcf3d86 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -111,13 +111,13 @@ struct tpm2_pcr_extend_in { u8 digest[TPM_DIGEST_SIZE]; } __packed; -struct tpm2_get_tpm_pt_in { +struct tpm2_getcap_in { __be32 cap_id; __be32 property_id; __be32 property_cnt; } __packed; -struct tpm2_get_tpm_pt_out { +struct tpm2_getcap_out { u8 more_data; __be32 subcap_id; __be32 property_cnt; @@ -140,8 +140,8 @@ union tpm2_cmd_params { struct tpm2_pcr_read_inpcrread_in; struct tpm2_pcr_read_out pcrread_out; struct tpm2_pcr_extend_in pcrextend_in; - struct tpm2_get_tpm_pt_in get_tpm_pt_in; - struct tpm2_get_tpm_pt_out get_tpm_pt_out; + struct tpm2_getcap_in getcap_in; + struct tpm2_getcap_out getcap_out; struct tpm2_get_random_in getrandom_in; struct tpm2_get_random_out getrandom_out; }; @@ -435,16 +435,6 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max) return total ? total : -EIO; } -#define TPM2_GET_TPM_PT_IN_SIZE \ - (sizeof(struct tpm_input_header) + \ -sizeof(struct tpm2_get_tpm_pt_in)) - -static const struct tpm_input_header tpm2_get_tpm_pt_header = { - .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS), - .length = cpu_to_be32(TPM2_GET_TPM_PT_IN_SIZE), - .ordinal = cpu_to_be32(TPM2_CC_GET_CAPABILITY) -}; - /** * Append TPMS_AUTH_COMMAND to the buffer. The buffer must be allocated with * tpm_buf_alloc(). @@ -750,35 +740,43 @@ out: return rc; } +#define TPM2_GETCAP_IN_SIZE \ + (sizeof(struct tpm_input_header) + sizeof(struct tpm2_getcap_in)) + +static const struct tpm_input_header tpm2_getcap_header = { + .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS), + .length = cpu_to_be32(TPM2_GETCAP_IN_SIZE), + .ordinal = cpu_to_be32(TPM2_CC_GET_CAPABILITY) +}; + /** - * tpm2_get_tpm_pt() - get value of a TPM_CAP_TPM_PROPERTIES type property - * @chip: TPM chip to use. - * @property_id: property ID. - * @value: output variable. + * tpm2_getcap_cmd() - execute a TPM2_GetCapability command + * @chip: TPM chip to use + * @cap_id:capability ID + * @property_id: property ID + * @value: value of the property * @desc: passed to tpm_transmit_cmd() * - * 0 is returned when the operation is successful. If a negative number is - * returned it remarks a POSIX error code. If a positive number is returned - * it remarks a TPM error. + * Return: same as with tpm_transmit_cmd */ -ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id, u32 *value, - const char *desc) +ssize_t tpm2_getcap_cmd(struct tpm_chip *chip, u32 cap_id, u32 property_id, + u32 *value, const char *desc) This function currently returns single value "u32 *value" as output data. Some calling function expect list of values from capabilities output. For eg., get_active_banks() use TPM_CAP_PCRS capability to retrieve list of active banks. And this capability returns array of pcr selections(which is a struct representing each active PCR bank) I was thinking, can we define output parameter as struct of cap_id and union of expected cap_data ? struct cap_out { u32 cap_id; union cap_data { struct tpml_pcr_selection assig
Re: [PATCH 2/3] vhost: better detection of available buffers
On 2016年11月11日 11:41, Michael S. Tsirkin wrote: On Fri, Nov 11, 2016 at 10:18:37AM +0800, Jason Wang wrote: > > >On 2016年11月10日 03:57, Michael S. Tsirkin wrote: > >On Wed, Nov 09, 2016 at 03:38:32PM +0800, Jason Wang wrote: > > >We should use vq->last_avail_idx instead of vq->avail_idx in the > > >checking of vhost_vq_avail_empty() since latter is the cached avail > > >index from guest but we want to know if there's pending available > > >buffers in the virtqueue. > > > > > >Signed-off-by: Jason Wang > >I'm not sure why is this patch here. Is it related to > >batching somehow? > >Yes, we need to know whether or not there's still buffers left in the >virtqueue, so need to check last_avail_idx. Otherwise, we're checking if >guest has submitted new buffers. > > > > > > > >--- > > > drivers/vhost/vhost.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > >diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > > >index c6f2d89..fdf4cdf 100644 > > >--- a/drivers/vhost/vhost.c > > >+++ b/drivers/vhost/vhost.c > > >@@ -2230,7 +2230,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq) > > > if (r) > > > return false; > > >- return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx; > > >+ return vhost16_to_cpu(vq, avail_idx) == vq->last_avail_idx; > > > } > > > EXPORT_SYMBOL_GPL(vhost_vq_avail_empty); > >That might be OK for TX but it's probably wrong for RX > >where the fact that used != avail does not mean > >we have enough space to store the packet. > >Right, but it's no harm since it was just a hint, handle_rx() can handle >this situation. Means busy polling will cause useless load on the CPU though. Right, but,it's not easy to have 100% correct hint here. Needs more thought.
Re: [PATCH 1/3] tuntap: rx batching
On 16-11-10 07:31 PM, Michael S. Tsirkin wrote: > On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote: >> >> >> On 2016年11月10日 00:38, Michael S. Tsirkin wrote: >>> On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: Backlog were used for tuntap rx, but it can only process 1 packet at one time since it was scheduled during sendmsg() synchronously in process context. This lead bad cache utilization so this patch tries to do some batching before call rx NAPI. This is done through: - accept MSG_MORE as a hint from sendmsg() caller, if it was set, batch the packet temporarily in a linked list and submit them all once MSG_MORE were cleared. - implement a tuntap specific NAPI handler for processing this kind of possible batching. (This could be done by extending backlog to support skb like, but using a tun specific one looks cleaner and easier for future extension). Signed-off-by: Jason Wang >>> So why do we need an extra queue? >> >> The idea was borrowed from backlog to allow some kind of bulking and avoid >> spinlock on each dequeuing. >> >>> This is not what hardware devices do. >>> How about adding the packet to queue unconditionally, deferring >>> signalling until we get sendmsg without MSG_MORE? >> >> Then you need touch spinlock when dequeuing each packet. > Random thought, I have a cmpxchg ring I am using for the qdisc work that could possibly replace the spinlock implementation. I haven't figured out the resizing API yet because I did not need it but I assume it could help here and let you dequeue multiple skbs in one operation. I can post the latest version if useful or an older version is somewhere on patchworks as well. .John > It runs on the same CPU, right? Otherwise we should use skb_array... > >>> >>> --- drivers/net/tun.c | 71 ++- 1 file changed, 65 insertions(+), 6 deletions(-) >> >> [...] >> rxhash = skb_get_hash(skb); - netif_rx_ni(skb); + skb_queue_tail(&tfile->socket.sk->sk_write_queue, skb); + + if (!more) { + local_bh_disable(); + napi_schedule(&tfile->napi); + local_bh_enable(); >>> Why do we need to disable bh here? I thought napi_schedule can >>> be called from any context. >> >> Yes, it's unnecessary. Will remove. >> >> Thanks
Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention
On Thu, 2016-11-10 at 11:52 +0300, Stas Sergeev wrote: > Hi! > > I don't know the context of that discussion, so I'll only > comment on the dosemu part. I'm sorry! I will cc you and the linux-msdos list in my v2. > > 10.11.2016 09:46, Ricardo Neri пишет: > > I took a closer look at the dosemu code. It appears that it does not > > purposely utilize SGDT to obtain the descriptor table while in vm86. It > > does use SGDT (in protected mode) to emulate certain functionality such > > as the Virtual xxx Driver. In such a case, UMIP needs to be disabled. > > However, this code seems to be disabled [1]. > Indeed. > The code you've found, was copied from wine, because > dosemu supports windows-3.1. But sgdt is in win32s part > that is disabled in dosemu. It is however enabled in wine, or > at least it was when I ported the VxD code from there. So you > may want to ask wine devs if they still use sgdt and vm86. > In dosemu, if we ever enable win32s support, we won't rely > on sgdt. In fact, when some prot mode program under dosemu > uses GDT selectors, in a fault handler we replace them with > LDT selectors. Actually, the SLDT instruction is also impacted by this feature. This feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT, SMSW or STR are executed with CPL > 0. Would this be a problem for dosemu? The proposal now is to trap this GPU fault and give fake value for these tables. > > > dosemu includes an i386 > > emulator that in some cases uses the actual instructions of the host > > system. > In dosemu2 code, the places you've found, now contain this: > error("SGDT not implemented\n"); > If we ever support SGDT, we'll use some emulation/fake values. > > So overall, dosemu is not going to willingly use sgdt in any > near future. But the programs running under vm86 or in prot mode > may do so. This is very uncommon though, especially under dosemu, > because it supports only a "polite" programs - those that work > under win95's dos prompt. No one would get sufficiently hurt if > sgdt under vm86 will somehow change from its current behaviour. This is good news. This means that we could go ahead and give a fake pointer to the GDT and the other impacted tables? > > You can ask wine people for their sgdt use in win32s subsystem. Will do. Thanks and BR, Ricardo
Re: [PATCH] mm: add ZONE_DEVICE statistics to smaps
On 11/11/2016 03:41 AM, Dan Williams wrote: > ZONE_DEVICE pages are mapped into a process via the filesystem-dax and > device-dax mechanisms. There are also proposals to use ZONE_DEVICE > pages for other usages outside of dax. Add statistics to smaps so > applications can debug that they are obtaining the mappings they expect, > or otherwise accounting them. This might also help when we will have ZONE_DEVICE based solution for HMM based device memory.
Re: [GIT PULL] SCSI fixes for 4.9-rc3
On 11.11.2016 04:30, Gabriel C wrote: > > On 05.11.2016 14:29, James Bottomley wrote: > > > ... > >> Kashyap Desai (1): >> scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) >> devices >> >> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >> b/drivers/scsi/megaraid/megaraid_sas_base.c >> index 9ff57de..d8b1fbd 100644 >> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >> @@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost, >> struct scsi_cmnd *scmd) >> goto out_done; >> } >> >> -switch (scmd->cmnd[0]) { >> -case SYNCHRONIZE_CACHE: >> -/* >> - * FW takes care of flush cache on its own >> - * No need to send it down >> - */ >> +/* >> + * FW takes care of flush cache on its own for Virtual Disk. >> + * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to >> FW. >> + */ >> +if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) { >> scmd->result = DID_OK << 16; >> goto out_done; >> -default: >> -break; >> } >> >> return instance->instancet->build_and_issue_cmd(instance, scmd); > > This patch breaks my box.. I'm not able to boot it anymore. > It seems with this patch I have /dev/sda[a-z] to /dev/sdz[a-z] ?!? > > I'm not sure how to get an log since dracut times out and I'm dropped , after > a very long time > of probing 'ghost devices', in a emercency shell, journalctl doesn't work > also.. > > After reverting this one I can boot normal. > > Box is a FUJITSU PRIMERGY TX200 S5.. > > This is from an working kernel.. > > [5.119371] megaraid_sas :01:00.0: FW now in Ready state > [5.119418] megaraid_sas :01:00.0: firmware supports msix: (0) > [5.119420] megaraid_sas :01:00.0: current msix/online cpus : > (1/16) > [5.119422] megaraid_sas :01:00.0: RDPQ mode : (disabled) > [5.123100] ehci-pci :00:1a.7: cache line size of 32 is not supported > [5.123113] ehci-pci :00:1a.7: irq 18, io mem 0xb002 > > ... > > [5.208063] megaraid_sas :01:00.0: controller type : MR(256MB) > [5.208065] megaraid_sas :01:00.0: Online Controller Reset(OCR) : > Enabled > [5.208067] megaraid_sas :01:00.0: Secure JBOD support : No > [5.208070] megaraid_sas :01:00.0: megasas_init_mfi: fw_support_ieee=0 > [5.208073] megaraid_sas :01:00.0: INIT adapter done > [5.208075] megaraid_sas :01:00.0: Jbod map is not supported > megasas_setup_jbod_map 4967 > [5.230163] megaraid_sas :01:00.0: MR_DCMD_PD_LIST_QUERY failed/not > supported by firmware > [5.252080] megaraid_sas :01:00.0: DCMD not supported by firmware - > megasas_ld_list_query 4369 > [5.274086] megaraid_sas :01:00.0: pci id: > (0x1000)/(0x0060)/(0x1734)/(0x10f9) > [5.274089] megaraid_sas :01:00.0: unevenspan support: no > [5.274090] megaraid_sas :01:00.0: firmware crash dump : no > [5.274092] megaraid_sas :01:00.0: jbod sync map : no > [5.274094] scsi host0: Avago SAS based MegaRAID driver > [5.280022] scsi 0:0:6:0: Direct-Access ATA WDC WD5002ABYS-5 3B06 > PQ: 0 ANSI: 5 > [5.282153] scsi 0:0:7:0: Direct-Access ATA WDC WD5002ABYS-5 3B06 > PQ: 0 ANSI: 5 > [5.285180] scsi 0:0:10:0: Direct-Access ATA ST500NM0011 > FTM6 PQ: 0 ANSI: 5 > [5.369885] scsi 0:2:0:0: Direct-Access LSI MegaRAID SAS RMB 1.40 > PQ: 0 ANSI: 5 > > .. > > Please let me know if you need more infos and/or want me to test patches. > > I managed to get some parts of the broken dmesg. There it is : http://ftp.frugalware.org/pub/other/people/crazy/kernel/broken-dmesg
Re: [PATCH 1/3] tuntap: rx batching
On 2016年11月11日 11:31, Michael S. Tsirkin wrote: On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote: > > >On 2016年11月10日 00:38, Michael S. Tsirkin wrote: > >On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: > > >Backlog were used for tuntap rx, but it can only process 1 packet at > > >one time since it was scheduled during sendmsg() synchronously in > > >process context. This lead bad cache utilization so this patch tries > > >to do some batching before call rx NAPI. This is done through: > > > > > >- accept MSG_MORE as a hint from sendmsg() caller, if it was set, > > >batch the packet temporarily in a linked list and submit them all > > >once MSG_MORE were cleared. > > >- implement a tuntap specific NAPI handler for processing this kind of > > >possible batching. (This could be done by extending backlog to > > >support skb like, but using a tun specific one looks cleaner and > > >easier for future extension). > > > > > >Signed-off-by: Jason Wang > >So why do we need an extra queue? > >The idea was borrowed from backlog to allow some kind of bulking and avoid >spinlock on each dequeuing. > > > This is not what hardware devices do. > >How about adding the packet to queue unconditionally, deferring > >signalling until we get sendmsg without MSG_MORE? > >Then you need touch spinlock when dequeuing each packet. It runs on the same CPU, right? Otherwise we should use skb_array... There could be multiple senders technically. Will try skb_array and see if there's any difference. Thanks
Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions
On Thu, 2016-11-10 at 09:58 +0100, Borislav Petkov wrote: > On Wed, Nov 09, 2016 at 07:24:43PM -0800, Ricardo Neri wrote: > > I intended this feature to be configurable at build time in case someone > > wants to build a kernel without it; similar to other features such as > > SMAP. Is this not needed? Should Linux be built with this feature always > > enabled? > > > > This feature could always be disabled via a kernel parameter, though; > > even if Linux is built with it. > > It probably is a good idea to have it build-time configurable for the > embedded folks. But you can do a before and after build and look at > the vmlinux size and see how much it has grown. If it is only a couple > of KBs I guess we can drop the config option even but I know there are > people who still care about KBs too... Thanks for the suggestions. Perhaps I can include these metrics in my V2. On th other hand, Dave Hansen gave a good argument on potential conflicts when, of instance running on an AMD CPU. UMIP is enabled by setting a bit in CR4. If that bit is not supposed to be set, that could cause a #GP fault. Thanks and BR, Ricardo > > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nürnberg)
linux-next: Tree for Nov 11
Hi all, Changes since 20161110: Non-merge commits (relative to Linus' tree): 5178 5669 files changed, 326526 insertions(+), 103299 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 246 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 (27bcd37e0240 Merge tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (cc6acc11cad1 kbuild: be more careful about matching preprocessed asm ___EXPORT_SYMBOL) Merging arc-current/for-curr (0a0a047def15 ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core) Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls) Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (b65f63ec547e powerpc/oops: Fix missing pr_cont()s in instruction dump) Merging sparc/master (0c183d92b20b Merge tag 'spi-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi) Merging net/master (23dd8315485a Merge branch 'mlxsw-fixes') Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti interface is removed) Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if it is L3 master) Merging ipvs/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if the user doesn't specify it) Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap) Merging mac80211/master (269ebce4531b xen-netfront: cast grant table reference first to type int) Merging sound-current/for-linus (2ecb704a1290 ALSA: hda - add a new condition to check if it is thinkpad) Merging pci-current/for-linus (4d3222f7071c arm64: dts: rockchip: add three new resets for rk3399 PCIe controller) Merging driver-core.current/driver-core-linus (bdacd1b426db driver core: fix smatch warning on dev->bus check) Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3) Merging usb.current/usb-linus (18266403f3fe USB: cdc-acm: fix TIOCMIWAIT) Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove interrupt throttling) Merging usb-serial-fixes/usb-linus (9bfef729a3d1 USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu) Merging staging.current/staging-linus (68fae2f3df45 staging: nvec: remove managed resource from PS2 driver) Merging char-misc.current/char-misc-linus (b13d14339baa ppdev: fix double-free of pp->pdev->name) Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup Focaltech code) Merging crypto-current/master (6d4952d9d9d4 hwrng: core - Don't use a stack buffer in add_early_randomness()) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merging rr-fixes/fixes (8244062ef1e5 modules
Re: [PATCH v2 00/12] mm: page migration enhancement for thp
On 11/10/2016 07:31 PM, Zi Yan wrote: > On 9 Nov 2016, at 18:52, Naoya Horiguchi wrote: > >> Hi Anshuman, >> >> On Wed, Nov 09, 2016 at 04:03:04PM +0530, Anshuman Khandual wrote: >>> On 11/08/2016 05:01 AM, Naoya Horiguchi wrote: Hi everyone, I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27 with feedbacks for ver.1. General description (no change since ver.1) === This patchset enhances page migration functionality to handle thp migration for various page migration's callers: - mbind(2) - move_pages(2) - migrate_pages(2) - cgroup/cpuset migration - memory hotremove - soft offline The main benefit is that we can avoid unnecessary thp splits, which helps us avoid performance decrease when your applications handles NUMA optimization on their own. The implementation is similar to that of normal page migration, the key point is that we modify a pmd to a pmd migration entry in swap-entry like format. >>> >>> Will it be better to have new THP_MIGRATE_SUCCESS and THP_MIGRATE_FAIL >>> VM events to capture how many times the migration worked without first >>> splitting the huge page and how many time it did not work ? >> >> Thank you for the suggestion. >> I think that's helpful, so will try it in next version. >> >>> Also do you >>> have a test case which demonstrates this THP migration and kind of shows >>> its better than the present split and move method ? >> >> I don't have test cases which compare thp migration and split-then-migration >> with some numbers. Maybe measuring/comparing the overhead of migration is >> a good start point, although I think the real benefit of thp migration comes >> from workload "after migration" by avoiding thp split. > > Migrating 4KB pages has much lower (~1/3) throughput than 2MB pages. I assume the 2MB throughput you mentioned is with this THP migration feature enabled. > > What I get is that on average it takes 1987.38 us to migrate 512 4KB pages and >658.54 us to migrate 1 2MB page. > > I did the test in a two-socket Intel Xeon E5-2640v4 box. I used > migrate_pages() > system call to migrate pages. MADV_NOHUGEPAGE and MADV_HUGEPAGE are used to > make 4KB and 2MB pages and each page’s flags are checked to make sure the page > size is 4KB or 2MB THP. > > There is no split page. But the page migration time already tells the story. Right. Just wondering if we can add a test case which measures just this migration time improvement by avoiding the split not the TLB based improvement which the workload will receive as an addition.
Re: [PATCH 2/3] vhost: better detection of available buffers
On Fri, Nov 11, 2016 at 10:18:37AM +0800, Jason Wang wrote: > > > On 2016年11月10日 03:57, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 03:38:32PM +0800, Jason Wang wrote: > > > We should use vq->last_avail_idx instead of vq->avail_idx in the > > > checking of vhost_vq_avail_empty() since latter is the cached avail > > > index from guest but we want to know if there's pending available > > > buffers in the virtqueue. > > > > > > Signed-off-by: Jason Wang > > I'm not sure why is this patch here. Is it related to > > batching somehow? > > Yes, we need to know whether or not there's still buffers left in the > virtqueue, so need to check last_avail_idx. Otherwise, we're checking if > guest has submitted new buffers. > > > > > > > > --- > > > drivers/vhost/vhost.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > > > index c6f2d89..fdf4cdf 100644 > > > --- a/drivers/vhost/vhost.c > > > +++ b/drivers/vhost/vhost.c > > > @@ -2230,7 +2230,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, > > > struct vhost_virtqueue *vq) > > > if (r) > > > return false; > > > - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx; > > > + return vhost16_to_cpu(vq, avail_idx) == vq->last_avail_idx; > > > } > > > EXPORT_SYMBOL_GPL(vhost_vq_avail_empty); > > That might be OK for TX but it's probably wrong for RX > > where the fact that used != avail does not mean > > we have enough space to store the packet. > > Right, but it's no harm since it was just a hint, handle_rx() can handle > this situation. Means busy polling will cause useless load on the CPU though. > > > > Maybe we should just rename this to vhost_vq_avail_unchanged > > to clarify usage. > > > > Ok. > > > > -- > > > 2.7.4
[no subject]
Hi Steven, On 21 October 2016 at 20:13, Chunyan Zhang wrote: > On 18 October 2016 at 23:44, Steven Rostedt wrote: >> On Tue, 18 Oct 2016 16:08:58 +0800 >> Chunyan Zhang wrote: >> >>> Currently Function traces can be only exported to ring buffer, this >>> patch added trace_export concept which can process traces and export >>> them to a registered destination as an addition to the current only >>> one output of Ftrace - i.e. ring buffer. >>> >>> In this way, if we want Function traces to be sent to other destination >>> rather than ring buffer only, we just need to register a new trace_export >>> and implement its own .write() function for writing traces to storage. >>> >>> With this patch, only Function trace (trace type is TRACE_FN) >>> is supported. >> >> This is getting better, but I still have some nits. >> > > Thanks. > >>> >>> Signed-off-by: Chunyan Zhang >>> --- >>> include/linux/trace.h | 28 +++ >>> kernel/trace/trace.c | 132 >>> +- >>> 2 files changed, 159 insertions(+), 1 deletion(-) >>> create mode 100644 include/linux/trace.h >>> >>> diff --git a/include/linux/trace.h b/include/linux/trace.h >>> new file mode 100644 >>> index 000..eb1c5b8 >>> --- /dev/null >>> +++ b/include/linux/trace.h >>> @@ -0,0 +1,28 @@ >>> +#ifndef _LINUX_TRACE_H >>> +#define _LINUX_TRACE_H >>> + >>> +#ifdef CONFIG_TRACING >>> +/* >>> + * The trace export - an export of Ftrace output. The trace_export >>> + * can process traces and export them to a registered destination as >>> + * an addition to the current only output of Ftrace - i.e. ring buffer. >>> + * >>> + * If you want traces to be sent to some other place rather than ring >>> + * buffer only, just need to register a new trace_export and implement >>> + * its own .write() function for writing traces to the storage. >>> + * >>> + * next - pointer to the next trace_export >>> + * write - copy traces which have been delt with ->commit() to >>> + * the destination >>> + */ >>> +struct trace_export { >>> + struct trace_export __rcu *next; >>> + void (*write)(const char *, unsigned int); >> >> Why const char*? Why not const void *? This will never be a string. >> > > Will revise this. > >> >>> +}; >>> + >>> +int register_ftrace_export(struct trace_export *export); >>> +int unregister_ftrace_export(struct trace_export *export); >>> + >>> +#endif /* CONFIG_TRACING */ >>> + >>> +#endif /* _LINUX_TRACE_H */ >>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c >>> index 8696ce6..db94ec1 100644 >>> --- a/kernel/trace/trace.c >>> +++ b/kernel/trace/trace.c >>> @@ -40,6 +40,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> >>> #include "trace.h" >>> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct >>> trace_array *tr, >>> ftrace_trace_userstack(buffer, flags, pc); >>> } >>> >>> +static void >>> +trace_process_export(struct trace_export *export, >>> +struct ring_buffer_event *event) >>> +{ >>> + struct trace_entry *entry; >>> + unsigned int size = 0; >>> + >>> + entry = ring_buffer_event_data(event); >>> + >>> + size = ring_buffer_event_length(event); >>> + >>> + if (export->write) >>> + export->write((char *)entry, size); >> >> Is there ever going to be a time where export->write wont be set? > > There hasn't been since only one trace_export (i.e. stm_ftrace) was > added in this patch-set , I just wanted to make sure the write() has > been set before registering trace_export like what I added in 2/3 of > this series. > >> >> And if there is, this can be racy. As in >> >> >> CPU 0: CPU 1: >> -- -- >> if (export->write) >> >> export->write = NULL; > > Is there going to be this kind of use case? Why some one needs to > change export->write() rather than register a new trace_export? > > I probably haven't understood your point thoroughly, please correct me > if my guess was wrong. > Any further comments? :) Thanks, Chunyan > > Thanks for the review, > Chunyan > >> >> export->write(entry, size); >> >> BOOM! >> >> >> -- Steve >> >>> +} >>> + >>> +static DEFINE_MUTEX(ftrace_export_lock); >>> + >>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly; >>> + >>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled); >>> + >>> +static inline void ftrace_exports_enable(void) >>> +{ >>> + static_branch_enable(&ftrace_exports_enabled); >>> +} >>> + >>> +static inline void ftrace_exports_disable(void) >>> +{ >>> + static_branch_disable(&ftrace_exports_enabled); >>> +} >>> + >>> +void ftrace_exports(struct ring_buffer_event *event) >>> +{ >>> + struct trace_export *export; >>> + >>> + preempt_disable_notrace(); >>> + >>> + export = rcu_dereference_raw_notrace(ftrace_exports_list); >>> + while (export
Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
On Fri, 11 Nov 2016 11:22:43 +0800 Jisheng Zhang wrote: > Hi Rob, Ziji, > > On Thu, 10 Nov 2016 19:44:19 +0800 Ziji Hu wrote: > > > Hi Rob, > > > > On 2016/11/10 2:24, Rob Herring wrote: > > > On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote: > > >> From: Ziji Hu > > >> > > >> Marvell Xenon SDHC can support eMMC/SD/SDIO. > > >> Add Xenon-specific properties. > > >> Also add properties for Xenon PHY setting. > > >> > > >> Signed-off-by: Hu Ziji > > >> Signed-off-by: Gregory CLEMENT > > >> --- > > >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 > > >> +++- > > >> MAINTAINERS | 1 +- > > >> 2 files changed, 162 insertions(+), 0 deletions(-) > > >> create mode 100644 > > >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > > >> > > >> diff --git > > >> a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > > >> b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > > >> new file mode 100644 > > >> index ..0d2d139494d3 > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > > >> @@ -0,0 +1,161 @@ > > >> +Marvell's Xenon SDHCI Controller device tree bindings > > >> +This file documents differences between the core mmc properties > > >> +described by mmc.txt and the properties used by the Xenon > > >> implementation. > > >> + > > >> +A single Xenon IP can support multiple slots. > > >> +Each slot acts as an independent SDHC. It owns independent resources, > > >> such > > >> +as register sets clock and PHY. > > >> +Each slot should have an independent device tree node. > > >> + > > >> +Required Properties: > > >> +- compatible: should be one of the following > > >> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC. > > >> + Must provide a second register area and marvell,pad-type. > > >> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than > > >> + Armada-3700. > > > > > > Need SoC specific compatible strings. > > > > > > > Xenon SDHC is a common IP for all Marvell SOCs. > > It is difficult to use a single SOC specific compatible to represent > > Xenon SDHC. > > There will be so many SOC compatible strings in list if each specific > > SOC owns a compatible. > > Actually only few SOCs require special properties. > > Any suggestion please? > > > > >> + > > >> +- clocks: > > >> + Array of clocks required for SDHCI. > > >> + Requires at least one for Xenon IP core. > > >> + Some SOCs require additional clock for AXI bus. > > >> + > > >> +- clock-names: > > >> + Array of names corresponding to clocks property. > > >> + The input clock for Xenon IP core should be named as "core". > > >> + The optional AXI clock should be named as "axi". > > > > > > When is AXI clock optional? This should be required for ?? compatible > > > strings. > > > > > It is required on some SOCs. > > I will double check if a suitable compatible string can be determined > > for those SOCs. > > Besides the core clk, berlin SoCs have one AXI clock. Usually, we have two > solutions: > > solA: as current patch does, take "marvell,xenon-sdhci" as compatible string > and make the AXI clock property optional. Usually for berlin SoCs, we don't > need > special properties. Personally, I prefer solA: use the IP name as compatible string. This is IP specific rather than SoC specific. The HW itself supports two clks Thanks, Jisheng > > PS: this solution is also what sdhci-pxav3.c takes > > solB: As Rob said, add extra SoC compatible strings, so we'll have > something like: > > static const struct of_device_id sdhci_xenon_of_match[] = { > { .compatible = "marvell,armada-3700-sdhci", }, > { .compatible = "marvell,berlin4ct-sdhci", }, > ... > { .compatible = "marvell,berlinxxx-mmc", }, > } > > then we take care the AXI clk for berlin SoCs in the code. > > > Which solution do you prefer? > > Thanks, > Jisheng
Re: [GIT PULL] SCSI fixes for 4.9-rc3
On 05.11.2016 14:29, James Bottomley wrote: ... > Kashyap Desai (1): > scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) > devices > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > b/drivers/scsi/megaraid/megaraid_sas_base.c > index 9ff57de..d8b1fbd 100644 > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > @@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost, struct > scsi_cmnd *scmd) > goto out_done; > } > > - switch (scmd->cmnd[0]) { > - case SYNCHRONIZE_CACHE: > - /* > - * FW takes care of flush cache on its own > - * No need to send it down > - */ > + /* > + * FW takes care of flush cache on its own for Virtual Disk. > + * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to > FW. > + */ > + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) { > scmd->result = DID_OK << 16; > goto out_done; > - default: > - break; > } > > return instance->instancet->build_and_issue_cmd(instance, scmd); This patch breaks my box.. I'm not able to boot it anymore. It seems with this patch I have /dev/sda[a-z] to /dev/sdz[a-z] ?!? I'm not sure how to get an log since dracut times out and I'm dropped , after a very long time of probing 'ghost devices', in a emercency shell, journalctl doesn't work also.. After reverting this one I can boot normal. Box is a FUJITSU PRIMERGY TX200 S5.. This is from an working kernel.. [5.119371] megaraid_sas :01:00.0: FW now in Ready state [5.119418] megaraid_sas :01:00.0: firmware supports msix: (0) [5.119420] megaraid_sas :01:00.0: current msix/online cpus : (1/16) [5.119422] megaraid_sas :01:00.0: RDPQ mode : (disabled) [5.123100] ehci-pci :00:1a.7: cache line size of 32 is not supported [5.123113] ehci-pci :00:1a.7: irq 18, io mem 0xb002 ... [5.208063] megaraid_sas :01:00.0: controller type : MR(256MB) [5.208065] megaraid_sas :01:00.0: Online Controller Reset(OCR) : Enabled [5.208067] megaraid_sas :01:00.0: Secure JBOD support : No [5.208070] megaraid_sas :01:00.0: megasas_init_mfi: fw_support_ieee=0 [5.208073] megaraid_sas :01:00.0: INIT adapter done [5.208075] megaraid_sas :01:00.0: Jbod map is not supported megasas_setup_jbod_map 4967 [5.230163] megaraid_sas :01:00.0: MR_DCMD_PD_LIST_QUERY failed/not supported by firmware [5.252080] megaraid_sas :01:00.0: DCMD not supported by firmware - megasas_ld_list_query 4369 [5.274086] megaraid_sas :01:00.0: pci id: (0x1000)/(0x0060)/(0x1734)/(0x10f9) [5.274089] megaraid_sas :01:00.0: unevenspan support: no [5.274090] megaraid_sas :01:00.0: firmware crash dump : no [5.274092] megaraid_sas :01:00.0: jbod sync map : no [5.274094] scsi host0: Avago SAS based MegaRAID driver [5.280022] scsi 0:0:6:0: Direct-Access ATA WDC WD5002ABYS-5 3B06 PQ: 0 ANSI: 5 [5.282153] scsi 0:0:7:0: Direct-Access ATA WDC WD5002ABYS-5 3B06 PQ: 0 ANSI: 5 [5.285180] scsi 0:0:10:0: Direct-Access ATA ST500NM0011 FTM6 PQ: 0 ANSI: 5 [5.369885] scsi 0:2:0:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5 .. Please let me know if you need more infos and/or want me to test patches. Best Regards, Gabriel C
Re: [PATCH 1/3] tuntap: rx batching
On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote: > > > On 2016年11月10日 00:38, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: > > > Backlog were used for tuntap rx, but it can only process 1 packet at > > > one time since it was scheduled during sendmsg() synchronously in > > > process context. This lead bad cache utilization so this patch tries > > > to do some batching before call rx NAPI. This is done through: > > > > > > - accept MSG_MORE as a hint from sendmsg() caller, if it was set, > > >batch the packet temporarily in a linked list and submit them all > > >once MSG_MORE were cleared. > > > - implement a tuntap specific NAPI handler for processing this kind of > > >possible batching. (This could be done by extending backlog to > > >support skb like, but using a tun specific one looks cleaner and > > >easier for future extension). > > > > > > Signed-off-by: Jason Wang > > So why do we need an extra queue? > > The idea was borrowed from backlog to allow some kind of bulking and avoid > spinlock on each dequeuing. > > > This is not what hardware devices do. > > How about adding the packet to queue unconditionally, deferring > > signalling until we get sendmsg without MSG_MORE? > > Then you need touch spinlock when dequeuing each packet. It runs on the same CPU, right? Otherwise we should use skb_array... > > > > > > > --- > > > drivers/net/tun.c | 71 > > > ++- > > > 1 file changed, 65 insertions(+), 6 deletions(-) > > > > > [...] > > > > rxhash = skb_get_hash(skb); > > > - netif_rx_ni(skb); > > > + skb_queue_tail(&tfile->socket.sk->sk_write_queue, skb); > > > + > > > + if (!more) { > > > + local_bh_disable(); > > > + napi_schedule(&tfile->napi); > > > + local_bh_enable(); > > Why do we need to disable bh here? I thought napi_schedule can > > be called from any context. > > Yes, it's unnecessary. Will remove. > > Thanks
Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
> On Nov 9, 2016, at 9:07 PM, Vignesh R wrote: > > Hi, > > On Thursday 10 November 2016 05:23 AM, John Syne wrote: >> OK, then back to my original question. Given that these DT properties are >> supported in the driver >> > > Below properties are supported by only by ti_am3335x_adc driver and not > ti_am335x_tsc driver. As author of this patch pointed out in another > reply, there is no need to change step-opendelay for tsc. AFAIK, I don't > see a use case where these values needs to be tweaked for tsc channels, > therefore it does not make sense to be DT properties. Yeah, the confusion was mine because the author of this patch series was proposing to hard code these settings while DT properties already existed in the ti_am335x_adc driver. I use the ADC for sensor measurement and do not use the touchscreen features. I already pointed out where these DT parameters should be added by referencing how this was done in one of the BBB DT overlay files [1]. I am just proposing the same is done as a default in the AM33xx.dtsi and AM4372.dtsi files. Here is what I was proposing. Granted, the adc-channels should be restricted to the subset of channels not used by tsc, but you get the idea. tscadc: tscadc@44e0d000 { compatible = "ti,am3359-tscadc"; reg = <0x44e0d000 0x1000>; interrupt-parent = <&intc>; interrupts = <16>; ti,hwmods = "adc_tsc"; status = "disabled"; dmas = <&edma 53 0>, <&edma 57 0>; dma-names = "fifo0", "fifo1”; tsc { compatible = "ti,am3359-tsc"; }; am335x_adc: adc { #io-channel-cells = <1>; ti,adc-channels = <0 1 2 3 4 5 6>; ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>; ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>; ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>; compatible = "ti,am3359-adc"; }; }; [1]https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts Regards, John > >> shouldn’t the following be added to am33xx.dtsi and am4372.dtsi? > > Its totally upto board dts files to allocate channels for tsc and adc. > So, how could these be added to dtsi files? > >> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>; >> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>; >> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>; >> >> Regards, >> John >>> >>> -- >>> Regards >>> Vignesh >> > > -- > Regards > Vignesh
[PATCH 1/2] mfd: axp20x: Add address extension registers for AXP806 regmap
The AXP806 supports either master/standalone or slave mode. Slave mode allows sharing the serial bus, even with multiple AXP806 which all have the same hardware address. This is done with extra "serial interface address extension", or AXP806_BUS_ADDR_EXT, and "register address extension", or AXP806_REG_ADDR_EXT, registers. The former is read-only, with 1 bit customizable at the factory, and 1 bit depending on the state of an external pin. The latter is writable. Only when the these device addressing bits (in the upper 4 bits of the registers) match, will the device respond to operations on its other registers. Add these 2 registers to the regmap so we can access them. Signed-off-by: Chen-Yu Tsai --- drivers/mfd/axp20x.c | 3 ++- include/linux/mfd/axp20x.h | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index ba130be32e61..cdaeb34a9a38 100644 --- a/drivers/mfd/axp20x.c +++ b/drivers/mfd/axp20x.c @@ -135,6 +135,7 @@ static const struct regmap_range axp806_writeable_ranges[] = { regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL), regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN), regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE), + regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT), }; static const struct regmap_range axp806_volatile_ranges[] = { @@ -305,7 +306,7 @@ static const struct regmap_config axp806_regmap_config = { .val_bits = 8, .wr_table = &axp806_writeable_table, .volatile_table = &axp806_volatile_table, - .max_register = AXP806_VREF_TEMP_WARN_L, + .max_register = AXP806_REG_ADDR_EXT, .cache_type = REGCACHE_RBTREE, }; diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h index fec597fb34cb..7e85ececcedf 100644 --- a/include/linux/mfd/axp20x.h +++ b/include/linux/mfd/axp20x.h @@ -115,6 +115,8 @@ enum { #define AXP806_CLDO2_V_CTRL0x25 #define AXP806_CLDO3_V_CTRL0x26 #define AXP806_VREF_TEMP_WARN_L0xf3 +#define AXP806_BUS_ADDR_EXT0xfe +#define AXP806_REG_ADDR_EXT0xff /* Interrupt */ #define AXP152_IRQ1_EN 0x40 -- 2.10.2
[PATCH 0/2] mfd: axp20x: Fix AXP806 access errors on cold boot
Hi Lee, Recently we've added full SPL support for A80 to mainline U-boot. This means we no longer depend on Allwinner's bootloader. It also means that some of system configuration the bootloader set up no longer applies. The bootloader was correctly configuring the multi-device addressing support in the AXP806 PMIC. If the PMIC is not correctly addressed, it just ignores all reads and writes to the other registers. As mainline U-boot does not support the AXP806, and since we can't always count on a good bootloader, we should re-configure this in the kernel regardless. Patch 1 adds the registers for the multi-device addressing scheme to the AXP806 regmap. Patch 2 configures the register at probe time, and reinitializes the regmap cache. Since support for this PMIC was just added in 4.9-rc1, I hope you can merge these 2 patches as fixes for 4.9. Thank you! Regards ChenYu Chen-Yu Tsai (2): mfd: axp20x: Add address extension registers for AXP806 regmap mfd: axp20x: Fix AXP806 access errors on cold boot drivers/mfd/axp20x.c | 38 +- include/linux/mfd/axp20x.h | 2 ++ 2 files changed, 39 insertions(+), 1 deletion(-) -- 2.10.2
[PATCH 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
The AXP806 supports either master/standalone or slave mode. Slave mode allows sharing the serial bus, even with multiple AXP806 which all have the same hardware address. This is done with extra "serial interface address extension", or AXP806_BUS_ADDR_EXT, and "register address extension", or AXP806_REG_ADDR_EXT, registers. The former is read-only, with 1 bit customizable at the factory, and 1 bit depending on the state of an external pin. The latter is writable. Only when the these device addressing bits (in the upper 4 bits of the registers) match, will the device respond to operations on its other registers. The AXP806_REG_ADDR_EXT was previously configured by Allwinner's bootloader. Work on U-boot SPL support now allows us to switch to mainline U-boot, which doesn't do this for us. There might be other bare minimum bootloaders out there which don't to this either. It's best to handle this in the kernel. This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we know to be the proper value for a standard AXP806 in slave mode. Afterwards it will reinitialize the regmap cache, to purge any invalid stale values. Signed-off-by: Chen-Yu Tsai --- drivers/mfd/axp20x.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index cdaeb34a9a38..2f5d46f28511 100644 --- a/drivers/mfd/axp20x.c +++ b/drivers/mfd/axp20x.c @@ -829,6 +829,41 @@ int axp20x_device_probe(struct axp20x_dev *axp20x) { int ret; + /* +* The AXP806 supports either master/standalone or slave mode. +* Slave mode allows sharing the serial bus, even with multiple +* AXP806 which all have the same hardware address. +* +* This is done with extra "serial interface address extension", +* or AXP806_BUS_ADDR_EXT, and "register address extension", or +* AXP806_REG_ADDR_EXT, registers. The former is read-only, with +* 1 bit customizable at the factory, and 1 bit depending on the +* state of an external pin. The latter is writable. Only when +* the these device addressing bits (in the upper 4 bits of the +* registers) match, will the device respond to operations on its +* other registers. +* +* Since we only support an AXP806 chained to an AXP809 in slave +* mode, and there isn't any existing hardware which uses AXP806 +* in master mode, or has 2 AXP806s in the same system, we can +* just program the register address extension to the slave mode +* address. +*/ + if (axp20x->variant == AXP806_ID) { + /* Write to the register address extension register */ + regmap_write(axp20x->regmap, AXP806_REG_ADDR_EXT, 0x10); + + /* Make sure the write hits the device */ + regcache_sync_region(axp20x->regmap, AXP806_REG_ADDR_EXT, +AXP806_REG_ADDR_EXT); + + /* +* Reinitialize the regmap cache in case the device didn't +* properly respond to our reads before. +*/ + regmap_reinit_cache(axp20x->regmap, axp20x->regmap_cfg); + } + ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq, IRQF_ONESHOT | IRQF_SHARED, -1, axp20x->regmap_irq_chip, -- 2.10.2
Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
Hi Rob, Ziji, On Thu, 10 Nov 2016 19:44:19 +0800 Ziji Hu wrote: > Hi Rob, > > On 2016/11/10 2:24, Rob Herring wrote: > > On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote: > >> From: Ziji Hu > >> > >> Marvell Xenon SDHC can support eMMC/SD/SDIO. > >> Add Xenon-specific properties. > >> Also add properties for Xenon PHY setting. > >> > >> Signed-off-by: Hu Ziji > >> Signed-off-by: Gregory CLEMENT > >> --- > >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 > >> +++- > >> MAINTAINERS | 1 +- > >> 2 files changed, 162 insertions(+), 0 deletions(-) > >> create mode 100644 > >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > >> > >> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > >> b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > >> new file mode 100644 > >> index ..0d2d139494d3 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt > >> @@ -0,0 +1,161 @@ > >> +Marvell's Xenon SDHCI Controller device tree bindings > >> +This file documents differences between the core mmc properties > >> +described by mmc.txt and the properties used by the Xenon implementation. > >> + > >> +A single Xenon IP can support multiple slots. > >> +Each slot acts as an independent SDHC. It owns independent resources, such > >> +as register sets clock and PHY. > >> +Each slot should have an independent device tree node. > >> + > >> +Required Properties: > >> +- compatible: should be one of the following > >> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC. > >> + Must provide a second register area and marvell,pad-type. > >> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than > >> + Armada-3700. > > > > Need SoC specific compatible strings. > > > > Xenon SDHC is a common IP for all Marvell SOCs. > It is difficult to use a single SOC specific compatible to represent > Xenon SDHC. > There will be so many SOC compatible strings in list if each specific > SOC owns a compatible. > Actually only few SOCs require special properties. > Any suggestion please? > > >> + > >> +- clocks: > >> + Array of clocks required for SDHCI. > >> + Requires at least one for Xenon IP core. > >> + Some SOCs require additional clock for AXI bus. > >> + > >> +- clock-names: > >> + Array of names corresponding to clocks property. > >> + The input clock for Xenon IP core should be named as "core". > >> + The optional AXI clock should be named as "axi". > > > > When is AXI clock optional? This should be required for ?? compatible > > strings. > > > It is required on some SOCs. > I will double check if a suitable compatible string can be determined > for those SOCs. Besides the core clk, berlin SoCs have one AXI clock. Usually, we have two solutions: solA: as current patch does, take "marvell,xenon-sdhci" as compatible string and make the AXI clock property optional. Usually for berlin SoCs, we don't need special properties. PS: this solution is also what sdhci-pxav3.c takes solB: As Rob said, add extra SoC compatible strings, so we'll have something like: static const struct of_device_id sdhci_xenon_of_match[] = { { .compatible = "marvell,armada-3700-sdhci", }, { .compatible = "marvell,berlin4ct-sdhci", }, ... { .compatible = "marvell,berlinxxx-mmc", }, } then we take care the AXI clk for berlin SoCs in the code. Which solution do you prefer? Thanks, Jisheng
Re: [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
Hi Heiko, 在 2016年11月10日 17:21, Heiko Stübner 写道: Am Donnerstag, 10. November 2016, 10:54:49 schrieb wlf: Hi Doug, 在 2016年11月10日 04:54, Doug Anderson 写道: Hi, On Mon, Nov 7, 2016 at 5:00 AM, William Wu wrote: We found that the system crashed due to 480MHz output clock of USB2 PHY was unstable after clock had been enabled by gpu module. Theoretically, 1 millisecond is a critical value for 480MHz output clock stable time, so we try to change the delay time to 1.2 millisecond to avoid this issue. Signed-off-by: William Wu --- drivers/phy/phy-rockchip-inno-usb2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c index ecfd7d1..8f2d2b6 100644 --- a/drivers/phy/phy-rockchip-inno-usb2.c +++ b/drivers/phy/phy-rockchip-inno-usb2.c @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)>> return ret; /* waitting for the clk become stable */ - mdelay(1); + udelay(1200); Several people who have seen this patch have expressed concern that a 1.2 ms delay is pretty long for something that's supposed to be "atomic" like a clk_enable(). Consider that someone might call clk_enable() while interrupts are disabled and that a 1.2 ms interrupt latency is not so great. It seems like this clock should be moved to be enabled in "prepare" and the "enable" should be a no-op. This is a functionality change, but I don't think there are any real users for this clock at the moment so it should be fine. (of course, the 1 ms latency that existed before this patch was still pretty bad, but ...) Thanks a lot for your suggestion. I agree with you. clk_enable() will call spin_lock_irqsave() to disable interrupt, and we add more than 1ms in clk_enable may cause big latency. And according to clk_prepare() description: In a simple case, clk_prepare can be used instead of clk_enable to ungate a clk if the operation may sleep. One example is a clk which is accessed over I2c. So maybe we can remove the clock to clk_prepare. Hi Heiko, Frank, What do you think of it? moving to clk_prepare sounds sensible. That way you can switch from delay to sleep functions as well. Thanks very much. I will try to update a new patch. Best regards, Wulf Heiko
Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC
On Thu, Nov 10, 2016 at 3:56 PM, Kees Cook wrote: > On Thu, Nov 10, 2016 at 12:37 PM, Peter Zijlstra wrote: >> On Thu, Nov 10, 2016 at 10:24:35PM +0200, Elena Reshetova wrote: >>> This series brings the PaX/Grsecurity PAX_REFCOUNT >>> feature support to the upstream kernel. All credit for the >>> feature goes to the feature authors. >>> >>> The name of the upstream feature is HARDENED_ATOMIC >>> and it is configured using CONFIG_HARDENED_ATOMIC and >>> HAVE_ARCH_HARDENED_ATOMIC. >>> >>> This series only adds x86 support; other architectures are expected >>> to add similar support gradually. >>> >>> More information about the feature can be found in the following >>> commit messages. >> >> No, this should be here. As it stands this is completely without >> content. >> >> In any case, NAK on this approach. Its the wrong way around. >> >> _IF_ you want to do a non-wrapping variant, it must not be the default. > > Unfortunately, we have to do it this way because there are so many > misuses of atomic_t, and they just keep appearing. We can't do opt-in > protections for the kernel -- we need to protect atomic_t and opt OUT > of the protection where it's not needed. > > We must change the kernel culture to making things secure-by-default. > Without this, we're wasting our time and continuing to leave people > vulnerable every time some new driver lands that refcounts with > atomic_t. Since education is proven to not work, we have to harden the > _infrastructure_ of the kernel, of which atomic_t is a part. > >> Since you need to audit every single atomic_t user in the kernel anyway, >> it doesn't matter. But changing atomic_t to non-wrap by default is not >> robust, if you forgot one, you can then trivially dos the kernel. > > Correct: everything must be audited in either case. However, making a > mistake using opt-out means a DoS. Making a mistake using opt-in means > an exploitable kernel escalation. We must have the courage to > recognize this distinction. Right now, every refcount mistake is an > exploitable kernel flaw. Reducing this to a DoS is a giant > improvement. > Agreed. And once this DoS happens only once and gets reported, it's solved forever. What about the approach of changing the behavior or the overflow response mechanism (hardened_atomic_overflow()) to only log the overflow, rather than killing the offending process? This way, it could bake in distros for a while and all necessary conversions to atomic_wrap_t can occur. Then, we can turn back on the behavior of killing the offending process. While behavior after an overflow occurs is undefined, this was happening before anyway. >> That said, I still don't much like this. >> >> I would much rather you make kref useful and use that. It still means >> you get to audit all refcounts in the kernel, but hey, you had to do >> that anyway. > > This has already been suggested in the past, and suffers from the same > opt-in problem. I'll let Greg comment on it, though, as he's agreed > with going opt-out in the past when reviewing this work. > > -Kees > > -- > Kees Cook > Nexus Security
Re: [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman : > On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote: >> >> sdhci_alloc_host() returns an error pointer when it fails. >> but mmc_alloc_host() cannot. >> >> This series allow to propagate a proper error code >> when host-allocation fails. > > Why? What can we really do about the error except give up? Why does > having a explicit error value make any difference to the caller, they > can't do anything different, right? The error code is shown in the console, like probe of 5a00.sdhc failed with error -12 The proper error code will give a clue why the driver failed to probe. > I suggest just leaving it as-is, it's simple, and you don't have to mess > with PTR_ERR() anywhere. Why? Most of driver just give up probing for any error, but we still do ERR_PTR()/PTR_ERR() here and there. I think this patch is the same pattern. If a function returns NULL on failure, we need to think about "what is the most common failure case". Currently, MMC drivers assume -ENOMEM is the best fit for mmc_alloc_host(), but the assumption is fragile. Already, mmc_alloc_host() calls a function that returns not only -ENOMEM, but also -ENOSPC. In the future, some other failure cases might be added to mmc_alloc_host(). Once we decide the API returns an error pointer, drivers just propagate the return value from the API. This is much more stable implementation. -- Best Regards Masahiro Yamada
Re: [PATCH v2 03/12] mm: thp: introduce separate TTU flag for thp freezing
On 11/10/2016 02:39 PM, Naoya Horiguchi wrote: > On Thu, Nov 10, 2016 at 02:01:56PM +0530, Anshuman Khandual wrote: >> > On 11/08/2016 05:01 AM, Naoya Horiguchi wrote: >>> > > TTU_MIGRATION is used to convert pte into migration entry until thp >>> > > split >>> > > completes. This behavior conflicts with thp migration added later >>> > > patches, >> > >> > Hmm, could you please explain why it conflicts with the PMD based >> > migration without split ? Why TTU_MIGRATION cannot be used to >> > freeze/hold on the PMD while it's being migrated ? > try_to_unmap() is used both for thp split (via freeze_page()) and page > migration (via __unmap_and_move()). In freeze_page(), ttu_flag given for > head page is like below (assuming anonymous thp): > > (TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS | TTU_RMAP_LOCKED | \ > TTU_MIGRATION | TTU_SPLIT_HUGE_PMD) Right. > > and ttu_flag given for tail pages is: > > (TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS | TTU_RMAP_LOCKED | \ > TTU_MIGRATION) Right. > > __unmap_and_move() calls try_to_unmap() with ttu_flag: > > (TTU_MIGRATION | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS) > > Now I'm trying to insert a branch for thp migration at the top of > try_to_unmap_one() like below > > > static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma, >unsigned long address, void *arg) > { > ... > if (flags & TTU_MIGRATION) { > if (!PageHuge(page) && PageTransCompound(page)) { > set_pmd_migration_entry(page, vma, address); > goto out; > } > } > > , so try_to_unmap() for tail pages called by thp split can go into thp > migration code path (which converts *pmd* into migration entry), while > the expectation is to freeze thp (which converts *pte* into migration entry.) Got it. > > I detected this failure as a "bad page state" error in a testcase where > split_huge_page() is called from queue_pages_pte_range(). > > Anyway, I'll add this explanation into the patch description in the next post. Sure, thanks for the explanation.
[PATCH] regulator: axp20x: Fix axp809 ldo_io registration error on cold boot
The maximum supported voltage for ldo_io# is 3.3V, but on cold boot the selector comes up at 0x1f, which maps to 3.8V. This was previously corrected by Allwinner's U-boot, which set all regulators on the PMICs to some pre-configured voltage. With recent progress in U-boot SPL support, this is no longer the case. In any case we should handle this quirk in the kernel driver as well. This invalid setting causes _regulator_get_voltage() to fail with -EINVAL which causes regulator registration to fail when constrains are used: [1.054181] vcc-pg: failed to get the current voltage(-22) [1.059670] axp20x-regulator axp20x-regulator.0: Failed to register ldo_io0 [1.069749] axp20x-regulator: probe of axp20x-regulator.0 failed with error -22 This commits makes the axp20x regulator driver accept the 0x1f register value, fixing this. The datasheet does not guarantee reliable operation above 3.3V, so on boards where this regulator is used the regulator-max-microvolt setting must be 3.3V or less. This is essentially the same as the commit f40d4896bf32 ("regulator: axp20x: Fix axp22x ldo_io registration error on cold boot") for AXP22x PMICs. Fixes: a51f9f4622a3 ("regulator: axp20x: support AXP809 variant") Signed-off-by: Chen-Yu Tsai --- drivers/regulator/axp20x-regulator.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index 54382ef902c6..e6a512ebeae2 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -337,10 +337,18 @@ static const struct regulator_desc axp809_regulators[] = { AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)), AXP_DESC(AXP809, ELDO3, "eldo3", "eldoin", 700, 3300, 100, AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)), - AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100, + /* +* Note the datasheet only guarantees reliable operation up to +* 3.3V, this needs to be enforced via dts provided constraints +*/ + AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3800, 100, AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07, AXP22X_IO_ENABLED, AXP22X_IO_DISABLED), - AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100, + /* +* Note the datasheet only guarantees reliable operation up to +* 3.3V, this needs to be enforced via dts provided constraints +*/ + AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3800, 100, AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07, AXP22X_IO_ENABLED, AXP22X_IO_DISABLED), AXP_DESC_FIXED(AXP809, RTC_LDO, "rtc_ldo", "ips", 1800), -- 2.10.2
Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
On 10-11-16, 14:51, Stephen Boyd wrote: > On 11/10, Viresh Kumar wrote: > > On 10-11-16, 16:36, Mark Brown wrote: > > > On Thu, Nov 10, 2016 at 09:34:40AM +0530, Viresh Kumar wrote: > > > > On 09-11-16, 14:58, Mark Brown wrote: > > > > > On Wed, Oct 26, 2016 at 12:02:56PM +0530, Viresh Kumar wrote: > > > > > > > > > + Entries for multiple regulators shall be provided in the same > > > > > > field separated > > > > > > + by angular brackets <>. The OPP binding doesn't provide any > > > > > > provisions to > > > > > > + relate the values to their power supplies or the order in which > > > > > > the supplies > > > > > > + need to be configured. > > > > > > > > I don't understand how this works. If we have an unordered list of > > > > > values to set for regulators how will we make sense of them? > > > > > > > The platform driver is responsible to identify the order and pass it on > > > > to the > > > > OPP core. And the platform driver needs to have that hard coded. > > > > > > That *really* should be in the binding. > > > > Okay, how do you suggest doing that? Will a property like supply-names > > in the OPP table be fine? Like this: > > > > @@ -369,13 +378,16 @@ Example 4: Handling multiple regulators > > compatible = "arm,cortex-a7"; > > ... > > > > - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, > > <&cpu_supply2>; > > + vcc0-supply = <&cpu_supply0>; > > + vcc1-supply = <&cpu_supply1>; > > + vcc2-supply = <&cpu_supply2>; > > operating-points-v2 = <&cpu0_opp_table>; > > }; > > }; > > > > cpu0_opp_table: opp_table0 { > > compatible = "operating-points-v2"; > > + supply-names = "vcc0", "vcc1", "vcc2"; > > opp-shared; > > > > No. The supply names (and also clock names/index) should be left > up to the consumer of the OPP table. We don't want to encode any > sort of details like this between the OPP table and the consumer > of it in DT because then it seriously couples the OPP table to > the consumer device. "The binding" in this case that needs to be > updated is the consumer binding, to indicate that it correlated > foo-supply and bar-supply to index 0 and 1 of the OPP table > voltages. Are you saying that we shall have a property like this then? diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index ee91cbdd95ee..733946df2fb8 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -389,7 +389,10 @@ Example 4: Handling multiple regulators compatible = "arm,cortex-a7"; ... - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>; + vcc0-supply = <&cpu_supply0>; + vcc1-supply = <&cpu_supply1>; + vcc2-supply = <&cpu_supply2>; + opp-supply-names = "vcc0", "vcc1", "vcc2"; operating-points-v2 = <&cpu0_opp_table>; }; }; -- viresh
Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
On Fri, Nov 11, 2016 at 5:42 AM, Rob Herring wrote: > On Sun, Nov 6, 2016 at 7:56 PM, Chen-Yu Tsai wrote: >> On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen wrote: >>> On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote: Quoting Peter Chen (2016-10-24 18:16:32) > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote: > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05) > > > Hi, > > > > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd > > > wrote: > > > > The ULPI bus can be built as a module, and it will soon be > > > > calling these functions when it supports probing devices from DT. > > > > Export them so they can be used by the ULPI module. > > > > > > > > Acked-by: Rob Herring > > > > Cc: > > > > Signed-off-by: Stephen Boyd > > > > --- > > > > drivers/of/device.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c > > > > index 8a22a253a830..6719ab35b62e 100644 > > > > --- a/drivers/of/device.c > > > > +++ b/drivers/of/device.c > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device > > > > *dev, char *str, ssize_t len) > > > > > > > > return tsize; > > > > } > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias); > > > > > > > > int of_device_request_module(struct device *dev) > > > > { > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, > > > > struct kobj_uevent_env *env) > > > > } > > > > mutex_unlock(&of_mutex); > > > > } > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias); > > > > > > This is trailing the wrong function. > > > > > > > Good catch. Must have been some bad rebase. > > > > Peter, can you fix it while applying or should I resend this patch? > > > > But, this is device tree patch. I can only get chipidea part and other > USB patches if Greg agrees. > Were you expecting Rob to take the drivers/of/* patches? Sorry I thought Rob acked them so they could go through usb with the other changes. >>> >>> I am just worried about possible merge error when linus pulls both OF >>> and USB tree. Greg, is it ok the OF patches through USB tree with OF >>> maintainer's ack? >> >> May I suggest putting the OF patches on an immutable branch so other >> subsystems can pull them in without pulling in the USB patches? At >> least I want to use them in the I2C subsystem, and in the sunxi-rsb >> driver. > > Do you have patches using this already. If not, it is starting to get > a bit late for v4.10. > > I can apply this, but then you'll just be pulling in other DT patches. Not sure what you mean by "using" this... I have patches which use this to add DT-based modalias entries for module auto-loading to i2c and sunxi-rsb that I haven't sent. As far as DT usage goes, we already need this for the axp20x mfd driver. There are 2 variants, i2c and sunxi-rsb. For the I2C variant a fix was sent to fix module auto-loading by using the I2C client ID table: mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=b7142a19321484bd7681aa547c1d50148c8e2825 But for the sunxi-rsb variant such a fix does not exist, as the bus does not have a separate ID table. It uses DT exclusively. Regards ChenYu
Re: [PATCH] watchdog: jz4740: Fix modular build
On 11/10/2016 04:02 PM, Stephen Boyd wrote: Compiling this driver as a module causes a build error because a semicolon is missing after MODULE_DEVICE_TABLE. Add it. CC [M] drivers/watchdog/jz4740_wdt.o drivers/watchdog/jz4740_wdt.c:154:1: error: expected ‘,’ or ‘;’ before ‘static’ drivers/watchdog/jz4740_wdt.c:218:11: error: ‘jz4740_wdt_probe’ undeclared here (not in a function) Cc: Zubair Lutfullah Kakakhel Cc: Guenter Roeck Signed-off-by: Stephen Boyd Oops :-( Reviewed-by: Guenter Roeck --- drivers/watchdog/jz4740_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c index c8d51ddb26d5..20627f22baf6 100644 --- a/drivers/watchdog/jz4740_wdt.c +++ b/drivers/watchdog/jz4740_wdt.c @@ -148,7 +148,7 @@ static const struct of_device_id jz4740_wdt_of_matches[] = { { .compatible = "ingenic,jz4740-watchdog", }, { /* sentinel */ } }; -MODULE_DEVICE_TABLE(of, jz4740_wdt_of_matches) +MODULE_DEVICE_TABLE(of, jz4740_wdt_of_matches); #endif static int jz4740_wdt_probe(struct platform_device *pdev)
Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability
Hi, On 11/11/2016 10:24 AM, Lu Baolu wrote: >> The only thing you can do to make this work is to prevent printing in NMI >> > context: >> > >> > write() >> > { >> >if (in_nmi()) >> >return; >> > >> >raw_spinlock_irqsave(&lock, flags); >> > >> > >> > That fully serializes the writes and just ignores NMI context printks. Not >> > optimal, but I fear that's all you can do. > Yes. But I want to add a bit more. > > write() > { > if (in_nmi() && raw_spin_is_locked(&lock)) { > trace("... ..."); > return; > } > > raw_spinlock_irqsave(&lock, flags); > Or...? write() { if (in_nmi() && raw_spin_is_locked(&lock)) { save_nmi_message_in_local_buf(); set_nmi_message_pending_flag(); return; } if (nmi_message_pending_flag_is_set()) { write_nmi_message(); clear_nmi_message_pending_flag(); } raw_spinlock_irqsave(&lock, flags); Best regards, Lu Baolu
Re: [PATCH v9 1/6] x86/platform/p2sb: New Primary to Sideband bridge support driver for Intel SOC's
On Tue, Nov 08, 2016 at 05:55:20PM +0100, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Tan Jui Nee wrote: > > There is already one and at least one more user coming which > > require an access to Primary to Sideband bridge (P2SB) in order > > to get IO or MMIO bar hidden by BIOS. > > Create a driver to access P2SB for x86 devices. > > > > arch/x86/Kconfig | 4 ++ > > arch/x86/include/asm/p2sb.h | 27 +++ > > arch/x86/platform/intel/Makefile | 1 + > > arch/x86/platform/intel/p2sb.c | 98 > > > > This really has nothing to do with architecture. It's a platform enablement > driver and therefor should go into drivers/platform/x86 > > Cc'ed Darren who is responsible for this. Thanks Thomas, Tan Jui, I'll be on a short medical leave through Nov 28. In the meantime, Andy Shevchenko (on Cc) will be taking the lead on drivers/platform/x86 patches. Andy, please work with Tan Jui to update this change to apply to our tree. Thanks, -- Darren Hart Intel Open Source Technology Center
[PATCH v2 0/3] pinctrl: sunxi: Support generic pinconf functions
Hi everyone, This series fixes up generic pinconf support for the sunxi pinctrl driver library. The driver was doing some bits wrong, like a) storing the pinconf config value in its struct, and not actually reading the hardware to get the current config, and b) not using the right arguments for the bias parameters. Patch 1 fixes the pin bias parameter arguments. Patch 2 makes the driver read out pinconf settings from the hardware, and returns the correct value for unsupported features and disable features. With this in place it also declares itself as generic pinconf compatible, which enables us to read the config through the debugfs pinconf interface. Patch 3 makes the sunxi_pconf_group_set callback use the helper function introduced in patch 1. Changes since v1: - Rebased onto the updated sunxi pinctrl driver with support for the generic pinconf bindings - Use separate value for what is written to the register in the pinconf set function, as Maxime requested. Regards ChenYu Chen-Yu Tsai (3): pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN,UP} argument pinctrl: sunxi: Add support for fetching pinconf settings from hardware pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper drivers/pinctrl/sunxi/pinctrl-sunxi.c | 156 +- drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 - 2 files changed, 118 insertions(+), 39 deletions(-) -- 2.10.2
[PATCH v2 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware
The sunxi pinctrl driver only caches whatever pinconf setting was last set on a given pingroup. This is not particularly helpful, nor is it correct. Fix this by actually reading the hardware registers and returning the correct results or error codes. Also filter out unsupported pinconf settings. Since this driver has a peculiar setup of 1 pin per group, we can support both pin and pingroup pinconf setting read back with the same code. The sunxi_pconf_reg helper and code structure is inspired by pinctrl-msm. With this done we can also claim to support generic pinconf, by setting .is_generic = true in pinconf_ops. Signed-off-by: Chen-Yu Tsai --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 84 +-- 1 file changed, 81 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index e04edda8629d..3e9f7c675d36 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -438,15 +438,91 @@ static const struct pinctrl_ops sunxi_pctrl_ops = { .get_group_pins = sunxi_pctrl_get_group_pins, }; +static int sunxi_pconf_reg(unsigned pin, enum pin_config_param param, + u32 *offset, u32 *shift, u32 *mask) +{ + switch (param) { + case PIN_CONFIG_DRIVE_STRENGTH: + *offset = sunxi_dlevel_reg(pin); + *shift = sunxi_dlevel_offset(pin); + *mask = DLEVEL_PINS_MASK; + break; + + case PIN_CONFIG_BIAS_PULL_UP: + case PIN_CONFIG_BIAS_PULL_DOWN: + case PIN_CONFIG_BIAS_DISABLE: + *offset = sunxi_pull_reg(pin); + *shift = sunxi_pull_offset(pin); + *mask = PULL_PINS_MASK; + break; + + default: + return -ENOTSUPP; + } + + return 0; +} + +static int sunxi_pconf_get(struct pinctrl_dev *pctldev, unsigned pin, + unsigned long *config) +{ + struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev); + enum pin_config_param param = pinconf_to_config_param(*config); + u32 offset, shift, mask, val; + u16 arg; + int ret; + + pin -= pctl->desc->pin_base; + + ret = sunxi_pconf_reg(pin, param, &offset, &shift, &mask); + if (ret < 0) + return ret; + + val = (readl(pctl->membase + offset) >> shift) & mask; + + switch (pinconf_to_config_param(*config)) { + case PIN_CONFIG_DRIVE_STRENGTH: + arg = (val + 1) * 10; + break; + + case PIN_CONFIG_BIAS_PULL_UP: + if (val != SUN4I_PINCTRL_PULL_UP) + return -EINVAL; + arg = 1; /* hardware is weak pull-up */ + break; + + case PIN_CONFIG_BIAS_PULL_DOWN: + if (val != SUN4I_PINCTRL_PULL_DOWN) + return -EINVAL; + arg = 1; /* hardware is weak pull-down */ + break; + + case PIN_CONFIG_BIAS_DISABLE: + if (val != SUN4I_PINCTRL_NO_PULL) + return -EINVAL; + arg = 0; + break; + + default: + /* sunxi_pconf_reg should catch anything unsupported */ + WARN_ON(1); + return -ENOTSUPP; + } + + *config = pinconf_to_config_packed(param, arg); + + return 0; +} + static int sunxi_pconf_group_get(struct pinctrl_dev *pctldev, unsigned group, unsigned long *config) { struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev); + struct sunxi_pinctrl_group *g = &pctl->groups[group]; - *config = pctl->groups[group].config; - - return 0; + /* We only support 1 pin per group. Chain it to the pin callback */ + return sunxi_pconf_get(pctldev, g->pin, config); } static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, @@ -518,6 +594,8 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, } static const struct pinconf_ops sunxi_pconf_ops = { + .is_generic = true, + .pin_config_get = sunxi_pconf_get, .pin_config_group_get = sunxi_pconf_group_get, .pin_config_group_set = sunxi_pconf_group_set, }; -- 2.10.2
[PATCH v2 3/3] pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
The sunxi_pconf_reg helper introduced in the last patch gives us the chance to rework sunxi_pconf_group_set to have it match the structure of sunxi_pconf_(group_)get and make it easier to understand. For each config to set, it: 1. checks if the parameter is supported. 2. checks if the argument is within limits. 3. converts argument to the register value. 4. writes to the register with spinlock held. As a result the function now blocks unsupported config parameters, instead of silently ignoring them. Signed-off-by: Chen-Yu Tsai --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 66 +-- drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 - 2 files changed, 32 insertions(+), 35 deletions(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index 3e9f7c675d36..fa11a3100346 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -532,23 +532,27 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, { struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev); struct sunxi_pinctrl_group *g = &pctl->groups[group]; - unsigned long flags; unsigned pin = g->pin - pctl->desc->pin_base; - u32 val, mask; - u16 strength; - u8 dlevel; int i; - spin_lock_irqsave(&pctl->lock, flags); - for (i = 0; i < num_configs; i++) { - switch (pinconf_to_config_param(configs[i])) { + enum pin_config_param param; + unsigned long flags; + u32 offset, shift, mask, reg; + u16 arg, val; + int ret; + + param = pinconf_to_config_param(configs[i]); + arg = pinconf_to_config_argument(configs[i]); + + ret = sunxi_pconf_reg(pin, param, &offset, &shift, &mask); + if (ret < 0) + return ret; + + switch (param) { case PIN_CONFIG_DRIVE_STRENGTH: - strength = pinconf_to_config_argument(configs[i]); - if (strength > 40) { - spin_unlock_irqrestore(&pctl->lock, flags); + if (arg < 10 || arg > 40) return -EINVAL; - } /* * We convert from mA to what the register expects: * 0: 10mA @@ -556,39 +560,33 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, * 2: 30mA * 3: 40mA */ - dlevel = strength / 10 - 1; - val = readl(pctl->membase + sunxi_dlevel_reg(pin)); - mask = DLEVEL_PINS_MASK << sunxi_dlevel_offset(pin); - writel((val & ~mask) - | dlevel << sunxi_dlevel_offset(pin), - pctl->membase + sunxi_dlevel_reg(pin)); + val = arg / 10 - 1; break; case PIN_CONFIG_BIAS_DISABLE: - val = readl(pctl->membase + sunxi_pull_reg(pin)); - mask = PULL_PINS_MASK << sunxi_pull_offset(pin); - writel((val & ~mask), - pctl->membase + sunxi_pull_reg(pin)); + val = 0; break; case PIN_CONFIG_BIAS_PULL_UP: - val = readl(pctl->membase + sunxi_pull_reg(pin)); - mask = PULL_PINS_MASK << sunxi_pull_offset(pin); - writel((val & ~mask) | 1 << sunxi_pull_offset(pin), - pctl->membase + sunxi_pull_reg(pin)); + if (arg == 0) + return -EINVAL; + val = 1; break; case PIN_CONFIG_BIAS_PULL_DOWN: - val = readl(pctl->membase + sunxi_pull_reg(pin)); - mask = PULL_PINS_MASK << sunxi_pull_offset(pin); - writel((val & ~mask) | 2 << sunxi_pull_offset(pin), - pctl->membase + sunxi_pull_reg(pin)); + if (arg == 0) + return -EINVAL; + val = 2; break; default: - break; + /* sunxi_pconf_reg should catch anything unsupported */ + WARN_ON(1); + return -ENOTSUPP; } - /* cache the config value */ - g->config = configs[i]; - } /* for each config */ - spin_unlock_irqrestore(&pctl->lock, flags); + spin_lock_irqsave(&pctl->lock, flags); + reg = readl(pctl->membase +
[PATCH v2 1/3] pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN,UP} argument
According to pinconf-generic.h, the argument for PIN_CONFIG_BIAS_PULL_{DOWN,UP} is non-zero if the bias is enabled with a pull up/down resistor, zero if it is directly connected to VDD or ground. Since Allwinner hardware uses a weak pull resistor internally, the argument should be 1. Signed-off-by: Chen-Yu Tsai --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index e199d95af8c0..e04edda8629d 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -291,12 +291,16 @@ static unsigned long *sunxi_pctrl_build_pin_config(struct device_node *node, if (sunxi_pctrl_has_bias_prop(node)) { int pull = sunxi_pctrl_parse_bias_prop(node); + int arg = 0; if (pull < 0) { ret = pull; goto err_free; } - pinconfig[idx++] = pinconf_to_config_packed(pull, 0); + if (pull != PIN_CONFIG_BIAS_DISABLE) + arg = 1; /* hardware uses weak pull resistors */ + + pinconfig[idx++] = pinconf_to_config_packed(pull, arg); } -- 2.10.2
[PATCH] pinctrl: sunxi: Free configs in pinctrl_map only if it is a config map
In the recently refactored sunxi pinctrl library, we are only allocating one set of pin configs for each pinmux setting node. When the pinctrl_map structure is freed, the pin configs should also be freed. However the code assumed the first map would contain the configs, which actually never happens, as the mux function map gets added first. The proper way to do this is to look through all the maps and free the first one whose type is actually PIN_MAP_TYPE_CONFIGS_GROUP. Also slightly expand the comment explaining this. Fixes: f233dbca6227 ("pinctrl: sunxi: Rework the pin config building code") Signed-off-by: Chen-Yu Tsai --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index ebe2c73d211e..e199d95af8c0 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -408,8 +408,21 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev, struct pinctrl_map *map, unsigned num_maps) { - /* All the maps have the same pin config, free only the first one */ - kfree(map[0].data.configs.configs); + int i; + + /* pin config is never in the first map */ + for (i = 1; i < num_maps; i++) { + if (map[i].type != PIN_MAP_TYPE_CONFIGS_GROUP) + continue; + + /* +* All the maps share the same pin config, +* free only the first one we find. +*/ + kfree(map[i].data.configs.configs); + break; + } + kfree(map); } -- 2.10.2
[GIT PULL] platform-drivers-x86 for 4.9-3
Hi Linus, The following changes since commit c3f8f7fa8b19e274e7eb99dee428ad3a9b2ad8eb: Merge tag 'platform-drivers-x86-v4.9-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86 (2016-10-19 11:45:06 -0700) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.9-3 for you to fetch changes up to 8ec4b736d709562193566156c0dd40e327df2cbb: Documentation/ABI: ibm_rtl: The "What:" fields are incomplete (2016-11-01 09:27:33 -0700) Thanks, Darren Hart Intel Open Source Technology Center platform-drivers-x86 for 4.9-3 Minor doc fix, a DMI match for ideapad and a fix to toshiba-wmi to avoid loading on non-toshiba systems. Documentation/ABI: - ibm_rtl: The "What:" fields are incomplete toshiba-wmi: - Fix loading the driver on non Toshiba laptops ideapad-laptop: - Add another DMI entry for Yoga 900 Azael Avalos (1): toshiba-wmi: Fix loading the driver on non Toshiba laptops Mauro Carvalho Chehab (1): Documentation/ABI: ibm_rtl: The "What:" fields are incomplete Mika Westerberg (1): ideapad-laptop: Add another DMI entry for Yoga 900 .../ABI/testing/sysfs-devices-system-ibm-rtl | 4 ++-- drivers/platform/x86/ideapad-laptop.c | 7 ++ drivers/platform/x86/toshiba-wmi.c | 26 -- 3 files changed, 28 insertions(+), 9 deletions(-) -- Darren Hart Intel Open Source Technology Center
Re: [PATCH 3/3] vhost_net: tx support batching
On 2016年11月10日 04:05, Michael S. Tsirkin wrote: On Wed, Nov 09, 2016 at 03:38:33PM +0800, Jason Wang wrote: This patch tries to utilize tuntap rx batching by peeking the tx virtqueue during transmission, if there's more available buffers in the virtqueue, set MSG_MORE flag for a hint for tuntap to batch the packets. The maximum number of batched tx packets were specified through a module parameter: tx_bached. When use 16 as tx_batched: When using Pktgen test shows 16% on tx pps in guest. Netperf test does not show obvious regression. Why doesn't netperf benefit? This is probably because the tests (4VCPU, 1queue, TCP, mlx4) does not produce 100% stress on vhost thread. In pktgen test, 100% stress on vhost thread is achieved easily. For safety, 1 were used as the default value for tx_batched. s/were used/is used/ Signed-off-by: Jason Wang These tests unfortunately only run a single flow. The concern would be whether this increases latency when NIC is busy with other flows, so I think this is what you need to test. Multiple flows were tested too, no obvious improvement/regression were found. --- drivers/vhost/net.c | 15 ++- drivers/vhost/vhost.c | 1 + drivers/vhost/vhost.h | 1 + 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 5dc128a..51c378e 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -35,6 +35,10 @@ module_param(experimental_zcopytx, int, 0444); MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;" " 1 -Enable; 0 - Disable"); +static int tx_batched = 1; +module_param(tx_batched, int, 0444); +MODULE_PARM_DESC(tx_batched, "Number of patches batched in TX"); + /* Max number of bytes transferred before requeueing the job. * Using this limit prevents one virtqueue from starving others. */ #define VHOST_NET_WEIGHT 0x8 I think we should do some tests and find a good default. Ok, will test 4 and 32 to see if there's any difference. (Btw, 16 were chosed since dpdk tends to batch 16 packet during TX). Thanks
Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability
Hi, On 11/10/2016 04:56 PM, Thomas Gleixner wrote: > On Thu, 10 Nov 2016, Lu Baolu wrote: >> On 11/09/2016 05:37 PM, Thomas Gleixner wrote: >>> On Tue, 1 Nov 2016, Lu Baolu wrote: +static void early_xdbc_write(struct console *con, const char *str, u32 n) +{ + int chunk, ret; + static char buf[XDBC_MAX_PACKET]; + int use_cr = 0; + + if (!xdbc.xdbc_reg) + return; + memset(buf, 0, XDBC_MAX_PACKET); >>> How is that dealing with reentrancy? >>> >>> early_printk() does not protect against it. Peter has a patch to prevent >>> concurrent access from different cpus, but it cannot and will never prevent >>> reentrancy on the same cpu (interrupt, nmi). >> I can use a spinlock_irq to protect reentrancy of interrupt on the same >> cpu. But I have no idea about the nmi one. > spinlock wont work due to NMIs. Yes, of course. > >> This seems to be a common issue for all early printk drivers. > No. The other early printk drivers like serial do not have that problem as > they simply do: > >while (*buf) { > while (inb(UART) & TX_BUSY) >cpu_relax(); > outb(*buf++, UART); >} > > The wait for the UART to become ready is independent of the context as it > solely depends on the hardware. > > As a result you can see the output from irq/nmi intermingled with the one > from thread context, but that's the only problem they have. Yes, you are right. > > The only thing you can do to make this work is to prevent printing in NMI > context: > > write() > { > if (in_nmi()) > return; > > raw_spinlock_irqsave(&lock, flags); > > > That fully serializes the writes and just ignores NMI context printks. Not > optimal, but I fear that's all you can do. Yes. But I want to add a bit more. write() { if (in_nmi() && raw_spin_is_locked(&lock)) { trace("... ..."); return; } raw_spinlock_irqsave(&lock, flags); Best regards, Lu Baolu
Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks
>> To circumvent this problem, statically define CMT_MAX_NR_PKGS number of >> lock_class_key's. > > That's a proper circumvention. Define a random number on your own. A judiciously chosen number ;) . > >> Additional details in code's comments. > > This is > > - pointless. Either there are comments or not. I can see that from >the patch. > > - wrong. Because for this crucial detail of it (the lockdep >restriction) there is no single comment in the code. Noted. I'll stop adding those notes to the changelogs. >> +/* Increase as needed as Intel CPUs grow. */ > > As CPUs grow? CMT is a per L3 cache domain, i.e. package, which is > equivivalent to socket today.. > >> +#define CMT_MAX_NR_PKGS 8 > > This already breaks on these shiny new 16 socket machines companies are > working on. Not to talk about the 4096 core monstrosities which are shipped > today, which have definitely more than 16 sockets already. > > And now the obvious question: How are you going to fix this? A possible alternative to nested spinlocks is to use a single rw_lock to protect changes to the monr hierarchy. This works because, when manipulating pmonrs, the monr hierarchy (monr's parent and children) is read but never changed (reader path). Changes to the monr hierarchy do change pmonrs (writer path). It would be implemented like: // system-wide lock for monr hierarchy rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock); Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions and when reading cgroups (read subtree of pmonrs in same package): v3 (old): raw_spin_lock(&pkgd->lock); // read monr data, read/write pmonr data raw_spin_unlock(&pkgd->lock); next version: read_lock(&monr_hrchy_rwlock); raw_spin_lock(&pkgd->lock); // read monr data, read/write pmonr data raw_spin_unlock(&pkgd->lock); read_unlock(&monr_hrchy_rwlock); Writer Path: Modifies monr hierarchy (add/remove monr in creation/destruction of events and start/stop monitoring of cgroups): v3 (old): monr_hrchy_acquire_locks(...); // acquires all pkg->lock // read/write monr data, potentially read/write pmonr data monr_hrchy_release_locks(...); // release all pkg->lock v4: write_lock(&monr_hrchy_rwlock); // read/write monr data, potentially read/write pmonr data write_unlock(&monr_hrchy_rwlock); The write-path should occur infrequently. The reader-path is slower due to the additional read_lock(&monr_hrchy_rwlock). The number of locks to acquire remains constant on the number of packages in both paths. There would be no need to ever nest pkgd->lock's. For v3, I discarded this idea because, due to the additional read_lock(&monr_hrchy_rwlock), the pmonr state transitions that may occur in a context switch would be slower than in the current version. But it may be ultimately better considering the scalability issues that you mention. >> + * - Hold pkg->mutex and pkg->lock in _all_ active packages to traverse or >> + * change the monr hierarchy. > > So if you hold both locks in 8 packages then you already have 16 locks held > nested. Now double that with 16 packages and you are slowly approaching the > maximum lock chain depth lockdep can cope with. Now think SGI and guess > how that works. > > I certainly can understand why you want to split the locks, but my gut > feeling tells me that while it's probably not a big issue on a 2/4 socket > machines it will go down the drain rather fast on anything real big. > > Thanks, > > tglx Thanks for reviewing the patches. I really appreciate the feedback. David
Re: [PATCH 2/3] vhost: better detection of available buffers
On 2016年11月10日 03:57, Michael S. Tsirkin wrote: On Wed, Nov 09, 2016 at 03:38:32PM +0800, Jason Wang wrote: We should use vq->last_avail_idx instead of vq->avail_idx in the checking of vhost_vq_avail_empty() since latter is the cached avail index from guest but we want to know if there's pending available buffers in the virtqueue. Signed-off-by: Jason Wang I'm not sure why is this patch here. Is it related to batching somehow? Yes, we need to know whether or not there's still buffers left in the virtqueue, so need to check last_avail_idx. Otherwise, we're checking if guest has submitted new buffers. --- drivers/vhost/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c6f2d89..fdf4cdf 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -2230,7 +2230,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq) if (r) return false; - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx; + return vhost16_to_cpu(vq, avail_idx) == vq->last_avail_idx; } EXPORT_SYMBOL_GPL(vhost_vq_avail_empty); That might be OK for TX but it's probably wrong for RX where the fact that used != avail does not mean we have enough space to store the packet. Right, but it's no harm since it was just a hint, handle_rx() can handle this situation. Maybe we should just rename this to vhost_vq_avail_unchanged to clarify usage. Ok. -- 2.7.4
Re: BYD TouchPad driver (4.8.1) misdetects a Logitech mouse
Sorry for the late response, forwarding to Dmitry and linux-input. I haven't dealt with input in years... Michael Shell wrote: > > Not a big deal, but something nonetheless ... > > I recently upgraded my kernel from 4.3 to 4.8.1 (this is a Linux From > Scratch build). There was only one obvious hiccup - X would not > start because it no longer saw the mouse. > > I have a Logitech RX250 PS2/USB mouse on the PS/2 port (via a USB->PS2 > adapter): > > http://support.logitech.com/en_gb/product/rx250-mouse > > The RX250 is a wheel mouse, but with an added left/right scroll wheel > "tilt" feature to provide for horizontal scrolling. > > In my xorg.conf I had: > > > Section "InputDevice" > Identifier "Mouse0" > Driver "evdev" > Option "Name" "ImExPS/2 Logitech Explorer Mouse" > EndSection > > > However, under the 4.8.1 kernel, cat /proc/bus/input/devices shows: > > > I: Bus=0011 Vendor=0002 Product=0006 Version=0073 > N: Name="ImExPS/2 BYD TouchPad" > P: Phys=isa0060/serio1/input0 > S: Sysfs=/devices/platform/i8042/serio1/input/input3 > U: Uniq= > H: Handlers=mouse0 event2 > B: PROP=1 > B: EV=7 > B: KEY=1f 0 0 0 0 0 0 0 0 > B: REL=143 > > > and dmesg shows the lines: > > > psmouse serio1: logips2pp: Detected unknown Logitech mouse model 115 > input: ImExPS/2 BYD TouchPad as /devices/platform/i8042/serio1/input/input3 > > > Changing the mouse name in xorg.conf to "ImExPS/2 BYD TouchPad" did > allow the mouse to work correctly under X, including the tilt buttons. > FWIW, in the 4.8.1 kernel config, the byd.c driver does default to > "Yes", a default which I accepted under make oldconfig. > > Apparently, the detection code (byd_detect) in the new byd.c driver, > which did not even exist in 4.3, (drivers/input/mouse/byd.c) falsely > sees the Logitech RX250 as being a BYD TouchPad and thus alters the > vendor and model names. > > I do not know if it is also desirable to add an entry for a Logitech > model 115 in get_model_info in logips2pp.c > (drivers/input/mouse/logips2pp.c). But if so, I would be willing to > test any such new code. Even as an unknown Logitech model, it does > work just fine. I am curious as to how the tilt feature buttons would > be declared in the model info (would these be PS2PP_EXTRA_BTN, > or PS2PP_NAV_BTN, etc.?) > > > > Cheers and thanks in advance, > > Mike Shell >
Re: [PATCH 1/3] tuntap: rx batching
On 2016年11月10日 00:38, Michael S. Tsirkin wrote: On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: Backlog were used for tuntap rx, but it can only process 1 packet at one time since it was scheduled during sendmsg() synchronously in process context. This lead bad cache utilization so this patch tries to do some batching before call rx NAPI. This is done through: - accept MSG_MORE as a hint from sendmsg() caller, if it was set, batch the packet temporarily in a linked list and submit them all once MSG_MORE were cleared. - implement a tuntap specific NAPI handler for processing this kind of possible batching. (This could be done by extending backlog to support skb like, but using a tun specific one looks cleaner and easier for future extension). Signed-off-by: Jason Wang So why do we need an extra queue? The idea was borrowed from backlog to allow some kind of bulking and avoid spinlock on each dequeuing. This is not what hardware devices do. How about adding the packet to queue unconditionally, deferring signalling until we get sendmsg without MSG_MORE? Then you need touch spinlock when dequeuing each packet. --- drivers/net/tun.c | 71 ++- 1 file changed, 65 insertions(+), 6 deletions(-) [...] rxhash = skb_get_hash(skb); - netif_rx_ni(skb); + skb_queue_tail(&tfile->socket.sk->sk_write_queue, skb); + + if (!more) { + local_bh_disable(); + napi_schedule(&tfile->napi); + local_bh_enable(); Why do we need to disable bh here? I thought napi_schedule can be called from any context. Yes, it's unnecessary. Will remove. Thanks
Re: [PATCH v3 12/17] ASoC: simple-card-utils: add asoc_simple_card_try_to_probe_graph_card()
Hi Kuninori, [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.9-rc4 next-20161110] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/2016-093231 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: x86_64-randconfig-x010-201645 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): sound/soc/generic/simple-card-utils.c: In function 'asoc_simple_card_try_to_probe_graph_card': >> sound/soc/generic/simple-card-utils.c:297:9: error: implicit declaration of >> function 'of_graph_get_top_port' [-Werror=implicit-function-declaration] node = of_graph_get_top_port(dev); ^ >> sound/soc/generic/simple-card-utils.c:297:7: warning: assignment makes >> pointer from integer without a cast [-Wint-conversion] node = of_graph_get_top_port(dev); ^ cc1: some warnings being treated as errors vim +/of_graph_get_top_port +297 sound/soc/generic/simple-card-utils.c 291 { 292 struct platform_device_info pdevinfo; 293 struct device_node *node; 294 const char *compatible; 295 int ret; 296 > 297 node = of_graph_get_top_port(dev); 298 if (!node || !info) 299 /* 300 * It doesn't have graph base sound DT, or its infomation. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v2 1/1] usb: xhci: handle endpoint error caused by TRB error
When xHCI host sees a malformed TRB in a transfer ring, it will generate a transfer event with the completion code set to COMP_TRB_ERR (5), and sets the endpoint state in output endpoint context to EP_STATE_ERROR. The endpoint enters ERROR state as the result. XHCI specification requires that Set TR Dequeue Pointer Command shall be used to transition the endpoint from Error to Stopped state. Current xHCI driver doesn't clear this endpoint error, hence the successive URB enqueue requests will result in error messages of "WARN waiting for error on ep to be cleared". And the corresponding USB device stays in unresponsive state. This patch enhances xHCI driver on this by printing out the malformed TRB and clearing the endpoint Error state. Tested-by: Wang Wendy Signed-off-by: Lu Baolu --- Change log: v1->v2: - Correct the email of Tested-by. drivers/usb/host/xhci-ring.c | 35 +++ drivers/usb/host/xhci.c | 22 ++ drivers/usb/host/xhci.h | 2 ++ 3 files changed, 59 insertions(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 822f88a..f81c1be 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1773,6 +1773,20 @@ static void xhci_cleanup_halted_endpoint(struct xhci_hcd *xhci, xhci_ring_cmd_db(xhci); } +static void xhci_cleanup_trb_error_endpoint(struct xhci_hcd *xhci, + unsigned int slot_id, unsigned int ep_index, + unsigned int stream_id, + struct xhci_td *td, union xhci_trb *event_trb) +{ + struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index]; + + ep->stopped_stream = stream_id; + xhci_cleanup_trb_error_ring(xhci, ep_index, td); + ep->stopped_stream = 0; + + xhci_ring_cmd_db(xhci); +} + /* Check if an error has halted the endpoint ring. The class driver will * cleanup the halt for a non-default control endpoint if we indicate a stall. * However, a babble and other errors also halt the endpoint ring, and the class @@ -1860,6 +1874,13 @@ static int finish_td(struct xhci_hcd *xhci, struct xhci_td *td, */ xhci_cleanup_halted_endpoint(xhci, slot_id, ep_index, ep_ring->stream_id, td, ep_trb); + } else if (trb_comp_code == COMP_TRB_ERR) { + /* Clear the Endpoint error caused by a TRB error by issuing +* a set dequeue command to move the dequeue pointer past the +* last TD. +*/ + xhci_cleanup_trb_error_endpoint(xhci, slot_id, ep_index, + ep_ring->stream_id, td, ep_trb); } else { /* Update ring dequeue pointer */ while (ep_ring->dequeue != td->last_trb) @@ -2474,6 +2495,20 @@ static int handle_tx_event(struct xhci_hcd *xhci, goto cleanup; } + /* +* Dump the original TRB which caused a transfer error with +* completion code set to TRB error. +*/ + if (trb_comp_code == COMP_TRB_ERR) { + xhci_err(xhci, "Malformed transfer TRB deteced:\n"); + xhci_err(xhci, "@%016llx %08x %08x %08x %08x\n", +(unsigned long long)ep_trb_dma, +le32_to_cpu(ep_trb->generic.field[0]), +le32_to_cpu(ep_trb->generic.field[1]), +le32_to_cpu(ep_trb->generic.field[2]), +le32_to_cpu(ep_trb->generic.field[3])); + } + /* update the urb's actual_length and give back to the core */ if (usb_endpoint_xfer_control(&td->urb->ep->desc)) process_ctrl_td(xhci, td, ep_trb, event, ep, &status); diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index ba46c70..e10a490 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -2944,6 +2944,28 @@ void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci, } } +void xhci_cleanup_trb_error_ring(struct xhci_hcd *xhci, + unsigned int ep_index, struct xhci_td *td) +{ + struct xhci_dequeue_state deq_state; + struct xhci_virt_ep *ep; + struct usb_device *udev = td->urb->dev; + + xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep, + "Cleaning up trb error endpoint ring"); + ep = &xhci->devs[udev->slot_id]->eps[ep_index]; + + xhci_find_new_dequeue_state(xhci, udev->slot_id, + ep_index, ep->stopped_stream, td, &deq_state); + + if (!deq_state.new_deq_ptr || !deq_state.new_deq_seg) + return; + + xhci_queue_new_dequeue_state(xhci, udev->slot_id, +ep_index, ep->stopped_stream, +
[PATCH] iommu/ipmmu-vmsa: Unify domain alloc/free implementations
The ARM and ARM64 implementations of the IOMMU domain alloc/free operations can be unified with the correct combination of type checking, as the domain type can never be IOMMU_DOMAIN_DMA on 32-bit ARM due to the driver calling iommu_group_get_for_dev() on ARM64 only. Do so. Signed-off-by: Laurent Pinchart --- drivers/iommu/ipmmu-vmsa.c | 58 +++--- 1 file changed, 14 insertions(+), 44 deletions(-) Hi Magnus, This cleans up patch 5/7, making patch 4/7 unnecessary. I proposed squashing 4/7, 5/7 and this one in v7. diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 11550ac90d65..827aa72aaf28 100644 --- a/drivers/iommu/ipmmu-vmsa.c +++ b/drivers/iommu/ipmmu-vmsa.c @@ -529,16 +529,22 @@ static irqreturn_t ipmmu_irq(int irq, void *dev) * IOMMU Operations */ -static struct iommu_domain *__ipmmu_domain_alloc(unsigned type) +static struct iommu_domain *ipmmu_domain_alloc(unsigned int type) { struct ipmmu_vmsa_domain *domain; + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA) + return NULL; + domain = kzalloc(sizeof(*domain), GFP_KERNEL); if (!domain) return NULL; spin_lock_init(&domain->lock); + if (type == IOMMU_DOMAIN_DMA) + iommu_get_dma_cookie(&domain->io_domain); + return &domain->io_domain; } @@ -546,6 +552,9 @@ static void ipmmu_domain_free(struct iommu_domain *io_domain) { struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain); + if (io_domain->type) + iommu_put_dma_cookie(io_domain); + /* * Free the domain resources. We assume that all devices have already * been detached. @@ -821,14 +830,6 @@ static void ipmmu_remove_device(struct device *dev) set_archdata(dev, NULL); } -static struct iommu_domain *ipmmu_domain_alloc(unsigned type) -{ - if (type != IOMMU_DOMAIN_UNMANAGED) - return NULL; - - return __ipmmu_domain_alloc(type); -} - static const struct iommu_ops ipmmu_ops = { .domain_alloc = ipmmu_domain_alloc, .domain_free = ipmmu_domain_free, @@ -847,42 +848,11 @@ static const struct iommu_ops ipmmu_ops = { #ifdef CONFIG_IOMMU_DMA -static struct iommu_domain *ipmmu_domain_alloc_dma(unsigned type) -{ - struct iommu_domain *io_domain = NULL; - - switch (type) { - case IOMMU_DOMAIN_UNMANAGED: - io_domain = __ipmmu_domain_alloc(type); - break; - - case IOMMU_DOMAIN_DMA: - io_domain = __ipmmu_domain_alloc(type); - if (io_domain) - iommu_get_dma_cookie(io_domain); - break; - } - - return io_domain; -} - -static void ipmmu_domain_free_dma(struct iommu_domain *io_domain) -{ - switch (io_domain->type) { - case IOMMU_DOMAIN_DMA: - iommu_put_dma_cookie(io_domain); - /* fall-through */ - default: - ipmmu_domain_free(io_domain); - break; - } -} - static int ipmmu_add_device_dma(struct device *dev) { struct iommu_group *group; - /* only accept devices with iommus property */ + /* Only accept devices with an iommus property. */ if (of_count_phandle_with_args(dev->of_node, "iommus", "#iommu-cells") < 0) return -ENODEV; @@ -920,13 +890,13 @@ static struct iommu_group *ipmmu_device_group_dma(struct device *dev) static int ipmmu_of_xlate_dma(struct device *dev, struct of_phandle_args *spec) { - /* dummy callback to satisfy of_iommu_configure() */ + /* Dummy callback to satisfy of_iommu_configure(). */ return 0; } static const struct iommu_ops ipmmu_ops = { - .domain_alloc = ipmmu_domain_alloc_dma, - .domain_free = ipmmu_domain_free_dma, + .domain_alloc = ipmmu_domain_alloc, + .domain_free = ipmmu_domain_free, .attach_dev = ipmmu_attach_device, .detach_dev = ipmmu_detach_device, .map = ipmmu_map, -- Regards, Laurent Pinchart
Re: [PATCH 1/1] usb: xhci: handle endpoint error caused by TRB error
Hi, On 11/11/2016 09:03 AM, Lu Baolu wrote: > When xHCI host sees a malformed TRB in a transfer ring, > it will generate a transfer event with the completion > code set to COMP_TRB_ERR (5), and sets the endpoint > state in output endpoint context to EP_STATE_ERROR. > The endpoint enters ERROR state as the result. > > XHCI specification requires that Set TR Dequeue Pointer > Command shall be used to transition the endpoint from > Error to Stopped state. Current xHCI driver doesn't > clear this endpoint error, hence the successive URB > enqueue requests will result in error messages of > "WARN waiting for error on ep to be cleared". And the > corresponding USB device stays in unresponsive state. > > This patch enhances xHCI driver on this by printing out > the malformed TRB and clearing the endpoint Error state. > > Tested-by: Wang Wendy ^ intel.com I will correct it with a v2. Best regards, Lu Baolu
[GIT PULL] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
Hi Dave, Please pull that change for ARC PGU that fixes driver instantiation on AXS 10x boards. The patch was published for review here: https://lists.freedesktop.org/archives/dri-devel/2016-October/121245.html It is based on today's "drm-next" branch. Probably it's already too late for 4.9 but if there's a chance to squeeze it there it will be super nice because it's a fix for inevitable driver crash right on start. Best regards, Alexey The following changes since commit fa860a1751e388385a7f249dd3f24a6c76db0ba9: drm: Print device information again in debugfs (2016-10-17 16:20:53 +1000) are available in the git repository at: https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git topic-arcpgu-fixes for you to fetch changes up to 7bc61cc5df808008b77a3b72cf814960c675518b: drm/arcpgu: Accommodate adv7511 switch to DRM bridge (2016-11-11 04:31:35 +0300) Eugeniy Paltsev (1): drm/arcpgu: Accommodate adv7511 switch to DRM bridge drivers/gpu/drm/arc/arcpgu_hdmi.c | 159 +--- 1 file changed, 17 insertions(+), 142 deletions(-)
Re: [PATCH v9 2/8] power: add power sequence library
On Fri, Nov 11, 2016 at 02:05:01AM +0100, Rafael J. Wysocki wrote: > On Tue, Nov 8, 2016 at 3:51 AM, Peter Chen wrote: > > We have an well-known problem that the device needs to do some power > > sequence before it can be recognized by related host, the typical > > example like hard-wired mmc devices and usb devices. > > > > This power sequence is hard to be described at device tree and handled by > > related host driver, so we have created a common power sequence > > library to cover this requirement. The core code has supplied > > some common helpers for host driver, and individual power sequence > > libraries handle kinds of power sequence for devices. The pwrseq > > librares always need to allocate extra instance for compatible > > string match. > > > > pwrseq_generic is intended for general purpose of power sequence, which > > handles gpios and clocks currently, and can cover other controls in > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off > > if only one power sequence is needed, else call of_pwrseq_on_list > > /of_pwrseq_off_list instead (eg, USB hub driver). > > > > For new power sequence library, it can add its compatible string > > to pwrseq_of_match_table, then the pwrseq core will match it with > > DT's, and choose this library at runtime. > > In the first place, please document this stuff better than you have so > far. To a minimum, add kerneldoc comments to all new non-trivial new > functions to document what they are for and how they are expected to > be used (especially the ones exported to drivers). > Thanks for your comments. I will add kerneldoc for main APIs. > Also, is there any guidance available for people who may want to use it? No doc now, only some guidance in this commit log. > > +config PWRSEQ_GENERIC > > + bool "Generic power sequence control" > > + depends on OF > > + select POWER_SEQUENCE > > + help > > + It is used for drivers which needs to do power sequence > > + (eg, turn on clock, toggle reset gpio) before the related > > + devices can be found by hardware. This generic one can be > > + used for common power sequence control. > > I wouldn't set it up this way. > > There are two problems here. > > First, say a distro is going to ship a multiplatform generic kernel. > How they are going to figure out whether or not to set the new symbol > in that kernel? > > Second, how users are supposed to know whether or not they will need > it even if they build the kernel by themselves? > > It would be better IMO to set things up to select the new symbol from > places making use of the code depending on it. > Will change it like below: # # Power Sequence library # menuconfig POWER_SEQUENCE bool "Power sequence control" depends on OF help It is used for drivers which needs to do power sequence (eg, turn on clock, toggle reset gpio) before the related devices can be found by hardware. if POWER_SEQUENCE config PWRSEQ_GENERIC bool "Generic power sequence control" default y help This is the generic power sequence control library, and is supposed to support common power sequence usage. endif And the current user usb core will select POWER_SEQUENCE. -- Best Regards, Peter Chen
Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
Hi Robin, On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote: > On 20/10/16 00:36, Magnus Damm wrote: > > From: Magnus Damm > > > > Introduce an alternative set of iommu_ops suitable for 64-bit ARM > > as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the > > Kconfig to depend on ARM or IOMMU_DMA. > > > > Signed-off-by: Magnus Damm > > --- > > > > Changes since V5: > > - Made domain allocation/free code more consistent - thanks Joerg! > > > > Changes since V4: > > - Added Kconfig hunk to depend on ARM or IOMMU_DMA > > > > Changes since V3: > > - Removed group parameter from ipmmu_init_platform_device() > > > > Changes since V2: > > > > - Included this new patch from the following series: > >[PATCH 00/04] iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update > > > > - Use only a single iommu_ops structure with #ifdef CONFIG_IOMMU_DMA > > - Folded in #ifdefs to handle CONFIG_ARM and CONFIG_IOMMU_DMA > > - of_xlate() is now used without #ifdefs > > - Made sure code compiles on both 32-bit and 64-bit ARM. > > > > drivers/iommu/Kconfig |1 > > drivers/iommu/ipmmu-vmsa.c | 122 --- > > 2 files changed, 115 insertions(+), 8 deletions(-) [snip] > > --- 0006/drivers/iommu/ipmmu-vmsa.c > > +++ work/drivers/iommu/ipmmu-vmsa.c 2016-10-20 08:16:48.440607110 +0900 [snip] > > -static struct iommu_domain *ipmmu_domain_alloc(unsigned type) > > -{ > > - if (type != IOMMU_DOMAIN_UNMANAGED) > > - return NULL; > > I *think* that if we did the initial check thus: > > if (type != IOMMU_DOMAIN_UNMANAGED || > (IS_ENABLED(CONFIG_IOMMU_DMA) && type != IOMMU_DOMAIN_DMA)) > return NULL; I assume you meant if (type != IOMMU_DOMAIN_UNMANAGED && (!IS_ENABLED(CONFIG_IOMMU_DMA) || type != IOMMU_DOMAIN_DMA)) return NULL; But how about just if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)) return NULL; as type will never be set to IOMMU_DOMAIN_DMA on ARM32 ? > it shouldn't be necessary to split the function at all - we then just > wrap the {get,put}_cookie() bits in "if (type == IOMMU_DOMAIN_DMA)" and > in the 32-bit ARM case they just don't run as that can never be true. > > > - > > - return __ipmmu_domain_alloc(type); > > -} > > - -- Regards, Laurent Pinchart