Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding

[Johan Hovold]

On Mon, May 07, 2018 at 10:50:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold  [180507 16:36]:
> > On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > > Hi,
> > > 
> > > * Johan Hovold  [180507 03:03]:
> > > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:

> > > > Note that serdev not enabling runtime pm for controllers is roughly
> > > > equivalent to setting the .ignore_children flag, which is what we do for
> > > > i2c and spi controller, and possibly what we want here too.
> > > 
> > > We currently don't idle serdev at all even if not in use. What
> > > I noticed is if I have these in my .config:
> > > 
> > > CONFIG_SERIAL_DEV_BUS=y
> > > CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
> > > 
> > > And no hci_serdev.ko driver loaded, then the 8250 port still stays
> > > active and there are no sysfs entries to idle it.
> > 
> > Sounds like the 8250_omap driver is doing something funky. Why would
> > there not be any sysfs attributes to control runtime pm?
> 
> I don't know, they are there for the ports that don't have any
> serdev device. But if there is a serdev child node, the sysfs
> disappear for the 8250 port like it's /dev/ttyS* entry. That is
> even with no hci_serdev.ko loaded :)

It sounds to me like you have a udev rule that's matching on TTY devices
and setting an autosuspend timeout that allows the controller to runtime
suspend. Is that so?

With serdev such a rule would no longer be sufficient as it would no
longer configure all controllers. You can always set the autosuspend
directly through the platform device node, for example:

/sys/bus/platform/devices/481aa000.serial

But the point is, we really don't want the runtime PM behaviour to be
dependent on the presence of such rules. The serial controllers should
always be idle when not in use (unless overridden by user space).

> > > Are you seeing this with your series?
> > 
> > I'm using omap-serial (on BBB) and like 8250_omap, the driver disables
> > runtime pm at probe by setting a negative autosuspend timeout.
> 
> Hmm I though we now have both 8250_omap and serial-omap behave the
> same way for PM.

It looks like they've been implemented the same way (e.g. the negative
autosuspend timeout).

> > Changing this through sysfs causes the serial controller to runtime
> > suspend, but something is not right in my setup as it doesn't wake up on
> > incoming data.
> 
> Do you have also a /dev/ttyO* entry created for the serdev port?

No, serdev claims the port and no tty device is created.

> > I'd say the omap drivers are broken; the controller should definitely
> > idle when the port is closed (whether using serdev or not) without
> > having to fiddle with sysfs.
> 
> This is happening for the non-serdev ports for sure. FYI, there is
> one patch needed for omap4 to idle unused ports that I posted
> few days ago:
> 
> [PATCHv3] serial: 8250: omap: Fix idling of clocks for unused uarts
> 
> But the serdev port is never idled, even if unused.

With the negative autosuspend set in both omap drivers probe functions,
this is the expected behaviour. Which I think we must fix.

> Can you check your serdev port clkctrl reg with rwmem or similar
> tool when it's idle?
> 
> You can do it with:
> 
> rwmem -s32 0x44e004b4   # uart 1 on l4_wkup
> rwmem -s32 0x44e0006c+0x10  # uart 2 - 5 on l4_per
> rwmem -s32 0x44e00038   # uart 6 on l4_per
> 
> And here's what I have on my bbb with 8250_omap:
> 
> 0x44e004b4 = 0x0002
> 0x44e0006c = 0x0003
> 0x44e00070 = 0x0003
> 0x44e00074 = 0x0003
> 0x44e00078 = 0x0003
> 0x44e00038 = 0x0003
> 
> So all disabled except for the console UART.

On BBB with omap-serial I have:

0x44e004b4 = 0x2(uart 1, console, open)
0x44e0006c = 0x2(uart 2, serdev, closed)
0x44e00070 = 0x3(uart 3, disabled in DT)
0x44e00074 = 0x3(uart 4, disabled in DT)
0x44e00078 = 0x2(uart 5, serdev, closed)
0x44e00038 = 0x2(uart 6, ttyO5, closed)

So no enabled and closed port is idle, whether using serdev or not.

Thanks,
Johan

Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

[Viresh Kumar]

On 07-05-18, 16:43, Claudio Scordino wrote:
> At OSPM, it was mentioned the issue about urgent CPU frequency requests
> arriving when a frequency switch is already in progress.
> 
> Besides the various issues (physical time for switching frequency,
> on-going kthread activity, etc.) one (minor) issue is the kernel
> "forgetting" such request, thus waiting the next switch time for
> recomputing the needed frequency and behaving accordingly.
> 
> This patch makes the kthread serve any urgent request occurred during
> the previous frequency switch. It introduces a specific flag, only set
> when the SCHED_DEADLINE scheduling class increases the CPU utilization,
> aiming at decreasing the likelihood of a deadline miss.
> 
> Indeed, some preliminary tests in critical conditions (i.e.
> SCHED_DEADLINE tasks with short periods) have shown reductions of more
> than 10% of the average number of deadline misses. On the other hand,
> the increase in terms of energy consumption when running SCHED_DEADLINE
> tasks (not yet measured) is likely to be not negligible (especially in
> case of critical scenarios like "ramp up" utilizations).
> 
> The patch is meant as follow-up discussion after OSPM.
> 
> Signed-off-by: Claudio Scordino 
> CC: Viresh Kumar 
> CC: Rafael J. Wysocki 
> CC: Peter Zijlstra 
> CC: Ingo Molnar 
> CC: Patrick Bellasi 
> CC: Juri Lelli 
> Cc: Luca Abeni 
> CC: Joel Fernandes 
> CC: linux...@vger.kernel.org
> ---
>  kernel/sched/cpufreq_schedutil.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index d2c6083..4de06b0 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -41,6 +41,7 @@ struct sugov_policy {
>   boolwork_in_progress;
>  
>   boolneed_freq_update;
> + boolurgent_freq_update;
>  };
>  
>  struct sugov_cpu {
> @@ -92,6 +93,14 @@ static bool sugov_should_update_freq(struct sugov_policy 
> *sg_policy, u64 time)
>   !cpufreq_can_do_remote_dvfs(sg_policy->policy))
>   return false;
>  
> + /*
> +  * Continue computing the new frequency. In case of work_in_progress,
> +  * the kthread will resched a change once the current transition is
> +  * finished.
> +  */
> + if (sg_policy->urgent_freq_update)
> + return true;
> +
>   if (sg_policy->work_in_progress)
>   return false;
>  
> @@ -121,6 +130,9 @@ static void sugov_update_commit(struct sugov_policy 
> *sg_policy, u64 time,
>   sg_policy->next_freq = next_freq;
>   sg_policy->last_freq_update_time = time;
>  
> + if (sg_policy->work_in_progress)
> + return;
> +
>   if (policy->fast_switch_enabled) {
>   next_freq = cpufreq_driver_fast_switch(policy, next_freq);
>   if (!next_freq)
> @@ -274,7 +286,7 @@ static inline bool sugov_cpu_is_busy(struct sugov_cpu 
> *sg_cpu) { return false; }
>  static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct 
> sugov_policy *sg_policy)
>  {
>   if (cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl)
> - sg_policy->need_freq_update = true;
> + sg_policy->urgent_freq_update = true;
>  }
>  
>  static void sugov_update_single(struct update_util_data *hook, u64 time,
> @@ -383,8 +395,11 @@ static void sugov_work(struct kthread_work *work)
>   struct sugov_policy *sg_policy = container_of(work, struct 
> sugov_policy, work);
>  
>   mutex_lock(&sg_policy->work_lock);
> - __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> + do {
> + sg_policy->urgent_freq_update = false;
> + __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
>   CPUFREQ_RELATION_L);

If we are going to solve this problem, then maybe instead of the added
complexity and a new flag we can look for need_freq_update flag at this location
and re-calculate the next frequency if required.

> + } while (sg_policy->urgent_freq_update);
>   mutex_unlock(&sg_policy->work_lock);
>  
>   sg_policy->work_in_progress = false;
> @@ -673,6 +688,7 @@ static int sugov_start(struct cpufreq_policy *policy)
>   sg_policy->next_freq= UINT_MAX;
>   sg_policy->work_in_progress = false;
>   sg_policy->need_freq_update = false;
> + sg_policy->urgent_freq_update   = false;
>   sg_policy->cached_raw_freq  = 0;
>  
>   for_each_cpu(cpu, policy->cpus) {
> -- 
> 2.7.4

-- 
viresh

Re: [PATCH v2 10/26] drm/bridge: panel: provide an owner .odev device

[Jyri Sarha]

On 05/04/18 16:51, Peter Rosin wrote:
> It gets rid of an #ifdef and the .of_node member is going away.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/bridge/panel.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 6d99d4a3beb3..f43d77b5ed20 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -169,10 +169,8 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel 
> *panel,
>   panel_bridge->connector_type = connector_type;
>   panel_bridge->panel = panel;
>  
> + panel_bridge->bridge.odev = panel->dev;

I am afraid this approach will eventually conflict with my lately
accepted patch[1].

The panel already has a device pointer of its own, and technically the
bridge element created here is created by the master drm device itself.

I suggest assigning odev here to NULL or to master drm device itself.

Best regards,
Jyri

>   panel_bridge->bridge.funcs = &panel_bridge_bridge_funcs;
> -#ifdef CONFIG_OF
> - panel_bridge->bridge.of_node = panel->dev->of_node;
> -#endif
>  
>   drm_bridge_add(&panel_bridge->bridge);
>  
> 

[1] https://lists.freedesktop.org/archives/dri-devel/2018-April/174559.html
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH] net: aquantia: Fix an error handling path in 'aq_pci_probe()'

[Christophe JAILLET]

The position of 2 labels should be swapped in order to release resources
in the correct order and avoid leaks.

Fixes: 23ee07ad3c2f ("net: aquantia: Cleanup pci functions module")
Signed-off-by: Christophe JAILLET 
---
The order of 'pci_release_regions()' and 'free_netdev()' is in reverse
order in the 'aq_pci_remove()' function.
I don't know if done on purpose and/or needed, so I've left it as-is.
---
 drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c 
b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
index ecc6306f940f..b7f6b5a68b33 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
@@ -298,9 +298,9 @@ static int aq_pci_probe(struct pci_dev *pdev,
kfree(self->aq_hw);
 err_ioremap:
free_netdev(ndev);
-err_pci_func:
-   pci_release_regions(pdev);
 err_ndev:
+   pci_release_regions(pdev);
+err_pci_func:
pci_disable_device(pdev);
return err;
 }
-- 
2.17.0

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

[Sean Wang]

Hi, Marcel

On Tue, 2018-04-03 at 12:27 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 

[ ... ]

> > +
> > +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 
> > plen,
> > +   const void *param)
> > +{
> > +   struct mtk_bt_dev *btdev = hu->priv;
> > +   struct hci_command_hdr *hhdr;
> > +   struct hci_acl_hdr *ahdr;
> > +   struct mtk_wmt_hdr *whdr;
> > +   struct sk_buff *skb;
> > +   int ret = 0;
> > +
> > +   init_completion(&btdev->wmt_cmd);
> > +
> > +   skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
> > +   if (!skb)
> > +   return -ENOMEM;
> > +
> > +   /*
> > +* WMT data is carried in either ACL or HCI format with op code as
> > +* 0xfc6f and followed by a WMT header and its actual payload.
> > +*/
> 
> Please use net subsystem comment style.
> 
> > +   switch (opcode) {
> > +   case MTK_WMT_PATCH_DWNLD:
> > +   ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
> > +   ahdr->handle = cpu_to_le16(0xfc6f);
> > +   ahdr->dlen   = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
> > +   break;
> > +   default:
> > +   hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
> > +   hhdr->opcode = cpu_to_le16(0xfc6f);
> > +   hhdr->plen = plen + MTK_WMT_HDR_SIZE;
> > +   break;
> > +   }
> > +
> > +   hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
> > +   HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
> 
> Why not move that into the switch statement above.
> 
> > +
> > +   /* Start to build a WMT header and its actual payload. */
> > +   whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> > +   whdr->dir = 1;
> > +   whdr->op = opcode;
> > +   whdr->dlen = cpu_to_le16(plen + 1);
> > +   whdr->flag = flag;
> > +   skb_put_data(skb, param, plen);
> > +
> > +   mtk_enqueue(hu, skb);
> > +   hci_uart_tx_wakeup(hu);
> > +
> > +   /*
> > +* Waiting a WMT event response, while we must take care in case of
> > +* failures for the wait.
> > +*/
> > +   ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> > +
> > +   return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> > +}
> 
> All in all I am not convinced that this is super clean. I get that we need 
> something special for having this in the ACL data packets, but for the 
> standard HCI command I prefer that __hci_cmd_sync is used. I addition, it 
> seems that patch download is the only special case and that happens before at 
> the setup stage. So we could make things special for that. I need to 
> understand this a bit better. Can I get a btmon -w trace.log file from the 
> whole init procedure.
> 

While i was trying to rewrite the driver based on btuart.c. you posted
on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
hci command sending which I've done previously with mtk_wmt_cmd_sync.

However, eventually, I got a cmd_timer timeout whose message printed
on console as "Bluetooth: hci0: command 0xfc6f tx timeout".

The mtk soc specific cmd/event I posted below, I dumped directly in
driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.

It appears to the event id is not standard and thus it cannot cancel the
cmd timer when the special hci event is being handled. This way can we
can still use __hci_cmd_sync api ?
 
[4.896200] hci tx: : 01 6f fc 05 01 07 01 00 04
[4.904671] hci rx: : e4 05 02 07 01 00
00 
[4.912859] Bluetooth: hci0 event 0xe4


buildroot login: [6.914509] Bluetooth: hci0: command 0xfc6f tx
timeout
[6.919831] hci tx: : 01 6f fc 06 01 06 02 00 00
01.o
[7.006631] hci rx: : e4 05 02 06 01 00
00 ...
[7.014821] Bluetooth: hci0 event 0xe4

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

[Jia-Ju Bai]

On 2018/5/8 13:04, Eric Dumazet wrote:


On 05/07/2018 07:16 PM, Jia-Ju Bai wrote:


Yes, "&dev->stats" will not change, because it is a fixed address.
But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors 
and rx_missed_errors).
So if the driver returns "&dev->stats" without lock protection (like on line 
858), the field data value of this return value can be the changed field data value or unchanged 
field data value.


We do not care.

This function can be called by multiple cpus at the same time.

As soon as one cpu returns from it, another cpu can happily modify 
dev->stats.ANYFIELD.

Your patch fixes nothing at all.



Okay, thanks.
I also find that my patch does not work...


Best wishes,
Jia-Ju Bai

Re: [PATCH v3 2/3] platform: move the early platform device support to arch/sh

[Geert Uytterhoeven]

Hi Bartosz,

On Fri, May 4, 2018 at 3:27 PM, Bartosz Golaszewski  wrote:
> From: Bartosz Golaszewski 
>
> SuperH is the only user of the current implementation of early platform
> device support. We want to introduce a more robust approach to early
> probing. As the first step - move all the current early platform code
> to arch/sh.
>
> In order not to export internal drivers/base functions to arch code for
> this temporary solution - copy the two needed routines for driver
> matching from drivers/base/platform.c to arch/sh/drivers/platform_early.c.
>
> Also: call early_platform_cleanup() from subsys_initcall() so that it's
> called after all early devices are probed.
>
> Signed-off-by: Bartosz Golaszewski 

>  drivers/clocksource/sh_cmt.c   |   7 +
>  drivers/clocksource/sh_mtu2.c  |   7 +
>  drivers/clocksource/sh_tmu.c   |   8 +
>  drivers/tty/serial/sh-sci.c|   7 +-
>  include/linux/platform_device.h|  64 +

The parts used on contemporary ARM/ARM64 Renesas SoCs look fine to me, so
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/2] media: v4l: Add new 10-bit packed grayscale format

[Todor Tomov]

Hi Sakari,

On  7.05.2018 13:59, Sakari Ailus wrote:
> Hi Todor,
> 
> On Fri, Apr 27, 2018 at 02:40:39PM +0300, Todor Tomov wrote:
>> The new format will be called V4L2_PIX_FMT_Y10P.
>> It is similar to the V4L2_PIX_FMT_SBGGR10P family formats
>> but V4L2_PIX_FMT_Y10P is a grayscale format.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  Documentation/media/uapi/v4l/pixfmt-y10p.rst | 31 
>> 
>>  Documentation/media/uapi/v4l/yuv-formats.rst |  1 +
>>  drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
>>  include/uapi/linux/videodev2.h   |  1 +
>>  4 files changed, 34 insertions(+)
>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-y10p.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-y10p.rst 
>> b/Documentation/media/uapi/v4l/pixfmt-y10p.rst
>> new file mode 100644
>> index 000..0018fe7
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/pixfmt-y10p.rst
>> @@ -0,0 +1,31 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _V4L2-PIX-FMT-Y10P:
>> +
>> +**
>> +V4L2_PIX_FMT_Y10P ('Y10P')
>> +**
>> +
>> +Grey-scale image as a MIPI RAW10 packed array
>> +
>> +
>> +Description
>> +===
>> +
>> +This is a packed grey-scale image format with a depth of 10 bits per
>> +pixel. Every four consecutive pixels are packed into 5 bytes. Each of
>> +the first 4 bytes contain the 8 high order bits of the pixels, and
>> +the 5th byte contains the 2 least significants bits of each pixel,
>> +in the same order.
>> +
>> +**Bit-packed representation.**
>> +
>> +.. flat-table::
>> +:header-rows:  0
>> +:stub-columns: 0
>> +
>> +* - Y'\ :sub:`00[9:2]`
>> +  - Y'\ :sub:`01[9:2]`
>> +  - Y'\ :sub:`02[9:2]`
>> +  - Y'\ :sub:`03[9:2]`
>> +  - Y'\ :sub:`03[1:0]`\ Y'\ :sub:`02[1:0]`\ Y'\ :sub:`01[1:0]`\ Y'\ 
>> :sub:`00[1:0]`
> 
> Could you add which exact bits the two LSBs of each pixel go to in the last
> byte, as in the 10-bit packed Bayer format documentation?

Thank you for review. I'll add and send v2.

Best regards,
Todor

> 
>> diff --git a/Documentation/media/uapi/v4l/yuv-formats.rst 
>> b/Documentation/media/uapi/v4l/yuv-formats.rst
>> index 3334ea4..9ab0592 100644
>> --- a/Documentation/media/uapi/v4l/yuv-formats.rst
>> +++ b/Documentation/media/uapi/v4l/yuv-formats.rst
>> @@ -29,6 +29,7 @@ to brightness information.
>>  pixfmt-y10
>>  pixfmt-y12
>>  pixfmt-y10b
>> +pixfmt-y10p
>>  pixfmt-y16
>>  pixfmt-y16-be
>>  pixfmt-y8i
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index f48c505..bdf2399 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -1147,6 +1147,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>>  case V4L2_PIX_FMT_Y16:  descr = "16-bit Greyscale"; break;
>>  case V4L2_PIX_FMT_Y16_BE:   descr = "16-bit Greyscale BE"; break;
>>  case V4L2_PIX_FMT_Y10BPACK: descr = "10-bit Greyscale (Packed)"; 
>> break;
>> +case V4L2_PIX_FMT_Y10P: descr = "10-bit Greyscale (MIPI 
>> Packed)"; break;
>>  case V4L2_PIX_FMT_Y8I:  descr = "Interleaved 8-bit Greyscale"; 
>> break;
>>  case V4L2_PIX_FMT_Y12I: descr = "Interleaved 12-bit Greyscale"; 
>> break;
>>  case V4L2_PIX_FMT_Z16:  descr = "16-bit Depth"; break;
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 600877b..b24ab720 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -522,6 +522,7 @@ struct v4l2_pix_format {
>>  
>>  /* Grey bit-packed formats */
>>  #define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10  
>> Greyscale bit-packed */
>> +#define V4L2_PIX_FMT_Y10Pv4l2_fourcc('Y', '1', '0', 'P') /* 10  
>> Greyscale, MIPI RAW10 packed */
>>  
>>  /* Palette formats */
>>  #define V4L2_PIX_FMT_PAL8v4l2_fourcc('P', 'A', 'L', '8') /*  8  8-bit 
>> palette */
>> -- 
>> 2.7.4
>>
> 

Re: [PATCH 2/2] serial: imx: dma_unmap_sg buffers on shutdown

[Uwe Kleine-König]

On Mon, May 07, 2018 at 11:36:10PM +0200, Sebastian Reichel wrote:
> This properly unmaps DMA SG on device shutdown.
> 
> Reported-by: Nandor Han 
> Suggested-by: Nandor Han 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/tty/serial/imx.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 3ca767b1162a..6c53e74244ec 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1425,10 +1425,18 @@ static void imx_uart_shutdown(struct uart_port *port)
>   u32 ucr1, ucr2;
>  
>   if (sport->dma_is_enabled) {
> - sport->dma_is_rxing = 0;
> - sport->dma_is_txing = 0;
>   dmaengine_terminate_sync(sport->dma_chan_tx);
> + if (sport->dma_is_txing) {
> + dma_unmap_sg(sport->port.dev, &sport->tx_sgl[0],
> +  sport->dma_tx_nents, DMA_TO_DEVICE);
> + sport->dma_is_txing = 0;
> + }

did you find this because the kernel crashed or consumed more and more
memory, or is this "only" a finding of reading the source code? If the
former it would be great to point out in the commit log, if the latter,
I wonder if this is a real problem that warrants a stable backport.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

[Tiwei Bie]

On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
> On 2018年05月08日 11:05, Jason Wang wrote:
> > > 
> > > Because in virtqueue_enable_cb_delayed(), we may set an
> > > event_off which is bigger than new and both of them have
> > > wrapped. And in this case, although new is smaller than
> > > event_off (i.e. the third param -- old), new shouldn't
> > > add vq->num, and actually we are expecting a very big
> > > idx diff.
> > 
> > Yes, so to calculate distance correctly between event and new, we just
> > need to compare the warp counter and return false if it doesn't match
> > without the need to try to add vq.num here.
> > 
> > Thanks
> 
> Sorry, looks like the following should work, we need add vq.num if
> used_wrap_counter does not match:
> 
> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>                       __u16 off_wrap, __u16 new,
>                       __u16 old)
> {
>     bool wrap = off_wrap >> 15;
>     int off = off_wrap & ~(1 << 15);
>     __u16 d1, d2;
> 
>     if (wrap != vq->used_wrap_counter)
>         d1 = new + vq->num - off - 1;

Just to draw your attention (maybe you have already
noticed this).

In this case (i.e. wrap != vq->used_wrap_counter),
it's also possible that (off < new) is true. Because,

when virtqueue_enable_cb_delayed_packed() is used,
`off` is calculated in driver in a way like this:

off = vq->last_used_idx + bufs;
if (off >= vq->vring_packed.num) {
off -= vq->vring_packed.num;
wrap_counter ^= 1;
}

And when `new` (in vhost) is close to vq->num. The
vq->last_used_idx + bufs (in driver) can be bigger
than vq->vring_packed.num, and:

1. `off` will wrap;
2. wrap counters won't match;
3. off < new;

And d1 (i.e. new + vq->num - off - 1) will be a value
bigger than vq->num. I'm okay with this, although it's
a bit weird.

Best regards,
Tiwei Bie

>     else
>         d1 = new - off - 1;
> 
>     if (new > old)
>         d2 = new - old;
>     else
>         d2 = new + vq->num - old;
> 
>     return d1 < d2;
> }
> 
> Thanks
> 

Re: [PATCH 0/3] scsi: arcmsr: Add driver parameter cmd_timeout for scsi command timeout setting

[Ching Huang]

On Tue, 2018-05-08 at 14:32 +0800, Ching Huang wrote:
> On Tue, 2018-05-08 at 01:41 -0400, Martin K. Petersen wrote:
> > Hello Ching,
> > 
> > > 1. Add driver parameter cmd_timeout, default value is 
> > > ARCMSR_DEFAULT_TIMEOUT.
> > > 2. Add slave_configure callback function to set device command timeout 
> > > value.
> > > 3. Update driver version to v1.40.00.06-20180504.
> > 
> > I am not so keen on arcmsr overriding the timeout set by the admin or
> > application.
> > 
> > Also, instead of introducing this module parameter, why not simply ask
> > the user to change rq_timeout?
> > 
> This timeout setting only after device has been inquiry successfully.
> Of course, user can set timeout value to /sys/block/sdX/device/timeout.
> But user does not like to set this value once command timeout occurred.
> They rather like timeout never happen.
> 
This timeout setting apply to all devices, its better than user has to
set one bye one for each device.

[PATCH] sched/schedutil: Don't set next_freq to UINT_MAX

[Viresh Kumar]

The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain
occasions:
- In sugov_start(), when the schedutil governor is started for a group
  of CPUs.
- And whenever we need to force a freq update before rate-limit
  duration, which happens when:
  - there is an update in cpufreq policy limits.
  - Or when the utilization of DL scheduling class increases.

In return, get_next_freq() doesn't return a cached next_freq value but
instead recalculates the next frequency. This has some side effects
though and may significantly delay a required increase in frequency.

In sugov_update_single() we try to avoid decreasing frequency if the CPU
has not been idle recently. Consider this scenario, the available range
of frequencies for a CPU are from 800 MHz to 2.5 GHz and current
frequency is 800 MHz. From one of the call paths
sg_policy->need_freq_update is set to true and hence
sg_policy->next_freq is set to UINT_MAX. Now if the CPU had been busy,
next_f will always be less than UINT_MAX, whatever the value of next_f
is. And so even when we wanted to increase the frequency, we will
overwrite next_f with UINT_MAX and will not change the frequency
eventually. This will continue until the time CPU stays busy. This isn't
cross checked with any specific test cases, but rather based on general
code review.

Fix that by not resetting the sg_policy->need_freq_update flag from
sugov_should_update_freq() but get_next_freq() and we wouldn't need to
overwrite sg_policy->next_freq anymore.

Cc: 4.12+  # 4.12+
Fixes: b7eaf1aab9f8 ("cpufreq: schedutil: Avoid reducing frequency of busy CPUs 
prematurely")
Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpufreq_schedutil.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index d2c6083304b4..daaca23697dc 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -95,15 +95,8 @@ static bool sugov_should_update_freq(struct sugov_policy 
*sg_policy, u64 time)
if (sg_policy->work_in_progress)
return false;
 
-   if (unlikely(sg_policy->need_freq_update)) {
-   sg_policy->need_freq_update = false;
-   /*
-* This happens when limits change, so forget the previous
-* next_freq value and force an update.
-*/
-   sg_policy->next_freq = UINT_MAX;
+   if (unlikely(sg_policy->need_freq_update))
return true;
-   }
 
delta_ns = time - sg_policy->last_freq_update_time;
 
@@ -165,8 +158,10 @@ static unsigned int get_next_freq(struct sugov_policy 
*sg_policy,
 
freq = (freq + (freq >> 2)) * util / max;
 
-   if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != 
UINT_MAX)
+   if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
return sg_policy->next_freq;
+
+   sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq = freq;
return cpufreq_driver_resolve_freq(policy, freq);
 }
@@ -670,7 +665,7 @@ static int sugov_start(struct cpufreq_policy *policy)
 
sg_policy->freq_update_delay_ns = sg_policy->tunables->rate_limit_us * 
NSEC_PER_USEC;
sg_policy->last_freq_update_time= 0;
-   sg_policy->next_freq= UINT_MAX;
+   sg_policy->next_freq= 0;
sg_policy->work_in_progress = false;
sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq  = 0;
-- 
2.15.0.194.g9af6a3dea062

Re: [PATCH v7 1/6] dt-bindings: define vendor prefix for Wi2Wi, Inc.

[H. Nikolaus Schaller]

HI Rob,

> Am 07.05.2018 um 22:54 schrieb Rob Herring :
> 
> On Thu, May 03, 2018 at 11:35:46AM +0200, H. Nikolaus Schaller wrote:
>> Introduce vendor prefix for Wi2Wi, Inc. for W2SG0004 GPS module
>> and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> Acked-by: Rob Herring 
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
> 
> Applied this one so you don't have to keep sending it.

Thanks and BR,
Nikolaus

Re: [PATCH 1/2] serial: imx: cleanup imx_uart_disable_dma()

[Uwe Kleine-König]

Hello,

On Mon, May 07, 2018 at 11:36:09PM +0200, Sebastian Reichel wrote:
> Remove unrelated CTSC/CTS disabling from imx_uart_disable_dma() and
> move it to imx_uart_shutdown(), which is the only user of the DMA
> disabling function. This should not change the driver's behaviour,
> but improves readability. After this change imx_uart_disable_dma()
> does the reverse thing of imx_uart_enable_dma().
> 
> Suggested-by: Nandor Han 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/tty/serial/imx.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index c2fc6bef7a6f..3ca767b1162a 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1291,18 +1291,13 @@ static void imx_uart_enable_dma(struct imx_port 
> *sport)
>  
>  static void imx_uart_disable_dma(struct imx_port *sport)
>  {
> - u32 ucr1, ucr2;
> + u32 ucr1;
>  
>   /* clear UCR1 */
>   ucr1 = imx_uart_readl(sport, UCR1);
>   ucr1 &= ~(UCR1_RXDMAEN | UCR1_TXDMAEN | UCR1_ATDMAEN);
>   imx_uart_writel(sport, ucr1, UCR1);
>  
> - /* clear UCR2 */
> - ucr2 = imx_uart_readl(sport, UCR2);
> - ucr2 &= ~(UCR2_CTSC | UCR2_CTS | UCR2_ATEN);
> - imx_uart_writel(sport, ucr2, UCR2);
> -
>   imx_uart_setup_ufcr(sport, TXTL_DEFAULT, RXTL_DEFAULT);
>  
>   sport->dma_is_enabled = 0;
> @@ -1447,7 +1442,7 @@ static void imx_uart_shutdown(struct uart_port *port)
>  
>   spin_lock_irqsave(&sport->port.lock, flags);
>   ucr2 = imx_uart_readl(sport, UCR2);
> - ucr2 &= ~(UCR2_TXEN | UCR2_ATEN);
> + ucr2 &= ~(UCR2_TXEN | UCR2_CTSC | UCR2_CTS | UCR2_ATEN);
>   imx_uart_writel(sport, ucr2, UCR2);
>   spin_unlock_irqrestore(&sport->port.lock, flags);

While this doesn't change behaviour (which is of course good and
intended here) I wonder if changing RTS is right here.

According to Documentation/serial/driver it is not.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Andrzej Hajda]

On 07.05.2018 15:53, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from the bridge consumer (the drm_device) to some
>>> non-existent bridge supplier.
>> I understand rationales behind this patch, but it is another step into
>> making drm_dev one big driver with subcomponents, where drm will work
>> only if every subcomponent is working/loaded. Do we need to go this way?
>> In case of many platforms such approach results in display turned on
>> very late on boot for example due to late initialization of some
>> regulator exposed by some i2c device, which is used by hdmi bridge. And
>> this hdmi bridge is just to provide alternative(rarely used) display
>> path, the main display path would work anyway.
>>
>> So the main question to drm maintainers is about evolution of bridges,
>> if drm_bridges should become mandatory components of drm device or they
>> could be added/removed dynamically?
> This is already the case. You currently cannot hotplug a drm_bridge,
> everything must be present.

Are you sure? DRM core is changing quite fast, so maybe I have missed
something, but AFAIK core calls bridge code only if full display
pipeline is created and connector is in connected state.
So adding and removing bridges from inactive pipelines should work if
coded properly.

>  I don't think it makes sense to change that
> until we have physically hotpluggable drm_bridges in real hardware.

But kernel core already assumes that device drivers are hot-pluggable
:), even this patch is created to solve issues regarding driver hot
unplugging.

>  I
> definitely don't want to refcount stuff to work around driver load
> bonghits on DT platforms, because refcounting is way too hard to get right
> :-)

I am not sure about bridges, but I have successfully (IMO) experimented
with hot (un)plugging panel driver, see panel-samsung-s6e8aa0.c driver
and exynos_drm_dsi.c, panel driver can be safely
plugged/unplugged/replugged without any refcounting (but with help of
mipi_dsi attach/detach callbacks, which are not available for
non-mipi-dsi drivers).

Regards
Andrzej

>
> Afaik there's out-of-tree patches to solve 99% of the driver load fun on
> DT platforms, but because it's not a 100% solution it's blocked since
> forever.
> -Daniel
>
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  drivers/gpu/drm/drm_bridge.c | 18 ++
>>>  include/drm/drm_bridge.h |  2 ++
>>>  2 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 78d186b6831b..0259f0a3ff27 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -26,6 +26,7 @@
>>>  #include 
>>>  
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  #include "drm_crtc_internal.h"
>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>>> struct drm_bridge *bridge,
>>> if (bridge->dev)
>>> return -EBUSY;
>>>  
>>> +   if (encoder->dev->dev != bridge->odev) {
>>> +   bridge->link = device_link_add(encoder->dev->dev,
>>> +  bridge->odev, 0);
>>> +   if (!bridge->link) {
>>> +   dev_err(bridge->odev, "failed to link bridge to %s\n",
>>> +   dev_name(encoder->dev->dev));
>>> +   return -EINVAL;
>>> +   }
>>> +   }
>>> +
>>> bridge->dev = encoder->dev;
>>> bridge->encoder = encoder;
>>>  
>>> if (bridge->funcs->attach) {
>>> ret = bridge->funcs->attach(bridge);
>>> if (ret < 0) {
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> bridge->dev = NULL;
>>> bridge->encoder = NULL;
>>> return ret;
>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>> if (bridge->funcs->detach)
>>> bridge->funcs->detach(bridge);
>>>  
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> +
>>> bridge->dev = NULL;
>>>  }
>>>  
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index b656e505d11e..804189c63a4c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>>   * @list: to keep track of all added bridges
>>>   * @timings: the timing specification for the bridge, if any (may
>>>   * be NULL)
>>> + * @link: drm consumer <-> bridge supplier
>>>   * @funcs: control functions
>>>   * @driver_private: pointer to the bridge driver's internal context
>>>   */
>>> @@ -271,6 +272,7 @@ struct drm

Re: [PATCH] i2c-mux-pca954x: Force reset on probe if available

[Peter Rosin]

On 2018-05-01 13:42, Mike Looijmans wrote:
> Instead of just hogging the reset GPIO into deactivated state, activate and
> then de-activate the reset. This allows for better recovery if the CPU was
> reset halfway through an I2C transaction for example.

I can't see any problems with this, and a reset at load time can certainly
be a benefit. Some questions below though...

Cheers,
Peter

> Signed-off-by: Mike Looijmans 
> ---
>  drivers/i2c/muxes/i2c-mux-pca954x.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c 
> b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index 09bafd3..13e10d0 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -36,6 +36,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -389,10 +390,17 @@ static int pca954x_probe(struct i2c_client *client,
>   i2c_set_clientdata(client, muxc);
>   data->client = client;
>  
> - /* Get the mux out of reset if a reset GPIO is specified. */
> - gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_LOW);
> + /* Reset the mux if a reset GPIO is specified. */
> + gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
>   if (IS_ERR(gpio))
>   return PTR_ERR(gpio);
> + if (gpio) {
> + /* Datasheet specifies a 4 ns reset-low time */
> + udelay(1);

ndelay(4) ?

> + gpiod_set_value_cansleep(gpio, 0);
> + /* Datasheet specifies a 500 ns reset recovery time */
> + udelay(1);

ndelay(500) ?

> + }
>  
>   match = of_match_device(of_match_ptr(pca954x_of_match), &client->dev);
>   if (match)
> 

Re: [PATCH 5/7] cifs: smbd: Protect memory registration using RCU

[kbuild test robot]

Hi Long,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on cifs/for-next]
[also build test WARNING on v4.17-rc4 next-20180507]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Long-Li/cifs-smbd-Make-upper-layer-decide-when-to-destroy-the-transport/20180508-110150
base:   git://git.samba.org/sfrench/cifs-2.6.git for-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   fs/cifs/smb2pdu.c:110:47: sparse: expression using sizeof(void)
   fs/cifs/smb2pdu.c:681:26: sparse: expression using sizeof(void)
>> fs/cifs/smb2pdu.c:2613:17: sparse: incompatible types in comparison 
>> expression (different address spaces)
   fs/cifs/smb2pdu.c:2993:17: sparse: incompatible types in comparison 
expression (different address spaces)
   fs/cifs/smb2pdu.c:3251:23: sparse: expression using sizeof(void)
   fs/cifs/smb2pdu.c:3251:23: sparse: expression using sizeof(void)
   fs/cifs/smb2pdu.c:3252:23: sparse: expression using sizeof(void)
   fs/cifs/smb2pdu.c:3713:17: sparse: expression using sizeof(void)
   fs/cifs/smb2pdu.c:3713:17: sparse: expression using sizeof(void)

vim +2613 fs/cifs/smb2pdu.c

  2565  
  2566  /*
  2567   * To form a chain of read requests, any read requests after the first 
should
  2568   * have the end_of_chain boolean set to true.
  2569   */
  2570  static int
  2571  smb2_new_read_req(void **buf, unsigned int *total_len,
  2572  struct cifs_io_parms *io_parms, struct cifs_readdata *rdata,
  2573  unsigned int remaining_bytes, int request_type)
  2574  {
  2575  int rc = -EACCES;
  2576  struct smb2_read_plain_req *req = NULL;
  2577  struct smb2_sync_hdr *shdr;
  2578  struct TCP_Server_Info *server;
  2579  
  2580  rc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, (void **) 
&req,
  2581   total_len);
  2582  if (rc)
  2583  return rc;
  2584  
  2585  server = io_parms->tcon->ses->server;
  2586  if (server == NULL)
  2587  return -ECONNABORTED;
  2588  
  2589  shdr = &req->sync_hdr;
  2590  shdr->ProcessId = cpu_to_le32(io_parms->pid);
  2591  
  2592  req->PersistentFileId = io_parms->persistent_fid;
  2593  req->VolatileFileId = io_parms->volatile_fid;
  2594  req->ReadChannelInfoOffset = 0; /* reserved */
  2595  req->ReadChannelInfoLength = 0; /* reserved */
  2596  req->Channel = 0; /* reserved */
  2597  req->MinimumCount = 0;
  2598  req->Length = cpu_to_le32(io_parms->length);
  2599  req->Offset = cpu_to_le64(io_parms->offset);
  2600  #ifdef CONFIG_CIFS_SMB_DIRECT
  2601  /*
  2602   * If we want to do a RDMA write, fill in and append
  2603   * smbd_buffer_descriptor_v1 to the end of read request
  2604   */
  2605  if (server->rdma && rdata && !server->sign &&
  2606  rdata->bytes >= 
server->smbd_conn->rdma_readwrite_threshold) {
  2607  
  2608  struct smbd_buffer_descriptor_v1 *v1;
  2609  bool need_invalidate =
  2610  io_parms->tcon->ses->server->dialect == 
SMB30_PROT_ID;
  2611  
  2612  rcu_read_lock();
> 2613  rcu_dereference(server->smbd_conn);
  2614  rdata->mr = smbd_register_mr(
  2615  server->smbd_conn, rdata->pages,
  2616  rdata->nr_pages, rdata->tailsz,
  2617  true, need_invalidate);
  2618  rcu_read_unlock();
  2619  if (!rdata->mr)
  2620  return -ENOBUFS;
  2621  
  2622  req->Channel = SMB2_CHANNEL_RDMA_V1_INVALIDATE;
  2623  if (need_invalidate)
  2624  req->Channel = SMB2_CHANNEL_RDMA_V1;
  2625  req->ReadChannelInfoOffset =
  2626  cpu_to_le16(offsetof(struct 
smb2_read_plain_req, Buffer));
  2627  req->ReadChannelInfoLength =
  2628  cpu_to_le16(sizeof(struct 
smbd_buffer_descriptor_v1));
  2629  v1 = (struct smbd_buffer_descriptor_v1 *) 
&req->Buffer[0];
  2630  v1->offset = cpu_to_le64(rdata->mr->mr->iova);
  2631  v1->token = cpu_to_le32(rdata->mr->mr->rkey);
  2632  v1->length = cpu_to_le32(rdata->mr->mr->length);
  2633  
  2634  *total_len

Re: [PATCH 2/2] leds: lm3601x: Introduce the lm3601x LED driver

[kbuild test robot]

Hi Dan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.17-rc4 next-20180507]
[cannot apply to j.anaszewski-leds/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/dt-bindings-lm3601x-Introduce-the-lm3601x-driver/20180508-074439
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All warnings (new ones prefixed by >>):

   In file included from drivers/leds/leds-lm3601x.c:13:0:
   drivers/leds/leds-lm3601x.c: In function 'lm3601x_strobe_brightness_set':
>> drivers/leds/leds-lm3601x.c:272:6: warning: large integer implicitly 
>> truncated to unsigned type [-Woverflow]
 ~LM3601X_MODE_STROBE, LED_OFF);
 ^
   include/linux/regmap.h:76:36: note: in definition of macro 
'regmap_update_bits'
 regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
   ^~~~

vim +272 drivers/leds/leds-lm3601x.c

   258  
   259  static int lm3601x_strobe_brightness_set(struct led_classdev *cdev,
   260   enum led_brightness brightness)
   261  {
   262  struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(cdev);
   263  struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
   264  int ret;
   265  u8 brightness_val;
   266  
   267  mutex_lock(&led->lock);
   268  ret = lm3601x_read_faults(led);
   269  
   270  if (brightness == LED_OFF) {
   271  ret = regmap_update_bits(led->regmap, 
LM3601X_ENABLE_REG,
 > 272  ~LM3601X_MODE_STROBE, LED_OFF);
   273  goto out;
   274  }
   275  
   276  if (brightness == LED_ON)
   277  brightness_val = LED_ON;
   278  else
   279  brightness_val = (brightness/2);
   280  
   281  ret = regmap_write(led->regmap, LM3601X_LED_FLASH_REG, 
brightness_val);
   282  
   283  out:
   284  mutex_unlock(&led->lock);
   285  return ret;
   286  }
   287  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

RE: [LINUX PATCH v8 2/2] memory: pl353: Add driver for arm pl353 static memory controller

[Naga Sureshkumar Relli]

> -Original Message-
> From: Julia Cartwright [mailto:ju...@ni.com]
> Sent: Monday, May 7, 2018 10:23 PM
> To: Naga Sureshkumar Relli 
> Cc: nagasureshkumarre...@gmail.com; boris.brezil...@bootlin.com; 
> rog...@ti.com;
> lee.jo...@linaro.org; alexandre.bell...@free-electrons.com; 
> nicolas.fe...@microchip.com;
> la...@linux-mips.org; a...@thorsis.com; linux-kernel@vger.kernel.org
> Subject: Re: [LINUX PATCH v8 2/2] memory: pl353: Add driver for arm pl353 
> static
> memory controller
> 
> On Mon, May 07, 2018 at 10:12:28AM +, Naga Sureshkumar Relli wrote:
> > Hi Julia,
> >
> > Thanks for reviewing the patch and Sorry for my late reply. This patch
> > went to junk folder, hence I didn't catch this patch.
> >
> > From: Julia Cartwright [mailto:ju...@ni.com]
> [..]
> > >
> > > It would be easier to follow if you constructed your two patchsets
> > > with git format-patch -- thread.
> > >
> >
> > I am using the same but with out --thread.
> >
> > > Or, merge them into a single patchset, especially considering the 
> > > dependency between
> patches.
> >
> > But both are different patches, one for Device tree documentation and other 
> > for driver
> update.
> 
> Yes, I'm not proposing you merge _patches_ but _patchsets_.  You have two 
> patchsets, one for
> the SMC driver, and another for the NAND.  Given that they depend on one 
> another, it's
> helpful for reviewers if you sent them all together, with a cover letter 
> which describes the
> entire patchset, changelog, it's dependencies, revision changelog, etc.
> 
> Something like:
> 
>[PATCH v9 0/4] rawnand: memory: add support for PL353 static memory 
> controller +
> NAND
>   [PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding 
> information
>   [PATCH v9 2/4] memory: pl353: Add driver for arm pl353 static memory 
> controller
>   [PATCH v9 3/4] Documentation: nand: pl353: Add documentation for 
> controller and
> driver
>   [PATCH v9 4/4] mtd: rawnand: pl353: Add basic driver for arm pl353 smc 
> nand interface
> 
> Anyway, just with --thread enabled would be an improvement.
Ok. Got it. But both are different layers hence I sent like that.

> 
> [..]
> > > > --- a/drivers/memory/Kconfig
> > > > +++ b/drivers/memory/Kconfig
> > > > @@ -152,6 +152,13 @@ config DA8XX_DDRCTL
> > > >   This driver is for the DDR2/mDDR Memory Controller present on
> > > >   Texas Instruments da8xx SoCs. It's used to tweak various 
> > > > memory
> > > >   controller configuration options.
> > > > +config PL35X_SMC
> > > > +   bool "ARM PL35X Static Memory Controller(SMC) driver"
> > >
> > > Is there any reason why this can't be tristate?
> >
> > There is a Nand driver which uses this driver. i.e The NAND driver
> > Depends on this driver.
> 
> That's true, but it's irrelevant to question I asked.  It is perfectly valid 
> for both the SMC and
> NAND drivers to be tristate, why are you not allowing this configuration?
Yes, I will update it in next version of patch set.

Thanks,
Naga Sureshkumar Relli
> 
>Julia

Re: [PATCH 0/3] scsi: arcmsr: Add driver parameter cmd_timeout for scsi command timeout setting

[Ching Huang]

On Tue, 2018-05-08 at 01:41 -0400, Martin K. Petersen wrote:
> Hello Ching,
> 
> > 1. Add driver parameter cmd_timeout, default value is 
> > ARCMSR_DEFAULT_TIMEOUT.
> > 2. Add slave_configure callback function to set device command timeout 
> > value.
> > 3. Update driver version to v1.40.00.06-20180504.
> 
> I am not so keen on arcmsr overriding the timeout set by the admin or
> application.
> 
> Also, instead of introducing this module parameter, why not simply ask
> the user to change rq_timeout?
> 
This timeout setting only after device has been inquiry successfully.
Of course, user can set timeout value to /sys/block/sdX/device/timeout.
But user does not like to set this value once command timeout occurred.
They rather like timeout never happen.

Re: [PATCH] nubus: Unconditionally register bus type

[Geert Uytterhoeven]

Hi Finn,

On Tue, May 8, 2018 at 1:44 AM, Finn Thain  wrote:
> On Mon, 7 May 2018, I wrote:
>> On Sun, 6 May 2018, Greg Kroah-Hartman wrote:
>> > > > Why not just have an "bus is registered" flag in your driver
>> > > > register function that refuses to let drivers register with the
>> > > > driver core if it isn't set?
>> > >
>> > > Perhaps that should happen in the core driver_register() function.
>> > > BUG_ON is frowned upon, after all. Would that be acceptable?
>> >
>> > I don't understand what you mean here, perhaps make a patch to show it?
>> >
>>
>> As an alternative to your suggestion (add flag to avoid the BUG_ON):
>>
>> --- a/drivers/base/driver.c
>> +++ b/drivers/base/driver.c
>> @@ -148,7 +148,10 @@ int driver_register(struct device_driver *drv)
>>   int ret;
>>   struct device_driver *other;
>>
>> - BUG_ON(!drv->bus->p);
>> + if (!drv->bus->p) {
>> + WARN_ONCE(1, "Cannot register driver with invalid bus\n");
>> + return -EPROBE_DEFER;
>> + }
>>
>>   if ((drv->bus->probe && drv->probe) ||
>>   (drv->bus->remove && drv->remove) ||
>>
>
> That rushed example I gave above seems to be confusing the issue. Sorry
> about that. (See sioux-core.c for the code that motivated it.)
>
> This example is the sort of flag removal that I had in mind --
>
> diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> index ba912558a510..4ee22fb3db92 100644
> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -148,7 +148,8 @@ int driver_register(struct device_driver *drv)
> int ret;
> struct device_driver *other;
>
> -   BUG_ON(!drv->bus->p);
> +   if (!drv->bus->p)
> +   return -ENODEV;

If this is meant to handle the case where the device driver is registered
before the bus is registered, while the latter can still happen later,
then you want to return -EPROBE_DEFER.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] IB/umem: use tgid instead of pid in ib_umem structure

[Jason Gunthorpe]

On Mon, May 07, 2018 at 09:38:53AM +0800, 858585 jemmy wrote:
> On Sat, May 5, 2018 at 2:23 AM, Jason Gunthorpe  wrote:
> > On Fri, May 04, 2018 at 04:51:15PM +0800, 858585 jemmy wrote:
> >> On Fri, May 4, 2018 at 11:14 AM, 858585 jemmy  
> >> wrote:
> >> > On Thu, May 3, 2018 at 11:33 PM, Jason Gunthorpe  wrote:
> >> >> On Thu, May 03, 2018 at 10:04:34PM +0800, Lidong Chen wrote:
> >> >>> The userspace may invoke ibv_reg_mr and ibv_dereg_mr by different 
> >> >>> threads.
> >> >>> If when ibv_dereg_mr invoke and the thread which invoked ibv_reg_mr has
> >> >>> exited, get_pid_task will return NULL, ib_umem_release does not 
> >> >>> decrease
> >> >>> mm->pinned_vm. This patch fixes it by use tgid.
> >> >>>
> >> >>> Signed-off-by: Lidong Chen 
> >> >>>  drivers/infiniband/core/umem.c | 12 ++--
> >> >>>  include/rdma/ib_umem.h |  2 +-
> >> >>>  2 files changed, 7 insertions(+), 7 deletions(-)
> >> >>
> >> >> Why are we even using a struct pid for this? Does anyone know?
> >> >
> >> > commit 87773dd56d5405ac28119fcfadacefd35877c18f add pid in ib_umem 
> >> > structure.
> >> >
> >> > and the comment has such information:
> >> > Later a different process with a different mm_struct than the one that
> >> > allocated the ib_umem struct
> >> > ends up releasing it which results in decrementing the new processes
> >> > mm->pinned_vm count past
> >> > zero and wrapping.
> >>
> >> I think a different process should not have the permission to release 
> >> ib_umem.
> >> so maybe the reason is not a different process?
> >> can ib_umem_release be invoked in interrupt context?
> >
> > We plan to restore fork support and add some way to share MRs between
> > processes, so we must consider having a different process release the
> > umem than acquired it.
> 
> If restore fork support, what is the expected behavior?
> If parent process pinned_vm is x, what is the child process pinned_vm
> value after fork? It reset to zero now.
> If the parent process call ibv_dereg_mr after fork, should the child
> process decrease pinned_vm?
> If the child process call  ibv_dereg_mr after fork, should the parent
> process decrease pinned_vm?

If I recall the purpose of accessing the MM during de-register is to
undo the pinned pages change (pinned_vm) that register performed.

So, the semantic is simple, during deregister we must access excatly
the same MM that was used during register and undo the change to
pinned_vm.

The approach should be to find the most reliably way to hold a
reference to the MM that was used during register.

Apparently we can't just hold a ref on the mm (according to mm_get's
comment at least)

tgid is clearly a better indirect reference to the mm than pid (pid is
so obviously wrong)

But I am wondering why not just hold struct task here instead of tgid?
Isn't task->mm going to be more reliably than tgid->task->mm ??

Jason

Re: [PATCH] nubus: Unconditionally register bus type

[Geert Uytterhoeven]

Hi Greg,

On Mon, May 7, 2018 at 4:45 PM, Greg Kroah-Hartman
 wrote:
> On Mon, May 07, 2018 at 02:53:13PM +0200, Geert Uytterhoeven wrote:
>> On Mon, May 7, 2018 at 1:57 AM, Finn Thain  
>> wrote:
>> > On Sun, 6 May 2018, Greg Kroah-Hartman wrote:
>> >> > > Why not just have an "bus is registered" flag in your driver
>> >> > > register function that refuses to let drivers register with the
>> >> > > driver core if it isn't set?
>> >> >
>> >> > Perhaps that should happen in the core driver_register() function.
>> >> > BUG_ON is frowned upon, after all. Would that be acceptable?
>> >>
>> >> I don't understand what you mean here, perhaps make a patch to show it?
>> >>
>> >
>> > As an alternative to your suggestion (add flag to avoid the BUG_ON):
>> >
>> > --- a/drivers/base/driver.c
>> > +++ b/drivers/base/driver.c
>> > @@ -148,7 +148,10 @@ int driver_register(struct device_driver *drv)
>> > int ret;
>> > struct device_driver *other;
>> >
>> > -   BUG_ON(!drv->bus->p);
>> > +   if (!drv->bus->p) {
>> > +   WARN_ONCE(1, "Cannot register driver with invalid bus\n");
>> > +   return -EPROBE_DEFER;
>> > +   }
>> >
>> > if ((drv->bus->probe && drv->probe) ||
>> > (drv->bus->remove && drv->remove) ||
>> >
>> > I'm not actually proposing this change; just responding to your question.
>>
>> The bus_type.p field may be unused by some bus drivers, hence this
>> would prevent their drivers from being registered.
>
> bus_type.p is an internal-to-the-driver-core structure, no bus driver
> should ever be touching it.  This is a catch to see if someone is using
> the driver core incorrectly.

Thanks, I stand corrected.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters

[Masahiro Yamada]

2018-05-07 16:39 GMT+09:00 Boris Brezillon :
> On Mon, 7 May 2018 12:40:39 +0900
> Masahiro Yamada  wrote:
>
>> 2018-05-03 21:20 GMT+09:00 Abhishek Sahu :
>> > commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
>> > match, maximize ECC settings") provides generic helpers which
>> > drivers can use for setting up ECC parameters.
>> >
>> > Since same board can have different ECC strength nand chips so
>> > following is the logic for setting up ECC strength and ECC step
>> > size, which can be used by most of the drivers.
>> >
>> > 1. If both ECC step size and ECC strength are already set
>> >(usually by DT) then just check whether this setting
>> >is supported by NAND controller.
>> > 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>> >supported by NAND controller.
>> > 3. Otherwise, try to match the ECC step size and ECC strength closest
>> >to the chip's requirement. If available OOB size can't fit the chip
>> >requirement then select maximum ECC strength which can be fit with
>> >available OOB size with warning.
>> >
>> > This patch introduces nand_ecc_param_setup function which calls the
>> > required helper functions for the above logic. The drivers can use
>> > this single function instead of calling the 3 helper functions
>> > individually.
>> >
>> > CC: Masahiro Yamada 
>> > Signed-off-by: Abhishek Sahu 
>> > ---
>> > * Changes from v1:
>> >
>> >   NEW PATCH
>> >
>> >  drivers/mtd/nand/raw/nand_base.c | 42 
>> > 
>> >  include/linux/mtd/rawnand.h  |  3 +++
>> >  2 files changed, 45 insertions(+)
>> >
>> > diff --git a/drivers/mtd/nand/raw/nand_base.c 
>> > b/drivers/mtd/nand/raw/nand_base.c
>> > index 72f3a89..dd7a984 100644
>> > --- a/drivers/mtd/nand/raw/nand_base.c
>> > +++ b/drivers/mtd/nand/raw/nand_base.c
>> > @@ -6249,6 +6249,48 @@ int nand_maximize_ecc(struct nand_chip *chip,
>> >  }
>> >  EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>> >
>> > +/**
>> > + * nand_ecc_param_setup - Set the ECC strength and ECC step size
>> > + * @chip: nand chip info structure
>> > + * @caps: ECC engine caps info structure
>> > + * @oobavail: OOB size that the ECC engine can use
>> > + *
>> > + * Choose the ECC strength according to following logic
>> > + *
>> > + * 1. If both ECC step size and ECC strength are already set (usually by 
>> > DT)
>> > + *then check if it is supported by this controller.
>> > + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
>> > + * 3. Otherwise, try to match the ECC step size and ECC strength closest
>> > + *to the chip's requirement. If available OOB size can't fit the chip
>> > + *requirement then fallback to the maximum ECC step size and ECC 
>> > strength
>> > + *and print the warning.
>> > + *
>> > + * On success, the chosen ECC settings are set.
>> > + */
>> > +int nand_ecc_param_setup(struct nand_chip *chip,
>> > +const struct nand_ecc_caps *caps, int oobavail)
>> > +{
>> > +   int ret;
>> > +
>> > +   if (chip->ecc.size && chip->ecc.strength)
>> > +   return nand_check_ecc_caps(chip, caps, oobavail);
>> > +
>> > +   if (chip->ecc.options & NAND_ECC_MAXIMIZE)
>> > +   return nand_maximize_ecc(chip, caps, oobavail);
>> > +
>> > +   if (!nand_match_ecc_req(chip, caps, oobavail))
>> > +   return 0;
>> > +
>> > +   ret = nand_maximize_ecc(chip, caps, oobavail);
>>
>>
>> Why two calls for nand_maximize_ecc()?
>
> As long as the code does the same thing, I don't care that much.
>
>>
>> My code is simpler,
>
> and I don't see how your code is simpler. Mainly a matter of taste
> AFAICS.
>
>> and does not display
>> false-positive warning.
>
> I agree on the false-positive warning though, this should be avoided.
>
>>
>>
>> > +   if (!ret)
>> > +   pr_warn("ECC (step, strength) = (%d, %d) not supported on 
>> > this controller. Fallback to (%d, %d)\n",
>> > +   chip->ecc_step_ds, chip->ecc_strength_ds,
>> > +   chip->ecc.size, chip->ecc.strength);
>>
>>
>> This is annoying.
>>
>> {ecc_step_ds, ecc_strength_ds} are not provided by Non-ONFi devices.
>>
>> So,
>>   ECC (step, strength) = (0, 0) not supported on this controller.
>
> Well, if you have a chip that requires ECC but exposes 0bits/0bytes
> then this should be fixed. 0,0 should only be valid when the chip does
> not require ECC at all (so, only really old chips). For all other chips,
> including non-ONFI ones, we should have a valid value here.


Sorry, it was my misunderstanding.

My NAND chip is Toshiba.

If I remember correctly, Toshiba chips were not set
with ECC requirements in the past,
but as far as I tested the latest kernel now,
the ECC requirement was set by
drivers/mtd/nand/raw/nand_toshiba.c





>>
>> will be always displayed.
>>
>>
>> The strength will be checked by nand_ecc_strength_good() anyway.
>
> True. So, I agree that the pr_warn() is unneeded, bu

[PATCH] media: i2c: tda1997: Fix an error handling path 'tda1997x_probe()'

[Christophe JAILLET]

If 'media_entity_pads_init()' fails, we must free the resources allocated
by 'v4l2_ctrl_handler_init()', as already done in the previous error
handling path.

'goto' the right label to fix it.

Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver")
Signed-off-by: Christophe JAILLET 
---
 drivers/media/i2c/tda1997x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
index 31bdab96f380..039a92c3294a 100644
--- a/drivers/media/i2c/tda1997x.c
+++ b/drivers/media/i2c/tda1997x.c
@@ -2723,7 +2723,7 @@ static int tda1997x_probe(struct i2c_client *client,
state->pads);
if (ret) {
v4l_err(client, "failed entity_init: %d", ret);
-   goto err_free_mutex;
+   goto err_free_handler;
}
 
ret = v4l2_async_register_subdev(sd);
-- 
2.17.0

Re: [PATCH v3 0/4] Better integrate seccomp logging and auditing

[Paul Moore]

On Sun, May 6, 2018 at 7:36 PM, Kees Cook  wrote:
> On Sun, May 6, 2018 at 2:31 PM, Paul Moore  wrote:
>> On Thu, May 3, 2018 at 9:08 PM, Tyler Hicks  wrote:
>>> Seccomp received improved logging controls in v4.14. Applications can opt 
>>> into
>>> logging of "handled" actions (SECCOMP_RET_TRAP, SECCOMP_RET_TRACE,
>>> SECCOMP_RET_ERRNO) using the SECCOMP_FILTER_FLAG_LOG bit when loading 
>>> filters.
>>> They can also debug filter matching with the new SECCOMP_RET_LOG action.
>>> Administrators can prevent specific actions from being logged using the
>>> kernel.seccomp.actions_logged sysctl.
>>>
>>> However, one corner case intentionally wasn't addressed in those v4.14 
>>> changes.
>>> When a process is being inspected by the audit subsystem, seccomp's decision
>>> making for logging ignores the new controls and unconditionally logs every
>>> action taken except for SECCOMP_RET_ALLOW. This isn't particularly useful 
>>> since
>>> many existing applications don't intend to log handled actions due to them
>>> occurring very frequently. This amount of logging fills the audit logs 
>>> without
>>> providing many benefits now that application authors have fine grained 
>>> controls
>>> at their disposal.
>>>
>>> This patch set aligns the seccomp logging behavior for both audited and
>>> non-audited processes. It also emits an audit record, if auditing is 
>>> enabled,
>>> when the kernel.seccomp.actions_logged sysctl is written to so that there's 
>>> a
>>> paper trail when entire actions are quieted.
>>>
>>> Changes in v3:
>>> * Patch 3
>>>   - Never drop a field when emitting the audit record
>>>   - Use the value "?" for the actions field when an error occurred while
>>> writing to the sysctl
>>>   - Use the value "?" for the actions and/or old-actions fields when a 
>>> failure
>>> to translate actions to names
>>>   - Use the value "(none)" for the actions and/or old-actions fields when no
>>> actions are specified
>>> + This is possible when writing an empty string to the sysctl
>>>   - Update the commit message to note the new values and give an example of
>>> when an empty string is written
>>> * Patch 4
>>>   - Adjust the control flow of seccomp_log() to exit early if nothing 
>>> should be
>>> logged
>>>
>>> Changes in v2:
>>> * Patch 2
>>>   - New patch, allowing for a configurable separator between action names
>>> * Patch 3
>>>   - The value of the actions field in the audit record now uses a comma 
>>> instead
>>> of a space
>>>   - The value of the actions field in the audit record is no longer 
>>> enclosed in
>>> quotes
>>>   - audit_log_start() is called with the current processes' audit_context in
>>> audit_seccomp_actions_logged()
>>>   - audit_seccomp_actions_logged() no longer records the pid, uid, auid, 
>>> tty,
>>> ses, task context, comm, or executable path
>>>   - The new and old value of seccomp_actions_logged is recorded in the
>>> AUDIT_CONFIG_CHANGE record
>>>   - The value of the "res" field in the CONFIG_CHANGE audit record is 
>>> corrected
>>> (1 indicates success, 0 failure)
>>>   - Updated patch 3's commit message to reflect the updated audit record 
>>> format
>>> in the examples
>>> * Patch 4
>>>   - A function comment for audit_seccomp() was added to explain, among other
>>> things, that event filtering is performed in seccomp_log()
>>
>> Kees, are you still okay with v3?  Also, are you okay with these
>> patches going in via the audit tree, or would you prefer to take them
>> via seccomp?  I've got a slight preference for the audit tree myself,
>> but as I said before, as long as it hits Linus' tree I'm happy.
>
> Yup, it looks good. I have no tree preference, so you win! :) Please
> consider the whole series:
>
> Acked-by: Kees Cook 

Merged into audit/next, thanks guys.

-- 
paul moore
www.paul-moore.com

[PATCH] f2fs: fix to let checkpoint guarantee atomic page persistence

[Chao Yu]

1. thread A: commit_inmem_pages submit data into block layer, but
haven't waited it writeback.
2. thread A: commit_inmem_pages update related node.
3. thread B: do checkpoint, flush all nodes to disk.
4. SPOR

Then, atomic file becomes corrupted since nodes is flushed before data.

This patch fixes to treat atomic page as checkpoint guaranteed one,
then in checkpoint, we can make sure all atomic page can be writebacked
with metadata of atomic file.

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 778b23fce4fa..734be00fab3a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -45,6 +45,8 @@ static bool __is_cp_guaranteed(struct page *page)
if (inode->i_ino == F2FS_META_INO(sbi) ||
inode->i_ino ==  F2FS_NODE_INO(sbi) ||
S_ISDIR(inode->i_mode) ||
+   (S_ISREG(inode->i_mode) &&
+   is_inode_flag_set(inode, FI_ATOMIC_FILE)) ||
is_cold_data(page))
return true;
return false;
-- 
2.17.0.391.g1f1cddd558b5

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

[Chao Yu]

On 2018/5/8 11:31, Jaegeuk Kim wrote:
> On 05/08, Chao Yu wrote:
>> On 2018/5/8 4:46, Jaegeuk Kim wrote:
>>> On 04/27, Chao Yu wrote:
 On 2018/4/27 0:36, Jaegeuk Kim wrote:
> On 04/26, Chao Yu wrote:
>> On 2018/4/26 23:48, Jaegeuk Kim wrote:
>>> On 04/26, Chao Yu wrote:
 Thread A   Thread B
 - f2fs_ioc_commit_atomic_write
  - commit_inmem_pages
   - f2fs_submit_merged_write_cond
   : write data
- write_checkpoint
 - do_checkpoint
 : commit all node within CP
 -> SPO
   - f2fs_do_sync_file
- file_write_and_wait_range
: wait data writeback

 In above race condition, data/node can be flushed in reversed order 
 when
 coming a checkpoint before f2fs_do_sync_file, after SPOR, it results in
 atomic written data being corrupted.
>>>
>>> Wait, what is the problem here? Thread B could succeed checkpoint, 
>>> there is
>>> no problem. If it fails, there is no fsync mark where we can recover 
>>> it, so
>>
>> Node is flushed by checkpoint before data, with reversed order, that's 
>> the problem.
>
> What do you mean? Data should be in disk, in order to proceed checkpoint.

 1. thread A: commit_inmem_pages submit data into block layer, but haven't 
 waited
 it writeback.
 2. thread A: commit_inmem_pages update related node.
 3. thread B: do checkpoint, flush all nodes to disk
>>>
>>> How about, in block_operations(),
>>>
>>> down_read_trylock(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
>>> if (fail)
>>> wait_on_all_pages_writeback(F2FS_WB_DATA);
>>> else
>>> up_read(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
>>
>> I sent one patch for that, could you check it?
>>
>> Adding wait_on_all_pages_writeback in block_operations() can make 
>> checkpoint()
>> wait pages writeback one more time, which break IO flow, so what's your 
>> concern
>> here?
> 
> Performance. And I can see wait_on_all_pages_writeback() waits only for
> F2FS_WB_CP_DATA in checkpoint()?

Oh, you mean wait all F2FS_WB_DATA pages writeback, what about just treating
atomic write page as F2FS_WB_CP_DATA, and we can wait atomic pages in
wait_on_all_pages_writeback() in do_checkpoitn().

Thanks,

> 
> 
>>
>> Thanks,
>>
>>>
>>>
 4. SPOR

 Then, atomic file becomes corrupted since nodes is flushed before data.

 Thanks,

>
>>
>> Thanks,
>>
>>> we can just ignore the last written data as nothing.
>>>

 This patch adds f2fs_wait_on_page_writeback in __revoke_inmem_pages() 
 to
 keep data and node of atomic file being flushed orderly.

 Signed-off-by: Chao Yu 
 ---
  fs/f2fs/file.c| 4 
  fs/f2fs/segment.c | 3 +++
  2 files changed, 7 insertions(+)

 diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
 index be7578774a47..a352804af244 100644
 --- a/fs/f2fs/file.c
 +++ b/fs/f2fs/file.c
 @@ -217,6 +217,9 @@ static int f2fs_do_sync_file(struct file *file, 
 loff_t start, loff_t end,
  
trace_f2fs_sync_file_enter(inode);
  
 +  if (atomic)
 +  goto write_done;
 +
/* if fdatasync is triggered, let's do in-place-update */
if (datasync || get_dirty_pages(inode) <= 
 SM_I(sbi)->min_fsync_blocks)
set_inode_flag(inode, FI_NEED_IPU);
 @@ -228,6 +231,7 @@ static int f2fs_do_sync_file(struct file *file, 
 loff_t start, loff_t end,
return ret;
}
  
 +write_done:
/* if the inode is dirty, let's recover all the time */
if (!f2fs_skip_inode_update(inode, datasync)) {
f2fs_write_inode(inode, NULL);
 diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
 index 584483426584..9ca3d0a43d93 100644
 --- a/fs/f2fs/segment.c
 +++ b/fs/f2fs/segment.c
 @@ -230,6 +230,8 @@ static int __revoke_inmem_pages(struct inode 
 *inode,
  
lock_page(page);
  
 +  f2fs_wait_on_page_writeback(page, DATA, true);
 +
if (recover) {
struct dnode_of_data dn;
struct node_info ni;
 @@ -415,6 +417,7 @@ static int __commit_inmem_pages(struct inode 
 *inode)
/* drop all uncommitted pages */
__revoke_inmem_pages(inode, &fi->inmem_pages, true, 
 false);
} else {
>>

Re: BUG: spinlock bad magic in tun_do_read

[Eric Dumazet]

On 05/07/2018 10:54 PM, Cong Wang wrote:
> On Mon, May 7, 2018 at 10:27 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:75bc37fefc44 Linux 4.17-rc4
>> git tree:   upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1162c69780
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
>> dashboard link: https://syzkaller.appspot.com/bug?extid=e8b902c3c3fadf0a9dba
>> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>> userspace arch: i386
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172e4c9780
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+e8b902c3c3fadf0a9...@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> IPVS: ftp: loaded support on port[0] = 21
>> BUG: spinlock bad magic on CPU#0, syz-executor0/4586
>>  lock: 0x8801ae8928c8, .magic: , .owner: /-1, .owner_cpu:
>> 0
>> CPU: 0 PID: 4586 Comm: syz-executor0 Not tainted 4.17.0-rc4+ #62
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>  spin_dump+0x160/0x169 kernel/locking/spinlock_debug.c:67
>>  spin_bug kernel/locking/spinlock_debug.c:75 [inline]
>>  debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
>>  do_raw_spin_lock.cold.3+0x37/0x3c kernel/locking/spinlock_debug.c:112
>>  __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
>>  _raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:144
>>  spin_lock include/linux/spinlock.h:310 [inline]
>>  ptr_ring_consume include/linux/ptr_ring.h:335 [inline]
>>  tun_ring_recv drivers/net/tun.c:2143 [inline]
> 
> Yeah, we should return early before hitting this uninitialized ptr ring...
> Something like:
> 
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index ef33950a45d9..638c87a95247 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -2128,6 +2128,9 @@ static void *tun_ring_recv(struct tun_file
> *tfile, int noblock, int *err)
> void *ptr = NULL;
> int error = 0;
> 
> +   if (!tfile->tx_ring.queue)
> +   goto out;
> +
> 
> Or, checking if tun is detached...
> 
>

tx_ring was properly initialized when first ptr_ring_consume() at line 2131 was 
attempted.

The bug happens later at line 2143 , after a schedule() call, line 2155

So a single check at function prologue wont solve the case the thread had to 
sleep,
then some uninit happened.

Re: Kernel build with gcc 8 a lot of warnings

[Greg KH]

On Tue, May 08, 2018 at 07:51:26AM +0200, Greg KH wrote:
> On Sun, May 06, 2018 at 11:54:53PM -0500, Josh Poimboeuf wrote:
> > On Sat, May 05, 2018 at 09:21:12PM +0200, damian wrote:
> > > Helllo together,
> > > 
> > > Hello everybody,
> > > 
> > > is something special to note when kernel build with gcc 8? I receive 
> > > various warnings from the objtool:
> > > With GCC 7 works all fine.
> > > 
> > > kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: 
> > > sibling call from callable instruction with modified stack frame
> > > kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: 
> > > sibling call from callable instruction with modified stack frame
> > > kernel/cgroup/cgroup.o: warning: objtool: 
> > > cgroup_apply_control_enable()+0x20b: sibling call from callable 
> > > instruction with modified stack frame
> > > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: 
> > > sibling call from callable instruction with modified stack frame
> > > kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: 
> > > sibling call from callable instruction with modified stack frame
> > > kernel/cgroup/cgroup.o: warning: objtool: 
> > > parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer 
> > > save/setup
> > > kernel/cgroup/cgroup.o: warning: objtool: 
> > > cgroup_addrm_files.cold.46()+0x17: call without frame pointer save/setup
> > > kernel/cgroup/cgroup.o: warning: objtool: 
> > > cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer 
> > > save/setup
> > > kernel/cgroup/cgroup.o: warning: objtool: 
> > > rebind_subsystems.cold.48()+0x10: call without frame pointer save/setup
> > > kernel/cgroup/cgroup.o: warning: objtool: 
> > > cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer 
> > > save/setup
> > >   CC  kernel/cgroup/stat.o
> > >   CC [M]  arch/x86/kvm/../../../virt/kvm/kvm_main.o
> > > arch/x86/kernel/acpi/boot.o: warning: objtool: 
> > > acpi_register_lapic()+0x10: sibling call from callable instruction with 
> > > modified stack frame
> > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: 
> > > sibling call from callable instruction with modified stack frame
> > > arch/x86/kernel/acpi/boot.o: warning: objtool: 
> > > acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup
> > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: 
> > > call without frame pointer save/setup
> > 
> > Thanks, this is a known issue with GCC 8 that I haven't gotten a chance
> > to fix yet.  They're related to the fact that GCC 8 is splitting out
> > 'unlikely' code into 'cold' subfunctions in .text.unlikely.
> > 
> > I've got some old patches that fix it.  Now that GCC 8 is out, I'll need
> > get the patches dusted off and cleaned up for merging.
> 
> Any pointers to these patches?  Archi linux just changed their default
> compiler to gcc 8 and now I'm seeing this in my local builds :(

s/Archi/Arch/

ugh, time for more coffee...

Re: BUG: spinlock bad magic in tun_do_read

[Cong Wang]

On Mon, May 7, 2018 at 10:27 PM, syzbot
 wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:75bc37fefc44 Linux 4.17-rc4
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1162c69780
> kernel config:  https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
> dashboard link: https://syzkaller.appspot.com/bug?extid=e8b902c3c3fadf0a9dba
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> userspace arch: i386
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172e4c9780
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e8b902c3c3fadf0a9...@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> IPVS: ftp: loaded support on port[0] = 21
> BUG: spinlock bad magic on CPU#0, syz-executor0/4586
>  lock: 0x8801ae8928c8, .magic: , .owner: /-1, .owner_cpu:
> 0
> CPU: 0 PID: 4586 Comm: syz-executor0 Not tainted 4.17.0-rc4+ #62
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  spin_dump+0x160/0x169 kernel/locking/spinlock_debug.c:67
>  spin_bug kernel/locking/spinlock_debug.c:75 [inline]
>  debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
>  do_raw_spin_lock.cold.3+0x37/0x3c kernel/locking/spinlock_debug.c:112
>  __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
>  _raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:144
>  spin_lock include/linux/spinlock.h:310 [inline]
>  ptr_ring_consume include/linux/ptr_ring.h:335 [inline]
>  tun_ring_recv drivers/net/tun.c:2143 [inline]

Yeah, we should return early before hitting this uninitialized ptr ring...
Something like:

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ef33950a45d9..638c87a95247 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2128,6 +2128,9 @@ static void *tun_ring_recv(struct tun_file
*tfile, int noblock, int *err)
void *ptr = NULL;
int error = 0;

+   if (!tfile->tx_ring.queue)
+   goto out;
+

Or, checking if tun is detached...


>  tun_do_read+0x18b1/0x29f0 drivers/net/tun.c:2182
>  tun_chr_read_iter+0xe5/0x1e0 drivers/net/tun.c:2214
>  call_read_iter include/linux/fs.h:1778 [inline]
>  new_sync_read fs/read_write.c:406 [inline]
>  __vfs_read+0x696/0xa50 fs/read_write.c:418
>  vfs_read+0x17f/0x3d0 fs/read_write.c:452
>  ksys_pread64+0x174/0x1a0 fs/read_write.c:626
>  __do_compat_sys_x86_pread arch/x86/ia32/sys_ia32.c:177 [inline]
>  __se_compat_sys_x86_pread arch/x86/ia32/sys_ia32.c:174 [inline]
>  __ia32_compat_sys_x86_pread+0xc4/0x130 arch/x86/ia32/sys_ia32.c:174
>  do_syscall_32_irqs_on arch/x86/entry/common.c:323 [inline]
>  do_fast_syscall_32+0x345/0xf9b arch/x86/entry/common.c:394
>  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> RIP: 0023:0xf7fc0cb9
> RSP: 002b:f7fbc0ac EFLAGS: 0282 ORIG_RAX: 00b4
> RAX: ffda RBX: 0003 RCX: 2080
> RDX: 006e RSI:  RDI: 
> RBP:  R08:  R09: 
> R10:  R11: 0292 R12: 
> R13:  R14:  R15: 
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.

Re: Kernel build with gcc 8 a lot of warnings

[Greg KH]

On Sun, May 06, 2018 at 11:54:53PM -0500, Josh Poimboeuf wrote:
> On Sat, May 05, 2018 at 09:21:12PM +0200, damian wrote:
> > Helllo together,
> > 
> > Hello everybody,
> > 
> > is something special to note when kernel build with gcc 8? I receive 
> > various warnings from the objtool:
> > With GCC 7 works all fine.
> > 
> > kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: 
> > sibling call from callable instruction with modified stack frame
> > kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: 
> > sibling call from callable instruction with modified stack frame
> > kernel/cgroup/cgroup.o: warning: objtool: 
> > cgroup_apply_control_enable()+0x20b: sibling call from callable instruction 
> > with modified stack frame
> > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: 
> > sibling call from callable instruction with modified stack frame
> > kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: 
> > sibling call from callable instruction with modified stack frame
> > kernel/cgroup/cgroup.o: warning: objtool: 
> > parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup
> > kernel/cgroup/cgroup.o: warning: objtool: 
> > cgroup_addrm_files.cold.46()+0x17: call without frame pointer save/setup
> > kernel/cgroup/cgroup.o: warning: objtool: 
> > cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer 
> > save/setup
> > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: 
> > call without frame pointer save/setup
> > kernel/cgroup/cgroup.o: warning: objtool: 
> > cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup
> >   CC  kernel/cgroup/stat.o
> >   CC [M]  arch/x86/kvm/../../../virt/kvm/kvm_main.o
> > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: 
> > sibling call from callable instruction with modified stack frame
> > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling 
> > call from callable instruction with modified stack frame
> > arch/x86/kernel/acpi/boot.o: warning: objtool: 
> > acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup
> > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: 
> > call without frame pointer save/setup
> 
> Thanks, this is a known issue with GCC 8 that I haven't gotten a chance
> to fix yet.  They're related to the fact that GCC 8 is splitting out
> 'unlikely' code into 'cold' subfunctions in .text.unlikely.
> 
> I've got some old patches that fix it.  Now that GCC 8 is out, I'll need
> get the patches dusted off and cleaned up for merging.

Any pointers to these patches?  Archi linux just changed their default
compiler to gcc 8 and now I'm seeing this in my local builds :(

thanks,

greg k-h

[PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

[Chao Yu]

Thread AThread B
- f2fs_remount
 - stop_gc_thread
- f2fs_sbi_store
   sbi->gc_thread = NULL;
  access sbi->gc_thread->gc_*

Previously, we allocate memory for sbi->gc_thread based on background
gc thread mount option, the memory can be released if we turn off
that mount option, but still there are several places access gc_thread
pointer without considering race condition, result in NULL point
dereference.

In order to fix this issue, use sb->s_umount to exclude those operations.

Signed-off-by: Chao Yu 
---
v2:
- fix to cover __struct_ptr() with sb->s_umount suggested by Jaegeuk.
 fs/f2fs/sysfs.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 7432192ebe17..79f4e4ac8200 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -168,7 +168,7 @@ static ssize_t f2fs_sbi_show(struct f2fs_attr *a,
return snprintf(buf, PAGE_SIZE, "%u\n", *ui);
 }
 
-static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
+static ssize_t __f2fs_sbi_store(struct f2fs_attr *a,
struct f2fs_sb_info *sbi,
const char *buf, size_t count)
 {
@@ -261,6 +261,22 @@ static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
return count;
 }
 
+static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
+   struct f2fs_sb_info *sbi,
+   const char *buf, size_t count)
+{
+   ssize_t ret;
+   bool gc_entry = (a->struct_type == GC_THREAD);
+
+   if (gc_entry)
+   down_read(&sbi->sb->s_umount);
+   ret = __f2fs_sbi_store(a, sbi, buf, count);
+   if (gc_entry)
+   up_read(&sbi->sb->s_umount);
+
+   return ret;
+}
+
 static ssize_t f2fs_attr_show(struct kobject *kobj,
struct attribute *attr, char *buf)
 {
-- 
2.17.0.391.g1f1cddd558b5

[PATCH] iw_cxgb4: Fix an error handling path in 'c4iw_get_dma_mr()'

[Christophe JAILLET]

The error handling path of 'c4iw_get_dma_mr()' does not free resources
in the correct order.
If an error occures, it can leak 'mhp->wr_waitp'.

Fixes: a3f12da0e99a ("iw_cxgb4: allocate wait object for each memory object")
Signed-off-by: Christophe JAILLET 
---
 drivers/infiniband/hw/cxgb4/mem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb4/mem.c 
b/drivers/infiniband/hw/cxgb4/mem.c
index e90f2fd8dc16..1445918e3239 100644
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -489,10 +489,10 @@ struct ib_mr *c4iw_get_dma_mr(struct ib_pd *pd, int acc)
 err_dereg_mem:
dereg_mem(&rhp->rdev, mhp->attr.stag, mhp->attr.pbl_size,
  mhp->attr.pbl_addr, mhp->dereg_skb, mhp->wr_waitp);
-err_free_wr_wait:
-   c4iw_put_wr_wait(mhp->wr_waitp);
 err_free_skb:
kfree_skb(mhp->dereg_skb);
+err_free_wr_wait:
+   c4iw_put_wr_wait(mhp->wr_waitp);
 err_free_mhp:
kfree(mhp);
return ERR_PTR(ret);
-- 
2.17.0

Re: [PATCH 0/3] scsi: arcmsr: Add driver parameter cmd_timeout for scsi command timeout setting

[Martin K. Petersen]

Hello Ching,

> 1. Add driver parameter cmd_timeout, default value is ARCMSR_DEFAULT_TIMEOUT.
> 2. Add slave_configure callback function to set device command timeout value.
> 3. Update driver version to v1.40.00.06-20180504.

I am not so keen on arcmsr overriding the timeout set by the admin or
application.

Also, instead of introducing this module parameter, why not simply ask
the user to change rq_timeout?

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

[Baolin Wang]

From: Xiaotong Lu 

This patch adds Spreadtrum SC27xx PMIC series breathing light controller
driver, which can support 3 LEDs. Each LED can work at normal PWM mode
and breathing mode.

Signed-off-by: Xiaotong Lu 
Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Add ABI documentation.
 - Add mutex protection in case of concurrent access.
 - Change the LED device name pattern.
 - Fix build warning.
---
 .../ABI/testing/sysfs-class-led-driver-sc27xx  |   19 +
 drivers/leds/Kconfig   |   11 +
 drivers/leds/Makefile  |1 +
 drivers/leds/leds-sc27xx-bltc.c|  387 
 4 files changed, 418 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
 create mode 100644 drivers/leds/leds-sc27xx-bltc.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx 
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..22166fb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,19 @@
+What:  /sys/class/leds//rise_time
+What:  /sys/class/leds//high_time
+What:  /sys/class/leds//fall_time
+What:  /sys/class/leds//low_time
+Date:  May 2018
+KernelVersion: 4.18
+Contact:   Xiaotong Lu 
+Description:
+   Set the pattern generator rise, high, fall and low
+   times (0..63). It's unit is 0.125s, it should be > 0.
+
+   1 - 125 ms
+   2 - 250 ms
+   3 - 375 ms
+   ...
+   ...
+   ...
+   62 - 7.75 s
+   63 - 7.875 s
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0..319449b 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -647,6 +647,17 @@ config LEDS_IS31FL32XX
  LED controllers. They are I2C devices with multiple constant-current
  channels, each with independent 256-level PWM control.
 
+config LEDS_SC27XX_BLTC
+   tristate "LED support for the SC27xx breathing light controller"
+   depends on LEDS_CLASS && MFD_SC27XX_PMIC
+   depends on OF
+   help
+ Say Y here to include support for the SC27xx breathing light 
controller
+ LEDs.
+
+ This driver can also be built as a module. If so the module will be
+ called leds-sc27xx-bltc.
+
 comment "LED driver for blink(1) USB RGB LED is under Special HID drivers 
(HID_THINGM)"
 
 config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81..ff6917e 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
 obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
 obj-$(CONFIG_LEDS_MT6323)  += leds-mt6323.o
 obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
new file mode 100644
index 000..61c5b72
--- /dev/null
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -0,0 +1,387 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Spreadtrum Communications Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PMIC global control register definition */
+#define SC27XX_MODULE_EN0  0xc08
+#define SC27XX_CLK_EN0 0xc18
+#define SC27XX_RGB_CTRL0xebc
+
+#define SC27XX_BLTC_EN BIT(9)
+#define SC27XX_RTC_EN  BIT(7)
+#define SC27XX_RGB_PD  BIT(0)
+
+/* Breathing light controller register definition */
+#define SC27XX_LEDS_CTRL   0x00
+#define SC27XX_LEDS_PRESCALE   0x04
+#define SC27XX_LEDS_DUTY   0x08
+#define SC27XX_LEDS_CURVE0 0x0c
+#define SC27XX_LEDS_CURVE1 0x10
+
+#define SC27XX_CTRL_SHIFT  4
+#define SC27XX_LED_RUN BIT(0)
+#define SC27XX_LED_TYPEBIT(1)
+
+#define SC27XX_DUTY_SHIFT  8
+#define SC27XX_DUTY_MASK   GENMASK(15, 0)
+#define SC27XX_MOD_MASKGENMASK(7, 0)
+
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
+#define SC27XX_LEDS_OFFSET 0x10
+#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_TIME_MAX   63
+
+/*
+ * The SC27xx breathing light controller can support 3 outputs: red LED,
+ * green LED and blue LED. Each LED can support normal PWM mode and breathing
+ * mode.
+ *
+ * In breathing mode, the LED output curve includes rise, high, fall and low 4
+ * stages, and the duration of each stage is configurable.
+ */
+enum sc27xx_led_config {
+   SC27XX_RISE_TIME,
+   SC27XX_FALL_TIME,
+   SC27XX_HIGH_TIME,
+   SC27XX_LOW_TIME,
+};
+
+struct sc27xx_led {
+   char name[LED_MAX_NAME_SIZE];
+   struct led_classde

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

[Jason Wang]

On 2018年05月08日 11:05, Jason Wang wrote:


Because in virtqueue_enable_cb_delayed(), we may set an
event_off which is bigger than new and both of them have
wrapped. And in this case, although new is smaller than
event_off (i.e. the third param -- old), new shouldn't
add vq->num, and actually we are expecting a very big
idx diff.


Yes, so to calculate distance correctly between event and new, we just 
need to compare the warp counter and return false if it doesn't match 
without the need to try to add vq.num here.


Thanks 


Sorry, looks like the following should work, we need add vq.num if 
used_wrap_counter does not match:


static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
                      __u16 off_wrap, __u16 new,
                      __u16 old)
{
    bool wrap = off_wrap >> 15;
    int off = off_wrap & ~(1 << 15);
    __u16 d1, d2;

    if (wrap != vq->used_wrap_counter)
        d1 = new + vq->num - off - 1;
    else
        d1 = new - off - 1;

    if (new > old)
        d2 = new - old;
    else
        d2 = new + vq->num - old;

    return d1 < d2;
}

Thanks

[PATCH v2 1/2] dt-bindings: leds: Add SC27xx breathing light controller documentation

[Baolin Wang]

This patch adds the binding documentation for Spreadtrum SC27xx series
breathing light controller, which supports 3 outputs: red LED, green
LED and blue LED.

Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Change the compatible string to be one explicit SoC name.
 - Change the child node name.
 - Change to be upper case for the first character.
---
 .../devicetree/bindings/leds/leds-sc27xx-bltc.txt  |   41 
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt 
b/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt
new file mode 100644
index 000..b3de7fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt
@@ -0,0 +1,41 @@
+LEDs connected to Spreadtrum SC27XX PMIC breathing light controller
+
+The SC27xx breathing light controller supports to 3 outputs:
+red LED, green LED and blue LED. Each LED can work at normal
+PWM mode or breath light mode.
+
+Required properties:
+- compatible: Should be "sprd,sc2731-bltc".
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- reg: Specify controller address.
+
+Required child properties:
+- reg: Number of LED line (could be from 0 to 2).
+
+Optional child properties:
+- label: See Documentation/devicetree/bindings/leds/common.txt.
+
+Examples:
+
+led-controller@200 {
+   compatible = "sprd,sc2731-bltc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x200>;
+
+   led@0 {
+   label = "red";
+   reg = <0x0>;
+   };
+
+   led@1 {
+   label = "green";
+   reg = <0x1>;
+   };
+
+   led@2 {
+   label = "blue";
+   reg = <0x2>;
+   };
+};
-- 
1.7.9.5

Re: [PATCH v2] scsi: 3w-9xxx: fix a missing-check bug

[Martin K. Petersen]

Wenwen,

> In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the
> userspace pointer 'argp' and saved to the kernel object 'driver_command'.
> Then a security check is performed on the data buffer size indicated by
> 'driver_command', which is 'driver_command.buffer_length'. If the security
> check is passed, the entire ioctl command is copied again from the 'argp'
> pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
> are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
> pointer resides in userspace, a malicious userspace process can race to
> change the buffer size between the two copies. This way, the user can
> bypass the security check and inject invalid data buffer size. This can
> cause potential security issues in the following execution.
>
> This patch checks for capable(CAP_SYS_ADMIN) in twa_chrdev_open()t o avoid
> the above issues.

Applied patch 1 + 2 to 4.18/scsi-queue. Thank you.

-- 
Martin K. Petersen  Oracle Linux Engineering

[lkp-robot] [EXP rcu] 21560e1007: WARNING:possible_recursive_locking_detected

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: 21560e10077bf9f7baf69aa82527850271173862 ("EXP rcu: Diagnostics for 
grace-period hangs")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
dev.2018.05.01a

in testcase: ebizzy
with following parameters:

nr_threads: 200%
iterations: 100x
duration: 10s

test-description: ebizzy is designed to generate a workload resembling common 
web application server workloads.
test-url: http://ebizzy.sourceforge.net/


on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -m 1G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | ed569311d8 | 21560e1007 |
+-+++
| boot_successes  | 4  | 4  |
| boot_failures   | 8  | 8  |
| invoked_oom-killer:gfp_mask=0x  | 8  ||
| Mem-Info| 8  ||
| Out_of_memory:Kill_process  | 8  ||
| WARNING:possible_recursive_locking_detected | 0  | 8  |
| RIP:arch_local_irq_restore  | 0  | 5  |
| BUG:kernel_hang_in_boot_stage   | 0  | 8  |
| RIP:__mutex_unlock_slowpath | 0  | 1  |
| RIP:kernfs_activate | 0  | 1  |
| RIP:debug_lockdep_rcu_enabled   | 0  | 1  |
+-+++



[2.079791] WARNING: possible recursive locking detected
[2.08] 4.17.0-rc1-00048-g21560e1 #1 Not tainted
[2.08] 
[2.08] swapper/0/1 is trying to acquire lock:
[2.08] 7895dd2f (rcu_node_0){..-.}, at: 
rcu_process_callbacks+0x4b3/0xa28
[2.08] 
[2.08] but task is already holding lock:
[2.08] 7895dd2f (rcu_node_0){..-.}, at: 
rcu_process_callbacks+0x3cf/0xa28
[2.08] 
[2.08] other info that might help us debug this:
[2.08]  Possible unsafe locking scenario:
[2.08] 
[2.08]CPU0
[2.08]
[2.08]   lock(rcu_node_0);
[2.08]   lock(rcu_node_0);
[2.08] 
[2.08]  *** DEADLOCK ***
[2.08] 
[2.08]  May be due to missing lock nesting notation
[2.08] 
[2.08] 1 lock held by swapper/0/1:
[2.08]  #0: 7895dd2f (rcu_node_0){..-.}, at: 
rcu_process_callbacks+0x3cf/0xa28
[2.08] 
[2.08] stack backtrace:
[2.08] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.17.0-rc1-00048-g21560e1 #1
[2.08] Call Trace:
[2.08]  
[2.08]  dump_stack+0x117/0x182
[2.08]  validate_chain+0x8d4/0xec0
[2.08]  ? lookup_chain_cache+0x4a/0x9c
[2.08]  ? validate_chain+0x9e/0xec0
[2.08]  ? lookup_chain_cache+0x4a/0x9c
[2.08]  ? lookup_chain_cache+0x4a/0x9c
[2.08]  ? lookup_chain_cache+0x4a/0x9c
[2.08]  ? __lock_acquire+0x8ed/0x9da
[2.08]  __lock_acquire+0x8ed/0x9da
[2.08]  lock_acquire+0x9e/0xcd
[2.08]  ? rcu_process_callbacks+0x4b3/0xa28
[2.08]  _raw_spin_lock_irqsave+0x60/0x88
[2.08]  ? rcu_process_callbacks+0x4b3/0xa28
[2.08]  rcu_process_callbacks+0x4b3/0xa28
[2.08]  ? kvm_clock_read+0x2f/0x45
[2.08]  ? kvm_sched_clock_read+0xc/0x1b
[2.08]  ? paravirt_sched_clock+0xc/0x16
[2.08]  ? sched_clock+0xc/0x14
[2.08]  ? sched_clock_local+0x10/0xb8
[2.08]  __do_softirq+0x134/0x303
[2.08]  irq_exit+0x92/0x143
[2.08]  smp_apic_timer_interrupt+0xb9/0xcb
[2.08]  apic_timer_interrupt+0xf/0x20
[2.08]  
[2.08] RIP: 0010:arch_local_irq_restore+0x9/0x16
[2.08] RSP: :88000fe63ce0 EFLAGS: 0206 ORIG_RAX: 
ff13
[2.08] RAX: 88000fe58040 RBX: 0206 RCX: 88000fe63b1c
[2.08] RDX: 0001 RSI: 0001 RDI: 0206
[2.08] RBP: 8800346be9b8 R08: 8800346beba8 R09: 000100080005
[2.08] R10: 88000fe63ce8 R11:  R12: 014080c0
[2.08] R13: 812c4f20 R14: 88000fcac5c0 R15: 
[2.08]  ? __kernfs_new_node+0x56/0x177
[2.08]  __slab_alloc+0xa1/0xb2
[2.08]  ? __kernfs_new_node+0x56/0x177
[2.08]  kmem_cache_alloc+0xe6/0x12c
[2.08]  __kernfs_new_node+0x56/0x177
[2.08]  kernfs_new_node+0x1d/0x4e
[2.08]  __kernfs_create_file+0x38/0x11c
[2.08]  sysfs_add_file_mode_ns+0x10a/0x238
[2.08]  internal_create_grou

Re: [PATCH v2 2/2] pinctrl: generic: improve apply_setting error verbosity

[Matheus Castello]

Hi Linus,

thanks for the tips, I will study this to break dependency from OF.

Best Regards,
Matheus Castello

On 05/02/2018 08:51 AM, Linus Walleij wrote:

On Tue, May 1, 2018 at 9:10 PM, Matheus Castello
 wrote:


For generic pinconf: print the dev_error with the pinctrl vendor
driver name, error code, the sub-node property name used and the
pin that was tried to set.

Improves the undestading of the error if use a generic sub-node
property that generic-pinconf can do parse but the vendor pinctrl
driver does not support.

Signed-off-by: Matheus Castello 



+#include 
  #include "core.h"
  #include "pinconf.h"

@@ -169,9 +170,21 @@ int pinconf_apply_setting(const struct pinctrl_setting 
*setting)
 setting->data.configs.configs,
 setting->data.configs.num_configs);
 if (ret < 0) {
+#ifdef CONFIG_OF


This doesn't seem right.

If this is restricted for OF only the root cause to why it is
like that needs to be found and the code refactored to fit anyone,
there is also ACPI support in the works I think, surely they should
be able to get verbose messages.


 dev_err(pctldev->dev,
-   "pin_config_set op failed for pin %d\n",
+   "%s error %d setting %s for pin %d\n",
+   pctldev->desc->name, ret,
+   pinconf_generic_get_param_property_name(
+   pctldev, 
setting->data.configs.num_configs,
+   setting->data.configs.configs),
 setting->data.configs.group_or_pin);


This doesn't seem right. First argument is a %d, yet this
is pctldev->desc->name?

Something is fishy with the argument list.

Yours,
Linus Walleij

Re: [PATCH] scsi: mptsas: fix spelling mistake: "matchs" -> "matches"

[Martin K. Petersen]

Colin,

> Trivial fix to spelling mistake in warning message

Applied to 4.18/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH][V2] scsi: lpfc: fix spelling mistakes: "mabilbox" and "maibox"

[Martin K. Petersen]

Colin,

> Trivial fix to spelling mistakes in lpfc_printf_log log message
>
> "mabilbox" -> "mailbox"
> "maibox" -> "mailbox"

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

BUG: spinlock bad magic in tun_do_read

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:75bc37fefc44 Linux 4.17-rc4
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1162c69780
kernel config:  https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
dashboard link: https://syzkaller.appspot.com/bug?extid=e8b902c3c3fadf0a9dba
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172e4c9780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e8b902c3c3fadf0a9...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
IPVS: ftp: loaded support on port[0] = 21
BUG: spinlock bad magic on CPU#0, syz-executor0/4586
 lock: 0x8801ae8928c8, .magic: , .owner: /-1, .owner_cpu:  
0

CPU: 0 PID: 4586 Comm: syz-executor0 Not tainted 4.17.0-rc4+ #62
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 spin_dump+0x160/0x169 kernel/locking/spinlock_debug.c:67
 spin_bug kernel/locking/spinlock_debug.c:75 [inline]
 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
 do_raw_spin_lock.cold.3+0x37/0x3c kernel/locking/spinlock_debug.c:112
 __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
 _raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:144
 spin_lock include/linux/spinlock.h:310 [inline]
 ptr_ring_consume include/linux/ptr_ring.h:335 [inline]
 tun_ring_recv drivers/net/tun.c:2143 [inline]
 tun_do_read+0x18b1/0x29f0 drivers/net/tun.c:2182
 tun_chr_read_iter+0xe5/0x1e0 drivers/net/tun.c:2214
 call_read_iter include/linux/fs.h:1778 [inline]
 new_sync_read fs/read_write.c:406 [inline]
 __vfs_read+0x696/0xa50 fs/read_write.c:418
 vfs_read+0x17f/0x3d0 fs/read_write.c:452
 ksys_pread64+0x174/0x1a0 fs/read_write.c:626
 __do_compat_sys_x86_pread arch/x86/ia32/sys_ia32.c:177 [inline]
 __se_compat_sys_x86_pread arch/x86/ia32/sys_ia32.c:174 [inline]
 __ia32_compat_sys_x86_pread+0xc4/0x130 arch/x86/ia32/sys_ia32.c:174
 do_syscall_32_irqs_on arch/x86/entry/common.c:323 [inline]
 do_fast_syscall_32+0x345/0xf9b arch/x86/entry/common.c:394
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7fc0cb9
RSP: 002b:f7fbc0ac EFLAGS: 0282 ORIG_RAX: 00b4
RAX: ffda RBX: 0003 RCX: 2080
RDX: 006e RSI:  RDI: 
RBP:  R08:  R09: 
R10:  R11: 0292 R12: 
R13:  R14:  R15: 


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

Re: [PATCH] scsi: qla2xxx: remove the unused tcm_qla2xxx_cmd_wq

[Martin K. Petersen]

Andrei,

Applied to 4.18/scsi-queue. thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/7] cifs: smbd: Make upper layer decide when to destroy the transport

[kbuild test robot]

Hi Long,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on cifs/for-next]
[also build test ERROR on v4.17-rc4 next-20180507]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Long-Li/cifs-smbd-Make-upper-layer-decide-when-to-destroy-the-transport/20180508-110150
base:   git://git.samba.org/sfrench/cifs-2.6.git for-next
config: i386-randconfig-x013-201818 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   fs//cifs/connect.c: In function 'cifs_reconnect':
>> fs//cifs/connect.c:381:16: error: passing argument 1 of 'smbd_destroy' from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
  smbd_destroy(server);
   ^~
   In file included from fs//cifs/connect.c:58:0:
   fs//cifs/smbdirect.h:334:20: note: expected 'struct smbd_connection *' but 
argument is of type 'struct TCP_Server_Info *'
static inline void smbd_destroy(struct smbd_connection *info) {}
   ^~~~
   fs//cifs/connect.c: In function 'clean_demultiplex_info':
   fs//cifs/connect.c:715:16: error: passing argument 1 of 'smbd_destroy' from 
incompatible pointer type [-Werror=incompatible-pointer-types]
  smbd_destroy(server);
   ^~
   In file included from fs//cifs/connect.c:58:0:
   fs//cifs/smbdirect.h:334:20: note: expected 'struct smbd_connection *' but 
argument is of type 'struct TCP_Server_Info *'
static inline void smbd_destroy(struct smbd_connection *info) {}
   ^~~~
   Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read
   Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write
   Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:set_bit
   Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:clear_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:test_and_set_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
   Cyclomatic Complexity 1 
include/uapi/linux/byteorder/little_endian.h:__le16_to_cpup
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/list.h:__list_add_valid
   Cyclomatic Complexity 1 include/linux/list.h:__list_del_entry_valid
   Cyclomatic Complexity 2 include/linux/list.h:__list_add
   Cyclomatic Complexity 1 include/linux/list.h:list_add
   Cyclomatic Complexity 1 include/linux/list.h:__list_del
   Cyclomatic Complexity 2 include/linux/list.h:__list_del_entry
   Cyclomatic Complexity 1 include/linux/list.h:list_del_init
   Cyclomatic Complexity 1 include/linux/list.h:list_move
   Cyclomatic Complexity 1 include/linux/list.h:list_empty
   Cyclomatic Complexity 1 arch/x86/include/asm/current.h:get_current
   Cyclomatic Complexity 1 include/linux/string.h:strnlen
   Cyclomatic Complexity 4 include/linux/string.h:strlen
   Cyclomatic Complexity 6 include/linux/string.h:strlcpy
   Cyclomatic Complexity 3 include/linux/string.h:memset
   Cyclomatic Complexity 4 include/linux/string.h:memcpy
   Cyclomatic Complexity 2 include/linux/string.h:strcpy
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_read
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_inc
   Cyclomatic Complexity 1 
arch/x86/include/asm/atomic.h:arch_atomic_dec_and_test
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_add_return
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_sub_return
   Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_read
   Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_inc
   Cyclomatic Complexity 1 
include/asm-generic/atomic-instrumented.h:atomic_inc_return
   Cyclomatic Complexity 1 
include/asm-generic/atomic-instrumented.h:atomic_dec_return
   Cyclomatic Complexity 1 
include/asm-generic/atomic-instrumented.h:atomic_dec_and_test
   Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
   Cyclomatic Complexity 1 include/linux/spinlock.h:s

Re: [PATCH] scsi: mptfusion: fix spelling mistake: "initators" -> "initiators"

[Martin K. Petersen]

Colin,

> Trivial fix to spelling mistake in text string

Applied to 4.18/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

linux-next: Tree for May 8

[Stephen Rothwell]

Hi all,

Changes since 20180507:

The pci tree gained a conflict against the dma-mapping tree.

The bpf-next tree gained a conflict against the s390 tree.

The drm-intel tree gained a build failure due to an interaction with
the dma-mapping tree for which I applied a merge fix patch.

Non-merge commits (relative to Linus' tree): 4364
 4203 files changed, 168450 insertions(+), 78362 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 257 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f142f08bf7ec Fix typo in comment.)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (0da7e4326114 genksyms: fix typo in 
parse.tab.{c,h} generation rules)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (3789c122d0a0 arm64: avoid instrumenting 
atomic_ll_sc.o)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (b2d7ecbe3556 powerpc/kvm/booke: Fix altivec 
related build break)
Merging sparc/master (fff75eb2a08c Merge tag 'errseq-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (d2fcd01335ac Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging bpf/master (2ba5622fba85 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
Merging ipsec/master (b4331a681822 vti6: Change minimum MTU to IPV4_MIN_MTU, 
vti6 can carry IPv4 too)
Merging netfilter/master (2f99aa31cd7a netfilter: nf_tables: skip 
synchronize_rcu if transaction log is empty)
Merging ipvs/master (2f99aa31cd7a netfilter: nf_tables: skip synchronize_rcu if 
transaction log is empty)
Merging wireless-drivers/master (a8d7aa17bbc9 dccp: fix tasklet usage)
Merging mac80211/master (914eac248d87 mac80211: use timeout from the AddBA 
response instead of the request)
Merging rdma-fixes/for-rc (9aa169213d11 RDMA/cma: Do not query GID during QP 
state transition to RTR)
Merging sound-current/for-linus (f13876e2c33a ALSA: pcm: Check PCM state at 
xfern compat ioctl)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (6da6c0db5316 Linux v4.17-rc3)
Merging tty.current/tty-linus (6da6c0db5316 Linux v4.17-rc3)
Merging usb.current/usb-linus (6844dc42722c Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (ed769520727e usb: gadget: composite Allow for 
larger configuration descriptors)
Merging usb-serial-fixes/usb-linus (4842ed5bfcb9 USB: serial: visor: handle 
potential invalid device configuration)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1)
Merging staging.current/staging-linus (6da6c0

Re: [PATCH] mptlan: fix mpt_lan_sdu_send()'s return type

[Martin K. Petersen]

Luc,

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.

You forgot to update the function prototype accordingly.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 00/11] hisi_sas: some misc patches

[Martin K. Petersen]

John,

> This patchset introduces some misc changes for the
> driver. These include:
> - fixes for potential problems related to SCSI EH
>   and device removal races
> - fix protection info size for all hw versions
> - some SoC bug workarounds
> - minor optimisations
> - other more minor things

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2 15/35] ovl: add ovl_fsync()

[Amir Goldstein]

On Mon, May 7, 2018 at 11:37 AM, Miklos Szeredi  wrote:
> Implement stacked fsync().
>
> Signed-off-by: Miklos Szeredi 
> ---
>  fs/overlayfs/file.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
> index a7af56861aa5..419aa3f9967b 100644
> --- a/fs/overlayfs/file.c
> +++ b/fs/overlayfs/file.c
> @@ -233,10 +233,30 @@ static ssize_t ovl_write_iter(struct kiocb *iocb, 
> struct iov_iter *iter)
> return ret;
>  }
>
> +static int ovl_fsync(struct file *file, loff_t start, loff_t end, int 
> datasync)
> +{
> +   struct fd real;
> +   const struct cred *old_cred;
> +   int ret;
> +

Don't sync non-upper. same as ovl_dir_fsync()

Thanks,
Amir.

Re: [PATCH v3 2/2] usb: dwc2: fix isoc split in transfer with no data

[Doug Anderson]

Hi,

On Mon, May 7, 2018 at 8:07 PM, William Wu  wrote:
> If isoc split in transfer with no data (the length of DATA0
> packet is zero), we can't simply return immediately. Because
> the DATA0 can be the first transaction or the second transaction
> for the isoc split in transaction. If the DATA0 packet with no
> data is in the first transaction, we can return immediately.
> But if the DATA0 packet with no data is in the second transaction
> of isoc split in transaction sequence, we need to increase the
> qtd->isoc_frame_index and giveback urb to device driver if needed,
> otherwise, the MDATA packet will be lost.
>
> A typical test case is that connect the dwc2 controller with an
> usb hs Hub (GL852G-12), and plug an usb fs audio device (Plantronics
> headset) into the downstream port of Hub. Then use the usb mic
> to record, we can find noise when playback.
>
> In the case, the isoc split in transaction sequence like this:
>
> - SSPLIT IN transaction
> - CSPLIT IN transaction
>   - MDATA packet (176 bytes)
> - CSPLIT IN transaction
>   - DATA0 packet (0 byte)
>
> This patch use both the length of DATA0 and qtd->isoc_split_offset
> to check if the DATA0 is in the second transaction.
>
> Signed-off-by: William Wu 
> ---
> Changes in v3:
> - Remove "qtd->isoc_split_offset = 0" in the if test
>
> Changes in v2:
> - Modify the commit message
>
>  drivers/usb/dwc2/hcd_intr.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
> index ba6fd852..3003594 100644
> --- a/drivers/usb/dwc2/hcd_intr.c
> +++ b/drivers/usb/dwc2/hcd_intr.c
> @@ -930,9 +930,8 @@ static int dwc2_xfercomp_isoc_split_in(struct dwc2_hsotg 
> *hsotg,
> frame_desc = &qtd->urb->iso_descs[qtd->isoc_frame_index];
> len = dwc2_get_actual_xfer_length(hsotg, chan, chnum, qtd,
>   DWC2_HC_XFER_COMPLETE, NULL);
> -   if (!len) {
> +   if (!len && !qtd->isoc_split_offset) {
> qtd->complete_split = 0;
> -   qtd->isoc_split_offset = 0;
> return 0;
> }

This looks fine to me now, but as per my comments on the previous
version I don't think I've dug through this problem enough to add my
Reviewed-by tag.  I'll assume that John or someone with more knowledge
of the USB protocol than I have will Review / Ack.


-Doug

[lkp-robot] [rcu] 6ec8474821: WARNING:at_kernel/softirq.c:#__local_bh_enable_ip

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: 6ec84748215d9b0c91dba0b8674540e493ce2dcf ("rcu: Make simple callback 
acceleration refer to rdp->gp_seq_needed")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
dev.2018.05.01a

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 7b05a33e23 | 6ec8474821 |
+---+++
| boot_successes| 1097   | 186|
| boot_failures | 42 | 34 |
| BUG:kernel_reboot-without-warning_in_test_stage   | 7  ||
| BUG:kernel_hang_in_test_stage | 17 ||
| IP-Config:Auto-configuration_of_network_failed| 18 | 22 |
| WARNING:at_kernel/softirq.c:#__local_bh_enable_ip | 0  | 34 |
| RIP:__local_bh_enable_ip  | 0  | 34 |
| RIP:rcu_gp_kthread| 0  | 4  |
| RIP:_raw_spin_unlock_irq  | 0  | 25 |
| RIP:_raw_spin_lock_irq| 0  | 1  |
| RIP:lock_is_held_type | 0  | 1  |
| RIP:rcu_dynticks_curr_cpu_in_eqs  | 0  | 1  |
+---+++



[   12.277264] WARNING: CPU: 0 PID: 10 at kernel/softirq.c:161 
__local_bh_enable_ip+0x5c/0xc4
[   12.280239] Modules linked in:
[   12.281495] CPU: 0 PID: 10 Comm: rcu_sched Not tainted 
4.17.0-rc1-00087-g6ec8474 #126
[   12.284043] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   12.286752] RIP: 0010:__local_bh_enable_ip+0x5c/0xc4
[   12.288514] RSP: :8d3a59c03e98 EFLAGS: 00010086
[   12.290002] RAX:  RBX: 0201 RCX: 0007
[   12.291862] RDX:  RSI: 8d3a59dd5840 RDI: 8d3a59dd5840
[   12.294071] RBP: 90121558 R08: aefba407 R09: 0004
[   12.295877] R10: 8d3a580c0040 R11: 0001 R12: 9011fbb0
[   12.297673] R13: 000a R14: 91a82480 R15: 8d3a59de2f00
[   12.299577] FS:  () GS:8d3a59c0() 
knlGS:
[   12.302107] CS:  0010 DS:  ES:  CR0: 80050033
[   12.303787] CR2: 0808f132 CR3: 1474 CR4: 06f0
[   12.305657] Call Trace:
[   12.306655]  
[   12.307753]  rcu_do_batch+0x71d/0x9cf
[   12.308979]  ? note_gp_changes+0x6d/0xaf
[   12.310446]  rcu_process_callbacks+0x445/0x575
[   12.311979]  __do_softirq+0x1fe/0x416
[   12.313211]  irq_exit+0x59/0xa8
[   12.314652]  smp_apic_timer_interrupt+0x285/0x290
[   12.316044]  apic_timer_interrupt+0xf/0x20
[   12.317368]  
[   12.318299] RIP: 0010:lock_is_held_type+0x4b/0x56
[   12.319727] RSP: :b2344011be78 EFLAGS: 0246 ORIG_RAX: 
ff13
[   12.322324] RAX:  RBX: 8d3a580c0040 RCX: 0001
[   12.324382] RDX:  RSI:  RDI: 0246
[   12.326314] RBP: 8d3a59de2f00 R08: aefba407 R09: 0004
[   12.328220] R10: 8d3a580c0040 R11: 0001 R12: 5494
[   12.330233] R13: 5401 R14: 0246 R15: 91a82900
[   12.332240]  rcu_read_lock_sched_held+0x51/0x57
[   12.333721]  rcu_gp_kthread+0x11b/0x13b7
[   12.335271]  ? rcu_sched_get_gp_seq+0x11/0x11
[   12.336784]  kthread+0x124/0x12c
[   12.338005]  ? kthread_create_on_node+0x62/0x62
[   12.339539]  ret_from_fork+0x3a/0x50
[   12.340915] Code: 08 00 00 00 75 27 83 b8 50 08 00 00 00 75 1e 80 3d 8c 9b 
b3 01 00 75 15 48 c7 c7 74 b3 80 91 c6 05 7c 9b b3 01 01 e8 1b 94 ff ff <0f> 0b 
fa 66 0f 1f 44 00 00 e8 e1 83 04 00 65 8b 05 12 4d f6 6f 
[   12.346330] irq event stamp: 150667
[   12.347696] hardirqs last  enabled at (150666): [] 
note_gp_changes+0x6d/0xaf
[   12.350360] hardirqs last disabled at (150667): [] 
rcu_process_callbacks+0x257/0x575
[   12.353207] softirqs last  enabled at (148284): [] 
__do_softirq+0x3da/0x416
[   12.357175] softirqs last disabled at (150649): [] 
irq_exit+0x59/0xa8
[   12.359963] ---[ end trace 72bef54097ed5232 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.17.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-6

Re: [PATCH v3 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

[Doug Anderson]

Hi,

On Mon, May 7, 2018 at 8:07 PM, William Wu  wrote:
> +static int dwc2_alloc_split_dma_aligned_buf(struct dwc2_hsotg *hsotg,
> +   struct dwc2_qh *qh,
> +   struct dwc2_host_chan *chan)
> +{
> +   if (!hsotg->unaligned_cache)
> +   return -ENOMEM;
> +
> +   if (!qh->dw_align_buf) {
> +   qh->dw_align_buf = kmem_cache_alloc(hsotg->unaligned_cache,
> +   GFP_ATOMIC | GFP_DMA);
> +   if (!qh->dw_align_buf)
> +   return -ENOMEM;
> +
> +   qh->dw_align_buf_size = min_t(u32, chan->max_packet,
> + DWC2_KMEM_UNALIGNED_BUF_SIZE);

Rather than using min_t, wouldn't it be better to return -ENOMEM if
"max_packet" > DWC2_KMEM_UNALIGNED_BUF_SIZE?  As it is, you might
allocate less space than you need, right?  That seems like it would be
bad (even though this is probably impossible).


> @@ -2797,6 +2837,32 @@ static int dwc2_assign_and_init_hc(struct dwc2_hsotg 
> *hsotg, struct dwc2_qh *qh)
> /* Set the transfer attributes */
> dwc2_hc_init_xfer(hsotg, chan, qtd);
>
> +   /* For non-dword aligned buffers */
> +   if (hsotg->params.host_dma && qh->do_split &&
> +   chan->ep_is_in && (chan->xfer_dma & 0x3)) {
> +   dev_vdbg(hsotg->dev, "Non-aligned buffer\n");
> +   if (dwc2_alloc_split_dma_aligned_buf(hsotg, qh, chan)) {
> +   dev_err(hsotg->dev,
> +   "Failed to allocate memory to handle 
> non-aligned buffer\n");
> +   /* Add channel back to free list */
> +   chan->align_buf = 0;
> +   chan->multi_count = 0;
> +   list_add_tail(&chan->hc_list_entry,
> + &hsotg->free_hc_list);
> +   qtd->in_process = 0;
> +   qh->channel = NULL;
> +   return -ENOMEM;
> +   }
> +   } else {
> +   /*
> +* We assume that DMA is always aligned in non-split
> +* case or split out case. Warn if not.
> +*/
> +   WARN_ON_ONCE(hsotg->params.host_dma &&
> +(chan->xfer_dma & 0x3));
> +   chan->align_buf = 0;
> +   }
> +
> if (chan->ep_type == USB_ENDPOINT_XFER_INT ||
> chan->ep_type == USB_ENDPOINT_XFER_ISOC)
> /*
> @@ -5241,6 +5307,17 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
> hsotg->params.dma_desc_enable = false;
> hsotg->params.dma_desc_fs_enable = false;
> }
> +   } else if (hsotg->params.host_dma) {

Are you sure this is "else if"?  Can't you have descriptor DMA enabled
in the controller and still need to do a normal DMA transfer if you
plug in a hub?  Seems like this should be just "if".


> +   /*
> +* Create kmem caches to handle non-aligned buffer
> +* in Buffer DMA mode.
> +*/
> +   hsotg->unaligned_cache = 
> kmem_cache_create("dwc2-unaligned-dma",
> +   DWC2_KMEM_UNALIGNED_BUF_SIZE, 
> 4,

Worth using "DWC2_USB_DMA_ALIGN" rather than 4?


> +   SLAB_CACHE_DMA, NULL);
> +   if (!hsotg->unaligned_cache)
> +   dev_err(hsotg->dev,
> +   "unable to create dwc2 unaligned cache\n");
> }
>
> hsotg->otg_port = 1;
> @@ -5279,6 +5356,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
>  error4:
> kmem_cache_destroy(hsotg->desc_gen_cache);
> kmem_cache_destroy(hsotg->desc_hsisoc_cache);
> +   kmem_cache_destroy(hsotg->unaligned_cache);

nitty nit: freeing order should be opposite of allocation, so the new
line should be above the other two.

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

[Eric Dumazet]

On 05/07/2018 07:16 PM, Jia-Ju Bai wrote:

> Yes, "&dev->stats" will not change, because it is a fixed address.
> But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors 
> and rx_missed_errors).
> So if the driver returns "&dev->stats" without lock protection (like on line 
> 858), the field data value of this return value can be the changed field data 
> value or unchanged field data value.


We do not care.

This function can be called by multiple cpus at the same time.

As soon as one cpu returns from it, another cpu can happily modify 
dev->stats.ANYFIELD.

Your patch fixes nothing at all.

Re: [PATCH v1 0/2] Add QCOM video clock controller driver

[Amit Nischal]

On 2018-05-07 22:41, Rob Herring wrote:

On Mon, May 07, 2018 at 04:16:53PM +0530, Amit Nischal wrote:

On 2018-05-04 22:01, Stephen Boyd wrote:
> Quoting Amit Nischal (2018-05-03 05:35:23)
> > Changes in v1:
> >https://lkml.org/lkml/2018/4/24/545
> > Addressed below review comments given by Rob
> > - Change the compatible property as per ',-'
> > format.
> > - Add header definitions for resets and power-domain cells.
>
> You didn't add any reset definitions though?

We haven't added the reset definitions for videocc as there is no
video reset client.


So? You don't know what resets there are?



We know the resets, but video driver doesn't do any block resets
prior to accessing the video subsystem so that's the reason we do
not want to expose the resets in videocc driver.


Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-clk" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bug in tag handling in blk-mq?

[Mike Galbraith]

On Mon, 2018-05-07 at 20:02 +0200, Paolo Valente wrote:
> 
> 
> > Is there a reproducer?

Just building fat config kernels works for me.  It was highly non-
deterministic, but reproduced quickly twice in a row with Paolos hack.
  
> Ok Mike, I guess it's your turn now, for at least a stack trace.

Sure.  I'm deadlined ATM, but will get to it.

-Mike

Re: [PATCH] PM / devfreq: Drop custom MIN/MAX macros

[Chanwoo Choi]

Hi,

On 2018년 04월 25일 04:46, Bjorn Andersson wrote:
> Drop the custom MIN/MAX macros in favour of the standard min/max from
> kernel.h
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/devfreq/devfreq.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index fe2af6aa88fc..2067cd229ce3 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -28,9 +28,6 @@
>  #include 
>  #include "governor.h"
>  
> -#define MAX(a,b) ((a > b) ? a : b)
> -#define MIN(a,b) ((a < b) ? a : b)
> -
>  static struct class *devfreq_class;
>  
>  /*
> @@ -280,8 +277,8 @@ int update_devfreq(struct devfreq *devfreq)
>* max_freq
>* min_freq
>*/
> - max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
> - min_freq = MAX(devfreq->scaling_min_freq, devfreq->min_freq);
> + max_freq = min(devfreq->scaling_max_freq, devfreq->max_freq);
> + min_freq = max(devfreq->scaling_min_freq, devfreq->min_freq);
>  
>   if (min_freq && freq < min_freq) {
>   freq = min_freq;
> @@ -1149,7 +1146,7 @@ static ssize_t min_freq_show(struct device *dev, struct 
> device_attribute *attr,
>  {
>   struct devfreq *df = to_devfreq(dev);
>  
> - return sprintf(buf, "%lu\n", MAX(df->scaling_min_freq, df->min_freq));
> + return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq));
>  }
>  
>  static ssize_t max_freq_store(struct device *dev, struct device_attribute 
> *attr,
> @@ -1185,7 +1182,7 @@ static ssize_t max_freq_show(struct device *dev, struct 
> device_attribute *attr,
>  {
>   struct devfreq *df = to_devfreq(dev);
>  
> - return sprintf(buf, "%lu\n", MIN(df->scaling_max_freq, df->max_freq));
> + return sprintf(buf, "%lu\n", min(df->scaling_max_freq, df->max_freq));
>  }
>  static DEVICE_ATTR_RW(max_freq);
>  
> 

Reviewed-by: Chanwoo Choi 

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH V4 10/10] ASoC: amd: dma driver changes for bt i2s instance

[Vijendar Mukunda]

With in ACP, There are three I2S controllers can be
configured/enabled ( I2S SP, I2S MICSP, I2S BT).
Default enabled I2S controller instance is I2S SP.
This patch provides required changes to support I2S BT
controller Instance.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
v1->v2: defined i2s instance macros in acp header file
v2->v3: sqaushed previous patch series and spilt changes
into multiple patches (acp dma driver code cleanup
patches and bt i2s instance specific changes)
v3->v4: Fixed checkpatch.pl error
 sound/soc/amd/acp-da7219-max98357a.c |  24 
 sound/soc/amd/acp-pcm-dma.c  | 256 +++
 sound/soc/amd/acp.h  |  40 ++
 3 files changed, 263 insertions(+), 57 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index 133139d..ccddc66 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 
+#include "acp.h"
 #include "../codecs/da7219.h"
 #include "../codecs/da7219-aad.h"
 
@@ -44,6 +45,7 @@
 
 static struct snd_soc_jack cz_jack;
 static struct clk *da7219_dai_clk;
+extern int bt_uart_enable;
 
 static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
 {
@@ -132,6 +134,9 @@ static const struct snd_pcm_hw_constraint_list 
constraints_channels = {
 static int cz_da7219_startup(struct snd_pcm_substream *substream)
 {
struct snd_pcm_runtime *runtime = substream->runtime;
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_card *card = rtd->card;
+   struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
 
/*
 * On this platform for PCM device we support stereo
@@ -143,6 +148,7 @@ static int cz_da7219_startup(struct snd_pcm_substream 
*substream)
snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
   &constraints_rates);
 
+   machine->i2s_instance = I2S_BT_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -153,6 +159,11 @@ static void cz_da7219_shutdown(struct snd_pcm_substream 
*substream)
 
 static int cz_max_startup(struct snd_pcm_substream *substream)
 {
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_card *card = rtd->card;
+   struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
+
+   machine->i2s_instance = I2S_SP_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -163,6 +174,11 @@ static void cz_max_shutdown(struct snd_pcm_substream 
*substream)
 
 static int cz_dmic_startup(struct snd_pcm_substream *substream)
 {
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_card *card = rtd->card;
+   struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
+
+   machine->i2s_instance = I2S_SP_INSTANCE;
return da7219_clk_enable(substream);
 }
 
@@ -266,10 +282,16 @@ static int cz_probe(struct platform_device *pdev)
 {
int ret;
struct snd_soc_card *card;
+   struct acp_platform_info *machine;
 
+   machine = devm_kzalloc(&pdev->dev, sizeof(struct acp_platform_info),
+  GFP_KERNEL);
+   if (!machine)
+   return -ENOMEM;
card = &cz_card;
cz_card.dev = &pdev->dev;
platform_set_drvdata(pdev, card);
+   snd_soc_card_set_drvdata(card, machine);
ret = devm_snd_soc_register_card(&pdev->dev, &cz_card);
if (ret) {
dev_err(&pdev->dev,
@@ -277,6 +299,8 @@ static int cz_probe(struct platform_device *pdev)
cz_card.name, ret);
return ret;
}
+   bt_uart_enable = !device_property_read_bool(&pdev->dev,
+   "bt-pad-enable");
return 0;
 }
 
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index ec9cab3..906eb77 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -37,12 +37,14 @@
 #define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define MIN_BUFFER MAX_BUFFER
 
-#define ST_PLAYBACK_MAX_PERIOD_SIZE 8192
+#define ST_PLAYBACK_MAX_PERIOD_SIZE 4096
 #define ST_CAPTURE_MAX_PERIOD_SIZE  ST_PLAYBACK_MAX_PERIOD_SIZE
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
 #define DRV_NAME "acp_audio_dma"
+bool bt_uart_enable = true;
+EXPORT_SYMBOL(bt_uart_enable);
 
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
@@ -357,6 +359,9 @@ static void acp_dma_start(void __iomem *acp_mmio,
case ACP_TO_I2S_DMA_CH_NUM:
case ACP_TO_SYSRAM_CH_NUM:
case I2S_TO_ACP_DMA_CH_NUM:
+   case ACP_TO_I2S_DMA_BT_INSTANCE_CH_NUM:
+   case ACP_TO_SYSRAM_BT_INSTANCE_CH_NUM:
+   cas

[PATCH 09/10] ASoC: AMD: Add const to snd_soc_ops instances

[Vijendar Mukunda]

From: Akshu Agrawal 

Marking snd_soc_ops instances const

Signed-off-by: Akshu Agrawal 
Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
 sound/soc/amd/acp-da7219-max98357a.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index fa5ad5b..133139d 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -171,17 +171,17 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
da7219_clk_disable();
 }
 
-static struct snd_soc_ops cz_da7219_cap_ops = {
+static const struct snd_soc_ops cz_da7219_cap_ops = {
.startup = cz_da7219_startup,
.shutdown = cz_da7219_shutdown,
 };
 
-static struct snd_soc_ops cz_max_play_ops = {
+static const struct snd_soc_ops cz_max_play_ops = {
.startup = cz_max_startup,
.shutdown = cz_max_shutdown,
 };
 
-static struct snd_soc_ops cz_dmic_cap_ops = {
+static const struct snd_soc_ops cz_dmic_cap_ops = {
.startup = cz_dmic_startup,
.shutdown = cz_dmic_shutdown,
 };
-- 
2.7.4

[PATCH 08/10] ASoC: AMD: Fix clocks in CZ DA7219 machine driver

[Vijendar Mukunda]

From: Akshu Agrawal 

System clock on the platform is 25Mhz and not 24Mhz.

PLL_OUT for da7219 codec to use DA7219_PLL_FREQ_OUT_98304
as it is for 48KHz SR.

Signed-off-by: Akshu Agrawal 
Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
 sound/soc/amd/acp-da7219-max98357a.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index 6495eed..fa5ad5b 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -39,8 +39,7 @@
 #include "../codecs/da7219.h"
 #include "../codecs/da7219-aad.h"
 
-#define CZ_PLAT_CLK 2400
-#define MCLK_RATE 24576000
+#define CZ_PLAT_CLK 2500
 #define DUAL_CHANNEL   2
 
 static struct snd_soc_jack cz_jack;
@@ -63,7 +62,7 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
}
 
ret = snd_soc_dai_set_pll(codec_dai, 0, DA7219_SYSCLK_PLL,
- CZ_PLAT_CLK, MCLK_RATE);
+ CZ_PLAT_CLK, DA7219_PLL_FREQ_OUT_98304);
if (ret < 0) {
dev_err(rtd->dev, "can't set codec pll: %d\n", ret);
return ret;
-- 
2.7.4

[PATCH 07/10] ASoC: AMD: Move clk enable from hw_params/free to startup/shutdown

[Vijendar Mukunda]

From: Akshu Agrawal 

hw_param can be called multiple times and thus we can have
more clk enable. The clk may not get diabled due to refcounting.
startup/shutdown ensures single clk enable/disable call.

Signed-off-by: Akshu Agrawal 
Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
 sound/soc/amd/acp-da7219-max98357a.c | 49 +---
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index 215b06b..6495eed 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -91,8 +91,7 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
return 0;
 }
 
-static int cz_da7219_hw_params(struct snd_pcm_substream *substream,
-struct snd_pcm_hw_params *params)
+static int da7219_clk_enable(struct snd_pcm_substream *substream)
 {
int ret = 0;
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -106,11 +105,9 @@ static int cz_da7219_hw_params(struct snd_pcm_substream 
*substream,
return ret;
 }
 
-static int cz_da7219_hw_free(struct snd_pcm_substream *substream)
+static void da7219_clk_disable(void)
 {
clk_disable_unprepare(da7219_dai_clk);
-
-   return 0;
 }
 
 static const unsigned int channels[] = {
@@ -133,7 +130,7 @@ static const struct snd_pcm_hw_constraint_list 
constraints_channels = {
.mask = 0,
 };
 
-static int cz_fe_startup(struct snd_pcm_substream *substream)
+static int cz_da7219_startup(struct snd_pcm_substream *substream)
 {
struct snd_pcm_runtime *runtime = substream->runtime;
 
@@ -147,23 +144,47 @@ static int cz_fe_startup(struct snd_pcm_substream 
*substream)
snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
   &constraints_rates);
 
-   return 0;
+   return da7219_clk_enable(substream);
+}
+
+static void cz_da7219_shutdown(struct snd_pcm_substream *substream)
+{
+   da7219_clk_disable();
+}
+
+static int cz_max_startup(struct snd_pcm_substream *substream)
+{
+   return da7219_clk_enable(substream);
+}
+
+static void cz_max_shutdown(struct snd_pcm_substream *substream)
+{
+   da7219_clk_disable();
+}
+
+static int cz_dmic_startup(struct snd_pcm_substream *substream)
+{
+   return da7219_clk_enable(substream);
+}
+
+static void cz_dmic_shutdown(struct snd_pcm_substream *substream)
+{
+   da7219_clk_disable();
 }
 
 static struct snd_soc_ops cz_da7219_cap_ops = {
-   .hw_params = cz_da7219_hw_params,
-   .hw_free = cz_da7219_hw_free,
-   .startup = cz_fe_startup,
+   .startup = cz_da7219_startup,
+   .shutdown = cz_da7219_shutdown,
 };
 
 static struct snd_soc_ops cz_max_play_ops = {
-   .hw_params = cz_da7219_hw_params,
-   .hw_free = cz_da7219_hw_free,
+   .startup = cz_max_startup,
+   .shutdown = cz_max_shutdown,
 };
 
 static struct snd_soc_ops cz_dmic_cap_ops = {
-   .hw_params = cz_da7219_hw_params,
-   .hw_free = cz_da7219_hw_free,
+   .startup = cz_dmic_startup,
+   .shutdown = cz_dmic_shutdown,
 };
 
 static struct snd_soc_dai_link cz_dai_7219_98357[] = {
-- 
2.7.4

[PATCH 06/10] ASoC: amd: memory release for rtd structure

[Vijendar Mukunda]

rtd structure freed early may result in kernel panic in dma close
call back. moved releasing memory for rtd structure to the end of
dma close callback.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
 sound/soc/amd/acp-pcm-dma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 8236116..ec9cab3 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -998,8 +998,6 @@ static int acp_dma_close(struct snd_pcm_substream 
*substream)
DRV_NAME);
struct audio_drv_data *adata = dev_get_drvdata(component->dev);
 
-   kfree(rtd);
-
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
adata->play_i2ssp_stream = NULL;
/*
@@ -1028,7 +1026,7 @@ static int acp_dma_close(struct snd_pcm_substream 
*substream)
 */
if (!adata->play_i2ssp_stream && !adata->capture_i2ssp_stream)
acp_reg_write(0, adata->acp_mmio, mmACP_EXTERNAL_INTR_ENB);
-
+   kfree(rtd);
return 0;
 }
 
-- 
2.7.4

[PATCH 05/10] ASoC: amd: sram bank update changes

[Vijendar Mukunda]

Added sram bank variable to audio_substream_data structure.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
 sound/soc/amd/acp-pcm-dma.c | 20 +---
 sound/soc/amd/acp.h | 20 ++--
 2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 39597fb..8236116 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -320,29 +320,16 @@ static void config_acp_dma(void __iomem *acp_mmio,
   struct audio_substream_data *rtd,
   u32 asic_type)
 {
-   u32 sram_bank;
-
-   if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
-   sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
-   else {
-   switch (asic_type) {
-   case CHIP_STONEY:
-   sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
-   break;
-   default:
-   sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
-   }
-   }
acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
   rtd->pte_offset);
/* Configure System memory <-> ACP SRAM DMA descriptors */
set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
   rtd->direction, rtd->pte_offset,
-  rtd->ch1, sram_bank,
+  rtd->ch1, rtd->sram_bank,
   rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
-  rtd->direction, sram_bank,
+  rtd->direction, rtd->sram_bank,
   rtd->destination, rtd->ch2,
   rtd->dma_dscr_idx_2, asic_type);
 }
@@ -795,6 +782,7 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
}
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
+   rtd->sram_bank = ACP_SRAM_BANK_1_ADDRESS;
rtd->destination = TO_ACP_I2S_1;
rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
@@ -805,9 +793,11 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
switch (adata->asic_type) {
case CHIP_STONEY:
rtd->pte_offset = ACP_ST_CAPTURE_PTE_OFFSET;
+   rtd->sram_bank = ACP_SRAM_BANK_2_ADDRESS;
break;
default:
rtd->pte_offset = ACP_CAPTURE_PTE_OFFSET;
+   rtd->sram_bank = ACP_SRAM_BANK_5_ADDRESS;
}
rtd->ch1 = ACP_TO_SYSRAM_CH_NUM;
rtd->ch2 = I2S_TO_ACP_DMA_CH_NUM;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 2f48d1d..62695ed 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -19,12 +19,19 @@
 
 #define ACP_PHYSICAL_BASE  0x14000
 
-/* Playback SRAM address (as a destination in dma descriptor) */
-#define ACP_SHARED_RAM_BANK_1_ADDRESS  0x4002000
-
-/* Capture SRAM address (as a source in dma descriptor) */
-#define ACP_SHARED_RAM_BANK_5_ADDRESS  0x400A000
-#define ACP_SHARED_RAM_BANK_3_ADDRESS  0x4006000
+/*
+ * In case of I2S SP controller instance, Stoney uses SRAM bank 1 for
+ * playback and SRAM Bank 2 for capture where as in case of BT I2S
+ * Instance, Stoney uses SRAM Bank 3 for playback & SRAM Bank 4 will
+ * be used for capture. Carrizo uses I2S SP controller instance. SRAM Banks
+ * 1, 2, 3, 4 will be used for playback & SRAM Banks 5, 6, 7, 8 will be used
+ * for capture scenario.
+ */
+#define ACP_SRAM_BANK_1_ADDRESS0x4002000
+#define ACP_SRAM_BANK_2_ADDRESS0x4004000
+#define ACP_SRAM_BANK_3_ADDRESS0x4006000
+#define ACP_SRAM_BANK_4_ADDRESS0x4008000
+#define ACP_SRAM_BANK_5_ADDRESS0x400A000
 
 #define ACP_DMA_RESET_TIME 1
 #define ACP_CLOCK_EN_TIME_OUT_VALUE0x00FF
@@ -95,6 +102,7 @@ struct audio_substream_data {
u16 dma_dscr_idx_1;
u16 dma_dscr_idx_2;
u32 pte_offset;
+   u32 sram_bank;
u32 byte_cnt_high_reg_offset;
u32 byte_cnt_low_reg_offset;
uint64_t size;
-- 
2.7.4

[PATCH V2 04/10] ASoC: amd: pte offset related dma driver changes

[Vijendar Mukunda]

Added pte offset variable in audio_substream_data structure.
Added Stoney related PTE offset macros in acp header file.
Modified hw_params callback to assign the pte offset value
based on asic_type.
PTE Offset macros used to calculate no of PTE entries
need to be programmed when memory allocated for audio buffer.
Depending upon allocated audio buffer size, PTE offset values
will change.
Compared to CZ, Stoney has SRAM memory limitation i.e 48k
It is required to define separate PTE Offset macros for
Stoney.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
v1->v2: Modified commit message
 sound/soc/amd/acp-pcm-dma.c | 26 +++---
 sound/soc/amd/acp.h |  5 +
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 862c1cf..39597fb 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -320,13 +320,11 @@ static void config_acp_dma(void __iomem *acp_mmio,
   struct audio_substream_data *rtd,
   u32 asic_type)
 {
-   u32 pte_offset, sram_bank;
+   u32 sram_bank;
 
-   if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK) {
-   pte_offset = ACP_PLAYBACK_PTE_OFFSET;
+   if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
-   } else {
-   pte_offset = ACP_CAPTURE_PTE_OFFSET;
+   else {
switch (asic_type) {
case CHIP_STONEY:
sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
@@ -336,10 +334,10 @@ static void config_acp_dma(void __iomem *acp_mmio,
}
}
acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
-  pte_offset);
+  rtd->pte_offset);
/* Configure System memory <-> ACP SRAM DMA descriptors */
set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
-  rtd->direction, pte_offset,
+  rtd->direction, rtd->pte_offset,
   rtd->ch1, sram_bank,
   rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
@@ -788,6 +786,13 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
}
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   switch (adata->asic_type) {
+   case CHIP_STONEY:
+   rtd->pte_offset = ACP_ST_PLAYBACK_PTE_OFFSET;
+   break;
+   default:
+   rtd->pte_offset = ACP_PLAYBACK_PTE_OFFSET;
+   }
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
rtd->destination = TO_ACP_I2S_1;
@@ -797,6 +802,13 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH;
rtd->byte_cnt_low_reg_offset = mmACP_I2S_TRANSMIT_BYTE_CNT_LOW;
} else {
+   switch (adata->asic_type) {
+   case CHIP_STONEY:
+   rtd->pte_offset = ACP_ST_CAPTURE_PTE_OFFSET;
+   break;
+   default:
+   rtd->pte_offset = ACP_CAPTURE_PTE_OFFSET;
+   }
rtd->ch1 = ACP_TO_SYSRAM_CH_NUM;
rtd->ch2 = I2S_TO_ACP_DMA_CH_NUM;
rtd->destination = FROM_ACP_I2S_1;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 82470bc..2f48d1d 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -10,6 +10,10 @@
 #define ACP_PLAYBACK_PTE_OFFSET10
 #define ACP_CAPTURE_PTE_OFFSET 0
 
+/* Playback and Capture Offset for Stoney */
+#define ACP_ST_PLAYBACK_PTE_OFFSET 0x04
+#define ACP_ST_CAPTURE_PTE_OFFSET  0x00
+
 #define ACP_GARLIC_CNTL_DEFAULT0x0FB4
 #define ACP_ONION_CNTL_DEFAULT 0x0FB4
 
@@ -90,6 +94,7 @@ struct audio_substream_data {
u16 destination;
u16 dma_dscr_idx_1;
u16 dma_dscr_idx_2;
+   u32 pte_offset;
u32 byte_cnt_high_reg_offset;
u32 byte_cnt_low_reg_offset;
uint64_t size;
-- 
2.7.4

[PATCH V2 03/10] ASoC: amd: removed separate byte count variables for playback and capture

[Vijendar Mukunda]

Removed separate byte count variables for playback and capture.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
v1->v2: Fixed review comment in acp_dma_pointer callback
 sound/soc/amd/acp-pcm-dma.c | 19 +--
 sound/soc/amd/acp.h |  3 +--
 2 files changed, 6 insertions(+), 16 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 6e338fe..862c1cf 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -866,13 +866,8 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
buffersize = frames_to_bytes(runtime, runtime->buffer_size);
bytescount = acp_get_byte_count(rtd);
 
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   if (bytescount > rtd->i2ssp_renderbytescount)
-   bytescount = bytescount - rtd->i2ssp_renderbytescount;
-   } else {
-   if (bytescount > rtd->i2ssp_capturebytescount)
-   bytescount = bytescount - rtd->i2ssp_capturebytescount;
-   }
+   if (bytescount > rtd->bytescount)
+   bytescount -= rtd->bytescount;
pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
 }
@@ -921,9 +916,9 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
bytescount = acp_get_byte_count(rtd);
+   if (rtd->bytescount == 0)
+   rtd->bytescount = bytescount;
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   if (rtd->i2ssp_renderbytescount == 0)
-   rtd->i2ssp_renderbytescount = bytescount;
acp_dma_start(rtd->acp_mmio, rtd->ch1, false);
while (acp_reg_read(rtd->acp_mmio, mmACP_DMA_CH_STS) &
BIT(rtd->ch1)) {
@@ -934,9 +929,6 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
}
cpu_relax();
}
-   } else {
-   if (rtd->i2ssp_capturebytescount == 0)
-   rtd->i2ssp_capturebytescount = bytescount;
}
acp_dma_start(rtd->acp_mmio, rtd->ch2, true);
ret = 0;
@@ -955,12 +947,11 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
acp_dma_stop(rtd->acp_mmio, rtd->ch1);
ret =  acp_dma_stop(rtd->acp_mmio, rtd->ch2);
-   rtd->i2ssp_renderbytescount = 0;
} else {
acp_dma_stop(rtd->acp_mmio, rtd->ch2);
ret = acp_dma_stop(rtd->acp_mmio, rtd->ch1);
-   rtd->i2ssp_capturebytescount = 0;
}
+   rtd->bytescount = 0;
break;
default:
ret = -EINVAL;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 3b076c6..82470bc 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -93,8 +93,7 @@ struct audio_substream_data {
u32 byte_cnt_high_reg_offset;
u32 byte_cnt_low_reg_offset;
uint64_t size;
-   u64 i2ssp_renderbytescount;
-   u64 i2ssp_capturebytescount;
+   u64 bytescount;
void __iomem *acp_mmio;
 };
 
-- 
2.7.4

[PATCH V2 02/10] ASoC: amd: added byte count register offset variables to rtd

[Vijendar Mukunda]

Added byte count register offset variables to audio_substream_data
structure. Modified dma pointer callback.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
v1->v2: Fixed Indentation issues
 sound/soc/amd/acp-pcm-dma.c | 36 +++-
 sound/soc/amd/acp.h |  2 ++
 2 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e9736fe..6e338fe 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -793,12 +793,18 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
rtd->destination = TO_ACP_I2S_1;
rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
+   rtd->byte_cnt_high_reg_offset =
+   mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH;
+   rtd->byte_cnt_low_reg_offset = mmACP_I2S_TRANSMIT_BYTE_CNT_LOW;
} else {
rtd->ch1 = ACP_TO_SYSRAM_CH_NUM;
rtd->ch2 = I2S_TO_ACP_DMA_CH_NUM;
rtd->destination = FROM_ACP_I2S_1;
rtd->dma_dscr_idx_1 = CAPTURE_START_DMA_DESCR_CH14;
rtd->dma_dscr_idx_2 = CAPTURE_START_DMA_DESCR_CH15;
+   rtd->byte_cnt_high_reg_offset =
+   mmACP_I2S_RECEIVED_BYTE_CNT_HIGH;
+   rtd->byte_cnt_low_reg_offset = mmACP_I2S_RECEIVED_BYTE_CNT_LOW;
}
 
size = params_buffer_bytes(params);
@@ -834,26 +840,15 @@ static int acp_dma_hw_free(struct snd_pcm_substream 
*substream)
return snd_pcm_lib_free_pages(substream);
 }
 
-static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+static u64 acp_get_byte_count(struct audio_substream_data *rtd)
 {
-   union acp_dma_count playback_dma_count;
-   union acp_dma_count capture_dma_count;
-   u64 bytescount = 0;
+   union acp_dma_count byte_count;
 
-   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
-   mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
-   playback_dma_count.bcount.low  = acp_reg_read(acp_mmio,
-   mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
-   bytescount = playback_dma_count.bytescount;
-   } else {
-   capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
-   mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
-   capture_dma_count.bcount.low  = acp_reg_read(acp_mmio,
-   mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
-   bytescount = capture_dma_count.bytescount;
-   }
-   return bytescount;
+   byte_count.bcount.high = acp_reg_read(rtd->acp_mmio,
+ rtd->byte_cnt_high_reg_offset);
+   byte_count.bcount.low  = acp_reg_read(rtd->acp_mmio,
+ rtd->byte_cnt_low_reg_offset);
+   return byte_count.bytescount;
 }
 
 static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream *substream)
@@ -869,7 +864,7 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
return -EINVAL;
 
buffersize = frames_to_bytes(runtime, runtime->buffer_size);
-   bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
+   bytescount = acp_get_byte_count(rtd);
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->i2ssp_renderbytescount)
@@ -925,8 +920,7 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
-   bytescount = acp_get_byte_count(rtd->acp_mmio,
-   substream->stream);
+   bytescount = acp_get_byte_count(rtd);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (rtd->i2ssp_renderbytescount == 0)
rtd->i2ssp_renderbytescount = bytescount;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 5e25428..3b076c6 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -90,6 +90,8 @@ struct audio_substream_data {
u16 destination;
u16 dma_dscr_idx_1;
u16 dma_dscr_idx_2;
+   u32 byte_cnt_high_reg_offset;
+   u32 byte_cnt_low_reg_offset;
uint64_t size;
u64 i2ssp_renderbytescount;
u64 i2ssp_capturebytescount;
-- 
2.7.4

[PATCH V2 01/10] ASoC: amd: dma config parameters changes

[Vijendar Mukunda]

Added dma configuration parameters to rtd structure.
Moved dma configuration parameters initialization to
hw_params callback.
Removed hard coding in prepare and trigger callbacks.

Signed-off-by: Vijendar Mukunda 
Reviewed-by: Daniel Kurtz 
---
v1->v2 : Fixed capture stream wrong channel assignment
 added comments in dma trigger api
 sound/soc/amd/acp-pcm-dma.c | 103 ++--
 sound/soc/amd/acp.h |   5 +++
 2 files changed, 48 insertions(+), 60 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 9c026c4..e9736fe 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -321,19 +321,12 @@ static void config_acp_dma(void __iomem *acp_mmio,
   u32 asic_type)
 {
u32 pte_offset, sram_bank;
-   u16 ch1, ch2, destination, dma_dscr_idx;
 
if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK) {
pte_offset = ACP_PLAYBACK_PTE_OFFSET;
-   ch1 = SYSRAM_TO_ACP_CH_NUM;
-   ch2 = ACP_TO_I2S_DMA_CH_NUM;
sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
-   destination = TO_ACP_I2S_1;
-
} else {
pte_offset = ACP_CAPTURE_PTE_OFFSET;
-   ch1 = SYSRAM_TO_ACP_CH_NUM;
-   ch2 = ACP_TO_I2S_DMA_CH_NUM;
switch (asic_type) {
case CHIP_STONEY:
sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
@@ -341,30 +334,19 @@ static void config_acp_dma(void __iomem *acp_mmio,
default:
sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
}
-   destination = FROM_ACP_I2S_1;
}
-
acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
   pte_offset);
-   if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
-   dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
-   else
-   dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
-
/* Configure System memory <-> ACP SRAM DMA descriptors */
set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
-  rtd->direction, pte_offset, ch1,
-  sram_bank, dma_dscr_idx, asic_type);
-
-   if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
-   dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH13;
-   else
-   dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH15;
+  rtd->direction, pte_offset,
+  rtd->ch1, sram_bank,
+  rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
   rtd->direction, sram_bank,
-  destination, ch2, dma_dscr_idx,
-  asic_type);
+  rtd->destination, rtd->ch2,
+  rtd->dma_dscr_idx_2, asic_type);
 }
 
 /* Start a given DMA channel transfer */
@@ -804,6 +786,21 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
acp_reg_write(val, adata->acp_mmio,
  mmACP_I2S_16BIT_RESOLUTION_EN);
}
+
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
+   rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
+   rtd->destination = TO_ACP_I2S_1;
+   rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
+   rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
+   } else {
+   rtd->ch1 = ACP_TO_SYSRAM_CH_NUM;
+   rtd->ch2 = I2S_TO_ACP_DMA_CH_NUM;
+   rtd->destination = FROM_ACP_I2S_1;
+   rtd->dma_dscr_idx_1 = CAPTURE_START_DMA_DESCR_CH14;
+   rtd->dma_dscr_idx_2 = CAPTURE_START_DMA_DESCR_CH15;
+   }
+
size = params_buffer_bytes(params);
status = snd_pcm_lib_malloc_pages(substream, size);
if (status < 0)
@@ -898,21 +895,15 @@ static int acp_dma_prepare(struct snd_pcm_substream 
*substream)
 
if (!rtd)
return -EINVAL;
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   config_acp_dma_channel(rtd->acp_mmio, SYSRAM_TO_ACP_CH_NUM,
-  PLAYBACK_START_DMA_DESCR_CH12,
-  NUM_DSCRS_PER_CHANNEL, 0);
-   config_acp_dma_channel(rtd->acp_mmio, ACP_TO_I2S_DMA_CH_NUM,
-  PLAYBACK_START_DMA_DESCR_CH13,
-  NUM_DSCRS_PER_CHANNEL, 0);
-   } else {
-   config_acp_dma_channel(rtd->acp_mmio, ACP_TO_SYSRAM_CH_NUM,
-  CAPTURE_START_DMA_DESCR_CH14,
-

Re: [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE

[Randy Dunlap]

On 05/07/2018 07:33 PM, Huaisheng HS1 Ye wrote:
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c782e8f..5fe1f63 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -687,6 +687,22 @@ config ZONE_DEVICE
>  
> +config ZONE_NVM
> + bool "Manage NVDIMM (pmem) by memory management (EXPERIMENTAL)"
> + depends on NUMA && X86_64

Hi,
I'm curious why this depends on NUMA. Couldn't it be useful in non-NUMA
(i.e., UMA) configs?

Thanks.

> + depends on HAVE_MEMBLOCK_NODE_MAP
> + depends on HAVE_MEMBLOCK
> + depends on !IA32_EMULATION
> + default n
> +
> + help
> +   This option allows you to use memory management subsystem to manage
> +   NVDIMM (pmem). With it mm can arrange NVDIMMs into real physical zones
> +   like NORMAL and DMA32. That means buddy system and swap can be used
> +   directly to NVDIMM zone. This feature is beneficial to recover
> +   dirty pages from power fail or system crash by storing write cache
> +   to NVDIMM zone.



-- 
~Randy

Re: [PATCH 4/9] hwmon: fschmd: fix typo 'can by' to 'can be'

[Guenter Roeck]

On 05/06/2018 04:23 AM, Wolfram Sang wrote:

Signed-off-by: Wolfram Sang 


Applied to hwmon-next.

Thanks,
Guenter


---
  drivers/hwmon/fschmd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/fschmd.c b/drivers/hwmon/fschmd.c
index 5e78229ade049f..22d3a84f13ef58 100644
--- a/drivers/hwmon/fschmd.c
+++ b/drivers/hwmon/fschmd.c
@@ -105,7 +105,7 @@ static const u8 FSCHMD_REG_VOLT[7][6] = {
  static const int FSCHMD_NO_VOLT_SENSORS[7] = { 3, 3, 3, 3, 3, 3, 6 };
  
  /*

- * minimum pwm at which the fan is driven (pwm can by increased depending on
+ * minimum pwm at which the fan is driven (pwm can be increased depending on
   * the temp. Notice that for the scy some fans share there minimum speed.
   * Also notice that with the scy the sensor order is different than with the
   * other chips, this order was in the 2.4 driver and kept for consistency.

[PATCH v3] staging: lustre: o2iblnd: Enable Multiple OPA Endpoints between Nodes

[Doug Oucharek]

OPA driver optimizations are based on the MPI model where it is
expected to have multiple endpoints between two given nodes. To
enable this optimization for Lustre, we need to make it possible,
via an LND-specific tuneable, to create multiple endpoints and to
balance the traffic over them.

Both sides of a connection must have this patch for it to work.
Only the active side of the connection (usually the client)
needs to have the new tuneable set > 1.

Signed-off-by: Doug Oucharek 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8943
Reviewed-on: https://review.whamcloud.com/25168
Reviewed-by: Amir Shehata 
Reviewed-by: Dmitry Eremin 
Reviewed-by: James Simmons 
Reviewed-by: Oleg Drokin 
Signed-off-by: Doug Oucharek 
---
Changes in v1: Original patch
Changes in v2: Fixed checkpatch issues
Changes in v3: Properly added version change log

 .../lustre/include/uapi/linux/lnet/lnet-dlc.h  |  3 ++-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 17 ---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 25 +++---
 .../lustre/lnet/klnds/o2iblnd/o2iblnd_modparams.c  |  9 
 4 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
index e45d828..c1619f4 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
@@ -53,7 +53,8 @@ struct lnet_ioctl_config_o2iblnd_tunables {
__u32 lnd_fmr_pool_size;
__u32 lnd_fmr_flush_trigger;
__u32 lnd_fmr_cache;
-   __u32 pad;
+   __u16 lnd_conns_per_peer;
+   __u16 pad;
 };
 
 struct lnet_ioctl_config_lnd_tunables {
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
index ca6e09d..bb663d6 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
@@ -568,6 +568,8 @@ struct kib_peer {
lnet_nid_t   ibp_nid; /* who's on the other end(s) */
struct lnet_ni  *ibp_ni; /* LNet interface */
struct list_head ibp_conns;   /* all active connections */
+   struct kib_conn *ibp_next_conn;  /* next connection to send on for
+ * round robin */
struct list_head ibp_tx_queue;/* msgs waiting for a conn */
__u64ibp_incarnation; /* incarnation of peer */
/* when (in jiffies) I was last alive */
@@ -581,7 +583,7 @@ struct kib_peer {
/* current active connection attempts */
unsigned short  ibp_connecting;
/* reconnect this peer later */
-   unsigned short  ibp_reconnecting:1;
+   unsigned char   ibp_reconnecting;
/* counter of how many times we triggered a conn race */
unsigned char   ibp_races;
/* # consecutive reconnection attempts to this peer */
@@ -744,10 +746,19 @@ struct kib_peer {
 static inline struct kib_conn *
 kiblnd_get_conn_locked(struct kib_peer *peer)
 {
+   struct list_head *next;
+
LASSERT(!list_empty(&peer->ibp_conns));
 
-   /* just return the first connection */
-   return list_entry(peer->ibp_conns.next, struct kib_conn, ibc_list);
+   /* Advance to next connection, be sure to skip the head node */
+   if (!peer->ibp_next_conn ||
+   peer->ibp_next_conn->ibc_list.next == &peer->ibp_conns)
+   next = peer->ibp_conns.next;
+   else
+   next = peer->ibp_next_conn->ibc_list.next;
+   peer->ibp_next_conn = list_entry(next, struct kib_conn, ibc_list);
+
+   return peer->ibp_next_conn;
 }
 
 static inline int
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index b4a182d..77b3ae6 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -1250,7 +1250,6 @@ static int kiblnd_resolve_addr(struct rdma_cm_id *cmid,
 
LASSERT(net);
LASSERT(peer->ibp_connecting > 0);
-   LASSERT(!peer->ibp_reconnecting);
 
cmid = kiblnd_rdma_create_id(kiblnd_cm_callback, peer, RDMA_PS_TCP,
 IB_QPT_RC);
@@ -1332,7 +1331,7 @@ static int kiblnd_resolve_addr(struct rdma_cm_id *cmid,
 
LASSERT(!peer->ibp_accepting && !peer->ibp_connecting &&
list_empty(&peer->ibp_conns));
-   peer->ibp_reconnecting = 0;
+   peer->ibp_reconnecting--;
 
if (!kiblnd_peer_active(peer)) {
list_splice_init(&peer->ibp_tx_queue, &txs);
@@ -1365,6 +1364,8 @@ static int kiblnd_resolve_addr(struct rdma_cm_id *cmid,
rwlock_t *g_lock = &kiblnd_data.kib_global_lock;
unsigned long flags;
int rc;
+   inti;
+   struct lnet_ioctl_config

[PATCH v1 04/13] drm/kms/mode/fsl-dcu: using helper func drm_display_mode_to_videomode for calculating timing parameters

[Satendra Singh Thakur]

-Using drm_display_mode_to_videomode to avoid duplicate logic
-Removed index = drm_crtc_index(crtc) as it is unused
-Replaced DRM_MODE_FLAG_* flags with DISPLAY_FLAGS_* flags
-Replaced mode->h/vdisplay with vm.h/vactive

Acked-by: Stefan Agner 
Signed-off-by: Satendra Singh Thakur 
Cc: Madhur Verma 
Cc: Hemanshu Srivastava 
---

 v1: 
Thanks for the comments Mr Stefan. I fixed most of them, other ones 
can't be fixed as explained below:
Header  defines struct vm, therefore we can't remove 
it.
Tried to add new line below clk_set_rate but checkpatch gave error.

Other changes in the patch:
Removed index = drm_crtc_index(crtc) line as it is unused
Replaced DRM_MODE_FLAG_* flags with DISPLAY_FLAGS_* flags
Replaced mode->h/vdisplay with vm.h/vactive
Added acked-by field

 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 37 --
 1 file changed, 15 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 0e37524..d6ea667 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "fsl_dcu_drm_crtc.h"
 #include "fsl_dcu_drm_drv.h"
@@ -85,40 +86,32 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
struct drm_connector *con = &fsl_dev->connector.base;
struct drm_display_mode *mode = &crtc->state->mode;
-   unsigned int hbp, hfp, hsw, vbp, vfp, vsw, index, pol = 0;
-
-   index = drm_crtc_index(crtc);
-   clk_set_rate(fsl_dev->pix_clk, mode->clock * 1000);
-
-   /* Configure timings: */
-   hbp = mode->htotal - mode->hsync_end;
-   hfp = mode->hsync_start - mode->hdisplay;
-   hsw = mode->hsync_end - mode->hsync_start;
-   vbp = mode->vtotal - mode->vsync_end;
-   vfp = mode->vsync_start - mode->vdisplay;
-   vsw = mode->vsync_end - mode->vsync_start;
+   unsigned int pol = 0;
+   struct videomode vm;
 
+   drm_display_mode_to_videomode(mode, &vm);
+   clk_set_rate(fsl_dev->pix_clk, vm.pixelclock);
/* INV_PXCK as default (most display sample data on rising edge) */
if (!(con->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE))
pol |= DCU_SYN_POL_INV_PXCK;
 
-   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+   if (vm.flags & DISPLAY_FLAGS_HSYNC_LOW)
pol |= DCU_SYN_POL_INV_HS_LOW;
 
-   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+   if (vm.flags & DISPLAY_FLAGS_VSYNC_LOW)
pol |= DCU_SYN_POL_INV_VS_LOW;
 
regmap_write(fsl_dev->regmap, DCU_HSYN_PARA,
-DCU_HSYN_PARA_BP(hbp) |
-DCU_HSYN_PARA_PW(hsw) |
-DCU_HSYN_PARA_FP(hfp));
+DCU_HSYN_PARA_BP(vm.hback_porch) |
+DCU_HSYN_PARA_PW(vm.hsync_len) |
+DCU_HSYN_PARA_FP(vm.hfront_porch));
regmap_write(fsl_dev->regmap, DCU_VSYN_PARA,
-DCU_VSYN_PARA_BP(vbp) |
-DCU_VSYN_PARA_PW(vsw) |
-DCU_VSYN_PARA_FP(vfp));
+DCU_VSYN_PARA_BP(vm.vback_porch) |
+DCU_VSYN_PARA_PW(vm.vsync_len) |
+DCU_VSYN_PARA_FP(vm.vfront_porch));
regmap_write(fsl_dev->regmap, DCU_DISP_SIZE,
-DCU_DISP_SIZE_DELTA_Y(mode->vdisplay) |
-DCU_DISP_SIZE_DELTA_X(mode->hdisplay));
+DCU_DISP_SIZE_DELTA_Y(vm.vactive) |
+DCU_DISP_SIZE_DELTA_X(vm.hactive));
regmap_write(fsl_dev->regmap, DCU_SYN_POL, pol);
regmap_write(fsl_dev->regmap, DCU_BGND, DCU_BGND_R(0) |
 DCU_BGND_G(0) | DCU_BGND_B(0));
-- 
2.7.4

Re: [PATCH] mm: expland documentation over __read_mostly

[Joel Fernandes]

On May 7, 2018 4:15:06 PM PDT, "Luis R. Rodriguez"  wrote:
>__read_mostly can easily be misused by folks, its not meant for
>just read-only data. There are performance reasons for using it, but
>we also don't provide any guidance about its use. Provide a bit more
>guidance over it use.
>
>Signed-off-by: Luis R. Rodriguez 
>---
> include/linux/cache.h | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>Every now and then we get a patch suggesting to use __read_mostly for
>something new or old but with no justifications. Add a bit more
>verbiage to help guide its users.
>
>Is this sufficient documentation to at least ask for a reason in the
>commit
>log as to why its being used for new entries? Or should we be explicit
>and
>ask for such justifications in commit logs? Taken from prior
>discussions
>with Christoph Lameter [0] over its use.
>
>[0]
>https://lkml.kernel.org/r/alpine.deb.2.11.1504301343190.28...@gentwo.org
>
>diff --git a/include/linux/cache.h b/include/linux/cache.h
>index 750621e41d1c..62bc5adc0ed5 100644
>--- a/include/linux/cache.h
>+++ b/include/linux/cache.h
>@@ -15,8 +15,14 @@
> 
> /*
>* __read_mostly is used to keep rarely changing variables out of
>frequently
>- * updated cachelines. If an architecture doesn't support it, ignore
>the
>- * hint.
>+ * updated cachelines. Its use should be reserved for data that is
>used
>+ * frequently in hot paths. Performance traces can help decide when to
>use
>+ * this. You want __read_mostly data to be tightly packed, so that in
>the
>+ * best case multiple frequently read variables for a hot path will be
>next
>+ * to each other in order to reduce the number of cachelines needed to
>+ * execute a critial path. We should be mindful and selective if its

Nit: in its use.

- Joel


>use.
>+ *
>+ * If an architecture doesn't support it, ignore the hint.
>  */
> #ifndef __read_mostly
> #define __read_mostly

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH net-next] net-next/hinic: add pci device ids for 25ge and 100ge card

[David Miller]

From: Zhao Chen 
Date: Mon, 7 May 2018 09:21:57 -0400

> This patch adds PCI device IDs to support 25GE and 100GE card:
> 
> 1. Add device id 0x0201 for HINIC 100GE dual port card.
> 2. Add device id 0x0200 for HINIC 25GE dual port card.
> 3. Macro of device id 0x1822 is modified for HINIC 25GE quad port card.
> 
> Signed-off-by: Zhao Chen 

Applied.

Re: [PATCH v3 2/3] usb: dwc3: Add Qualcomm DWC3 glue driver

[Manu Gautam]

On 5/5/2018 12:18 AM, Manu Gautam wrote:
> DWC3 controller on Qualcomm SOCs has a Qscratch wrapper.
> Some of its uses are described below resulting in need to
> have a separate glue driver instead of using dwc3-of-simple:
>  - It exposes register interface to override vbus-override
>and lane0-pwr-present signals going to hardware. These
>must be updated in peripheral mode for DWC3 if vbus lines
>are not connected to hardware block. Otherwise RX termination
>in SS mode or DP pull-up is not applied by device controller.
>  - pwr_events_irq_stat support to check if USB2 PHY is in L2 state
>before glue driver proceeds with suspend.
>  - Support for wakeup interrupts lines that are asserted whenever
>there is any wakeup event on USB3 or USB2 bus.
>  - Support to replace pip3 clock going to DWC3 with utmi clock
>for hardware configuration where SSPHY is not used with DWC3.
>
> Signed-off-by: Manu Gautam 
[snip]
> +static const struct of_device_id dwc3_qcom_of_match[] = {
> + { .compatible = "qcom,dwc3" },

I should also add SOC specific compatibles.
Will do that in next patch.


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] trivial: fix inconsistent help texts

[David Miller]

From: Georg Hofmann 
Date: Mon,  7 May 2018 14:03:18 +0200

> This patch removes "experimental" from the help text where depends on
> CONFIG_EXPERIMENTAL was already removed.
> 
> Signed-off-by: Georg Hofmann 

Applied.

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

[Agrawal, Akshu]

On 5/8/2018 3:14 AM, Deucher, Alexander wrote:
>> -Original Message-
>> From: Agrawal, Akshu
>> Sent: Monday, May 7, 2018 6:14 AM
>> Cc: djku...@chromium.org; Agrawal, Akshu ;
>> Deucher, Alexander ;
>> mturque...@baylibre.com; sb...@kernel.org; Koenig, Christian
>> ; airl...@redhat.com; Liu, Shaoyun
>> ; linux-kernel@vger.kernel.org; linux-
>> c...@vger.kernel.org; r...@rjwysocki.net; l...@kernel.org; linux-
>> a...@vger.kernel.org
>> Subject: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock
>>
>> Stoney SoC provides oscout clock. This clock can support 25Mhz and 48Mhz
>> of frequency.
>> The clock is available for general system use.
>>
>> Signed-off-by: Akshu Agrawal 
>> ---
>> v2: config change, added SPDX tag and used clk_hw_register_.
>> v3: Fix kbuild warning for checking of NULL pointer
>> v4: unregister clk_hw in driver remove, add .suppress_bind_attrs
>>  drivers/clk/x86/Makefile |  3 +-
>>  drivers/clk/x86/clk-st.c | 85
>> 
>>  include/linux/platform_data/clk-st.h | 17 
>>  3 files changed, 104 insertions(+), 1 deletion(-)  create mode 100644
>> drivers/clk/x86/clk-st.c  create mode 100644
>> include/linux/platform_data/clk-st.h
>>
>> diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile index
>> 1367afb..00303bc 100644
>> --- a/drivers/clk/x86/Makefile
>> +++ b/drivers/clk/x86/Makefile
>> @@ -1,3 +1,4 @@
>> +obj-$(CONFIG_PMC_ATOM)  += clk-pmc-atom.o
>> +obj-$(CONFIG_X86_AMD_PLATFORM_DEVICE)   += clk-st.o
>>  clk-x86-lpss-objs   := clk-lpt.o
>>  obj-$(CONFIG_X86_INTEL_LPSS)+= clk-x86-lpss.o
>> -obj-$(CONFIG_PMC_ATOM)  += clk-pmc-atom.o
>> diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c new file 
>> mode
>> 100644 index 000..8a7795c
>> --- /dev/null
>> +++ b/drivers/clk/x86/clk-st.c
>> @@ -0,0 +1,85 @@
>> +// SPDX-License-Identifier: GPL-2.0
> 
> Should this be MIT?  The original license was MIT.
> 
> Alex
>

We are adding SPDX tag, while license remains same GPL-2.0

What I have read is this is "to provide license identifiers inside the
source code that could be easily parsed by machines and would allow
checking for license compliance of an open source project easier."

Thanks,
Akshu

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

[Masami Hiramatsu]

On Mon, 7 May 2018 11:30:03 -0400
Steven Rostedt  wrote:

> On Sun, 6 May 2018 00:51:43 +0900
> Masami Hiramatsu  wrote:
> 
> > OK, now I think it is a time to introduce new unified interface for dynamic 
> > events,
> > tracefs/dynamic_events and make uprobe_events and kprobe_events as 
> > symbolic-links
> > to the new interface file.
> 
> So basically make one file that does all the work?
> 
> I'm not sure we can keep the other files as symbolic links. Because we
> don't want the kprobe_events showing up in the uprobe_events file, and
> vice versa. We need to keep all this backward compatible.

Good catch!
Can't we check which file the user opened? If not, even though
we can setup a filter in ops->open().

> 
> But I do like the idea of one file to rule them all, approach.

Thanks!

> 
> -- Steve
> 
> 
> > 
> > Actually, there is no reason we split those 2 interfaces, since
> > both have similar, but very clear syntax differences.
> > 
> > o Uprobe event definition
> >   p[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a uprobe
> >   r[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe)
> >   -:[GRP/]EVENT   : Clear uprobe or uretprobe event
> > 
> > o Kprobe event definition
> >   p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS]  : Set a probe
> >   r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]  : Set a return probe
> >   -:[GRP/]EVENT : Clear a probe
> > 
> > At first, it is clear that those can share the parser. 2nd, it is easy to
> > distinguish those, because Uprobe event must require the PATH which starts
> > with '/', on the other hand, Kprobe event must NOT start with '/'.
> > (both SYM and MOD will start with alphabet or '_', of course MEMADDR
> > will start with digits)
> > 
> > If we can merge those to unified dynamic_events interface, I think
> > 'f[:[GRP/]EVENT] SYM(CAST)' is also acceptable, since it is no more
> > only for kprobe/uprobe. We can directly add some other dynamic
> > events via dynamic_events interface. ;)
> > 
> > Thank you,
> > 
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2 6/7] ocxl: Add an IOCTL so userspace knows what CPU features are available

[Alastair D'Silva]

On Tue, 2018-05-08 at 13:50 +1000, Nicholas Piggin wrote:
> On Tue, 08 May 2018 10:41:55 +1000
> "Alastair D'Silva"  wrote:
> 
> > On Mon, 2018-05-07 at 20:14 +0200, Frederic Barrat wrote:
> > > 
> > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit :  
> > > > From: Alastair D'Silva 
> > > > 
> > > > In order for a userspace AFU driver to call the Power9 specific
> > > > OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can
> > > > actually
> > > > make that call.
> > > > 
> > > > Signed-off-by: Alastair D'Silva 
> > > > ---
> > > >   Documentation/accelerators/ocxl.rst |  1 -
> > > >   drivers/misc/ocxl/file.c| 25
> > > > +
> > > >   include/uapi/misc/ocxl.h|  4 
> > > >   3 files changed, 29 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/Documentation/accelerators/ocxl.rst
> > > > b/Documentation/accelerators/ocxl.rst
> > > > index ddcc58d01cfb..7904adcc07fd 100644
> > > > --- a/Documentation/accelerators/ocxl.rst
> > > > +++ b/Documentation/accelerators/ocxl.rst
> > > > @@ -157,7 +157,6 @@ OCXL_IOCTL_GET_METADATA:
> > > > Obtains configuration information from the card, such at
> > > > the
> > > > size of
> > > > MMIO areas, the AFU version, and the PASID for the current
> > > > context.
> > > > 
> > > > -  
> > > 
> > > 
> > > Intended?
> > > 
> > > Other than that,
> > > Acked-by: Frederic Barrat 
> > >   
> > 
> > Nope, I'll fix that, thanks.
> > 
> 
> Just to be clear, this is for OCXL features. I would just make that
> explicit in the title (s/CPU/OCXL).
> 
> Thanks,
> Nick
> 

OK, sounds reasonable.

-- 
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819

Re: [PATCH] f2fs: fix to avoid race during access gc_thread pointer

[Jaegeuk Kim]

On 05/08, Chao Yu wrote:
> Thread A  Thread B
> - f2fs_remount
>  - stop_gc_thread
>   - f2fs_sbi_store
>sbi->gc_thread = NULL;
> access sbi->gc_thread->gc_*
> 
> Previously, we allocate memory for sbi->gc_thread based on background
> gc thread mount option, the memory can be released if we turn off
> that mount option, but still there are several places access gc_thread
> pointer without considering race condition, result in NULL point
> dereference.
> 
> In order to fix this issue, use sb->s_umount to exclude those operations.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/sysfs.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
> index f3c3fb4cbb0d..0aec4db7fa02 100644
> --- a/fs/f2fs/sysfs.c
> +++ b/fs/f2fs/sysfs.c
> @@ -179,6 +179,7 @@ static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
>   unsigned long t;
>   unsigned int *ui;
>   ssize_t ret;
> + bool gc_entry = (a->struct_type == GC_THREAD);
>  
>   ptr = __struct_ptr(sbi, a->struct_type);

We need to cover __struct_ptr() here.

>   if (!ptr)
> @@ -277,8 +278,14 @@ static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
>   return count;
>   }
>  
> + if (gc_entry)
> + down_read(&sbi->sb->s_umount);
> +
>   *ui = t;
>  
> + if (gc_entry)
> + up_read(&sbi->sb->s_umount);
> +
>   if (!strcmp(a->attr.name, "iostat_enable") && *ui == 0)
>   f2fs_reset_iostat(sbi);
>   return count;
> -- 
> 2.17.0.391.g1f1cddd558b5

Re: [External] Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

[Dan Williams]

On Mon, May 7, 2018 at 7:59 PM, Huaisheng HS1 Ye  wrote:
>>
>>Dan Williams  writes:
>>
>>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox 
>>wrote:
 On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management)
>>subsystem as
> DEVICE zone, which is a virtual zone and both its start and end of pfn
> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel
>>uses
> corresponding drivers, which locate at \drivers\nvdimm\ and
> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
> memory hot plug implementation.

 You probably want to let linux-nvdimm know about this patch set.
 Adding to the cc.
>>>
>>> Yes, thanks for that!
>>>
 Also, I only received patch 0 and 4.  What happened
 to 1-3,5 and 6?

> With current kernel, many mm’s classical features like the buddy
> system, swap mechanism and page cache couldn’t be supported to
>>NVDIMM.
> What we are doing is to expand kernel mm’s capacity to make it to
>>handle
> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and
>>NVDIMM
> separately, that means mm can only put the critical pages to NVDIMM
>>
>>Please define "critical pages."
>>
> zone, here we created a new zone type as NVM zone. That is to say for
> traditional(or normal) pages which would be stored at DRAM scope like
> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
> them could be recovered from power fail or system crash, we make them
> to be persistent by storing them to NVM zone.
>>
>>[...]
>>
>>> I think adding yet one more mm-zone is the wrong direction. Instead,
>>> what we have been considering is a mechanism to allow a device-dax
>>> instance to be given back to the kernel as a distinct numa node
>>> managed by the VM. It seems it times to dust off those patches.
>>
>>What's the use case?  The above patch description seems to indicate an
>>intent to recover contents after a power loss.  Without seeing the whole
>>series, I'm not sure how that's accomplished in a safe or meaningful
>>way.
>>
>>Huaisheng, could you provide a bit more background?
>>
>
> Currently in our mind, an ideal use scenario is that, we put all page caches 
> to
> zone_nvm, without any doubt, page cache is an efficient and common cache
> implement, but it has a disadvantage that all dirty data within it would has 
> risk
> to be missed by power failure or system crash. If we put all page caches to 
> NVDIMMs,
> all dirty data will be safe.
>
> And the most important is that, Page cache is different from dm-cache or 
> B-cache.
> Page cache exists at mm. So, it has much more performance than other Write
> caches, which locate at storage level.

Can you be more specific? I think the only fundamental performance
difference between page cache and a block caching driver is that page
cache pages can be DMA'ed directly to lower level storage. However, I
believe that problem is solvable, i.e. we can teach dm-cache to
perform the equivalent of in-kernel direct-I/O when transferring data
between the cache and the backing storage when the cache is comprised
of persistent memory.

>
> At present we have realized NVM zone to be supported by two sockets(NUMA)
> product based on Lenovo Purley platform, and we can expand NVM flag into
> Page Cache allocation interface, so all Page Caches of system had been stored
> to NVDIMM safely.
>
> Now we are focusing how to recover data from Page cache after power on. That 
> is,
> The dirty pages could be safe and the time cost of cache training would be 
> saved a lot.
> Because many pages have already stored to ZONE_NVM before power failture.

I don't see how ZONE_NVM fits into a persistent page cache solution.
All of the mm structures to maintain the page cache are built to be
volatile. Once you build the infrastructure to persist and restore the
state of the page cache it is no longer the traditional page cache.
I.e. it will become something much closer to dm-cache or a filesystem.

One nascent idea from Dave Chinner is to teach xfs how to be a block
server for an upper level filesystem. His aim is sub-volume and
snapshot support, but I wonder if caching could be adapted into that
model?

In any event I think persisting and restoring cache state needs to be
designed before deciding if changes to the mm are needed.

Re: [PATCH v2 6/7] ocxl: Add an IOCTL so userspace knows what CPU features are available

[Nicholas Piggin]

On Tue, 08 May 2018 10:41:55 +1000
"Alastair D'Silva"  wrote:

> On Mon, 2018-05-07 at 20:14 +0200, Frederic Barrat wrote:
> > 
> > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit :  
> > > From: Alastair D'Silva 
> > > 
> > > In order for a userspace AFU driver to call the Power9 specific
> > > OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually
> > > make that call.
> > > 
> > > Signed-off-by: Alastair D'Silva 
> > > ---
> > >   Documentation/accelerators/ocxl.rst |  1 -
> > >   drivers/misc/ocxl/file.c| 25
> > > +
> > >   include/uapi/misc/ocxl.h|  4 
> > >   3 files changed, 29 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/accelerators/ocxl.rst
> > > b/Documentation/accelerators/ocxl.rst
> > > index ddcc58d01cfb..7904adcc07fd 100644
> > > --- a/Documentation/accelerators/ocxl.rst
> > > +++ b/Documentation/accelerators/ocxl.rst
> > > @@ -157,7 +157,6 @@ OCXL_IOCTL_GET_METADATA:
> > > Obtains configuration information from the card, such at the
> > > size of
> > > MMIO areas, the AFU version, and the PASID for the current
> > > context.
> > > 
> > > -  
> > 
> > 
> > Intended?
> > 
> > Other than that,
> > Acked-by: Frederic Barrat 
> >   
> 
> Nope, I'll fix that, thanks.
> 

Just to be clear, this is for OCXL features. I would just make that
explicit in the title (s/CPU/OCXL).

Thanks,
Nick

Re: [Ksummit-discuss] bug-introducing patches

[Theodore Y. Ts'o]

On Tue, May 08, 2018 at 02:34:41AM +, Sasha Levin via Ksummit-discuss wrote:
> 
> Tony, I'm curious, how many users are you aware of who actually run
> Linus's tree? All the users I've encountered so far on Azure seem to be
> running something based on -stable.

The people who run Linus's tree and test -rc kernels tend to be kernel
developers and individual users who want to run bleeding edge kernels
and who generally are technically clueful.  If you were talking about
SLR cameras, you'd call them the "prosumers" segment of the market.

It tends to be more on desktops and laptops, so it doesn't surprise me
that you don't often see them in a hosting environment where you have
to pay $$$.  (And where you do see them in a hosting environment, it's
probably for things like gce-xfstests.)

> I think that a question we should be asking ourselves is whether we
> should be basing our decisions here on the assumption that (pretty much)
> no one runs Linus's tree anymore?

These people *do* exist, because as a maintainer, I get bug reports
from them.  (And sometimes as a user, I send bug reports when running
-rc kernels to other maintainers, such as the i915 drivers and the
Intel Wireless driver folks.)

Such reports are incredibly valuable and precious to me, since it
allows me to find problems that weren't picked up in my own testing.
(In the case of Intel Wireless, a while back the IWL team didn't have
Aruba Enterprise Access Points in their test hardware library, so I
found a regression after the merge window because I was running -rcX
on my laptop, and wireless access to googleguest network broke.  If I
hadn't been running -rcX, they probably wouldn't have discovered this
problem until after that particular kernel had been released.)

So keeping those users happy is a good thing; since they tend to be
very technically clueful, they can do bisections for you, and they are
able to give a detailed and useful bug report.  If they report that a
regression that was introduced in -rc2 is fixed by a particular patch,
I want to push it into -rc3 immediately, and not let it stall in
linux-next.  If the reason why is because you don't trust my patch
because it "only" got tested by the technically advanced user
reporting the regression, then don't take patches from -rc3 into your
stable branch right away!  Let it bake in Linus's tree anfor a week or
two, instead of demanding that patches stick around in Linux-next
before flowing into Linus's tree.

Because I will guarantee you this --- there are more real users
running Linus's tree than linux-next.  This is because Linus's tree
tends to be far more stable than linux-next, since after -rc2
linux-next starts getting the first set of experiments for what will
be going into the next merge window.  So while I am willing to run
something based on -rc2 or later on my laptop, there is no way in heck
I would be willing to put linux-next on my laptop.  That's just way
too exciting for me

Would I pull down linux-next, and fire up a VM running gce-xfstests?
Sure.  But that's not a real-life use case; that's just running canned
test cases.  And more often than not, linux-next will be broken while
Linus's -rcX tree is just fine; which is why I do most of my ext4
testing using patches based on top of -rcX, not based on top of
linux-next.

 - Ted

Re: [PATCH] watchdog: mena21_wdt: Fix a possible data race in a21_wdt_set_timeout

[Jia-Ju Bai]

On 2018/5/8 11:42, Guenter Roeck wrote:

On 05/07/2018 08:32 PM, Jia-Ju Bai wrote:



On 2018/5/8 11:28, Guenter Roeck wrote:

On 05/07/2018 08:18 PM, Jia-Ju Bai wrote:

The write operation to "wdt->timeout" is protected by
the lock on line 118, but the read operation to
this data on line 105 is not protected by the lock.
Thus, there may exist a data race for "wdt->timeout".

To fix this data race, the read operation to "wdt->timeout"
should be also protected by the lock.



There is no race. There is already a mutex in the watchdog core 
which serializes
calls to the various API functions. It would make more sense to drop 
drv->lock

from the driver.



Thanks for your reply :)
Need I submit a patch of dropping all calls to "drv->lock"?



You don't _need_ to, but I would happily give it my Reviewed-by: tag 
if you do.




Okay, I will write a patch today :)


Best wishes,
Jia-Ju Bai

Re: [PATCH 8/9] net: flow_dissector: fix typo 'can by' to 'can be'

[David Miller]

From: Wolfram Sang 
Date: Sun,  6 May 2018 13:23:52 +0200

> Signed-off-by: Wolfram Sang 

Applied.

[PATCH] ata: ata_piix: Fix a possible data race in piix_pci_device_resume

[Jia-Ju Bai]

The write operation to "host->flags" is protected by
the lock on line 1048, but the read operation to
this data on line 1046 is not protected by the lock.
Thus, there may exist a data race for "host->flags".

To fix this data race, the read operation to "host->flags" 
should be also protected by the lock.

Signed-off-by: Jia-Ju Bai 
---
 drivers/ata/ata_piix.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 7ecb1322a514..c99fdf473dee 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1043,8 +1043,8 @@ static int piix_pci_device_resume(struct pci_dev *pdev)
unsigned long flags;
int rc;
 
+   spin_lock_irqsave(&host->lock, flags);
if (host->flags & PIIX_HOST_BROKEN_SUSPEND) {
-   spin_lock_irqsave(&host->lock, flags);
host->flags &= ~PIIX_HOST_BROKEN_SUSPEND;
spin_unlock_irqrestore(&host->lock, flags);
 
@@ -1060,8 +1060,10 @@ static int piix_pci_device_resume(struct pci_dev *pdev)
dev_err(&pdev->dev,
"failed to enable device after resume (%d)\n",
rc);
-   } else
+   } else {
+   spin_unlock_irqrestore(&host->lock, flags);
rc = ata_pci_device_do_resume(pdev);
+   }
 
if (rc == 0)
ata_host_resume(host);
-- 
2.17.0

Re: [PATCH 1/7] cifs: smbd: Make upper layer decide when to destroy the transport

[kbuild test robot]

Hi Long,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on cifs/for-next]
[also build test WARNING on v4.17-rc4 next-20180507]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Long-Li/cifs-smbd-Make-upper-layer-decide-when-to-destroy-the-transport/20180508-110150
base:   git://git.samba.org/sfrench/cifs-2.6.git for-next
config: i386-randconfig-a1-05080831 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   fs//cifs/connect.c: In function 'cifs_reconnect':
>> fs//cifs/connect.c:381:16: warning: passing argument 1 of 'smbd_destroy' 
>> from incompatible pointer type
  smbd_destroy(server);
   ^
   In file included from fs//cifs/connect.c:58:0:
   fs//cifs/smbdirect.h:334:20: note: expected 'struct smbd_connection *' but 
argument is of type 'struct TCP_Server_Info *'
static inline void smbd_destroy(struct smbd_connection *info) {}
   ^
   fs//cifs/connect.c: In function 'clean_demultiplex_info':
   fs//cifs/connect.c:715:16: warning: passing argument 1 of 'smbd_destroy' 
from incompatible pointer type
  smbd_destroy(server);
   ^
   In file included from fs//cifs/connect.c:58:0:
   fs//cifs/smbdirect.h:334:20: note: expected 'struct smbd_connection *' but 
argument is of type 'struct TCP_Server_Info *'
static inline void smbd_destroy(struct smbd_connection *info) {}
   ^

vim +/smbd_destroy +381 fs//cifs/connect.c

   312  
   313  static int ip_connect(struct TCP_Server_Info *server);
   314  static int generic_ip_connect(struct TCP_Server_Info *server);
   315  static void tlink_rb_insert(struct rb_root *root, struct tcon_link 
*new_tlink);
   316  static void cifs_prune_tlinks(struct work_struct *work);
   317  static int cifs_setup_volume_info(struct smb_vol *volume_info, char 
*mount_data,
   318  const char *devname);
   319  
   320  /*
   321   * cifs tcp session reconnection
   322   *
   323   * mark tcp session as reconnecting so temporarily locked
   324   * mark all smb sessions as reconnecting for tcp session
   325   * reconnect tcp session
   326   * wake up waiters on reconnection? - (not needed currently)
   327   */
   328  int
   329  cifs_reconnect(struct TCP_Server_Info *server)
   330  {
   331  int rc = 0;
   332  struct list_head *tmp, *tmp2;
   333  struct cifs_ses *ses;
   334  struct cifs_tcon *tcon;
   335  struct mid_q_entry *mid_entry;
   336  struct list_head retry_list;
   337  
   338  spin_lock(&GlobalMid_Lock);
   339  if (server->tcpStatus == CifsExiting) {
   340  /* the demux thread will exit normally
   341  next time through the loop */
   342  spin_unlock(&GlobalMid_Lock);
   343  return rc;
   344  } else
   345  server->tcpStatus = CifsNeedReconnect;
   346  spin_unlock(&GlobalMid_Lock);
   347  server->maxBuf = 0;
   348  server->max_read = 0;
   349  
   350  cifs_dbg(FYI, "Reconnecting tcp session\n");
   351  
   352  /* before reconnecting the tcp session, mark the smb session 
(uid)
   353  and the tid bad so they are not used until reconnected 
*/
   354  cifs_dbg(FYI, "%s: marking sessions and tcons for reconnect\n",
   355   __func__);
   356  spin_lock(&cifs_tcp_ses_lock);
   357  list_for_each(tmp, &server->smb_ses_list) {
   358  ses = list_entry(tmp, struct cifs_ses, smb_ses_list);
   359  ses->need_reconnect = true;
   360  list_for_each(tmp2, &ses->tcon_list) {
   361  tcon = list_entry(tmp2, struct cifs_tcon, 
tcon_list);
   362  tcon->need_reconnect = true;
   363  }
   364  if (ses->tcon_ipc)
   365  ses->tcon_ipc->need_reconnect = true;
   366  }
   367  spin_unlock(&cifs_tcp_ses_lock);
   368  
   369  /* do not want to be sending data on a socket we are freeing */
   370  cifs_dbg(FYI, "%s: tearing down socket\n", __func__);
   371  mutex_lock(&server->srv_mutex);
   372  if (server->ssocket) {
   373  cifs_dbg(FYI, "State: 0x%x Flags: 0x%lx\n",
   374   server->ssocket->state, 
server->ssocket->flags);
   375 

Re: [PATCH] watchdog: mena21_wdt: Fix a possible data race in a21_wdt_set_timeout

[Guenter Roeck]

On 05/07/2018 08:32 PM, Jia-Ju Bai wrote:



On 2018/5/8 11:28, Guenter Roeck wrote:

On 05/07/2018 08:18 PM, Jia-Ju Bai wrote:

The write operation to "wdt->timeout" is protected by
the lock on line 118, but the read operation to
this data on line 105 is not protected by the lock.
Thus, there may exist a data race for "wdt->timeout".

To fix this data race, the read operation to "wdt->timeout"
should be also protected by the lock.



There is no race. There is already a mutex in the watchdog core which serializes
calls to the various API functions. It would make more sense to drop drv->lock
from the driver.



Thanks for your reply :)
Need I submit a patch of dropping all calls to "drv->lock"?



You don't _need_ to, but I would happily give it my Reviewed-by: tag if you do.

Guenter

Re: [PATCH 04/15] powerpc/powernv: opal-kmsg use flush fallback from console code

[Nicholas Piggin]

On Mon, 07 May 2018 20:36:39 +1000
Michael Ellerman  wrote:

> Nicholas Piggin  writes:
> > On Fri, 04 May 2018 15:16:37 +1000
> > Michael Ellerman  wrote:  
> >> Nicholas Piggin  writes:  
> >> > Use the more refined and tested event polling loop from opal_put_chars
> >> > as the fallback console flush in the opal-kmsg path. This loop is used
> >> > by the console driver today, whereas the opal-kmsg fallback is not
> >> > likely to have been used for years.
> >> >
> >> > Use WARN_ONCE rather than a printk when the fallback is invoked to
> >> > prepare for moving the console flush into a common function.
> >> 
> >> Do we want to add a WARN in that path? If we're panicking things might
> >> get worse if we WARN (which takes a trap).  
> >
> > True, probably a good idea not to... oh there's a printk_once so
> > that'll work nicely.  
> 
> Cool.
> 
> I have this series in a tree so you can send me an incremental diff if
> it's reasonably small.

It's a one liner (also moved location of message back to where it was
originally).

The next patch will clash because it moves this over into opal.c, so
you'd have to fix that by hand.

Thanks,
Nick

---
 arch/powerpc/platforms/powernv/opal-kmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal-kmsg.c 
b/arch/powerpc/platforms/powernv/opal-kmsg.c
index fd2bbf4fd6dc..c610ef3541aa 100644
--- a/arch/powerpc/platforms/powernv/opal-kmsg.c
+++ b/arch/powerpc/platforms/powernv/opal-kmsg.c
@@ -53,12 +53,12 @@ static void force_opal_console_flush(struct kmsg_dumper 
*dumper,
} else {
__be64 evt;
 
-   WARN_ONCE(1, "opal: OPAL_CONSOLE_FLUSH missing.\n");
/*
 * If OPAL_CONSOLE_FLUSH is not implemented in the firmware,
 * the console can still be flushed by calling the polling
 * function while it has OPAL_EVENT_CONSOLE_OUTPUT events.
 */
+   printk_once(KERN_NOTICE "opal: OPAL_CONSOLE_FLUSH missing.\n");
do {
opal_poll_events(&evt);
} while (be64_to_cpu(evt) & OPAL_EVENT_CONSOLE_OUTPUT);
-- 
2.17.0

[PATCH] f2fs: fix to avoid race during access gc_thread pointer

[Chao Yu]

Thread AThread B
- f2fs_remount
 - stop_gc_thread
- f2fs_sbi_store
   sbi->gc_thread = NULL;
  access sbi->gc_thread->gc_*

Previously, we allocate memory for sbi->gc_thread based on background
gc thread mount option, the memory can be released if we turn off
that mount option, but still there are several places access gc_thread
pointer without considering race condition, result in NULL point
dereference.

In order to fix this issue, use sb->s_umount to exclude those operations.

Signed-off-by: Chao Yu 
---
 fs/f2fs/sysfs.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index f3c3fb4cbb0d..0aec4db7fa02 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -179,6 +179,7 @@ static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
unsigned long t;
unsigned int *ui;
ssize_t ret;
+   bool gc_entry = (a->struct_type == GC_THREAD);
 
ptr = __struct_ptr(sbi, a->struct_type);
if (!ptr)
@@ -277,8 +278,14 @@ static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
return count;
}
 
+   if (gc_entry)
+   down_read(&sbi->sb->s_umount);
+
*ui = t;
 
+   if (gc_entry)
+   up_read(&sbi->sb->s_umount);
+
if (!strcmp(a->attr.name, "iostat_enable") && *ui == 0)
f2fs_reset_iostat(sbi);
return count;
-- 
2.17.0.391.g1f1cddd558b5

Re: [PATCH 09/24] selftests: ftrace: return Kselftest Skip code for skipped tests

[Masami Hiramatsu]

On Fri,  4 May 2018 19:13:13 -0600
"Shuah Khan (Samsung OSG)"  wrote:

> When ftrace test is skipped because of unmet dependencies and/or
> unsupported configuration, it returns 0 which is treated as a pass
> by the Kselftest framework. This leads to false positive result even
> when the test could not be run.
> 
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
> 
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
> 
> Signed-off-by: Shuah Khan (Samsung OSG) 
> ---
>  tools/testing/selftests/ftrace/ftracetest | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/ftrace/ftracetest 
> b/tools/testing/selftests/ftrace/ftracetest
> index f9a9d424c980..b731c8cdcffb 100755
> --- a/tools/testing/selftests/ftrace/ftracetest
> +++ b/tools/testing/selftests/ftrace/ftracetest
> @@ -23,6 +23,9 @@ echo "  If  is -, all logs 
> output in console only"
>  exit $1
>  }
>  
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
>  errexit() { # message
>echo "Error: $1" 1>&2
>exit 1
> @@ -30,7 +33,8 @@ errexit() { # message
>  
>  # Ensuring user privilege
>  if [ `id -u` -ne 0 ]; then
> -  errexit "this must be run by root user"
> +  echo "Skipping: test must be run by root user"
> +  exit $ksft_skip
>  fi
>  
>  # Utilities
> @@ -249,7 +253,7 @@ trap 'SIG_RESULT=$UNTESTED' $SIG_UNTESTED
>  SIG_UNSUPPORTED=$((SIG_BASE + UNSUPPORTED))
>  exit_unsupported () {
>kill -s $SIG_UNSUPPORTED $SIG_PID
> -  exit 0
> +  exit $ksft_skip

This should return 0. If you want to change the result code,
you have to change the last part as below.
(Note that we need a switch option of return code, so that
 ftracetest user can continue to use same way...)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index f9a9d424c980..d6ce56a2a937 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -326,5 +326,15 @@ prlog "# of unsupported: " `echo $UNSUPPORTED_CASES | wc 
-w`
 prlog "# of xfailed: " `echo $XFAILED_CASES | wc -w`
 prlog "# of undefined(test bug): " `echo $UNDEFINED_CASES | wc -w`
 
-# if no error, return 0
-exit $TOTAL_RESULT
+# following kselftest result code
+if [ $UNSUPPORTED_CASES -ne 0 -o \
+   $UNTESTED_CASES -ne 0 -o \
+   $UNRESOLVED_CASES -ne 0]; then # There are skipped tests
+  exit 4
+elif [ $XAILED_CASES -ne 0 -o ]; then # XFAILs
+  exit 2
+elif [ $FAILED_CASES -ne 0 -o ]; then # FAILs
+  exit 1
+else # PASS
+  exit 0
+fi

Thanks,

-- 
Masami Hiramatsu 

Re: [PATCH 08/15] powerpc/powernv: implement opal_put_chars_atomic

[Nicholas Piggin]

On Mon, 07 May 2018 20:35:42 +1000
Michael Ellerman  wrote:

> Nicholas Piggin  writes:
> 
> > On Tue, 01 May 2018 19:48:58 +1000
> > Benjamin Herrenschmidt  wrote:
> >  
> >> On Tue, 2018-05-01 at 00:55 +1000, Nicholas Piggin wrote:  
> >> > The RAW console does not need writes to be atomic, so relax
> >> > opal_put_chars to be able to do partial writes, and implement an
> >> > _atomic variant which does not take a spinlock. This API is used
> >> > in xmon, so the less locking that is used, the better chance there
> >> > is that a crash can be debugged.
> >> 
> >> Same comment I already had :-) "atomic" in Linux tends to mean
> >> something else (ie, atomic context), so I'd rather have something
> >> like opal_put_chars_sync() or such...  
> >
> > Oh yeah, I didn't ignore you, just... I thought atomic was okay.
> > atomic *also* tends to mean happens atomically. I think the in
> > atomic context meaning actually tends to be inatomic.
> >
> > Sync I actually thought could be more easily confused with
> > synchronous vs asynchronous here.  
> 
> I think we probably want opal_put_chars() to stay as it is.
> 
> And then add a variant for the call (just xmon?) that want lock free
> behaviour.

No it's not the lock which is important here, it is whether the
message goes to the console atomically versus other writes. The
raw console does not require this, only one which sends some
control characters, which is the hvterm-protocol compatible variant
of the vio console, and I think FSP console.

BMC consoles for example always use raw.

> opal_put_chars_unlocked() or something?

I prefer the _atomic as the special case. Ordinarily we don't have
a special requirement, but with the control characters then we do.

Thanks,
Nick

[PATCH] xen: xenbus: Fix a possible data race in xs_request_enter

[Jia-Ju Bai]

The read operation to "req->type" is protected by
the lock on line 128, but the write operation to
this data on line 118 is not protected by the lock.
Thus, there may exist a data race for "req->type".

To fix this data race, the write operation to "req->type" 
should be also protected by the lock.

Signed-off-by: Jia-Ju Bai 
---
 drivers/xen/xenbus/xenbus_xs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 49a3874ae6bb..274cdfee08b1 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -115,10 +115,10 @@ static uint32_t xs_request_enter(struct xb_req_data *req)
 {
uint32_t rq_id;
 
-   req->type = req->msg.type;
-
spin_lock(&xs_state_lock);
 
+   req->type = req->msg.type;
+
while (!xs_state_users && xs_suspend_active) {
spin_unlock(&xs_state_lock);
wait_event(xs_state_enter_wq, xs_suspend_active == 0);
-- 
2.17.0

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

[Jaegeuk Kim]

On 05/08, Chao Yu wrote:
> On 2018/5/8 4:46, Jaegeuk Kim wrote:
> > On 04/27, Chao Yu wrote:
> >> On 2018/4/27 0:36, Jaegeuk Kim wrote:
> >>> On 04/26, Chao Yu wrote:
>  On 2018/4/26 23:48, Jaegeuk Kim wrote:
> > On 04/26, Chao Yu wrote:
> >> Thread A   Thread B
> >> - f2fs_ioc_commit_atomic_write
> >>  - commit_inmem_pages
> >>   - f2fs_submit_merged_write_cond
> >>   : write data
> >>- write_checkpoint
> >> - do_checkpoint
> >> : commit all node within CP
> >> -> SPO
> >>   - f2fs_do_sync_file
> >>- file_write_and_wait_range
> >>: wait data writeback
> >>
> >> In above race condition, data/node can be flushed in reversed order 
> >> when
> >> coming a checkpoint before f2fs_do_sync_file, after SPOR, it results in
> >> atomic written data being corrupted.
> >
> > Wait, what is the problem here? Thread B could succeed checkpoint, 
> > there is
> > no problem. If it fails, there is no fsync mark where we can recover 
> > it, so
> 
>  Node is flushed by checkpoint before data, with reversed order, that's 
>  the problem.
> >>>
> >>> What do you mean? Data should be in disk, in order to proceed checkpoint.
> >>
> >> 1. thread A: commit_inmem_pages submit data into block layer, but haven't 
> >> waited
> >> it writeback.
> >> 2. thread A: commit_inmem_pages update related node.
> >> 3. thread B: do checkpoint, flush all nodes to disk
> > 
> > How about, in block_operations(),
> > 
> > down_read_trylock(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
> > if (fail)
> > wait_on_all_pages_writeback(F2FS_WB_DATA);
> > else
> > up_read(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
> 
> I sent one patch for that, could you check it?
> 
> Adding wait_on_all_pages_writeback in block_operations() can make checkpoint()
> wait pages writeback one more time, which break IO flow, so what's your 
> concern
> here?

Performance. And I can see wait_on_all_pages_writeback() waits only for
F2FS_WB_CP_DATA in checkpoint()?


> 
> Thanks,
> 
> > 
> > 
> >> 4. SPOR
> >>
> >> Then, atomic file becomes corrupted since nodes is flushed before data.
> >>
> >> Thanks,
> >>
> >>>
> 
>  Thanks,
> 
> > we can just ignore the last written data as nothing.
> >
> >>
> >> This patch adds f2fs_wait_on_page_writeback in __revoke_inmem_pages() 
> >> to
> >> keep data and node of atomic file being flushed orderly.
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >>  fs/f2fs/file.c| 4 
> >>  fs/f2fs/segment.c | 3 +++
> >>  2 files changed, 7 insertions(+)
> >>
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index be7578774a47..a352804af244 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -217,6 +217,9 @@ static int f2fs_do_sync_file(struct file *file, 
> >> loff_t start, loff_t end,
> >>  
> >>trace_f2fs_sync_file_enter(inode);
> >>  
> >> +  if (atomic)
> >> +  goto write_done;
> >> +
> >>/* if fdatasync is triggered, let's do in-place-update */
> >>if (datasync || get_dirty_pages(inode) <= 
> >> SM_I(sbi)->min_fsync_blocks)
> >>set_inode_flag(inode, FI_NEED_IPU);
> >> @@ -228,6 +231,7 @@ static int f2fs_do_sync_file(struct file *file, 
> >> loff_t start, loff_t end,
> >>return ret;
> >>}
> >>  
> >> +write_done:
> >>/* if the inode is dirty, let's recover all the time */
> >>if (!f2fs_skip_inode_update(inode, datasync)) {
> >>f2fs_write_inode(inode, NULL);
> >> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >> index 584483426584..9ca3d0a43d93 100644
> >> --- a/fs/f2fs/segment.c
> >> +++ b/fs/f2fs/segment.c
> >> @@ -230,6 +230,8 @@ static int __revoke_inmem_pages(struct inode 
> >> *inode,
> >>  
> >>lock_page(page);
> >>  
> >> +  f2fs_wait_on_page_writeback(page, DATA, true);
> >> +
> >>if (recover) {
> >>struct dnode_of_data dn;
> >>struct node_info ni;
> >> @@ -415,6 +417,7 @@ static int __commit_inmem_pages(struct inode 
> >> *inode)
> >>/* drop all uncommitted pages */
> >>__revoke_inmem_pages(inode, &fi->inmem_pages, true, 
> >> false);
> >>} else {
> >> +  /* wait all committed IOs writeback and release them 
> >> from list */
> >>__revoke_inmem_pages(inode, &revoke_list, false, false);
> >>}
> >>  
> >> -- 
> >> 2.15.0.55.gc2ece9dc4de6
> >>>
> >>> .
>

Re: [PATCH] watchdog: mena21_wdt: Fix a possible data race in a21_wdt_set_timeout

[Jia-Ju Bai]

On 2018/5/8 11:28, Guenter Roeck wrote:

On 05/07/2018 08:18 PM, Jia-Ju Bai wrote:

The write operation to "wdt->timeout" is protected by
the lock on line 118, but the read operation to
this data on line 105 is not protected by the lock.
Thus, there may exist a data race for "wdt->timeout".

To fix this data race, the read operation to "wdt->timeout"
should be also protected by the lock.



There is no race. There is already a mutex in the watchdog core which 
serializes
calls to the various API functions. It would make more sense to drop 
drv->lock

from the driver.



Thanks for your reply :)
Need I submit a patch of dropping all calls to "drv->lock"?


Best wishes,
Jia-Ju Bai

Re: [PATCH 2/2] net: nixge: Address compiler warnings about signedness

[David Miller]

From: Moritz Fischer 
Date: Fri,  4 May 2018 10:18:34 -0700

> Fixes the following warnings:
> warning: pointer targets in passing argument 1 of
> ‘is_valid_ether_addr’ differ in signedness [-Wpointer-sign]
>   if (mac_addr && is_valid_ether_addr(mac_addr)) {
>   ^~~~
> expected ‘const u8 * {aka const unsigned char *}’ but argument
> is of type ‘const char *’
>  static inline bool is_valid_ether_addr(const u8 *addr)
> ^~~
> warning: pointer targets in passing argument 2 of
> ‘ether_addr_copy’ differ in signedness [-Wpointer-sign]
>ether_addr_copy(ndev->dev_addr, mac_addr);
>^~~~
> expected ‘const u8 * {aka const unsigned char *}’ but argument
> is of type ‘const char *’
>  static inline void ether_addr_copy(u8 *dst, const u8 *src)
> 
> Signed-off-by: Moritz Fischer 

Applied.

Re: [PATCH 1/2] net: nixge: Fix error path for obtaining mac address

[David Miller]

From: Moritz Fischer 
Date: Fri,  4 May 2018 10:18:33 -0700

> Fix issue where nixge_get_nvmem_address() returns a non-NULL
> return value on a failed nvmem_cell_get() that causes an invalid
> access when error value encoded in pointer is dereferenced.
> 
> Furthermore ensure that buffer allocated by nvmem_cell_read()
> actually gets kfreed() if the function succeeds.
> 
> Fixes commit 492caffa8a1a ("net: ethernet: nixge: Add support for
> National Instruments XGE netdev")
> Reported-by: Alex Williams 
> Signed-off-by: Moritz Fischer 

Applied.

Re: [PATCH 09/24] selftests: ftrace: return Kselftest Skip code for skipped tests

[Masami Hiramatsu]

On Mon, 7 May 2018 11:17:21 -0400
Steven Rostedt  wrote:

> On Fri,  4 May 2018 19:13:13 -0600
> "Shuah Khan (Samsung OSG)"  wrote:
> 
> > When ftrace test is skipped because of unmet dependencies and/or
> > unsupported configuration, it returns 0 which is treated as a pass
> > by the Kselftest framework. This leads to false positive result even
> > when the test could not be run.
> > 
> > Change it to return kselftest skip code when a test gets skipped to
> > clearly report that the test could not be run.
> > 
> > Kselftest framework SKIP code is 4 and the framework prints appropriate
> > messages to indicate that the test is skipped.
> > 
> 
> I'm fine with this change, but I believe Masami and perhaps others
> have scripts that expect zero return.

Oh, I'm happy with updating my script to follow the kselftest
framework spec, since that is the standard.

Shuah, is there any document which describe the return code for
kselftest framework? (And I think it should report some FAIL/PASS counts
to kselftest

However, this patch seems not working as you expected.
If kselftest framework would like to get the SKIP code from ftrace script,
you need to update TOTAL_RESULT before leave.

> If anything, we probably need to have a way to override the ksft_skip
> via a command line argument.
> 
> Masami?

Agreed. Maybe we can pass the option via an environment variable.

Thanks,

> 
> -- Steve
> 
> > Signed-off-by: Shuah Khan (Samsung OSG) 
> > ---
> >  tools/testing/selftests/ftrace/ftracetest | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/testing/selftests/ftrace/ftracetest 
> > b/tools/testing/selftests/ftrace/ftracetest
> > index f9a9d424c980..b731c8cdcffb 100755
> > --- a/tools/testing/selftests/ftrace/ftracetest
> > +++ b/tools/testing/selftests/ftrace/ftracetest
> > @@ -23,6 +23,9 @@ echo "If  is -, all logs 
> > output in console only"
> >  exit $1
> >  }
> >  
> > +# Kselftest framework requirement - SKIP code is 4.
> > +ksft_skip=4
> > +
> >  errexit() { # message
> >echo "Error: $1" 1>&2
> >exit 1
> > @@ -30,7 +33,8 @@ errexit() { # message
> >  
> >  # Ensuring user privilege
> >  if [ `id -u` -ne 0 ]; then
> > -  errexit "this must be run by root user"
> > +  echo "Skipping: test must be run by root user"
> > +  exit $ksft_skip
> >  fi
> >  
> >  # Utilities
> > @@ -249,7 +253,7 @@ trap 'SIG_RESULT=$UNTESTED' $SIG_UNTESTED
> >  SIG_UNSUPPORTED=$((SIG_BASE + UNSUPPORTED))
> >  exit_unsupported () {
> >kill -s $SIG_UNSUPPORTED $SIG_PID
> > -  exit 0
> > +  exit $ksft_skip
> >  }
> >  trap 'SIG_RESULT=$UNSUPPORTED' $SIG_UNSUPPORTED
> >  
> 


-- 
Masami Hiramatsu 

Re: [PATCH] selftests: net: use TEST_PROGS_EXTENDED

[David Miller]

From: Anders Roxell 
Date: Fri,  4 May 2018 18:47:25 +0200

> When a script file that isn't generated uses the variable
> TEST_GEN_PROGS_EXTENDED and a 'make -C tools/testing/selftests clean' is
> performed the script file gets removed and git shows the file as
> deleted. For script files that isn't generated TEST_PROGS_EXTENDED
> should be used.
> 
> Fixes: 9faedd643fd9 ("selftests: net: add in_netns.sh 
> TEST_GEN_PROGS_EXTENDED")
> Signed-off-by: Anders Roxell 

Applied.

Re: [PATCH] watchdog: mena21_wdt: Fix a possible data race in a21_wdt_set_timeout

[Guenter Roeck]

On 05/07/2018 08:18 PM, Jia-Ju Bai wrote:

The write operation to "wdt->timeout" is protected by
the lock on line 118, but the read operation to
this data on line 105 is not protected by the lock.
Thus, there may exist a data race for "wdt->timeout".

To fix this data race, the read operation to "wdt->timeout"
should be also protected by the lock.



There is no race. There is already a mutex in the watchdog core which serializes
calls to the various API functions. It would make more sense to drop drv->lock
from the driver.

Guenter


Signed-off-by: Jia-Ju Bai 
---
  drivers/watchdog/mena21_wdt.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/mena21_wdt.c b/drivers/watchdog/mena21_wdt.c
index 25d5d2b8cfbe..05ca69042829 100644
--- a/drivers/watchdog/mena21_wdt.c
+++ b/drivers/watchdog/mena21_wdt.c
@@ -102,14 +102,15 @@ static int a21_wdt_set_timeout(struct watchdog_device 
*wdt,
return -EINVAL;
}
  
+	mutex_lock(&drv->lock);

+
if (timeout == 30 && wdt->timeout == 1) {
+   mutex_unlock(&drv->lock);
dev_err(wdt->parent,
"Transition from fast to slow mode not allowed\n");
return -EINVAL;
}
  
-	mutex_lock(&drv->lock);

-
if (timeout == 1)
gpio_set_value(drv->gpios[GPIO_WD_FAST], 1);
else