Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
> Am 11.09.2019 um 08:03 schrieb H. Nikolaus Schaller : > > >> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller : >> >> Hi Adam, >> >>> Am 11.09.2019 um 02:41 schrieb Adam Ford : >> >> >> The error message looks as if we have to enable multi_regulator. >> > > That will enable both vdd and vbb regulators from what I can tell in the > driver. > >> And that may need to rename cpu0-supply to vdd-supply (unless the >> names can be configured). > > That is consistent with what I found. vdd-supply = <&vcc>; and > vbb-supply = <&abb_mpu_iva>; > I put them both under the cpu node. Unfortunately, when I did that, > my board crashed. > > I am thinking it has something to do with the abb_mpu_iva driver > because until this point, we've always operated at 800MHz or lower > which all have the same behavior in abb_mpu_iva. > > With the patch you posted for the regulator, without the update to > cpufreq, and with debugging enabled, I received the following in > dmesg: > > [1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing > 'efuse-address' IO resource > [1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0 > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > [1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=120 ABB=0 > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > [1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0 > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > [1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1 > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > [1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings: > Clk_rate=1300, sr2_cnt=0x0032 > Using an unmodified kernel, I changed the device tree to make the abb regulator power the cpu instead of vcc. After doing so, I was able to read the microvolt value, and it matched the processor's desired OPP voltage, and the debug code showed the abb regulator was attempting to set the various index based on the needed voltage. I think the abb driver is working correctly. I think tomorrow, I will re-apply the patches and tweak it again to support both vdd and vbb regulators. If it crashes again, I'll look more closely at the logs to see if I can determine why. I think it's pretty close. I also need to go back and find the SmartReflex stuff as well. >>> Well, I couldn't give it up for the night, so I thought I'd show my data >>> dump >>> >>> [9.807647] [ cut here ] >>> [9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630 >>> dev_pm_opp_set_rate+0x3cc/0x480 >>> [9.821044] Modules linked in: sha256_generic sha256_arm cfg80211 >>> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class >>> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v >>> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common >>> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery >>> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph >>> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt >>> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+) >>> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+) >>> twl4030_pwrbutton sn >>> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio >>> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004 >>> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm >>> drm_panel_or >>> ientation_quirks cec >>> [9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted >>> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5 >>> [9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree) >>> [9.909515] Workqueue: events dbs_work_handler >>> [9.914031] [] (unwind_backtrace) from [] >>> (show_stack+0x10/0x14) >>> [9.921813] [] (show_stack) from [] >>> (dump_stack+0xb4/0xd4) >>> [9.929107] [] (dump_stack) from [] >>> (__warn.part.3+0xa8/0xd4) >>> [9.936614] [] (__warn.part.3) from [] >>> (warn_slowpath_null+0x40/0x4c) >>> [9.944854] [] (warn_slowpath_null) from [] >>> (dev_pm_opp_set_rate+0x3cc/0x480) >>> [9.953796] [] (dev_pm_opp_set_rate) from [] >>> (set_target+0x30/0x58 [cpufreq_dt]) >>> [9.963012] [] (set_target [cpufreq_dt]) from >>> [] (__cpufreq_driver_target+0x188/0x514) >>> [9.972717] [] (__cpufreq_driver_target) from >>> [] (od_dbs_update+0x130/0x15c) >>> [9.981567] [] (od_dbs_update) from [] >>> (dbs_work_handler+0x28/0x58) >>> [9.989624] [] (dbs_work_handler) from [] >>> (process_one_work+0x20c/0x500) >>> [9.998107] [] (process_one_work) from [] >>> (worker_thread+0x2c/0x5bc) >>> [ 10.006256] [] (worker_thread) from [] >>> (kthread+0x134/0x148) >>> [ 10.013702] [] (kthread) from [] >>> (ret_from_fork+0x14/0x2c) >>> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8) >>>
Re: [PATCH] driver core: ensure a device has valid node id in device_add()
On Wed 11-09-19 14:15:51, Yunsheng Lin wrote:
> On 2019/9/11 13:33, Michal Hocko wrote:
> > On Tue 10-09-19 14:53:39, Michal Hocko wrote:
> >> On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
> >>> On 2019/9/10 19:12, Greg KH wrote:
> On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> > On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
> >> On 2019/9/10 17:31, Greg KH wrote:
> >>> On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
> On 2019/9/9 17:53, Greg KH wrote:
> > On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
> >> Currently a device does not belong to any of the numa nodes
> >> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
> >> specified by fw nor by virtual device layer and the device has
> >> no parent device.
> >
> > Is this really a problem?
>
> Not really.
> Someone need to guess the node id when it is not specified, right?
> >>>
> >>> No, why? Guessing guarantees you will get it wrong on some systems.
> >>>
> >>> Are you seeing real problems because the id is not being set? What
> >>> problem is this fixing that you can actually observe?
> >>
> >> When passing the return value of dev_to_node() to cpumask_of_node()
> >> without checking the node id if the node id is not valid, there is
> >> global-out-of-bounds detected by KASAN as below:
> >
> > OK, I seem to remember this being brought up already. And now when I
> > think about it, we really want to make cpumask_of_node NUMA_NO_NODE
> > aware. That means using the same trick the allocator does for this
> > special case.
>
> That seems reasonable to me, and much more "obvious" as to what is going
> on.
>
> >>>
> >>> Ok, thanks for the suggestion.
> >>>
> >>> For arm64 and x86, there are two versions of cpumask_of_node().
> >>>
> >>> when CONFIG_DEBUG_PER_CPU_MAPS is defined, the cpumask_of_node()
> >>>in arch/x86/mm/numa.c is used, which does partial node id checking:
> >>>
> >>> const struct cpumask *cpumask_of_node(int node)
> >>> {
> >>> if (node >= nr_node_ids) {
> >>> printk(KERN_WARNING
> >>> "cpumask_of_node(%d): node > nr_node_ids(%u)\n",
> >>> node, nr_node_ids);
> >>> dump_stack();
> >>> return cpu_none_mask;
> >>> }
> >>> if (node_to_cpumask_map[node] == NULL) {
> >>> printk(KERN_WARNING
> >>> "cpumask_of_node(%d): no node_to_cpumask_map!\n",
> >>> node);
> >>> dump_stack();
> >>> return cpu_online_mask;
> >>> }
> >>> return node_to_cpumask_map[node];
> >>> }
> >>>
> >>> when CONFIG_DEBUG_PER_CPU_MAPS is undefined, the cpumask_of_node()
> >>>in arch/x86/include/asm/topology.h is used:
> >>>
> >>> static inline const struct cpumask *cpumask_of_node(int node)
> >>> {
> >>> return node_to_cpumask_map[node];
> >>> }
> >>
> >> I would simply go with. There shouldn't be any need for heavy weight
> >> checks that CONFIG_DEBUG_PER_CPU_MAPS has.
> >>
> >> static inline const struct cpumask *cpumask_of_node(int node)
> >> {
> >>/* A nice comment goes here */
> >>if (node == NUMA_NO_NODE)
>
> How about "(unsigned int)node >= nr_node_ids", this is suggested
> by Peter, it checks the case where the node id set by fw is bigger
> or equal than nr_node_ids, and still handle the < 0 case, which
> includes NUMA_NO_NODE.
Isn't that a plain bug? Is something like that really happening?
> Maybe define a macro like below to do that in order to do
> the node checking consistently through kernel:
>
> #define numa_node_valid(node) ((unsigned int)(node) < nr_node_ids)
>
>
> >>return node_to_cpumask_map[numa_mem_id()];
> >> return node_to_cpumask_map[node];
> >> }
> >
> > Sleeping over this and thinking more about the actual semantic the above
> > is wrong. We cannot really copy the page allocator logic. Why? Simply
> > because the page allocator doesn't enforce the near node affinity. It
> > just picks it up as a preferred node but then it is free to fallback to
> > any other numa node. This is not the case here and node_to_cpumask_map will
> > only restrict to the particular node's cpus which would have really non
> > deterministic behavior depending on where the code is executed. So in
> > fact we really want to return cpu_online_mask for NUMA_NO_NODE.
>
> From below, if the __GFP_THISNODE is set, the fallback is not performed.
__GFP_THISNODE is a very specific situation when the caller knows which
node should be used for the allocation. NUMA_NO_NODE && __GFP_THISNODE
is a bug and I would dare to call it an undefined behavior.
> For node_to_cpumask_map() case, maybe we can return the cpumask that is
> on the node of cpu_to_node(raw_smp_processor_
Re: [PATCH 2/2] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
On Fri, Aug 23, 2019 at 12:37:35AM +, Fancy Fang wrote:
> The mipi pll clock comes from the MIPI PHY PLL output, so
> it should not be a fixed clock.
>
> MIPI PHY PLL is in the MIPI DSI space, and it is used as
> the bit clock for transferring the pixel data out and its
> output clock is configured according to the display mode.
>
> So it should be used only for MIPI DSI and not be exported
> out for other usages.
>
> Signed-off-by: Fancy Fang
> ---
> .../devicetree/bindings/clock/imx7ulp-clock.txt | 1 -
> drivers/clk/imx/clk-imx7ulp.c | 3 +--
> include/dt-bindings/clock/imx7ulp-clock.h | 15 +++
> 3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> index a4f8cd478f92..93d89adb7afe 100644
> --- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> @@ -82,7 +82,6 @@ pcc2: pcc2@403f {
><&scg1 IMX7ULP_CLK_APLL_PFD0>,
><&scg1 IMX7ULP_CLK_UPLL>,
><&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
> - <&scg1 IMX7ULP_CLK_MIPI_PLL>,
><&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
><&scg1 IMX7ULP_CLK_ROSC>,
><&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;
> diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
> index 2022d9bead91..459b120b71d5 100644
> --- a/drivers/clk/imx/clk-imx7ulp.c
> +++ b/drivers/clk/imx/clk-imx7ulp.c
> @@ -28,7 +28,7 @@ static const char * const scs_sels[]= {
> "dummy", "sosc", "sirc", "firc", "dumm
> static const char * const ddr_sels[] = { "apll_pfd_sel", "upll", };
> static const char * const nic_sels[] = { "firc", "ddr_clk", };
> static const char * const periph_plat_sels[] = { "dummy", "nic1_bus_clk",
> "nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
> -static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk",
> "mpll", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
> +static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk",
> "dummy", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk",
> };
> static const char * const arm_sels[] = { "divcore", "dummy",
> "dummy", "hsrun_divcore", };
>
> /* used by sosc/sirc/firc/ddr/spll/apll dividers */
> @@ -75,7 +75,6 @@ static void __init imx7ulp_clk_scg1_init(struct device_node
> *np)
> clks[IMX7ULP_CLK_SOSC] = imx_obtain_fixed_clk_hw(np, "sosc");
> clks[IMX7ULP_CLK_SIRC] = imx_obtain_fixed_clk_hw(np, "sirc");
> clks[IMX7ULP_CLK_FIRC] = imx_obtain_fixed_clk_hw(np, "firc");
> - clks[IMX7ULP_CLK_MIPI_PLL] = imx_obtain_fixed_clk_hw(np, "mpll");
> clks[IMX7ULP_CLK_UPLL] = imx_obtain_fixed_clk_hw(np, "upll");
>
> /* SCG1 */
> diff --git a/include/dt-bindings/clock/imx7ulp-clock.h
> b/include/dt-bindings/clock/imx7ulp-clock.h
> index 6f66f9005c81..f8d34fb4378f 100644
> --- a/include/dt-bindings/clock/imx7ulp-clock.h
> +++ b/include/dt-bindings/clock/imx7ulp-clock.h
> @@ -49,15 +49,14 @@
> #define IMX7ULP_CLK_NIC1_DIV 36
> #define IMX7ULP_CLK_NIC1_BUS_DIV 37
> #define IMX7ULP_CLK_NIC1_EXT_DIV 38
> -#define IMX7ULP_CLK_MIPI_PLL 39
> -#define IMX7ULP_CLK_SIRC 40
> -#define IMX7ULP_CLK_SOSC_BUS_CLK 41
> -#define IMX7ULP_CLK_FIRC_BUS_CLK 42
> -#define IMX7ULP_CLK_SPLL_BUS_CLK 43
> -#define IMX7ULP_CLK_HSRUN_SYS_SEL44
> -#define IMX7ULP_CLK_HSRUN_CORE_DIV 45
> +#define IMX7ULP_CLK_SIRC 39
> +#define IMX7ULP_CLK_SOSC_BUS_CLK 40
> +#define IMX7ULP_CLK_FIRC_BUS_CLK 41
> +#define IMX7ULP_CLK_SPLL_BUS_CLK 42
> +#define IMX7ULP_CLK_HSRUN_SYS_SEL43
> +#define IMX7ULP_CLK_HSRUN_CORE_DIV 44
No. These clock IDs need to be stable, as they are referred by DT.
If you want to remove an ID, just remove it, keep others unchanged.
Shawn
>
> -#define IMX7ULP_CLK_SCG1_END 46
> +#define IMX7ULP_CLK_SCG1_END 45
>
> /* PCC2 */
> #define IMX7ULP_CLK_DMA1 0
> --
> 2.17.1
>
Re: [PATCH] mm: Add callback for defining compaction completion
On Tue 10-09-19 22:27:53, Nitin Gupta wrote: [...] > > On Tue 10-09-19 13:07:32, Nitin Gupta wrote: > > > For some applications we need to allocate almost all memory as > > > hugepages. > > > However, on a running system, higher order allocations can fail if the > > > memory is fragmented. Linux kernel currently does on-demand > > > compaction > > > as we request more hugepages but this style of compaction incurs very > > > high latency. Experiments with one-time full memory compaction > > > (followed by hugepage allocations) shows that kernel is able to > > > restore a highly fragmented memory state to a fairly compacted memory > > > state within <1 sec for a 32G system. Such data suggests that a more > > > proactive compaction can help us allocate a large fraction of memory > > > as hugepages keeping allocation latencies low. > > > > > > In general, compaction can introduce unexpected latencies for > > > applications that don't even have strong requirements for contiguous > > > allocations. Could you expand on this a bit please? Gfp flags allow to express how much the allocator try and compact for a high order allocations. Hugetlb allocations tend to require retrying and heavy compaction to succeed and the success rate tends to be pretty high from my experience. Why that is not case in your case? > > > It is also hard to efficiently determine if the current > > > system state can be easily compacted due to mixing of unmovable > > > memory. Due to these reasons, automatic background compaction by the > > > kernel itself is hard to get right in a way which does not hurt > > > unsuspecting > > applications or waste CPU cycles. > > > > We do trigger background compaction on a high order pressure from the > > page allocator by waking up kcompactd. Why is that not sufficient? > > > > Whenever kcompactd is woken up, it does just enough work to create > one free page of the given order (compaction_control.order) or higher. This is an implementation detail IMHO. I am pretty sure we can do a better auto tuning when there is an indication of a constant flow of high order requests. This is no different from the memory reclaim in principle. Just because the kswapd autotuning not fitting with your particular workload you wouldn't want to export direct reclaim functionality and call it from a random module. That is just doomed to fail because different subsystems in control just leads to decisions going against each other. > Such a design causes very high latency for workloads where we want > to allocate lots of hugepages in short period of time. With pro-active > compaction we can hide much of this latency. For some more background > discussion and data, please see this thread: > > https://patchwork.kernel.org/patch/11098289/ I am aware of that thread. And there are two things. You claim the allocation success rate is unnecessarily lower and that the direct latency is high. You simply cannot assume both low latency and high success rate. Compaction is not free. Somebody has to do the work. Hiding it into the background means that you are eating a lot of cycles from everybody else (think of a workload running in a restricted cpu controller just doing a lot of work in an unaccounted context). That being said you really have to be prepared to pay a price for precious resource like high order pages. On the other hand I do understand that high latency is not really desired for a more optimistic allocation requests with a reasonable fallback strategy. Those would benefit from kcompactd not giving up too early. > > > Even with these caveats, pro-active compaction can still be very > > > useful in certain scenarios to reduce hugepage allocation latencies. > > > This callback interface allows drivers to drive compaction based on > > > their own policies like the current level of external fragmentation > > > for a particular order, system load etc. > > > > So we do not trust the core MM to make a reasonable decision while we give > > a free ticket to modules. How does this make any sense at all? How is a > > random module going to make a more informed decision when it has less > > visibility on the overal MM situation. > > > > Embedding any specific policy (like: keep external fragmentation for order-9 > between 30-40%) within MM core looks like a bad idea. Agreed > As a driver, we > can easily measure parameters like system load, current fragmentation level > for any order in any zone etc. to make an informed decision. > See the thread I refereed above for more background discussion. Do that from the userspace then. If there is an insufficient interface to do that then let's talk about what is missing. > > If you need to control compaction from the userspace you have an interface > > for that. It is also completely unexplained why you need a completion > > callback. > > > > /proc/sys/vm/compact_memory does whole system compaction which is > often too much as a pro-active compaction strategy. To get more
Re: [PATCH 1/2] ARM: dts: imx7ulp: remove mipi pll clock node
On Fri, Aug 23, 2019 at 12:37:30AM +, Fancy Fang wrote: > According to the IMX7ULP reference manual, the mipi pll > clock comes from the MIPI PHY PLL output. So it should > not be defined as a fixed clock. So remove this clock > node and all the references to it. > > Signed-off-by: Fancy Fang Applied, thanks.
[PATCH 2/3] USB: host: ohci-at91: suspend: delay needed before to stop clocks
In order to completely remove marginal power consumption in PM suspend, we need to let the controller settle down before being stopped. In ohci_hcd_at91_drv_suspend() function, one additional delay is needed before to stop the clocks. Reported-by: Boris Krasnovskiy Signed-off-by: Nicolas Ferre --- drivers/usb/host/ohci-at91.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index cb63bcd5049a..85d67fe42d59 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -628,6 +628,7 @@ ohci_hcd_at91_drv_suspend(struct device *dev) /* flush the writes */ (void) ohci_readl (ohci, &ohci->regs->control); + msleep(1); at91_stop_clock(ohci_at91); } -- 2.17.1
[PATCH 3/3] USB: host: ohci-at91: resume: balance the clock start call
From: Boris Krasnovskiy There is a clock enable counter run away problem in resume ohci_at91. Code enables clock that was never disabled in case of non wakeup interface. That would make clock unstoppable in future. Use proper alternative to start clocks only if they were stopped before. Signed-off-by: Boris Krasnovskiy Signed-off-by: Nicolas Ferre --- drivers/usb/host/ohci-at91.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index 85d67fe42d59..513e48397743 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -643,8 +643,8 @@ ohci_hcd_at91_drv_resume(struct device *dev) if (ohci_at91->wakeup) disable_irq_wake(hcd->irq); - - at91_start_clock(ohci_at91); + else + at91_start_clock(ohci_at91); ohci_resume(hcd, false); -- 2.17.1
[PATCH 1/3] USB: host: ohci-at91: completely shutdown the controller in at91_stop_hc()
From: Boris Krasnovskiy When removing the ohci-at91 module, the fact of not running complete shutdown of all the ports was keeping additional analog cells consuming power for no reason. Doing Reset (OHCI_HCR) to HcCommandStatus register is the way to go, but using the OHCI controller shutdown procedure is just perfect for this. Signed-off-by: Boris Krasnovskiy Signed-off-by: Nicolas Ferre --- drivers/usb/host/ohci-at91.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index fc35a7993b7b..cb63bcd5049a 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -123,7 +123,7 @@ static void at91_stop_hc(struct platform_device *pdev) /* * Put the USB host controller into reset. */ - writel(0, ®s->control); + usb_hcd_platform_shutdown(pdev); /* * Stop the USB clocks. -- 2.17.1
[PATCH 0/3] USB: host: ohci-at91: tailor power consumption
Following a set of experiments we found areas of improvement for OHCI power consumption (and associated USB analog cells). This enhances the shutdown of residual power consumption in case of Linux suspend/resume and removal of the driver (when compiled as a module). Best regards, Nicolas Boris Krasnovskiy (2): USB: host: ohci-at91: completely shutdown the controller in at91_stop_hc() USB: host: ohci-at91: resume: balance the clock start call Nicolas Ferre (1): USB: host: ohci-at91: suspend: delay needed before to stop clocks drivers/usb/host/ohci-at91.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.17.1
[PATCH] clk: at91: allow 24 Mhz clock as input for PLL
From: Eugen Hristev
The PLL input range needs to be able to allow 24 Mhz crystal as input
Update the range accordingly in plla characteristics struct
Signed-off-by: Eugen Hristev
---
drivers/clk/at91/sama5d2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
index 6509d09..0de1108 100644
--- a/drivers/clk/at91/sama5d2.c
+++ b/drivers/clk/at91/sama5d2.c
@@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
};
static const struct clk_pll_characteristics plla_characteristics = {
- .input = { .min = 1200, .max = 1200 },
+ .input = { .min = 1200, .max = 2400 },
.num_output = ARRAY_SIZE(plla_outputs),
.output = plla_outputs,
.icpll = plla_icpll,
--
2.7.4
Re: [PATCH 00/10] Hwpoison soft-offline rework
On 2019-09-11 08:22, Naoya Horiguchi wrote: I found another panic ... Hi Naoya, Thanks for giving it a try. Are these testcase public? I will definetely take a look and try to solve these cases. Thanks! This testcase is testing the corner case where hugepage migration fails by allocation failure on destination numa node which is caused by the condition that all remaining free hugetlb are reserved. [ 2610.711713] ===> testcase 'page_migration/hugetlb_madv_soft_reserve_noovercommit.auto2' start [ 2610.995836] bash (15807): drop_caches: 3 [ 2612.596154] Soft offlining pfn 0x1d000 at process virtual address 0x7000 [ 2612.910245] bash (15807): drop_caches: 3 [ 2613.099769] page:f4ba4074 refcount:1 mapcount:-128 mapping: index:0x0 [ 2613.102099] flags: 0xfffe00080(hwpoison) [ 2613.103424] raw: 000fffe00080 9c953ffd5af8 f4ba40e78008 [ 2613.105817] raw: 0009 0001ff7f [ 2613.107703] page dumped because: VM_BUG_ON_PAGE(page_count(buddy) != 0) [ 2613.109485] [ cut here ] [ 2613.110834] kernel BUG at mm/page_alloc.c:821! [ 2613.112015] invalid opcode: [#1] SMP PTI [ 2613.113245] CPU: 0 PID: 16195 Comm: sysctl Not tainted 5.3.0-rc8-v5.3-rc8-190911-1025-00010-ga436dbce8674+ #18 [ 2613.115982] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 [ 2613.118495] RIP: 0010:free_one_page+0x5f1/0x610 [ 2613.119803] Code: 09 7e 81 49 8d b4 17 c0 00 00 00 8b 14 24 48 89 ef e8 83 75 00 00 e9 16 fe ff ff 48 c7 c6 c0 2b 0d 82 4c 89 e7 e8 9f c3 fd ff <0f> 0b 48 c7 c6 c0 2b 0d 82 e8 91 c3 fd ff 0f 0b 66 66 2e 0f 1f 84 [ 2613.124751] RSP: 0018:ac7442727ca8 EFLAGS: 00010046 [ 2613.126224] RAX: 003b RBX: 0009 RCX: 0006 [ 2613.128261] RDX: RSI: RDI: 820d1814 [ 2613.130299] RBP: f4ba40748000 R08: 0710 R09: 004a [ 2613.132082] R10: R11: ac7442727b20 R12: f4ba4074 [ 2613.133821] R13: 0001d200 R14: R15: 9c953ffd5680 [ 2613.135769] FS: 7fbf2e6cb900() GS:9c953da0() knlGS: [ 2613.138077] CS: 0010 DS: ES: CR0: 80050033 [ 2613.139721] CR2: 55eef99d4d38 CR3: 7cb5 CR4: 001406f0 [ 2613.141747] Call Trace: [ 2613.142472] __free_pages_ok+0x175/0x4e0 [ 2613.143454] free_pool_huge_page+0xec/0x100 [ 2613.144500] __nr_hugepages_store_common+0x173/0x2e0 [ 2613.145968] ? __do_proc_doulongvec_minmax+0x3ae/0x440 [ 2613.147444] hugetlb_sysctl_handler_common+0xad/0xc0 [ 2613.148867] proc_sys_call_handler+0x1a5/0x1c0 [ 2613.150104] vfs_write+0xa5/0x1a0 [ 2613.151081] ksys_write+0x59/0xd0 [ 2613.152052] do_syscall_64+0x5f/0x1a0 [ 2613.153071] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2613.154327] RIP: 0033:0x7fbf2eb01ed8 On Wed, Sep 11, 2019 at 05:29:56AM +, Horiguchi Naoya(堀口 直也) wrote: Hi Oscar, Thank you for your working on this. My testing shows the following error: [ 1926.932435] ===> testcase 'mce_ksm_soft-offline_avoid_access.auto2' start [ 1927.155321] bash (15853): drop_caches: 3 [ 1929.019094] page:e5c384c4cd40 refcount:1 mapcount:0 mapping:0003 index:0x70001 [ 1929.021586] anon [ 1929.021588] flags: 0x57ffe00088000e(referenced|uptodate|dirty|swapbacked|hwpoison) [ 1929.024289] raw: 0057ffe00088000e dead0100 dead0122 0003 [ 1929.026611] raw: 00070001 [ 1929.028760] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)) [ 1929.030559] [ cut here ] [ 1929.031684] kernel BUG at mm/internal.h:73! [ 1929.032738] invalid opcode: [#1] SMP PTI [ 1929.033941] CPU: 3 PID: 16052 Comm: mceinj.sh Not tainted 5.3.0-rc8-v5.3-rc8-190911-1025-00010-ga436dbce8674+ #18 [ 1929.037137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 [ 1929.040066] RIP: 0010:page_set_poison+0xf9/0x160 [ 1929.041665] Code: 63 02 7f 31 c0 5b 5d 41 5c c3 48 c7 c6 d0 d1 0c b0 48 89 df e8 88 bb f8 ff 0f 0b 48 c7 c6 f0 2a 0d b0 48 89 df e8 77 bb f8 ff <0f> 0b 48 8b 45 00 48 c1 e8 33 83 e0 07 83 f8 04 75 89 48 8b 45 08 [ 1929.047773] RSP: 0018:b4fb8a73bde0 EFLAGS: 00010246 [ 1929.049511] RAX: 0039 RBX: e5c384c4cd40 RCX: [ 1929.051870] RDX: RSI: RDI: b00d1814 [ 1929.054238] RBP: e5c384c4cd40 R08: 0596 R09: 0048 [ 1929.056599] R10: R11: b4fb8a73bc58 R12: [ 1929.058986] R13: b4fb8a73be10 R14: 00131335 R15: 0001 [ 1929.061366] FS: 7fc9e208d740() GS:9fa9bdb0(0
Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
On Tue, Aug 27, 2019 at 09:16:39PM +0300, Vladimir Oltean wrote: > On Tue, 27 Aug 2019 at 21:13, Mark Brown wrote: > > > > On Tue, Aug 27, 2019 at 09:06:14PM +0300, Vladimir Oltean wrote: > > > On Tue, 27 Aug 2019 at 21:05, Mark Brown wrote: > > > > On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote: > > > > > > > I noticed you skipped applying this patch, and I'm not sure that Shawn > > > > > will review it/take it. > > > > > Do you have a better suggestion how I can achieve putting the DSPI > > > > > driver in poll mode for this board? A Kconfig option maybe? > > > > > > DT changes go through the relevant platform trees, not the > > > > subsystem trees, so it's not something I'd expect to apply. > > > > > But at least is it something that you expect to see done through a > > > device tree change? > > > > Well, it's not ideal - if it performs better all the time the > > driver should probably just do it unconditionally. If there's > > some threashold where it tends to perform better then the driver > > should check for that but IIRC it sounds like the interrupt just > > isn't at all helpful here. > > I can't seem to find any situation where it performs worse. Hence my > question on whether it's a better idea to condition this behavior on a > Kconfig option rather than a DT blob which may or may not be in sync. DT is a description of hardware not condition for software behavior, where module parameter is usually used for. Shawn
Re: [PATCH 1/2] ASoC: fsl_mqs: add DT binding documentation
Hi Shengjiu,
Your mail is dated in the future, its time is 16:42 (GMT+2) whereas it
is still the morning.
Please fix your clock or timezone for future mails.
Thanks
Christophe
Le 11/09/2019 à 16:42, Shengjiu Wang a écrit :
Add the DT binding documentation for NXP MQS driver
Signed-off-by: Shengjiu Wang
---
.../devicetree/bindings/sound/fsl,mqs.txt | 20 +++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,mqs.txt
diff --git a/Documentation/devicetree/bindings/sound/fsl,mqs.txt
b/Documentation/devicetree/bindings/sound/fsl,mqs.txt
new file mode 100644
index ..a1dbe181204a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,mqs.txt
@@ -0,0 +1,20 @@
+fsl,mqs audio CODEC
+
+Required properties:
+
+ - compatible : Must contain one of "fsl,imx6sx-mqs", "fsl,codec-mqs"
+ "fsl,imx8qm-mqs", "fsl,imx8qxp-mqs".
+ - clocks : A list of phandles + clock-specifiers, one for each entry in
+clock-names
+ - clock-names : Must contain "mclk"
+ - gpr : The gpr node.
+
+Example:
+
+mqs: mqs {
+ compatible = "fsl,imx6sx-mqs";
+ gpr = <&gpr>;
+ clocks = <&clks IMX6SX_CLK_SAI1>;
+ clock-names = "mclk";
+ status = "disabled";
+};
Re: [PATCH v2] dt-bindings: arm: samsung: Convert Samsung Exynos IOMMU H/W, System MMU to dt-schema
On Tue, 10 Sep 2019 at 17:52, Maciej Falkowski wrote:
>
> Convert Samsung Exynos IOMMU H/W, System Memory Management Unit
> to newer dt-schema format.
>
> Update clock description.
>
> Signed-off-by: Maciej Falkowski
> Signed-off-by: Andrzej Hajda
> ---
> Hi Krzysztof,
>
> Thank you for feedback.
>
> New changes:
> - style fixes including missing empty lines,
> deletion of unneeded descriptions
>
> - fix mistake where one example was split
> into two separete ones.
>
> There are some updates with clock description. I have spoken with
> Marek Szyprowski and the right setup for clocks seems to be two pairs:
> "sysmmu" with optional "master" or a pair of "aclk" + "pclk".
>
> The option: "aclk" + "pclk" + "master" was never used in any
> of device bindings and there are none compilation problems with that.
>
> In so, clock-names are rewritten to handle this version
> and maximal clock number is set to two.
>
> Best regards,
> Maciej Falkowski
> ---
> .../bindings/iommu/samsung,sysmmu.txt | 67 ---
> .../bindings/iommu/samsung,sysmmu.yaml| 112 ++
> 2 files changed, 112 insertions(+), 67 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
> create mode 100644
> Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
> b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
> deleted file mode 100644
> index 525ec82615a6..
> --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
> +++ /dev/null
> @@ -1,67 +0,0 @@
> -Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit)
> -
> -Samsung's Exynos architecture contains System MMUs that enables scattered
> -physical memory chunks visible as a contiguous region to DMA-capable
> peripheral
> -devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> -
> -System MMU is an IOMMU and supports identical translation table format to
> -ARMv7 translation tables with minimum set of page properties including access
> -permissions, shareability and security protection. In addition, System MMU
> has
> -another capabilities like L2 TLB or block-fetch buffers to minimize
> translation
> -latency.
> -
> -System MMUs are in many to one relation with peripheral devices, i.e. single
> -peripheral device might have multiple System MMUs (usually one for each bus
> -master), but one System MMU can handle transactions from only one peripheral
> -device. The relation between a System MMU and the peripheral device needs to
> be
> -defined in device node of the peripheral device.
> -
> -MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2
> System
> -MMUs.
> -* MFC has one System MMU on its left and right bus.
> -* FIMD in Exynos5420 has one System MMU for window 0 and 4, the other system
> MMU
> - for window 1, 2 and 3.
> -* M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel
> and
> - the other System MMU on the write channel.
> -
> -For information on assigning System MMU controller to its peripheral devices,
> -see generic IOMMU bindings.
> -
> -Required properties:
> -- compatible: Should be "samsung,exynos-sysmmu"
> -- reg: A tuple of base address and size of System MMU registers.
> -- #iommu-cells: Should be <0>.
> -- interrupts: An interrupt specifier for interrupt signal of System MMU,
> - according to the format defined by a particular interrupt
> - controller.
> -- clock-names: Should be "sysmmu" or a pair of "aclk" and "pclk" to gate
> - SYSMMU core clocks.
> - Optional "master" if the clock to the System MMU is gated by
> - another gate clock other core (usually main gate clock
> - of peripheral device this SYSMMU belongs to).
> -- clocks: Phandles for respective clocks described by clock-names.
> -- power-domains: Required if the System MMU is needed to gate its power.
> - Please refer to the following document:
> - Documentation/devicetree/bindings/power/pd-samsung.txt
> -
> -Examples:
> - gsc_0: gsc@13e0 {
> - compatible = "samsung,exynos5-gsc";
> - reg = <0x13e0 0x1000>;
> - interrupts = <0 85 0>;
> - power-domains = <&pd_gsc>;
> - clocks = <&clock CLK_GSCL0>;
> - clock-names = "gscl";
> - iommus = <&sysmmu_gsc0>;
> - };
> -
> - sysmmu_gsc0: sysmmu@13e8 {
> - compatible = "samsung,exynos-sysmmu";
> - reg = <0x13E8 0x1000>;
> - interrupt-parent = <&combiner>;
> - interrupts = <2 0>;
> - clock-names = "sysmmu", "master";
> - clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
> - power-domains = <&pd_gsc>;
> - #iommu-cells = <0>;
> - };
> diff --git a/Documentation/devicetree/bi
Re: [PATCH v7 0/5] kasan: support backing vmalloc space with real shadow memory
Hi Daniel, Are any other patches required prior to this series ? I have tried to apply it on later powerpc/merge branch without success: [root@localhost linux-powerpc]# git am /root/Downloads/kasan-support-backing-vmalloc-space-with-real-shadow-memory\(1\).patch Applying: kasan: support backing vmalloc space with real shadow memory .git/rebase-apply/patch:389: trailing whitespace. * (1) (2) (3) error: patch failed: lib/Kconfig.kasan:142 error: lib/Kconfig.kasan: patch does not apply Patch failed at 0001 kasan: support backing vmalloc space with real shadow memory The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [root@localhost linux-powerpc]# git am -3 /root/Downloads/kasan-support-backing-vmalloc-space-with-real-shadow-memory\(1\).patch Applying: kasan: support backing vmalloc space with real shadow memory error: sha1 information is lacking or useless (include/linux/vmalloc.h). error: could not build fake ancestor Patch failed at 0001 kasan: support backing vmalloc space with real shadow memory The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Christophe On 09/03/2019 02:55 PM, Daniel Axtens wrote: Currently, vmalloc space is backed by the early shadow page. This means that kasan is incompatible with VMAP_STACK. This series provides a mechanism to back vmalloc space with real, dynamically allocated memory. I have only wired up x86, because that's the only currently supported arch I can work with easily, but it's very easy to wire up other architectures, and it appears that there is some work-in-progress code to do this on arm64 and s390. This has been discussed before in the context of VMAP_STACK: - https://bugzilla.kernel.org/show_bug.cgi?id=202009 - https://lkml.org/lkml/2018/7/22/198 - https://lkml.org/lkml/2019/7/19/822 In terms of implementation details: Most mappings in vmalloc space are small, requiring less than a full page of shadow space. Allocating a full shadow page per mapping would therefore be wasteful. Furthermore, to ensure that different mappings use different shadow pages, mappings would have to be aligned to KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE. Instead, share backing space across multiple mappings. Allocate a backing page when a mapping in vmalloc space uses a particular page of the shadow region. This page can be shared by other vmalloc mappings later on. We hook in to the vmap infrastructure to lazily clean up unused shadow memory. v1: https://lore.kernel.org/linux-mm/20190725055503.19507-1-...@axtens.net/ v2: https://lore.kernel.org/linux-mm/20190729142108.23343-1-...@axtens.net/ Address review comments: - Patch 1: use kasan_unpoison_shadow's built-in handling of ranges that do not align to a full shadow byte - Patch 3: prepopulate pgds rather than faulting things in v3: https://lore.kernel.org/linux-mm/20190731071550.31814-1-...@axtens.net/ Address comments from Mark Rutland: - kasan_populate_vmalloc is a better name - handle concurrency correctly - various nits and cleanups - relax module alignment in KASAN_VMALLOC case v4: https://lore.kernel.org/linux-mm/20190815001636.12235-1-...@axtens.net/ Changes to patch 1 only: - Integrate Mark's rework, thanks Mark! - handle the case where kasan_populate_shadow might fail - poision shadow on free, allowing the alloc path to just unpoision memory that it uses v5: https://lore.kernel.org/linux-mm/20190830003821.10737-1-...@axtens.net/ Address comments from Christophe Leroy: - Fix some issues with my descriptions in commit messages and docs - Dynamically free unused shadow pages by hooking into the vmap book-keeping - Split out the test into a separate patch - Optional patch to track the number of pages allocated - minor checkpatch cleanups v6: https://lore.kernel.org/linux-mm/20190902112028.23773-1-...@axtens.net/ Properly guard freeing pages in patch 1, drop debugging code. v7: Add a TLB flush on freeing, thanks Mark Rutland. Explain more clearly how I think freeing is concurrency-safe. Daniel Axtens (5): kasan: support backing vmalloc space with real shadow memory kasan: add test for vmalloc fork: support VMAP_STACK with KASAN_VMALLOC x86/kasan: support KASAN_VMALLOC kasan debug: track pages allocated for vmalloc shadow Documentation/dev-tools/kasan.rst | 63 arch/Kconfig | 9 +- arch/x86/Kconfig | 1 + arch/x86/mm/kasan_init_64.c | 60 include/linux/kasan.h | 31 include/linux
RE: [v2] ACPI: support for NXP i2c controller
Hi rafael, wolfram
Any comments about this?
>
> Enable NXP i2c controller to boot with ACPI
>
> Signed-off-by: Meenakshi Aggarwal
> Signed-off-by: Udit Kumar
> Signed-off-by: Chuanhua Han
> Signed-off-by: Biwen Li
> ---
> Change in v2:
> - Simplify code
> - Adjust header file order
> - Not use ACPI_PTR()
>
> drivers/acpi/acpi_apd.c | 7 +++
> drivers/i2c/busses/i2c-imx.c | 17 +
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> 7cd0c9ac71ea..71511ae2dfcd 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -160,11 +160,17 @@ static const struct apd_device_desc hip08_i2c_desc
> = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 25000,
> };
> +
> static const struct apd_device_desc thunderx2_i2c_desc = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 12500,
> };
>
> +static const struct apd_device_desc nxp_i2c_desc = {
> + .setup = acpi_apd_setup,
> + .fixed_clk_rate = 35000,
> +};
> +
> static const struct apd_device_desc hip08_spi_desc = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 25000,
> @@ -238,6 +244,7 @@ static const struct acpi_device_id acpi_apd_device_ids[]
> = {
> { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> { "HISI0173", APD_ADDR(hip08_spi_desc) },
> + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> #endif
> { }
> };
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index
> 15f6cde6452f..a3b61336fe55 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -20,6 +20,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[] =
> { }; MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
>
> +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> +
> static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx) {
> return i2c_imx->hwdata->devtype == IMX1_I2C; @@ -1048,14 +1055,13
> @@ static const struct i2c_algorithm i2c_imx_algo = {
>
> static int i2c_imx_probe(struct platform_device *pdev) {
> - const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> -&pdev->dev);
> struct imx_i2c_struct *i2c_imx;
> struct resource *res;
> struct imxi2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
> void __iomem *base;
> int irq, ret;
> dma_addr_t phy_addr;
> + const struct imx_i2c_hwdata *match;
>
> dev_dbg(&pdev->dev, "<%s>\n", __func__);
>
> @@ -1075,8 +1081,9 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> if (!i2c_imx)
> return -ENOMEM;
>
> - if (of_id)
> - i2c_imx->hwdata = of_id->data;
> + match = device_get_match_data(&pdev->dev);
> + if (match)
> + i2c_imx->hwdata = match;
> else
> i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> platform_get_device_id(pdev)->driver_data;
> @@ -1089,6 +1096,7 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> i2c_imx->adapter.nr = pdev->id;
> i2c_imx->adapter.dev.of_node= pdev->dev.of_node;
> i2c_imx->base = base;
> + ACPI_COMPANION_SET(&i2c_imx->adapter.dev,
> ACPI_COMPANION(&pdev->dev));
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(&pdev->dev, NULL); @@ -1247,6 +1255,7
> @@ static struct platform_driver i2c_imx_driver = {
> .name = DRIVER_NAME,
> .pm = &i2c_imx_pm_ops,
> .of_match_table = i2c_imx_dt_ids,
> + .acpi_match_table = i2c_imx_acpi_ids,
> },
> .id_table = imx_i2c_devtype,
> };
> --
> 2.17.1
Re: [PATCH V4 3/4] ARM: imx_v6_v7_defconfig: Enable CONFIG_IMX7ULP_WDT by default
On Wed, Aug 21, 2019 at 10:37:42PM -0400, Anson Huang wrote: > Select CONFIG_IMX7ULP_WDT by default to support i.MX7ULP watchdog. > > Signed-off-by: Anson Huang Patch #4 and #5 look good to me, and I will pick them up once the first 3 get applied by Guenter. Shawn
RE: [EXT] Re: [v2] ACPI: support for NXP i2c controller
、>
> Caution: EXT Email
>
> On Fri, Sep 6, 2019 at 11:03 AM Biwen Li wrote:
> >
> > From: Chuanhua Han
> >
> > Enable NXP i2c controller to boot with ACPI
> >
>
> Thanks, the code looks good to me,
> Reviewed-by: Andy Shevchenko
>
> though...
>
> > Signed-off-by: Meenakshi Aggarwal
> > Signed-off-by: Udit Kumar
> > Signed-off-by: Chuanhua Han
>
> This SoB chain is a bit odd. Who is the author of this? The first SoB in the
> chain
> usually points to the first (main) author. There is also possible to change
> that,
> though in that case for the rest we now use Co-developed-by tag rather than
> SoB.
> In any case, if Rafael and Wolfram are okay with this, I have no objections.
Thanks.
>
> > Signed-off-by: Biwen Li
> > ---
> > Change in v2:
> > - Simplify code
> > - Adjust header file order
> > - Not use ACPI_PTR()
> >
> > drivers/acpi/acpi_apd.c | 7 +++
> > drivers/i2c/busses/i2c-imx.c | 17 +
> > 2 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> > 7cd0c9ac71ea..71511ae2dfcd 100644
> > --- a/drivers/acpi/acpi_apd.c
> > +++ b/drivers/acpi/acpi_apd.c
> > @@ -160,11 +160,17 @@ static const struct apd_device_desc
> hip08_i2c_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 25000,
> > };
> > +
> > static const struct apd_device_desc thunderx2_i2c_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 12500,
> > };
> >
> > +static const struct apd_device_desc nxp_i2c_desc = {
> > + .setup = acpi_apd_setup,
> > + .fixed_clk_rate = 35000,
> > +};
> > +
> > static const struct apd_device_desc hip08_spi_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 25000,
> > @@ -238,6 +244,7 @@ static const struct acpi_device_id
> acpi_apd_device_ids[] = {
> > { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> > { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> > { "HISI0173", APD_ADDR(hip08_spi_desc) },
> > + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> > #endif
> > { }
> > };
> > diff --git a/drivers/i2c/busses/i2c-imx.c
> > b/drivers/i2c/busses/i2c-imx.c index 15f6cde6452f..a3b61336fe55 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -20,6 +20,7 @@
> > *
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[]
> > = { }; MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
> >
> > +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> > + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> > +
> > static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx) {
> > return i2c_imx->hwdata->devtype == IMX1_I2C; @@ -1048,14
> > +1055,13 @@ static const struct i2c_algorithm i2c_imx_algo = {
> >
> > static int i2c_imx_probe(struct platform_device *pdev) {
> > - const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> > -
> &pdev->dev);
> > struct imx_i2c_struct *i2c_imx;
> > struct resource *res;
> > struct imxi2c_platform_data *pdata =
> dev_get_platdata(&pdev->dev);
> > void __iomem *base;
> > int irq, ret;
> > dma_addr_t phy_addr;
> > + const struct imx_i2c_hwdata *match;
> >
> > dev_dbg(&pdev->dev, "<%s>\n", __func__);
> >
> > @@ -1075,8 +1081,9 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> > if (!i2c_imx)
> > return -ENOMEM;
> >
> > - if (of_id)
> > - i2c_imx->hwdata = of_id->data;
> > + match = device_get_match_data(&pdev->dev);
> > + if (match)
> > + i2c_imx->hwdata = match;
> > else
> > i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> >
> platform_get_device_id(pdev)->driver_data;
> > @@ -1089,6 +1096,7 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> > i2c_imx->adapter.nr = pdev->id;
> > i2c_imx->adapter.dev.of_node= pdev->dev.of_node;
> > i2c_imx->base = base;
> > + ACPI_COMPANION_SET(&i2c_imx->adapter.dev,
> ACPI_COMPANION(&pdev->dev));
> >
> > /* Get I2C clock */
> > i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> > @@ -1247,6 +1255,7 @@ static struct platform_driver i2c_imx_driver = {
> > .name = DRIVER_NAME,
> > .pm = &i2c_imx_pm_ops,
> > .of_match_table = i2c_imx_dt_ids,
> > + .acpi_match_table = i2c_imx_acpi_ids,
> > },
> > .id_table = imx_i2c_devtype,
> > };
> > --
> > 2.17.1
> >
>
>
> --
> With Best Regards,
> Andy Shevchenko
[PATCH] Staging: octeon: Avoid several usecases of strcpy
strcpy was used multiple times in strcpy to write into dev->name. I replaced them with strscpy. Signed-off-by: Sandro Volery --- drivers/staging/octeon/ethernet.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 8889494adf1f..cf8e9a23ebf9 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -784,7 +784,7 @@ static int cvm_oct_probe(struct platform_device *pdev) priv->imode = CVMX_HELPER_INTERFACE_MODE_DISABLED; priv->port = CVMX_PIP_NUM_INPUT_PORTS; priv->queue = -1; - strcpy(dev->name, "pow%d"); + strscpy(dev->name, "pow%d", sizeof(dev->name)); for (qos = 0; qos < 16; qos++) skb_queue_head_init(&priv->tx_free_list[qos]); dev->min_mtu = VLAN_ETH_ZLEN - mtu_overhead; @@ -856,39 +856,39 @@ static int cvm_oct_probe(struct platform_device *pdev) case CVMX_HELPER_INTERFACE_MODE_NPI: dev->netdev_ops = &cvm_oct_npi_netdev_ops; - strcpy(dev->name, "npi%d"); + strscpy(dev->name, "npi%d", sizeof(dev->name)); break; case CVMX_HELPER_INTERFACE_MODE_XAUI: dev->netdev_ops = &cvm_oct_xaui_netdev_ops; - strcpy(dev->name, "xaui%d"); + strscpy(dev->name, "xaui%d", sizeof(dev->name)); break; case CVMX_HELPER_INTERFACE_MODE_LOOP: dev->netdev_ops = &cvm_oct_npi_netdev_ops; - strcpy(dev->name, "loop%d"); + strscpy(dev->name, "loop%d", sizeof(dev->name)); break; case CVMX_HELPER_INTERFACE_MODE_SGMII: priv->phy_mode = PHY_INTERFACE_MODE_SGMII; dev->netdev_ops = &cvm_oct_sgmii_netdev_ops; - strcpy(dev->name, "eth%d"); + strscpy(dev->name, "eth%d", sizeof(dev->name)); break; case CVMX_HELPER_INTERFACE_MODE_SPI: dev->netdev_ops = &cvm_oct_spi_netdev_ops; - strcpy(dev->name, "spi%d"); + strscpy(dev->name, "spi%d", sizeof(dev->name)); break; case CVMX_HELPER_INTERFACE_MODE_GMII: priv->phy_mode = PHY_INTERFACE_MODE_GMII; dev->netdev_ops = &cvm_oct_rgmii_netdev_ops; - strcpy(dev->name, "eth%d"); + strscpy(dev->name, "eth%d", sizeof(dev->name)); break; case CVMX_HELPER_INTERFACE_MODE_RGMII: dev->netdev_ops = &cvm_oct_rgmii_netdev_ops; - strcpy(dev->name, "eth%d"); + strscpy(dev->name, "eth%d", sizeof(dev->name)); cvm_set_rgmii_delay(priv, interface, port_index); break; -- 2.23.0
Re: [PATCH 00/10] Hwpoison soft-offline rework
I found another panic ... This testcase is testing the corner case where hugepage migration fails by allocation failure on destination numa node which is caused by the condition that all remaining free hugetlb are reserved. [ 2610.711713] ===> testcase 'page_migration/hugetlb_madv_soft_reserve_noovercommit.auto2' start [ 2610.995836] bash (15807): drop_caches: 3 [ 2612.596154] Soft offlining pfn 0x1d000 at process virtual address 0x7000 [ 2612.910245] bash (15807): drop_caches: 3 [ 2613.099769] page:f4ba4074 refcount:1 mapcount:-128 mapping: index:0x0 [ 2613.102099] flags: 0xfffe00080(hwpoison) [ 2613.103424] raw: 000fffe00080 9c953ffd5af8 f4ba40e78008 [ 2613.105817] raw: 0009 0001ff7f [ 2613.107703] page dumped because: VM_BUG_ON_PAGE(page_count(buddy) != 0) [ 2613.109485] [ cut here ] [ 2613.110834] kernel BUG at mm/page_alloc.c:821! [ 2613.112015] invalid opcode: [#1] SMP PTI [ 2613.113245] CPU: 0 PID: 16195 Comm: sysctl Not tainted 5.3.0-rc8-v5.3-rc8-190911-1025-00010-ga436dbce8674+ #18 [ 2613.115982] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 [ 2613.118495] RIP: 0010:free_one_page+0x5f1/0x610 [ 2613.119803] Code: 09 7e 81 49 8d b4 17 c0 00 00 00 8b 14 24 48 89 ef e8 83 75 00 00 e9 16 fe ff ff 48 c7 c6 c0 2b 0d 82 4c 89 e7 e8 9f c3 fd ff <0f> 0b 48 c7 c6 c0 2b 0d 82 e8 91 c3 fd ff 0f 0b 66 66 2e 0f 1f 84 [ 2613.124751] RSP: 0018:ac7442727ca8 EFLAGS: 00010046 [ 2613.126224] RAX: 003b RBX: 0009 RCX: 0006 [ 2613.128261] RDX: RSI: RDI: 820d1814 [ 2613.130299] RBP: f4ba40748000 R08: 0710 R09: 004a [ 2613.132082] R10: R11: ac7442727b20 R12: f4ba4074 [ 2613.133821] R13: 0001d200 R14: R15: 9c953ffd5680 [ 2613.135769] FS: 7fbf2e6cb900() GS:9c953da0() knlGS: [ 2613.138077] CS: 0010 DS: ES: CR0: 80050033 [ 2613.139721] CR2: 55eef99d4d38 CR3: 7cb5 CR4: 001406f0 [ 2613.141747] Call Trace: [ 2613.142472] __free_pages_ok+0x175/0x4e0 [ 2613.143454] free_pool_huge_page+0xec/0x100 [ 2613.144500] __nr_hugepages_store_common+0x173/0x2e0 [ 2613.145968] ? __do_proc_doulongvec_minmax+0x3ae/0x440 [ 2613.147444] hugetlb_sysctl_handler_common+0xad/0xc0 [ 2613.148867] proc_sys_call_handler+0x1a5/0x1c0 [ 2613.150104] vfs_write+0xa5/0x1a0 [ 2613.151081] ksys_write+0x59/0xd0 [ 2613.152052] do_syscall_64+0x5f/0x1a0 [ 2613.153071] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2613.154327] RIP: 0033:0x7fbf2eb01ed8 On Wed, Sep 11, 2019 at 05:29:56AM +, Horiguchi Naoya(堀口 直也) wrote: > Hi Oscar, > > Thank you for your working on this. > > My testing shows the following error: > > [ 1926.932435] ===> testcase 'mce_ksm_soft-offline_avoid_access.auto2' start > [ 1927.155321] bash (15853): drop_caches: 3 > [ 1929.019094] page:e5c384c4cd40 refcount:1 mapcount:0 > mapping:0003 index:0x70001 > [ 1929.021586] anon > [ 1929.021588] flags: > 0x57ffe00088000e(referenced|uptodate|dirty|swapbacked|hwpoison) > [ 1929.024289] raw: 0057ffe00088000e dead0100 dead0122 > 0003 > [ 1929.026611] raw: 00070001 > > [ 1929.028760] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)) > [ 1929.030559] [ cut here ] > [ 1929.031684] kernel BUG at mm/internal.h:73! > [ 1929.032738] invalid opcode: [#1] SMP PTI > [ 1929.033941] CPU: 3 PID: 16052 Comm: mceinj.sh Not tainted > 5.3.0-rc8-v5.3-rc8-190911-1025-00010-ga436dbce8674+ #18 > [ 1929.037137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.12.0-2.fc30 04/01/2014 > [ 1929.040066] RIP: 0010:page_set_poison+0xf9/0x160 > [ 1929.041665] Code: 63 02 7f 31 c0 5b 5d 41 5c c3 48 c7 c6 d0 d1 0c b0 48 > 89 df e8 88 bb f8 ff 0f 0b 48 c7 c6 f0 2a 0d b0 48 89 df e8 77 bb f8 ff <0f> > 0b 48 8b 45 00 48 c1 e8 33 83 e0 07 83 f8 04 75 89 48 8b 45 08 > [ 1929.047773] RSP: 0018:b4fb8a73bde0 EFLAGS: 00010246 > [ 1929.049511] RAX: 0039 RBX: e5c384c4cd40 RCX: > > [ 1929.051870] RDX: RSI: RDI: > b00d1814 > [ 1929.054238] RBP: e5c384c4cd40 R08: 0596 R09: > 0048 > [ 1929.056599] R10: R11: b4fb8a73bc58 R12: > > [ 1929.058986] R13: b4fb8a73be10 R14: 00131335 R15: > 0001 > [ 1929.061366] FS: 7fc9e208d740() GS:9fa9bdb0() > knlGS: > [ 1929.063842] CS: 0010 DS: ES: CR0: 800500
Re: [PATCH] driver core: ensure a device has valid node id in device_add()
On 2019/9/11 13:33, Michal Hocko wrote:
> On Tue 10-09-19 14:53:39, Michal Hocko wrote:
>> On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
>>> On 2019/9/10 19:12, Greg KH wrote:
On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
>> On 2019/9/10 17:31, Greg KH wrote:
>>> On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
On 2019/9/9 17:53, Greg KH wrote:
> On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
>> Currently a device does not belong to any of the numa nodes
>> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
>> specified by fw nor by virtual device layer and the device has
>> no parent device.
>
> Is this really a problem?
Not really.
Someone need to guess the node id when it is not specified, right?
>>>
>>> No, why? Guessing guarantees you will get it wrong on some systems.
>>>
>>> Are you seeing real problems because the id is not being set? What
>>> problem is this fixing that you can actually observe?
>>
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking the node id if the node id is not valid, there is
>> global-out-of-bounds detected by KASAN as below:
>
> OK, I seem to remember this being brought up already. And now when I
> think about it, we really want to make cpumask_of_node NUMA_NO_NODE
> aware. That means using the same trick the allocator does for this
> special case.
That seems reasonable to me, and much more "obvious" as to what is going
on.
>>>
>>> Ok, thanks for the suggestion.
>>>
>>> For arm64 and x86, there are two versions of cpumask_of_node().
>>>
>>> when CONFIG_DEBUG_PER_CPU_MAPS is defined, the cpumask_of_node()
>>>in arch/x86/mm/numa.c is used, which does partial node id checking:
>>>
>>> const struct cpumask *cpumask_of_node(int node)
>>> {
>>> if (node >= nr_node_ids) {
>>> printk(KERN_WARNING
>>> "cpumask_of_node(%d): node > nr_node_ids(%u)\n",
>>> node, nr_node_ids);
>>> dump_stack();
>>> return cpu_none_mask;
>>> }
>>> if (node_to_cpumask_map[node] == NULL) {
>>> printk(KERN_WARNING
>>> "cpumask_of_node(%d): no node_to_cpumask_map!\n",
>>> node);
>>> dump_stack();
>>> return cpu_online_mask;
>>> }
>>> return node_to_cpumask_map[node];
>>> }
>>>
>>> when CONFIG_DEBUG_PER_CPU_MAPS is undefined, the cpumask_of_node()
>>>in arch/x86/include/asm/topology.h is used:
>>>
>>> static inline const struct cpumask *cpumask_of_node(int node)
>>> {
>>> return node_to_cpumask_map[node];
>>> }
>>
>> I would simply go with. There shouldn't be any need for heavy weight
>> checks that CONFIG_DEBUG_PER_CPU_MAPS has.
>>
>> static inline const struct cpumask *cpumask_of_node(int node)
>> {
>> /* A nice comment goes here */
>> if (node == NUMA_NO_NODE)
How about "(unsigned int)node >= nr_node_ids", this is suggested
by Peter, it checks the case where the node id set by fw is bigger
or equal than nr_node_ids, and still handle the < 0 case, which
includes NUMA_NO_NODE.
Maybe define a macro like below to do that in order to do
the node checking consistently through kernel:
#define numa_node_valid(node) ((unsigned int)(node) < nr_node_ids)
>> return node_to_cpumask_map[numa_mem_id()];
>> return node_to_cpumask_map[node];
>> }
>
> Sleeping over this and thinking more about the actual semantic the above
> is wrong. We cannot really copy the page allocator logic. Why? Simply
> because the page allocator doesn't enforce the near node affinity. It
> just picks it up as a preferred node but then it is free to fallback to
> any other numa node. This is not the case here and node_to_cpumask_map will
> only restrict to the particular node's cpus which would have really non
> deterministic behavior depending on where the code is executed. So in
> fact we really want to return cpu_online_mask for NUMA_NO_NODE.
>From below, if the __GFP_THISNODE is set, the fallback is not performed.
For node_to_cpumask_map() case, maybe we can return the cpumask that is
on the node of cpu_to_node(raw_smp_processor_id()) for NUMA_NO_NODE,
because the current cpu does belong to a node, and the node does have at
least one cpu, which is the cpu is calling the node_to_cpumask_map().
Make any sense?
/*
* Allocate pages, preferring the node given as nid. The node must be valid and
* online. For more general interface, see alloc_pages_node().
*/
static inline struct page *
__alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
{
VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
VM_WARN_ON((gfp_mask & __GFP_THI
[PATCH v4 1/2] PTP: introduce new versions of IOCTLs
The current version of the IOCTL have a small problem which prevents us
from extending the API by making use of reserved fields. In these new
IOCTLs, we are now making sure that flags and rsv fields are zero which
will allow us to extend the API in the future.
Reviewed-by: Richard Cochran
Signed-off-by: Felipe Balbi
---
Changes since v3:
- Remove bogus bitwise negation
Changes since v2:
- Define PTP_{PEROUT,EXTTS}_VALID_FLAGS
- Fix comment above PTP_*_FLAGS
Changes since v1:
- Add a blank line after memset()
- Move memset(req) to the three places where it's needed
- Fix the accidental removal of GETFUNC and SETFUNC
drivers/ptp/ptp_chardev.c | 63 ++
include/uapi/linux/ptp_clock.h | 24 -
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 18ffe449efdf..9c18476d8d10 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -126,7 +126,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
switch (cmd) {
case PTP_CLOCK_GETCAPS:
+ case PTP_CLOCK_GETCAPS2:
memset(&caps, 0, sizeof(caps));
+
caps.max_adj = ptp->info->max_adj;
caps.n_alarm = ptp->info->n_alarm;
caps.n_ext_ts = ptp->info->n_ext_ts;
@@ -139,11 +141,24 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_EXTTS_REQUEST:
+ case PTP_EXTTS_REQUEST2:
+ memset(&req, 0, sizeof(req));
+
if (copy_from_user(&req.extts, (void __user *)arg,
sizeof(req.extts))) {
err = -EFAULT;
break;
}
+ if (((req.extts.flags & ~PTP_EXTTS_VALID_FLAGS) ||
+ req.extts.rsv[0] || req.extts.rsv[1]) &&
+ cmd == PTP_EXTTS_REQUEST2) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_EXTTS_REQUEST) {
+ req.extts.flags &= ~PTP_EXTTS_VALID_FLAGS;
+ req.extts.rsv[0] = 0;
+ req.extts.rsv[1] = 0;
+ }
if (req.extts.index >= ops->n_ext_ts) {
err = -EINVAL;
break;
@@ -154,11 +169,27 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_PEROUT_REQUEST:
+ case PTP_PEROUT_REQUEST2:
+ memset(&req, 0, sizeof(req));
+
if (copy_from_user(&req.perout, (void __user *)arg,
sizeof(req.perout))) {
err = -EFAULT;
break;
}
+ if (((req.perout.flags & ~PTP_PEROUT_VALID_FLAGS) ||
+ req.perout.rsv[0] || req.perout.rsv[1] ||
+ req.perout.rsv[2] || req.perout.rsv[3]) &&
+ cmd == PTP_PEROUT_REQUEST2) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PEROUT_REQUEST) {
+ req.perout.flags &= ~PTP_PEROUT_VALID_FLAGS;
+ req.perout.rsv[0] = 0;
+ req.perout.rsv[1] = 0;
+ req.perout.rsv[2] = 0;
+ req.perout.rsv[3] = 0;
+ }
if (req.perout.index >= ops->n_per_out) {
err = -EINVAL;
break;
@@ -169,6 +200,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_ENABLE_PPS:
+ case PTP_ENABLE_PPS2:
+ memset(&req, 0, sizeof(req));
+
if (!capable(CAP_SYS_TIME))
return -EPERM;
req.type = PTP_CLK_REQ_PPS;
@@ -177,6 +211,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_SYS_OFFSET_PRECISE:
+ case PTP_SYS_OFFSET_PRECISE2:
if (!ptp->info->getcrosststamp) {
err = -EOPNOTSUPP;
break;
@@ -201,6 +236,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_SYS_OFFSET_EXTENDED:
+ case PTP_SYS_OFFSET_EXTENDED2:
if (!ptp->info->gettimex64) {
err = -EOPNOTSUPP;
break;
@@ -232,6 +268,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_SYS_OFFSET:
+ case PTP_SYS_OFFSET2:
sysoff = memdup_user((void __user *)arg, sizeof(*sysoff));
if (IS_ERR(sysof
[PATCH v4 2/2] PTP: add support for one-shot output
Some controllers allow for a one-shot output pulse, in contrast to
periodic output. Now that we have extensible versions of our IOCTLs, we
can finally make use of the 'flags' field to pass a bit telling driver
that if we want one-shot pulse output.
Signed-off-by: Felipe Balbi
---
Changes since v3:
- Remove bogus bitwise negation
Changes since v2:
- Add _PEROUT_ to bit macro
Changes since v1:
- remove comment from .flags field
include/uapi/linux/ptp_clock.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
index 9a0af3511b68..f16301015949 100644
--- a/include/uapi/linux/ptp_clock.h
+++ b/include/uapi/linux/ptp_clock.h
@@ -38,8 +38,8 @@
/*
* Bits of the ptp_perout_request.flags field:
*/
-#define PTP_PEROUT_VALID_FLAGS (0)
-
+#define PTP_PEROUT_ONE_SHOT (1<<0)
+#define PTP_PEROUT_VALID_FLAGS (PTP_PEROUT_ONE_SHOT)
/*
* struct ptp_clock_time - represents a time value
*
@@ -77,7 +77,7 @@ struct ptp_perout_request {
struct ptp_clock_time start; /* Absolute start time. */
struct ptp_clock_time period; /* Desired period, zero means disable. */
unsigned int index; /* Which channel to configure. */
- unsigned int flags; /* Reserved for future use. */
+ unsigned int flags;
unsigned int rsv[4]; /* Reserved for future use. */
};
--
2.23.0
Re: [PATCH v3 1/2] PTP: introduce new versions of IOCTLs
Hi,
Richard Cochran writes:
> On Mon, Sep 09, 2019 at 10:59:39AM +0300, Felipe Balbi wrote:
>
>> case PTP_PEROUT_REQUEST:
>> +case PTP_PEROUT_REQUEST2:
>
> ...
>
>> +if (((req.perout.flags & ~PTP_PEROUT_VALID_FLAGS) ||
>> +req.perout.rsv[0] || req.perout.rsv[1] ||
>> +req.perout.rsv[2] || req.perout.rsv[3]) &&
>> +cmd == PTP_PEROUT_REQUEST2) {
>> +err = -EINVAL;
>> +break;
>
> ...
>
>> +/*
>> + * Bits of the ptp_perout_request.flags field:
>> + */
>> +#define PTP_PEROUT_VALID_FLAGS (~0)
>
> I think you meant (0) here, or I am confused...
Argh. What a brain fart!
Sorry about that. I'll go fix that ASAP.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 4/8] x86/platform/uv: Setup UV functions for Hubless UV Systems
* Mike Travis wrote:
> +/* Initialize UV hubless systems */
> +static __init int uv_system_init_hubless(void)
> +{
> + int rc;
> +
> + /* Setup PCH NMI handler */
> + uv_nmi_setup_hubless();
> +
> + /* Init kernel/BIOS interface */
> + rc = uv_bios_init();
> +
> + return rc;
> +}
Am I the only one who immediately sees the trivial C transformation
through which this function could lose a local variable and become 4
lines shorter?
And this function got two Reviewed-by tags...
Thanks,
Ingo
Re: [PATCH] ARM: dts: vf610-zii-scu4-aib: Drop "rs485-rts-delay" property
On Mon, Aug 19, 2019 at 08:13:01PM -0700, Andrey Smirnov wrote: > LPUART driver does not support specifying "rs485-rts-delay" > property. Drop it. > > Signed-off-by: Andrey Smirnov > Cc: Shawn Guo > Cc: Chris Healy > Cc: Fabio Estevam > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org Applied, thanks.
Re: [PATCH V2 5/8] x86/platform/uv: Add UV Hubbed/Hubless Proc FS Files
* Mike Travis wrote:
> @@ -1596,7 +1687,7 @@ static void __init uv_system_init_hub(vo
> uv_nmi_setup();
> uv_cpu_init();
> uv_scir_register_cpu_notifier();
> - proc_mkdir("sgi_uv", NULL);
> + uv_setup_proc_files(0);
This slipped through previously: platform drivers have absolutely no
business mucking in /proc.
Please describe the hardware via sysfs as pretty much everyone else does.
Thanks,
Ingo
Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller : > > Hi Adam, > >> Am 11.09.2019 um 02:41 schrieb Adam Ford : > > > The error message looks as if we have to enable multi_regulator. > That will enable both vdd and vbb regulators from what I can tell in the driver. > And that may need to rename cpu0-supply to vdd-supply (unless the > names can be configured). That is consistent with what I found. vdd-supply = <&vcc>; and vbb-supply = <&abb_mpu_iva>; I put them both under the cpu node. Unfortunately, when I did that, my board crashed. I am thinking it has something to do with the abb_mpu_iva driver because until this point, we've always operated at 800MHz or lower which all have the same behavior in abb_mpu_iva. With the patch you posted for the regulator, without the update to cpufreq, and with debugging enabled, I received the following in dmesg: [1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing 'efuse-address' IO resource [1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0 ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 [1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=120 ABB=0 ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 [1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0 ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 [1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1 ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 [1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings: Clk_rate=1300, sr2_cnt=0x0032 >>> >>> Using an unmodified kernel, I changed the device tree to make the abb >>> regulator power the cpu instead of vcc. After doing so, I was able to >>> read the microvolt value, and it matched the processor's desired OPP >>> voltage, and the debug code showed the abb regulator was attempting to >>> set the various index based on the needed voltage. I think the abb >>> driver is working correctly. >>> >>> I think tomorrow, I will re-apply the patches and tweak it again to >>> support both vdd and vbb regulators. If it crashes again, I'll look >>> more closely at the logs to see if I can determine why. I think it's >>> pretty close. I also need to go back and find the SmartReflex stuff >>> as well. >>> >> Well, I couldn't give it up for the night, so I thought I'd show my data dump >> >> [9.807647] [ cut here ] >> [9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630 >> dev_pm_opp_set_rate+0x3cc/0x480 >> [9.821044] Modules linked in: sha256_generic sha256_arm cfg80211 >> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class >> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v >> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common >> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery >> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph >> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt >> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+) >> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+) >> twl4030_pwrbutton sn >> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio >> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004 >> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm >> drm_panel_or >> ientation_quirks cec >> [9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted >> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5 >> [9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree) >> [9.909515] Workqueue: events dbs_work_handler >> [9.914031] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [9.921813] [] (show_stack) from [] >> (dump_stack+0xb4/0xd4) >> [9.929107] [] (dump_stack) from [] >> (__warn.part.3+0xa8/0xd4) >> [9.936614] [] (__warn.part.3) from [] >> (warn_slowpath_null+0x40/0x4c) >> [9.944854] [] (warn_slowpath_null) from [] >> (dev_pm_opp_set_rate+0x3cc/0x480) >> [9.953796] [] (dev_pm_opp_set_rate) from [] >> (set_target+0x30/0x58 [cpufreq_dt]) >> [9.963012] [] (set_target [cpufreq_dt]) from >> [] (__cpufreq_driver_target+0x188/0x514) >> [9.972717] [] (__cpufreq_driver_target) from >> [] (od_dbs_update+0x130/0x15c) >> [9.981567] [] (od_dbs_update) from [] >> (dbs_work_handler+0x28/0x58) >> [9.989624] [] (dbs_work_handler) from [] >> (process_one_work+0x20c/0x500) >> [9.998107] [] (process_one_work) from [] >> (worker_thread+0x2c/0x5bc) >> [ 10.006256] [] (worker_thread) from [] >> (kthread+0x134/0x148) >> [ 10.013702] [] (kthread) from [] >> (ret_from_fork+0x14/0x2c) >> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8) >> [ 10.026062] bfa0: >> >> [ 10.034271] bfc0: >> 00
[PATCH] bus: moxtet: Update proper type 'size_t' to 'ssize_t'
The simple_write_to_buffer() returns ssize_t type value, which is either positive or negative. However 'res' is declared as size_t(unsigned int) which contains non-negative type. So 'res < 0' statement is always false, this cannot execute execptional-case handling. To prevent this case, update proper type 'size_t' to 'ssize_t' for execptional handling. Signed-off-by: Austin Kim --- drivers/bus/moxtet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/moxtet.c b/drivers/bus/moxtet.c index 1ee4570..288a9e4 100644 --- a/drivers/bus/moxtet.c +++ b/drivers/bus/moxtet.c @@ -514,7 +514,7 @@ static ssize_t output_write(struct file *file, const char __user *buf, struct moxtet *moxtet = file->private_data; u8 bin[TURRIS_MOX_MAX_MODULES]; u8 hex[sizeof(bin) * 2 + 1]; - size_t res; + ssize_t res; loff_t dummy = 0; int err, i; -- 2.6.2
Re: [PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent memory
* Thomas Hellström (VMware) wrote: > With SEV and sometimes with SME encryption, The dma api coherent memory is > typically unencrypted, meaning the linear kernel map has the encryption > bit cleared. However, default page protection returned from vm_get_page_prot() > has the encryption bit set. So to compute the correct page protection we need > to clear the encryption bit. > > Also, in order for the encryption bit setting to survive across do_mmap() and > mprotect_fixup(), We need to make pgprot_modify() aware of it and not touch > it. > Therefore make sme_me_mask part of _PAGE_CHG_MASK and make sure > pgprot_modify() preserves also cleared bits that are part of _PAGE_CHG_MASK, > not just set bits. The use of pgprot_modify() is currently quite limited and > easy to audit. > > (Note that the encryption status is not logically encoded in the pfn but in > the page protection even if an address line in the physical address is used). > > The patchset has seen some sanity testing by exporting dma_pgprot() and > using it in the vmwgfx mmap handler with SEV enabled. > > Changes since: > RFC: > - Make sme_me_mask port of _PAGE_CHG_MASK rather than using it by its own in > pgprot_modify(). Could you please add a "why is this patch-set needed", not just describe the "what does this patch set do"? I've seen zero discussion in the three changelogs of exactly why we'd want this, which drivers and features are affected and in what way, etc. It's called a "fix" but doesn't explain what bad behavior it fixes. Thanks, Ingo
[PATCH] Staging: exfat: Avoid use of strcpy
Replaced strcpy with strscpy in exfat_core.c. Signed-off-by: Sandro Volery --- drivers/staging/exfat/exfat_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/exfat/exfat_core.c b/drivers/staging/exfat/exfat_core.c index da8c58149c35..c71b145e8a24 100644 --- a/drivers/staging/exfat/exfat_core.c +++ b/drivers/staging/exfat/exfat_core.c @@ -2964,7 +2964,7 @@ s32 resolve_path(struct inode *inode, char *path, struct chain_t *p_dir, if (strlen(path) >= (MAX_NAME_LENGTH * MAX_CHARSET_SIZE)) return FFS_INVALIDPATH; - strcpy(name_buf, path); + strscpy(name_buf, path, sizeof(name_buf)); nls_cstring_to_uniname(sb, p_uniname, name_buf, &lossy); if (lossy) -- 2.23.0
RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
Hi Andre,
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, 28 Aug 2019 03:03:02 +
> Peng Fan wrote:
>
> Hi,
>
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Cce8d04bcbdea4de6a77a08d7353c4e35%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637036405476727893&sdata=y5%2FI%2B
> w%2FPOypEh
> > zh6gWdXAGMGnl677B7gDZsX%2F5zfAQw%3D&reserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > ab4eb750bbdd..7707ee26251a 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -16,6 +16,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..76a2ae11ee4d
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
> > +
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 chan_id;
> > + u32 flags;
> > +};
> > +
> > +struct arm_smccc_mbox_cmd {
> > + unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
>
> I think this is one or even two registers too long?
> The SMCCC speaks of the function ID in x0/r0 and six arguments, with a
> "client ID" being an optional seventh argument. Looking at the description
> there I believe we cannot use the client ID here for this purpose, as this is
> supposed to be set by a hypervisor before passing on an SMC to EL3 firmware.
> KVM does not allow passing on SMCs in this way.
I'll drop a7.
>
> Also, while using "long" in here seems to make sense from the mailbox and
> SMC point of view, aliasing this to the mailbox client provided data seems
> dangerous to me, as this exposes the difference between arm32 and arm64
> to the client. I think this is not what we want, the client should not be
> architecture specific.
I see.
>
> > +};
> > +
> > +typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long, unsigned long); static
> > smc_mbox_fn
> > +*invoke_smc_mbox_fn;
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + unsigned long ret;
> > + u32 function_id;
> > + u32 chan_id;
> > +
> > + if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cm
Re: [PATCH] gpiolib: don't clear FLAG_IS_OUT when emulating open-drain/open-source
wt., 10 wrz 2019 o 12:48 Sasha Levin napisał(a):
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: c663e5f56737 gpio: support native single-ended hardware
> drivers.
>
> The bot has tested the following trees: v5.2.13, v4.19.71, v4.14.142,
> v4.9.191.
>
> v5.2.13: Build OK!
> v4.19.71: Build OK!
> v4.14.142: Failed to apply! Possible dependencies:
> 02e479808b5d ("gpio: Alter semantics of *raw* operations to actually be
> raw")
> fac9d8850a0c ("gpio: Get rid of _prefix and __prefixes")
>
> v4.9.191: Failed to apply! Possible dependencies:
> 02e479808b5d ("gpio: Alter semantics of *raw* operations to actually be
> raw")
> 0db0f26c2c5d ("pinctrl-sx150x: Convert driver to use regmap API")
> 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO
> chips")
> 46a5c112a401 ("gpio: merrifield: Implement gpio_get_direction callback")
> 6489677f86c3 ("pinctrl-sx150x: Replace sx150x_*_cfg by means of regmap
> API")
> 6697546d650d ("pinctrl-sx150x: Add SX1503 specific data")
> 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
> e3ba81206811 ("pinctrl-sx150x: Improve OF device matching code")
> e7a718f9b1c1 ("gpio: merrifield: Add support for hardware debouncer")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
Once it's accepted, I'll prepare backports.
Bart
Re: [PATCH V8 5/5] mmc: host: sdhci-pci: Add Genesys Logic GL975x support
On Wed, Sep 11, 2019 at 12:42 PM Guenter Roeck wrote:
>
> On Fri, Sep 06, 2019 at 10:33:26AM +0800, Ben Chuang wrote:
> > From: Ben Chuang
> >
> > Add support for the GL9750 and GL9755 chipsets.
> >
> > Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/
> > GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor
> > tuning flow for GL9750.
> >
> > Co-developed-by: Michael K Johnson
> > Signed-off-by: Michael K Johnson
> > Signed-off-by: Ben Chuang
> > ---
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/Makefile | 2 +-
> > drivers/mmc/host/sdhci-pci-core.c | 2 +
> > drivers/mmc/host/sdhci-pci-gli.c | 355 ++
> > drivers/mmc/host/sdhci-pci.h | 5 +
> > 5 files changed, 364 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/mmc/host/sdhci-pci-gli.c
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 931770f17087..9fbfff514d6c 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -94,6 +94,7 @@ config MMC_SDHCI_PCI
> > depends on MMC_SDHCI && PCI
> > select MMC_CQHCI
> > select IOSF_MBI if X86
> > + select MMC_SDHCI_IO_ACCESSORS
> > help
> > This selects the PCI Secure Digital Host Controller Interface.
> > Most controllers found today are PCI devices.
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 73578718f119..661445415090 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -13,7 +13,7 @@ obj-$(CONFIG_MMC_MXS) += mxs-mmc.o
> > obj-$(CONFIG_MMC_SDHCI) += sdhci.o
> > obj-$(CONFIG_MMC_SDHCI_PCI) += sdhci-pci.o
> > sdhci-pci-y += sdhci-pci-core.o sdhci-pci-o2micro.o
> > sdhci-pci-arasan.o \
> > -sdhci-pci-dwc-mshc.o
> > +sdhci-pci-dwc-mshc.o sdhci-pci-gli.o
> > obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI)) += sdhci-pci-data.o
> > obj-$(CONFIG_MMC_SDHCI_ACPI) += sdhci-acpi.o
> > obj-$(CONFIG_MMC_SDHCI_PXAV3)+= sdhci-pxav3.o
> > diff --git a/drivers/mmc/host/sdhci-pci-core.c
> > b/drivers/mmc/host/sdhci-pci-core.c
> > index 4154ee11b47d..e5835fbf73bc 100644
> > --- a/drivers/mmc/host/sdhci-pci-core.c
> > +++ b/drivers/mmc/host/sdhci-pci-core.c
> > @@ -1682,6 +1682,8 @@ static const struct pci_device_id pci_ids[] = {
> > SDHCI_PCI_DEVICE(O2, SEABIRD1, o2),
> > SDHCI_PCI_DEVICE(ARASAN, PHY_EMMC, arasan),
> > SDHCI_PCI_DEVICE(SYNOPSYS, DWC_MSHC, snps),
> > + SDHCI_PCI_DEVICE(GLI, 9750, gl9750),
> > + SDHCI_PCI_DEVICE(GLI, 9755, gl9755),
> > SDHCI_PCI_DEVICE_CLASS(AMD, SYSTEM_SDHCI, PCI_CLASS_MASK, amd),
> > /* Generic SD host controller */
> > {PCI_DEVICE_CLASS(SYSTEM_SDHCI, PCI_CLASS_MASK)},
> > diff --git a/drivers/mmc/host/sdhci-pci-gli.c
> > b/drivers/mmc/host/sdhci-pci-gli.c
> > new file mode 100644
> > index ..94462b94abec
> > --- /dev/null
> > +++ b/drivers/mmc/host/sdhci-pci-gli.c
> > @@ -0,0 +1,355 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2019 Genesys Logic, Inc.
> > + *
> > + * Authors: Ben Chuang
> > + *
> > + * Version: v0.9.0 (2019-08-08)
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "sdhci.h"
> > +#include "sdhci-pci.h"
> > +
> > +/* Genesys Logic extra registers */
> > +#define SDHCI_GLI_9750_WT 0x800
> > +#define SDHCI_GLI_9750_WT_EN BIT(0)
> > +#define GLI_9750_WT_EN_ON 0x1
> > +#define GLI_9750_WT_EN_OFF 0x0
> > +
> > +#define SDHCI_GLI_9750_DRIVING 0x860
> > +#define SDHCI_GLI_9750_DRIVING_1GENMASK(11, 0)
> > +#define SDHCI_GLI_9750_DRIVING_2GENMASK(27, 26)
> > +#define GLI_9750_DRIVING_1_VALUE0xFFF
> > +#define GLI_9750_DRIVING_2_VALUE0x3
> > +
> > +#define SDHCI_GLI_9750_PLL 0x864
> > +#define SDHCI_GLI_9750_PLL_TX2_INVBIT(23)
> > +#define SDHCI_GLI_9750_PLL_TX2_DLYGENMASK(22, 20)
> > +#define GLI_9750_PLL_TX2_INV_VALUE0x1
> > +#define GLI_9750_PLL_TX2_DLY_VALUE0x0
> > +
> > +#define SDHCI_GLI_9750_SW_CTRL 0x874
> > +#define SDHCI_GLI_9750_SW_CTRL_4GENMASK(7, 6)
> > +#define GLI_9750_SW_CTRL_4_VALUE0x3
> > +
> > +#define SDHCI_GLI_9750_MISC0x878
> > +#define SDHCI_GLI_9750_MISC_TX1_INVBIT(2)
> > +#define SDHCI_GLI_9750_MISC_RX_INV BIT(3)
> > +#define SDHCI_GLI_9750_MISC_TX1_DLYGENMASK(6, 4)
> > +#define GLI_9750_MISC_TX1_INV_VALUE0x0
> > +#define GLI_9750_MISC_RX_INV_ON0x1
> > +#define GLI_9750_MISC_RX_INV_OFF 0x0
> > +#define GLI_9750_MISC_RX_INV_VALUE GLI_9750_MISC_RX_INV_OFF
> > +#define GLI_9750_MISC_TX1_DLY_VALUE0x5
> > +
> > +#define SDHCI_GLI_9750_TUNING_CONTROL 0x540
> > +#define SDHCI_GLI_9750_TUNING_CONTROL_EN BIT(4)
> > +#define GL
Re: [PATCH] driver core: ensure a device has valid node id in device_add()
On Tue 10-09-19 14:53:39, Michal Hocko wrote:
> On Tue 10-09-19 20:47:40, Yunsheng Lin wrote:
> > On 2019/9/10 19:12, Greg KH wrote:
> > > On Tue, Sep 10, 2019 at 01:04:51PM +0200, Michal Hocko wrote:
> > >> On Tue 10-09-19 18:58:05, Yunsheng Lin wrote:
> > >>> On 2019/9/10 17:31, Greg KH wrote:
> > On Tue, Sep 10, 2019 at 02:43:32PM +0800, Yunsheng Lin wrote:
> > > On 2019/9/9 17:53, Greg KH wrote:
> > >> On Mon, Sep 09, 2019 at 02:04:23PM +0800, Yunsheng Lin wrote:
> > >>> Currently a device does not belong to any of the numa nodes
> > >>> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
> > >>> specified by fw nor by virtual device layer and the device has
> > >>> no parent device.
> > >>
> > >> Is this really a problem?
> > >
> > > Not really.
> > > Someone need to guess the node id when it is not specified, right?
> >
> > No, why? Guessing guarantees you will get it wrong on some systems.
> >
> > Are you seeing real problems because the id is not being set? What
> > problem is this fixing that you can actually observe?
> > >>>
> > >>> When passing the return value of dev_to_node() to cpumask_of_node()
> > >>> without checking the node id if the node id is not valid, there is
> > >>> global-out-of-bounds detected by KASAN as below:
> > >>
> > >> OK, I seem to remember this being brought up already. And now when I
> > >> think about it, we really want to make cpumask_of_node NUMA_NO_NODE
> > >> aware. That means using the same trick the allocator does for this
> > >> special case.
> > >
> > > That seems reasonable to me, and much more "obvious" as to what is going
> > > on.
> > >
> >
> > Ok, thanks for the suggestion.
> >
> > For arm64 and x86, there are two versions of cpumask_of_node().
> >
> > when CONFIG_DEBUG_PER_CPU_MAPS is defined, the cpumask_of_node()
> >in arch/x86/mm/numa.c is used, which does partial node id checking:
> >
> > const struct cpumask *cpumask_of_node(int node)
> > {
> > if (node >= nr_node_ids) {
> > printk(KERN_WARNING
> > "cpumask_of_node(%d): node > nr_node_ids(%u)\n",
> > node, nr_node_ids);
> > dump_stack();
> > return cpu_none_mask;
> > }
> > if (node_to_cpumask_map[node] == NULL) {
> > printk(KERN_WARNING
> > "cpumask_of_node(%d): no node_to_cpumask_map!\n",
> > node);
> > dump_stack();
> > return cpu_online_mask;
> > }
> > return node_to_cpumask_map[node];
> > }
> >
> > when CONFIG_DEBUG_PER_CPU_MAPS is undefined, the cpumask_of_node()
> >in arch/x86/include/asm/topology.h is used:
> >
> > static inline const struct cpumask *cpumask_of_node(int node)
> > {
> > return node_to_cpumask_map[node];
> > }
>
> I would simply go with. There shouldn't be any need for heavy weight
> checks that CONFIG_DEBUG_PER_CPU_MAPS has.
>
> static inline const struct cpumask *cpumask_of_node(int node)
> {
> /* A nice comment goes here */
> if (node == NUMA_NO_NODE)
> return node_to_cpumask_map[numa_mem_id()];
> return node_to_cpumask_map[node];
> }
Sleeping over this and thinking more about the actual semantic the above
is wrong. We cannot really copy the page allocator logic. Why? Simply
because the page allocator doesn't enforce the near node affinity. It
just picks it up as a preferred node but then it is free to fallback to
any other numa node. This is not the case here and node_to_cpumask_map will
only restrict to the particular node's cpus which would have really non
deterministic behavior depending on where the code is executed. So in
fact we really want to return cpu_online_mask for NUMA_NO_NODE.
Sorry about the confusion.
> --
> Michal Hocko
> SUSE Labs
--
Michal Hocko
SUSE Labs
Re: [PATCH 00/10] Hwpoison soft-offline rework
Hi Oscar, Thank you for your working on this. My testing shows the following error: [ 1926.932435] ===> testcase 'mce_ksm_soft-offline_avoid_access.auto2' start [ 1927.155321] bash (15853): drop_caches: 3 [ 1929.019094] page:e5c384c4cd40 refcount:1 mapcount:0 mapping:0003 index:0x70001 [ 1929.021586] anon [ 1929.021588] flags: 0x57ffe00088000e(referenced|uptodate|dirty|swapbacked|hwpoison) [ 1929.024289] raw: 0057ffe00088000e dead0100 dead0122 0003 [ 1929.026611] raw: 00070001 [ 1929.028760] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)) [ 1929.030559] [ cut here ] [ 1929.031684] kernel BUG at mm/internal.h:73! [ 1929.032738] invalid opcode: [#1] SMP PTI [ 1929.033941] CPU: 3 PID: 16052 Comm: mceinj.sh Not tainted 5.3.0-rc8-v5.3-rc8-190911-1025-00010-ga436dbce8674+ #18 [ 1929.037137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 [ 1929.040066] RIP: 0010:page_set_poison+0xf9/0x160 [ 1929.041665] Code: 63 02 7f 31 c0 5b 5d 41 5c c3 48 c7 c6 d0 d1 0c b0 48 89 df e8 88 bb f8 ff 0f 0b 48 c7 c6 f0 2a 0d b0 48 89 df e8 77 bb f8 ff <0f> 0b 48 8b 45 00 48 c1 e8 33 83 e0 07 83 f8 04 75 89 48 8b 45 08 [ 1929.047773] RSP: 0018:b4fb8a73bde0 EFLAGS: 00010246 [ 1929.049511] RAX: 0039 RBX: e5c384c4cd40 RCX: [ 1929.051870] RDX: RSI: RDI: b00d1814 [ 1929.054238] RBP: e5c384c4cd40 R08: 0596 R09: 0048 [ 1929.056599] R10: R11: b4fb8a73bc58 R12: [ 1929.058986] R13: b4fb8a73be10 R14: 00131335 R15: 0001 [ 1929.061366] FS: 7fc9e208d740() GS:9fa9bdb0() knlGS: [ 1929.063842] CS: 0010 DS: ES: CR0: 80050033 [ 1929.065429] CR2: 55946c05d192 CR3: 0001365f2000 CR4: 001406e0 [ 1929.067373] Call Trace: [ 1929.068094] soft_offline_page+0x2be/0x600 [ 1929.069246] soft_offline_page_store+0xdf/0x110 [ 1929.070510] kernfs_fop_write+0x116/0x190 [ 1929.071618] vfs_write+0xa5/0x1a0 [ 1929.072614] ksys_write+0x59/0xd0 [ 1929.073548] do_syscall_64+0x5f/0x1a0 [ 1929.074554] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1929.075957] RIP: 0033:0x7fc9e217ded8 It seems that soft-offlining on ksm pages is affected by this changeset. Could you try to handle this? - Naoya On Tue, Sep 10, 2019 at 12:30:06PM +0200, Oscar Salvador wrote: > > This patchset was based on Naoya's hwpoison rework [1], so thanks to him > for the initial work. > > This patchset aims to fix some issues laying in soft-offline handling, > but it also takes the chance and takes some further steps to perform > cleanups and some refactoring as well. > > - Motivation: > >A customer and I were facing an issue where poisoned pages we returned >back to user-space after having offlined them properly. >This was only seend under some memory stress + soft offlining pages. >After some anaylsis, it became clear that the problem was that >when kcompactd kicked in to migrate pages over, compaction_alloc >callback was handing poisoned pages to the migrate routine. >Once this page was later on fault in, __do_page_fault returned >VM_FAULT_HWPOISON making the process being killed. > >All this could happen because isolate_freepages_block and >fast_isolate_freepages just check for the page to be PageBuddy, >and since 1) poisoned pages can be part of a higher order page >and 2) poisoned pages are also Page Buddy, they can sneak in easily. > >I also saw some problem with swap pages, but I suspected to be the >same sort of problem, so I did not follow that trace. > >The full explanation can be see in [2]. > > - Approach: > >The taken approach is to not let poisoned pages hit neither >pcplists nor buddy freelists. >This is achieved by: > > In-use pages: > >* Normal pages > >1) do not release the last reference count after the > invalidation/migration of the page. >2) the page is being handed to page_set_poison, which does: > 2a) sets PageHWPoison flag > 2b) calls put_page (only to be able to call __page_cache_release) > Since poisoned pages are skipped in free_pages_prepare, > this put_page is safe. > 2c) Sets the refcount to 1 > >* Hugetlb pages > >1) Hand the page to page_set_poison after migration >2) page_set_poison does: > 2a) Calls dissolve_free_huge_page > 2b) If ranged to be dissolved contains poisoned pages, > we free the rangeas order-0 pages (as we do with gigantic hugetlb > page), > so free_pages_prepare will skip them accordingly. > 2c) Sets the refcount to 1 > > Free pages: > >* Normal pages: > >1) Take
Re: linux-next: Signed-off-by missing for commit in the net-next tree
On Wed, 2019-09-11 at 00:42 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> aa43ae121675 ("iwlwifi: LTR updates")
>
> is missing a Signed-off-by from its committer.
Oops, that was my fault. What can we do about it? Is it enough if I
give my s-o-b publicly here?
I hereby sign off this change:
Signed-off-by: Luca Coelho
--
Cheers,
Luca.
Re: [PATCH v2] Fix fTPM on AMD Zen+ CPUs
> > And why is this allocating memory inside the acpi table walker? It > > seems to me like the memory should be allocated once the mapping is > > made. > > > > Yes, this looks bad. Letting the walker build the list and then using > it is, probably, a better idea. > > > Maybe all the mappings should be created from the ACPI ranges right > > away? > > > > I don't know if it's a good idea to just map them all instead of doing > so only for relevant ones. Maybe it is safe, here I need an advice > from a more knowledgeable person. > Vanya, I also made a patch series to solve AMD's fTPM. My patch link is here, https://lkml.org/lkml/2019/9/9/132 . The maintainer, Jarkko, wanted me to remark on your patch, so I would like to cooperate with you. Your patch is good for me. If you are fine, I would like to take your patch and merge it with my patch series. I also would like to change some points Jason mentioned before. Of course, I will leave your commit message and sign-off-by note. According to the guideline below, I will just add co-developed-by and sign-off-by notes behind you. https://www.kernel.org/doc/html/v5.2/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by If you have any idea about our co-work, please let me know. I hope we can solve AMD's fTPM problem soon. Seunghun
[PATCH v1 1/1] pinctrl: iproc: Add 'get_direction' support
Add 'get_direction' support to the iProc GPIO driver.
Signed-off-by: Rayagonda Kokatanur
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index b70058c..d782d70 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -355,6 +355,15 @@ static int iproc_gpio_direction_output(struct gpio_chip
*gc, unsigned gpio,
return 0;
}
+static int iproc_gpio_get_direction(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct iproc_gpio *chip = gpiochip_get_data(gc);
+ unsigned int offset = IPROC_GPIO_REG(gpio, IPROC_GPIO_OUT_EN_OFFSET);
+ unsigned int shift = IPROC_GPIO_SHIFT(gpio);
+
+ return !(readl(chip->base + offset) & BIT(shift));
+}
+
static void iproc_gpio_set(struct gpio_chip *gc, unsigned gpio, int val)
{
struct iproc_gpio *chip = gpiochip_get_data(gc);
@@ -784,6 +793,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
gc->free = iproc_gpio_free;
gc->direction_input = iproc_gpio_direction_input;
gc->direction_output = iproc_gpio_direction_output;
+ gc->get_direction = iproc_gpio_get_direction;
gc->set = iproc_gpio_set;
gc->get = iproc_gpio_get;
--
1.9.1
Re: [PATCH v3 1/2] drm/virtio: Rewrite virtio_gpu_queue_ctrl_buffer using fenced version.
On Tue, Sep 10, 2019 at 01:06:50PM -0700, David Riley wrote: > Factor function in preparation to generating scatterlist prior to locking. Patches are looking good now, but they don't apply. What tree was used to create them? Latest virtio-gpu driver bits are in drm-misc-next (see https://cgit.freedesktop.org/drm/drm-misc). cheers, Gerd
Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
Hi Adam, > Am 11.09.2019 um 02:41 schrieb Adam Ford : The error message looks as if we have to enable multi_regulator. >>> >>> That will enable both vdd and vbb regulators from what I can tell in the >>> driver. >>> And that may need to rename cpu0-supply to vdd-supply (unless the names can be configured). >>> >>> That is consistent with what I found. vdd-supply = <&vcc>; and >>> vbb-supply = <&abb_mpu_iva>; >>> I put them both under the cpu node. Unfortunately, when I did that, >>> my board crashed. >>> >>> I am thinking it has something to do with the abb_mpu_iva driver >>> because until this point, we've always operated at 800MHz or lower >>> which all have the same behavior in abb_mpu_iva. >>> >>> With the patch you posted for the regulator, without the update to >>> cpufreq, and with debugging enabled, I received the following in >>> dmesg: >>> >>> [1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing >>> 'efuse-address' IO resource >>> [1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=120 ABB=0 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings: >>> Clk_rate=1300, sr2_cnt=0x0032 >>> >> >> Using an unmodified kernel, I changed the device tree to make the abb >> regulator power the cpu instead of vcc. After doing so, I was able to >> read the microvolt value, and it matched the processor's desired OPP >> voltage, and the debug code showed the abb regulator was attempting to >> set the various index based on the needed voltage. I think the abb >> driver is working correctly. >> >> I think tomorrow, I will re-apply the patches and tweak it again to >> support both vdd and vbb regulators. If it crashes again, I'll look >> more closely at the logs to see if I can determine why. I think it's >> pretty close. I also need to go back and find the SmartReflex stuff >> as well. >> > Well, I couldn't give it up for the night, so I thought I'd show my data dump > > [9.807647] [ cut here ] > [9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630 > dev_pm_opp_set_rate+0x3cc/0x480 > [9.821044] Modules linked in: sha256_generic sha256_arm cfg80211 > joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class > panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v > ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common > bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery > snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph > y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt > watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+) > snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+) > twl4030_pwrbutton sn > d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio > soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004 > tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm > drm_panel_or > ientation_quirks cec > [9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted > 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5 > [9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree) > [9.909515] Workqueue: events dbs_work_handler > [9.914031] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [9.921813] [] (show_stack) from [] > (dump_stack+0xb4/0xd4) > [9.929107] [] (dump_stack) from [] > (__warn.part.3+0xa8/0xd4) > [9.936614] [] (__warn.part.3) from [] > (warn_slowpath_null+0x40/0x4c) > [9.944854] [] (warn_slowpath_null) from [] > (dev_pm_opp_set_rate+0x3cc/0x480) > [9.953796] [] (dev_pm_opp_set_rate) from [] > (set_target+0x30/0x58 [cpufreq_dt]) > [9.963012] [] (set_target [cpufreq_dt]) from > [] (__cpufreq_driver_target+0x188/0x514) > [9.972717] [] (__cpufreq_driver_target) from > [] (od_dbs_update+0x130/0x15c) > [9.981567] [] (od_dbs_update) from [] > (dbs_work_handler+0x28/0x58) > [9.989624] [] (dbs_work_handler) from [] > (process_one_work+0x20c/0x500) > [9.998107] [] (process_one_work) from [] > (worker_thread+0x2c/0x5bc) > [ 10.006256] [] (worker_thread) from [] > (kthread+0x134/0x148) > [ 10.013702] [] (kthread) from [] > (ret_from_fork+0x14/0x2c) > [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8) > [ 10.026062] bfa0: > > [ 10.034271] bfc0: > > [ 10.042510] bfe0: 0013 > [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]--- > [ 10.053894] cpu c
[PATCH v4 09/14] software node: simplify property_entry_read_string_array()
There is no need to treat string arrays and single strings separately, we can go
exclusively by the element length in relation to data type size.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index a019b5e90d3b..9c3e566c753e 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -173,28 +173,21 @@ static int property_entry_read_string_array(const struct
property_entry *props,
const char *propname,
const char **strings, size_t nval)
{
- const struct property_entry *prop;
const void *pointer;
- size_t array_len, length;
+ size_t length;
+ int array_len;
/* Find out the array length. */
- prop = property_entry_get(props, propname);
- if (!prop)
- return -EINVAL;
-
- if (prop->is_array)
- /* Find the length of an array. */
- array_len = property_entry_count_elems_of_size(props, propname,
- sizeof(const char *));
- else
- /* The array length for a non-array string property is 1. */
- array_len = 1;
+ array_len = property_entry_count_elems_of_size(props, propname,
+ sizeof(const char *));
+ if (array_len < 0)
+ return array_len;
/* Return how many there are if strings is NULL. */
if (!strings)
return array_len;
- array_len = min(nval, array_len);
+ array_len = min_t(size_t, nval, array_len);
length = array_len * sizeof(*strings);
pointer = property_entry_find(props, propname, length);
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 07/14] software node: remove property_entry_read_uNN_array functions
There is absolutely no reason to have them as we can handle it all nicely in
property_entry_read_int_array().
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 85 +++
1 file changed, 14 insertions(+), 71 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 726195d334e4..a019b5e90d3b 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -131,66 +131,6 @@ static const void *property_entry_find(const struct
property_entry *props,
return pointer;
}
-static int property_entry_read_u8_array(const struct property_entry *props,
- const char *propname,
- u8 *values, size_t nval)
-{
- const void *pointer;
- size_t length = nval * sizeof(*values);
-
- pointer = property_entry_find(props, propname, length);
- if (IS_ERR(pointer))
- return PTR_ERR(pointer);
-
- memcpy(values, pointer, length);
- return 0;
-}
-
-static int property_entry_read_u16_array(const struct property_entry *props,
-const char *propname,
-u16 *values, size_t nval)
-{
- const void *pointer;
- size_t length = nval * sizeof(*values);
-
- pointer = property_entry_find(props, propname, length);
- if (IS_ERR(pointer))
- return PTR_ERR(pointer);
-
- memcpy(values, pointer, length);
- return 0;
-}
-
-static int property_entry_read_u32_array(const struct property_entry *props,
-const char *propname,
-u32 *values, size_t nval)
-{
- const void *pointer;
- size_t length = nval * sizeof(*values);
-
- pointer = property_entry_find(props, propname, length);
- if (IS_ERR(pointer))
- return PTR_ERR(pointer);
-
- memcpy(values, pointer, length);
- return 0;
-}
-
-static int property_entry_read_u64_array(const struct property_entry *props,
-const char *propname,
-u64 *values, size_t nval)
-{
- const void *pointer;
- size_t length = nval * sizeof(*values);
-
- pointer = property_entry_find(props, propname, length);
- if (IS_ERR(pointer))
- return PTR_ERR(pointer);
-
- memcpy(values, pointer, length);
- return 0;
-}
-
static int
property_entry_count_elems_of_size(const struct property_entry *props,
const char *propname, size_t length)
@@ -209,21 +149,24 @@ static int property_entry_read_int_array(const struct
property_entry *props,
unsigned int elem_size, void *val,
size_t nval)
{
+ const void *pointer;
+ size_t length;
+
if (!val)
return property_entry_count_elems_of_size(props, name,
elem_size);
- switch (elem_size) {
- case sizeof(u8):
- return property_entry_read_u8_array(props, name, val, nval);
- case sizeof(u16):
- return property_entry_read_u16_array(props, name, val, nval);
- case sizeof(u32):
- return property_entry_read_u32_array(props, name, val, nval);
- case sizeof(u64):
- return property_entry_read_u64_array(props, name, val, nval);
- }
- return -ENXIO;
+ if (!is_power_of_2(elem_size) || elem_size > sizeof(u64))
+ return -ENXIO;
+
+ length = nval * elem_size;
+
+ pointer = property_entry_find(props, name, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(val, pointer, length);
+ return 0;
}
static int property_entry_read_string_array(const struct property_entry *props,
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 04/14] software node: mark internal macros with double underscores
Let's mark PROPERTY_ENTRY_* macros that are internal with double leading
underscores so users are not tempted to use them.
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/property.h b/include/linux/property.h
index f89b930ca4b7..2c9d4d209296 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -256,7 +256,7 @@ struct property_entry {
* and structs.
*/
-#define PROPERTY_ENTRY_ARRAY_LEN(_name_, _type_, _Type_, _val_, _len_) \
+#define __PROPERTY_ENTRY_ARRAY_LEN(_name_, _type_, _Type_, _val_, _len_)\
(struct property_entry) { \
.name = _name_, \
.length = (_len_) * sizeof(_type_), \
@@ -266,13 +266,13 @@ struct property_entry {
}
#define PROPERTY_ENTRY_U8_ARRAY_LEN(_name_, _val_, _len_) \
- PROPERTY_ENTRY_ARRAY_LEN(_name_, u8, U8, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u8, U8, _val_, _len_)
#define PROPERTY_ENTRY_U16_ARRAY_LEN(_name_, _val_, _len_) \
- PROPERTY_ENTRY_ARRAY_LEN(_name_, u16, U16, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u16, U16, _val_, _len_)
#define PROPERTY_ENTRY_U32_ARRAY_LEN(_name_, _val_, _len_) \
- PROPERTY_ENTRY_ARRAY_LEN(_name_, u32, U32, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u32, U32, _val_, _len_)
#define PROPERTY_ENTRY_U64_ARRAY_LEN(_name_, _val_, _len_) \
- PROPERTY_ENTRY_ARRAY_LEN(_name_, u64, U64, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u64, U64, _val_, _len_)
#define PROPERTY_ENTRY_STRING_ARRAY_LEN(_name_, _val_, _len_) \
(struct property_entry) { \
@@ -294,7 +294,7 @@ struct property_entry {
#define PROPERTY_ENTRY_STRING_ARRAY(_name_, _val_) \
PROPERTY_ENTRY_STRING_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
-#define PROPERTY_ENTRY_INTEGER(_name_, _type_, _Type_, _val_) \
+#define __PROPERTY_ENTRY_INTEGER(_name_, _type_, _Type_, _val_)\
(struct property_entry) { \
.name = _name_, \
.length = sizeof(_type_), \
@@ -303,13 +303,13 @@ struct property_entry {
}
#define PROPERTY_ENTRY_U8(_name_, _val_) \
- PROPERTY_ENTRY_INTEGER(_name_, u8, U8, _val_)
+ __PROPERTY_ENTRY_INTEGER(_name_, u8, U8, _val_)
#define PROPERTY_ENTRY_U16(_name_, _val_) \
- PROPERTY_ENTRY_INTEGER(_name_, u16, U16, _val_)
+ __PROPERTY_ENTRY_INTEGER(_name_, u16, U16, _val_)
#define PROPERTY_ENTRY_U32(_name_, _val_) \
- PROPERTY_ENTRY_INTEGER(_name_, u32, U32, _val_)
+ __PROPERTY_ENTRY_INTEGER(_name_, u32, U32, _val_)
#define PROPERTY_ENTRY_U64(_name_, _val_) \
- PROPERTY_ENTRY_INTEGER(_name_, u64, U64, _val_)
+ __PROPERTY_ENTRY_INTEGER(_name_, u64, U64, _val_)
#define PROPERTY_ENTRY_STRING(_name_, _val_) \
(struct property_entry) { \
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 11/14] software node: move small properties inline when copying
When copying/duplicating set of properties, move smaller properties that
were stored separately directly inside property entry structures. We can
move:
- up to 8 bytes from U8 arrays
- up to 4 words
- up to 2 double words
- one U64 value
- one or 2 strings.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 83e2a706a86e..1aa6559993ec 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -277,6 +277,16 @@ static int property_entry_copy_data(struct property_entry
*dst,
dst->value = src->value;
}
+ if (!dst->is_inline && dst->length <= sizeof(dst->value)) {
+ /* We have an opportunity to move the data inline */
+ const void *tmp = dst->pointer;
+
+ memcpy(&dst->value, tmp, dst->length);
+ dst->is_inline = true;
+
+ kfree(tmp);
+ }
+
dst->length = src->length;
dst->type = src->type;
dst->name = kstrdup(src->name, GFP_KERNEL);
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 08/14] software node: unify PROPERTY_ENTRY_XXX macros
We can unify string properties initializer macros with integer
initializers.
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 64 +---
1 file changed, 27 insertions(+), 37 deletions(-)
diff --git a/include/linux/property.h b/include/linux/property.h
index ec8f84d564a8..238e1507925f 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -245,37 +245,33 @@ struct property_entry {
};
/*
- * Note: the below four initializers for the anonymous union are carefully
+ * Note: the below initializers for the anonymous union are carefully
* crafted to avoid gcc-4.4.4's problems with initialization of anon unions
* and structs.
*/
-#define __PROPERTY_ENTRY_ARRAY_LEN(_name_, _type_, _Type_, _val_, _len_)\
+#define __PROPERTY_ENTRY_ELEMENT_SIZE(_elem_) \
+ sizeof(((struct property_entry *)NULL)->value._elem_)
+
+#define __PROPERTY_ENTRY_ARRAY_LEN(_name_, _elem_, _Type_, _val_, _len_)\
(struct property_entry) { \
.name = _name_, \
- .length = (_len_) * sizeof(_type_), \
+ .length = (_len_) * __PROPERTY_ENTRY_ELEMENT_SIZE(_elem_), \
.is_array = true, \
.type = DEV_PROP_##_Type_, \
{ .pointer = _val_ }, \
}
#define PROPERTY_ENTRY_U8_ARRAY_LEN(_name_, _val_, _len_) \
- __PROPERTY_ENTRY_ARRAY_LEN(_name_, u8, U8, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u8_data, U8, _val_, _len_)
#define PROPERTY_ENTRY_U16_ARRAY_LEN(_name_, _val_, _len_) \
- __PROPERTY_ENTRY_ARRAY_LEN(_name_, u16, U16, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u16_data, U16, _val_, _len_)
#define PROPERTY_ENTRY_U32_ARRAY_LEN(_name_, _val_, _len_) \
- __PROPERTY_ENTRY_ARRAY_LEN(_name_, u32, U32, _val_, _len_)
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u32_data, U32, _val_, _len_)
#define PROPERTY_ENTRY_U64_ARRAY_LEN(_name_, _val_, _len_) \
- __PROPERTY_ENTRY_ARRAY_LEN(_name_, u64, U64, _val_, _len_)
-
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, u64_data, U64, _val_, _len_)
#define PROPERTY_ENTRY_STRING_ARRAY_LEN(_name_, _val_, _len_) \
-(struct property_entry) { \
- .name = _name_, \
- .length = (_len_) * sizeof(const char *), \
- .is_array = true, \
- .type = DEV_PROP_STRING,\
- { .pointer = _val_ }, \
-}
+ __PROPERTY_ENTRY_ARRAY_LEN(_name_, str, STRING, _val_, _len_)
#define PROPERTY_ENTRY_U8_ARRAY(_name_, _val_) \
PROPERTY_ENTRY_U8_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
@@ -288,30 +284,24 @@ struct property_entry {
#define PROPERTY_ENTRY_STRING_ARRAY(_name_, _val_) \
PROPERTY_ENTRY_STRING_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
-#define __PROPERTY_ENTRY_INTEGER(_name_, _type_, _Type_, _val_)\
-(struct property_entry) { \
- .name = _name_, \
- .length = sizeof(_type_), \
- .type = DEV_PROP_##_Type_, \
- { .value = { ._type_##_data = _val_ } },\
+#define __PROPERTY_ENTRY_ELEMENT(_name_, _elem_, _Type_, _val_)
\
+(struct property_entry) { \
+ .name = _name_, \
+ .length = __PROPERTY_ENTRY_ELEMENT_SIZE(_elem_),\
+ .type = DEV_PROP_##_Type_, \
+ { .value = { ._elem_ = _val_ } }, \
}
-#define PROPERTY_ENTRY_U8(_name_, _val_) \
- __PROPERTY_ENTRY_INTEGER(_name_, u8, U8, _val_)
-#define PROPERTY_ENTRY_U16(_name_, _val_) \
- __PROPERTY_ENTRY_INTEGER(_name_, u16, U16, _val_)
-#define PROPERTY_ENTRY_U32(_name_, _val_) \
- __PROPERTY_ENTRY_INTEGER(_name_, u32, U32, _val_)
-#define PROPERTY_ENTRY_U64(_name_, _val_) \
- __PROPERTY_ENTRY_INTEGER(_name_, u64, U64, _val_)
-
-#define PROPERTY_ENTRY_STRING(_name_, _val_) \
-(struct property_entry) { \
- .name = _name_, \
- .length = sizeof(const char *), \
- .type = DEV_PROP_STRING,\
- { .value = { .str = _val_ } }, \
-}
+#define PROPERTY_E
[PATCH v4 14/14] software node: remove separate handling of references
Now that all users of references have moved to reference properties,
we can remove separate handling of references.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c| 46 +++-
include/linux/property.h | 14
2 files changed, 17 insertions(+), 43 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 07e1325789d2..ef38ea9f730b 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -465,9 +465,8 @@ software_node_get_reference_args(const struct fwnode_handle
*fwnode,
struct fwnode_reference_args *args)
{
struct swnode *swnode = to_swnode(fwnode);
- const struct software_node_reference *ref;
const struct software_node_ref_args *ref_array;
- const struct software_node_ref_args *ref_args;
+ const struct software_node_ref_args *ref;
const struct property_entry *prop;
struct fwnode_handle *refnode;
int i;
@@ -476,37 +475,26 @@ software_node_get_reference_args(const struct
fwnode_handle *fwnode,
return -ENOENT;
prop = property_entry_get(swnode->node->properties, propname);
- if (prop) {
- if (prop->type != DEV_PROP_REF)
- return -EINVAL;
-
- /*
-* We expect that references are never stored inline, even
-* single ones, as they are too big.
-*/
- if (prop->is_inline)
- return -EINVAL;
-
- if (index * sizeof(*ref_args) >= prop->length)
- return -ENOENT;
+ if (!prop)
+ return -ENOENT;
- ref_array = prop->pointer;
- ref_args = &ref_array[index];
- } else {
- if (!swnode->node->references)
- return -ENOENT;
+ if (prop->type != DEV_PROP_REF)
+ return -EINVAL;
- for (ref = swnode->node->references; ref->name; ref++)
- if (!strcmp(ref->name, propname))
- break;
+ /*
+* We expect that references are never stored inline, even
+* single ones, as they are too big.
+*/
+ if (prop->is_inline)
+ return -EINVAL;
- if (!ref->name || index > (ref->nrefs - 1))
- return -ENOENT;
+ if (index * sizeof(*ref) >= prop->length)
+ return -ENOENT;
- ref_args = &ref->refs[index];
- }
+ ref_array = prop->pointer;
+ ref = &ref_array[index];
- refnode = software_node_fwnode(ref_args->node);
+ refnode = software_node_fwnode(ref->node);
if (!refnode)
return -ENOENT;
@@ -525,7 +513,7 @@ software_node_get_reference_args(const struct fwnode_handle
*fwnode,
args->nargs = nargs;
for (i = 0; i < nargs; i++)
- args->args[i] = ref_args->args[i];
+ args->args[i] = ref->args[i];
return 0;
}
diff --git a/include/linux/property.h b/include/linux/property.h
index 08d3e9d126ef..fa5a2ddc0c7b 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -412,30 +412,16 @@ int fwnode_graph_parse_endpoint(const struct
fwnode_handle *fwnode,
/* --
*/
/* Software fwnode support - when HW description is incomplete or missing */
-/**
- * struct software_node_reference - Named software node reference property
- * @name: Name of the property
- * @nrefs: Number of elements in @refs array
- * @refs: Array of references with optional arguments
- */
-struct software_node_reference {
- const char *name;
- unsigned int nrefs;
- const struct software_node_ref_args *refs;
-};
-
/**
* struct software_node - Software node description
* @name: Name of the software node
* @parent: Parent of the software node
* @properties: Array of device properties
- * @references: Array of software node reference properties
*/
struct software_node {
const char *name;
const struct software_node *parent;
const struct property_entry *properties;
- const struct software_node_reference *references;
};
bool is_software_node(const struct fwnode_handle *fwnode);
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 06/14] software node: get rid of property_set_pointer()
Instead of explicitly setting values of integer types when copying
property entries lets just copy entire value union when processing
non-array values.
When handling array values assign the pointer there using the newly
introduced "raw" pointer union member. This allows us to remove
property_set_pointer().
In property_get_pointer() we do not need to handle each data type
separately, we can simply return either the raw pointer or pointer to
values union.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c| 90 +---
include/linux/property.h | 12 ++
2 files changed, 22 insertions(+), 80 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 7bad41a8f65d..726195d334e4 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -103,71 +103,15 @@ property_entry_get(const struct property_entry *prop,
const char *name)
return NULL;
}
-static void
-property_set_pointer(struct property_entry *prop, const void *pointer)
-{
- switch (prop->type) {
- case DEV_PROP_U8:
- if (prop->is_array)
- prop->pointer.u8_data = pointer;
- else
- prop->value.u8_data = *((u8 *)pointer);
- break;
- case DEV_PROP_U16:
- if (prop->is_array)
- prop->pointer.u16_data = pointer;
- else
- prop->value.u16_data = *((u16 *)pointer);
- break;
- case DEV_PROP_U32:
- if (prop->is_array)
- prop->pointer.u32_data = pointer;
- else
- prop->value.u32_data = *((u32 *)pointer);
- break;
- case DEV_PROP_U64:
- if (prop->is_array)
- prop->pointer.u64_data = pointer;
- else
- prop->value.u64_data = *((u64 *)pointer);
- break;
- case DEV_PROP_STRING:
- if (prop->is_array)
- prop->pointer.str = pointer;
- else
- prop->value.str = pointer;
- break;
- default:
- break;
- }
-}
-
static const void *property_get_pointer(const struct property_entry *prop)
{
- switch (prop->type) {
- case DEV_PROP_U8:
- if (prop->is_array)
- return prop->pointer.u8_data;
- return &prop->value.u8_data;
- case DEV_PROP_U16:
- if (prop->is_array)
- return prop->pointer.u16_data;
- return &prop->value.u16_data;
- case DEV_PROP_U32:
- if (prop->is_array)
- return prop->pointer.u32_data;
- return &prop->value.u32_data;
- case DEV_PROP_U64:
- if (prop->is_array)
- return prop->pointer.u64_data;
- return &prop->value.u64_data;
- case DEV_PROP_STRING:
- if (prop->is_array)
- return prop->pointer.str;
- return &prop->value.str;
- default:
+ if (!prop->length)
return NULL;
- }
+
+ if (prop->is_array)
+ return prop->pointer;
+
+ return &prop->value;
}
static const void *property_entry_find(const struct property_entry *props,
@@ -322,13 +266,15 @@ static int property_entry_read_string_array(const struct
property_entry *props,
static void property_entry_free_data(const struct property_entry *p)
{
const void *pointer = property_get_pointer(p);
+ const char * const *src_str;
size_t i, nval;
if (p->is_array) {
- if (p->type == DEV_PROP_STRING && p->pointer.str) {
+ if (p->type == DEV_PROP_STRING && p->pointer) {
+ src_str = p->pointer;
nval = p->length / sizeof(const char *);
for (i = 0; i < nval; i++)
- kfree(p->pointer.str[i]);
+ kfree(src_str[i]);
}
kfree(pointer);
} else if (p->type == DEV_PROP_STRING) {
@@ -341,6 +287,7 @@ static const char * const *
property_copy_string_array(const struct property_entry *src)
{
const char **d;
+ const char * const *src_str = src->pointer;
size_t nval = src->length / sizeof(*d);
int i;
@@ -349,8 +296,8 @@ property_copy_string_array(const struct property_entry *src)
return NULL;
for (i = 0; i < nval; i++) {
- d[i] = kstrdup(src->pointer.str[i], GFP_KERNEL);
- if (!d[i] && src->pointer.str[i]) {
+ d[i] = kstrdup(src_str[i], GFP_KERNEL);
+ if (!d[i] && src_str[i]) {
while (--i >= 0)
kfree(d[i]);
kfree(d);
@@ -380,20 +
[PATCH v4 05/14] software node: clean up property_copy_string_array()
Because property_copy_string_array() stores the newly allocated pointer in the
destination property, we have an awkward code in property_entry_copy_data()
where we fetch the new pointer from dst.
Let's change property_copy_string_array() to return pointer and rely on the
common path in property_entry_copy_data() to store it in destination structure.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index ee2a405cca9a..7bad41a8f65d 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -337,8 +337,8 @@ static void property_entry_free_data(const struct
property_entry *p)
kfree(p->name);
}
-static int property_copy_string_array(struct property_entry *dst,
- const struct property_entry *src)
+static const char * const *
+property_copy_string_array(const struct property_entry *src)
{
const char **d;
size_t nval = src->length / sizeof(*d);
@@ -346,7 +346,7 @@ static int property_copy_string_array(struct property_entry
*dst,
d = kcalloc(nval, sizeof(*d), GFP_KERNEL);
if (!d)
- return -ENOMEM;
+ return NULL;
for (i = 0; i < nval; i++) {
d[i] = kstrdup(src->pointer.str[i], GFP_KERNEL);
@@ -354,12 +354,11 @@ static int property_copy_string_array(struct
property_entry *dst,
while (--i >= 0)
kfree(d[i]);
kfree(d);
- return -ENOMEM;
+ return NULL;
}
}
- dst->pointer.str = d;
- return 0;
+ return d;
}
static int property_entry_copy_data(struct property_entry *dst,
@@ -367,17 +366,15 @@ static int property_entry_copy_data(struct property_entry
*dst,
{
const void *pointer = property_get_pointer(src);
const void *new;
- int error;
if (src->is_array) {
if (!src->length)
return -ENODATA;
if (src->type == DEV_PROP_STRING) {
- error = property_copy_string_array(dst, src);
- if (error)
- return error;
- new = dst->pointer.str;
+ new = property_copy_string_array(src);
+ if (!new)
+ return -ENOMEM;
} else {
new = kmemdup(pointer, src->length, GFP_KERNEL);
if (!new)
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 13/14] platform/x86: intel_cht_int33fe: use inline reference properties
Now that static device properties allow defining reference properties
together with all other types of properties, instead of managing them
separately, let's adjust the driver.
Signed-off-by: Dmitry Torokhov
---
drivers/platform/x86/intel_cht_int33fe.c | 81
1 file changed, 41 insertions(+), 40 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 1d5d877b9582..4177c5424931 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -46,30 +46,6 @@ struct cht_int33fe_data {
struct fwnode_handle *dp;
};
-static const struct software_node nodes[];
-
-static const struct software_node_ref_args pi3usb30532_ref = {
- &nodes[INT33FE_NODE_PI3USB30532]
-};
-
-static const struct software_node_ref_args dp_ref = {
- &nodes[INT33FE_NODE_DISPLAYPORT]
-};
-
-static struct software_node_ref_args mux_ref;
-
-static const struct software_node_reference usb_connector_refs[] = {
- { "orientation-switch", 1, &pi3usb30532_ref},
- { "mode-switch", 1, &pi3usb30532_ref},
- { "displayport", 1, &dp_ref},
- { }
-};
-
-static const struct software_node_reference fusb302_refs[] = {
- { "usb-role-switch", 1, &mux_ref},
- { }
-};
-
/*
* Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
* the max17047 both through the INT33FE ACPI device (it is right there
@@ -105,8 +81,18 @@ static const struct property_entry max17047_props[] = {
{ }
};
+/*
+ * We are not using inline property here because those are constant,
+ * and we need to adjust this one at runtime to point to real
+ * software node.
+ */
+static struct software_node_ref_args fusb302_mux_refs[] = {
+ { .node = NULL },
+};
+
static const struct property_entry fusb302_props[] = {
PROPERTY_ENTRY_STRING("linux,extcon-name", "cht_wcove_pwrsrc"),
+ PROPERTY_ENTRY_REF_ARRAY("usb-role-switch", fusb302_mux_refs),
{ }
};
@@ -122,6 +108,8 @@ static const u32 snk_pdo[] = {
PDO_VAR(5000, 12000, 3000),
};
+static const struct software_node nodes[];
+
static const struct property_entry usb_connector_props[] = {
PROPERTY_ENTRY_STRING("data-role", "dual"),
PROPERTY_ENTRY_STRING("power-role", "dual"),
@@ -129,15 +117,21 @@ static const struct property_entry usb_connector_props[]
= {
PROPERTY_ENTRY_U32_ARRAY("source-pdos", src_pdo),
PROPERTY_ENTRY_U32_ARRAY("sink-pdos", snk_pdo),
PROPERTY_ENTRY_U32("op-sink-microwatt", 250),
+ PROPERTY_ENTRY_REF("orientation-switch",
+ &nodes[INT33FE_NODE_PI3USB30532]),
+ PROPERTY_ENTRY_REF("mode-switch",
+ &nodes[INT33FE_NODE_PI3USB30532]),
+ PROPERTY_ENTRY_REF("displayport",
+ &nodes[INT33FE_NODE_DISPLAYPORT]),
{ }
};
static const struct software_node nodes[] = {
- { "fusb302", NULL, fusb302_props, fusb302_refs },
+ { "fusb302", NULL, fusb302_props },
{ "max17047", NULL, max17047_props },
{ "pi3usb30532" },
{ "displayport" },
- { "connector", &nodes[0], usb_connector_props, usb_connector_refs },
+ { "connector", &nodes[0], usb_connector_props },
{ }
};
@@ -173,9 +167,10 @@ static void cht_int33fe_remove_nodes(struct
cht_int33fe_data *data)
{
software_node_unregister_nodes(nodes);
- if (mux_ref.node) {
- fwnode_handle_put(software_node_fwnode(mux_ref.node));
- mux_ref.node = NULL;
+ if (fusb302_mux_refs[0].node) {
+ fwnode_handle_put(
+ software_node_fwnode(fusb302_mux_refs[0].node));
+ fusb302_mux_refs[0].node = NULL;
}
if (data->dp) {
@@ -187,25 +182,31 @@ static void cht_int33fe_remove_nodes(struct
cht_int33fe_data *data)
static int cht_int33fe_add_nodes(struct cht_int33fe_data *data)
{
+ const struct software_node *mux_ref_node;
int ret;
- ret = software_node_register_nodes(nodes);
- if (ret)
- return ret;
-
- /* The devices that are not created in this driver need extra steps. */
-
/*
* There is no ACPI device node for the USB role mux, so we need to wait
* until the mux driver has created software node for the mux device.
* It means we depend on the mux driver. This function will return
* -EPROBE_DEFER until the mux device is registered.
*/
- mux_ref.node = software_node_find_by_name(NULL, "intel-xhci-usb-sw");
- if (!mux_ref.node) {
- ret = -EPROBE_DEFER;
- goto err_remove_nodes;
- }
+ mux_ref_node = software_node_find_by_name(NULL, "intel-xhci-usb-sw");
+ if (!mux_ref_node)
+ return -EPROBE_DEFER;
+
+ /*
+* Update node used in "usb-role-switch" property. Note that we
+*
[PATCH v4 03/14] efi/apple-properties: use PROPERTY_ENTRY_U8_ARRAY_LEN
Let's switch to using PROPERTY_ENTRY_U8_ARRAY_LEN() to initialize
property entries. Also, when dumping data, rely on local variables
instead of poking into the property entry structure directly.
Signed-off-by: Dmitry Torokhov
---
drivers/firmware/efi/apple-properties.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/efi/apple-properties.c
b/drivers/firmware/efi/apple-properties.c
index 0e206c9e0d7a..5ccf39986a14 100644
--- a/drivers/firmware/efi/apple-properties.c
+++ b/drivers/firmware/efi/apple-properties.c
@@ -53,7 +53,8 @@ static void __init unmarshal_key_value_pairs(struct
dev_header *dev_header,
for (i = 0; i < dev_header->prop_count; i++) {
int remaining = dev_header->len - (ptr - (void *)dev_header);
- u32 key_len, val_len;
+ u32 key_len, val_len, entry_len;
+ const u8 *entry_data;
char *key;
if (sizeof(key_len) > remaining)
@@ -85,17 +86,14 @@ static void __init unmarshal_key_value_pairs(struct
dev_header *dev_header,
ucs2_as_utf8(key, ptr + sizeof(key_len),
key_len - sizeof(key_len));
- entry[i].name = key;
- entry[i].length = val_len - sizeof(val_len);
- entry[i].is_array = !!entry[i].length;
- entry[i].type = DEV_PROP_U8;
- entry[i].pointer.u8_data = ptr + key_len + sizeof(val_len);
-
+ entry_data = ptr + key_len + sizeof(val_len);
+ entry_len = val_len - sizeof(val_len);
+ entry[i] = PROPERTY_ENTRY_U8_ARRAY_LEN(key, entry_data,
+ entry_len);
if (dump_properties) {
- dev_info(dev, "property: %s\n", entry[i].name);
+ dev_info(dev, "property: %s\n", key);
print_hex_dump(KERN_INFO, pr_fmt(), DUMP_PREFIX_OFFSET,
- 16, 1, entry[i].pointer.u8_data,
- entry[i].length, true);
+ 16, 1, entry_data, entry_len, true);
}
ptr += key_len + val_len;
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 12/14] software node: implement reference properties
It is possible to store references to software nodes in the same fashion as
other static properties, so that users do not need to define separate
structures:
static const struct software_node gpio_bank_b_node = {
.name = "B",
};
static const struct property_entry simone_key_enter_props[] = {
PROPERTY_ENTRY_U32("linux,code", KEY_ENTER),
PROPERTY_ENTRY_STRING("label", "enter"),
PROPERTY_ENTRY_REF("gpios", &gpio_bank_b_node, 123, GPIO_ACTIVE_LOW),
{ }
};
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c| 48 +++--
include/linux/property.h | 57 +---
2 files changed, 81 insertions(+), 24 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 1aa6559993ec..07e1325789d2 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -265,6 +265,12 @@ static int property_entry_copy_data(struct property_entry
*dst,
}
dst->pointer = new;
+ } else if (src->type == DEV_PROP_REF) {
+ /*
+* Reference properties are never stored inline as
+* they are too big.
+*/
+ return -EINVAL;
} else if (src->type == DEV_PROP_STRING) {
new = kstrdup(src->value.str, GFP_KERNEL);
if (!new && src->value.str)
@@ -460,21 +466,47 @@ software_node_get_reference_args(const struct
fwnode_handle *fwnode,
{
struct swnode *swnode = to_swnode(fwnode);
const struct software_node_reference *ref;
+ const struct software_node_ref_args *ref_array;
+ const struct software_node_ref_args *ref_args;
const struct property_entry *prop;
struct fwnode_handle *refnode;
int i;
- if (!swnode || !swnode->node->references)
+ if (!swnode)
return -ENOENT;
- for (ref = swnode->node->references; ref->name; ref++)
- if (!strcmp(ref->name, propname))
- break;
+ prop = property_entry_get(swnode->node->properties, propname);
+ if (prop) {
+ if (prop->type != DEV_PROP_REF)
+ return -EINVAL;
- if (!ref->name || index > (ref->nrefs - 1))
- return -ENOENT;
+ /*
+* We expect that references are never stored inline, even
+* single ones, as they are too big.
+*/
+ if (prop->is_inline)
+ return -EINVAL;
+
+ if (index * sizeof(*ref_args) >= prop->length)
+ return -ENOENT;
+
+ ref_array = prop->pointer;
+ ref_args = &ref_array[index];
+ } else {
+ if (!swnode->node->references)
+ return -ENOENT;
+
+ for (ref = swnode->node->references; ref->name; ref++)
+ if (!strcmp(ref->name, propname))
+ break;
+
+ if (!ref->name || index > (ref->nrefs - 1))
+ return -ENOENT;
+
+ ref_args = &ref->refs[index];
+ }
- refnode = software_node_fwnode(ref->refs[index].node);
+ refnode = software_node_fwnode(ref_args->node);
if (!refnode)
return -ENOENT;
@@ -493,7 +525,7 @@ software_node_get_reference_args(const struct fwnode_handle
*fwnode,
args->nargs = nargs;
for (i = 0; i < nargs; i++)
- args->args[i] = ref->refs[index].args[i];
+ args->args[i] = ref_args->args[i];
return 0;
}
diff --git a/include/linux/property.h b/include/linux/property.h
index ac7823d58cfe..08d3e9d126ef 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -22,6 +22,7 @@ enum dev_prop_type {
DEV_PROP_U32,
DEV_PROP_U64,
DEV_PROP_STRING,
+ DEV_PROP_REF,
};
enum dev_dma_attr {
@@ -218,6 +219,20 @@ static inline int fwnode_property_count_u64(const struct
fwnode_handle *fwnode,
return fwnode_property_read_u64_array(fwnode, propname, NULL, 0);
}
+struct software_node;
+
+/**
+ * struct software_node_ref_args - Reference property with additional arguments
+ * @node: Reference to a software node
+ * @nargs: Number of elements in @args array
+ * @args: Integer arguments
+ */
+struct software_node_ref_args {
+ const struct software_node *node;
+ unsigned int nargs;
+ u64 args[NR_FWNODE_REFERENCE_ARGS];
+};
+
/**
* struct property_entry - "Built-in" device property representation.
* @name: Name of the property.
@@ -255,14 +270,20 @@ struct property_entry {
#define __PROPERTY_ENTRY_ELEMENT_SIZE(_elem_) \
sizeof(((struct property_entry *)NULL)->value._elem_)
-#define __PROPERTY_ENTRY_ARRAY_LEN(_name_, _elem_, _Type_, _val_, _len_)\
+#define __PROPERTY_ENTRY_ARRAY_ELSIZE_LEN(_name_, _elsize_, _Type_,\
+
[PATCH v4 01/14] software node: remove DEV_PROP_MAX
This definition is not used anywhere, let's remove it.
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/property.h b/include/linux/property.h
index 9b3d4ca3a73a..44c1704f7163 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -22,7 +22,6 @@ enum dev_prop_type {
DEV_PROP_U32,
DEV_PROP_U64,
DEV_PROP_STRING,
- DEV_PROP_MAX,
};
enum dev_dma_attr {
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 02/14] software node: introduce PROPERTY_ENTRY_ARRAY_XXX_LEN()
Sometimes we want to initialize property entry array from a regular
pointer, when we can't determine length automatically via ARRAY_SIZE.
Let's introduce PROPERTY_ENTRY_ARRAY_XXX_LEN macros that take explicit
"len" argument.
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 45 +---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/include/linux/property.h b/include/linux/property.h
index 44c1704f7163..f89b930ca4b7 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -256,33 +256,44 @@ struct property_entry {
* and structs.
*/
-#define PROPERTY_ENTRY_INTEGER_ARRAY(_name_, _type_, _Type_, _val_)\
+#define PROPERTY_ENTRY_ARRAY_LEN(_name_, _type_, _Type_, _val_, _len_) \
(struct property_entry) { \
.name = _name_, \
- .length = ARRAY_SIZE(_val_) * sizeof(_type_), \
+ .length = (_len_) * sizeof(_type_), \
.is_array = true, \
.type = DEV_PROP_##_Type_, \
{ .pointer = { ._type_##_data = _val_ } }, \
}
-#define PROPERTY_ENTRY_U8_ARRAY(_name_, _val_) \
- PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u8, U8, _val_)
-#define PROPERTY_ENTRY_U16_ARRAY(_name_, _val_)\
- PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u16, U16, _val_)
-#define PROPERTY_ENTRY_U32_ARRAY(_name_, _val_)\
- PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u32, U32, _val_)
-#define PROPERTY_ENTRY_U64_ARRAY(_name_, _val_)\
- PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u64, U64, _val_)
+#define PROPERTY_ENTRY_U8_ARRAY_LEN(_name_, _val_, _len_) \
+ PROPERTY_ENTRY_ARRAY_LEN(_name_, u8, U8, _val_, _len_)
+#define PROPERTY_ENTRY_U16_ARRAY_LEN(_name_, _val_, _len_) \
+ PROPERTY_ENTRY_ARRAY_LEN(_name_, u16, U16, _val_, _len_)
+#define PROPERTY_ENTRY_U32_ARRAY_LEN(_name_, _val_, _len_) \
+ PROPERTY_ENTRY_ARRAY_LEN(_name_, u32, U32, _val_, _len_)
+#define PROPERTY_ENTRY_U64_ARRAY_LEN(_name_, _val_, _len_) \
+ PROPERTY_ENTRY_ARRAY_LEN(_name_, u64, U64, _val_, _len_)
-#define PROPERTY_ENTRY_STRING_ARRAY(_name_, _val_) \
-(struct property_entry) { \
- .name = _name_, \
- .length = ARRAY_SIZE(_val_) * sizeof(const char *), \
- .is_array = true, \
- .type = DEV_PROP_STRING,\
- { .pointer = { .str = _val_ } },\
+#define PROPERTY_ENTRY_STRING_ARRAY_LEN(_name_, _val_, _len_) \
+(struct property_entry) { \
+ .name = _name_, \
+ .length = (_len_) * sizeof(const char *), \
+ .is_array = true, \
+ .type = DEV_PROP_STRING,\
+ { .pointer = { .str = _val_ } },\
}
+#define PROPERTY_ENTRY_U8_ARRAY(_name_, _val_) \
+ PROPERTY_ENTRY_U8_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
+#define PROPERTY_ENTRY_U16_ARRAY(_name_, _val_)
\
+ PROPERTY_ENTRY_U16_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
+#define PROPERTY_ENTRY_U32_ARRAY(_name_, _val_)
\
+ PROPERTY_ENTRY_U32_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
+#define PROPERTY_ENTRY_U64_ARRAY(_name_, _val_)
\
+ PROPERTY_ENTRY_U64_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
+#define PROPERTY_ENTRY_STRING_ARRAY(_name_, _val_) \
+ PROPERTY_ENTRY_STRING_ARRAY_LEN(_name_, _val_, ARRAY_SIZE(_val_))
+
#define PROPERTY_ENTRY_INTEGER(_name_, _type_, _Type_, _val_) \
(struct property_entry) { \
.name = _name_, \
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 10/14] software node: rename is_array to is_inline
We do not need a special flag to know if we are dealing with an array,
as we can get that data from ratio between element length and the data
size, however we do need a flag to know whether the data is stored
directly inside property_entry or separately.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c| 9 +
include/linux/property.h | 12 +++-
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 9c3e566c753e..83e2a706a86e 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -108,7 +108,7 @@ static const void *property_get_pointer(const struct
property_entry *prop)
if (!prop->length)
return NULL;
- if (prop->is_array)
+ if (!prop->is_inline)
return prop->pointer;
return &prop->value;
@@ -205,7 +205,7 @@ static void property_entry_free_data(const struct
property_entry *p)
const char * const *src_str;
size_t i, nval;
- if (p->is_array) {
+ if (!p->is_inline) {
if (p->type == DEV_PROP_STRING && p->pointer) {
src_str = p->pointer;
nval = p->length / sizeof(const char *);
@@ -250,7 +250,7 @@ static int property_entry_copy_data(struct property_entry
*dst,
const void *pointer = property_get_pointer(src);
const void *new;
- if (src->is_array) {
+ if (!src->is_inline) {
if (!src->length)
return -ENODATA;
@@ -264,15 +264,16 @@ static int property_entry_copy_data(struct property_entry
*dst,
return -ENOMEM;
}
- dst->is_array = true;
dst->pointer = new;
} else if (src->type == DEV_PROP_STRING) {
new = kstrdup(src->value.str, GFP_KERNEL);
if (!new && src->value.str)
return -ENOMEM;
+ dst->is_inline = true;
dst->value.str = new;
} else {
+ dst->is_inline = true;
dst->value = src->value;
}
diff --git a/include/linux/property.h b/include/linux/property.h
index 238e1507925f..ac7823d58cfe 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -222,15 +222,17 @@ static inline int fwnode_property_count_u64(const struct
fwnode_handle *fwnode,
* struct property_entry - "Built-in" device property representation.
* @name: Name of the property.
* @length: Length of data making up the value.
- * @is_array: True when the property is an array.
+ * @is_inline: True when the property value is stored directly in
+ * &struct property_entry instance.
* @type: Type of the data in unions.
- * @pointer: Pointer to the property (an array of items of the given type).
- * @value: Value of the property (when it is a single item of the given type).
+ * @pointer: Pointer to the property when it is stored separately from
+ * the &struct property_entry instance.
+ * @value: Value of the property when it is stored inline.
*/
struct property_entry {
const char *name;
size_t length;
- bool is_array;
+ bool is_inline;
enum dev_prop_type type;
union {
const void *pointer;
@@ -257,7 +259,6 @@ struct property_entry {
(struct property_entry) { \
.name = _name_, \
.length = (_len_) * __PROPERTY_ENTRY_ELEMENT_SIZE(_elem_), \
- .is_array = true, \
.type = DEV_PROP_##_Type_, \
{ .pointer = _val_ }, \
}
@@ -288,6 +289,7 @@ struct property_entry {
(struct property_entry) { \
.name = _name_, \
.length = __PROPERTY_ENTRY_ELEMENT_SIZE(_elem_),\
+ .is_inline = true, \
.type = DEV_PROP_##_Type_, \
{ .value = { ._elem_ = _val_ } }, \
}
--
2.23.0.162.g0b9fbb3734-goog
[PATCH v4 00/14] software node: add support for reference properties
These series implement "references" properties for software nodes as true properties, instead of managing them completely separately. The first 10 patches are generic cleanups and consolidation and unification of the existing code; patch #11 implements PROPERTY_EMTRY_REF() and friends; patch #12 converts the user of references to the property syntax, and patch #13 removes the remains of references as entities that are managed separately. Changes in v4: - dealt with union aliasing concerns - inline small properties on copy Changes in v3: - added various cleanups before implementing reference properties Changes in v2: - reworked code so that even single-entry reference properties are stored as arrays (i.e. the software_node_ref_args instances are not part of property_entry structure) to avoid size increase. From user's POV nothing is changed, one can still use PROPERTY_ENTRY_REF macro to define reference "inline". - dropped unused DEV_PROP_MAX - rebased on linux-next Dmitry Torokhov (14): software node: remove DEV_PROP_MAX software node: introduce PROPERTY_ENTRY_ARRAY_XXX_LEN() efi/apple-properties: use PROPERTY_ENTRY_U8_ARRAY_LEN software node: mark internal macros with double underscores software node: clean up property_copy_string_array() software node: get rid of property_set_pointer() software node: remove property_entry_read_uNN_array functions software node: unify PROPERTY_ENTRY_XXX macros software node: simplify property_entry_read_string_array() software node: rename is_array to is_inline software node: move small properties inline when copying software node: implement reference properties platform/x86: intel_cht_int33fe: use inline reference properties software node: remove separate handling of references drivers/base/swnode.c| 266 --- drivers/firmware/efi/apple-properties.c | 18 +- drivers/platform/x86/intel_cht_int33fe.c | 81 +++ include/linux/property.h | 177 +++ 4 files changed, 230 insertions(+), 312 deletions(-) -- 2.23.0.162.g0b9fbb3734-goog
Re: [PATCH] net: stmmac: socfpga: re-use the `interface` parameter from platform data
On Tue, 2019-09-10 at 17:46 +0200, David Miller wrote: > [External] > > From: David Miller > Date: Tue, 10 Sep 2019 17:45:44 +0200 (CEST) > > > From: Alexandru Ardelean > > Date: Fri, 6 Sep 2019 15:30:54 +0300 > > > > > The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac` > > > struct and parses it on init. > > > > > > The shared `stmmac_probe_config_dt()` function also parses this from the > > > device-tree and makes it available on the returned `plat_data` (which is > > > the same data available via `netdev_priv()`). > > > > > > All that's needed now is to dig that information out, via some > > > `dev_get_drvdata()` && `netdev_priv()` calls and re-use it. > > > > > > Signed-off-by: Alexandru Ardelean > > > > This doesn't build even on net-next. > Right. My bad. I think I got confused with multiple/cross-testing and probably this change didn't even get compiled. Apologies for this. Will send a good version. Alex > Specifically: > > drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c: In function > ‘socfpga_gen5_set_phy_mode’: > drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: error: ‘phymode’ > undeclared (first use in this function); > did you mean ‘phy_modes’? > 264 | dev_err(dwmac->dev, "bad phy mode %d\n", phymode); > |^~~ > ./include/linux/device.h:1499:32: note: in definition of macro ‘dev_err’ > 1499 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__) > |^~~ > drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: note: each > undeclared identifier is reported only once for > each function it appears in > 264 | dev_err(dwmac->dev, "bad phy mode %d\n", phymode); > |^~~ > ./include/linux/device.h:1499:32: note: in definition of macro ‘dev_err’ > 1499 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__) > |^~~ > drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c: In function > ‘socfpga_gen10_set_phy_mode’: > drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:340:6: error: ‘phymode’ > undeclared (first use in this function); > did you mean ‘phy_modes’? > 340 | phymode == PHY_INTERFACE_MODE_MII || > | ^~~ > | phy_modes
[PATCH] ARM: module: Drop 'rel->r_offset < 0' always false statement
Since rel->r_offset is declared as Elf32_Addr,
this value is always non-negative.
typedef struct elf32_rel {
Elf32_Addrr_offset;
Elf32_Word r_info;
} Elf32_Rel;
typedef __u32 Elf32_Addr;
typedef unsigned int __u32;
Drop 'rel->r_offset < 0' statement which is always false.
Signed-off-by: Austin Kim
---
arch/arm/kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f..0921ce7 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -92,7 +92,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab,
unsigned int symindex,
sym = ((Elf32_Sym *)symsec->sh_addr) + offset;
symname = strtab + sym->st_name;
- if (rel->r_offset < 0 || rel->r_offset > dstsec->sh_size -
sizeof(u32)) {
+ if (rel->r_offset > dstsec->sh_size - sizeof(u32)) {
pr_err("%s: section %u reloc %u sym '%s': out of bounds
relocation, offset %d size %u\n",
module->name, relindex, i, symname,
rel->r_offset, dstsec->sh_size);
--
2.6.2
Re: [PATCH V8 5/5] mmc: host: sdhci-pci: Add Genesys Logic GL975x support
On Fri, Sep 06, 2019 at 10:33:26AM +0800, Ben Chuang wrote:
> From: Ben Chuang
>
> Add support for the GL9750 and GL9755 chipsets.
>
> Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/
> GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor
> tuning flow for GL9750.
>
> Co-developed-by: Michael K Johnson
> Signed-off-by: Michael K Johnson
> Signed-off-by: Ben Chuang
> ---
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/Makefile | 2 +-
> drivers/mmc/host/sdhci-pci-core.c | 2 +
> drivers/mmc/host/sdhci-pci-gli.c | 355 ++
> drivers/mmc/host/sdhci-pci.h | 5 +
> 5 files changed, 364 insertions(+), 1 deletion(-)
> create mode 100644 drivers/mmc/host/sdhci-pci-gli.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 931770f17087..9fbfff514d6c 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -94,6 +94,7 @@ config MMC_SDHCI_PCI
> depends on MMC_SDHCI && PCI
> select MMC_CQHCI
> select IOSF_MBI if X86
> + select MMC_SDHCI_IO_ACCESSORS
> help
> This selects the PCI Secure Digital Host Controller Interface.
> Most controllers found today are PCI devices.
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 73578718f119..661445415090 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -13,7 +13,7 @@ obj-$(CONFIG_MMC_MXS) += mxs-mmc.o
> obj-$(CONFIG_MMC_SDHCI) += sdhci.o
> obj-$(CONFIG_MMC_SDHCI_PCI) += sdhci-pci.o
> sdhci-pci-y += sdhci-pci-core.o sdhci-pci-o2micro.o
> sdhci-pci-arasan.o \
> -sdhci-pci-dwc-mshc.o
> +sdhci-pci-dwc-mshc.o sdhci-pci-gli.o
> obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI)) += sdhci-pci-data.o
> obj-$(CONFIG_MMC_SDHCI_ACPI) += sdhci-acpi.o
> obj-$(CONFIG_MMC_SDHCI_PXAV3)+= sdhci-pxav3.o
> diff --git a/drivers/mmc/host/sdhci-pci-core.c
> b/drivers/mmc/host/sdhci-pci-core.c
> index 4154ee11b47d..e5835fbf73bc 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -1682,6 +1682,8 @@ static const struct pci_device_id pci_ids[] = {
> SDHCI_PCI_DEVICE(O2, SEABIRD1, o2),
> SDHCI_PCI_DEVICE(ARASAN, PHY_EMMC, arasan),
> SDHCI_PCI_DEVICE(SYNOPSYS, DWC_MSHC, snps),
> + SDHCI_PCI_DEVICE(GLI, 9750, gl9750),
> + SDHCI_PCI_DEVICE(GLI, 9755, gl9755),
> SDHCI_PCI_DEVICE_CLASS(AMD, SYSTEM_SDHCI, PCI_CLASS_MASK, amd),
> /* Generic SD host controller */
> {PCI_DEVICE_CLASS(SYSTEM_SDHCI, PCI_CLASS_MASK)},
> diff --git a/drivers/mmc/host/sdhci-pci-gli.c
> b/drivers/mmc/host/sdhci-pci-gli.c
> new file mode 100644
> index ..94462b94abec
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-pci-gli.c
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Genesys Logic, Inc.
> + *
> + * Authors: Ben Chuang
> + *
> + * Version: v0.9.0 (2019-08-08)
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "sdhci.h"
> +#include "sdhci-pci.h"
> +
> +/* Genesys Logic extra registers */
> +#define SDHCI_GLI_9750_WT 0x800
> +#define SDHCI_GLI_9750_WT_EN BIT(0)
> +#define GLI_9750_WT_EN_ON 0x1
> +#define GLI_9750_WT_EN_OFF 0x0
> +
> +#define SDHCI_GLI_9750_DRIVING 0x860
> +#define SDHCI_GLI_9750_DRIVING_1GENMASK(11, 0)
> +#define SDHCI_GLI_9750_DRIVING_2GENMASK(27, 26)
> +#define GLI_9750_DRIVING_1_VALUE0xFFF
> +#define GLI_9750_DRIVING_2_VALUE0x3
> +
> +#define SDHCI_GLI_9750_PLL 0x864
> +#define SDHCI_GLI_9750_PLL_TX2_INVBIT(23)
> +#define SDHCI_GLI_9750_PLL_TX2_DLYGENMASK(22, 20)
> +#define GLI_9750_PLL_TX2_INV_VALUE0x1
> +#define GLI_9750_PLL_TX2_DLY_VALUE0x0
> +
> +#define SDHCI_GLI_9750_SW_CTRL 0x874
> +#define SDHCI_GLI_9750_SW_CTRL_4GENMASK(7, 6)
> +#define GLI_9750_SW_CTRL_4_VALUE0x3
> +
> +#define SDHCI_GLI_9750_MISC0x878
> +#define SDHCI_GLI_9750_MISC_TX1_INVBIT(2)
> +#define SDHCI_GLI_9750_MISC_RX_INV BIT(3)
> +#define SDHCI_GLI_9750_MISC_TX1_DLYGENMASK(6, 4)
> +#define GLI_9750_MISC_TX1_INV_VALUE0x0
> +#define GLI_9750_MISC_RX_INV_ON0x1
> +#define GLI_9750_MISC_RX_INV_OFF 0x0
> +#define GLI_9750_MISC_RX_INV_VALUE GLI_9750_MISC_RX_INV_OFF
> +#define GLI_9750_MISC_TX1_DLY_VALUE0x5
> +
> +#define SDHCI_GLI_9750_TUNING_CONTROL 0x540
> +#define SDHCI_GLI_9750_TUNING_CONTROL_EN BIT(4)
> +#define GLI_9750_TUNING_CONTROL_EN_ON 0x1
> +#define GLI_9750_TUNING_CONTROL_EN_OFF0x0
> +#define SDHCI_GLI_9750_TUNING_CONTROL_GLITCH_1BIT(16)
> +#define SDHCI_GLI_9750_TUNING_CONTROL_GLITCH_2GENMASK(20, 19)
> +#define GLI_9750_TUNING_CONTROL_GLITCH_1_VALUE0
Re: [PATCH] Revert "locking/pvqspinlock: Don't wait if vCPU is preempted"
On 9/10/19 6:56 AM, Wanpeng Li wrote: > On Mon, 9 Sep 2019 at 18:56, Waiman Long wrote: >> On 9/9/19 2:40 AM, Wanpeng Li wrote: >>> From: Wanpeng Li >>> >>> This patch reverts commit 75437bb304b20 (locking/pvqspinlock: Don't wait if >>> vCPU is preempted), we found great regression caused by this commit. >>> >>> Xeon Skylake box, 2 sockets, 40 cores, 80 threads, three VMs, each is 80 >>> vCPUs. >>> The score of ebizzy -M can reduce from 13000-14000 records/s to 1700-1800 >>> records/s with this commit. >>> >>> Host Guestscore >>> >>> vanilla + w/o kvm optimizes vanilla 1700-1800 records/s >>> vanilla + w/o kvm optimizes vanilla + revert 13000-14000 records/s >>> vanilla + w/ kvm optimizes vanilla 4500-5000 records/s >>> vanilla + w/ kvm optimizes vanilla + revert 14000-15500 records/s >>> >>> Exit from aggressive wait-early mechanism can result in yield premature and >>> incur extra scheduling latency in over-subscribe scenario. >>> >>> kvm optimizes: >>> [1] commit d73eb57b80b (KVM: Boost vCPUs that are delivering interrupts) >>> [2] commit 266e85a5ec9 (KVM: X86: Boost queue head vCPU to mitigate lock >>> waiter preemption) >>> >>> Tested-by: loobin...@tencent.com >>> Cc: Peter Zijlstra >>> Cc: Thomas Gleixner >>> Cc: Ingo Molnar >>> Cc: Waiman Long >>> Cc: Paolo Bonzini >>> Cc: Radim Krčmář >>> Cc: loobin...@tencent.com >>> Cc: sta...@vger.kernel.org >>> Fixes: 75437bb304b20 (locking/pvqspinlock: Don't wait if vCPU is preempted) >>> Signed-off-by: Wanpeng Li >>> --- >>> kernel/locking/qspinlock_paravirt.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/kernel/locking/qspinlock_paravirt.h >>> b/kernel/locking/qspinlock_paravirt.h >>> index 89bab07..e84d21a 100644 >>> --- a/kernel/locking/qspinlock_paravirt.h >>> +++ b/kernel/locking/qspinlock_paravirt.h >>> @@ -269,7 +269,7 @@ pv_wait_early(struct pv_node *prev, int loop) >>> if ((loop & PV_PREV_CHECK_MASK) != 0) >>> return false; >>> >>> - return READ_ONCE(prev->state) != vcpu_running || >>> vcpu_is_preempted(prev->cpu); >>> + return READ_ONCE(prev->state) != vcpu_running; >>> } >>> >>> /* >> There are several possibilities for this performance regression: >> >> 1) Multiple vcpus calling vcpu_is_preempted() repeatedly may cause some >> cacheline contention issue depending on how that callback is implemented. >> >> 2) KVM may set the preempt flag for a short period whenver an vmexit >> happens even if a vmenter is executed shortly after. In this case, we >> may want to use a more durable vcpu suspend flag that indicates the vcpu >> won't get a real vcpu back for a longer period of time. >> >> Perhaps you can add a lock event counter to count the number of >> wait_early events caused by vcpu_is_preempted() being true to see if it >> really cause a lot more wait_early than without the vcpu_is_preempted() >> call. > pv_wait_again:1:179 > pv_wait_early:1:189429 > pv_wait_head:1:263 > pv_wait_node:1:189429 > pv_vcpu_is_preempted:1:45588 > =sleep 5 > pv_wait_again:1:181 > pv_wait_early:1:202574 > pv_wait_head:1:267 > pv_wait_node:1:202590 > pv_vcpu_is_preempted:1:46336 > > The sampling period is 5s, 6% of wait_early events caused by > vcpu_is_preempted() being true. 6% isn't that high. However, when one vCPU voluntarily releases its vCPU, all the subsequently waiters in the queue will do the same. It is a cascading effect. Perhaps we wait early too aggressive with the original patch. I also look up the email chain of the original commit. The patch submitter did not provide any performance data to support this change. The patch just looked reasonable at that time. So there was no objection. Given that we now have hard evidence that this was not a good idea. I think we should revert it. Reviewed-by: Waiman Long Thanks, Longman
Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit
On Tue, Sep 10, 2019 at 12:26 PM Thomas Hellström (VMware)
wrote:
>
> On 9/10/19 6:11 PM, Andy Lutomirski wrote:
> >
> >> On Sep 5, 2019, at 8:24 AM, Christoph Hellwig wrote:
> >>
> >>> On Thu, Sep 05, 2019 at 05:21:24PM +0200, Thomas Hellström (VMware) wrote:
> On 9/5/19 4:15 PM, Dave Hansen wrote:
> Hi Thomas,
>
> Thanks for the second batch of patches! These look much improved on all
> fronts.
> >>> Yes, although the TTM functionality isn't in yet. Hopefully we won't have
> >>> to
> >>> bother you with those though, since this assumes TTM will be using the dma
> >>> API.
> >> Please take a look at dma_mmap_prepare and dma_mmap_fault in this
> >> branch:
> >>
> >>
> >> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-mmap-improvements
> >>
> >> they should allow to fault dma api pages in the page fault handler. But
> >> this is totally hot off the press and not actually tested for the last
> >> few patches. Note that I've also included your two patches from this
> >> series to handle SEV.
> > I read that patch, and it seems like you’ve built in the assumption that
> > all pages in the mapping use identical protection or, if not, that the same
> > fake vma hack that TTM already has is used to fudge around it. Could it be
> > reworked slightly to avoid this?
> >
> > I wonder if it’s a mistake to put the encryption bits in vm_page_prot at
> > all.
>
> From my POW, the encryption bits behave quite similar in behaviour to
> the caching mode bits, and they're also in vm_page_prot. They're the
> reason TTM needs to modify the page protection in the fault handler in
> the first place.
>
> The problem seen in TTM is that we want to be able to change the
> vm_page_prot from the fault handler, but it's problematic since we have
> the mmap_sem typically only in read mode. Hence the fake vma hack. From
> what I can tell it's reasonably well-behaved, since pte_modify() skips
> the bits TTM updates, so mprotect() and mremap() works OK. I think
> split_huge_pmd may run into trouble, but we don't support it (yet) with
> TTM.
One thing I'm confused about: does TTM move individual pages between
main memory and device memory or does it move whole mappings? If it
moves individual pages, then a single mapping could have PTEs from
dma_alloc_coherent() space and from PCI space. How can this work with
vm_page_prot? I guess you might get lucky and have both have the same
protection bits, but that seems like an unfortunate thing to rely on.
As a for-real example, take a look at arch/x86/entry/vdso/vma.c. The
"vvar" VMA contains multiple pages that are backed by different types
of memory. There's a page of ordinary kernel memory. Historically
there was a page of genuine MMIO memory, but that's gone now. If the
system is a SEV guest with pvclock enabled, then there's a page of
decrypted memory. They all share a VMA, they're instantiated in
.fault, and there is no hackery involved. Look at vvar_fault().
So, Christoph, can't you restructure your code a bit to compute the
caching and encryption state per page instead of once in
dma_mmap_prepare() and insert the pages accordingly? You might need
to revert 6d958546ff611c9ae09b181e628c1c5d5da5ebda depending on
exactly how you structure it.
>
> We could probably get away with a WRITE_ONCE() update of the
> vm_page_prot before taking the page table lock since
>
> a) We're locking out all other writers.
> b) We can't race with another fault to the same vma since we hold an
> address space lock ("buffer object reservation")
> c) When we need to update there are no valid page table entries in the
> vma, since it only happens directly after mmap(), or after an
> unmap_mapping_range() with the same address space lock. When another
> reader (for example split_huge_pmd()) sees a valid page table entry, it
> also sees the new page protection and things are fine.
>
> But that would really be a special case. To solve this properly we'd
> probably need an additional lock to protect the vm_flags and
> vm_page_prot, taken after mmap_sem and i_mmap_lock.
>
This is all horrible IMO.
Re: [PATCH 0/2] Perf/stat: Solve problems with repeat and interval
On 9/4/19 3:17 PM, Srikar Dronamraju wrote: There are some problems in perf stat when using a combination of repeat and interval options. This series tries to fix them. For the series: Tested-by: Ravi Bangoria
Re: [BACKPORT 4.14.y v2 2/6] locking/lockdep: Add debug_locks check in __lock_downgrade()
On Tue, 10 Sep 2019 at 22:32, Greg KH wrote: > > On Thu, Sep 05, 2019 at 11:07:14AM +0800, Baolin Wang wrote: > > From: Waiman Long > > > > [Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf] > > > > Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" > > warning right after a previous lockdep warning. It is likely that the > > previous warning turned off lock debugging causing the lockdep to have > > inconsistency states leading to the lock downgrade warning. > > > > Fix that by add a check for debug_locks at the beginning of > > __lock_downgrade(). > > > > Reported-by: Tetsuo Handa > > Reported-by: syzbot+53383ae265fb161ef...@syzkaller.appspotmail.com > > Signed-off-by: Waiman Long > > Signed-off-by: Peter Zijlstra (Intel) > > Cc: Andrew Morton > > Cc: Linus Torvalds > > Cc: Paul E. McKenney > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Will Deacon > > Link: > > https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com > > Signed-off-by: Ingo Molnar > > Signed-off-by: Baolin Wang > > --- > > kernel/locking/lockdep.c |3 +++ > > 1 file changed, 3 insertions(+) > > Why isn't this relevant for 4.19.y? I can't add a patch to 4.14.y and > then have someone upgrade to 4.19.y and not have the same fix in there, > that would be a regression. > > So can you redo this series also with a 4.19.y set at the same so we > don't get out of sync? I've queued up your first patch already as that > was in 4.19.y (and also needed in 4.9.y). I understood, will do. Thanks. -- Baolin Wang Best Regards
Re: [PATCH v3] module: add link_flag pram in ref_module func to decide whether add usage link
Friendly Ping...
On 2019/7/20 22:40, Zhiqiang Liu wrote:
> Users can call ref_module func in their modules to construct
> relationships with other modules. However, the holders
> '/sys/module//holders' of the target module donot include
> the users` module. So lsmod command misses detailed info of 'Used by'.
>
> When load module, the process is given as follows,
> load_module()
> -> mod_sysfs_setup()
> -> add_usage_links
> -> do_init_module
> -> mod->init()
>
> add_usage_links func creates holders of target modules linking to
> this module. If ref_module is called in mod->init() func, the usage
> links cannot be added.
>
> Consider that add_module_usage and add usage_link may separate, the
> link_flag pram is added in ref_module func to decide whether add usage
> link after add_module_usage. If link_flag is true, it means usage link
> of a to b's holder_dir should be created immediately after add_module_usage.
>
> V2->V3:
> - add link_flag pram in ref_module func to decide whether add usage link
>
> V1->V2:
> - remove incorrect Fixes tag
> - fix error handling of sysfs_create_link as suggested by Jessica Yu
>
> Signed-off-by: Zhiqiang Liu
> Suggested-by: Jessica Yu
> Reviewed-by: Kang Zhou
> ---
> include/linux/module.h | 2 +-
> kernel/module.c| 27 ---
> 2 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 188998d3dca9..9ec04b9e93e8 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -632,7 +632,7 @@ static inline void __module_get(struct module *module)
> #define symbol_put_addr(p) do { } while (0)
>
> #endif /* CONFIG_MODULE_UNLOAD */
> -int ref_module(struct module *a, struct module *b);
> +int ref_module(struct module *a, struct module *b, bool link_flag);
>
> /* This is a #define so the string doesn't get put in every .o file */
> #define module_name(mod) \
> diff --git a/kernel/module.c b/kernel/module.c
> index 80c7c09584cf..00e4862a8ef7 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -837,25 +837,26 @@ static int already_uses(struct module *a, struct module
> *b)
> *'b' can walk the list to see who sourced them), and of 'a'
> *targets (so 'a' can see what modules it targets).
> */
> -static int add_module_usage(struct module *a, struct module *b)
> +static struct module_use *add_module_usage(struct module *a, struct module
> *b)
> {
> struct module_use *use;
>
> pr_debug("Allocating new usage for %s.\n", a->name);
> use = kmalloc(sizeof(*use), GFP_ATOMIC);
> if (!use)
> - return -ENOMEM;
> + return NULL;
>
> use->source = a;
> use->target = b;
> list_add(&use->source_list, &b->source_list);
> list_add(&use->target_list, &a->target_list);
> - return 0;
> + return use;
> }
>
> /* Module a uses b: caller needs module_mutex() */
> -int ref_module(struct module *a, struct module *b)
> +int ref_module(struct module *a, struct module *b, bool link_flag)
> {
> + struct module_use *use;
> int err;
>
> if (b == NULL || already_uses(a, b))
> @@ -866,9 +867,21 @@ int ref_module(struct module *a, struct module *b)
> if (err)
> return err;
>
> - err = add_module_usage(a, b);
> + use = add_module_usage(a, b);
> + if (!use) {
> + module_put(b);
> + return -ENOMEM;
> + }
> +
> + if (!link_flag)
> + return 0;
> +
> + err = sysfs_create_link(b->holders_dir, &a->mkobj.kobj, a->name);
> if (err) {
> module_put(b);
> + list_del(&use->source_list);
> + list_del(&use->target_list);
> + kfree(use);
> return err;
> }
> return 0;
> @@ -1152,7 +1165,7 @@ static inline void module_unload_free(struct module
> *mod)
> {
> }
>
> -int ref_module(struct module *a, struct module *b)
> +int ref_module(struct module *a, struct module *b, bool link_flag)
> {
> return strong_try_module_get(b);
> }
> @@ -1407,7 +1420,7 @@ static const struct kernel_symbol
> *resolve_symbol(struct module *mod,
> goto getname;
> }
>
> - err = ref_module(mod, owner);
> + err = ref_module(mod, owner, false);
> if (err) {
> sym = ERR_PTR(err);
> goto getname;
>
Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
On Wed, Sep 11, 2019 at 10:52:03AM +0800, Jason Wang wrote:
> On 2019/9/11 上午9:47, Tiwei Bie wrote:
> > On Tue, Sep 10, 2019 at 04:19:34PM +0800, Jason Wang wrote:
> > > This path introduces a new mdev transport for virtio. This is used to
> > > use kernel virtio driver to drive the mediated device that is capable
> > > of populating virtqueue directly.
> > >
> > > A new virtio-mdev driver will be registered to the mdev bus, when a
> > > new virtio-mdev device is probed, it will register the device with
> > > mdev based config ops. This means, unlike the exist hardware
> > > transport, this is a software transport between mdev driver and mdev
> > > device. The transport was implemented through:
> > >
> > > - configuration access was implemented through parent_ops->read()/write()
> > > - vq/config callback was implemented through parent_ops->ioctl()
> > >
> > > This transport is derived from virtio MMIO protocol and was wrote for
> > > kernel driver. But for the transport itself, but the design goal is to
> > > be generic enough to support userspace driver (this part will be added
> > > in the future).
> > >
> > > Note:
> > > - current mdev assume all the parameter of parent_ops was from
> > >userspace. This prevents us from implementing the kernel mdev
> > >driver. For a quick POC, this patch just abuse those parameter and
> > >assume the mdev device implementation will treat them as kernel
> > >pointer. This should be addressed in the formal series by extending
> > >mdev_parent_ops.
> > > - for a quick POC, I just drive the transport from MMIO, I'm pretty
> > >there's lot of optimization space for this.
> > >
> > > Signed-off-by: Jason Wang
> > > ---
> > > drivers/vfio/mdev/Kconfig| 7 +
> > > drivers/vfio/mdev/Makefile | 1 +
> > > drivers/vfio/mdev/virtio_mdev.c | 500 +++
> > > include/uapi/linux/virtio_mdev.h | 131
> > > 4 files changed, 639 insertions(+)
> > > create mode 100644 drivers/vfio/mdev/virtio_mdev.c
> > > create mode 100644 include/uapi/linux/virtio_mdev.h
> > >
> > [...]
> > > diff --git a/include/uapi/linux/virtio_mdev.h
> > > b/include/uapi/linux/virtio_mdev.h
> > > new file mode 100644
> > > index ..8040de6b960a
> > > --- /dev/null
> > > +++ b/include/uapi/linux/virtio_mdev.h
> > > @@ -0,0 +1,131 @@
> > > +/*
> > > + * Virtio mediated device driver
> > > + *
> > > + * Copyright 2019, Red Hat Corp.
> > > + *
> > > + * Based on Virtio MMIO driver by ARM Ltd, copyright ARM Ltd. 2011
> > > + *
> > > + * This header is BSD licensed so anyone can use the definitions to
> > > implement
> > > + * compatible drivers/servers.
> > > + *
> > > + * Redistribution and use in source and binary forms, with or without
> > > + * modification, are permitted provided that the following conditions
> > > + * are met:
> > > + * 1. Redistributions of source code must retain the above copyright
> > > + *notice, this list of conditions and the following disclaimer.
> > > + * 2. Redistributions in binary form must reproduce the above copyright
> > > + *notice, this list of conditions and the following disclaimer in the
> > > + *documentation and/or other materials provided with the
> > > distribution.
> > > + * 3. Neither the name of IBM nor the names of its contributors
> > > + *may be used to endorse or promote products derived from this
> > > software
> > > + *without specific prior written permission.
> > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > > ``AS IS'' AND
> > > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> > > PURPOSE
> > > + * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
> > > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > > CONSEQUENTIAL
> > > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
> > > GOODS
> > > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> > > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> > > STRICT
> > > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
> > > WAY
> > > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> > > + * SUCH DAMAGE.
> > > + */
> > > +#ifndef _LINUX_VIRTIO_MDEV_H
> > > +#define _LINUX_VIRTIO_MDEV_H
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +/*
> > > + * Ioctls
> > > + */
> > > +
> > > +struct virtio_mdev_callback {
> > > + irqreturn_t (*callback)(void *);
> > > + void *private;
> > > +};
> > > +
> > > +#define VIRTIO_MDEV 0xAF
> > > +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
> > > + struct virtio_mdev_callback)
> > > +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
> > > + struct virt
[PATCH] mm/memblock: fix typo in memblock doc
elaboarte -> elaborate architecure -> architecture compltes -> completes Signed-off-by: Cao jin --- mm/memblock.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/memblock.c b/mm/memblock.c index 7d4f61ae666a..0d0f92003d18 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -83,16 +83,16 @@ * Note, that both API variants use implict assumptions about allowed * memory ranges and the fallback methods. Consult the documentation * of :c:func:`memblock_alloc_internal` and - * :c:func:`memblock_alloc_range_nid` functions for more elaboarte + * :c:func:`memblock_alloc_range_nid` functions for more elaborate * description. * * As the system boot progresses, the architecture specific * :c:func:`mem_init` function frees all the memory to the buddy page * allocator. * - * Unless an architecure enables %CONFIG_ARCH_KEEP_MEMBLOCK, the + * Unless an architecture enables %CONFIG_ARCH_KEEP_MEMBLOCK, the * memblock data structures will be discarded after the system - * initialization compltes. + * initialization completes. */ #ifndef CONFIG_NEED_MULTIPLE_NODES -- 2.21.0
Re: [vfs] 8bb3c61baf: vm-scalability.median -23.7% regression
On Mon, 9 Sep 2019, Hugh Dickins wrote:
> On Mon, 9 Sep 2019, Al Viro wrote:
> >
> > Anyway, see vfs.git#uncertain.shmem for what I've got with those folded in.
> > Do you see any problems with that one? That's the last 5 commits in
> > there...
>
> It's mostly fine, I've no problem with going your way instead of what
> we had in mmotm; but I have seen some problems with it, and had been
> intending to send you a fixup patch tonight (shmem_reconfigure() missing
> unlock on error is the main problem, but there are other fixes needed).
>
> But I'm growing tired. I've a feeling my "swap" of the mpols, instead
> of immediate mpol_put(), was necessary to protect against a race with
> shmem_get_sbmpol(), but I'm not clear-headed enough to trust myself on
> that now. And I've a mystery to solve, that shmem_reconfigure() gets
> stuck into showing the wrong error message.
On my "swap" for the mpol_put(): no, the race against shmem_get_sbmpol()
is safe enough without that, and what you have matches what was always
done before. I rather like my "swap", which the previous double-free had
led me to, but it's fine if you prefer the ordinary way. I was probably
coming down from some over-exposure to iput() under spinlock, but there's
no such complications here.
>
> Tomorrow
>
> Oh, and my first attempt to build and boot that series over 5.3-rc5
> wouldn't boot. Luckily there was a tell-tale "i915" in the stacktrace,
> which reminded me of the drivers/gpu/drm/i915/gem/i915_gemfs.c fix
> we discussed earlier in the cycle. That is of course in linux-next
> by now, but I wonder if your branch ought to contain a duplicate of
> that fix, so that people with i915 doing bisections on 5.4-rc do not
> fall into an unbootable hole between vfs and gpu merges.
Below are the fixups I arrived at last night (I've not rechecked your
tree today, to see if you made any changes since). But they're not
enough: I now understand why shmem_reconfigure() got stuck showing
the wrong error message, but I'll have to leave it to you to decide
what to do about it, because I don't know whether it's just a mistake,
or different filesystem types have different needs there.
My /etc/fstab has a line in for one of my test mounts:
tmpfs/tlo tmpfs size=4G 0 0
and that "size=4G" is what causes the problem: because each time
shmem_parse_options(fc, data) is called for a remount, data (that is,
options) points to a string starting with "size=4G,", followed by
what's actually been asked for in the remount options.
So if I try
mount -o remount,size=0 /tlo
that succeeds, setting the filesystem size to 0 meaning unlimited.
So if then as a test I try
mount -o remount,size=1M /tlo
that correctly fails with "Cannot retroactively limit size".
But then when I try
mount -o remount,nr_inodes=0 /tlo
I again get "Cannot retroactively limit size",
when it should have succeeded (again, 0 here meaning unlimited).
That's because the options in shmem_parse_options() are
"size=4G,nr_inodes=0", which indeed looks like an attempt to
retroactively limit size; but the user never asked "size=4G" there.
I think this problem, and some of what's fixed below, predate your
rework, and would equally affect the version in mmotm: I just didn't
discover these issues when I was testing that before.
Hugh
--- aviro/mm/shmem.c2019-09-09 14:10:34.379832855 -0700
+++ hughd/mm/shmem.c2019-09-09 23:29:28.467037895 -0700
@@ -3456,7 +3456,7 @@ static int shmem_parse_one(struct fs_con
ctx->huge = result.uint_32;
if (ctx->huge != SHMEM_HUGE_NEVER &&
!(IS_ENABLED(CONFIG_TRANSPARENT_HUGE_PAGECACHE) &&
- has_transparent_hugepage()))
+ has_transparent_hugepage()))
goto unsupported_parameter;
ctx->seen |= SHMEM_SEEN_HUGE;
break;
@@ -3532,26 +3532,26 @@ static int shmem_reconfigure(struct fs_c
spin_lock(&sbinfo->stat_lock);
inodes = sbinfo->max_inodes - sbinfo->free_inodes;
- if (ctx->seen & SHMEM_SEEN_BLOCKS) {
+ if ((ctx->seen & SHMEM_SEEN_BLOCKS) && ctx->blocks) {
+ if (!sbinfo->max_blocks) {
+ err = "Cannot retroactively limit size";
+ goto out;
+ }
if (percpu_counter_compare(&sbinfo->used_blocks,
ctx->blocks) > 0) {
err = "Too small a size for current use";
goto out;
}
- if (ctx->blocks && !sbinfo->max_blocks) {
- err = "Cannot retroactively limit nr_blocks";
+ }
+ if ((ctx->seen & SHMEM_SEEN_INODES) && ctx->inodes) {
+ if (!sbinfo->max_inodes) {
+ err = "Cannot retroactively limit inodes";
goto out;
}
- }
- if (ctx->seen & SHME
Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
On 2019/9/11 上午9:47, Tiwei Bie wrote:
On Tue, Sep 10, 2019 at 04:19:34PM +0800, Jason Wang wrote:
This path introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means, unlike the exist hardware
transport, this is a software transport between mdev driver and mdev
device. The transport was implemented through:
- configuration access was implemented through parent_ops->read()/write()
- vq/config callback was implemented through parent_ops->ioctl()
This transport is derived from virtio MMIO protocol and was wrote for
kernel driver. But for the transport itself, but the design goal is to
be generic enough to support userspace driver (this part will be added
in the future).
Note:
- current mdev assume all the parameter of parent_ops was from
userspace. This prevents us from implementing the kernel mdev
driver. For a quick POC, this patch just abuse those parameter and
assume the mdev device implementation will treat them as kernel
pointer. This should be addressed in the formal series by extending
mdev_parent_ops.
- for a quick POC, I just drive the transport from MMIO, I'm pretty
there's lot of optimization space for this.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/Kconfig| 7 +
drivers/vfio/mdev/Makefile | 1 +
drivers/vfio/mdev/virtio_mdev.c | 500 +++
include/uapi/linux/virtio_mdev.h | 131
4 files changed, 639 insertions(+)
create mode 100644 drivers/vfio/mdev/virtio_mdev.c
create mode 100644 include/uapi/linux/virtio_mdev.h
[...]
diff --git a/include/uapi/linux/virtio_mdev.h b/include/uapi/linux/virtio_mdev.h
new file mode 100644
index ..8040de6b960a
--- /dev/null
+++ b/include/uapi/linux/virtio_mdev.h
@@ -0,0 +1,131 @@
+/*
+ * Virtio mediated device driver
+ *
+ * Copyright 2019, Red Hat Corp.
+ *
+ * Based on Virtio MMIO driver by ARM Ltd, copyright ARM Ltd. 2011
+ *
+ * This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+#ifndef _LINUX_VIRTIO_MDEV_H
+#define _LINUX_VIRTIO_MDEV_H
+
+#include
+#include
+#include
+
+/*
+ * Ioctls
+ */
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *);
+ void *private;
+};
+
+#define VIRTIO_MDEV 0xAF
+#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
+struct virtio_mdev_callback)
+#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
+ struct virtio_mdev_callback)
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+
+/*
+ * Control registers
+ */
+
+/* Magic value ("virt" string) - Read Only */
+#define VIRTIO_MDEV_MAGIC_VALUE0x000
+
+/* Virtio device version - Read Only */
+#define VIRTIO_MDEV_VERSION0x004
+
+/* Virtio device ID - Read Only */
+#define VIRTIO_MDEV_DEVICE_ID 0x008
+
+/* Virtio vendor ID - Read Only */
+#define VIRTIO_MDEV_VENDOR_ID 0x00c
+
+/* Bitmask of the features supported by the device (host)
+ * (32 bits per set) - Read Only */
+#define VIRTIO_MDEV_DEVICE_FEATURES0x010
+
+/* Device (host) features set selector - Write Only */
+#define VIRTIO_MDE
[PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna
The RTL8723BU suffers the wifi disconnection problem while bluetooth
device connected. While wifi is doing tx/rx, the bluetooth will scan
without results. This is due to the wifi and bluetooth share the same
single antenna for RF communication and they need to have a mechanism
to collaborate.
BT information is provided via the packet sent from co-processor to
host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h
dose not really handle it. And there's no bluetooth coexistence
mechanism to deal with it.
This commit adds a workqueue to set the tdma configurations and
coefficient table per the parsed bluetooth link status and given
wifi connection state. The tdma/coef table comes from the vendor
driver code of the RTL8192EU and RTL8723BU. However, this commit is
only for single antenna scenario which RTL8192EU is default dual
antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h
is only for 8723b and 8192e so the mechanism is expected to work
on both chips with single antenna. Note RTL8192EU dual antenna is
not supported.
Signed-off-by: Chris Chiu
---
Notes:
v2:
- Add helper functions to replace bunch of tdma settings
- Reformat some lines to meet kernel coding style
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 37 +++
.../realtek/rtl8xxxu/rtl8xxxu_8723b.c | 2 -
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 262 +-
3 files changed, 294 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 582c2a346cec..22e95b11bfbb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1220,6 +1220,37 @@ enum ratr_table_mode_new {
RATEID_IDX_BGN_3SS = 14,
};
+#define BT_INFO_8723B_1ANT_B_FTP BIT(7)
+#define BT_INFO_8723B_1ANT_B_A2DP BIT(6)
+#define BT_INFO_8723B_1ANT_B_HID BIT(5)
+#define BT_INFO_8723B_1ANT_B_SCO_BUSY BIT(4)
+#define BT_INFO_8723B_1ANT_B_ACL_BUSY BIT(3)
+#define BT_INFO_8723B_1ANT_B_INQ_PAGE BIT(2)
+#define BT_INFO_8723B_1ANT_B_SCO_ESCO BIT(1)
+#define BT_INFO_8723B_1ANT_B_CONNECTIONBIT(0)
+
+enum _BT_8723B_1ANT_STATUS {
+ BT_8723B_1ANT_STATUS_NON_CONNECTED_IDLE = 0x0,
+ BT_8723B_1ANT_STATUS_CONNECTED_IDLE = 0x1,
+ BT_8723B_1ANT_STATUS_INQ_PAGE= 0x2,
+ BT_8723B_1ANT_STATUS_ACL_BUSY= 0x3,
+ BT_8723B_1ANT_STATUS_SCO_BUSY= 0x4,
+ BT_8723B_1ANT_STATUS_ACL_SCO_BUSY= 0x5,
+ BT_8723B_1ANT_STATUS_MAX
+};
+
+struct rtl8xxxu_btcoex {
+ u8 bt_status;
+ boolbt_busy;
+ boolhas_sco;
+ boolhas_a2dp;
+ boolhas_hid;
+ boolhas_pan;
+ boolhid_only;
+ boola2dp_only;
+ boolc2h_bt_inquiry;
+};
+
#define RTL8XXXU_RATR_STA_INIT 0
#define RTL8XXXU_RATR_STA_HIGH 1
#define RTL8XXXU_RATR_STA_MID 2
@@ -1340,6 +1371,10 @@ struct rtl8xxxu_priv {
*/
struct ieee80211_vif *vif;
struct delayed_work ra_watchdog;
+ struct work_struct c2hcmd_work;
+ struct sk_buff_head c2hcmd_queue;
+ spinlock_t c2hcmd_lock;
+ struct rtl8xxxu_btcoex bt_coex;
};
struct rtl8xxxu_rx_urb {
@@ -1486,6 +1521,8 @@ void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw,
struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
bool short_preamble, bool ampdu_enable,
u32 rts_rate);
+void rtl8723bu_set_ps_tdma(struct rtl8xxxu_priv *priv,
+ u8 arg1, u8 arg2, u8 arg3, u8 arg4, u8 arg5);
extern struct rtl8xxxu_fileops rtl8192cu_fops;
extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index ceffe05bd65b..9ba661b3d767 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1580,9 +1580,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
/*
* Software control, antenna at WiFi side
*/
-#ifdef NEED_PS_TDMA
rtl8723bu_set_ps_tdma(priv, 0x08, 0x00, 0x00, 0x00, 0x00);
-#endif
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE1, 0x);
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE2, 0x);
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a6f358b9e447..e4c1b08c8070 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3820,9 +3820,8 @@ void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv)
rtl8xxxu_write8(priv, REG_RSV_CTRL, 0x0e);
}
-#ifdef NEED_PS_TDM
Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara wrote: > > On Wed, 28 Aug 2019 03:02:58 + > Peng Fan wrote: > > Hi, > > sorry for the late reply, eventually managed to have a closer look on this. > > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > > actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 > > + > > 1 file changed, 125 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > > + call) instruction to trigger a mailbox-connected activity in firmware, > > + executing on the very same core as the caller. By nature this operation > > + is synchronous and this mailbox provides no way for asynchronous messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > received > > + message to the mailbox framework, so a synchronous communication can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well as the > > + return value is defined by their users and is not subject to this > > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses shared > > memory > > + to transfer commands and parameters, and a mailbox to trigger a function > > + call. This allows SoCs without a separate management processor (or when > > + such a processor is not available or used) to use this standardized > > + interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware interface. > > + Upon receiving an SMC using one of the described SMC function > > identifiers, > > + the firmware is expected to trigger some mailbox connected functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The supported > > + identifiers are passed from consumers, or listed in the the arm,func-ids > > + properties as described below. The firmware can return one value in > > + the first SMC result register, it is expected to be an error value, > > + which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as long > > as > > + a firmware component running in EL3 or EL2 is handling these calls. > > + > > +properties: > > + compatible: > > +const: arm,smc-mbox > > + > > + "#mbox-cells": > > +const: 1 > > + > > + arm,num-chans: > > +description: The number of channels supported. > > +items: > > + minimum: 1 > > + maximum: 4096 # Should be enough? > > This maximum sounds rather arbitrary. Why do we need one? In the driver this > just allocates more memory, so why not just impose no artificial limit at all? > This will be gone, once the driver is converted to 1channel per controller. > Actually, do we need this property at all? Can't we just rely on the size of > arm,func-ids to determine this (using of_property_count_elems_of_size() in > the driver)? Having both sounds redundant and brings up the question what to > do if they don't match. > > > + > > + method: > > +- enum: > > +- smc > > +- hvc > > + > > + transports: > > +- enum: > > +- mem > > +- reg > > Shouldn't there be a description on what both mean, exactly? > For instance I would expect a list of registers to be shown for the "reg" > case, and be it by referring to the ARM SMCCC. > > Also looking at the driver this brings up more questions: > - Which memory does mem refer to? If this is really the means of transport, > it should be referenced in this *controller* node and populated by the > driver. Looking at the example below and the driver code, it actually isn't > used that way, instead the memory is used and controlled by the mailbox > *client*. > - W
[PATCH 2/2] ASoC: fsl_mqs: Add MQS component driver
MQS (medium quality sound), is used to generate medium quality
audio via a standard digital output pin. It can be used to
connect stereo speakers or headphones simply via power amplifier
stages without an additional DAC chip. It only accepts 2-channel,
LSB-valid 16bit, MSB shift-out first, frame sync asserting with
the first bit of the frame, data shifted with the posedge of
bit clock, 44.1 kHz or 48 kHz signals from SAI1 in left justified
format; and it provides the SNR target as no more than 20dB for
the signals below 10 kHz. The signals above 10 kHz will have
worse THD+N values.
MQS provides only simple audio reproduction. No internal pop,
click or distortion artifact reduction methods are provided.
The MQS receives the audio data from the SAI1 Tx section.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig | 10 ++
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/fsl_mqs.c | 336
3 files changed, 348 insertions(+)
create mode 100644 sound/soc/fsl/fsl_mqs.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index aa99c008a925..65e8cd4be930 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -25,6 +25,16 @@ config SND_SOC_FSL_SAI
This option is only useful for out-of-tree drivers since
in-tree drivers select it automatically.
+config SND_SOC_FSL_MQS
+ tristate "Medium Quality Sound (MQS) module support"
+ depends on SND_SOC_FSL_SAI
+ select REGMAP_MMIO
+ help
+ Say Y if you want to add Medium Quality Sound (MQS)
+ support for the Freescale CPUs.
+ This option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
+
config SND_SOC_FSL_AUDMIX
tristate "Audio Mixer (AUDMIX) module support"
select REGMAP_MMIO
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index c0dd04422fe9..8cde88c72d93 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -23,6 +23,7 @@ snd-soc-fsl-esai-objs := fsl_esai.o
snd-soc-fsl-micfil-objs := fsl_micfil.o
snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
+snd-soc-fsl-mqs-objs := fsl_mqs.o
obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
@@ -33,6 +34,7 @@ obj-$(CONFIG_SND_SOC_FSL_SPDIF) += snd-soc-fsl-spdif.o
obj-$(CONFIG_SND_SOC_FSL_ESAI) += snd-soc-fsl-esai.o
obj-$(CONFIG_SND_SOC_FSL_MICFIL) += snd-soc-fsl-micfil.o
obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o
+obj-$(CONFIG_SND_SOC_FSL_MQS) += snd-soc-fsl-mqs.o
obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
# MPC5200 Platform Support
diff --git a/sound/soc/fsl/fsl_mqs.c b/sound/soc/fsl/fsl_mqs.c
new file mode 100644
index ..d164f5da3460
--- /dev/null
+++ b/sound/soc/fsl/fsl_mqs.c
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ALSA SoC IMX MQS driver
+ *
+ * Copyright (C) 2014-2019 Freescale Semiconductor, Inc.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_MQS_CTRL 0x00
+
+#define MQS_EN_MASK(0x1 << 28)
+#define MQS_EN_SHIFT (28)
+#define MQS_SW_RST_MASK(0x1 << 24)
+#define MQS_SW_RST_SHIFT (24)
+#define MQS_OVERSAMPLE_MASK(0x1 << 20)
+#define MQS_OVERSAMPLE_SHIFT (20)
+#define MQS_CLK_DIV_MASK (0xFF << 0)
+#define MQS_CLK_DIV_SHIFT (0)
+
+/* codec private data */
+struct fsl_mqs {
+ struct regmap *regmap;
+ struct clk *mclk;
+ struct clk *ipg;
+
+ unsigned int reg_iomuxc_gpr2;
+ unsigned int reg_mqs_ctrl;
+ bool use_gpr;
+};
+
+#define FSL_MQS_RATES (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000)
+#define FSL_MQS_FORMATSSNDRV_PCM_FMTBIT_S16_LE
+
+static int fsl_mqs_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+ struct snd_soc_component *component = dai->component;
+ struct fsl_mqs *mqs_priv = snd_soc_component_get_drvdata(component);
+ unsigned long mclk_rate;
+ int div, res;
+ int bclk, lrclk;
+
+ mclk_rate = clk_get_rate(mqs_priv->mclk);
+ bclk = snd_soc_params_to_bclk(params);
+ lrclk = params_rate(params);
+
+ /*
+* mclk_rate / (oversample(32,64) * FS * 2 * divider ) = repeat_rate;
+* if repeat_rate is 8, mqs can achieve better quality.
+* oversample rate is fix to 32 currently.
+*/
+ div = mclk_rate / (32 * lrclk * 2 * 8);
+ res = mclk_rate % (32 * lrclk * 2 * 8);
+
+ if (res == 0 && div > 0 && div <= 256) {
+ if (mqs_priv->use_gpr) {
+ regmap_update_bits(mqs_priv->regmap, IOMUXC_GPR2,
+
[PATCH 1/2] ASoC: fsl_mqs: add DT binding documentation
Add the DT binding documentation for NXP MQS driver
Signed-off-by: Shengjiu Wang
---
.../devicetree/bindings/sound/fsl,mqs.txt | 20 +++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,mqs.txt
diff --git a/Documentation/devicetree/bindings/sound/fsl,mqs.txt
b/Documentation/devicetree/bindings/sound/fsl,mqs.txt
new file mode 100644
index ..a1dbe181204a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,mqs.txt
@@ -0,0 +1,20 @@
+fsl,mqs audio CODEC
+
+Required properties:
+
+ - compatible : Must contain one of "fsl,imx6sx-mqs", "fsl,codec-mqs"
+ "fsl,imx8qm-mqs", "fsl,imx8qxp-mqs".
+ - clocks : A list of phandles + clock-specifiers, one for each entry in
+clock-names
+ - clock-names : Must contain "mclk"
+ - gpr : The gpr node.
+
+Example:
+
+mqs: mqs {
+ compatible = "fsl,imx6sx-mqs";
+ gpr = <&gpr>;
+ clocks = <&clks IMX6SX_CLK_SAI1>;
+ clock-names = "mclk";
+ status = "disabled";
+};
--
2.21.0
[PATCH V2 net-next 5/7] net: hns3: modify some logs format
From: Guangbin Huang The pfc_en and pfc_map need to be displayed in hexadecimal notation, printing dma address should use %pad, and the end of printed string needs to be add "\n". This patch modifies them. Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 7 +-- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 2 +- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c index 5cf4c1e..28961a6 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c @@ -166,6 +166,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const char *cmd_buf) struct hns3_enet_ring *ring; u32 tx_index, rx_index; u32 q_num, value; + dma_addr_t addr; int cnt; cnt = sscanf(&cmd_buf[8], "%u %u", &q_num, &tx_index); @@ -194,8 +195,9 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const char *cmd_buf) } tx_desc = &ring->desc[tx_index]; + addr = le64_to_cpu(tx_desc->addr); dev_info(dev, "TX Queue Num: %u, BD Index: %u\n", q_num, tx_index); - dev_info(dev, "(TX)addr: 0x%llx\n", tx_desc->addr); + dev_info(dev, "(TX)addr: %pad\n", &addr); dev_info(dev, "(TX)vlan_tag: %u\n", tx_desc->tx.vlan_tag); dev_info(dev, "(TX)send_size: %u\n", tx_desc->tx.send_size); dev_info(dev, "(TX)vlan_tso: %u\n", tx_desc->tx.type_cs_vlan_tso); @@ -217,8 +219,9 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const char *cmd_buf) rx_index = (cnt == 1) ? value : tx_index; rx_desc = &ring->desc[rx_index]; + addr = le64_to_cpu(rx_desc->addr); dev_info(dev, "RX Queue Num: %u, BD Index: %u\n", q_num, rx_index); - dev_info(dev, "(RX)addr: 0x%llx\n", rx_desc->addr); + dev_info(dev, "(RX)addr: %pad\n", &addr); dev_info(dev, "(RX)l234_info: %u\n", rx_desc->rx.l234_info); dev_info(dev, "(RX)pkt_len: %u\n", rx_desc->rx.pkt_len); dev_info(dev, "(RX)size: %u\n", rx_desc->rx.size); diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c index 816f920..c063301 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c @@ -342,7 +342,7 @@ static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc) hdev->tm_info.pfc_en = pfc->pfc_en; netif_dbg(h, drv, netdev, - "set pfc: pfc_en=%u, pfc_map=%u, num_tc=%u\n", + "set pfc: pfc_en=%x, pfc_map=%x, num_tc=%u\n", pfc->pfc_en, pfc_map, hdev->tm_info.num_tc); hclge_tm_pfc_info_update(hdev); diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c index 8d4dc1b..bc5bad3 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -3751,7 +3751,7 @@ static void hclge_reset_event(struct pci_dev *pdev, struct hnae3_handle *handle) else if (time_after(jiffies, (hdev->last_reset_time + 4 * 5 * HZ))) hdev->reset_level = HNAE3_FUNC_RESET; - dev_info(&hdev->pdev->dev, "received reset event , reset type is %d", + dev_info(&hdev->pdev->dev, "received reset event, reset type is %d\n", hdev->reset_level); /* request reset & schedule reset task */ -- 2.7.4
[PATCH V2 net-next 3/7] net: hns3: fix shaper parameter algorithm
From: Yonglong Liu
Currently when hns3 driver configures the tm shaper to limit
bandwidth below 20Mbit using the parameters calculated by
hclge_shaper_para_calc(), the actual bandwidth limited by tm
hardware module is not accurate enough, for example, 1.28 Mbit
when the user is configuring 1 Mbit.
This patch adjusts the ir_calc to be closer to ir, and
always calculate the ir_b parameter when user is configuring
a small bandwidth. Also, removes an unnecessary parenthesis
when calculating denominator.
Fixes: 848440544b41 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3
driver")
Signed-off-by: Yonglong Liu
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index e829101..9f0e35f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -81,16 +81,13 @@ static int hclge_shaper_para_calc(u32 ir, u8 shaper_level,
return 0;
} else if (ir_calc > ir) {
/* Increasing the denominator to select ir_s value */
- while (ir_calc > ir) {
+ while (ir_calc >= ir && ir) {
ir_s_calc++;
ir_calc = DIVISOR_IR_B_126 / (tick * (1 << ir_s_calc));
}
- if (ir_calc == ir)
- *ir_b = 126;
- else
- *ir_b = (ir * tick * (1 << ir_s_calc) +
-(DIVISOR_CLK >> 1)) / DIVISOR_CLK;
+ *ir_b = (ir * tick * (1 << ir_s_calc) + (DIVISOR_CLK >> 1)) /
+ DIVISOR_CLK;
} else {
/* Increasing the numerator to select ir_u value */
u32 numerator;
@@ -104,7 +101,7 @@ static int hclge_shaper_para_calc(u32 ir, u8 shaper_level,
if (ir_calc == ir) {
*ir_b = 126;
} else {
- u32 denominator = (DIVISOR_CLK * (1 << --ir_u_calc));
+ u32 denominator = DIVISOR_CLK * (1 << --ir_u_calc);
*ir_b = (ir * tick + (denominator >> 1)) / denominator;
}
}
--
2.7.4
[PATCH V2 net-next 1/7] net: hns3: add ethtool_ops.set_channels support for HNS3 VF driver
From: Guangbin Huang
This patch adds ethtool_ops.set_channels support for HNS3 VF driver,
and updates related TQP information and RSS information, to support
modification of VF TQP number, and uses current rss_size instead of
max_rss_size to initialize RSS.
Also, fixes a format error in hclgevf_get_rss().
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 +
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 83 --
2 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index aa692b1..f5a681d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -1397,6 +1397,7 @@ static const struct ethtool_ops hns3vf_ethtool_ops = {
.set_rxfh = hns3_set_rss,
.get_link_ksettings = hns3_get_link_ksettings,
.get_channels = hns3_get_channels,
+ .set_channels = hns3_set_channels,
.get_coalesce = hns3_get_coalesce,
.set_coalesce = hns3_set_coalesce,
.get_regs_len = hns3_get_regs_len,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 594cae8..e3090b3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -743,7 +743,7 @@ static int hclgevf_get_rss(struct hnae3_handle *handle, u32
*indir, u8 *key,
}
static int hclgevf_set_rss(struct hnae3_handle *handle, const u32 *indir,
- const u8 *key, const u8 hfunc)
+ const u8 *key, const u8 hfunc)
{
struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
struct hclgevf_rss_cfg *rss_cfg = &hdev->rss_cfg;
@@ -2060,9 +2060,10 @@ static int hclgevf_config_gro(struct hclgevf_dev *hdev,
bool en)
static int hclgevf_rss_init_hw(struct hclgevf_dev *hdev)
{
struct hclgevf_rss_cfg *rss_cfg = &hdev->rss_cfg;
- int i, ret;
+ int ret;
+ u32 i;
- rss_cfg->rss_size = hdev->rss_size_max;
+ rss_cfg->rss_size = hdev->nic.kinfo.rss_size;
if (hdev->pdev->revision >= 0x21) {
rss_cfg->hash_algo = HCLGEVF_RSS_HASH_ALGO_SIMPLE;
@@ -2099,13 +2100,13 @@ static int hclgevf_rss_init_hw(struct hclgevf_dev *hdev)
/* Initialize RSS indirect table */
for (i = 0; i < HCLGEVF_RSS_IND_TBL_SIZE; i++)
- rss_cfg->rss_indirection_tbl[i] = i % hdev->rss_size_max;
+ rss_cfg->rss_indirection_tbl[i] = i % rss_cfg->rss_size;
ret = hclgevf_set_rss_indir_table(hdev);
if (ret)
return ret;
- return hclgevf_set_rss_tc_mode(hdev, hdev->rss_size_max);
+ return hclgevf_set_rss_tc_mode(hdev, rss_cfg->rss_size);
}
static int hclgevf_init_vlan_config(struct hclgevf_dev *hdev)
@@ -2835,6 +2836,77 @@ static void hclgevf_get_tqps_and_rss_info(struct
hnae3_handle *handle,
*max_rss_size = hdev->rss_size_max;
}
+static void hclgevf_update_rss_size(struct hnae3_handle *handle,
+ u32 new_tqps_num)
+{
+ struct hnae3_knic_private_info *kinfo = &handle->kinfo;
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ u16 max_rss_size;
+
+ kinfo->req_rss_size = new_tqps_num;
+
+ max_rss_size = min_t(u16, hdev->rss_size_max,
+hdev->num_tqps / kinfo->num_tc);
+
+ /* Use the user's configuration when it is not larger than
+* max_rss_size, otherwise, use the maximum specification value.
+*/
+ if (kinfo->req_rss_size != kinfo->rss_size && kinfo->req_rss_size &&
+ kinfo->req_rss_size <= max_rss_size)
+ kinfo->rss_size = kinfo->req_rss_size;
+ else if (kinfo->rss_size > max_rss_size ||
+(!kinfo->req_rss_size && kinfo->rss_size < max_rss_size))
+ kinfo->rss_size = max_rss_size;
+
+ kinfo->num_tqps = kinfo->num_tc * kinfo->rss_size;
+}
+
+static int hclgevf_set_channels(struct hnae3_handle *handle, u32 new_tqps_num,
+ bool rxfh_configured)
+{
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ struct hnae3_knic_private_info *kinfo = &handle->kinfo;
+ u16 cur_rss_size = kinfo->rss_size;
+ u16 cur_tqps = kinfo->num_tqps;
+ u32 *rss_indir;
+ unsigned int i;
+ int ret;
+
+ hclgevf_update_rss_size(handle, new_tqps_num);
+
+ ret = hclgevf_set_rss_tc_mode(hdev, kinfo->rss_size);
+ if (ret)
+ return ret;
+
+ /* RSS indirection table has been configuared by user */
+ if (rxfh_configured)
+ goto out;
+
+ /* Reinitializes the rss indirect table according to the new RSS size */
+ rss_indir = kcalloc(HCL
[PATCH V2 net-next 7/7] net: hns3: add some DFX info for reset issue
This patch adds more information for reset DFX. Also, adds some
cleanups to reset info, move reset_fail_cnt into struct
hclge_rst_stats, and modifies some print formats.
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 32 --
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 11
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 2 +-
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index 6dcce48..d0128d7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -931,22 +931,36 @@ static void hclge_dbg_fd_tcam(struct hclge_dev *hdev)
static void hclge_dbg_dump_rst_info(struct hclge_dev *hdev)
{
- dev_info(&hdev->pdev->dev, "PF reset count: %d\n",
+ dev_info(&hdev->pdev->dev, "PF reset count: %u\n",
hdev->rst_stats.pf_rst_cnt);
- dev_info(&hdev->pdev->dev, "FLR reset count: %d\n",
+ dev_info(&hdev->pdev->dev, "FLR reset count: %u\n",
hdev->rst_stats.flr_rst_cnt);
- dev_info(&hdev->pdev->dev, "CORE reset count: %d\n",
-hdev->rst_stats.core_rst_cnt);
- dev_info(&hdev->pdev->dev, "GLOBAL reset count: %d\n",
+ dev_info(&hdev->pdev->dev, "GLOBAL reset count: %u\n",
hdev->rst_stats.global_rst_cnt);
- dev_info(&hdev->pdev->dev, "IMP reset count: %d\n",
+ dev_info(&hdev->pdev->dev, "IMP reset count: %u\n",
hdev->rst_stats.imp_rst_cnt);
- dev_info(&hdev->pdev->dev, "reset done count: %d\n",
+ dev_info(&hdev->pdev->dev, "reset done count: %u\n",
hdev->rst_stats.reset_done_cnt);
- dev_info(&hdev->pdev->dev, "HW reset done count: %d\n",
+ dev_info(&hdev->pdev->dev, "HW reset done count: %u\n",
hdev->rst_stats.hw_reset_done_cnt);
- dev_info(&hdev->pdev->dev, "reset count: %d\n",
+ dev_info(&hdev->pdev->dev, "reset count: %u\n",
hdev->rst_stats.reset_cnt);
+ dev_info(&hdev->pdev->dev, "reset count: %u\n",
+hdev->rst_stats.reset_cnt);
+ dev_info(&hdev->pdev->dev, "reset fail count: %u\n",
+hdev->rst_stats.reset_fail_cnt);
+ dev_info(&hdev->pdev->dev, "vector0 interrupt enable status: 0x%x\n",
+hclge_read_dev(&hdev->hw, HCLGE_MISC_VECTOR_REG_BASE));
+ dev_info(&hdev->pdev->dev, "reset interrupt source: 0x%x\n",
+hclge_read_dev(&hdev->hw, HCLGE_MISC_RESET_STS_REG));
+ dev_info(&hdev->pdev->dev, "reset interrupt status: 0x%x\n",
+hclge_read_dev(&hdev->hw, HCLGE_MISC_VECTOR_INT_STS));
+ dev_info(&hdev->pdev->dev, "hardware reset status: 0x%x\n",
+hclge_read_dev(&hdev->hw, HCLGE_GLOBAL_RESET_REG));
+ dev_info(&hdev->pdev->dev, "handshake status: 0x%x\n",
+hclge_read_dev(&hdev->hw, HCLGE_NIC_CSQ_DEPTH_REG));
+ dev_info(&hdev->pdev->dev, "function reset status: 0x%x\n",
+hclge_read_dev(&hdev->hw, HCLGE_FUN_RST_ING));
}
static void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index bc5bad3..fd7f943 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3547,12 +3547,12 @@ static bool hclge_reset_err_handle(struct hclge_dev
*hdev)
"reset failed because new reset interrupt\n");
hclge_clear_reset_cause(hdev);
return false;
- } else if (hdev->reset_fail_cnt < MAX_RESET_FAIL_CNT) {
- hdev->reset_fail_cnt++;
+ } else if (hdev->rst_stats.reset_fail_cnt < MAX_RESET_FAIL_CNT) {
+ hdev->rst_stats.reset_fail_cnt++;
set_bit(hdev->reset_type, &hdev->reset_pending);
dev_info(&hdev->pdev->dev,
"re-schedule reset task(%d)\n",
-hdev->reset_fail_cnt);
+hdev->rst_stats.reset_fail_cnt);
return true;
}
@@ -3679,7 +3679,8 @@ static void hclge_reset(struct hclge_dev *hdev)
/* ignore RoCE notify error if it fails HCLGE_RESET_MAX_FAIL_CNT - 1
* times
*/
- if (ret && hdev->reset_fail_cnt < HCLGE_RESET_MAX_FAIL_CNT - 1)
+ if (ret &&
+ hdev->rst_stats.reset_fail_cnt < HCLGE_RESET_MAX_FAIL_CNT - 1)
goto err_reset;
rtnl_lock();
@@ -3695,7 +3696,7 @@ static void hclge_reset(struct hclge_dev *hdev)
goto err_reset;
hdev->last_reset_time = jiffies;
- hdev->reset_fail_cnt = 0;
+ hdev->rst_stats.reset_fail_cnt = 0;
hdev->rs
[PATCH V2 net-next 0/7] net: hns3: add a feature & bugfixes & cleanups
This patch-set includes a VF feature, bugfixes and cleanups for the HNS3 ethernet controller driver. [patch 01/07] adds ethtool_ops.set_channels support for HNS3 VF driver [patch 02/07] adds a recovery for setting channel fail. [patch 03/07] fixes an error related to shaper parameter algorithm. [patch 04/07] fixes an error related to ksetting. [patch 05/07] adds cleanups for some log pinting. [patch 06/07] adds a NULL pointer check before function calling. [patch 07/07] adds some debugging information for reset issue. Change log: V1->V2: fixes comment from David Miller. Guangbin Huang (4): net: hns3: add ethtool_ops.set_channels support for HNS3 VF driver net: hns3: fix port setting handle for fibre port net: hns3: modify some logs format net: hns3: check NULL pointer before use Huazhong Tan (1): net: hns3: add some DFX info for reset issue Peng Li (1): net: hns3: revert to old channel when setting new channel num fail Yonglong Liu (1): net: hns3: fix shaper parameter algorithm drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 7 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 54 ++ drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 16 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 2 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 32 ++--- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 13 ++-- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 2 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 11 ++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 83 -- 9 files changed, 174 insertions(+), 46 deletions(-) -- 2.7.4
[PATCH V2 net-next 4/7] net: hns3: fix port setting handle for fibre port
From: Guangbin Huang
For hardware doesn't support use specified speed and duplex
to negotiate, it's unnecessary to check and modify the port
speed and duplex for fibre port when autoneg is on.
Fixes: 22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre
port")
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index f5a681d..680c350 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -726,6 +726,12 @@ static int hns3_check_ksettings_param(const struct
net_device *netdev,
u8 duplex;
int ret;
+ /* hw doesn't support use specified speed and duplex to negotiate,
+* unnecessary to check them when autoneg on.
+*/
+ if (cmd->base.autoneg)
+ return 0;
+
if (ops->get_ksettings_an_result) {
ops->get_ksettings_an_result(handle, &autoneg, &speed, &duplex);
if (cmd->base.autoneg == autoneg && cmd->base.speed == speed &&
@@ -787,6 +793,15 @@ static int hns3_set_link_ksettings(struct net_device
*netdev,
return ret;
}
+ /* hw doesn't support use specified speed and duplex to negotiate,
+* ignore them when autoneg on.
+*/
+ if (cmd->base.autoneg) {
+ netdev_info(netdev,
+ "autoneg is on, ignore the speed and duplex\n");
+ return 0;
+ }
+
if (ops->cfg_mac_speed_dup_h)
ret = ops->cfg_mac_speed_dup_h(handle, cmd->base.speed,
cmd->base.duplex);
--
2.7.4
[PATCH V2 net-next 2/7] net: hns3: revert to old channel when setting new channel num fail
From: Peng Li
After setting new channel num, it needs free old ring memory and
allocate new ring memory. If there is no enough memory and allocate
new ring memory fail, the ring may initialize fail. To make sure
the network interface can work normally, driver should revert the
channel to the old configuration.
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 51 ++---
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 9f3f8e3..8dbaf36 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -4410,6 +4410,30 @@ static int hns3_reset_notify(struct hnae3_handle *handle,
return ret;
}
+static int hns3_change_channels(struct hnae3_handle *handle, u32 new_tqp_num,
+ bool rxfh_configured)
+{
+ int ret;
+
+ ret = handle->ae_algo->ops->set_channels(handle, new_tqp_num,
+rxfh_configured);
+ if (ret) {
+ dev_err(&handle->pdev->dev,
+ "Change tqp num(%u) fail.\n", new_tqp_num);
+ return ret;
+ }
+
+ ret = hns3_reset_notify(handle, HNAE3_INIT_CLIENT);
+ if (ret)
+ return ret;
+
+ ret = hns3_reset_notify(handle, HNAE3_UP_CLIENT);
+ if (ret)
+ hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT);
+
+ return ret;
+}
+
int hns3_set_channels(struct net_device *netdev,
struct ethtool_channels *ch)
{
@@ -4450,24 +4474,23 @@ int hns3_set_channels(struct net_device *netdev,
return ret;
org_tqp_num = h->kinfo.num_tqps;
- ret = h->ae_algo->ops->set_channels(h, new_tqp_num, rxfh_configured);
+ ret = hns3_change_channels(h, new_tqp_num, rxfh_configured);
if (ret) {
- ret = h->ae_algo->ops->set_channels(h, org_tqp_num,
- rxfh_configured);
- if (ret) {
- /* If revert to old tqp failed, fatal error occurred */
- dev_err(&netdev->dev,
- "Revert to old tqp num fail, ret=%d", ret);
- return ret;
+ int ret1;
+
+ netdev_warn(netdev,
+ "Change channels fail, revert to old value\n");
+ ret1 = hns3_change_channels(h, org_tqp_num, rxfh_configured);
+ if (ret1) {
+ netdev_err(netdev,
+ "revert to old channel fail\n");
+ return ret1;
}
- dev_info(&netdev->dev,
-"Change tqp num fail, Revert to old tqp num");
- }
- ret = hns3_reset_notify(h, HNAE3_INIT_CLIENT);
- if (ret)
+
return ret;
+ }
- return hns3_reset_notify(h, HNAE3_UP_CLIENT);
+ return 0;
}
static const struct hns3_hw_error_info hns3_hw_err[] = {
--
2.7.4
[PATCH V2 net-next 6/7] net: hns3: check NULL pointer before use
From: Guangbin Huang
This patch checks ops->set_default_reset_request whether is NULL
before using it in function hns3_slot_reset.
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 8dbaf36..616cad0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2006,7 +2006,8 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev
*pdev)
ops = ae_dev->ops;
/* request the reset */
- if (ops->reset_event && ops->get_reset_level) {
+ if (ops->reset_event && ops->get_reset_level &&
+ ops->set_default_reset_request) {
if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
&ae_dev->hw_err_reset_req);
--
2.7.4
Re: mtd raw nand denali.c broken for Intel/Altera Cyclone V
Hi Dinh, On Wed, Sep 11, 2019 at 12:22 AM Dinh Nguyen wrote: > > > > On 9/10/19 8:48 AM, Tim Sander wrote: > > Hi > > > > I have noticed that my SPF records where not in place after moving the > > server, > > so it seems the mail didn't go to the mailing list. Hopefully that's fixed > > now. > > > > Am Dienstag, 10. September 2019, 09:16:37 CEST schrieb Masahiro Yamada: > >> On Fri, Sep 6, 2019 at 9:39 PM Tim Sander wrote: > >>> Hi > >>> > >>> I have noticed that there multiple breakages piling up for the denali nand > >>> driver on the Intel/Altera Cyclone V. Unfortunately i had no time to track > >>> the mainline kernel closely. So the breakage seems to pile up. I am a > >>> little disapointed that Intel is not on the lookout that the kernel works > >>> on the chips they are selling. I was really happy about the state of the > >>> platform before concerning mainline support. > >>> > >>> The failure starts with kernel 4.19 or stable kernel release 4.18.19. The > >>> commit is ba4a1b62a2d742df9e9c607ac53b3bf33496508f. > >> > >> Just for clarification, this corresponds to > >> 0d55c668b218a1db68b5044bce4de74e1bd0f0c8 upstream. > >> > >>> The problem here is that > >>> our platform works with a zero in the SPARE_AREA_SKIP_BYTES register. > >> > >> Please clarify the scope of "our platform". > >> (Only you, or your company, or every individual using this chip?) > > The company i work for uses this chip as a base for multiple products. > > > >> First, SPARE_AREA_SKIP_BYTES is not the property of the hardware. > >> Rather, it is about the OOB layout, in other words, this parameter > >> is defined by software. > >> > >> For example, U-Boot supports the Denali NAND driver. > >> The SPARE_AREA_SKIP_BYTES is a user-configurable parameter: > >> https://github.com/u-boot/u-boot/blob/v2019.10-rc3/drivers/mtd/nand/raw/Kcon > >> fig#L112 > >> > >> > >> Your platform works with a zero in the SPARE_AREA_SKIP_BYTES register > >> because the NAND chip on the board was initialized with a zero > >> set to the SPARE_AREA_SKIP_BYTES register. > >> > >> If the NAND chip had been initialized with 8 > >> set to the SPARE_AREA_SKIP_BYTES register, it would have > >> been working with 8 to the SPARE_AREA_SKIP_BYTES. > >> > >> The Boot ROM is the only (semi-)software that is unconfigurable by users, > >> so the value of SPARE_AREA_SKIP_BYTES should be aligned with > >> the boot ROM. > >> I recommend you to check the spec of the boot ROM. > > We boot from NOR flash. That's why i didn't see a problem booting probably. > > > >> (The maintainer of the platform, Dihn is CC'ed, > >> so I hope he will jump in) > > Yes i hope so too. > > > > I don't have access to a NAND device at the moment. I'll try to find one > and debug. > > Dinh Dinh, Do you have answers for the following questions? - Does the SOCFPGA boot ROM support the NAND boot mode? - If so, which value does it use for SPARE_AREA_SKIP_BYTES? -- Best Regards Masahiro Yamada
Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
On 2019/9/10 下午9:52, Michael S. Tsirkin wrote:
On Tue, Sep 10, 2019 at 09:13:02PM +0800, Jason Wang wrote:
On 2019/9/10 下午6:01, Michael S. Tsirkin wrote:
+#ifndef _LINUX_VIRTIO_MDEV_H
+#define _LINUX_VIRTIO_MDEV_H
+
+#include
+#include
+#include
+
+/*
+ * Ioctls
+ */
Pls add a bit more content here. It's redundant to state these
are ioctls. Much better to document what does each one do.
Ok.
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *);
+ void *private;
+};
+
+#define VIRTIO_MDEV 0xAF
+#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
+struct virtio_mdev_callback)
+#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
+ struct virtio_mdev_callback)
Function pointer in an ioctl parameter? How does this ever make sense?
I admit this is hacky (casting).
And can't we use a couple of registers for this, and avoid ioctls?
Yes, how about something like interrupt numbers for each virtqueue and
config?
Should we just reuse VIRTIO_PCI_COMMON_Q_XXX then?
You mean something like VIRTIO_PCI_COMMON_Q_MSIX? Then it becomes a PCI
transport in fact. And using either MSIX or irq number is actually
another layer of indirection. So I think we can just write callback
function and parameter through registers.
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+
+/*
+ * Control registers
+ */
+
+/* Magic value ("virt" string) - Read Only */
+#define VIRTIO_MDEV_MAGIC_VALUE0x000
+
+/* Virtio device version - Read Only */
+#define VIRTIO_MDEV_VERSION0x004
+
+/* Virtio device ID - Read Only */
+#define VIRTIO_MDEV_DEVICE_ID 0x008
+
+/* Virtio vendor ID - Read Only */
+#define VIRTIO_MDEV_VENDOR_ID 0x00c
+
+/* Bitmask of the features supported by the device (host)
+ * (32 bits per set) - Read Only */
+#define VIRTIO_MDEV_DEVICE_FEATURES0x010
+
+/* Device (host) features set selector - Write Only */
+#define VIRTIO_MDEV_DEVICE_FEATURES_SEL0x014
+
+/* Bitmask of features activated by the driver (guest)
+ * (32 bits per set) - Write Only */
+#define VIRTIO_MDEV_DRIVER_FEATURES0x020
+
+/* Activated features set selector - Write Only */
+#define VIRTIO_MDEV_DRIVER_FEATURES_SEL0x024
+
+/* Queue selector - Write Only */
+#define VIRTIO_MDEV_QUEUE_SEL 0x030
+
+/* Maximum size of the currently selected queue - Read Only */
+#define VIRTIO_MDEV_QUEUE_NUM_MAX 0x034
+
+/* Queue size for the currently selected queue - Write Only */
+#define VIRTIO_MDEV_QUEUE_NUM 0x038
+
+/* Ready bit for the currently selected queue - Read Write */
+#define VIRTIO_MDEV_QUEUE_READY0x044
Is this same as started?
Do you mean "status"?
I really meant "enabled", didn't remember the correct name.
As in: VIRTIO_PCI_COMMON_Q_ENABLE
Yes, it's the same.
Thanks
+
+/* Alignment of virtqueue - Read Only */
+#define VIRTIO_MDEV_QUEUE_ALIGN0x048
+
+/* Queue notifier - Write Only */
+#define VIRTIO_MDEV_QUEUE_NOTIFY 0x050
+
+/* Device status register - Read Write */
+#define VIRTIO_MDEV_STATUS 0x060
+
+/* Selected queue's Descriptor Table address, 64 bits in two halves */
+#define VIRTIO_MDEV_QUEUE_DESC_LOW 0x080
+#define VIRTIO_MDEV_QUEUE_DESC_HIGH0x084
+
+/* Selected queue's Available Ring address, 64 bits in two halves */
+#define VIRTIO_MDEV_QUEUE_AVAIL_LOW0x090
+#define VIRTIO_MDEV_QUEUE_AVAIL_HIGH 0x094
+
+/* Selected queue's Used Ring address, 64 bits in two halves */
+#define VIRTIO_MDEV_QUEUE_USED_LOW 0x0a0
+#define VIRTIO_MDEV_QUEUE_USED_HIGH0x0a4
+
+/* Configuration atomicity value */
+#define VIRTIO_MDEV_CONFIG_GENERATION 0x0fc
+
+/* The config space is defined by each driver as
+ * the per-driver configuration space - Read Write */
+#define VIRTIO_MDEV_CONFIG 0x100
Mixing device and generic config space is what virtio pci did,
caused lots of problems with extensions.
It would be better to reserve much more space.
I see, will do this.
Thanks
+
+#endif
+
+
+/* Ready bit for the currently selected queue - Read Write */
--
2.19.1
Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
On Mon, Sep 9, 2019 at 8:32 AM Andre Przywara wrote:
>
> On Fri, 30 Aug 2019 03:12:29 -0500
> Jassi Brar wrote:
>
> Hi,
>
> > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan wrote:
> > >
> > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for
> > > > the ARM
> > > > SMC/HVC mailbox
> > > >
> > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > > > for the ARM SMC/HVC mailbox
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan wrote:
> > > > > >
> > > > > > > > > +examples:
> > > > > > > > > + - |
> > > > > > > > > +sram@91 {
> > > > > > > > > + compatible = "mmio-sram";
> > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <1>;
> > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > +
> > > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x0 0x200>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x200 0x200>;
> > > > > > > > > + };
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +firmware {
> > > > > > > > > + smc_mbox: mailbox {
> > > > > > > > > +#mbox-cells = <1>;
> > > > > > > > > +compatible = "arm,smc-mbox";
> > > > > > > > > +method = "smc";
> > > > > > > > > +arm,num-chans = <0x2>;
> > > > > > > > > +transports = "mem";
> > > > > > > > > +/* Optional */
> > > > > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > > > > >
> > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e,
> > > > > > > > there can only be one instance running platform wide. Right?
> > > > > > >
> > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > For virtualization case, there could be dedicated channel for
> > > > > > > each VM.
> > > > > > >
> > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > > > > both be active at the same time, right?
> > > > >
> > > > > If I get your point correctly,
> > > > > On UP, both could not be active. On SMP, tx/rx could be both active,
> > > > > anyway this depends on secure firmware and Linux firmware design.
> > > > >
> > > > > Do you have any suggestions about arm,func-ids here?
> > > > >
> > > > I was thinking if this is just an instruction, why can't each channel be
> > > > represented as a controller, i.e, have exactly one func-id per
> > > > controller node.
> > > > Define as many controllers as you need channels ?
> > >
> > > I am ok, this could make driver code simpler. Something as below?
> > >
> > > smc_tx_mbox: tx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc2fe>;
> > > };
> > >
> > > smc_rx_mbox: rx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc2ff>;
> > > };
> > >
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi";
> > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
> > > mbox-names = "tx", "rx";
> > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> > > };
> > > };
> > >
> > Yes, the channel part is good.
> > But I am not convinced by the need to have SCMI specific "transport" mode.
>
> Why would this be SCMI specific and what is the problem with having this
> property?
> By the very nature of the SMC/HVC call you would expect to also pass
> parameters in registers.
> However this limits the amount of data you can push, so the option of
> reverting to a
> memory based payload sounds very reasonable.
>
Of course, it is very legit to pass data via mem and many platforms do
that. But as you note in your next post, the 'transport' doesn't seem
necessary doing what it does in the driver.
Cheers!
Re: [PATCH 00/13] hisi_sas: Some misc patches
John, > This patchset includes support for some more minor features, a bit of > tidying, and a few patches to make the driver a bit more robust. Applied to 5.4/scsi-queue, thanks. -- Martin K. Petersen Oracle Linux Engineering
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, 30 Aug 2019 03:12:29 -0500
> Jassi Brar wrote:
>
> Hi,
>
> > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan wrote:
> > >
> > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > for the ARM SMC/HVC mailbox
> > > >
> > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding
> > > > > > doc for the ARM SMC/HVC mailbox
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan
> wrote:
> > > > > >
> > > > > > > > > +examples:
> > > > > > > > > + - |
> > > > > > > > > +sram@91 {
> > > > > > > > > + compatible = "mmio-sram";
> > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <1>;
> > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > +
> > > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x0 0x200>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x200 0x200>;
> > > > > > > > > + };
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +firmware {
> > > > > > > > > + smc_mbox: mailbox {
> > > > > > > > > +#mbox-cells = <1>;
> > > > > > > > > +compatible = "arm,smc-mbox";
> > > > > > > > > +method = "smc";
> > > > > > > > > +arm,num-chans = <0x2>;
> > > > > > > > > +transports = "mem";
> > > > > > > > > +/* Optional */
> > > > > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > > > > >
> > > > > > > > SMC/HVC is synchronously(block) running in "secure mode",
> > > > > > > > i.e, there can only be one instance running platform wide.
> > > > > > > > Right?
> > > > > > >
> > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > For virtualization case, there could be dedicated channel for each
> VM.
> > > > > > >
> > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above,
> > > > > > can't both be active at the same time, right?
> > > > >
> > > > > If I get your point correctly,
> > > > > On UP, both could not be active. On SMP, tx/rx could be both
> > > > > active, anyway this depends on secure firmware and Linux firmware
> design.
> > > > >
> > > > > Do you have any suggestions about arm,func-ids here?
> > > > >
> > > > I was thinking if this is just an instruction, why can't each
> > > > channel be represented as a controller, i.e, have exactly one func-id
> > > > per
> controller node.
> > > > Define as many controllers as you need channels ?
> > >
> > > I am ok, this could make driver code simpler. Something as below?
> > >
> > > smc_tx_mbox: tx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc2fe>;
> > > };
> > >
> > > smc_rx_mbox: rx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc2ff>;
> > > };
> > >
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi";
> > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
> > > mbox-names = "tx", "rx";
> > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> > > };
> > > };
> > >
> > Yes, the channel part is good.
> > But I am not convinced by the need to have SCMI specific "transport" mode.
>
> Why would this be SCMI specific and what is the problem with having this
> property?
> By the very nature of the SMC/HVC call you would expect to also pass
> parameters in registers. However this limits the amount of data you can push,
> so the option of reverting to a memory based payload sounds very
> reasonable.
> On the other hand *just* using memory complicates things, in case you have a
> very simple protocol. You would need a memory region shared between
> firmware and OS, which is not always easily possible on every platform. Also
> this doesn't scale easily with multiple mailboxes and channels. Passing
> parameters via registers is also naturally consistent, as there would be no
> races and no need for synchronisation with other cores or other users of the
> mailbox.
>
> So I clearly see the benefit of specifying *both* ways of payload transport.
> Given that this driver should be protocol agnostic, it makes a lot of sense to
> introduce both methods *now*, so in the future users can just use the register
> method, without extending the binding in a incompatible way later (earlier
> kernels would have the driver, but wou
[PATCH 1/2] arm64: dts: imx8mm: Remove incorrect fallback compatible for ocotp
Compared to i.MX7D, i.MX8MM has different ocotp layout, so it should
NOT use "fsl,imx7d-ocotp" as ocotp's fallback compatible, remove it.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 5f9d0da..7c4dcce 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -426,7 +426,7 @@
};
ocotp: ocotp-ctrl@3035 {
- compatible = "fsl,imx8mm-ocotp",
"fsl,imx7d-ocotp", "syscon";
+ compatible = "fsl,imx8mm-ocotp", "syscon";
reg = <0x3035 0x1>;
clocks = <&clk IMX8MM_CLK_OCOTP_ROOT>;
/* For nvmem subnodes */
--
2.7.4
[PATCH 2/2] arm64: dts: imx8mn: Use "fsl,imx8mm-ocotp" as ocotp's fallback compatible
Use "fsl,imx8mm-ocotp" as i.MX8MN ocotp's fallback compatible instead
of "fsl,imx7d-ocotp" to support SoC UID read, as i.MX8MN reuses
i.MX8MM's SoC ID driver.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index e4efe8d..6cb6c9c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -337,7 +337,7 @@
};
ocotp: ocotp-ctrl@3035 {
- compatible = "fsl,imx8mn-ocotp",
"fsl,imx7d-ocotp", "syscon";
+ compatible = "fsl,imx8mn-ocotp",
"fsl,imx8mm-ocotp", "syscon";
reg = <0x3035 0x1>;
clocks = <&clk IMX8MN_CLK_OCOTP_ROOT>;
#address-cells = <1>;
--
2.7.4
Re: [PATCH v2] scsi: virtio_scsi: unplug LUNs when events missed
Matt, > The event handler calls scsi_scan_host() when events are missed, which > will hotplug new LUNs. However, this function won't remove any > unplugged LUNs. The result is that hotunplug doesn't work properly > when the number of unplugged LUNs exceeds the event queue size > (currently 8). > > Scan existing LUNs when events are missed to check if they are still > present. If not, remove them. Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
NOTICE!!
Receive $39 Million for our mutual benefit.
Re: [PATCH net-next 1/7] net: hns3: add ethtool_ops.set_channels support for HNS3 VF driver
On 2019/9/11 1:25, David Miller wrote:
From: Huazhong Tan
Date: Tue, 10 Sep 2019 16:58:22 +0800
+ /* Set to user value, no larger than max_rss_size. */
+ if (kinfo->req_rss_size != kinfo->rss_size && kinfo->req_rss_size &&
+ kinfo->req_rss_size <= max_rss_size) {
+ dev_info(&hdev->pdev->dev, "rss changes from %u to %u\n",
+kinfo->rss_size, kinfo->req_rss_size);
+ kinfo->rss_size = kinfo->req_rss_size;
Please do not emit kernel log messages for normal operations.
Will remove this log in V2.
Thanks.
.
RE: [EXT] Re: [V4 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs
Hi Vinod,
I send those series patchs(V5) on June 25, 2019. I haven't received any
comments yet. Their current state
is "Not Applicable", so please let me know what I need to do next.
Thanks very much for your comments.
Patch link:
https://patchwork.kernel.org/patch/11015035/
https://patchwork.kernel.org/patch/11015033/
Best Regards,
Peng
>-Original Message-
>From: Vinod Koul
>Sent: 2019年6月25日 0:46
>To: Peng Ma
>Cc: dan.j.willi...@intel.com; Leo Li ;
>linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org
>Subject: [EXT] Re: [V4 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA
>controller driver for Layerscape SoCs
>
>Caution: EXT Email
>
>On 13-06-19, 10:13, Peng Ma wrote:
>> DPPA2(Data Path Acceleration Architecture 2) qDMA supports channel
>> virtualization by allowing DMA
>
>typo virtualization
>
>> jobs to be enqueued into different frame queues.
>> Core can initiate a DMA transaction by preparing a frame
>> descriptor(FD) for each DMA job and enqueuing this job to a frame
>> queue. through a hardware portal. The qDMA
> ^^^
>why this full stop?
>
>> +static struct dpaa2_qdma_comp *
>> +dpaa2_qdma_request_desc(struct dpaa2_qdma_chan *dpaa2_chan) {
>> + struct dpaa2_qdma_comp *comp_temp = NULL;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&dpaa2_chan->queue_lock, flags);
>> + if (list_empty(&dpaa2_chan->comp_free)) {
>> + spin_unlock_irqrestore(&dpaa2_chan->queue_lock, flags);
>> + comp_temp = kzalloc(sizeof(*comp_temp), GFP_NOWAIT);
>> + if (!comp_temp)
>> + goto err;
>> + comp_temp->fd_virt_addr =
>> + dma_pool_alloc(dpaa2_chan->fd_pool,
>GFP_NOWAIT,
>> +&comp_temp->fd_bus_addr);
>> + if (!comp_temp->fd_virt_addr)
>> + goto err_comp;
>> +
>> + comp_temp->fl_virt_addr =
>> + dma_pool_alloc(dpaa2_chan->fl_pool,
>GFP_NOWAIT,
>> +&comp_temp->fl_bus_addr);
>> + if (!comp_temp->fl_virt_addr)
>> + goto err_fd_virt;
>> +
>> + comp_temp->desc_virt_addr =
>> + dma_pool_alloc(dpaa2_chan->sdd_pool,
>GFP_NOWAIT,
>> +
>&comp_temp->desc_bus_addr);
>> + if (!comp_temp->desc_virt_addr)
>> + goto err_fl_virt;
>> +
>> + comp_temp->qchan = dpaa2_chan;
>> + return comp_temp;
>> + }
>> +
>> + comp_temp = list_first_entry(&dpaa2_chan->comp_free,
>> + struct dpaa2_qdma_comp, list);
>> + list_del(&comp_temp->list);
>> + spin_unlock_irqrestore(&dpaa2_chan->queue_lock, flags);
>> +
>> + comp_temp->qchan = dpaa2_chan;
>> +
>> + return comp_temp;
>> +
>> +err_fl_virt:
>
>no err logs? how will you know what went wrong?
>
>> +static enum
>> +dma_status dpaa2_qdma_tx_status(struct dma_chan *chan,
>> + dma_cookie_t cookie,
>> + struct dma_tx_state *txstate) {
>> + return dma_cookie_status(chan, cookie, txstate);
>
>why not set dma_cookie_status as this callback?
>
>> +static int __cold dpaa2_qdma_setup(struct fsl_mc_device *ls_dev) {
>> + struct dpaa2_qdma_priv_per_prio *ppriv;
>> + struct device *dev = &ls_dev->dev;
>> + struct dpaa2_qdma_priv *priv;
>> + u8 prio_def = DPDMAI_PRIO_NUM;
>> + int err = -EINVAL;
>> + int i;
>> +
>> + priv = dev_get_drvdata(dev);
>> +
>> + priv->dev = dev;
>> + priv->dpqdma_id = ls_dev->obj_desc.id;
>> +
>> + /* Get the handle for the DPDMAI this interface is associate with */
>> + err = dpdmai_open(priv->mc_io, 0, priv->dpqdma_id,
>&ls_dev->mc_handle);
>> + if (err) {
>> + dev_err(dev, "dpdmai_open() failed\n");
>> + return err;
>> + }
>> + dev_info(dev, "Opened dpdmai object successfully\n");
>
>this is noise in kernel, consider debug level
>
>> +static int __cold dpaa2_dpdmai_bind(struct dpaa2_qdma_priv *priv) {
>> + int err;
>> + int i, num;
>> + struct device *dev = priv->dev;
>> + struct dpaa2_qdma_priv_per_prio *ppriv;
>> + struct dpdmai_rx_queue_cfg rx_queue_cfg;
>> + struct fsl_mc_device *ls_dev = to_fsl_mc_device(dev);
>
>the order is reverse than used in other fn, please stick to one style!
>--
>~Vinod
Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
On Tue, Sep 10, 2019 at 04:19:34PM +0800, Jason Wang wrote:
> This path introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
>
> A new virtio-mdev driver will be registered to the mdev bus, when a
> new virtio-mdev device is probed, it will register the device with
> mdev based config ops. This means, unlike the exist hardware
> transport, this is a software transport between mdev driver and mdev
> device. The transport was implemented through:
>
> - configuration access was implemented through parent_ops->read()/write()
> - vq/config callback was implemented through parent_ops->ioctl()
>
> This transport is derived from virtio MMIO protocol and was wrote for
> kernel driver. But for the transport itself, but the design goal is to
> be generic enough to support userspace driver (this part will be added
> in the future).
>
> Note:
> - current mdev assume all the parameter of parent_ops was from
> userspace. This prevents us from implementing the kernel mdev
> driver. For a quick POC, this patch just abuse those parameter and
> assume the mdev device implementation will treat them as kernel
> pointer. This should be addressed in the formal series by extending
> mdev_parent_ops.
> - for a quick POC, I just drive the transport from MMIO, I'm pretty
> there's lot of optimization space for this.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/Kconfig| 7 +
> drivers/vfio/mdev/Makefile | 1 +
> drivers/vfio/mdev/virtio_mdev.c | 500 +++
> include/uapi/linux/virtio_mdev.h | 131
> 4 files changed, 639 insertions(+)
> create mode 100644 drivers/vfio/mdev/virtio_mdev.c
> create mode 100644 include/uapi/linux/virtio_mdev.h
>
[...]
> diff --git a/include/uapi/linux/virtio_mdev.h
> b/include/uapi/linux/virtio_mdev.h
> new file mode 100644
> index ..8040de6b960a
> --- /dev/null
> +++ b/include/uapi/linux/virtio_mdev.h
> @@ -0,0 +1,131 @@
> +/*
> + * Virtio mediated device driver
> + *
> + * Copyright 2019, Red Hat Corp.
> + *
> + * Based on Virtio MMIO driver by ARM Ltd, copyright ARM Ltd. 2011
> + *
> + * This header is BSD licensed so anyone can use the definitions to implement
> + * compatible drivers/servers.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + * 3. Neither the name of IBM nor the names of its contributors
> + *may be used to endorse or promote products derived from this software
> + *without specific prior written permission.
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
> IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +#ifndef _LINUX_VIRTIO_MDEV_H
> +#define _LINUX_VIRTIO_MDEV_H
> +
> +#include
> +#include
> +#include
> +
> +/*
> + * Ioctls
> + */
> +
> +struct virtio_mdev_callback {
> + irqreturn_t (*callback)(void *);
> + void *private;
> +};
> +
> +#define VIRTIO_MDEV 0xAF
> +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
> + struct virtio_mdev_callback)
> +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
> + struct virtio_mdev_callback)
> +
> +#define VIRTIO_MDEV_DEVICE_API_STRING"virtio-mdev"
> +
> +/*
> + * Control registers
> + */
> +
> +/* Magic value ("virt" string) - Read Only */
> +#define VIRTIO_MDEV_MAGIC_VALUE 0x000
> +
> +/* Virtio device version - Read Only */
> +#define VIRTIO_MDEV_VERSION 0x004
> +
> +/* Virtio device ID - Read Only */
> +#define VIRTIO_MDEV_DEVICE_ID0x008
> +
> +/* Virtio vendor ID - Read Only */
> +#define VIRTIO_MDEV_VENDOR_ID0x00c
> +
> +/* Bitmask of the features su
Re: [PATCH 0/3] rtlwifi: use generic rtl_evm_db_to_percentage
On Tue, 2019-09-10 at 21:04 +0200, Michael Straube wrote:
> Functions _rtl92{c,d}_evm_db_to_percentage are functionally identical
> to the generic version rtl_evm_db_to percentage. This series converts
> rtl8192ce, rtl8192cu and rtl8192de to use the generic version.
>
> Michael Straube (3):
> rtlwifi: rtl8192ce: replace _rtl92c_evm_db_to_percentage with generic
> version
> rtlwifi: rtl8192cu: replace _rtl92c_evm_db_to_percentage with generic
> version
> rtlwifi: rtl8192de: replace _rtl92d_evm_db_to_percentage with generic
> version
>
> .../wireless/realtek/rtlwifi/rtl8192ce/trx.c | 23 +--
> .../wireless/realtek/rtlwifi/rtl8192cu/mac.c | 18 +--
> .../wireless/realtek/rtlwifi/rtl8192de/trx.c | 18 ++-
> 3 files changed, 4 insertions(+), 55 deletions(-)
>
I checked the generic version and removed functions, and they are indeed
identical. Thanks for your patches.
Acked-by: Ping-Ke Shih
Re: [PATCH net 1/2] sctp: remove redundant assignment when call sctp_get_port_local
On 2019/9/11 3:22, Dan Carpenter wrote:
> On Tue, Sep 10, 2019 at 09:57:10PM +0300, Dan Carpenter wrote:
>> On Tue, Sep 10, 2019 at 03:13:42PM +0800, Mao Wenan wrote:
>>> There are more parentheses in if clause when call sctp_get_port_local
>>> in sctp_do_bind, and redundant assignment to 'ret'. This patch is to
>>> do cleanup.
>>>
>>> Signed-off-by: Mao Wenan
>>> ---
>>> net/sctp/socket.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>>> index 9d1f83b10c0a..766b68b55ebe 100644
>>> --- a/net/sctp/socket.c
>>> +++ b/net/sctp/socket.c
>>> @@ -399,9 +399,8 @@ static int sctp_do_bind(struct sock *sk, union
>>> sctp_addr *addr, int len)
>>> * detection.
>>> */
>>> addr->v4.sin_port = htons(snum);
>>> - if ((ret = sctp_get_port_local(sk, addr))) {
>>> + if (sctp_get_port_local(sk, addr))
>>> return -EADDRINUSE;
>>
>> sctp_get_port_local() returns a long which is either 0,1 or a pointer
>> casted to long. It's not documented what it means and neither of the
>> callers use the return since commit 62208f12451f ("net: sctp: simplify
>> sctp_get_port").
>
> Actually it was commit 4e54064e0a13 ("sctp: Allow only 1 listening
> socket with SO_REUSEADDR") from 11 years ago. That patch fixed a bug,
> because before the code assumed that a pointer casted to an int was the
> same as a pointer casted to a long.
commit 4e54064e0a13 treated non-zero return value as unexpected, so the current
cleanup is ok?
>
> regards,
> dan carpenter
>
>
> .
>
[PATCH v2 net] net: sonic: replace dev_kfree_skb in sonic_send_packet
sonic_send_packet will be processed in irq or non-irq
context, so it would better use dev_kfree_skb_any
instead of dev_kfree_skb.
Fixes: d9fb9f384292 ("*sonic/natsemi/ns83829: Move the National Semi-conductor
drivers")
Signed-off-by: Mao Wenan
---
v2: change 'none irq' to 'non-irq'.
drivers/net/ethernet/natsemi/sonic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/natsemi/sonic.c
b/drivers/net/ethernet/natsemi/sonic.c
index 18fd62fbfb64..b339125b2f09 100644
--- a/drivers/net/ethernet/natsemi/sonic.c
+++ b/drivers/net/ethernet/natsemi/sonic.c
@@ -233,7 +233,7 @@ static int sonic_send_packet(struct sk_buff *skb, struct
net_device *dev)
laddr = dma_map_single(lp->device, skb->data, length, DMA_TO_DEVICE);
if (!laddr) {
pr_err_ratelimited("%s: failed to map tx DMA buffer.\n",
dev->name);
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
--
2.20.1
Re: [Xen-devel] [PATCH] xen/pci: try to reserve MCFG areas earlier
On 10/09/2019 22:19, Boris Ostrovsky wrote: > On 9/10/19 4:36 PM, Igor Druzhinin wrote: >> On 10/09/2019 18:48, Boris Ostrovsky wrote: >>> On 9/10/19 5:46 AM, Igor Druzhinin wrote: On 10/09/2019 02:47, Boris Ostrovsky wrote: > On 9/9/19 5:48 PM, Igor Druzhinin wrote: >> On 09/09/2019 20:19, Boris Ostrovsky wrote: >> >>> The other question I have is why you think it's worth keeping >>> xen_mcfg_late() as a late initcall. How could MCFG info be updated >>> between acpi_init() and late_initcalls being run? I'd think it can only >>> happen when a new device is hotplugged. >>> >> It was a precaution against setup_mcfg_map() calls that might add new >> areas that are not in MCFG table but for some reason have _CBA method. >> It's obviously a "firmware is broken" scenario so I don't have strong >> feelings to keep it here. Will prefer to remove in v2 if you want. > Isn't setup_mcfg_map() called before the first xen_add_device() which is > where you are calling xen_mcfg_late()? > setup_mcfg_map() calls are done in order of root bus discovery which happens *after* the previous root bus has been enumerated. So the order is: call setup_mcfg_map() for root bus 0, find that pci_mmcfg_late_init() has finished MCFG area registration, perform PCI enumeration of bus 0, call xen_add_device() for every device there, call setup_mcfg_map() for root bus X, etc. >>> Ah, yes. Multiple busses. >>> >>> If that's the case then why don't we need to call xen_mcfg_late() for >>> the first device on each bus? >>> >> Ideally, yes - we'd like to call it for every bus discovered. But boot >> time buses are already in MCFG (otherwise system boot might not simply >> work as Jan pointed out) so it's not strictly required. The only case is >> a potential PCI bus hot-plug but I'm not sure it actually works in >> practice and we certainly didn't support it before. It might be solved >> theoretically by subscribing to acpi_bus_type that is available after >> acpi_init(). > > OK. Then *I think* we can drop late_initcall() but I would really like > to hear when others think. > Another thing that I implied by "not supporting" but want to explicitly call out is that currently Xen will refuse reserving any MCFG area unless it actually existed in MCFG table at boot. I don't clearly understand reasoning behind it but it might be worth relaxing at least size matching restriction on Xen side now with this change. Igor
Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
Cc-ing Ted, Arnd, Greg
On (09/10/19 11:22), Qian Cai wrote:
> [ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
> [ 1078.291350][T43784]__lock_acquire+0x5c8/0xbb0
> [ 1078.296394][T43784]lock_acquire+0x154/0x428
> [ 1078.301266][T43784]_raw_spin_lock_irqsave+0x80/0xa0
> [ 1078.306831][T43784]tty_port_tty_get+0x28/0x68
> [ 1078.311873][T43784]tty_port_default_wakeup+0x20/0x40
> [ 1078.317523][T43784]tty_port_tty_wakeup+0x38/0x48
> [ 1078.322827][T43784]uart_write_wakeup+0x2c/0x50
> [ 1078.327956][T43784]pl011_tx_chars+0x240/0x260
> [ 1078.332999][T43784]pl011_start_tx+0x24/0xa8
> [ 1078.337868][T43784]__uart_start+0x90/0xa0
> [ 1078.342563][T43784]uart_write+0x15c/0x2c8
> [ 1078.347261][T43784]do_output_char+0x1c8/0x2b0
> [ 1078.352304][T43784]n_tty_write+0x300/0x668
> [ 1078.357087][T43784]tty_write+0x2e8/0x430
> [ 1078.361696][T43784]redirected_tty_write+0xcc/0xe8
> [ 1078.367086][T43784]do_iter_write+0x228/0x270
> [ 1078.372041][T43784]vfs_writev+0x10c/0x1c8
> [ 1078.376735][T43784]do_writev+0xdc/0x180
> [ 1078.381257][T43784]__arm64_sys_writev+0x50/0x60
> [ 1078.386476][T43784]el0_svc_handler+0x11c/0x1f0
> [ 1078.391606][T43784]el0_svc+0x8/0xc
> [ 1078.395691][T43784]
uart_port->lock -> tty_port->lock
This thing along is already a bit suspicious. We re-enter tty
here: tty -> uart -> serial -> tty
And we re-enter tty under uart_port->lock.
> [ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
> [ 1078.402561][T43784]__lock_acquire+0x5c8/0xbb0
> [ 1078.407604][T43784]lock_acquire+0x154/0x428
> [ 1078.412474][T43784]_raw_spin_lock+0x68/0x88
> [ 1078.417343][T43784]pl011_console_write+0x2ac/0x318
> [ 1078.422820][T43784]console_unlock+0x3c4/0x898
> [ 1078.427863][T43784]vprintk_emit+0x2d4/0x460
> [ 1078.432732][T43784]vprintk_default+0x48/0x58
> [ 1078.437688][T43784]vprintk_func+0x194/0x250
> [ 1078.442557][T43784]printk+0xbc/0xec
> [ 1078.446732][T43784]register_console+0x4a8/0x580
> [ 1078.451947][T43784]uart_add_one_port+0x748/0x878
> [ 1078.457250][T43784]pl011_register_port+0x98/0x128
> [ 1078.462639][T43784]sbsa_uart_probe+0x398/0x480
> [ 1078.467772][T43784]platform_drv_probe+0x70/0x108
> [ 1078.473075][T43784]really_probe+0x15c/0x5d8
> [ 1078.477944][T43784]driver_probe_device+0x94/0x1d0
> [ 1078.483335][T43784]__device_attach_driver+0x11c/0x1a8
> [ 1078.489072][T43784]bus_for_each_drv+0xf8/0x158
> [ 1078.494201][T43784]__device_attach+0x164/0x240
> [ 1078.499331][T43784]device_initial_probe+0x24/0x30
> [ 1078.504721][T43784]bus_probe_device+0xf0/0x100
> [ 1078.509850][T43784]device_add+0x63c/0x960
> [ 1078.514546][T43784]platform_device_add+0x1ac/0x3b8
> [ 1078.520023][T43784]platform_device_register_full+0x1fc/0x290
> [ 1078.526373][T43784]acpi_create_platform_device.part.0+0x264/0x3a8
> [ 1078.533152][T43784]acpi_create_platform_device+0x68/0x80
> [ 1078.539150][T43784]acpi_default_enumeration+0x34/0x78
> [ 1078.544887][T43784]acpi_bus_attach+0x340/0x3b8
> [ 1078.550015][T43784]acpi_bus_attach+0xf8/0x3b8
> [ 1078.555057][T43784]acpi_bus_attach+0xf8/0x3b8
> [ 1078.560099][T43784]acpi_bus_attach+0xf8/0x3b8
> [ 1078.565142][T43784]acpi_bus_scan+0x9c/0x100
> [ 1078.570015][T43784]acpi_scan_init+0x16c/0x320
> [ 1078.575058][T43784]acpi_init+0x330/0x3b8
> [ 1078.579666][T43784]do_one_initcall+0x158/0x7ec
> [ 1078.584797][T43784]kernel_init_freeable+0x9a8/0xa70
> [ 1078.590360][T43784]kernel_init+0x18/0x138
> [ 1078.595055][T43784]ret_from_fork+0x10/0x1c
>
> [ 1078.599835][T43784] -> #1 (console_owner){-...}:
> [ 1078.606618][T43784]__lock_acquire+0x5c8/0xbb0
> [ 1078.611661][T43784]lock_acquire+0x154/0x428
> [ 1078.616530][T43784]console_unlock+0x298/0x898
> [ 1078.621573][T43784]vprintk_emit+0x2d4/0x460
> [ 1078.626442][T43784]vprintk_default+0x48/0x58
> [ 1078.631398][T43784]vprintk_func+0x194/0x250
> [ 1078.636267][T43784]printk+0xbc/0xec
> [ 1078.640443][T43784]_warn_unseeded_randomness+0xb4/0xd0
> [ 1078.646267][T43784]get_random_u64+0x4c/0x100
> [ 1078.651224][T43784]add_to_free_area_random+0x168/0x1a0
> [ 1078.657047][T43784]free_one_page+0x3dc/0xd08
> [ 1078.662003][T43784]__free_pages_ok+0x490/0xd00
> [ 1078.667132][T43784]__free_pages+0xc4/0x118
> [ 1078.671914][T43784]__free_pages_core+0x2e8/0x428
> [ 1078.677219][T43784]memblock_free_pages+0xa4/0xec
> [ 1078.682522][T43784]memblock_free_all+0x264/0x330
> [ 1078.687825][T43784]mem_init+0x90/0x148
> [ 1078.692259][T43784]
Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
On Tue, Sep 10, 2019 at 7:24 PM Adam Ford wrote: > > On Tue, Sep 10, 2019 at 3:06 PM Adam Ford wrote: > > > > On Tue, Sep 10, 2019 at 2:55 PM H. Nikolaus Schaller > > wrote: > > > > > > Ok, > > > > > > > Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller > > > > : > > > > > > > it, but then I got some nasty errors and crashes. > > > >>> > > > >>> I have done the same but not (yet) seen a crash or error. Maybe you > > > >>> had > > > >>> a typo? > > > >> > > > >> Can you send me an updated patch? I'd like to try to get where you > > > >> are that doesn't crash. > > > > > > > > Yes, as soon as I have access. > > > > > > it turns out that my patch breaks cpufreq completely... > > > So it looks as if *I* have a typo :) > > > > > > Hence I am likely running at constant speed and the > > > VDD1 regulator is fixed a 1.200V. > > > > > > root@letux:~# dmesg|fgrep opp > > > [2.426208] cpu cpu0: opp_parse_supplies: Invalid number of elements > > > in opp-microvolt property (6) with supplies (1) > > > [2.438140] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 > > > root@letux:~# cat /sys/class/regulator/regulator.8/microvolts > > > 120 > > > root@letux:~# > > > > > > The error message looks as if we have to enable multi_regulator. > > > > That will enable both vdd and vbb regulators from what I can tell in the > > driver. > > > > > And that may need to rename cpu0-supply to vdd-supply (unless the > > > names can be configured). > > > > That is consistent with what I found. vdd-supply = <&vcc>; and > > vbb-supply = <&abb_mpu_iva>; > > I put them both under the cpu node. Unfortunately, when I did that, > > my board crashed. > > > > I am thinking it has something to do with the abb_mpu_iva driver > > because until this point, we've always operated at 800MHz or lower > > which all have the same behavior in abb_mpu_iva. > > > > With the patch you posted for the regulator, without the update to > > cpufreq, and with debugging enabled, I received the following in > > dmesg: > > > > [1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing > > 'efuse-address' IO resource > > [1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0 > > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > > [1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=120 ABB=0 > > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > > [1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0 > > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > > [1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1 > > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 > > [1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings: > > Clk_rate=1300, sr2_cnt=0x0032 > > > > Using an unmodified kernel, I changed the device tree to make the abb > regulator power the cpu instead of vcc. After doing so, I was able to > read the microvolt value, and it matched the processor's desired OPP > voltage, and the debug code showed the abb regulator was attempting to > set the various index based on the needed voltage. I think the abb > driver is working correctly. > > I think tomorrow, I will re-apply the patches and tweak it again to > support both vdd and vbb regulators. If it crashes again, I'll look > more closely at the logs to see if I can determine why. I think it's > pretty close. I also need to go back and find the SmartReflex stuff > as well. > Well, I couldn't give it up for the night, so I thought I'd show my data dump [9.807647] [ cut here ] [9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630 dev_pm_opp_set_rate+0x3cc/0x480 [9.821044] Modules linked in: sha256_generic sha256_arm cfg80211 joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+) snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+) twl4030_pwrbutton sn d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004 tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm drm_panel_or ientation_quirks cec [9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5 [9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree) [9.909515] Workqueue: events dbs_work_handler [9.914031] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [9.921813] [] (show_stack) from [] (dump_stack+0xb4/0xd4) [9.929107] [] (dump_stack) from [] (__warn.part.3+0xa8/0xd4) [9.936614] [] (__warn.part.3) from [] (warn_slowpath_null+0x40/0x4c) [9.944854] [] (warn_slowpath_null) from [] (dev_pm_opp_set_rate+0
[PATCH] net: qrtr: fix memort leak in qrtr_tun_write_iter
In qrtr_tun_write_iter the allocated kbuf should be release in case of
error happening.
Signed-off-by: Navid Emamdoost
---
net/qrtr/tun.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/qrtr/tun.c b/net/qrtr/tun.c
index ccff1e544c21..1dba8b92560e 100644
--- a/net/qrtr/tun.c
+++ b/net/qrtr/tun.c
@@ -84,12 +84,18 @@ static ssize_t qrtr_tun_write_iter(struct kiocb *iocb,
struct iov_iter *from)
if (!kbuf)
return -ENOMEM;
- if (!copy_from_iter_full(kbuf, len, from))
+ if (!copy_from_iter_full(kbuf, len, from)) {
+ kfree(kbuf);
return -EFAULT;
+ }
ret = qrtr_endpoint_post(&tun->ep, kbuf, len);
+ if (ret < 0) {
+ kfree(kbuf);
+ return ret;
+ }
- return ret < 0 ? ret : len;
+ return len;
}
static __poll_t qrtr_tun_poll(struct file *filp, poll_table *wait)
--
2.17.1
