Re: [RFC] regmap-irq: add "main register" and level-irq support
On Wed, Dec 05, 2018 at 10:22:51AM +0200, Matti Vaittinen wrote: > On Tue, Dec 04, 2018 at 05:21:37PM +, Mark Brown wrote: > > On Fri, Nov 30, 2018 at 10:59:08AM +0200, Matti Vaittinen wrote: > > This sounds exactly like the wm831x which uses cascaded irqchips for > > this, though not regmap-irq. > Yep. I guess I could do cascaded chips - but I would like to use the > regmap-irq for this driver. Maybe we could change regmap-irq so that it > would be possible to not give the DT node from regmap for this chip? > This was actually my first thought - but then I felt that having two irq > chips for one device is a bit hacky - and hence I decided to see how > regmap-irq could be changed to support the 'main irq status' register > usage. I think this 'main register' setup is pretty common design. I'm not sure I see it as particularly hacky - it's using features that the frameworks provide to do the fan out, that just seems like making use of existing framework features. > > I suspect the idiomatic way to handle this in DT is to make DT nodes > > (and devices) for the subfunction interrupt controllers and expose the > > internal structure of the chip to the DT. > Yes. This would be one approach - but I am not sure how DT guys see > this. I may be wrong but I have a feeling Rob prefers having only one DT > node describing single device. But for me it would make sense to have > own node for GPIO - especially because the GPIO is only IRQ controller Well, it kind of depends if you see the sub-interrupt controllers as independent devices or not (at the hardware level they will be). > which really is visible outside the chip. But here we still hit the same > problem if we want to use regmap-irq. Regmap-irq still knows only the > i2c device DT node. Currently there is no way to tell regmap-irq to use > the sub-node. If they're full subdevices you'd be pointing at the relevant platform device anyway. > > This does make some sense as > > the individual interrupt controllers within the chip are clearly > > reusable IP blocks though it means that the chip starts looking a bit > > weird externally so perhaps that's not ideal and your suggestion makes > > sense. > So I take this as a suggestion to continue tinkering with the 'main irq > register support'. Or how do you see my suggestion of making iot > possible to instruct the regmap-irq to not use DT for 'main irq > controller'? Then we could probably do cascaded controllers where only > the controller handling the externally visible 'sub-irqs' would be > bound to DT? The pitfall here is case where more than one sub-irq > controllers needs to be exposed to other devices. In that sense the > 'main irq thing' would have better 'case coverage' =) (Wow, what a fancy > words, maybe I am turning into a manager here :p ) I'm on the fence about the main controller idea. > > > + * @main_status: Base main status register address. For chips which have > > > + *interrupts arranged in separate sub-irq blocks with > > > own IRQ > > > + *registers and which have a main IRQ registers > > > indicating > > > + *sub-irq blocks with unhandled interrupts. For such > > > chips fill > > > + *sub-irq register information in status_base, mask_base > > > and > > > + *ack_base. > > > + * @sub_reg_offsets: arrays of mappings from main register bits to sub > > > irq > > > + *registers. First item in array describes the registers > > > + *for first main status bit. Second array for second bit > > > etc. > > > + *Offset is given as sub register status offset to > > > status_base. > > > + *Should contain num_regs arrays. Can be provided for > > > chips with > > > + *more complex mapping than 1.st bit to 1.st sub-reg, > > > 2.nd bit to > > > + *2.nd sub-reg, ... > > This interface feels a little awkward in that we define the sub > > interrupts in this separate array and require them all to be in separate > > single registers which probably won't be true in general (IIRC it wasn't > > how the wm831x worked). > So my implementation here was just the simplest solution to 'glue' the > main status register on top of existing implementation. If we do it this > way, then the 'main status register' is completely optional - chip would > work just fine even without the 'main register' - main register only > saves some reads as subregisters with no irqs can be left unread. But > you are correct - this only supports limited amount of HWs. Many chips I > have seen (prior to the one I am now working with) actually require > acking also the main status register. They also may support masking the > main status register. But I guess trying to support all such cases would > make the regmap-irq really complex and hard to understand. Right, it's that sort of thing that makes me want to just cascade the interrupt controllers -
Re: [PATCH v6 00/14] block: always associate blkg and refcount cleanup
On 12/5/18 10:10 AM, Dennis Zhou wrote: > Hi everyone, > > This is a minor update addressing the feedback from Mike and Josef. > > v6: > 0005: Address Mike's feedback for the flush bio comment. > 0006: Add a WARN_ONCE() for blkg fallback suggested by Josef. Thanks Dennis, applied for 4.21. -- Jens Axboe
[driver-core PATCH v8 0/9] Add NUMA aware async_schedule calls
This patch set provides functionality that will help to improve the locality of the async_schedule calls used to provide deferred initialization. This patch set originally started out focused on just the one call to async_schedule_domain in the nvdimm tree that was being used to defer the device_add call however after doing some digging I realized the scope of this was much broader than I had originally planned. As such I went through and reworked the underlying infrastructure down to replacing the queue_work call itself with a function of my own and opted to try and provide a NUMA aware solution that would work for a broader audience. In addition I have added several tweaks and/or clean-ups to the front of the patch set. Patches 1 through 4 address a number of issues that actually were causing the existing async_schedule calls to not show the performance that they could due to either not scaling on a per device basis, or due to issues that could result in a potential deadlock. For example, patch 4 addresses the fact that we were calling async_schedule once per driver instead of once per device, and as a result we would have still ended up with devices being probed on a non-local node without addressing this first. RFC->v1: Dropped nvdimm patch to submit later. It relies on code in libnvdimm development tree. Simplified queue_work_near to just convert node into a CPU. Split up drivers core and PM core patches. v1->v2: Renamed queue_work_near to queue_work_node Added WARN_ON_ONCE if we use queue_work_node with per-cpu workqueue v2->v3: Added Acked-by for queue_work_node patch Continued rename from _near to _node to be consistent with queue_work_node Renamed async_schedule_near_domain to async_schedule_node_domain Renamed async_schedule_near to async_schedule_node Added kerneldoc for new async_schedule_XXX functions Updated patch description for patch 4 to include data on potential gains v3->v4 Added patch to consolidate use of need_parent_lock Make asynchronous driver probing explicit about use of drvdata v4->v5 Added patch to move async_synchronize_full to address deadlock Added bit async_probe to act as mutex for probe/remove calls Added back nvdimm patch as code it relies on is now in Linus's tree Incorporated review comments on parent & device locking consolidation Rebased on latest linux-next v5->v6: Drop the "This patch" or "This change" from start of patch descriptions. Drop unnecessary parenthesis in first patch Use same wording for "selecting a CPU" in comments added in first patch Added kernel documentation for async_probe member of device Fixed up comments for async_schedule calls in patch 2 Moved code related setting async driver out of device.h and into dd.c Added Reviewed-by for several patches v6->v7: Fixed typo which had kernel doc refer to "lock" when I meant "unlock" Dropped "bool X:1" to "u8 X:1" from patch description Added async_driver to device_private structure to store driver Dropped unecessary code shuffle from async_probe patch Reordered patches to move fixes up to front Added Reviewed-by for several patches Updated cover page and patch descriptions throughout the set v7->v8: Replaced async_probe value with dead, only apply dead in device_del Dropped Reviewed-by from patch 2 due to significant changes Added Reviewed-by for patches reviewed by Luis Chamberlain --- Alexander Duyck (9): driver core: Move async_synchronize_full call driver core: Establish order of operations for device_add and device_del via bitflag device core: Consolidate locking and unlocking of parent and device driver core: Probe devices asynchronously instead of the driver workqueue: Provide queue_work_node to queue work near a given NUMA node async: Add support for queueing on specific NUMA node driver core: Attach devices on CPU local to device node PM core: Use new async_schedule_dev command libnvdimm: Schedule device registration on node local to the device drivers/base/base.h |4 + drivers/base/bus.c| 46 ++ drivers/base/core.c | 11 +++ drivers/base/dd.c | 152 ++--- drivers/base/power/main.c | 12 ++-- drivers/nvdimm/bus.c | 11 ++- include/linux/async.h | 82 +++- include/linux/device.h|5 + include/linux/workqueue.h |2 + kernel/async.c| 53 +--- kernel/workqueue.c| 84 + 11 files changed, 362 insertions(+), 100 deletions(-) --
Re: [PATCH v6 07/10] clk: rk808: use managed version of of_provider registration
Quoting Matti Vaittinen (2018-12-04 03:38:03) > Simplify clean-up for rk808 by using managed version of of_provider > registration. > > Signed-off-by: Matti Vaittinen > --- Applied to clk-next
[driver-core PATCH v8 1/9] driver core: Move async_synchronize_full call
Move the async_synchronize_full call out of __device_release_driver and
into driver_detach.
The idea behind this is that the async_synchronize_full call will only
guarantee that any existing async operations are flushed. This doesn't do
anything to guarantee that a hotplug event that may occur while we are
doing the release of the driver will not be asynchronously scheduled.
By moving this into the driver_detach path we can avoid potential deadlocks
as we aren't holding the device lock at this point and we should not have
the driver we want to flush loaded so the flush will take care of any
asynchronous events the driver we are detaching might have scheduled.
Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for
drivers")
Reviewed-by: Luis Chamberlain
Reviewed-by: Bart Van Assche
Reviewed-by: Dan Williams
Signed-off-by: Alexander Duyck
---
drivers/base/dd.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 689ac9dc6d81..88713f182086 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -931,9 +931,6 @@ static void __device_release_driver(struct device *dev,
struct device *parent)
drv = dev->driver;
if (drv) {
- if (driver_allows_async_probing(drv))
- async_synchronize_full();
-
while (device_links_busy(dev)) {
device_unlock(dev);
if (parent)
@@ -1039,6 +1036,9 @@ void driver_detach(struct device_driver *drv)
struct device_private *dev_prv;
struct device *dev;
+ if (driver_allows_async_probing(drv))
+ async_synchronize_full();
+
for (;;) {
spin_lock(&drv->p->klist_devices.k_lock);
if (list_empty(&drv->p->klist_devices.k_list)) {
[driver-core PATCH v8 8/9] PM core: Use new async_schedule_dev command
Use the device specific version of the async_schedule commands to defer
various tasks related to power management. By doing this we should see a
slight improvement in performance as any device that is sensitive to
latency/locality in the setup will now be initializing on the node closest
to the device.
Reviewed-by: Dan Williams
Reviewed-by: Bart Van Assche
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Alexander Duyck
---
drivers/base/power/main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index a690fd400260..ebb8b61b52e9 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -726,7 +726,7 @@ void dpm_noirq_resume_devices(pm_message_t state)
reinit_completion(&dev->power.completion);
if (is_async(dev)) {
get_device(dev);
- async_schedule(async_resume_noirq, dev);
+ async_schedule_dev(async_resume_noirq, dev);
}
}
@@ -883,7 +883,7 @@ void dpm_resume_early(pm_message_t state)
reinit_completion(&dev->power.completion);
if (is_async(dev)) {
get_device(dev);
- async_schedule(async_resume_early, dev);
+ async_schedule_dev(async_resume_early, dev);
}
}
@@ -1047,7 +1047,7 @@ void dpm_resume(pm_message_t state)
reinit_completion(&dev->power.completion);
if (is_async(dev)) {
get_device(dev);
- async_schedule(async_resume, dev);
+ async_schedule_dev(async_resume, dev);
}
}
@@ -1366,7 +1366,7 @@ static int device_suspend_noirq(struct device *dev)
if (is_async(dev)) {
get_device(dev);
- async_schedule(async_suspend_noirq, dev);
+ async_schedule_dev(async_suspend_noirq, dev);
return 0;
}
return __device_suspend_noirq(dev, pm_transition, false);
@@ -1569,7 +1569,7 @@ static int device_suspend_late(struct device *dev)
if (is_async(dev)) {
get_device(dev);
- async_schedule(async_suspend_late, dev);
+ async_schedule_dev(async_suspend_late, dev);
return 0;
}
@@ -1833,7 +1833,7 @@ static int device_suspend(struct device *dev)
if (is_async(dev)) {
get_device(dev);
- async_schedule(async_suspend, dev);
+ async_schedule_dev(async_suspend, dev);
return 0;
}
Re: [PATCH v3 5/5] clk: samsung: exynos5433: add imem clocks
On 12/5/18 17:08, Stephen Boyd wrote:
> Quoting Sylwester Nawrocki (2018-12-05 02:57:32)
>> On 12/4/18 19:40, Stephen Boyd wrote:
>>> Quoting Kamil Konieczny (2018-12-04 08:52:48)
+
+static const unsigned long imem_clk_regs[] __initconst = {
[...]
+};
+
+static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
+ /* ENABLE_ACLK_IMEM */
+ GATE(CLK_ACLK_AXI2AHB_IMEMH, "aclk_axi2ahb_imemh", "aclk_imem_200",
+ ENABLE_ACLK_IMEM, 24, 0, 0),
>>
>> I don't think that clock will ever need to be disabled/enabled, so I would
>> drop this definition. The clock will remain in its default state after reset
>> (enabled).
>>
+ GATE(CLK_ACLK_AXIDS_SROMC, "aclk_axids_sromc", "aclk_imem_200",
+ ENABLE_ACLK_IMEM, 23, CLK_IGNORE_UNUSED, 0),
>>>
>>> Why is there so much use of CLK_IGNORE_UNUSED in this file?
>>
>> I suppose CLK_IGNORE_UNUSED is needed because there is no drivers that
>> would enable required clocks. For some clocks the flag could probably
>> indeed just be omitted, e.g. SLIMSSS clocks.
>>
>> I'm inclined to just define clocks that we are confident about and which
>> are needed now. i.e. the SSS IP block clocks. So in include/dt-bindings/
>> clock/exynos5433.h we would have something like:
>
> Agreed, it doesn't make much sense to add clk support for clks that
> you'll never need to modify one way or the other.
>
>>
>> +/* CMU_IMEM */
>> +#define CLK_ACLK_SSS 1
>> +#define CLK_PCLK_SSS 40
>>
>> +#define IMEM_NR_CLK41
>>
>> The other clocks could be added later as needed by someone who has
>> detailed knowledge about respective peripheral blocks.
>>
>
> The slow addition of new clks to the binding header file makes for an
> integration problem, so can we try to expose any clks that we know about
> now as defines and make them not work if the driver isn't implementing
> support for those clks? That way the binding is not changing but the
> implementation can decide to support or not support certain clks.
That makes a lot of sense to me. Then all we have to do now is to drop
some of the entries in the imem_gate_clks array above.
--
Regards,
Sylwester
Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
- On Nov 26, 2018, at 12:07 PM, Rich Felker dal...@libc.org wrote: > On Mon, Nov 26, 2018 at 11:30:51AM -0500, Mathieu Desnoyers wrote: >> - On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers >> mathieu.desnoy...@efficios.com wrote: >> >> > - On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote: >> > >> >> * Mathieu Desnoyers: >> >> >> >>> Using a "weak" symbol in early adopter libraries is important, so they >> >>> can be loaded together into the same process without causing loader >> >>> errors due to many definitions of the same strong symbol. >> >> >> >> This is not how ELF dynamic linking works. If the symbol name is the >> >> same, one definition interposes the others. >> >> >> >> You need to ensure that the symbol has the same size everywhere, though. >> >> There are some tricky interactions with symbol versions, too. (The >> >> interposing libraries must not use symbol versioning.) >> > >> > I was under the impression that loading the same strong symbol into an >> > application multiple times would cause some kind of warning if non-weak. I >> > did >> > some testing to figure out which case I remembered would cause this. >> > >> > When compiling with "-fno-common", dynamic and static linking work fine, >> > but >> > trying to add multiple instances of a given symbol into a single object >> > fails >> > with: >> > >> > /tmp/ccSakXZV.o:(.bss+0x0): multiple definition of `a' >> > /tmp/ccQBJBOo.o:(.bss+0x0): first defined here >> > >> > Even if the symbol has the same size. >> > >> > So considering that we don't care about compiling into a single object >> > here, >> > and only care about static and dynamic linking of libraries, indeed the >> > "weak" >> > symbol is not useful. >> > >> > So let's make __rseq_abi and __rseq_refcount strong symbols then ? >> >> Actually, looking into ld(1) --warn-common, it looks like "weak" would be >> cleaner >> after all, especially for __rseq_abi which we needs to be initialized to a >> specific >> value, which is therefore not a common symbol. >> >> " --warn-common >>Warn when a common symbol is combined with another common symbol >> or with a >>symbol definition. Unix >>linkers allow this somewhat sloppy practice, but linkers on some >> other operating >>systems do not. >>This option allows you to find potential problems from combining >> global symbols. >>Unfortunately, >>some C libraries use this practice, so you may get some warnings >> about symbols >>in the libraries as >>well as in your programs." >> >> Thoughts ? > > AFAIK this has nothing to do with dynamic linking. Reading through the ELF specification, it seems to imply that "weak" only affects the link editor behavior when combining relocatable objects, not the behavior of the dynamic linker. Is that what you refer to when you say "weak" has nothing to do with dynamic linking ? If that interpretation is correct, then indeed I should remove the "weak" from the __rseq_abi and __rseq_refcount. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH -next] coresight: stm: remove set but not used variable 'res_size'
On Sat, 1 Dec 2018 at 01:31, YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/hwtracing/coresight/coresight-stm.c: In function 'stm_probe':
> drivers/hwtracing/coresight/coresight-stm.c:796:9: warning:
> variable 'res_size' set but not used [-Wunused-but-set-variable]
>
> It never used since introduction in commit
> 237483aa5cf4 ("coresight: stm: adding driver for CoreSight STM component")
>
> Signed-off-by: YueHaibing
Applied - thanks,
Mathieu
> ---
> drivers/hwtracing/coresight/coresight-stm.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c
> b/drivers/hwtracing/coresight/coresight-stm.c
> index ef339ff..f07825d 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -793,7 +793,7 @@ static int stm_probe(struct amba_device *adev, const
> struct amba_id *id)
> struct stm_drvdata *drvdata;
> struct resource *res = &adev->res;
> struct resource ch_res;
> - size_t res_size, bitmap_size;
> + size_t bitmap_size;
> struct coresight_desc desc = { 0 };
> struct device_node *np = adev->dev.of_node;
>
> @@ -833,15 +833,11 @@ static int stm_probe(struct amba_device *adev, const
> struct amba_id *id)
>
> drvdata->write_bytes = stm_fundamental_data_size(drvdata);
>
> - if (boot_nr_channel) {
> + if (boot_nr_channel)
> drvdata->numsp = boot_nr_channel;
> - res_size = min((resource_size_t)(boot_nr_channel *
> - BYTES_PER_CHANNEL), resource_size(res));
> - } else {
> + else
> drvdata->numsp = stm_num_stimulus_port(drvdata);
> - res_size = min((resource_size_t)(drvdata->numsp *
> -BYTES_PER_CHANNEL), resource_size(res));
> - }
> +
> bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
>
> guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
>
>
>
Re: [PATCH 3/9] tools/lib/traceevent: Install trace-seq.h API header file
On Wed, Dec 05, 2018 at 12:03:34PM -0500, Steven Rostedt wrote: > On Wed, 5 Dec 2018 13:25:17 +0100 > Jiri Olsa wrote: > > > On Tue, Dec 04, 2018 at 02:41:45PM -0500, Steven Rostedt wrote: > > > On Tue, 4 Dec 2018 16:47:39 +0900 > > > Namhyung Kim wrote: > > > > > > > > > > > @@ -302,6 +302,7 @@ install_headers: > > > > > $(call QUIET_INSTALL, headers) \ > > > > > $(call > > > > > do_install,event-parse.h,$(prefix)/include/traceevent,644); \ > > > > > $(call > > > > > do_install,event-utils.h,$(prefix)/include/traceevent,644); \ > > > > > + $(call > > > > > do_install,trace-seq.h,$(prefix)/include/traceevent,644); \ > > > > > $(call > > > > > do_install,kbuffer.h,$(prefix)/include/traceevent,644) > > > > > > > > Do you still wanna have 'traceevent' directory prefix? I just > > > > sometimes feel a bit annoying to type it. ;-) > > > > > > I'd still want the separate directory for it. I'll probably have a > > > ftrace.h file added to this for ftrace specific code in the future. > > > > > > > > > > > Or you can rename it something like 'tep' or 'libtep' - and hopefully > > > > having only single header file to include.. > > > > > > > > > > Hmm, I wonder if we should just call the directory "trace"? > > > > hum, I think it should match the library name, like 'include/tep/' > > I was hoping to add other headers in this directly, like ftrace.h and > perf.h ;-) those are headers from trace-cmd? I guess we could have some common 'trace' related directory, but I think we should have some rules for placing files in there to avoid mayhem ;-) but I'd prefer to go with package related directories under include > > also we should change the plugin installation directory > > > > [jolsa@krava traceevent]$ rpm -ql perf | grep traceevent > > /usr/lib64/traceevent > > /usr/lib64/traceevent/plugins > > /usr/lib64/traceevent/plugins/plugin_cfg80211.so > > /usr/lib64/traceevent/plugins/plugin_function.so > > /usr/lib64/traceevent/plugins/plugin_hrtimer.so > > /usr/lib64/traceevent/plugins/plugin_jbd2.so > > /usr/lib64/traceevent/plugins/plugin_kmem.so > > /usr/lib64/traceevent/plugins/plugin_kvm.so > > /usr/lib64/traceevent/plugins/plugin_mac80211.so > > /usr/lib64/traceevent/plugins/plugin_sched_switch.so > > /usr/lib64/traceevent/plugins/plugin_scsi.so > > /usr/lib64/traceevent/plugins/plugin_xen.so > > Change it to tep? yes, that makes sense to me jirka
Re: [PATCH] Revert "clk: fix __clk_init_parent() for single parent clocks"
On Tue, 2018-12-04 at 23:54 -0800, Stephen Boyd wrote:
> Quoting Jerome Brunet (2018-12-04 11:51:17)
> > On Tue, 2018-12-04 at 10:05 -0800, Stephen Boyd wrote:
> > > Quoting Jerome Brunet (2018-12-04 08:32:57)
> > > > This reverts commit 2430a94d1e719b7b4af2a65b781a4c036eb22e64.
> > > >
> > > > From the original commit message:
> > > > It turned out a problem because there are some single-parent clocks
> > > > that implement .get_parent() callback and return non-zero index.
> > > > The SOCFPGA clock is the case; the commit broke the SOCFPGA boards.
> > > >
> > > > It is wrong for a clock to return an index >= num_parents. CCF checks
> > > > for this condition in clk_core_get_parent_by_index(). This function
> > > > sets
> > > > the parent to NULL if index is incoherent, which seems like the only
> > > > sane choice.
> > > >
> > > > commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single parent
> > > > clocks")
> > > > appears to be a work around installed in the core framework for a
> > > > problem
> > > > that is platform specific, and should probably be fixed in the
> > > > platform
> > > > code.
> > >
> > > Ouch. I see that I even pointed that out in 2016 but never got a reply
> > > or a fix patch[1].
> > >
> > > > Further more, it introduces a problem in a corner case of the mux
> > > > clock.
> > > > Take mux with multiple parents, but only one is known, the rest being
> > > > undocumented. The register reset has one of unknown parent set.
> > > >
> > > > Before commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single
> > > > parent clocks"):
> > > > * get_parent() is called, register is read and give an unknown index.
> > > >-> the mux is orphaned.
> > > > * a call to set_rate() will reparent the mux to the only known
> > > > parent.
> > > >
> > > > With commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single
> > > > parent
> > > > clocks"):
> > > > * the register is never read.
> > > > * parent is wrongly assumed to be the only known one.
> > > >As a consequence, all the calculation deriving from the mux will be
> > > >wrong
> > > > * Since we believe the only know parent to be set, set_parent() won't
> > > >ever be called and the register won't be set with the correct
> > > > value.
> > >
> > > Isn't this the broken bad case all over again? Why register a clk as a
> > > mux and then only say it has one parent?
> >
> > I understand it is a bit odd but as I explained it is a corner case.
> >
> > We are really trying to drive a mux here, applying a values will change
> > the
> > clock signal we get. Documentation being what it is, we only know one the
> > parent. The other parent could anything or maybe not connected at all, who
> > know. That is not the important part actually
> >
> > If such mux was already set to the known entry by default, it would be OK
> > to
> > ignore it. But if it is not, then we CCF to realise that and change the
> > setting accordingly.
> >
> > This the case of the 'ao_cts_cec' clock in the following patch:
> > https://lore.kernel.org/patchwork/patch/1021028/
> >
> > by default the value in the register is 0, but the only one that makes
> > sense
> > for us is 1.
>
> Ok. Thanks for the explanation. What do you do to fix this problem in
> the 'ao_cts_cec' clk implementation?
IMO, there is nothing to fix, the implementation is correct.
> Sounds like you just rely on
> clk_set_rate() to fix this all up for you when the consumer changes the
> rate?
To setup the rate as the customer expect, yes.
>
> If we have something that is default parented to something we're not
> telling the framework about for some reason then one solution would be
> to have some init code reparent the clk in hardware before registering
> it with the framework. Basically "fix up" the clk tree in hardware to be
> consistent with what software can reason about.
Should we really ? Something the framework does not know about is not
necessarily something wrong.
It would best if we could model the tree completly, but most of the time, we
just approximate it the best we can.
The framework just knows how to setup rates, it has no idea what rate needs to
be set or when - And I think it is best if does not make any assumption about
that.
Pushing it a bit, this unknown parent might important to the boot sequence.
How would you know when it is safe to change the setting ?
What would change it to ? It Seems obvious when there is only one known
parent, but what if there two ? which one do you pick ? Is it really the role
of CCF to make this kind of choice ?
>
> This also reminds me of some audio clks I've seen before where the
> default parent is some external pin and it can be reparented to an
> internal clk with clk_set_rate/parent. In that case, I think we forced
> the parent over to the internal clk before registering so that it would
> always get parented properly in the framework. Right now, this is going
> to cause problems for plans to pro
[PATCH v1] perf record: fix memory leak on AIO objects deallocation
Sending a part which was missed between v12 and v13 of the patch set
introducing AIO trace streaming for perf record mode.
The part is essential to avoid memory leakage during deallocation
of AIO related trace data buffers.
It is applied on top of acme perf/core repo.
Signed-off-by: Alexey Budankov
---
tools/perf/util/mmap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index ab30555d2afc..169d02973757 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -207,8 +207,18 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map,
struct mmap_params *mp)
static void perf_mmap__aio_munmap(struct perf_mmap *map)
{
+ int i;
+
+ for (i = 0; i < map->aio.nr_cblocks; ++i) {
+ if (map->aio.data[i])
+ zfree(&map->aio.data[i]);
+ }
if (map->aio.data)
zfree(&map->aio.data);
+ if (map->aio.cblocks)
+ zfree(&map->aio.cblocks);
+ if (map->aio.aiocb)
+ zfree(&map->aio.aiocb);
}
int perf_mmap__aio_push(struct perf_mmap *md, void *to, int idx,
Re: [PATCH 4/5] ARC: perf: fix description comment
On 12/5/18 9:06 AM, Eugeniy Paltsev wrote: > Fix description comment as this code doesn't belong only to > ARC700 anymore. > > Also while I'm at it, use SPDX License Identifier. > > Signed-off-by: Eugeniy Paltsev Maybe squash this into trivial cleanups 1/5 ? Acked-by: Vineet Gupta Thx, -Vineet
Re: [PATCH v2 1/7] arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE
On 05/12/2018 15:02, Will Deacon wrote:
On Fri, Nov 30, 2018 at 05:18:00PM +, Suzuki K Poulose wrote:
We have two entries for ARM64_WORKAROUND_CLEAN_CACHE capability :
1) ARM Errata 826319, 827319, 824069, 819472 on A53 r0p[012]
2) ARM Errata 819472 on A53 r0p[01]
Both have the same work around. Merge these entries to avoid
duplicate entries for a single capability. Add a new Kconfig
entry to control the "capability" entry to make it easier
to handle combinations of the CONFIGs.
Cc: Will Deacon
Cc: Andre Przywara
Cc: Mark Rutland
Signed-off-by: Suzuki K Poulose
---
arch/arm64/Kconfig | 7 +++
arch/arm64/include/asm/cputype.h | 1 +
arch/arm64/kernel/cpu_errata.c | 28
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 787d785..ad69e15 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -313,9 +313,13 @@ menu "Kernel Features"
menu "ARM errata workarounds via the alternatives framework"
+config ARM64_WORKAROUND_CLEAN_CACHE
+ def_bool n
+
config ARM64_ERRATUM_826319
bool "Cortex-A53: 826319: System might deadlock if a write cannot complete
until read data is accepted"
default y
+ select ARM64_WORKAROUND_CLEAN_CACHE
help
This option adds an alternative code sequence to work around ARM
erratum 826319 on Cortex-A53 parts up to r0p2 with an AMBA 4 ACE or
@@ -337,6 +341,7 @@ config ARM64_ERRATUM_826319
config ARM64_ERRATUM_827319
bool "Cortex-A53: 827319: Data cache clean instructions might cause
overlapping transactions to the interconnect"
default y
+ select ARM64_WORKAROUND_CLEAN_CACHE
help
This option adds an alternative code sequence to work around ARM
erratum 827319 on Cortex-A53 parts up to r0p2 with an AMBA 5 CHI
@@ -358,6 +363,7 @@ config ARM64_ERRATUM_827319
config ARM64_ERRATUM_824069
bool "Cortex-A53: 824069: Cache line might not be marked as clean after a
CleanShared snoop"
default y
+ select ARM64_WORKAROUND_CLEAN_CACHE
help
This option adds an alternative code sequence to work around ARM
erratum 824069 on Cortex-A53 parts up to r0p2 when it is connected
@@ -380,6 +386,7 @@ config ARM64_ERRATUM_824069
config ARM64_ERRATUM_819472
bool "Cortex-A53: 819472: Store exclusive instructions might cause data
corruption"
default y
+ select ARM64_WORKAROUND_CLEAN_CACHE
help
This option adds an alternative code sequence to work around ARM
erratum 819472 on Cortex-A53 parts up to r0p1 with an L2 cache
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 12f93e4d..2e26375 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -151,6 +151,7 @@ struct midr_range {
.rv_max = MIDR_CPU_VAR_REV(v_max, r_max), \
}
+#define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v, r_max)
What's the point of this macro?
That can be used to specify a set of MIDRs which has the same "variant" but a
range of "revisions". This is used for the A53 errata and also for the Cavium
errata in the following patch.
Suzuki
Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings
On Wed, Dec 05, 2018 at 05:25:26PM +0100, Ingo Molnar wrote:
> Also, preferably the prototype should be eliminated via proper ordering
> of functions from lower level to higher levels.
Well, that trampoline_handler() is special as we call it from inline asm
and I see Masami has marked it __visible etc.
So doing this below still builds and the trampoline_handler doesn't get
discarded but maybe there's a reason for it not being static.
Masami?
---
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 6480056d370f..308bf103cc73 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -66,8 +66,6 @@
#include "common.h"
-void *trampoline_handler(struct pt_regs *regs);
-
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -753,7 +751,7 @@ STACK_FRAME_NON_STANDARD(kretprobe_trampoline);
/*
* Called from kretprobe_trampoline
*/
-__visible __used void *trampoline_handler(struct pt_regs *regs)
+static __used void *trampoline_handler(struct pt_regs *regs)
{
struct kretprobe_instance *ri = NULL;
struct hlist_head *head, empty_rp;
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: edac driver injection of uncorrected errors & utils
On Wed, Dec 05, 2018 at 10:37:52AM -0600, Tracy Smith wrote: > This was very helpful. I'm glad. Can you do me a favor pls and not top-post when replying on a mailing list? Thx. > Tracing through the code, it doesn't do a panic > before Linux crashes from multi-bit errors because as York has > indicated, this type of memory controller doesn't limit the number of > errors. > > I do have a general question about single bit errors. The EDAC driver > corrects single bit errors by doing a scrub, is this correct? The > edac code does not do periodic scrubs, but I see scrubs when a > correctable error is found (edac_mc_scrub_block and edac_atomic_scrub > in edac_mc.c)? > > This is more directed toward York for layerscape. Yes, this is all platform-specific as you can see that some arches implement that atomic scrubbing thing. Also, not every driver sets mci->scrub_mode == SCRUB_SW_SRC in order to even do the scrubbing. HTH. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample
On Wed, 5 Dec 2018, Jiri Olsa wrote: > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote: > > On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote: > > > Hello, > > > > > > I was able to trigger another oops with the perf_fuzzer with current git. > > > > > > This is 4.20-rc5 after the fix for the very similar oops I previously > > > reported got committed. > > > > > > It seems to be pointing to the same location in the source as > > > before, I guess maybe triggered a different way? > > > > nice.. yep, looks the same > > > > > > > > Unfortunately this crash is not easily reproducible like the last one was. > > > > will check > > what model are hitting this on? Haswell. 6/60/3. While I can't deterministically trigger this, the fuzzer usually hits it within an hour or two. Is there any debug or printk messages I can add that would help figure out what's going on? Vince
[PATCH 12/14] blkcg: remove bio_disassociate_task()
Now that a bio only holds a blkg reference, so clean up is simply
putting back that reference. Remove bio_disassociate_task() as it just
calls bio_disassociate_blkg() and call the latter directly.
Signed-off-by: Dennis Zhou
Acked-by: Tejun Heo
Reviewed-by: Josef Bacik
---
block/bio.c | 11 +--
include/linux/bio.h | 2 --
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index ce1e512dca5a..7ec5316e6ecc 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -244,7 +244,7 @@ struct bio_vec *bvec_alloc(gfp_t gfp_mask, int nr, unsigned
long *idx,
void bio_uninit(struct bio *bio)
{
- bio_disassociate_task(bio);
+ bio_disassociate_blkg(bio);
}
EXPORT_SYMBOL(bio_uninit);
@@ -2073,15 +2073,6 @@ void bio_associate_blkg(struct bio *bio)
}
EXPORT_SYMBOL_GPL(bio_associate_blkg);
-/**
- * bio_disassociate_task - undo bio_associate_current()
- * @bio: target bio
- */
-void bio_disassociate_task(struct bio *bio)
-{
- bio_disassociate_blkg(bio);
-}
-
/**
* bio_clone_blkg_association - clone blkg association from src to dst bio
* @dst: destination bio
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 84e1c4dc703a..7380b094dcca 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -516,7 +516,6 @@ void bio_disassociate_blkg(struct bio *bio);
void bio_associate_blkg(struct bio *bio);
void bio_associate_blkg_from_css(struct bio *bio,
struct cgroup_subsys_state *css);
-void bio_disassociate_task(struct bio *bio);
void bio_clone_blkg_association(struct bio *dst, struct bio *src);
#else /* CONFIG_BLK_CGROUP */
static inline void bio_disassociate_blkg(struct bio *bio) { }
@@ -524,7 +523,6 @@ static inline void bio_associate_blkg(struct bio *bio) { }
static inline void bio_associate_blkg_from_css(struct bio *bio,
struct cgroup_subsys_state *css)
{ }
-static inline void bio_disassociate_task(struct bio *bio) { }
static inline void bio_clone_blkg_association(struct bio *dst,
struct bio *src) { }
#endif /* CONFIG_BLK_CGROUP */
--
2.17.1
Re: [PATCH] perf, tools: Support srccode output
On Wed, Dec 05, 2018 at 01:54:30PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 05, 2018 at 01:28:38PM +0100, Jiri Olsa escreveu:
> > On Mon, Dec 03, 2018 at 04:18:48PM -0800, Andi Kleen wrote:
> > > From: Andi Kleen
> > >
> > > When looking at PT or brstackinsn traces with perf script
> > > it can be very useful to see the source code. This adds a simple
> > > facility to print them with perf script, if the information
> > > is available through dwarf
> > >
> > > % perf record ...
> > > % perf script -F insn,ip,sym,srccode
> > > ...
> > >
> > > 4004c6 main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004cd main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004c6 main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004cd main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004cd main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004cd main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004cd main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004cd main
> > > 5 for (i = 0; i < 1000; i++)
> > >4004b3 main
> > > 6 v++;
> > >
> > > % perf record -b ...
> > > % perf script -F insn,ip,sym,srccode,brstackinsn
> > >
> > > ...
> > >main+22:
> > > 00400543insn: e8 ca ff ff ff# PRED
> > > |18 f1();
> > > f1:
> > > 00400512insn: 55
> > > |10 {
> > > 00400513insn: 48 89 e5
> > > 00400516insn: b8 00 00 00 00
> > > |11 f2();
> > > 0040051binsn: e8 d6 ff ff ff# PRED
> > > f2:
> > > 004004f6insn: 55
> > > |5{
> > > 004004f7insn: 48 89 e5
> > > 004004fainsn: 8b 05 2c 0b 20 00
> > > |6 c = a / b;
> > > 00400500insn: 8b 0d 2a 0b 20 00
> > > 00400506insn: 99
> > > 00400507insn: f7 f9
> > > 00400509insn: 89 05 29 0b 20 00
> > > 0040050finsn: 90
> > > |7}
> > > 00400510insn: 5d
> > > 00400511insn: c3# PRED
> > > f1+14:
> > > 00400520insn: b8 00 00 00 00
> > > |12 f2();
> > > 00400525insn: e8 cc ff ff ff# PRED
> > > f2:
> > > 004004f6insn: 55
> > > |5{
> > > 004004f7insn: 48 89 e5
> > > 004004fainsn: 8b 05 2c 0b 20 00
> > > |6 c = a / b;
> > >
> > > Not supported for callchains currently, would need some
> > > layout changes there.
> >
> > nice, works nicely, especialy with --xed
>
> The above seems to imply you actually tested it, was that the case? Can
> you please provide me the exact 'perf record' line you used, that is
> lacking in Andi's original commit log message?
yep..
# ./perf record -e intel_pt//u -- ./perf
jirka
[PATCH 01/12] staging: rtl8188eu: refactor cckrates_included()
Refactor cckrates_included() to improve readability and slightly
reduce object file size. Also change the return type to bool.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 9 +
drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 24918223499b..90160d5fc292 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -56,13 +56,14 @@ static u8 rtw_basic_rate_mix[7] = {
IEEE80211_OFDM_RATE_24MB | IEEE80211_BASIC_RATE_MASK
};
-int cckrates_included(unsigned char *rate, int ratelen)
+bool cckrates_included(unsigned char *rate, int ratelen)
{
- int i;
+ int i;
for (i = 0; i < ratelen; i++) {
- if rate[i]) & 0x7f) == 2) || (((rate[i]) & 0x7f) == 4) ||
-(((rate[i]) & 0x7f) == 11) || (((rate[i]) & 0x7f) == 22))
+ u8 r = rate[i] & 0x7f;
+
+ if (r == 2 || r == 4 || r == 11 || r == 22)
return true;
}
return false;
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index 9526da3efcc4..c86dec12dec2 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -580,7 +580,7 @@ void addba_timer_hdl(struct timer_list *t);
mod_timer(&mlmeext->link_timer, jiffies + \
msecs_to_jiffies(ms))
-int cckrates_included(unsigned char *rate, int ratelen);
+bool cckrates_included(unsigned char *rate, int ratelen);
int cckratesonly_included(unsigned char *rate, int ratelen);
void process_addba_req(struct adapter *padapter, u8 *paddba_req, u8 *addr);
--
2.19.2
[PATCH 06/12] staging: rtl8188eu: cleanup block comment in rtw_wlan_util.c
Cleanup a block comment to clear a checkpatch warning. WARNING: Block comments use * on subsequent lines Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c index e61fc7ce65e8..956a331beda2 100644 --- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c +++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c @@ -760,11 +760,11 @@ void HTOnAssocRsp(struct adapter *padapter) return; } - /* handle A-MPDU parameter field */ - /* - AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k - AMPDU_para [4:2]:Min MPDU Start Spacing - */ + /* handle A-MPDU parameter field +* +* AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k +* AMPDU_para [4:2]:Min MPDU Start Spacing +*/ max_AMPDU_len = pmlmeinfo->HT_caps.ampdu_params_info & 0x03; min_MPDU_spacing = (pmlmeinfo->HT_caps.ampdu_params_info & 0x1c) >> 2; -- 2.19.2
Re: [PATCH] clk: rockchip: add clock gate of ACODEC for rk3328
Am 5. Dezember 2018 15:18:40 MEZ schrieb kbuild test robot :
>Hi Katsuhiro,
>
>Thank you for the patch! Yet something to improve:
>
>[auto build test ERROR on rockchip/for-next]
>[also build test ERROR on v4.20-rc5]
>[cannot apply to next-20181204]
>[if your patch is applied to the wrong git tree, please drop us a note
>to help improve the system]
>
>url:
>https://github.com/0day-ci/linux/commits/Katsuhiro-Suzuki/clk-rockchip-add-clock-gate-of-ACODEC-for-rk3328/20181126-085855
>base:
>https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
>for-next
>config: arm64-defconfig (attached as .config)
>compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>reproduce:
>wget
>https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>-O ~/bin/make.cross
>chmod +x ~/bin/make.cross
># save the attached .config to linux build tree
>GCC_VERSION=7.2.0 make.cross ARCH=arm64
>
>All errors (new ones prefixed by >>):
>
> In file included from drivers/clk/rockchip/clk-rk3328.c:21:0:
>>> drivers/clk/rockchip/clk-rk3328.c:807:7: error: 'PCLK_ACODECPHY'
>undeclared here (not in a function); did you mean 'PCLK_HDMIPHY'?
>GATE(PCLK_ACODECPHY, "pclk_acodecphy", "pclk_phy_pre", 0,
>RK3328_CLKGATE_CON(17), 5, GFLAGS),
> ^
> drivers/clk/rockchip/clk.h:666:10: note: in definition of macro 'GATE'
> .id = _id,\
> ^~~
>
There was a separate patch adding the id sent before this one, but Not part of
a mail series. I have already applied both anyway ;-).
Heiko
>vim +807 drivers/clk/rockchip/clk-rk3328.c
>
> 242
> 243 static struct rockchip_clk_branch rk3328_i2s0_fracmux __initdata =
> 244 MUX(0, "i2s0_pre", mux_i2s0_p, CLK_SET_RATE_PARENT,
> 245 RK3328_CLKSEL_CON(6), 8, 2, MFLAGS);
> 246
> 247 static struct rockchip_clk_branch rk3328_i2s1_fracmux __initdata =
> 248 MUX(0, "i2s1_pre", mux_i2s1_p, CLK_SET_RATE_PARENT,
> 249 RK3328_CLKSEL_CON(8), 8, 2, MFLAGS);
> 250
> 251 static struct rockchip_clk_branch rk3328_i2s2_fracmux __initdata =
> 252 MUX(0, "i2s2_pre", mux_i2s2_p, CLK_SET_RATE_PARENT,
> 253 RK3328_CLKSEL_CON(10), 8, 2, MFLAGS);
> 254
>255static struct rockchip_clk_branch rk3328_spdif_fracmux __initdata =
> 256 MUX(SCLK_SPDIF, "sclk_spdif", mux_spdif_p, CLK_SET_RATE_PARENT,
> 257 RK3328_CLKSEL_CON(12), 8, 2, MFLAGS);
> 258
>259static struct rockchip_clk_branch rk3328_uart0_fracmux __initdata =
> 260 MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
> 261 RK3328_CLKSEL_CON(14), 8, 2, MFLAGS);
> 262
>263static struct rockchip_clk_branch rk3328_uart1_fracmux __initdata =
> 264 MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
> 265 RK3328_CLKSEL_CON(16), 8, 2, MFLAGS);
> 266
>267static struct rockchip_clk_branch rk3328_uart2_fracmux __initdata =
> 268 MUX(SCLK_UART2, "sclk_uart2", mux_uart2_p, CLK_SET_RATE_PARENT,
> 269 RK3328_CLKSEL_CON(18), 8, 2, MFLAGS);
> 270
>271static struct rockchip_clk_branch rk3328_clk_branches[] __initdata
>= {
> 272 /*
> 273 * Clock-Architecture Diagram 1
> 274 */
> 275
> 276 DIV(0, "clk_24m", "xin24m", CLK_IGNORE_UNUSED,
> 277 RK3328_CLKSEL_CON(2), 8, 5, DFLAGS),
> 278 COMPOSITE(SCLK_RTC32K, "clk_rtc32k", mux_2plls_xin24m_p, 0,
> 279 RK3328_CLKSEL_CON(38), 14, 2, MFLAGS, 0, 14,
> DFLAGS,
> 280 RK3328_CLKGATE_CON(0), 11, GFLAGS),
> 281
> 282 /* PD_MISC */
> 283 MUX(HDMIPHY, "hdmiphy", mux_hdmiphy_p, CLK_SET_RATE_PARENT,
> 284 RK3328_MISC_CON, 13, 1, MFLAGS),
> 285 MUX(USB480M, "usb480m", mux_usb480m_p, CLK_SET_RATE_PARENT,
> 286 RK3328_MISC_CON, 15, 1, MFLAGS),
> 287
> 288 /*
> 289 * Clock-Architecture Diagram 2
> 290 */
> 291
> 292 /* PD_CORE */
> 293 GATE(0, "apll_core", "apll", CLK_IGNORE_UNUSED,
> 294 RK3328_CLKGATE_CON(0), 0, GFLAGS),
> 295 GATE(0, "gpll_core", "gpll", CLK_IGNORE_UNUSED,
> 296 RK3328_CLKGATE_CON(0), 2, GFLAGS),
> 297 GATE(0, "dpll_core", "dpll", CLK_IGNORE_UNUSED,
> 298 RK3328_CLKGATE_CON(0), 1, GFLAGS),
> 299 GATE(0, "npll_core", "npll", CLK_IGNORE_UNUSED,
> 300 RK3328_CLKGATE_CON(0), 12, GFLAGS),
> 301 COMPOSITE_NOMUX(0, "pclk_dbg", "armclk", CLK_IGNORE_UNUSED,
> 302 RK3328_CLKSEL_CON(1), 0, 4, DFLAGS |
> CLK_DIVIDER_READ_ONLY,
> 303 RK3328_CLKGATE_CON(7), 0, GFLAGS),
> 304 COMPOSITE_NO
[PATCH 05/12] staging: rtl8188eu: cleanup declarations in rtw_wlan_util.c
Replace tabs with spaces and/or remove spaces in declarations
to cleanup whitespace. Remove unused/commented declarations.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/core/rtw_wlan_util.c| 175 +-
1 file changed, 86 insertions(+), 89 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 0e2653a68f4f..e61fc7ce65e8 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -177,7 +177,7 @@ static unsigned int ratetbl2rateset(struct adapter
*padapter, unsigned char *rat
{
int i;
unsigned char rate;
- unsigned intlen = 0;
+ unsigned int len = 0;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
for (i = 0; i < NumRates; i++) {
@@ -213,8 +213,8 @@ void get_rate_set(struct adapter *padapter, unsigned char
*pbssrate, int *bssrat
void UpdateBrateTbl(struct adapter *Adapter, u8 *mbrate)
{
- u8 i;
- u8 rate;
+ u8 i;
+ u8 rate;
/* 1M, 2M, 5.5M, 11M, 6M, 12M, 24M are mandatory. */
for (i = 0; i < NDIS_802_11_LENGTH_RATES_EX; i++) {
@@ -235,8 +235,8 @@ void UpdateBrateTbl(struct adapter *Adapter, u8 *mbrate)
void UpdateBrateTblForSoftAP(u8 *bssrateset, u32 bssratelen)
{
- u8 i;
- u8 rate;
+ u8 i;
+ u8 rate;
for (i = 0; i < bssratelen; i++) {
rate = bssrateset[i] & 0x7f;
@@ -253,14 +253,14 @@ void UpdateBrateTblForSoftAP(u8 *bssrateset, u32
bssratelen)
void Save_DM_Func_Flag(struct adapter *padapter)
{
- u8 saveflag = true;
+ u8 saveflag = true;
rtw_hal_set_hwreg(padapter, HW_VAR_DM_FUNC_OP, (u8 *)(&saveflag));
}
void Restore_DM_Func_Flag(struct adapter *padapter)
{
- u8 saveflag = false;
+ u8 saveflag = false;
rtw_hal_set_hwreg(padapter, HW_VAR_DM_FUNC_OP, (u8 *)(&saveflag));
}
@@ -370,8 +370,8 @@ u16 get_beacon_interval(struct wlan_bssid_ex *bss)
int is_client_associated_to_ap(struct adapter *padapter)
{
- struct mlme_ext_priv*pmlmeext;
- struct mlme_ext_info*pmlmeinfo;
+ struct mlme_ext_priv *pmlmeext;
+ struct mlme_ext_info *pmlmeinfo;
if (!padapter)
return _FAIL;
@@ -387,8 +387,8 @@ int is_client_associated_to_ap(struct adapter *padapter)
int is_client_associated_to_ibss(struct adapter *padapter)
{
- struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
+ struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
((pmlmeinfo->state&0x03) == WIFI_FW_ADHOC_STATE))
return true;
@@ -399,8 +399,8 @@ int is_client_associated_to_ibss(struct adapter *padapter)
int is_IBSS_empty(struct adapter *padapter)
{
unsigned int i;
- struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
+ struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
for (i = IBSS_START_MAC_ID; i < NUM_STA; i++) {
if (pmlmeinfo->FW_sta_info[i].status == 1)
@@ -426,9 +426,9 @@ void invalidate_cam_all(struct adapter *padapter)
void write_cam(struct adapter *padapter, u8 entry, u16 ctrl, u8 *mac, u8 *key)
{
- unsigned inti, val, addr;
+ unsigned int i, val, addr;
int j;
- u32 cam_val[2];
+ u32 cam_val[2];
addr = entry << 3;
@@ -464,8 +464,8 @@ void clear_cam_entry(struct adapter *padapter, u8 entry)
int allocate_fw_sta_entry(struct adapter *padapter)
{
unsigned int mac_id;
- struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
+ struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
for (mac_id = IBSS_START_MAC_ID; mac_id < NUM_STA; mac_id++) {
if (pmlmeinfo->FW_sta_info[mac_id].status == 0) {
@@ -480,8 +480,8 @@ int allocate_fw_sta_entry(struct adapter *padapter)
void flush_all_cam_entry(struct adapter *padapter)
{
- struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
+ struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
rtw_hal_set_hwreg(padapter, HW_VAR_CAM_INVALID_ALL, NULL);
@@ -490,10 +490,9 @@ void flush_all_cam_entry(struct adapter *padapter)
int WMM_param_handler(struct adapter *padapter, struct ndis_802_11_var_ie *pIE)
{
- /* struct registry_p
[PATCH 07/12] staging: rtl8188eu: cleanup long lines in rtw_wlan_util.c
Cleanup some lines over 80 characters by adding appropriate
line breaks and removing commented code.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 956a331beda2..2ffa0332bf32 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -379,7 +379,8 @@ int is_client_associated_to_ap(struct adapter *padapter)
pmlmeext = &padapter->mlmeextpriv;
pmlmeinfo = &pmlmeext->mlmext_info;
- if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
((pmlmeinfo->state&0x03) == WIFI_FW_STATION_STATE))
+ if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
+ (pmlmeinfo->state & 0x03) == WIFI_FW_STATION_STATE)
return true;
else
return _FAIL;
@@ -390,7 +391,8 @@ int is_client_associated_to_ibss(struct adapter *padapter)
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
- if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
((pmlmeinfo->state&0x03) == WIFI_FW_ADHOC_STATE))
+ if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
+ (pmlmeinfo->state & 0x03) == WIFI_FW_ADHOC_STATE)
return true;
else
return _FAIL;
@@ -662,8 +664,6 @@ static void bwmode_update_check(struct adapter *padapter,
struct ndis_802_11_var
struct wlan_bssid_ex*cur_network = &pmlmeinfo->network;
struct sta_priv *pstapriv = &padapter->stapriv;
- /* set_channel_bwmode(padapter, pmlmeext->cur_channel,
pmlmeext->cur_ch_offset, pmlmeext->cur_bwmode); */
-
/* update ap's stainfo */
psta = rtw_get_stainfo(pstapriv, cur_network->MacAddress);
if (psta) {
--
2.19.2
[PATCH 11/12] staging: rtl8188eu: rename struct field Wifi_Error_Status
Rename struct field Wifi_Error_Status to avoid CamelCase.
Wifi_Error_Status -> wifi_error_status
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_sreset.c | 4 ++--
drivers/staging/rtl8188eu/include/rtw_sreset.h | 2 +-
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_sreset.c
b/drivers/staging/rtl8188eu/core/rtw_sreset.c
index fb5adaf4a42c..a8397b132002 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sreset.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sreset.c
@@ -12,10 +12,10 @@ void rtw_hal_sreset_init(struct adapter *padapter)
{
struct sreset_priv *psrtpriv = &padapter->HalData->srestpriv;
- psrtpriv->Wifi_Error_Status = WIFI_STATUS_SUCCESS;
+ psrtpriv->wifi_error_status = WIFI_STATUS_SUCCESS;
}
void sreset_set_wifi_error_status(struct adapter *padapter, u32 status)
{
- padapter->HalData->srestpriv.Wifi_Error_Status = status;
+ padapter->HalData->srestpriv.wifi_error_status = status;
}
diff --git a/drivers/staging/rtl8188eu/include/rtw_sreset.h
b/drivers/staging/rtl8188eu/include/rtw_sreset.h
index 3ee6a4a7847d..ea3c0d93bf0b 100644
--- a/drivers/staging/rtl8188eu/include/rtw_sreset.h
+++ b/drivers/staging/rtl8188eu/include/rtw_sreset.h
@@ -11,7 +11,7 @@
#include
struct sreset_priv {
- u8 Wifi_Error_Status;
+ u8 wifi_error_status;
};
#include
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index 7dc7028c1cd5..e4f2af2974ed 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -263,7 +263,7 @@ static int usbctrl_vendorreq(struct adapter *adapt, u8
request, u16 value, u16 i
if (status == (-ESHUTDOWN) || status == -ENODEV)
adapt->bSurpriseRemoved = true;
else
-
adapt->HalData->srestpriv.Wifi_Error_Status = USB_VEN_REQ_CMD_FAIL;
+
adapt->HalData->srestpriv.wifi_error_status = USB_VEN_REQ_CMD_FAIL;
} else { /* status != len && status >= 0 */
if (status > 0) {
if (requesttype == 0x01) {
@@ -410,7 +410,7 @@ static void usb_read_port_complete(struct urb *purb, struct
pt_regs *regs)
break;
case -EPROTO:
case -EOVERFLOW:
- adapt->HalData->srestpriv.Wifi_Error_Status =
USB_READ_PORT_FAIL;
+ adapt->HalData->srestpriv.wifi_error_status =
USB_READ_PORT_FAIL;
precvbuf->reuse = true;
usb_read_port(adapt, RECV_BULK_IN_ADDR, precvbuf);
break;
--
2.19.2
[PATCH 04/12] staging: rtl8188eu: remove unnecessary parentheses in rtw_wlan_util.c
Remove unnecessary parentheses reported by checkpatch.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/core/rtw_wlan_util.c| 64 +--
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 76c7010c3a5c..0e2653a68f4f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -377,7 +377,7 @@ int is_client_associated_to_ap(struct adapter *padapter)
return _FAIL;
pmlmeext = &padapter->mlmeextpriv;
- pmlmeinfo = &(pmlmeext->mlmext_info);
+ pmlmeinfo = &pmlmeext->mlmext_info;
if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
((pmlmeinfo->state&0x03) == WIFI_FW_STATION_STATE))
return true;
@@ -388,7 +388,7 @@ int is_client_associated_to_ap(struct adapter *padapter)
int is_client_associated_to_ibss(struct adapter *padapter)
{
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
if ((pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS) &&
((pmlmeinfo->state&0x03) == WIFI_FW_ADHOC_STATE))
return true;
@@ -400,7 +400,7 @@ int is_IBSS_empty(struct adapter *padapter)
{
unsigned int i;
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
for (i = IBSS_START_MAC_ID; i < NUM_STA; i++) {
if (pmlmeinfo->FW_sta_info[i].status == 1)
@@ -465,7 +465,7 @@ int allocate_fw_sta_entry(struct adapter *padapter)
{
unsigned int mac_id;
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
for (mac_id = IBSS_START_MAC_ID; mac_id < NUM_STA; mac_id++) {
if (pmlmeinfo->FW_sta_info[mac_id].status == 0) {
@@ -481,7 +481,7 @@ int allocate_fw_sta_entry(struct adapter *padapter)
void flush_all_cam_entry(struct adapter *padapter)
{
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
rtw_hal_set_hwreg(padapter, HW_VAR_CAM_INVALID_ALL, NULL);
@@ -491,9 +491,9 @@ void flush_all_cam_entry(struct adapter *padapter)
int WMM_param_handler(struct adapter *padapter, struct ndis_802_11_var_ie *pIE)
{
/* struct registry_priv *pregpriv = &padapter->registrypriv; */
- struct mlme_priv*pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
if (pmlmepriv->qospriv.qos_option == 0) {
pmlmeinfo->WMM_enable = 0;
@@ -501,7 +501,7 @@ int WMM_param_handler(struct adapter *padapter, struct
ndis_802_11_var_ie *pIE)
}
pmlmeinfo->WMM_enable = 1;
- memcpy(&(pmlmeinfo->WMM_param), (pIE->data + 6), sizeof(struct
WMM_para_element));
+ memcpy(&pmlmeinfo->WMM_param, pIE->data + 6, sizeof(struct
WMM_para_element));
return true;
}
@@ -513,7 +513,7 @@ void WMMOnAssocRsp(struct adapter *padapter)
u32 acParm, i;
u32 edca[4], inx[4];
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
struct xmit_priv*pxmitpriv = &padapter->xmitpriv;
struct registry_priv*pregpriv = &padapter->registrypriv;
@@ -609,9 +609,9 @@ static void bwmode_update_check(struct adapter *padapter,
struct ndis_802_11_var
unsigned charnew_bwmode;
unsigned char new_ch_offset;
struct HT_info_element *pHT_info;
- struct mlme_priv*pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
struct registry_priv *pregistrypriv = &padapter->registrypriv;
struct ht_priv *phtpriv = &pmlmepriv->htpriv;
@@ -660,7 +660,7 @@ static void bwmode_update_check(struct adapter *padapter,
struct ndis_802_11_var
if (pmlmeinfo->bwmode_updated) {
struct sta_info *p
[PATCH 08/12] staging: rtl8188eu: add spaces around operators in rtw_wlan_util.c
Add spaces around '+', '-', '&' and '>>' to follow kernel coding
style. Reported by checkpatch.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/core/rtw_wlan_util.c| 21 +++
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 2ffa0332bf32..0eb904317118 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -444,7 +444,8 @@ void write_cam(struct adapter *padapter, u8 entry, u16
ctrl, u8 *mac, u8 *key)
break;
default:
i = (j - 2) << 2;
- val = key[i] | (key[i+1] << 8) | (key[i+2] << 16) |
(key[i+3] << 24);
+ val = key[i] | (key[i + 1] << 8) | (key[i + 2] << 16) |
+ (key[i + 3] << 24);
break;
}
@@ -580,7 +581,7 @@ void WMMOnAssocRsp(struct adapter *padapter)
/* entry indx: 0->vo, 1->vi, 2->be, 3->bk. */
for (i = 0; i < 4; i++) {
- for (j = i+1; j < 4; j++) {
+ for (j = i + 1; j < 4; j++) {
/* compare CW and AIFS */
if ((edca[j] & 0x) < (edca[i] & 0x)) {
change_inx = true;
@@ -894,7 +895,7 @@ int rtw_check_bcn_info(struct adapter *Adapter, u8
*pframe, u32 packet_len)
ht_info_infos_0 = 0;
}
if (ht_cap_info != cur_network->BcnInfo.ht_cap_info ||
- ((ht_info_infos_0&0x03) !=
(cur_network->BcnInfo.ht_info_infos_0&0x03))) {
+ ((ht_info_infos_0 & 0x03) != (cur_network->BcnInfo.ht_info_infos_0
& 0x03))) {
DBG_88E("%s bcn now: ht_cap_info:%x
ht_info_infos_0:%x\n", __func__,
ht_cap_info, ht_info_infos_0);
DBG_88E("%s bcn link: ht_cap_info:%x
ht_info_infos_0:%x\n", __func__,
@@ -983,18 +984,20 @@ int rtw_check_bcn_info(struct adapter *Adapter, u8
*pframe, u32 packet_len)
}
if (encryp_protocol == ENCRYP_PROTOCOL_WPA || encryp_protocol ==
ENCRYP_PROTOCOL_WPA2) {
- pbuf = rtw_get_wpa_ie(&bssid->ies[12], &wpa_ielen,
bssid->ie_length-12);
+ pbuf = rtw_get_wpa_ie(&bssid->ies[12], &wpa_ielen,
+ bssid->ie_length - 12);
if (pbuf && (wpa_ielen > 0)) {
- if (_SUCCESS == rtw_parse_wpa_ie(pbuf, wpa_ielen+2,
&group_cipher, &pairwise_cipher, &is_8021x)) {
+ if (_SUCCESS == rtw_parse_wpa_ie(pbuf, wpa_ielen + 2,
&group_cipher, &pairwise_cipher, &is_8021x)) {
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
("%s pnetwork->pairwise_cipher: %d,
group_cipher is %d, is_8021x is %d\n", __func__,
pairwise_cipher, group_cipher,
is_8021x));
}
} else {
- pbuf = rtw_get_wpa2_ie(&bssid->ies[12], &wpa_ielen,
bssid->ie_length-12);
+ pbuf = rtw_get_wpa2_ie(&bssid->ies[12], &wpa_ielen,
+ bssid->ie_length - 12);
if (pbuf && (wpa_ielen > 0)) {
- if (_SUCCESS == rtw_parse_wpa2_ie(pbuf,
wpa_ielen+2, &group_cipher, &pairwise_cipher, &is_8021x)) {
+ if (_SUCCESS == rtw_parse_wpa2_ie(pbuf,
wpa_ielen + 2, &group_cipher, &pairwise_cipher, &is_8021x)) {
RT_TRACE(_module_rtl871x_mlme_c_,
_drv_info_,
("%s
pnetwork->pairwise_cipher: %d, pnetwork->group_cipher is %d, is_802x is %d\n",
__func__, pairwise_cipher,
group_cipher, is_8021x));
@@ -1498,7 +1501,7 @@ void process_addba_req(struct adapter *padapter, u8
*paddba_req, u8 *addr)
if (psta) {
param = le16_to_cpu(preq->BA_para_set);
- tid = (param>>2)&0x0f;
+ tid = (param >> 2) & 0x0f;
preorder_ctrl = &psta->recvreorder_ctrl[tid];
preorder_ctrl->indicate_seq = 0x;
preorder_ctrl->enable = pmlmeinfo->accept_addba_req;
@@ -1513,7 +1516,7 @@ void update_TSF(struct mlme_ext_priv *pmlmeext, u8
*pframe, uint len)
pIE = pframe + sizeof(struct ieee80211_hdr_3addr);
pbuf = (__le32 *)pIE;
- pmlmeext->TSFValue = le32_to_cpu(*(pbuf+1));
+ pmlmeext->TSFValue = le32_to_cpu(*(pbuf + 1));
pmlmeext->TSFValue = pmlmeext->TSFValue << 32;
--
2.19.2
[PATCH 12/12] staging: rtl8188eu: remove unused code in rtw_cmd.c
Remove unused/commented code in rtw_cmd.c.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index e3e46f7ac834..f9cdd1da8add 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -215,8 +215,6 @@ int rtw_cmd_thread(void *context)
/* free all cmd_obj resources */
while ((pcmd = rtw_dequeue_cmd(&pcmdpriv->cmd_queue))) {
- /* DBG_88E("%s: leaving... drop cmdcode:%u\n", __func__,
pcmd->cmdcode); */
-
rtw_free_cmd_obj(pcmd);
}
@@ -259,7 +257,6 @@ u8 rtw_sitesurvey_cmd(struct adapter *padapter, struct
ndis_802_11_ssid *ssid,
init_h2fwcmd_w_parm_no_rsp(ph2c, psurveyPara, _SiteSurvey_CMD_);
- /* psurveyPara->bsslimit = 48; */
psurveyPara->scan_mode = pmlmepriv->scan_mode;
/* prepare ssid list */
@@ -660,9 +657,6 @@ u8 rtw_addbareq_cmd(struct adapter *padapter, u8 tid, u8
*addr)
init_h2fwcmd_w_parm_no_rsp(ph2c, paddbareq_parm, _AddBAReq_CMD_);
- /* DBG_88E("rtw_addbareq_cmd, tid =%d\n", tid); */
-
- /* rtw_enqueue_cmd(pcmdpriv, ph2c); */
res = rtw_enqueue_cmd(pcmdpriv, ph2c);
exit:
@@ -696,7 +690,6 @@ u8 rtw_dynamic_chk_wk_cmd(struct adapter *padapter)
init_h2fwcmd_w_parm_no_rsp(ph2c, pdrvextra_cmd_parm,
_Set_Drv_Extra_CMD_);
- /* rtw_enqueue_cmd(pcmdpriv, ph2c); */
res = rtw_enqueue_cmd(pcmdpriv, ph2c);
exit:
return res;
@@ -862,7 +855,6 @@ static void lps_ctrl_wk_hdl(struct adapter *padapter, u8
lps_ctrl_type)
rtw_hal_set_hwreg(padapter, HW_VAR_H2C_FW_JOINBSSRPT, (u8
*)(&mstatus));
break;
case LPS_CTRL_SPECIAL_PACKET:
- /* DBG_88E("LPS_CTRL_SPECIAL_PACKET\n"); */
pwrpriv->DelayLPSLastTimeStamp = jiffies;
LPS_Leave(padapter);
break;
@@ -879,7 +871,6 @@ u8 rtw_lps_ctrl_wk_cmd(struct adapter *padapter, u8
lps_ctrl_type, u8 enqueue)
struct cmd_obj *ph2c;
struct drvextra_cmd_parm*pdrvextra_cmd_parm;
struct cmd_priv *pcmdpriv = &padapter->cmdpriv;
- /* struct pwrctrl_priv *pwrctrlpriv = &padapter->pwrctrlpriv; */
u8 res = _SUCCESS;
if (enqueue) {
@@ -1029,9 +1020,6 @@ static void rtw_chk_hi_queue_hdl(struct adapter *padapter)
if (psta_bmc->sleepq_len == 0) {
u8 val = 0;
- /* while ((rtw_read32(padapter, 0x414)&0x0000)!= 0) */
- /* while ((rtw_read32(padapter, 0x414)&0xff00)!= 0) */
-
rtw_hal_get_hwreg(padapter, HW_VAR_CHK_HI_QUEUE_EMPTY, &val);
while (!val) {
--
2.19.2
Re: [PATCH 3/9] tools/lib/traceevent: Install trace-seq.h API header file
On Wed, 5 Dec 2018 13:25:17 +0100 Jiri Olsa wrote: > On Tue, Dec 04, 2018 at 02:41:45PM -0500, Steven Rostedt wrote: > > On Tue, 4 Dec 2018 16:47:39 +0900 > > Namhyung Kim wrote: > > > > > > > > @@ -302,6 +302,7 @@ install_headers: > > > > $(call QUIET_INSTALL, headers) \ > > > > $(call > > > > do_install,event-parse.h,$(prefix)/include/traceevent,644); \ > > > > $(call > > > > do_install,event-utils.h,$(prefix)/include/traceevent,644); \ > > > > + $(call > > > > do_install,trace-seq.h,$(prefix)/include/traceevent,644); \ > > > > $(call > > > > do_install,kbuffer.h,$(prefix)/include/traceevent,644) > > > > > > Do you still wanna have 'traceevent' directory prefix? I just > > > sometimes feel a bit annoying to type it. ;-) > > > > I'd still want the separate directory for it. I'll probably have a > > ftrace.h file added to this for ftrace specific code in the future. > > > > > > > > Or you can rename it something like 'tep' or 'libtep' - and hopefully > > > having only single header file to include.. > > > > > > > Hmm, I wonder if we should just call the directory "trace"? > > hum, I think it should match the library name, like 'include/tep/' I was hoping to add other headers in this directly, like ftrace.h and perf.h ;-) > > also we should change the plugin installation directory > > [jolsa@krava traceevent]$ rpm -ql perf | grep traceevent > /usr/lib64/traceevent > /usr/lib64/traceevent/plugins > /usr/lib64/traceevent/plugins/plugin_cfg80211.so > /usr/lib64/traceevent/plugins/plugin_function.so > /usr/lib64/traceevent/plugins/plugin_hrtimer.so > /usr/lib64/traceevent/plugins/plugin_jbd2.so > /usr/lib64/traceevent/plugins/plugin_kmem.so > /usr/lib64/traceevent/plugins/plugin_kvm.so > /usr/lib64/traceevent/plugins/plugin_mac80211.so > /usr/lib64/traceevent/plugins/plugin_sched_switch.so > /usr/lib64/traceevent/plugins/plugin_scsi.so > /usr/lib64/traceevent/plugins/plugin_xen.so Change it to tep? -- Steve
[PATCH 03/12] staging: rtl8188eu: simplify array initializations
Simplfy initialization of arrays with zero only values
to improve readability and save a line.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index fac1c1c20b2f..76c7010c3a5c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -455,9 +455,8 @@ void write_cam(struct adapter *padapter, u8 entry, u16
ctrl, u8 *mac, u8 *key)
void clear_cam_entry(struct adapter *padapter, u8 entry)
{
- u8 null_sta[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
- u8 null_key[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ u8 null_sta[ETH_ALEN] = {};
+ u8 null_key[16] = {};
write_cam(padapter, entry, 0, null_sta, null_key);
}
--
2.19.2
[PATCH 10/12] staging: rtl8188eu: correct indentation in update_wireless_mode()
Correct indentation in update_wireless_mode() to clear a checkpatch warning. WARNING: Statements should start on a tabstop Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c index 7af3dd910c93..42b9974fab8a 100644 --- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c +++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c @@ -1442,7 +1442,7 @@ void update_wireless_mode(struct adapter *padapter) if (pmlmeext->cur_wireless_mode & WIRELESS_11B) update_mgnt_tx_rate(padapter, IEEE80211_CCK_RATE_1MB); -else + else update_mgnt_tx_rate(padapter, IEEE80211_OFDM_RATE_6MB); } -- 2.19.2
[PATCH 09/12] staging: rtl8188eu: write out multiplying in wifirate2_ratetbl_inx()
Write out multiplying in wifirate2_ratetbl_inx() to improve
readabilitiy and clear checkpatch issues with missing spaces
around '*' operator.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/core/rtw_wlan_util.c| 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 0eb904317118..7af3dd910c93 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -1123,29 +1123,29 @@ static int wifirate2_ratetbl_inx(unsigned char rate)
rate = rate & 0x7f;
switch (rate) {
- case 54*2:
+ case 108:
return 11;
- case 48*2:
+ case 96:
return 10;
- case 36*2:
+ case 72:
return 9;
- case 24*2:
+ case 48:
return 8;
- case 18*2:
+ case 36:
return 7;
- case 12*2:
+ case 24:
return 6;
- case 9*2:
+ case 18:
return 5;
- case 6*2:
+ case 12:
return 4;
- case 11*2:
+ case 22:
return 3;
case 11:
return 2;
- case 2*2:
+ case 4:
return 1;
- case 1*2:
+ case 2:
return 0;
default:
return 0;
--
2.19.2
[PATCH 02/12] staging: rtl8188eu: refactor cckratesonly_included()
Refactor cckratesonly_included() to improve readability and slightly
reduce object file size. Also change the return type to bool.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 10 +-
drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 90160d5fc292..fac1c1c20b2f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -69,16 +69,16 @@ bool cckrates_included(unsigned char *rate, int ratelen)
return false;
}
-int cckratesonly_included(unsigned char *rate, int ratelen)
+bool cckratesonly_included(unsigned char *rate, int ratelen)
{
- int i;
+ int i;
for (i = 0; i < ratelen; i++) {
- if rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
- (((rate[i]) & 0x7f) != 11) && (((rate[i]) & 0x7f)
!= 22))
+ u8 r = rate[i] & 0x7f;
+
+ if (r != 2 && r != 4 && r != 11 && r != 22)
return false;
}
-
return true;
}
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index c86dec12dec2..0ade33df16d2 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -581,7 +581,7 @@ void addba_timer_hdl(struct timer_list *t);
msecs_to_jiffies(ms))
bool cckrates_included(unsigned char *rate, int ratelen);
-int cckratesonly_included(unsigned char *rate, int ratelen);
+bool cckratesonly_included(unsigned char *rate, int ratelen);
void process_addba_req(struct adapter *padapter, u8 *paddba_req, u8 *addr);
--
2.19.2
Re: [PATCH] x86/mce: Streamline MCE subsystem's naming
On Wed, Dec 05, 2018 at 05:30:37PM +0100, Ingo Molnar wrote: > Would it make sense to organize it a bit more and separate out vendor > specific functionality: > > mce/cpu/intel.c > mce/cpu/intel-p5.c > mce/cpu/amd.c > mce/cpu/winchip.c That's too fine-grained IMO and look at the path we'd get then: arch/x86/kernel/cpu/mce/cpu/intel.c ^^^ ^^^ which brings me to something we already talked about: the "kernel" part of the arch/x86/ paths. See this thread: https://lkml.kernel.org/r/20140114185802.gb29...@pd.tnic from 2014. We practically agreed there that "kernel/" is redundant as it all is kernel. So maybe we should start moving stuff up into arch/x86/ and then kill kernel/ eventually. > This way there's a clear separation between low level, vendor specific > MCE logic and higher level MCE logic. > > mce/apei.c, if this is an Intel-only feature, could perhaps become > mce/cpu/intel-apei.c? Yeah, I think the pile in mce/ is pretty succinct now. We can always separate it more later, if it starts to hurt but right now it is ok, IMO. > Anyway, your patch is fine too, so whichever subset you decide to use: > > Reviewed-by: Ingo Molnar Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
Quoting Viresh Kumar (2018-12-04 22:16:00)
> On 05-12-18, 09:07, Taniya Das wrote:
> > Hello Stephen, Viresh
> >
> > Thanks for the code and suggestions.
> >
> > Having a NR_DOMAINS '2' makes the driver not scalable for re-use.
>
> Sure, I didn't like it either and that wasn't really what I was suggesting in
> the first place. I didn't wanted to write the code myself and pass it on, but
> I
> have it now anyway :)
>
> It may have a bug or two in there, but compiles just fine and is rebased over
> your patch Taniya.
If we move the ioremap of registers to the cpufreq_driver::init path
then we need to unmap it on cpufreq_driver::exit. In fact, all the
devm_*() code in the init path needs to change to non-devm. Otherwise
it's a nice simplification!
> +static int qcom_cpufreq_hw_read_lut(struct device *dev,
> + struct cpufreq_policy *policy,
> + void __iomem *base)
> {
> u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, freq;
> - unsigned int max_cores = cpumask_weight(&c->related_cpus);
> + unsigned int max_cores = cpumask_weight(policy->cpus);
> + struct cpufreq_frequency_table *table;
>
> - c->table = devm_kcalloc(dev, LUT_MAX_ENTRIES + 1,
> - sizeof(*c->table), GFP_KERNEL);
> - if (!c->table)
> + table = devm_kcalloc(dev, LUT_MAX_ENTRIES + 1,
> + sizeof(*table), GFP_KERNEL);
This one.
> + if (!table)
> return -ENOMEM;
>
> for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> @@ -194,22 +154,29 @@ static void qcom_get_related_cpus(int index, struct
> cpumask *m)
> }
> }
>
> -static int qcom_cpu_resources_init(struct platform_device *pdev,
> - unsigned int cpu, int index,
> - unsigned long xo_rate,
> - unsigned long cpu_hw_rate)
> +static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
> {
> - struct cpufreq_qcom *c;
> + struct device *dev = &global_pdev->dev;
> + struct of_phandle_args args;
> + struct device_node *cpu_np;
> struct resource *res;
> - struct device *dev = &pdev->dev;
> void __iomem *base;
> - int ret, cpu_r;
> + int ret, index;
>
> - c = devm_kzalloc(dev, sizeof(*c), GFP_KERNEL);
> - if (!c)
> - return -ENOMEM;
> + cpu_np = of_cpu_device_node_get(policy->cpu);
> + if (!cpu_np)
> + return -EINVAL;
> +
> + ret = of_parse_phandle_with_args(cpu_np, "qcom,freq-domain",
> + "#freq-domain-cells", 0, &args);
> + of_node_put(cpu_np);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> + if (ret)
> + return ret;
> +
> + index = args.args[0];
> +
> + res = platform_get_resource(global_pdev, IORESOURCE_MEM, index);
> base = devm_ioremap_resource(dev, res);
And this one.
> if (IS_ERR(base))
> return PTR_ERR(base);
Here's a patch to squash in to fix those tiny problems. I left it as
devm_ioremap_resource() because that has all the nice features of
resource requesting inside and it didn't seem too bad to devm_iounmap()
on the exit path.
-8<--
drivers/cpufreq/qcom-cpufreq-hw.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index bcf9bb37298a..1e865e216839 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#define LUT_MAX_ENTRIES40U
#define LUT_SRCGENMASK(31, 30)
@@ -77,8 +78,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
unsigned int max_cores = cpumask_weight(policy->cpus);
struct cpufreq_frequency_table *table;
- table = devm_kcalloc(dev, LUT_MAX_ENTRIES + 1,
- sizeof(*table), GFP_KERNEL);
+ table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
if (!table)
return -ENOMEM;
@@ -144,7 +144,7 @@ static void qcom_get_related_cpus(int index, struct cpumask
*m)
ret = of_parse_phandle_with_args(cpu_np, "qcom,freq-domain",
"#freq-domain-cells", 0,
- &args);
+&args);
of_node_put(cpu_np);
if (ret < 0)
continue;
@@ -170,7 +170,6 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
ret = of_parse_phandle_with_args(cpu_np, "qcom,freq-domain",
"#freq-domain-cells", 0, &ar
Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
On Wed 05-12-18 13:29:18, Michal Hocko wrote:
[...]
> After some more thinking I am not really sure the above reasoning is
> still true with the current upstream kernel. Maybe I just managed to
> confuse myself so please hold off on this patch for now. Testing by
> Oscar has shown this patch is helping but the changelog might need to be
> updated.
OK, so Oscar has nailed it down and it seems that 4.4 kernel we have
been debugging on behaves slightly different. The underlying problem is
the same though. So I have reworded the changelog and added "just in
case" PageLRU handling. Naoya, maybe you have an argument that would
make this void for current upstream kernels.
I have dropped all the reviewed tags as the patch has changed slightly.
Thanks a lot to Oscar for his patience and testing he has devoted to
this issue.
Btw. the way how we drop all the work on the first page that we cannot
isolate is just goofy. Why don't we simply migrate all that we already
have on the list and go on? Something for a followup cleanup though.
---
>From 909521051f41ae46a841b481acaf1ed9c695ae7b Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Mon, 3 Dec 2018 10:27:18 +0100
Subject: [PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be
offlined
We have received a bug report that an injected MCE about faulty memory
prevents memory offline to succeed on 4.4 base kernel. The underlying
reason was that the HWPoison page has an elevated reference count and
the migration keeps failing. There are two problems with that. First
of all it is dubious to migrate the poisoned page because we know that
accessing that memory is possible to fail. Secondly it doesn't make any
sense to migrate a potentially broken content and preserve the memory
corruption over to a new location.
Oscar has found out that 4.4 and the current upstream kernels behave
slightly differently with his simply testcase
===
int main(void)
{
int ret;
int i;
int fd;
char *array = malloc(4096);
char *array_locked = malloc(4096);
fd = open("/tmp/data", O_RDONLY);
read(fd, array, 4095);
for (i = 0; i < 4096; i++)
array_locked[i] = 'd';
ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked),
sizeof(array_locked));
if (ret)
perror("mlock");
sleep (20);
ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096,
MADV_HWPOISON);
if (ret)
perror("madvise");
for (i = 0; i < 4096; i++)
array_locked[i] = 'd';
return 0;
}
===
+ offline this memory.
In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU
list
kernel: [] dump_trace+0x59/0x340
kernel: [] show_stack_log_lvl+0xea/0x170
kernel: [] show_stack+0x21/0x40
kernel: [] dump_stack+0x5c/0x7c
kernel: [] warn_slowpath_common+0x81/0xb0
kernel: [] __pagevec_lru_add_fn+0x14c/0x160
kernel: [] pagevec_lru_move_fn+0xad/0x100
kernel: [] __lru_cache_add+0x6c/0xb0
kernel: [] add_to_page_cache_lru+0x46/0x70
kernel: [] extent_readpages+0xc3/0x1a0 [btrfs]
kernel: [] __do_page_cache_readahead+0x177/0x200
kernel: [] ondemand_readahead+0x168/0x2a0
kernel: [] generic_file_read_iter+0x41f/0x660
kernel: [] __vfs_read+0xcd/0x140
kernel: [] vfs_read+0x7a/0x120
kernel: [] kernel_read+0x3b/0x50
kernel: [] do_execveat_common.isra.29+0x490/0x6f0
kernel: [] do_execve+0x28/0x30
kernel: [] call_usermodehelper_exec_async+0xfb/0x130
kernel: [] ret_from_fork+0x55/0x80
And that later confuses the hotremove path because an LRU page is
attempted to be migrated and that fails due to an elevated reference
count. It is quite possible that the reuse of the HWPoisoned page is
some kind of fixed race condition but I am not really sure about that.
With the upstream kernel the failure is slightly different. The page
doesn't seem to have LRU bit set but isolate_movable_page simply fails
and do_migrate_range simply puts all the isolated pages back to LRU and
therefore no progress is made and scan_movable_pages finds same set of
pages over and over again.
Fix both cases by explicitly checking HWPoisoned pages before we even
try to get a reference on the page, try to unmap it if it is still
mapped. As explained by Naoya
: Hwpoison code never unmapped those for no big reason because
: Ksm pages never dominate memory, so we simply didn't have strong
: motivation to save the pages.
Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU
HWPoison pages which shouldn't happen but I couldn't convince myself
about that.
Debugged-by: Oscar Salvador
Cc: stable
Signed-off-by: Michal Hocko
---
mm/memory_hotplug.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c6c42a7425e5..cfa1a2736876 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -1366,6 +1367,21 @@ do
Re: [PATCH] x86/mce: Streamline MCE subsystem's naming
On Wed, Dec 05, 2018 at 03:13:23PM +0100, Borislav Petkov wrote: > From: Borislav Petkov > > Rename the containing folder to "mce" which is the most widespread name. > Drop the "mce[-_]" filename prefix of some compilation units (while > others don't have it). > > This unifies the file naming in the MCE subsystem: > > mce/ > |-- amd.c > |-- apei.c > |-- core.c > |-- dev-mcelog.c > |-- genpool.c > |-- inject.c > |-- intel.c > |-- internal.h > |-- Makefile > |-- p5.c > |-- severity.c > |-- therm_throt.c > |-- threshold.c > `-- winchip.c > > No functional changes. > > Signed-off-by: Borislav Petkov Acked-by: Tony Luck
Re: [PATCH v6 10/24] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
On 04/12/18 17:36, Catalin Marinas wrote:
> On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
>> diff --git a/arch/arm64/include/asm/irqflags.h
>> b/arch/arm64/include/asm/irqflags.h
>> index 24692ed..e0a32e4 100644
>> --- a/arch/arm64/include/asm/irqflags.h
>> +++ b/arch/arm64/include/asm/irqflags.h
>> @@ -18,7 +18,27 @@
>>
>> #ifdef __KERNEL__
>>
>> +#include
>> +#include
>> #include
>> +#include
>> +
>> +
>> +/*
>> + * When ICC_PMR_EL1 is used for interrupt masking, only the bit indicating
>> + * whether the normal interrupts are masked is kept along with the daif
>> + * flags.
>> + */
>> +#define ARCH_FLAG_PMR_EN 0x1
>> +
>> +#define MAKE_ARCH_FLAGS(daif, pmr) \
>> +((daif) | (((pmr) >> GIC_PRIO_STATUS_SHIFT) & ARCH_FLAG_PMR_EN))
>> +
>> +#define ARCH_FLAGS_GET_PMR(flags)\
>> +flags) & ARCH_FLAG_PMR_EN) << GIC_PRIO_STATUS_SHIFT) \
>> +| GIC_PRIO_IRQOFF)
>> +
>> +#define ARCH_FLAGS_GET_DAIF(flags) ((flags) & ~ARCH_FLAG_PMR_EN)
>
> I wonder whether we could just use the PSR_I_BIT here to decide whether
> to set the GIC_PRIO_IRQ{ON,OFF}. We could clear the PSR_I_BIT in
> _restore_daif() with an alternative.
>
So, the issue with it is that some contexts might be using PSR.I to
disable interrupts (any contexts with async errors or debug exceptions
disabled, kvm guest entry paths, pseudo-NMIs, ...).
If any of these contexts calls local_irq_save()/local_irq_restore() or
local_daif_save()/local_daif_restore(), by only relying on PSR_I_BIT to
represent the PMR status, we might end up clearing PSR.I when we shouldn't.
I'm not sure whether there are no callers of these functions in those
context. But if that is the case, we could simplify things, yes.
Thanks,
>> +/*
>> + * CPU interrupt mask handling.
>> + */
>> static inline void arch_local_irq_enable(void)
>> {
>> -asm volatile(
>> -"msrdaifclr, #2 // arch_local_irq_enable"
>> -:
>> +unsigned long unmasked = GIC_PRIO_IRQON;
>> +
>> +asm volatile(ALTERNATIVE(
>> +"msrdaifclr, #2 // arch_local_irq_enable\n"
>> +"nop",
>> +"msr_s " __stringify(SYS_ICC_PMR_EL1) ",%0\n"
>> +"dsbsy",
>> +ARM64_HAS_IRQ_PRIO_MASKING)
>
> DSB needed here as well? I guess I'd have to read the GIC spec before
> asking again ;).
>
--
Julien Thierry
Re: [PATCH] perf, tools: Support srccode output
Em Wed, Dec 05, 2018 at 01:28:38PM +0100, Jiri Olsa escreveu:
> On Mon, Dec 03, 2018 at 04:18:48PM -0800, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > When looking at PT or brstackinsn traces with perf script
> > it can be very useful to see the source code. This adds a simple
> > facility to print them with perf script, if the information
> > is available through dwarf
> >
> > % perf record ...
> > % perf script -F insn,ip,sym,srccode
> > ...
> >
> > 4004c6 main
> > 5 for (i = 0; i < 1000; i++)
> >4004cd main
> > 5 for (i = 0; i < 1000; i++)
> >4004c6 main
> > 5 for (i = 0; i < 1000; i++)
> >4004cd main
> > 5 for (i = 0; i < 1000; i++)
> >4004cd main
> > 5 for (i = 0; i < 1000; i++)
> >4004cd main
> > 5 for (i = 0; i < 1000; i++)
> >4004cd main
> > 5 for (i = 0; i < 1000; i++)
> >4004cd main
> > 5 for (i = 0; i < 1000; i++)
> >4004b3 main
> > 6 v++;
> >
> > % perf record -b ...
> > % perf script -F insn,ip,sym,srccode,brstackinsn
> >
> > ...
> >main+22:
> > 00400543insn: e8 ca ff ff ff# PRED
> > |18 f1();
> > f1:
> > 00400512insn: 55
> > |10 {
> > 00400513insn: 48 89 e5
> > 00400516insn: b8 00 00 00 00
> > |11 f2();
> > 0040051binsn: e8 d6 ff ff ff# PRED
> > f2:
> > 004004f6insn: 55
> > |5{
> > 004004f7insn: 48 89 e5
> > 004004fainsn: 8b 05 2c 0b 20 00
> > |6 c = a / b;
> > 00400500insn: 8b 0d 2a 0b 20 00
> > 00400506insn: 99
> > 00400507insn: f7 f9
> > 00400509insn: 89 05 29 0b 20 00
> > 0040050finsn: 90
> > |7}
> > 00400510insn: 5d
> > 00400511insn: c3# PRED
> > f1+14:
> > 00400520insn: b8 00 00 00 00
> > |12 f2();
> > 00400525insn: e8 cc ff ff ff# PRED
> > f2:
> > 004004f6insn: 55
> > |5{
> > 004004f7insn: 48 89 e5
> > 004004fainsn: 8b 05 2c 0b 20 00
> > |6 c = a / b;
> >
> > Not supported for callchains currently, would need some
> > layout changes there.
>
> nice, works nicely, especialy with --xed
The above seems to imply you actually tested it, was that the case? Can
you please provide me the exact 'perf record' line you used, that is
lacking in Andi's original commit log message?
- Arnaldo
> Acked-by: Jiri Olsa
Re: [PATCH] auxdisplay: charlcd: fix x/y command parsing
Hi Mans,
[CC'ing a few people involved previously on this]
On Wed, Dec 5, 2018 at 2:53 PM Mans Rullgard wrote:
>
> Commit b34050fadb86 ("auxdisplay: charlcd: Fix and clean up handling of
> x/y commands") fixed some problems by rewriting the parsing code,
> but also broke things further by removing the check for a complete
> command before attempting to parse it. As a result, parsing is
> terminated at the first x or y character.
Why is it necessary to check for ";" to be exactly at the end? Or, in
other words, what requires it?
If the syntax supported by parse_xy() is wrong for some reason, we
should fix that (instead of adding a check before calling it).
Thanks for taking a look at this!
Cheers,
Miguel
[GIT PULL] x86: remove Intel MPX
Hi x86 maintainers, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-mpx.git mpx-remove There is only one commit, removing the Intel MPX implementation from the tree. The benefits of keeping the feature in the tree are not worth the ongoing maintenance cost. I updated this branch for 4.20-rc4 and it has passed all of the normal 0-day compile tests. -- Documentation/x86/intel_mpx.txt | 244 arch/x86/Kconfig| 28 - arch/x86/include/asm/bugs.h |6 - arch/x86/include/asm/disabled-features.h|8 +- arch/x86/include/asm/fpu/xstate.h |4 +- arch/x86/include/asm/mmu.h |4 - arch/x86/include/asm/mmu_context.h | 31 - arch/x86/include/asm/mpx.h | 115 -- arch/x86/include/asm/processor.h| 18 - arch/x86/include/asm/trace/mpx.h| 134 --- arch/x86/kernel/cpu/common.c| 18 - arch/x86/kernel/cpu/cpuid-deps.c|1 - arch/x86/kernel/cpu/intel.c | 37 - arch/x86/kernel/fpu/xstate.c|6 +- arch/x86/kernel/setup.c |2 - arch/x86/kernel/sys_x86_64.c|9 - arch/x86/kernel/traps.c | 74 -- arch/x86/kvm/cpuid.c| 13 +- arch/x86/kvm/cpuid.h|1 - arch/x86/kvm/svm.c |6 - arch/x86/kvm/vmx.c | 60 +- arch/x86/kvm/x86.c | 25 - arch/x86/kvm/x86.h |3 +- arch/x86/mm/Makefile|1 - arch/x86/mm/hugetlbpage.c |5 - arch/x86/mm/mpx.c | 936 fs/exec.c |1 - include/asm-generic/mm_hooks.h | 11 - include/uapi/linux/prctl.h |2 +- kernel/sys.c| 13 +- mm/mmap.c |6 - tools/testing/selftests/x86/mpx-debug.h | 15 - tools/testing/selftests/x86/mpx-dig.c | 499 - tools/testing/selftests/x86/mpx-hw.h| 124 -- tools/testing/selftests/x86/mpx-mini-test.c | 1616 tools/testing/selftests/x86/mpx-mm.h| 10 - 36 files changed, 13 insertions(+), 4073 deletions(-) delete mode 100644 Documentation/x86/intel_mpx.txt delete mode 100644 arch/x86/include/asm/mpx.h delete mode 100644 arch/x86/include/asm/trace/mpx.h delete mode 100644 arch/x86/mm/mpx.c delete mode 100644 tools/testing/selftests/x86/mpx-debug.h delete mode 100644 tools/testing/selftests/x86/mpx-dig.c delete mode 100644 tools/testing/selftests/x86/mpx-hw.h delete mode 100644 tools/testing/selftests/x86/mpx-mini-test.c delete mode 100644 tools/testing/selftests/x86/mpx-mm.h
Re: [PATCH 4.19 000/139] 4.19.7-stable review
On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.7 release. > There are 139 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 6 10:36:22 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Note: As a consequence of the retpoline backport, we upgraded our toolchain that is used to build the kernel and userspace from 7.0 to 7.3 (containing retpoline support). Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.7-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 987a6da5152c29e37cc11de9a2d10a23a48015c9 git describe: v4.19.6-140-g987a6da5152c Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.6-140-g987a6da5152c No Regressions (compared to build v4.19.6) No Fixes (compared to build v4.19.6) Ran 20285 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 0/7] microblaze: fix various problems in building boot images
On 03. 12. 18 8:50, Masahiro Yamada wrote: > This patch set fixes various issues in microblaze Makefiles. > > BTW, "simpleImage." works like a phony target to generate the > following four images, where the first three are just aliases. > > - arch/microblaze/boot/simpleImage.: > identical to arch/microblaze/boot/linux.bin It is not - fdt section should be empty. simpleImage has this section filled. > > - arch/microblaze/boot/simpleImage..unstrip: > identical to vmlinux The same here with filled section. > > - arch/microblaze/boot/simpleImage..ub: > identical to arch/microblaze/boot/linux.bin.ub as above. > > - arch/microblaze/boot/simpleImage..strip: > stripped vmlinux And this is there because unstrip version is quite huge and for early issues you need to know only some symbols that's why debugger is not overflow with stuff which none needs. Maybe this is not an issue now but that strip version is used a lot. > > I am not sure how much useful those copies are, > but, I tried my best to keep the same behavior. > > IMHO, I guess DTB= would be more sensible, > but it is up to Michal. What do you mean by this exactly? Definitely thanks for looking at this. Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: Provide support for reading ID code from MVB device (BK4)
Hi Fabio,
> Hi Lukasz,
>
> On Mon, Dec 3, 2018 at 7:33 AM Lukasz Majewski wrote:
>
> > > > + 72xx165@0 {
> > >
> > > Please use a generic name for the node.
> >
> > This is a bit tricky.
>
> What about using 'gpio@0' like described in
> Documentation/devicetree/bindings/gpio/gpio-pisosr.txt ?
Seems like a good idea. Thanks.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp_wxzbff2wR.pgp
Description: OpenPGP digital signature
Re: [PATCH 4.14 121/146] x86/fpu: Disable bottom halves while loading FPU registers
Greg Kroah-Hartman wrote:
> commit 68239654acafe6aad5a3c1dc7237e60accfebc03 upstream.
>
> The sequence
>
> fpu->initialized = 1; /* step A */
> preempt_disable();/* step B */
> fpu__restore(fpu);
> preempt_enable();
>
> in __fpu__restore_sig() is racy in regard to a context switch.
That same race appears to be present in older kernel branches also.
The context is sligthly different, so the patch for 4.14 does not
apply cleanly to older kernels. For 4.9 branch, this edit works:
s/fpu->initialized/fpu->fpstate_active/
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -342,10 +342,10 @@ static int __fpu__restore_sig(void __use
sanitize_restored_xstate(tsk, &env, xfeatures, fx_only);
}
+ local_bh_disable();
fpu->fpstate_active = 1;
- preempt_disable();
fpu__restore(fpu);
- preempt_enable();
+ local_bh_enable();
return err;
} else {
Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample
On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote: > On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote: > > Hello, > > > > I was able to trigger another oops with the perf_fuzzer with current git. > > > > This is 4.20-rc5 after the fix for the very similar oops I previously > > reported got committed. > > > > It seems to be pointing to the same location in the source as > > before, I guess maybe triggered a different way? > > nice.. yep, looks the same > > > > > Unfortunately this crash is not easily reproducible like the last one was. > > will check what model are hitting this on? jirka
Re: [RFC PATCH 1/1] epoll: use rwlock in order to reduce ep_poll_callback() contention
On 12/5/18 6:16 AM, Roman Penyaev wrote:
> On 2018-12-04 18:23, Jason Baron wrote:
>> On 12/3/18 6:02 AM, Roman Penyaev wrote:
>
> [...]
>
>>>
>>> ep_set_busy_poll_napi_id(epi);
>>>
>>> @@ -1156,8 +1187,8 @@ static int ep_poll_callback(wait_queue_entry_t *wait,
>>> unsigned mode, int sync, v
>>> */
>>> if (unlikely(ep->ovflist != EP_UNACTIVE_PTR)) {
>>> if (epi->next == EP_UNACTIVE_PTR) {
>>> - epi->next = ep->ovflist;
>>> - ep->ovflist = epi;
>>> + /* Atomically exchange tail */
>>> + epi->next = xchg(&ep->ovflist, epi);
>>
>> This also relies on the fact that the same epi can't be added to the
>> list in parallel, because the wait queue doing the wakeup will have the
>> wait_queue_head lock. That was a little confusing for me b/c we only had
>> the read_lock() above.
>
> Yes, that is indeed not obvious path, but wq is locked by wake_up_*_poll()
> call or caller of wake_up_locked_poll() has to be sure wq.lock is taken.
>
> I'll add an explicit comment here, thanks for pointing out.
>
>>
>>> if (epi->ws) {
>>> /*
>>> * Activate ep->ws since epi->ws may get
>>> @@ -1172,7 +1203,7 @@ static int ep_poll_callback(wait_queue_entry_t *wait,
>>> unsigned mode, int sync, v
>>>
>>> /* If this file is already in the ready list we exit soon */
>>> if (!ep_is_linked(epi)) {
>>> - list_add_tail(&epi->rdllink, &ep->rdllist);
>>> + list_add_tail_lockless(&epi->rdllink, &ep->rdllist);
>>> ep_pm_stay_awake_rcu(epi);
>>> }
>>
>> same for this.
>
> ... and an explicit comment here.
>
>>
>>>
>>> @@ -1197,13 +1228,13 @@ static int ep_poll_callback(wait_queue_entry_t
>>> *wait, unsigned mode, int sync, v
>>> break;
>>> }
>>> }
>>> - wake_up_locked(&ep->wq);
>>> + wake_up(&ep->wq);
>>
>> why the switch here to the locked() variant? Shouldn't the 'reader'
>> side, in this case which takes the rwlock for write see all updates in a
>> coherent state at this point?
>
> lockdep inside __wake_up_common expects wq_head->lock is taken, and
> seems this is not a good idea to leave wq naked on wake up path,
> when several CPUs can enter wake function. Although default_wake_function
> is protected by spinlock inside try_to_wake_up(), but for example
> autoremove_wake_function() can't be called concurrently for the same wq
> (it removes wq entry from the list). Also in case of bookmarks
> __wake_up_common adds an entry to the list, thus can't be called without
> any locks.
>
> I understand you concern and you are right saying that read side sees
> wq entries as stable, but that will work only if __wake_up_common does
> not modify anything, that is seems true now, but of course it is
> too scary to rely on that in the future.
I think it might be interesting for, at least testing, to see if not grabbing
wq.lock improves your benchmarks any further? fwiw, epoll only recently started
grabbing wq.lock bc lockdep required it.
Thanks,
-Jason
[PATCH] x86/fault: Print "SUPERVISOR" and "READ" when decoding #PF oops
...instead of manually handling the case where error_code=0, e.g. to
display "[SUPERVISOR] [READ]" instead of "normal kernel read fault".
This makes the zero case consistent with all other messages and also
provides additional information for other error code combinations,
e.g. error_code==1 will display "[PROT] [SUPERVISOR] [READ]" instead
of simply "[PROT]".
Print unique names for the negative cases as opposed to e.g. "[!USER]"
to avoid mixups due to users missing a single "!" character, and to be
more concise for the !INSTR && !WRITE case.
Print "SUPERVISOR" in favor of "KERNEL" to reduce the likelihood that
the message is misinterpreted as a generic kernel/software error and
to be consistent with the SDM's nomenclature.
An alternative to passing a negated error code to err_str_append() would
be to expand err_str_append() to take a second string for the negative
test, but that approach complicates handling the "[READ]" case, which
looks for !INSTR && !WRITE, e.g. it would require an extra call to
err_str_append() and logic in err_str_append() to allow null messages
for both the positive and negative tests. Printing "[INSTR] [READ]"
wouldn't be the end of the world, but a little bit of trickery in the
kernel is a relatively small price to pay in exchange for the ability
to unequivocally know the access type by reading a single word.
Now that all components of the message use the [] format,
explicitly state that it's the error *code* that's being printed and
group the err_str_append() calls by type so that the resulting print
messages are consistent, e.g. the deciphered codes will always be:
[PROT] [USER|SUPERVISOR] [WRITE|INSTR|READ] [RSDV] [PK]
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Yu-cheng Yu
Cc: linux-kernel@vger.kernel.org
Cc: Ingo Molnar
Signed-off-by: Sean Christopherson
---
arch/x86/mm/fault.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 2ff25ad33233..0b4ce5d2b461 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -609,7 +609,7 @@ static void show_ldttss(const struct desc_ptr *gdt, const
char *name, u16 index)
*/
static void err_str_append(unsigned long error_code, char *buf, unsigned long
mask, const char *txt)
{
- if (error_code & mask) {
+ if ((error_code & mask) == mask) {
if (buf[0])
strcat(buf, " ");
strcat(buf, txt);
@@ -655,13 +655,16 @@ show_fault_oops(struct pt_regs *regs, unsigned long
error_code, unsigned long ad
* zero delimiter must fit into err_txt[].
*/
err_str_append(error_code, err_txt, X86_PF_PROT, "[PROT]" );
- err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]");
err_str_append(error_code, err_txt, X86_PF_USER, "[USER]" );
- err_str_append(error_code, err_txt, X86_PF_RSVD, "[RSVD]" );
+ err_str_append(~error_code, err_txt, X86_PF_USER, "[SUPERVISOR]");
+ err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]");
err_str_append(error_code, err_txt, X86_PF_INSTR, "[INSTR]");
+ err_str_append(~error_code, err_txt, X86_PF_WRITE | X86_PF_INSTR,
+ "[READ]");
+ err_str_append(error_code, err_txt, X86_PF_RSVD, "[RSVD]" );
err_str_append(error_code, err_txt, X86_PF_PK,"[PK]" );
- pr_alert("#PF error: %s\n", error_code ? err_txt : "[normal kernel read
fault]");
+ pr_alert("#PF error code: %s\n", err_txt);
if (!(error_code & X86_PF_USER) && user_mode(regs)) {
struct desc_ptr idt, gdt;
--
2.19.2
Re: edac driver injection of uncorrected errors & utils
This was very helpful. Tracing through the code, it doesn't do a panic before Linux crashes from multi-bit errors because as York has indicated, this type of memory controller doesn't limit the number of errors. I do have a general question about single bit errors. The EDAC driver corrects single bit errors by doing a scrub, is this correct? The edac code does not do periodic scrubs, but I see scrubs when a correctable error is found (edac_mc_scrub_block and edac_atomic_scrub in edac_mc.c)? This is more directed toward York for layerscape. I see some edac code that seem to do periodic scrubs based on intervals or scrub rate, but that is not needed for the layerscape driver to correct errors because errors are scrubbed when found by the edac scrub block or is it because the memory controller itself does the correction/scrubbing when an error is found? thx, Tracy On Wed, Nov 28, 2018 at 5:44 PM Borislav Petkov wrote: > > On Wed, Nov 28, 2018 at 04:14:24PM -0600, Tracy Smith wrote: > > Is there another way of creating an uncorrected error without crashing > > Linux using the layerscape driver? I would like to see a UE error > > collected without a Linux crash scenario because I need to validate > > UEs are being collected. > > It depends on whether the hardware is causing the crash on uncorrectable > error to prevent data corruption or the error handler is calling panic() > or somesuch. If it is the former, then you need to disable that feature > - if at all possible (no clue what that platform does). > > If it is the latter, you can comment out the panic() for testing > purposes only and inject then. For an example what x86 does, see > "tolerant" here: > > Documentation/x86/x86_64/machinecheck > > HTH. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. -- Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), please immediately notify the sender and delete this e-mail message.
Re: [PATCH 1/2] ARM: Remove '-p' from LDFLAGS
On Tue, 4 Dec 2018, Nathan Chancellor wrote:
> This option is not supported by lld:
>
> ld.lld: error: unknown argument: -p
>
> This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
> that tree). Given that the lowest officially supported of binutils for
> the kernel is 2.20, which was released in 2009, nobody needs this flag
> around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
> linker flag") did the same for arm64.
>
> Signed-off-by: Nathan Chancellor
Acked-by: Nicolas Pitre
> ---
> arch/arm/Makefile | 2 +-
> arch/arm/boot/compressed/Makefile | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 05a91d8b89f3..e2a0baf36766 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
> #
> # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux :=-p --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux := --no-undefined -X --pic-veneer
> ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> LDFLAGS_vmlinux += --be8
> KBUILD_LDFLAGS_MODULE+= --be8
> diff --git a/arch/arm/boot/compressed/Makefile
> b/arch/arm/boot/compressed/Makefile
> index 1f5a5ffe7fcf..dcd07bd24b85 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -131,8 +131,6 @@ endif
> ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> LDFLAGS_vmlinux += --be8
> endif
> -# ?
> -LDFLAGS_vmlinux += -p
> # Report unresolved symbol references
> LDFLAGS_vmlinux += --no-undefined
> # Delete all temporary local symbols
> --
> 2.20.0.rc1
>
>
Re: [PATCH v2] tracing: add cond_resched to ftrace_replace_code()
On Wed, 5 Dec 2018 11:43:12 +0100 Anders Roxell wrote: > > > + schedulable = !irqs_disabled() && !preempt_count(); > > > > Is there a reason not to use preemptible() here? > > As I understand it preemptible() is defined to 0 if > CONFIG_PREEMPT_COUNT is disabled. > Thats no good right ? No it's not, which means this isn't a good approach. I have a much better idea on how to solve this. I'll post a small patch set in a bit. -- Steve
[PATCH] usb: host: isp1362-hcd: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
drivers/usb/host/isp1362-hcd.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/isp1362-hcd.c b/drivers/usb/host/isp1362-hcd.c
index b21c386e6a46..28bf8bfb091e 100644
--- a/drivers/usb/host/isp1362-hcd.c
+++ b/drivers/usb/host/isp1362-hcd.c
@@ -2159,25 +2159,15 @@ static int isp1362_show(struct seq_file *s, void
*unused)
return 0;
}
-
-static int isp1362_open(struct inode *inode, struct file *file)
-{
- return single_open(file, isp1362_show, inode);
-}
-
-static const struct file_operations debug_ops = {
- .open = isp1362_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(isp1362);
/* expect just one isp1362_hcd per system */
static void create_debug_file(struct isp1362_hcd *isp1362_hcd)
{
isp1362_hcd->debug_file = debugfs_create_file("isp1362", S_IRUGO,
usb_debug_root,
- isp1362_hcd, &debug_ops);
+ isp1362_hcd,
+ &isp1362_fops);
}
static void remove_debug_file(struct isp1362_hcd *isp1362_hcd)
--
2.17.0
Re: [PATCH 7/7] microblaze: remove the unneeded code just in case file copy fails
On 03. 12. 18 8:50, Masahiro Yamada wrote:
> I guess
>
> || (rm -f $@ && echo false)
>
> ... should be
>
> || (rm -f $@ && false)
>
> since printing the string "false" on the console has no point.
>
> Moreover, no Makefile needs to delete a target on error explicitly
> since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
> target").
>
> Reuse equivalent cmd_shipped from scripts/Makefile.lib.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/microblaze/boot/dts/Makefile | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/microblaze/boot/dts/Makefile
> b/arch/microblaze/boot/dts/Makefile
> index c7324e7..ef00dd3 100644
> --- a/arch/microblaze/boot/dts/Makefile
> +++ b/arch/microblaze/boot/dts/Makefile
> @@ -12,12 +12,9 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
> # Generate system.dtb from $(DTB).dtb
> ifneq ($(DTB),system)
> $(obj)/system.dtb: $(obj)/$(DTB).dtb
> - $(call if_changed,cp)
> + $(call if_changed,shipped)
> endif
> endif
>
> -quiet_cmd_cp = CP $< $@$2
> - cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
> -
> # Rule to build device tree blobs
> DTC_FLAGS := -p 1024
>
Acked-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 6/7] microblaze: fix race condition in building boot images
On 03. 12. 18 8:50, Masahiro Yamada wrote:
> I fixed a race condition in the parallel building of ARM in commit
> 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
> generate invalid images").
>
> I see the same problem for MicroBlaze too.
>
> "make -j ARCH=microblaze all linux.bin.ub" results in a broken build
> since two threads descend into arch/microblaze/boot simultaneously.
I see also different problem that when I run that make above
linux.bin.ub is not generated at all.
>
> Add proper dependencies to avoid it.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/microblaze/Makefile | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
> index 7a5df02..544796d 100644
> --- a/arch/microblaze/Makefile
> +++ b/arch/microblaze/Makefile
> @@ -79,13 +79,15 @@ all: linux.bin
> archclean:
> $(Q)$(MAKE) $(clean)=$(boot)
>
> +linux.bin.ub linux.bin.gz: linux.bin
> +
> PHONY += linux.bin linux.bin.gz linux.bin.ub
> linux.bin linux.bin.gz linux.bin.ub: vmlinux
> $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
> @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
>
> PHONY += simpleImage.$(DTB)
> -simpleImage.$(DTB): vmlinux
> +simpleImage.$(DTB): linux.bin.ub
It looks weird that simpleImage requires linux.bin.ub.
Is it really linux.bin.ub here or just linux.bin?
> $(Q)$(MAKE) $(build)=$(boot) simple_images
> @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
>
>
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 0/4] add uart DMA function
Hi Greg, On 05-12-18, 11:03, Greg Kroah-Hartman wrote: > On Wed, Dec 05, 2018 at 04:42:56PM +0800, Long Cheng wrote: > > In Mediatek SOCs, the uart can support DMA function. > > Base on DMA engine formwork, we add the DMA code to support uart. And put > > the code under drivers/dma. > > > > This series contains document bindings, Kconfig to control the function > > enable or not, > > device tree including interrupt and dma device node, the code of UART DM > > I've queued up patches 1 and 3 from this series in my tty tree, thanks. Do you mind not taking patch 2, I would like that to go thru dmaengine tree Thanks -- ~Vinod
Re: [PATCH] x86/mce: Streamline MCE subsystem's naming
* Borislav Petkov wrote: > From: Borislav Petkov > > Rename the containing folder to "mce" which is the most widespread name. > Drop the "mce[-_]" filename prefix of some compilation units (while > others don't have it). > > This unifies the file naming in the MCE subsystem: > > mce/ > |-- amd.c > |-- apei.c > |-- core.c > |-- dev-mcelog.c > |-- genpool.c > |-- inject.c > |-- intel.c > |-- internal.h > |-- Makefile > |-- p5.c > |-- severity.c > |-- therm_throt.c > |-- threshold.c > `-- winchip.c > > No functional changes. Cool! Would it make sense to organize it a bit more and separate out vendor specific functionality: mce/cpu/intel.c mce/cpu/intel-p5.c mce/cpu/amd.c mce/cpu/winchip.c mce/internal.h mce/core.c mce/genpool.c mce/threshold.c mce/severity.c mce/inject.c mce/therm_throt.c mce/dev-mcelog.c mce/apei.c ? This way there's a clear separation between low level, vendor specific MCE logic and higher level MCE logic. mce/apei.c, if this is an Intel-only feature, could perhaps become mce/cpu/intel-apei.c? Anyway, your patch is fine too, so whichever subset you decide to use: Reviewed-by: Ingo Molnar Thanks, Ingo
Re: [PATCH] binder: fix sparse warnings on locking context
On Wed, Dec 05, 2018 at 06:02:22AM -0800, Todd Kjos wrote: > On Wed, Dec 5, 2018 at 2:57 AM Greg KH wrote: > > > On Mon, Dec 03, 2018 at 12:24:54PM -0800, Todd Kjos wrote: > > > Add __acquire()/__release() annnotations to fix warnings > > > in sparse context checking > > > > > > There is one case where the warning was due to a lack of > > > a "default:" case in a switch statement where a lock was > > > being released in each of the cases, so the default > > > case was added. > > > > > > Signed-off-by: Todd Kjos > > > > You sent out 4 patches here, as a series, but with no numbering so I > > don't know what order to put them in :( > > > > Can you resend them properly numbered so I have a chance to get it > > right? > > > > I didn't number them because they are independent and can go in any order. Ah, that wasn't obvious :) > They are not really a series. I can resend with numbers though if you want > to reflect the order I sent them in. Ok, no need for numbering them, but they do need to be resent based on the feedback I gave. I've dropped them all from my queue because of that. thanks, greg k-h
Re: [PATCH 0/2] Fix return code and improve feature check for synthetic uevents
On Wed, Dec 05, 2018 at 12:27:43PM +0100, Peter Rajnoha wrote: > Two small patches to aid handling of synthetic uevents back in userspace: > > - Return error code back to userspace on /sys/.../uevent file write > failure so userspace knows and it can act accordingly. > > - Add new 'kernel/uevent_features' sysfs file to make it possible for > userspace to check that the extended synthetic uevent arguments are > supported without relying on kernel version check only. > > Peter Rajnoha (2): > kobject: return error code if writing /sys/.../uevent fails > kobject: add kernel/uevent_features sysfs file Did you send this series twice? Which one should I pay attention to? confused, greg k-h
Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings
* Borislav Petkov wrote: > On Wed, Dec 05, 2018 at 10:49:06PM +0900, Masami Hiramatsu wrote: > > I would like to put this prototype inside arch/x86/kernel/kprobes/core.c, > > since that is locally used. > > Done. Also, preferably the prototype should be eliminated via proper ordering of functions from lower level to higher levels. On the rest: Reviewed-by: Ingo Molnar Thanks, Ingo
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
Good news is that I got our opengl test running on your x86/mm branch.
The commit a2b4306c50b5de2ca955cd73ac57c2ac6426ee15 (current tip of
x86/mm) is good. For sanity I jumped back and found this commit
a2aa52ab16efbee40ad118ebac4a5e438f5b43ee doesn't work.
Thanks,
Tom
On 2018-12-03 2:26 p.m., Tom St Denis wrote:
> Hi Peter,
>
> After updating my UMDs (mesa/etc) over the weekend I cannot reproduce
> the bug to begin with. I'll try jumping directly to the intersection
> and see if I can reproduce the fault there otherwise I'll have to
> rollback my umds.
>
> Hopefully I can test this tomorrow.
>
> Tom
>
> On 2018-12-03 10:41 a.m., Peter Zijlstra wrote:
>> On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
>>> NAK I get a failure in TTM on init with your x86/mm branch (see attached
>>> dmesg).
>>
>> So the good news is that with some additional self-tests I can trivially
>> reproduce this. The bad news is that an otherwise straight forward
>> cleanup seems to make CPA horribly mad at me.
>>
>> And since we're somewhat late in the release cycle, I suppose we should
>> do the simple thing first, and then I can try and figure out this CPA
>> mess later.
>>
>> So how about this relatively simple partial revert to sort the problem.
>>
>> ---
>> Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
>>
>> In commit:
>>
>> a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>>
>> I misread the cpa array code and incorrectly used
>> tlb_flush_kernel_range(), resulting in missing TLB flushes and
>> consequent failures.
>>
>> Instead do a full invalidate in this case -- for now.
>>
>> Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>> Reported-by: "StDenis, Tom"
>> Signed-off-by: Peter Zijlstra (Intel)
>> ---
>> arch/x86/mm/pageattr.c | 24
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
>> index bac35001d896..61bc7d1800d7 100644
>> --- a/arch/x86/mm/pageattr.c
>> +++ b/arch/x86/mm/pageattr.c
>> @@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
>> on_each_cpu(__cpa_flush_all, (void *) cache, 1);
>> }
>> -static bool __cpa_flush_range(unsigned long start, int numpages, int
>> cache)
>> +static bool __inv_flush_all(int cache)
>> {
>> BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
>> - WARN_ON(PAGE_ALIGN(start) != start);
>> -
>> if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
>> cpa_flush_all(cache);
>> return true;
>> }
>> - flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
>> -
>> - return !cache;
>> + return false;
>> }
>> static void cpa_flush_range(unsigned long start, int numpages, int
>> cache)
>> @@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start,
>> int numpages, int cache)
>> unsigned int i, level;
>> unsigned long addr;
>> - if (__cpa_flush_range(start, numpages, cache))
>> + WARN_ON(PAGE_ALIGN(start) != start);
>> +
>> + if (__inv_flush_all(cache))
>> + return;
>> +
>> + flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
>> +
>> + if (!cache)
>> return;
>> /*
>> @@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr,
>> unsigned long *start,
>> {
>> unsigned int i, level;
>> - if (__cpa_flush_range(baddr, numpages, cache))
>> + if (__inv_flush_all(cache))
>> + return;
>> +
>> + flush_tlb_all();
>> +
>> + if (!cache)
>> return;
>> /*
>>
>
[PATCH 2/4] dmaengine: mic_x100_dma: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
drivers/dma/mic_x100_dma.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c
index adfd316db1a8..6a91e28d537d 100644
--- a/drivers/dma/mic_x100_dma.c
+++ b/drivers/dma/mic_x100_dma.c
@@ -676,7 +676,7 @@ static void mic_dma_dev_unreg(struct mic_dma_device
*mic_dma_dev)
}
/* DEBUGFS CODE */
-static int mic_dma_reg_seq_show(struct seq_file *s, void *pos)
+static int mic_dma_reg_show(struct seq_file *s, void *pos)
{
struct mic_dma_device *mic_dma_dev = s->private;
int i, chan_num, first_chan = mic_dma_dev->start_ch;
@@ -707,23 +707,7 @@ static int mic_dma_reg_seq_show(struct seq_file *s, void
*pos)
return 0;
}
-static int mic_dma_reg_debug_open(struct inode *inode, struct file *file)
-{
- return single_open(file, mic_dma_reg_seq_show, inode->i_private);
-}
-
-static int mic_dma_reg_debug_release(struct inode *inode, struct file *file)
-{
- return single_release(inode, file);
-}
-
-static const struct file_operations mic_dma_reg_ops = {
- .owner = THIS_MODULE,
- .open= mic_dma_reg_debug_open,
- .read= seq_read,
- .llseek = seq_lseek,
- .release = mic_dma_reg_debug_release
-};
+DEFINE_SHOW_ATTRIBUTE(mic_dma_reg);
/* Debugfs parent dir */
static struct dentry *mic_dma_dbg;
@@ -747,7 +731,7 @@ static int mic_dma_driver_probe(struct mbus_device *mbdev)
if (mic_dma_dev->dbg_dir)
debugfs_create_file("mic_dma_reg", 0444,
mic_dma_dev->dbg_dir, mic_dma_dev,
- &mic_dma_reg_ops);
+ &mic_dma_reg_fops);
}
return 0;
}
--
2.17.0
[PATCH 1/4] dmaengine: amba-pl08x: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
drivers/dma/amba-pl08x.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 97483df1f82e..fc8c2bab563c 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2505,24 +2505,14 @@ static int pl08x_debugfs_show(struct seq_file *s, void
*data)
return 0;
}
-static int pl08x_debugfs_open(struct inode *inode, struct file *file)
-{
- return single_open(file, pl08x_debugfs_show, inode->i_private);
-}
-
-static const struct file_operations pl08x_debugfs_operations = {
- .open = pl08x_debugfs_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(pl08x_debugfs);
static void init_pl08x_debugfs(struct pl08x_driver_data *pl08x)
{
/* Expose a simple debugfs interface to view all clocks */
(void) debugfs_create_file(dev_name(&pl08x->adev->dev),
S_IFREG | S_IRUGO, NULL, pl08x,
- &pl08x_debugfs_operations);
+ &pl08x_debugfs_fops);
}
#else
--
2.17.0
Re: [PATCH] dmaengine: remove DBGFS_FUNC_DECL()
On Wed, Dec 5, 2018 at 11:59 PM Vinod Koul wrote: > > On 05-12-18, 23:49, Frank Lee wrote: > > On Wed, Dec 5, 2018 at 4:27 PM Vinod Koul wrote: > > > > > > On 30-11-18, 10:42, Yangtao Li wrote: > > > > We already have the DEFINE_SHOW_ATTRIBUTE,There is no need to define > > > > such a macro,so remove DBGFS_FUNC_DECL.Also use macro to simplify some > > > > code. > > > > > > Spaces after full stop and comma please > > > > > > > > > > > Signed-off-by: Yangtao Li > > > > --- > > > > drivers/dma/amba-pl08x.c | 14 ++ > > > > drivers/dma/mic_x100_dma.c | 22 +++--- > > > > drivers/dma/pxa_dma.c| 24 > > > > drivers/dma/qcom/hidma_dbg.c | 33 ++--- > > > > > > Do you mind splitting it per file. > > Hi Vinod: > > > > Why not apply it once ？The change is not too big. > > It is not about big or small. A patch should do one thing and touch a > single module. > > It also helps people when they look at changes and backports. Already divided into small files, as you need. MBR, Yangtao > > -- > ~Vinod
Re: [PATCH] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
On Wed, 5 Dec 2018 at 17:11, Anand Moon wrote:
>
> Hi Krzysztof,
>
> Thanks for your review.
> .
> On Wed, 5 Dec 2018 at 19:36, Krzysztof Kozlowski wrote:
> >
> > On Tue, 4 Dec 2018 at 20:40, Anand Moon wrote:
> > >
> > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > during system suspend and also support changing the regulator operating
> > > mode during runtime and when the system enter sleep mode.
> > >
> > > Signed-off-by: Anand Moon
> > > ---
> > > Tested on Odroid U3+
> > > ---
> > > .../boot/dts/exynos4412-odroid-common.dtsi| 72 +++
> > > 1 file changed, 72 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > index 2caa3132f34e..837713a2ec3b 100644
> > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > @@ -285,6 +285,9 @@
> > > regulator-min-microvolt = <180>;
> > > regulator-max-microvolt = <180>;
> > > regulator-always-on;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + };
> >
> > Driver does not support suspend_enable so this will be noop. We could
> > add this for DT-correctness (and full description of HW) but then I
> > need explanation why this regulator has to stay on during suspend.
> >
>
> Well I tried to study the suspend/resume feature from
> *arch/arm/boot/dts/exynos4412-midas.dtsi*
> and them I tried to apply the same with this on Odroid-U3 boards and
> test these changes.
Midas DTSI clearly has bugs then.
>
> > > };
> > >
> > > ldo3_reg: LDO3 {
> > > @@ -292,6 +295,9 @@
> > > regulator-min-microvolt = <180>;
> > > regulator-max-microvolt = <180>;
> > > regulator-always-on;
> > > + regulator-state-mem {
> > > + regulator-off-in-suspend;
> > > + };
> >
> > The same but with suspend_disable.
> >
> > I am not saying that these are wrong but I would be happy to see
> > explanations why you chosen these particular properties.
> >
>
> Well I was not aware on the regulator-always-on cannot be set to off
> in suspend mode.
> Will drop this in the future patch where regulator-always-on; is set.
>
> > > };
> > >
> > > ldo4_reg: LDO4 {
> > > @@ -299,6 +305,9 @@
> > > regulator-min-microvolt = <280>;
> > > regulator-max-microvolt = <280>;
> > > regulator-boot-on;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + };
> > > };
> > >
> > > ldo5_reg: LDO5 {
> > > @@ -307,6 +316,9 @@
> > > regulator-max-microvolt = <180>;
> > > regulator-always-on;
> > > regulator-boot-on;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + };
> > > };
> > >
> > > ldo6_reg: LDO6 {
> > > @@ -314,6 +326,9 @@
> > > regulator-min-microvolt = <100>;
> > > regulator-max-microvolt = <100>;
> > > regulator-always-on;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + };
> > > };
> > >
> > > ldo7_reg: LDO7 {
> > > @@ -321,18 +336,27 @@
> > > regulator-min-microvolt = <100>;
> > > regulator-max-microvolt = <100>;
> > > regulator-always-on;
> > > + regulator-state-mem {
> > > + regulator-on-in-suspend;
> > > + };
> > > };
> > >
> > > ldo8_reg: LDO8 {
> > > regulator-name = "VDD10_HDMI_1.0V";
> > > regulator-min-microvolt = <100>;
> > > regulator-max-microvolt = <100>;
> > > + regulator-state-mem {
> > > +
[PATCH 3/4] dmaengine: pxa: remove DBGFS_FUNC_DECL()
We already have the DEFINE_SHOW_ATTRIBUTE, There is no need to define
such a macro, so remove DBGFS_FUNC_DECL.
Signed-off-by: Yangtao Li
Acked-by: Robert Jarzmik
---
drivers/dma/pxa_dma.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 825725057e00..e78fe98b5cf1 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -189,7 +189,7 @@ bool pxad_filter_fn(struct dma_chan *chan, void *param);
#include
#include
-static int dbg_show_requester_chan(struct seq_file *s, void *p)
+static int requester_chan_show(struct seq_file *s, void *p)
{
struct pxad_phy *phy = s->private;
int i;
@@ -220,7 +220,7 @@ static int is_phys_valid(unsigned long addr)
#define PXA_DCSR_STR(flag) (dcsr & PXA_DCSR_##flag ? #flag" " : "")
#define PXA_DCMD_STR(flag) (dcmd & PXA_DCMD_##flag ? #flag" " : "")
-static int dbg_show_descriptors(struct seq_file *s, void *p)
+static int descriptors_show(struct seq_file *s, void *p)
{
struct pxad_phy *phy = s->private;
int i, max_show = 20, burst, width;
@@ -263,7 +263,7 @@ static int dbg_show_descriptors(struct seq_file *s, void *p)
return 0;
}
-static int dbg_show_chan_state(struct seq_file *s, void *p)
+static int chan_state_show(struct seq_file *s, void *p)
{
struct pxad_phy *phy = s->private;
u32 dcsr, dcmd;
@@ -306,7 +306,7 @@ static int dbg_show_chan_state(struct seq_file *s, void *p)
return 0;
}
-static int dbg_show_state(struct seq_file *s, void *p)
+static int state_show(struct seq_file *s, void *p)
{
struct pxad_device *pdev = s->private;
@@ -317,22 +317,10 @@ static int dbg_show_state(struct seq_file *s, void *p)
return 0;
}
-#define DBGFS_FUNC_DECL(name) \
-static int dbg_open_##name(struct inode *inode, struct file *file) \
-{ \
- return single_open(file, dbg_show_##name, inode->i_private); \
-} \
-static const struct file_operations dbg_fops_##name = { \
- .open = dbg_open_##name, \
- .llseek = seq_lseek, \
- .read = seq_read, \
- .release= single_release, \
-}
-
-DBGFS_FUNC_DECL(state);
-DBGFS_FUNC_DECL(chan_state);
-DBGFS_FUNC_DECL(descriptors);
-DBGFS_FUNC_DECL(requester_chan);
+DEFINE_SHOW_ATTRIBUTE(state);
+DEFINE_SHOW_ATTRIBUTE(chan_state);
+DEFINE_SHOW_ATTRIBUTE(descriptors);
+DEFINE_SHOW_ATTRIBUTE(requester_chan);
static struct dentry *pxad_dbg_alloc_chan(struct pxad_device *pdev,
int ch, struct dentry *chandir)
@@ -348,13 +336,13 @@ static struct dentry *pxad_dbg_alloc_chan(struct
pxad_device *pdev,
if (chan)
chan_state = debugfs_create_file("state", 0400, chan, dt,
-&dbg_fops_chan_state);
+&chan_state_fops);
if (chan_state)
chan_descr = debugfs_create_file("descriptors", 0400, chan, dt,
-&dbg_fops_descriptors);
+&descriptors_fops);
if (chan_descr)
chan_reqs = debugfs_create_file("requesters", 0400, chan, dt,
- &dbg_fops_requester_chan);
+ &requester_chan_fops);
if (!chan_reqs)
goto err_state;
@@ -375,7 +363,7 @@ static void pxad_init_debugfs(struct pxad_device *pdev)
goto err_root;
pdev->dbgfs_state = debugfs_create_file("state", 0400, pdev->dbgfs_root,
- pdev, &dbg_fops_state);
+ pdev, &state_fops);
if (!pdev->dbgfs_state)
goto err_state;
--
2.17.0
[PATCH 4/4] dmaengine: qcom_hidma: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
Acked-by: Sinan Kaya
---
drivers/dma/qcom/hidma_dbg.c | 33 ++---
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
index 3bdcb8056a36..9523faf7acdc 100644
--- a/drivers/dma/qcom/hidma_dbg.c
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -85,11 +85,11 @@ static void hidma_ll_devstats(struct seq_file *s, void
*llhndl)
}
/*
- * hidma_chan_stats: display HIDMA channel statistics
+ * hidma_chan_show: display HIDMA channel statistics
*
* Display the statistics for the current HIDMA virtual channel device.
*/
-static int hidma_chan_stats(struct seq_file *s, void *unused)
+static int hidma_chan_show(struct seq_file *s, void *unused)
{
struct hidma_chan *mchan = s->private;
struct hidma_desc *mdesc;
@@ -117,11 +117,11 @@ static int hidma_chan_stats(struct seq_file *s, void
*unused)
}
/*
- * hidma_dma_info: display HIDMA device info
+ * hidma_dma_show: display HIDMA device info
*
* Display the info for the current HIDMA device.
*/
-static int hidma_dma_info(struct seq_file *s, void *unused)
+static int hidma_dma_show(struct seq_file *s, void *unused)
{
struct hidma_dev *dmadev = s->private;
resource_size_t sz;
@@ -138,29 +138,8 @@ static int hidma_dma_info(struct seq_file *s, void *unused)
return 0;
}
-static int hidma_chan_stats_open(struct inode *inode, struct file *file)
-{
- return single_open(file, hidma_chan_stats, inode->i_private);
-}
-
-static int hidma_dma_info_open(struct inode *inode, struct file *file)
-{
- return single_open(file, hidma_dma_info, inode->i_private);
-}
-
-static const struct file_operations hidma_chan_fops = {
- .open = hidma_chan_stats_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static const struct file_operations hidma_dma_fops = {
- .open = hidma_dma_info_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(hidma_chan);
+DEFINE_SHOW_ATTRIBUTE(hidma_dma);
void hidma_debug_uninit(struct hidma_dev *dmadev)
{
--
2.17.0
Re: [PATCH 00/19] mailbox: Device-managed registration
On Wed, Nov 28, 2018 at 10:39:50AM +0100, Thierry Reding wrote: > On Wed, Nov 21, 2018 at 03:54:10PM +0100, Thierry Reding wrote: > > From: Thierry Reding > > > > Hi, > > > > This series of patches adds device-managed registration functions for > > mailbox controllers. A number of drivers can be simplified by making use > > of this new API both in the error cleanup paths in their probe functions > > and in the driver remove implementation. > > > > In addition to adding the new API this series converts all drivers to > > use it. There is also an additional cleanup patch for the mtk-cmdq > > driver that removes some calls to devm_kfree() that are not needed. > > > > Thierry > > > > Thierry Reding (19): > > mailbox: Add device-managed registration functions > > mailbox: arm-mhu: Use device-managed registration API > > mailbox: bcm2835: Use device-managed registration API > > mailbox: bcm-flexrm: Use device-managed registration API > > mailbox: bcm-pdc: Use device-managed registration API > > mailbox: hi3660: Use device-managed registration API > > mailbox: hi6220: Use device-managed registration API > > mailbox: imx: Use device-managed registration API > > mailbox: altera: Use device-managed registration API > > mailbox: sti: Use device-managed registration API > > mailbox: xgene-slimpro: Use device-managed registration API > > mailbox: mtk-cmdq: Use device-managed registration API > > mailbox: mtk-cmdq: Remove needless devm_kfree() calls > > mailbox: omap: Use device-managed registration API > > mailbox: platform-mhu: Use device-managed registration API > > mailbox: qcom-apcs: Use device-managed registration API > > mailbox: rockchip: Use device-managed registration API > > mailbox: stm32-ipcc: Use device-managed registration API > > mailbox: ti-msgmgr: Use device-managed registration API > > > > drivers/mailbox/arm_mhu.c | 12 + > > drivers/mailbox/bcm-flexrm-mailbox.c| 4 +- > > drivers/mailbox/bcm-pdc-mailbox.c | 4 +- > > drivers/mailbox/bcm2835-mailbox.c | 10 +--- > > drivers/mailbox/hi3660-mailbox.c| 11 +--- > > drivers/mailbox/hi6220-mailbox.c| 11 +--- > > drivers/mailbox/imx-mailbox.c | 3 +- > > drivers/mailbox/mailbox-altera.c| 15 +- > > drivers/mailbox/mailbox-sti.c | 13 + > > drivers/mailbox/mailbox-xgene-slimpro.c | 11 +--- > > drivers/mailbox/mailbox.c | 70 + > > drivers/mailbox/mtk-cmdq-mailbox.c | 11 +--- > > drivers/mailbox/omap-mailbox.c | 4 +- > > drivers/mailbox/platform_mhu.c | 12 + > > drivers/mailbox/qcom-apcs-ipc-mailbox.c | 3 +- > > drivers/mailbox/rockchip-mailbox.c | 15 +- > > drivers/mailbox/stm32-ipcc.c| 4 +- > > drivers/mailbox/ti-msgmgr.c | 13 + > > include/linux/mailbox_controller.h | 5 ++ > > 19 files changed, 92 insertions(+), 139 deletions(-) > > Hi Jassi, > > any comments on this? Ping! Thierry signature.asc Description: PGP signature
Re: linux-next: manual merge of the selinux tree with the vfs tree
On Wed, Dec 05, 2018 at 10:37:56AM +0100, Ondrej Mosnacek wrote: > I just tested the Q28 branch rebased onto a recent Fedora rawhide > kernel (4.20.0-0.rc5.git0.1) and that code seems to be working fine. > The submount test failed with Q28 and succeeds with Q28+fix, as > expected. Also, the overlay tests failures are gone now (except for > the 4 known failures from GH issue #43, since I had to rebase onto > 4.20-rcX). > > This is the commit that I used as the SELinux submount fix: > https://gitlab.com/omos/linux-public/commit/47922f9c70a83008388b836c285f94c40da1af2b FWIW, I'm none too happy about the fix. Observations: * sb_get_tree (and sb_kern_mount past the "LSM: lift parsing LSM options into the caller of ->sb_kern_mount()" in this series) is equivalent to sb_set_mnt_opts() + (for userland mounts) an selinux-only MAC check. IOW, application of options (for LSMs that have those in the first place) + actual "are we permitted to mount that?" check. * the second part should be done only for userland mounts - not automounting, not kernel-internal ones, etc. * a very common pattern is "vfs_get_tree, vfs_create_mount if we hadn't failed that, then unconditional put_fs_context". So much that it clearly deserves a helper - too much boilerplate as it is. * look at the callers of vfs_get_tree(): 1) afs_mntpt_do_automount(): submount, helper fodder. No MAC. 2) nfs_do_submount(): submount, standalone, but caller will very shortly follow with the rest of the helper. No MAC. 3) btrfs_mount_root(): helper fodder, cloned context, probably no point in the actual MAC - we are in ->get_tree(), the caller will decide if it wants to bother. 4) do_nfs4_mount(): NFS counterpart of the above. 5) mount_one_hugetlbfs(): kernel-internal, helper fodder, no MAC. 6) pid_ns_prepare_proc(): kernel-internal, helper fodder, no MAC. 7) mq_create_mount(): kernel-internal, helper fodder, no MAC. 8) do_new_mount(): almost a helper fodder, wants MAC (mount(2) guts) 9) fsopen(2): standalone, wants MAC (it's mount(2)-equivalent) 10) vfs_kern_mount(): that's a bit more complicated. It is, again, a helper fodder. The need of MAC depends upon the caller, in theory. Callers: simple_pin_fs() - kernel-internal, no MAC init_mount_tree() - no MAC, that's the absolute root and that, by definition, is much too early in the boot (before initramfs, etc.) for any LSM shite to be applicable. In any case, it's done by the kernel. kern_mount() - kernel-internal, no MAC cpuset_get_tree() - part of ->get_tree(), caller will decide if they want the damn MAC. vfs_submount() - automounts, presumably no MAC. Conclusion: fuck the MAC in vfs_get_tree(). Let's just lift it into do_new_mount()/fsopen(). The only thing we really need there is to keep ->s_umount held (exclusive) until after the MAC. So let vfs_get_tree() return with fc->root->d_sb->s_umount locked and have mount_create_mount() (which is _always_ preceded by successful vfs_get_tree()), unlock the sucker. In vfs_get_tree() we need to do sb_set_mnt_opts(), with the rest of it (selinux-only) called by do_new_mount()/fsopen(2). All there is to it...
Re: [PATCH v6 1/3] staging: mt7621-mmc: Remove #if 0 blocks in sd.c
On Sun, Nov 18, 2018 at 08:33:03AM +1100, NeilBrown wrote:
> On Thu, Oct 04 2018, Nishad Kamdar wrote:
>
> > This patch removes #if 0 code blocks and usages of
> > functions defined in the #if 0 blocks in sd.c.
> >
> > Signed-off-by: Nishad Kamdar
>
> Hi Nishad,
> thanks for this patch (and others) and apologies for not
> reviewing/testing it earlier.
> Unfortunately there is a problem - see below.
>
> >
> > -#if 0 /* --- by chhung */
> > -/* For E2 only */
> > -static u8 clk_src_bit[4] = {
> > - 0, 3, 5, 7
> > -};
> > -
> > static void msdc_select_clksrc(struct msdc_host *host, unsigned char
> > clksrc)
> > {
> > u32 val;
>
> Above you removed the first few lines of a "#if 0" block, but not all of
> it. Previously the function msdc_select_clksrc() was not compiled at
> all. Now it is, and that causes an error - MSDC_CLKSRC_REG is not
> defined.
>
> Would you be able to send a follow-patch patch which removes this
> function and the "#endif /* end of --- */" at the end?
>
> Thanks,
> NeilBrown
Sure, I'll send the updated patch.
Thanks for the review.
Regards,
Nishad
Re: [PATCH v10 1/7] interconnect: Add generic on-chip interconnect API
On Tue, Nov 27, 2018 at 12:03 PM Georgi Djakov wrote: > > This patch introduces a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current > demand. > > The API is using a consumer/provider-based model, where the providers are > the interconnect buses and the consumers could be various drivers. > The consumers request interconnect resources (path) between endpoints and > set the desired constraints on this data flow path. The providers receive > requests from consumers and aggregate these requests for all master-slave > pairs on that path. Then the providers configure each participating in the > topology node according to the requested data flow path, physical links and > constraints. The topology could be complicated and multi-tiered and is SoC > specific. > > Signed-off-by: Georgi Djakov > Reviewed-by: Evan Green [...] > +struct icc_path *icc_get(struct device *dev, const int src_id, > +const int dst_id); > +void icc_put(struct icc_path *path); > +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw); icc_set() is very generic, but this function isn't easily extended to other parameters than bandwidth. Perhaps icc_set_bandwidth() instead. Then when you add some other setting, you just add a new function. Of course, if you wind up with a bunch of different parameters, then you'll probably need an atomic type interface where you test all the settings together and then commit them separately in one call. But from a DT perspective, I certainly hope there are not lots of new settings folks want to add. :) Rob
[PATCH] staging: mt7621-mmc: Remove missed lines of the #if 0 block in sd.c
The below patch
https://lore.kernel.org/patchwork/patch/995533/
does not completely remove an #if 0 block in sd.c.
This causes the function msdc_select_clksrc()
which was earler not compiled, to be compiled.
That causes an error - MSDC_CLKSRC_REG is not
defined.
This patch completely removes the #if 0 block
Signed-off-by: Nishad Kamdar
---
drivers/staging/mt7621-mmc/sd.c | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 7b66f9b0a094..3d918e481bd8 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -216,26 +216,6 @@ static void msdc_tasklet_card(struct work_struct *work)
spin_unlock(&host->lock);
}
-static void msdc_select_clksrc(struct msdc_host *host, unsigned char clksrc)
-{
- u32 val;
-
- BUG_ON(clksrc > 3);
-
- val = readl(host->base + MSDC_CLKSRC_REG);
- if (readl(host->base + MSDC_ECO_VER) >= 4) {
- val &= ~(0x3 << clk_src_bit[host->id]);
- val |= clksrc << clk_src_bit[host->id];
- } else {
- val &= ~0x3; val |= clksrc;
- }
- writel(val, host->base + MSDC_CLKSRC_REG);
-
- host->hclk = hclks[clksrc];
- host->hw->clk_src = clksrc;
-}
-#endif /* end of --- */
-
static void msdc_set_mclk(struct msdc_host *host, int ddr, unsigned int hz)
{
//struct msdc_hw *hw = host->hw;
--
2.17.1
Re: [BUG BISECT] Missing MTD NAND partitions - mtd: rawnand: Move the ->exec_op() method to nand_controller_ops
Hi Krzysztof,
Krzysztof Kozlowski wrote on Wed, 5 Dec 2018 17:10:38
+0100:
> On Tue, 20 Nov 2018 at 13:15, Krzysztof Kozlowski wrote:
> >
> > On Tue, 20 Nov 2018 at 13:09, Boris Brezillon
> > wrote:
> > >
> > > On Tue, 20 Nov 2018 12:48:46 +0100
> > > Krzysztof Kozlowski wrote:
> > >
> > > > On Tue, 20 Nov 2018 at 11:33, Miquel Raynal
> > > > wrote:
> > > > >
> > > > > Hi Krzysztof,
> > > > >
> > > > > Krzysztof Kozłowski wrote on Tue, 20 Nov
> > > > > 2018
> > > > > 10:46:33 +0100:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Since few days linux-next has problem on Freescale VF500 - MTD seems
> > > > > > to be broken.
> > > > > >
> > > > > > Bisect pointed me to commit 7c27338c728e39ef47c83d101959aa332506969d
> > > > > > ("mtd: rawnand: Move the ->exec_op() method to nand_controller_ops")
> > > > > > as reason of failure to find MTD partitions.
> > > > > >
> > > > > > Toradex Colibri VF50 on Iris board (ARMv7, UP, Cortext-A5, NXP
> > > > > > VF500,
> > > > > > 128 MB RAM, 128 MB NAND, Systemd: v232) booted from NFS root (NFSv4)
> > > > > > trying to mount UBIFS from NAND/MTD. Board uses VF610 NAND driver.
> > > > > >
> > > > > > The MTD partitions are missing entirely (nothing under /dev/mtd).
> > > > > > In the logs you can also see:
> > > > > > [1.232161] UBI error: cannot open mtd ubi2, error -2
> > > > > >
> > > > > > Attached - dmesg.log
> > > > > >
> > > > > > Let me know if you need defconfig or any other information.
> > > > >
> > > > > Thank you very much for testing and reporting the bug!
> > > > >
> > > > > Could you please test with this diff applied [1] please? We discussed
> > > > > with Boris and we think it should fix your setup (and all others also
> > > > > impacted).
> > > > >
> > > > > [1] http://code.bulix.org/r1m99i-509201
> > > >
> > > > error: patch failed: drivers/mtd/nand/raw/nand_base.c:4399
> > > > error: drivers/mtd/nand/raw/nand_base.c: patch does not apply
> > > >
> > > > Maybe you have a git tree with this somewhere?
> > >
> > > Yep: https://github.com/bbrezillon/linux/tree/nand/next-fix
> >
> > Works fine now, thanks!
> > Tested-by: Krzysztof Kozlowski
>
> Although the patch fixed the issue... but it seems it is not in
> linux-next. The next is broken since almost two weeks.
>
Sorry, this is definitely in my TODO list, I need to put the NAND
branch in shape this week anyway.
Thanks,
Miquèl
Re: [BUG BISECT] Missing MTD NAND partitions - mtd: rawnand: Move the ->exec_op() method to nand_controller_ops
On Tue, 20 Nov 2018 at 13:15, Krzysztof Kozlowski wrote:
>
> On Tue, 20 Nov 2018 at 13:09, Boris Brezillon
> wrote:
> >
> > On Tue, 20 Nov 2018 12:48:46 +0100
> > Krzysztof Kozlowski wrote:
> >
> > > On Tue, 20 Nov 2018 at 11:33, Miquel Raynal
> > > wrote:
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > Krzysztof Kozłowski wrote on Tue, 20 Nov 2018
> > > > 10:46:33 +0100:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Since few days linux-next has problem on Freescale VF500 - MTD seems
> > > > > to be broken.
> > > > >
> > > > > Bisect pointed me to commit 7c27338c728e39ef47c83d101959aa332506969d
> > > > > ("mtd: rawnand: Move the ->exec_op() method to nand_controller_ops")
> > > > > as reason of failure to find MTD partitions.
> > > > >
> > > > > Toradex Colibri VF50 on Iris board (ARMv7, UP, Cortext-A5, NXP VF500,
> > > > > 128 MB RAM, 128 MB NAND, Systemd: v232) booted from NFS root (NFSv4)
> > > > > trying to mount UBIFS from NAND/MTD. Board uses VF610 NAND driver.
> > > > >
> > > > > The MTD partitions are missing entirely (nothing under /dev/mtd).
> > > > > In the logs you can also see:
> > > > > [1.232161] UBI error: cannot open mtd ubi2, error -2
> > > > >
> > > > > Attached - dmesg.log
> > > > >
> > > > > Let me know if you need defconfig or any other information.
> > > >
> > > > Thank you very much for testing and reporting the bug!
> > > >
> > > > Could you please test with this diff applied [1] please? We discussed
> > > > with Boris and we think it should fix your setup (and all others also
> > > > impacted).
> > > >
> > > > [1] http://code.bulix.org/r1m99i-509201
> > >
> > > error: patch failed: drivers/mtd/nand/raw/nand_base.c:4399
> > > error: drivers/mtd/nand/raw/nand_base.c: patch does not apply
> > >
> > > Maybe you have a git tree with this somewhere?
> >
> > Yep: https://github.com/bbrezillon/linux/tree/nand/next-fix
>
> Works fine now, thanks!
> Tested-by: Krzysztof Kozlowski
Although the patch fixed the issue... but it seems it is not in
linux-next. The next is broken since almost two weeks.
Best regards,
Krzysztof
Re: [PATCH] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi Krzysztof,
Thanks for your review.
.
On Wed, 5 Dec 2018 at 19:36, Krzysztof Kozlowski wrote:
>
> On Tue, 4 Dec 2018 at 20:40, Anand Moon wrote:
> >
> > Add suspend-to-mem node to regulator core to be enabled or disabled
> > during system suspend and also support changing the regulator operating
> > mode during runtime and when the system enter sleep mode.
> >
> > Signed-off-by: Anand Moon
> > ---
> > Tested on Odroid U3+
> > ---
> > .../boot/dts/exynos4412-odroid-common.dtsi| 72 +++
> > 1 file changed, 72 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > index 2caa3132f34e..837713a2ec3b 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -285,6 +285,9 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <180>;
> > regulator-always-on;
> > + regulator-state-mem {
> > + regulator-on-in-suspend;
> > + };
>
> Driver does not support suspend_enable so this will be noop. We could
> add this for DT-correctness (and full description of HW) but then I
> need explanation why this regulator has to stay on during suspend.
>
Well I tried to study the suspend/resume feature from
*arch/arm/boot/dts/exynos4412-midas.dtsi*
and them I tried to apply the same with this on Odroid-U3 boards and
test these changes.
> > };
> >
> > ldo3_reg: LDO3 {
> > @@ -292,6 +295,9 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <180>;
> > regulator-always-on;
> > + regulator-state-mem {
> > + regulator-off-in-suspend;
> > + };
>
> The same but with suspend_disable.
>
> I am not saying that these are wrong but I would be happy to see
> explanations why you chosen these particular properties.
>
Well I was not aware on the regulator-always-on cannot be set to off
in suspend mode.
Will drop this in the future patch where regulator-always-on; is set.
> > };
> >
> > ldo4_reg: LDO4 {
> > @@ -299,6 +305,9 @@
> > regulator-min-microvolt = <280>;
> > regulator-max-microvolt = <280>;
> > regulator-boot-on;
> > + regulator-state-mem {
> > + regulator-on-in-suspend;
> > + };
> > };
> >
> > ldo5_reg: LDO5 {
> > @@ -307,6 +316,9 @@
> > regulator-max-microvolt = <180>;
> > regulator-always-on;
> > regulator-boot-on;
> > + regulator-state-mem {
> > + regulator-on-in-suspend;
> > + };
> > };
> >
> > ldo6_reg: LDO6 {
> > @@ -314,6 +326,9 @@
> > regulator-min-microvolt = <100>;
> > regulator-max-microvolt = <100>;
> > regulator-always-on;
> > + regulator-state-mem {
> > + regulator-on-in-suspend;
> > + };
> > };
> >
> > ldo7_reg: LDO7 {
> > @@ -321,18 +336,27 @@
> > regulator-min-microvolt = <100>;
> > regulator-max-microvolt = <100>;
> > regulator-always-on;
> > + regulator-state-mem {
> > + regulator-on-in-suspend;
> > + };
> > };
> >
> > ldo8_reg: LDO8 {
> > regulator-name = "VDD10_HDMI_1.0V";
> > regulator-min-microvolt = <100>;
> > regulator-max-microvolt = <100>;
> > + regulator-state-mem {
> > + regulator-off-in-suspend;
> > + };
> > };
> >
> > ldo10_reg: LDO10 {
> > regulator-name = "VDDQ_MIPIHSI_1.8V";
> > regulator-min-microvolt = <180
Re: [PATCH v3 5/5] clk: samsung: exynos5433: add imem clocks
Quoting Sylwester Nawrocki (2018-12-05 02:57:32)
> On 12/4/18 19:40, Stephen Boyd wrote:
> > Quoting Kamil Konieczny (2018-12-04 08:52:48)
> >> +
> >> +static const unsigned long imem_clk_regs[] __initconst = {
> >> + ENABLE_ACLK_IMEM,
> >> + ENABLE_ACLK_IMEM_INT_MEM,
> >> + ENABLE_ACLK_IMEM_SSS,
> >> + ENABLE_ACLK_IMEM_SLIMSSS,
> >> + ENABLE_ACLK_IMEM_RTIC,
> >> + ENABLE_ACLK_IMEM_SMMU_SSS,
> >> + ENABLE_ACLK_IMEM_SMMU_SLIMSSS,
> >> + ENABLE_ACLK_IMEM_SMMU_RTIC,
> >> + ENABLE_ACLK_IMEM_ARBG_TX,
> >> + ENABLE_ACLK_IMEM_SMMU_ARBG_TX,
> >> + ENABLE_PCLK_IMEM,
> >> + ENABLE_PCLK_IMEM_SSS,
> >> + ENABLE_PCLK_IMEM_SLIMSSS,
> >> + ENABLE_PCLK_IMEM_RTIC,
> >> + ENABLE_PCLK_IMEM_SMMU_SSS,
> >> + ENABLE_PCLK_IMEM_SMMU_SLIMSSS,
> >> + ENABLE_PCLK_IMEM_SMMU_RTIC,
> >> + ENABLE_PCLK_IMEM_SMMU_ARGB_TX,
> >> +};
> >> +
> >> +static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
> >> + /* ENABLE_ACLK_IMEM */
> >> + GATE(CLK_ACLK_AXI2AHB_IMEMH, "aclk_axi2ahb_imemh", "aclk_imem_200",
> >> + ENABLE_ACLK_IMEM, 24, 0, 0),
>
> I don't think that clock will ever need to be disabled/enabled, so I would
> drop this definition. The clock will remain in its default state after reset
> (enabled).
>
> >> + GATE(CLK_ACLK_AXIDS_SROMC, "aclk_axids_sromc", "aclk_imem_200",
> >> + ENABLE_ACLK_IMEM, 23, CLK_IGNORE_UNUSED, 0),
> >
> > Why is there so much use of CLK_IGNORE_UNUSED in this file?
>
> I suppose CLK_IGNORE_UNUSED is needed because there is no drivers that
> would enable required clocks. For some clocks the flag could probably
> indeed just be omitted, e.g. SLIMSSS clocks.
>
> I'm inclined to just define clocks that we are confident about and which
> are needed now. i.e. the SSS IP block clocks. So in include/dt-bindings/
> clock/exynos5433.h we would have something like:
Agreed, it doesn't make much sense to add clk support for clks that
you'll never need to modify one way or the other.
>
> +/* CMU_IMEM */
> +#define CLK_ACLK_SSS 1
> +#define CLK_PCLK_SSS 40
>
> +#define IMEM_NR_CLK41
>
> The other clocks could be added later as needed by someone who has
> detailed knowledge about respective peripheral blocks.
>
The slow addition of new clks to the binding header file makes for an
integration problem, so can we try to expose any clks that we know about
now as defines and make them not work if the driver isn't implementing
support for those clks? That way the binding is not changing but the
implementation can decide to support or not support certain clks.
Re: [PATCH] iommu: fix amd_iommu=force_isolation
On Tue, Dec 04, 2018 at 03:37:16PM -0700, Yu Zhao wrote:
> The parameter is still there but it's ignored. We need to check its
> value before deciding to go into passthrough mode for AMD IOMMU.
>
> Fixes: aafd8ba0ca74 ("iommu/amd: Implement add_device and remove_device")
>
> Signed-off-by: Yu Zhao
> ---
> drivers/iommu/amd_iommu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 1167ff0416cf..3e4219e6cff0 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -2195,7 +2195,8 @@ static int amd_iommu_add_device(struct device *dev)
>
> BUG_ON(!dev_data);
>
> - if (iommu_pass_through || dev_data->iommu_v2)
> + if (iommu_pass_through ||
> + (!amd_iommu_force_isolation && dev_data->iommu_v2))
This breaks the iommu_v2 use-case, as it needs a direct mapping for the
devices that support it.
I think the force_isolation parameter does not make sense anymore today
and should be removed.
Regards,
Joerg
Re: [RFC PATCH 00/14] Heterogeneous Memory System (HMS) and hbind()
On Wed, Dec 05, 2018 at 04:57:17PM +0530, Aneesh Kumar K.V wrote: > On 12/5/18 12:19 AM, Jerome Glisse wrote: > > > Above example is for migrate. Here is an example for how the > > topology is use today: > > > > Application knows that the platform is running on have 16 > > GPU split into 2 group of 8 GPUs each. GPU in each group can > > access each other memory with dedicated mesh links between > > each others. Full speed no traffic bottleneck. > > > > Application splits its GPU computation in 2 so that each > > partition runs on a group of interconnected GPU allowing > > them to share the dataset. > > > > With HMS: > > Application can query the kernel to discover the topology of > > system it is running on and use it to partition and balance > > its workload accordingly. Same application should now be able > > to run on new platform without having to adapt it to it. > > > > Will the kernel be ever involved in decision making here? Like the scheduler > will we ever want to control how there computation units get scheduled onto > GPU groups or GPU? I don;t think you will ever see fine control in software because it would go against what GPU are fundamentaly. GPU have 1000 of cores and usualy 10 times more thread in flight than core (depends on the number of register use by the program or size of their thread local storage). By having many more thread in flight the GPU always have some threads that are not waiting for memory access and thus always have something to schedule next on the core. This scheduling is all done in real time and i do not see that as a good fit for any kernel CPU code. That being said higher level and more coarse directive can be given to the GPU hardware scheduler like giving priorities to group of thread so that they always get schedule first if ready. There is a cgroup proposal that goes into the direction of exposing high level control over GPU resource like that. I think this is a better venue to discuss such topics. > > > This is kind of naive i expect topology to be hard to use but maybe > > it is just me being pesimistics. In any case today we have a chicken > > and egg problem. We do not have a standard way to expose topology so > > program that can leverage topology are only done for HPC where the > > platform is standard for few years. If we had a standard way to expose > > the topology then maybe we would see more program using it. At very > > least we could convert existing user. > > > > > > I am wondering whether we should consider HMAT as a subset of the ideas > mentioned in this thread and see whether we can first achieve HMAT > representation with your patch series? I do not want to block HMAT on that. What i am trying to do really does not fit in the existing NUMA node this is what i have been trying to show even if not everyone is convince by that. Some bulets points of why: - memory i care about is not accessible by everyone (backed in assumption in NUMA node) - memory i care about might not be cache coherent (again backed in assumption in NUMA node) - topology matter so that userspace knows what inter-connect is share and what have dedicated links to memory - their can be multiple path between one device and one target memory and each path have different numa distance (or rather properties like bandwidth, latency, ...) again this is does not fit with the NUMA distance thing - memory is not manage by core kernel for reasons i hav explained - ... The HMAT proposal does not deal with such memory, it is much more close to what the current model can describe. Cheers, Jérôme
[RFC 1/8] perf: Block perf calls for system call tracepoints
hi, Steven asked for possibility to block traced process in case the tracer can't keep up and we would loose events. This (RFC) patchset tries to implement this by adding 'block' bool in struct perf_event_attr to be set only for syscalls tracepoints and adding code to block the traced process, if there's no space in event's ring buffer. The blocking code will poll/periodically check for the space and continue if the event was successfully written. Available also here: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/block Thoughts? thanks, jirka --- Jiri Olsa (8): perf: Allow to block process in syscall tracepoints perf tools: Sync uapi perf_event.h perf record: Add --block option perf trace: Add --block option perf tools: Add block term support for tracepoints perf tools: Add ordered_events__flush_time interface perf trace: Move event delivery to deliver_event function perf trace: Add ordered processing for --block option arch/x86/entry/common.c | 36 ++-- include/linux/perf_event.h| 2 ++ include/linux/sched.h | 2 ++ include/linux/syscalls.h | 2 ++ include/uapi/linux/perf_event.h | 3 ++- kernel/events/core.c | 40 ++-- kernel/events/ring_buffer.c | 4 +++- kernel/trace/trace_event_perf.c | 4 kernel/trace/trace_syscalls.c | 28 tools/include/uapi/linux/perf_event.h | 3 ++- tools/perf/builtin-record.c | 9 + tools/perf/builtin-trace.c| 97 - tools/perf/perf.h | 1 + tools/perf/util/evsel.c | 7 +++ tools/perf/util/evsel.h | 2 ++ tools/perf/util/ordered-events.c | 34 ++ tools/perf/util/ordered-events.h | 3 +++ tools/perf/util/parse-events.c| 8 tools/perf/util/parse-events.h| 1 + tools/perf/util/parse-events.l| 1 + 20 files changed, 263 insertions(+), 24 deletions(-)
Re: [PATCH 4.19 000/139] 4.19.7-stable review
On Wed, Dec 5, 2018 at 4:08 AM Rafael David Tinoco wrote: > > On 12/5/18 4:58 AM, Greg Kroah-Hartman wrote: > > On Tue, Dec 04, 2018 at 07:09:46PM -0200, Rafael David Tinoco wrote: > >> On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote: > >>> This is the start of the stable review cycle for the 4.19.7 release. > >>> There are 139 patches in this series, all will be posted as a response > >>> to this one. If anyone has any issues with these being applied, please > >>> let me know. > >>> > >>> Responses should be made by Thu Dec 6 10:36:22 UTC 2018. > >>> Anything received after that time might be too late. > >>> > >>> The whole patch series can be found in one patch at: > >>> > >>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz > >>> or in the git tree and branch at: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > >>> linux-4.19.y > >>> and the diffstat can be found below. > >>> > >>> thanks, > >>> > >>> greg k-h > >> > >> During functional tests for this v4.19 release, we faced a PANIC, > >> described bellow, but unlikely related to this specific v4.19 version. > >> > >> First a WARN() at tcp_output.c: > >> > >> tcp_send_loss_probe(): > >> ... > >> /* Retransmit last segment. */ > >> if (WARN_ON(!skb)) > >> goto rearm_timer; > >> ... > >> > >> [ 173.557528] WARNING: CPU: 1 PID: 0 at > >> /srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485 > >> tcp_send_loss_probe+0x164/0x1e8 > >> [ 173.571425] Modules linked in: crc32_ce crct10dif_ce fuse > >> [ 173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1 > >> [ 173.583014] Hardware name: ARM Juno development board (r2) (DT) > > > > So only this one machine saw this failure? > > > > If you can reproduce it again, bisection would be great to do if > > possible. > > Yes, the only machine... I'm afraid this issue is intermittent and > depends on TCP Tail Loss and a specific race causing the NULL > dereference, so bisection would be tricky since it has happened > independently of the functional test that was running. I have also > copied authors for the Tail Loss code to check if they got any clues > even without KASAN data. There cause is an inconsistency of packet accounting: TCP retransmission queue is empty but tp->packets_out is not zero. We will send a fix soon. Thanks. > > Thank you, > - > Rafael D. Tinoco >
[PATCH 1/8] perf: Allow to block process in syscall tracepoints
Adding support to specify 'block' bool in struct perf_event_attr
for syscalls tracepoints, allowing the event to block the process,
if there's no space in the ring buffer.
The blocking code will poll/periodically check for the space and
continue if the event was successfully written.
It's allowed only for syscall tracepoint events attached to
process. Following syscall events are supported:
raw_syscalls:sys_enter
raw_syscalls:sys_exit
syscalls:sys_enter_accept
syscalls:sys_enter_accept4
syscalls:sys_enter_access
syscalls:sys_enter_acct
syscalls:sys_enter_add_key
...
Suggested-by: Steven Rostedt
Link: http://lkml.kernel.org/n/tip-ocz7zwwkkx11v0mkxrtcd...@git.kernel.org
Signed-off-by: Jiri Olsa
---
arch/x86/entry/common.c | 36 +++--
include/linux/perf_event.h | 2 ++
include/linux/sched.h | 2 ++
include/linux/syscalls.h| 2 ++
include/uapi/linux/perf_event.h | 3 ++-
kernel/events/core.c| 40 +++--
kernel/events/ring_buffer.c | 4 +++-
kernel/trace/trace_event_perf.c | 4
kernel/trace/trace_syscalls.c | 28 +++
9 files changed, 111 insertions(+), 10 deletions(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 3b2490b81918..e55cf9169a03 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -60,6 +60,32 @@ static void do_audit_syscall_entry(struct pt_regs *regs, u32
arch)
}
}
+static void trace_block_syscall(struct pt_regs *regs, bool enter)
+{
+ current->perf_blocked = true;
+
+ do {
+ schedule_timeout(100 * HZ);
+ current->perf_blocked_cnt = 0;
+
+ if (enter) {
+ /* perf syscalls:* enter */
+ perf_trace_syscall_enter(regs);
+
+ /* perf raw_syscalls:* enter */
+ perf_trace_sys_enter(&event_sys_enter, regs,
regs->orig_ax);
+ } else {
+ /* perf syscalls:* enter */
+ perf_trace_syscall_exit(regs);
+
+ /* perf raw_syscalls:* enter */
+ perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);
+ }
+ } while (current->perf_blocked_cnt);
+
+ current->perf_blocked = false;
+}
+
/*
* Returns the syscall nr to run (which should match regs->orig_ax) or -1
* to skip the syscall.
@@ -123,8 +149,11 @@ static long syscall_trace_enter(struct pt_regs *regs)
}
#endif
- if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+ if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT))) {
trace_sys_enter(regs, regs->orig_ax);
+ if (current->perf_blocked_cnt)
+ trace_block_syscall(regs, true);
+ }
do_audit_syscall_entry(regs, arch);
@@ -224,8 +253,11 @@ static void syscall_slow_exit_work(struct pt_regs *regs,
u32 cached_flags)
audit_syscall_exit(regs);
- if (cached_flags & _TIF_SYSCALL_TRACEPOINT)
+ if (cached_flags & _TIF_SYSCALL_TRACEPOINT) {
trace_sys_exit(regs, regs->ax);
+ if (current->perf_blocked_cnt)
+ trace_block_syscall(regs, false);
+ }
/*
* If TIF_SYSCALL_EMU is set, we only get here because of
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 47a31d01df5a..904b7245357a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -695,6 +695,8 @@ struct perf_event {
#endif
struct list_headsb_list;
+
+ boolblocked;
#endif /* CONFIG_PERF_EVENTS */
};
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a51c13c2b1a0..aea741ef29ae 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1009,6 +1009,8 @@ struct task_struct {
struct perf_event_context *perf_event_ctxp[perf_nr_task_contexts];
struct mutexperf_event_mutex;
struct list_headperf_event_list;
+ boolperf_blocked;
+ unsigned intperf_blocked_cnt;
#endif
#ifdef CONFIG_DEBUG_PREEMPT
unsigned long preempt_disable_ip;
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 2ac3d13a915b..3c8012ca9aa3 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -1296,4 +1296,6 @@ static inline unsigned int ksys_personality(unsigned int
personality)
return old;
}
+void perf_trace_syscall_enter(struct pt_regs *regs);
+void perf_trace_syscall_exit(struct pt_regs *regs);
#endif
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 9de8780ac8d9..92bae4cf279c 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -372,7 +372,8 @@ struct perf_eve
[PATCH 4/8] perf trace: Add --block option
Adding --block option to allow trace command pass along
the --block option for record command or to set it for
trace run session, like:
# perf trace --block kill
# perf trace --block -p ...
# perf trace -e raw_syscalls:sys_enter --block -p ...
It's allowed only for syscall tracepoint events
attached to process.
Link: http://lkml.kernel.org/n/tip-ocz7zwwkkx11v0mkxrtcd...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-trace.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a57a9ae1fd4b..a663ec346a8e 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2379,10 +2379,12 @@ static int trace__record(struct trace *trace, int argc,
const char **argv)
unsigned int majpf_args_nr = ARRAY_SIZE(majpf_args);
const char * const minpf_args[] = { "-e", "minor-faults" };
unsigned int minpf_args_nr = ARRAY_SIZE(minpf_args);
+ const char * const block_args[] = { "--block", };
+ unsigned int block_args_nr = ARRAY_SIZE(block_args);
/* +1 is for the event string below */
rec_argc = ARRAY_SIZE(record_args) + sc_args_nr + 1 +
- majpf_args_nr + minpf_args_nr + argc;
+ majpf_args_nr + minpf_args_nr + block_args_nr + argc;
rec_argv = calloc(rec_argc + 1, sizeof(char *));
if (rec_argv == NULL)
@@ -2416,6 +2418,9 @@ static int trace__record(struct trace *trace, int argc,
const char **argv)
for (i = 0; i < minpf_args_nr; i++)
rec_argv[j++] = minpf_args[i];
+ if (trace->opts.block)
+ rec_argv[j++] = block_args[0];
+
for (i = 0; i < (unsigned int)argc; i++)
rec_argv[j++] = argv[i];
@@ -3409,6 +3414,8 @@ int cmd_trace(int argc, const char **argv)
trace__parse_events_option),
OPT_BOOLEAN(0, "comm", &trace.show_comm,
"show the thread COMM next to its id"),
+ OPT_BOOLEAN(0, "block", &trace.opts.block,
+ "Request blocked tracing (for syscall tracepoints)"),
OPT_BOOLEAN(0, "tool_stats", &trace.show_tool_stats, "show tool stats"),
OPT_CALLBACK(0, "expr", &trace, "expr", "list of syscalls/events to
trace",
trace__parse_events_option),
@@ -3500,6 +3507,14 @@ int cmd_trace(int argc, const char **argv)
"cgroup monitoring only available in
system-wide mode");
}
+ if (trace.opts.block) {
+ if (!target__has_task(&trace.opts.target) &&
+ !target__none(&trace.opts.target)) {
+ pr_err("ERROR: Can't use --block on non task
targets\n");
+ goto out;
+ }
+ }
+
evsel = bpf__setup_output_event(trace.evlist, "__augmented_syscalls__");
if (IS_ERR(evsel)) {
bpf__strerror_setup_output_event(trace.evlist, PTR_ERR(evsel),
bf, sizeof(bf));
--
2.17.2
[PATCH 3/8] perf record: Add --block option
Adding --block option to allow record command set block
bool in struct perf_event_attr for event, like:
# perf record -e raw_syscalls:sys_enter --block ls
# perf record -e raw_syscalls:sys_enter --block -p ...
It's allowed only for syscall tracepoint events
attached to process.
Link: http://lkml.kernel.org/n/tip-ocz7zwwkkx11v0mkxrtcd...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-record.c | 9 +
tools/perf/perf.h | 1 +
tools/perf/util/evsel.c | 3 +++
3 files changed, 13 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4736dc96c4ca..79c8d2f94f86 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1937,6 +1937,8 @@ static struct option __record_options[] = {
"append timestamp to output filename"),
OPT_BOOLEAN(0, "timestamp-boundary", &record.timestamp_boundary,
"Record timestamp boundary (time of first/last samples)"),
+ OPT_BOOLEAN(0, "block", &record.opts.block,
+ "Request blocked tracing (for syscall tracepoints)"),
OPT_STRING_OPTARG_SET(0, "switch-output", &record.switch_output.str,
&record.switch_output.set, "signal,size,time",
"Switch output when receive SIGUSR2 or cross
size,time threshold",
@@ -2116,6 +2118,13 @@ int cmd_record(int argc, const char **argv)
goto out;
}
+ if (rec->opts.block &&
+ !target__has_task(&rec->opts.target) &&
+ !target__none(&rec->opts.target)) {
+ pr_err("Can't use --block on non task targets\n");
+ goto out;
+ }
+
/* Enable ignoring missing threads when -u/-p option is defined. */
rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX ||
rec->opts.target.pid;
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 4d40baa45a5f..7884701247b8 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -66,6 +66,7 @@ struct record_opts {
bool ignore_missing_thread;
bool strict_freq;
bool sample_id;
+ bool block;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index dbc0466db368..e4943e8f811b 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1045,6 +1045,9 @@ void perf_evsel__config(struct perf_evsel *evsel, struct
record_opts *opts,
if (opts->sample_transaction)
perf_evsel__set_sample_bit(evsel, TRANSACTION);
+ if (opts->block)
+ attr->block = true;
+
if (opts->running_time) {
evsel->attr.read_format |=
PERF_FORMAT_TOTAL_TIME_ENABLED |
--
2.17.2
[PATCH 6/8] perf tools: Add ordered_events__flush_time interface
Adding OE_FLUSH__TIME flush type, to be able to flush
only certain amount of the queue based on the provided
timestamp. It will be used in following patches.
Link: http://lkml.kernel.org/n/tip-a3na77vemwr1g92lfhlrz...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/ordered-events.c | 23 +++
tools/perf/util/ordered-events.h | 2 ++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index c5412db05683..b5c6a854379f 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -219,8 +219,7 @@ int ordered_events__queue(struct ordered_events *oe, union
perf_event *event,
return 0;
}
-static int __ordered_events__flush(struct ordered_events *oe,
- bool show_progress)
+static int do_flush(struct ordered_events *oe, bool show_progress)
{
struct list_head *head = &oe->events;
struct ordered_event *tmp, *iter;
@@ -263,7 +262,8 @@ static int __ordered_events__flush(struct ordered_events
*oe,
return 0;
}
-int ordered_events__flush(struct ordered_events *oe, enum oe_flush how)
+static int __ordered_events__flush(struct ordered_events *oe, enum oe_flush
how,
+ u64 time)
{
static const char * const str[] = {
"NONE",
@@ -302,6 +302,11 @@ int ordered_events__flush(struct ordered_events *oe, enum
oe_flush how)
break;
}
+ case OE_FLUSH__TIME:
+ oe->next_flush = time;
+ show_progress = false;
+ break;
+
case OE_FLUSH__ROUND:
case OE_FLUSH__NONE:
default:
@@ -312,7 +317,7 @@ int ordered_events__flush(struct ordered_events *oe, enum
oe_flush how)
str[how], oe->nr_events);
pr_oe_time(oe->max_timestamp, "max_timestamp\n");
- err = __ordered_events__flush(oe, show_progress);
+ err = do_flush(oe, show_progress);
if (!err) {
if (how == OE_FLUSH__ROUND)
@@ -328,6 +333,16 @@ int ordered_events__flush(struct ordered_events *oe, enum
oe_flush how)
return err;
}
+int ordered_events__flush(struct ordered_events *oe, enum oe_flush how)
+{
+ return __ordered_events__flush(oe, how, 0);
+}
+
+int ordered_events__flush_time(struct ordered_events *oe, u64 time)
+{
+ return __ordered_events__flush(oe, OE_FLUSH__TIME, time);
+}
+
void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t
deliver,
void *data)
{
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 0c6e26aec0e3..6ef81e5be052 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -19,6 +19,7 @@ enum oe_flush {
OE_FLUSH__ROUND,
OE_FLUSH__HALF,
OE_FLUSH__TOP,
+ OE_FLUSH__TIME,
};
struct ordered_events;
@@ -55,6 +56,7 @@ int ordered_events__queue(struct ordered_events *oe, union
perf_event *event,
u64 timestamp, u64 file_offset);
void ordered_events__delete(struct ordered_events *oe, struct ordered_event
*event);
int ordered_events__flush(struct ordered_events *oe, enum oe_flush how);
+int ordered_events__flush_time(struct ordered_events *oe, u64 time);
void ordered_events__init(struct ordered_events *oe, ordered_events__deliver_t
deliver,
void *data);
void ordered_events__free(struct ordered_events *oe);
--
2.17.2
[PATCH 2/8] perf tools: Sync uapi perf_event.h
Link: http://lkml.kernel.org/n/tip-lh4vrg3t3sjhvue16i5f3...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/include/uapi/linux/perf_event.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index 9de8780ac8d9..92bae4cf279c 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -372,7 +372,8 @@ struct perf_event_attr {
context_switch : 1, /* context switch data */
write_backward : 1, /* Write ring buffer from
end to beginning */
namespaces : 1, /* include namespaces data
*/
- __reserved_1 : 35;
+ block : 1, /* block process if
there's no space in RB (syscall tracepoints only) */
+ __reserved_1 : 34;
union {
__u32 wakeup_events;/* wakeup every n events */
--
2.17.2
[PATCH 7/8] perf trace: Move event delivery to deliver_event function
Moving event delivery code to deliver_event function,
so it's easier to add conditional ordered delivery
coming in following patches.
Link: http://lkml.kernel.org/n/tip-qz9wzti2cw6q7swja0h2x...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-trace.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a663ec346a8e..b4b1dafe882a 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2641,6 +2641,21 @@ static int trace__set_filter_pids(struct trace *trace)
return err;
}
+static int deliver_event(struct trace *trace, union perf_event *event)
+{
+ struct perf_evlist *evlist = trace->evlist;
+ struct perf_sample sample;
+ int err;
+
+ err = perf_evlist__parse_sample(evlist, event, &sample);
+ if (err)
+ fprintf(trace->output, "Can't parse sample, err = %d,
skipping...\n", err);
+ else
+ trace__handle_event(trace, event, &sample);
+
+ return 0;
+}
+
static int trace__run(struct trace *trace, int argc, const char **argv)
{
struct perf_evlist *evlist = trace->evlist;
@@ -2806,18 +2821,10 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
continue;
while ((event = perf_mmap__read_event(md)) != NULL) {
- struct perf_sample sample;
-
++trace->nr_events;
- err = perf_evlist__parse_sample(evlist, event, &sample);
- if (err) {
- fprintf(trace->output, "Can't parse sample, err
= %d, skipping...\n", err);
- goto next_event;
- }
+ deliver_event(trace, event);
- trace__handle_event(trace, event, &sample);
-next_event:
perf_mmap__consume(md);
if (interrupted)
--
2.17.2
[PATCH 5/8] perf tools: Add block term support for tracepoints
Allow to specify 'block' term for tracepoint in the -e command
line option, like:
# perf record -e raw_syscalls:sys_enter/block/ -p ...
# perf trace -e raw_syscalls:sys_enter/block/ -p ...
to set this tracepoint as blocking (sets struct perf_event_attr::block)
It's allowed only for syscall tracepoint events
attached to process.
Link: http://lkml.kernel.org/n/tip-jj5uwlt3izp1gpk8jcspu...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/evsel.c| 4
tools/perf/util/evsel.h| 2 ++
tools/perf/util/parse-events.c | 8
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.l | 1 +
5 files changed, 16 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index e4943e8f811b..886b0dbec534 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -811,6 +811,9 @@ static void apply_config_terms(struct perf_evsel *evsel,
break;
case PERF_EVSEL__CONFIG_TERM_DRV_CFG:
break;
+ case PERF_EVSEL__CONFIG_TERM_BLOCK:
+ attr->block = term->val.block ? 1 : 0;
+ break;
default:
break;
}
@@ -1655,6 +1658,7 @@ int perf_event_attr__fprintf(FILE *fp, struct
perf_event_attr *attr,
PRINT_ATTRf(context_switch, p_unsigned);
PRINT_ATTRf(write_backward, p_unsigned);
PRINT_ATTRf(namespaces, p_unsigned);
+ PRINT_ATTRf(block, p_unsigned);
PRINT_ATTRn("{ wakeup_events, wakeup_watermark }", wakeup_events,
p_unsigned);
PRINT_ATTRf(bp_type, p_unsigned);
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 82a289ce8b0c..c5d11035a21b 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -50,6 +50,7 @@ enum term_type {
PERF_EVSEL__CONFIG_TERM_OVERWRITE,
PERF_EVSEL__CONFIG_TERM_DRV_CFG,
PERF_EVSEL__CONFIG_TERM_BRANCH,
+ PERF_EVSEL__CONFIG_TERM_BLOCK,
};
struct perf_evsel_config_term {
@@ -67,6 +68,7 @@ struct perf_evsel_config_term {
booloverwrite;
char*branch;
unsigned long max_events;
+ boolblock;
} val;
bool weak;
};
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index caecd2d9494a..6b6e70f1ae1f 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -930,6 +930,7 @@ static const char
*config_term_names[__PARSE_EVENTS__TERM_TYPE_NR] = {
[PARSE_EVENTS__TERM_TYPE_OVERWRITE] = "overwrite",
[PARSE_EVENTS__TERM_TYPE_NOOVERWRITE] = "no-overwrite",
[PARSE_EVENTS__TERM_TYPE_DRV_CFG] = "driver-config",
+ [PARSE_EVENTS__TERM_TYPE_BLOCK] = "block",
};
static bool config_term_shrinked;
@@ -1041,6 +1042,9 @@ do {
\
case PARSE_EVENTS__TERM_TYPE_MAX_EVENTS:
CHECK_TYPE_VAL(NUM);
break;
+ case PARSE_EVENTS__TERM_TYPE_BLOCK:
+ CHECK_TYPE_VAL(NUM);
+ break;
default:
err->str = strdup("unknown term");
err->idx = term->err_term;
@@ -1091,6 +1095,7 @@ static int config_term_tracepoint(struct perf_event_attr
*attr,
case PARSE_EVENTS__TERM_TYPE_MAX_EVENTS:
case PARSE_EVENTS__TERM_TYPE_OVERWRITE:
case PARSE_EVENTS__TERM_TYPE_NOOVERWRITE:
+ case PARSE_EVENTS__TERM_TYPE_BLOCK:
return config_term_common(attr, term, err);
default:
if (err) {
@@ -1179,6 +1184,9 @@ do {
\
case PARSE_EVENTS__TERM_TYPE_DRV_CFG:
ADD_CONFIG_TERM(DRV_CFG, drv_cfg, term->val.str);
break;
+ case PARSE_EVENTS__TERM_TYPE_BLOCK:
+ ADD_CONFIG_TERM(BLOCK, block, term->val.num ? 1 : 0);
+ break;
default:
break;
}
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index 5ed035cbcbb7..204f4bf1c62a 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -75,6 +75,7 @@ enum {
PARSE_EVENTS__TERM_TYPE_NOOVERWRITE,
PARSE_EVENTS__TERM_TYPE_OVERWRITE,
PARSE_EVENTS__TERM_TYPE_DRV_CFG,
+ PARSE_EVENTS__TERM_TYPE_BLOCK,
__PARSE_EVENTS__TERM_TYPE_NR,
};
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 7805c71aaae2..69141fb38347 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -274,6 +274,7 @@ inherit { return term(yyscanner,
PARSE_EVENTS__TERM_TYPE_INHERIT); }
no-inherit { return term(yyscanner,
PARSE_EVENTS__TERM_TYPE
[PATCH 8/8] perf trace: Add ordered processing for --block option
Adding support to sort the trace events if --block option is set.
In this mode we don't loose events, and we are potentionally slow
by definition, because the traced process could be blocked.
In this case it makes sense to sort events and provide the precise
outcome of ordered events.
Link: http://lkml.kernel.org/n/tip-me69opepwec6tjtpy2cxr...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-trace.c | 59 +++-
tools/perf/util/ordered-events.c | 11 ++
tools/perf/util/ordered-events.h | 1 +
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index b4b1dafe882a..d650d8cd421b 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -127,6 +127,11 @@ struct trace {
boolforce;
boolvfs_getname;
int trace_pgfaults;
+
+ struct {
+ struct ordered_events data;
+ u64 last;
+ } oe;
};
struct tp_field {
@@ -2656,6 +2661,43 @@ static int deliver_event(struct trace *trace, union
perf_event *event)
return 0;
}
+
+static int flush_ordered_events(struct trace *trace)
+{
+ u64 first = ordered_events__first_time(&trace->oe.data);
+ u64 flush = trace->oe.last - NSEC_PER_SEC;
+
+ /* Is there some thing to flush.. */
+ if (first && first < flush)
+ return ordered_events__flush_time(&trace->oe.data, flush);
+
+ return 0;
+}
+
+static int deliver_ordered_event(struct trace *trace, union perf_event *event)
+{
+ struct perf_evlist *evlist = trace->evlist;
+ int err;
+
+ err = perf_evlist__parse_sample_timestamp(evlist, event,
&trace->oe.last);
+ if (err && err != -1)
+ return err;
+
+ err = ordered_events__queue(&trace->oe.data, event, trace->oe.last, 0);
+ if (err)
+ return err;
+
+ return flush_ordered_events(trace);
+}
+
+static int ordered_events__deliver_event(struct ordered_events *oe,
+struct ordered_event *event)
+{
+ struct trace *trace = container_of(oe, struct trace, oe.data);
+
+ return deliver_event(trace, event->event);
+}
+
static int trace__run(struct trace *trace, int argc, const char **argv)
{
struct perf_evlist *evlist = trace->evlist;
@@ -2823,7 +2865,13 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
while ((event = perf_mmap__read_event(md)) != NULL) {
++trace->nr_events;
- deliver_event(trace, event);
+ if (trace->opts.block) {
+ err = deliver_ordered_event(trace, event);
+ if (err)
+ goto out_disable;
+ } else {
+ deliver_event(trace, event);
+ }
perf_mmap__consume(md);
@@ -2846,6 +2894,9 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
draining = true;
goto again;
+ } else {
+ if (trace->opts.block && flush_ordered_events(trace))
+ goto out_disable;
}
} else {
goto again;
@@ -2856,6 +2907,9 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
perf_evlist__disable(evlist);
+ if (trace->opts.block)
+ ordered_events__flush(&trace->oe.data, OE_FLUSH__FINAL);
+
if (!err) {
if (trace->summary)
trace__fprintf_thread_summary(trace, trace->output);
@@ -3520,6 +3574,9 @@ int cmd_trace(int argc, const char **argv)
pr_err("ERROR: Can't use --block on non task
targets\n");
goto out;
}
+
+ ordered_events__init(&trace.oe.data,
ordered_events__deliver_event, &trace);
+ ordered_events__set_copy_on_queue(&trace.oe.data, true);
}
evsel = bpf__setup_output_event(trace.evlist, "__augmented_syscalls__");
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index b5c6a854379f..6bd9f50ac83e 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -343,6 +343,17 @@ int ordered_events__flush_time(struct ordered_events *oe,
u64 time)
return __ordered_events__flush(oe, OE_FLUSH__TIME, time);
}
+u64 ordered_events__first_time(struct ordered_events *oe)
+{
+ struct ordered_event *event;
+
+ if (list_empty(&oe->events))
+ return 0;
+
+ event = list_first_entry(&oe->events, struct ordered_event, list);
+ return event->timestamp;
+}
+
void ordered_event
Re: [PATCH v2 1/1] arm64: Early boot time stamps
On 18-11-22 14:14:29, Marc Zyngier wrote: > On Wed, 21 Nov 2018 17:58:41 +, > Pavel Tatashin wrote: > > > > On 18-11-21 17:47:07, Will Deacon wrote: > > > > + /* > > > > +* The arm64 boot protocol mandates that CNTFRQ_EL0 reflects > > > > +* the timer frequency. To avoid breakage on misconfigured > > > > +* systems, do not register the early sched_clock if the > > > > +* programmed value if zero. Other random values will just > > > > +* result in random output. > > > > +*/ > > > > + if (!freq) > > > > + return; > > > > + > > > > + arch_timer_read_counter = arch_counter_get_cntvct; > > > > > > Why do you need to assign this here? > > > > > > > + sched_clock_register(arch_timer_read_counter, ARCH_TIMER_NBITS, > > > > freq); > > > > > > arch_timer_read_counter can be reassigned once the arm_arch_timer driver > > > has probed; what stops this from being unused as the sched_clock after > > > that > > > has happened? I worry that toggling the function pointer could lead to > > > sched_clock() going backwards. > > > > No reason, I will revert it back to use a local variable. > > I think the issue is that you are doing an assignment for something > that the kernel has already statically initialized. > > > I agree, time can go backward for a period of time while we switch > > to permanent clock later, if that clock is different. > > It is worse than that. You're setting up sched_clock with an > unreliable clock source which can go backward at any point, not just > at handover time. > > I'd rather we have the timestamping code be able to use another souce > than sched_clock, and eventually switch to it once sched_clock is > registered (and properly corrected. Hi Marc, The early sched clock is implemented the same way on SPARC and x86: it uses the sched_clock() interface to get timestamps. In addition it can be used be engineers to precisely measure and debug early boot problems by directly inserting cheap sched_clock() calls into code. Ftrace might also be extended in future to support early boot. I am not sure it is a good idea to invent a different interface that would be used by printk() only for timestamping early in boot. During the hang over from unstable to stable the sched_clock_register() does the right thing and calculates the offset where the last clock ended and new started. In unlikely even if on some broken chips time goes backward, it will happen during early boot only. Do you know if there are arm64 chips exist where time may go backward? We can either don't do early boot clock on those chips, or modify sched_clock() to check for the last return value, and make sure that it is always smaller than the new return value. Thank you, Pasha
Re: [PATCH v10 5/7] interconnect: qcom: Add sdm845 interconnect provider driver
Hi Evan,
On 12/1/18 02:39, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov
> wrote:
>>
>> From: David Dai
>>
>> Introduce Qualcomm SDM845 specific provider driver using the
>> interconnect framework.
>>
>> Signed-off-by: David Dai
>> Signed-off-by: Georgi Djakov
>> ---
>> .../bindings/interconnect/qcom,sdm845.txt | 24 +
>> drivers/interconnect/Kconfig | 5 +
>> drivers/interconnect/Makefile | 1 +
>> drivers/interconnect/qcom/Kconfig | 13 +
>> drivers/interconnect/qcom/Makefile| 5 +
>> drivers/interconnect/qcom/sdm845.c| 836 ++
>> .../dt-bindings/interconnect/qcom,sdm845.h| 143 +++
>> 7 files changed, 1027 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>> create mode 100644 drivers/interconnect/qcom/Kconfig
>> create mode 100644 drivers/interconnect/qcom/Makefile
>> create mode 100644 drivers/interconnect/qcom/sdm845.c
>> create mode 100644 include/dt-bindings/interconnect/qcom,sdm845.h
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>> b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>> new file mode 100644
>> index ..d45150e99665
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>> @@ -0,0 +1,24 @@
>> +Qualcomm SDM845 Network-On-Chip interconnect driver binding
>> +---
>> +
>> +SDM845 interconnect providers support system bandwidth requirements through
>> +RPMh hardware accelerators known as Bus Clock Manager(BCM). The provider is
>> able
>> +to communicate with the BCM through the Resource State Coordinator(RSC)
>> +associated with each execution environment. Provider nodes must reside
>> within
>> +an RPMh device node pertaining to their RSC and each provider maps to
>> +a single RPMh resource.
>> +
>> +Required properties :
>> +- compatible : shall contain only one of the following:
>> + "qcom,sdm845-rsc-hlos"
>
> I wonder if maybe hlos isn't necessary. Unless you somehow imagine
> secure mode would have a device tree entry in here as well? Probably
> not.
Ok, will remove it. David, please chime in if you have any concerns with
this.
>> +- #interconnect-cells : should contain 1
>> +
>> +Examples:
>> +
>> +apps_rsc: rsc {
>> + qnoc: qnoc-rsc-hlos {
>> + compatible = "qcom,sdm845-rsc-hlos";
>> + #interconnect-cells = <1>;
>> + };
>> +};
>> +
> ...
>> diff --git a/drivers/interconnect/qcom/sdm845.c
>> b/drivers/interconnect/qcom/sdm845.c
>> new file mode 100644
>> index ..1678de91ca52
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/sdm845.c
>> @@ -0,0 +1,836 @@
> ...
>> +
>> +static void tcs_list_gen(struct list_head *bcm_list,
>> +struct tcs_cmd *tcs_list, int *n)
>
> We could make the prototype of this function be:
>
> static void tcs_list_gen(struct list_head *bcm_list,
> struct tcs_cmd tcs_list[SDM845_MAX_VCD], int n[SDM845_MAX_VCD])
>
> which would catch errors if somebody later passed in an array that
> wasn't the right size, since we blindly memset below.
Yes, sounds good. I will try to optimize it.
Thanks,
Georgi
>> +{
>> + struct qcom_icc_bcm *bcm;
>> + bool commit;
>> + size_t idx = 0, batch = 0, cur_vcd_size = 0;
>> +
>> + memset(n, 0, sizeof(int) * SDM845_MAX_VCD);
>> +
>> + list_for_each_entry(bcm, bcm_list, list) {
>> + commit = false;
>> + cur_vcd_size++;
>> + if ((list_is_last(&bcm->list, bcm_list)) ||
>> + bcm->aux_data.vcd != list_next_entry(bcm,
>> list)->aux_data.vcd) {
>> + commit = true;
>> + cur_vcd_size = 0;
>> + }
>> + tcs_cmd_gen(&tcs_list[idx], bcm->vote_x, bcm->vote_y,
>> + bcm->addr, commit);
>> + idx++;
>> + n[batch]++;
>> + /*
>> +* Batch the BCMs in such a way that we do not split them in
>> +* multiple payloads when they are under the same VCD. This
>> is
>> +* to ensure that every BCM is committed since we only set
>> the
>> +* commit bit on the last BCM request of every VCD.
>> +*/
>> + if (n[batch] >= MAX_RPMH_PAYLOAD) {
>> + if (!commit) {
>> + n[batch] -= cur_vcd_size;
>> + n[batch + 1] = cur_vcd_size;
>> + }
>> + batch++;
>> + }
>> + }
>> +}
>> +
Re: [PATCH v10 6/7] arm64: dts: sdm845: Add interconnect provider DT nodes
Hi Evan,
On 12/1/18 02:39, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov
> wrote:
>>
>> From: David Dai
>>
>> Add RSC (Resource State Coordinator) provider
>> dictating network-on-chip interconnect bus performance
>> found on SDM845-based platforms.
>>
>> Signed-off-by: David Dai
>> Signed-off-by: Georgi Djakov
>> ---
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index b72bdb0a31a5..856d33604e9c 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -1324,6 +1324,11 @@
>> compatible = "qcom,sdm845-rpmh-clk";
>> #clock-cells = <1>;
>> };
>> +
>> + qnoc: qnoc {
>> + compatible = "qcom,sdm845-rsc-hlos";
>> + #interconnect-cells = <1>;
>> + };
>
> Should we alphabetize this node above rpmhcc?
Sure!
Thanks,
Georgi
Re: [PATCHv2 2/4] PCI: dwc: fix 4GiB outbound window size truncated to zero issue
On Wed, Nov 07, 2018 at 10:09:10AM +, Z.q. Hou wrote:
> From: Hou Zhiqiang
>
> The current type of mem_size is 'u32', so when resource_size()
> return 4G it will be truncated to zero. This patch fix it by
> changing its type to 'u64'.
>
> Signed-off-by: Hou Zhiqiang
> Acked-by: Gustavo Pimentel
> ---
> V2:
> - Reworded the subject.
>
> drivers/pci/controller/dwc/pcie-designware.c | 4 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
I would like to add a Fixes: tag.
is
edd45e396829 ("PCI: dwc: designware: Move _unroll configurations to a
separate function")
the commit you are fixing ?
Thanks,
Lorenzo
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 2153956a0b20..7ac5989c23ef 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -106,7 +106,7 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie *pci,
> u32 index, u32 reg,
>
> static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
>int type, u64 cpu_addr,
> - u64 pci_addr, u32 size)
> + u64 pci_addr, u64 size)
> {
> u32 retries, val;
>
> @@ -141,7 +141,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct
> dw_pcie *pci, int index,
> }
>
> void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> -u64 cpu_addr, u64 pci_addr, u32 size)
> +u64 cpu_addr, u64 pci_addr, u64 size)
> {
> u32 retries, val;
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 9f1a5e399b70..a438c3879aa9 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -153,7 +153,7 @@ struct pcie_port {
> u32 io_size;
> u64 mem_base;
> phys_addr_t mem_bus_addr;
> - u32 mem_size;
> + u64 mem_size;
> struct resource *cfg;
> struct resource *io;
> struct resource *mem;
> @@ -238,7 +238,7 @@ int dw_pcie_link_up(struct dw_pcie *pci);
> int dw_pcie_wait_for_link(struct dw_pcie *pci);
> void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> int type, u64 cpu_addr, u64 pci_addr,
> -u32 size);
> +u64 size);
> int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
>u64 cpu_addr, enum dw_pcie_as_type as_type);
> void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> --
> 2.17.1
>
Re: [PATCH V2 1/2] mmc: mmci: send stop command if sbc error issue
On 12/5/18 3:23 PM, Ulf Hansson wrote:
On Tue, 20 Nov 2018 at 10:42, Ulf Hansson wrote:
On 7 November 2018 at 10:30, Ludovic Barre wrote:
From: Ludovic Barre
Refer to "4.15 set block count command" of sd specification:
Host needs to issue CMD12 if any error is detected in
the CMD18 and CMD25 operations.
In sbc case, the data->stop is fill by framework.
Signed-off-by: Ludovic Barre
---
drivers/mmc/host/mmci.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 82bab35..13fa640 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1190,11 +1190,10 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data
*data,
/* The error clause is handled above, success! */
data->bytes_xfered = data->blksz * data->blocks;
- if (!data->stop || host->mrq->sbc) {
+ if (!data->stop || (host->mrq->sbc && !data->error))
mmci_request_end(host, data->mrq);
- } else {
+ else
mmci_start_command(host, data->stop, 0);
This looks correct to me!
Although, just wanted to double check that you tested this for a case
where we have host->mrq->sbc set and got an error in data->error? I
guess it can be tricky, so I was thinking of manually trying to
instruct the code, to set an error in data->error, at some point to
trigger this code. That would at least give us some confidence that it
works as expected.
I did some manual tests to trigger the error path. As far as I can
tell, it works as expected and I observes that the core is able to
recover and re-send the request.
Ulf, very thanks for the tests, and sorry for my busy status.
I will send as soon as possible the 2/2 with your recommendation (I will
more spare time for upstream)
[...]
So, I have added my tested-by tag and applied this for next. Thanks!
In regards to patch2/2 I am awaiting your update.
Kind regards
Uffe
Re: [Letux-kernel] [PATCH 0/5] gnss: sirf: add support for w2sg0004 + lna
On Wed, Dec 05, 2018 at 04:19:16PM +0100, Johan Hovold wrote: > On Mon, Nov 19, 2018 at 07:44:14PM +0100, Andreas Kemnade wrote: > > > On Mon, 19 Nov 2018 09:22:59 +0100 > > "H. Nikolaus Schaller" wrote: > > > > > Am 18.11.2018 um 22:57 schrieb Andreas Kemnade : > > > > > > > > Here is another chapter of the story to get gta04 gnss power > > > > management into the mainline kernel. > > > > There is a w2sg0004 without wakeup line in there, so power state > > > > can only be determined indirectly by looking at the serial data lines. > > > > Then there as also an lna which needs to be powered for real gps > > > > reception. That part needs probably more discussion, since it might > > > > be an idea to have it more generalized since it has nothing todo > > > > with the chip itself. > > > > > > On the other hand if we follow the "SoC is the spider in the net" > > > way of looking at DTS hierarchy, we have the uart as a child of the > > > SoC and the gnss receiver as a serdev child of the UART. The LNA > > > is even one step more distantly connected to the gnss. So it makes > > > sense to me to have it as a property/reference of the gnss chip's > > > DTS record which is a sibling of the compatible records. So the only > > > place where it can be reasonably processed is the driver. > > > > > Or the lna is a child of the gnss receiver. The whole thing > > should probably not be overdesigned, but it does not make sense that > > every gnss chip driver has some lna logic. > > Did you mean "does make sense" here? > > > Maybe the regulator should just be stored in the struct > > gnss_device and then drivers/gnss/core.c takes care. > > Maybe eventually, but keeping it per driver is fine for now. > > As you say above, this really isn't part of the chip itself, and > therefore should probably be a generic gnss property as it could be > required for any receiver (in principle). > > But we still need driver support for coordinating it with the rest of > the receiver power management, so adding it to drivers as need arises > seems reasonable. Actually, the property probably still should go into gnss.txt as a generic optional property, but driver support for it will be added as need arises. Rob? Thanks, Johan
Re: [PATCH] clk: qcom: Remove LPASS_CC config for GCC lpass clocks
Quoting Taniya Das (2018-12-05 00:02:00) > The GCC lpass clocks are updated as protected, so clean up the ifdefers. > > Signed-off-by: Taniya Das > --- Ok. But this will have to wait for a few months until everything is merged together. Was that the intention of sending this now instead of later?
Re: [PATCH] dmaengine: remove DBGFS_FUNC_DECL()
On 05-12-18, 23:49, Frank Lee wrote: > On Wed, Dec 5, 2018 at 4:27 PM Vinod Koul wrote: > > > > On 30-11-18, 10:42, Yangtao Li wrote: > > > We already have the DEFINE_SHOW_ATTRIBUTE,There is no need to define > > > such a macro,so remove DBGFS_FUNC_DECL.Also use macro to simplify some > > > code. > > > > Spaces after full stop and comma please > > > > > > > > Signed-off-by: Yangtao Li > > > --- > > > drivers/dma/amba-pl08x.c | 14 ++ > > > drivers/dma/mic_x100_dma.c | 22 +++--- > > > drivers/dma/pxa_dma.c| 24 > > > drivers/dma/qcom/hidma_dbg.c | 33 ++--- > > > > Do you mind splitting it per file. > Hi Vinod: > > Why not apply it once ？The change is not too big. It is not about big or small. A patch should do one thing and touch a single module. It also helps people when they look at changes and backports. -- ~Vinod
Re: [PATCH 5/7] microblaze: add linux.bin* and simpleImage.* to PHONY
On 03. 12. 18 8:50, Masahiro Yamada wrote: > linux.bin, linux.bin.gz, and linux.bin.ub are phony targets to > generate a corresponding image under arch/microblaze/boot/. > > simpleImage.% also works like a PHONY target, but a pattern that > contains '%' cannot be a PHONY target. I renamed it to equivalent > simpleImage.$(DTB). > > Signed-off-by: Masahiro Yamada > --- > > arch/microblaze/Makefile | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile > index c5d5b0e..7a5df02 100644 > --- a/arch/microblaze/Makefile > +++ b/arch/microblaze/Makefile > @@ -79,11 +79,13 @@ all: linux.bin > archclean: > $(Q)$(MAKE) $(clean)=$(boot) > > +PHONY += linux.bin linux.bin.gz linux.bin.ub > linux.bin linux.bin.gz linux.bin.ub: vmlinux > $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ > @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' > > -simpleImage.%: vmlinux > +PHONY += simpleImage.$(DTB) > +simpleImage.$(DTB): vmlinux > $(Q)$(MAKE) $(build)=$(boot) simple_images > @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' > > Acked-by: Michal Simek Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
Re: [PATCH AUTOSEL 4.19 40/68] ALSA: hda/ca0132 - Add new ZxR quirk
On Thu, Nov 29, 2018 at 09:51:55AM -0500, Connor McAdams wrote: This patch won't break anything, but it also won't fix anything either. Not sure if that matters or not. I'll remove it then, thank you. -- Thanks, Sasha
Re: [PATCH 4/7] microblaze: fix multiple bugs in arch/microblaze/boot/Makefile
On 03. 12. 18 8:50, Masahiro Yamada wrote:
> This Makefile is wrong in multiple ways.
>
> The first issue is the breakage of 'linux.bin.ub' target since commit
> ece97f3a5fb5 ("microblaze: Fix simpleImage format generation")
> because the addition of UIMAGE_{IN,OUT} obviously affected it.
>
> make ARCH=microblaze CROSS_COMPILE=microblaze-linux- linux.bin.ub
> [ snip ]
> OBJCOPY arch/microblaze/boot/linux.bin
> UIMAGE arch/microblaze/boot/linux.bin.ub.ub
> /usr/bin/mkimage: Can't open arch/microblaze/boot/linux.bin.ub: No such file
> or directory
> make[1]: *** [arch/microblaze/boot/Makefile;14:
> arch/microblaze/boot/linux.bin.ub] Error 1
> make: *** [arch/microblaze/Makefile;83: linux.bin.ub] Error 2
>
> The second issue is the use of the "if_changed" multiple times for
> the same target.
>
> As commit 92a4728608a8 ("x86/boot: Fix if_changed build flip/flop bug")
> pointed out, this never works properly. Moreover, generating multiple
> images as a side-effect is extremely confusing and wrong.
>
> As far as I understood, "simpleImage." works like a phony target
> to generate the following four images.
>
> - arch/microblaze/boot/simpleImage.:
>identical to arch/microblaze/boot/linux.bin
>
> - arch/microblaze/boot/simpleImage..unstrip:
>identical to vmlinux
>
> - arch/microblaze/boot/simpleImage..ub:
>identical to arch/microblaze/boot/linux.bin.ub
>
> - arch/microblaze/boot/simpleImage..strip:
>stripped vmlinux
Your understanding is correct. It always worked like that
simpleImage. was generating 4 files.
I have wired that long time ago because I wanted to boot image in U-Boot
that's why .ub was also generated.
Definitely simpleImage..ub can be another target and not
automatically generated by simpleImage.
Acked-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v10 1/7] interconnect: Add generic on-chip interconnect API
Hi Evan,
On 12/1/18 02:38, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov
> wrote:
>>
>> This patch introduces a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
>>
>> The API is using a consumer/provider-based model, where the providers are
>> the interconnect buses and the consumers could be various drivers.
>> The consumers request interconnect resources (path) between endpoints and
>> set the desired constraints on this data flow path. The providers receive
>> requests from consumers and aggregate these requests for all master-slave
>> pairs on that path. Then the providers configure each participating in the
>> topology node according to the requested data flow path, physical links and
>
> Strange word ordering. Consider something like: "Then the providers
> configure each node participating in the topology"
>
> ...Or a slightly different flavor: "Then the providers configure each
> node along the path to support a bandwidth that satisfies all
> bandwidth requests that cross through that node".
>
This sounds better!
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov
>> Reviewed-by: Evan Green
>
> This already has my reviewed by, and I still stand by it, but I
> couldn't help finding some nits anyway. Sorry :)
Thanks for finding them!
>> ---
>> Documentation/interconnect/interconnect.rst | 94
>> drivers/Kconfig | 2 +
>> drivers/Makefile| 1 +
>> drivers/interconnect/Kconfig| 10 +
>> drivers/interconnect/Makefile | 5 +
>> drivers/interconnect/core.c | 569
>> include/linux/interconnect-provider.h | 125 +
>> include/linux/interconnect.h| 51 ++
>> 8 files changed, 857 insertions(+)
>> create mode 100644 Documentation/interconnect/interconnect.rst
>> create mode 100644 drivers/interconnect/Kconfig
>> create mode 100644 drivers/interconnect/Makefile
>> create mode 100644 drivers/interconnect/core.c
>> create mode 100644 include/linux/interconnect-provider.h
>> create mode 100644 include/linux/interconnect.h
>>
[..]
>> +/*
>> + * We want the path to honor all bandwidth requests, so the average and peak
>> + * bandwidth requirements from each consumer are aggregated at each node.
>> + * The aggregation is platform specific, so each platform can customize it
>> by
>> + * implementing it's own aggregate() function.
>
> Grammar police: remove the apostrophe in its.
>
Oops.
>> + */
>> +
>> +static int aggregate_requests(struct icc_node *node)
>> +{
>> + struct icc_provider *p = node->provider;
>> + struct icc_req *r;
>> +
>> + node->avg_bw = 0;
>> + node->peak_bw = 0;
>> +
>> + hlist_for_each_entry(r, &node->req_list, req_node)
>> + p->aggregate(node, r->avg_bw, r->peak_bw,
>> +&node->avg_bw, &node->peak_bw);
>> +
>> + return 0;
>> +}
>> +
>> +static int apply_constraints(struct icc_path *path)
>> +{
>> + struct icc_node *next, *prev = NULL;
>> + int ret = -EINVAL;
>> + int i;
>> +
>> + for (i = 0; i < path->num_nodes; i++, prev = next) {
>> + struct icc_provider *p;
>> +
>> + next = path->reqs[i].node;
>> + /*
>> +* Both endpoints should be valid master-slave pairs of the
>> +* same interconnect provider that will be configured.
>> +*/
>> + if (!prev || next->provider != prev->provider)
>> + continue;
>
> I wonder if we should explicitly ban paths where we bounce through an
> odd number of nodes within one provider. Otherwise, set() won't be
> called on all nodes in the path. Or, if we wanted to support those
> kinds of topologies, you could call set with one of the nodes set to
> NULL to represent either the ingress or egress bandwidth to this NoC.
> This doesn't necessarily need to be addressed in this series, but is
> something that other providers might bump into when implementing their
> topologies.
>
Yes, we can do something like this. But i prefer that we first add
support for more platforms and then according to the requirements we can
work out something.
[..]
>> + new = krealloc(src->links,
>> + (src->num_links) * sizeof(*src->links),
>
> These parentheses aren't needed.
Sure!
>> + GFP_KERNEL);
>> + if (new)
>> + src->links = new;
>> +
[..]
>> +
>> +MODULE_AUTHOR("Georgi Djakov
> This is missing the closing >
Thanks!
>> +MODULE_DESCRIPTION("Interconnect Driver Core");
>> +MODULE_LICENSE("GPL v2");
> ...
>> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
>> new file mode 100644
>> index ..04b2966ded9f
Re: [PATCH v10 3/7] interconnect: Allow endpoints translation via DT
Hi Evan,
On 12/1/18 02:38, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov
> wrote:
>>
>> Currently we support only platform data for specifying the interconnect
>> endpoints. As now the endpoints are hard-coded into the consumer driver
>> this may lead to complications when a single driver is used by multiple
>> SoCs, which may have different interconnect topology.
>> To avoid cluttering the consumer drivers, introduce a translation function
>> to help us get the board specific interconnect data from device-tree.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> drivers/interconnect/core.c | 156 ++
>> include/linux/interconnect-provider.h | 17 +++
>> include/linux/interconnect.h | 7 ++
>> 3 files changed, 180 insertions(+)
>>
>> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
>> index 3ae8e5a58969..ebc42ef9fa46 100644
>> --- a/drivers/interconnect/core.c
>> +++ b/drivers/interconnect/core.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> static DEFINE_IDR(icc_idr);
>> @@ -193,6 +194,159 @@ static int apply_constraints(struct icc_path *path)
>> return ret;
>> }
>>
>> +/* of_icc_xlate_onecell() - Xlate function using a single index.
>
> It would be nice if translate were spelled out instead of xlate in the
> description portion (throughout).
Ok, done.
>> + * @spec: OF phandle args to map into an interconnect node.
>> + * @data: private data (pointer to struct icc_onecell_data)
>> + *
>> + * This is a generic xlate function that can be used to model simple
>> + * interconnect providers that have one device tree node and provide
>> + * multiple interconnect nodes. A single cell is used as an index into
>> + * an array of icc nodes specified in the icc_onecell_data struct when
>> + * registering the provider.
>> + */
[..]
>> +/**
>> + * of_icc_get() - get a path handle from a DT node based on name
>> + * @dev: device pointer for the consumer device
>> + * @name: interconnect path name
>> + *
>> + * This function will search for a path two endpoints and return an
>
> path between two endpoints
>
Ok.
>> + * icc_path handle on success. Use icc_put() to release constraints when
>> + * they are not needed anymore.
>> + * If the interconnect API is disabled, NULL is returned and the consumer
>> + * drivers will still build. Drivers are free to handle this specifically,
>> + * but they don't have to. NULL is also returned when the "interconnects"
>
> I'm not sure the sentence starting with "Drivers are free" adds much.
> Also, you mention that null is returned when the interconnect API is
> disabled both above and below. We probably only need it once.
>
So it depends on the driver how to handle it. If an enabled interconnect
is a hard requirement for a driver to work, it can choose to fail. If it
is optional, the driver can succeed and continue and all bandwidth
requests will be silently ignored.
>> + * DT property is missing.
>> + *
>> + * Return: icc_path pointer on success or ERR_PTR() on error. NULL is
>> returned
>> + * when the API is disabled or the "interconnects" DT property is missing.
>> + */
>> +struct icc_path *of_icc_get(struct device *dev, const char *name)
>> +{
>> + struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
>> + struct icc_node *src_node, *dst_node;
>> + struct device_node *np = NULL;
>> + struct of_phandle_args src_args, dst_args;
>> + int idx = 0;
>> + int ret;
>> +
>> + if (!dev || !dev->of_node)
>> + return ERR_PTR(-ENODEV);
>> +
>> + np = dev->of_node;
>> +
>> + /*
>> +* When the consumer DT node do not have "interconnects" property
>> +* return a NULL path to skip setting constraints.
>> +*/
>> + if (!of_find_property(np, "interconnects", NULL))
>> + return NULL;
>> +
>> + /*
>> +* We use a combination of phandle and specifier for endpoint. For
>> now
>> +* lets support only global ids and extend this is the future if
>> needed
>
> s/is the future/in the future/
Ok.
>> +* without breaking DT compatibility.
>> +*/
>> + if (name) {
>> + idx = of_property_match_string(np, "interconnect-names",
>> name);
>> + if (idx < 0)
>> + return ERR_PTR(idx);
>> + }
>> +
>> + ret = of_parse_phandle_with_args(np, "interconnects",
>> +"#interconnect-cells", idx * 2,
>> +&src_args);
>> + if (ret)
>> + return ERR_PTR(ret);
>> +
>> + of_node_put(src_args.np);
>> +
>> + if (!src_args.args_count || src_args.args_count > 1)
>
> This could be src_args.argc_count != 1
>
>> + return ERR_PTR(-EINVAL);
>> +
>> + ret = of_parse_phandle_with_args(np, "interconnects",
>> +
