Re: [PATCH 4/6] dt-bindings: interrupt-controller: RISC-V local interrupt controller docs
On Tue, Jul 31, 2018 at 04:37:14PM -0600, Rob Herring wrote: > On Wed, Jul 25, 2018 at 11:36:47AM +0200, Christoph Hellwig wrote: > > From: Palmer Dabbelt > > > > This patch adds documentation on the RISC-V local interrupt controller, > > which is a per-hart interrupt controller that manages all interrupts > > entering a RISC-V hart. This interrupt controller is present on all > > RISC-V systems. > > > > Signed-off-by: Palmer Dabbelt > > --- > > .../interrupt-controller/riscv,cpu-intc.txt | 41 +++ > > 1 file changed, 41 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt > > My questions and comments on the prior version from Palmer remain. Can you point to these questions please? I don't even rember when this was last posted as it must have been a long time ago.
Re: [PATCH 4/4] cpufreq: intel_pstate: enable boost for Skylake Xeon
Giovanni Gherdovich writes: > On Mon, 2018-07-30 at 11:32 -0700, Francisco Jerez wrote: >> Mel Gorman writes: >> >> > On Sat, Jul 28, 2018 at 01:21:51PM -0700, Francisco Jerez wrote: >> > > > > Please revert this series, it led to significant energy usage and >> > > > > graphics performance regressions [1]. The reasons are roughly the >> > > > > ones >> > > > > we discussed by e-mail off-list last April: This causes the >> > > > > intel_pstate >> > > > > driver to decrease the EPP to zero when the workload blocks on IO >> > > > > frequently enough, which for the regressing benchmarks detailed in >> > > > > [1] >> > > > > is a symptom of the workload being heavily IO-bound, which means they >> > > > > won't benefit at all from the EPP boost since they aren't >> > > > > significantly >> > > > > CPU-bound, and they will suffer a decrease in parallelism due to the >> > > > > active CPU core using a larger fraction of the TDP in order to >> > > > > achieve >> > > > > the same work, causing the GPU to have a lower power budget >> > > > > available, >> > > > > leading to a decrease in system performance. >> > > > >> > > > It slices both ways. >> > > >> > > I don't think it's acceptable to land an optimization that trades >> > > performance of one use-case for another, >> > >> > The same logic applies to a revert >> >> No, it doesn't, the responsibility of addressing the fallout from a >> change that happens to hurt performance even though it was supposed to >> improve it lies on the author of the change, not on the reporter of the >> regression. > > The server and desktop worlds have different characteristics and needs, which > in this particular case appear to be conflicting. Luckily we can can > differentiate the two scenarios (as in the bugfix patch by Srinivas a few > hours ago). > I'm skeptical that the needs of the server and desktop world are really as different and conflicting as this discussion may make them seem. In a server environment it can be as much (if not more) of a factor how many requests the system can process per second rather than the latency of any individual request (since the latency of the network can easily be an order of magnitude higher than the latency reduction that can possibly be achieved by tricking the HWP into reacting faster). I'm not convinced about the usefulness of trading the former for the latter in a server environment, particularly since we could achieve both goals simultaneously. >> The task scheduler does go through the effort of attempting to re-use >> the most frequently active CPU when a task wakes up, at least last time >> I checked. > > Unfortunately that doesn't happen in practice; the load balancer in the > scheduler is in a constant tension between spreading tasks evenly across all > cores (necessary when the machine is under heavy load) and packing on just a > few (which makes more sense when only a few threads are working and the box is > almost idle otherwise). Recent evolutions favour spreading. We often observe > tasks helplessly bounce from core to core losing all their accrued utilisation > score, and intel_pstate (with or without HWP) penalizes that. > That's unfortunate. Luckily it's easy enough for the cpufreq governor to differentiate those cases from the applications that have enough parallelism to utilize at least one system resource close to its maximum throughput and become non-CPU-bound. > On Mon, 2018-07-30 at 11:32 -0700, Francisco Jerez wrote: >> Mel Gorman writes: >> >> [...] >> > One pattern is a small fsync which ends up context switching between >> > the process and a journalling thread (may be dedicated thread, may be >> > workqueue depending on filesystem) and the process waking again in the >> > very near future on IO completion. While the workload may be single >> > threaded, more than one core is in use because of how the short sleeps >> > migrate the task to other cores. HWP does not necessarily notice that >> > the task is quite CPU-intensive due to the migrations and so the >> > performance suffers. >> > >> > Some effort is made to minimise the number of cores used with this sort >> > of waker/wakee relationship but it's not necessarily enough for HWP to >> > boost the frequency. Minimally, the journalling thread woken up will >> > not wake on the same CPU as the IO issuer except under extremely heavily >> > utilisation and this is not likely to change (stacking stacks too often >> > increases wakeup latency). >> > >> >> The task scheduler does go through the effort of attempting to re-use >> the most frequently active CPU when a task wakes up, at least last time >> I checked. But yes some migration patterns can exacerbate the downward >> bias of the response of the HWP to an intermittent workload, primarily >> in cases where the application is unable to take advantage of the >> parallelism between CPU and the IO device involved, like you're >> describing above. > > Unfortunately that doesn't happen i
Re: [PATCH 7/9] irqchip: add a RISC-V PLIC driver
On Tue, Jul 31, 2018 at 05:38:01PM -0700, Atish Patra wrote: > Some typos in the above repo in the PLIC driver patch. The following > changes are required. Inline patch below Thanks, I'll fold this in. > With the above changes, I am able to boot quite far. But it still crashes > which may be a driver issue. I might have missed something while merging It probably is. For now I want the qemu virt machine to boot the kernel at least as that unblocks a lot of things like enabling CI bots and people being able to actually hack and test their contributions upstream.
Re: [PATCH] timers: fix offset calculation when the expires align with LVL_GRAN
On Wed, 1 Aug 2018, Xu YiPing wrote:
> On 2018/7/31 22:34, Thomas Gleixner wrote:
> >
> >
> > On Tue, 31 Jul 2018, Thomas Gleixner wrote:
> >
> >> On Tue, 31 Jul 2018, Xu YiPing wrote:
> >>> On 2018/7/30 19:03, Thomas Gleixner wrote:
>
> __internal_add_timer(base, timer)
> {
> idx = calc_wheel_index(1, 1)
> {
> delta = 1 - 1;<- 0
>
> if (0 < LVL_START(1))
> idx = calc_index(1, 0)
> {
> expires = (1 + LVL_GRAN(0) - 1) >> LVL_SHIFT(0);
> > expires = 0
> >>>
> >>> LVL_GRAN(0) = 1 and LVL_SHIFT(0) = 0
> >>>
> >>> after the calculation, expires = 1 ?
> >>
> >> Indeed. You're right. Math is hard... So the index would be 1 and still not
> >> fulfil the below:
> >
> > Hmm, crap. Let me think about it some more. 34C is way too hot to think.
> >
>
> when the expire is aligned with LVL_GRAN(x), it could be triggered at
> expire,
> no need to wait another LVL_GRAN(x).
>
> just a little improvement, useful when expire is small.
The expire early problem still persists:
schedule_timeout(x)
expires = jiffies + x;
mod_timer(timer, expires);
This will return _BEFORE_ X jiffies have elapsed in 99% of the cases, so it's
not a little improvement, it's a big regression.
Again for schedule_timeout(1):
|---|---||
tick ticktick
jiffies jiffies + 1jiffies + 2
| |
| Any timer armed | ^
| here must be | |
| queued here -|
| |
| Any timer armed | ^
| here must be | |
| queued here -|
The only case where your change would be correct is if _all_ timers are
armed exactly at the jiffies boundary. Can you guarantee that? Not at all.
And even hrtiemrs suffer from this issue when high resolution mode is
disabled because then they are expired on the tick boundary as well and if
the expiry time is past the current time at the tick boundary then the
timer will be expired one tick later.
It's a fundamental property of timers which are driven by a periodic tick
and you can argue in circles it wont change.
Thanks,
tglx
Re: [PATCH 6/6] dt-bindings: interrupt-controller: RISC-V PLIC documentation
On Tue, Jul 31, 2018 at 04:46:30PM -0600, Rob Herring wrote: > Perhaps this should be 'sifive,plic0' Excepet for the fact this the old name has already been in shipping hardware and release of qemu and other emulators it should. > Normally this would have an SoC specific compatible too. Sometimes we > can get away without, but it doesn't seem like the PLIC is very tightly > specified nor has common implementations. It is a giant f***cking mess to be honest. Adding a highlevel spec to the ISA but not a register layout is completely idotic, but if you look at the current riscv-sw list this decision is still defended by SiFive / the RISC-V foundation. The whole stale of the RISC-V platform Ecosystem is rather pathetic unfortunately, and people don't seem to be willing to learn from past good practice nor mistakes in ARM land.
Re: bisected - arm64 kvm unit test failures
On Wed, 01 Aug 2018 07:02:25 +0100, Mike Galbraith wrote: > > [1 ] > On Wed, 2018-08-01 at 06:35 +0100, Marc Zyngier wrote: > > > > Is it something that is reproducible with the current mainline (non-RT)? > > These waters are a bit muddy, it's config dependent. I'm trying to > generate a reproducing !RT config for -rc7 as we speak. If I build > openSUSE/master-default, it does NOT reproduce. That with the bisect > config just finished building, and yup, it reproduced > (attached). Thanks for that. > > Every RT tree 4.16..master.today reproduces, and is fixed up (modulo > the RT specific failure) by reverting the fingered commit. > > > Pretty worrying. What HW is that on? > > Box is a 4 node/64 core TaiShan 2280. Is that what is also known as D05/HIP07, with 64 Cortex-A72? If so, I think we have one somewhere... I'll try to reproduce it once I'm back into the office (things seem to run just fine on my A72-based laptop, so it definitely smells of being config dependent). Cheers, M. -- Jazz is not dead, it just smell funny.
Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
[+Cc linux-crypto] Hi Jason, Apologies for starting a new thread, but this patch apparently wasn't Cc'ed to linux-crypto, despite adding over 24000 lines of crypto code. So much for WireGuard being only 4000 lines :-) (For anyone else like me who didn't receive the patch, it can be found at https://patchwork.ozlabs.org/patch/951763/) I have some preliminary comments below. On Tue, 31 Jul 2018 21:11:01 +0200, Jason A. Donenfeld wrote: > [PATCH v1 2/3] zinc: Introduce minimal cryptography library > > Zinc stands for "Zinc Is Not crypto/". It's also short, easy to type, > and plays nicely with the recent trend of naming crypto libraries after > elements. The guiding principle is "don't overdo it". It's less of a > library and more of a directory tree for organizing well-curated direct > implementations of cryptography primitives. > > Zinc is a new cryptography API that is much more minimal and lower-level > than the current one. It intends to complement it and provide a basis > upon which the current crypto API might build, and perhaps someday Zinc > may altogether supplant the current crypto API. It is motivated by > three primary observations in crypto API design: > > * Highly composable "cipher modes" and related abstractions from > 90s cryptographers did not turn out to be as terrific an idea as > hoped, leading to a host of API misuse problems. > > * Most programmers are afraid of crypto code, and so prefer to > integrate it into libraries in a highly abstracted manner, so as to > shield themselves from implementation details. Cryptographers, on > the other hand, prefer simple direct implementations, which they're > able to verify for high assurance and optimize in accordance with > their expertise. > > * Overly abstracted and flexible cryptography APIs lead to a host of > dangerous problems and performance issues. The kernel is in the > business usually not of coming up with new uses of crypto, but > rather implementing various constructions, which means it essentially > needs a library of primitives, not a highly abstracted enterprise-ready > pluggable system, with a few particular exceptions. > > This last observation has seen itself play out several times over and > over again within the kernel: > > * The perennial move of actual primitives away from crypto/ and into > lib/, so that users can actually call these functions directly with > no overhead and without lots of allocations, function pointers, > string specifier parsing, and general clunkiness. For example: > sha256, chacha20, siphash, sha1, and so forth live in lib/ rather > than in crypto/. Zinc intends to stop the cluttering of lib/ and > introduce these direct primitives into their proper place, lib/zinc/. > > * An abundance of misuse bugs with the present crypto API that have > been very unpleasant to clean up. > > * A hesitance to even use cryptography, because of the overhead and > headaches involved in accessing the routines. > > Zinc goes in a rather different direction. Rather than providing a > thoroughly designed and abstracted API, Zinc gives you simple functions, > which implement some primitive, or some particular and specific > construction of primitives. It is not dynamic in the least, though one > could imagine implementing a complex dynamic dispatch mechanism (such as > the current crypto API) on top of these basic functions. After all, > dynamic dispatch is usually needed for applications with cipher agility, > such as IPsec, dm-crypt, AF_ALG, and so forth, and the existing crypto > API will continue to play that role. However, Zinc will provide a non- > haphazard way of directly utilizing crypto routines in applications > that do have neither need nor desire for abstraction and dynamic > dispatch. > > It also organizes the implementations in a simple, straight-forward, > and direct manner, making it enjoyable and intuitive to work on. > Rather than moving optimized assembly implementations into arch/, it > keeps them all together in lib/zinc/, making it simple and obvious to > compare and contrast what's happening. This is, notably, exactly what > the lib/raid6/ tree does, and that seems to work out rather well. It's > also the pattern of most successful crypto libraries. Likewise, the > cascade of architecture-specific functions is done as ifdefs within one > file, so that it's easy and obvious and clear what's happening, how each > architecture differs, and how to optimize for shared patterns. This is > very much preferable to architecture-specific file splitting. > > All implementations have been extensively tested and fuzzed, and are > selected for their quality, trustworthiness, and performance. Wherever > possible and performant, formally verified implementations are used, > such as those from HACL* [1] and Fiat-Crypto [2]. The routines also take > special care to zero out secrets using memzero_explicit (and
[PATCH v3 1/2] dt-bindings: spi: add DT bindings for UniPhier SPI controller
From: Kunihiko Hayashi
Add DT bindings for SPI controller implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Keiji Hayashibara
Reviewed-by: Rob Herring
---
.../devicetree/bindings/spi/spi-uniphier.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-uniphier.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-uniphier.txt
b/Documentation/devicetree/bindings/spi/spi-uniphier.txt
new file mode 100644
index 000..504a4ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-uniphier.txt
@@ -0,0 +1,22 @@
+Socionext UniPhier SPI controller driver
+
+UniPhier SoCs have SCSSI which supports SPI single channel.
+
+Required properties:
+ - compatible: should be "socionext,uniphier-scssi"
+ - reg: address and length of the spi master registers
+ - #address-cells: must be <1>, see spi-bus.txt
+ - #size-cells: must be <0>, see spi-bus.txt
+ - clocks: A phandle to the clock for the device.
+ - resets: A phandle to the reset control for the device.
+
+Example:
+
+spi0: spi@54006000 {
+ compatible = "socionext,uniphier-scssi";
+ reg = <0x54006000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&peri_clk 11>;
+ resets = <&peri_rst 11>;
+};
--
2.7.4
[PATCH v3 0/2] add SPI controller driver for UniPhier SoCs
This series adds support for SPI controller driver implemented on UniPhier SoCs. Changes since v2: - remove check code of clock divider in uniphier_spi_set_baudrate(). - change irq from struct variable to stack variable. - other trivial change. Keiji Hayashibara (1): spi: add SPI controller driver for UniPhier SoC Kunihiko Hayashi (1): dt-bindings: spi: add DT bindings for UniPhier SPI controller .../devicetree/bindings/spi/spi-uniphier.txt | 22 + drivers/spi/Kconfig| 13 + drivers/spi/Makefile | 1 + drivers/spi/spi-uniphier.c | 525 + 4 files changed, 561 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-uniphier.txt create mode 100644 drivers/spi/spi-uniphier.c -- 2.7.4
[PATCH v3 2/2] spi: add SPI controller driver for UniPhier SoC
Add SPI controller driver implemented in Socionext UniPhier SoCs.
UniPhier SoCs have two types SPI controllers; SCSSI supports a
single channel, and MCSSI supports multiple channels.
This driver supports SCSSI only.
This controller has 32bit TX/RX FIFO with depth of eight entry,
and supports the SPI master mode only.
This commit is implemented in PIO transfer mode, not DMA transfer.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Keiji Hayashibara
---
drivers/spi/Kconfig| 13 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-uniphier.c | 525 +
3 files changed, 539 insertions(+)
create mode 100644 drivers/spi/spi-uniphier.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ad5d68e..671d078 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -688,6 +688,19 @@ config SPI_TXX9
help
SPI driver for Toshiba TXx9 MIPS SoCs
+config SPI_UNIPHIER
+ tristate "Socionext UniPhier SPI Controller"
+ depends on (ARCH_UNIPHIER || COMPILE_TEST) && OF
+ help
+ This enables a driver for the Socionext UniPhier SoC SCSSI SPI
controller.
+
+ UniPhier SoCs have SCSSI and MCSSI SPI controllers.
+ Every UniPhier SoC has SCSSI which supports single channel.
+ Older UniPhier Pro4/Pro5 also has MCSSI which support multiple
channels.
+ This driver supports SCSSI only.
+
+ If your SoC supports SCSSI, say Y here.
+
config SPI_XCOMM
tristate "Analog Devices AD-FMCOMMS1-EBZ SPI-I2C-bridge driver"
depends on I2C
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index cb1f437..a90d559 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -101,6 +101,7 @@ spi-thunderx-objs := spi-cavium.o
spi-cavium-thunderx.o
obj-$(CONFIG_SPI_THUNDERX) += spi-thunderx.o
obj-$(CONFIG_SPI_TOPCLIFF_PCH) += spi-topcliff-pch.o
obj-$(CONFIG_SPI_TXX9) += spi-txx9.o
+obj-$(CONFIG_SPI_UNIPHIER) += spi-uniphier.o
obj-$(CONFIG_SPI_XCOMM)+= spi-xcomm.o
obj-$(CONFIG_SPI_XILINX) += spi-xilinx.o
obj-$(CONFIG_SPI_XLP) += spi-xlp.o
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
new file mode 100644
index 000..0899854
--- /dev/null
+++ b/drivers/spi/spi-uniphier.c
@@ -0,0 +1,525 @@
+// SPDX-License-Identifier: GPL-2.0
+// spi-uniphier.c - Socionext UniPhier SPI controller driver
+// Copyright 2012 Panasonic Corporation
+// Copyright 2016-2018 Socionext Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define SSI_TIMEOUT_MS 2000
+#define SSI_MAX_CLK_DIVIDER254
+#define SSI_MIN_CLK_DIVIDER4
+
+struct uniphier_spi_priv {
+ void __iomem *base;
+ struct clk *clk;
+ struct spi_master *master;
+ struct completion xfer_done;
+
+ int error;
+ unsigned int tx_bytes;
+ unsigned int rx_bytes;
+ const u8 *tx_buf;
+ u8 *rx_buf;
+
+ bool is_save_param;
+ u8 bits_per_word;
+ u16 mode;
+ u32 speed_hz;
+};
+
+#define SSI_CTL0x00
+#define SSI_CTL_EN BIT(0)
+
+#define SSI_CKS0x04
+#define SSI_CKS_CKRAT_MASK GENMASK(7, 0)
+#define SSI_CKS_CKPHSBIT(14)
+#define SSI_CKS_CKINIT BIT(13)
+#define SSI_CKS_CKDLYBIT(12)
+
+#define SSI_TXWDS 0x08
+#define SSI_TXWDS_WDLEN_MASK GENMASK(13, 8)
+#define SSI_TXWDS_TDTF_MASK GENMASK(7, 6)
+#define SSI_TXWDS_DTLEN_MASK GENMASK(5, 0)
+
+#define SSI_RXWDS 0x0c
+#define SSI_RXWDS_DTLEN_MASK GENMASK(5, 0)
+
+#define SSI_FPS0x10
+#define SSI_FPS_FSPOLBIT(15)
+#define SSI_FPS_FSTRTBIT(14)
+
+#define SSI_SR 0x14
+#define SSI_SR_RNE BIT(0)
+
+#define SSI_IE 0x18
+#define SSI_IE_RCIE BIT(3)
+#define SSI_IE_RORIE BIT(0)
+
+#define SSI_IS 0x1c
+#define SSI_IS_RXRS BIT(9)
+#define SSI_IS_RCID BIT(3)
+#define SSI_IS_RORID BIT(0)
+
+#define SSI_IC 0x1c
+#define SSI_IC_TCIC BIT(4)
+#define SSI_IC_RCIC BIT(3)
+#define SSI_IC_RORIC BIT(0)
+
+#define SSI_FC 0x20
+#define SSI_FC_TXFFL BIT(12)
+#define SSI_FC_TXFTH_MASKGENMASK(11, 8)
+#define SSI_FC_RXFFL BIT(4)
+#define SSI_FC_RXFTH_MASKGENMASK(3, 0)
+
+#define SSI_TXDR 0x24
+#define SSI_RXDR 0x24
+
+#define SSI_FIFO_DEPTH 8U
+
+static inline unsigned int bytes_per_word(unsigned int bits)
+{
+ return bits <= 8 ? 1 : (bits <= 16 ? 2 : 4);
+}
+
+static inline void uniphier_spi_irq_enable(struct spi_device *spi, u32 mask)
+{
+ struct uniphier_s
Re: [PATCH] PM / devfreq: Generic cpufreq governor
On Tue, Jul 31, 2018 at 9:21 PM, wrote: > On 2018-07-31 01:00, Rafael J. Wysocki wrote: >> >> On Mon, Jul 30, 2018 at 8:58 PM, wrote: >>> >>> On 2018-07-29 03:52, Rafael J. Wysocki wrote: On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan wrote: > > > Many CPU architectures have caches that can scale independent of the > CPUs. > Frequency scaling of the caches is necessary to make sure the cache is > not > a performance bottleneck that leads to poor performance and power. The > same > idea applies for RAM/DDR. > > To achieve this, this patch adds a generic devfreq governor that can > listen > to the frequency transitions of each CPU frequency domain and then > adjusts > the frequency of the cache (or any devfreq device) based on the > frequency > of the CPUs. > > To decide the frequency of the device, the governor does one of the > following: > > * Uses a CPU frequency to device frequency mapping table > - Either one mapping table used for all CPU freq policies (typically > used > for system with homogeneous cores/clusters that have the same OPPs. > - One mapping table per CPU freq policy (typically used for ASMP > systems > with heterogeneous CPUs with different OPPs) > > OR > > * Scales the device frequency in proportion to the CPU frequency. So, > if > the CPUs are running at their max frequency, the device runs at its > max > frequency. If the CPUs are running at their min frequency, the > device > runs at its min frequency. And interpolated for frequencies in > between. While not having looked at the details of the patch yet, I would change the name of the feature to "Generic cpufreq transition governor" to make it somewhat less ambiguous. >>> >>> >>> >>> In my opinion it makes it look MORE like this is a cpufreq governor. How >>> about the following? >>> PM / devfreq: Generic cpufreq to devfreq mapping governor >>> Seem a lot more clear to me. >> >> >> Well, it's not just mapping, but also it triggers on cpufreq transitions >> AFAICS. > > > Right, but I'm not sure that's the most important aspect of this governor. What are the other events triggering it, then? >> Which makes me wonder if the approach here is the right one at all. >> >> Shouldn't the cpufreq driver be hooked up to the related HW through >> the OPP framework and sharing access with devfreq rather? > > Not sure what you mean here. This devfreq governor is orthogonal to what the > cpufreq driver does with its HW. This is just trying to scale L3 or DDR or > whatever other device based on current CPU frequency. Not all CPUfreq > drivers support OPP. And even if they do, I don't see how it's relevant > here. OK, fair enough.
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Tue, Jul 31, 2018 at 9:31 PM, wrote: > On 2018-07-31 00:59, Quentin Perret wrote: >> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote: >> [...] >>> >>> If it's going to be a different aggregation from what's done for >>> frequency >>> guidance, I don't see the point of having this inside schedutil. Why not >>> keep it inside the scheduler files? >> >> >> This code basically results from a discussion we had with Peter on v4. >> Keeping everything centralized can make sense from a maintenance >> perspective, I think. That makes it easy to see the impact of any change >> to utilization signals for both EAS and schedutil. > > > In that case, I'd argue it makes more sense to keep the code centralized in > the scheduler. The scheduler can let schedutil know about the utilization > after it aggregates them. There's no need for a cpufreq governor to know > that there are scheduling classes or how many there are. And the scheduler > can then choose to aggregate one way for task packing and another way for > frequency guidance. Also the aggregate utilization may be used by cpuidle governors in principle to decide how deep they can go with idle state selection.
hallo Schönheit
Wie geht es Ihnen heute? Verzeih mir, dass ich deinen Frieden gestört habe, ich verstehe meine Herangehensweise vielleicht sehr ungeschickt und unhöflich, bitte ich bitte, dass du mir verzeihst, ein Eindringling zu sein. Ich bin Wesley mit Namen, ich bin aus dem Vereinigten Staaten von Amerika, ich bin derzeit auf der Suche nach einer Beziehung, in der ich mich geliebt fühle. Es wird dich überraschen zu wissen, dass ich kein Fan von Social Media bin. Ich hoffe, du wirst so freundlich sein, mir mehr über dich zu erzählen, wenn es dir nichts ausmacht. Hoffe bald von dir zu hören. Grüße, Wesley.
Re: [PATCH] prctl: add PR_[GS]ET_KILLABLE
On Tue, 2018-07-31 at 18:26 +0200, Jann Horn wrote: > On Mon, Jul 30, 2018 at 10:01 AM Jürg Billeter wrote: > > [...] > > diff --git a/kernel/sys.c b/kernel/sys.c > > index 38509dc1f77b..264de630d548 100644 > > --- a/kernel/sys.c > > +++ b/kernel/sys.c > > [...] > > + case PR_SET_KILLABLE: > > + if (arg2 != 1 || arg3 || arg4 || arg5) > > + return -EINVAL; > > + me->signal->flags &= ~SIGNAL_UNKILLABLE; > > + break; > > I don't have an opinion on this patchset otherwise, but should this > prctl maybe block PR_SET_KILLABLE if you're actually the real init > process? This seems like it could potentially lead to weird things. While I don't expect global init to use this, I can't think of a good reason to disallow it in the kernel. Do you have specific concerns or is the code in kernel/fork.c the only reason? I prefer avoiding special cases unless really required. > This code in kernel/fork.c seems to rely on the fact that global init > is SIGNAL_UNKILLABLE, and probably also leads to weirdness if > container init is non-SIGNAL_UNKILLABLE: Yes, Oleg has mentioned this as well. I have to change copy_process() to directly check for the PID namespace root process instead of checking for SIGNAL_UNKILLABLE. Jürg
[PATCH] arm64: dts: allwinner: a64: add csi regulator to sopine dts
sopine board has a csi. enable supply dvdd-1v8-csi, dovdd-2v8-csi and
avdd-2v8-csi on board to access external camera connected to it.
Signed-off-by: Akash Gajjar
---
.../arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index 43418bd..256229b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -68,6 +68,13 @@
#include "axp803.dtsi"
+®_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-name = "dovdd-csi";
+};
+
®_aldo2 {
regulator-always-on;
regulator-min-microvolt = <180>;
@@ -112,6 +119,13 @@
regulator-name = "vdd-sys";
};
+®_dldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-name = "avdd-csi";
+};
+
®_eldo1 {
regulator-always-on;
regulator-min-microvolt = <180>;
@@ -119,6 +133,13 @@
regulator-name = "vdd-1v8-lpddr";
};
+®_eldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vdd-csi";
+};
+
®_fldo1 {
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
--
2.7.4
[PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag
chan->tag has no terminal char at last which will result in printing messy
code when debugging code. So we should add '\0' for tag.
Signed-off-by: Jun Piao
---
net/9p/trans_virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index d422bfc..49d71d6 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -585,7 +585,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
err = -EINVAL;
goto out_free_vq;
}
- tag = kmalloc(tag_len, GFP_KERNEL);
+ tag = kzalloc(tag_len + 1, GFP_KERNEL);
if (!tag) {
err = -ENOMEM;
goto out_free_vq;
--
Re: bisected - arm64 kvm unit test failures
On Wed, 2018-08-01 at 08:22 +0100, Marc Zyngier wrote: > > > Box is a 4 node/64 core TaiShan 2280. > > Is that what is also known as D05/HIP07, with 64 Cortex-A72? No idea, our rent-a-box web client shows nothing informative. -Mike
Re: [PATCH v7 2/3] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
Hi Sean,
> This adds a driver based on serdev driver for the MediaTek serial protocol
> based on running H:4, which can enable the built-in Bluetooth device inside
> MT7622 SoC.
>
> Signed-off-by: Sean Wang
> ---
> drivers/bluetooth/Kconfig | 11 +
> drivers/bluetooth/Makefile| 2 +
> drivers/bluetooth/btmtkuart.c | 591 ++
> 3 files changed, 604 insertions(+)
> create mode 100644 drivers/bluetooth/btmtkuart.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index f3c643a..5ace676 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -74,6 +74,17 @@ config BT_HCIBTSDIO
> Say Y here to compile support for Bluetooth SDIO devices into the
> kernel or say M to compile it as module (btsdio).
>
> +config BT_MTKUART
> + tristate "MediaTek HCI UART driver"
> + depends on SERIAL_DEV_BUS
> + help
> + MediaTek Bluetooth HCI UART driver.
> + This driver is required if you want to use MediaTek Bluetooth
> + with serial interface.
> +
> + Say Y here to compile support for MediaTek Bluetooth UART devices
> + into the kernel or say M to compile it as module (btmtkuart).
> +
> config BT_HCIUART
> tristate "HCI UART driver"
> depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index ec16c55..12ad6e9 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -25,6 +25,8 @@ obj-$(CONFIG_BT_BCM)+= btbcm.o
> obj-$(CONFIG_BT_RTL) += btrtl.o
> obj-$(CONFIG_BT_QCA) += btqca.o
>
> +obj-$(CONFIG_BT_MTKUART) += btmtkuart.o
> +
> obj-$(CONFIG_BT_HCIUART_NOKIA)+= hci_nokia.o
>
> obj-$(CONFIG_BT_HCIRSI) += btrsi.o
> diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> new file mode 100644
> index 000..def3d4b
> --- /dev/null
> +++ b/drivers/bluetooth/btmtkuart.c
> @@ -0,0 +1,591 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 MediaTek Inc.
> +
> +/*
> + * Bluetooth support for MediaTek serial devices
> + *
> + * Author: Sean Wang
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "h4_recv.h"
> +
> +#define VERSION "0.1"
> +
> +#define FIRMWARE_MT7622 "mediatek/mt7622pr2h.bin"
> +
> +#define MTK_STP_TLR_SIZE 2
> +
> +#define BTMTKUART_TX_STATE_ACTIVE1
> +#define BTMTKUART_TX_STATE_WAKEUP2
> +
> +enum {
> + MTK_WMT_PATCH_DWNLD = 0x1,
> + MTK_WMT_FUNC_CTRL = 0x6,
> + MTK_WMT_RST = 0x7
> +};
> +
> +struct mtk_stp_hdr {
> + u8 prefix;
> + u8 dlen1:4;
> + u8 type:4;
So this is the hard one. I doubt that this is endian safe. It is also some fun
way of packing it. Can you find a better variable name and just pack it into an
u16 in the function. And then also label this __le16 or __be16 accordingly.
> + u8 dlen2;
> + u8 cs;
Are you checking the checksum on receive?
> +} __packed;
> +
> +struct mtk_wmt_hdr {
> + u8 dir;
> + u8 op;
> + __le16 dlen;
> + u8 flag;
> +} __packed;
> +
> +struct mtk_hci_wmt_cmd {
> + struct mtk_wmt_hdr hdr;
> + u8 data[256];
> +} __packed;
> +
> +struct btmtkuart_dev {
> + struct hci_dev *hdev;
> + struct serdev_device *serdev;
> +
> + struct work_struct tx_work;
> + unsigned long tx_state;
> + struct sk_buff_head txq;
> +
> + struct sk_buff *rx_skb;
> +
> + struct mtk_stp_splitter *sp;
This should be a leftover and no longer be needed.
> + struct clk *clk;
Move the struct clk below struct serdev_device.
> +
> + u8 stp_pad[6];
> + u8 stp_cursor;
> + u16 stp_dlen;
> +};
> +
> +static int mtk_hci_wmt_sync(struct hci_dev *hdev, u8 op, u8 flag, u16 plen,
> + const void *param)
> +{
> + struct mtk_hci_wmt_cmd wc;
> + struct mtk_wmt_hdr *hdr;
> + struct sk_buff *skb;
> + u32 hlen;
> +
> + hlen = sizeof(*hdr) + plen;
> + if (hlen > 255)
> + return -EINVAL;
> +
> + hdr = (struct mtk_wmt_hdr *)&wc;
> + hdr->dir = 1;
> + hdr->op = op;
> + hdr->dlen = cpu_to_le16(plen + 1);
> + hdr->flag = flag;
> + memcpy(wc.data, param, plen);
> +
> + atomic_inc(&hdev->cmd_cnt);
Why are you doing this one. It will need a comment here if really needed.
However I doubt that this is needed. You are only using it from hdev->setup and
hdev->shutdown callbacks.
> +
> + skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT,
> + HCI_INIT_TIMEOUT);
> +
> + if (IS_ERR(skb)) {
> + int err = PTR_ERR(skb);
> +
> + bt_dev_err(hdev, "Failed to send wmt cmd (%d)", err);
> + return err;
> + }
> +
> + kfree_skb(skb);
>
Re: [PATCH] prctl: add PR_[GS]ET_KILLABLE
On Wed, Aug 1, 2018 at 9:44 AM Jürg Billeter wrote: > > On Tue, 2018-07-31 at 18:26 +0200, Jann Horn wrote: > > On Mon, Jul 30, 2018 at 10:01 AM Jürg Billeter wrote: > > > > [...] > > > diff --git a/kernel/sys.c b/kernel/sys.c > > > index 38509dc1f77b..264de630d548 100644 > > > --- a/kernel/sys.c > > > +++ b/kernel/sys.c > > > > [...] > > > + case PR_SET_KILLABLE: > > > + if (arg2 != 1 || arg3 || arg4 || arg5) > > > + return -EINVAL; > > > + me->signal->flags &= ~SIGNAL_UNKILLABLE; > > > + break; > > > > I don't have an opinion on this patchset otherwise, but should this > > prctl maybe block PR_SET_KILLABLE if you're actually the real init > > process? This seems like it could potentially lead to weird things. > > While I don't expect global init to use this, I can't think of a good > reason to disallow it in the kernel. Do you have specific concerns or > is the code in kernel/fork.c the only reason? No, I don't have any other specific concerns. > I prefer avoiding special cases unless really required.
Re: [PATCH v12 16/16] arm64: kexec_file: add kaslr support
James,
All the changes mentioned below were applied to my coming v13.
On Fri, Jul 27, 2018 at 10:22:31AM +0100, James Morse wrote:
> Hi Akashi,
>
>
> On 07/27/2018 09:31 AM, AKASHI Takahiro wrote:
> >On Thu, Jul 26, 2018 at 02:40:49PM +0100, James Morse wrote:
> >>On 24/07/18 07:57, AKASHI Takahiro wrote:
> >>>Adding "kaslr-seed" to dtb enables triggering kaslr, or kernel virtual
> >>>address randomization, at secondary kernel boot.
> >>Hmm, there are three things that get moved by CONFIG_RANDOMIZE_BASE. The
> >>kernel
> >>physical placement when booted via the EFIstub, the kernel-text VAs and the
> >>location of memory in the linear-map region. Adding the kaslr-seed only
> >>does the
> >>last two.
> >Yes, but I think that I and Mark has agreed that "kaslr" meant
> >"virtual" randomisation, not including "physical" randomisation.
> Okay, I'll update my terminology!
>
>
> >>This means the physical placement of the new kernel is predictable from
> >>/proc/iomem ... but this also tells you the physical placement of the
> >>current
> >>kernel, so I don't think this is a problem.
> >>
> >>
> >>>We always do this as it will have no harm on kaslr-incapable kernel.
> >>>We don't have any "switch" to turn off this feature directly, but still
> >>>can suppress it by passing "nokaslr" as a kernel boot argument.
> >>
> >>>diff --git a/arch/arm64/kernel/machine_kexec_file.c
> >>>b/arch/arm64/kernel/machine_kexec_file.c
> >>>index 7356da5a53d5..47a4fbd0dc34 100644
> >>>--- a/arch/arm64/kernel/machine_kexec_file.c
> >>>+++ b/arch/arm64/kernel/machine_kexec_file.c
> >>>@@ -158,6 +160,12 @@ static int setup_dtb(struct kimage *image,
> >>Don't you need to reserve some space in the area you vmalloc()d for the DT?
> >No, I don't think so.
> >All the data to be loaded are temporarily saved in kexec buffers,
> >which will eventually be copied to target locations in machine_kexec
> >(arm64_relocate_new_kernel, which, unlike its name, will handle
> >not only kernel but also other data as well).
>
> I think we're speaking at cross purposes. Don't you need:
>
> | buf_size += fdt_prop_len("kaslr―seed", sizeof(u64));
>
>
> You can't assume the existing DTB had a kaslr-seed property, and the
> difference may take us over a PAGE_SIZE boundary.
I see, I will add that.
>
> >
> >>
> >>>+ /* add kaslr-seed */
> >>>+ get_random_bytes(&value, sizeof(value));
> >>What happens if the crng isn't ready?
> >>
> >>It looks like this will print a warning that these random-bytes aren't
> >>really up
> >>to standard, but the new kernel doesn't know this happened.
> >>
> >>crng_ready() isn't exposed, all we could do now is
> >>wait_for_random_bytes(), but that may wait forever because we do this
> >>unconditionally.
> >>
> >>I'd prefer to leave this feature until we can check crng_ready(), and skip
> >>adding a dodgy-seed if its not-ready. This avoids polluting the
> >>next-kernel's
> >>entropy pool.
> >OK. I would try to follow the same way as Bhupesh's userspace patch
> >does for kaslr-seed:
> >http://lists.infradead.org/pipermail/kexec/2018-April/020564.html
>
> (I really don't understand this 'copying code from user-space' that happens
> with kexec_file_load)
>
>
> > if (not found kaslr-seed in 1st kernel's dtb)
> > don't care; go ahead
>
> Don' t bother. As you say in the commit-message its harmless if the new
> kernel doesn't support it.
> Always having this would let you use kexec_file_load as a bootloader that
> can get the crng to
> provide decent entropy even if the platform bootloader can't.
OK, but anyway previous "kaslr-seed" will be dropped first.
>
> > else
> > if (current kaslr-seed != 0)
> > error
>
> Don't bother. If this happens its a bug in another part of the kernel that
> doesn't affect this one. We aren't second-guessing the file-system when we
> read the kernel-fd, lets keep this simple.
OK
> > if (crng_ready()) ; FIXME, it's a local macro
> > get_random_bytes(non-blocking)
> > set new kaslr-seed
> > else
> > error
> error? Something like pr_warn_once().
It was changed to pr_notice() since there is nothing wrong.
Thanks,
-Takahiro AKASHI
> I thought the kaslr-seed was added to the entropy pool, but now I look again
> I see its a separate EFI table. So the new kernel will add the same entropy
> ... that doesn't sound clever. (I can't see where its zero'd or
> re-initialised)
>
>
>
> Thanks,
>
> James
Re: [PATCH v2 1/3] overflow.h: Add arithmetic shift helper
The idea is nice, but I don't like the API. The "_overflow" feels too
specific because maybe we could check for other things in the future.
Normally boolean macros should say they are boolean in the name and I
would prefer if it returned zero on failure.
if (!checked_shift(dest, mask, shift)) {
if (!shift_ok(dest, mask, shift)) {
if (!safe_shift(dest, mask, shift)) {
regards,
dan carpenter
[PATCH v13 00/16] subject: arm64: kexec: add kexec_file_load() support
This is the thirteenth round of implementing kexec_file_load() support
on arm64.[1] (See "Changes" below)
Most of the code is based on kexec-tools.
This patch series enables us to
* load the kernel by specifying its file descriptor, instead of user-
filled buffer, at kexec_file_load() system call, and
* optionally verify its signature at load time for trusted boot.
Kernel virtual address randomization is also supported since v9.
Contrary to kexec_load() system call, as we discussed a long time ago,
users may not be allowed to provide a device tree to the 2nd kernel
explicitly, hence enforcing a dt blob of the first kernel to be re-used
internally.
To use kexec_file_load() system call, instead of kexec_load(), at kexec
command, '-s' option must be specified. See [2] for a necessary patch for
kexec-tools.
To analyze a generated crash dump file, use the latest master branch of
crash utility[3]. I always try to submit patches to fix any inconsistencies
introduced in the latest kernel.
Regarding a kernel image verification, a signature must be presented
along with the binary itself. A signature is basically a hash value
calculated against the whole binary data and encrypted by a key which
will be authenticated by one of the system's trusted certificates.
Any attempt to read and load a to-be-kexec-ed kernel image through
a system call will be checked and blocked if the binary's hash value
doesn't match its associated signature.
There are two methods available now:
1. implementing arch-specific verification hook of kexec_file_load()
2. utilizing IMA(Integrity Measurement Architecture)[4] appraisal framework
Before my v7, I believed that my patch only supports (1) but am now
confident that (2) comes free if IMA is enabled and properly configured.
(1) Arch-specific verification hook
If CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_file_load() invokes an arch-
defined (and hence file-format-specific) hook function to check for the
validity of kernel binary.
On x86, a signature is embedded into a PE file (Microsoft's format) header
of binary. Since arm64's "Image" can also be seen as a PE file as far as
CONFIG_EFI is enabled, we adopt this format for kernel signing.
As in the case of UEFI applications, we can create a signed kernel image:
$ sbsign --key ${KEY} --cert ${CERT} Image
You may want to use certs/signing_key.pem, which is intended to be used
for module signing (CONFIG_MODULE_SIG), as ${KEY} and ${CERT} for test
purpose.
(2) IMA appraisal-based
IMA was first introduced in linux in order to meet TCG (Trusted Computing
Group) requirement that all the sensitive files be *measured* before
reading/executing them to detect any untrusted changes/modification.
Then appraisal feature, which allows us to ensure the integrity of
files and even prevent them from reading/executing, was added later.
Meanwhile, kexec_file_load() has been merged since v3.17 and evolved to
enable IMA-appraisal type verification by the commit b804defe4297 ("kexec:
replace call to copy_file_from_fd() with kernel version").
In this scheme, a signature will be stored in a extended file attribute,
"security.ima" while a decryption key is hold in a dedicated keyring,
".ima" or "_ima". All the necessary process of verification is confined
in a secure API, kernel_read_file_from_fd(), called by kexec_file_load().
Please note that powerpc is one of the two architectures now
supporting KEXEC_FILE, and that it wishes to extend IMA,
where a signature may be appended to "vmlinux" file[5], like module
signing, instead of using an extended file attribute.
While IMA meant to be used with TPM (Trusted Platform Module) on secure
platform, IMA is still usable without TPM. Here is an example procedure
about how we can give it a try to run the feature using a self-signed
root ca for demo/test purposes:
1) Generate needed keys and certificates, following "Generate trusted
keys" section in README of ima-evm-utils[6].
2) Build the kernel with the following kernel configurations, specifying
"ima-local-ca.pem" for CONFIG_SYSTEM_TRUSTED_KEYS:
CONFIG_EXT4_FS_SECURITY
CONFIG_INTEGRITY_SIGNATURE
CONFIG_INTEGRITY_ASYMMETRIC_KEYS
CONFIG_INTEGRITY_TRUSTED_KEYRING
CONFIG_IMA
CONFIG_IMA_WRITE_POLICY
CONFIG_IMA_READ_POLICY
CONFIG_IMA_APPRAISE
CONFIG_IMA_APPRAISE_BOOTPARAM
CONFIG_SYSTEM_TRUSTED_KEYS
Please note that CONFIG_KEXEC_VERIFY_SIG is not, actually should
not be, enabled.
3) Sign(label) a kernel image binary to be kexec-ed on target filesystem:
$ evmctl ima_sign --key /path/to/private_key.pem /your/Image
4) Add a command line parameter and boot the kernel:
ima_appraise=enforce
On live system,
5) Set a security policy:
$ mount -t securityfs none /sys/kernel/security
$ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" \
> /sys/kernel/security/ima/policy
6) Add a key for ima:
$ keyctl
[PATCH v13 04/16] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem()
Memblock list is another source for usable system memory layout.
So move powerpc's arch_kexec_walk_mem() to common code so that other
memblock-based architectures, particularly arm64, can also utilise it.
A moved function is now renamed to kexec_walk_memblock() and integrated
into kexec_locate_mem_hole(), which will now be usable for all
architectures with no need for overriding arch_kexec_walk_mem().
With this change, arch_kexec_walk_mem() need no longer be a weak function,
and was now renamed to kexec_walk_resources().
Since powerpc doesn't support kdump in its kexec_file_load(), the current
kexec_walk_memblock() won't work for kdump either in this form, this will
be fixed in the next patch.
Signed-off-by: AKASHI Takahiro
Cc: "Eric W. Biederman"
Acked-by: Dave Young
Cc: Vivek Goyal
Cc: Baoquan He
Acked-by: James Morse
---
arch/powerpc/kernel/machine_kexec_file_64.c | 54 ---
include/linux/kexec.h | 2 -
kernel/kexec_file.c | 60 +++--
3 files changed, 57 insertions(+), 59 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c
b/arch/powerpc/kernel/machine_kexec_file_64.c
index 0bd23dc789a4..5357b09902c5 100644
--- a/arch/powerpc/kernel/machine_kexec_file_64.c
+++ b/arch/powerpc/kernel/machine_kexec_file_64.c
@@ -24,7 +24,6 @@
#include
#include
-#include
#include
#include
#include
@@ -46,59 +45,6 @@ int arch_kexec_kernel_image_probe(struct kimage *image, void
*buf,
return kexec_image_probe_default(image, buf, buf_len);
}
-/**
- * arch_kexec_walk_mem - call func(data) for each unreserved memory block
- * @kbuf: Context info for the search. Also passed to @func.
- * @func: Function to call for each memory block.
- *
- * This function is used by kexec_add_buffer and kexec_locate_mem_hole
- * to find unreserved memory to load kexec segments into.
- *
- * Return: The memory walk will stop when func returns a non-zero value
- * and that value will be returned. If all free regions are visited without
- * func returning non-zero, then zero will be returned.
- */
-int arch_kexec_walk_mem(struct kexec_buf *kbuf,
- int (*func)(struct resource *, void *))
-{
- int ret = 0;
- u64 i;
- phys_addr_t mstart, mend;
- struct resource res = { };
-
- if (kbuf->top_down) {
- for_each_free_mem_range_reverse(i, NUMA_NO_NODE, 0,
- &mstart, &mend, NULL) {
- /*
-* In memblock, end points to the first byte after the
-* range while in kexec, end points to the last byte
-* in the range.
-*/
- res.start = mstart;
- res.end = mend - 1;
- ret = func(&res, kbuf);
- if (ret)
- break;
- }
- } else {
- for_each_free_mem_range(i, NUMA_NO_NODE, 0, &mstart, &mend,
- NULL) {
- /*
-* In memblock, end points to the first byte after the
-* range while in kexec, end points to the last byte
-* in the range.
-*/
- res.start = mstart;
- res.end = mend - 1;
- ret = func(&res, kbuf);
- if (ret)
- break;
- }
- }
-
- return ret;
-}
-
/**
* setup_purgatory - initialize the purgatory's global variables
* @image: kexec image.
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 49ab758f4d91..c196bfd11bee 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -184,8 +184,6 @@ int __weak arch_kexec_apply_relocations(struct
purgatory_info *pi,
const Elf_Shdr *relsec,
const Elf_Shdr *symtab);
-int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
- int (*func)(struct resource *, void *));
extern int kexec_add_buffer(struct kexec_buf *kbuf);
int kexec_locate_mem_hole(struct kexec_buf *kbuf);
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index bf39df5e5bb9..1073ef56a95d 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -501,6 +502,55 @@ static int locate_mem_hole_callback(struct resource *res,
void *arg)
return locate_mem_hole_bottom_up(start, end, kbuf);
}
+#if defined(CONFIG_HAVE_MEMBLOCK) && !defined(CONFIG_ARCH_DISCARD_MEMBLOCK)
+static int kexec_walk_memblock(struct kexec_buf *kbuf,
+ int (*func)(struct resource *, void *))
+{
+ int ret =
linux-next: Tree for Aug 1
Hi all, Changes since 20180731: The pci tree gained a conflict against the pci-current tree. The net-next tree gained a conflict against the bpf tree. The block tree lost its build failure. The staging tree still had its build failure due to an interaction with the vfs tree for which I disabled CONFIG_EROFS_FS. The kspp tree lost its build failure. Non-merge commits (relative to Linus' tree): 10070 9137 files changed, 417605 insertions(+), 179996 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). 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 (c1d61e7fe376 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (9d3cce1e8b85 Linux 4.18-rc5) Merging arc-current/for-curr (ec837d620c75 arc: fix type warnings in arc/mm/cache.c) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (c7513c2a2714 crypto/arm64: aes-ce-gcm - add missing kernel_neon_begin/end pair) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (b03897cf318d powerpc/powernv: Fix save/restore of SPRG3 on entry/exit from stop (idle)) Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e39eb58a Merge tag 'mlx5-fixes-2018-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging bpf/master (2d55d614fcf5 net: xsk: don't return frames via the allocator on error) Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (101f0cd4f221 net: ena: Fix use of uninitialized DMA address bits field) Merging ipvs/master (0026129c8629 rhashtable: add restart routine in rhashtable_free_and_destroy()) Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in parsing NVRAM for multiple devices) Merging mac80211/master (e31f6456c01c cfg80211: never ignore user regulatory hint) Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV port checks) Merging sound-current/for-linus (f59cf9a0551d ALSA: hda - Sleep for 10ms after entering D3 on Conexant codecs) Merging sound-asoc-fixes/for-linus (3e4b165997cb Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (d72e90f33aa4 Linux 4.18-rc6) Merging regulator-fixes/for-linus (61b0049c348c Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (56e72c1eca32 Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race condition) Merging driver-core.current/driver-core-linus (acb1872577b3 Linux 4.18-rc7) Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3) Merging usb.current/usb-linus (acb1872577b3 Linux 4.18-rc7) Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7) Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux 4.18-rc5) Merging usb-chipide
RE: [PATCH V2] x86/speculation: Support Enhanced IBRS on future CPUs
> > Yes, that makes sense. > > But on the machine, I see IBRS bit set on all cores. As you said, > > someone else might be writing the MSR. I will try to find that out and will > update the patch accordingly. > > > > I initially suspected it to be __ssb_select_mitigation() as I have > > "spec_store_bypass_disable=on" in the kernel command line, but turns out > > it's > not so. > > I will update you more on this. > > There are lots of places like the firmware mitigation stuff and other things > which > write that MSR. And because the bit is set in x86_spec_ctrl_base it will be > on at > some point and stay so. True! After a bit of experimenting with printk(), I see that it's being set by intel_set_ssb_state() during systemd initialization. > > Writing it explicitely at the point where it is set makes it independent of > other > mechanisms which touch that MSR and Just Works. Yes, that makes sense. I will add an explicit wrmsrl(). Just wanted to have a better understanding of how things work. Regards, Sai
[PATCH v13 16/16] arm64: kexec_file: add kaslr support
Adding "kaslr-seed" to dtb enables triggering kaslr, or kernel virtual
address randomization, at secondary kernel boot. We always do this as
it will have no harm on kaslr-incapable kernel.
We don't have any "switch" to turn off this feature directly, but still
can suppress it by passing "nokaslr" as a kernel boot argument.
Signed-off-by: AKASHI Takahiro
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/kernel/machine_kexec_file.c | 45 ++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec_file.c
b/arch/arm64/kernel/machine_kexec_file.c
index ecaecb122cad..967db9824e3f 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,6 +28,7 @@
#define FDT_PSTR_INITRD_STA"linux,initrd-start"
#define FDT_PSTR_INITRD_END"linux,initrd-end"
#define FDT_PSTR_BOOTARGS "bootargs"
+#define FDT_PSTR_KASLR_SEED"kaslr-seed"
const struct kexec_file_ops * const kexec_file_loaders[] = {
&kexec_image_ops,
@@ -45,6 +47,32 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
return kexec_image_post_load_cleanup_default(image);
}
+/* crng needs to have been initialized for providing kaslr-seed */
+static int random_ready;
+
+static void random_ready_notified(struct random_ready_callback *unused)
+{
+ random_ready = 1;
+}
+
+static struct random_ready_callback random_ready_cb = {
+ .func = random_ready_notified,
+};
+
+static __init int init_random_ready_cb(void)
+{
+ int ret;
+
+ ret = add_random_ready_callback(&random_ready_cb);
+ if (ret == -EALREADY)
+ random_ready = 1;
+ else if (ret)
+ pr_warn("failed to add a callback for random_ready\n");
+
+ return 0;
+}
+late_initcall(init_random_ready_cb)
+
static int setup_dtb(struct kimage *image,
unsigned long initrd_load_addr, unsigned long initrd_len,
char *cmdline, unsigned long cmdline_len,
@@ -53,6 +81,7 @@ static int setup_dtb(struct kimage *image,
void *buf = NULL;
size_t buf_size, range_size;
int nodeoffset;
+ u64 value;
int ret;
/* check ranges against root's #address-cells and #size-cells */
@@ -85,6 +114,8 @@ static int setup_dtb(struct kimage *image,
/* can be redundant, but trimmed at the end */
buf_size += fdt_prop_len(FDT_PSTR_BOOTARGS, cmdline_len);
+ buf_size += fdt_prop_len(FDT_PSTR_KASLR_SEED, sizeof(u64));
+
buf = vmalloc(buf_size);
if (!buf) {
ret = -ENOMEM;
@@ -164,6 +195,20 @@ static int setup_dtb(struct kimage *image,
}
}
+ /* add kaslr-seed */
+ fdt_delprop(buf, nodeoffset, FDT_PSTR_KASLR_SEED);
+ if (random_ready) {
+ get_random_bytes(&value, sizeof(value));
+ ret = fdt_setprop_u64(buf, nodeoffset, FDT_PSTR_KASLR_SEED,
+ value);
+ if (ret) {
+ ret = -EINVAL;
+ goto out_err;
+ }
+ } else {
+ pr_notice("kaslr-seed won't be fed\n");
+ }
+
/* trim a buffer */
fdt_pack(buf);
*dtb_buf = buf;
--
2.18.0
Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads
On 2018-07-30 14:07, Peter Zijlstra wrote:
On Mon, Jul 30, 2018 at 10:12:43AM -0700, Sodagudi Prasad wrote:
How about including below change as well? Currently, there is no way
to
identify thread migrations completed or not. When we observe this
issue,
the symptom was work queue lock up. It is better to have some timeout
here
and induce the bug_on.
You'd trigger the soft-lockup or hung-task detector I think. And if
not,
we ought to look at making it trigger at least one of those.
There is no way to identify the migration threads stuck or not.
Should be pretty obvious from the splat generated by the above, no?
Hi Peter and Thomas,
Thanks for your support.
I have another question on this flow and retry mechanism used in this
cpu_stop_queue_two_works() function using the global variable
stop_cpus_in_progress.
This variable is getting used in various paths, such as task migration,
set task affinity, and CPU hotplug.
For example cpu hotplug path, stop_cpus_in_progress variable getting set
with true with out checking.
takedown_cpu()
--stop_machine_cpuslocked()
---stop_cpus()
---__stop_cpus()
queue_stop_cpus_work()
setting stop_cpus_in_progress to true directly.
But in the task migration path only, the stop_cpus_in_progress variable
is used for retry.
I am thinking that stop_cpus_in_progress variable lead race conditions,
where CPU hotplug and task migration happening simultaneously. Please
correct me If my understanding wrong.
-Thanks, Prasad
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -290,6 +290,7 @@ int stop_two_cpus(unsigned int cpu1, unsigned int
cpu2,
cpu_stop_fn_t fn, void *
struct cpu_stop_done done;
struct cpu_stop_work work1, work2;
struct multi_stop_data msdata;
+ int ret;
msdata = (struct multi_stop_data){
.fn = fn,
@@ -312,7 +313,10 @@ int stop_two_cpus(unsigned int cpu1, unsigned int
cpu2,
cpu_stop_fn_t fn, void *
if (cpu_stop_queue_two_works(cpu1, &work1, cpu2, &work2))
return -ENOENT;
- wait_for_completion(&done.completion);
+ ret = wait_for_completion_timeout(&done.completion,
msecs_to_jiffies(1000));
+ if (!ret)
+ BUG_ON(1);
+
That's a random timeout, which if you spuriously trigger it, will take
down your machine. That seems like a cure worse than the disease.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
Re: [PATCH v2 1/3] overflow.h: Add arithmetic shift helper
On Wed, Aug 01, 2018 at 10:57:44AM +0300, Dan Carpenter wrote:
> The idea is nice, but I don't like the API. The "_overflow" feels too
> specific because maybe we could check for other things in the future.
> Normally boolean macros should say they are boolean in the name and I
> would prefer if it returned zero on failure.
>
> if (!checked_shift(dest, mask, shift)) {
> if (!shift_ok(dest, mask, shift)) {
> if (!safe_shift(dest, mask, shift)) {
Huh... It turns out I put the argument order different as well.
If we wanted to keep it returning 1 on failure then some other names
are:
if (shift_failed(dest, mask, shift)) {
if (shift_error(dest, mask, shift)) {
if (shift_overflow(dest, mask, shift)) {
regards,
dan carpenter
Szybkie tłumaczenia
Witaj Piszę do Ciebię ponieważ chciałbym zaproponować skorzystanie z bardzo sprawnego i rzetelnego serwisu tłumaczeń. Dzięki nam zlecisz tłumaczenia zwykłe, specjalistyczne lub przysięgłe nie wstając sprzed komputera albo smartfona. Wystarczy przesłać nam plik do wyceny, odpowiedź otrzymasz w 20 minut. Masz jakieś pytania? Po prostu kliknij https://cpnow.me/d/pYDy oddzwonimy! Pozdrawiam Mateusz Górecki Senior Account Manager profesjonalne-tlumaczenia.com Ps. Rzadko się odzywam, jeśli nie odpowiesz nie będę niepokoił, ale możesz także wypisac się z mailingu pisząc rezygnacja. Informacje dotyczące prywatności: www.profesjonalne-tlumaczenia.com
Re: [PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag
piaojun wrote on Wed, Aug 01, 2018:
> chan->tag has no terminal char at last which will result in printing messy
> code when debugging code. So we should add '\0' for tag.
9p is full of non null-terminated string so I'm not sure how I feel
about it, is there anything wrong with how this is used or was this just
when you tried to printf it?
If it's just for debugging I'd suggest using the printf format "%.*s"
with "chan->tag_len, chan->tag" arguments,
That said it's not like this is costly, so I'll take it if someone else
thinks this is helpful
>
> Signed-off-by: Jun Piao
> ---
> net/9p/trans_virtio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index d422bfc..49d71d6 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -585,7 +585,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
> err = -EINVAL;
> goto out_free_vq;
> }
> - tag = kmalloc(tag_len, GFP_KERNEL);
> + tag = kzalloc(tag_len + 1, GFP_KERNEL);
> if (!tag) {
> err = -ENOMEM;
> goto out_free_vq;
> --
--
Dominique
Låneerbjudande
Kära Herr / Fru,
Du behöver ett brådskande lån för att lösa dina ekonomiska behov. Vi erbjuder
ett intervall från 10 000,00 Euro till 100 000 000,00 Euroloan Max, vi är
pålitliga, effektiva, snabba och dynamiska, med 100% garanterad och vi ger
också kredit till (euro, pund och dollar ) Räntesatsen för alla lönedagslån
(3%), om du är intresserad, kom tillbaka till oss via denna Email:
fundingtrustfina...@gmail.com
{BORROWERS DATA INFORMATION}
* (1) Nödbelopp som behövs:
* (2) Lånebelopp som behövs i ord:
* (3) Fullständiga namn:
* (4) Land:
* (5) Giltigt Mobiltelefonnummer eller Tel Phone:
* (6) Syftet med lånet:
* (7) Adress:
* (8) yrke:
* (9) Kön: Man eller Kvinna:
* (10) Lånets längd:
* (11) Ålder:
Efter ditt svar kommer jag genast tillbaka till dig med ytterligare information
om hur du ska hantera och godkänna lånet. En mycket
trevlig dag är min önskan till dig.
Tack för ditt beskydd
Jag ser fram emot att höra från dig soonext.
Med vänliga hälsningar,
Herr Ronny Hens
EMAIL: fundingtrustfina...@gmail.com
Re: [PATCH v5 07/12] PM / devfreq: export devfreq_class
Hi Matthias, On 2018년 08월 01일 04:29, Matthias Kaehlcke wrote: > On Mon, Jul 16, 2018 at 12:41:14PM -0700, Matthias Kaehlcke wrote: >> Hi Chanwoo, >> >> On Thu, Jul 12, 2018 at 06:08:36PM +0900, Chanwoo Choi wrote: >>> Hi Matthias, >>> >>> On 2018년 07월 07일 03:09, Matthias Kaehlcke wrote: Hi, On Wed, Jul 04, 2018 at 02:30:32PM +0900, Chanwoo Choi wrote: > I didn't see any framework which exporting the class instance. > It is very dangerous. Unknown device drivers is able to reset > the 'devfreq_class' instance. I can't agree this approach. While I agree that it is potential dangerous it is actually a common practice to export the class: >>> >>> I tried to find the real usage of exported class instance >>> and I add the comment for each class instance. Almost exported class >>> instance are used in the their own director or some exported class >>> like rio_mport_class/switchtec_class are created from specific device driver >>> instead of subsystem. >>> >>> Only following two cases are used on outside of subsystem directory. >>> devtmpfs.c and alarmtimer.c are core feature of linux kernel. >>> >>> drivers/base/devtmpfs.c uses 'block_class'. >>> kernel/time/alarmtimer.c uses 'rtc_class'. >>> >>> I cannot yet agree this approach due to only block_class and rtc_class. >> >> I thought your main concern was that the class is exported, which is >> what several other subsystems do. That the class isn't used outside of >> the subsystem directory most likely means that there is no need for >> it, rather than that it shouldn't be done at all (depending on the >> type of use of course). >> >> In any case not exporting the class object provides a limited >> protection against potential abuse of the class at best. To use the >> class API all that is needed is a 'struct device' of a devfreq device, >> which has a pointer to the class object (dev->class). >> >> Theoretically I could register a fake devfreq device to obtain access >> to the class object, though that doesn't seem a very neat approach ;-) >> >>> You added the following comment why devfreq_class instance is necessary. >>> Actullay, I don't know the best solution right now. But, all device drivers >>> can be added or removed if driver uses the module type. It is not a problem >>> for only devfreq instance. >> >> Certainly it's not a problem limited to devfreq devices. In many other >> cases bus notifiers can be used, but since devfreq devices areen't >> tied to a specific bus this is not an option here. >> >> If you really don't want to export the class we could add wrappers >> for (un)registering a class interface: >> >> int devfreq_class_interface_register(struct class_interface *) >> void devfreq_class_interface_unregister(struct class_interface *) About this approach, I agree because it doesn't export the devfreq_class instance as you commented. >> >> The wrappers would have to assign ci->class since the throttler >> can't see the class object. >> >> Or add notifiers for device addition/removal, though the throttler >> relies on the behavior of the class_interface which also notifies >> about devices added before registration. This might not be what other >> potential users of the notifiers expect. > > Ping > > Could we please try to find a solution/reach a conclusion for this? > > Not that it should affect the outcome of this discussion, but I want > to mention that from my point of view it is a bit unfortunate that > this and other fundamental concerns were only raised after I spent > significant time on repeatedly refactoring the throttler driver to > address other comments. Since you and MyungJoo Ham previously had only > minor comments on the other devfreq patches in this series I assumed > there were no major concerns from your side :( > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote:
> On Tue, Jul 31, 2018 at 9:31 PM, wrote:
> > On 2018-07-31 00:59, Quentin Perret wrote:
> >>
> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote:
> >> [...]
> >>>
> >>> If it's going to be a different aggregation from what's done for
> >>> frequency
> >>> guidance, I don't see the point of having this inside schedutil. Why not
> >>> keep it inside the scheduler files?
> >>
> >>
> >> This code basically results from a discussion we had with Peter on v4.
> >> Keeping everything centralized can make sense from a maintenance
> >> perspective, I think. That makes it easy to see the impact of any change
> >> to utilization signals for both EAS and schedutil.
> >
> >
> > In that case, I'd argue it makes more sense to keep the code centralized in
> > the scheduler. The scheduler can let schedutil know about the utilization
> > after it aggregates them. There's no need for a cpufreq governor to know
> > that there are scheduling classes or how many there are. And the scheduler
> > can then choose to aggregate one way for task packing and another way for
> > frequency guidance.
>
> Also the aggregate utilization may be used by cpuidle governors in
> principle to decide how deep they can go with idle state selection.
The only issue I see with this right now is that some of the things done
in this function are policy decisions which really belong to the governor,
I think. The RT-go-to-max-freq thing in particular. And I really don't
think EAS should cope with that, at least for now.
But if this specific bit is factored out of the aggregation function, I
suppose we could move it somewhere else. Maybe pelt.c ?
How ugly is something like the below (totally untested) code ? It would
change slightly how we deal with DL utilization in EAS but I don't think
this is an issue.
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index af86050edcf5..51c9ac9f30e8 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -178,121 +178,17 @@ static unsigned int get_next_freq(struct sugov_policy
*sg_policy,
return cpufreq_driver_resolve_freq(policy, freq);
}
-/*
- * This function computes an effective utilization for the given CPU, to be
- * used for frequency selection given the linear relation: f = u * f_max.
- *
- * The scheduler tracks the following metrics:
- *
- * cpu_util_{cfs,rt,dl,irq}()
- * cpu_bw_dl()
- *
- * Where the cfs,rt and dl util numbers are tracked with the same metric and
- * synchronized windows and are thus directly comparable.
- *
- * The cfs,rt,dl utilization are the running times measured with rq->clock_task
- * which excludes things like IRQ and steal-time. These latter are then accrued
- * in the irq utilization.
- *
- * The DL bandwidth number otoh is not a measured metric but a value computed
- * based on the task model parameters and gives the minimal utilization
- * required to meet deadlines.
- */
-unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs,
- enum schedutil_type type)
-{
- struct rq *rq = cpu_rq(cpu);
- unsigned long util, irq, max;
-
- max = arch_scale_cpu_capacity(NULL, cpu);
-
- if (type == frequency_util && rt_rq_is_runnable(&rq->rt))
- return max;
-
- /*
-* Early check to see if IRQ/steal time saturates the CPU, can be
-* because of inaccuracies in how we track these -- see
-* update_irq_load_avg().
-*/
- irq = cpu_util_irq(rq);
- if (unlikely(irq >= max))
- return max;
-
- /*
-* Because the time spend on RT/DL tasks is visible as 'lost' time to
-* CFS tasks and we use the same metric to track the effective
-* utilization (PELT windows are synchronized) we can directly add them
-* to obtain the CPU's actual utilization.
-*/
- util = util_cfs;
- util += cpu_util_rt(rq);
-
- if (type == frequency_util) {
- /*
-* For frequency selection we do not make cpu_util_dl() a
-* permanent part of this sum because we want to use
-* cpu_bw_dl() later on, but we need to check if the
-* CFS+RT+DL sum is saturated (ie. no idle time) such
-* that we select f_max when there is no idle time.
-*
-* NOTE: numerical errors or stop class might cause us
-* to not quite hit saturation when we should --
-* something for later.
-*/
-
- if ((util + cpu_util_dl(rq)) >= max)
- return max;
- } else {
- /*
-* OTOH, for energy computation we need the estimated
-* running time, so include util_dl and ignore dl_bw.
-*/
- util += cpu_util_dl(rq);
-
Re: [PATCH v2 8/9] libata-scsi: Move sense buffers onto stack
On Tue, Jul 31, 2018 at 12:51:53PM -0700, Kees Cook wrote: > To support future compile-time sizeof() checks that will be able to > validate the length of sense buffers, this removes the only dynamically > allocated sense buffers in the tree by putting the 96 byte sense buffers > on the stack. > > Signed-off-by: Kees Cook Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v2 6/9] ide-cd: Remove redundant sense buffer
On Tue, Jul 31, 2018 at 12:51:51PM -0700, Kees Cook wrote: > This is already able to process the sense buffer, so remove the redundant > parsing during the failure path. This also fixes any possible stale values > since the prior code did not check the sense length. > > Signed-off-by: Kees Cook Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v2 5/9] block: Switch struct packet_command to use struct scsi_sense_hdr
On Tue, Jul 31, 2018 at 12:51:50PM -0700, Kees Cook wrote: > There is a lot of needless struct request_sense usage in the CDROM > code. These can all be struct scsi_sense_hdr instead, to avoid any > confusion over their respective structure sizes. This patch is a lot > of noise changing "sense" to "sshdr", but the final code is more > readable to distinguish between "sense" meaning "struct request_sense" > and "sshdr" meaning "struct scsi_sense_hdr". Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v5 09/12] dt-bindings: misc: add bindings for throttler
Hi Matthias,
On 2018년 07월 04일 08:47, Matthias Kaehlcke wrote:
> The Throttler is used for non-thermal throttling of system components
> like CPUs or devfreq devices.
>
> Signed-off-by: Matthias Kaehlcke
> --
> Changes in v5:
> - patch added to the series (replacing "dt-bindings: PM / OPP: add
> opp-throttlers property")
> ---
> .../devicetree/bindings/misc/throttler.txt | 13 +
> 1 file changed, 13 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/throttler.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/throttler.txt
> b/Documentation/devicetree/bindings/misc/throttler.txt
> new file mode 100644
> index ..2ea80c62dbe1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/throttler.txt
> @@ -0,0 +1,13 @@
> +Throttler driver
> +
> +The Throttler is used for non-thermal throttling of system components like
> +CPUs or devfreq devices.
> +
> +Required properties:
> +- throttler-opps Array of OPP-v2 phandles with the OPPs used for
> + throttling.
> +
> +Example:
> + throttler {
> + throttler-opps = <&cpu0_opp03, &cpu1_opp02, &gpu_opp03>;
> + };
>
If possible, I hope the more detailed example for "cpu0_opp03, &cpu1_opp02,
&gpu_opp03"
because I'm confusing the meaning of 'cpu0_opp03' phandle.
cpu0_opp03 indicates the only one specific OPP entry among set of OPP entries
of CPU0 cpufreq? or
cpu0_opp03 indicates the set of OPP entries for CPU0 cpufreq ?
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: KASAN: use-after-free Read in rtnetlink_put_metrics
On 8/1/18 10:15 AM, Sabrina Dubroca wrote: > ip -net peerA route add fec0:B::/64 via fec0:A:: mtu 1300 I am on vacation right now with limited access to internet, so not able to take a look. In submitting the fib6_info changes I did tests like this and did not see memleak reports (and verified the metrics refcnts with printks), so I am surprised to see your patch in this area. Will take a look when I can but that will not be for a couple more weeks.
Re: [PATCH v2 9/9] scsi: Check sense buffer size at build time
On Tue, Jul 31, 2018 at 12:51:54PM -0700, Kees Cook wrote:
> To avoid introducing problems like those fixed in commit f7068114d45e
> ("sr: pass down correctly sized SCSI sense buffer"), this creates a macro
> wrapper for scsi_execute() that verifies the size of the sense buffer
> similar to what was done for command string sizes in commit 3756f6401c30
> ("exec: avoid gcc-8 warning for get_task_comm").
>
> Another solution could be to add a length argument to scsi_execute(),
> but this function already takes a lot of arguments and Jens was not fond
> of that approach.
>
> Additionally, this moves the SCSI_SENSE_BUFFERSIZE definition into
> scsi_device.h, and removes a redundant include for scsi_device.h from
> scsi_cmnd.h.
>
> Signed-off-by: Kees Cook
Looks good,
Reviewed-by: Christoph Hellwig
Re: [PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag
Hi Dominique,
On 2018/8/1 16:11, Dominique Martinet wrote:
> piaojun wrote on Wed, Aug 01, 2018:
>> chan->tag has no terminal char at last which will result in printing messy
>> code when debugging code. So we should add '\0' for tag.
>
> 9p is full of non null-terminated string so I'm not sure how I feel
> about it, is there anything wrong with how this is used or was this just
> when you tried to printf it?
There is nothing wrong at the places using tag, as they calculated the
tag_len carefully. Adding '\0' for it will make the code more robust. And
I'm glad to hear others' opinions.
Thanks,
Jun
>
> If it's just for debugging I'd suggest using the printf format "%.*s"
> with "chan->tag_len, chan->tag" arguments,
>
>
> That said it's not like this is costly, so I'll take it if someone else
> thinks this is helpful
>
>>
>> Signed-off-by: Jun Piao
>> ---
>> net/9p/trans_virtio.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
>> index d422bfc..49d71d6 100644
>> --- a/net/9p/trans_virtio.c
>> +++ b/net/9p/trans_virtio.c
>> @@ -585,7 +585,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
>> err = -EINVAL;
>> goto out_free_vq;
>> }
>> -tag = kmalloc(tag_len, GFP_KERNEL);
>> +tag = kzalloc(tag_len + 1, GFP_KERNEL);
>> if (!tag) {
>> err = -ENOMEM;
>> goto out_free_vq;
>> --
Re: [PATCH v5 06/12] PM / devfreq: Make update_devfreq() public
Hi Matthias,
On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote:
> Currently update_devfreq() is only visible to devfreq governors outside
> of devfreq.c. Make it public to allow drivers that adjust devfreq policies
> to cause a re-evaluation of the frequency after a policy change.
>
> Signed-off-by: Matthias Kaehlcke
> Acked-by: MyungJoo Ham
> Reviewed-by: Brian Norris
> --
> Changes in v5:
> - none
>
> Changed in v4:
> - added 'Reviewed-by: Brian Norris ' tag
>
> Changes in v3:
> - none
>
> Changes in v2:
> - added 'Acked-by: MyungJoo Ham ' tag
> ---
> drivers/devfreq/governor.h | 3 ---
> include/linux/devfreq.h| 8
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
> index b81700244ce3..f53339ca610f 100644
> --- a/drivers/devfreq/governor.h
> +++ b/drivers/devfreq/governor.h
> @@ -57,9 +57,6 @@ struct devfreq_governor {
> unsigned int event, void *data);
> };
>
> -/* Caution: devfreq->lock must be locked before calling update_devfreq */
> -extern int update_devfreq(struct devfreq *devfreq);
> -
> extern void devfreq_monitor_start(struct devfreq *devfreq);
> extern void devfreq_monitor_stop(struct devfreq *devfreq);
> extern void devfreq_monitor_suspend(struct devfreq *devfreq);
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 7c8dce96db73..c4f84a769cb5 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -222,6 +222,14 @@ extern void devm_devfreq_remove_device(struct device
> *dev,
> extern int devfreq_suspend_device(struct devfreq *devfreq);
> extern int devfreq_resume_device(struct devfreq *devfreq);
>
> +/**
> + * update_devfreq() - Reevaluate the device and configure frequency
> + * @devfreq: the devfreq device
> + *
> + * Note: devfreq->lock must be held
> + */
> +extern int update_devfreq(struct devfreq *devfreq);
> +
> /* Helper functions for devfreq user device driver with OPP. */
> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> unsigned long *freq, u32 flags);
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Wed, Aug 1, 2018 at 10:23 AM, Quentin Perret wrote:
> On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote:
>> On Tue, Jul 31, 2018 at 9:31 PM, wrote:
>> > On 2018-07-31 00:59, Quentin Perret wrote:
>> >>
>> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote:
>> >> [...]
>> >>>
>> >>> If it's going to be a different aggregation from what's done for
>> >>> frequency
>> >>> guidance, I don't see the point of having this inside schedutil. Why not
>> >>> keep it inside the scheduler files?
>> >>
>> >>
>> >> This code basically results from a discussion we had with Peter on v4.
>> >> Keeping everything centralized can make sense from a maintenance
>> >> perspective, I think. That makes it easy to see the impact of any change
>> >> to utilization signals for both EAS and schedutil.
>> >
>> >
>> > In that case, I'd argue it makes more sense to keep the code centralized in
>> > the scheduler. The scheduler can let schedutil know about the utilization
>> > after it aggregates them. There's no need for a cpufreq governor to know
>> > that there are scheduling classes or how many there are. And the scheduler
>> > can then choose to aggregate one way for task packing and another way for
>> > frequency guidance.
>>
>> Also the aggregate utilization may be used by cpuidle governors in
>> principle to decide how deep they can go with idle state selection.
>
> The only issue I see with this right now is that some of the things done
> in this function are policy decisions which really belong to the governor,
> I think.
Well, the scheduler makes policy decisions too, in quite a few places. :-)
The really important consideration here is whether or not there may be
multiple governors making different policy decisions in that respect.
If not, then where exactly the single policy decision is made doesn't
particularly matter IMO.
> The RT-go-to-max-freq thing in particular. And I really don't
> think EAS should cope with that, at least for now.
>
> But if this specific bit is factored out of the aggregation function, I
> suppose we could move it somewhere else. Maybe pelt.c ?
>
> How ugly is something like the below (totally untested) code ? It would
> change slightly how we deal with DL utilization in EAS but I don't think
> this is an issue.
>
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index af86050edcf5..51c9ac9f30e8 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -178,121 +178,17 @@ static unsigned int get_next_freq(struct sugov_policy
> *sg_policy,
> return cpufreq_driver_resolve_freq(policy, freq);
> }
>
> -/*
> - * This function computes an effective utilization for the given CPU, to be
> - * used for frequency selection given the linear relation: f = u * f_max.
> - *
> - * The scheduler tracks the following metrics:
> - *
> - * cpu_util_{cfs,rt,dl,irq}()
> - * cpu_bw_dl()
> - *
> - * Where the cfs,rt and dl util numbers are tracked with the same metric and
> - * synchronized windows and are thus directly comparable.
> - *
> - * The cfs,rt,dl utilization are the running times measured with
> rq->clock_task
> - * which excludes things like IRQ and steal-time. These latter are then
> accrued
> - * in the irq utilization.
> - *
> - * The DL bandwidth number otoh is not a measured metric but a value computed
> - * based on the task model parameters and gives the minimal utilization
> - * required to meet deadlines.
> - */
> -unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs,
> - enum schedutil_type type)
> -{
> - struct rq *rq = cpu_rq(cpu);
> - unsigned long util, irq, max;
> -
> - max = arch_scale_cpu_capacity(NULL, cpu);
> -
> - if (type == frequency_util && rt_rq_is_runnable(&rq->rt))
> - return max;
> -
> - /*
> -* Early check to see if IRQ/steal time saturates the CPU, can be
> -* because of inaccuracies in how we track these -- see
> -* update_irq_load_avg().
> -*/
> - irq = cpu_util_irq(rq);
> - if (unlikely(irq >= max))
> - return max;
> -
> - /*
> -* Because the time spend on RT/DL tasks is visible as 'lost' time to
> -* CFS tasks and we use the same metric to track the effective
> -* utilization (PELT windows are synchronized) we can directly add
> them
> -* to obtain the CPU's actual utilization.
> -*/
> - util = util_cfs;
> - util += cpu_util_rt(rq);
> -
> - if (type == frequency_util) {
> - /*
> -* For frequency selection we do not make cpu_util_dl() a
> -* permanent part of this sum because we want to use
> -* cpu_bw_dl() later on, but we need to check if the
> -* CFS+RT+DL sum is saturated (ie. no idle time) such
> -* that we select f_max when there is
[PATCH v5 1/2] dt-bindings: mux: add adi,adgs1408
From: Mircea Caprioru
Adding documentation for adgs1408/1409 multiplexer. The bindings
follow the standard SPI and mux bindings and do not require any
additional custom properties.
Signed-off-by: Mircea Caprioru
Reviewed-by: Rob Herring
[peda: reword idle-state to non-array for singular mux controller]
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/mux/adi,adgs1408.txt | 48 ++
MAINTAINERS| 6 +++
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mux/adi,adgs1408.txt
diff --git a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt
b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt
new file mode 100644
index ..be6947f4d86b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt
@@ -0,0 +1,48 @@
+Bindings for Analog Devices ADGS1408/1409 8:1/Dual 4:1 Mux
+
+Required properties:
+- compatible : Should be one of
+ * "adi,adgs1408"
+ * "adi,adgs1409"
+* Standard mux-controller bindings as described in mux-controller.txt
+
+Optional properties for ADGS1408/1409:
+- gpio-controller : if present, #gpio-cells is required.
+- #gpio-cells : should be <2>
+ - First cell is the GPO line number, i.e. 0 to 3
+ for ADGS1408 and 0 to 4 for ADGS1409
+ - Second cell is used to specify active high (0)
+ or active low (1)
+
+Optional properties:
+- idle-state : if present, the state that the mux controller will have
+ when idle. The special state MUX_IDLE_AS_IS is the default and
+ MUX_IDLE_DISCONNECT is also supported.
+
+States 0 through 7 correspond to signals S1 through S8 in the datasheet.
+For ADGS1409 only states 0 to 3 are available.
+
+Example:
+
+ /*
+* One mux controller.
+* Mux state set to idle as is (no idle-state declared)
+*/
+ &spi0 {
+ mux: mux-controller@0 {
+ compatible = "adi,adgs1408";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ #mux-control-cells = <0>;
+ };
+ }
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 1>;
+ io-channel-names = "parent";
+ mux-controls = <&mux>;
+
+ channels = "out_a0", "out_a1", "test0", "test1",
+ "out_b0", "out_b1", "testb0", "testb1";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 0fe4228f78cb..eaa2b55a0e9b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -810,6 +810,12 @@ L: linux-me...@vger.kernel.org
S: Maintained
F: drivers/media/i2c/ad9389b*
+ANALOG DEVICES INC ADGS1408 DRIVER
+M: Mircea Caprioru
+S: Supported
+F: drivers/mux/adgs1408.c
+F: Documentation/devicetree/bindings/mux/adgs1408.txt
+
ANALOG DEVICES INC ADV7180 DRIVER
M: Lars-Peter Clausen
L: linux-me...@vger.kernel.org
--
2.11.0
[PATCH v5 2/2] mux: adgs1408: new driver for Analog Devices ADGS1408/1409 mux
From: Mircea Caprioru
This patch adds basic support for Analog Device ADGS1408/09 SPI mux
controller.
The device is probed and set to a disabled state. It uses the new mux
controller framework.
Signed-off-by: Mircea Caprioru
Signed-off-by: Peter Rosin
---
drivers/mux/Kconfig| 10
drivers/mux/Makefile | 2 +
drivers/mux/adgs1408.c | 131 +
3 files changed, 143 insertions(+)
create mode 100644 drivers/mux/adgs1408.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 6241678e99af..7659d6c5f718 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -21,6 +21,16 @@ config MUX_ADG792A
To compile the driver as a module, choose M here: the module will
be called mux-adg792a.
+config MUX_ADGS1408
+ tristate "Analog Devices ADGS1408/ADGS1409 Multiplexers"
+ depends on SPI
+ help
+ ADGS1408 8:1 multiplexer and ADGS1409 double 4:1 multiplexer
+ switches.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-adgs1408.
+
config MUX_GPIO
tristate "GPIO-controlled Multiplexer"
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index c3d883955fd5..6e9fa47daf56 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -5,10 +5,12 @@
mux-core-objs := core.o
mux-adg792a-objs := adg792a.o
+mux-adgs1408-objs := adgs1408.o
mux-gpio-objs := gpio.o
mux-mmio-objs := mmio.o
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
+obj-$(CONFIG_MUX_ADGS1408) += mux-adgs1408.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
diff --git a/drivers/mux/adgs1408.c b/drivers/mux/adgs1408.c
new file mode 100644
index ..0f7cf54e3234
--- /dev/null
+++ b/drivers/mux/adgs1408.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ADGS1408/ADGS1409 SPI MUX driver
+ *
+ * Copyright 2018 Analog Devices Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ADGS1408_SW_DATA (0x01)
+#define ADGS1408_REG_READ(reg) ((reg) | 0x80)
+#define ADGS1408_DISABLE (0x00)
+#define ADGS1408_MUX(state)(((state) << 1) | 1)
+
+enum adgs1408_chip_id {
+ ADGS1408 = 1,
+ ADGS1409,
+};
+
+static int adgs1408_spi_reg_write(struct spi_device *spi,
+ u8 reg_addr, u8 reg_data)
+{
+ u8 tx_buf[2];
+
+ tx_buf[0] = reg_addr;
+ tx_buf[1] = reg_data;
+
+ return spi_write_then_read(spi, tx_buf, sizeof(tx_buf), NULL, 0);
+}
+
+static int adgs1408_set(struct mux_control *mux, int state)
+{
+ struct spi_device *spi = to_spi_device(mux->chip->dev.parent);
+ u8 reg;
+
+ if (state == MUX_IDLE_DISCONNECT)
+ reg = ADGS1408_DISABLE;
+ else
+ reg = ADGS1408_MUX(state);
+
+ return adgs1408_spi_reg_write(spi, ADGS1408_SW_DATA, reg);
+}
+
+static const struct mux_control_ops adgs1408_ops = {
+ .set = adgs1408_set,
+};
+
+static int adgs1408_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ enum adgs1408_chip_id chip_id;
+ struct mux_chip *mux_chip;
+ struct mux_control *mux;
+ s32 idle_state;
+ int ret;
+
+ chip_id = (enum adgs1408_chip_id)of_device_get_match_data(dev);
+ if (!chip_id)
+ chip_id = spi_get_device_id(spi)->driver_data;
+
+ mux_chip = devm_mux_chip_alloc(dev, 1, 0);
+ if (IS_ERR(mux_chip))
+ return PTR_ERR(mux_chip);
+
+ mux_chip->ops = &adgs1408_ops;
+
+ ret = adgs1408_spi_reg_write(spi, ADGS1408_SW_DATA, ADGS1408_DISABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
+ if (ret < 0)
+ idle_state = MUX_IDLE_AS_IS;
+
+ mux = mux_chip->mux;
+
+ if (chip_id == ADGS1408)
+ mux->states = 8;
+ else
+ mux->states = 4;
+
+ switch (idle_state) {
+ case MUX_IDLE_DISCONNECT:
+ case MUX_IDLE_AS_IS:
+ case 0 ... 7:
+ /* adgs1409 supports only 4 states */
+ if (idle_state < mux->states) {
+ mux->idle_state = idle_state;
+ break;
+ }
+ /* fall through */
+ default:
+ dev_err(dev, "invalid idle-state %d\n", idle_state);
+ return -EINVAL;
+ }
+
+ return devm_mux_chip_register(dev, mux_chip);
+}
+
+static const struct spi_device_id adgs1408_spi_id[] = {
+ { "adgs1408", ADGS1408 },
+ { "adgs1409", ADGS1409 },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, adgs1408_spi_id);
+
+static const struct of_device_id adgs1408_of_match[] = {
[PATCH v5 0/2] mux: new driver for ADGS1408/1409
Hi Greg, Here's a new mux driver for v4.19-rc1. It's been in -next for a couple of days, and the risk is low since it is a completely new driver with no strange entanglements. And it's tiny. There was a report from -next about a trivial conflict in MAINTAINERS, but I guess that's more or less standard... That said, the commit time is really fresh, that's because I initially forgot to add Robs tag and only just realized. Sorry about that. I know you don't want to pull, but I included the output from request-pull anyway, so you may do as you wish... Cheers, Peter The following changes since commit d72e90f33aa4709ebecc5005562f52335e106a60: Linux 4.18-rc6 (2018-07-22 14:12:20 -0700) are available in the git repository at: https://gitlab.com/peda-linux/mux.git adgs1408 for you to fetch changes up to fad6692ba25138cd127d12569062e9fcc4674cb3: mux: adgs1408: new driver for Analog Devices ADGS1408/1409 mux (2018-08-01 10:11:59 +0200) Mircea Caprioru (2): dt-bindings: mux: add adi,adgs1408 mux: adgs1408: new driver for Analog Devices ADGS1408/1409 mux .../devicetree/bindings/mux/adi,adgs1408.txt | 48 MAINTAINERS| 6 + drivers/mux/Kconfig| 10 ++ drivers/mux/Makefile | 2 + drivers/mux/adgs1408.c | 131 + 5 files changed, 197 insertions(+) create mode 100644 Documentation/devicetree/bindings/mux/adi,adgs1408.txt create mode 100644 drivers/mux/adgs1408.c -- 2.11.0
Re: [PATCH v4 5/5] arm64: dts: actions: Add pinctrl node for Actions Semi S700
Hi All, On 08/01/2018 02:45 AM, kbuild test robot wrote: Hi Saravanan, Thank you for the patch! Yet something to improve: [auto build test ERROR on pinctrl/devel] [also build test ERROR on next-20180731] [cannot apply to v4.18-rc7] [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/Saravanan-Sekar/pinctrl-actions-define-constructor-generic-to-Actions-Semi-SoC-s/20180801-042834 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel config: arm64-defconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): Error: arch/arm64/boot/dts/actions/s700.dtsi:172.19-20 syntax error FATAL ERROR: Unable to parse input tree Device tree entry in this patch depends on actions clock patch [1], and it is not yet merged. The above build error is because of the dependency. [1] https://patchwork.kernel.org/patch/10533959/ --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- Thanks, Parthiban Nallathambi DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Re: [PATCH RESEND RFC 2/4] drivers: pinctrl: qcom: add wakeup gpio map for sdm845
On Wed, 01 Aug 2018 03:00:19 +0100,
Lina Iyer wrote:
>
> Add GPIO to PDC pin map for the SDM845 SoC.
>
> Signed-off-by: Lina Iyer
> ---
> drivers/pinctrl/qcom/pinctrl-sdm845.c | 76 +++
> 1 file changed, 76 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
> b/drivers/pinctrl/qcom/pinctrl-sdm845.c
> index 2ab7a8885757..e93660922dc2 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
> @@ -1277,6 +1277,80 @@ static const struct msm_pingroup sdm845_groups[] = {
> UFS_RESET(ufs_reset, 0x99f000),
> };
>
> +static struct msm_pinctrl_pdc_map sdm845_wakeup_gpios[] = {
[huge array]
> +};
Why isn't that array part of the DT? I'd expect other SoCs to
eventually use a similar mechanism, no?
M.
--
Jazz is not dead, it just smell funny.
[PATCH v3 0/4] arm64: dts: rockchip: add basic dts file for PX30 SoCs
From: Liang Chen Changes in v3: 1. backlight: remove properties ,, , as the driver will compute a default table. Changes in V2: 1. change the subject to format "dt-bindings: module: ..." for the documents. 2. use new property for backlight. 3. remove pinctrl of rk809, because the driver is not ready. Liang Chen (4): dt-bindings: usb: dwc2: add description for px30 dt-bindings: rockchip: grf: add grf and pmugrf description for px30 arm64: dts: rockchip: add core dtsi file for PX30 SoCs arm64: dts: rockchip: add PX30 eavluation board devicetree Documentation/devicetree/bindings/arm/rockchip.txt |4 + .../devicetree/bindings/soc/rockchip/grf.txt |2 + Documentation/devicetree/bindings/usb/dwc2.txt |1 + arch/arm64/boot/dts/rockchip/Makefile |1 + arch/arm64/boot/dts/rockchip/px30-evb.dts | 470 + arch/arm64/boot/dts/rockchip/px30.dtsi | 2043 6 files changed, 2521 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/px30-evb.dts create mode 100644 arch/arm64/boot/dts/rockchip/px30.dtsi -- 1.9.1
[PATCH v3 1/4] dt-bindings: usb: dwc2: add description for px30
From: Liang Chen This patch adds the compatible of dwc2 for PX30 SoCs. Acked-by: Rob Herring Signed-off-by: Liang Chen --- Documentation/devicetree/bindings/usb/dwc2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 46da5f1..6dc3c4a 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -6,6 +6,7 @@ Required properties: - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC. - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC. - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc; + - "rockchip,px30-usb", "rockchip,rk3066-usb", "snps,dwc2": for px30 Soc; - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc; - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc; - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs; -- 1.9.1
[PATCH v3 2/4] dt-bindings: rockchip: grf: add grf and pmugrf description for px30
From: Liang Chen This patch adds the compatible of GRF and PMUGRF for PX30 SoCs. Acked-by: Rob Herring Signed-off-by: Liang Chen --- Documentation/devicetree/bindings/soc/rockchip/grf.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt index 7dc5ce8..46e27cd 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt @@ -13,6 +13,7 @@ On RK3328 SoCs, the GRF adds a section for USB2PHYGRF, Required Properties: - compatible: GRF should be one of the following: + - "rockchip,px30-grf", "syscon": for px30 - "rockchip,rk3036-grf", "syscon": for rk3036 - "rockchip,rk3066-grf", "syscon": for rk3066 - "rockchip,rk3188-grf", "syscon": for rk3188 @@ -23,6 +24,7 @@ Required Properties: - "rockchip,rk3399-grf", "syscon": for rk3399 - "rockchip,rv1108-grf", "syscon": for rv1108 - compatible: PMUGRF should be one of the following: + - "rockchip,px30-pmugrf", "syscon": for px30 - "rockchip,rk3368-pmugrf", "syscon": for rk3368 - "rockchip,rk3399-pmugrf", "syscon": for rk3399 - compatible: SGRF should be one of the following -- 1.9.1
[PATCH v3 3/4] arm64: dts: rockchip: add core dtsi file for PX30 SoCs
From: Liang Chen
This patch adds core dtsi file for Rockchip PX30 SoCs.
Signed-off-by: Liang Chen
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 2043
1 file changed, 2043 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/px30.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
new file mode 100644
index 000..5e15aee
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -0,0 +1,2043 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "rockchip,px30";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 = &gmac;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ serial5 = &uart5;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&cru ARMCLK>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <90>;
+ operating-points-v2 = <&cpu0_opp_table>;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ operating-points-v2 = <&cpu0_opp_table>;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+ };
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ operating-points-v2 = <&cpu0_opp_table>;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+ };
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35", "arm,armv8";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ operating-points-v2 = <&cpu0_opp_table>;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+ };
+
+ idle-states {
+ entry-method = "psci";
+
+ CPU_SLEEP: cpu-sleep {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ arm,psci-suspend-param = <0x001>;
+ entry-latency-us = <120>;
+ exit-latency-us = <250>;
+ min-residency-us = <900>;
+ };
+
+ CLUSTER_SLEEP: cluster-sleep {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ arm,psci-suspend-param = <0x101>;
+ entry-latency-us = <400>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+ };
+ };
+
+ cpu0_opp_table: cpu0-opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-40800 {
+ opp-hz = /bits/ 64 <40800>;
+ opp-microvolt = <95 95 135>;
+ clock-latency-ns = <4>;
+ opp-suspend;
+ };
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <95 95 135>;
+ clock-latency-ns = <4>;
+ };
+ opp-81600 {
+ opp-hz = /bits/ 64 <81600>;
+ opp-microvolt = <105 105 135>;
+ clock-latency-ns = <4>;
+ };
+ opp-100800 {
+ opp-hz = /bits/ 64 <100800>;
+
[PATCH v3 4/4] arm64: dts: rockchip: add PX30 eavluation board devicetree
From: Liang Chen
This patch add px30-evb.dts for PX30 evaluation board.
Tested on PX30 evb.
Acked-by: Rob Herring
Signed-off-by: Liang Chen
---
Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/px30-evb.dts | 470 +
3 files changed, 475 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/px30-evb.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 1c1d62d..e33b23a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -158,6 +158,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
+- Rockchip PX30 evb:
+Required root node properties:
+ - compatible = "rockchip,px30-evb", "rockchip,px30";
+
- Rockchip RK3368 evb:
Required root node properties:
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 48a83f8..19aa9c6 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -14,3 +14,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
diff --git a/arch/arm64/boot/dts/rockchip/px30-evb.dts
b/arch/arm64/boot/dts/rockchip/px30-evb.dts
new file mode 100644
index 000..f7bd2e3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/px30-evb.dts
@@ -0,0 +1,470 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include "px30.dtsi"
+
+/ {
+ model = "Rockchip PX30 EVB";
+ compatible = "rockchip,px30-evb", "rockchip,px30";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 2>;
+ io-channel-names = "buttons";
+ poll-interval = <100>;
+ keyup-threshold-microvolt = <180>;
+
+ esc-key {
+ linux,code = ;
+ label = "esc";
+ press-threshold-microvolt = <131>;
+ };
+
+ home-key {
+ linux,code = ;
+ label = "home";
+ press-threshold-microvolt = <624000>;
+ };
+
+ menu-key {
+ linux,code = ;
+ label = "menu";
+ press-threshold-microvolt = <987000>;
+ };
+
+ vol-down-key {
+ linux,code = ;
+ label = "volume down";
+ press-threshold-microvolt = <30>;
+ };
+
+ vol-up-key {
+ linux,code = ;
+ label = "volume up";
+ press-threshold-microvolt = <17000>;
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 25000 0>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS2,150n8";
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+
+ /*
+* On the module itself this is one of these (depending
+* on the actual card populated):
+* - SDIO_RESET_L_WL_REG_ON
+* - PDN (power down when low)
+*/
+ reset-gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>; /* GPIO3_A4 */
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc5v0_sys: vccsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&display_subsystem {
+ status = "okay";
+};
+
+&emmc {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ status = "okay";
+};
+
+&gmac {
+ phy-supply = <&vcc_phy>;
+ clock_in_out = "output";
+ snps,reset-gpio = <&gpio2 13 GPIO_ACTIVE_LOW>;
+ snps
Re: [QUESTION] llist: Comment releasing 'must delete' restriction before traversing
On Wed, Aug 01, 2018 at 01:43:10PM +0800, Huang, Ying wrote: > Byungchul Park writes: > > > I think rcu list also works well. But I decided to use llist because > > llist is simpler and has one less pointer. > > > > Just to be sure, let me explain my use case more: > > > >1. Introduced a global list where single linked list is sufficient. > >2. All operations I need is to add items and traverse the list. > >3. Ensure the operations always happen within irq-disabled section. > >4. I'm considering CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG properly. > >5. The list can be accessed by every CPU concurrently. > > > > Can you provide more information about where is your use case? Is it a > kernel driver? Then it is better to submit the patch together with its > user. > > And I have the similar concern as Steven Rostedt. That is, if you are > the only user forever, it's not necessary to change the common code. I'm sorry the patch is too complicated and premature to share at the moment so I don't know how to extract only what you're asking me for. Thanks anyway. The common code doesn't have to be changed then. > Best Regards, > Huang, Ying
Re: [PATCH 6/7] x86/vdso: Add vDSO functions for user wait instructions
On Tue, 31 Jul 2018, Andy Lutomirski wrote: > On Tue, Jul 31, 2018 at 2:22 PM, Thomas Gleixner wrote: > >> u64 start = __vdso_read_art_ns(); > > > > Errm. No. You can't read ART. ART is only used by decives to which it is > > distributed. You can only read TSC here and convert that to nsecs. > > Bah. > > But my point remains -- I think that the user (non-vDSO) code should > think in nanoseconds, not TSC ticks. That we have have a much better > chance of getting migration right. Agreed. And we should not create new interfaces for that. We already have clock_gettime() which is the right thing to use. > > A possible solution would be to use CLOCK_MOTONIC_RAW which is not affected > > by NTP/PTP adjustments. But that still has the issue of TSC not being the > > timekeeping clocksource. Bah, the whole TSC deadline mode sucks. I have no > > idea what's wrong with simple down counters. They Just Work. > > I think it's not totally crazy to declare UMWAIT on a system with a > non-TSC clocksource to be unsupported. Sure, the information is already available in the VDSO gtod data. Thanks, tglx
Re: [PATCH v2 03/10] mfd: wcd9335: add wcd irq support
Thanks for the review, On 31/07/18 21:45, Rob Herring wrote: On Fri, Jul 27, 2018 at 01:17:59PM +0100, Srinivas Kandagatla wrote: WCD9335 supports two lines of irqs INTR1 and INTR2. Multiple interrupts are muxed via these lines. INTR1 consists of all possible interrupt sources like: Ear OCP, HPH OCP, MBHC, MAD, VBAT, and SVA INTR2 is a subset of first interrupt sources like MAD, VBAT, and SVA Signed-off-by: Srinivas Kandagatla --- drivers/mfd/Makefile| 2 +- drivers/mfd/wcd9335-core.c | 9 ++ drivers/mfd/wcd9335-irq.c | 172 include/dt-bindings/mfd/wcd9335.h | 43 + I'm confused why these are defined here. The binding for the wc9335 is not an interrupt-controller. I can move this defines to include/linux/mfd/wcd9335/wcd9335.h as there are no active users for this, but I was hoping that these can be used in DT in future. WCD9335 is an interrupt controller too. It muxes multiple interrupts via a gpio line interrupt. I did mention this in the bindings. +- interrupt-controller: + Usage: required + Definition: Indicating that this is a interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: should be 1 + include/linux/mfd/wcd9335/wcd9335.h | 3 + 5 files changed, 228 insertions(+), 1 deletion(-) create mode 100644 drivers/mfd/wcd9335-irq.c create mode 100644 include/dt-bindings/mfd/wcd9335.h Thanks, srini
Re: [PATCH v2 05/10] ASoC: wcd9335: add CLASS-H Controller support
Thanks for the review,
On 31/07/18 18:05, Mark Brown wrote:
On Fri, Jul 27, 2018 at 01:18:01PM +0100, Srinivas Kandagatla wrote:
+ res_val = WCD9XXX_CLASSH_CTRL_VCL_VREF_FILT_R_0KOHM;
+ switch (mode) {
+ case CLS_H_NORMAL:
+ res_val = WCD9XXX_CLASSH_CTRL_VCL_VREF_FILT_R_50KOHM;
+ val = WCD9XXX_A_ANA_HPH_PWR_LEVEL_NORMAL;
+ gain = DAC_GAIN_0DB;
+ ipeak = WCD9XXX_CLASSH_CTRL_CCL_1_DELTA_IPEAK_50MA;
+ break;
+ case CLS_AB:
+ val = WCD9XXX_A_ANA_HPH_PWR_LEVEL_NORMAL;
+ gain = DAC_GAIN_0DB;
+ ipeak = WCD9XXX_CLASSH_CTRL_CCL_1_DELTA_IPEAK_50MA;
+ break;
+ case CLS_H_HIFI:
+ val = WCD9XXX_A_ANA_HPH_PWR_LEVEL_UHQA;
+ gain = DAC_GAIN_M0P2DB;
+ ipeak = WCD9XXX_CLASSH_CTRL_CCL_1_DELTA_IPEAK_50MA;
+ break;
+ case CLS_H_LP:
+ val = WCD9XXX_A_ANA_HPH_PWR_LEVEL_LP;
+ ipeak = WCD9XXX_CLASSH_CTRL_CCL_1_DELTA_IPEAK_30MA;
+ break;
+ };
This is missing a default case for error checking, and you don't need
the semicolon at the end either.
These states are validated before any calls are made to these functions.
However I agree without on default case for error checking and ;
I will fix this in next version.
thanks,
srini
Re: [PATCH v2 06/10] ASoC: wcd9335: add basic controls
Thanks for the review.
On 31/07/18 18:16, Mark Brown wrote:
On Fri, Jul 27, 2018 at 01:18:02PM +0100, Srinivas Kandagatla wrote:
+static const char * const wcd9335_ear_pa_gain_text[] = {
+ "G_6_DB", "G_4P5_DB", "G_3_DB", "G_1P5_DB",
+ "G_0_DB", "G_M2P5_DB", "UNDEFINED", "G_M12_DB"
+};
This is fairly clearly a volume control so shouldn't be an enum. I
don't think we have a standard control that enables you to skip values
in a regular volume control (we do for enums which you should've used
rather than having the undefined entry) so you'd have to have custom get
and put operators but that's better than abusing an enum.
I agree, this can be a TLV, I will fix any such instances in next version.
+static const char * const rx_hph_mode_mux_text[] = {
+ "CLS_H_INVALID", "CLS_H_HIFI", "CLS_H_LP", "CLS_AB", "CLS_H_LOHIFI"
+};
Use a SOC_VALUE_ENUM to hide the invalid option from users.
Yep.
+ wcd->comp_enabled[comp] = value;
+ sel = value ? WCD9335_HPH_GAIN_SRC_SEL_COMPANDER :
+ WCD9335_HPH_GAIN_SRC_SEL_REGISTER;
Just write normal if statements unless there's a reason not to, it's
easier to read.
Will do that in next version.
thanks,
srini
Re: [PATCH v2 02/10] mfd: wcd9335: add support to wcd9335 core
Thanks for reviewing,
On 30/07/18 05:12, Vinod wrote:
On 27-07-18, 13:17, Srinivas Kandagatla wrote:
+obj-$(CONFIG_MFD_WCD9335) += wcd9335.o
+wcd9335-objs := wcd9335-core.o
+
no slimbus objs?
Yep, I will try to tidy this up a bit in next version.
+static int wcd9335_bring_up(struct wcd9335 *wcd)
+{
+ struct regmap *rm = wcd->regmap;
+ int val, byte0;
+ int ret = 0;
+
+ regmap_read(rm, WCD9335_CHIP_TIER_CTRL_EFUSE_VAL_OUT0, &val);
+ regmap_read(rm, WCD9335_CHIP_TIER_CTRL_CHIP_ID_BYTE0, &byte0);
+
+ if ((val < 0) || (byte0 < 0)) {
+ dev_err(wcd->dev, "wcd9335 codec version detection fail!\n");
+ return -EINVAL;
+ }
+
+ if (byte0 == 0x1) {
+ dev_info(wcd->dev, "wcd9335 codec version is v2.0\n");
+ wcd->version = WCD9335_VERSION_2_0;
+ regmap_write(rm, WCD9335_CODEC_RPM_RST_CTL, 0x01);
+ regmap_write(rm, WCD9335_SIDO_SIDO_TEST_2, 0x00);
+ regmap_write(rm, WCD9335_SIDO_SIDO_CCL_8, 0x6F);
+ regmap_write(rm, WCD9335_BIAS_VBG_FINE_ADJ, 0x65);
+ regmap_write(rm, WCD9335_CODEC_RPM_PWR_CDC_DIG_HM_CTL, 0x5);
+ regmap_write(rm, WCD9335_CODEC_RPM_PWR_CDC_DIG_HM_CTL, 0x7);
+ regmap_write(rm, WCD9335_CODEC_RPM_PWR_CDC_DIG_HM_CTL, 0x3);
+ regmap_write(rm, WCD9335_CODEC_RPM_RST_CTL, 0x3);
+ } else {
+ dev_err(wcd->dev, "wcd9335 codec version not supported\n");
+ ret = -EINVAL;
+ }
+
+ return ret;
we can do return 0 and remove the variable as it is not used anywhere
else.
Yes, it makes sense!
Thanks,
srini
Re: [PATCH v2 01/10] ASoC: dt-bindings: add dt bindings for wcd9335 audio codec
Thanks for the review.
On 31/07/18 21:43, Rob Herring wrote:
+
+- reset-gpio:
reset-gpios
Yep, reset-gpios makes more inline with others!
+ Usage: required
+ Value type:
+ Definition: Reset gpio line
+
+- qcom,ifd:
+ Usage: required
+ Value type:
+ Definition: SLIM interface device
Wouldn't this be the parent?
No, Interface device is just like other slim device and is part of
SLIMbus Component and has a unique address. Every SLIMbus component has
one interface device.
...
+
+codec@1{
audio-codec@1
Yep, I will fix this in next version.
+ compatible = "slim217,1a0";
+ reg = <1 0>;
Thanks,
srini
[PATCH v5 1/4] ASoC: qcom: dt-bindings: Add sdm845 machine bindings
Add devicetree bindings documentation file for SDM845 sound card.
Reviewed-by: Rob Herring
Signed-off-by: Rohit kumar
---
.../devicetree/bindings/sound/qcom,sdm845.txt | 80 ++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/qcom,sdm845.txt
diff --git a/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
new file mode 100644
index 000..408c483
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
@@ -0,0 +1,80 @@
+* Qualcomm Technologies Inc. SDM845 ASoC sound card driver
+
+This binding describes the SDM845 sound card, which uses qdsp for audio.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,sdm845-sndcard"
+
+- audio-routing:
+ Usage: Optional
+ Value type:
+ Definition: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names could be power supplies, MicBias
+ of codec and the jacks on the board.
+
+- model:
+ Usage: required
+ Value type:
+ Definition: The user-visible name of this sound card.
+
+= dailinks
+Each subnode of sndcard represents either a dailink, and subnodes of each
+dailinks would be cpu/codec/platform dais.
+
+- link-name:
+ Usage: required
+ Value type:
+ Definition: User friendly name for dai link
+
+= CPU, PLATFORM, CODEC dais subnodes
+- cpu:
+ Usage: required
+ Value type:
+ Definition: cpu dai sub-node
+
+- codec:
+ Usage: required
+ Value type:
+ Definition: codec dai sub-node
+
+- platform:
+ Usage: Optional
+ Value type:
+ Definition: platform dai sub-node
+
+- sound-dai:
+ Usage: required
+ Value type:
+ Definition: dai phandle/s and port of CPU/CODEC/PLATFORM node.
+
+Example:
+
+audio {
+ compatible = "qcom,sdm845-sndcard";
+ model = "sdm845-snd-card";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pri_mi2s_active &pri_mi2s_ws_active>;
+ pinctrl-1 = <&pri_mi2s_sleep &pri_mi2s_ws_sleep>;
+
+ mm1-dai-link {
+ link-name = "MultiMedia1";
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ pri-mi2s-dai-link {
+ link-name = "PRI MI2S Playback";
+ cpu {
+ sound-dai = <&q6afedai PRIMARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+ };
+};
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v5 0/4] Add support for audio on SDM845 SoC
This provides initial patchset to support audio on Qualcomm Techonologies Inc. SDM845 SoC. Currently, it supports audio playback/capture over Primary MI2S and Quaternary TDM ports. Changes since v4: - Used snd_mask_set_format() instead of snd_mask_set() to avoid sparse warning. Rohit kumar (4): ASoC: qcom: dt-bindings: Add sdm845 machine bindings ASoC: dt-bindings: Update dt binding name for apq8096 ASoC: qcom: Add support to parse common audio device nodes ASoC: qcom: add sdm845 sound card support .../devicetree/bindings/sound/qcom,apq8096.txt | 15 +- .../devicetree/bindings/sound/qcom,sdm845.txt | 80 ++ sound/soc/qcom/Kconfig | 8 + sound/soc/qcom/Makefile| 4 +- sound/soc/qcom/apq8096.c | 111 +--- sound/soc/qcom/common.c| 112 sound/soc/qcom/common.h| 12 + sound/soc/qcom/sdm845.c| 286 + 8 files changed, 525 insertions(+), 103 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,sdm845.txt create mode 100644 sound/soc/qcom/common.c create mode 100644 sound/soc/qcom/common.h create mode 100644 sound/soc/qcom/sdm845.c -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v5 3/4] ASoC: qcom: Add support to parse common audio device nodes
This adds support to parse cpu, platform and codec
device nodes and add them in dai-links. Also, update
apq8096 machine driver to use the common API.
Acked-by: Srinivas Kandagatla
Signed-off-by: Rohit kumar
---
sound/soc/qcom/Makefile | 2 +-
sound/soc/qcom/apq8096.c | 111 +-
sound/soc/qcom/common.c | 112 +++
sound/soc/qcom/common.h | 12 +
4 files changed, 136 insertions(+), 101 deletions(-)
create mode 100644 sound/soc/qcom/common.c
create mode 100644 sound/soc/qcom/common.h
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 206945b..fefecc0 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
# Machine
snd-soc-storm-objs := storm.o
snd-soc-apq8016-sbc-objs := apq8016_sbc.o
-snd-soc-apq8096-objs := apq8096.o
+snd-soc-apq8096-objs := apq8096.o common.o
obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
index a561562..1e4a90d 100644
--- a/sound/soc/qcom/apq8096.c
+++ b/sound/soc/qcom/apq8096.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include "common.h"
static int apq8096_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
struct snd_pcm_hw_params *params)
@@ -24,109 +25,16 @@ static int apq8096_be_hw_params_fixup(struct
snd_soc_pcm_runtime *rtd,
return 0;
}
-static int apq8096_sbc_parse_of(struct snd_soc_card *card)
+static void apq8096_add_be_ops(struct snd_soc_card *card)
{
- struct device_node *np;
- struct device_node *codec = NULL;
- struct device_node *platform = NULL;
- struct device_node *cpu = NULL;
- struct device *dev = card->dev;
- struct snd_soc_dai_link *link;
- int ret, num_links;
-
- ret = snd_soc_of_parse_card_name(card, "qcom,model");
- if (ret) {
- dev_err(dev, "Error parsing card name: %d\n", ret);
- return ret;
- }
-
- /* DAPM routes */
- if (of_property_read_bool(dev->of_node, "qcom,audio-routing")) {
- ret = snd_soc_of_parse_audio_routing(card,
- "qcom,audio-routing");
- if (ret)
- return ret;
- }
-
- /* Populate links */
- num_links = of_get_child_count(dev->of_node);
-
- /* Allocate the DAI link array */
- card->dai_link = kcalloc(num_links, sizeof(*link), GFP_KERNEL);
- if (!card->dai_link)
- return -ENOMEM;
+ struct snd_soc_dai_link *link = card->dai_link;
+ int i, num_links = card->num_links;
- card->num_links = num_links;
- link = card->dai_link;
-
- for_each_child_of_node(dev->of_node, np) {
- cpu = of_get_child_by_name(np, "cpu");
- if (!cpu) {
- dev_err(dev, "Can't find cpu DT node\n");
- ret = -EINVAL;
- goto err;
- }
-
- link->cpu_of_node = of_parse_phandle(cpu, "sound-dai", 0);
- if (!link->cpu_of_node) {
- dev_err(card->dev, "error getting cpu phandle\n");
- ret = -EINVAL;
- goto err;
- }
-
- ret = snd_soc_of_get_dai_name(cpu, &link->cpu_dai_name);
- if (ret) {
- dev_err(card->dev, "error getting cpu dai name\n");
- goto err;
- }
-
- platform = of_get_child_by_name(np, "platform");
- codec = of_get_child_by_name(np, "codec");
- if (codec && platform) {
- link->platform_of_node = of_parse_phandle(platform,
- "sound-dai",
- 0);
- if (!link->platform_of_node) {
- dev_err(card->dev, "platform dai not found\n");
- ret = -EINVAL;
- goto err;
- }
-
- ret = snd_soc_of_get_dai_link_codecs(dev, codec, link);
- if (ret < 0) {
- dev_err(card->dev, "codec dai not found\n");
- goto err;
- }
- link->no_pcm = 1;
- link->ignore_pmdown_time = 1;
+ for (i = 0; i < num_links; i++) {
+ if (link->no_pcm == 1)
link->be_hw_params_fixup = apq8096_be_hw_params_fixup;
- } else {
- link->platform_of_node = link->cpu_of_node;
- link->codec_dai_name
[PATCH v8 3/4] powerpc/lib: implement strlen() in assembly for PPC32
The generic implementation of strlen() reads strings byte per byte. This patch implements strlen() in assembly based on a read of entire words, in the same spirit as what some other arches and glibc do. On a 8xx the time spent in strlen is reduced by 3/4 for long strings. strlen() selftest on an 8xx provides the following values: Before the patch (ie with the generic strlen() in lib/string.c): len 256 : time = 1.195055 len 016 : time = 0.083745 len 008 : time = 0.046828 len 004 : time = 0.028390 After the patch: len 256 : time = 0.272185 ==> 78% improvment len 016 : time = 0.040632 ==> 51% improvment len 008 : time = 0.033060 ==> 29% improvment len 004 : time = 0.029149 ==> 2% degradation On a 832x: Before the patch: len 256 : time = 0.236125 len 016 : time = 0.018136 len 008 : time = 0.011000 len 004 : time = 0.007229 After the patch: len 256 : time = 0.094950 ==> 60% improvment len 016 : time = 0.013357 ==> 26% improvment len 008 : time = 0.010586 ==> 4% improvment len 004 : time = 0.008784 Signed-off-by: Christophe Leroy --- Changes in v8: - No change Changes in v7: - Reduced the scope to PPC32 - Modified the missalignment handling to be branchless and loopless Changes in v6: - Reworked for having branchless conclusion Changes in v5: - Fixed for PPC64 LITTLE ENDIAN Changes in v4: - Added alignment of the loop - doing the andc only if still not 0 as it happends only for bytes above 0x7f which is pretty rare in a string Changes in v3: - Made it common to PPC32 and PPC64 Changes in v2: - Moved handling of unaligned strings outside of the main path as it is very unlikely. - Removed the verification of the fourth byte in case none of the three first ones are NUL. arch/powerpc/include/asm/string.h | 2 + arch/powerpc/lib/Makefile | 2 +- arch/powerpc/lib/strlen_32.S | 78 +++ 3 files changed, 81 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/lib/strlen_32.S diff --git a/arch/powerpc/include/asm/string.h b/arch/powerpc/include/asm/string.h index 9b8cedf618f4..1647de15a31e 100644 --- a/arch/powerpc/include/asm/string.h +++ b/arch/powerpc/include/asm/string.h @@ -50,6 +50,8 @@ static inline void *memset64(uint64_t *p, uint64_t v, __kernel_size_t n) return __memset64(p, v, n * 8); } #else +#define __HAVE_ARCH_STRLEN + extern void *memset16(uint16_t *, uint16_t, __kernel_size_t); #endif #endif /* __KERNEL__ */ diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index d0ca13ad8231..670286808928 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -12,7 +12,7 @@ CFLAGS_REMOVE_feature-fixups.o = $(CC_FLAGS_FTRACE) obj-y += string.o alloc.o code-patching.o feature-fixups.o -obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o +obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o strlen_32.o # See corresponding test in arch/powerpc/Makefile # 64-bit linker creates .sfpr on demand for final link (vmlinux), diff --git a/arch/powerpc/lib/strlen_32.S b/arch/powerpc/lib/strlen_32.S new file mode 100644 index ..0a8d3f64d493 --- /dev/null +++ b/arch/powerpc/lib/strlen_32.S @@ -0,0 +1,78 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * strlen() for PPC32 + * + * Copyright (C) 2018 Christophe Leroy CS Systemes d'Information. + * + * Inspired from glibc implementation + */ +#include +#include +#include + + .text + +/* + * Algorithm: + * + * 1) Given a word 'x', we can test to see if it contains any 0 bytes + *by subtracting 0x01010101, and seeing if any of the high bits of each + *byte changed from 0 to 1. This works because the least significant + *0 byte must have had no incoming carry (otherwise it's not the least + *significant), so it is 0x00 - 0x01 == 0xff. For all other + *byte values, either they have the high bit set initially, or when + *1 is subtracted you get a value in the range 0x00-0x7f, none of which + *have their high bit set. The expression here is + *(x - 0x01010101) & ~x & 0x80808080), which gives 0x when + *there were no 0x00 bytes in the word. You get 0x80 in bytes that + *match, but possibly false 0x80 matches in the next more significant + *byte to a true match due to carries. For little-endian this is + *of no consequence since the least significant match is the one + *we're interested in, but big-endian needs method 2 to find which + *byte matches. + * 2) Given a word 'x', we can test to see _which_ byte was zero by + *calculating ~(((x & ~0x80808080) - 0x80808080 - 1) | x | ~0x80808080). + *This produces 0x80 in each byte that was zero, and 0x00 in all + *the other bytes. The '| ~0x80808080' clears the low 7 bits in each + *byte, and the '| x' part ensures that bytes with the high bit set + *produce 0x00. The addition will carry into the high bit of each byte + *iff that byte had one of its low 7 bits set. We can then just see
[PATCH v8 1/4] selftests/powerpc: add test for 32 bits memcmp
This patch renames memcmp test to memcmp_64 and adds a memcmp_32 test for testing the 32 bits version of memcmp() Signed-off-by: Christophe Leroy --- v8: rebased on latest powerpc/merge v7: no change v6: no change v5: no change v4: new tools/testing/selftests/powerpc/stringloops/Makefile| 14 +++--- tools/testing/selftests/powerpc/stringloops/memcmp_32.S | 1 + 2 files changed, 12 insertions(+), 3 deletions(-) create mode 12 tools/testing/selftests/powerpc/stringloops/memcmp_32.S diff --git a/tools/testing/selftests/powerpc/stringloops/Makefile b/tools/testing/selftests/powerpc/stringloops/Makefile index c60c6172dd3c..3862256c2b7d 100644 --- a/tools/testing/selftests/powerpc/stringloops/Makefile +++ b/tools/testing/selftests/powerpc/stringloops/Makefile @@ -1,10 +1,18 @@ # SPDX-License-Identifier: GPL-2.0 # The loops are all 64-bit code -CFLAGS += -m64 -maltivec CFLAGS += -I$(CURDIR) -TEST_GEN_PROGS := memcmp -EXTRA_SOURCES := memcmp_64.S ../harness.c +EXTRA_SOURCES := ../harness.c + +$(OUTPUT)/memcmp_64: memcmp.c +$(OUTPUT)/memcmp_64: CFLAGS += -m64 -maltivec + +$(OUTPUT)/memcmp_32: memcmp.c +$(OUTPUT)/memcmp_32: CFLAGS += -m32 + +ASFLAGS = $(CFLAGS) + +TEST_GEN_PROGS := memcmp_32 memcmp_64 include ../../lib.mk diff --git a/tools/testing/selftests/powerpc/stringloops/memcmp_32.S b/tools/testing/selftests/powerpc/stringloops/memcmp_32.S new file mode 12 index ..056f2b3af789 --- /dev/null +++ b/tools/testing/selftests/powerpc/stringloops/memcmp_32.S @@ -0,0 +1 @@ +../../../../../arch/powerpc/lib/memcmp_32.S \ No newline at end of file -- 2.13.3
[PATCH v5 2/4] ASoC: dt-bindings: Update dt binding name for apq8096
Remove qcom prefix from machine driver dt bindings of
apq8096 SoC.
Acked-by: Srinivas Kandagatla
Reviewed-by: Rob Herring
Signed-off-by: Rohit kumar
---
Documentation/devicetree/bindings/sound/qcom,apq8096.txt | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
index c7600a9..c814e86 100644
--- a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
+++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
@@ -7,7 +7,7 @@ This binding describes the APQ8096 sound card, which uses qdsp
for audio.
Value type:
Definition: must be "qcom,apq8096-sndcard"
-- qcom,audio-routing:
+- audio-routing:
Usage: Optional
Value type:
Definition: A list of the connections between audio components.
@@ -49,6 +49,12 @@ This binding describes the APQ8096 sound card, which uses
qdsp for audio.
"DMIC1"
"DMIC2"
"DMIC3"
+
+- model:
+ Usage: required
+ Value type:
+ Definition: The user-visible name of this sound card.
+
= dailinks
Each subnode of sndcard represents either a dailink, and subnodes of each
dailinks would be cpu/codec/platform dais.
@@ -79,11 +85,16 @@ dailinks would be cpu/codec/platform dais.
Value type:
Definition: dai phandle/s and port of CPU/CODEC/PLATFORM node.
+Obsolete:
+ qcom,model: String for soundcard name (Use model instead)
+ qcom,audio-routing: A list of the connections between audio components.
+ (Use audio-routing instead)
+
Example:
audio {
compatible = "qcom,apq8096-sndcard";
- qcom,model = "DB820c";
+ model = "DB820c";
mm1-dai-link {
link-name = "MultiMedia1";
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v5 4/4] ASoC: qcom: add sdm845 sound card support
This patch adds sdm845 audio machine driver support.
Acked-by: Srinivas Kandagatla
Signed-off-by: Rohit kumar
---
sound/soc/qcom/Kconfig | 8 ++
sound/soc/qcom/Makefile | 2 +
sound/soc/qcom/sdm845.c | 286
3 files changed, 296 insertions(+)
create mode 100644 sound/soc/qcom/sdm845.c
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 87838fa..3507308 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -90,3 +90,11 @@ config SND_SOC_MSM8996
Support for Qualcomm Technologies LPASS audio block in
APQ8096 SoC-based systems.
Say Y if you want to use audio device on this SoCs
+
+config SND_SOC_SDM845
+ tristate "SoC Machine driver for SDM845 boards"
+ select SND_SOC_QDSP6
+ help
+ To add support for audio on Qualcomm Technologies Inc.
+ SDM845 SoC-based systems.
+ Say Y if you want to use audio device on this SoCs.
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index fefecc0..f0e94d4 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -14,10 +14,12 @@ obj-$(CONFIG_SND_SOC_LPASS_APQ8016) +=
snd-soc-lpass-apq8016.o
snd-soc-storm-objs := storm.o
snd-soc-apq8016-sbc-objs := apq8016_sbc.o
snd-soc-apq8096-objs := apq8096.o common.o
+snd-soc-sdm845-objs := sdm845.o common.o
obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
obj-$(CONFIG_SND_SOC_MSM8996) += snd-soc-apq8096.o
+obj-$(CONFIG_SND_SOC_SDM845) += snd-soc-sdm845.o
#DSP lib
obj-$(CONFIG_SND_SOC_QDSP6) += qdsp6/
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
new file mode 100644
index 000..bf4ec4646
--- /dev/null
+++ b/sound/soc/qcom/sdm845.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "common.h"
+#include "qdsp6/q6afe.h"
+
+#define DEFAULT_SAMPLE_RATE_48K48000
+#define DEFAULT_MCLK_RATE 24576000
+#define DEFAULT_BCLK_RATE 12288000
+
+struct sdm845_snd_data {
+ struct snd_soc_card *card;
+ uint32_t pri_mi2s_clk_count;
+ uint32_t quat_tdm_clk_count;
+};
+
+static unsigned int tdm_slot_offset[8] = {0, 4, 8, 12, 16, 20, 24, 28};
+
+static int sdm845_tdm_snd_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int ret = 0;
+ int channels, slot_width;
+
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ slot_width = 32;
+ break;
+ default:
+ dev_err(rtd->dev, "%s: invalid param format 0x%x\n",
+ __func__, params_format(params));
+ return -EINVAL;
+ }
+
+ channels = params_channels(params);
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ ret = snd_soc_dai_set_tdm_slot(cpu_dai, 0, 0x3,
+ 8, slot_width);
+ if (ret < 0) {
+ dev_err(rtd->dev, "%s: failed to set tdm slot,
err:%d\n",
+ __func__, ret);
+ goto end;
+ }
+
+ ret = snd_soc_dai_set_channel_map(cpu_dai, 0, NULL,
+ channels, tdm_slot_offset);
+ if (ret < 0) {
+ dev_err(rtd->dev, "%s: failed to set channel map,
err:%d\n",
+ __func__, ret);
+ goto end;
+ }
+ } else {
+ ret = snd_soc_dai_set_tdm_slot(cpu_dai, 0xf, 0,
+ 8, slot_width);
+ if (ret < 0) {
+ dev_err(rtd->dev, "%s: failed to set tdm slot,
err:%d\n",
+ __func__, ret);
+ goto end;
+ }
+
+ ret = snd_soc_dai_set_channel_map(cpu_dai, channels,
+ tdm_slot_offset, 0, NULL);
+ if (ret < 0) {
+ dev_err(rtd->dev, "%s: failed to set channel map,
err:%d\n",
+ __func__, ret);
+ goto end;
+ }
+ }
+end:
+ return ret;
+}
+
+static int sdm845_snd_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int ret = 0;
+
+ switch (cpu_dai->id) {
+ case QUATERNARY_TDM_RX_0:
+ case QU
Re: [PATCH 4/7] x86/umwait_contro: Set global umwait maximum time limit and umwait C0.2 state
On Mon, 23 Jul 2018, Andy Lutomirski wrote: > On 07/23/2018 05:55 AM, Fenghua Yu wrote: > > UMWAIT or TPAUSE called by user process makes processor to reside in > > a light-weight power/performance optimized state (C0.1 state) or an > > improved power/performance optimized state (C0.2 state). > > > > IA32_UMWAIT_CONTROL MSR register allows OS to set global maximum umwait > > time and disable C0.2 on the processor. > > > > The maximum time value in IA32_UMWAIT_CONTROL[31-2] is set as zero which > > means there is no global time limit for UMWAIT and TPAUSE instructions. > > Each process sets its own umwait maximum time as the instructions operand. > > We don't set a non-zero global umwait maximum time value to enforce user > > wait timeout because we couldn't find any usage for it. > > Do you know what the instruction designers had in mind? I assume they were > thinking of *something*, but I'm seriously mystified by three things: > > - Why does CF work the way it does? It seems like it would be genuinely > useful for CF to indicate whether the in-register timeout has expired, but > that's not what CF does. Right, it would be useful to see whether the timeout caused the exit or something else. Thanks, tglx
[PATCH v2 1/2] leds: core: Introduce LED pattern trigger
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This patch adds pattern trigger that LED device can configure the
pattern and trigger it.
Signed-off-by: Raphael Teysseyre
Signed-off-by: Baolin Wang
---
Changes from v1:
- Use ATTRIBUTE_GROUPS() to define attributes.
- Introduce hardware_pattern flag to determine if software pattern
or hardware pattern.
- Re-implement pattern_trig_store_pattern() function.
- Remove pattern_get() interface.
- Improve comments.
- Other small optimization.
---
.../ABI/testing/sysfs-class-led-trigger-pattern| 21 ++
drivers/leds/trigger/Kconfig |7 +
drivers/leds/trigger/Makefile |1 +
drivers/leds/trigger/ledtrig-pattern.c | 273
include/linux/leds.h | 16 ++
5 files changed, 318 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
new file mode 100644
index 000..f9a4ac0
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
@@ -0,0 +1,21 @@
+What: /sys/class/leds//pattern
+Date: August 2018
+KernelVersion: 4.19
+Description:
+ Specify a pattern for the LED, for LED hardware that support
+ altering the brightness as a function of time.
+
+ The pattern is given by a series of tuples, of brightness and
+ duration (ms). The LED is expected to traverse the series and
+ each brightness value for the specified duration. Duration of
+ 0 means brightness should immediately change to new value.
+
+ The format of the pattern values should be:
+ "brightness_1 duration_1, brightness_2 duration_2, brightness_3
+ duration_3 ...".
+
+What: /sys/class/leds//repeat
+Date: August 2018
+KernelVersion: 4.19
+Description:
+ Specify a pattern repeat number. 0 means repeat indefinitely.
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 4018af7..b76fc3c 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV
This allows LEDs to be controlled by network device activity.
If unsure, say Y.
+config LEDS_TRIGGER_PATTERN
+ tristate "LED Pattern Trigger"
+ help
+ This allows LEDs to be controlled by a software or hardware pattern
+ which is a series of tuples, of brightness and duration (ms).
+ If unsure, say N
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index f3cfe19..9bcb64e 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
+obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o
diff --git a/drivers/leds/trigger/ledtrig-pattern.c
b/drivers/leds/trigger/ledtrig-pattern.c
new file mode 100644
index 000..006874b
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-pattern.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * LED pattern trigger
+ *
+ * Idea discussed with Pavel Machek. Raphael Teysseyre implemented
+ * the first version, Baolin Wang simplified and improved the approach.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_PATTERNS 1024
+#define PATTERN_SEPARATOR ","
+
+struct pattern_trig_data {
+ struct led_classdev *led_cdev;
+ struct led_pattern patterns[MAX_PATTERNS];
+ struct led_pattern *curr;
+ struct led_pattern *next;
+ struct mutex lock;
+ u32 npatterns;
+ u32 repeat;
+ bool is_indefinite;
+ bool hardware_pattern;
+ struct timer_list timer;
+};
+
+static void pattern_trig_update_patterns(struct pattern_trig_data *data)
+{
+ data->curr = data->next;
+ if (!data->is_indefinite && data->curr == data->patterns)
+ data->repeat--;
+
+ if (data->next == data->patterns + data->npatterns - 1)
+ data->next = data->patterns;
+ else
+ data->next++;
+}
+
+static void pattern_trig_timer_function(struct timer_list *t)
+{
+ struct pattern_trig_data *data = from_timer(data, t, timer);
+
+ mutex_lock(&data->lock);
+
+ if (!data->is_indefinite && !data->repeat) {
+ mutex_unlock(&data->lock);
+ return;
+ }
+
+ led_set_
[PATCH v2 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
---
changes from v1:
- Remove pattern_get interface.
---
drivers/leds/leds-sc27xx-bltc.c | 94 +++
1 file changed, 94 insertions(+)
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..297dd43 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,13 @@
#define SC27XX_DUTY_MASK GENMASK(15, 0)
#define SC27XX_MOD_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
#define SC27XX_LEDS_OFFSET 0x10
#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +127,91 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum
led_brightness value)
return err;
}
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ struct regmap *regmap = leds->priv->regmap;
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ int err;
+
+ mutex_lock(&leds->priv->lock);
+
+ /* Reset the rise, high, fall and low time to zero. */
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+ err = regmap_update_bits(regmap, ctrl_base,
+ (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+ mutex_unlock(&leds->priv->lock);
+
+ return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ int len, u32 repeat)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ struct regmap *regmap = leds->priv->regmap;
+ int err;
+
+ /*
+* Must contain 4 patterns to configure the rise time, high time, fall
+* time and low time to enable the breathing mode.
+*/
+ if (len != SC27XX_LEDS_PATTERN_CNT)
+ return -EINVAL;
+
+ mutex_lock(&leds->priv->lock);
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE0,
+SC27XX_CURVE_L_MASK, pattern[0].delta_t);
+ if (err)
+ goto out;
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE1,
+SC27XX_CURVE_L_MASK, pattern[1].delta_t);
+ if (err)
+ goto out;
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE0,
+SC27XX_CURVE_H_MASK,
+pattern[2].delta_t << SC27XX_CURVE_SHIFT);
+ if (err)
+ goto out;
+
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE1,
+SC27XX_CURVE_H_MASK,
+pattern[3].delta_t << SC27XX_CURVE_SHIFT);
+ if (err)
+ goto out;
+
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_DUTY,
+SC27XX_DUTY_MASK,
+(pattern[0].brightness << SC27XX_DUTY_SHIFT) |
+SC27XX_MOD_MASK);
+ if (err)
+ goto out;
+
+ /* Enable the LED breathing mode */
+ err = regmap_update_bits(regmap, ctrl_base,
+SC27XX_LED_RUN << ctrl_shift,
+SC27XX_LED_RUN << ctrl_shift);
+
+out:
+ mutex_unlock(&leds->priv->lock);
+
+ return err;
+}
+
static int sc27xx_led_register(struct device *dev, struct sc27xx_led_priv
*priv)
{
int i, err;
@@ -140,6 +230,9 @@ static int sc27xx_led_register(struct device *dev, struct
sc27xx_led_priv *priv)
led->priv = priv;
led->ldev.name = led->name;
led->ldev.brightness_set_blocking = sc27xx_led_set;
+ led->ldev.pattern_set = sc27xx_led_pattern_set;
+ led->ldev.pattern_clear = sc27xx_led_pattern_clear;
+ led->ldev.default_trigger = "pattern";
err = devm_led_classdev_register(dev, &led->ldev);
if (err)
@@ -241,4 +334,5 @@ static int sc27xx_led_remove(struct platform_device *pdev)
MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
MODULE_AUTHOR("Xiaotong Lu ");
+MODULE_AUTHOR("Baolin Wang ");
MODULE_LICENSE("GPL v2");
--
1.7.9.5
Re: [PATCH 1/2] staging: erofs: add the missing break in z_erofs_map_blocks_iter
On Wed, Aug 01, 2018 at 02:38:30PM +0800, Gao Xiang wrote:
> diff --git a/drivers/staging/erofs/unzip_vle.c
> b/drivers/staging/erofs/unzip_vle.c
> index bd2d7a8..6d3ab31 100644
> --- a/drivers/staging/erofs/unzip_vle.c
> +++ b/drivers/staging/erofs/unzip_vle.c
> @@ -1596,10 +1596,10 @@ int z_erofs_map_blocks_iter(struct inode *inode,
> cluster_type = vle_cluster_type(di);
>
> switch (cluster_type) {
> - case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:
> + case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:/* fallthrough */
This fallthrough comment is in the wrong place. It should be at the end
where the break would have been. Like this:
switch (cluster_type) {
case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:
frob();
frob();
frob();
/* fallthrough */
case Z_EROFS_VLE_CLUSTER_TYPE_HEAD:
frob();
regards,
dan carpenter
[PATCH RT] sched: drop is_special_task_state() check from __set_current_state_no_track()
The is_special_task_state() check in __set_current_state_no_track()
has been wrongly placed. __set_current_state_no_track() is used in RT
while a sleeping lock is acquired. It is used at the begin of the wait
loop with TASK_UNINTERRUPTIBLE and while leaving it and restoring the
original state. The latter part triggers the warning.
Drop the special state check. This is only used within the sleeping lock
implementation and the assignment happens while the PI lock is held.
While at it, drop set_current_state_no_track() because it has no users.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/sched.h | 8
1 file changed, 8 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a0c1c0cae992..b20264e17b02 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -132,16 +132,9 @@ struct task_group;
#define __set_current_state_no_track(state_value) \
do {\
- WARN_ON_ONCE(is_special_task_state(state_value));\
current->state = (state_value); \
} while (0)
-#define set_current_state_no_track(state_value)\
- do {\
- WARN_ON_ONCE(is_special_task_state(state_value));\
- smp_store_mb(current->state, (state_value));\
- } while (0)
-
#define set_special_state(state_value) \
do {\
unsigned long flags; /* may shadow */ \
@@ -196,7 +189,6 @@ struct task_group;
smp_store_mb(current->state, (state_value))
#define __set_current_state_no_track(state_value)
__set_current_state(state_value)
-#define set_current_state_no_track(state_value)
set_current_state(state_value)
/*
* set_special_state() should be used for those states when the blocking task
--
2.18.0
RE: [PATCH v2 0/4] arm64 SMMUv3 PMU driver with IORT support
Hi Lorenzo/Robin, Just a gentle ping on this series. This is a v2 for smmu pmcg support based on Neil Leeder's v1[1]. Main changes include, -an helper function to IORT to retrieve the associated SMMU info. -MSI support to the PMU driver. Please take a look and let me know your thoughts. Thanks, Shameer [1]https://www.spinics.net/lists/arm-kernel/msg598591.html > -Original Message- > From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of > Shameer Kolothum > Sent: 24 July 2018 12:45 > To: lorenzo.pieral...@arm.com; robin.mur...@arm.com > Cc: mark.rutl...@arm.com; vkil...@codeaurora.org; > neil.m.lee...@gmail.com; pa...@codeaurora.org; will.dea...@arm.com; > rruig...@codeaurora.org; Linuxarm ; linux- > ker...@vger.kernel.org; linux-a...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: [PATCH v2 0/4] arm64 SMMUv3 PMU driver with IORT support > > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > > This is based on the initial work done by Neil Leeder[1] > > SMMUv3 PMCG devices are named as arm_smmu_v3_x_pmcg_y where x > denotes the associated smmuv3 dev id(if any) and y denotes the > pmu dev id. > > Usage example: > For common arch supported events: > perf stat -e arm_smmu_v3_0_pmcg_6/transaction,filter_enable=1, > filter_span=1,filter_stream_id=0x42/ -a pwd > > For IMP DEF events: > perf stat -e arm_smmu_v3.0_pmcg.6/event=id/ -a pwd > > Sanity tested on HiSilicon platform. Further testing on supported > platforms are very much welcome. > > v1 --> v2 > > - Addressed comments from Robin. > - Added an helper to retrieve the associated smmu dev and named PMUs > to make the association visible to user. > - Added MSI support for overflow irq > > [1]https://www.spinics.net/lists/arm-kernel/msg598591.html > > Neil Leeder (2): > acpi: arm64: add iort support for PMCG > perf: add arm64 smmuv3 pmu driver > > Shameer Kolothum (2): > acpi: arm64: iort helper to find the associated smmu of pmcg node > perf/smmuv3: Add MSI irq support > > drivers/acpi/arm64/iort.c | 179 +++-- > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 901 > ++ > include/linux/acpi_iort.h | 4 + > 5 files changed, 1063 insertions(+), 31 deletions(-) > create mode 100644 drivers/perf/arm_smmuv3_pmu.c > > -- > 2.7.4 > > > ___ > Linuxarm mailing list > linux...@huawei.com > http://hulk.huawei.com/mailman/listinfo/linuxarm
Re: linux-next: build failure after merge of the staging tree
Hi Stephen,
On 2018/7/30 14:31, Gao Xiang wrote:
> Hi Stephen,
>
> On 2018/7/30 14:16, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> After merging the staging tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/staging/erofs/super.c: In function 'erofs_read_super':
>> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first
>> use in this function); did you mean 'IS_RDONLY'?
>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>> ^
>> IS_RDONLY
>> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is
>> reported only once for each function it appears in
>> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first
>> use in this function); did you mean 'S_NOATIME'?
>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>> ^~
>> S_NOATIME
>> drivers/staging/erofs/super.c: In function 'erofs_mount':
>> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of
>> 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
>>&priv, erofs_fill_super);
>> ^~~~
>> In file included from include/linux/buffer_head.h:12:0,
>> from drivers/staging/erofs/super.c:14:
>> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}'
>> but argument is of type 'int (*)(struct super_block *, void *, int)'
>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>^~
>> drivers/staging/erofs/super.c:500:9: error: too few arguments to function
>> 'mount_bdev'
>> return mount_bdev(fs_type, flags, dev_name,
>> ^~
>> In file included from include/linux/buffer_head.h:12:0,
>> from drivers/staging/erofs/super.c:14:
>> include/linux/fs.h:2151:23: note: declared here
>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>^~
>> drivers/staging/erofs/super.c: At top level:
>> drivers/staging/erofs/super.c:518:20: error: initialization from
>> incompatible pointer type [-Werror=incompatible-pointer-types]
>> .mount = erofs_mount,
>> ^~~
>> drivers/staging/erofs/super.c:518:20: note: (near initialization for
>> 'erofs_fs_type.mount')
>> drivers/staging/erofs/super.c: In function 'erofs_remount':
>> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first
>> use in this function); did you mean 'IS_RDONLY'?
>> *flags |= MS_RDONLY;
>> ^
>> IS_RDONLY
>> drivers/staging/erofs/super.c: At top level:
>> drivers/staging/erofs/super.c:640:16: error: initialization from
>> incompatible pointer type [-Werror=incompatible-pointer-types]
>> .remount_fs = erofs_remount,
>> ^
>>
>> Caused by various commits creating erofs in the staging tree interacting
>> with various commits redoing the mount infrastructure in the vfs tree.
>>
>> I have disabed CONFIG_EROFS_FS for now:
Xiang has submitted several patches as below to fix compiling error on -next
tree, could you consider to merge those temporary fixes into -next after merging
staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
compiling and test?
staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
staging: erofs: update .mount and .remount_sb
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
BTW, for this condition that erofs was not covered by some common vfs stuff
changes in other one's tree, who should take care of those missing fixes during
coming next merge window?
Thanks,
>
> I will fix them as soon as possible, and test it with the latest linux-next
> code.
> It seems caused by some vfs changes.
>
> Thanks,
> Gao Xiang
>
> .
>
Re: [PATCH 6/6] arm64: enable RapidIO menu in Kconfig
On Tue, Jul 31, 2018 at 04:29:56PM -0400, Alex Bounine wrote: > On 2018-07-31 08:54 AM, Alex Bounine wrote: > >On 2018-07-31 04:41 AM, Will Deacon wrote: > >>On Mon, Jul 30, 2018 at 06:50:34PM -0400, Alexei Colin wrote: > >>>Platforms with a PCI bus will be offered the RapidIO menu since they may > >>>be want support for a RapidIO PCI device. Platforms without a PCI bus > >>>that might include a RapidIO IP block will need to "select HAS_RAPIDIO" > >>>in the platform-/machine-specific "config ARCH_*" Kconfig entry. > >>> > >>>Tested that kernel builds for arm64 with RapidIO subsystem and > >>>switch drivers enabled, also that the modules load successfully > >>>on a custom Aarch64 Qemu model. > >>> > >>>Cc: Andrew Morton > >>>Cc: Russell King > >>>Cc: John Paul Walters > >>>Cc: linux-arm-ker...@lists.infradead.org > >>>Cc: linux-kernel@vger.kernel.org, > >>>Signed-off-by: Alexei Colin > >>>--- > >>> arch/arm64/Kconfig | 2 ++ > >>> 1 file changed, 2 insertions(+) > >> > >>Thanks, this looks much cleaner than before: > >> > >>Acked-by: Will Deacon > >> > >>The only thing I'm not sure about is why we don't just select HAS_RAPIDIO > >>unconditionally in the arm64 Kconfig. Does selecting only that option > >>actually pull in new code to the build? > >> > >HAS_RAPIDIO option is intended for SOCs that have built in SRIO > >controllers, like TI KeyStoneII or FPGAs. Because RapidIO subsystem core > >is required during RapidIO port driver initialization, having separate > >option allows us to control available build options for RapidIO core and > >port driver (bool vs. tristate) and disable module option if port driver > >is configured as built-in. > > I am thinking about where HAS_RAPIDIO option can be set for arm64 branch. > Having it set globally is too broad. For example we have Xilinx Zinq US > board with SRIO IP on it. Having it globally in arm64 branch - bad. Probably > having it set in drivers/soc/... is the best place. Why is selecting HAS_RAPIDIO globally a bad thing to do? The way these normally work is, if some subsystem requires arch support, then there's an ARCH_HAS_ option which the architecture selects when it implements that support. Once you've enabled that, then that allows other sub-options to be selected, such as specific drivers or what-not. Look at the Kconfig files under drivers/soc/ -- you don't see anybody selecting ARCH_HAS_* options. Now, if HAS_RAPIDIO alone is pulling in a whole load of code to the build, then it sounds like a misnomer. Confused. Will
Re: bisected - arm64 kvm unit test failures
On Wed, 2018-08-01 at 08:22 +0100, Marc Zyngier wrote: > On Wed, 01 Aug 2018 07:02:25 +0100, > Mike Galbraith wrote: > > > > [1 ] > > On Wed, 2018-08-01 at 06:35 +0100, Marc Zyngier wrote: > > > > > > Is it something that is reproducible with the current mainline (non-RT)? > > > > These waters are a bit muddy, it's config dependent. I'm trying to > > generate a reproducing !RT config for -rc7 as we speak. If I build > > openSUSE/master-default, it does NOT reproduce. That with the bisect > > config just finished building, and yup, it reproduced > > (attached). > > Thanks for that. Cheers. The dependency is THP, which is disabled in RT. --- config.save 2018-05-18 17:59:44.729165480 +0200 +++ .config 2018-08-01 11:00:24.484148316 +0200 @@ -632,7 +632,10 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y # CONFIG_HWPOISON_INJECT is not set -# CONFIG_TRANSPARENT_HUGEPAGE is not set +CONFIG_TRANSPARENT_HUGEPAGE=y +CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y +# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set +CONFIG_TRANSPARENT_HUGE_PAGECACHE=y CONFIG_CLEANCACHE=y CONFIG_FRONTSWAP=y CONFIG_CMA=y @@ -4306,6 +4309,7 @@ CONFIG_RAS=y # CONFIG_ANDROID is not set # CONFIG_LIBNVDIMM is not set CONFIG_DAX=y +# CONFIG_DEV_DAX is not set CONFIG_NVMEM=y # CONFIG_MTK_EFUSE is not set # CONFIG_QCOM_QFPROM is not set @@ -5175,6 +5179,7 @@ CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_LZ4=y CONFIG_GENERIC_ALLOCATOR=y +CONFIG_RADIX_TREE_MULTIORDER=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y
Re: [PATCH 1/2] staging: erofs: add the missing break in z_erofs_map_blocks_iter
Hi Dan,
On 2018/8/1 17:02, Dan Carpenter wrote:
> On Wed, Aug 01, 2018 at 02:38:30PM +0800, Gao Xiang wrote:
>> diff --git a/drivers/staging/erofs/unzip_vle.c
>> b/drivers/staging/erofs/unzip_vle.c
>> index bd2d7a8..6d3ab31 100644
>> --- a/drivers/staging/erofs/unzip_vle.c
>> +++ b/drivers/staging/erofs/unzip_vle.c
>> @@ -1596,10 +1596,10 @@ int z_erofs_map_blocks_iter(struct inode *inode,
>> cluster_type = vle_cluster_type(di);
>>
>> switch (cluster_type) {
>> -case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:
>> +case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:/* fallthrough */
> This fallthrough comment is in the wrong place. It should be at the end
> where the break would have been. Like this:
>
> switch (cluster_type) {
> case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:
> frob();
> frob();
> frob();
> /* fallthrough */
> case Z_EROFS_VLE_CLUSTER_TYPE_HEAD:
> frob();
>
I am sorry.. I will send a new patch.
Thanks for your reply...
Thanks,
Gao Xiang
> regards,
> dan carpenter
>
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Wednesday 01 Aug 2018 at 10:35:32 (+0200), Rafael J. Wysocki wrote: > On Wed, Aug 1, 2018 at 10:23 AM, Quentin Perret > wrote: > > On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote: > >> On Tue, Jul 31, 2018 at 9:31 PM, wrote: > >> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote: > >> >>> If it's going to be a different aggregation from what's done for > >> >>> frequency > >> >>> guidance, I don't see the point of having this inside schedutil. Why > >> >>> not > >> >>> keep it inside the scheduler files? > >> >> > >> >> This code basically results from a discussion we had with Peter on v4. > >> >> Keeping everything centralized can make sense from a maintenance > >> >> perspective, I think. That makes it easy to see the impact of any change > >> >> to utilization signals for both EAS and schedutil. > >> > > >> > In that case, I'd argue it makes more sense to keep the code centralized > >> > in > >> > the scheduler. The scheduler can let schedutil know about the utilization > >> > after it aggregates them. There's no need for a cpufreq governor to know > >> > that there are scheduling classes or how many there are. And the > >> > scheduler > >> > can then choose to aggregate one way for task packing and another way for > >> > frequency guidance. > >> > >> Also the aggregate utilization may be used by cpuidle governors in > >> principle to decide how deep they can go with idle state selection. > > > > The only issue I see with this right now is that some of the things done > > in this function are policy decisions which really belong to the governor, > > I think. > > Well, the scheduler makes policy decisions too, in quite a few places. :-) That is true ... ;-) But not so much about frequency selection yet I guess > The really important consideration here is whether or not there may be > multiple governors making different policy decisions in that respect. > If not, then where exactly the single policy decision is made doesn't > particularly matter IMO. I think some users of the aggregated utilization signal do want to make slightly different decisions (I'm thinking about the RT-go-to-max thing again which makes perfect sense in sugov, but could possibly hurt EAS). So the "hard" part of this work is to figure out what really is a governor-specific policy decision, and what is common between all users. I put "hard" between quotes because I only see the case of RT as truly sugov-specific for now. If we also want a special case for DL, Peter's enum should work OK, and enable to add more special cases for new users (cpuidle ?) if needed. But maybe that is something for later ? Thanks, Quentin
Re: [PATCH v2 2/5] regulator: rk808: add RK809 and RK817 support.
On Tue, Jul 31, 2018 at 03:57:27PM +0800, Tony Xie wrote:
> + default:
> + pr_warn("%s ramp_delay: %d not supported, setting 1\n",
> + rdev->desc->name, ramp_delay);
> + }
This looks mostly good but I notice that most of the prints in the
driver are pr_ rather than dev_ ones - using dev_ is better as it allows
people to see which device was affected.
signature.asc
Description: PGP signature
Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Make synic_initialized flag per-cpu
"Michael Kelley (EOSG)" writes:
> From: Vitaly Kuznetsov Sent: Tuesday, July 31, 2018
> 4:20 AM
>>
>> Alternatively, we can get rid of synic_initialized flag altogether:
>> hv_synic_init() never fails in the first place but we can always
>> implement something like:
>>
>> int hv_synic_is_initialized(void) {
>> union hv_synic_scontrol sctrl;
>>
>> hv_get_synic_state(sctrl.as_uint64);
>>
>> return sctrl.enable;
>> }
>>
>> as it doesn't seem that we need to check synic state on _other_ CPUs.
>>
>
> I was trying to decide if there are any arguments in favor of one
> approach vs. the other: a per-cpu flag in memory or checking
> the synic_control "enable" bit. Seems like a wash to me, in which
> case I have a slight preference for the per-cpu flag in memory vs.
> creating another function to return sctrl.enable. But I'm completely
> open to reasons why checking sctrl.enable is better.
Just a few thoughts: reading MSR is definitely slower but we avoid
'shadowing' the state, the reading is always correct. In case there's a
chance the SynIC will get disabled from host side we can only find this
out by doing MSR read. This is a purely theoretical possibility, I
believe, we can go ahead with this patch.
--
Vitaly
Re: [PATCH V4 5/7] mmc: sdhci: add Auto CMD Auto Select support
On 31 July 2018 at 17:36, Adrian Hunter wrote:
> On 31/07/18 12:20, Chunyan Zhang wrote:
>> On 31 July 2018 at 16:56, Adrian Hunter wrote:
>>> On 31/07/18 11:36, Chunyan Zhang wrote:
On 31 July 2018 at 16:05, Adrian Hunter wrote:
> On 31/07/18 10:04, Chunyan Zhang wrote:
>> Hi Adrian,
>>
>> On 30 July 2018 at 21:06, Adrian Hunter wrote:
>>> On 23/07/18 13:08, Chunyan Zhang wrote:
As SD Host Controller Specification v4.10 documents:
Host Controller Version 4.10 defines this "Auto CMD Auto Select" mode.
Selection of Auto CMD depends on setting of CMD23 Enable in the Host
Control 2 register which indicates whether card supports CMD23. If
CMD23
Enable =1, Auto CMD23 is used and if CMD23 Enable =0, Auto CMD12 is
used. In case of Version 4.10 or later, use of Auto CMD Auto Select is
recommended rather than use of Auto CMD12 Enable or Auto CMD23
Enable.
This patch add this new mode support.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 61
+++-
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 5acea3d..5c60590 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -311,6 +311,23 @@ static void sdhci_config_dma(struct sdhci_host
*host)
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
}
+static void sdhci_enable_cmd23(struct sdhci_host *host)
+{
+ u16 ctrl2;
+
+ /*
+ * This is used along with "Auto CMD Auto Select" feature,
+ * which is introduced from v4.10, if card supports CMD23,
+ * Auto CMD23 should be used instead of Auto CMD12.
+ */
+ if (host->version >= SDHCI_SPEC_410 &&
+ (host->mmc->caps & MMC_CAP_CMD23)) {
>>>
>>> That is the host capability. It needs to be the card capability.
>>
>> Could you please elaborate the issue?
>>
>> I thought we're setting for host here. Do you mean we need to see the
>> card capability?
>
> Yes. SDHCI_TRNS_AUTO_SEL selects auto-CMD23 or auto-CMD12 based on this
> setting, so this must reflect the card's capability.
Got it, but how to know if the card supports CMD23?
>>>
>>> At the moment the only way of knowing is if a request is received with
>>> mrq->sbc
>>>
>
>>
>>>
+ ctrl2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ ctrl2 |= SDHCI_CMD23_ENABLE;
+ sdhci_writew(host, ctrl2, SDHCI_HOST_CONTROL2);
+ }
+}
+
static void sdhci_init(struct sdhci_host *host, int soft)
{
struct mmc_host *mmc = host->mmc;
@@ -329,6 +346,8 @@ static void sdhci_init(struct sdhci_host *host,
int soft)
host->clock = 0;
mmc->ops->set_ios(mmc, &mmc->ios);
}
+
+ sdhci_enable_cmd23(host);
}
static void sdhci_reinit(struct sdhci_host *host)
@@ -1093,6 +1112,36 @@ static inline bool sdhci_auto_cmd12(struct
sdhci_host *host,
!mrq->cap_cmd_during_tfr;
}
+static inline void sdhci_auto_cmd_select(struct sdhci_host *host,
+ struct mmc_command *cmd,
+ u16 *mode)
+{
+ bool use_cmd12 = sdhci_auto_cmd12(host, cmd->mrq) &&
+ (cmd->opcode != SD_IO_RW_EXTENDED);
+ bool use_cmd23 = cmd->mrq->sbc && (host->flags &
SDHCI_AUTO_CMD23);
+
+ /*
+ * In case of Version 4.10 or later, use of 'Auto CMD Auto
+ * Select' is recommended rather than use of 'Auto CMD12
+ * Enable' or 'Auto CMD23 Enable'.
+ */
+ if (host->version >= SDHCI_SPEC_410 && (use_cmd12 || use_cmd23))
{
+ *mode |= SDHCI_TRNS_AUTO_SEL;
>>>
>>> As noted in patch 4, the CMD23 argument is not just the block count for
>>> eMMC.
>>
>> Probably I haven't got your point...
>>
>> >From what I understand, auto_sel mode doesn't need argument2. Doesn't
>> this work for eMMC?
>
> CMD23 always needs an argument
But setting argument for CMD23 will cover the block count value we set
before, that will lead mounting emmc to fail.
>>>
>>> Does it fail because it contains cmd->mrq->sbc->arg or does it fail because
>>> it gets written twice?
>>
>> Seems t
[PATCH 10/14] mmc: mmci: add dma_release callback
From: Ludovic Barre
This patch adds dma_release callback at mmci_host_ops
to allow to call specific variant.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 13 -
drivers/mmc/host/mmci.h | 2 ++
drivers/mmc/host/mmci_qcom_dml.c | 1 +
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index ae47d08..177e2e8 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -409,6 +409,12 @@ int mmci_dma_setup(struct mmci_host *host)
return host->ops->dma_setup(host);
}
+void mmci_dma_release(struct mmci_host *host)
+{
+ if (host->ops && host->ops->dma_release)
+ host->ops->dma_release(host);
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -546,7 +552,7 @@ int mmci_dmae_setup(struct mmci_host *host)
* This is used in or so inline it
* so it can be discarded.
*/
-static inline void mmci_dma_release(struct mmci_host *host)
+void mmci_dmae_release(struct mmci_host *host)
{
struct dmaengine_priv *dmae = host->dma_priv;
@@ -799,13 +805,10 @@ static struct mmci_host_ops mmci_variant_ops = {
.unprepare_data = mmci_dmae_unprepare_data,
.get_next_data = mmci_dmae_get_next_data,
.dma_setup = mmci_dmae_setup,
+ .dma_release = mmci_dmae_release,
};
#else
/* Blank functions if the DMA engine is not available */
-static inline void mmci_dma_release(struct mmci_host *host)
-{
-}
-
static inline void mmci_dma_finalize(struct mmci_host *host,
struct mmc_data *data)
{
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index e1b389c..f961f90 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -279,6 +279,7 @@ struct mmci_host_ops {
int err);
void (*get_next_data)(struct mmci_host *host, struct mmc_data *data);
int (*dma_setup)(struct mmci_host *host);
+ void (*dma_release)(struct mmci_host *host);
};
struct mmci_host {
@@ -336,3 +337,4 @@ void mmci_dmae_unprepare_data(struct mmci_host *host,
struct mmc_data *data, int err);
void mmci_dmae_get_next_data(struct mmci_host *host, struct mmc_data *data);
int mmci_dmae_setup(struct mmci_host *host);
+void mmci_dmae_release(struct mmci_host *host);
diff --git a/drivers/mmc/host/mmci_qcom_dml.c b/drivers/mmc/host/mmci_qcom_dml.c
index 47abbdd..3c9d32e 100644
--- a/drivers/mmc/host/mmci_qcom_dml.c
+++ b/drivers/mmc/host/mmci_qcom_dml.c
@@ -186,6 +186,7 @@ static struct mmci_host_ops qcom_variant_ops = {
.unprepare_data = mmci_dmae_unprepare_data,
.get_next_data = mmci_dmae_get_next_data,
.dma_setup = qcom_dma_setup,
+ .dma_release = mmci_dmae_release,
};
void qcom_variant_init(struct mmci_host *host)
--
2.7.4
[PATCH 04/14] mmc: mmci: introduce dma_priv pointer to mmci_host
From: Ludovic Barre
This patch introduces dma_priv pointer to define specific
needs for each dma engine. This patch is needed to prepare
sdmmc variant with internal dma which not use dmaengine API.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 165 +--
drivers/mmc/host/mmci.h | 20 +
drivers/mmc/host/mmci_qcom_dml.c | 6 +-
3 files changed, 112 insertions(+), 79 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 8144a87..bdc48c3 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -415,31 +415,57 @@ static void mmci_init_sg(struct mmci_host *host, struct
mmc_data *data)
* no custom DMA interfaces are supported.
*/
#ifdef CONFIG_DMA_ENGINE
-static void mmci_dma_setup(struct mmci_host *host)
+struct dmaengine_next {
+ struct dma_async_tx_descriptor *dma_desc;
+ struct dma_chan *dma_chan;
+ s32 cookie;
+};
+
+struct dmaengine_priv {
+ struct dma_chan *dma_current;
+ struct dma_chan *dma_rx_channel;
+ struct dma_chan *dma_tx_channel;
+ struct dma_async_tx_descriptor *dma_desc_current;
+ struct dmaengine_next next_data;
+ bool dma_in_progress;
+};
+
+#define __dmae_inprogress(dmae) ((dmae)->dma_in_progress)
+
+static int mmci_dma_setup(struct mmci_host *host)
{
const char *rxname, *txname;
+ struct dmaengine_priv *dmae;
- host->dma_rx_channel = dma_request_slave_channel(mmc_dev(host->mmc),
"rx");
- host->dma_tx_channel = dma_request_slave_channel(mmc_dev(host->mmc),
"tx");
+ dmae = devm_kzalloc(mmc_dev(host->mmc), sizeof(*dmae), GFP_KERNEL);
+ if (!dmae)
+ return -ENOMEM;
+
+ host->dma_priv = dmae;
+
+ dmae->dma_rx_channel = dma_request_slave_channel(mmc_dev(host->mmc),
+"rx");
+ dmae->dma_tx_channel = dma_request_slave_channel(mmc_dev(host->mmc),
+"tx");
/* initialize pre request cookie */
- host->next_data.cookie = 1;
+ dmae->next_data.cookie = 1;
/*
* If only an RX channel is specified, the driver will
* attempt to use it bidirectionally, however if it is
* is specified but cannot be located, DMA will be disabled.
*/
- if (host->dma_rx_channel && !host->dma_tx_channel)
- host->dma_tx_channel = host->dma_rx_channel;
+ if (dmae->dma_rx_channel && !dmae->dma_tx_channel)
+ dmae->dma_tx_channel = dmae->dma_rx_channel;
- if (host->dma_rx_channel)
- rxname = dma_chan_name(host->dma_rx_channel);
+ if (dmae->dma_rx_channel)
+ rxname = dma_chan_name(dmae->dma_rx_channel);
else
rxname = "none";
- if (host->dma_tx_channel)
- txname = dma_chan_name(host->dma_tx_channel);
+ if (dmae->dma_tx_channel)
+ txname = dma_chan_name(dmae->dma_tx_channel);
else
txname = "none";
@@ -450,15 +476,15 @@ static void mmci_dma_setup(struct mmci_host *host)
* Limit the maximum segment size in any SG entry according to
* the parameters of the DMA engine device.
*/
- if (host->dma_tx_channel) {
- struct device *dev = host->dma_tx_channel->device->dev;
+ if (dmae->dma_tx_channel) {
+ struct device *dev = dmae->dma_tx_channel->device->dev;
unsigned int max_seg_size = dma_get_max_seg_size(dev);
if (max_seg_size < host->mmc->max_seg_size)
host->mmc->max_seg_size = max_seg_size;
}
- if (host->dma_rx_channel) {
- struct device *dev = host->dma_rx_channel->device->dev;
+ if (dmae->dma_rx_channel) {
+ struct device *dev = dmae->dma_rx_channel->device->dev;
unsigned int max_seg_size = dma_get_max_seg_size(dev);
if (max_seg_size < host->mmc->max_seg_size)
@@ -466,7 +492,9 @@ static void mmci_dma_setup(struct mmci_host *host)
}
if (host->ops && host->ops->dma_setup)
- host->ops->dma_setup(host);
+ return host->ops->dma_setup(host);
+
+ return 0;
}
/*
@@ -475,21 +503,24 @@ static void mmci_dma_setup(struct mmci_host *host)
*/
static inline void mmci_dma_release(struct mmci_host *host)
{
- if (host->dma_rx_channel)
- dma_release_channel(host->dma_rx_channel);
- if (host->dma_tx_channel)
- dma_release_channel(host->dma_tx_channel);
- host->dma_rx_channel = host->dma_tx_channel = NULL;
+ struct dmaengine_priv *dmae = host->dma_priv;
+
+ if (dmae->dma_rx_channel)
+ dma_release_channel(dmae->dma_rx_channel);
+ if (dmae->dma_tx_channel)
+ dma_release_channel(dmae->dma_tx_channel);
+ dmae->dma_rx
[PATCH 12/14] mmc: mmci: add dma_finalize callback
From: Ludovic Barre
This patch adds dma_finalize callback at mmci_host_ops
to allow to call specific variant.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 14 --
drivers/mmc/host/mmci.h | 2 ++
drivers/mmc/host/mmci_qcom_dml.c | 1 +
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 642ef19..b124a73 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -447,6 +447,12 @@ int mmci_dma_start(struct mmci_host *host, unsigned int
datactrl)
return 0;
}
+void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
+{
+ if (host->ops && host->ops->dma_finalize)
+ host->ops->dma_finalize(host, data);
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -626,7 +632,7 @@ static void mmci_dma_data_error(struct mmci_host *host)
__mmci_dmae_unmap(host, host->data);
}
-static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
+void mmci_dmae_finalize(struct mmci_host *host, struct mmc_data *data)
{
struct dmaengine_priv *dmae = host->dma_priv;
u32 status;
@@ -820,14 +826,10 @@ static struct mmci_host_ops mmci_variant_ops = {
.dma_setup = mmci_dmae_setup,
.dma_release = mmci_dmae_release,
.dma_start = mmci_dmae_start,
+ .dma_finalize = mmci_dmae_finalize,
};
#else
/* Blank functions if the DMA engine is not available */
-static inline void mmci_dma_finalize(struct mmci_host *host,
-struct mmc_data *data)
-{
-}
-
static inline void mmci_dma_data_error(struct mmci_host *host)
{
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 3a200a9..3f482d5 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -281,6 +281,7 @@ struct mmci_host_ops {
int (*dma_setup)(struct mmci_host *host);
void (*dma_release)(struct mmci_host *host);
int (*dma_start)(struct mmci_host *host, unsigned int *datactrl);
+ void (*dma_finalize)(struct mmci_host *host, struct mmc_data *data);
};
struct mmci_host {
@@ -340,3 +341,4 @@ void mmci_dmae_get_next_data(struct mmci_host *host, struct
mmc_data *data);
int mmci_dmae_setup(struct mmci_host *host);
void mmci_dmae_release(struct mmci_host *host);
int mmci_dmae_start(struct mmci_host *host, unsigned int *datactrl);
+void mmci_dmae_finalize(struct mmci_host *host, struct mmc_data *data);
diff --git a/drivers/mmc/host/mmci_qcom_dml.c b/drivers/mmc/host/mmci_qcom_dml.c
index e6267ad..ba7e311 100644
--- a/drivers/mmc/host/mmci_qcom_dml.c
+++ b/drivers/mmc/host/mmci_qcom_dml.c
@@ -188,6 +188,7 @@ static struct mmci_host_ops qcom_variant_ops = {
.dma_setup = qcom_dma_setup,
.dma_release = mmci_dmae_release,
.dma_start = mmci_dmae_start,
+ .dma_finalize = mmci_dmae_finalize,
};
void qcom_variant_init(struct mmci_host *host)
--
2.7.4
[PATCH 07/14] mmc: mmci: add prepare/unprepare_data callbacks
From: Ludovic Barre
This patch adds prepare/unprepare callbacks to mmci_host_ops.
Like this mmci_pre/post_request can be generic, mmci_prepare_data
and mmci_unprepare_data provide common next_cookie management.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 118 +++
drivers/mmc/host/mmci.h | 10
drivers/mmc/host/mmci_qcom_dml.c | 2 +
3 files changed, 93 insertions(+), 37 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index e4d80f1..345aa2e 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -58,6 +58,7 @@ static struct variant_data variant_arm = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_ROD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_arm_extended_fifo = {
@@ -69,6 +70,7 @@ static struct variant_data variant_arm_extended_fifo = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_ROD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_arm_extended_fifo_hwfc = {
@@ -81,6 +83,7 @@ static struct variant_data variant_arm_extended_fifo_hwfc = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_ROD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_u300 = {
@@ -99,6 +102,7 @@ static struct variant_data variant_u300 = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_OD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_nomadik = {
@@ -118,6 +122,7 @@ static struct variant_data variant_nomadik = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_OD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_ux500 = {
@@ -143,6 +148,7 @@ static struct variant_data variant_ux500 = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_OD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_ux500v2 = {
@@ -170,6 +176,7 @@ static struct variant_data variant_ux500v2 = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_OD,
+ .init = mmci_variant_init,
};
static struct variant_data variant_stm32 = {
@@ -187,6 +194,7 @@ static struct variant_data variant_stm32 = {
.f_max = 4800,
.pwrreg_clkgate = true,
.pwrreg_nopower = true,
+ .init = mmci_variant_init,
};
static struct variant_data variant_qcom = {
@@ -357,6 +365,31 @@ static void mmci_set_clkreg(struct mmci_host *host,
unsigned int desired)
mmci_write_clkreg(host, clk);
}
+int mmci_prepare_data(struct mmci_host *host, struct mmc_data *data, bool next)
+{
+ int err;
+
+ if (!host->ops || !host->ops->prepare_data)
+ return 0;
+
+ err = host->ops->prepare_data(host, data, next);
+
+ if (next && !err)
+ data->host_cookie = ++host->next_cookie < 0 ?
+ 1 : host->next_cookie;
+
+ return err;
+}
+
+void mmci_unprepare_data(struct mmci_host *host, struct mmc_data *data,
+int err)
+{
+ if (host->ops && host->ops->unprepare_data)
+ host->ops->unprepare_data(host, data, err);
+
+ data->host_cookie = 0;
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -588,9 +621,9 @@ static void mmci_dma_finalize(struct mmci_host *host,
struct mmc_data *data)
}
/* prepares DMA channel and DMA descriptor, returns non-zero on failure */
-static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
- struct dma_chan **dma_chan,
- struct dma_async_tx_descriptor **dma_desc)
+static int __mmci_dmae_prep_data(struct mmci_host *host, struct mmc_data *data,
+struct dma_chan **dma_chan,
+struct dma_async_tx_descriptor **dma_desc)
{
struct dmaengine_priv *dmae = host->dma_priv;
struct variant_data *variant = host->variant;
@@ -651,22 +684,21 @@ static int __mmci_dma_prep_data(struct mmci_host *host,
struct mmc_data *data,
return -ENOMEM;
}
-static inline int mmci_dma_prepare_data(struct mmci_host *host,
- struct mmc_data *data,
-
[PATCH 09/14] mmc: mmci: modify dma_setup callback
From: Ludovic Barre
This patch creates a generic mmci_dma_setup which calls
dma_setup callback and manages common next_cookie.
This patch is needed for sdmmc variant which has a different
dma settings.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 25 +
drivers/mmc/host/mmci.h | 1 +
drivers/mmc/host/mmci_qcom_dml.c | 2 ++
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 0193da6..ae47d08 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -398,6 +398,17 @@ void mmci_get_next_data(struct mmci_host *host, struct
mmc_data *data)
host->ops->get_next_data(host, data);
}
+int mmci_dma_setup(struct mmci_host *host)
+{
+ if (!host->ops || !host->ops->dma_setup)
+ return 0;
+
+ /* initialize pre request cookie */
+ host->next_cookie = 1;
+
+ return host->ops->dma_setup(host);
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -472,7 +483,7 @@ struct dmaengine_priv {
#define __dmae_inprogress(dmae) ((dmae)->dma_in_progress)
-static int mmci_dma_setup(struct mmci_host *host)
+int mmci_dmae_setup(struct mmci_host *host)
{
const char *rxname, *txname;
struct dmaengine_priv *dmae;
@@ -488,9 +499,6 @@ static int mmci_dma_setup(struct mmci_host *host)
dmae->dma_tx_channel = dma_request_slave_channel(mmc_dev(host->mmc),
"tx");
- /* initialize pre request cookie */
- host->next_cookie = 1;
-
/*
* If only an RX channel is specified, the driver will
* attempt to use it bidirectionally, however if it is
@@ -531,9 +539,6 @@ static int mmci_dma_setup(struct mmci_host *host)
host->mmc->max_seg_size = max_seg_size;
}
- if (host->ops && host->ops->dma_setup)
- return host->ops->dma_setup(host);
-
return 0;
}
@@ -793,14 +798,10 @@ static struct mmci_host_ops mmci_variant_ops = {
.prepare_data = mmci_dmae_prepare_data,
.unprepare_data = mmci_dmae_unprepare_data,
.get_next_data = mmci_dmae_get_next_data,
+ .dma_setup = mmci_dmae_setup,
};
#else
/* Blank functions if the DMA engine is not available */
-static inline int mmci_dma_setup(struct mmci_host *host)
-{
- return 0;
-}
-
static inline void mmci_dma_release(struct mmci_host *host)
{
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index bb1e4ba..e1b389c 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -335,3 +335,4 @@ int mmci_dmae_prepare_data(struct mmci_host *host, struct
mmc_data *data,
void mmci_dmae_unprepare_data(struct mmci_host *host,
struct mmc_data *data, int err);
void mmci_dmae_get_next_data(struct mmci_host *host, struct mmc_data *data);
+int mmci_dmae_setup(struct mmci_host *host);
diff --git a/drivers/mmc/host/mmci_qcom_dml.c b/drivers/mmc/host/mmci_qcom_dml.c
index e4c505a..47abbdd 100644
--- a/drivers/mmc/host/mmci_qcom_dml.c
+++ b/drivers/mmc/host/mmci_qcom_dml.c
@@ -126,6 +126,8 @@ static int qcom_dma_setup(struct mmci_host *host)
int consumer_id, producer_id;
struct device_node *np = host->mmc->parent->of_node;
+ mmci_dmae_setup(host);
+
consumer_id = of_get_dml_pipe_index(np, "tx");
producer_id = of_get_dml_pipe_index(np, "rx");
--
2.7.4
[PATCH 03/14] mmc: mmci: internalize dma_inprogress into mmci dma functions
From: Ludovic Barre
This patch internalizes the dma_inprogress into mmci dma interfaces.
This allows to simplify and prepare the next dma callbacks
for mmci host ops. __dma_inprogress is called in mmci_dma_data_error
and mmci_dma_finalize.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 16 ++--
drivers/mmc/host/mmci.h | 4 +---
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index d8fa178..8144a87 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -497,6 +497,9 @@ static void __mmci_dma_unmap(struct mmci_host *host, struct
mmc_data *data)
static void mmci_dma_data_error(struct mmci_host *host)
{
+ if (!__dma_inprogress(host))
+ return;
+
dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
dmaengine_terminate_all(host->dma_current);
host->dma_in_progress = false;
@@ -512,6 +515,9 @@ static void mmci_dma_finalize(struct mmci_host *host,
struct mmc_data *data)
u32 status;
int i;
+ if (!__dma_inprogress(dmae))
+ return;
+
/* Wait up to 1ms for the DMA to complete */
for (i = 0; ; i++) {
status = readl(host->base + MMCISTATUS);
@@ -903,8 +909,7 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
u32 remain, success;
/* Terminate the DMA transfer */
- if (dma_inprogress(host))
- mmci_dma_data_error(host);
+ mmci_dma_data_error(host);
/*
* Calculate how far we are into the transfer. Note that
@@ -942,8 +947,8 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
dev_err(mmc_dev(host->mmc), "stray MCI_DATABLOCKEND
interrupt\n");
if (status & MCI_DATAEND || data->error) {
- if (dma_inprogress(host))
- mmci_dma_finalize(host, data);
+ mmci_dma_finalize(host, data);
+
mmci_stop_data(host);
if (!data->error)
@@ -1050,8 +1055,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command
*cmd,
if ((!sbc && !cmd->data) || cmd->error) {
if (host->data) {
/* Terminate the DMA transfer */
- if (dma_inprogress(host))
- mmci_dma_data_error(host);
+ mmci_dma_data_error(host);
mmci_stop_data(host);
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 696a066..f1ec066 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -332,9 +332,7 @@ struct mmci_host {
struct mmci_host_next next_data;
booldma_in_progress;
-#define dma_inprogress(host) ((host)->dma_in_progress)
-#else
-#define dma_inprogress(host) (0)
+#define __dma_inprogress(host) ((host)->dma_in_progress)
#endif
};
--
2.7.4
[PATCH 06/14] mmc: mmci: merge prepare data functions
From: Ludovic Barre
This patch merges the prepare data functions.
This allows to define a single access to prepare data service.
This prepares integration for mmci host ops.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 5646c2e6..e4d80f1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -651,11 +651,16 @@ static int __mmci_dma_prep_data(struct mmci_host *host,
struct mmc_data *data,
return -ENOMEM;
}
-static inline int mmci_dma_prep_data(struct mmci_host *host,
-struct mmc_data *data)
+static inline int mmci_dma_prepare_data(struct mmci_host *host,
+ struct mmc_data *data,
+ bool next)
{
struct dmaengine_priv *dmae = host->dma_priv;
+ struct dmaengine_next *nd = &dmae->next_data;
+ if (next)
+ return __mmci_dma_prep_data(host, data, &nd->dma_chan,
+ &nd->dma_desc);
/* Check if next job is already prepared. */
if (dmae->dma_current && dmae->dma_desc_current)
return 0;
@@ -665,22 +670,13 @@ static inline int mmci_dma_prep_data(struct mmci_host
*host,
&dmae->dma_desc_current);
}
-static inline int mmci_dma_prep_next(struct mmci_host *host,
-struct mmc_data *data)
-{
- struct dmaengine_priv *dmae = host->dma_priv;
- struct dmaengine_next *nd = &dmae->next_data;
-
- return __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc);
-}
-
static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
{
struct dmaengine_priv *dmae = host->dma_priv;
struct mmc_data *data = host->data;
int ret;
- ret = mmci_dma_prep_data(host, host->data);
+ ret = mmci_dma_prepare_data(host, host->data, false);
if (ret)
return ret;
@@ -737,7 +733,7 @@ static void mmci_pre_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if (mmci_validate_data(host, data))
return;
- if (!mmci_dma_prep_next(host, data))
+ if (!mmci_dma_prepare_data(host, data, true))
data->host_cookie = ++host->next_cookie < 0 ?
1 : host->next_cookie;
}
--
2.7.4
[PATCH 02/14] mmc: mmci: internalize dma map/unmap into mmci dma functions
From: Ludovic Barre
This patch internalizes the management of dma map/unmap into
mmci dma interfaces. This allows to simplify and prepare the next dma
callbacks for mmci host ops.
mmci_dma_unmap was called in mmci_data_irq & mmci_cmd_irq functions
and can be integrated in mmci_dma_data_error.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 44 +++-
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 1841d250..d8fa178 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -482,17 +482,7 @@ static inline void mmci_dma_release(struct mmci_host *host)
host->dma_rx_channel = host->dma_tx_channel = NULL;
}
-static void mmci_dma_data_error(struct mmci_host *host)
-{
- dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
- dmaengine_terminate_all(host->dma_current);
- host->dma_in_progress = false;
- host->dma_current = NULL;
- host->dma_desc_current = NULL;
- host->data->host_cookie = 0;
-}
-
-static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
+static void __mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
{
struct dma_chan *chan;
@@ -505,6 +495,18 @@ static void mmci_dma_unmap(struct mmci_host *host, struct
mmc_data *data)
mmc_get_dma_dir(data));
}
+static void mmci_dma_data_error(struct mmci_host *host)
+{
+ dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
+ dmaengine_terminate_all(host->dma_current);
+ host->dma_in_progress = false;
+ host->dma_current = NULL;
+ host->dma_desc_current = NULL;
+ host->data->host_cookie = 0;
+
+ __mmci_dma_unmap(host, host->data);
+}
+
static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
{
u32 status;
@@ -528,11 +530,10 @@ static void mmci_dma_finalize(struct mmci_host *host,
struct mmc_data *data)
mmci_dma_data_error(host);
if (!data->error)
data->error = -EIO;
+ } else if (!data->host_cookie) {
+ __mmci_dma_unmap(host, data);
}
- if (!data->host_cookie)
- mmci_dma_unmap(host, data);
-
/*
* Use of DMA with scatter-gather is impossible.
* Give up with DMA and switch back to PIO mode.
@@ -704,7 +705,7 @@ static void mmci_post_request(struct mmc_host *mmc, struct
mmc_request *mrq,
if (!data || !data->host_cookie)
return;
- mmci_dma_unmap(host, data);
+ __mmci_dma_unmap(host, data);
if (err) {
struct mmci_host_next *next = &host->next_data;
@@ -742,10 +743,6 @@ static inline void mmci_dma_release(struct mmci_host *host)
{
}
-static inline void mmci_dma_unmap(struct mmci_host *host, struct mmc_data
*data)
-{
-}
-
static inline void mmci_dma_finalize(struct mmci_host *host,
struct mmc_data *data)
{
@@ -906,10 +903,8 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data
*data,
u32 remain, success;
/* Terminate the DMA transfer */
- if (dma_inprogress(host)) {
+ if (dma_inprogress(host))
mmci_dma_data_error(host);
- mmci_dma_unmap(host, data);
- }
/*
* Calculate how far we are into the transfer. Note that
@@ -1055,10 +1050,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command
*cmd,
if ((!sbc && !cmd->data) || cmd->error) {
if (host->data) {
/* Terminate the DMA transfer */
- if (dma_inprogress(host)) {
+ if (dma_inprogress(host))
mmci_dma_data_error(host);
- mmci_dma_unmap(host, host->data);
- }
+
mmci_stop_data(host);
}
mmci_request_end(host, host->mrq);
--
2.7.4
maybe resource leak in security/selinux/selinuxfs.c
advisory:
1 After creating dentry in d_alloc_name, should I call dput to release
resources before the exception exit?
2 After calling the new_inode to create an inode, should the inode resource be
released before the exception exit?
If the dentry and inode resources need to be actively released, there are
multiple resource leaks in security/selinux/selinuxfs.c.
Example:
Linux master branch v4.18-rc5
The function sel_make_avc_files in security/selinux/selinuxfs.c.
1566 static int sel_make_avc_files(struct dentry *dir)
...
1580 for (i = 0; i < ARRAY_SIZE(files); i++) {
1581 struct inode *inode;
1582 struct dentry *dentry;
1583
1584 dentry = d_alloc_name(dir, files[i].name);
1585 if (!dentry)
/*Resource leak: when i!=0, the release action of dentry and inode resources is
missing*/
1586 return -ENOMEM;
1587
1588 inode = sel_make_inode(dir->d_sb, S_IFREG|files[i].mode);
1589 if (!inode)
/*Resource leak: missing dput(dentry)*/
/*Resource leak: when i!=0, the release action of dentry and inode resources is
missing*/
1590 return -ENOMEM;
1591
1592 inode->i_fop = files[i].ops;
1593 inode->i_ino = ++fsi->last_ino;
1594 d_add(dentry, inode);
1595 }
1596
1597 return 0;
1598 }
There are similar resource leaking functions:
Sel_make_bools
Sel_make_avc_files
Sel_make_initcon_files
Sel_make_perm_files
Sel_make_class_dir_entries
Sel_make_policycap
Sel_fill_super
Sel_make_policy_nodes
Sel_make_classes
[PATCH 13/14] mmc: mmci: add dma_error callback
From: Ludovic Barre
This patch adds dma_error callback at mmci_host_ops
to allow to call specific variant.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 20 +++-
drivers/mmc/host/mmci.h | 2 ++
drivers/mmc/host/mmci_qcom_dml.c | 1 +
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index b124a73..d5ca93e 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -453,6 +453,12 @@ void mmci_dma_finalize(struct mmci_host *host, struct
mmc_data *data)
host->ops->dma_finalize(host, data);
}
+void mmci_dma_error(struct mmci_host *host)
+{
+ if (host->ops && host->ops->dma_error)
+ host->ops->dma_error(host);
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -615,7 +621,7 @@ static void __mmci_dmae_unmap(struct mmci_host *host,
struct mmc_data *data)
mmc_get_dma_dir(data));
}
-static void mmci_dma_data_error(struct mmci_host *host)
+void mmci_dmae_error(struct mmci_host *host)
{
struct dmaengine_priv *dmae = host->dma_priv;
@@ -656,7 +662,7 @@ void mmci_dmae_finalize(struct mmci_host *host, struct
mmc_data *data)
* contiguous buffers. On TX, we'll get a FIFO underrun error.
*/
if (status & MCI_RXDATAAVLBLMASK) {
- mmci_dma_data_error(host);
+ mmci_dma_error(host);
if (!data->error)
data->error = -EIO;
} else if (!data->host_cookie) {
@@ -827,13 +833,9 @@ static struct mmci_host_ops mmci_variant_ops = {
.dma_release = mmci_dmae_release,
.dma_start = mmci_dmae_start,
.dma_finalize = mmci_dmae_finalize,
+ .dma_error = mmci_dmae_error,
};
#else
-/* Blank functions if the DMA engine is not available */
-static inline void mmci_dma_data_error(struct mmci_host *host)
-{
-}
-
static struct mmci_host_ops mmci_variant_ops = {};
#endif
@@ -1011,7 +1013,7 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data
*data,
u32 remain, success;
/* Terminate the DMA transfer */
- mmci_dma_data_error(host);
+ mmci_dma_error(host);
/*
* Calculate how far we are into the transfer. Note that
@@ -1157,7 +1159,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command
*cmd,
if ((!sbc && !cmd->data) || cmd->error) {
if (host->data) {
/* Terminate the DMA transfer */
- mmci_dma_data_error(host);
+ mmci_dma_error(host);
mmci_stop_data(host);
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 3f482d5..0a4811d 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -282,6 +282,7 @@ struct mmci_host_ops {
void (*dma_release)(struct mmci_host *host);
int (*dma_start)(struct mmci_host *host, unsigned int *datactrl);
void (*dma_finalize)(struct mmci_host *host, struct mmc_data *data);
+ void (*dma_error)(struct mmci_host *host);
};
struct mmci_host {
@@ -342,3 +343,4 @@ int mmci_dmae_setup(struct mmci_host *host);
void mmci_dmae_release(struct mmci_host *host);
int mmci_dmae_start(struct mmci_host *host, unsigned int *datactrl);
void mmci_dmae_finalize(struct mmci_host *host, struct mmc_data *data);
+void mmci_dmae_error(struct mmci_host *host);
diff --git a/drivers/mmc/host/mmci_qcom_dml.c b/drivers/mmc/host/mmci_qcom_dml.c
index ba7e311..80701b4 100644
--- a/drivers/mmc/host/mmci_qcom_dml.c
+++ b/drivers/mmc/host/mmci_qcom_dml.c
@@ -189,6 +189,7 @@ static struct mmci_host_ops qcom_variant_ops = {
.dma_release = mmci_dmae_release,
.dma_start = mmci_dmae_start,
.dma_finalize = mmci_dmae_finalize,
+ .dma_error = mmci_dmae_error,
};
void qcom_variant_init(struct mmci_host *host)
--
2.7.4
[PATCH 11/14] mmc: mmci: add dma_start callback
From: Ludovic Barre
This patch adds dma_start callback to mmci_host_ops.
Create a generic mmci_dma_start function which regroup
common action between variant.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 63 +++-
drivers/mmc/host/mmci.h | 2 ++
drivers/mmc/host/mmci_qcom_dml.c | 1 +
3 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 177e2e8..642ef19 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -415,6 +415,38 @@ void mmci_dma_release(struct mmci_host *host)
host->ops->dma_release(host);
}
+int mmci_dma_start(struct mmci_host *host, unsigned int datactrl)
+{
+ struct mmc_data *data = host->data;
+ int ret;
+
+ ret = mmci_prepare_data(host, data, false);
+ if (ret)
+ return ret;
+
+ if (!host->ops || !host->ops->dma_start)
+ return -EINVAL;
+
+ /* Okay, go for it. */
+ dev_vdbg(mmc_dev(host->mmc),
+"Submit MMCI DMA job, sglen %d blksz %04x blks %04x flags
%08x\n",
+data->sg_len, data->blksz, data->blocks, data->flags);
+
+ host->ops->dma_start(host, &datactrl);
+
+ /* Trigger the DMA transfer */
+ mmci_write_datactrlreg(host, datactrl);
+
+ /*
+* Let the MMCI say when the data is ended and it's time
+* to fire next DMA request. When that happens, MMCI will
+* call mmci_data_end()
+*/
+ writel(readl(host->base + MMCIMASK0) | MCI_DATAENDMASK,
+ host->base + MMCIMASK0);
+ return 0;
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -721,20 +753,11 @@ int mmci_dmae_prepare_data(struct mmci_host *host,
&dmae->dma_desc_current);
}
-static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
+int mmci_dmae_start(struct mmci_host *host, unsigned int *datactrl)
{
struct dmaengine_priv *dmae = host->dma_priv;
struct mmc_data *data = host->data;
- int ret;
-
- ret = mmci_prepare_data(host, host->data, false);
- if (ret)
- return ret;
- /* Okay, go for it. */
- dev_vdbg(mmc_dev(host->mmc),
-"Submit MMCI DMA job, sglen %d blksz %04x blks %04x flags
%08x\n",
-data->sg_len, data->blksz, data->blocks, data->flags);
dmae->dma_in_progress = true;
dmaengine_submit(dmae->dma_desc_current);
dma_async_issue_pending(dmae->dma_current);
@@ -742,18 +765,8 @@ static int mmci_dma_start_data(struct mmci_host *host,
unsigned int datactrl)
if (host->variant->qcom_dml)
dml_start_xfer(host, data);
- datactrl |= MCI_DPSM_DMAENABLE;
-
- /* Trigger the DMA transfer */
- mmci_write_datactrlreg(host, datactrl);
+ *datactrl |= MCI_DPSM_DMAENABLE;
- /*
-* Let the MMCI say when the data is ended and it's time
-* to fire next DMA request. When that happens, MMCI will
-* call mmci_data_end()
-*/
- writel(readl(host->base + MMCIMASK0) | MCI_DATAENDMASK,
- host->base + MMCIMASK0);
return 0;
}
@@ -806,6 +819,7 @@ static struct mmci_host_ops mmci_variant_ops = {
.get_next_data = mmci_dmae_get_next_data,
.dma_setup = mmci_dmae_setup,
.dma_release = mmci_dmae_release,
+ .dma_start = mmci_dmae_start,
};
#else
/* Blank functions if the DMA engine is not available */
@@ -818,11 +832,6 @@ static inline void mmci_dma_data_error(struct mmci_host
*host)
{
}
-static inline int mmci_dma_start_data(struct mmci_host *host, unsigned int
datactrl)
-{
- return -ENOSYS;
-}
-
static struct mmci_host_ops mmci_variant_ops = {};
#endif
@@ -925,7 +934,7 @@ static void mmci_start_data(struct mmci_host *host, struct
mmc_data *data)
* Attempt to use DMA operation mode, if this
* should fail, fall back to PIO mode
*/
- if (!mmci_dma_start_data(host, datactrl))
+ if (!mmci_dma_start(host, datactrl))
return;
/* IRQ mode, map the SG list for CPU reading/writing */
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index f961f90..3a200a9 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -280,6 +280,7 @@ struct mmci_host_ops {
void (*get_next_data)(struct mmci_host *host, struct mmc_data *data);
int (*dma_setup)(struct mmci_host *host);
void (*dma_release)(struct mmci_host *host);
+ int (*dma_start)(struct mmci_host *host, unsigned int *datactrl);
};
struct mmci_host {
@@ -338,3 +339,4 @@ void mmci_dmae_unprepare_data(struct mmci_host *host,
void mmci_dmae_get_next_data(struct mmci_host *host, struct mmc_data *data);
int mmci_dmae_setup(struct mmci_host *host);
void mmci_dmae_release(struct mmci_host *host
[PATCH 14/14] mmc: mmci: add validate_data callback
From: Ludovic Barre
This patch adds validate_data callback at mmci_host_ops
to check specific constraints of variant.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 39 +--
drivers/mmc/host/mmci.h | 1 +
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index d5ca93e..7ba2f61 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -234,24 +234,6 @@ static int mmci_card_busy(struct mmc_host *mmc)
return busy;
}
-/*
- * Validate mmc prerequisites
- */
-static int mmci_validate_data(struct mmci_host *host,
- struct mmc_data *data)
-{
- if (!data)
- return 0;
-
- if (!is_power_of_2(data->blksz)) {
- dev_err(mmc_dev(host->mmc),
- "unsupported block size (%d bytes)\n", data->blksz);
- return -EINVAL;
- }
-
- return 0;
-}
-
static void mmci_reg_delay(struct mmci_host *host)
{
/*
@@ -365,6 +347,27 @@ static void mmci_set_clkreg(struct mmci_host *host,
unsigned int desired)
mmci_write_clkreg(host, clk);
}
+/*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ if (!is_power_of_2(data->blksz)) {
+ dev_err(mmc_dev(host->mmc),
+ "unsupported block size (%d bytes)\n", data->blksz);
+ return -EINVAL;
+ }
+
+ if (host->ops && host->ops->validate_data)
+ return host->ops->validate_data(host, data);
+
+ return 0;
+}
+
int mmci_prepare_data(struct mmci_host *host, struct mmc_data *data, bool next)
{
int err;
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 0a4811d..10b71bf 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -273,6 +273,7 @@ struct variant_data {
/* mmci variant callbacks */
struct mmci_host_ops {
+ int (*validate_data)(struct mmci_host *host, struct mmc_data *data);
int (*prepare_data)(struct mmci_host *host, struct mmc_data *data,
bool next);
void (*unprepare_data)(struct mmci_host *host, struct mmc_data *data,
--
2.7.4
[PATCH 08/14] mmc: mmci: add get_next_data callback
From: Ludovic Barre
This patch adds get_next_data callback to mmci_host_ops.
Generic mmci_get_next_data factorizes next_cookie check and
the host ops call.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 16 ++--
drivers/mmc/host/mmci.h | 2 ++
drivers/mmc/host/mmci_qcom_dml.c | 1 +
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 345aa2e..0193da6 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -390,6 +390,14 @@ void mmci_unprepare_data(struct mmci_host *host, struct
mmc_data *data,
data->host_cookie = 0;
}
+void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
+{
+ WARN_ON(data->host_cookie && data->host_cookie != host->next_cookie);
+
+ if (host->ops && host->ops->get_next_data)
+ host->ops->get_next_data(host, data);
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
@@ -738,12 +746,11 @@ static int mmci_dma_start_data(struct mmci_host *host,
unsigned int datactrl)
return 0;
}
-static void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
+void mmci_dmae_get_next_data(struct mmci_host *host, struct mmc_data *data)
{
struct dmaengine_priv *dmae = host->dma_priv;
struct dmaengine_next *next = &dmae->next_data;
- WARN_ON(data->host_cookie && data->host_cookie != host->next_cookie);
WARN_ON(!data->host_cookie && (next->dma_desc || next->dma_chan));
dmae->dma_desc_current = next->dma_desc;
@@ -785,13 +792,10 @@ void mmci_dmae_unprepare_data(struct mmci_host *host,
static struct mmci_host_ops mmci_variant_ops = {
.prepare_data = mmci_dmae_prepare_data,
.unprepare_data = mmci_dmae_unprepare_data,
+ .get_next_data = mmci_dmae_get_next_data,
};
#else
/* Blank functions if the DMA engine is not available */
-static void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
-{
-}
-
static inline int mmci_dma_setup(struct mmci_host *host)
{
return 0;
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index fa2702b..bb1e4ba 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -277,6 +277,7 @@ struct mmci_host_ops {
bool next);
void (*unprepare_data)(struct mmci_host *host, struct mmc_data *data,
int err);
+ void (*get_next_data)(struct mmci_host *host, struct mmc_data *data);
int (*dma_setup)(struct mmci_host *host);
};
@@ -333,3 +334,4 @@ int mmci_dmae_prepare_data(struct mmci_host *host, struct
mmc_data *data,
bool next);
void mmci_dmae_unprepare_data(struct mmci_host *host,
struct mmc_data *data, int err);
+void mmci_dmae_get_next_data(struct mmci_host *host, struct mmc_data *data);
diff --git a/drivers/mmc/host/mmci_qcom_dml.c b/drivers/mmc/host/mmci_qcom_dml.c
index d534fa1..e4c505a 100644
--- a/drivers/mmc/host/mmci_qcom_dml.c
+++ b/drivers/mmc/host/mmci_qcom_dml.c
@@ -182,6 +182,7 @@ static int qcom_dma_setup(struct mmci_host *host)
static struct mmci_host_ops qcom_variant_ops = {
.prepare_data = mmci_dmae_prepare_data,
.unprepare_data = mmci_dmae_unprepare_data,
+ .get_next_data = mmci_dmae_get_next_data,
.dma_setup = qcom_dma_setup,
};
--
2.7.4
[PATCH 01/14] mmc: mmci: fix qcom dma issue during mmci init with new dma_setup callback
From: Ludovic Barre
This patch fixes qcom dma issue during mmci init.
Like init callback of qcom variant is not set, the qcom dma
is not correctly initialized and fail while dma transfer
("buggy DMA detected. Taking evasive action").
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 1 +
drivers/mmc/host/mmci.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 71e9336..1841d250 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -208,6 +208,7 @@ static struct variant_data variant_qcom = {
.mmcimask1 = true,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_ROD,
+ .init = qcom_variant_init,
};
/* Busy detection for the ST Micro variant */
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 517591d..696a066 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -338,3 +338,4 @@ struct mmci_host {
#endif
};
+void qcom_variant_init(struct mmci_host *host);
--
2.7.4
[PATCH 00/14] mmc: mmci: prepare dma callbacks with mmci_host_ops
From: Ludovic Barre This patch series prepares and adds callbacks for dma transfert at mmci_host_ops. This series is composed of 3 parts: -Internalize specific needs of legacy dmaengine. -Create and setup dma_priv pointer -Create generic callbacks which share some features (like cookie...) and call specific needs This patch series must be applied on top of "mmc: mmci: Add and implement a ->dma_setup() callback for qcom dml" Ludovic Barre (14): mmc: mmci: fix qcom dma issue during mmci init with new dma_setup callback mmc: mmci: internalize dma map/unmap into mmci dma functions mmc: mmci: internalize dma_inprogress into mmci dma functions mmc: mmci: introduce dma_priv pointer to mmci_host mmc: mmci: move mmci next cookie to mci host mmc: mmci: merge prepare data functions mmc: mmci: add prepare/unprepare_data callbacks mmc: mmci: add get_next_data callback mmc: mmci: modify dma_setup callback mmc: mmci: add dma_release callback mmc: mmci: add dma_start callback mmc: mmci: add dma_finalize callback mmc: mmci: add dma_error callback mmc: mmci: add validate_data callback drivers/mmc/host/mmci.c | 458 --- drivers/mmc/host/mmci.h | 45 ++-- drivers/mmc/host/mmci_qcom_dml.c | 15 +- 3 files changed, 322 insertions(+), 196 deletions(-) -- 2.7.4
[PATCH 05/14] mmc: mmci: move mmci next cookie to mci host
From: Ludovic Barre
This patch moves next cookie to mmci host structure to
share same cookie management between all variants.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 10 --
drivers/mmc/host/mmci.h | 2 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index bdc48c3..5646c2e6 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -418,7 +418,6 @@ static void mmci_init_sg(struct mmci_host *host, struct
mmc_data *data)
struct dmaengine_next {
struct dma_async_tx_descriptor *dma_desc;
struct dma_chan *dma_chan;
- s32 cookie;
};
struct dmaengine_priv {
@@ -449,7 +448,7 @@ static int mmci_dma_setup(struct mmci_host *host)
"tx");
/* initialize pre request cookie */
- dmae->next_data.cookie = 1;
+ host->next_cookie = 1;
/*
* If only an RX channel is specified, the driver will
@@ -716,7 +715,7 @@ static void mmci_get_next_data(struct mmci_host *host,
struct mmc_data *data)
struct dmaengine_priv *dmae = host->dma_priv;
struct dmaengine_next *next = &dmae->next_data;
- WARN_ON(data->host_cookie && data->host_cookie != next->cookie);
+ WARN_ON(data->host_cookie && data->host_cookie != host->next_cookie);
WARN_ON(!data->host_cookie && (next->dma_desc || next->dma_chan));
dmae->dma_desc_current = next->dma_desc;
@@ -728,9 +727,7 @@ static void mmci_get_next_data(struct mmci_host *host,
struct mmc_data *data)
static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct mmci_host *host = mmc_priv(mmc);
- struct dmaengine_priv *dmae = host->dma_priv;
struct mmc_data *data = mrq->data;
- struct dmaengine_next *nd = &dmae->next_data;
if (!data)
return;
@@ -741,7 +738,8 @@ static void mmci_pre_request(struct mmc_host *mmc, struct
mmc_request *mrq)
return;
if (!mmci_dma_prep_next(host, data))
- data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
+ data->host_cookie = ++host->next_cookie < 0 ?
+ 1 : host->next_cookie;
}
static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 260a1de..d2ec4fd 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -318,6 +318,8 @@ struct mmci_host {
int (*get_rx_fifocnt)(struct mmci_host *h, u32 status, int remain);
void*dma_priv;
+
+ s32 next_cookie;
};
void qcom_variant_init(struct mmci_host *host);
--
2.7.4
Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
On Wed, Aug 1, 2018 at 11:23 AM, Quentin Perret wrote: > On Wednesday 01 Aug 2018 at 10:35:32 (+0200), Rafael J. Wysocki wrote: >> On Wed, Aug 1, 2018 at 10:23 AM, Quentin Perret >> wrote: >> > On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote: >> >> On Tue, Jul 31, 2018 at 9:31 PM, wrote: >> >> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org >> >> >> wrote: >> >> >>> If it's going to be a different aggregation from what's done for >> >> >>> frequency >> >> >>> guidance, I don't see the point of having this inside schedutil. Why >> >> >>> not >> >> >>> keep it inside the scheduler files? >> >> >> >> >> >> This code basically results from a discussion we had with Peter on v4. >> >> >> Keeping everything centralized can make sense from a maintenance >> >> >> perspective, I think. That makes it easy to see the impact of any >> >> >> change >> >> >> to utilization signals for both EAS and schedutil. >> >> > >> >> > In that case, I'd argue it makes more sense to keep the code >> >> > centralized in >> >> > the scheduler. The scheduler can let schedutil know about the >> >> > utilization >> >> > after it aggregates them. There's no need for a cpufreq governor to know >> >> > that there are scheduling classes or how many there are. And the >> >> > scheduler >> >> > can then choose to aggregate one way for task packing and another way >> >> > for >> >> > frequency guidance. >> >> >> >> Also the aggregate utilization may be used by cpuidle governors in >> >> principle to decide how deep they can go with idle state selection. >> > >> > The only issue I see with this right now is that some of the things done >> > in this function are policy decisions which really belong to the governor, >> > I think. >> >> Well, the scheduler makes policy decisions too, in quite a few places. :-) > > That is true ... ;-) But not so much about frequency selection yet I guess > >> The really important consideration here is whether or not there may be >> multiple governors making different policy decisions in that respect. >> If not, then where exactly the single policy decision is made doesn't >> particularly matter IMO. > > I think some users of the aggregated utilization signal do want to make > slightly different decisions (I'm thinking about the RT-go-to-max thing > again which makes perfect sense in sugov, but could possibly hurt EAS). Fair enough. > So the "hard" part of this work is to figure out what really is a > governor-specific policy decision, and what is common between all users. > I put "hard" between quotes because I only see the case of RT as truly > sugov-specific for now. OK > If we also want a special case for DL, Peter's enum should work OK, and > enable to add more special cases for new users (cpuidle ?) if needed. > But maybe that is something for later ? I agree. That can be done later if need be.
Re: [PATCH] mmc: mxcmmc: Fix missing parentheses and brace
On 31 July 2018 at 22:27, Kees Cook wrote:
> On Mon, Jul 16, 2018 at 3:11 AM, Ulf Hansson wrote:
>> On 12 July 2018 at 21:59, Kees Cook wrote:
>>> Looks like the adjusted syntax wasn't fully build tested. This fixes
>>> failures with powerpc builds:
>>>
>>> drivers/mmc/host/mxcmmc.c: In function ‘mxcmci_swap_buffers’:
>>> drivers/mmc/host/mxcmmc.c:296:51: error: expected ‘)’ before ‘;’ token
>>>void *buf = kmap_atomic(sg_page(sg) + sg->offset;
>>>^
>>> drivers/mmc/host/mxcmmc.c:299:1: error: expected ‘,’ or ‘;’ before ‘}’ token
>>> }
>>> ^
>>>
>>> Fixes: b189e7589f6d3 ("mmc: mxcmmc: handle highmem pages")
>>> Signed-off-by: Kees Cook
>>
>> Thanks, applied for fixes!
>
> I just checked again, and while I see this in linux-next, I would
> expect this to be in 4.18, since this fixes a 4.18-introduced build
> failure for some PPC configurations. Can this please be included in
> 4.18?
Yes it will, I was just about to create a PR for it.
However, I have deliberately slowed down the pace of sending fixes to
Linus, because of trying to achieve a somewhat better test coverage.
If you want to test the latest 4.18 rcs with pending fixes, we have
the pending-fixes branch in Stephen's next tree.
[...]
Kind regards
Uffe
[PATCH] staging: mt29f_spinand: fix memory leak while programming pages
In spinand_program_page(), it uses devm_kzalloc() to allocate memory to wbuf dynamically if internal ECC is on, but it doesn't free memory allocated to wbuf at the end of this function. This leads to a memory leak issue when internal ECC is on. Signed-off-by: Jheng-Jhong Wu --- drivers/staging/mt29f_spinand/mt29f_spinand.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c index e389009..cf51ca8 100644 --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c @@ -553,6 +553,8 @@ static int spinand_program_page(struct spi_device *spi_nand, } enable_hw_ecc = 0; } + + devm_kfree(&spi_nand->dev, wbuf); #endif return 0; -- 2.7.4
[PATCH 3/5] meson: pinctrl-gxbb: add support for TEST_N pin
The Amlogic Meson GXBB SoCs needs a Secure Monitor call to set the TEST_N
direction, add a special bank to support this pin.
Signed-off-by: Neil Armstrong
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index 2c97a2e0..c0954be 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -15,6 +15,7 @@
#include
#include "pinctrl-meson.h"
#include "pinctrl-meson8-pmx.h"
+#include
static const struct pinctrl_pin_desc meson_gxbb_periphs_pins[] = {
MESON_PIN(GPIOZ_0),
@@ -823,6 +824,9 @@ static struct meson_bank meson_gxbb_periphs_banks[] = {
static struct meson_bank meson_gxbb_aobus_banks[] = {
/* namefirst last irqpullen pulldir out
in */
BANK("AO", GPIOAO_0, GPIOAO_13, 0, 13, 0, 0, 0, 16, 0, 0, 0,
16, 1, 0),
+ /* This PIN Direction must be set using a SMC call, so dir reg offset
is the sm call */
+ BANK_SMC("TEST", GPIO_TEST_N, GPIO_TEST_N,
+-1, -1, 0, 30, 0, 14, SM_TEST_N_DIR,
1, 0, 31, 1, 31),
};
static struct meson_pinctrl_data meson_gxbb_periphs_pinctrl_data = {
--
2.7.4
