- 06 Apr, 2016 40 commits
-
-
Will Deacon authored
We want to avoid lots of different copy_page implementations, settling for something that is "good enough" everywhere and hopefully easy to understand and maintain whilst we're at it. This patch reworks our copy_page implementation based on discussions with Cavium on the list and benchmarking on Cortex-A processors so that: - The loop is unrolled to copy 128 bytes per iteration - The reads are offset so that we read from the next 128-byte block in the same iteration that we store the previous block - Explicit prefetch instructions are removed for now, since they hurt performance on CPUs with hardware prefetching - The loop exit condition is calculated at the start of the loop Signed-off-by:Will Deacon <will.deacon@arm.com> Tested-by:
Andrew Pinski <apinski@cavium.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> (cherry picked from linux-next commit 223e23e8) Signed-off-by:
Dann Frazier <dann.frazier@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Will Deacon authored
Most CPUs have a hardware prefetcher which generally performs better without explicit prefetch instructions issued by software, however some CPUs (e.g. Cavium ThunderX) rely solely on explicit prefetch instructions. This patch adds an alternative pattern (ARM64_HAS_NO_HW_PREFETCH) to allow our library code to make use of explicit prefetch instructions during things like copy routines only when the CPU does not have the capability to perform the prefetching itself. Signed-off-by:
-
Will Deacon authored
The LSE atomics rely on us not dirtying data at L1 if we can avoid it, otherwise many of the potential scalability benefits are lost. This patch replaces spin_lock_prefetch with a nop when the LSE atomics are in use, so that users don't shoot themselves in the foot by causing needless coherence traffic at L1. Signed-off-by:
-
Tirumalesh Chalamarla authored
Setting TCR_EL2.PS to 40 bits is wrong on systems with less that less than 40 bits of physical addresses. and breaks KVM on systems where the RAM is above 40 bits. This patch uses ID_AA64MMFR0_EL1.PARange to set TCR_EL2.PS dynamically, just like we already do for VTCR_EL2.PS. [Marc: rewrote commit message, patch tidy up] Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com> Signed-off-by:
-
Tirumalesh Chalamarla authored
The ARM GICv3 specification mentions the need for dsb after a read from the ICC_IAR1_EL1 register: 4.1.1 Physical CPU Interface: The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a returned INTID are not guaranteed to be visible until after the execution of a DSB. Not having this could result in missed interrupts, so let's add the required barrier. [Marc: fixed commit message] Acked-by:
-
Kefeng Wang authored
Convert the driver to use ns_to_timespec64() to keep consistency with timespec64_to_ns() instead of open coding the same logic. Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 286af315) Signed-off-by:
-
Sunil Goutham authored
This feature is introduced in pass-2 chip and with this CQ interrupt coalescing will work based on both timer and count. Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
-
Sunil Goutham authored
This adds support for offloading TCP segmentation to HW in pass-2 revision of hardware. Both driver level SW TSO for pass1.x chips and HW TSO for pass-2 chip will co-exist. Modified SQ descriptor structures to reflect pass-2 hw implementation. Signed-off-by:
-
Sunil Goutham authored
Since we have moved on to using allocated pages to carve receive buffers instead of netdev_alloc_skb() there is no need to store any pointers for later retrieval. Earlier we had to store skb and skb->data pointers which later are used to handover received packet to network stack. This will avoid an unnecessary cache miss as well. Signed-off-by:
-
Yury Norov authored
The same switch-case repeates for nivc_*_intr functions. In this patch it is moved to a helper nicvf_int_type_to_mask(). By the way: - Unneeded write to NICVF register dropped if int_type is unknown. - netdev_dbg() is used instead of netdev_err(). Signed-off-by:
Yury Norov <yury.norov@auriga.com> Signed-off-by:
Aleksey Makarov <aleksey.makarov@caviumnetworks.com> Acked-by:
Vadim Lomovtsev <Vadim.Lomovtsev@caiumnetworks.com> Signed-off-by:
-
Tim Gardner authored
Signed-off-by: -
Aditya Kali authored
BugLink: http://bugs.launchpad.net/bugs/1546775Signed-off-by:
Aditya Kali <adityakali@google.com> Signed-off-by:
Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Serge Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1546775 allowing root in a non-init user namespace to mount it. This should now be safe, because 1. non-init-root cannot mount a previously unbound subsystem 2. the task doing the mount must be privileged with respect to the user namespace owning the cgroup namespace 3. the mounted subsystem will have its current cgroup as the root dentry. the permissions will be unchanged, so tasks will receive no new privilege over the cgroups which they did not have on the original mounts. Signed-off-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
-
Serge Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1546775 This patch enables cgroup mounting inside userns when a process as appropriate privileges. The cgroup filesystem mounted is rooted at the cgroupns-root. Thus, in a container-setup, only the hierarchy under the cgroupns-root is exposed inside the container. This allows container management tools to run inside the containers without depending on any global state. Signed-off-by:
-
Aditya Kali authored
BugLink: http://bugs.launchpad.net/bugs/1546775 Add a new kernfs api is added to lookup the dentry for a particular kernfs path. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Aditya Kali authored
BugLink: http://bugs.launchpad.net/bugs/1546775 setns on a cgroup namespace is allowed only if task has CAP_SYS_ADMIN in its current user-namespace and over the user-namespace associated with target cgroupns. No implicit cgroup changes happen with attaching to another cgroupns. It is expected that the somone moves the attaching process under the target cgroupns-root. Signed-off-by:
-
Aditya Kali authored
BugLink: http://bugs.launchpad.net/bugs/1546775 Introduce the ability to create new cgroup namespace. The newly created cgroup namespace remembers the cgroup of the process at the point of creation of the cgroup namespace (referred as cgroupns-root). The main purpose of cgroup namespace is to virtualize the contents of /proc/self/cgroup file. Processes inside a cgroup namespace are only able to see paths relative to their namespace root (unless they are moved outside of their cgroupns-root, at which point they will see a relative path from their cgroupns-root). For a correctly setup container this enables container-tools (like libcontainer, lxc, lmctfy, etc.) to create completely virtualized containers without leaking system level cgroup hierarchy to the task. This patch only implements the 'unshare' part of the cgroupns. Signed-off-by:
-
Aditya Kali authored
BugLink: http://bugs.launchpad.net/bugs/1546775 CLONE_NEWCGROUP will be used to create new cgroup namespace. Signed-off-by:
-
Aditya Kali authored
BugLink: http://bugs.launchpad.net/bugs/1546775 The new function kernfs_path_from_node() generates and returns kernfs path of a given kernfs_node relative to a given parent kernfs_node. Signed-off-by:
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Commit d1cd2142 ("pwm: Set enable state properly on failed call to enable") introduced a mutex that is needed to protect internal state of PWM devices. Since that mutex is acquired in pwm_set_polarity() and in pwm_enable() and might potentially block, all PWM devices effectively become "might sleep". It's rather pointless to keep the .can_sleep field around, but given that there are external users let's postpone the removal for the next release cycle. Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> (cherry picked from commit ff01c944) Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1520436 "omap" is NULL so we can't dereference it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Vegard Nossum authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Ran into this on UML: drivers/built-in.o: In function `fsl_pwm_probe': linux/drivers/pwm/pwm-fsl-ftm.c:436: undefined reference to `devm_ioremap_resource' collect2: error: ld returned 1 exit status devm_ioremap_resource() is defined only when HAS_IOMEM is selected. Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Cc: Xiubo Li <Li.Xiubo@freescale.com> Cc: Alison Wang <b18965@freescale.com> Cc: Jingchang Lu <b35083@freescale.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Yuan Yao <yao.yuan@freescale.com> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Neil Armstrong authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Adds support for using a OMAP dual-mode timer with PWM capability as a Linux PWM device. The driver controls the timer by using the dmtimer API. Add a platform_data structure for each pwm-omap-dmtimer nodes containing the dmtimers functions in order to get driver not rely on platform specific functions. Cc: Grant Erickson <marathon96@gmail.com> Cc: NeilBrown <neilb@suse.de> Cc: Joachim Eastwood <manabian@gmail.com> Suggested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
-
Ryo Kodama authored
BugLink: http://bugs.launchpad.net/bugs/1520436 From: Ryo Kodama <ryo.kodama.vz@renesas.com> When period_ns is set to the same value of RCAR_PWM_MAX_CYCLE in rcar_pwm_get_clock_division(), this function should allow such value for improving accuracy of frequency division setting. Signed-off-by:
Ryo Kodama <ryo.kodama.vz@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Instead of silent acceptance of unsupported requested configuration for PWM period and setting the boundary supported value, return -ERANGE to a caller. Duty period value equal to 0 or period is still accepted to allow configuration by PWM sysfs interface, when it is set to 0 by default. For reference this is a list of restrictions on period_ns == 1/freq: | PWM parent clock | parent clock divisor | max freq | min freq | +------------------+----------------------+----------+----------+ | HCLK == 13 MHz | 1 (min) | 50.7 KHz | 198.3 Hz | | HCLK == 13 MHz | 15 (max) | 3.38 KHz | 13.22 Hz | | RTC == 32.7 KHz | 1 (min) | 128 Hz | 0.5 Hz | | RTC == 32.7 KHz | 15 (max) | 8.533 Hz | 0.033 Hz | Note that PWM sysfs interface does not support setting of period more than NSEC_PER_SEC / MAX_INT32 ~ 2 seconds, however this PWM controller supports a period up to 30 seconds. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 The change fixes a problem, if duty_ns is too small in comparison to period_ns (as a valid corner case duty_ns is 0 ns), then due to PWM_DUTY() macro applied on a value the result is overflowed over 8 bits, and instead of the highest bitfield duty cycle value 0xff the invalid duty cycle bitfield value 0x00 is written. For reference the LPC32xx spec defines PWMx_DUTY bitfield description is this way and it seems to be correct: [Low]/[High] = [PWM_DUTY]/[256-PWM_DUTY], where 0 < PWM_DUTY <= 255. In addition according to my oscilloscope measurements LPC32xx PWM is "tristate" in sense that it produces a wave with floating min/max voltage levels for different duty cycle values, for corner cases: PWM_DUTY == 0x01 => signal is in range from -1.05v to 0v .... PWM_DUTY == 0x80 => signal is in range from -0.75v to +0.75v .... PWM_DUTY == 0xff => signal is in range from 0v to +1.05v PWM_DUTY == 0x00 => signal is around 0v, PWM is off Due to this peculiarity on very long period ranges (less than 1KHz) and odd pre-divider values PWM generated wave does not remind a clock shape signal, but rather a heartbit shape signal with positive and negative peaks, so I would recommend to use high-speed HCLK clock as a PWM parent clock and avoid using RTC clock as a parent. The change corrects PWM output in corner cases and prevents any possible overflows in calculation of values for PWM_DUTY and PWM_RELOADV bitfields, thus helper macro definitions may be removed. Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 As a preparatory change for switching LPC32xx mach support to common clock framework fix clk_enable/clk_disable calls without matching clk_prepare/clk_unprepare. The driver can not be used on a platform with common clock framework until clk_prepare/clk_unprepare calls are added, otherwise clk_enable calls will fail and a WARN is generated: # echo 1 > /sys/bus/platform/drivers/lpc32xx-pwm/4005c000.pwm/pwm/pwmchip0/pwm0/enable ------------[ cut here ]------------ WARNING: CPU: 0 PID: 701 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4() Modules linked in: sc16is7xx CPU: 0 PID: 701 Comm: sh Tainted: G W 4.3.0-rc2+ #171 Hardware name: LPC32XX SoC (Flattened Device Tree) Backtrace: [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c) [<>] (show_stack) from [<>] (dump_stack+0x20/0x28) [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8) [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c) [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4) [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38) [<>] (clk_enable) from [<>] (lpc32xx_pwm_enable+0x1c/0x40) [<>] (lpc32xx_pwm_enable) from [<>] (pwm_enable+0x48/0x5c) [<>] (pwm_enable) from [<>] (pwm_enable_store+0x5c/0x78) [<>] (pwm_enable_store) from [<>] (dev_attr_store+0x20/0x2c) [<>] (dev_attr_store) from [<>] (sysfs_kf_write+0x44/0x50) [<>] (sysfs_kf_write) from [<>] (kernfs_fop_write+0x134/0x194) [<>] (kernfs_fop_write) from [<>] (__vfs_write+0x34/0xdc) [<>] (__vfs_write) from [<>] (vfs_write+0xb8/0x140) [<>] (vfs_write) from [<>] (SyS_write+0x50/0x90) [<>] (SyS_write) from [<>] (ret_fast_syscall+0x0/0x38) Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 LPC32xx SoC has two independent PWM controllers, they have different clock parents, clock gates and even slightly different controls, and each of these two PWM controllers has one output channel. Due to almost similar controls arranged in a row it is incorrectly set that there is one PWM controller with two channels, fix this problem, which at the moment prevents separate configuration of different clock parents and gates for both PWM controllers. The change makes previous PWM device node description incompatible with this update. Signed-off-by:
-
Stefan Agner authored
BugLink: http://bugs.launchpad.net/bugs/1520436 A FTM PWM instance enables/disables three clocks: The bus clock, the counter clock and the PWM clock. The bus clock gets enabled on pwm_request, whereas the counter and PWM clocks will be enabled upon pwm_enable. The driver has three closesly related issues when enabling/disabling clocks during suspend/resume: - The three clocks are not treated differently in regards to the individual PWM state enabled/requested. This can lead to clocks getting disabled which have not been enabled in the first place (a PWM channel which only has been requested going through suspend/resume). - When entering suspend, the current behavior relies on the FTM_OUTMASK register: If a PWM output is unmasked, the driver assumes the clocks are enabled. However, some PWM instances have only 2 channels connected (e.g. Vybrid's FTM1). In that case, the FTM_OUTMASK reads 0x3 if all channels are disabled, even if the code wrote 0xff to it before. For those PWM instances, the current approach to detect enabled PWM signals does not work. - A third issue applies to the bus clock only, which can get enabled multiple times (once for each PWM channel of a PWM chip). This is fine, however when entering suspend mode, the clock only gets disabled once. This change introduces a different approach by relying on the enable and prepared counters of the clock framework and using the frameworks PWM signal states to address all three issues. Clocks get disabled during suspend and back enabled on resume regarding to the PWM channels individual state (requested/enabled). Since we do not count the clock enables in the driver, this change no longer clears the Status and Control registers Clock Source Selection (FTM_SC[CLKS]). However, since we disable the selected clock anyway, and we explicitly select the clock source on reenabling a PWM channel this approach should not make a difference in practice. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Setting of PWM_SW_UPDATE is bit different in Intel Broxton compared to the previous generation SoCs. Previously it was OK to set the bit many times (from userspace via sysfs for example) before the PWM is actually enabled. Starting from Intel Broxton it seems that we must set PWM_SW_UPDATE only once before the PWM is enabled. Otherwise it is possible that the PWM does not start properly. Change the sequence of how PWM_SW_UPDATE is programmed so that we only set it in pwm_lpss_config() when the PWM is already enabled. The initial setting of PWM_SW_UPDATE will be done when PWM gets enabled. This should make the driver work with the previous generation Intel SoCs and Broxton. Add also small delay after the bit is set to let the hardware propagate it properly. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1520436 We have two users of core part right now. Let them to select core part automatically. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
qipeng.zha authored
BugLink: http://bugs.launchpad.net/bugs/1520436 For Broxton PWM controller, base unit is defined as 8-bit integer and 14-bit fraction, so need to update base unit setting to output wave with right frequency. Signed-off-by:
Qipeng Zha <qipeng.zha@intel.com> Acked-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1520436Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1520436 It's possible that the PWM clock becomes an orphan. So better check the result of clk_get_rate() in order to prevent a division by zero. Signed-off-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Currently pwm-bcm2835 assumes a fixed clock rate and stores the resulting scaler in the driver structure. But with the upcoming PWM clock support for clk-bcm2835 the rate could change, so calculate the scaler in the ->config() callback. Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1520436 The LPSS PWM driver calls pwm_lpss_disable() when the PWM device is released (for example unexported from sysfs). This in turn calls pm_runtime_put() which makes runtime PM count to be unbalanced if the device has not been enabled at this point. This is easy to reproduce: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # echo 0 > unexport The count is unbalanced and prevents the PWM device from being powered on next time. Fix this by removing ->free() callback. There are no resources to be released anyway. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1520436Signed-off-by:
-
Andy Whitcroft authored
Fix a number of KVP parameter parsing issues: 1) we should not be separating the prefix and instance numbers with an '_', 2) IPADDR/NETMASK instance 0 does have a suffix which we do not provide, 3) GATEWAY instance 0 is inconsistant, 4) IPv6 should be configured whether IPv4 is DHCP or not, and 5) DHCP mode is selected via BOOTPROTO=dhcp not DHCP=yes. BugLink: http://bugs.launchpad.net/bugs/1540586Signed-off-by:
Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1540586Signed-off-by:
-
Tycho Andersen authored
Operations with the GENL_ADMIN_PERM flag fail permissions checks because this flag means we call netlink_capable, which uses the init user ns. Instead, let's introduce a new flag, GENL_UNS_ADMIN_PERM for operations which should be allowed inside a user namespace. The motivation for this is to be able to run openvswitch in unprivileged containers. I've tested this and it seems to work, but I really have no idea about the security consequences of this patch, so thoughts would be much appreciated. v2: use the GENL_UNS_ADMIN_PERM flag instead of a check in each function v3: use separate ifs for UNS_ADMIN_PERM and ADMIN_PERM, instead of one massive one Reported-by:James Page <james.page@canonical.com> Signed-off-by:
Tycho Andersen <tycho.andersen@canonical.com> CC: Eric Biederman <ebiederm@xmission.com> CC: Pravin Shelar <pshelar@ovn.org> CC: Justin Pettit <jpettit@nicira.com> CC: "David S. Miller" <davem@davemloft.net> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
