Re: [PATCH] [RFC] dmaengine: add fifo_size member
On 07/06/2019 06:50, Peter Ujfalusi wrote: > Jon, > > On 06/06/2019 15.37, Jon Hunter wrote: >>> Looking at the drivers/dma/tegra210-adma.c for the >>> TEGRA*_FIFO_CTRL_DEFAULT definition it is still not clear where the >>> remote FIFO size would fit. >>> There are fields for overflow and starvation(?) thresholds and TX/RX >>> size (assuming word length, 3 == 32bits?). >> >> The TX/RX size are the FIFO size. So 3 equates to a FIFO size of 3 * 64 >> bytes. >> >>> Both threshold is set to one, so I assume currently ADMA is >>> pushing/pulling data word by word. >> >> That's different. That indicates thresholds when transfers start. >> >>> Not sure what the burst size is used for, my guess would be that it is >>> used on the memory (DDR) side for optimized, more efficient accesses? >> >> That is the actual burst size. >> >>> My guess is that the threshold values are the counter limits, if the DMA >>> request counter reaches it then ADMA would do a threshold limit worth of >>> push/pull to ADMAIF. >>> Or there is another register where the remote FIFO size can be written >>> and ADMA is counting back from there until it reaches the threshold (and >>> pushes/pulling again threshold amount of data) so it keeps the FIFO >>> filled with at least threshold amount of data? >>> >>> I think in both cases the threshold would be the maxburst. >>> >>> I suppose you have the patch for adma on how to use the fifo_size >>> parameter? That would help understand what you are trying to achieve better. >> >> Its quite simple, we would just use the FIFO size to set the fields >> TEGRAXXX_ADMA_CH_FIFO_CTRL_TXSIZE/RXSIZE in the >> TEGRAXXX_ADMA_CH_FIFO_CTRL register. That's all. > > Hrm, it is still not clear how all of these fits together. > > What happens if you configure ADMA side: > BURST = 10 > TX/RXSIZE = 100 (100 * 64 bytes?) /* FIFO_SIZE? */ > *THRES = 5 > > And if you change the *THRES to 10? > And if you change the TX/RXSIZE to 50 (50 * 64 bytes?) > And if you change the BURST to 5? > > In other words what is the relation between all of these? So the THRES values are only applicable when the FETCHING_POLICY (bit 31 of the CH_FIFO_CTRL) is set. The FETCHING_POLICY bit defines two modes; a threshold based transfer mode or a burst based transfer mode. The burst mode transfer data as and when there is room for a burst in the FIFO. We use the burst mode and so we really should not be setting the THRES fields as they are not applicable. Oh well something else to correct, but this is side issue. > There must be a rule and constraints around these and if we do really > need a new parameter for ADMA's FIFO_SIZE I'd like it to be defined in a > generic way so others could benefit without 'misusing' a fifo_size > parameter for similar, but not quite fifo_size information. Yes I see what you are saying. One option would be to define both a src/dst_maxburst and src/dst_minburst size. Then we could use max for the FIFO size and min for the actual burst size. Cheers Jon -- nvpublic
[GIT PULL] Power management fixes for v5.2-rc4
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-5.2-rc4 with top-most commit a964d23c94e8177c501fc9a37dcf1f0dd2750527 Merge branch 'pm-x86' on top of commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a Linux 5.2-rc3 to receive power management fixes for 5.2-rc4. These fix a crash during resume from hibernation introduced during the 4.19 cycle, cause the new Performance and Energy Bias Hint (EPB) code to be built only if CONFIG_PM is set and add a few missing kerneldoc comments. Specifics: - Fix a crash that occurs when a kernel with 'nosmt' in the command line is used to resume the system from hibernation (as the "restore" kernel), because memory mapping differences between the restore and image kernels cause SMT siblings to be woken up from idle states and subsequently they try to fetch instructions from incorrect memory locations (Jiri Kosina). - Cause the new Performance and Energy Bias Hint (EPB) code to be built only if CONFIG_PM is set, because that code is not really necessary otherwise (Rafael Wysocki). - Add kerneldoc comments to documents some helper functions related to system-wide suspend to avoid possible confusion regarding their purpose (Rafael Wysocki). Thanks! --- Jiri Kosina (1): x86/power: Fix 'nosmt' vs hibernation triple fault during resume Rafael J. Wysocki (2): x86: intel_epb: Do not build when CONFIG_PM is unset PM: sleep: Add kerneldoc comments to some functions --- arch/x86/kernel/cpu/Makefile| 5 - arch/x86/kernel/cpu/intel_epb.c | 22 +- arch/x86/power/cpu.c| 10 ++ arch/x86/power/hibernate.c | 33 + include/linux/cpu.h | 4 include/linux/suspend.h | 31 +++ kernel/cpu.c| 4 ++-- kernel/power/hibernate.c| 9 + kernel/power/suspend.c | 6 ++ 9 files changed, 100 insertions(+), 24 deletions(-)
Re: [PATCH v2 4/7] cpufreq: add driver for Raspbery Pi
Hi Viresh, Am 07.06.19 um 05:09 schrieb Viresh Kumar: > On 06-06-19, 11:23, Stephen Boyd wrote: >> Yes, thanks. I see that largely follows the commit description so it >> looks OK to me. > Do you want to provide your Reviewed/Acked-by tag before I apply it ? Nicolas wanted to send a V3 of this series and as a platform maintainer i need some time for testing this version. Stefan
[PATCH V3 1/2] arm64/mm: Consolidate page fault information capture
This consolidates page fault information capture and move them bit earlier.
While here it also adds an wrapper is_write_abort(). It also saves some
cycles by replacing multiple user_mode() calls into a single one earlier
during the fault.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James Morse
Cc: Andrey Konovalov
---
arch/arm64/mm/fault.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7c1c8f4..95cac4a 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -435,6 +435,15 @@ static bool is_el0_instruction_abort(unsigned int esr)
return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_LOW;
}
+/*
+ * Note: not valid for EL1 DC IVAC, but we never use that such that it
+ * should fault. EL0 cannot issue DC IVAC (undef).
+ */
+static bool is_write_abort(unsigned int esr)
+{
+ return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM);
+}
+
static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
@@ -443,6 +452,9 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
vm_fault_t fault, major = 0;
unsigned long vm_flags = VM_READ | VM_WRITE;
unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+ bool is_user = user_mode(regs);
+ bool is_el0_exec = is_el0_instruction_abort(esr);
+ bool is_write = is_write_abort(esr);
if (notify_page_fault(regs, esr))
return 0;
@@ -454,13 +466,13 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
if (faulthandler_disabled() || !mm)
goto no_context;
- if (user_mode(regs))
+ if (is_user)
mm_flags |= FAULT_FLAG_USER;
- if (is_el0_instruction_abort(esr)) {
+ if (is_el0_exec) {
vm_flags = VM_EXEC;
mm_flags |= FAULT_FLAG_INSTRUCTION;
- } else if ((esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM)) {
+ } else if (is_write) {
vm_flags = VM_WRITE;
mm_flags |= FAULT_FLAG_WRITE;
}
@@ -488,7 +500,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
* we can bug out early if this is from code which shouldn't.
*/
if (!down_read_trylock(&mm->mmap_sem)) {
- if (!user_mode(regs) && !search_exception_tables(regs->pc))
+ if (!is_user && !search_exception_tables(regs->pc))
goto no_context;
retry:
down_read(&mm->mmap_sem);
@@ -499,7 +511,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
*/
might_sleep();
#ifdef CONFIG_DEBUG_VM
- if (!user_mode(regs) && !search_exception_tables(regs->pc)) {
+ if (!is_user && !search_exception_tables(regs->pc)) {
up_read(&mm->mmap_sem);
goto no_context;
}
@@ -517,7 +529,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
* in __lock_page_or_retry in mm/filemap.c.
*/
if (fatal_signal_pending(current)) {
- if (!user_mode(regs))
+ if (!is_user)
goto no_context;
return 0;
}
@@ -562,7 +574,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
* If we are in kernel mode at this point, we have no context to
* handle this fault with.
*/
- if (!user_mode(regs))
+ if (!is_user)
goto no_context;
if (fault & VM_FAULT_OOM) {
--
2.7.4
[PATCH V3 2/2] arm64/mm: Refactor __do_page_fault()
__do_page_fault() is over complicated with multiple goto statements. This
cleans up the code flow and while there drops local variable vm_fault_t.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James Morse
Cc: Andrey Konovalov
Cc: Christoph Hellwig
---
arch/arm64/mm/fault.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 95cac4a..235b7c0 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -397,37 +397,29 @@ static void do_bad_area(unsigned long addr, unsigned int
esr, struct pt_regs *re
static vm_fault_t __do_page_fault(struct mm_struct *mm, unsigned long addr,
unsigned int mm_flags, unsigned long vm_flags)
{
- struct vm_area_struct *vma;
- vm_fault_t fault;
+ struct vm_area_struct *vma = find_vma(mm, addr);
- vma = find_vma(mm, addr);
- fault = VM_FAULT_BADMAP;
if (unlikely(!vma))
- goto out;
- if (unlikely(vma->vm_start > addr))
- goto check_stack;
+ return VM_FAULT_BADMAP;
/*
* Ok, we have a good vm_area for this memory access, so we can handle
* it.
*/
-good_area:
+ if (unlikely(vma->vm_start > addr)) {
+ if (!(vma->vm_flags & VM_GROWSDOWN))
+ return VM_FAULT_BADMAP;
+ if (expand_stack(vma, addr))
+ return VM_FAULT_BADMAP;
+ }
+
/*
* Check that the permissions on the VMA allow for the fault which
* occurred.
*/
- if (!(vma->vm_flags & vm_flags)) {
- fault = VM_FAULT_BADACCESS;
- goto out;
- }
-
+ if (!(vma->vm_flags & vm_flags))
+ return VM_FAULT_BADACCESS;
return handle_mm_fault(vma, addr & PAGE_MASK, mm_flags);
-
-check_stack:
- if (vma->vm_flags & VM_GROWSDOWN && !expand_stack(vma, addr))
- goto good_area;
-out:
- return fault;
}
static bool is_el0_instruction_abort(unsigned int esr)
--
2.7.4
[PATCH V3 0/2] arm64/mm: Clean ups for do_page_fault()
This contains some clean ups for page fault handling in do_page_fault(). This has been boot tested on arm64 platform along with some stress tests but just build tested on others. Contains remaining two patches from v3 series after the first two patches were merged. This series applies on arm64 tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git (for-next/core) Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: James Morse Cc: Andrey Konovalov Cc: Christoph Hellwig Changes in V3: - Dropped first two patches which got queued up for 5.3 - Rebased on branch for-next/core on arm64 tree - s/is_el0_write_abort/is_write_abort/ with a comment per Mark and Catalin - s/is_el0_write/is_write following the above change - Updated commit message on [PATCH V3 2/2] per Catalin Changes in V2: (https://lkml.org/lkml/2019/6/3/79) - s/is_write_abort()/is_el0_write_abort() with a comment per Mark Rutland - s/is_write/is_el0_write/ & updated commit message as required - s/argument/local variable/ per Christoph Hellwig - Preserved VMA check order for VM_FAULT_BADMAP & VM_FAULT_BADACCESS per Mark - Preserved all existing __do_page_fault() in code comments per Mark - Dropped 'fixes' from the series's subject line per Will Deacon V1: https://lkml.org/lkml/2019/5/29/431 Anshuman Khandual (2): arm64/mm: Consolidate page fault information capture arm64/mm: Refactor __do_page_fault() arch/arm64/mm/fault.c | 56 +++ 1 file changed, 30 insertions(+), 26 deletions(-) -- 2.7.4
Re: [PATCH] clk: fix a missing-free bug in clk_cpy_name()
On 07. 06. 19, 3:52, Gen Zhang wrote:
> @@ -3491,6 +3492,8 @@ static int clk_core_populate_parent_map(struct
> clk_core *core)
> kfree_const(parents[i].name);
> kfree_const(parents[i].fw_name);
> } while (--i >= 0);
> + kfree_const(parent->name);
> + kfree_const(parent->fw_name);
Both of them were just freed in the loop above, no?
>>> for (i = 0, parent = parents; i < num_parents; i++, parent++)
>>> Is 'parent' the same as the one from the loop above?
>>
>> Yes. Did it change somehow?
> parent++?
parent++ is done after the loop body. Or what do you mean?
>>> Moreover, should 'parents[i].name' and 'parents[i].fw_name' be freed by
>>> kfree_const()?
>>>
>>
>> Yes? They're allocated with kstrdup_const() in clk_cpy_name(), or
>> they're NULL by virtue of the kcalloc and then kfree_const() does
>> nothing.
> I re-examined clk_cpy_name(). They are the second parameter of
> clk_cpy_name(). The first parameter is allocated, not the second one.
> So 'parent->name' and 'parent->fw_name' should be freed, not
> 'parents[i].name' or 'parents[i].fw_name'. Am I totally misunderstanding
> this clk_cpy_name()? :-(
The second parameter (the source) is parent_data[i].*, not parents[i].*
(the destination). parent->fw_name and parent->name are properly freed
in the do {} while loop as parents[i].name and parents[i].fw_name, given
i hasn't changed yet. I am not sure what you mean at all. Are you
uncertain about the C code flow?
thanks,
--
js
suse labs
[PATCH] ARM: davinci: da850-evm: call regulator_has_full_constraints()
From: Bartosz Golaszewski
The BB expander at 0x21 i2c bus 1 fails to probe on da850-evm because
the board doesn't set has_full_constraints to true in the regulator
API.
Call regulator_has_full_constraints() at the end of board registration
just like we do in da850-lcdk and da830-evm.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-da850-evm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 4ee65a8a3b80..31ae3be5741d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1480,6 +1480,8 @@ static __init void da850_evm_init(void)
if (ret)
pr_warn("%s: dsp/rproc registration failed: %d\n",
__func__, ret);
+
+ regulator_has_full_constraints();
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
2.21.0
RE: [PATCH] phy: renesas: rcar-gen3-usb2: fix imbalance powered flag
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, June 5, 2019 10:08 PM
> > > From: Geert Uytterhoeven, Sent: Wednesday, June 5, 2019 6:25 PM
> >
> > > Thank you, this seems to fix the warning, so
> > > Tested-by: Geert Uytterhoeven
> >
> > Thank you for the testing!
> >
> > > However, the other imbalance (phy-ee080200.usb-phy.6 enabling its
> > > regulator during each system resume phase, but never touching it
> > > otherwise) is still present.
> >
> > Umm, since I'd like to investigate this,
> > would you share your debug print patch?
>
> Attached.
Thank you for your patch. Finally, I found the other imbalance is caused by
rcar_gen3_phy_usb2_power_on(). rcar_gen3_phy_usb2_power_on() should have
own mutex lock to avoid a race condition between calls
rcar_gen3_are_all_rphys_power_off()
and assign the ->powered. So, I'll submit v2 patch later.
Notes:
- Even if the driver has such an own mutex, sometimes the different phy number
enables the regulator. But the imbalance enabling the regulator issue
disappears.
- One of the phy channel has 4 phy devices. And the phy channel has a regulator
so that enabling the regulator by one of the phy devices is enough.
--- Example (v5.2-rc3 on R-Car H3) ---
# ls /sys/class/phy/
phy-e65ee000.usb-phy.12 phy-ee0a0200.usb-phy.0 phy-ee0c0200.usb-phy.5
phy-ee080200.usb-phy.10 phy-ee0a0200.usb-phy.1 phy-ee0c0200.usb-phy.6
phy-ee080200.usb-phy.11 phy-ee0a0200.usb-phy.2 phy-ee0c0200.usb-phy.7
phy-ee080200.usb-phy.8 phy-ee0a0200.usb-phy.3
phy-ee080200.usb-phy.9 phy-ee0c0200.usb-phy.4
- phy-ee080200.usb-phy is one of the phy channel.
-- And the "phy-ee080200.usb-phy" phy channel has a regulator.
-- Other phy channels (phy-ee0[ac]0200.usb-phy) don't have their regulators.
- phy-ee080200.usb-phy.{8,9,10,11} are phy devices.
Best regards,
Yoshihiro Shimoda
[RFC PATCH 4/6] soundwire: stream: make stream name a const pointer
Make stream name const pointer
Signed-off-by: Srinivas Kandagatla
---
drivers/soundwire/stream.c| 2 +-
include/linux/soundwire/sdw.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
index b86992145799..8da1a8d2dac1 100644
--- a/drivers/soundwire/stream.c
+++ b/drivers/soundwire/stream.c
@@ -863,7 +863,7 @@ EXPORT_SYMBOL(sdw_release_stream);
* sdw_alloc_stream should be called only once per stream. Typically
* invoked from ALSA/ASoC machine/platform driver.
*/
-struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name)
+struct sdw_stream_runtime *sdw_alloc_stream(const char *stream_name)
{
struct sdw_stream_runtime *stream;
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index 80ca997e4e5d..457be7d09a4a 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -831,7 +831,7 @@ struct sdw_stream_params {
* @m_rt_count: Count of Master runtime(s) in this stream
*/
struct sdw_stream_runtime {
- char *name;
+ const char *name;
struct sdw_stream_params params;
enum sdw_stream_state state;
enum sdw_stream_type type;
@@ -839,7 +839,7 @@ struct sdw_stream_runtime {
int m_rt_count;
};
-struct sdw_stream_runtime *sdw_alloc_stream(char *stream_name);
+struct sdw_stream_runtime *sdw_alloc_stream(const char *stream_name);
void sdw_release_stream(struct sdw_stream_runtime *stream);
int sdw_stream_add_master(struct sdw_bus *bus,
struct sdw_stream_config *stream_config,
--
2.21.0
Re: [PATCH v2] kernel: module: Use struct_size() helper
+++ Gustavo A. R. Silva [06/06/19 13:18 -0500]:
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct module_sect_attrs {
...
struct module_sect_attr attrs[0];
};
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
So, replace the following form:
sizeof(*sect_attrs) + nloaded * sizeof(sect_attrs->attrs[0]
with:
struct_size(sect_attrs, attrs, nloaded)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Update changelog text by adding a better description for
the motivation and usage of the struct_size() helper.
Applied. Thanks a lot!
Jessica
[RFC PATCH 2/6] soundwire: Add compute_params callback
From: Vinod Koul
This callback allows masters to compute the bus parameters required.
Signed-off-by: Vinod Koul
Signed-off-by: Srinivas Kandagatla
---
drivers/soundwire/stream.c| 9 +
include/linux/soundwire/sdw.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
index 73c52cd4fec8..b86992145799 100644
--- a/drivers/soundwire/stream.c
+++ b/drivers/soundwire/stream.c
@@ -1485,6 +1485,15 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime
*stream)
bus->params.bandwidth += m_rt->stream->params.rate *
m_rt->ch_count * m_rt->stream->params.bps;
+ /* Compute params */
+ if (bus->compute_params) {
+ ret = bus->compute_params(bus);
+ if (ret < 0) {
+ dev_err(bus->dev, "Compute params failed: %d",
ret);
+ return ret;
+ }
+ }
+
/* Program params */
ret = sdw_program_params(bus);
if (ret < 0) {
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index bea46bd8b6ce..aac68e879fae 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -718,6 +718,7 @@ struct sdw_master_ops {
* Bit set implies used number, bit clear implies unused number.
* @bus_lock: bus lock
* @msg_lock: message lock
+ * @compute_params: points to Bus resource management implementation
* @ops: Master callback ops
* @port_ops: Master port callback ops
* @params: Current bus parameters
@@ -739,6 +740,7 @@ struct sdw_bus {
DECLARE_BITMAP(assigned, SDW_MAX_DEVICES);
struct mutex bus_lock;
struct mutex msg_lock;
+ int (*compute_params)(struct sdw_bus *bus);
const struct sdw_master_ops *ops;
const struct sdw_master_port_ops *port_ops;
struct sdw_bus_params params;
--
2.21.0
[RFC PATCH 0/6] soundwire: Add support to Qualcomm SoundWire master
Hi All, This patchset is very first version of Qualcomm SoundWire Master Controller found in most of Qualcomm SoCs and WCD audio codecs. This driver along with WCD934x codec and WSA881x Class-D Smart Speaker Amplifier drivers is on DragonBoard DB845c based of SDM845 SoC. WCD934x and WSA881x patches will be posted soon. SoundWire controller on SDM845 is integrated in WCD934x audio codec via SlimBus interface. Currently this driver is very minimal and only supports PDM. Most of the code in this driver is rework of Qualcomm downstream drivers used in Andriod. Credits to Banajit Goswami and Patrick Lai's Team. TODO: Test and add PCM support. Thanks, srini Srinivas Kandagatla (5): ASoC: core: add support to snd_soc_dai_get_sdw_stream() soundwire: core: define SDW_MAX_PORT soundwire: stream: make stream name a const pointer dt-bindings: soundwire: add bindings for Qcom controller soundwire: qcom: add support for SoundWire controller Vinod Koul (1): soundwire: Add compute_params callback .../bindings/soundwire/qcom,swr.txt | 62 ++ drivers/soundwire/Kconfig | 9 + drivers/soundwire/Makefile| 4 + drivers/soundwire/qcom.c | 983 ++ drivers/soundwire/stream.c| 11 +- include/linux/soundwire/sdw.h | 7 +- include/sound/soc-dai.h | 10 + 7 files changed, 1083 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,swr.txt create mode 100644 drivers/soundwire/qcom.c -- 2.21.0
[RFC PATCH 1/6] ASoC: core: add support to snd_soc_dai_get_sdw_stream()
On platforms which have smart speaker amplifiers connected via
soundwire and modeled as aux devices in ASoC, in such usecases machine
driver should be able to get sdw master stream from dai so that it can
use the runtime stream to setup slave streams.
soundwire already as a set function, get function would provide more
flexibility to above configurations.
Signed-off-by: Srinivas Kandagatla
---
include/sound/soc-dai.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index f5d70041108f..9f90b936fd9a 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -177,6 +177,7 @@ struct snd_soc_dai_ops {
int (*set_sdw_stream)(struct snd_soc_dai *dai,
void *stream, int direction);
+ void *(*get_sdw_stream)(struct snd_soc_dai *dai, int direction);
/*
* DAI digital mute - optional.
* Called by soc-core to minimise any pops.
@@ -385,4 +386,13 @@ static inline int snd_soc_dai_set_sdw_stream(struct
snd_soc_dai *dai,
return -ENOTSUPP;
}
+static inline void *snd_soc_dai_get_sdw_stream(struct snd_soc_dai *dai, int
direction)
+{
+ if (dai->driver->ops->get_sdw_stream)
+ return dai->driver->ops->get_sdw_stream(dai, direction);
+ else
+ return NULL;
+
+}
+
#endif
--
2.21.0
[RFC PATCH 5/6] dt-bindings: soundwire: add bindings for Qcom controller
This patch adds bindings for Qualcomm soundwire controller.
Qualcomm SoundWire Master controller is present in most Qualcomm SoCs
either integrated as part of WCD audio codecs via slimbus or
as part of SOC I/O.
Signed-off-by: Srinivas Kandagatla
---
.../bindings/soundwire/qcom,swr.txt | 62 +++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,swr.txt
diff --git a/Documentation/devicetree/bindings/soundwire/qcom,swr.txt
b/Documentation/devicetree/bindings/soundwire/qcom,swr.txt
new file mode 100644
index ..eb84d0f4f36f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soundwire/qcom,swr.txt
@@ -0,0 +1,62 @@
+Qualcomm SoundWire Controller
+
+This binding describes the Qualcomm SoundWire Controller Bindings.
+
+Required properties:
+
+- compatible: Must be "qcom,soundwire-v..",
+ example:
+ "qcom,soundwire-v1.3.0"
+ "qcom,soundwire-v1.5.0"
+ "qcom,soundwire-v1.6.0"
+- reg: SoundWire controller address space.
+- interrupts: SoundWire controller interrupt.
+- clock-names: Must contain "iface".
+- clocks: Interface clocks needed for controller.
+- #sound-dai-cells:Must be 1 for digital audio interfaces on the
controllers.
+- #address-cells: Must be 1 for SoundWire devices;
+- #size-cells: Must be <0> as SoundWire addresses have no size
component.
+- qcom,dout-ports: Must be count of data out ports
+- qcom,din-ports: Must be count of data in ports
+- qcom,ports-offset1: Must be frame offset1 of each data port.
+ Out followed by In. Used for Block size calculation.
+- qcom,ports-offset2: Must be frame offset2 of each data port.
+ Out followed by In. Used for Block size calculation.
+- qcom,ports-sinterval-low: Must be sample interval low of each data port.
+ Out followed by In. Used for Sample Interval
calculation.
+
+= SoundWire devices
+Each subnode of the bus represents SoundWire device attached to it.
+The properties of these nodes are defined by the individual bindings.
+
+= EXAMPLE
+The following example represents a SoundWire controller on DB845c board
+which has controller integrated inside WCD934x codec on SDM845 SoC.
+
+soundwire: soundwire@c85 {
+ compatible = "qcom,soundwire-v1.3.0";
+ reg = <0xc85 0x20>;
+ interrupts = <20 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&wcc>;
+ clock-names = "iface";
+ #sound-dai-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ qcom,dout-ports = <6>;
+ qcom,din-ports = <2>;
+ qcom,ports-sinterval-low =/bits/ 8 <0x07 0x1F 0x3F 0x7 0x1F 0x3F 0x0F
0x0F>;
+ qcom,ports-offset1 = /bits/ 8 <0x01 0x02 0x0C 0x6 0x12 0x0D 0x07 0x0A >;
+ qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x1F 0x00 0x00 0x1F 0x00 0x00>;
+
+ /* Left Speaker */
+ wsa8810@1{
+
+ reg = <1>;
+ };
+
+ /* Right Speaker */
+ wsa8810@2{
+
+ reg = <2>;
+ };
+};
--
2.21.0
[RFC PATCH 3/6] soundwire: core: define SDW_MAX_PORT
This patch adds SDW_MAX_PORT so that other driver can use it. Signed-off-by: Srinivas Kandagatla --- include/linux/soundwire/sdw.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index aac68e879fae..80ca997e4e5d 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -36,6 +36,7 @@ struct sdw_slave; #define SDW_FRAME_CTRL_BITS48 #define SDW_MAX_DEVICES11 +#define SDW_MAX_PORTS 14 #define SDW_VALID_PORT_RANGE(n)((n) <= 14 && (n) >= 1) #define SDW_DAI_ID_RANGE_START 100 -- 2.21.0
[RFC PATCH 6/6] soundwire: qcom: add support for SoundWire controller
Qualcomm SoundWire Master controller is present in most Qualcomm SoCs either integrated as part of WCD audio codecs via slimbus or as part of SOC I/O. This patchset adds support to a very basic controller which has been tested with WCD934x SoundWire controller connected to WSA881x smart speaker amplifiers. Signed-off-by: Srinivas Kandagatla --- drivers/soundwire/Kconfig | 9 + drivers/soundwire/Makefile | 4 + drivers/soundwire/qcom.c | 983 + 3 files changed, 996 insertions(+) create mode 100644 drivers/soundwire/qcom.c diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig index 53b55b79c4af..f44d4f36dbbb 100644 --- a/drivers/soundwire/Kconfig +++ b/drivers/soundwire/Kconfig @@ -34,4 +34,13 @@ config SOUNDWIRE_INTEL enable this config option to get the SoundWire support for that device. +config SOUNDWIRE_QCOM + tristate "Qualcomm SoundWire Master driver" + select SOUNDWIRE_BUS + depends on SND_SOC + help + SoundWire Qualcomm Master driver. + If you have an Qualcomm platform which has a SoundWire Master then + enable this config option to get the SoundWire support for that + device endif diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile index 5817beaca0e1..f4ebfde31372 100644 --- a/drivers/soundwire/Makefile +++ b/drivers/soundwire/Makefile @@ -16,3 +16,7 @@ obj-$(CONFIG_SOUNDWIRE_INTEL) += soundwire-intel.o soundwire-intel-init-objs := intel_init.o obj-$(CONFIG_SOUNDWIRE_INTEL) += soundwire-intel-init.o + +#Qualcomm driver +soundwire-qcom-objs := qcom.o +obj-$(CONFIG_SOUNDWIRE_QCOM) += soundwire-qcom.o diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c new file mode 100644 index ..d1722d44d217 --- /dev/null +++ b/drivers/soundwire/qcom.c @@ -0,0 +1,983 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2019, Linaro Limited + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "bus.h" + +#define SWRM_COMP_HW_VERSION 0x00 +#define SWRM_COMP_CFG_ADDR 0x04 +#define SWRM_COMP_CFG_IRQ_LEVEL_OR_PULSE_MSK BIT(1) +#define SWRM_COMP_CFG_ENABLE_MSK BIT(0) +#define SWRM_COMP_PARAMS 0x100 +#define SWRM_COMP_PARAMS_DOUT_PORTS_MASK GENMASK(4, 0) +#define SWRM_COMP_PARAMS_DIN_PORTS_MASK GENMASK(9, 5) +#define SWRM_COMP_PARAMS_WR_FIFO_DEPTH GENMASK(14, 10) +#define SWRM_COMP_PARAMS_RD_FIFO_DEPTH GENMASK(19, 15) +#define SWRM_COMP_PARAMS_AUTO_ENUM_SLAVES GENMASK(32. 20) +#define SWRM_INTERRUPT_STATUS 0x200 +#define SWRM_INTERRUPT_STATUS_RMSK GENMASK(16, 0) +#define SWRM_INTERRUPT_STATUS_SLAVE_PEND_IRQ BIT(0) +#define SWRM_INTERRUPT_STATUS_NEW_SLAVE_ATTACHED BIT(1) +#define SWRM_INTERRUPT_STATUS_CHANGE_ENUM_SLAVE_STATUS BIT(2) +#define SWRM_INTERRUPT_STATUS_MASTER_CLASH_DET BIT(3) +#define SWRM_INTERRUPT_STATUS_RD_FIFO_OVERFLOW BIT(4) +#define SWRM_INTERRUPT_STATUS_RD_FIFO_UNDERFLOWBIT(5) +#define SWRM_INTERRUPT_STATUS_WR_CMD_FIFO_OVERFLOW BIT(6) +#define SWRM_INTERRUPT_STATUS_CMD_ERRORBIT(7) +#define SWRM_INTERRUPT_STATUS_DOUT_PORT_COLLISION BIT(8) +#define SWRM_INTERRUPT_STATUS_READ_EN_RD_VALID_MISMATCHBIT(9) +#define SWRM_INTERRUPT_STATUS_SPECIAL_CMD_ID_FINISHED BIT(10) +#define SWRM_INTERRUPT_STATUS_NEW_SLAVE_AUTO_ENUM_FINISHED BIT(11) +#define SWRM_INTERRUPT_STATUS_AUTO_ENUM_FAILED BIT(12) +#define SWRM_INTERRUPT_STATUS_AUTO_ENUM_TABLE_IS_FULL BIT(13) +#define SWRM_INTERRUPT_STATUS_BUS_RESET_FINISHED BIT(14) +#define SWRM_INTERRUPT_STATUS_CLK_STOP_FINISHEDBIT(15) +#define SWRM_INTERRUPT_STATUS_ERROR_PORT_TEST BIT(16) +#define SWRM_INTERRUPT_MASK_ADDR 0x204 +#define SWRM_INTERRUPT_CLEAR 0x208 +#define SWRM_CMD_FIFO_WR_CMD 0x300 +#define SWRM_CMD_FIFO_RD_CMD 0x304 +#define SWRM_CMD_FIFO_CMD 0x308 +#define SWRM_CMD_FIFO_STATUS 0x30C +#define SWRM_CMD_FIFO_CFG_ADDR 0x314 +#define SWRM_CMD_FIFO_CFG_NUM_OF_CMD_RETRY_SHFT0x0 +#define SWRM_CMD_FIFO_RD_FIFO_ADDR 0x318 +#define SWRM_ENUMERATOR_CFG_ADDR 0x500 +#def
Re: [PATCH v9 10/12] mm/devm_memremap_pages: Enable sub-section remap
On Wed, Jun 05, 2019 at 02:58:53PM -0700, Dan Williams wrote:
> Teach devm_memremap_pages() about the new sub-section capabilities of
> arch_{add,remove}_memory(). Effectively, just replace all usage of
> align_start, align_end, and align_size with res->start, res->end, and
> resource_size(res). The existing sanity check will still make sure that
> the two separate remap attempts do not collide within a sub-section (2MB
> on x86).
>
> Cc: Michal Hocko
> Cc: Toshi Kani
> Cc: Jérôme Glisse
> Cc: Logan Gunthorpe
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Signed-off-by: Dan Williams
Looks good to me:
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
Re: [PATCH 12/15] x86/static_call: Add out-of-line static call implementation
On Fri, Jun 07, 2019 at 10:38:46AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 07, 2019 at 06:13:58AM +, Nadav Amit wrote:
> > > On Jun 5, 2019, at 6:08 AM, Peter Zijlstra wrote:
>
> > > +void arch_static_call_transform(void *site, void *tramp, void *func)
> > > +{
> > > + unsigned char opcodes[CALL_INSN_SIZE];
> > > + unsigned char insn_opcode;
> > > + unsigned long insn;
> > > + s32 dest_relative;
> > > +
> > > + mutex_lock(&text_mutex);
> > > +
> > > + insn = (unsigned long)tramp;
> > > +
> > > + insn_opcode = *(unsigned char *)insn;
> > > + if (insn_opcode != 0xE9) {
> > > + WARN_ONCE(1, "unexpected static call insn opcode 0x%x at %pS",
> > > + insn_opcode, (void *)insn);
> > > + goto unlock;
> >
> > This might happen if a kprobe is installed on the call, no?
> >
> > I don’t know if you want to be more gentle handling of this case (or perhaps
> > modify can_probe() to prevent such a case).
> >
>
> yuck.. yes, that's something that needs consideration.
For jump_label this is avoided by jump_label_text_reserved(), I'm
thinking static_call should do the same.
Re: [PATCH 10/15] static_call: Add basic static call infrastructure
On Fri, 7 Jun 2019 at 10:29, Peter Zijlstra wrote:
>
> On Thu, Jun 06, 2019 at 10:44:23PM +, Nadav Amit wrote:
> > > + * Usage example:
> > > + *
> > > + * # Start with the following functions (with identical prototypes):
> > > + * int func_a(int arg1, int arg2);
> > > + * int func_b(int arg1, int arg2);
> > > + *
> > > + * # Define a 'my_key' reference, associated with func_a() by default
> > > + * DEFINE_STATIC_CALL(my_key, func_a);
> > > + *
> > > + * # Call func_a()
> > > + * static_call(my_key, arg1, arg2);
> > > + *
> > > + * # Update 'my_key' to point to func_b()
> > > + * static_call_update(my_key, func_b);
> > > + *
> > > + * # Call func_b()
> > > + * static_call(my_key, arg1, arg2);
> >
> > I think that this calling interface is not very intuitive.
>
> Yeah, it is somewhat unfortunate..
>
Another thing I brought up at the time is that it would be useful to
have the ability to 'reset' a static call to its default target. E.g.,
for crypto modules that implement an accelerated version of a library
interface, removing the module should revert those call sites back to
the original target, without putting a disproportionate burden on the
module itself to implement the logic to support this.
> > I understand that
> > the macros/objtool cannot allow the calling interface to be completely
> > transparent (as compiler plugin could). But, can the macros be used to
> > paste the key with the “static_call”? I think that having something like:
> >
> > static_call__func(arg1, arg2)
> >
> > Is more readable than
> >
> > static_call(func, arg1, arg2)
>
> Doesn't really make it much better for me; I think I'd prefer to switch
> to the GCC plugin scheme over this. ISTR there being some propotypes
> there, but I couldn't quickly locate them.
>
I implemented the GCC plugin here
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=static-calls
but IIRC, all it does is annotate call sites exactly how objtool does it.
> > > +}
> > > +
> > > +#define static_call_update(key, func)
> > > \
> > > +({ \
> > > + BUILD_BUG_ON(!__same_type(func, STATIC_CALL_TRAMP(key))); \
> > > + __static_call_update(&key, func); \
> > > +})
> >
> > Is this safe against concurrent module removal?
>
> It is for CONFIG_MODULE=n :-)
Re: [PATCH] Documentation: coresight: Update the generic device names
Hi Leo,
A Coresight PMU works the same way as any other PMU, i.e the name of the PMU
is
listed along with configuration options within forward slashes '/'. Since a
Coresight system will typically have more than one sink, the name of the
sink to
-work with needs to be specified as an event option. Names for sink to choose
-from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
+work with needs to be specified as an event option.
+On newer kernels the available sinks are listed in sysFS under:
+($SYSFS)/bus/event_source/devices/cs_etm/sinks/
- root@linaro-nano:~# ls /sys/bus/coresight/devices/
- 2001.etf 2004.funnel 2010.stm 2204.etm
- 2214.etm 230c.funnel 2324.etm 2003.tpiu
- 2007.etr 2012.replicator 220c.funnel
- 2304.etm 2314.etm 2334.etm
+ root@localhost:/sys/bus/event_source/devices/cs_etm/sinks# ls
+ tmc_etf0 tmc_etr0 tpiu0
- root@linaro-nano:~# perf record -e cs_etm/@2007.etr/u --per-thread
program
+On older kernels, this may need to be found from the list of coresight devices,
+available under ($SYSFS)/bus/coresight/devices/:
+
+ root@localhost:/sys/bus/coresight/devices# ls
+ etm0 etm1 etm2 etm3 etm4 etm5 funnel0 funnel1 funnel2
replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
+
+ root@linaro-nano:~# perf record -e cs_etm/@tmc_etr0/u --per-thread
program
On the "older" kernels you are referring to one would find the original naming
convention. Everything else looks good to me.
True, but do we care what we see there ? All we care about is the location,
where to find them. I could fix it, if you think thats needed.
IIUC, either the old kernel or newer kernel, both we can find the event
from ($SYSFS)/bus/event_source/devices/cs_etm/sinks/; the only
difference between them is the naming convention.
The cs_etm/sinks was only added with the CPU-wide trace support. So, if someone
refers to this document alone and then tries to do something on on older kernel,
which is quite possible for a production device running a stable kernel, {s,}he
might be surprised.
So the doc can use the same location to find event for both new and
old kernel, and explain the naming convention difference?
My question is really, does the naming convention matter ? What you see
under the directory is the name. But yes, I am open to add a section to
explain the fact that we changed the naming scheme, if everyone agrees
to it.
Cheers
Suzuki
Re: linux-next boot error: WARNING: workqueue cpumask: online intersect > possible intersect
On Fri, Jun 7, 2019 at 10:33 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:ae3cad8f Add linux-next specific files for 20190603 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=164f802ea0 > kernel config: https://syzkaller.appspot.com/x/.config?x=7ccec0766d83706f > dashboard link: https://syzkaller.appspot.com/bug?extid=4d497898effeb1936245 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+4d497898effeb1936...@syzkaller.appspotmail.com > > smpboot: CPU0: Intel(R) Xeon(R) CPU @ 2.30GHz (family: 0x6, model: 0x3f, > stepping: 0x0) > Performance Events: unsupported p6 CPU model 63 no PMU driver, software > events only. > rcu: Hierarchical SRCU implementation. > NMI watchdog: Perf NMI watchdog permanently disabled > smp: Bringing up secondary CPUs ... > x86: Booting SMP configuration: > node #0, CPUs: #1 > MDS CPU bug present and SMT on, data leak possible. See > https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for > more details. > smp: Brought up 2 nodes, 2 CPUs > smpboot: Max logical packages: 1 > smpboot: Total of 2 processors activated (9200.00 BogoMIPS) > devtmpfs: initialized > clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: > 1911260446275 ns > futex hash table entries: 512 (order: 4, 65536 bytes) > xor: automatically using best checksumming function avx > PM: RTC time: 07:02:18, date: 2019-06-03 > NET: Registered protocol family 16 > audit: initializing netlink subsys (disabled) > cpuidle: using governor menu > ACPI: bus type PCI registered > dca service started, version 1.12.1 > PCI: Using configuration type 1 for base access > WARNING: workqueue cpumask: online intersect > possible intersect +workqueue maintainers and Michael who added this WARNING The WARNING was added in 2017, so I guess it's a change somewhere else that triggered it. The WARNING message does not seem to give enough info about the caller (should it be changed to WARN_ONCE to print a stack?). How can be root cause this and unbreak linux-next? > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/f19676058ab7adc4%40google.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH v4] selinux: lsm: fix a missing-check bug in selinux_sb_eat_lsm_o pts()
On Thu, Jun 6, 2019 at 10:55 AM Gen Zhang wrote:
> In selinux_sb_eat_lsm_opts(), 'arg' is allocated by kmemdup_nul(). It
> returns NULL when fails. So 'arg' should be checked. And 'mnt_opts'
> should be freed when error.
>
> Signed-off-by: Gen Zhang
> Fixes: 99dbbb593fe6 ("selinux: rewrite selinux_sb_eat_lsm_opts()")
My comments about the subject and an empty line before label apply
here as well, but Paul can fix both easily when applying, so:
Reviewed-by: Ondrej Mosnacek
> ---
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3ec702c..13479cd 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2616,10 +2616,11 @@ static int selinux_sb_eat_lsm_opts(char *options,
> void **mnt_opts)
> char *from = options;
> char *to = options;
> bool first = true;
> + int rc;
>
> while (1) {
> int len = opt_len(from);
> - int token, rc;
> + int token;
> char *arg = NULL;
>
> token = match_opt_prefix(from, len, &arg);
> @@ -2635,15 +2636,15 @@ static int selinux_sb_eat_lsm_opts(char *options,
> void **mnt_opts)
> *q++ = c;
> }
> arg = kmemdup_nul(arg, q - arg, GFP_KERNEL);
> + if (!arg) {
> + rc = -ENOMEM;
> + goto free_opt;
> + }
> }
> rc = selinux_add_opt(token, arg, mnt_opts);
> if (unlikely(rc)) {
> kfree(arg);
> - if (*mnt_opts) {
> - selinux_free_mnt_opts(*mnt_opts);
> - *mnt_opts = NULL;
> - }
> - return rc;
> + goto free_opt;
> }
> } else {
> if (!first) { // copy with preceding comma
> @@ -2661,6 +2662,12 @@ static int selinux_sb_eat_lsm_opts(char *options, void
> **mnt_opts)
> }
> *to = '\0';
> return 0;
> +free_opt:
> + if (*mnt_opts) {
> + selinux_free_mnt_opts(*mnt_opts);
> + *mnt_opts = NULL;
> + }
> + return rc;
> }
>
> static int selinux_sb_remount(struct super_block *sb, void *mnt_opts)
--
Ondrej Mosnacek
Software Engineer, Security Technologies
Red Hat, Inc.
Re: [PATCH 12/15] x86/static_call: Add out-of-line static call implementation
On Fri, Jun 07, 2019 at 06:13:58AM +, Nadav Amit wrote:
> > On Jun 5, 2019, at 6:08 AM, Peter Zijlstra wrote:
> > +void arch_static_call_transform(void *site, void *tramp, void *func)
> > +{
> > + unsigned char opcodes[CALL_INSN_SIZE];
> > + unsigned char insn_opcode;
> > + unsigned long insn;
> > + s32 dest_relative;
> > +
> > + mutex_lock(&text_mutex);
> > +
> > + insn = (unsigned long)tramp;
> > +
> > + insn_opcode = *(unsigned char *)insn;
> > + if (insn_opcode != 0xE9) {
> > + WARN_ONCE(1, "unexpected static call insn opcode 0x%x at %pS",
> > + insn_opcode, (void *)insn);
> > + goto unlock;
>
> This might happen if a kprobe is installed on the call, no?
>
> I don’t know if you want to be more gentle handling of this case (or perhaps
> modify can_probe() to prevent such a case).
>
yuck.. yes, that's something that needs consideration.
Re: [PATCH v3] selinux: lsm: fix a missing-check bug in selinux_add_mnt_opt( )
On Thu, Jun 6, 2019 at 11:23 AM Gen Zhang wrote:
> In selinux_add_mnt_opt(), 'val' is allocated by kmemdup_nul(). It returns
> NULL when fails. So 'val' should be checked. And 'mnt_opts' should be
> freed when error.
>
> Signed-off-by: Gen Zhang
> Fixes: 757cbe597fe8 ("LSM: new method: ->sb_add_mnt_opt()")
> ---
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3ec702c..4e4c1c6 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1052,15 +1052,23 @@ static int selinux_add_mnt_opt(const char *option,
> const char *val, int len,
> if (token == Opt_error)
> return -EINVAL;
>
> - if (token != Opt_seclabel)
> - val = kmemdup_nul(val, len, GFP_KERNEL);
> + if (token != Opt_seclabel) {
> + val = kmemdup_nul(val, len, GFP_KERNEL);
> + if (!val) {
> + rc = -ENOMEM;
> + goto free_opt;
> + }
> + }
> rc = selinux_add_opt(token, val, mnt_opts);
> if (unlikely(rc)) {
> kfree(val);
> - if (*mnt_opts) {
> - selinux_free_mnt_opts(*mnt_opts);
> - *mnt_opts = NULL;
> - }
> + goto free_opt;
> + }
> + return rc;
At this point rc is guaranteed to be 0, so you can just 'return 0' for
clarity. Also, I visually prefer an empty line between a return
statement and a goto label, but I'm not sure what is the
general/maintainer's preference.
Also, you should drop the "lsm: " from the subject - it is redundant
and doesn't follow the SELinux convention. See `git log --oneline --
security/selinux/` for what the subjects usually look like - mostly we
just go with "selinux: " (or "LSM: " when
the changes affect the shared LSM interface).
> +free_opt:
> + if (*mnt_opts) {
> + selinux_free_mnt_opts(*mnt_opts);
> + *mnt_opts = NULL;
> }
> return rc;
> }
--
Ondrej Mosnacek
Software Engineer, Security Technologies
Red Hat, Inc.
Re: [PATCH 11/15] static_call: Add inline static call infrastructure
On Thu, Jun 06, 2019 at 10:24:17PM +, Nadav Amit wrote:
> > +static void static_call_del_module(struct module *mod)
> > +{
> > + struct static_call_site *start = mod->static_call_sites;
> > + struct static_call_site *stop = mod->static_call_sites +
> > + mod->num_static_call_sites;
> > + struct static_call_site *site;
> > + struct static_call_key *key, *prev_key = NULL;
> > + struct static_call_mod *site_mod;
> > +
> > + for (site = start; site < stop; site++) {
> > + key = static_call_key(site);
> > + if (key == prev_key)
> > + continue;
> > + prev_key = key;
> > +
> > + list_for_each_entry(site_mod, &key->site_mods, list) {
> > + if (site_mod->mod == mod) {
> > + list_del(&site_mod->list);
> > + kfree(site_mod);
> > + break;
> > + }
> > + }
> > + }
>
> I think that for safety, when a module is removed, all the static-calls
> should be traversed to check that none of them calls any function in the
> removed module. If that happens, perhaps it should be poisoned.
We don't do that for normal indirect calls either.. I suppose we could
here, but meh.
> > +}
> > +
> > +static int static_call_module_notify(struct notifier_block *nb,
> > +unsigned long val, void *data)
> > +{
> > + struct module *mod = data;
> > + int ret = 0;
> > +
> > + cpus_read_lock();
> > + static_call_lock();
> > +
> > + switch (val) {
> > + case MODULE_STATE_COMING:
> > + module_disable_ro(mod);
> > + ret = static_call_add_module(mod);
> > + module_enable_ro(mod, false);
>
> Doesn’t it cause some pages to be W+X ? Can it be avoided?
I don't know why it does this, jump_labels doesn't seem to need this,
and I'm not seeing what static_call needs differently.
> > + if (ret) {
> > + WARN(1, "Failed to allocate memory for static calls");
> > + static_call_del_module(mod);
>
> If static_call_add_module() succeeded in changing some of the calls, but not
> all, I don’t think that static_call_del_module() will correctly undo
> static_call_add_module(). The code transformations, I think, will remain.
Hurm, jump_labels has the same problem.
I wonder why kernel/module.c:prepare_coming_module() doesn't propagate
the error from the notifier call. If it were to do that, I think we'll
abort the module load and any modifications get lost anyway.
[PATCH] MAINTAINERS: media: Add Tomasz Figa as a videobuf2 reviewer
I tend to review most of the vb2 patches anyway and we need some active reviewers, so let add me to the MAINTAINERS file as such. Signed-off-by: Tomasz Figa --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 98cd84977350..b5f65f61becb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16758,6 +16758,7 @@ VIDEOBUF2 FRAMEWORK M: Pawel Osciak M: Marek Szyprowski M: Kyungmin Park +R: Tomasz Figa L: linux-me...@vger.kernel.org S: Maintained F: drivers/media/common/videobuf2/* -- 2.22.0.rc1.311.g5d7573a151-goog
Re: [PATCH v9 08/12] mm/sparsemem: Support sub-section hotplug
On Wed, Jun 05, 2019 at 02:58:42PM -0700, Dan Williams wrote:
> The libnvdimm sub-system has suffered a series of hacks and broken
> workarounds for the memory-hotplug implementation's awkward
> section-aligned (128MB) granularity. For example the following backtrace
> is emitted when attempting arch_add_memory() with physical address
> ranges that intersect 'System RAM' (RAM) with 'Persistent Memory' (PMEM)
> within a given section:
>
> WARNING: CPU: 0 PID: 558 at kernel/memremap.c:300
> devm_memremap_pages+0x3b5/0x4c0
> devm_memremap_pages attempted on mixed region [mem 0x2-0x2fbff
> flags 0x200]
> [..]
> Call Trace:
>dump_stack+0x86/0xc3
>__warn+0xcb/0xf0
>warn_slowpath_fmt+0x5f/0x80
>devm_memremap_pages+0x3b5/0x4c0
>__wrap_devm_memremap_pages+0x58/0x70 [nfit_test_iomap]
>pmem_attach_disk+0x19a/0x440 [nd_pmem]
>
> Recently it was discovered that the problem goes beyond RAM vs PMEM
> collisions as some platform produce PMEM vs PMEM collisions within a
> given section. The libnvdimm workaround for that case revealed that the
> libnvdimm section-alignment-padding implementation has been broken for a
> long while. A fix for that long-standing breakage introduces as many
> problems as it solves as it would require a backward-incompatible change
> to the namespace metadata interpretation. Instead of that dubious route
> [1], address the root problem in the memory-hotplug implementation.
>
> [1]:
> https://lore.kernel.org/r/155000671719.348031.2347363160141119237.st...@dwillia2-desk3.amr.corp.intel.com
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Logan Gunthorpe
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Signed-off-by: Dan Williams
> ---
> include/linux/memory_hotplug.h |2
> mm/memory_hotplug.c|7 -
> mm/page_alloc.c|2
> mm/sparse.c| 225
> +++-
> 4 files changed, 155 insertions(+), 81 deletions(-)
>
[...]
> @@ -325,6 +332,15 @@ static void __meminit sparse_init_one_section(struct
> mem_section *ms,
> unsigned long pnum, struct page *mem_map,
> struct mem_section_usage *usage)
> {
> + /*
> + * Given that SPARSEMEM_VMEMMAP=y supports sub-section hotplug,
> + * ->section_mem_map can not be guaranteed to point to a full
> + * section's worth of memory. The field is only valid / used
> + * in the SPARSEMEM_VMEMMAP=n case.
> + */
> + if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> + mem_map = NULL;
Will this be a problem when reading mem_map with the crash-tool?
I do not expect it to be, but I am not sure if crash internally tries
to read ms->section_mem_map and do some sort of translation.
And since ms->section_mem_map SECTION_HAS_MEM_MAP, it might be that it expects
a valid mem_map?
> +static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
> + struct vmem_altmap *altmap)
> +{
> + DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 };
> + DECLARE_BITMAP(tmp, SUBSECTIONS_PER_SECTION) = { 0 };
> + struct mem_section *ms = __pfn_to_section(pfn);
> + bool early_section = is_early_section(ms);
> + struct page *memmap = NULL;
> + unsigned long *subsection_map = ms->usage
> + ? &ms->usage->subsection_map[0] : NULL;
> +
> + subsection_mask_set(map, pfn, nr_pages);
> + if (subsection_map)
> + bitmap_and(tmp, map, subsection_map, SUBSECTIONS_PER_SECTION);
> +
> + if (WARN(!subsection_map || !bitmap_equal(tmp, map,
> SUBSECTIONS_PER_SECTION),
> + "section already deactivated (%#lx + %ld)\n",
> + pfn, nr_pages))
> + return;
> +
> + /*
> + * There are 3 cases to handle across two configurations
> + * (SPARSEMEM_VMEMMAP={y,n}):
> + *
> + * 1/ deactivation of a partial hot-added section (only possible
> + * in the SPARSEMEM_VMEMMAP=y case).
> + *a/ section was present at memory init
> + *b/ section was hot-added post memory init
> + * 2/ deactivation of a complete hot-added section
> + * 3/ deactivation of a complete section from memory init
> + *
> + * For 1/, when subsection_map does not empty we will not be
> + * freeing the usage map, but still need to free the vmemmap
> + * range.
> + *
> + * For 2/ and 3/ the SPARSEMEM_VMEMMAP={y,n} cases are unified
> + */
> + bitmap_xor(subsection_map, map, subsection_map,
> SUBSECTIONS_PER_SECTION);
> + if (bitmap_empty(subsection_map, SUBSECTIONS_PER_SECTION)) {
> + unsigned long section_nr = pfn_to_section_nr(pfn);
> +
> + if (!early_section) {
> + kfree(ms->usage);
> + ms->usage = NULL;
> + }
> + memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr);
> + ms->section_mem_map = sparse_encode_
linux-next boot error: WARNING: workqueue cpumask: online intersect > possible intersect
Hello, syzbot found the following crash on: HEAD commit:ae3cad8f Add linux-next specific files for 20190603 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=164f802ea0 kernel config: https://syzkaller.appspot.com/x/.config?x=7ccec0766d83706f dashboard link: https://syzkaller.appspot.com/bug?extid=4d497898effeb1936245 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+4d497898effeb1936...@syzkaller.appspotmail.com smpboot: CPU0: Intel(R) Xeon(R) CPU @ 2.30GHz (family: 0x6, model: 0x3f, stepping: 0x0) Performance Events: unsupported p6 CPU model 63 no PMU driver, software events only. rcu: Hierarchical SRCU implementation. NMI watchdog: Perf NMI watchdog permanently disabled smp: Bringing up secondary CPUs ... x86: Booting SMP configuration: node #0, CPUs: #1 MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. smp: Brought up 2 nodes, 2 CPUs smpboot: Max logical packages: 1 smpboot: Total of 2 processors activated (9200.00 BogoMIPS) devtmpfs: initialized clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns futex hash table entries: 512 (order: 4, 65536 bytes) xor: automatically using best checksumming function avx PM: RTC time: 07:02:18, date: 2019-06-03 NET: Registered protocol family 16 audit: initializing netlink subsys (disabled) cpuidle: using governor menu ACPI: bus type PCI registered dca service started, version 1.12.1 PCI: Using configuration type 1 for base access WARNING: workqueue cpumask: online intersect > possible intersect HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages cryptd: max_cpu_qlen set to 1000 raid6: avx2x4 gen() 11090 MB/s raid6: avx2x4 xor() 6383 MB/s raid6: avx2x2 gen() 5774 MB/s raid6: avx2x2 xor() 3935 MB/s raid6: avx2x1 gen() 863 MB/s raid6: avx2x1 xor() 2032 MB/s raid6: sse2x4 gen() 6156 MB/s raid6: sse2x4 xor() 3206 MB/s raid6: sse2x2 gen() 3796 MB/s raid6: sse2x2 xor() 1912 MB/s raid6: sse2x1 gen() 499 MB/s raid6: sse2x1 xor() 1075 MB/s raid6: using algorithm avx2x4 gen() 11090 MB/s raid6: xor() 6383 MB/s, rmw enabled raid6: using avx2x2 recovery algorithm ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Added _OSI(Linux-Dell-Video) ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) ACPI: 2 ACPI AML tables successfully acquired and loaded ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: Enabled 16 GPEs in block 00 to 0F ACPI: PCI Root Bridge [PCI0] (domain [bus 00-ff]) acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x-0x0cf7 window] pci_bus :00: root bus resource [io 0x0d00-0x window] pci_bus :00: root bus resource [mem 0x000a-0x000b window] pci_bus :00: root bus resource [mem 0xc000-0xfebf window] pci_bus :00: root bus resource [bus 00-ff] pci :00:00.0: [8086:1237] type 00 class 0x06 pci :00:01.0: [8086:7110] type 00 class 0x060100 pci :00:01.3: [8086:7113] type 00 class 0x068000 pci :00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI pci :00:03.0: [1af4:1004] type 00 class 0x00 pci :00:03.0: reg 0x10: [io 0xc000-0xc03f] pci :00:03.0: reg 0x14: [mem 0xfebfe000-0xfebfe07f] pci :00:04.0: [1af4:1000] type 00 class 0x02 pci :00:04.0: reg 0x10: [io 0xc040-0xc07f] pci :00:04.0: reg 0x14: [mem 0xfebff000-0xfebff07f] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) ACPI: PCI Interrupt Link [LNKS] (IRQs *9) vgaarb: loaded SCSI subsystem initialized ACPI: bus type USB registered usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb mc: Linux media interface: v0.10 videodev: Linux video capture interface: v2.00 pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered EDAC MC: Ver: 3.0.0 Advanced Linux Sound Architecture Driver Initialized. PCI: Using ACPI for IRQ routing Bluetooth: Core ver 2.22 NET
Re: [PATCH 2/2] Revert "mm, thp: restore node-local hugepage allocations"
On Thu 06-06-19 15:12:40, David Rientjes wrote: > On Wed, 5 Jun 2019, Michal Hocko wrote: > > > > That's fine, but we also must be mindful of users who have used > > > MADV_HUGEPAGE over the past four years based on its hard-coded behavior > > > that would now regress as a result. > > > > Absolutely, I am all for helping those usecases. First of all we need to > > understand what those usecases are though. So far we have only seen very > > vague claims about artificial worst case examples when a remote access > > dominates the overall cost but that doesn't seem to be the case in real > > life in my experience (e.g. numa balancing will correct things or the > > over aggressive node reclaim tends to cause problems elsewhere etc.). > > > > The usecase is a remap of a binary's text segment to transparent hugepages > by doing mmap() -> madvise(MADV_HUGEPAGE) -> mremap() and when this > happens on a locally fragmented node. This happens at startup when we > aren't concerned about allocation latency: we want to compact. We are > concerned with access latency thereafter as long as the process is > running. You have indicated this previously but no call for a stand alone reproducer was successful. It is really hard to optimize for such a specialized workload without anything to play with. Btw. this is exactly a case where I would expect numa balancing to converge to the optimal placement. And if numabalancing is not an option than an explicit mempolicy (e.g. the one suggested here) would be a good fit. [...] I will defer the compaction related stuff to Vlastimil and Mel who are much more familiar with the current code. > So my proposed change would be: > - give the page allocator a consistent indicator that compaction failed >because we are low on memory (make COMPACT_SKIPPED really mean this), > - if we get this in the page allocator and we are allocating thp, fail, >reclaim is unlikely to help here and is much more likely to be >disruptive > - we could retry compaction if we haven't scanned all memory and >were contended, > - if the hugepage allocation fails, have thp check watermarks for order-0 >pages without any padding, > - if watermarks succeed, fail the thp allocation: we can't allocate >because of fragmentation and it's better to return node local memory, Doesn't this lead to the same THP low success rate we have seen with one of the previous patches though? Let me remind you of the previous semantic I was proposing http://lkml.kernel.org/r/20181206091405.gd1...@dhcp22.suse.cz and that didn't get shot down. Linus had some follow up ideas on how exactly the fallback order should look like and that is fine. We should just measure differences between local node cheep base page vs. remote THP on _real_ workloads. Any microbenchmark which just measures a latency is inherently misleading. And really, fundamental problem here is that MADV_HUGEPAGE has gained a NUMA semantic without a due scrutiny leading to a broken interface with side effects that are simply making the interface unusable for a large part of usecases that the madvise was originaly designed for. Until we find an agreement on this point we will be looping in a dead end discussion, I am afraid. -- Michal Hocko SUSE Labs
[PATCH v2 6/8] usb: dwc3: qcom: Add support for booting with ACPI
In Linux, the DWC3 core exists as its own independent platform device.
Thus when describing relationships in Device Tree, the current default
boot configuration table option, the DWC3 core often resides as a child
of the platform specific node. Both of which are given their own
address space descriptions and the drivers can be mostly agnostic to
each other.
However, other Operating Systems have taken a more monolithic approach,
which is evident in the configuration ACPI tables for the Qualcomm
Snapdragon SDM850, where all DWC3 (core and platform) components are
described under a single IO memory region.
To ensure successful booting using the supplied ACPI tables, we need to
devise a way to chop up the address regions provided and subsequently
register the DWC3 core with the resultant information, which is
precisely what this patch aims to achieve.
Signed-off-by: Lee Jones
---
drivers/usb/dwc3/Kconfig | 2 +-
drivers/usb/dwc3/dwc3-qcom.c | 206 ++-
2 files changed, 179 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 2b1494460d0c..6dab3fd1e233 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -116,7 +116,7 @@ config USB_DWC3_ST
config USB_DWC3_QCOM
tristate "Qualcomm Platform"
depends on EXTCON && (ARCH_QCOM || COMPILE_TEST)
- depends on OF
+ depends on (OF || ACPI)
default USB_DWC3
help
Some Qualcomm SoCs use DesignWare Core IP for USB2/3
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 184df4daa590..1e1f12b7991d 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -4,6 +4,7 @@
* Inspired by dwc3-of-simple.c
*/
+#include
#include
#include
#include
@@ -38,6 +39,20 @@
#define PWR_EVNT_LPM_IN_L2_MASKBIT(4)
#define PWR_EVNT_LPM_OUT_L2_MASK BIT(5)
+#define SDM845_QSCRATCH_BASE_OFFSET0xf8800
+#define SDM845_QSCRATCH_SIZE 0x400
+#define SDM845_DWC3_CORE_SIZE 0xcd00
+
+struct dwc3_acpi_pdata {
+ u32 qscratch_base_offset;
+ u32 qscratch_base_size;
+ u32 dwc3_core_base_size;
+ int hs_phy_irq_index;
+ int dp_hs_phy_irq_index;
+ int dm_hs_phy_irq_index;
+ int ss_phy_irq_index;
+};
+
struct dwc3_qcom {
struct device *dev;
void __iomem*qscratch_base;
@@ -56,6 +71,8 @@ struct dwc3_qcom {
struct notifier_block vbus_nb;
struct notifier_block host_nb;
+ const struct dwc3_acpi_pdata *acpi_pdata;
+
enum usb_dr_modemode;
boolis_suspended;
boolpm_suspended;
@@ -300,12 +317,27 @@ static void dwc3_qcom_select_utmi_clk(struct dwc3_qcom
*qcom)
PIPE_UTMI_CLK_DIS);
}
+static int dwc3_qcom_get_irq(struct platform_device *pdev,
+const char *name, int num)
+{
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+
+ if (np)
+ ret = platform_get_irq_byname(pdev, name);
+ else
+ ret = platform_get_irq(pdev, num);
+
+ return ret;
+}
+
static int dwc3_qcom_setup_irq(struct platform_device *pdev)
{
struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
+ const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata;
int irq, ret;
-
- irq = platform_get_irq_byname(pdev, "hs_phy_irq");
+ irq = dwc3_qcom_get_irq(pdev, "hs_phy_irq",
+ pdata ? pdata->hs_phy_irq_index : -1);
if (irq > 0) {
/* Keep wakeup interrupts disabled until suspend */
irq_set_status_flags(irq, IRQ_NOAUTOEN);
@@ -320,7 +352,8 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)
qcom->hs_phy_irq = irq;
}
- irq = platform_get_irq_byname(pdev, "dp_hs_phy_irq");
+ irq = dwc3_qcom_get_irq(pdev, "dp_hs_phy_irq",
+ pdata ? pdata->dp_hs_phy_irq_index : -1);
if (irq > 0) {
irq_set_status_flags(irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
@@ -334,7 +367,8 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)
qcom->dp_hs_phy_irq = irq;
}
- irq = platform_get_irq_byname(pdev, "dm_hs_phy_irq");
+ irq = dwc3_qcom_get_irq(pdev, "dm_hs_phy_irq",
+ pdata ? pdata->dm_hs_phy_irq_index : -1);
if (irq > 0) {
irq_set_status_flags(irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
@@ -348,7 +382,8 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)
Re: [PATCH v8 24/29] vfio: VFIO_IOMMU_BIND/UNBIND_MSI
Hi Alex,
On 6/4/19 12:32 AM, Alex Williamson wrote:
> On Sun, 26 May 2019 18:09:59 +0200
> Eric Auger wrote:
>
>> This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioctl which aim
>> to pass/withdraw the guest MSI binding to/from the host.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> v6 -> v7:
>> - removed the dev arg
>>
>> v3 -> v4:
>> - add UNBIND
>> - unwind on BIND error
>>
>> v2 -> v3:
>> - adapt to new proto of bind_guest_msi
>> - directly use vfio_iommu_for_each_dev
>>
>> v1 -> v2:
>> - s/vfio_iommu_type1_guest_msi_binding/vfio_iommu_type1_bind_guest_msi
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 64 +
>> include/uapi/linux/vfio.h | 29 +++
>> 2 files changed, 93 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index 6fda4fbc9bfa..18142cb078a3 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -1832,6 +1832,42 @@ static int vfio_cache_inv_fn(struct device *dev, void
>> *data)
>> return iommu_cache_invalidate(dc->domain, dev, &ustruct->info);
>> }
>>
>> +static int
>> +vfio_bind_msi(struct vfio_iommu *iommu,
>> + dma_addr_t giova, phys_addr_t gpa, size_t size)
>> +{
>> +struct vfio_domain *d;
>> +int ret = 0;
>> +
>> +mutex_lock(&iommu->lock);
>> +
>> +list_for_each_entry(d, &iommu->domain_list, next) {
>> +ret = iommu_bind_guest_msi(d->domain, giova, gpa, size);
>> +if (ret)
>> +goto unwind;
>> +}
>> +goto unlock;
>> +unwind:
>> +list_for_each_entry_continue_reverse(d, &iommu->domain_list, next) {
>> +iommu_unbind_guest_msi(d->domain, giova);
>> +}
>> +unlock:
>> +mutex_unlock(&iommu->lock);
>> +return ret;
>> +}
>> +
>> +static void
>> +vfio_unbind_msi(struct vfio_iommu *iommu, dma_addr_t giova)
>> +{
>> +struct vfio_domain *d;
>> +
>> +mutex_lock(&iommu->lock);
>> +list_for_each_entry(d, &iommu->domain_list, next) {
>> +iommu_unbind_guest_msi(d->domain, giova);
>> +}
>> +mutex_unlock(&iommu->lock);
>> +}
>> +
>> static long vfio_iommu_type1_ioctl(void *iommu_data,
>> unsigned int cmd, unsigned long arg)
>> {
>> @@ -1936,6 +1972,34 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
>> &ustruct);
>> mutex_unlock(&iommu->lock);
>> return ret;
>> +} else if (cmd == VFIO_IOMMU_BIND_MSI) {
>> +struct vfio_iommu_type1_bind_msi ustruct;
>> +
>> +minsz = offsetofend(struct vfio_iommu_type1_bind_msi,
>> +size);
>> +
>> +if (copy_from_user(&ustruct, (void __user *)arg, minsz))
>> +return -EFAULT;
>> +
>> +if (ustruct.argsz < minsz || ustruct.flags)
>> +return -EINVAL;
>> +
>> +return vfio_bind_msi(iommu, ustruct.iova, ustruct.gpa,
>> + ustruct.size);
>> +} else if (cmd == VFIO_IOMMU_UNBIND_MSI) {
>> +struct vfio_iommu_type1_unbind_msi ustruct;
>> +
>> +minsz = offsetofend(struct vfio_iommu_type1_unbind_msi,
>> +iova);
>> +
>> +if (copy_from_user(&ustruct, (void __user *)arg, minsz))
>> +return -EFAULT;
>> +
>> +if (ustruct.argsz < minsz || ustruct.flags)
>> +return -EINVAL;
>> +
>> +vfio_unbind_msi(iommu, ustruct.iova);
>> +return 0;
>> }
>>
>> return -ENOTTY;
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 055aa9b9745a..2774a1ab37ae 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -798,6 +798,35 @@ struct vfio_iommu_type1_cache_invalidate {
>> };
>> #define VFIO_IOMMU_CACHE_INVALIDATE _IO(VFIO_TYPE, VFIO_BASE + 24)
>>
>> +/**
>> + * VFIO_IOMMU_BIND_MSI - _IOWR(VFIO_TYPE, VFIO_BASE + 25,
>> + * struct vfio_iommu_type1_bind_msi)
>> + *
>> + * Pass a stage 1 MSI doorbell mapping to the host so that this
>> + * latter can build a nested stage2 mapping
>> + */
>> +struct vfio_iommu_type1_bind_msi {
>> +__u32 argsz;
>> +__u32 flags;
>> +__u64 iova;
>> +__u64 gpa;
>> +__u64 size;
>> +};
>> +#define VFIO_IOMMU_BIND_MSI _IO(VFIO_TYPE, VFIO_BASE + 25)
>> +
>> +/**
>> + * VFIO_IOMMU_UNBIND_MSI - _IOWR(VFIO_TYPE, VFIO_BASE + 26,
>> + * struct vfio_iommu_type1_unbind_msi)
>> + *
>> + * Unregister an MSI mapping
>> + */
>> +struct vfio_iommu_type1_unbind_msi {
>> +__u32 argsz;
>> +__u32 flags;
>> +__u64 iova;
>> +};
>> +#define VFIO_IOMMU_UNBIND_MSI _IO(VFIO_TYPE, VFIO_BASE + 26)
>> +
>> /* Additional API for SPAPR TCE (Server POWERPC) IOMMU */
>>
>> /*
>
> And another pair of ioctls. Maybe think about how we can r
[PATCH v2 4/8] pinctrl: qcom: sdm845: Provide ACPI support
This patch provides basic support for booting with ACPI instead
of the currently supported Device Tree. When doing so there are a
couple of differences which we need to taken into consideration.
Firstly, the SDM850 ACPI tables omit information pertaining to the
4 reserved GPIOs on the platform. If Linux attempts to touch/
initialise any of these lines, the firmware will restart the
platform.
Secondly, when booting with ACPI, it is expected that the firmware
will set-up things like; Regulators, Clocks, Pin Functions, etc in
their ideal configuration. Thus, the possible Pin Functions
available to this platform are not advertised when providing the
higher GPIOD/Pinctrl APIs with pin information.
Signed-off-by: Lee Jones
---
drivers/pinctrl/qcom/Kconfig | 2 +-
drivers/pinctrl/qcom/pinctrl-sdm845.c | 35 ++-
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 2e66ab72c10b..aafbe932424f 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -168,7 +168,7 @@ config PINCTRL_SDM660
config PINCTRL_SDM845
tristate "Qualcomm Technologies Inc SDM845 pin controller driver"
- depends on GPIOLIB && OF
+ depends on GPIOLIB && (OF || ACPI)
select PINCTRL_MSM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index c97f20fca5fd..7188bee3cf3e 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
@@ -3,6 +3,7 @@
* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include
#include
@@ -1277,6 +1278,10 @@ static const struct msm_pingroup sdm845_groups[] = {
UFS_RESET(ufs_reset, 0x99f000),
};
+static const int sdm845_acpi_reserved_gpios[] = {
+ 0, 1, 2, 3, 81, 82, 83, 84, -1
+};
+
static const struct msm_pinctrl_soc_data sdm845_pinctrl = {
.pins = sdm845_pins,
.npins = ARRAY_SIZE(sdm845_pins),
@@ -1284,14 +1289,41 @@ static const struct msm_pinctrl_soc_data sdm845_pinctrl
= {
.nfunctions = ARRAY_SIZE(sdm845_functions),
.groups = sdm845_groups,
.ngroups = ARRAY_SIZE(sdm845_groups),
+ .reserved_gpios = sdm845_acpi_reserved_gpios,
+ .ngpios = 150,
+};
+
+static const struct msm_pinctrl_soc_data sdm845_acpi_pinctrl = {
+ .pins = sdm845_pins,
+ .npins = ARRAY_SIZE(sdm845_pins),
+ .groups = sdm845_groups,
+ .ngroups = ARRAY_SIZE(sdm845_groups),
+ .reserved_gpios = sdm845_acpi_reserved_gpios,
.ngpios = 150,
};
static int sdm845_pinctrl_probe(struct platform_device *pdev)
{
- return msm_pinctrl_probe(pdev, &sdm845_pinctrl);
+ int ret;
+
+ if (pdev->dev.of_node) {
+ ret = msm_pinctrl_probe(pdev, &sdm845_pinctrl);
+ } else if (ACPI_HANDLE(&pdev->dev)) {
+ ret = msm_pinctrl_probe(pdev, &sdm845_acpi_pinctrl);
+ } else {
+ dev_err(&pdev->dev, "DT and ACPI disabled\n");
+ return -EINVAL;
+ }
+
+ return ret;
}
+static const struct acpi_device_id sdm845_pinctrl_acpi_match[] = {
+ { "QCOM0217"},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, sdm845_pinctrl_acpi_match);
+
static const struct of_device_id sdm845_pinctrl_of_match[] = {
{ .compatible = "qcom,sdm845-pinctrl", },
{ },
@@ -1302,6 +1334,7 @@ static struct platform_driver sdm845_pinctrl_driver = {
.name = "sdm845-pinctrl",
.pm = &msm_pinctrl_dev_pm_ops,
.of_match_table = sdm845_pinctrl_of_match,
+ .acpi_match_table = ACPI_PTR(sdm845_pinctrl_acpi_match),
},
.probe = sdm845_pinctrl_probe,
.remove = msm_pinctrl_remove,
--
2.17.1
[PATCH v2 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list
When booting MSM based platforms with Device Tree or some ACPI
implementations, it is possible to provide a list of reserved pins
via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
However some ACPI tables are not populated with this information,
thus it has to come from a knowledgable device driver instead.
Here we provide the MSM common driver with additional support to
parse this informtion and correctly populate the widely used
'valid_mask'.
Signed-off-by: Lee Jones
---
drivers/pinctrl/qcom/pinctrl-msm.c | 18 ++
drivers/pinctrl/qcom/pinctrl-msm.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index ee8119879c4c..3ac740b36508 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -607,8 +607,23 @@ static int msm_gpio_init_valid_mask(struct gpio_chip *chip)
int ret;
unsigned int len, i;
unsigned int max_gpios = pctrl->soc->ngpios;
+ const int *reserved = pctrl->soc->reserved_gpios;
u16 *tmp;
+ /* Driver provided reserved list overrides DT and ACPI */
+ if (reserved) {
+ bitmap_fill(chip->valid_mask, max_gpios);
+ for (i = 0; reserved[i] >= 0; i++) {
+ if (i >= max_gpios || reserved[i] >= max_gpios) {
+ dev_err(pctrl->dev, "invalid list of reserved
GPIOs\n");
+ return -EINVAL;
+ }
+ clear_bit(reserved[i], chip->valid_mask);
+ }
+
+ return 0;
+ }
+
/* The number of GPIOs in the ACPI tables */
len = ret = device_property_read_u16_array(pctrl->dev, "gpios", NULL,
0);
@@ -964,6 +979,9 @@ static void msm_gpio_irq_handler(struct irq_desc *desc)
static bool msm_gpio_needs_valid_mask(struct msm_pinctrl *pctrl)
{
+ if (pctrl->soc->reserved_gpios)
+ return true;
+
return device_property_read_u16_array(pctrl->dev, "gpios", NULL, 0) > 0;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h
b/drivers/pinctrl/qcom/pinctrl-msm.h
index c12048e54a6f..23b93ae92269 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.h
+++ b/drivers/pinctrl/qcom/pinctrl-msm.h
@@ -121,6 +121,7 @@ struct msm_pinctrl_soc_data {
bool pull_no_keeper;
const char *const *tiles;
unsigned int ntiles;
+ const int *reserved_gpios;
};
extern const struct dev_pm_ops msm_pinctrl_dev_pm_ops;
--
2.17.1
Re: [PATCH 10/15] static_call: Add basic static call infrastructure
On Thu, Jun 06, 2019 at 10:44:23PM +, Nadav Amit wrote:
> > + * Usage example:
> > + *
> > + * # Start with the following functions (with identical prototypes):
> > + * int func_a(int arg1, int arg2);
> > + * int func_b(int arg1, int arg2);
> > + *
> > + * # Define a 'my_key' reference, associated with func_a() by default
> > + * DEFINE_STATIC_CALL(my_key, func_a);
> > + *
> > + * # Call func_a()
> > + * static_call(my_key, arg1, arg2);
> > + *
> > + * # Update 'my_key' to point to func_b()
> > + * static_call_update(my_key, func_b);
> > + *
> > + * # Call func_b()
> > + * static_call(my_key, arg1, arg2);
>
> I think that this calling interface is not very intuitive.
Yeah, it is somewhat unfortunate..
> I understand that
> the macros/objtool cannot allow the calling interface to be completely
> transparent (as compiler plugin could). But, can the macros be used to
> paste the key with the “static_call”? I think that having something like:
>
> static_call__func(arg1, arg2)
>
> Is more readable than
>
> static_call(func, arg1, arg2)
Doesn't really make it much better for me; I think I'd prefer to switch
to the GCC plugin scheme over this. ISTR there being some propotypes
there, but I couldn't quickly locate them.
> > +}
> > +
> > +#define static_call_update(key, func)
> > \
> > +({ \
> > + BUILD_BUG_ON(!__same_type(func, STATIC_CALL_TRAMP(key))); \
> > + __static_call_update(&key, func); \
> > +})
>
> Is this safe against concurrent module removal?
It is for CONFIG_MODULE=n :-)
[PATCH v2 7/8] usb: dwc3: qcom: Start USB in 'host mode' on the SDM845
When booting with Device Tree, the current default boot configuration
table option, the request to boot via 'host mode' comes from the
'dr_mode' property. A property of the same name can be used inside
ACPI tables too. However it is missing from the SDM845's ACPI tables
so we have to supply this information using Platform Device Properties
instead.
This does not change the behaviour of any currently supported devices.
The property is only set on ACPI enabled platforms, thus for H/W
booting DT, unless a 'dr_mode' property is present, the default is
still OTG (On-The-Go) as per [0]. Any new ACPI devices added will
also be able to over-ride this implementation by providing a 'dr_mode'
property in their ACPI tables. In cases where 'dr_mode' is omitted
from the tables AND 'host mode' should not be the default (very
unlikely), then we will have to add some way of choosing between them
at run time - most likely by ACPI HID.
[0] Documentation/devicetree/bindings/usb/generic.txt
Signed-off-by: Lee Jones
---
drivers/usb/dwc3/dwc3-qcom.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 1e1f12b7991d..55ba04254e38 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -444,6 +444,11 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, int
count)
return 0;
}
+static const struct property_entry dwc3_qcom_acpi_properties[] = {
+ PROPERTY_ENTRY_STRING("dr_mode", "host"),
+ {}
+};
+
static int dwc3_qcom_acpi_register_core(struct platform_device *pdev)
{
struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
@@ -488,6 +493,13 @@ static int dwc3_qcom_acpi_register_core(struct
platform_device *pdev)
goto out;
}
+ ret = platform_device_add_properties(qcom->dwc3,
+dwc3_qcom_acpi_properties);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add properties\n");
+ goto out;
+ }
+
ret = platform_device_add(qcom->dwc3);
if (ret)
dev_err(&pdev->dev, "failed to add device\n");
--
2.17.1
[PATCH v2 5/8] soc: qcom: geni: Add support for ACPI
When booting with ACPI as the active set of configuration tables,
all; clocks, regulators, pin functions ect are expected to be at
their ideal values/levels/rates, thus the associated frameworks
are unavailable. Ensure calls to these APIs are shielded when
ACPI is enabled.
Signed-off-by: Lee Jones
---
drivers/soc/qcom/qcom-geni-se.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index 6b8ef01472e9..cff0a413e59a 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+#include
#include
#include
#include
@@ -450,6 +451,9 @@ int geni_se_resources_off(struct geni_se *se)
{
int ret;
+ if (ACPI_HANDLE(se->dev))
+ return 0;
+
ret = pinctrl_pm_select_sleep_state(se->dev);
if (ret)
return ret;
@@ -487,6 +491,9 @@ int geni_se_resources_on(struct geni_se *se)
{
int ret;
+ if (ACPI_HANDLE(se->dev))
+ return 0;
+
ret = geni_se_clks_on(se);
if (ret)
return ret;
@@ -724,12 +731,14 @@ static int geni_se_probe(struct platform_device *pdev)
if (IS_ERR(wrapper->base))
return PTR_ERR(wrapper->base);
- wrapper->ahb_clks[0].id = "m-ahb";
- wrapper->ahb_clks[1].id = "s-ahb";
- ret = devm_clk_bulk_get(dev, NUM_AHB_CLKS, wrapper->ahb_clks);
- if (ret) {
- dev_err(dev, "Err getting AHB clks %d\n", ret);
- return ret;
+ if (!ACPI_HANDLE(&pdev->dev)) {
+ wrapper->ahb_clks[0].id = "m-ahb";
+ wrapper->ahb_clks[1].id = "s-ahb";
+ ret = devm_clk_bulk_get(dev, NUM_AHB_CLKS, wrapper->ahb_clks);
+ if (ret) {
+ dev_err(dev, "Err getting AHB clks %d\n", ret);
+ return ret;
+ }
}
dev_set_drvdata(dev, wrapper);
--
2.17.1
[PATCH v2 1/8] i2c: i2c-qcom-geni: Provide support for ACPI
Add a match table to allow automatic probing of ACPI device
QCOM0220. Ignore clock attainment errors. Set default clock
frequency value.
Signed-off-by: Lee Jones
---
drivers/i2c/busses/i2c-qcom-geni.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index db075bc0d952..0fa93b448e8d 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+#include
#include
#include
#include
@@ -483,6 +484,12 @@ static const struct i2c_algorithm geni_i2c_algo = {
.functionality = geni_i2c_func,
};
+static const struct acpi_device_id geni_i2c_acpi_match[] = {
+ { "QCOM0220"},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, geni_i2c_acpi_match);
+
static int geni_i2c_probe(struct platform_device *pdev)
{
struct geni_i2c_dev *gi2c;
@@ -502,7 +509,7 @@ static int geni_i2c_probe(struct platform_device *pdev)
return PTR_ERR(gi2c->se.base);
gi2c->se.clk = devm_clk_get(&pdev->dev, "se");
- if (IS_ERR(gi2c->se.clk)) {
+ if (IS_ERR(gi2c->se.clk) && !ACPI_HANDLE(&pdev->dev)) {
ret = PTR_ERR(gi2c->se.clk);
dev_err(&pdev->dev, "Err getting SE Core clk %d\n", ret);
return ret;
@@ -510,12 +517,19 @@ static int geni_i2c_probe(struct platform_device *pdev)
ret = device_property_read_u32(&pdev->dev, "clock-frequency",
&gi2c->clk_freq_out);
- if (ret) {
+ if (ret && !ACPI_HANDLE(&pdev->dev)) {
dev_info(&pdev->dev,
"Bus frequency not specified, default to 100kHz.\n");
gi2c->clk_freq_out = KHZ(100);
}
+ if (ACPI_HANDLE(&pdev->dev)) {
+ ACPI_COMPANION_SET(&gi2c->adap.dev, ACPI_COMPANION(&pdev->dev));
+
+ /* Using default, same as the !ACPI case above */
+ gi2c->clk_freq_out = KHZ(100);
+ }
+
gi2c->irq = platform_get_irq(pdev, 0);
if (gi2c->irq < 0) {
dev_err(&pdev->dev, "IRQ error for i2c-geni\n");
@@ -660,6 +674,7 @@ static struct platform_driver geni_i2c_driver = {
.name = "geni_i2c",
.pm = &geni_i2c_pm_ops,
.of_match_table = geni_i2c_dt_match,
+ .acpi_match_table = ACPI_PTR(geni_i2c_acpi_match),
},
};
--
2.17.1
[PATCH v2 8/8] usb: dwc3: qcom: Improve error handling
dwc3_qcom_clk_init() is called with of_count_phandle_with_args() as an argument. If of_count_phandle_with_args() returns an error, the number of clocks will be a negative value and will lead to undefined behaviour. Ensure we check for an error before attempting to blindly use the value. Signed-off-by: Lee Jones Reviewed-by: Bjorn Andersson --- drivers/usb/dwc3/dwc3-qcom.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 55ba04254e38..e4dac82abd7d 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -409,6 +409,9 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, int count) if (!np || !count) return 0; + if (count < 0) + return count; + qcom->num_clocks = count; qcom->clks = devm_kcalloc(dev, qcom->num_clocks, -- 2.17.1
[PATCH v2 2/8] i2c: i2c-qcom-geni: Signify successful driver probe
The Qualcomm Geni I2C driver currently probes silently which can be confusing when debugging potential issues. Add a low level (INFO) print when each I2C controller is successfully initially set-up. Signed-off-by: Lee Jones --- drivers/i2c/busses/i2c-qcom-geni.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 0fa93b448e8d..720131c40fe0 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -598,6 +598,8 @@ static int geni_i2c_probe(struct platform_device *pdev) return ret; } + dev_dbg(&pdev->dev, "Geni-I2C adaptor successfully added\n"); + return 0; } -- 2.17.1
Re: [PATCH 08/15] x86/alternatives: Teach text_poke_bp() to emulate instructions
On Fri, Jun 07, 2019 at 05:41:42AM +, Nadav Amit wrote:
> > int poke_int3_handler(struct pt_regs *regs)
> > {
> > + long ip = regs->ip - INT3_INSN_SIZE + CALL_INSN_SIZE;
> > + struct opcode {
> > + u8 insn;
> > + s32 rel;
> > + } __packed opcode;
> > +
> > /*
> > * Having observed our INT3 instruction, we now must observe
> > * bp_patching_in_progress.
> > *
> > -* in_progress = TRUE INT3
> > -* WMB RMB
> > -* write INT3 if (in_progress)
> > +* in_progress = TRUE INT3
> > +* WMB RMB
> > +* write INT3 if (in_progress)
>
> I don’t see what has changed in this chunk… Whitespaces?
Yep, my editor kept marking that stuff red (space before tab), which
annoyed me enough to fix it.
> > *
> > -* Idem for bp_int3_handler.
> > +* Idem for bp_int3_opcode.
> > */
> > smp_rmb();
> >
> > @@ -943,8 +949,21 @@ int poke_int3_handler(struct pt_regs *re
> > if (user_mode(regs) || regs->ip != (unsigned long)bp_int3_addr)
> > return 0;
> >
> > - /* set up the specified breakpoint handler */
> > - regs->ip = (unsigned long) bp_int3_handler;
> > + opcode = *(struct opcode *)bp_int3_opcode;
> > +
> > + switch (opcode.insn) {
> > + case 0xE8: /* CALL */
> > + int3_emulate_call(regs, ip + opcode.rel);
> > + break;
> > +
> > + case 0xE9: /* JMP */
> > + int3_emulate_jmp(regs, ip + opcode.rel);
> > + break;
>
> Consider using RELATIVECALL_OPCODE and RELATIVEJUMP_OPCODE instead of the
> constants (0xE8, 0xE9), just as you do later in the patch.
Those are private to kprobes..
but I can do something like so:
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -48,8 +48,14 @@ static inline void int3_emulate_jmp(stru
regs->ip = ip;
}
-#define INT3_INSN_SIZE 1
-#define CALL_INSN_SIZE 5
+#define INT3_INSN_SIZE 1
+#define INT3_INSN_OPCODE 0xCC
+
+#define CALL_INSN_SIZE 5
+#define CALL_INSN_OPCODE 0xE8
+
+#define JMP_INSN_SIZE 5
+#define JMP_INSN_OPCODE0xE9
static inline void int3_emulate_push(struct pt_regs *regs, unsigned long val)
{
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -952,11 +952,11 @@ int poke_int3_handler(struct pt_regs *re
opcode = *(struct opcode *)bp_int3_opcode;
switch (opcode.insn) {
- case 0xE8: /* CALL */
+ case CALL_INSN_OPCODE:
int3_emulate_call(regs, ip + opcode.rel);
break;
- case 0xE9: /* JMP */
+ case JMP_INSN_OPCODE:
int3_emulate_jmp(regs, ip + opcode.rel);
break;
Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> that allows execution of legacy, non-IBT compatible library by an
> IBT-enabled application. When set, each bit in the bitmap indicates
> one page of legacy code.
>
> The bitmap is allocated and setup from the application.
> +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
> +{
> + u64 r;
> +
> + if (!current->thread.cet.ibt_enabled)
> + return -EINVAL;
> +
> + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
> + return -EINVAL;
> +
> + current->thread.cet.ibt_bitmap_addr = bitmap;
> + current->thread.cet.ibt_bitmap_size = size;
> +
> + /*
> + * Turn on IBT legacy bitmap.
> + */
> + modify_fpu_regs_begin();
> + rdmsrl(MSR_IA32_U_CET, r);
> + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
> + wrmsrl(MSR_IA32_U_CET, r);
> + modify_fpu_regs_end();
> +
> + return 0;
> +}
So you just program a random user supplied address into the hardware.
What happens if there's not actually anything at that address or the
user munmap()s the data after doing this?
Re: [PATCH 1/2] habanalabs: add rate-limit to an error message
On Thu, Jun 6, 2019 at 9:54 PM Joe Perches wrote:
>
> On Thu, 2019-06-06 at 15:20 +0300, Oded Gabbay wrote:
> > This patch changes the print of an error message about mis-configuration
> > of the debug infrastructure to be rate-limited, to prevent flooding of
> > kernel log, as these configuration requests can come at a high rate.
> []
> > diff --git a/drivers/misc/habanalabs/habanalabs_ioctl.c
> > b/drivers/misc/habanalabs/habanalabs_ioctl.c
> []
> > @@ -255,7 +255,7 @@ static int hl_debug_ioctl(struct hl_fpriv *hpriv, void
> > *data)
> > case HL_DEBUG_OP_SPMU:
> > case HL_DEBUG_OP_TIMESTAMP:
> > if (!hdev->in_debug) {
> > - dev_err(hdev->dev,
> > + dev_err_ratelimited(hdev->dev,
> > "Rejecting debug configuration request
> > because device not in debug mode\n");
> > return -EFAULT;
> > }
>
> Perhaps this should be dev_dbg
>
>
But this a basic error. I prefer to give visibility to the user in such a case.
Thanks,
Oded
Re: [RESEND v2 00/18] clk: imx: Switch the imx6 and imx7 to clk_hw based API
On 19-06-06 11:29:40, Stephen Boyd wrote: > Quoting Abel Vesa (2019-05-29 05:26:38) > > Resend for the following: > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F5%2F2%2F170&data=02%7C01%7Cabel.vesa%40nxp.com%7Ccd18ca91df204bd6f99408d6eaacf258%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636954425864592743&sdata=12O60IgeI2yxb2hJ5NmYyYxkE4o7VwH7rh1Zye%2BkT8E%3D&reserved=0 > > What's left after this series to convert over to clk_hw based APIs? I'm > happy to see this merge as long as we eventually delete the clk based > versions of the code in the imx driver so that we can complete the task. > The clk based defines will go away once there is no clk provider that needs it. The left clk providers are: all imx1 through imx5 and imx8. I will take care of this cleanup myself. > I took a look over everything and nothing stuck out, so: > > Reviewed-by: Stephen Boyd > > for the series. >
RE: [PATCH v7 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
>
>On 05/06/2019 13:03, Pawel Laszczak wrote:
>> This patch introduce new Cadence USBSS DRD driver to Linux kernel.
>>
>> The Cadence USBSS DRD Driver is a highly configurable IP Core which
>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
>> Host Only (XHCI)configurations.
>>
>> The current driver has been validated with FPGA platform. We have
>> support for PCIe bus, which is used on FPGA prototyping.
>>
>> The host side of USBSS-DRD controller is compliant with XHCI
>> specification, so it works with standard XHCI Linux driver.
>>
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/Kconfig|2 +
>> drivers/usb/Makefile |2 +
>> drivers/usb/cdns3/Kconfig | 44 +
>> drivers/usb/cdns3/Makefile | 14 +
>> drivers/usb/cdns3/cdns3-pci-wrap.c | 157 ++
>> drivers/usb/cdns3/core.c | 529 +++
>> drivers/usb/cdns3/core.h | 121 ++
>> drivers/usb/cdns3/debug.h | 173 +++
>> drivers/usb/cdns3/debugfs.c| 173 +++
>> drivers/usb/cdns3/drd.c| 379 +
>> drivers/usb/cdns3/drd.h| 166 ++
>> drivers/usb/cdns3/ep0.c| 915 +++
>> drivers/usb/cdns3/gadget-export.h | 28 +
>> drivers/usb/cdns3/gadget.c | 2290
>> drivers/usb/cdns3/gadget.h | 1313
>> drivers/usb/cdns3/host-export.h| 28 +
>> drivers/usb/cdns3/host.c | 76 +
>> drivers/usb/cdns3/trace.c | 23 +
>> drivers/usb/cdns3/trace.h | 447 ++
>> 19 files changed, 6880 insertions(+)
>> create mode 100644 drivers/usb/cdns3/Kconfig
>> create mode 100644 drivers/usb/cdns3/Makefile
>> create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c
>> create mode 100644 drivers/usb/cdns3/core.c
>> create mode 100644 drivers/usb/cdns3/core.h
>> create mode 100644 drivers/usb/cdns3/debug.h
>> create mode 100644 drivers/usb/cdns3/debugfs.c
>> create mode 100644 drivers/usb/cdns3/drd.c
>> create mode 100644 drivers/usb/cdns3/drd.h
>> create mode 100644 drivers/usb/cdns3/ep0.c
>> create mode 100644 drivers/usb/cdns3/gadget-export.h
>> create mode 100644 drivers/usb/cdns3/gadget.c
>> create mode 100644 drivers/usb/cdns3/gadget.h
>> create mode 100644 drivers/usb/cdns3/host-export.h
>> create mode 100644 drivers/usb/cdns3/host.c
>> create mode 100644 drivers/usb/cdns3/trace.c
>> create mode 100644 drivers/usb/cdns3/trace.h
>>
>
>
>
>
>> +/**
>> + * cdns3_probe - probe for cdns3 core device
>> + * @pdev: Pointer to cdns3 core platform device
>> + *
>> + * Returns 0 on success otherwise negative errno
>> + */
>> +static int cdns3_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct resource *res;
>> +struct cdns3 *cdns;
>> +void __iomem *regs;
>> +int ret;
>> +
>> +ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
>
>Are all cores supported by this driver limited to 32-bit? If not then
>you need to set the mask based on compatibles?
Two version: 0x00024509 and 0x0002450d support extended DMA address to 48 bits.
The problem is that the 16 most significant bit indicate the segment that can
be set
per endpoint. We can assume that it will be constant per endpoint. All DMA
memory
for data buffers and for TRBs must be in this range.
I think that Linux kernel (DMA subsystem) can't guarantee it.
Using dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48)) not guarantee that
segment
part will be always the same.
So the safest way is to limit DMA range to 32 bits.
>
Regards,
Pawel
Re: [PATCH bpf] bpf: fix nested bpf tracepoints with per-cpu data
On Thu, 6 Jun 2019 19:59:18 -0700 Andrii Nakryiko wrote: > On Thu, Jun 6, 2019 at 1:17 PM Matt Mullins wrote: > > > > BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as > > they do not increment bpf_prog_active while executing. > > > > This enables three levels of nesting, to support > > - a kprobe or raw tp or perf event, > > - another one of the above that irq context happens to call, and > > - another one in nmi context > > Can NMIs be nested? No, otherwise several things in the kernel will break. -- Steve
Béren felüli juttatások
Kedves Hölgyem/Uram! 2019 januárjától szinte minden béren kívüli juttatás jövedelemként fog adózni (kivételt képez ez alól a SZÉP kártya). A változások ellenére a vállalatok több mint 55%-a meg kívánja tartani a dolgozói juttatások nettó összegét, magára vállalva ezzel a megemelkedett adóterheket. Juttatási kártyáink segítségével 2019-ben a munkáltatók lefedhetik szinte az összes jelenleg használt béren kívüli juttatást, miközben munkavállalóik élvezhetik az akár korlátlan felhasználás lehetőségét. A SZÉP kártyától eltérően a mi kártyáinkkal olyan mindennapos költségek fedezhetőek mint például élelmiszer vásárlás, egészségügyi ellátás, ruházat, elektronika, üzemanyagköltség, közműdíj, sőt, akár még készpénzfelvételre is alkalmasak. Ez az egyetlen olyan juttatási kártya a magyar piacon, melyet minden hazai POS terminál elfogad, ezzel biztosítva a kártya széles körű felhasználhatóságát. Szívesen bemutatom Önnek, milyen további előnyökkel jár kártyáink dolgozói juttatásként történő alkalmazása, és részletes tájékoztatást adok a kártyák felhasználási lehetőségeiről – kérem jelezze ez iránti igényét. Kapolcs Mátyás Hungary Team Leader
Re: 5.1 kernel: khugepaged stuck at 100%
On 2019/06/07 09:40, Max Kellermann wrote: > On 2019/06/06 19:24, Max Kellermann wrote: > > I have the same problem (kernel 5.1.7), but over here, it's a PHP > > process, not khugepaged, which is looping inside compaction_alloc. > > This is what happened an hour later: > > kernel tried to execute NX-protected page - exploit attempt? (uid: 3) > BUG: unable to handle kernel paging request at c036f00f Another machine in the cluster has just crashed (same kernel, and hugepage/compaction again): BUG: unable to handle kernel paging request at d4338206 #PF error: [normal kernel read fault] PGD 85fff8067 P4D 85fff8067 PUD 85fff7067 PMD 0 Oops: [#2] SMP PTI CPU: 27 PID: 117908 Comm: php-cgi7.0 Tainted: G D 5.1.7-cmag1-th+ #5 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 RIP: 0010:isolate_freepages_block+0xa3/0x380 Code: 10 4c 89 c0 c7 44 24 0c 00 00 00 00 4d 89 de 48 c1 e0 06 f6 c3 1f 48 89 44 24 18 44 89 c8 49 89 d1 41 89 c4 0f 84 03 01 00 00 <49> 8b 07 83 c5 01 a9 00 00 01 00 75 0c 49 8b 47 08 a8 01 0f 84 b8 RSP: 0018:ad0d258bf898 EFLAGS: 00010246 RAX: RBX: 00081800 RCX: ad0d258bfb89 RDX: RSI: RDI: 9c08c8e0 RBP: R08: 0001 R09: 00081bff R10: R11: ad0d258bfb89 R12: R13: ad0d258bfb10 R14: ad0d258bfb89 R15: d4338206 FS: 7f92c1c84740() GS:9c08df9c() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: d4338206 CR3: 000966150002 CR4: 001606e0 Call Trace: compaction_alloc+0x7e6/0x870 ? move_freelist_tail+0xd0/0xd0 migrate_pages+0xaa/0x780 ? isolate_freepages_block+0x380/0x380 compact_zone+0x6ec/0xca0 compact_zone_order+0xd8/0x120 try_to_compact_pages+0xb1/0x260 __alloc_pages_direct_compact+0x87/0x160 __alloc_pages_slowpath+0x427/0xd50 __alloc_pages_nodemask+0x2d6/0x310 do_huge_pmd_anonymous_page+0x131/0x680 ? vma_merge+0x24f/0x3a0 __handle_mm_fault+0xbca/0x1260 handle_mm_fault+0x135/0x1b0 __do_page_fault+0x242/0x4b0 ? page_fault+0x8/0x30 page_fault+0x1e/0x30 RIP: 0033:0x55ab2b7205ee Code: 24 18 01 00 00 41 8b 8c 24 48 01 00 00 8d 51 01 41 3b 94 24 4c 01 00 00 41 89 94 24 48 01 00 00 7e 08 41 89 94 24 4c 01 00 00 <4c> 89 20 49 8b 94 24 38 01 00 00 45 31 db 41 bd 00 10 00 00 41 b9 RSP: 002b:7ffd79f76750 EFLAGS: 00010202 RAX: 7f929b80 RBX: 0011 RCX: 0007 RDX: 0008 RSI: 0020 RDI: 7f929b80 RBP: 0006 R08: R09: R10: 0022 R11: 0246 R12: 7f92bd40 R13: R14: 0200 R15: 7f929c7ac648 Modules linked in: CR2: d4338206 ---[ end trace 73412f77c0bd1f72 ]--- RIP: 0010:isolate_freepages_block+0xa3/0x380 Code: 10 4c 89 c0 c7 44 24 0c 00 00 00 00 4d 89 de 48 c1 e0 06 f6 c3 1f 48 89 44 24 18 44 89 c8 49 89 d1 41 89 c4 0f 84 03 01 00 00 <49> 8b 07 83 c5 01 a9 00 00 01 00 75 0c 49 8b 47 08 a8 01 0f 84 b8 RSP: 0018:ad0d0894f898 EFLAGS: 00010246 RAX: RBX: 00082000 RCX: ad0d0894fb89 RDX: RSI: RDI: 9c08c8e0 RBP: R08: 0001 R09: 000823ff R10: R11: ad0d0894fb89 R12: R13: ad0d0894fb10 R14: ad0d0894fb89 R15: d4338208 FS: 7f92c1c84740() GS:9c08df9c() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: d4338206 CR3: 000966150002 CR4: 001606e0
Re: 5.1 kernel: khugepaged stuck at 100%
Hi.
On Fri, Jun 07, 2019 at 09:40:52AM +0200, Max Kellermann wrote:
> On 2019/06/06 19:24, Max Kellermann wrote:
> > I have the same problem (kernel 5.1.7), but over here, it's a PHP
> > process, not khugepaged, which is looping inside compaction_alloc.
>
> This is what happened an hour later:
>
> kernel tried to execute NX-protected page - exploit attempt? (uid: 3)
> BUG: unable to handle kernel paging request at c036f00f
> #PF error: [PROT] [INSTR]
> PGD 35fa10067 P4D 35fa10067 PUD 35fa12067 PMD 105ba71067 PTE 80022d28e061
> Oops: 0011 [#1] SMP PTI
> CPU: 12 PID: 263514 Comm: php-cgi7.0 Not tainted 5.1.7-cmag1-th+ #5
> Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89
> 10/17/2018
> RIP: 0010:0xc036f00f
> Code: Bad RIP value.
> RSP: 0018:b63c4d547928 EFLAGS: 00010216
> RAX: RBX: b63c4d547b10 RCX: ffc004d021bd
> RDX: 9ac83fffc500 RSI: 7fe0026810dee7ff RDI: 7fe0026810dee400
> RBP: 7fe0026810dee400 R08: 0002 R09: 00020300
> R10: 00010642641a0d3a R11: 0001 R12: 7fe0026810dee800
> R13: 0001 R14: R15: 9ac83fffc500
> FS: 7fa5c1000740() GS:9ad01f60() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: c036efe5 CR3: 0008eb8a0005 CR4: 001606e0
> Call Trace:
> ? move_freelist_tail+0xd0/0xd0
> ? migrate_pages+0xaa/0x780
> ? isolate_freepages_block+0x380/0x380
> ? compact_zone+0x6ec/0xca0
> ? compact_zone_order+0xd8/0x120
> ? try_to_compact_pages+0xb1/0x260
> ? __alloc_pages_direct_compact+0x87/0x160
> ? __alloc_pages_slowpath+0x427/0xd50
> ? __alloc_pages_nodemask+0x2d6/0x310
> ? do_huge_pmd_anonymous_page+0x131/0x680
> ? vma_merge+0x24f/0x3a0
> ? __handle_mm_fault+0xbca/0x1260
> ? handle_mm_fault+0x135/0x1b0
> ? __do_page_fault+0x242/0x4b0
> ? page_fault+0x8/0x30
> ? page_fault+0x1e/0x30
> Modules linked in:
> CR2: c036f00f
> ---[ end trace 0f31edf3041f5d9e ]---
> RIP: 0010:0xc036f00f
> Code: Bad RIP value.
> RSP: 0018:b63c4d547928 EFLAGS: 00010216
> RAX: RBX: b63c4d547b10 RCX: ffc004d021bd
> RDX: 9ac83fffc500 RSI: 7fe0026810dee7ff RDI: 7fe0026810dee400
> RBP: 7fe0026810dee400 R08: 0002 R09: 00020300
> R10: 00010642641a0d3a R11: 0001 R12: 7fe0026810dee800
> R13: 0001 R14: R15: 9ac83fffc500
> FS: 7fa5c1000740() GS:9ad01f60() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: c036efe5 CR3: 0008eb8a0005 CR4: 001606e0
Make sure to check if e577c8b64d ("mm, compaction: make sure we isolate
a valid PFN") fixes your issue. It is staged for 5.1.8, BTW.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
Re: [PATCH 12/15] x86/static_call: Add out-of-line static call implementation
On Fri, 7 Jun 2019 06:13:58 +
Nadav Amit wrote:
> > On Jun 5, 2019, at 6:08 AM, Peter Zijlstra wrote:
> >
> > From: Josh Poimboeuf
> >
> > Add the x86 out-of-line static call implementation. For each key, a
> > permanent trampoline is created which is the destination for all static
> > calls for the given key. The trampoline has a direct jump which gets
> > patched by static_call_update() when the destination function changes.
> >
> > Cc: x...@kernel.org
> > Cc: Steven Rostedt
> > Cc: Julia Cartwright
> > Cc: Ingo Molnar
> > Cc: Ard Biesheuvel
> > Cc: Jason Baron
> > Cc: Linus Torvalds
> > Cc: Jiri Kosina
> > Cc: Thomas Gleixner
> > Cc: Masami Hiramatsu
> > Cc: Borislav Petkov
> > Cc: David Laight
> > Cc: Jessica Yu
> > Cc: Andy Lutomirski
> > Cc: "H. Peter Anvin"
> > Signed-off-by: Josh Poimboeuf
> > Signed-off-by: Peter Zijlstra (Intel)
> > Link:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.kernel.org%2Fr%2F00b08f2194e80241decbf206624b6580b9b8855b.1543200841.git.jpoimboe%40redhat.com&data=02%7C01%7Cnamit%40vmware.com%7C13bc03381930464a018e08d6e9b8f90e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636953378007810030&sdata=UnHEUYEYV3FBSZj667lZYzGKRov%2B1PdAjAnM%2BqOz3Ns%3D&reserved=0
> > ---
> > arch/x86/Kconfig |1
> > arch/x86/include/asm/static_call.h | 28 +++
> > arch/x86/kernel/Makefile |1
> > arch/x86/kernel/static_call.c | 38
> > +
> > 4 files changed, 68 insertions(+)
> > create mode 100644 arch/x86/include/asm/static_call.h
> > create mode 100644 arch/x86/kernel/static_call.c
> >
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -198,6 +198,7 @@ config X86
> > select HAVE_FUNCTION_ARG_ACCESS_API
> > select HAVE_STACKPROTECTOR if CC_HAS_SANE_STACKPROTECTOR
> > select HAVE_STACK_VALIDATIONif X86_64
> > + select HAVE_STATIC_CALL
> > select HAVE_RSEQ
> > select HAVE_SYSCALL_TRACEPOINTS
> > select HAVE_UNSTABLE_SCHED_CLOCK
> > --- /dev/null
> > +++ b/arch/x86/include/asm/static_call.h
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_STATIC_CALL_H
> > +#define _ASM_STATIC_CALL_H
> > +
> > +/*
> > + * Manually construct a 5-byte direct JMP to prevent the assembler from
> > + * optimizing it into a 2-byte JMP.
> > + */
> > +#define __ARCH_STATIC_CALL_JMP_LABEL(key) ".L" __stringify(key ##
> > _after_jmp)
> > +#define __ARCH_STATIC_CALL_TRAMP_JMP(key, func)
> > \
> > + ".byte 0xe9 \n" \
> > + ".long " #func " - " __ARCH_STATIC_CALL_JMP_LABEL(key) "\n" \
> > + __ARCH_STATIC_CALL_JMP_LABEL(key) ":"
> > +
> > +/*
> > + * This is a permanent trampoline which does a direct jump to the function.
> > + * The direct jump get patched by static_call_update().
> > + */
> > +#define ARCH_DEFINE_STATIC_CALL_TRAMP(key, func) \
> > + asm(".pushsection .text, \"ax\" \n" \
> > + ".align 4 \n" \
> > + ".globl " STATIC_CALL_TRAMP_STR(key) " \n" \
> > + ".type " STATIC_CALL_TRAMP_STR(key) ", @function\n" \
> > + STATIC_CALL_TRAMP_STR(key) ": \n" \
> > + __ARCH_STATIC_CALL_TRAMP_JMP(key, func) " \n" \
> > + ".popsection\n")
> > +
> > +#endif /* _ASM_STATIC_CALL_H */
> > --- a/arch/x86/kernel/Makefile
> > +++ b/arch/x86/kernel/Makefile
> > @@ -63,6 +63,7 @@ obj-y += tsc.o tsc_msr.o io_delay.o rt
> > obj-y += pci-iommu_table.o
> > obj-y += resource.o
> > obj-y += irqflags.o
> > +obj-y += static_call.o
> >
> > obj-y += process.o
> > obj-y += fpu/
> > --- /dev/null
> > +++ b/arch/x86/kernel/static_call.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define CALL_INSN_SIZE 5
> > +
> > +void arch_static_call_transform(void *site, void *tramp, void *func)
> > +{
> > + unsigned char opcodes[CALL_INSN_SIZE];
> > + unsigned char insn_opcode;
> > + unsigned long insn;
> > + s32 dest_relative;
> > +
> > + mutex_lock(&text_mutex);
> > +
> > + insn = (unsigned long)tramp;
> > +
> > + insn_opcode = *(unsigned char *)insn;
> > + if (insn_opcode != 0xE9) {
> > + WARN_ONCE(1, "unexpected static call insn opcode 0x%x at %pS",
> > + insn_opcode, (void *)insn);
> > + goto unlock;
>
> This might happen if a kprobe is installed on the call, no?
>
> I don’t know if you want to be more gentle handling of this case (or perhaps
> modify can_probe() to prev
Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
Hi Dmitry: Will you apply them? Thanks, Aaron On 6/4/19 1:19 PM, Christopher Heiny wrote: > Given that, I'm willing to accept the patch as is. > > Cheers, > Chris
Thanks and I wait for your answer
Hello, I am Martin Henry, An American Citizen; I am the personal secretary to Mr. Donald Railton, the controller of a Lottery Company. Please I am having big problem now, I have a 6yrs old daughter who has leukemia, a disease of the blood, and she needs a bone marrow transplant or she will die. Please I am only asking for your help and you will benefit from it also. As an insider with Lottery Firm, working as the personal secretary to the controller, I want you to send me your name to play, I have some numbers that are going to win, stored in his secret data system in the office. The Lottery is an online entry with credit card anywhere with a name and address. All I want you to do is to send your name to play it and I will send confirmation to you. I will play with my card on your name and the Prize will be shared equally between us. Immediately the results are released they will contact you for payment as the oversea winner. The lotto can be played with 9.00 dollars, or 50 dollars but the prize will be Millions. Remember that I am playing on your name with my card; I just want to front you for this, because I need this money to save the life of my little daughter. Thanks and I wait for your answer Martin Henry.
Re: [PATCH V5 1/3] mm/hotplug: Reorder arch_remove_memory() call in __remove_memory()
On 07.06.19 04:28, Anshuman Khandual wrote: > > > On 05/30/2019 04:07 PM, Mark Rutland wrote: >> On Wed, May 29, 2019 at 02:46:25PM +0530, Anshuman Khandual wrote: >>> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs >>> entries between memory block and node. It first checks pfn validity with >>> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config >>> (arm64 has this enabled) pfn_valid_within() calls pfn_valid(). >>> >>> pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID) >>> which scans all mapped memblock regions with memblock_is_map_memory(). This >>> creates a problem in memory hot remove path which has already removed given >>> memory range from memory block with memblock_[remove|free] before arriving >>> at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1 >>> skipping subsequent sysfs_remove_link() calls leaving node <-> memory block >>> sysfs entries as is. Subsequent memory add operation hits BUG_ON() because >>> of existing sysfs entries. >>> >>> [ 62.007176] NUMA: Unknown node for memory at 0x68000, assuming node 0 >>> [ 62.052517] [ cut here ] >>> [ 62.053211] kernel BUG at mm/memory_hotplug.c:1143! >>> [ 62.053868] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP >>> [ 62.054589] Modules linked in: >>> [ 62.054999] CPU: 19 PID: 3275 Comm: bash Not tainted >>> 5.1.0-rc2-4-g28cea40b2683 #41 >>> [ 62.056274] Hardware name: linux,dummy-virt (DT) >>> [ 62.057166] pstate: 4045 (nZcv daif +PAN -UAO) >>> [ 62.058083] pc : add_memory_resource+0x1cc/0x1d8 >>> [ 62.058961] lr : add_memory_resource+0x10c/0x1d8 >>> [ 62.059842] sp : 168b3ce0 >>> [ 62.060477] x29: 168b3ce0 x28: 8005db546c00 >>> [ 62.061501] x27: x26: >>> [ 62.062509] x25: 111ef000 x24: 111ef5d0 >>> [ 62.063520] x23: x22: 0006bfff >>> [ 62.064540] x21: ffef x20: 006c >>> [ 62.065558] x19: 0068 x18: 0024 >>> [ 62.066566] x17: x16: >>> [ 62.067579] x15: x14: 8005e412e890 >>> [ 62.068588] x13: 8005d6b105d8 x12: >>> [ 62.069610] x11: 8005d6b10490 x10: 0040 >>> [ 62.070615] x9 : 8005e412e898 x8 : 8005e412e890 >>> [ 62.071631] x7 : 8005d6b105d8 x6 : 8005db546c00 >>> [ 62.072640] x5 : 0001 x4 : 0002 >>> [ 62.073654] x3 : 8005d7049480 x2 : 0002 >>> [ 62.074666] x1 : 0003 x0 : ffef >>> [ 62.075685] Process bash (pid: 3275, stack limit = 0xd754280f) >>> [ 62.076930] Call trace: >>> [ 62.077411] add_memory_resource+0x1cc/0x1d8 >>> [ 62.078227] __add_memory+0x70/0xa8 >>> [ 62.078901] probe_store+0xa4/0xc8 >>> [ 62.079561] dev_attr_store+0x18/0x28 >>> [ 62.080270] sysfs_kf_write+0x40/0x58 >>> [ 62.080992] kernfs_fop_write+0xcc/0x1d8 >>> [ 62.081744] __vfs_write+0x18/0x40 >>> [ 62.082400] vfs_write+0xa4/0x1b0 >>> [ 62.083037] ksys_write+0x5c/0xc0 >>> [ 62.083681] __arm64_sys_write+0x18/0x20 >>> [ 62.084432] el0_svc_handler+0x88/0x100 >>> [ 62.085177] el0_svc+0x8/0xc >>> >>> Re-ordering arch_remove_memory() with memblock_[free|remove] solves the >>> problem on arm64 as pfn_valid() behaves correctly and returns positive >>> as memblock for the address range still exists. arch_remove_memory() >>> removes applicable memory sections from zone with __remove_pages() and >>> tears down kernel linear mapping. Removing memblock regions afterwards >>> is safe because there is no other memblock (bootmem) allocator user that >>> late. So nobody is going to allocate from the removed range just to blow >>> up later. Also nobody should be using the bootmem allocated range else >>> we wouldn't allow to remove it. So reordering is indeed safe. >>> >>> Acked-by: Michal Hocko >>> Reviewed-by: David Hildenbrand >>> Reviewed-by: Oscar Salvador >>> Signed-off-by: Anshuman Khandual >> >> Acked-by: Mark Rutland > > Hello Andrew, > > Will it be possible for this particular patch of the series to be merged > alone. > I am still reworking arm64 hot-remove parts as per the suggestions from Mark. > Just wondering if this patch which has been reviewed and acked for a while now > can be out of our way. I suggest that you just resend a rebased version (linux-next). That makes it much easier for Andrew to pick up (and for others to review). Cheers! > > Also because this has some conflict with David's series which can be sorted > out > earlier before arm64 hot-remove V6 series comes in. > > From my previous response on this series last week, the following can resolve > the conflict with David's [v3, 09/11] patch. > > C) Rebase (https://patchwork.kernel.org/patch/10962589/) [v3, 09/11] > > - hot-remove series moves arch_remove_memory() be
Re: 5.1 kernel: khugepaged stuck at 100%
On 2019/06/06 19:24, Max Kellermann wrote: > I have the same problem (kernel 5.1.7), but over here, it's a PHP > process, not khugepaged, which is looping inside compaction_alloc. This is what happened an hour later: kernel tried to execute NX-protected page - exploit attempt? (uid: 3) BUG: unable to handle kernel paging request at c036f00f #PF error: [PROT] [INSTR] PGD 35fa10067 P4D 35fa10067 PUD 35fa12067 PMD 105ba71067 PTE 80022d28e061 Oops: 0011 [#1] SMP PTI CPU: 12 PID: 263514 Comm: php-cgi7.0 Not tainted 5.1.7-cmag1-th+ #5 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 RIP: 0010:0xc036f00f Code: Bad RIP value. RSP: 0018:b63c4d547928 EFLAGS: 00010216 RAX: RBX: b63c4d547b10 RCX: ffc004d021bd RDX: 9ac83fffc500 RSI: 7fe0026810dee7ff RDI: 7fe0026810dee400 RBP: 7fe0026810dee400 R08: 0002 R09: 00020300 R10: 00010642641a0d3a R11: 0001 R12: 7fe0026810dee800 R13: 0001 R14: R15: 9ac83fffc500 FS: 7fa5c1000740() GS:9ad01f60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c036efe5 CR3: 0008eb8a0005 CR4: 001606e0 Call Trace: ? move_freelist_tail+0xd0/0xd0 ? migrate_pages+0xaa/0x780 ? isolate_freepages_block+0x380/0x380 ? compact_zone+0x6ec/0xca0 ? compact_zone_order+0xd8/0x120 ? try_to_compact_pages+0xb1/0x260 ? __alloc_pages_direct_compact+0x87/0x160 ? __alloc_pages_slowpath+0x427/0xd50 ? __alloc_pages_nodemask+0x2d6/0x310 ? do_huge_pmd_anonymous_page+0x131/0x680 ? vma_merge+0x24f/0x3a0 ? __handle_mm_fault+0xbca/0x1260 ? handle_mm_fault+0x135/0x1b0 ? __do_page_fault+0x242/0x4b0 ? page_fault+0x8/0x30 ? page_fault+0x1e/0x30 Modules linked in: CR2: c036f00f ---[ end trace 0f31edf3041f5d9e ]--- RIP: 0010:0xc036f00f Code: Bad RIP value. RSP: 0018:b63c4d547928 EFLAGS: 00010216 RAX: RBX: b63c4d547b10 RCX: ffc004d021bd RDX: 9ac83fffc500 RSI: 7fe0026810dee7ff RDI: 7fe0026810dee400 RBP: 7fe0026810dee400 R08: 0002 R09: 00020300 R10: 00010642641a0d3a R11: 0001 R12: 7fe0026810dee800 R13: 0001 R14: R15: 9ac83fffc500 FS: 7fa5c1000740() GS:9ad01f60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c036efe5 CR3: 0008eb8a0005 CR4: 001606e0
[PATCH] drivers/ata: remove flood "Enabling discard_zeroes_data"
Printing this at each SCSI READ_CAPACITY command is too verbose.
Flag "discard_zeroes_data" is deprecated since commit 48920ff2a5a9
("block: remove the discard_zeroes_data flag").
Signed-off-by: Konstantin Khlebnikov
---
drivers/ata/libata-scsi.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 391ac0503dc0..a475e94944b7 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2735,10 +2735,8 @@ static unsigned int ata_scsiop_read_cap(struct
ata_scsi_args *args, u8 *rbuf)
rbuf[14] |= 0x80; /* LBPME */
if (ata_id_has_zero_after_trim(args->id) &&
- dev->horkage & ATA_HORKAGE_ZERO_AFTER_TRIM) {
- ata_dev_info(dev, "Enabling
discard_zeroes_data\n");
+ dev->horkage & ATA_HORKAGE_ZERO_AFTER_TRIM)
rbuf[14] |= 0x40; /* LBPRZ */
- }
}
if (ata_id_zoned_cap(args->id) ||
args->dev->class == ATA_DEV_ZAC)
[PATCH] drivers/ata: print trim features at device initialization
Print trim status once at ata device initialization in form:
ataX.YZ: trim: , queued: ,
zero_after_trim:
Full example:
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.00: NCQ Send/Recv Log not supported
ata1.00: ATA-9: SAMSUNG MZ7GE900HMHP-000DX, EXT03Y3Q, max UDMA/133
ata1.00: 1758174768 sectors, multi 16: LBA48 NCQ (depth 32), AA
ata1.00: trim: supported, queued: no, zero_after_trim: maybe
ata1.00: NCQ Send/Recv Log not supported
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA SAMSUNG MZ7GE900 3Y3Q PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 1758174768 512-byte logical blocks: (900 GB/838 GiB)
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
Signed-off-by: Konstantin Khlebnikov
---
drivers/ata/libata-core.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index aaa57e0c809d..6ff33e79cfc2 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2617,6 +2617,34 @@ int ata_dev_configure(struct ata_device *dev)
}
}
+ if (print_info && ata_id_has_trim(id)) {
+ const char *trim_status;
+ const char *trim_queued;
+ const char *trim_zero;
+
+ if (dev->horkage & ATA_HORKAGE_NOTRIM)
+ trim_status = "backlisted";
+ else
+ trim_status = "supported";
+
+ if (!ata_fpdma_dsm_supported(dev))
+ trim_queued = "no";
+ else if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM)
+ trim_queued = "backlisted";
+ else
+ trim_queued = "yes";
+
+ if (!ata_id_has_zero_after_trim(id))
+ trim_zero = "no";
+ else if (dev->horkage & ATA_HORKAGE_ZERO_AFTER_TRIM)
+ trim_zero = "yes";
+ else
+ trim_zero = "maybe";
+
+ ata_dev_info(dev, "trim: %s, queued: %s,
zero_after_trim: %s\n",
+trim_status, trim_queued, trim_zero);
+ }
+
/* Check and mark DevSlp capability. Get DevSlp timing variables
* from SATA Settings page of Identify Device Data Log.
*/
[PATCH] drivers/ata: cleanup creation of device sysfs attribute
This patch merges common ATA and AHCI specific attribute "sw_activity"
into one group with ->is_visible() method which hides attributes if
feature is not supported by hardware.
This allows to add all attributes in one place without exporting
each piece for linking into another list in ahci module.
Signed-off-by: Konstantin Khlebnikov
---
drivers/ata/ahci.h|4 +---
drivers/ata/libahci.c |8
drivers/ata/libata-scsi.c | 48 +
include/linux/libata.h|7 ++-
4 files changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 0570629d719d..09b55161a107 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -371,7 +371,6 @@ struct ahci_host_priv {
extern int ahci_ignore_sss;
extern struct device_attribute *ahci_shost_attrs[];
-extern struct device_attribute *ahci_sdev_attrs[];
/*
* This must be instantiated by the edge drivers. Read the comments
@@ -382,8 +381,7 @@ extern struct device_attribute *ahci_sdev_attrs[];
.can_queue = AHCI_MAX_CMDS,\
.sg_tablesize = AHCI_MAX_SG, \
.dma_boundary = AHCI_DMA_BOUNDARY,\
- .shost_attrs= ahci_shost_attrs, \
- .sdev_attrs = ahci_sdev_attrs
+ .shost_attrs= ahci_shost_attrs
extern struct ata_port_operations ahci_ops;
extern struct ata_port_operations ahci_platform_ops;
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 0984c4b76d7e..532f087e7dbf 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -122,14 +122,6 @@ struct device_attribute *ahci_shost_attrs[] = {
};
EXPORT_SYMBOL_GPL(ahci_shost_attrs);
-struct device_attribute *ahci_sdev_attrs[] = {
- &dev_attr_sw_activity,
- &dev_attr_unload_heads,
- &dev_attr_ncq_prio_enable,
- NULL
-};
-EXPORT_SYMBOL_GPL(ahci_sdev_attrs);
-
struct ata_port_operations ahci_ops = {
.inherits = &sata_pmp_port_ops,
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index a475e94944b7..810cc78814f5 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -253,9 +253,8 @@ static ssize_t ata_scsi_park_store(struct device *device,
return rc ? rc : len;
}
-DEVICE_ATTR(unload_heads, S_IRUGO | S_IWUSR,
- ata_scsi_park_show, ata_scsi_park_store);
-EXPORT_SYMBOL_GPL(dev_attr_unload_heads);
+static DEVICE_ATTR(unload_heads, S_IRUGO | S_IWUSR,
+ ata_scsi_park_show, ata_scsi_park_store);
static ssize_t ata_ncq_prio_enable_show(struct device *device,
struct device_attribute *attr,
@@ -330,9 +329,8 @@ static ssize_t ata_ncq_prio_enable_store(struct device
*device,
return rc ? rc : len;
}
-DEVICE_ATTR(ncq_prio_enable, S_IRUGO | S_IWUSR,
- ata_ncq_prio_enable_show, ata_ncq_prio_enable_store);
-EXPORT_SYMBOL_GPL(dev_attr_ncq_prio_enable);
+static DEVICE_ATTR(ncq_prio_enable, S_IRUGO | S_IWUSR,
+ ata_ncq_prio_enable_show, ata_ncq_prio_enable_store);
void ata_scsi_set_sense(struct ata_device *dev, struct scsi_cmnd *cmd,
u8 sk, u8 asc, u8 ascq)
@@ -459,16 +457,40 @@ ata_scsi_activity_store(struct device *dev, struct
device_attribute *attr,
}
return -EINVAL;
}
-DEVICE_ATTR(sw_activity, S_IWUSR | S_IRUGO, ata_scsi_activity_show,
- ata_scsi_activity_store);
-EXPORT_SYMBOL_GPL(dev_attr_sw_activity);
+static DEVICE_ATTR(sw_activity, S_IWUSR | S_IRUGO,
+ ata_scsi_activity_show, ata_scsi_activity_store);
-struct device_attribute *ata_common_sdev_attrs[] = {
- &dev_attr_unload_heads,
- &dev_attr_ncq_prio_enable,
+static umode_t ata_common_attrs_are_visible(struct kobject *kobj,
+ struct attribute *a, int n)
+{
+ struct scsi_device *sdev = to_scsi_device(kobj_to_dev(kobj));
+ struct ata_port *ap = ata_shost_to_port(sdev->host);
+
+ if (a == &dev_attr_sw_activity.attr) {
+ if (!(ap->flags & ATA_FLAG_SW_ACTIVITY))
+ return 0;
+ }
+
+ return a->mode;
+}
+
+static struct attribute *ata_sdev_attrs[] = {
+ &dev_attr_unload_heads.attr,
+ &dev_attr_ncq_prio_enable.attr,
+ &dev_attr_sw_activity.attr,
+ NULL
+};
+
+static const struct attribute_group ata_sdev_attr_group = {
+ .attrs = ata_sdev_attrs,
+ .is_visible = ata_common_attrs_are_visible,
+};
+
+const struct attribute_group *ata_sdev_attr_groups[] = {
+ &ata_sdev_attr_group,
NULL
};
-EXPORT_SYMBOL_GPL(ata_common_sdev_attrs);
+EXPORT_SYMBOL_GPL(ata_sdev_attr_groups);
/**
* ata_std_bios_param - generic bios head/sector/cylinder calculator used
by sd.
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 207e7e
[PATCH] staging: rtl8723bs: os_dep: ioctl_linux.c: Remove return variables
Remove return variables and return the values directly, as the functions
all return 0 in all cases.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 236a462a4936..a6fce63ad4db 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -2601,9 +2601,7 @@ static int rtw_p2p_set(struct net_device *dev,
union iwreq_data *wrqu, char *extra)
{
- int ret = 0;
-
- return ret;
+ return 0;
}
@@ -2612,9 +2610,7 @@ static int rtw_p2p_get(struct net_device *dev,
union iwreq_data *wrqu, char *extra)
{
- int ret = 0;
-
- return ret;
+ return 0;
}
@@ -2623,9 +2619,7 @@ static int rtw_p2p_get2(struct net_device *dev,
union iwreq_data *wrqu, char
*extra)
{
- int ret = 0;
-
- return ret;
+ return 0;
}
--
2.19.1
Re: [PATCH 0/2] block, bfq: add weight symlink to the bfq.weight cgroup parameter
On 5/21/19 2:01 AM, Paolo Valente wrote: > Many userspace tools and services use the proportional-share policy of > the blkio/io cgroups controller. The CFQ I/O scheduler implemented > this policy for the legacy block layer. To modify the weight of a > group in case CFQ was in charge, the 'weight' parameter of the group > must be modified. On the other hand, the BFQ I/O scheduler implements > the same policy in blk-mq, but, with BFQ, the parameter to modify has > a different name: bfq.weight (forced choice until legacy block was > present, because two different policies cannot share a common parameter > in cgroups). > > Due to CFQ legacy, most if not all userspace configurations still use > the parameter 'weight', and for the moment do not seem likely to be > changed. But, when CFQ went away with legacy block, such a parameter > ceased to exist. > > So, a simple workaround has been proposed by Johannes [1] to make all > configurations work: add a symlink, named weight, to bfq.weight. This > pair of patches adds: > 1) the possibility to create a symlink to a cgroup file; > 2) the above 'weight' symlink. Applied, thanks. -- Jens Axboe
Re: [PATCH] lockref: Limit number of cmpxchg loop retries
On Thu, Jun 06, 2019 at 10:28:12AM +, Jan Glauber wrote: > On Thu, Jun 06, 2019 at 10:41:54AM +0100, Will Deacon wrote: > > On Thu, Jun 06, 2019 at 08:03:27AM +, Jan Glauber wrote: > > > On Wed, Jun 05, 2019 at 01:16:46PM -0700, Linus Torvalds wrote: > > > > On Wed, Jun 5, 2019 at 6:49 AM Jan Glauber wrote: > > > > > > > > > > Add an upper bound to the loop to force the fallback to spinlocks > > > > > after some time. A retry value of 100 should not impact any hardware > > > > > that does not have this issue. > > > > > > > > > > With the retry limit the performance of an open-close testcase > > > > > improved between 60-70% on ThunderX2. > > > > > > > > Btw, did you do any kind of performance analysis across different > > > > retry limit values? > > > > > > I tried 15/50/100/200/500, results were largely identical up to 100. > > > For SMT=4 a higher retry value might be better, but unless we can add a > > > sysctl value 100 looked like a good compromise to me. > > > > Perhaps I'm just getting confused pre-morning-coffee, but I thought the > > original complaint (and the reason for this patch even existing) was that > > when many CPUs were hammering the lockref then performance tanked? In which > > case, increasing the threshold as the number of CPUs increases seems > > counter-intuitive to me because it suggests that the larger the system, > > the harder we should try to make the cmpxchg work. > > For SMT=4 the top hit I see is queued_spin_lock_slowpath(). Maybe this is more > costly with more threads, so trying harder to use lockref-cmpxchg makes > the microbenchmark faster in that case? To clarify, with 224 threads & CPUs queued_spin_lock_slowpath is the top hit even without a retry limit in lockref. This could be unrelated to the lockref fallback, it looks like it's coming from the spinlock in: do_sys_open -> get_unused_fd_flags -> __alloc_fd --Jan
[PATCH 1/2] staging: rtl8723bs: rtw_os_recv_resource_alloc(): Change type
Remove assignment of the return value of rtw_os_recv_resource_alloc as
this assignment at the call site is never used.
Remove return statement from rtw_os_recv_resource_alloc() as its return
variable is never used.
Change the type of the function to void.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/core/rtw_recv.c | 2 +-
drivers/staging/rtl8723bs/include/recv_osdep.h | 2 +-
drivers/staging/rtl8723bs/os_dep/recv_linux.c | 6 +-
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c
b/drivers/staging/rtl8723bs/core/rtw_recv.c
index b9c9bba1a335..687ff3c6f09f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -67,7 +67,7 @@ sint _rtw_init_recv_priv(struct recv_priv *precvpriv, struct
adapter *padapter)
list_add_tail(&(precvframe->u.list),
&(precvpriv->free_recv_queue.queue));
- res = rtw_os_recv_resource_alloc(padapter, precvframe);
+ rtw_os_recv_resource_alloc(padapter, precvframe);
precvframe->u.hdr.len = 0;
diff --git a/drivers/staging/rtl8723bs/include/recv_osdep.h
b/drivers/staging/rtl8723bs/include/recv_osdep.h
index 6fea0e948271..0e1baf170cfb 100644
--- a/drivers/staging/rtl8723bs/include/recv_osdep.h
+++ b/drivers/staging/rtl8723bs/include/recv_osdep.h
@@ -22,7 +22,7 @@ int rtw_init_recv_priv(struct recv_priv *precvpriv, struct
adapter *padapter);
void rtw_free_recv_priv (struct recv_priv *precvpriv);
-int rtw_os_recv_resource_alloc(struct adapter *padapter, union recv_frame
*precvframe);
+void rtw_os_recv_resource_alloc(struct adapter *padapter, union recv_frame
*precvframe);
void rtw_os_recv_resource_free(struct recv_priv *precvpriv);
diff --git a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
index 67ec336264e5..45145efa3f68 100644
--- a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
@@ -21,13 +21,9 @@ void rtw_os_free_recvframe(union recv_frame *precvframe)
}
/* alloc os related resource in union recv_frame */
-int rtw_os_recv_resource_alloc(struct adapter *padapter, union recv_frame
*precvframe)
+void rtw_os_recv_resource_alloc(struct adapter *padapter, union recv_frame
*precvframe)
{
- int res = _SUCCESS;
-
precvframe->u.hdr.pkt_newalloc = precvframe->u.hdr.pkt = NULL;
-
- return res;
}
/* free os related resource in union recv_frame */
--
2.19.1
[PATCH 2/2] staging: rtl8723bs: rtw_os_recvbuf_resource_free(): Change type
Change return type of function rtw_os_recvbuf_resource_free to void as
its return value is never stored, checked or otherwise used.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/include/recv_osdep.h | 2 +-
drivers/staging/rtl8723bs/os_dep/recv_linux.c | 6 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/recv_osdep.h
b/drivers/staging/rtl8723bs/include/recv_osdep.h
index 0e1baf170cfb..1056f615d0f9 100644
--- a/drivers/staging/rtl8723bs/include/recv_osdep.h
+++ b/drivers/staging/rtl8723bs/include/recv_osdep.h
@@ -29,7 +29,7 @@ void rtw_os_recv_resource_free(struct recv_priv *precvpriv);
void rtw_os_free_recvframe(union recv_frame *precvframe);
-int rtw_os_recvbuf_resource_free(struct adapter *padapter, struct recv_buf
*precvbuf);
+void rtw_os_recvbuf_resource_free(struct adapter *padapter, struct recv_buf
*precvbuf);
_pkt *rtw_os_alloc_msdu_pkt(union recv_frame *prframe, u16 nSubframe_Length,
u8 *pdata);
void rtw_os_recv_indicate_pkt(struct adapter *padapter, _pkt *pkt, struct
rx_pkt_attrib *pattrib);
diff --git a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
index 45145efa3f68..3fe9c2255edd 100644
--- a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
@@ -46,16 +46,12 @@ void rtw_os_recv_resource_free(struct recv_priv *precvpriv)
}
/* free os related resource in struct recv_buf */
-int rtw_os_recvbuf_resource_free(struct adapter *padapter, struct recv_buf
*precvbuf)
+void rtw_os_recvbuf_resource_free(struct adapter *padapter, struct recv_buf
*precvbuf)
{
- int ret = _SUCCESS;
-
if (precvbuf->pskb)
{
dev_kfree_skb_any(precvbuf->pskb);
}
- return ret;
-
}
_pkt *rtw_os_alloc_msdu_pkt(union recv_frame *prframe, u16 nSubframe_Length,
u8 *pdata)
--
2.19.1
[PATCH] staging: rtl8723bs: hal: sdio_halinit.c: Remove variables
Remove the variables RegRATR and RegRRSR as they are never used after
initialisation and assignment.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/sdio_halinit.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 3c65a9c02bbd..55d21aa52e62 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -614,7 +614,6 @@ static void _InitOperationMode(struct adapter *padapter)
struct hal_com_data *pHalData;
struct mlme_ext_priv *pmlmeext;
u8 regBwOpMode = 0;
- u32 regRATR = 0, regRRSR = 0;
pHalData = GET_HAL_DATA(padapter);
pmlmeext = &padapter->mlmeextpriv;
@@ -626,34 +625,24 @@ static void _InitOperationMode(struct adapter *padapter)
switch (pmlmeext->cur_wireless_mode) {
case WIRELESS_MODE_B:
regBwOpMode = BW_OPMODE_20MHZ;
- regRATR = RATE_ALL_CCK;
- regRRSR = RATE_ALL_CCK;
break;
case WIRELESS_MODE_A:
/* RT_ASSERT(false, ("Error wireless a mode\n")); */
break;
case WIRELESS_MODE_G:
regBwOpMode = BW_OPMODE_20MHZ;
- regRATR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
- regRRSR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
break;
case WIRELESS_MODE_AUTO:
regBwOpMode = BW_OPMODE_20MHZ;
- regRATR = RATE_ALL_CCK | RATE_ALL_OFDM_AG | RATE_ALL_OFDM_1SS |
RATE_ALL_OFDM_2SS;
- regRRSR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
break;
case WIRELESS_MODE_N_24G:
/* It support CCK rate by default. */
/* CCK rate will be filtered out only when associated AP does
not support it. */
regBwOpMode = BW_OPMODE_20MHZ;
- regRATR = RATE_ALL_CCK | RATE_ALL_OFDM_AG | RATE_ALL_OFDM_1SS |
RATE_ALL_OFDM_2SS;
- regRRSR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
break;
case WIRELESS_MODE_N_5G:
/* RT_ASSERT(false, ("Error wireless mode")); */
regBwOpMode = BW_OPMODE_5G;
- regRATR = RATE_ALL_OFDM_AG | RATE_ALL_OFDM_1SS |
RATE_ALL_OFDM_2SS;
- regRRSR = RATE_ALL_OFDM_AG;
break;
default: /* for MacOSX compiler warning. */
--
2.19.1
[PATCH] staging: rtl8723bs: hal: hal_btcoex.c: Remove variable
Remove variable and use the values directly.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/hal_btcoex.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
index 6caddd7834a1..aebe8b8977ad 100644
--- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
+++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
@@ -362,15 +362,9 @@ static u32 halbtcoutsrc_GetBtPatchVer(PBTC_COEXIST
pBtCoexist)
static s32 halbtcoutsrc_GetWifiRssi(struct adapter *padapter)
{
- struct hal_com_data *pHalData;
- s32 UndecoratedSmoothedPWDB = 0;
-
-
- pHalData = GET_HAL_DATA(padapter);
-
- UndecoratedSmoothedPWDB =
pHalData->dmpriv.EntryMinUndecoratedSmoothedPWDB;
+ struct hal_com_data *pHalData = GET_HAL_DATA(padapter);
- return UndecoratedSmoothedPWDB;
+ return pHalData->dmpriv.EntryMinUndecoratedSmoothedPWDB;
}
static u8 halbtcoutsrc_GetWifiScanAPNum(struct adapter *padapter)
--
2.19.1
[PATCH] staging: rtl8723bs: core: Remove variable priority
Remove local variable change_priority, as it takes the value of the
argument priority; as both of these variables are of type u8, priority
can be modified without changing the value of its copy at the call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index 53146ec62ae9..b5dcb78fb4f4 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -625,13 +625,11 @@ static s32 update_attrib_sec_info(struct adapter
*padapter, struct pkt_attrib *p
u8 qos_acm(u8 acm_mask, u8 priority)
{
- u8 change_priority = priority;
-
switch (priority) {
case 0:
case 3:
if (acm_mask & BIT(1))
- change_priority = 1;
+ priority = 1;
break;
case 1:
case 2:
@@ -639,19 +637,19 @@ u8 qos_acm(u8 acm_mask, u8 priority)
case 4:
case 5:
if (acm_mask & BIT(2))
- change_priority = 0;
+ priority = 0;
break;
case 6:
case 7:
if (acm_mask & BIT(3))
- change_priority = 5;
+ priority = 5;
break;
default:
DBG_871X("qos_acm(): invalid pattrib->priority: %d!!!\n",
priority);
break;
}
- return change_priority;
+ return priority;
}
static void set_qos(struct pkt_file *ppktfile, struct pkt_attrib *pattrib)
--
2.19.1
RE: [PATCH v8 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
Hi Sakari, Thanks for reviewing. > -Original Message- > From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com] > Sent: Wednesday, June 05, 2019 6:19 PM > To: Vishal Sagar > Cc: Hyun Kwon ; laurent.pinch...@ideasonboard.com; > mche...@kernel.org; robh...@kernel.org; mark.rutl...@arm.com; Michal > Simek ; linux-me...@vger.kernel.org; > devicet...@vger.kernel.org; hans.verk...@cisco.com; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Dinesh Kumar > ; Sandip Kothari ; Luca Ceresoli > ; Jacopo Mondi > Subject: Re: [PATCH v8 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx > Subsystem driver > > EXTERNAL EMAIL > > Hi Vishal, > > On Mon, Jun 03, 2019 at 03:29:31PM +0530, Vishal Sagar wrote: > > The Xilinx MIPI CSI-2 Rx Subsystem soft IP is used to capture images > > from MIPI CSI-2 camera sensors and output AXI4-Stream video data ready > > for image processing. Please refer to PG232 for details. > > > > The driver is used to set the number of active lanes, if enabled > > in hardware. The CSI2 Rx controller filters out all packets except for > > the packets with data type fixed in hardware. RAW8 packets are always > > allowed to pass through. > > > > It is also used to setup and handle interrupts and enable the core. It > > logs all the events in respective counters between streaming on and off. > > > > The driver supports only the video format bridge enabled configuration. > > Some data types like YUV 422 10bpc, RAW16, RAW20 are supported when > the > > CSI v2.0 feature is enabled in design. When the VCX feature is enabled, > > the maximum number of virtual channels becomes 16 from 4. > > > > Signed-off-by: Vishal Sagar > > Reviewed-by: Hyun Kwon > > --- > > v8 > > - Use clk_bulk* APIs > > - Add gpio reset for asserting video_aresetn when stream line buffer occurs > > - Removed short packet related events and irq handling > > - V4L2_EVENT_XLNXCSIRX_SPKT and V4L2_EVENT_XLNXCSIRX_SPKT_OVF > removed > > - Removed frame counter control > V4L2_CID_XILINX_MIPICSISS_FRAME_COUNTER > > and xcsi2rxss_g_volatile_ctrl() > > - Minor formatting fixes > > > > v7 > > - No change > > > > v6 > > - No change > > > > v5 > > - Removed bayer and updated related parts like set default format based > > on Luca Cersoli's comments. > > - Added correct YUV422 10bpc media bus format > > > > v4 > > - Removed irq member from core structure > > - Consolidated IP config prints in xcsi2rxss_log_ipconfig() > > - Return -EINVAL in case of invalid ioctl > > - Code formatting > > - Added reviewed by Hyun Kwon > > > > v3 > > - Fixed comments given by Hyun. > > - Removed DPHY 200 MHz clock. This will be controlled by DPHY driver > > - Minor code formatting > > - en_csi_v20 and vfb members removed from struct and made local to dt > parsing > > - lock description updated > > - changed to ratelimited type for all dev prints in irq handler > > - Removed YUV 422 10bpc media format > > > > v2 > > - Fixed comments given by Hyun and Sakari. > > - Made all bitmask using BIT() and GENMASK() > > - Removed unused definitions > > - Removed DPHY access. This will be done by separate DPHY PHY driver. > > - Added support for CSI v2.0 for YUV 422 10bpc, RAW16, RAW20 and extra > > virtual channels > > - Fixed the ports as sink and source > > - Now use the v4l2fwnode API to get number of data-lanes > > - Added clock framework support > > - Removed the close() function > > - updated the set format function > > - support only VFB enabled configuration > > > > drivers/media/platform/xilinx/Kconfig | 10 + > > drivers/media/platform/xilinx/Makefile |1 + > > drivers/media/platform/xilinx/xilinx-csi2rxss.c | 1406 > +++ > > include/uapi/linux/xilinx-v4l2-controls.h | 12 + > > include/uapi/linux/xilinx-v4l2-events.h | 21 + > > 5 files changed, 1450 insertions(+) > > create mode 100644 drivers/media/platform/xilinx/xilinx-csi2rxss.c > > create mode 100644 include/uapi/linux/xilinx-v4l2-events.h > > > > diff --git a/drivers/media/platform/xilinx/Kconfig > b/drivers/media/platform/xilinx/Kconfig > > index a2773ad..cd1a0fd 100644 > > --- a/drivers/media/platform/xilinx/Kconfig > > +++ b/drivers/media/platform/xilinx/Kconfig > > @@ -10,6 +10,16 @@ config VIDEO_XILINX > > > > if VIDEO_XILINX > > > > +config VIDEO_XILINX_CSI2RXSS > > + tristate "Xilinx CSI2 Rx Subsystem" > > I think you'll need at least these dependencies: > > VIDEO_V4L2 > VIDEO_V4L2_SUBDEV_API > > And select: > VIDEO_V4L2_FWNODE > Ok. I missed to add "depends on VIDEO_XILINX" here. This should take care of the above dependencies. > > + help > > + Driver for Xilinx MIPI CSI2 Rx Subsystem. This is a V4L sub-device > > + based driver that takes input from CSI2 Tx source and converts > > + it into an AXI4-Stream. The subsystem comprises of a CSI2 Rx > > + controller, DPHY, an optional I2C controller and a Video Format > > + Bridge. T
[PATCH] staging: rtl8723bs: hal: rtl8723b_cmd.c: Remove variables
Remove variables that are declared and initialised but never used.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
index fe3891106a6d..e001d302b34c 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
@@ -674,10 +674,6 @@ static void ConstructProbeReq(struct adapter *padapter, u8
*pframe, u32 *pLength
u32 pktlen;
unsigned char *mac;
unsigned char bssrate[NumRates];
- struct xmit_priv *pxmitpriv = &(padapter->xmitpriv);
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
- struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
- struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
int bssrate_len = 0;
u8 bc_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
@@ -1288,8 +1284,6 @@ static void rtl8723b_set_FwAOACGlobalInfo_Cmd(struct
adapter *padapter, u8 grou
static void rtl8723b_set_FwScanOffloadInfo_cmd(struct adapter *padapter,
PRSVDPAGE_LOC rsvdpageloc, u8 enable)
{
u8 u1H2CScanOffloadInfoParm[H2C_SCAN_OFFLOAD_CTRL_LEN] = {0};
- u8 res = 0, count = 0;
- struct pwrctrl_priv *pwrpriv = adapter_to_pwrctl(padapter);
DBG_871X("%s: loc_probe_packet:%d, loc_scan_info: %d
loc_ssid_info:%d\n",
__func__, rsvdpageloc->LocProbePacket,
rsvdpageloc->LocScanInfo, rsvdpageloc->LocSSIDInfo);
--
2.19.1
[PATCH] staging: rtl8723bs: core: rtw_mlme_ext.c: Remove unused variables
Remove variables that are declared and assigned values but not otherwise
used.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 65e8cba7feba..5f0b20038a28 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -6771,10 +6771,6 @@ int rtw_get_ch_setting_union(struct adapter *adapter, u8
*ch, u8 *bw, u8 *offset
{
struct dvobj_priv *dvobj = adapter_to_dvobj(adapter);
struct adapter *iface;
- struct mlme_ext_priv *mlmeext;
- u8 ch_ret = 0;
- u8 bw_ret = CHANNEL_WIDTH_20;
- u8 offset_ret = HAL_PRIME_CHNL_OFFSET_DONT_CARE;
if (ch)
*ch = 0;
@@ -6784,15 +6780,10 @@ int rtw_get_ch_setting_union(struct adapter *adapter,
u8 *ch, u8 *bw, u8 *offset
*offset = HAL_PRIME_CHNL_OFFSET_DONT_CARE;
iface = dvobj->padapters;
- mlmeext = &iface->mlmeextpriv;
if (!check_fwstate(&iface->mlmepriv, _FW_LINKED|_FW_UNDER_LINKING))
return 0;
- ch_ret = mlmeext->cur_channel;
- bw_ret = mlmeext->cur_bwmode;
- offset_ret = mlmeext->cur_ch_offset;
-
return 1;
}
--
2.19.1
Re: [PATCH] [RFC] dmaengine: add fifo_size member
Jon, On 06/06/2019 15.37, Jon Hunter wrote: >> Looking at the drivers/dma/tegra210-adma.c for the >> TEGRA*_FIFO_CTRL_DEFAULT definition it is still not clear where the >> remote FIFO size would fit. >> There are fields for overflow and starvation(?) thresholds and TX/RX >> size (assuming word length, 3 == 32bits?). > > The TX/RX size are the FIFO size. So 3 equates to a FIFO size of 3 * 64 > bytes. > >> Both threshold is set to one, so I assume currently ADMA is >> pushing/pulling data word by word. > > That's different. That indicates thresholds when transfers start. > >> Not sure what the burst size is used for, my guess would be that it is >> used on the memory (DDR) side for optimized, more efficient accesses? > > That is the actual burst size. > >> My guess is that the threshold values are the counter limits, if the DMA >> request counter reaches it then ADMA would do a threshold limit worth of >> push/pull to ADMAIF. >> Or there is another register where the remote FIFO size can be written >> and ADMA is counting back from there until it reaches the threshold (and >> pushes/pulling again threshold amount of data) so it keeps the FIFO >> filled with at least threshold amount of data? >> >> I think in both cases the threshold would be the maxburst. >> >> I suppose you have the patch for adma on how to use the fifo_size >> parameter? That would help understand what you are trying to achieve better. > > Its quite simple, we would just use the FIFO size to set the fields > TEGRAXXX_ADMA_CH_FIFO_CTRL_TXSIZE/RXSIZE in the > TEGRAXXX_ADMA_CH_FIFO_CTRL register. That's all. Hrm, it is still not clear how all of these fits together. What happens if you configure ADMA side: BURST = 10 TX/RXSIZE = 100 (100 * 64 bytes?) /* FIFO_SIZE? */ *THRES = 5 And if you change the *THRES to 10? And if you change the TX/RXSIZE to 50 (50 * 64 bytes?) And if you change the BURST to 5? In other words what is the relation between all of these? There must be a rule and constraints around these and if we do really need a new parameter for ADMA's FIFO_SIZE I'd like it to be defined in a generic way so others could benefit without 'misusing' a fifo_size parameter for similar, but not quite fifo_size information. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
